z80 out via 0000, bios bugs finally solved

Code:
-----
So, the code I'm using is the CPMFAST of Linards. Csoren there provides a working package with instructions (great!)
github.com/csoren/c128cpm

the 'original' code from commodore (part of the developers kit, I assume) is found (in more places, but here's one): www.z80.eu/c128.html (follow the links to the d71 images)

In the code the comments from the developer(s), and I assume it's from Von, state things like what I show above.

That commented code is there, indeed. for example in the io module (cxio.asm) one finds:
125 if use$fast
126 lxi b,VIC$speed
127 inp a
128 sta sys$speed
129 outp d ; set slow mode (1 2 MHz Z80)
130 endif
Before executing a 6502 routine, and after:
148 if use$fast
149 lxi b,VIC$speed
150 lda sys$speed ; get desired system speed
151 outp a ; set speed (2 or 4 MHz Z80)
152 endif

These comments again are from whoever (Von?) wrote this.
And indeed they suggest the "intent" of getting 4Mhz during Z80 and only 1Mhz during 6502.
The reason for 1Mhz 6502 is (at least) that this is needed for switching (something with the bus hanging or so)

Versions:
---------
I think there must be several BIOS versions out there but what they have in common is an absolute minor change in the code with the VERY notable exception of Linards' work.
In the case of the ZPM3, we get a 'Z-system' BDOS part running on a CPM3 BIOS (the CPMFAST in this case), patched for a 16M REU. Since the BIOS has the really nasty bug of init6551 clobbering d000 area, I can understand people gave up on the BIOS part (so 'c128 cpm3').
It is believed that Z80 is 'faster' but that is only true for a few cases. Mostly it allows even more terse code compared to 8080. So: more efficient, not per se faster.
That said, with elaborate code the 2Mhz Z80 in C128 can do some things at speed comparable to 1Mhz6502, a 8080 would not be able.
The 16M reu patch has as a major turn-off the 128 dir-entry limit, this can be changed but requires recompile (and I then the out 0000 bug pops up).
On the 16M REU you can (at most) set 1024 dir entries (16bitmap*2048block/ 32byte), which is still not great but better.

Since Z-system combines a neat replacement BDOS + good utils onto the 'existing' CPM+ bios (I never checked how much change the bios needs, Z docs say 'none') I guess any bios updates would be available for the Z-system.
In 'practice' the z-system does not add to cpm-capability (the most interesting use is dbase, hence my interest in larger disks with more dir-space). No application of 'that time' supported Z-system improvements (like terminal abstraction)

I think a 'definitive' version would be one where I figure out how to run the c128 compatible speed loader in csdb.dk in the '6502-BIOS', so that my trusty 1541ii works faster at track access.
My new-times-c128-extension of choice ended up the Uii+, and I'm using it's "dos" interface to get multiple drives.
From a sd2iec perspective, I would expect it is possible to add FSD2000/4000 support (reusing the 1581 code) however this will cost a lot of memory.

Therefore, another 'definite' approach is assuming an REU and updating the code for pseudo-banking via REU to reach the max HD size of CPM3: 512Mb.

How many people have a running c128, or even with expensive parts like 1541U/U2...

No, I've not published the described repairs to the existing published code-bases.

The long:
For the official commodore c128 CPM3 version, 28 may 87, source and disks are found at www.zimmers.net/anonftp/pub/cpm/sys/c128/system/index.html. Look for 28may87.d64 and source as a d81.

If you compile the 28may87 code, the code in "cxio.asm" at line 204 will get the IO word-value DE00 and put it into the "usart$adr" at location FD25.
As described above, this is too late for the init. Devices were already initialized in cxkrnl.asm at lines 149-155, before the cold-boot attempts to reach the init-code in cxio.

(note: because a 6551 (eg. swiftlink cart) would NOT be initialized correctly, this explains the need for things like 'initacia.com' which comes with the swiftlink cart.)

Regarding inclusion into a system disk:
If you wanted to solve this, the starting content of FD25,FD26 is not part of booting. Repairs need to happen runtime at the very start of the cold-boot (before the device init).
The simplest 'patch' to an existing system disk cpm+.sys file is therefore to completely remove the dynamic behavior of "where is 6551 in IO space", since the system initializes this hardcoded to DE00.
Any subsequent changes to usart$adr will not be seen anymore in the init-routine (called by device.com), but De00 seems sensible enough.

The most precise 3-byte patch is therefore to load the HL registers with hardcoded DE00 in the "?int65" (init of 6551). Replacing "LD HL,(usart$adr)" with "LD HL,$DE00". ( lhld usart$adr -> lxi h,0DE00h). Alternatively one must find 6 bytes space to load De00 and store into FD25 (this is not a simple patch anymore)

The 3 bytes change can be done as patch on the cpm+.sys file, but locating the offset is very hard.
runtime, the code for ?int65 sits at $Db9c, where we need to change 3 values.

Impact of the bug in existing code:
The values outputted from 6551init are overwriting code in D001, D002, D003.
As it happens, for may87 version, this is exactly the implementation of the "Esc D" and "Esc L" (kaypro parsing of the delete line and draw line, not implemented but parsed). There codes are 1. used on Kaypro programes, 2. not used so much anyway. So you tend to not see this.
Take C128 CPM, do 'ESC d' or 'ESC l' + enter to see the bug in action.
(break at Cfff in your fav emulator to see this. I recommend z64k)

Code at Cfff changes from
cfff: call cf64
d002: call cf64 (this accept get next value from character output routine)

into
cfff: call 3f64
d002: dec BC
d003: jr cfd4 -> this goes to do rst 08 which locks up your system.

Now, as to the patching:
The int6552 code sits in the banked block of code, at the end of code-segement.
CPM compiles all the .asm files, then links them in a given order (this determines where they will be in mem). cxext.asm is the last file with any code (last is cxscb but this is in common).
The code in cxext has all 'dseg' tagged so this means it is all in "banked".
CPM loader in z80 boot rom loads the block of 'common' code stretching down from FC00.
The cpmload screen shows "BNKBIOS3 F000 0C00" and then "BNKBIOS3 C800 1800".
The 2nd one (with the banked code) is where our data goes, right up until E000 (shared mem point).

So we know that, since cxext is the last to be linked (in may28 version), its code will end up at the very end. CPM does not load us to DF00 but reserves room for disk buffer structs there. Default this is for the 5 drives ABCDE (shared buffers) and means our bios code is found at DBxx
On disk, the block is cut up in halves (128byte records of CPM) and we're in the 2nd part.
Looks like this:
>c:db80: 57 49 4e 45 20 56 4f 4e 01 00 00 00 00 00 00 00 WINE VON........
>c:db90: 00 00 00 00 6b 0d 00 00 6b 0d 00 00 2a 25 fd 44 ....k...k...*%.D
You see "WINE VON", that makes it easy to find inside CPM+.sys.
The code "2a 25 fd" (lhld fd25) must become "21 00 de" (lxi h,de00)

Note that CPMloader handles our data in aligned 128b blocks so on disk we are expecting to see 'exactly' this alignment ('WINE VON').
Patching in cpm use done easily with superzap.com (use version 5.2)
Edit file cpm+.sys, look for ascii "WINE V" and see this is found at 001B00. Also the location of the 3 bytes is found there at (indeed) 001B1C,D,E
Edit the 3 bytes to the required "21 00 DE" and save the sector. Done.
Alternate methods involve writing code to open the, get record nr 54, update, and save.

Mind you, this will repair the CPM+.sys file such that it can show screens in which EscL or D appear (without actual drawing). That is it.
Much more relevant is that make possible attempts to compile the original source with minor edits.