exxos's Atari, Amiga & retro forum

dml wrote: 04 Aug 2026 15:58 Interesting - does that still work out to be safe given the port has 3 sequentially written port bytes? The FIFO transfer is triggered on the low byte so it is important that the other two bytes are written first (but in any order - so long as the low byte is last). If there is a single store buffer then it will always be safe. If it is multiword & unordered, it could transfer the wrong upper-bytes on each low-byte transfer. Worse - the transfer would appear to have worked because the correct number of transfers take place, just not with the correct data sometimes.

I'm probably borrowing trouble here and you figured this already - otherwise it looks very nice :)

The storebuffer is, as far as I understand from the manual, an ordered FIFO of 4 entries, and although the actual writes happen asynchronously they are always in the order you wrote them from the cpu.
Any read or write to any uncached-precise page will flushes the storebuffer so if you need to read some status flag, or just flush and stall for the storebuffer to finish, you'll want to use the regular precise page.

Data validity has so far only been tested by using the method in dsp_ExecProg and seeing that the uploaded program works as expected, so more testing should happen for sure.


And now I'm wondering if I can take advantage of this type of thing for other stuff too..
Writes to gfxcard VRAM perhaps.

agranlund wrote: 04 Aug 2026 16:13 The storebuffer is, as far as I understand from the manual, an ordered FIFO of 4 longwords, and although the actual writes happen asynchronously they are always in the order you wrote them from the cpu.

Ok my question is fully answered there :) an ordered fifo. Not a detail I remember, if I even did absorb it (I did not do much on 060 except fix some broken things TBH).

All looking very nice and pretty much absorbs any overhead from address stride on those 3 bytes.