Extended bootloader

[ThorstenBr]

Hi,
I like the new option to load an extended bootloader from the Arduino flash. We already discussed about this on the Fritter forum. Simply using the existing boot mechanism, and just changing the "Prodos" command is a pretty neat solution.
Are you working on an extended bootloader already or planning to make one?

I did a custom bootloader with a configuration utility for the DAN II card for Apple /// (which did load from an actual boot disk, rather than the DANII controller, since Apple /// doesn't support autoboot ROMs). I could adapt this for the Apple II and make a suggestion (merge request, maybe in a week or two). It could also make use of your new option to read and display the current configuration. Let me know, if you were already working on a bootloader - so I could save the effort.

[profdc9]

Well, I'm open to having a bootloader written. Let me explain how it would have to work and what my idea was, which was very simple. First what needs to be done. When you enter the bootloader, the unit number of the booting device, of which the upper nibble contains the slot in which it booted from, is in the X register. Based on this, you can reconstruct the address of the block routine by using the upper byte as $Cx where x is the slot number, and the lower byte comes from the location $CxFF. You can then store that in the zero page, for example, locations $F1 (low byte containing contents of $CxFF) and $F2 (high byte containing $Cx), place the value $20 for the opcode JSR at location $F0, and $60 for the opcode of RTS at $F3, that way you can JSR $00F0 to call the block routine. I have some code below to show how to do this. By the way, I just changed the "get_status" operation in the Arduino on github, so update yours before using this code. My idea for a bootloader was to get the ProDOS volume names of the volume files on SD slot 1 and SD slot 2 and display them, and then take input for which was selected. The ProDOS volume name would serve as the label to identify the file. Example code: INSTRUC = $F0 LOWBT = $F1 HIGHBT = $F2 RTSBYT = $F3 OFFSET = $F4 VOLDRIVE0 = $F5 VOLDRIVE1 = $F6 BLKBUF = $1000 COMMAND = $42 UNIT = $43 BUFLO = $44 BUFHI = $45 BLKLO = $46 BLKHI = $47 START LDA #$20 ; store JSR at $F0 STA INSTRUC LDA #$60 ; store RTS at $F3 STA RTSBYT STX UNIT ; store in unit number TXA ; put unit in A register LSR A ; shift to lower nibble LSR A LSR A LSR A AND #$07 ; just in case we booted from drive 2 ? ORA #$C0 ; make high nibble $C0 STA HIGHBT ; store high byte in memory location LDY #$00 ; store zero in low byte STY LOWBT DEY ; make zero a $FF LDA (LOWBT),Y ; get low byte of address STA LOWBT ; place at low byte ... BUFLOC LDA #<BLKBUF ; store buffer location STA BUFLO LDA #>BLKBUF STA BUFHI RTS READB LDA #$01 ; read block STA COMMAND ; store at $42 JSR BUFLOC ; store buffer location LDA #$04 ; which block (in this example $0004) STA BLKLO LDA #$00 STA BLKHI JSR INSTRUC RTS SETVOL LDA #$06 ; set volume (alternate code) STA COMMAND JSR BUFLOC ; dummy buffer location LDA VOLDRIVE0 STA BLKLO LDA VOLDRIVE1 STA BLKHI JSR INSTRUC RTS GETVOL LDA #$05 ; read block STA COMMAND ; store at $42 JSR BUFLOC ; store buffer location JSR INSTRUC LDA BLKBUF STA VOLDRIVE0 LDA BLKBUF+1 STA VOLDRIVE1 RTS REBOOT LDA #$00 ; store zero byte at $F1 STA LOWBT JMP (LOWBT) ; jump back and reboot

…

On Sun, Nov 20, 2022 at 1:13 PM ThorstenB ***@***.***> wrote: Hi, I like the new option to load an extended bootloader from the Arduino flash. We already discussed about this on the Fritter forum. Simply using the existing boot mechanism, and just changing the "Prodos" command is a pretty neat solution. Are you working on an extended bootloader already or planning to make one? I did a custom bootloader with a configuration utility for the DAN II card for Apple /// (which did load from an actual boot disk, rather than the DANII controller, since Apple /// doesn't support autoboot ROMs). I could adapt this for the Apple II and make a suggestion (merge request, maybe in a week or two). It could also make use of your new option to read and display the current configuration. Let me know, if you were already working on a bootloader - so I could save the effort. — Reply to this email directly, view it on GitHub <#7>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFIJZGPKICNVNLNX3NC5LLWJJZ6HANCNFSM6AAAAAASF7O4Y4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ThorstenBr]

Thanks for the hint with the X register and "unit" containing the slot information in the top nibble. I had already looked at that - and initially thought that unit was zero at boot time. So identifying the slot is actually easier than I initially thought.

Ok, I'll be looking into the bootloader. I'll push something to my GitHub when I have a first working version, so you can have a look.

[profdc9]

I was intending that the unit number would be used to reconstruct the slot number. So that for example, if the card was booted from slot 7, unit number would be $70. This could be used to reconstruct the address of the ProDOS block driver routine in $C7xx (where xx is at the location $C7FF). The code fragment I sent shows how I thought this might be done, so the code would be consistent with how the bootloader uses the X register. Dan

…

On Mon, Nov 21, 2022 at 5:01 PM ThorstenB ***@***.***> wrote: Concerning detecting the slot via the X-register: I already had a look into this. Right now, it wouldn't work, since the value of X is lost before the ROM jumps to the bootloader. It always resets X before returning to the caller (or jumping to the bootloader): quitok: ldx unit ; <<== causes X to be lost prior to "RTS" lda #$00 clc rts The "ldx unit" is probably only required when returning to Prodos, but the same code is executed before jumping to the bootloader. So right now, a bootloader has no way to tell from where it was loaded. One solution I thought about was making a change to the readbytes routine: @@ -179,8 +179,8 @@ readbytes: bne readbytes ; get next byte to 256 bytes ldy uppage bne exit512 ; already read upper page + stx uppage ; store x!=0 to indicate we're processing the second page inc bufhi - inc uppage bne readbytes X is always != 0, so it can be used as a flag to indicate when readbytes is processing the second page (instead of "inc uppage"). As a side effect, the scratch register "uppage" then retains the X value indicating the slot when the bootloader is executed. Tiny change, wouldn't even cost an extra byte. Ok, I'll be looking into the bootloader. I'll push something to my GitHub when I have a first working version, so you can have a look. — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFIJZAWLUU6MJ7I5IXZR6LWJP5LVANCNFSM6AAAAAASF7O4Y4> . You are receiving this because you commented.Message ID: ***@***.***>