Modified Sega Megadrive - what did they do to it?

Actually, taking a closer look at the Cross Products unit, there's no ICE provided by the unit at all! What it does is remove the M68K chips from the Mega Drive and MegaCD units, and replace them with regular M68K chips on the SNASM board itself, with some extra hardware sitting in the middle, but there's no "In Circuit Emulator" as such. What they've done is simply add logic between the M68K processors and the rest of the system, which is able to snoop on the bus while the processors are running, and halt or intercept bus operations where required. This is enough to give basic debugging functionality, such as the ability to set breakpoints, read and write to memory locations, etc, from the debugger itself, but it's not a full blown emulation of the processor. This is a good idea, as it gives 90% of the features a developer usually wants, at 10% of the price of a full blown ICE unit.

Some of the features the ZAX ICE unit would be able to provide over and above the SNASM system are as follows:
-Logic analyser. This is a pretty powerful feature, especially for debugging timing related problems, or problems related to bus requests.
-Trace functionality, without introducing delays (SNASM does have trace support, but it would probably have to rely on trace interrupts, slowing down code execution dramatically. Not sure though, if their bus monitoring is clever enough, they could avoid using trace interrupts)
-More powerful breakpoint features. I don't think the SNASM system can break on memory read/write at a target address for example, which the ICE unit certainly could.

Again, for more detail, we'd need to compare the SNASM manuals with the ZAX 318P manuals.

 

Thanks for the proper information and corrections.

 

I've purchased both. Just need a scanner

 

??? The ZAX isn't a true emulation of the processor either, can you imagine how many 74 series and SPLD that would take and how slow it'd have to run? It's built exactly the same way--a stock 68K with a lot of small logic tacked on. Breaking on an address/interrupt is the ONLY kind of breakpoint it can do since the thing doesn't have it's own instruction decoder to understand the CPU state, it just has a handful of hardware address comparators for breakpoints. Any kind of conditional debugging must be in software with a debug monitor so while it won't necessarily require debugging stubs in your program, conditions will cause runtime slowdown. Tracing probably uses a circular buffer that just logs all access so the disassembler has context on a break. The only other hardware feature I can think of is having RAM which shadows/overlays the work RAM and optionally registers. It could possibly do something like log instructions accessing an address but not likely given the memory width needed for that.

I also don't think the ZAX has a general purpose logic analyzer either, that would be a useless feature to monitor the bus that will operate as specified. Nobody uses ICE for developing hardware, you'd just use a real logic analyzer. If you read something about a LA it probably just has LA-like triggering but more than a couple states deep is doubtful given the hardware constraints. The original ICE in existence *were* logic analyzers with CPU pods so they had access to "deep" triggering, but they also had $10k/unit custom LSI to implement the functions (which are still primitive).

I don't really understand the fascination here now with software emulators. Today it would be absolute hell to use one of these things. Sure they're a novelty, but they aren't even first-party so collectable? Your call.

 

I was basing my assumptions about what features the ZAX-318P has based on what info Charles MacDonald gave on the ZAX-308P in that SMSPower thread I linked to, and the manual for the ZAX ICD-278 Z80 ICE he referenced. That documentation and his comments indicate it does have a full history of the bus signal state, with probes that can trace and break on custom signals, and it does have advanced breakpoint features (check page xi of the manual). The Z80 ICE can also break on an "llegal" (unsupported) instruction, so that ZAX unit at least must be doing its own instruction decoding. I strongly suspect the ZAX-318P has a similar feature set. You're probably right in the sense that the ICE unit doesn't "emulate" the chip (I was wondering how it could possibly do that in realtime), but it must have a LOT of hardware sitting between the chip and the system.

 

I'm writing an emulator, and I'm very aware of how inaccurate current emulators are, especially when it comes to MegaCD and 32x emulation. A lot of problems are caused by a lack of information about how the real system behaves under various conditions, and the only way to find out how it really behaves is to test it on the real system, and some things are very hard to test without making significant modifications to the release units. I'm interested in these units from a technical point of view. Do you need them? No. Can they help? Definitely.

 

I write emulators too, but I don't see how an ICE can help any more than an EPROM emulator or even controller-PC interface for running tests. I think you're biased since you're interested in them To learn anything outside of the software realm a logic analyzer is the best shot, but sometimes without internal documentation or with pins so small only ridiculously priced clips can attach to them there's not a lot you can do but rely on your most clever software tests (which will run from anything).

 

Sure I'm biased. I have a technical interest, but I'm a collector too. Hey, what can I say, I "just want one" .

Still, I tend to think you can never have enough tools. I agree a general purpose logic analyser beats this out, but this could still be useful. It really depends on the system you're working on, and the level of information you require. Most emulators don't aim for cycle-level accuracy, so this level of detail isn't required, but if you want to go further than what you can examine through software tests, in particular for really precise timing information, you need some specialized hardware. As you pointed out, hooking a logic analyser in can be very difficult. I had to do a lot of physical modifications to my Mega Drive unit in order to attach a logic analyser into the private VRAM bus, and there are a million probes running everywhere, which are easy to bump and dislodge. The sample buffer size is only so big too, and it's not always easy to figure out how to set a trigger to observe the event you want to examine. Now this unit wouldn't have helped with that analysis, but I'm going to do a lot of snooping on the Z80 and M68000 in the future, to gather enough data to obtain complete cycle-level accuracy in terms of the timing and order of external bus operations within each opcode. If this unit could take some of the pain out of that, it'd be worth it. Is it worth to me what I'd probably have to pay to get one? I doubt it, but hey, if by chance I saw one going for $50, I wouldn't walk past it .

 

Jeeze that case is obliterated. Why wouldn't he just pull the mobo out of the case and work with it bare bones?

 

It looks like the CPU has been swapped to an MC68000P12 (clocked at 12Mhz IIRC) rather than the standard MC68000P8 in PAL units (clocked at 7-8Mhz), should be good for when you lose a lot of rings in Sonic, no slow down!

 

They totally did it so they could play Sonic 2 multiplayer without the slow down

 

The slowdown in the Sonic 2 game with massive ring loss has always been very annoying. Perhaps the cheap developers who had this were attempting to fix the slow down issues games like this had with the stock clocked MC68000.