12 replies to this topic

[X-thunder28]

You don 't have give any news about your <{GNULINUX}> on AFX!
What about it??

lol:

7' />8' />9' />
4' />5' />6' />
1' />2' />3' />

[huhn_m]

I'm really sorry but I had no time to develop it any further in the last months since I work on my game for the ucn game competition.
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!

[huhn_m]

THe problem with the comport was solved! It was due to an error in my send script that misinterpreted a param.

YOu could answere my other questions thought. You aren'T online very often are you?

[CrimsonCasio]

huhn, I advise you go ahead and make the huge basic file, anyone that can upload your game can also back up their programs. if you need to do that to get done in time then bye all means go ahead (just fix it in an update )

[X-thunder28]

sorry, huhn, but i sometime forgot to look in this forum.

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!

[huhn_m]

Thanks for the reply!

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?

[mastermage]

Yes Whyp found a way to overwrite RomDos (this a project called SHINE http://shine.sourceforge.net ) but it's buggy (most programs don work on my Graph100+)

[X-thunder28]

"After each byte sent there is an acknowleding byte sent back from the receiver. Is this the cause for slow transfers?"

hmm i think you should send some byte and after control if the lenght received is the same that the lenght sended!

[huhn_m]

Yes this is probably faster. But i've no time to fix it now since i'll risk messing up the transfer routines again.
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.

[2072]

yes you have to make a checksum of those 128b it's better that just count them, you should also set the transfer rate to 115200bps.

[huhn_m]

i have it at 115200 bps. it seems incredibly slow though ... maybe it is because the receive routine is laid on the timer? (int 08h)
(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.

[X-thunder28]

You have to receive/send in the program directely without interruption!

[huhn_m]

ok i'll do this whenever fast transfer is needed (data >= 1 KB).
Thanks