DFB1 Support thread

[Badwolf]

This: https://www.ebay.co.uk/itm/304136985036 Plus this: https://www.ebay.co.uk/itm/230460442947

They don't connect together, though -- well, the end that connects to the Falcon connects to the other cable, but that isn't very helpful!

BW

[frank.lukas]

Boot from Floppy ...

Autofolder: 1. fastram.prg (2614 bytes) 2. hddriver.prg

... 3 or 4 bombs after open up drive c:\

[Badwolf]

Boot from Floppy ...

Autofolder: 1. fastram.prg (2614 bytes) 2. hddriver.prg

... 3 or 4 bombs after open up drive c:\

Thanks, Frank. Are you able to confirm _FRB is there before HDDriver runs? SYSINFO or Cookie CPX, perhaps?

Cheers,

BW.

[exxos]

Grand, thanks, mfro. So it looks to me like MAPROM/FASTRAM is doing the right thing.

I think the only check left is to see if _FRB is actually set.

Although I would be interested in knowing if there's any change to what happens if HDDriver is run *after* MAPROM (eg from floppy).

Interesting..

I'd assume if HDdriver is loaded before MAPROM, it shouldn't know anything about TTram and not use it.. *unless* its doing something naughty.. Like it is trying to set up the FRB without GEMDOS knowing it has TTram. But assume not.

If MAPROM is loaded first, then all should be good.. but does HDdriver then also setup FRB, it could throw things if if both programs try to set the cookie.. again it should be checked if FRB exists before setup the FRB cookie... Or would it conflict with the cookie from MAPROM.

MAPROM should check for the cookie. I think I requested this feature in a later version because in my build of TOS, it does set the FRB automatically. So then MAPROM should not then set it if its already set.. Not sure if those changes made it into FASTRAM.PRG or not...

I think this needs to be tested out what is setting FRB exactly. I would think that MAPROM loading first should be the way to go.. Then check the cookie.. Then load HD11 make sure nothing alters cookie wise.

[dml]

I'd assume if HDdriver is loaded before MAPROM, it shouldn't know anything about TTram and not use it.. *unless* its doing something naughty.. Like it is trying to set up the FRB without GEMDOS knowing it has TTram. But assume not.

I was wondering the same - but the worst that can happen (if it just creates _FRB without visibility of TTRam) is that disk drivers see the _FRB and start using it. Which is benign, if maybe a little bit less efficient (maybe - not necessarily). So it might be the safest policy for a disk driver to just create one, MXAlloc'd from STRam, when it knows it is 'first in' before AUTO folder stuff.

[markus0321]

No worries, that's what Ptermres() does. It's not only "stopping the release" but it completely unhooks allocated blocks from memory management. They simply do not exist anymore from the GEMDOS point of view.

Grand, thanks, mfro. So it looks to me like MAPROM/FASTRAM is doing the right thing.

I think the only check left is to see if _FRB is actually set.

Although I would be interested in knowing if there's any change to what happens if HDDriver is run *after* MAPROM (eg from floppy).

The more information to report to Uwe the better.

BW

I loaded maprom22.prg from floppy disk and then hddriver 11.13. I did an attempt to test the LZH archive and it works fine!
EDIT:
I will try to run programs from SCSI in this configuration.

[dml]

This is what MAPROM2.2 does:-

What I read from the asm:

- tries to publish physical TTRAM to TOS via maddalt (not sure where it gets its size info from, but it looks like the address is hardcoded probably to 16mb)
- bails out if this version of TOS doesn't understand the maddalt() request
- mxalloc's 64kb of STRam for _FRB (bails on failure or unsupported)
- writes a _FRB cookie with the new address (not clear if it checks for existing one first, or if it modifies existing one - probably not)
- updates memtop and writes the 'ttram valid' magic (to survive warm resets)
- quits as TSR, retaining code & all allocs

(I think mfro answered the TSR question already)

[stephen_usher]

This: https://www.ebay.co.uk/itm/304136985036 Plus this: https://www.ebay.co.uk/itm/230460442947

They don't connect together, though -- well, the end that connects to the Falcon connects to the other cable, but that isn't very helpful!

BW

The first cable goes from the Falcon (HD50) to a DB50 (male). The second goes from a DB50 socket (female) to an IDC, connecting to a drive. I thought that was what you wanted.

[frank.lukas]

Boot from Floppy ...

Autofolder: 1. fastram.prg (2614 bytes) 2. hddriver.prg

... 3 or 4 bombs after open up drive c:\

Thanks, Frank. Are you able to confirm _FRB is there before HDDriver runs? SYSINFO or Cookie CPX, perhaps?

Cheers,

BW.

fastram.prg set the _FRB 119FC
fastram.prg plus hddriver.prg set also the cookie

fastram.prg set no values into the XBRA List but HDDriver do ...

0472 hdv_bpb USHD
0476 hdv_rw USHD
047E hdv_mediach USHD

... boot from Floppy with fastram.prg first and than hddriver.prg works sometimes but give 4 bombs when I copy files from one partition to another.

[markus0321]

Thanks, Frank. Are you able to confirm _FRB is there before HDDriver runs? SYSINFO or Cookie CPX, perhaps?

Cheers,

BW.

fastram.prg set the _FRB 119FC
fastram.prg plus hddriver.prg set also the cookie

fastram.prg set no values into the XBRA List but HDDriver do ...

0472 hdv_bpb USHD
0476 hdv_rw USHD
047E hdv_mediach USHD

... boot from Floppy with fastram.prg first and than hddriver.prg works sometimes but give 4 bombs when I copy files from one partition to another.

For me, I ran MAPROM22.PRG from floppy disk 1 and then HDDRIVER.PRG, the first time I also got bombs. I turned Falcon off and back on and this combination works now. Programs that previously crashed now work properly.