Why not use the movem instruction in the monitor

[radexx]

Hi, First things first: Very nice project. Congrats.

Why not using the movem instruction to save and restore the registers?. It would be faster since a lot of instruction fetches (and decodes) are avoided, and the monitor will take up less ROM saving you some valuable Flash space in the UMDK cart and some even more valuable addresses in the limited 68K ROM area. Probably the dXSave/aXSave/fpSave labels don't make sense anymore and you want to change its name to something more meaningful...

Cheers!

[makestuff]

Welcome to the project!

I was thinking of movem when I wrote this code, but at that time it had been ~15 years since I wrote any 68000 code, and I wasn't sure it would support any addressing-mode other than address-register with postincrement/postdecrement. Also I was at that point debugging the GDB bridge, and wanted very explicit code.

So, bottom line, I like your patch. Have you actually tried it with a real UMDK cart? I don't have mine setup right now but if you've tried it that's good enough for me.

Two minor changes:

(1) Can you resubmit your PR against the dev branch rather than master? I merge up from dev to master when doing a new release, so master always matches the most recent release. (2) Can you make the changes you suggest in your comment (i.e delete unused labels and rename d0Save to regSave)?

[radexx]

Hi Chris, Wow, that was a quick reply!

Nope, I haven't tested it on the actual hardware beyond checking that it compiles.

On a side note: I don't have an UMDK cart. I'd like to, but I'm unsure where to order one (SpritesMind was a bit misleading), and I'm afraid it would probably be too expensive for just hobbyist purposes. Perhaps you can clear this up for me. I'm developing some stuff on emulators. Every time I want to try my code on the real hardware I use a Mega Everdrive (very time consuming and cumbersome), and of course I can't debug.

Amusingly enough, I had a side project in mind, and would love to hear your thoughts on it:

I was thinking of building an extension to the Everdrive cart. I would talk to it through SPI by plugging an AVR uC to the SD card slot, where the firmware would forward the SPI commands to the PC via RS232 over USB. In a nutshell, my GDB bridge would serve three purposes:

• Emulating the basic card commands for initialization, reads and writes
• Creating a virtual FAT32 filesystem in RAM containing the EverDrive BIOS and the ROM file I want to test and serving it to the cart via the SD card SPI protocol
• Sending GDB commands and getting responses via raw SPI once the ROM is up and running (this is possible since the EverDrive exposes the raw SPI bus with a data and a control register in a similar fashion as the UMDK does).

Of course my code would need to have the monitor built into it (plus the interrupt vectors and stuff), besides, I would also need to patch the ROM with ILL (and probably NOPs) everytime I set a breakpoint, and I wouldn't be able to debug commercial games, but it should be good enough for homebrew demos and stuff. Bottomline: Less cool but probably cheaper.

Second side note: I was very excited to hear that Visual Studio 2015 comes with GDB support :)

Back to the patch: (1) Sure, I will resubmit my PR on the dev branch (2) No problem

Thanks! MIke

[makestuff]

Unfortunately your manufacturing options are limited. It may be possible to do a Kickstarter campaign and get the electronics manufactured in China, but my gut feeling is that there are not enough people interested to make it worthwhile. Another problem is that there have been several false starts to the manufacturing process, and a bit of acrimony on SpritesMind, neither of which have done the project any favours. Right now I have a kind of laissez-faire attitude; I'll help new users get up and running and I'll help developers extend UMDK further, but I don't intend to put a lot of time into developing it further on my own.

Your Everdrive idea is ingenious. I'm not familiar with the product though so I don't know if it's feasible.

• Timing could be a problem: most people who write SD-card drivers (myself included) take a fairly hacky approach, by making it work with the SD-cards they have to hand, and then doing bug-fixes when people complain that it doesn't work with their cards. So the extra latency involved in marshalling over USB might prove problematic.
• Your PC/USB interface will not be able to directly write to the EverDrive's memory; the monitor will have to do it, and unfortunately, writing to the ROM area (needed for, e.g breakpoints) could be problematic. The EverDrive may write-protect its onboard RAM once a ROM image has been loaded (UMDK does this too). Also, IIRC MD2 only strobes one side of the write bus in the 0x000000-0x3FFFFF region whereas MD1 strobes both /UDSW and /LDSW. UMDK gets around this problem in the SD-card code in standalone mode by loading into the bottom of the SDRAM through a mapping higher up in the MD address-space using the SSF2 registers.

Another EverDrive-based option could be to use the MD1's EXT port (which is basically an RS-232 interface) to implement the GDB remote-serial protocol. You're back to issues with write strobes and EverDrive ROM write-protect, but you could certainly set breakpoints in code copied into the MD's onboard RAM, which would be better than nothing.

[radexx]

Hi Chris, Sorry for abusing this thread, but I don't know of a better way to contact you, and this chat is just getting too interesting :) .

Thanks for your thoughts on my side project. Everdrive MD

• The Everdrive MD (unlike the Mega Everdrive) is a Flash Cart.
  • It's basically a CPLD (Altera MAX II EPM240T100C5N with on-board ROM) and an 8-meg flash chip.
  • The bottom 4 meg contain the first stage bootloader, a small 68K program that is exposed in the $000000-$3FFFFF area on power on, tries to init the SD card and loads EDMD/MDOS.bin, which seems to be the menu program itself, which I believe is loaded into RAM. Then it jumps to the menu entry point.
  • When choosing a game, the menu code issues SD card commands to read the bin file and burn it into the upper 4 megs of Flash. Once it's done, the cart does a hard reset and flips the upper and lower halves of the flash.
• I had no idea of the MD2 strobe issue
• The way the 68K erases and programs the flash indeed entails the 68K doing write cycles to some magic ROM addresses to advance a state machine in the CPLD, to finally access the location to be erased/programmed (in multiples to 4 bytes).
• Oddly enough, it seems to work on the MD2 as well... Probably they do the SSF2 mapping trick too.
• I'd be surprised if the Everdrive blocked flash writes once a ROM image is loaded, but it's possible. However, the Everdrive support built into the SGDK wouldn't make sense at all. https://github.com/Stephane-D/SGDK/blob/master/inc/everdrive.h https://github.com/Stephane-D/SGDK/blob/master/src/everdrive.c

Serial ports

• Yeah, that was the first thing that came to mind. In fact I've been playing around with the controller ports (there is no such distinction as a Serial port, because every controller port can be put into Serial mode, and the EXT port (which not all consoles have) is also a third controller port). Unfortunately there are some odds to this:
  • The baud rate is extermely limited (up to 4800 bps) and loading up the ROM which is the most time-consuming task would take even longer than unplugging the card, plugging it into a PC, overwritting the files, .....).
  • The FIFOs are just 1 byte long. If you don't read every single byte when it arrives, chances are that it will get overwritten before you save it.
  • There's a RX interrupt, but the latency is very high (5 ms according to my experiments), thus limiting even more the RX baudrate
  • There's no such thing as a "TX buffer empty" interrupt, you must poll it periodically. I used to do that in the HBlank interrupt, but as you might have guessed it severely hinders the TX baudrate.
  • But yeah, it might work for simple operations like memory and register R/W, or stepping as long as you use soft flow control.

SD emulation

• Totally agreed, Not sure what does it take to implement the bare minimum functionality (init, list directory, read file). It is my understanding that the command set is fairly small (you can see the internals in the links above). And as long as it works with the Everdrive I'm OK.

USB speed

• You're right. Even USB Full Speed (12 Mbps) can become a bottleneck if just forwarding raw SPI commands, but only during the initial ROM file transfer. I think that later GDB traffic would require very little bandwidth. Perhaps I could implement the FAT32 file system in the microcontroller and communicate with the PC at a higher level.

Conclussion

• It would take a lot of time and effort to get this right. More than I actually have. So getting an UMDK might be an option after all.
• I would be very happy to assemble and program it myself if I had the PCBs. I also do embedded electronics so I have the skills and the equipment (no BGA, reflow or rocket science involved here :) ).
• Perhaps I can buy both PCBs directly from you and get the components myself?.

Thanks again!! Mike

[makestuff]

I'm going to close this thread. Feel free to send future responses to prophet3636 at gmail dot com and we can continue the discussion via email.

If the flash-write is implemented as you say through the CPLD (which probably has some registers mapped at 0xA13xxx) then you don't need to worry about the write-strobe issue, and no SSF2 re-mapping is necessary. The gdb proxy would get commands like "write N bytes at address A", both for loading .elf files and for setting breakpoints, etc. That means whenever you set a breakpoint, it will have to write two bytes to the underlying flash, which is kinda clunky but totally doable.

The other host-link possibility is to only use the FAT thing for booting the monitor, and from there play with the cart's CPLD registers controlling the SD-card interface directly, and use it to implement a lower-level SPI-based protocol. Unfortunately the MD would be the "master" and your PC (or the microcontroller) would be the "slave". You could implement some kind of poll (e.g at the end of the vblank routine) on the MD side to check whether the PC has issued commands to execute, and build a fairly high-level custom protocol on the microcontroller (i.e rather than marshalling single SPI bytes over USB). I did something similar with this project: https://www.youtube.com/watch?v=HTOVBADSPMs which you're welcome to cannibalize.

In short, yes it would take some effort to get this going, but it sounds totally feasible, and it would offer an alternative route for people wanting to debug on real hardware. So if you've got the time you should definitely give it a go. I'd start by trying to get the SPI interface talking.

If you do want to build a UMDK cart I can sell you an LX9 blank PCB for ~$7 plus postage, but I don't have any of the bridge PCBs left. Luckily they're small, only 2-layer, and cheap to make. Someone on SpritesMind may have spares.