5 ms·

I feel like this would be an inferior development experience in 2022 compared to this approach: https://hackaday.io/project/1507-usb-megadrive-devkit https://ha

I feel like this would be an inferior development experience in 2022 compared to this approach: https://hackaday.io/project/1507-usb-megadrive-devkit https://hackaday.io/project/1507-usb-megadrive-devkit Which is an fpga in the cartridge that also serves as a gdb stub over serial. You can debug with gdb directly on the hardware.

tndata 5y ago
Original author here, wow! What a cool project!
- djmips 5y ago
  If you haven't implemented a debugger and want to you may contact me if you want to hear more about how we did it 'back in the day' if you are interested.
deleted 5y ago
[deleted]
mikepavone 5y ago
I have a UMDK and it's a neat piece of hardware, but it sadly has some design flaws that make it hard to recommend. One problem is that it doesn't make use of the !CE0 signal (the main chip select for the cartridge) on the cart slot which means it will get into bus fights on systems with TMSS (Trademark Security Sysstem, i.e. the thing that displays the "Produced or Under License by Sega Enterprises, Ltd." text). The bigger problem is that it has issues with DMA transfers on a lot of systems resulting in severe graphical corruption in some cases.
djmips 5y ago
It's probably better than what the original poster has made, however you can debug with gdb directly on the hardware with the simple design of bidirectional communication / dual port RAM and a little bit of ROM code to boot your debug code into the Genesis / MD memory. That's what we did. Single stepping is supported by using 68K trap instructions. The command set isn't very big. Mostly read memory / write memory / Run. I can't remember how we implemented stop but IIRC it was polling from an interrupt routine that was running from a timer. In any case you can get a lot of mileage out of a simple bit of hardware.
- jdmoreira 5y ago
  Thank you for your reply. Yes, I'm aware you can basically link a gdb stub within your own program as well. I want to encourage you to release your code if you still have it somewhere!
  - djmips 5y ago
    This code is from 1992. No Internet, no GitHub and many fragile hard drives ago... So much old code is lost to time.

tndata 5y ago

Original author here, wow! What a cool project!

djmips 5y ago
If you haven't implemented a debugger and want to you may contact me if you want to hear more about how we did it 'back in the day' if you are interested.

deleted 5y ago

[deleted]

mikepavone 5y ago

I have a UMDK and it's a neat piece of hardware, but it sadly has some design flaws that make it hard to recommend. One problem is that it doesn't make use of the !CE0 signal (the main chip select for the cartridge) on the cart slot which means it will get into bus fights on systems with TMSS (Trademark Security Sysstem, i.e. the thing that displays the "Produced or Under License by Sega Enterprises, Ltd." text). The bigger problem is that it has issues with DMA transfers on a lot of systems resulting in severe graphical corruption in some cases.

djmips 5y ago

It's probably better than what the original poster has made, however you can debug with gdb directly on the hardware with the simple design of bidirectional communication / dual port RAM and a little bit of ROM code to boot your debug code into the Genesis / MD memory. That's what we did. Single stepping is supported by using 68K trap instructions. The command set isn't very big. Mostly read memory / write memory / Run. I can't remember how we implemented stop but IIRC it was polling from an interrupt routine that was running from a timer. In any case you can get a lot of mileage out of a simple bit of hardware.

jdmoreira 5y ago
Thank you for your reply. Yes, I'm aware you can basically link a gdb stub within your own program as well. I want to encourage you to release your code if you still have it somewhere!
- djmips 5y ago
  This code is from 1992. No Internet, no GitHub and many fragile hard drives ago... So much old code is lost to time.