Fix floppy access when overclocking is enabled

[beholdnec]

This PR makes the SWIM/IWM component run at native speed regardless of overclocking, fixing floppy access when overclocking is enabled.

[twvd]

I also noticed that in any overclocking setup on the compact Macs, the floppy icon with the question mark flashes too quickly. This is timed by VIA T2 afaik. Note that they import DEFAULT_BUS_SPEED from MacII bus, which, of course, is incorrect.

I also don't like the use of 16 MHz in terminology; there's Macs with many different clock speeds which makes it factually incorrect in the context of e.g. the VIA.

I'm starting to wonder if a different approach may work better here: skipping bus.tick() from within the CPU itself. E.g. if the base speed is 8 MHz and you want to overclock to 32, only call bus.tick() every 4 CPU cycles. This will cause issues with wait states, though. To be accurate, I think wait states should then also be stretched. So 4 wait state cycles at 8 MHz become 16 at 32 MHz. This can also be achieved using the same mechanism (the CPU will just spinlock longer on BusResult::WaitState until bus.tick() is called again).
This will have a diminishing returns on higher clock speeds but I think it is as accurate as overclocking can be while retaining system accuracy (as far as that's possible; there are also apps that use hot loops to time the IWM which will of course still break).

[beholdnec]

• when I run the bus at 16mhz regardless of overclock, it does NOT fix floppies.
• when I run all bus components at overclock frequency, it DOES fix floppies, but obviously causes other timing issues.

Does Mac OS itself use hot loops to time IWM?

[twvd]

Yes, seems it does:

                      P_Sony_RdAddr:
18C22  7603                      MoveQ.L   #$3, D3
18C24  747F                      MoveQ.L   #$7F, D2
18C26  7A00                      MoveQ.L   #$0, D5
18C28  287C 00DF F9FF            Move.L    #$DFF9FF, A4    ; address for Q6L @sc
18C2E  21DF 0124                 Move.L    (A7)+, (DskRtnAdr)
18C32  4A15           L4629:     Tst.B     (A5)
18C34  6B02                      BMI.B     L4630
18C36  1F16                      Move.B    (A6), -(A7)     ; push SCC Channel A data on stack if waitRq is zero @sc
18C38  1A14           L4630:     Move.B    (A4), D5        ; get a disk byte @sc
18C3A  51CA 0008                 DBF       D2, L4631
18C3E  70BE                      MoveQ.L   #$-42, D0       ; error -66, no nybble error, disk is probably blank @sc
18C40  6000 008A                 Bra       L4644
18C44  6AEC           L4631:     BPL.B     L4629           ; if it's not a valid disk byte, keep trying @sc

[beholdnec]

Do you think it would help to insert a CPU delay on accesses to DFF9FF? Or am I misreading the code?

[beholdnec]

I inserted a bus-wait delay on accesses to IWM/SWIM registers. This seems to fix floppy access for overclocked macii and compact. Portable still fails.
I'm delaying for 8 ticks, but in theory it should work with only 1 tick. Delaying for 1 tick makes it fail, however.

[beholdnec]

I fixed floppy booting for all of macii, compact and portable when overclocked. I wrote code to detect accesses to the IWM/SWIM registers and force them to run at 16MHz by inserting wait states. However, I'm not sure why I need to delay by 8 16MHz ticks instead of just 1 - there might be something conceptually wrong with this approach. As a result, floppy access is slower than it should be.

[beholdnec]

I implemented a new throttling method.
I've measured the hot loop and found that IWM regs are accessed at 9-tick intervals. Therefore, if IWM accesses are throttled to 9 ticks apart, it seems to fix floppy access for all machines. 9 seems to be the minimum - if I set it to 8, it fails.

I'm turning off draft mode, please take a look!