|
|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
View topic - Serial bootloader, now with whole RAM usage (and VRAM)
 |
| Author | Message |
|---|---|
|
 Serial bootloader, now with whole RAM usage (and VRAM)
 Posted: Sat Jul 14, 2018 1:56 pm Last edited by NeonMan on Mon Jun 17, 2019 10:17 pm; edited 8 times in total |
|
Click here for latest ROM.
Source code repository here A rewrite of my old serial bootloader. This program allows you to upload a binary to the SMS RAM via Serial Port and then execute it. I find it useful for test programs, alleviating the hassle of actually having to reflash a ROM chip every time. Connection and instructions on the ZIP file. This revision keeps using XMODEM-CRC at 4800bps as the protocol but allows up to 8K binaries, and the binary is always loaded at 0xC000, making programming of these ROMs a bit easier. The rewrite is a result of a self-imposed challenge to make a non-trivial tool use Zero bytes of RAM, and this is the result. Since loader uses no RAM, I can upload the biggest ROM possible to RAM :) Tested with: - Teraterm - Cypress CY7C65211 USB-to-UART converter 
|
|
  
|
|
|
Posted: Sun Jul 15, 2018 12:25 am
|
That's really impressive, especially using 0 bytes of RAM! I'm wondering now whether some tiny serial debugger could fit too, this cable could make some in-device testing so much simpler
|
|
|
|
|
|
Posted: Tue Jul 17, 2018 11:01 pm
|
| Impressive, and with XMODEM, no less. It's always fun writing bitbanged serial loaders/savers for old systems. | |
|
|
|
|
Posted: Wed Jul 18, 2018 12:30 am
|
Small update, serial port now runs at 9600bps making uploads sensibly faster and the ROM size smaller. See attachments.
Next in line would be making it boot from a TFTP server (over SLIP link) effectively connecting to the internet. Maybe I'll submit that on the next coding competition. The coding process has been documented on my homepage if you are curious. This is my first completed pure assembler project ^_^ 
|
|
|
|
|
|
Posted: Wed Jul 18, 2018 3:07 pm
|
| After reading the blog post, this is really quite cunning. It's a shame it can't work with "normal" software, but maybe a RAM cartridge could help there. Hopefully the assembler bug will get you writing more... | |
|
|
|
|
Posted: Wed Jul 18, 2018 5:42 pm
|
|
The primary motivation for this thing was and still is running test programs on the hardware itself. Making it use Zero RAM was just an itch I needed to scratch :P
A minor variant of this ROM that keeps retrying a download forever is loaded on the flash card, that way on my PC at any time I can upload test ROMs, read the ROM results using the same serial port, then automagically load the next test ROM if available. I only need to either press Pause or make the test ROM "exit" by jumping to 0x0000 |
|
|
|
|
|
Posted: Thu May 23, 2019 11:12 pm
|
|
I've retaken the development of this zero-ram bootloader to allow uploading of both the 8K RAM and the 16K of VRAM as to have the VDP graphics loaded before booting the Uploaded ROM.
Currently the bootloader can preload the VRAM by sending up to 16K of data past the 8K mark into the VDP but it does no integrity checking on whatever was uploaded to VRAM. Expect a V1.2 release and demo this weekend :) |
|
|
|
|
|
Posted: Fri May 24, 2019 12:50 am
|
Am i able to have a copy of this variant? I think it might be quite useful. |
|
|
|
|
|
Posted: Fri May 24, 2019 5:34 am
|
| Ive seen something like this for the MegaDrive/Genesis as well. Though the creator used a Ram Cartridge. | |
|
|
|
|
Posted: Fri May 24, 2019 6:58 am
|
I have attached a "preview" version of the loader (No CRC checking on VDP data) on both variants, regular, where you must press RESET/PAUSE to retry booting and bootloop variant where on error or timeout it automatically retries. Still labeled as V1.1 and makes no reference to VRAM feature. |
|
|
|
|
|
Posted: Fri May 24, 2019 10:08 pm
|
|
I'm consistently hitting a CRC error a the 8K VRAM mark and I'm not sure if it is a VRAM error or some weird timing issue. Can someone try running the ROM and make a transfer on their system?
Bootloader, instructions and a sample upload ROMs attached to this message. If you want quicker feedback use the email address on my profile. Edit: I'm screwing up. VRAM address setting and writes ain't being done properly. |
|
|
|
|
|
Posted: Thu May 30, 2019 10:45 am
|
|
Ive had a little play with this for you.
Had to make a cable up and had issues with it not working but got there in the end. The stupid usb adapter i had didnt seem to play ball.. i swapped it for a snap off one off a cypress development board and that worked fine. All of the test roms transfer fine expect rel-sample.waytoobig.sms. That seems to start filling up the vram and the xmodem transfer gets to 100% but never completes. I end up with with a bunch of lines on the display. 
|
|
|
|
|
|
Posted: Sun Jun 02, 2019 12:55 am
|
|
Waytoobig is expected to fail as it is .. well, too big (by one byte) for VRAM. It should have shown a bluescreen (or other colour screen) though.
I'm trying to fix the VRAM read/write code right now, one week too late. |
|
|
|
|
|
Posted: Thu Jun 06, 2019 9:18 am
|
Ive just had a chance to play with this some more and found something interesting. If i load it from my master ever drive and send "rel-sample.toobig.sms", it goes through fine and i get the hello world message. If i load it from one of the writable cards i build then it gets almost to the end then errors with a blue screen as you were expecting. Based on that, the menu on the every drive must be leaving the system in a different state to how the bios does? |
|
|
|
|
|
Posted: Mon Jun 10, 2019 10:36 pm Last edited by NeonMan on Tue Jun 11, 2019 4:02 pm; edited 2 times in total |
|
Finally completed the VRAM loads, one month later than expected. However, the VRAM writes are *very* inconsistent, many requiring multiple packet retries, slowing down the upload which eventually ends with a success. It also seems using 2 stop bits instead of one helps, which might indicate I'm very tight on timing during VDP uploads.
Do I need to follow any restrictions when writing/reading on the VRAM?
It shouldn't break no more on VRAM end. I hope. Edit: A Video showing the "wonkyness" of the upload is availavle here Edit2: Removed binaries from this post since they were very broken. |
|
|
|
|
|
Posted: Tue Jun 11, 2019 7:11 am
|
You should have at least 26 CPU cycles between writes (or reads) if screen is on (and not in vblank phase). When it's off or in vblank you shouldn't have any restriction. |
|
|
|
|
|
Posted: Tue Jun 11, 2019 7:31 am
|
|
Due to how the data is read, byte-by-byte from the serial port, that cycle limit is respected by a wide margin, however, the distance between VDP control read (reset) and control Write (addressing) could be shorter than the 26 cycles.
Does it matter? |
|
|
|
|
|
Posted: Tue Jun 11, 2019 1:09 pm
|
|
reading/writing VDP control port shouldn't cause any problem.
but if you're experiencing 'VRAM corruption' (VRAM contents aren't what they should be) it's a clear indicator that you're writing too fast, if the code is correct (I mean, if the algorithm is) |
|
|
|
|
|
Posted: Tue Jun 11, 2019 1:56 pm
|
|
Both the write and the test loops seem wide enough between writes and the test loop has a CRC calculation between bytes (also way past 26) TStates. So I guess is either a timing issue on the serial port (I'm too slow writing on the VDP) or the addressing code is wrong.
Addressing is performed like this: .macro set_vram_packet_addr packet, cmd IN A, (#0xBF) ;Clear VDP ;Command Low byte LD A, packet SRL A ; LSB in C LD A, #0x00 ; Clear A RRA ; Put packet LSB in A OUT (#0xBF), A LD A, packet SRL A OR A, cmd OUT (#0xBF), A .endm `packet` goes from 0 to 127, since XMODEM packets are 128byte in size, 128 packets fill all of VRAM. Just before a write cmd is set to 0x40 (command 1) and Just before a read is set to 0x00. Note it essentially uses a bit shift to multiply by 128. EDIT: whenever `packet` is A (as in the reg) it goes haywire. I think that's it... Cos I'm using it on the CRC test loop |
|
|
|
|
|
Posted: Tue Jun 11, 2019 2:45 pm
|
|
are you using a macro? are you using that 128 times?
macro are always prone to problems... OK, make sure packet is starting with # and isn't hex, then, and let's see. as for cmd too... but you can use #$40 and #0 if you prefer. |
|
|
|
|
|
Posted: Tue Jun 11, 2019 2:50 pm
|
|
Is used once per packet, for each of the 128 packets, then shortly after 128 byte Reads/Writes may happen.
`packet` is intended to be a register but works just as well with a #constant. Only issue is, `A` is not a valid reg to use. I fixed (but not tested yet) by changing it from set_vram_packet_addr A, #0
To LD D, A
set_vram_packet_addr D, #0 |
|
|
|
|
|
Posted: Tue Jun 11, 2019 3:58 pm Last edited by NeonMan on Wed Jun 12, 2019 8:45 pm; edited 1 time in total |
|
Yas! It seems to be working!
I'll test with a proper ROM/VRAM program later but I'm now getting silky smooth uploads with this revision. Attached ROMs and Source. Edit: Removed broken ROMs |
|
|
|
|
|
Posted: Tue Jun 11, 2019 6:30 pm
|
| Yes, the macro uses a so the value is destroyed later. Macros are not functions (something I got confused by at first), and you don't get C parameter semantics in assembly... | |
|
|
|
|
Posted: Wed Jun 12, 2019 7:55 am
|
|
A sample ROM that uses the VRAM data preloaded by the Bootloader. Emulator says it should work but will do some extra testing later.
Attached ROMs: * nyan.boot.sms (to be loaded via serial) * nyan.cartridge.sms (to use as a regular ROM) Source code on the same repo as bootloader, check first post. The second one just has some code that emulates how the Bootloader would load the data, copying 8K Code to RAM at and 16K of data to VRAM. |
|
|
|
|
|
Posted: Wed Jun 12, 2019 7:33 pm
|
|
Minor changes to loader and sample ROM and is done!
Bootloader now can upload 8K code and 16K VRAM data. (video) Attached is the ROM (both regular and bootloop) Edit: just for fun, this is how an upload looks when we aren't hiding the VRAM changes |
|
|
|
|
|
Posted: Thu Jun 13, 2019 9:24 am
|
Awesome work! Ive built a special purpose usb cable for this and also flashed it onto one of the cards i made. Makes testing stuff rather convenient!
|
|
|
|
|
|
Posted: Thu Jun 13, 2019 11:29 am
|
I've changed a couple things, for instance CRC errors are recoverable now and don't crash the loader. Check latest README.md on the last ROM. Also, on the repository, the source code and Makefile of the Nyancat ROM gives an example on how to make a ROM/VRAM image. I'm really happy to see someone else using this tool :D |
|
|
|
|
|
Posted: Mon Jun 17, 2019 10:16 pm
|
|
Got to work on some performance improvements and now a complete upload takes just below 30s by using the serial port at 14400bps. 19200bps is definetly doable, I can upload to RAM at that Speed but VRAM uploads are just too slow yet and fail.
Further improvements could be done when calculating the packet CRC, since close to 20% of the idle line time is spent validating the packet but I'm not sure how to further optimize it. Check the crc16-xmodem* files on the source repository includes. Help welcome! Next in line would be either further performance improvements and forwarding of interrupts to the uploaded ROM, especially INT without which the programming potential gets severely limited. Finally, attached to this post is an 8K ROM "selfboot" that makes a "bootable" ROM into a regular one by appending the bootable ROM to it at the end, good for testing bootable ROMs on an emulator. I hope this tool keeps being useful :) |
|
|
|
|
