+Andrew Davie Posted September 6, 2020 Share Posted September 6, 2020 I assume the speed in downloading ROMs is slow because of PlusCart maintaining the (+) screen while downloading. But the game's immediately going to do all sorts of funny things anyway. I'd much prefer (I think) PlusCart to just abandon screen draw while doing a download. Perhaps the $4C4C "trick" might be usable here? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 2 hours ago, Andrew Davie said: I assume the speed in downloading ROMs is slow because of PlusCart maintaining the (+) screen while downloading. The (+) screen is running in VCS Ram. So the PlusCart is concentrating entirely on downloading already. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2020 Author Share Posted September 6, 2020 4 hours ago, Al_Nafuur said: The (+) screen is running in VCS Ram. So the PlusCart is concentrating entirely on downloading already. OK, TY. Where is the speed bottleneck? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 1 hour ago, Andrew Davie said: OK, TY. Where is the speed bottleneck? The communication between the ARM board and the ESP is a 115200 baud UART connection. The bottleneck is the 4K UART buffer in the ESP8266 firmware. If we try to download files larger than 4k in one request we might have buffer overflows in the ESP and bytes will be lost. So every ROM file is requested in 4K range request. The ESP does not close the http connection between these requests, but this only saves a few ms. The PlusStore server is located here in Germany and in Europe the timing for an request is usually below 60ms, from the US the timing for a request is 130-200ms, but from Australia the request time is about 450ms. For a 32K ROM with 8 requests this means 3,6s waiting. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 (edited) what irritates me is that since we changed the menu to 32 chars I moved the entries list from the VCS ROM to the ARM RAM so we could have more than 135 entries (or rows in text files) now up to 1024 entries can be stored in the PlusCart. The directory requests from the PlusCart are not split into multiple range requests (because 135 entries * (max 12 chars + 6 filesize + 1 filetype) has been always below 4k). But now these directory or text file responses can be much larger than 4K. And I haven't encountered any trouble with larger directories or text files so far. So I have build a test firmware where I changed the MAX_RANGE_SIZE from 4096 to 32768 bytes for the ROM loading. I am testing that build at the moment.. Edited September 6, 2020 by Al_Nafuur Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2020 Author Share Posted September 6, 2020 2 hours ago, Al_Nafuur said: The PlusStore server is located here in Germany and in Europe the timing for an request is usually below 60ms, from the US the timing for a request is 130-200ms, but from Australia the request time is about 450ms. For a 32K ROM with 8 requests this means 3,6s waiting. Is it possible to fire off a request while you are waiting for one already in progress? In other words, could you shoot off your next packet request about 400ms before you expect to receive the completed 4K you are waiting on? Another alternative is to embed a checksum in each 4K block, and do a re-request of failed block at the end, where the checksum failed. That would then let you not worry so much about buffer corruption/overflow - you could just "go for it" with sensible request spacing based on expected/calculated request times as above. So, I'm kind of thinking a pre-processing of ROM files into chunks which are checksummed. That's the block size the ESP requests (and retries if required). The preprocessing could even be done on-the-fly with variable chunk size, based on the connection performance. I'd have to think about this more; I just thought I'd throw some ideas up. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 2 hours ago, Andrew Davie said: Is it possible to fire off a request while you are waiting for one already in progress? In other words, could you shoot off your next packet request about 400ms before you expect to receive the completed 4K you are waiting on? The ESP8266 can have up to 4 parallel connections, but parsing the responses on the one UART line with the STM32 is a pain, and I am not sure if these 4 requests are sharing the same (4K?) buffer That's why I choose the transparent transmission mode which is much easier to parse, but only has 1 connection. I haven't had issues with my test firmware that is doing 32K range requests. I am not quite sure why this is working now. The 4K restriction is a very old restriction in this project. The first prototype(s) and PC USB Foca setups had a breadboard wire connection between the STM or PC and the ESP board, maybe that was causing some kind of delay because of CRC errors? Also I have done some software changes in the communication between STM and ESP in the last year, maybe one of this optimizations has solved the buffer overflow issue. I am going to test the 32K range request firmware on my first wired Prototype. If I it has loading errors for ROMs larger than 4K then it must be wires, if it's working the code changes have solved the issue.. @Andrew Davie do you want to test the firmware on your PlusCart? Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2020 Author Share Posted September 6, 2020 3 hours ago, Al_Nafuur said: @Andrew Davie do you want to test the firmware on your PlusCart? How about I get the other one running, and use that as a test victim? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 22 minutes ago, Andrew Davie said: How about I get the other one running, and use that as a test victim? manual flashing ? http://pluscart.firmaplus.de/pico/?flashing Good luck PlusCart.elf Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2020 Author Share Posted September 6, 2020 16 minutes ago, Al_Nafuur said: manual flashing ? http://pluscart.firmaplus.de/pico/?flashing Good luck PlusCart.elf 188.01 kB · 0 downloads I tried and failed to get the STMProgrammer thing to work earlier. I guess I'll have to give it another go. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 (edited) O 7 minutes ago, Andrew Davie said: I tried and failed to get the STMProgrammer thing to work earlier. I guess I'll have to give it another go. https://www.oracle.com/java/technologies/javase-jre8-downloads.html ? Or use a Windows PC (exceptionally) Edited September 6, 2020 by Al_Nafuur Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 6, 2020 Author Share Posted September 6, 2020 3 minutes ago, Al_Nafuur said: O Or use a Windows PC (exceptionally) I do not own a Windows PC. I did, however, try installing Windows in a VirtualBox and then STMProgrammer in that, and that did not work for me either. It was frustrating. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 6, 2020 Share Posted September 6, 2020 1 minute ago, Andrew Davie said: I do not own a Windows PC. I did, however, try installing Windows in a VirtualBox and then STMProgrammer in that, and that did not work for me either. It was frustrating. https://www.oracle.com/java/technologies/javase-jre8-downloads.html ? Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 7, 2020 Author Share Posted September 7, 2020 Installing software is the bane of my existence... this sort of thing happens to me ALL the time... I guess I will just have to wait. Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts