What would be a DIY dev kit ?

[KanedaFr]

Hi,

it's been a long time it's bugging me so let me ask an open question :

We all know EA's SPROBE is a modified Genesis.
https://www.youtube.com/watch?v=FTnV2NqQwA8

But what is really modified ?
From various reports I read, we only know it supports
- "loading ROM from PC"
- "debugging features thanks a PC Card link"

So, in 2017, what could be done ?
Loading ROM from PC is already available to anyone thanks to various flash carts.
but what about debugging features ?
Yes, UMDK is an answer (and a great one) but I wonder if we could do the EA way : mod the Genny, not use an addon

- 68K In Circuit Emulator : to be able to debug code ?
- Z80 In Circuit Emulator (like the "official" one : http://www.smspower.org/forums/12038-ZA ... vkitAnyway)
- (V)RAM emulator : to be able to get a dump of RAM and VRAM anytime ?

What would make a sense to debug code on a real genesis ?
Matt is actualy developping Tanglewood this way (using the old SNASM Kit, https://twitter.com/big_evil_corp/statu ... 0475174912)
since the SNASM (or PsyQ) kit are very rare, expensive and need a old 486 computer under DOS, it's not for everyone.
So what could be done ? what surgery should be done to a Genny to add real time debugging over usb or ethernet or whatever ?
Does someone already tested / used some kind of hardware dev kit ?

[Mask of Destiny]

Basic 68K debugging is probably the easiest. All you really need is a RAM-based cartridge (like the UMDK or MED) or patch registers (think Game Gear or Action Replay), some kind of link to the host machine and a small debug monitor. Breakpoints are then implemented by replacing the instruction at a target address with an appropriate trap causing instruction and single-stepping can be done with trace mode. Supporting watchpoints would require some specialized hardware, but you could potentially still do it on a pure cart based solution though. Snoop the bus for writes to the appropriate address and then insert a breakpoint/invalid/trap instruction instead of the next cartridge-based instruction fetch.

Physically removing the 68K and putting it on a separate board would give you some more flexibility in watchpoint implementation as you have access to signals that aren't normally exposed to the CPU. For instance, using an NMI (interrupt priority 7) would then be possible and would probably be a cleaner way to handle entering the debug monitor.

For the Z80, implementing breakpoints without special hardware is pretty easy as long as you have some spare RAM for at least a small stub for the debug monitor (debug monitor itself could potentially live in ROM, but you would need enough code to change the bank at least). Anything more would probably require some specialized hardware that either sits between the Z80 and the system is it least hooked up to allow snooping on the bus.

I think the biggest problem with doing debugging on an actual system is that you can't easily stop the rest of the hardware when you stop the 68K. This makes debugging rather invasive. A modified console could potentially pause the clocks, but it was quite common for old chips to use DRAM cells for registers that will lose their value if the clock is stopped for too long or the frequency goes too low.

[KanedaFr]

I, perhaps wrongly, though a cart based solution won't be able to handle
- VRAM reading
- interrupts handling

The last one is currently what's avoid me to add GDB support to KMod : you could add a breakpoint, but if an interrupt occurs, you're dead.

I didn't know MED could be used as a basic debug cart....need to check what could be done, because it don't see how you could send back data (to PC where you're debugin code)

[KanedaFr]

OK, I found the extended_ssf-v2.txt which explains how to use MED's USB feature....
Need to finish my tool


So yes, I see how it could help for "basic" debug feature but breakpoint not seems something easy to handle, even more if using GDB
or we need a specific stub (what you call debug_monitor?) ?

[Mask of Destiny]

I, perhaps wrongly, though a cart based solution won't be able to handle
- VRAM reading

As long as you don't stick a breakpoint in the middle of some code that assumes the VDP address and CD registers are in a certain state, there's nothing preventing your debug stub/monitor/whatever from reading VRAM the normal way. Not super fast obviously, but should be sufficient if you want to inspect the state of things when stopped in a breakpoint

- interrupts handling

Not sure what the problem is here. Just mask out interrupts when you enter the debugger and restore the interrupt mask when you're done. If you're worried about pending interrupts firing at weird times when you exit the debugger, you can temporarily switch into Mode 4 and read from the control/status port to clear the pending flags.

The last one is currently what's avoid me to add GDB support to KMod : you could add a breakpoint, but if an interrupt occurs, you're dead.

Isn't it even simpler for an emulator? In BlastEm, I just pause the entire emulated system when the CPU is paused in either the internal debugger or GDB.

I didn't know MED could be used as a basic debug cart....need to check what could be done, because it don't see how you could send back data (to PC where you're debugin code)

I haven't heard of anyone actually doing so, but I don't see why it wouldn't work. And yeah, the extend SSF2 mode is what you want since it provides access to the serial/USB link.

So yes, I see how it could help for "basic" debug feature but breakpoint not seems something easy to handle, even more if using GDB
or we need a specific stub (what you call debug_monitor?) ?

So if you use the existing gdb stub, the only real work is to hook that up to whatever communication channel you're using. Doing it yourself is a bit more work, but not too complicated. Let's say you want to set a breakpoint at address $400. First, you read the word stored at $400 and save it somewhere. Then you replace that word with an appropriate instruction that will cause a trap (illegal or trap #). Then you make the debugger stub the handler for the relevant exception. On entrance to the stub, you save the register state somewhere. PC can be pulled from the stack.

Resuming execution is a bit trickier. You either have to execute the instruction somewhere else and then jump to the instruction after the one you patched or use trace mode. For trace mode, what you would probably want to do is undo the patch, enable the trace bit in the saved SR on the stack and then return from the exception handler using rte. This will execute one instruction and then invoke the trace exception handler. That exception handler would then need to restore the breakpoint patch, turn off trace in the saved SR on the stack and resume.

[BigEvilCorporation]

This is my dream kit: https://www.youtube.com/watch?v=A9zQueG ... zO11jhZ6qq

I don't know its full capabilities, or whether it's able to read VRAM (probably not), but it's a simple slot-in-and-play solution that's not unlike UMDK. If one of these ever hits eBay I'm dropping my life savings on it.

I also have two Gennys with socketed CPUs that need an ICE, if I can find one I'll let you know what it's like to work with. I also have a first edition SNASM box, just need the rest of the pieces (breakout cart + cable) and it's good to go, but I don't expect it'll be much different (workflow/features wise) to the SNASM2 kit I use on a daily basis. The only real benefit is it's designed for pure Genesis and not MegaCD, so I can break out of the 128kb MCD boot ROM area.

I'm not a hardware guy so I don't *really* know what I'm talking about here, but would the best solutions spawn from socketed chips with probes in the middle? Would be lovely to see a full Genesis modded with a USB port, and all the debug stuff built neatly inside it.

I wonder if we could get a UMDK in Lock-On cart form, and embed it inside the case...

[BigEvilCorporation]

I didn't know MED could be used as a basic debug cart....

Only the recent models: http://krikzz.com/store/home/33-mega-everdrive-v2.html

USB port for homebrew development and for future features.

[HardWareMan]

This is my dream kit: https://www.youtube.com/watch?v=A9zQueG ... zO11jhZ6qq
I don't know its full capabilities, or whether it's able to read VRAM (probably not), but it's a simple slot-in-and-play solution that's not unlike UMDK. If one of these ever hits eBay I'm dropping my life savings on it.

Wrong. Since this devkit uses regular console and interact with it only via slot the UMDK is more powerful. It can read VRAM but only via VDP. It emulate single step debugging because DTACK generate automatically within cartrige space. More powerful debug kit we already discussed. The link is dead, but small pictures is saved:


It is a MD1 with connector instead of M68K CPU. That connector is for debug board, that allow gain full control on CPU on it. Or even simulate a CPU, disabling real one.

But it is still has no true full control on the system. Because we have Z80 and VDP, that is not simple glue logic. They can act separatly and independ from main CPU and you can't get real state of hardware when you hit the break. The true full control availble only in emulator or simulator in FPGA. The last ones can freeze whole system logic and show you every state of every part of system. In micro or macro level.

I'm not a hardware guy so I don't *really* know what I'm talking about here, but would the best solutions spawn from socketed chips with probes in the middle? Would be lovely to see a full Genesis modded with a USB port, and all the debug stuff built neatly inside it.

I'm in progress to build this kind device. But my goal is different: I want to research and reverse engineering MD hardware and I don't care about software.

My advice from hardware guy: stop fooling around with old rare hardware. They place in the museum as part of the history. I hope some of them will get there. You already have most powerfull software devkit. UMDK abilities is greater then all those old rare devkits combined. You should start to create and develope software for UMDK. For Windows, Linux or even Mac (if any programmer will do it). I can help too, but for now I don't have any UMDK, maybe later.

[BigEvilCorporation]

UMDK only connects through cart slot, so unsure how it could compete with the Cross Products unit (it's an entire custom MCD board and interface), unless I'm missing something.

I am indeed developing software for it though, and really excited about it - currently making GDB improvements to read SNASM-format COFF files, then moving onto an automated test rig. Ultimately I want to write a code profiler with "heatmap" style code telemetry, once I've got my feet wet.

Can UMDK read VRAM?

[HardWareMan]

Yes, via VDP by M68K CPU way. All I were said previously is UMDK can everything that those devkit does and even more. It is all up to software and FPGA configuration part.

[Mask of Destiny]

In theory you could do even better than that if there's enough spare room in the FPGA. 68K bus snooping is theoretically enough to mirror the VDP state into the UMDK's RAM. Of course, you would probably want to fix the DMA issues first.

[KanedaFr]

Reading your post, it seems I made a big mistake thinking debugging through the cart connector only won't be enough...

I have the MED sitting here, time to use it for something interesting

[HardWareMan]

In theory you could do even better than that if there's enough spare room in the FPGA. 68K bus snooping is theoretically enough to mirror the VDP state into the UMDK's RAM. Of course, you would probably want to fix the DMA issues first.

That is real thoughts. Most of DMA can be snooped since it use M68K bus, but not copy or fill VRAM inside VDP. So, the only way is make VDP copy in FPGA, at least VRAM stuff part. But for now emulation is not perfect, because it based on outside blackbox observation and some poorly docs. That's why I try to push the decap process for MD's SEGA ICs.

[Jorge Nuno]

As a HW guy myself too, I totally agree with HardWareMan. Old debugging hardware is almost useless and it's good in a museum. A proper modern cart does it better, faster, more reliably, and doesn't require fiddling with oldass computer hardware/software that has no use othrwise. Acquiring the whole setup the devs used back in the days is pretty much impossible too.

My question is, how far deep to you need to go with debugging? Sure having the ability to look/freeze/change anything is awesome, but is it really needed?

With standard sega parts this is not fully accomplishable: One can look and take control of vram using a man-in-middle-attack device between vdp&vram but registers and other internal memories/states stuff can only be shadowed.

Solution is emulator, either software like exodus (and others to a lesser extent) OR hardware emulator. The second option is very expensive and I'm pretty sure nobody is in a position to be able to develop such a thing with the required accuracy with the current knowledge of the megadrive.