search

pi1541 / Pi1541

Commodore 1541 emulator for the Raspberry Pi
GNU General Public License v3.0
381 stars 81 forks source link

Cp/m booting issue with 1581 emulation #177

Open bordy12 opened 4 years ago

bordy12 commented 4 years ago

Hi, I'm having issues trying reading and booting cp/m disk in 1581 format with my C128 with the Pi1541 v.1.23. The disk image seems to load normally on the Pi's lcd then after typing the BOOT command the C128 reply with "BOOTING..." and then nothing else, it keeps stuck in this state. The same disk image boots normally under Vice128. The disk image I refer to is the one contained in this archive: http://www.zimmers.net/anonftp/pub/cbm/demodisks/c128/cpm.622-5002336.d81.gz Others cp/m disk image in d64 boot normally with my C128. Thank you

sven700c commented 3 years ago

Same issue persists on v1.24 and with the ZP/M .d81 image below: http://csdb.dk/getinternalfile.php/175248/zpm3.16mREU.zip

GeoKM commented 3 years ago

I can confirm that both the zpm3 and a freshly made cpm3 .d81 image fail to boot with the above hang, and that my .d64 images of original cpm3 (1987 version) boot just fine. All of which boot fine on VICE. Of course the .d64's are incredibly slow with the pi1541 doing cycle exact. Using .d81's for faster cp/m boot and more space was in fact the reason I bought the pi1541. I hope this gets fixed soon 8-).

I see that on 1541 and 1571 disks the trk1 sect 0 has the boot sector stuff with "CBM" in the first few bytes. 1581's seem different. They start the CP/M directory in trk1 sect 0 and according to some docs I read have a bootable flag on track 40. No idea where the BOOT SECTOR is kept though?

NCommander commented 3 years ago

Going to +1 this bug and add some additional info. If the Pi1541 is in D81 mode (with a ROM loaded) as device 9, CP/M will boot from device 8, and then hang at the BOOTING CP/M PLUS screen. Its possible CP/M is sending a command the Pi1541 doesn't know how to handle; CP/M does work with the SD2IEC so this is almost certainly an IEC communication issue and not something more subtle.

On that note, its fine in the same configuration if the Pi1541 is in 1541 mode. This appears to be caused by an enumeration when the IEC bus is probed. The Commodore 128 CP/M is published and has all the disk commands sent if it helps narrow it down. I was able to write a C128 CP/M boot disk to a the Pi1541 in 1541 mode and boot successfully.

I may take a stab at debugging this further. Need to see how complex the CP/M boot code actually is ...

mwehrens commented 1 year ago

GeoKM: "where is the bootsector?" The Commodore 1581 allows the use of a special disk-side-autoloader USR file by the name of "COPYRIGHT CBM 86". If this file is present on the disk, the drive will load and execute its content completely independently from the computer. In the case of a 1581 formatted disk for Commodore128 CP/M, the auto-exec program installs itself in the queue handler and will intercept an attempt to load-to-buffer the boot sector at Track1 Sector 0 "U1 01 00" as executed by the ROM-Loader of the c128. Instead of Tr1,0 you will receive Tr40,5 (starting Track count at 1, 256b sectors) The boot-sector is loaded to $0B00 - $0C00 as normal, but it loads additional Boot-Code to $E000 using the Burst commands (Track count starting at 0). This loads 4 native 512byte blocks (from 39,4 - 39,7) of a 1581 disk (very fast) to $E000-$E400 Z80 processor is directed to $E000 and picks up there, installs the 1581-updated "boot rom code" (normally copied from Z80 ROM) to $3000 The reason the boot rom code needed to be updated is the disk size of the 1581, this is so large it needed 16bit CPM-block-addressing while the original ROM-based 1571 boot-loader used 8bit CPM-block-addressing.

This 1581 behavior caused the people at CMD (back in the early 90s) to create a special 'CP/M 1581 partition' which redirects the Tr1,0 to Tr40,3 in the same way.

As to why Commodore would have done this, I can only consider the following: The most obvious choice for 1581 would have been to use a full MFM formatted disk (skipping any GCR translation), however this would not have booted in C128. So, if you had a flat C128 and only the 1581 drive, you would have needed an additional program to start CP/M from a 1581 (namely: the boot code). This meant: the 1581 disk would have to support the 'read block Tr1 sec0' command, a Commodore DOS command only effective on GCR disks. That explains the choice for GCR, not for the relocation of the boot block. The bootblock could have sat on Tr1, Sec0 of that disk and could have use the chainloading ability of the C128 to do the rest. However, this would mean the disk would have to skip 1 track (waste of two times 5k of CPM space, upper and lower). Since the 1581 already uses its directory 'automagically' starting an auto-exec, this also meant possible problems. Thus people must have considered: move the bootloader to the directory track (track 40) and use the fancy autoexec to fool the C128 Rom Boot. This way one can start CP/M from a 1581 connected to device 8. For reasons unknown, the device number 8 was hard-coded (LDX #8) both in the boot block and in the '8502-code' used by the z80 loader, while this could perfectly have been LDX 'boot device' from zero page. Note that CPM would still try to load from drive A (device 8). however this can be fixed as well in the bootloader.

If you put a normal (1571, 1541) C128 CP/M boot block on a 1581, it will start booting CP/M but since the block numbers in the CP/M directory of a 1581 are 16bit, the loader will fail.

The Pi1541 needs one of two things to boot CP/M from D81:

Of course, you can still write your own bootloader into Tr1, Sec0 (i.e. copy Tr40 Sec5 to Tr1 Sec0) but this will be incompatible with CP/M since your 256bytes will overwrite the directory of CP/M (the C128 CP/M will start the 1581 disks at Tr0/Sec0 using Burst Commands)