The Layers: Who Stands Between You and the Disc

Introduction

DISKMON is about to ask for things from the disc, and there are two places it can ask. They know different things, they answer differently when something goes wrong, and one of them is not always there. Before the first call it is worth seeing both side by side.

Two Routes

Your program can reach the disc through the BDOS, or through the MOS

The BDOS is part of XtalDOS. When the Einstein starts from a system disc, XtalDOS is loaded into memory, and the BDOS sits at EC00h. Address 0005h holds a jump to it, so a program reaches it with CALL 5, putting the number of the function it wants in C. The BDOS deals in files: names, and 128-byte records of a file read in order or by number. When the disc fails it, it deals with that itself - it puts its own message on the screen and asks the person at the keyboard what to do.

The MOS is in the Einstein's ROM, so it is there whether or not a DOS was ever loaded. A program reaches it with RST 8 and a call number, as you have printed with call 158. The MOS deals in sectors: drive, track, sector ID, 512 bytes. When the disc fails it, it says so with a number and leaves the decision to your program.

	The BDOS	The MOS
Reached by	`CALL 5`, function in `C`	`RST 8`, call number after it
Present	only when XtalDOS was loaded	always
Knows about	files, by name; 128-byte records	drives, tracks, sectors; 512 bytes
When the disc fails	its own message, and a question on screen	an error number, back to your program

Below both is the floppy disc controller, the WD1770, the chip that moves the head and reads the bits. The MOS drives it for you - and in Part five, so will DISKMON, directly through its ports, to find a message hidden where neither the BDOS nor the MOS can show it.

A Tool for Looking: Hex

From S5 on, DISKMON shows you addresses and bytes, so it needs to print a byte as two hex digits. PHEX does it: the top four bits first, rotated down into the bottom four, then the bottom four; each becomes 0-9 or, past 9, A-F - seven characters further on in ASCII. SHOWMEM uses it to print a run of bytes from memory, and NEWLINE ends a line.

To try it out, DISKMON shows the first eight bytes at 0100h - which are DISKMON itself.

The Code

The whole of DISKMON so far. New since S2: the five lines after CALL PRINT in START, and NEWLINE, PHEX, SHOWMEM and MEMMSG.

; DISKMON - reads and writes the Einstein's discs.
; The Assembly Disc Access Primer's program, as it stands at the end of
; the section named in this file's name.

        ORG 0100H

START:  LD HL,TITLE
        CALL PRINT
        LD HL,MEMMSG
        CALL PRINT
        LD HL,0100H
        LD B,8
        CALL SHOWMEM
        CALL NEWLINE
        RET

; --------------------------------------------------------------- output
; PRINT: print the zero-terminated text at HL.
PRINT:  LD A,(HL)
        OR A
        RET Z
        CALL PUTC
        INC HL
        JR PRINT

; PUTC: print the character in A, keeping BC, DE and HL.
PUTC:   PUSH BC
        PUSH DE
        PUSH HL
        RST 8
        DEFB 158
        POP HL
        POP DE
        POP BC
        RET

; NEWLINE: carriage return, then line feed.
NEWLINE: LD A,13
        CALL PUTC
        LD A,10
        JP PUTC

; PHEX: print A as two hex digits.
PHEX:   PUSH AF
        RRCA
        RRCA
        RRCA
        RRCA
        CALL DIGIT
        POP AF
DIGIT:  AND 0FH
        ADD A,'0'
        CP '9'+1
        JR C,DIG1
        ADD A,7
DIG1:   JP PUTC

; SHOWMEM: print B bytes from HL in hex, each followed by a space.
SHOWMEM: LD A,(HL)
        CALL PHEX
        LD A,' '
        CALL PUTC
        INC HL
        DJNZ SHOWMEM
        RET

; ----------------------------------------------------------------- data
TITLE:  DEFB 'DISKMON',13,10,0
MEMMSG: DEFB 'AT 0100: ',0

SHOWMEM counts with B and DJNZ, which is safe only because PUTC keeps BC for it.

Run it

z80asm -o diskmon.com diskmon.asm
python3 edisc.py remove diskmon.dsk DISKMON.COM
python3 edisc.py add diskmon.dsk diskmon.com DISKMON.COM
mame -rompath ~/roms einstein -window -nomaximize -ui_active -skip_gameinfo -flop1 XTALDOS.DSK -flop2 diskmon.dsk

and type 1:DISKMON.

What you should see

0:1:DISKMON
DISKMON
AT 0100: 21 57 01 CD 18 01 21 61

0:

21 57 01 is LD HL,TITLE - 21, then TITLE's address, 0157h, low byte first - and CD 18 01 is CALL PRINT. Assemble with z80asm -l to see the listing and check the rest.

Change One Thing

Change LD HL,0100H to LD HL,0005H and LD B,8 to LD B,3. You are now looking at the jump to the BDOS. What three bytes do you expect, and what address do they name?
Take out the PUSH BC and POP BC in PUTC. What happens to the count in SHOWMEM - and why might it seem to work anyway?

Summary

A program has two ways to the disc: the BDOS, which knows files and is there only when XtalDOS is; and the MOS, which knows sectors and is always there. DISKMON can now print bytes in hex.

S5 makes DISKMON's first call to the BDOS, and looks at where the BDOS lives and what memory that leaves you.

← Previous Next →