New project: An ACT Apricot F1 "barn find"

[stephen_usher]

I'm thoroughly confused now.

The real floppy is definitely behaving as if it's using /READY, so that's fine. However, it's not always being detected so it must be some other signal.

The only reliable way of making sure that it's not seen is if the Gotek is powered up without a USB drive in the slot, then the system will always only see the Gotek and not the floppy. (Though after not detecting it the system selects drive 1 and holds the line at that level until a virtual disk is loaded into the Gotek.)

Nine out of ten times if I don't have a virtual floppy (i.e. ejected) mounted in the Gotek then again it will only see one drive.

However, if I have a virtual floppy in mounted in the Gotek and the Gotek was powered on with a USB stick in the drive and mount at boot is turned on then about 8 out of 10 times the second drive will be detected. Unless something on the floppy drive/Gotek side goes screwy and it only sees one drive until I power cycle everything and leave it off for about 30 seconds.

[stephen_usher]

And now I can't get it to pick up the second drive at all.

I wonder if it's a timing issue in the boot ROM and the floppy drive isn't responding quickly enough to whatever it's looking for, or maybe it's expecting a Track-0 signal straight away as the built-in drive automatically seeks to track zero on power-up.

If it's the latter then I'm stuffed, unless I make the real floppy drive A: as the disk controller does a seek test automatically.

[stephen_usher]

I think that I've confirmed that it's a "/TRACK0" issue that's stopping the second drive from being detected by the BIOS.

Booted and the second drive wasn't detected. I power cycled multiple times and it was always the same.

I manually pushed the heads back to track zero and then powered up the system and the second drive was detected.

P.S. I'm wondering how I'm going to fix this. Maybe I could pull the drive select 1 line low whilst the FDC does its seek test until track zero goes low directly after power up. If I'm not using the Motor On and Select Drive 0 then I can use those two pins.

[stephen_usher]

You know, I should really read the documentation... From the "Apricot F1 Technical Reference Manual"...

d-oh.jpg (125.36 KiB) Viewed 2395 times

This, of course, means that I'm going to have to somehow throw a whole load of STEP pulses at drive 1 as soon as the power is turned on.

I've a spare pin on connector I added on both the daughter board and floppy cable adapter and the socket for the ATTiny85 has an output which can control STEP so probably only one bodge wire on each board will be necessary, This assumes that the step direction line stays high so as to step outwards.

The alternative is that I pull Drive select 1 down whilst the FDC does its seek test (so that both drive seek, not only drive 0) and then release it as soon as "track zero" is signalled, letting the FDC do the heavy lifting.

[stephen_usher]

I think the quick fix will be to hold the drive select 1 line low for 10 seconds after power on. The FDC controller will do its seek test and bring both drives to track zero. It won't harm if there's no second drive as there will be nothing to force "TRACK00" low and so it won't accidentally find two drives when there is only one. After the 10 seconds is up I can change the output pin on the ATTiny85 to tristate so that it won't affect the system subsequently or change it to being an input pin.

[stephen_usher]

For the time being I have a bit of a hack...
Run GWBASIC with the following program and change the system variable for the number of floppies and warm reset.

Code: Select all

10 DEF SEG=0
20 POKE &H0416,2
30 SYSTEM

[stephen_usher]

I don't s'pose anyone has knowledge of 8086 real mode assembly?

The only free 16-bit x86 C compilers for Linux I can see don't have "far" pointer capability without diving into x86 assembler, which I don't know.

I'm thinking of a small program I can run from AUTOEXEC.BAT in lieu of a hardware solution.

[rubber_jonnie]

Seems like you're getting a good handle on this now, good job sir.

[mrbombermillzy]

I don't s'pose anyone has knowledge of 8086 real mode assembly?

The only free 16-bit x86 C compilers for Linux I can see don't have "far" pointer capability without diving into x86 assembler, which I don't know.

I'm thinking of a small program I can run from AUTOEXEC.BAT in lieu of a hardware solution.

I'm very rusty, but will try to help if no one better suited can!

By far pointer capability, do you mean 32 bit vs 16 bit pointer address offset sizing?

[stephen_usher]

16 bit real mode segment+offset addressing.

I need to change the byte at segment 0x0000, offset 0x0416 to having the value 2 essentially.