Which CP/M for a new port: 2.2 or 3?

[durgadas311]

Well, for directory lookups CP/M 3 with HASH buffers would work better. I guess if you have enough track buffers then you should essentially have the directories in memory most of the time.

Regarding the overhead, keep in mind that you are adding that ON TOP of whatever I/O needs to be done, and it is not insignificant even on a Z80. CP/M 3 will do bulk I/O (with multisector count, if the application uses it) directly between disk and the user memory, so that could be faster than using a track buffer and copying. The raw math doesn't always look as good in real life.

I also wonder, if you are caching multiple tracks, what the overhead will be when you sync to disk. lots of stepping to do in that case, you may need some sort of "elevator" algorithm to optimize it.

You've got a big project ahead of you, best of luck. Lots of interesting problems to solve.

[hjalfi]

It lives! It liiiives!

https://photos.app.goo.gl/zzUEzkA6aawoLUfw6

The tty emulation isn't there yet for WordStar, and that 6x8 font is really ugly, but it'll run all the command-line stuff I've thrown at it --- including Mix C, Microsoft Basic, BBC Basic, ADVENT, my own Cowgol compiler, etc.

This is with 5 x 9kB disk buffers arranged in an LRU cache. Writes are deferred until a buffer gets evicted. After the discussion on eviction strategies on disk change, I tried implementing some, and the results were awful: once you get used to running ADVENT with disk access only happening every ten or so rooms because everything is precached, waiting while it hits disk every time you do anything is intolerable. What I'll end up doing is making the user tell the machine when they've changed disks using a special key combination (and an on-screen banner). I mean, it's a dreadful user experience, but I think the alternative is worse. (CP/M 3, if I ever get round to implementing it, will work quite differently, of course.)

Performance is difficult to judge as I don't have any other real CP/M hardware (although I have just won an auction for an Epson PX-8 with FDD, which will be nice).

This machine does have an RTC, so I'll probably replace CP/M 2.2 with a clone with timestamp support. Dealing with the licensing labyrinth will be nightmarish but then I'll at least be able to run a benchmark.

[hjalfi]

I now have enough ADM 3a / Kaypro terminal emulation up and running that VDE works, Turbo Pascal works, etc. It's surprisingly usable. CATCHUM and ALIENS sort of work but the screen's the wrong size.

Most programs I've tried are pretty solid; some will reliably fail, either hanging or just behaving weird. For some reason, no C compiler I've tried will work. This is an oddly specific bug; what does my machine have against C? Some of my best friends write C. So obviously there's still something I'm doing wrong. Although it's strange that Turbo Pascal is entirely happy.

Question:

The manual doesn't say anything about which registers need to be preserved in BIOS calls; I've been assuming, none of them. If this isn't actually true, then this could be causing all kinds of weird behaviour, very much depending on what the language the program is written in, which would handily explain what I'm seeing. Is this something I need to worry about?

As an extension to that question: my machine has a Z80. The manual obviously says nothing about the Z80 registers because they hadn't been invented when CP/M 2.2 was around. There's enough Z80 CP/M software that there must be a set of de-facto rules about when you can expect the extra Z80 registers to be corrupted or not. Does anyone know what these are?

[Chuck(G)]

I think a good rule is if you're going to use IX or IY in your BIOS, you should save them before use, as CP/M BDOS certainly won't save them. Otherwise, you're depending on the application program to save them before a call--that may not be safe.

The alternate register set, I wouldn't bother with--so few programs use them, that I'd leave that problem to the application.

As far as the other registers go; they're all fair game. However, don't think you have a great big stack to play with--if your code uses much stack space, use a private one.

[durgadas311]

The general CP/M expectation is that the caller is responsible for saving any registers they need to preserve. Calls to BDOS or BIOS cannot assume any registers are preserved. But the bottom line will be what is done by the applications you want to support, since you only have control over the BIOS. For example, if you want to run an application that uses the alternate register set (and does not protect it), then your BIOS will need to leave the alternate registers alone - or save them.

Of course, interrupt routines must save any registers they use. And cannot assume that the alternate registers are free.

[dreNorteR]

CP/M doesn't use any of the Z80 specific registers, so some programs will expect them all to be preserved. I wouldn't bother using IX and IY at all, the instructions are slow, and in a BIOS there shouldn't be much need to access structures.

The alternate register bank is much more useful. I have written a very fast 6-pixel text output routine for the NC100 (part of an OS intended to replace the standard ROM). No push/pop inside the inner loop at all, and when printing a string the state can stay in registers all the time.

[hjalfi]

I need to shout a little. Please excuse me:

<loud> What <omitted/> architecture requires you to manually turn off interrupts at the beginning of the ISR??? </loud>

Thank you. Have a nice day.

...of course, it's obvious what's happening in hindsight; the Z80 handles interrupts by asserting a byte onto the data bus during instruction fetch, and RST doesn't turn off interrupts, so... but wow. I grew up on the 6502. It's definitely a foreign country over here!

So that made things much more stable, to nobody's surprise whatsoever. BDS C runs, amazingly quickly. Mix C runs, amazingly slowly. HiTech C is... unhappy.

This led me to my next discovery: my BDOS and CCP come from Clark Calkins' Z80-mnemonic CP/M 2.2 disassembly. It turns out this is wrong. It puts the six version string bytes which should be at the beginning of the BDOS at the end of the CCP instead. I hadn't previously noticed because my startup code was also wrong, and was using FBASE as the BDOS entry point rather than FBASE+6.

So I don't know what else might be wrong. Certainly, replacing the BDOS with Novados makes HiTech C run fine, if slowly. But I can't use Novados for real because (like P2DOS and SuprBDOS) it claims to be restricted to non-commercial use only. However, that licensing statement was written in the 1980s. Have the licensing terms changed since then?

[durgadas311]

I need to shout a little. Please excuse me:

<loud> What <omitted/> architecture requires you to manually turn off interrupts at the beginning of the ISR??? </loud>

Thank you. Have a nice day.

The Z80 disables interrupts when it responds to an interrupt. The ISR should not need to DI again. The ISR must EI before the RET, though. Makes me wonder what was actually happening on your system.

[hjalfi]

On a second reading that's not quite as late at night, you're quite right, and I found a reference; from the Z80 CPU book, page 23:

When a non-maskable interrupt is accepted, IFF1 resets to
prevent further interrupts until reenabled by the programmer.

(Although you have to read very carefully to find that.)

However, Zilog's own application notes put a DI at the beginning of their example ISRs!

Also however, adding that DI made the difference between working and not working. This suggests that something is calling rst 0x38 when it shouldn't be. I know that the reset vectors are technically reserved for the system in CP/M... except for 0x38, which is used for DDT, but my hardware runs in IM 1 so I don't get a choice here. I wonder whether the more complex software is installing its own rst handler, using it for application logic, and then chaining on to my interrupt handler; that would result in it being called occasionally with interrupts on; an interrupt at the wrong place would cause all kinds of weird behaviour.

I could simply do without user-mode interrupts at all; I can still handle interrupts from my supervisor code (when the user code in 0000..3fff is banked out). As this is invoked in every BIOS call, things like the keyboard should still work fine. That would free up the reset vector, but it would also rule out stuff like an interrupt-driven serial port.

[durgadas311]

Your quote from the Zilog manual is for NMI, but there is similar verbiage for maskable interrupts as well. A DI is needed if you use your ISR for a "software interrupt" as well.

You could be encountering a spurious RST 7 for many reasons. Depending on if the databus has pull-ups, it could be non-existent memory access (not sure if that is possible on your banked memory system). Could also be general program crash/executing uninitialized memory. Old DRAM used to tend to power-up with alternating segments of 00 and FF (with some variations due to randomness), and so you would often hit RST 7 if your program got derailed.