PDA

View Full Version : ZSID on the Superbrain



JonB
June 16th, 2017, 11:37 PM
Superbrain threads are like buses round here. You wait ages for one, then ten come along at the same time. :D

Anyway.. today I tried to run ZSID on my 'brain but it crashed, nastily. Before I break out the toolchains and start banging my head against a brick wall, I thought I'd ask if anyone has a copy of a working ZSID for this fab computer, or any thoughts as to why the standard ZSID won't work.

My view is that the Superbrain's non standard memory map is to blame, but I need to understand what ZSID is actually doing first. At a guess, it copies itself to the top of the TPA, overwriting CCP at start up, then jumps to the load routine. Then, the program to be debugged is loaded at 100h and off we go. Also, I believe it uses RST38 for single step - I need to see if that is in use.

Your thoughts?

SteveH
June 17th, 2017, 01:00 AM
Just a thought, but does the Superbrain use RST38 for its own internal use? If so, it may explain why it crashes when ZSID resets it to point to its single stepping routines. IIRC there are other versions (or patched copies) of ZSID available that use a different RST for the single stepping (possibly from something like a ZX Spectrum version of CP/M). Have you tried a copy of SID or DDT - I'd expect the same crashes as they too use RST38 (by default). You could knock up a noddy program that simply displays the RST38 address - then you'd have an idea if it's pointing to something Superbrain specific.

HTH

Chuck(G)
June 17th, 2017, 08:48 AM
Does the Superbrain use RST38 (RST 7 in 8080 terms) as an interrupt service vector, say for the keyboard or diskette? As SteveH has said, both DDT and ZSID can be patched to use a different vector. FWIW, if DDT runs on your system, do you know what vector it uses?

JonB
June 18th, 2017, 11:03 PM
As I thought.

There's a jump at 38h so RST38 is already in use (checked it with a small BASIC proggie). I'll have to hunt around to see if there is another version of ZSID that uses a different RST vector - unless anyone has one already?

@Chuck: yes, I have DDT running but I don't know what vector it uses. I suppose the way to tell would be to dump all the RST vectors with a program and compare with the same under DDT.

(Edit: Looks like Superbrain DDT is using RST 6, how very annoying of it..)

JonB
June 18th, 2017, 11:25 PM
Found a patch on Gaby's site to change RST 7 to RST 6 in SID 1.4. It's used for the Amstrad PCW machines which, like the Superbrain, are using RST7 already.

One quick hack later and we have a working ZSID.

39162

What a great hobby!

lowen
June 19th, 2017, 05:19 AM
FWIW, the TRS-80 Model 4 uses mode 1 interrupts and so the Montezuma Micro CP/M for the Model 4 should also have a 'non-RST 38H' patched SID/ZSID.

Chuck(G)
June 19th, 2017, 10:07 AM
Another nasty with the Z80 and CP/M is that some hardware uses the NMI feature, whcih vectors to 0066h; right in the middle of the first default FCB, making the NMI feature useless, unless also accompanied by extra hardware to re-map the vector.

Of course, CP/M was developed on the 8080, which lacks that feature; but somehow the 8085 managed to provide the same feature with the TRAP facility, vectoring to 0024h, out of the way of anything that CP/M cares about.

lowen
June 19th, 2017, 10:39 AM
Another nasty with the Z80 and CP/M is that some hardware uses the NMI feature, whcih vectors to 0066h; right in the middle of the first default FCB, making the NMI feature useless, unless also accompanied by extra hardware to re-map the vector.

The TRS-80 Model III (and thus the Model 4 as well) used NMI for the floppy controller's data request. Any CP/M for TRS-80 Model 4 needed to deal with this.


Of course, CP/M was developed on the 8080, which lacks that feature; but somehow the 8085 managed to provide the same feature with the TRAP facility, vectoring to 0024h, out of the way of anything that CP/M cares about.

I'm not sure how Montezuma Micro got around it; I've never looked at its internals. But on the TRS-80 Model 4 NMI had a pretty vital role as the vector for the floppy controller's data request interrupt; MM fixed it some way or another. The 8085 half-RST IRQs and its TRAP were good design features; I'm not sure which conceptually came first, the Z80 NMI or the 8085 TRAP (the timeline is pretty tight, with the Z80 and the 8085 developed in parallel and released within months of each other).

With as many Z80 CP/M machines as were out there, one would think there was a pretty standard way of dealing with this.

Chuck(G)
June 19th, 2017, 11:08 AM
I was looking at replacing an 8085 with an NSC800 (I've still got a bunch of the things) to give me access to the Z80 instruction set. The host hardware uses the 8085 TRAP line for things like I/O timeouts. I looked at how that would translate to the NSC800 NMI and basically decided that it wasn't worth the effort, as existing 8085 software (not CP/M) used 0066H.

Another project shot down by details...but if that wasn't there, I don't know how well the NSC800 would have played with the 8202 DRAM controller or the 8257 DMAC...

JonB
August 27th, 2018, 08:16 AM
Oops, the file was corrupt! Try this one...

Alphasite
August 27th, 2018, 11:19 AM
The TRS-80 Model III (and thus the Model 4 as well) used NMI for the floppy controller's data request. Any CP/M for TRS-80 Model 4 needed to deal with this.



I'm not sure how Montezuma Micro got around it; I've never looked at its internals. But on the TRS-80 Model 4 NMI had a pretty vital role as the vector for the floppy controller's data request interrupt; MM fixed it some way or another. The 8085 half-RST IRQs and its TRAP were good design features; I'm not sure which conceptually came first, the Z80 NMI or the 8085 TRAP (the timeline is pretty tight, with the Z80 and the 8085 developed in parallel and released within months of each other).

With as many Z80 CP/M machines as were out there, one would think there was a pretty standard way of dealing with this.

I'll have to look at my Model 4 BIOS. I know I used ZSID all the time and I don't remember patching it.