FlashFloppy v1.0 and AutoSwap

[Keir]

I'm pleased to announce the release of FlashFloppy v1.0!

The major feature in this point release, apart from finally branching a stable release series from major-feature development, is support for automatic disk swapping in suitably-patched multi-disk software titles.

So far I have patched five games for Amiga to eliminate all manual disk swapping:

• Beneath a Steel Sky
• Indiana Jones and the Fate of Atlantis
• The Secret of Monkey Island
• Monkey Island 2: LeChuck's Revenge
• Mortal Kombat

The game patches are freely available in source form, and of course I have pre-built binaries for general users:
Source: https://github.com/keirf/FF_AutoSwap.git
Binary: https://github.com/keirf/FF_AutoSwap/wiki/Downloads

Thanks are due to JOTD (WHDLoad project) for his game cracks and fixes, which I cribbed or outright stole. Also to ross (EAB of course) for his addchip bootblock which allowed me to support BASS on 512+512k Amigas.

FlashFloppy v1.0 full feature list:

• Game/demo AutoSwap-disks feature
• FF.CFG: New OLED display-type sib-option "-narrower"
• PC98: Direct support for HDM image files
• HxC Compat: Small fixes to Amiga file selector

[Daedalus]

Ooh, that's an awesome feature to have. Well done, and thanks for all your work on Flash Floppy!

[Keir]

I would like some requests for swap-heavy arcade titles if any. Non-AmigaDOS titles to use as proof of concept for any other interested hackers.

All the titles so far are super easy, using AmigaDOS hook(s): I will add more of those titles in due course (Flight Of The Amazon Queen? Legend of Kyrandia? Cruise for a Corpse?). But of course they tend to be adventure genre.

[Neil79]

[Higgy]

Thanks for this & the prepatched files

swap-heavy arcade titles - Street Fighter 2

[Superman]

The Fairlight Mortal Kombat crack seems to have lots of disk swaps before you even get to play the game.

[DamienD]

Rise Of The Robots would also be a good candidate.

[Keir]

Originally Posted by Superman

The Fairlight Mortal Kombat crack seems to have lots of disk swaps before you even get to play the game.

Yeah that's an interesting example, as cracks of extra-capacity formats like PDOS often overflow onto an extra disk and depending how well that's done can make a bunch of extra disk swaps. So examples like that are very helpful!

[bni]

I tried this last night. Awesome work kaffer!

On my Amiga 500 I dont have a HD, and thus can't use WHDLoad stuff, nor do I really want to. So this is perfect for my use case. BASS is very playable now.

Looking forward to try more patched games in the future. Even classics on fewer disks like Cannon Fodder could benefit I think.

On of my favourite games is Pinball Fantasies. But since disk switching are used to select tables, it might not be possible to patch a game like that. Unless a way could be figured out to be able to select from all four tables in some way.

[Keir]

Originally Posted by bni

I tried this last night. Awesome work kaffer!

On my Amiga 500 I dont have a HD, and thus can't use WHDLoad stuff, nor do I really want to. So this is perfect for my use case. BASS is very playable now.

Thanks, that's exactly the motivation for AutoSwap. I'm glad the niche does really exist!

Looking forward to try more patched games in the future. Even classics on fewer disks like Cannon Fodder could benefit I think.

I'm currently working on Fairlight's crack of Mortal Kombat, as first example of doing an arcade title. It is attractive because it's well known, the crack is horrible to use with only a single drive, and for various technical reasons it is looking quite easy to do.

On of my favourite games is Pinball Fantasies. But since disk switching are used to select tables, it might not be possible to patch a game like that. Unless a way could be figured out to be able to select from all four tables in some way.

Could add a keypress to swap between disks, but then it's not really properly autoswap any more.

[Keir]

An update to say that Mortal Kombat is done.

Based on the original Fairlight crack, the AutoSwap version has the following features:

• Automatically swaps disks (of course!)
• Boots from any drive (Kickstart 2+ required)
• Approx 2x faster loading
• Bugs fixed (eg. original crashed with 512/512 memory and Kickstart 2)

There is now a ~1kB assembly version of the AutoSwap patch, suitable for dropping into other arcade titles (where disk/memory constraints permit!). I will shortly write a Wiki article explaining the patching process, though it is a pretty straightforward job for a cracker to plumb in my routines.

[matburton]

This is pretty damn awesome

n00b question but is the Gotek hardware limited to emulating one drive?

i.e. if SEL 2 and SEL 3 were also wired-up would the firmware feasibly be able to emulate more than one drive?
e.g. with a DF0 selector switch in an A500 and a cable with the right wiring is there a world where a single Gotek could act as DF0, DF2 and DF3? (DF1 skipped I presume)

I ask because I'm sure there a loads of 2-3 disk games that would befit from something like this, but patching them sounds like a lot of effort

[Keir]

Originally Posted by matburton

This is pretty damn awesome

n00b question but is the Gotek hardware limited to emulating one drive?

i.e. if SEL 2 and SEL 3 were also wired-up would the firmware feasibly be able to emulate more than one drive?
e.g. with a DF0 selector switch in an A500 and a cable with the right wiring is there a world where a single Gotek could act as DF0, DF2 and DF3? (DF1 skipped I presume)

I ask because I'm sure there a loads of 2-3 disk games that would befit from something like this, but patching them sounds like a lot of effort

I have half a patch in progress to implement this for two drives. More than that is a bit tricky off the Amiga internal floppy header as only two drive-select lines are exposed there. Still that would suffice for 2-disk games and help with many 3-disk games -- assuming they support an external drive!

I do plan to get this finished now that v1.0 is out but it's a tricky patch and apart from this use case its utility is probably quite limited. So the effort-reward tradeoff isn't super motivating

[Jope]

How about test clips to the CIA chip to get the additional two selects?

[matburton]

More than that is a bit tricky off the Amiga internal floppy header as only two drive-select lines are exposed there

True but SEL1, SEL2 and SEL3 are exposed externally and cables are cheap.
Using all three select lines externally with a DF0 selector (again cheap) is pretty plausible.
(I know not all games work with that 'hack' but the majority do)
And with kickstarts after 1.3 the early boot menu removes the need for the DF0 selector switch.

But doubling the drives with the same hardware sounds like an epic win to me in case that helps with motivation!
(If it helps as well I'd be more than willing to buy a Gotek and do testing, but I doubt I can be help with the tricky patch sorry)

[Keir]

Originally Posted by Jope

How about test clips to the CIA chip to get the additional two selects?

Fine for A500. The other issue is finding suitable pins to use for select inputs on the Gotek STM32. Especially since some GPIO pins are not broken out on the PCB, and soldering direct to the STM32 pins is not plausible for most users. Many available headers already used for speaker, OLED display, rotary encoder, ... which users probably want as well as multiple select inputs

[tekopaa]

Fiendish Fred and Big top of Fun would be great to have autoswap too. Its been hard to convert Whdload and only way to play it is via disk

[Photon]

Originally Posted by kaffer

I'm pleased to announce the release of FlashFloppy v1.0!

The major feature in this point release, apart from finally branching a stable release series from major-feature development, is support for automatic disk swapping in suitably-patched multi-disk software titles.

So far I have patched five games for Amiga to eliminate all manual disk swapping:

• Beneath a Steel Sky
• Indiana Jones and the Fate of Atlantis
• The Secret of Monkey Island
• Monkey Island 2: LeChuck's Revenge
• Mortal Kombat

The game patches are freely available in source form, and of course I have pre-built binaries for general users:
Source: https://github.com/keirf/FF_AutoSwap.git
Binary: https://github.com/keirf/FF_AutoSwap/wiki/Downloads

Thanks are due to JOTD (WHDLoad project) for his game cracks and fixes, which I cribbed or outright stole. Also to ross (EAB of course) for his addchip bootblock which allowed me to support BASS on 512+512k Amigas.

FlashFloppy v1.0 full feature list:

• Game/demo AutoSwap-disks feature
• FF.CFG: New OLED display-type sib-option "-narrower"
• PC98: Direct support for HDM image files
• HxC Compat: Small fixes to Amiga file selector

Excellent! Just tried it, read the Amiga info, and after changing FF.CFG to shugart I have native mode working.

I want to make a config close to Amiga drives Do you mind a few questions?

1. How are the images ordered? (Alphabetical from 000 and up?) I'd like to use non-indexed mode because indexed mode sorta destroys the names

2. What does index-suppression do?

3. Is head-settle-ms = 12 a compatibility setting for various Amiga loaders, or taken from HRM, or an average for Amiga drives? (Why not 0? The loader would read it and be happy whatever its timing, or how do I think about this?)

4. (Sketchy I guess) Any hope for .DMS support? It's just a fact that a large portion of the images were released as .DMS, so it would save a step.

[Keir]

Originally Posted by Photon

Excellent! Just tried it, read the Amiga info, and after changing FF.CFG to shugart I have native mode working.

Shouldn't have needed any FF.CFG at all. Default interface setting is 'jc' which means IBMPC if JC is jumpered, else Shugart if not. But explicitly setting 'interface=shugart' does no harm.

1. How are the images ordered? (Alphabetical from 000 and up?) I'd like to use non-indexed mode because indexed mode sorta destroys the names

FAT directory-entry order. You need to use a FAT sorter to alphabetise your directory entries.

2. What does index-suppression do?

Most modern drives (certainly HD ones; I think many DD ones too) suppress index pulses during track changes. FlashFloppy also suppresses index pulses during writeback to Flash after a track/sector write. This is sensible especially for systems using an IBM-compatible FDuC (that is most systems) because index pulses are used to time-out sector read operations -- hence index pulses while RDATA is inactive can only do harm.

I'm not actually sure whether original Amiga drives suppress IDX during track changes? The HRM doesn't specify and I haven't actually tested. I think 3.5-inch DD drives do, and it's older 5.25-inch ones that may not.

You could check by stepping in and out in a long loop and check if IDX is interrupted.

3. Is head-settle-ms = 12 a compatibility setting for various Amiga loaders, or taken from HRM, or an average for Amiga drives? (Why not 0? The loader would read it and be happy whatever its timing, or how do I think about this?)

Head settle on many drives is actually 18ms. The drive will not assert RDATA until that long after a STEP. I'm not sure emulating this aspect of real-drive behaviour is very important. You could drop this to zero, but:
(a) A real drive will certainly have *some* settle time (and likely 18ms)
(b) Even set to 0, FlashFloppy takes time to fetch new track data and prime the pipeline. This would likely be 5ms+.
(c) A more significant setting might be 'track-change='. The default 'instant' pauses disk rotation during track changes, so you lose rotation time during step operations. Obviously unrealistic but it definitely behaves better on a wider range of platforms out of the box. On Amiga you could use the more realistic 'realtime'.

If you really want to be like a real drive I would suggest: 'track-change=realtime' and 'head-settle-ms=18'. I would avoid 'index-suppression=no' as it actually deliberately messes with IDX for systems which rely on regular IDX to generate RDY/DSKCHG type signals.

4. (Sketchy I guess) Any hope for .DMS support? It's just a fact that a large portion of the images were released as .DMS, so it would save a step.

Hard to support compressed image formats. If uncompressed DMS images are common, they could perhaps be supported?

[Photon]

Originally Posted by kaffer

Shouldn't have needed any FF.CFG at all. Default interface setting is 'jc' which means IBMPC if JC is jumpered, else Shugart if not. But explicitly setting 'interface=shugart' does no harm.

Hm... weird. Well, it said F-F on the display permanently and with ADFs in the root folder, the buttons did nothing. When I put FF.CFG with shugart there, the display said 000 and the buttons worked. Maybe I did something else in between? But I don't think I did. Anyway, this is history.

FAT directory-entry order. You need to use a FAT sorter to alphabetise your directory entries.

Hm. Well as I see it I wouldn't then know which is in which slot when I want to put another one on...?

I'm thinking just some lesser selector replacement for day-to-day use. (I first followed HxC compat instructions which didn't let me swap slots and no Selector in .zip...? Be happy to help with a selector for native mode.)

Alphabetized would allow renaming without destroying the filename PC side for putting on new images.

Fantasizing now: If there was some mode toggle between directories and files (e.g. both button press or long-press), you could leverage 100+ images to some degree. 1000+ and you'd want an Amiga selector.

But you can also prepare PC side, just a few images, and if they're alpha-sorted (or if, say, indexed mode used 000*.*, 001*.* etc), you could add on a few images with a minimum of fuss.

Most modern drives (certainly HD ones; I think many DD ones too) suppress index pulses during track changes. FlashFloppy also suppresses index pulses during writeback to Flash after a track/sector write. This is sensible especially for systems using an IBM-compatible FDuC (that is most systems) because index pulses are used to time-out sector read operations -- hence index pulses while RDATA is inactive can only do harm.

I'm not actually sure whether original Amiga drives suppress IDX during track changes? The HRM doesn't specify and I haven't actually tested. I think 3.5-inch DD drives do, and it's older 5.25-inch ones that may not.

You could check by stepping in and out in a long loop and check if IDX is interrupted.

Don't know, but during stepping it's pretty useless to read it so suppressing could be yes as I see it. It all depends on what RDATA means to Gotek (terminology differs here) and whether it is active only when actually transferring data. Certainly, some savers and possibly loaders could wait for an index pulse before writing or reading. Is it only during stepping?

Head settle on many drives is actually 18ms. The drive will not assert RDATA until that long after a STEP. I'm not sure emulating this aspect of real-drive behaviour is very important. You could drop this to zero, but:
(a) A real drive will certainly have *some* settle time (and likely 18ms)
(b) Even set to 0, FlashFloppy takes time to fetch new track data and prime the pipeline. This would likely be 5ms+.
(c) A more significant setting might be 'track-change='. The default 'instant' pauses disk rotation during track changes, so you lose rotation time during step operations. Obviously unrealistic but it definitely behaves better on a wider range of platforms out of the box. On Amiga you could use the more realistic 'realtime'.

Yes, but as I see it reads/writes (for ADF on Amiga, at least) would automatically wait for the signal you send; DMA data transfer would start when the chipset detects the sync word. It all depends on whether your settle time is an "extra wait" after you are sure you can receive/send data. If it is, 0 should be the best setting because there could be a bad saver out there that doesn't wait the max specified in HRM. Only if it's not, it should be set to a time that you can guarantee to be ready within. Right?

Hard to support compressed image formats. If uncompressed DMS images are common, they could perhaps be supported?

Well, hey, long shot, had to get it in there. Thing is about half the images will be compressed DMS and uncompressing each image is as much work as converting to ADF already.

Supporting DMS would be an awesome feature, though, since it's a popular format.

While I'm dreaming how about hot-swap? (I actually haven't tried, since the USB stick keeps blinking forever even when not loading, so I guess it's not safe.) Then, you could keep the root folder empty and just put the ones on that you want to try for the day and all the points about Selectors and slot mapping would be mostly moot.