Image Map Image Map
Page 3 of 53 FirstFirst 123456713 ... LastLast
Results 21 to 30 of 527

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
    Code:
    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

    So
    Code:
    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.

    Attachment: cbios64.zip

  2. #22

    Default

    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:
    cpm3ldr.jpg

    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

    Default

    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!!

  4. #24

    Default

    Here's what I think the LDRBIOs needs to be, with minimal "gratuitous" changes. CPMLDR.ASM supports BDOS deblocking, but this BIOS still does that and tells the BDOS the physical sector size is 128. It also does not fully implement the DIR/DTA BCBs since only DIRBCB is used in this case. I also am not sure how much of the serial I/O code can go away.

    ldrbios.asm.txt

    Also, since I don't use Z80 mnemonics, I can't be sure the changes are 100% correct, but I'm sure your assembler will tell you. Of course, I can't be certain this will work, either. Take a look and review it, let me know if you have questions.

    This LDRBIOS is derived from you CP/M 2.2 BIOS "cbios64.asm". I added extra entry points and traps for unused ones. It prints enough messages that you should be able to tell how far it gets. If the CP/M LOADER message get printed, that means that the LDRBIOS cold boot completed. If you enabled the memory map printing in GENCPM, that message gets printed after opening CPM3.SYS and reading the first few records. And of course if your CP/M 3 BIOS prints a sign-on message, that indicates you made it to the CP/M 3 cold boot routine. From there, it is debugging your CP/M BIOS.
    Last edited by durgadas311; December 14th, 2017 at 02:15 PM.

  5. #25

    Thumbs up

    Quote Originally Posted by durgadas311 View Post
    Here's what I think the LDRBIOs needs to be, with minimal "gratuitous" changes.
    Sorry durgadas, I got sidetracked by another mini-project (I've implemented in-circuit programming of the ROM to save me swapping the ROM out every time I want to update the monitor). I've put off working on the CP/M 3 upgrade as much as I can now, so I started looking at CP/M earlier this evening, so your post couldn't have come at a better time! Thank you so much for your help!

    Quote Originally Posted by durgadas311 View Post
    CPMLDR.ASM supports BDOS deblocking, but this BIOS still does that and tells the BDOS the physical sector size is 128. It also does not fully implement the DIR/DTA BCBs since only DIRBCB is used in this case. I also am not sure how much of the serial I/O code can go away.
    Ah yes, don't worry about the serial I/O code - I know exactly what it's for and can just DIsable interrupts for CPMLDR. The serial I/O interrupt tells the system that a character is waiting to be read in the port A or port B buffers (i.e. the user has tapped a key in the terminal or a data stream is waiting in the B buffer from the ATmega368 support module).

    Not sure what you mean by the DIRBCB/DTABCB comments - I will go away and read up on this next.

    Quote Originally Posted by durgadas311 View Post
    Also, since I don't use Z80 mnemonics, I can't be sure the changes are 100% correct, but I'm sure your assembler will tell you. Of course, I can't be certain this will work, either. Take a look and review it, let me know if you have questions.
    Absolutely - will do!

    Quote Originally Posted by durgadas311 View Post
    This LDRBIOS is derived from you CP/M 2.2 BIOS "cbios64.asm". I added extra entry points and traps for unused ones. It prints enough messages that you should be able to tell how far it gets. If the CP/M LOADER message get printed, that means that the LDRBIOS cold boot completed. If you enabled the memory map printing in GENCPM, that message gets printed after opening CPM3.SYS and reading the first few records. And of course if your CP/M 3 BIOS prints a sign-on message, that indicates you made it to the CP/M 3 cold boot routine. From there, it is debugging your CP/M BIOS.
    So... just to be clear (it's been a long day and I'm going to bed!)... To test out our new BIOS I need to compile LDRBIOS.ASM into LDRBIOS.REL using RMAC? Then use LINK to link CPMLDR.REL (supplied with the CP/M source files) with LDRBIOS.REL to create CPMLDR.COM?

  6. #26

    Default

    Based on the CPMLDR.ASM I have, assuming it is what produced CPMLDR.REL, you should do this:

    RMAC LDRBIOS.ASM
    LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]

    although, does RMAC support Z80 mnemonics? Back in the old days, we just stuck with Intel + Z80.LIB so I never tried anything else.

    The DIRBCB/DTABCB are just constructs created for CP/M 3 to handle disk buffers. It's a structure (BCB = Buffer Control Block) that allows several buffers to be managed by the BDOS, basically in a least-recently-used manner. One set used for directory, the other for data.

  7. #27

    Question

    Quote Originally Posted by durgadas311 View Post
    Based on the CPMLDR.ASM I have, assuming it is what produced CPMLDR.REL, you should do this:

    RMAC LDRBIOS.ASM
    LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]

    although, does RMAC support Z80 mnemonics? Back in the old days, we just stuck with Intel + Z80.LIB so I never tried anything else.
    I think it does... well, I got this when I tried RMAC just now:

    Code:
    026C
    00DH USE FACTOR
    END OF ASSEMBLY
    That appeared at the end of a (very) long console output of the PRN file, I'm guessing. Couldn't see any errors with my untrained eye..

    The next line - LINK CPMLDR=... etc - produces this response:

    Code:
    A>LINK CPMLDR=CPMLDR,LDRBIOS[OC,NR]
    LINK 1.31
    
    ABSOLUTE     0000
    CODE SIZE    0C6C (0100-0D6B)
    DATA SIZE    0000
    COMMON SIZE  0000
    USE FACTOR     27
    
    A>
    So it appears to have compiled okay. Running CPMLDR seems to do nothing though?

    Code:
    A>cpmldr
    
    A>sysinfo
    Processor:   Z80
    System:      CP/M 2.2
    Top of TPA:  D800
    BIOS start:  E600
    It just returns to the console - a subsequent SYSINFO shows that 2.2 is still running, seemingly with no ill-effects and no trap error messages etc from CPMLDR. Am I missing something painfully obvious? I was hoping that it would at least attempt to load the CPM3.SYS file and (most likely) crash as I haven't compiled CP/M 3 with the new BIOS?

  8. #28

    Default

    Hmmm, do you have a special, modern, version of RMAC? I tried just now on a virtual CP/M machine with RMAC 1.1 and it chokes on nearly every line. I'm guess that the RMAC result you got, 026C, is too small for the BIOS as well, indicating something went wrong. My failed attempt returned 0278 so something must be different between our two setups. The PRN file showed the first successfully assembled code was the "JP BOOT" and the "CALL TRAP". Intel mnemonics interpret "JP" as "Jump if Plus" and you follow that with a CALL TRAP with "trap" undefined (due to invalid op code at that routine) and you have a chance (depending on the CPU flags when CCP executes the loader) that the "JP BOOT" will fall-through to the "CALL TRAP" ("CALL 0000H") which simply returns to the native CP/M immediately. There are also many other opportunities to jump/call 0000H in this mangled code stream.

    But, what have you been using to assemble your Z80 code up to now? Does that tool produce REL files?

    I'd be interested to see your PRN file and look at what code it actually produced. Strange that it did not spew a ton of errors.

  9. #29

    Default

    Quote Originally Posted by durgadas311 View Post
    Hmmm, do you have a special, modern, version of RMAC?
    Hmm.. not that I know of. I can't remember where I got it from as it wasn't in the original CP/M 2.2 file archive that I had. I suspect it was from a CP/M 3 archive or something...

    Quote Originally Posted by durgadas311 View Post
    I tried just now on a virtual CP/M machine with RMAC 1.1 and it chokes on nearly every line. I'm guess that the RMAC result you got, 026C, is too small for the BIOS as well, indicating something went wrong. My failed attempt returned 0278 so something must be different between our two setups. The PRN file showed the first successfully assembled code was the "JP BOOT" and the "CALL TRAP". Intel mnemonics interpret "JP" as "Jump if Plus" and you follow that with a CALL TRAP with "trap" undefined (due to invalid op code at that routine) and you have a chance (depending on the CPU flags when CCP executes the loader) that the "JP BOOT" will fall-through to the "CALL TRAP" ("CALL 0000H") which simply returns to the native CP/M immediately. There are also many other opportunities to jump/call 0000H in this mangled code stream.

    But, what have you been using to assemble your Z80 code up to now? Does that tool produce REL files?
    I've been using TASM, through the DOSBox emulator (and I suspect it is TASM 3.1, from here) - I don't do any code editing in CP/M as I don't have anything other than ED in CP/M 2.2 (which is a royal pain in the arse). I don't think I can use Wordstar or anything like that as I'm accessing the SBC through a terminal (PuTTY) rather than a CRT, so I don't have any graphics or cursor-positioning commands other than the extreme basics.

    EDIT: And no, it doesn't produce .REL files as far as I can tell. :/

    Quote Originally Posted by durgadas311 View Post
    I'd be interested to see your PRN file and look at what code it actually produced. Strange that it did not spew a ton of errors.
    I'll see if I can get it copied via the terminal and post here shortly.
    Last edited by nockieboy; December 16th, 2017 at 11:03 AM. Reason: Adding URL link for TASM

  10. #30

    Default

    Okay, here's the LDRBIOS.PRN file:

    LDRBIOS.zip

    Here's RMAC:

    Code:
    A>RMAC
    CP/M RMAC ASSEM 1.1
    A:.ASM-NO SOURCE FILE PRESENT

Bookmarks

Posting Permissions

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