SevenFFF wrote: ↑
Tue May 19, 2020 4:00 pm
It doesn’t fit in the UART buffer though, so you will have to be very timely in emptying that. I don’t know if this is why you had reports of unreliability. The buffer could easily be full before you start, so you should drain it first.
It would be better to use a chunk size which fits in the UART buffer.
Since transferred files can probably can be larger than the entire Next RAM, you are really at the mercy of the SD chunk save speed, which can vary with environmental factors as you discovered. So a protocol which uses chunks <=512 and which delays the send of the next chunk until save is complete is the only way you can be completely robust. This is probably why you had issues with 2meg yourself.
Congrats on the release
The whole protocol is next-driven, so the server doesn't send anything unless the next asks for the next bit of data, so the SD card speed doesn't matter.
I can see that there may be problems in two places: either the uart buffer is overrun, or we stop waiting for data to arrive too early for some reason. Maybe the wifi packet is fragmented and parts of it arrive too late, or something.
When I upped the z80 clock and things broke, it was a case of emptying the uart fifo too fast and giving up on receiving. Adding more delays made things work. That was with the default bit rate, though.
Upping the bit rate and breaking does sound like the buffer may be overrun. At 2 megabits we're talking 250 000 bytes per second. At 28MHz that means we have around 100 clocks to process a byte, which isn't a lot. I think you're correct!
What's still a mystery to me is what the video clock have to do with any of this. I'm using the prescaler calculation code from .uart source so that part should be dealt with.
And why does this work for me (with vga4 50hz as far as I recall), but other people are having trouble.