PDA

View Full Version : Quick question about MOVCPM.COM



JonB
October 7th, 2016, 07:06 AM
Hi

Whilst trying to make space for a patched hard disk driver in Lifeboat CP/M, I have issued the following instructions:


a> MOVCPM 63, *
a> SYSGEN

(followed by <CR> to skip file selection, then enter the drive designation B)

So far, so good. I have a bootable disk in B: that reports itself as a 63k CP/M (normally it is 64K).

Now I thought this meant that the BIOS, BDOS, CCP got moved down the memory map by 1024 bytes, which is plenty for these LoTech drivers, but looking in DDT I can see meaningful data above F6FF (actually, some directory entries - lists of filenames etc. A power cycle / cold boot improves things somewhat - I see FF 00 all over the place now, apart from one area where again there is a directory listing. I went into DDT and attemted to fill the last 1k of memory with FF using command FF700,FFFF,FF which seemed to lock up on me (Edit: It appears to be wrapping at FFFF!); then on a soft boot I see FFs but also the directory entries.

Is this expected behaviour? I would have thought MOVing CP/M down a K would have given me the full K to put my ported driver into.

Chuck(G)
October 7th, 2016, 08:44 AM
A lot depends on where you got your MOVCPM.COM, because it's the responsibility of the OEM to create it. Some OEMs left it "as is" in which case, it includes only the BDOS and CCP data and not the BIOS--you'll have to relocate and re-assemble that one separately and include it on the boot tracks. Other vendors, but by no means all, did a better job and included the page-relocatable binary for the BIOS in the MOVCPM.COM data.

My guess is that you're going to end up re-assembling your BIOS to a lower memory address and writing it do disk yourself. That may also include reassembling the boot sector image and writing that to disk as well.

The "CP/M Alteration Guide" does talk about this a bit, but is a bit opaque, because it wasn't written for OEMs working up a redistribution set.

JonB
October 7th, 2016, 09:11 AM
Hmm, well after all that discussion of Lifeboat Associates and their crappy CP/Ms, maybe I should switch to Aton CP/M...

deramp5113
October 8th, 2016, 05:08 AM
Note that the top 1K of memory starts at FC00, not F700. DDT has known problems with some commands that include FFFF in the range - that didn't have anything to do with the 63K version you created.

Mike

Chuck(G)
October 8th, 2016, 08:15 AM
Yup, DDT doesn't detect the overflow from FFFF to 0000, so if you start, say a dump command there, it will wrap to 0000 and keep on going until the entire 64K has been displayed.

Not very user-friendly. I don't know if any of the derivative debuggers, such as SID or ZDT do that.

JonB
October 8th, 2016, 12:59 PM
Note that the top 1K of memory starts at FC00, not F700. DDT has known problems with some commands that include FFFF in the range - that didn't have anything to do with the 63K version you created.

Mike

Mike, I'm going to double check my numbers.:)

FFFF = 65536.
65536 - 1024 = 64511 which is F6FF (so I put F700) .. according to my calculator, which appears to be lying to me.

[Edit: It's not lying! I just misinterpreted the B in FB00 as a 6 (it displays the value as a lower case b on a digital calculator style panel). Oh, silly me.. ]

So MOVCPM is working and giving me the right amount of free memory, hurrah!

(Move along, nothing to see here..)