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

[nockieboy]

Wait, did you actually make the change you asked about? This is not correct:

LD SP,(OSENTRYADR)

In that case, the correct code is to get the *address of* osentry$adr. So do not change that instruction.

Yes, I DID make that change, but was starting to think I need to change it back - your post has just confirmed that for me! I'll get it updated in a short while - I imagine the console output will be identical to previous posts, but I guess now I need to start looking at confirming somehow that BIOS3 is actually at FE00h? That should be location of the cold boot jump, shouldn't it?

EDIT: Perhaps instead of showing the address of osentry$adr, I should dump 256 bytes from FE00h?

 

[daver2]

The code *** SHOULD BE *** "LD SP,OSENTRYADR" and not "LD SP,(OSENTRYADR)". Just to confirm...

The next thing it does is a RETurn - so this is setting up the stack pointer to an 'imaginary' stack that has been pre-loaded with the address to transfer to (via the RET instruction).

This should (by the looks of what you are seeing) jump to F400. Why looking at FE00?

Within the COLD start of your BIOS - the stack pointer at this point in time should be considered invalid. You appear to save the current value of the stack pointer (that is OK) and then load it up again (after disabling interrupts), so that looks OK to me too.

Dave

 

[nockieboy]

The code *** SHOULD BE *** "LD SP,OSENTRYADR" and not "LD SP,(OSENTRYADR)". Just to confirm...

Yep, sorted.

The next thing it does is a RETurn - so this is setting up the stack pointer to an 'imaginary' stack that has been pre-loaded with the address to transfer to (via the RET instruction).

Just seems like an unnecessarily fancy way of doing a JP (OSENTRYADR)?

This should (by the looks of what you are seeing) jump to F400. Why looking at FE00?

Ignore that, Dave - in a previous console log I'd done it showed an address of FE00 - I still had that in my head when I wrote that post. The log posted below prints the page from F400.

Within the COLD start of your BIOS - the stack pointer at this point in time should be considered invalid. You appear to save the current value of the stack pointer (that is OK) and then load it up again (after disabling interrupts), so that looks OK to me too.

Dave

Yes, a local stack is set up for BIOS3 immediately after disabling interrupts - so, in theory at least, if CPMLDR is jumping to the right address (F400), the cold boot should be being executed... Which is telling, because it doesn't seem to be.

Here's the latest console log from CPMLDR - this time I've made it dump a page of RAM from F400. Looks to me an awful lot like it's jumping to F400, then getting stuck in a loop jumping back to F400 continuously....

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

CPMLDR: OSENTRYADR = F400
CPMLDR: Page Dump from F400h
C300F40000F40000F4002CF9C310F9
C36BF4C36BF4C36AF4C38FF9C374F9
C392F9C397F9C39CF9C3EBF9C318FA
C367F4C3A7F9C325F9C36AF4C367F4
C363F4C366F4C3E9F5C3EDF5C3EEF5
C3C5F5C3EFF5C3CAF5C3A3F9C3C9F5
C30000C30000C30000210000C9AF3D
C9AFC9000000000000000000000000
34F5000051B311B313B3FFFF000000
0000000000000000000045F5000052
B411B313B3FFFF0000000000000000
000000000045F5000053B511B313B3
FFFF00000000000000000000000000
45F5000054B611B313B3FFFF000000
0000000000000000000045F5000055
B711B313B3FFFF0000000000000000
000000000045F5000056B811B313B3
FFFF00000000000000000000000000
45F5000057B911B313B3FFFF000000
0000000000000000000056F5000058
BA11B313B3FFFF0080000000000000
000000000000010002038000051F01
FF07FF01F000000000000203800005
1F01FF04FF01F00000000000020300
000040CBF700180484011803E105EA
001804C40118020003E105EA000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000EBEDB0EBC9C5E53210B38787
4F060021E1F5090E380604EDB3E1C1
C90011223304152633216CF4C9C9C9
C9F3ED73C3F531C3F5CD50FA0C4249
4F53333A20507265706172696E6720
4D4D552E2E2E0D0A003E00D3383E11
D3383E22D3383E33D338CDABF7216B
F57CED477D327EF5CD50FA0C42494F
53333A20496E697469616C6973696E
672053494F2E2E2E0D0A003A6AF5FE
38CA61F63E84C363F63EC43270F521
6DF50E02060AEDB32177F50E03060C
EDB3CD50FA0C5A3830204D494E4943
4F4D2049492043502F4D20506C7573
2042494F5320312E302E3020627920
4A2E4E6F636B20323031370D0A0D0A
43502F4D20506C757320436F707972
696768742031393832202863292062
79204469676974616C205265736561
7263680D0A00CD45FA3E01D3113EEF
D317CD45FA3E82D3113EEFD317AF32
A4FA32E7FA2164FA22A0FA22A2FA21
A7FA22E3FA22E5FAED5EFBC324F7ED
73C3F531C3F5CDABF7AF32FEFE2100
00220EFF0E0F11EFFECD7EF73CCA82
F71100010E1ACD7EF71180000E2CCD
7EF711EFFE0E14CD7EF7ED7BC3F5C3
000121000101800C3A10B3F53E01CD
CAF57EF53E00CDCAF5F177230B78B1
20ECF1CDCAF5C300012AFEF3E9CD50
FA0C42494F53204572726F72206F6E
20413A204E6F204343502E434F4D20
66696C650D0A00F3763E04D338CDB6
F73E00D3383EC33200002103F42201
003205002AFEF3220600C9F5E597D3
02DB020F302B2AA0FA233AA5FABD20
032164FA22A0FADB00773AA4FA3C32
A4FAFE3238083E05D3023EE8D302E1
F1FBED4D2AE3FA233AE8FABDC20EF8
21A7FA22E3FADB01773AE7FA3C32E7
FAFE32DA28F83E05D3033EE8D3037E
FE23CC33F8E1F1FBED4DF3CDE9F8FE
23CA52F8FE25CA4AF83AE7FAFE05D2
34F8C9CDE9F8FE45CC53F8C9CDE9F8
FE23CAA2F832EAFACDE9F8FE23CAA2
F832EBFACDCAF83269F5CDE9F8FE23
CAA2F832EAFACDE9F8FE23CAA2F832
EBFACDCAF83268F52A68F5E5CDE9F8
E1FE23CAA2F877233AE7FAFE00C28E
F8C932EEFAE6F00F0F0F0FCDB2F83A
EEFAE60FFE0ADAC0F8D609F640C3C2
F8F6304FCD10F93AEEFAC93AEAFACD
E1F8E60F07070707573AEBFACDE1F8
E60FB2C9D630FE0AD8D607C92AE5FA
233AE8FABDC2F7F821A7FA22E5FA3A
E7FA3D32E7FAFE05D20EF93E05D303
3EEAD3037EC9F5CD64F928FB79D300
F1C9CD6CF928FB79D301F1C9CD64F9
C8AF3DC9CD59F928FB2AA2FA233AA5
FABD20032164FAF322A2FA3AA4FA3D
32A4FAFE0530083E05D3023EEAD302
7EFBE1C9E53AA4FAB72802AF3DE1C9
97D302DB02E604C997D303DB03E604
C921000079FE083805AF3204B3C932
04B3216CF4011900093D20FCC90100
00ED4305B3C9ED4307B3C9ED430DB3
3A10B3320FB3C96069C92A05B32929
2929293A07B3B53200B33A04B3CB0F
CB0F6FE6033202B37DE6C0B43201B3
3EE03203B33A00B3D3133A01B3D314
3A02B3D3153A03B3D3163E01D312C9
F5C5E5CD45FACDAAF93E20D317CD45
FA3A0FB3CDCAF506000E102A0DB3ED
B2EDB2AFCDCAF5E1C1F1AF3209B3C9
F5C5E5CD45FACDAAF93E30D317CD45
FA3A0FB3CDCAF506000E102A0DB3ED
B3EDB3AFCDCAF5E1C1F1AF3209B3C9
F5DB17E680FE8028F8F1C9E3F5C57E
FE0028074FCD10F92318F423C1F1E3
C90000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000A0FA00000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
00000000000000000000000000E3FA
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000004343502020
2020434F4D00000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000C303E6
0100C306D8F233EAECAC000938CC62
B3E2CBA0A8E0FA3CAA4E0C2BE83EB2
22ACEA08BC8A8B82C26BC8882D22A2
8B0F00823330BE8F0C978AEECE7D9E
2A0BE9E3B8B8A9EEA03AEFB836CF33
0AEA040FC32A9B0001020303AC3A00
202020202020202020202000000039
002020202020202020202020000000
000028B2E30D0A20424E4B42494F53
332053505220204634303020203043
30300D0A20424E4B42494F53332053
50522020423330302020304430300D
0A2052455342444F53332053505220
20454530302020303630300D0A2042
4E4B42444F53332053505220203835
30302020324530300D0A200A0D2035
394B205450410A0D24242424243143
03CD000C0E0DCD4F030E0911A702CD
4F030E0F11F401CD4F03FEFF111802
CAEB01118000CDD801CDDE01218000
1143030E067E1213230DC23401CDDE
010E09118000CD4F033A4403673A43
03CDBC013A4603B7CA5F01673A4503
CDBC01215D007EFE24C26F01237EFE
42CCF2010E09116E02CD4F032A4703
7CCD440B7DCD440B1186020E09CD4F
033E0F4721FFF3237EC5E5CD440BE1
C110F511A4020E09C5E5CD4F03E1C1
3E0F477DFEFFC2900111A4020E09CD
4F03314703C9B7571E007C1767EB01
80FF09EBD5E5CDD801CDDE01E1D125
C2C301C90E1ACD4F03C90E1411F401
CD4F03B7114302C80E09CD4F03F376
FFC90043504D332020202053595301
000080260027002800570058000000
000000001C0000000D0A43504D4C44
52206572726F723A20206661696C65
6420746F206F70656E2043504D332E
5359530D0A240D0A43504D4C445220
6572726F723A20206661696C656420
746F20726561642043504D332E5359
530D0A240D0A43504D4C44523A204F
53454E545259414452203D20240D0A
43504D4C44523A2050616765204475
6D702066726F6D2046343030680D0A
240D0A0A0A0A0A0A0A0A0A0A0A0A0A
0A0A0A0A0A0A0A0A0A0A0A43502F4D
2056332E30204C6F616465720D0A43
6F7079726967687420284329203139
38322C204469676974616C20526573
65617263680D0A2430323131383200

 

[durgadas311]

Yes, dumping 256 bytes at the address contained in osentry$adr would be the next step (should be 0F400H according to current data).

The file CPM3.SYS contains the CP/M image in reverse order, and the loader will read records from the file in order but place them in memory from the top downwards. So if you go examining CPM3.SYS you'll want to keep that in mind. The first record should be the load data, the second should be the load map message, and the third onwards will be the system image, resident (high, CSEG) section first. So, the record containing the BIOS entry jump table will be many records into the file.

One thought I had was that something corrupted the load data and so things did not load correctly. If the length of the resident section was too small, it might account for what we see (too large and we would see the "read failed" message from a premature EOF). So another thing to try might be to dump the 4 bytes before osentry$adr as well, just before jumping to the BIOS3 cold boot entry. We can then compare those to the expected values (from the load map message or by dumping the first record of CPM3.SYS).

FYI, but not to distract from the debug, your LDRBIOS contains hex dump routines and you could call those out as "public" in LDRBIOS.ASM and then as "extrn" in CPMLDR.ASM and call them directly. But again, probably not worth the risk to make that change now.

 

[durgadas311]

Just crossed-paths with your next post...

Your BIOS3 looks bad. The cold start entry is a jump to itself - that is bad. Then there is some corruption for a few jump entries. Maybe post the latest listing file for BIOS3.ASM as we can look at what is getting assembled. Probably include the REL file, too.

 

[daver2]

+1...

"Jump to self" = not going anywhere fast!

Can you post your latest BIOS assembly code so we are all working from the same page (no pun intended).

We need to work out if your BIOS assembled/linked wrongly, failed to load correctly, or got corrupt somewhere down the line.

EDIT: It may also be worth posting the CPM3.SYS file for us to look at".

EDIT2: What durgadas311 said...

Dave

 

[nockieboy]

Okay, here's some files:
View attachment CPM_output.zip - this is a zip of all the relevant .LST and .REL files
View attachment CPM_ASM.zip - this is a zip of the relevant .ASM files.

I've included SCB as well as I'm not convinced the problem isn't there (though I know little about how it all fits together.)

CPM3.SYS will take a while longer - I'm going to have to work out a way to get that off the SBC. I've not got any way I can send it back up the line or print its contents to the console (have I?)

 

[durgadas311]

Looking at the hex dump of F400, along side the BIOS3.lst file, I see that 9 of the first 10 bytes have been "corrupted":

C3[COLOR="#FF0000"]00F40000F40000F400[/COLOR]2CF9C310F9

I'm not sure where the pattern comes from, but it seems to be 3 instances of:

 DW 0F400H
 DB 0

Any ideas where that could have come from? Since CPM3.SYS is already relocated, that was either put there by the loader (corrupted at runtime) or is corrupted in the CPM3.SYS file. The REL file contains the correct tags, so either the LINK did this, or GENCPM, or loader at runtime. Might be good to examine both BNKBIOS3.SPR and CPM3.SYS.

You could examine these using DDT on CP/M 2.2, although its a bit trickier. For BNKBIOS3.SPR, it should be fairly easy to locate the BIOS jump table, it should be at 0200H (as loaded by DDT). For CPM3.SYS, you'll have to figure out the location within the file. Based on the last load map, there are 24 records in the resident BIOS, and two records of header, so the BIOS jump table should be near 0D80H (check around that area) - if my calculations are correct.

 

[daver2]

I have also come to exactly the same conclusion.

At some point (assuming it is part of the build), the BIOS3 will go from 'correct' to 'not correct' and we need to look at what is going wrong.

if everything is correct 'on the disk' so to speak, it must be the run-time that is corrupting things.

Yep, BNKBIOS3.SPR is the next place to look.

EDIT: My CPM3.SYS looks a bit 'short'???

Dave

 

[nockieboy]

EDIT: My CPM3.SYS looks a bit 'short'???

Dave

Yes, it was - I realised after I edited it into the post that it wasn't quite right, so I removed it again. Will have to think of other ways I can view the files on the SBC. Might have to make a hex file viewer, unless anyone knows of something similar already in existence for CP/M?

 

[daver2]

Ah, that's what happened to it! I wasn't going mad when I thought I saw a post that I downloaded a file from ...

Do you have DUMP.COM on your CP/M system?

A>DUMP CPM3.SYS

Dave

 

[nockieboy]

Ah, that's what happened to it! I wasn't going mad when I thought I saw a post that I downloaded a file from ...

Do you have DUMP.COM on your CP/M system?

A>DUMP CPM3.SYS

Dave

Yes, I do! I assumed it was to dump memory, not programs... shows there's some truth in old saying about me and asses.

 

[durgadas311]

Can you look at the files on CP/M 2.2 under DDT? That should give us the information immediately.

 

[nockieboy]

Okay, here's a dump of CPM3.SYS (thanks Dave for pointing me to DUMP!)

View attachment CPM3.zip

EDIT: On inspection, it looks like 0C80 is the problem location. The CPM3.SYS file is corrupt somehow.

 

[nockieboy]

Can you look at the files on CP/M 2.2 under DDT? That should give us the information immediately.

I can - if you don't mind telling me what commands I need to use?

 

[daver2]

eee-aaaah...

I am going out for my evening walk. You should be able to find your BIOS jump table in the CPM3.SYS file - and it should be intact.

If it is - the loading process has done it in.

If it is not intact, then GENCPM (or some other prior process causing GENCPM to get it wrong) is the culprit.

Dave

 

[durgadas311]

You should get familiar with DDT, IMHO.

For this case, to dump the BIOS entry:

A> DDT BNKBIOS3.SPR
...
* D200
...
* G0
A>

Similar for CPM3.SYS, but you may have to hunt around for the exact address, if 0D80 is not it. "D" is the dump command, followed by the starting address. "G" is the "Go" command, with zero as the address it will return to CP/M.

 

[nockieboy]

Yes, a quick text search of the CPM3.SYS.txt file has thrown up the BIOS jump table at 0C80 and the first three jump addresses are corrupt as per the memory dump from CPMLDR. So it seems there's a problem with GENCPM?

 

[daver2]

Just saw your post before I went out (I have got my coat on ready) and had a nosy at your post.

Agreed - CPM3.SYS is corrupt.

What caused it?

Can you post a copy of the SPR files next?

Dave

 

[nockieboy]

You should get familiar with DDT, IMHO.

For this case, to dump the BIOS entry:

A> DDT BNKBIOS3.SPR
...
* D200
...
* G0
A>

Similar for CPM3.SYS, but you may have to hunt around for the exact address, if 0D80 is not it. "D" is the dump command, followed by the starting address. "G" is the "Go" command, with zero as the address it will return to CP/M.

I know, I just haven't had much call to use DDT up til now. Have just confirmed my previous post, however - 0D80 is the address of the jump table and yes, it is corrupt as per the memory dump from CPMLDR. The question is, what could be wrong with GENCPM to be causing this?