|
|
Post by buzbard on Dec 2, 2014 18:19:43 GMT
Here's a DASM source to build an autoboot sector for your disks, it also works with the latest sd2iec firmware, just compile, rename the resulting .bin file to "bootsect.128" and save it to your SD card. Note: The 3 lines dealing with additional sectors is ignored by the new sd2iec firmware. bootsect.asm ; C128 boot sector. (T1, S0)
; Compile without a load address. {-f3}
processor 6502
org $b00
byte "CBM" ; Autoboot signature.
word $0000 ; Load address for additional sectors. (T1, S1)
byte $00 ; Bank number for additional sectors.
byte $00 ; Number of sectors to load.
byte "MENU", $00 ; Boot message: "BOOTING..."
byte "", $00 ; Program to load on boot.
start ldx #<cmd-1 ; Lo-byte of cmd - 1
ldy #>cmd ; Hi-byte of cmd
jmp $afa5 ; Execute BASIC command.
cmd byte "RUN", $22 ; The RUN" command.
byte "MENU" ; Program to "RUN".
org $bff, $00 ; Fill remaining bytes with $00 up to 256 bytes.
byte $00
If you modify this to work with other compilers, post it here for the benefit of others.  |
|
|
|
Post by hydrophilic on Dec 3, 2014 5:22:54 GMT
What do you mean the 3 lines are ignored by the sd2iec? The KERNAL will send these in '1541 Standard' format of U1 (block-read) regardless of burst-mode (fast-serial) support. The U1 command is supported by sd2iec and all CBM floppy drives since (at least) the 1541...
Those 3 lines allow you to load a 'random' file (i.e., probably be missing from the DIRECTORY). The sequential sectors start at track 1 / sector 1... the KERNAL is hard-coded for 1541/71 format... so after sector 20 of track 1, the next sector it loads will be sector 0 of track 2 (this is important if you use a 1581 or CMD disk... they have more than 21 sectors/track in native mode).
CP/M is the only 'commercial' software that I have seen that uses the 'sequential sector load' feature of the boot sector. However I have used it in personal software and it works... it can be slow because the KERNAL increments 'sector' by 1 for each 256 bytes of data... this is slow on a physical disk because it represents a Sector Interleave of 1... floppy disks generally need a Sector Interleave of 4 to 10 for optimal performance (the best value depends on the drive used).
Note that unlike a normal file, each sector of the 'random' file is a full 256 bytes (not the usual 254 bytes)... this is because the track+sector 'link' is not needed (because the sectors are loaded in a known order). Also unlike a normal file, the first 2 bytes of the first sector do NOT contain a load address... the load address (and bank#) are given in the boot sector (the first 2 of those 3 lines).
Trivia: a 'random' (sequential load) file larger than 21*17-1 = 356 sectors will fail on a 1541/1571 because the KERNAL does not skip over the directory track of the 1541/1571! I do _not_ think this is a real BUG because only 256 sectors will fill an entire bank of RAM (and the KERNAL does not increment banks when the address rolls over).
Anyway, thanks for posting useful C128 content for all of us!
|
|
|
|
Post by buzbard on Dec 3, 2014 11:56:54 GMT
Ok, you caught me in a technicality, what I should have said is, The 3 lines dealing with additional sectors is ignored by the new sd2iec firmware if no disk image is mounted. This was added to the firmware November of 2013 to allow auto-booting directly from the SD card without mounting a disk image. The file "bootsect.128" is a simulated boot sector and to quote Ingo Korb, "Attempts to access other sectors are rejected." This works very well for automatically mounting and booting a disk image such as CP/M or GEOS on power-up. Thanks for the "trivia", I hadn't really thought about large sector loads like that. How would you load more than 256 sectors since you only have one byte for the number of sectors? |
|
|
|
Post by hydrophilic on Dec 5, 2014 23:38:26 GMT
The 3 lines dealing with additional sectors is ignored by the new sd2iec firmware if no disk image is mounted... The file "bootsect.128" is a simulated boot sector and to quote Ingo Korb, "Attempts to access other sectors are rejected." ... How would you load more than 256 sectors since you only have one byte for the number of sectors? Ah, I remember reading about the bootsect.128 file. I didn't realize you were referring exclusively to that. Yes, in that case, the concept of tracks and sectors does not apply when no disk image is mounted.
Good call! You can't load more than 255 sectors with the format of the boot sector... so I guess the KERNAL does not have a bug.
On a related note, CMD devices (in native mode) store their disk header and BAM immediately after the boot sector... so they can never support a 'random file' for booting either. Perhaps another reason the method was seldom used.
On topic, a good 'cmd' might be:
cmd .BYTE "OPEN 1,8,15," , $22, "CD:"
.BYTE "DISKNAME.D64", $22, ":RUN", $22
.BYTE "FILENAME"
This mounts a disk image and runs a file on the disk. The example assumes the disk image is in the root directory.
Another good idea for 'cmd' might be to change the device#
|
|
|
|
Post by jmpff3d on Dec 6, 2018 17:13:53 GMT
CP/M is the only 'commercial' software that I have seen that uses the 'sequential sector load' feature of the boot sector. However I have used it in personal software and it works... it can be slow because the KERNAL increments 'sector' by 1 for each 256 bytes of data... this is slow on a physical disk because it represents a Sector Interleave of 1... floppy disks generally need a Sector Interleave of 4 to 10 for optimal performance (the best value depends on the drive used).
The C-128 Infocom games might be replete with that kind of loading, if memory serves properly. |
|
