Best way to check active floppy in bootblock

[alpine9000]

Is there an easy way to check which disk drive just booted my bootblock ?

[phx]

Trackloader?

When I initialize my trackloader, then I will check all available drives for disks and read block 0 from them (which also contains my trackloader directory). I can find out the drive with the game disk by checking for an identification on it, like for example a 32-bit ID in the Root-Block field of the boot block (offset 8), which is unused for NDOS disks (880 otherwise).

[alpine9000]

Originally Posted by phx

Trackloader?

When I initialize my trackloader, then I will check all available drives for disks and read block 0 from them (which also contains my trackloader directory). I can find out the drive with the game disk by checking for an identification on it, like for example a 32-bit ID in the Root-Block field of the boot block (offset 8), which is unused for NDOS disks (880 otherwise).

Yes I have seen this code (and use it in fact), but in this case I am wondering if there is a shortcut? Surely some pointer into an OS device structure must hold the disk #?

[phx]

There is a solution for everything, if you dig deep enough.

As you certainly know, the bootblock receives a trackdisk IoStdReq pointer in A1, which was used to load it. You just have to follow the reference to the drive's Unit structure via IO_UNIT(A1), before it gets difficult...

The public portion of the trackdisk Unit structure (refer to TDU_PUBLICUNIT from devices/trackdisk.i) unfortunately does not include the actual unit number. You have to rely on the internal part of the structure, which follows at offset TDU_PUBLICUNITSIZE:

*-- Unit Structure
 STRUCTURE TDU,TDU_PUBLICUNITSIZE       ;(000)
        UBYTE   TDU_DRIVETYPE           ;(xxx) the type of the drive
        UBYTE   TDU_RESERVED2           ;(XXX) for alignment
        UWORD   TDU_NUMTRACKS           ;(xxx) number of tracks on this drive
        ULONG   TDU_MAXOFFSET           ;(xxx) max IO_POSITION allowable
                                        ; Note: now variable
        UWORD   TDU_MFM_TRKBUF          ; used to be MFM_TRKBUF equate
        UWORD   TDU_MFM_MAXTRACK        ; used to be MFM_MAXTRACK+2 equate
                                        ; (the +2 is for the $aaa8 on the end!)
        UWORD   TDU_MFM_SLOP            ; used to be MFM_SLOP equate
        UWORD   TDU_NUMSECS             ; used to be 11
        ULONG   TDU_TDT_DISKSYNC        ; used to be TDT_DISKSYNC
        ULONG   TDU_DISKTYPE            ;(xxx) as returned from disk resource
                                        ; Note: now variable
        UBYTE   TDU_FLAGS               ;(xxx) unit flags
        UBYTE   TDU_6522                ;(xxx) word to write to 6522
        UBYTE   TDU_RETRY               ;(xxx) count of retries
        UBYTE   TDU_UNITNUM             ;(xxx) the number of our unit
        (...much more to follow...)

You should find your unit number in TDU_UNITNUM (untested)!

[alpine9000]

Originally Posted by phx

There is a solution for everything, if you dig deep enough.

As you certainly know, the bootblock receives a trackdisk IoStdReq pointer in A1, which was used to load it. You just have to follow the reference to the drive's Unit structure via IO_UNIT(A1), before it gets difficult...

The public portion of the trackdisk Unit structure (refer to TDU_PUBLICUNIT from devices/trackdisk.i) unfortunately does not include the actual unit number. You have to rely on the internal part of the structure, which follows at offset TDU_PUBLICUNITSIZE:

*-- Unit Structure
 STRUCTURE TDU,TDU_PUBLICUNITSIZE       ;(000)
        UBYTE   TDU_DRIVETYPE           ;(xxx) the type of the drive
        UBYTE   TDU_RESERVED2           ;(XXX) for alignment
        UWORD   TDU_NUMTRACKS           ;(xxx) number of tracks on this drive
        ULONG   TDU_MAXOFFSET           ;(xxx) max IO_POSITION allowable
                                        ; Note: now variable
        UWORD   TDU_MFM_TRKBUF          ; used to be MFM_TRKBUF equate
        UWORD   TDU_MFM_MAXTRACK        ; used to be MFM_MAXTRACK+2 equate
                                        ; (the +2 is for the $aaa8 on the end!)
        UWORD   TDU_MFM_SLOP            ; used to be MFM_SLOP equate
        UWORD   TDU_NUMSECS             ; used to be 11
        ULONG   TDU_TDT_DISKSYNC        ; used to be TDT_DISKSYNC
        ULONG   TDU_DISKTYPE            ;(xxx) as returned from disk resource
                                        ; Note: now variable
        UBYTE   TDU_FLAGS               ;(xxx) unit flags
        UBYTE   TDU_6522                ;(xxx) word to write to 6522
        UBYTE   TDU_RETRY               ;(xxx) count of retries
        UBYTE   TDU_UNITNUM             ;(xxx) the number of our unit
        (...much more to follow...)

You should find your unit number in TDU_UNITNUM (untested)!

Yes! That’s exactly what I was looking for. Thanks so much! I’ll report back when I get a chance to test it.

[phx]

Yes, please tell us if it worked. The internal TDU is from 3.1. I don't know if it changed since 1.x.

[alpine9000]

Originally Posted by phx

Yes, please tell us if it worked. The internal TDU is from 3.1. I don't know if it changed since 1.x.

Does 1.x even allow booting from a drive other than DF0 ?

[Toni Wilen]

Why do you need to know boot drive? AFAIK disk private part has changed in all KS versions.

[alpine9000]

Originally Posted by Toni Wilen

Why do you need to know boot drive? AFAIK disk private part has changed in all KS versions.

Just trying to remove the hard coded drive # from a trackloader so I can boot from an external gotek cable I have on order ;-)

[meynaf]

Can't selx bits in $bfd100 give that kind of info ?

[Toni Wilen]

Originally Posted by alpine9000

Just trying to remove the hard coded drive # from a trackloader so I can boot from an external gotek cable I have on order ;-)

If you already have working trackloader, it should be very easy to add extra drive check. Just find first drive that has disk inserted if you want minimal solution and don't want to check if disk contains expected data.

[alpine9000]

Originally Posted by Toni Wilen

If you already have working trackloader, it should be very easy to add extra drive check. Just find first drive that has disk inserted if you want minimal solution and don't want to check if disk contains expected data.

I guess that's the fallback, I was just double checking there isn't a one liner I can do (like what meynaf suggested above, except I don't think it works).

I just figured that number must be in RAM or the hardware somewhere if the OS has just used the drive to load my bootblock.

[Toni Wilen]

Unfortunately simple unit number is not available in any public data structures (or even in static private).

It should be easy after dos exists but boot block executes before dos initializes.

[alpine9000]

Originally Posted by Toni Wilen

Unfortunately simple unit number is not available in any public data structures (or even in static private).

It should be easy after dos exists but boot block executes before dos initializes.

Well I guess that’s it then, time for plan B

[ross]

I faced this problem for a multifloppy dynamic loader but not solved in a clean/simple way..
So i've fall back to this steps:
- derive which floppies are connected in the chain (this can be from A1 in every KS, see my addchip bootblock, http://eab.abime.net/showpost.php?p=...3&postcount=25)
- scan and map with a simple ID in sector 0 what drive contain what floppy
- if /CHNG detected, repeat scan and remap

[ross]

Originally Posted by meynaf

Can't selx bits in $bfd100 give that kind of info ?

Hi meynaf, I also tried this way but unfortunately is not reliable

[meynaf]

Originally Posted by ross

Hi meynaf, I also tried this way but unfortunately is not reliable

For a very simple check yes, but what happens if you start some i/o with the iorequest and then examine the hardware ?

[ross]

Originally Posted by meynaf

For a very simple check yes, but what happens if you start some i/o with the iorequest and then examine the hardware ?

This actually deserves a try.
But it's probably the same thing as when the bootblock code is starting (and in that case it does not work).

[Toni Wilen]

This is most likely too timing sensitive and it probably also depends on disk rotational position.

[alpine9000]

What happens if you try and turn the motor on in an empty drive ?

I ask as I think that it probably what happens with a lot of trackloaders if you stick them in df1:. They will load the boot block from df1, then the trackloader will try and load the demo/game data from the hard coded df0: