FlashFloppy v1.0 and AutoSwap

[Keir]

Originally Posted by Photon

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.

Weird. Oh well.

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

Yes that is true, of course slot assignments would shift.

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.)

Did you get the HxC-Compat selector working at all? The Selector is called AUTOBOOT.HFE, not Selector.adf or anything else.

If you have thoughts on what the different feature set would be for a new Selector, that would be interesting. I think a more featureful Selector (more iGame style) might be good... A more minimal selector I'm not sure about, as the existing Selector is pretty minimal.

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.

I'm resistant to overloading the buttons and 3-digit display too much. It's okay for casual users, and with AUTOBOOT.HFE for Selecting between many images. For more demanding users, you are best fitting an OLED display (killer feature) and a rotary encoder (almost as killer). This makes native mode amazingly more usable for a cost of a few pounds and maybe 30 minutes modding.

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.

That's an interesting option for indexed mode.

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?

A floppy drive is constantly reading while:
(a) motor is on and stabilised (Gotek ignores motor signal by the way)
(b) heads aren't settling
(c) host isn't writing (DKWEB & SELx == FALSE)

This is true even if SELx is deasserted (the open-collector DKRD output is of course disabled in this case).

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?

Oh, the settle time is ignored for writes (host -> drive). It is only a delay before read data is sent (drive -> host). So don't worry about it.

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

What tools are out there for DMS-ADF conversion? If there is a library or command-line tool (on Amiga platform or Windows/Linux/etc) then it would be so easy to script a batch conversion.

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.

Hot swap is (mostly) safe already. The stick endlessly blinks because FF endlessly reads from the stick, because:
(a) as mentioned above a floppy drive is almost constantly reading
(b) FF has no buffer/block cache at the moment, so it endlessly reads the current track's data from the ADF image even if it would easily fit in Gotek SRAM.

But it's only dangerous to pull the stick during writes. Those only occur within a split second after a host write to the emulated floppy drive, or immediately after selecting a new image (FlashFloppy remembers last-selected image by saving that to the USB stick). So you can pretty much pull the stick when you like, no problems.

[Photon]

HxC selector does the job, probably just some prepare work PC side (A-Z folders) would make it as efficient as most people would want I guess. Having a slick picture selector would probably not work as you'd have to do it Amiga side with only floppy loading available? Maybe some design and a good font, and replacing _ with space and remove the suffix to clean up the file names a little could make it look better.

If the selector is open source it would be best to update/fork the project.

Thx for answers, I have no real questions anymore because it's all set up and working

[wiz12]

I'm just after testing Indiana Jones and the Fate of Atlantis and autoswap doesn't seem to be working correctly for me. The game still asks me to insert a disk, even after clicking the left mouse button. I found that it works if I eject the disk and reinsert the same disk again. Is there some setting in the config file I need to adjust?

[Keir]

Originally Posted by Photon

HxC selector does the job, probably just some prepare work PC side (A-Z folders) would make it as efficient as most people would want I guess. Having a slick picture selector would probably not work as you'd have to do it Amiga side with only floppy loading available?

The selector can direct-access the whole USB stick so it isn't limited to assets that fit in a single disk image. It is limited to floppy data rate though, but I'm not sure that's too terrible.

[Keir]

Originally Posted by wiz12

I'm just after testing Indiana Jones and the Fate of Atlantis and autoswap doesn't seem to be working correctly for me. The game still asks me to insert a disk, even after clicking the left mouse button. I found that it works if I eject the disk and reinsert the same disk again. Is there some setting in the config file I need to adjust?

What Kickstart version? I had a report that 3.1.4 isn't working well...

Can you try other Kickstart versions?

[lesta_smsc]

Thank you for this release! I was playing MK1 only last week and could not believe how often I had to do a disk swap! lol this would have been perfect! Does it still prompt for disk swap or is this 'hard coded out'?

You mentioned "Approx 2x faster load times" in readme. Is this due to eliminating disk swap or due to faster disk read speed (e.g. like how you can set to 800% on WinUAE)? If it is the former, is there anyway to 'speed up' the read speed on disks so that it works as quick as HDD?

The OLED update, how does make use of this or will it automatically configure to have the narrower display?

[wiz12]

Originally Posted by kaffer

What Kickstart version? I had a report that 3.1.4 isn't working well...

Can you try other Kickstart versions?

Yes, I'm using Kickstart 3.1.4. I could test it with 3.x or 3.1.

[Keir]

Originally Posted by wiz12

Yes, I'm using Kickstart 3.1.4. I could test it with 3.x or 3.1.

That would be interesting if convenient. I did not have 3.1.4 available when I was testing AutoSwap, but I happen to have it on my latest rom multi-switcher on my test board now, so I should be able to repro this and fix in the next week.

[Keir]

Originally Posted by lesta_smsc

Thank you for this release! I was playing MK1 only last week and could not believe how often I had to do a disk swap! lol this would have been perfect! Does it still prompt for disk swap or is this 'hard coded out'?

Hard coded out.

You mentioned "Approx 2x faster load times" in readme. Is this due to eliminating disk swap or due to faster disk read speed (e.g. like how you can set to 800% on WinUAE)?

It's due to tweaks to the track loader which the original cracker (Nomad/Fairlight) used, and also cache the disk-id/file-table sector in memory.

If it is the former, is there anyway to 'speed up' the read speed on disks so that it works as quick as HDD?

Still fundamentally limited by the data rate of the floppy interface, it will never be as quick as HDD.

The OLED update, how does make use of this or will it automatically configure to have the narrower display?

I don't know what you mean here.

[wiz12]

Originally Posted by kaffer

That would be interesting if convenient. I did not have 3.1.4 available when I was testing AutoSwap, but I happen to have it on my latest rom multi-switcher on my test board now, so I should be able to repro this and fix in the next week.

Just tested it with Kickstart 3.1 roms and it's working fine. Do you have any idea why would 3.1.4 would be causing this weird issue?

[lesta_smsc]

Originally Posted by kaffer

Hard coded out.

Excellent!

It's due to tweaks to the track loader which the original cracker (Nomad/Fairlight) used, and also cache the disk-id/file-table sector in memory.

Interesting

Still fundamentally limited by the data rate of the floppy interface, it will never be as quick as HDD.

Ah... there was me thinking it could be overridden through software tweaks on the Gotek FW side.

I don't know what you mean here.

Nevermind, I just read the FF.CFG on GitHub and now know what you meant by this. Very nice how the smaller font looks more appealing to the eyes as per the following image taken from http://torlus.com/floppy/forum/viewt...3072&start=60:



Is there any improvements or changes when using the larger OLED of 128x64? If I recall, there was an issue with colours being split midway, but it would be nice if the disk name was one colour and the track identification of a different colour (including if this option was available on the smaller 128x32

[Keir]

Originally Posted by lesta_smsc

Is there any improvements or changes when using the larger OLED of 128x64? If I recall, there was an issue with colours being split midway, but it would be nice if the disk name was one colour and the track identification of a different colour (including if this option was available on the smaller 128x32

The supported OLED displays are monochrome. The displays with a colour split have a multi-colour filter/overlay, so just don't buy those ones.

At the moment 128x64 just gets you larger characters, it's still two rows with the same info as on 128x32. But some people like that it's more readable, and it does fit vertically in the Gotek case's display cutout.

[Keir]

Originally Posted by wiz12

Just tested it with Kickstart 3.1 roms and it's working fine. Do you have any idea why would 3.1.4 would be causing this weird issue?

No it's supposed to be a bug *fix* release.

Seriously, the bug is almost certainly mine. I will investigate this week and see what's up.

[Keir]

Originally Posted by wiz12

Just tested it with Kickstart 3.1 roms and it's working fine. Do you have any idea why would 3.1.4 would be causing this weird issue?

Fixed now, it seems that disk changes weren't always being detected. Possibly the disk swap was too quick. Adding an extra ACTION_FLUSH message to the DOS handler seems to have helped.

However, I still have problems with Indiana Jones, and also Monkey 2, on Kickstart v3. The mouse pointer is offset vertically, like the mouse is too high, or the screen is too low. So button presses require the mouse positioned above the button. I don't know why this is -- it doesn't happen with Kickstart v1 or v2 in my tests.

For now I have release-noted it as a potential issue on those two titles. Safest bet on all the old SCUMM games is to use Kickstart 1.3 if possible.

[wiz12]

Originally Posted by kaffer

Fixed now, it seems that disk changes weren't always being detected. Possibly the disk swap was too quick. Adding an extra ACTION_FLUSH message to the DOS handler seems to have helped.

However, I still have problems with Indiana Jones, and also Monkey 2, on Kickstart v3. The mouse pointer is offset vertically, like the mouse is too high, or the screen is too low. So button presses require the mouse positioned above the button. I don't know why this is -- it doesn't happen with Kickstart v1 or v2 in my tests.

For now I have release-noted it as a potential issue on those two titles. Safest bet on all the old SCUMM games is to use Kickstart 1.3 if possible.

Nice work. With the disk change problem, it wasn't detecting a correctly numbered and inserted disk at times though sometimes it would. Inserting any disk even the one it wasn't looking for would make the autoswap work again for some reason. Will test the new fix when it's released.

Regarding the mouse pointer, that's one annoying thing I've noticed too but thought it was maybe down to my mouse. I think it has this issue under Kickstart 3.1 also.

[Keir]

Originally Posted by wiz12

Nice work. With the disk change problem, it wasn't detecting a correctly numbered and inserted disk at times though sometimes it would. Inserting any disk even the one it wasn't looking for would make the autoswap work again for some reason. Will test the new fix when it's released.

It is released already. Download the new v1.4 zip file.

Regarding the mouse pointer, that's one annoying thing I've noticed too but thought it was maybe down to my mouse. I think it has this issue under Kickstart 3.1 also.

Yes it is under 3.1 too. It is not related to AutoSwap, the unpatched game would also have this issue. Maybe sometime I will find a fix.

[DamienD]

Originally Posted by kaffer

However, I still have problems with Indiana Jones, and also Monkey 2, on Kickstart v3. The mouse pointer is offset vertically, like the mouse is too high, or the screen is too low. So button presses require the mouse positioned above the button. I don't know why this is -- it doesn't happen with Kickstart v1 or v2 in my tests.

Originally Posted by wiz12

Regarding the mouse pointer, that's one annoying thing I've noticed too but thought it was maybe down to my mouse. I think it has this issue under Kickstart 3.1 also.

Re: Indy; there is a thread and posts about this exact issue; too lazy to search.

Unfortunately there is no solution though, if using KS v3.x...

Haven't seen it with Monkey Island 2 though...

[Keir]

Originally Posted by DamienD

Re: Indy; there is a thread and posts about this exact issue; too lazy to search.

I found some which suggested it's a PAL/NTSC issue. But I am using EU retail disk images from SPS. So I'm not totally convinced. Anyway as you say no real solution was forthcoming.

Unfortunately there is no solution though, if using KS v3.x...

Nope. Need a kickstart switcher or if enough RAM then relokick into 1.3.

Haven't seen it with Monkey Island 2 though...

It's definitely there (KIXX release).

[DamienD]

Originally Posted by kaffer

It's definitely there (KIXX release).

Just tested with this set and the issue isn't there: Monkey Island 2 - LeChuck's Revenge v1.0 (1992-04-08)(LucasArts - U.S. Gold)[cr Conet]

Probably not a crack of the KIXX release though...

It's quite obvious with Indy 4, for example if you press <F5> and try to select the "Save" button you need to be above and left.

[Keir]

Originally Posted by DamienD

Just tested with this set and the issue isn't there: Monkey Island 2 - LeChuck's Revenge v1.0 (1992-04-08)(LucasArts - U.S. Gold)[cr Conet]

Probably not a crack of the KIXX release though...

Maybe it is a PAL/NTSC thing. The KIXX release you have to be offset the mouse cursor even at the "Monkey Island 2"/"Monkey 2 Lite" selection screen, but that screen is full-height (256px) purple. The crack has the mouse working correctly, but a much shorter height of purple (200px? possibly less) and with an ugly half scanline purple/black. I didn't bother checking further, they do seem to be different builds of the main game executable.