SpritesMind.Net

There is no facility currently to debug Z80 with breakpoints, etc. Such a thing may be possible but I personally concentrated on the 68000. There are some games where the music stops when the 68000 hits a breakpoint (I guess where the 68K is feeding the Z80 with notes to play), and there are others ...

I have a local build for win64 which needs some debugging because the behaviour of the Windows non-blocking I/O used in the GDB bridge is different from on Linux by the looks of it. Getting it working on Windows is not rocket-science though, it just needs someone with the time to work on it.

SDRAM may not work at 53MHz? really? lol As I've mentioned before, SDRAM is optimised for throughput, not latency. Achieving tight latency requirements, even those of the lowly MegaDrive, is non-trivial. It always comes down to a delicate balance between clock-speed and the timings in the SDRAM dat...

Yep, another complexity to take into account. Let's step back a bit. The ultimate objective is to switch the timestamp for each bus transaction in the trace-log from a 48MHz counter to the 7.6MHz VCLK. There are two proposed solutions, both of which are functionally identical (i.e from a user's pers...

Yep, true. Although it may appear & disappear as temperature rises & falls.

Right, but you can't know where in the VCLK period the VCLK-synchronous signals from the MD actually transition: there's no guarantee you won't get metastability problems. So you have to treat the multiplied clock like an asynchronous clock anyway. So why not avoid the complexity and just use the 48...

So I just checked the Spartan-6 coregen thing and I was wrong - the DCM can sync down to 5MHz, provided you have an integer multiplier. But since the result is effectively an asynchronous clock anyway, it still makes more sense to just keep the one 48MHz core clock and synchronise VCLK to that, I th...

Yeah but the only MD clock available is the 7MHz clock, no? And if you can't multiply it, there's no way to clock the SDRAM fast enough. And if you can multiply it, then it's a multiplied clock to which nothing is synchronous anyway (therefore everything would need to be explicitly sync'd to it with...

You won't be able to do that, (a) because the Xilinx DCMs won't sync to frequencies that low, and (b) the USB interface is fixed at 48MHz.

But you can sample & synchronise the VClk to the 48MHz core clock, and only increment the counter when you see it transition from 0 to 1.

Actually, that question could do with further elaboration. I can see how extra RAM would be useful in a traditional development environment, where the only way of tracing what's going on is to write log information and metrics to some extra RAM and then read it back later for analysis. But if you ha...

There is only one "free" FPGA I/O, and that is the one currently connected to the (unpopulated) DTACK transistor. You could re-route VCLK (via an unused level-shifter channel) to the FPGA like that. You should probably look at the 48MHz timestamps to test the assumption that all reads & writes (incl...

Certainly feasible. The SMS's Z80 could be made to do breakpoints and single-stepping using the RST instruction. But it would be more work because you probably can't just build a Z80 GDB and use that. But running and cycle-tracing code should be straightforward with very few changes to the VHDL.

As some of you are aware, thanks to KanedaFr, the USB MegaDrive DevKit now has its own forum here on SpritesMind ! I thought I'd post here an example of the UMDK bus-cycle trace, gathered from running Sonic 1 for a little over 18 seconds, from reset. I could sample all day without filling up my hard...

Phew. You had me worried for a moment there.

It's a two-board setup because the FPGA board is general-purpose; I designed it so it can be used in several other projects (I'm only tangentially interested in the MD). I have not seen evidence of /OE held low for multiple addresses. If you give me some code that does it I'd be happy to run it and ...