32-bit data bus support

[mras0]

From dirkwhoffmann/vAmiga#730 some thoughts:

With 020+ and MMU support coming along/planned it might be a good idea to add support for proper 32-bit bus operations sooner rather than later. If I'm reading the source code correctly things are nicely prepared to support it, but all 32-bit accesses are split up into two 16-bit ones.

At the very latest, I think you'll have issues with (long)word accesses straddling protection boundaries, but I guess already with a (non-EC) 020 word access to $00ffffff you might notice a difference. Without having a complete overview, I'm guessing the "Memory" abstraction needs to be the one making the decision of whether to split up the access. Maybe it also needs to provide feedback on the access time for (more) exact emulation (at a much later point).

If/when making such changes it might be worthwhile to also consider how caches can/will be implemented. Not that I see any particular problems with the current implementation, just something to keep in mind (i.e. if 16-bit accessible chip mem is cached, you want a longword read to be read from the cache in one go, etc.)

[dirkwhoffmann]

If I'm reading the source code correctly things are nicely prepared to support it, but all 32-bit accesses are split up into two 16-bit ones.

Yes, the current code hard-codes what the 68000 is doing. If I remember correctly, the 68020+ has two external pins for controlling the data bus width. Depending on the values on these pins, a 32-bit access is either performed as one 32-bit operation (requires a 32-bit data bus of course), two 16-bit operations, or four 8-bit operations. On my real machine, the 68030 must be forced to operate in 16-bit mode. Otherwise, it couldn't utilize the Amiga data bus.

[mras0]

If I'm reading the source code correctly things are nicely prepared to support it, but all 32-bit accesses are split up into two 16-bit ones.

Yes, the current code hard-codes what the 68000 is doing. If I remember correctly, the 68020+ has two external pins for controlling the data bus width. Depending on the values on these pins, a 32-bit access is either performed as one 32-bit operation (requires a 32-bit data bus of course), two 16-bit operations, or four 8-bit operations. On my real machine, the 68030 must be forced to operate in 16-bit mode. Otherwise, it couldn't utilize the Amiga data bus.

If I'm reading the manuals correctly about "Dynamic Bus Sizing" (MC68020UM §5.2.1/MC68030UM §7.2.1) you remember right. External devices can provide feedback on the buswidth (16 bits for the A500) via /DSACK{1-0}. I'm guessing that's performed by some glue logic on the board and fast RAM access is still 32-bit (or maybe that's what differentiates the TF534 from the TF536 (Z2 vs. Z3)? On wikipedia I can see that the "A2500" did ship with 32-bit RAM.

Either way, this and the other "issue" were mostly meant to have a place to add comments (while they were present in my mind) for more longer term concerns that didn't fit in the vAmiga EC030 thread. As usual feel free to disregard/close at your own convenience.