NZCOM incompatibility about ishkurcpm HOT 14 OPEN

I am not sure how NZCOM works under the hood. There definitely are subtle differences between "stock" CP/M and what we have running here. For one, the BDOS has been modified to allow for system calls to be hooked into. Something like MOVCPM won't work because all of the addresses are slightly different. High memory also works differently, as some NABU-specific apps need interrupt vectors set up in specific ways.

By the way, do you mind if I try to get the work you made with ZCPR1 merged into the main branch?

from ishkurcpm.

I thought something looked strange with the BDOS. Is it the 'NFS' filesystem that needs hooks? Non-standard entry points will break a significant number of things.

You can go ahead and merge ZCPR1 if you like. I was just hacking at it, and it's plainly better to find-and-replace the various symbols I had to doubly define.

from ishkurcpm.

The NFS driver makes use of the hooks to intercept BDOS calls. There isn't really a good way to translate BIOS calls into accesses to individual files, so the NFS driver detects FCB BDOS calls to drive numbers it "owns" and interprets them itself. I am also playing with the idea of writing a TCP network driver. This would also need to use the hook in order to insert additional BDOS calls.

I will need to modify ZCPR1 to make it work with submit files on NFS. Similar to the default CCP, ZCPR1 relies on quirks of the CP/M file system that can't really be accurately emulated with my current approach.

from ishkurcpm.

It would be good to have a non-NFS version of Ishkur CP/M with conventional BDOS. That's the only way we'll be able to get Z-System working.

from ishkurcpm.

It should be as simple as dropping a copy of the stock DR BDOS into the System directory and then changing the #include "bdos.asm" line in the config. You wouldn't be able to use hook, but only NFS uses those at the moment. It also may be possible to simply update the BDOS call hooking strategy to not modify the BDOS as heavily.

I would be more interested to learn what exactly NZCOM it trying to access directly from BDOS memory. I would love to be able to use Z-System stuff under NFS, but if the system is directly accessing the BDOS is the wrong ways it probably isn't possible.

I'll take a look into using the stock DR BDOS tomorrow and see if that improves things.

from ishkurcpm.

The NFS extension is a cool bit of coding, but it definitely introduces some oddness in places. One other thing I noticed is that 'stat' always shows a record count of 0.

from ishkurcpm.

I'm starting to pick the Ishkur code in a bit more detail. One thing I'm puzzled about: Why does the page zero BDOS vector point to an address four bytes earlier than the fbase symbol?

from ishkurcpm.

That is due to odd behavior with MBASIC. If the 0x0005 vector is set to exactly at the fbase symbol, then MBASIC will set the stack pointer too high and clobber the serial string.

from ishkurcpm.

Something is not right then. I've never had to do that when building CP/M systems. I'm quite sure MBASIC works on all of same.

At least part of the problem with NZCOM is that most everything assumes a BDOS that's E00h long. BDOS needs to start at E400 and BIOS at F200. Yet, when I finagle that it gets into a boot loop. Is there something in the loader that's hardwired for the non-standard locations?

And, to my knowledge, nothing outside of SYSGEN even cares about the serial string.

from ishkurcpm.

This is the minimal set of changes that use a more expected BDOS entry, shorten BDOS to E00h and adjust BIOS to setup the BDOS+6 entry. It just cycles on a failed boot and I'm unclear as to why.

diff --git a/System/bdos.asm b/System/bdos.asm
index 242281b..992e275 100644
--- a/System/bdos.asm
+++ b/System/bdos.asm
@@ -27,7 +27,7 @@ pattrn2:defb	0,22,0,0,0,0	;(* serial number bytes *).
 ;**************************************************************
 ;
 fbase:	jp	fbase1
-	jp	boot
+;	jp	boot
 ;
 ;   bdos error table.
 ;
@@ -54,7 +54,7 @@ fbase1:	ex	de,hl		;save the (de) parameters.
 	ld	(auto),a
 	ld	hl,goback	;set return address.
 	push	hl
-	call	syshook		; see if anyone wants to intercept the call
+;	call	syshook		; see if anyone wants to intercept the call
 	ld	a,c		;get function number.
 	cp	nfuncts		;valid function number?
 	ret	nc
@@ -91,7 +91,7 @@ error1:	ld	hl,badsec	;bad sector message.
 	ret			;no, return to retry i/o function.
 ;
 error2:	ld	hl,badsel	;bad drive selected.
-	jp	error5
+	jr	error5
 ;
 error3:	ld	hl,diskro	;disk is read only.
 	jp	error5

diff --git a/System/bios.asm b/System/bios.asm
index 85f82c5..7e45211 100644
--- a/System/bios.asm
+++ b/System/bios.asm
@@ -130,7 +130,7 @@ wboot0:	push	bc
 cpmlow:	jp	wbootin	; Call jump table version instead
 	defb	0x81	; Default IOBYTE
 	defb	0	; Default drive
-	jp	fbase-4	; 4 bytes before BDOS entry 
+	jp	fbase	; 4 bytes before BDOS entry 
 
 
 ; Console status

from ishkurcpm.

The reason you are probably failing to boot is because the bootstrap programs expect there to be a boot vector at BDOS_BASE + 9. I originally put this in with the idea that I may want to expand the BDOS size in the future, but I never used it.

This project was my first time really getting in depth with the CP/M internals. There are a number of decisions that I made earlier in the project that are questionable. I am working on tagging a stable release for all the adapter people to use, but I am going to go through and refactor everything to be a little more "sane".

from ishkurcpm.

Thanks - I'll see if I can short-circuit that call. In the long-term, please do consider making the BDOS look conventional enough for Z-System. "Back in the day", BDOS extensions were dynamically loaded into buffers above the BIOS and hooked in as appropriate. Logically you had a large BDOS with, e.g. time and datestamping capability that "looked" normal to most tools that assume CCP = 2k and BDOS = 3.5k length. There's often an assumption that the BDOS jump in page zero represents exactly BDOS+6, although that's fairly dangerous since many programs hook it.

from ishkurcpm.

Another thought: Why not put some of the device driver logic into the upper part of an 8k ROM?

from ishkurcpm.

I hard-coded a jump to F200h in the loader and everything works as it should. And, as predicted, the Z-System utilities appear to run correctly. I'll keep you apprised of my progress.

UPDATE: All set! Z-System loads and runs. The terminal claims to be VT52 compatible, but it's actually closer to Kaypro II and that definition almost works. The main problem is that the cursor is not displayed in many of the utilities. I'll pick through the console driver and see if I can figure out what's going wrong.

from ishkurcpm.