Image Map Image Map
Page 3 of 3 FirstFirst 123
Results 21 to 23 of 23

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

  1. #21

    Thumbs up

    Quote Originally Posted by durgadas311 View Post
    I understand the frustration, this sort of thing is not really easy - despite what the instructions might imply. And to do this while learning (about Z80 ASM and CP/M) is even harder. If I had a virtual machine to match your hardware, I could probably be of more help. I'm strapped for spare time right now, though.

    another area to pay attention to, when creating the BIOS3 code, is the DPH and associated structures. There are some subtle differences and new structures which need to be carefully handled.

    I'l try to find some time this weekend to take a closer look at your BIOS code and see if I can help by inspection. If you've got something to document your hardware, that might be nice. either "programmer notes" or a schematic.
    You sir are a star.

    I don't have a single schematic for the design - the schematics are quite modular. However, here's a summary of features that should help:

    The SBC has a flexible MMU, which splits the Z80's 64KB memory space into 4 16KB 'Areas', each able to be independently mapped to any 16KB Bank in the 256K available physical memory (128KB SRAM in lower half, 128KB EEPROM in upper half.) With the addition of a CompactFlash card, the SBC has permanent storage allowing it to run CP/M 2.2. It uses an ATmega328 microcontroller to enhance its IO potential:
    • Z80 microprocessor at 2, 4 or 8 MHz clockspeed, software-selectable
    • 128K SRAM (00000h-1FFFFh)
    • 128K ROM (20000h-3FFFFh)
    • MMU provides access to 256KB physical memory in 16x16KB Banks, mappable to the Z80 in any arrangement as 4x16KB Areas
    • Z80 SIO/2 providing two serial interfaces, with interrupt-driven Rx channels to prevent unnecessary polling of the Rx buffer when not in use
    • CompactFlash adapter with 64MB CF card providing 8x 8MB drives for file storage
    • OS - Custom ROM monitor providing NASCOM BASIC, memory and Intel HEX file input utilities & CP/M 2.2
    • I2C bus via Support Module - currently supports Real Time Clock module
    • Fully-expandable interrupt system
    • Z80 CTC for clock/timer functions and user-programmable triggerable interrupts
    • Z80 PIO for 2-channel parallel IO

    Memory & IO Map:

    Power-up Memory Map:
    • Area 0 - 0000-3FFF ROM (Bank 0F - DMI monitor)
    • Area 1 - 4000-7FFF RAM (Bank 01)
    • Area 2 - 8000-BFFF RAM (Bank 02)
    • Area 3 - C000-FFFF RAM (Bank 03)

    As the MMU allows full configuration of the memory space, this memory map is only applicable at first power-on. i.e. the RAMMODE command copies the DMI from Bank 0F to Bank 00, then maps Area 00 to Bank 00.

    Memory Map in CP/M mode:
    • Area 0 - Bank 0 (SRAM)
    • Area 1 - Bank 1 (SRAM)
    • Area 2 - Bank 2 (SRAM)
    • Area 3 - Bank 3 (SRAM)

    Breakdown of the CP/M memory map:
    • 0000-0100 Scratch storage & interrupt vectors
    • 0100-D800 TPA
    • D800-E5FF CP/M
    • E600-FFFF BIOS

    I/O Map
    • 00-07 SIO/2 dual-port serial interface
    • 08-0F Reserved for PSG
    • 10-17 CompactFlash interface
    • 18-1F CTC 4-channel programmable clock/timer
    • 20-27 PIO 2-channel parallel I/O
    • 28-2F Unused
    • 30-37 Unused
    • 38-3F Memory Management Unit

    The CompactFlash storage and format is identical to Grant Searle's design here and uses the same routines to read/write. In fact the SBC is based loosely on Grant's design, with some modifications to the IO mapping and RAM/ROM select (in my SBC it's managed via the MMU.)

    The MMU is controlled via an
    OUT ($38),n
    command, where n is a control byte made up of the following:
    • B7 - low = MMU active, high = MMU inactive
    • B6 - not used
    • B5, B4 = Area select
    • B3-B0 = Bank select

    OUT ($38),02
    would map Bank 02 (SRAM 8000-BFFFh) to Area 0 (0000-3FFFh).

    Also, I've attached the current CBIOS for CP/M 2.2 - this works with my SBC to allow CP/M 2.2 to run without problems.


  2. #22


    I did some looking around. I see that you are using Z80 vectored interrupts, but it appears the only interrupts are for serial input. I don't know if one of your serial channels is automated in any way (i.e. input may occur spontaneously at any time - like during the loader execution). To be safe, I would suggest that your loader BIOS either keep interrupts disabled or re-initialize the Z80 and SIO vector pieces for valid routines within your loader BIOS.

    Another thing I noticed is that the loader BDOS expects your loader BIOS to work in CP/M 3 version structures. This means the DPH and the DPB need to be compatible with CP/M 3. This also means you could let the loader BDOS handle deblocking, if you wanted, by initializing (to non-zero) the physical sector bytes at the end of the DPB. The loader BDOS does not do any bank-switching, but it does depend on a "move" entry point to the BIOS, which is a simple (DE)-to-(HL)x(BC) move routine. The only BIOS routines that seem to be needed are COLD BOOT, CONOUT, disk setup and read, and MOVE. The loader BDOS also expects the DIRBCB and DTABCB buffer control bock chains to be valid. So, the loader BIOS is not really CP/M 2.2 nor is it a full-featured CP/M 3 BIOS.

    Looking at the latest LDRBIOS.ASM that I have, I would do the following:

    1) Remove all EXTRNs, and any code that uses those symbols.
    2) Change all "unused" BIOS entries into a trap for debugging. since you already have routines to print a HEX address, you could change all the unused JP entries into "CALL TRAP" and have the TRAP routine pop the address and print it in an error message and then die (DI; HLT) - so you know what's being called.
    3) Remove all code no longer used after (2).
    4) Make (cold) BOOT do *at least* a DI (and make sure nothing enables interrupts). The loader won't use console input, but if you have other uses for that special channel then you'll need to handle it. You can either do polled input or re-initialize the interrupt vector to something inside the loader BIOS. Also, do not change the stack pointer - keep the loader's stack. Be sure to return from BOOT, do not try to "start CP/M" yourself.
    5) Do not use DSEG - keep all code/data in CSEG.
    6) Do not rely on the CP/M 2.2 BIOS for anything. The BDOS, including loader BDOS, remembers the BIOS structures and uses them, which won't work while the loader is overwriting the CP/M 2.2 BIOS with CP/M 3. Let alone you won't be able to call into the 2.2 BIOS.

    Here's a picture that may help:

    While the loader is running, it is overwriting the area used by the 2.2 BIOS with the CP/M 3 resident BIOS/BDOS. This means that any attempts to access code or data in the 2.2 BIOS area will result in a crash (either jumping to invalid code or using corrupted data). This is why the loader BIOS must be stand-alone. But since you don't need any of the write and deblocking code, or any of the extra I/O, it should be simple and small.

    Does this make sense?

  3. #23


    Quote Originally Posted by durgadas311 View Post
    Does this make sense?
    Right now, having just skim-read your post, no it doesn't really. But that's no surprise as I'm so new to CP/M and assembly that it'll probably take me a few days of reviewing what you've written and breaking it down before I get a grasp of it all. I'm hoping to get some time tomorrow or perhaps during the week to review what you've written and develop a plan of action. I'll be back with questions, no doubt!

    Thanks so much for taking the time to look at it, durgadas - your help is much appreciated!!


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts