Installing CP/M 3 (Plus?) on a home-built Z80 computer

[daver2]

Did you think it was going to work just like that! He he...

Yes, you need 8+3 characters for the filename to be correct. Don't forget you need to assemble, link and generate for the change to take effect. Many is the time I have made a change and missed a step out of the build process - only to get the same error again. Under these circumstances, I doubt myself and double-check the build process before trying to chase down a bug that should no longer exist.

So, we are now getting into the COLD BOOT entry of the 'real' BIOS. Yes?

If we know it gets into the BIOS entry point, does it get to the exit point? Can you print out a message before it exits. Also, can you do a hex dump of the first page of memory (from 0x0000) just before the exit?

Dave

 

[durgadas311]

On thing I notice, examining the boot path, is that you are saving and restoring the stack pointer in both "boot" and "wboot". This should not be done - at least the restore of the SP before jumping to CCP. If you are restoring the loader SP at that point, you are trying to start the CCP with bogus stack set somewhere in the middle of CCP code. However, the first thing CCP does is set it's own stack so it probably doesn't matter - unless you catch an interrupt (in which case you corrupt the CCP).

So, as done for the loader, try to pinpoint just where things are hanging. Confirm that it actually makes it to the "JP ccp" instruction. Also, make sure Page 0 got initialized correctly, in both banks. Also, make certain you selected Bank 1 for loading the CCP and jumping to it.

EDIT: It looks like you are still in bank 0 when you load the CCP, as well as jump to it. That's not going to work.

 

[nockieboy]

Did you think it was going to work just like that! He he...

I know, it was an amateur mistake to make expecting it all to work fine after the last bug...

Yes, you need 8+3 characters for the filename to be correct. Don't forget you need to assemble, link and generate for the change to take effect. Many is the time I have made a change and missed a step out of the build process - only to get the same error again. Under these circumstances, I doubt myself and double-check the build process before trying to chase down a bug that should no longer exist.

So, we are now getting into the COLD BOOT entry of the 'real' BIOS. Yes?

Yes, that probably explains the change in output I'm getting now. Yes indeed, we're getting to cold boot as the BIOS is printing the "BIOS3: Preparing MMU..." etc strings to the console.

If we know it gets into the BIOS entry point, does it get to the exit point? Can you print out a message before it exits. Also, can you do a hex dump of the first page of memory (from 0x0000) just before the exit?

Okay, here's the latest console dump from CPMLDR with an updated BIOS3 that has the requested debug information:

CP/M V3.0 Loader
Copyright (C) 1982, Digital Research

 BNKBIOS3 SPR  F300  0D00
 BNKBIOS3 SPR  B300  0D00
 RESBDOS3 SPR  ED00  0600
 BNKBDOS3 SPR  8500  2E00

 59K TPA
BIOS3: Preparing MMU...
BIOS3: Initialising SIO...
Z80 MINICOM II CP/M Plus BIOS 1.0.0 by J.Nock 2017

CP/M Plus Copyright 1982 (c) by Digital Research
BIOS3: About to set IDE to 8-bit...
BIOS3: IDE set to 8-bit mode...
BIOS3: IDE no write-cache set...
BIOS3: Input channel buffers set...

BIOS3: Interrupts enabled, cold boot finished, loading CCP...
C303F30100C306EDF233AAA6A8800B
39CC62B3E2CBE0F8E0FA3C8A4E0C2A
E83AB2A2A8EA48BC8283A2C26BC88C
0922A2CB8F00823330BE8F08978AEE
CEFDDE2A0BE9F3B8B8ABE3A03AEFB8
768FB30AF8040EDB2A9A0001020303
ACFA00202020202020202020202000
000037002020202020202020202020
0000000000E8B2E30D0A20424E4B42
494F53332053505220204633303020
20304430300D0A20424E4B42494F53
332053505220204233303020203044
30300D0A2052455342444F53332053
50522020454430302020303630300D
0A20424E4B42444F53332053505220
20383530302020324530300D0A200A
0D2035394B205450410A0D24242424
2431C102CD000B0E0DCDCD020E0911
2502CDCD020E0F11AB01CDCD02FEFF
11CF01CAA201118000CD8F01CD9501
21800011C1020E067E1213230DC234
01CD95010E09118000CDCD023AC202
673AC102CD73013AC402B7CA5F0167
3AC302CD7301215D007EFE24C26F01
237EFE42CCA90131C502C9B7571E00
7C1767EB0180FF09EBD5E5CD8F01CD
9501E1D125C27A01C90E1ACDCD02C9
0E1411AB01CDCD02B711FA01C80E09
CDCD02F376FFC90043504D33202020
205359530100008026002700280057
0058000000000000001E0000000D0A
43504D4C4452206572726F723A2020
6661696C656420746F206F70656E20
43504D332E5359530D0A240D0A4350
4D4C4452206572726F723A20206661
696C656420746F2072656164204350
4D332E5359530D0A240D0A0A0A0A0A
0A0A0A0A0A0A0A0A0A0A0A0A0A0A0A
0A0A0A0A43502F4D2056332E30204C
6F616465720D0A436F707972696768
742028432920313938322C20446967
6974616C2052657365617263680D0A
243032313138320000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
004D0F02209D018801000100855F01
0013C03B00F3000000000000EB221F
0AEB79FE0EDAE50232220AAF32F709
3A1E0A32FE097B32FA092100002249
0422210A3922800331D203218E09E5
79FE32D20A034B211C03C30F03DE64
DADB075F160019195E23562A1F0AEB
E928042804FB032804280428042804
280428041F04280428042804400957
095D0928042804280428047B092804
280428042804810987092804280428
042804280428042804280428042804
280428042804280428042804280428
0428042804280428042804B702C7C7
C7C7C7C7C7C7C7C7C7C7C7C7C7C7C7
C7C7C7C7C7C7C7C7C7C7C7C7C7C7C7
C7C7C7C7C7C7C7C7C7C7C7C7C7C7C7
C7C7C7C7C754204F11770500000000
54204F117705160000004F10390659
068E093A2E04B7C2DE03C5CD0C0BC1
79211A0AFE7FC834FE20D0357EB7C8
79FE08C2F50335C9FE0AC03600C979
FE09C2D2030E20CDD2033A1A0AE607
C20104C9211B0A0ABEC803C54FCDFB
03C1C30F04EB4D44C30F04324904C9
3E01C32504000D0A42444F53204552
523A202453656C656374245065726D
2E240000012F04CD0F04013C04C360
04012F04CD0F04014304CD0F04F376
7B955F7A9C57D005C97B855F7A8C57
D004C90C0DC8298FC378041ABEC023
130DC8C37F040C0DC81A771323C38A
044ACD1B0B7CB5C85E235623232322
D009232322D209232323232323EB22
F80921D8090E0DCD89042AD809EB21
E5090E11CD89042AEA097C21FD0936
FFB7CAD504360037C9CD180BAF2AD0
097723772AD2097723772377C92103
0A5E23562346C9CDEA04CD270BB7C8
4FFE03DA57040E01C357042A230A0E
02CD66060600EB21030A7323722370
C92AD0094E2346C52AD2095E235623
462A030A3A050A4F7D937C9A7998E5
D247052AE509CD6504E1E32BE3C330
052AE509CD6E04E17D937C9A7998DA
5E05E323E3E5C34705E3E52AE509CD
6504E1D5C5E5EB2AF20919444D220E
0ACD1E0BD12AD009732372C1D12AD2
097323722370C179936F789A67CDAB
05444D2AF809EBCD300B4D4422100A
CD210B2ACA094D44C3240B3AF4094F
C3660621E7094E3A010AB71F0DC2B9
05473E08964F3A000A0DCAD005B717
C3C70580C92A1F0A11100019C9CDD2
05093AFD09B7CAE8056E60C9097E23
666FC9CDB20532FB094F0600CDDA05
22030A7DB4C93AE7094F2A030AAFCD
770422030A32050A22060A3AE8094F
3A010AA14732F60921030AB677C92A
1F0A110C0019C92A1F0A110F0019C9
CD2E06EB21110019C9CD36067E3201
0AEB7E32FF09CD26063AE909A63200
0AC9CD36060E013A010A8177EB3AFF
0977C90C0DC87CB71F677D1F6FC367
060C0DC829C374063A1E0AC54F2101
00CD7306C179B56F78B467C93A1E0A
4FCD66067DE601C92ACC093A090A85
6FD024C9CD26067EE61F77C97B956F
7A9C67C9D5110A00195E2356EBD1C9
CD06053AF509B7CACF063E03CD280A
C3DB06CDE10622CC09CD1A05CDF304
2A1C0AC3E7062ADE09CDB20622CA09
C921230A7E23BEC03CC921FFFF2223
0AC92AEC09EB2A230A2322230ACDAB
06DAF4063A230AE60306058705C213
0732090AB7C0C5CDBD06C1C9C5F53A
E9092F4779A04FF1A091E61FC1C9CD
36060E10410CC5C10DAF2B05BEC249
070DC23F077932FB093AFD09B778C2
56071FC5E56F26003AE709573E0792
4FCD6606453AE909B8E1DA3C07CD26
064E2FE61FA1B0C1C92A1F0A22250A
7932270ACDF406CDD7040E00CDFB06
CDEB06CADB072A250AEBCD98063A27
0A4F06007EFEE5CA8A0779B7CAD407
78FE0DCACD07FE0CCAC2071A96E67F
C28A07C3CD071AC54ECD2307C1B7C2
8A071323040DC3A807AF3249044704
C93EFF4704C325040E0FCD7A07C8CD
26067EF5CD9806EB2A1F0A0E20CD89
04CD34074FF1770600EB210300191A
91CA180878D212083E8046777832FC
09C932FC097EB7C03AFB09B7C83A22
0AFE0FC83680C9E53AFC09B7CA3D08
1103001977AF32FC09E1C9CD26067E
4F0CCD2307CA61083E1FA1770E0FCD
7A07CDE807CD3F06AF32010AC32504
34CD34074FBED26E0835C32904CD2C
08CDFF07C35708CD3F063A010A21FF
09BEDA9308FE80C22904CD3F083A49
04B7C22904CDEE05CA2904CD00063A
F509B7C2120ACDDB06CD1A05CDF304
C356063A1E0A3CCA4B043D21020ABE
C877572AC809CD8D065FD5CD9304E1
D24B042DC82AC8094D44CD7A0622C8
09C93AFA09321E0AC9AF32080AC312
093E80473D4F2A1F0A110700EB197E
A07EA177237EA032080A7EA177CDA3
06CD2E067EA0CA12097EA17032FC09
210000220A0A3EFF32210A2A1F0A7E
E61F3D32FA09FEFFCA36097E320A0A
CDDB08CDAF083E002A1F0A77C92100
0022C809AF321E0A3D32020A218000
221C0AC3DB06CDDB08C3AF08CDE208
CDE207CD6709C9CDEB06C8CD36067E
3CC277091B1B1A77E10E40C9CDE908
C377083A1E0AC32504EB221C0AC3DB
063A220AFE0FDABE093AFE09321E0A
3A210AB7CABE092A1F0A36003A0A0A
B7CAB00977233A080AB677CD2E063A
FC09B6772A8003F92A49047D44C901
000085F1190000670B690B00000000
330C0000B011D319E219FFFF008000
051F01FB07FF01F000000001000000
1D000000FF0400000080011D001D0B
00000B00000000000017001D003E01
CD2E0AC356060024008500AB01FF00
2800AB010F2ADE09C3310A2AE009F5
CD940A3A030A5FA0320B0A7BA13203
0A220C0ACDB20622CA09CD9B0AF1F5
FE04D25C0ACD7F04CA6C0AAFCDA40A
3E02CDAC0ACD9B0ACD890436003A0B
0A3C1180002180FF193DC2760AEB2A
CA0919F1FE03C28A0A22CC09C9EB2A
1C0A018000C34B0B3AF509472F4FC9
2A0C0A11020A0E04C91104002A0C0A
19C9F5CD1A05F13DF4F304CDA40A23
23110E0A0E04C38904000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
0000000000000000000000C39B0CCD
880CCD880CCD880CC3490FCD880CCD
880CCD880CC3900FC3700FC39C0FC3
A10FC3A60FC3AE0FCD880CCD880CC3
AB0FCD880CCD880CCD880CCD880CCD
880CCD880CCD880CCD880CC3830CCD
880CCD880CCD880CCD880CCD880CCD
880CCD880C000000001600000B0000
0000330C0000B011D319E219FFFF00
00000000000000000000000000440C
0000B112D319E219FFFF0000000000
000000000000000000440C0000B213
D319E219FFFF000000000000000000
0000000000440C0000B314D319E219
FFFF00000000000000000000000000
00440C0000B415D319E219FFFF0000
000000000000000000000000440C00
00B516D319E219FFFF000000000000
0000000000000000440C0000B617D3
19E219FFFF00000000000000000000
00000000550C0000B718D319E219FF
FF00008000051F01FB07FF01F00000
00010000008000051F01FF07FF01F0
000000000000008000051F01FF04FF
01F0000000000000000000002F1C70
1C00180484011803E105EA001804C4
0118025003E105EAEBEDB0EBC90E2A
CD490FE12B2B2B7CCDDC0E7DCDDC0E
F376F3ED73F11B31F11BCD9C110C50
7265706172696E67204D4D552E2E2E
0D0A003E00D3383E11D3383E22D338
3E33D338CD9C110C53657474696E67
204D4D55206C6F636B20627974652E
2E2E0D0A00AF3255003E013256003E
023257003E03325800CD9C110C496E
697469616C6973696E672053494F2E
2E2E0D0A002A010011DD00197EFE38
CA280D3E84C32A0D3EC432700C216D
0C0E02060AEDB321770C0E03060CED
B33E00ED4721040E225000CD9C110C
5A3830204D494E49434F4D20494920
43502F4D20506C7573204C44524249
4F5320312E300D0A0D0A43502F4D20
506C757320436F7079726967687420
313938322028632920627920446967
6974616C2052657365617263680D0A
00CD91113E01D3113EEFD317CD9111
3E82D3113EEFD317AF32331C32741C
21F31B222F1C22311C21341C22701C
22721CED7BF11BED5EFBCD9C110C4C
445242494F532072657475726E696E
6720746F3A2000E17CCDDC0E7DCDDC
0EE5C9F5E597D302DB020F302B2A2F
1C233A690CBD200321F31B222F1CDB
00773A331C3C32331CFE3238083E05
D3023EE8D302E1F1FBED4D2A701C23
3A6B0CBDC2470E21341C22701CDB01
773A741C3C32741CFE32DA610E3E05
D3033EE8D3037EFE23CC6C0EE1F1FB
ED4DF3CD220FFE23CA8B0EFE25CA83
0E3A741CFE05D26D0EC9CD220FFE45
CC8C0EC9CD220FFE23CADB0E32751C
CD220FFE23CADB0E32761CCD030F32
680CCD220FFE23CADB0E32751CCD22
0FFE23CADB0E32761CCD030F32670C
2A670CE5CD220FE1FE23CADB0E7723
3A741CFE00C2C70EC932791CE6F00F
0F0F0FCDEB0E3A791CE60FFE0ADAF9
0ED609F640C3FB0EF6304FCD490F3A


CP/M Error On k: Invalid Drive
BDOS Function = 15  File = CCP     .COM▒!▒▒▒,▒!▒▒"▒▒▒h▒\▒!
CP/M Error On ,: Invalid Drive
BDOS Function = 15  File = CCP     .COM▒!▒▒▒,▒!▒▒"▒▒▒h▒\▒!▒

Latest BIOS3.ASM here so you can see how the debug information fits into the boot process: View attachment BIOS3.ASM.txt

 

[nockieboy]

I missed your post whilst writing mine, durgadas311 - so it looks like it's a memory bank issue then? So I need to add in a switch to Bank 1 before loading the CCP (as well as tidying up the stack issue)? What would be the best way to do that?

 

[durgadas311]

I would suggest adding this to the start of ld_ccp:

 LD A,1
 CALL SELMEM

 

[nockieboy]

Thanks durgadas311. Have added that in and some debug prints as well (which I've detailed below) and I get the following in the console - looks like it's not completing the load of CCP:

CP/M V3.0 Loader
Copyright (C) 1982, Digital Research

 BNKBIOS3 SPR  F400  0C00
 BNKBIOS3 SPR  B300  0D00
 RESBDOS3 SPR  EE00  0600
 BNKBDOS3 SPR  8500  2E00

 59K TPA
Z80 MINICOM II CP/M Plus BIOS 1.0.0 by J.Nock 2017

CP/M Plus Copyright 1982 (c) by Digital Research
Loading CCP...
Bank 1 selected...

Here's the relevant section from BIOS3.ASM to show you where the debug prints are located:

ld_ccp:
	
	; DEBUG
	CALL	printInline
	.TEXT 	"Loading CCP..."
	.DB 	CR,LF,0
	
	; Load CCP.COM into bank 1 and jump to it.
	LD	A,1
	CALL	SELMEM						; Switch to Bank 1
	
	; DEBUG
	CALL	printInline
	.TEXT 	"Bank 1 selected..."
	.DB 	CR,LF,0
	
	XOR	A									; Zero extent
	LD	(ccp$fcb+15),A
	LD	HL,0								; Start at beginning of file
	LD	(fcb$nr),HL
	LD	C,open$func				; Open the CCP.COM file
	LD	DE,ccp$fcb
	CALL	bdose							; BDOS will return to this CALL, not bdose as it uses a JP
	INC	A
	JP	Z,no$CCP					; If A is zero, CCP wasn't loaded successfully
	LD	DE,ccp
	LD	C,26								; Set DMA address
	CALL	bdose
	LD	DE,128							; Read up to 128 records (up to 16K)
	LD	C,44								; Set multi-sector count
	CALL	bdose
	LD	DE,ccp$fcb					; Load it
	LD	C,20								; Read record(s)
	CALL	bdose
	
	IM	2
	EI								; Enable interrupts

	; DEBUG
	CALL	printInline
	.TEXT 	"CCP loaded..."
	.DB 	CR,LF,0
	
	; Pass execution to CCP
	JP		ccp

 

[daver2]

Ther's not much between the message being output (Bank 1 selected...) and the CALL bdose (which is probably what is going south).

What is the value in @mxtpa that it is going to call (display before calling of course).

Dave

 

[nockieboy]

Ther's not much between the message being output (Bank 1 selected...) and the CALL bdose (which is probably what is going south).

What is the value in @mxtpa that it is going to call (display before calling of course).

Dave

Apparently:

@mxtpa = EE06

This is from this code:

ld_ccp:
	
	; DEBUG
	CALL	printInline
	.TEXT 	"Loading CCP..."
	.DB 	CR,LF,0
	
	; Load CCP.COM into bank 1 and jump to it.
	LD	A,1
	CALL	SELMEM						; Switch to Bank 1
	
	; DEBUG
	CALL	printInline
	.TEXT 	"Bank 1 selected..."
	.DB 	CR,LF,0
	
	CALL	printInline
	.TEXT 	"@mxtpa = "
	.DB 	0
	
	LD	HL,(@mxtpa)
	LD	A,H
	CALL	PHEX
	LD	A,L
	CALL	PHEX
	
	
	XOR	A									; Zero extent
	LD	(ccp$fcb+15),A
	LD	HL,0								; Start at beginning of file
	LD	(fcb$nr),HL
	LD	C,open$func				; Open the CCP.COM file
	LD	DE,ccp$fcb
	CALL	bdose							; BDOS will return to this CALL, not bdose as it uses a JP
	INC	A
	JP	Z,no$CCP					; If A is zero, CCP wasn't loaded successfully
	LD	DE,ccp
	LD	C,26								; Set DMA address
	CALL	bdose
	LD	DE,128							; Read up to 128 records (up to 16K)
	LD	C,44								; Set multi-sector count
	CALL	bdose
	LD	DE,ccp$fcb					; Load it
	LD	C,20								; Read record(s)
	CALL	bdose
	
	IM	2
	EI								; Enable interrupts

	; DEBUG
	CALL	printInline
	.TEXT 	"CCP loaded..."
	.DB 	CR,LF,0
	
	; Pass execution to CCP
	JP	ccp

Which places the call firmly within RESBDOS3?

BNKBIOS3 SPR  F400  0C00
 BNKBIOS3 SPR  B300  0D00
 RESBDOS3 SPR  EE00  0600
 BNKBDOS3 SPR  8500  2E00

 

[durgadas311]

I don't think this is the problem, but I see that you are setting interrupt mode and enabling interrupts *after* you've been calling the BDOS. Generally, you should have the entire hardware initialized *before* you start calling BDOS. Cold boot used to do the IM 2/EI before ld_ccp, perhaps it still does. The general expectation is that the system is fully functional before the first call into BDOS.

I think we've confirmed @mxtpa is correct, at least that should have been used to initialize the JMP at 0005H - which looks correct in the dump of Page 0 from previous runs.

Might be good to find out how far into loading the CCP you get. Perhaps a short message after each BDOS call returns.

 

[nockieboy]

Might be good to find out how far into loading the CCP you get. Perhaps a short message after each BDOS call returns.

It's not getting past the first bdose call - I've added debug prints after each call (all three of them) in the routine and none are showing.

Is there any reason bdose is working like this?

bdose:
	LD		HL,(@mxtpa)
	JP		(HL)

Wouldn't it be easier to just call (@mxtpa) and stick a return in bdose?

 

[durgadas311]

There is no indirect call on the Z80, so there is no "call (@mxtpa)". Keep in mind the 8080, and by inference the Z80, are not at all symmetrical instruction sets. The Z80 mnemonics give a false impression that there is symmetry.

I'm not sure why you need to change bdose. Perhaps you can explain what you think is wrong there.

Otherwise, assuming there are no bugs in the BDOS, I expect that the OPEN call is making some calls into the BIOS. You might start putting debug messages in some of those. SELDSK is probably the first one called, but eventually it will call READ to locate CCP.COM in the directory. Try and figure out how far it gets.

 

[daver2]

+1.

The BDOS is probably trying to read the directory to find the CCP (or something else like that)...

One step at a time...

Some other processors could use any register and any addressing mode with any instruction. Not so the Z80.

Dave

 

[nockieboy]

Okay, I've added a few debug prints to seldsk (and chgdsk by extension) and read, including one for the initial bank swap that read tries to do before reading data from the CF card. Here's the output:

CP/M Plus Copyright 1982 (c) by Digital Research
Loading CCP...
Bank 1 selected...
seldsk called...
...jumped to chgdsk
read called...
read: Switching to Bank 00

It would appear that read is switching to Bank 0 before reading the data from the CF card...?? Is that right?

Here's the code that produced the above:

read:
	PUSH 	AF
	PUSH 	BC
	PUSH 	HL
	
	; DEBUG
	CALL	printInline
	.TEXT 	"read called..."
	.DB 	CR,LF,0

	CALL 	cfWait
	CALL 	setLBAaddr

	LD 	A,CF_READ_SEC
	OUT 	(CF_COMMAND),A

	CALL 	cfWait

	LD	A,(dmaBank)
	
	; DEBUG
	; DEBUG
	CALL	printInline
	.TEXT 	"read: Switching to Bank "
	.DB 	0
	LD	A,(dmaBank)
	CALL	PHEX
	
	CALL	selmem			; could avoid this if dmaBank == 0
	LD 	B,0					; 256 bytes at a time
	LD	C,CF_DATA
	LD 	HL,(dmaAddr)
	INIR							; do 256 bytes
	INIR							; do another 256 bytes = 512
	XOR	A						; back to Bank 0...
	CALL	selmem			; could avoid this if dmaBank == 0

	POP 	HL
	POP 	BC
	POP 	AF

	XOR 	A
	LD	(erflag),A
	RET

 

[daver2]

I was just looking at something 'strange' in seldsk.

If A is 0 (drive A?) then the bit of code later will point HL at the wrong place won't it? It will take an A register value of 0 as being 256...

Dave

 

[durgadas311]

The directory buffers - used only by BDOS internally - are in Bank 0 so that switch to bank 0 makes sense. The first read should be of the first directory sector into an internal buffer. I'm assuming the READ actually completes and returns to BDOS, but knowing that is critical.

Maybe some checking of the dir buffer structures is in order, or confirmation that the DMa address is correct/sane.

 

[durgadas311]

Yes, daver2, I think you are right. There should have been an INC A before the start of that loop. I think I remember planning to add that, but obviously I didn't. That code should probably be changed to use "dtbl" instead, but it should work as-is (with the INC added).

 

[nockieboy]

Yes, it appears that read completes:

CP/M Plus Copyright 1982 (c) by Digital Research
Loading CCP...
Bank 1 selected...
seldsk called...
...jumped to chgdsk
read called...
read: Switching to Bank 00
read completed, erflag = 00

 

[nockieboy]

Yes, daver2, I think you are right. There should have been an INC A before the start of that loop. I think I remember planning to add that, but obviously I didn't. That code should probably be changed to use "dtbl" instead, but it should work as-is (with the INC added).

I've added the INC A in - just trying to get the SBC to reboot and try out the new BIOS...

 

[nockieboy]

Wow - that was annoying. What a time for the serial interface to start playing up.

Here's an updated console log after I've added the INC A here (that's right, isn't it?):

seldsk:
	; DEBUG
	CALL	printInline
	.TEXT 	"seldsk called..."
	.DB 		CR,LF,0
	
	LD		HL,$0000			; error return
	LD		A,C
	CP		8						; 16 for 128MB disk, 8 for 64MB disk
	JR		C,chgdsk			; if invalid drive will give BDOS error
	XOR		A						; else reset default back to a:
	LD		(sekdsk),A
	RET

chgdsk:
	; DEBUG
	CALL	printInline
	.TEXT 	"...jumped to chgdsk"
	.DB 		CR,LF,0
	
	LD 		(sekdsk),A
	LD 		HL,dpbase
	LD 		BC,dphlen
	INC		A		<---- added
chgdk0:
	ADD		HL,BC
	DEC		A
	JR		NZ,chgdk0
	RET

Log:

CP/M V3.0 Loader
Copyright (C) 1982, Digital Research

 BNKBIOS3 SPR  F300  0D00
 BNKBIOS3 SPR  B300  0D00
 RESBDOS3 SPR  ED00  0600
 BNKBDOS3 SPR  8500  2E00

 59K TPA
Z80 MINICOM II CP/M Plus BIOS 1.0.0 by J.Nock 2017

CP/M Plus Copyright 1982 (c) by Digital Research
Loading CCP...
Bank 1 selected...
seldsk called...
...jumped to chgdsk
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
read called...
read: Switching to Bank 00
read completed, erflag = 00
First bdose call completed...
BIOS Error on A: No CCP.COM file

Seems that's fixed the 'invalid drive' error, the first bdose call is completing, but it's now throwing an error as a result of:

INC		A
JP		Z,no$CCP					; If A is zero, CCP wasn't loaded successfully

...which comes directly after the first bdose call.

 

[durgadas311]

Rats, that routine needs a better fix. Let's replace it with this:

chgdsk:
	LD 	(sekdsk),A
	ADD	A,A
	LD	C,A
	LD	B,0
	LD 	HL,dtbl
	ADD	HL,BC
	LD	E,M
	INC	HL
	LD	D,M
	EX	HL,DE
	RET

Daver2: pls review and make sure that's correct...