PDA

View Full Version : Puzzled by disk parameter block



pavery
June 25th, 2017, 11:48 PM
Hello all

I'm fitting CP/M up to an 8085 system that uses a RAM disk as opposed to floppy disks.

I'm stuck with figuring out the Disk Parameter Block I should be using, the Alteration Guide just isn't making sense to me. What I have is:

8 sectors (0..7) of 128 bytes (1024 bytes)

256 tracks (0..255) (256KB)

2 tracks (0..1) reserved for system

This is the DPB I've come up with:
spt=8 bsh=3 blm=7 exm=0 dsm=242 drm=63 al0=192 al1=0 cks=16 off=2

dir_buffer 128 bytes
csv0 16 bytes
alv0 31 bytes

Why I've gone with 8 spt & 256 tracks is the RAM board is accessible in 1KB blocks, so no translation is necessary. However the above DPB doesn't appear to fully work.

I'm thinking if someone is kind enough to produce a good DPB, I should be able to work backwards and understand how its derived.

Hopefully I can be put out of my misery :)

Thanks
Philip

Chuck(G)
June 26th, 2017, 07:49 AM
First of all, if this is a RAMdisk, it's hardly removable, so CSV0 and CKS should both be zero. Similarly, your track offset can be 0, since you're not reserving space for boot tracks. BSH/BLM look okay for 1K allocation. DSM is however many K belongs to the RAMdisk (but should be less than 256). You want 64 directory entries, so that's 32 bytes per entry or the directory will occupy 2048 bytes or 2 allocation units. AL0 will therefore have its two highest-order bits sets (C0) and be 192. Each extent will have 16 allocation blocks of 1K bytes or 128 sectors, so EXM will also be 0.

Other than what I've commented on, it looks fine. I'm assuming that you clear out your RAM Disk to E5s on boot.

Perhaps there's a problem in your read/write routines?

pavery
June 26th, 2017, 05:40 PM
Thanks Chuck

Perhaps I should point out this is my first CP/M install & my CP/M experience isn't great as I didn't use it in the day. Also this is
CP/M 2.2.

OK, so the DPB is fine.

The problem I'm having is many commands work, but some don't. DIR, SAVE, TYPE, ERA, STAT & PIP work fine.

What doesn't: MBasic wont start up & DDT is having trouble with loading a file. Eg "DDT file" hangs, using the "I" command returns to prompt without loading file. Yet other commands in DDT work.

What I find puzzling is PIP with filename works, I can copy DDT with PIP and that version of DDT works, so I can't see the read/write (or any BIOS) routines at fault.

Where shall I be looking with this?

Lastly, on getting DDT & MBasic working, would that deem this install to be fully working? Is there any other program I should test?

Many thanks

Chuck(G)
June 26th, 2017, 07:23 PM
How is your stack usage in your RAM Disk routines? A too-hungry stack setup will cause all sorts of problems.

Chuck(G)
June 27th, 2017, 08:47 AM
For certain, if you meed more space in high memory, you need to perform MOVCPM to relocate things. The thing in location 6 is used mostly when routines like XSUB are being used, which temporarily load below the CCP. But a RAM disk driver shouldn't take much memory, should it? It seems to me that it would be the simplest of all disk drivers.

pavery
June 27th, 2017, 01:08 PM
Gee, I thought heavy stack usage might be it as CONIN & CONOUT were pretty heavy. However wrapping those two routines with their own stack hasn't changed the outcome.

I need to verify my copy of DDT is good & then I'll start stepping through it...

As always, thanks for your help Chuck.

pavery
July 8th, 2017, 08:14 PM
Following up on this... I got there, I have CP/M up & running on a TRS-80 Model 100. Well, actually the Virtual T emulator as this was convenient to emulate disk drives. The M100 community is discussing what new hardware needs to be developed to allow us to use a real M100 for CP/M and be mobile, as in not tethered to a desk.

Why DDT didn't work?: On perusing the CCP source long long ago, I spied the HL2DE routine which I needed & duly called from BIOS. This worked fine until a program like DDT wiped CCP to make use of the space. Fixed by BIOS having its own HL2DE routine.

MBASIC not booting up: By using DDT and tracing MBASIC booting up concurrently on another machine, I was able to see where the two machines differed. What struck me as odd was on the successful machine the MBASIC splash screen displayed without a call to BDOS. Here I found code which modified MBASIC to call CONIN, CONOUT, CONST, LIST directly to the BIOS, bypassing BDOS. Why it wouldn't for me was at 0000 I had JMP to my Warm Boot routine and not going to BDOS first. MBasic cleverly uses address at 0001 & 0002 to derive where the BIOS routines are so it can call them directly.

I have one question remaining: Is it necessary to reinstate BDOS as well as CCP on warm boot?

Many thanks
Philip

Chuck(G)
July 8th, 2017, 09:44 PM
That "find the BIOS' trick is more common than you'd think. So 0000 is assumed to be a JMP to BIOS+3. Disk sector-level editing routines use the same trick to find the BDOS SETSEC, SETTRK and READ/WRITE entry points.

No, you don't have to reload the BDOS on a warm boot; the user program isn't supposed to overlay it--only CCP. But since CCP is adjacent to BDOS on the disk, there's little to be gained by not reloading it.