Commodore Amiga Reading HD 1.76MB ADF Images.

[Tallguy297]

I recently created a few bootable ADF 1.76MB Workbench Images.
They only seem to boot if I go through the AUTOBOOT process and select an image manually.
If I reset and try to reboot the same image, it is skipped and boot commences from the hard-drive.
It seems to get stuck on the 1st couple of tracks and then decides to skip.
If I boot using the hard-drive, 1.76MB ADF image is sensed. I can read, write & format.
If I select a standard 880Mb ADF image, when I reboot the image will boot successfully.
If boot the Workbench from the hard-drive, I can read, write & format the standard ADF image.

Is this a problem than can be corrected with a firmware patch/upgrade?

Thankyou...

[keirf]

The HD ID signal that flashfloppy generates 101010... is not synced to the motor signal as it should be. This is because standard gotek doesn't have the motor signal connected. Usually we get away with it but perhaps not at boot.

This is possibly fixable if you hardware mod the gotek to connect the motor signal through.

[keirf]

Have you tried a double reset? Ie reset after failing to boot from the floppy. Or reset and then reselect disk image before the boot process gets as far as checking the floppy for boot?

[Tallguy297]

Yes I have tried a double reset and I get the same result.
It gets stuck between track 0 and 1 and then boots from the hard-drive.

Why would a hardware mod be necessary?
Could that be emulated in a firmware fix?
If a hardware mod is the only solution, could you provide a circuit diagram?

Thankyou...

[keirf]

The issue is that the ID is sent on the READY signal wire when the motor is off, and select line is toggled. 1, 0, 1, 0, etc. But it has to be in sync at the start, as 0, 1, 0, 1, etc is a different ID! The start is signalled by the Amiga turning the floppy motor on and then off again. We miss that, and trust to blind luck that we are in sync with the Amiga's expectations (a 50/50 shot that actually we seem to always win, except in this case here).

Why does it work via AUTOBOOT? Probably because this looks like a disk-change at boot time.

So:

1. Does a 1.76MB image boot from power on?
2. If you eject the 1.76MB image (do you have a rotary encoder? Just press it), reset, and then immediately re-insert the image (press the encoder again) does that boot?

And yes, in short you would need a hardware mod (here: https://github.com/keirf/FlashFloppy/wiki/Hardware-Mods#motor-signal) and you would need a tricky little firmware fix too. So that approach is not straightforward.

[keirf]

If you are interested in doing it properly, with the hardware mod, let me know and I can send you firmware(s) to test.

[Tallguy297]

The 1.76MB image does not boot from power on.
I have a rotary encoder and when I press it to eject and then reinsert, nothing seems to happen.
It's only when I do a disk change through the Autoboot program then it boots.

It's not a huge concern. I was creating a custom install disk with the PFS3 file system on it. I ran out of space so I created a 1.76MB floppy version to make things a little easier.
I am getting the new Kickstart 3.X upgrade rom and I have to reinstall the operating system onto a new SD card.

I don't mind going through the AutoBoot program to do a disk change. It's just a little inconvenient.

Thanks for your help...

[keirf]

OK no problem. Reopen if you want to pursue it in future.

[gbouille]

If you are interested in doing it properly, with the hardware mod, let me know and I can send you firmware(s) to test.

Hi,

I have an Amiga 4000 with modified Gotek drive (like described here https://github.com/keirf/FlashFloppy/wiki/Hardware-Mods#motor-signal). Sometimes it work and sometimes not when I start theAmiga with an HD floppy drive inserted. So I'm ok to do some tests with an alternative firmware. Just let me know if it's still good for you.

[keirf]

OK I will investigate this some more and get back to you.

[callimero]

I just stubled at that topic. Was trying to use a HD Disk for booting some experimental WB. Made an HD Image, made install df0: on amiga, then copied a WB to it. I think it booted straight to it but maybe (i forgot) I needed some tries?! When booted I installed some grafic card drivers on that WB, rebooted and so far I could not get it to boot again :(

EDIT: Insert a normal DD Boot disk, enter the Boot menu, select DF0:, press boot and swap image to HD works.

Another thing I want to mention: After trying to boot a HD Image FlashFLoppy does not work anymore, I can switch images but they never appear on WB or the system. Even normal DD ones not.

[keirf]

@gbouille (and others) still any interest in pursuing this? Sorry for the years delay!!

[gbouille]

Hi @keirf , It was a long time :) Yes I'm still interested by this feature. And don't worry about the delay, I was not as available as I wish. Thanks !

[Madowax]

Just a quick question related to this issue, in the hardware mods wiki, about Motor Signal mod, the mod specifically describes to connect pin 36 of the MCU to pin 16 of the floppy interface, while on the gotek bug fixes list, concerning the MotorON Signal, it is said that PA15, which is instead pin50 of the MCU, should be connected to pin 16 of the floppy interface, is it a typo or both MCU pins must be connected to pin16 of the floppy interface?

[keirf]

For a regular Gotek it is PB15 (pin 36 on an LQFP64 package). PA15 = pin 50 is only for Enhanced Gotek designs, identifying themselves as such to firmware via ID on pins PC12-15.

These days it is easier to get a new AT32F435 based Gotek which have Motor signal jumper configurable.

[keirf]

I have moved the Enhanced Gotek stuff to a separate support wiki page. It was confusing having it as a section within user Hardware Mods.

[Madowax]

Thanks I modified my regular gotek with motor_on signal using your instructions and pin 36 for quite some time, to use it as HD floppy in my A4000, it is configured as Amiga under FF.cfg also the motor delay is set to 200ms in the cfg file. Still I also experience the behavior described above, amigatest kit describes the HD ID signal as unstable and it complains about a too fast ready signal switch between motoron and ready. I hope I explained it well enough. Is there the need of a custom firmware still?

[keirf]

Yes, the correct integration of Motor handling into generation of the HD disk ID signal is yet to be completed.

[keirf]

The too-fast READY signal warning means that the motor signal is somehow not configured correctly. Wrong option name in FF.CFG, or not correctly connected to pin 36, or not pulled up by a 1k resistor.

[Madowax]

The 1k pull-up is correctly connected to pin 16 of the floppy interface and +5V line, so it is the wire to pin 36 of the MCU, just checked with multimeter. In FF.cfg I modified interface = amiga and motor-delay = 200, is there anything else needed? Flash floppy 3.35 installed ofc

[Madowax]

Ok just tested: with interface = JC or shugart, motor signal works perfectly with 200ms delay to ready signal, it does not work with interface = amiga, In that case HD ID signal works but not motor-delay. Sorry I did not understand that it was not implemented at all if the interface is set to amiga, I thought it was still working simply not properly. Thanks and sorry

[keirf]

Please can you try this test firmware (you will need to be logged into GitHub for the link to work). Please make sure interface = amiga and motor-delay = 200 in your FF.CFG.

You should find that the 200ms delay works properly. Also hopefully you will find that the HD ID stream is stable and correct.

https://github.com/keirf/flashfloppy/suites/8142113998/artifacts/353073025

[Madowax]

Yep, it does work! 200ms motor signal to ready delay and no more unstable id! Do you need any more tests performed? My floppy config is: Gotek as HD Drive as DF0 and a regular DD amiga floppy as DF1, both internal on the same cable.

[keirf]

Can you give it a kick around on actual amigados, with/without using autoboot, inserted from cold boot, not inserted from cold boot, disk swaps within Workbench etc etc and see if it seems solid?

[Madowax]

OK I got AmigaOS 3.2 Rom installed:

1. power on, No disks inserted -> Insert disk Logo on screen -> insert booting DD ADF -> working boot!
2. power on, booting DD ADF inserted -> working boot!
3. power on, booting DD disk DF1, not booting HD ADF in DF0 -> working boot -> able to browse HD ADF contents
4. power on, booting HDD, not booting DD ADF inserted, not booting DF1 disk inserted -> working HDD boot, able to browse both disks contents
5. In workbench with inserted DD adf on DF0: -> switch to HD adf on DF0: without eject-> able to browse HD ADF contents

I have yet to try a booting HD adf but other tests look ok. I will let you know booting HD ADF results Thanks

[keirf]

That's great! Thanks for your testing so far.

[Madowax]

Ok, no problems whatsoever, but it does not boot from HD ADF, sometime it does but it's due to the fact that the Amiga still thinks it is a DD ADF. Let me explain: you power on the Amiga with not booting DD ADF inserted, Amiga goes to insert disk logo, then you switch to a Booting HD ADF without ejecting, the Amiga starts to boot but than complains about blocks out of range. I can replicate this every time. At the same time if I go to Early Startup with a HD ADF mounted since power on, DF0 is not even listed as a boot device only DF1 is there, if I do the same but with DD ADF inserted both drives are present in the early startup boot selection. Quick question: can Amiga boots from HD floppies? A real HD FDD with a booting HD floppy inserted I mean. I can't test it, I got no HD FDD.

[keirf]

How odd. I think HD disks can be booted, though I've never tried myself.

Was this from power on? Is the behaviour the same if you mount an HD ADF and then C-A-A reset?

And is the overall amigados behaviour strictly better than previously?

EDIT: There is also some small possibility this is an HD boot issue specific to Kickstart 3.2. Boot detection of df0 was changed in this Kickstart release.

[Madowax]

The overall behavior is better, even more when, while in WBench, you switch from DD to HD ADF, it works no problem, probably the ID signal is working better. However if you boot to HDD with an HD ADF inserted since poweron/CTRL+A+A the DF0 drive does not work at all. This happens with cold boot and CTRL+A+A both.

[keirf]

I could disassemble 3.2 I suppose and see what it does at boot.

It's weird it would be reliable everywhere except at boot, assuming 3.2 recognises HD disks at boot, which isn't confirmed.

[keirf]

Which Kickstart version are you running? 3.2 or 3.2.1?

[Madowax]

3.2 but I can flash whatever version you want to test, no problem. I got official 3.2 and 3.1 original roms. Let me know.

[keirf]

A play around with 3.1 would be interesting. The boot time drive detection is definitely different in 3.1. More like earlier ROMs. Hyperion gave it perhaps the first big change / rewrite ever in 3.2.

If you have time.

I also could do some testing. I'd need to make a bootable HD ADF.

[Madowax]

I can switch the gotek to my Amiga 500 with KS2.04 or to my Amiga 1200 with KS 3.0 or 3.1 it does not require much work/time. If it still counts as a functional test for you.

[keirf]

Yes still useful!

[keirf]

I disassembled KS 3.2.1 but nothing jumped out at me as being obviously different or wrong for boot time DF0.

[keirf]

Hopefully others will do some before vs after testing too. It would be nice to put these changes in the next release if they don't regress anything and are of wider benefit. The comment here linking to the test firmware and instructions to make use of it is: https://github.com/keirf/flashfloppy/issues/354#issuecomment-1237316838 Note that you will need MOTOR signal hooked up: either using an AT32F435 Gotek, or will require solder modding of most old Gotek models.

[Madowax]

Tested on KS3.0 A1200 same issue, WinUAE boots from HD floppies though, so probably does a real Amiga, using Amiga Test KIT on WinUAE with HD adf I get 377 ms motor-delay and 386 ms index pulses period, which is not exactly double the value of DD adf, which is 204 ms. Do you think it might be related?

[keirf]

I'm going to try and obtain a real Amiga HD drive Chinon F[BZ]-357A and then I can do real-world side-by-side comparisons. I can't really understand why boot time behaves differently, especially warm reboot. Perhaps the FlashFloppy fix is still a bit racey.

Are your 1200 or 4000 accelerated at all?

386ms index pulses period is strange. I suspect a WinUAE bug.

[Madowax]

In PCFloppy2Amiga.lha on aminet (which you probably already know perfectly well) there is this timing schema: If there is a HD disk in the drive it will not pull the READY line low the second time the SELECT line is low. For every even pulse on the SELECT line no READY pulse is given. In a time diagram it looks like this:

SELECT ~~||~~||~~||~~||~ amiga signal

READY ~~||~~~~~~||~~~ signal from drive

and this note: For a High density drive to work with the amiga you need at least a kickstart 37.175 (2.0). There is however a bug only in the 37.175 kickstart. When you used the HD drive with a DD floppy and you change it back for a HD floppy you will still be in the DD mode so you will get a read error of the roottrack. The program HDFixer in aminet archive disk/misc/HDFixer.lzh will remove this bug.

[Madowax]

I'm going to try and obtain a real Amiga HD drive Chinon F[BZ]-357A and then I can do real-world side-by-side comparisons. I can't really understand why boot time behaves differently, especially warm reboot. Perhaps the FlashFloppy fix is still a bit racey.

Are your 1200 or 4000 accelerated at all?

386ms index pulses period is strange. I suspect a WinUAE bug.

My test a1200 is baremetal 68020 with only chip ram, my A4000 is warp engine accell with 68060 @ 75mhz and 128 MB fast

[keirf]

Okay not related to acceleration then basically.

Regarding behaviour of READY signal -- yes, this is what the FF firmware fix is trying to improve emulation of. It's tricky in firmware as timing of responses to changes in the SELECT signal needs to be very fast. Maybe I'll find it works better anyway with the new 435-based Goteks (they are clocked 4x faster at 288MHz c.w. 72MHz on older Goteks).

I can also put a logic analyser on the drive lines and check that READY is behaving as it should... just a case of finding some more time.

[Madowax]

Okay not related to acceleration then basically.

Regarding behaviour of READY signal -- yes, this is what the FF firmware fix is trying to improve emulation of. It's tricky in firmware as timing of responses to changes in the SELECT signal needs to be very fast. Maybe I'll find it works better anyway with the new 435-based Goteks (they are clocked 4x faster at 288MHz c.w. 72MHz on older Goteks).

I can also put a logic analyser on the drive lines and check that READY is behaving as it should... just a case of finding some more time.

Even if it is only at boot time, during os it works nicely, if needed I can connect an oscilloscope to SEL and READY lines to take a look at timings. there is also this note In PCFloppy2Amiga.lha: The thing I didn't tell you that the amiga system isn't happy with testing the READY line once no, to be on the save side it does it only 32 times.

[keirf]

Yes it reads in a 32-bit drive id. For no good reason really. Two bits would do: 11 no drive, 00 DD drive or HD drive DD disk, 10 HD drive HD disk, 01 40-track 5.25 drive.

[Madowax]

This is described as the exact drive behaviour, probably timing relation between signals is quite important at boot time: To recognize when a drive has been connected to the bus, there is a special drive identification mode. A 32-bit word is read serially from the drive. To start this identification, the MTR line of the drive in question must be turned on and then off again (The description of the MTRX line tells how this is done). This resets the serial shift register in the drive. The individual data bits can then be read by placing the SELx line low and reading the value of the RDY as a data bit and then placing the SELx line high again. This process is repeated 32 times. The bit first received is the MSB (Most-Significant Bit) of the data word. Since the RDY line is active low, the data bits must be inverted.

The following are standard definitions for external drives:

$0000 0000 No drive connected (00) $FFFF ffff Standard Amiga 3 1/2" drive (11) $5555 5555 Amiga5 1/4" drive, 2x40 tracks (01) As you can see, there are currently so few different identifications that it suffices to readjust the first two bits.

[A high capacity floppy drive was available for later Amigas, so this list may have been expanded for later models]

Most standard drives do not support this option.

As mentioned before, all of the lines except DRES affect only the drive selected. Originally the MTRX line was also independent of SELx, but the Amiga developers changed this by adding the motor flip-flop described on the floppy disk interfacing page.

MTRX | Normally this line causes all connected drives to turn their motors on, however, the Amiga has a flip-flop for each drive which takes on the value of the MTRX line whenever the SEL line for the given drive goes low. The output of the flip-flop is connected to the MTR line of the drive. This allows the drive motors to be turned on and off independently. For example, if the SEL0 line is placed low while the MTRX line is at 0, the motor on the internal floppy turns on. For the internal drive this flip-flop is on the motherboard. For each additional drive, an additional one is needed. On the 1010 disk drive Commodore placed this flip-flop on a small adapter board.

[Madowax]

Sorry to bother you again Keirf, would be possible to have the regular flashfloppy firmware with just a simple addition? I need an output signal for when a DD or HD ADF is inserted, which I think is what you named in your ff.cfg: the dens,ndens signal. But I need it on a different pin which is not connected to pin 2 or pin 34 of the floppy interface. I would like to try and solve the ID problem at boot time with a simple and small logic board addition but I need a signal low when no adf or a DD ADF are inserted and a signal high when a HD ADF is inserted. If it works it should be possible to use the standard "interface=JC" or "interface=shugart" config with motor-delay set and the aforementioned DD/HD signal that could eventually be enabled in FF.cfg. In this way there would be no need to match the Amiga timings with firmware and it could be used on every gotek old or new. Let me know what you think.

[keirf]

Here is a build which emits den signal on pin JB (speaker functionality is therefore disabled on this pin): https://github.com/keirf/flashfloppy/suites/8169156486/artifacts/354965722

[Madowax]

Ok, it works with the small logic board. Amigas boot from the hd ADF with no issue.

[keirf]

Some more work required on the firmware then!

[Madowax]

Some more work required on the firmware then!

This is the design I used as reference, based on how to modify a CHINON FB-357 to FB-357A. This is the pcb schematics to allow a FB-357 PC Drive to pass the correct ready signal for HD disks.

http://jope.fi/drives/fz357/CHINON1.JPG

Tested with FlashFloppy 3.35 interface=jc motor-delay=200 and a manual switch to choose DD/HD signal. I hope it helps.

[keirf]

Can you zip and attach a bootable HD ADF here for reference?