Hey huhn_m!
#1
Posted 19 October 2003 - 10:05 AM
What about it??
lol:
7' />8' />9' />
4' />5' />6' />
1' />2' />3' />
#2
Posted 19 October 2003 - 10:37 AM
I'm not sure if i'll finish the game in time though had a lot of things to do the last weeks and had no time to dev. anything the
last 14 days ... network is still buggy.
But the dev game me some ideas how <{GNULINUX}> could be improved and the game is partly based on the <{GNULINUX}> 2.0 routines (console etc.)
console has been improved. comport & grayscale have been improoved and the interrput system got better.
I have a problem with my game:
I have to store about 96KB of data in memory. This is too much to store in basic since ppl. have other progs on it.
No there are 2 possibilitys:
*overwrite dos
*flash basic and then reflash it if done.
What would you suggest? How do i do the first method and howmany ram can I get this way. WHat interrupts mus? I uninstall first?
I need 7Ch for my prog due to contrast.
How can I change ontrast to a fixed value WITHOUT using the interrupt?
How can I ensure that every byte has been received properly by the comport of the other calc?
Please help me or my progs will never get finished!
#3
Posted 21 October 2003 - 05:26 PM
YOu could answere my other questions thought. You aren'T online very often are you?
#4
Posted 21 October 2003 - 06:57 PM
#5
Posted 23 October 2003 - 04:25 PM
For your 96kB, you have to :
-use less memory, because, if i don't know what is your game, i know that the calc should run program that could be run on it.(it 's stupid, but i forgot that recently)
-compress your data with RLE method
I wonder what is your program!
"How can I change ontrast to a fixed value WITHOUT using the interrupt?"
I know that you can read the current value of contrast in a byte(in memory), i don 't know what will happen if you change this value!
"How can I ensure that every byte has been received properly by the comport of the other calc?" hmm a checksum for check packet lenght with resending in fail is a good solution... you should speaking of that with dada66, programmer of Flash100 and Gcomm, about that!
#6
Posted 24 October 2003 - 12:51 PM
You misunderstood me! The data (69K) is for maps that need to be sent from the server to the client to ensure both have the same versions.
And a Unitmap where several infos are stored. Due to security i can'T tell more. It has nothing got to do with the executable but is an additional file.
For Comport. I fixed my own routine. After each byte sent there is an acknowleding byte sent back from the receiver. Is this the cause for slow transfers?
(3 Kb in 40 secs)? THe maps usually are not this large (like 64K). This is only the biggest case. Usually everything will be arround 20KB
And there is no way to overwrite dos? I thought someone from the french forum found a way that he used in a program called command.com?
#7
Posted 24 October 2003 - 01:30 PM
#8
Posted 25 October 2003 - 06:49 PM
hmm i think you should send some byte and after control if the lenght received is the same that the lenght sended!
#9
Posted 26 October 2003 - 05:54 AM
I'll either fix it in the end or in an update after it is release since it is no bug but just annoying to wait 40 secs to transfer 3KB.
ShineOS ... He doesn't overwrite DOS yet. So if I could manage it i'd be the first. But since this is also not this important (and users
could free some rom like crimson said) this is also one of the last things done or fixed in an update.
Thank you to all for your help.
PS: What packet sice (to send) would you recommend? (since i must see that i have to resend it if it failed and this shouldn't take too long)
I think about 128 Byte would be ok. This will spare me a lot of transfer since only 24 Ack. bytes have to be sent.
#10
Posted 26 October 2003 - 06:04 AM
#11
Posted 26 October 2003 - 06:21 AM
(not the timer folow interrupt!).
Maybe i've to use a special way for sync task with huge amunt of data sent where i disable all thoose interrupts.
#12
Posted 26 October 2003 - 09:29 AM
#13
Posted 26 October 2003 - 10:05 AM
Thanks
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users