Some facts about the mysterious
arbitration logic inside the Rainbow...
Quote: reliable floppy operation is not possible 'if both CPUs operate outside of shared memory'.View from Z80:
- private RAM (2 K static RAM) can be accessed at any time without any wait states
- 62 K shared RAM considered 'busy' when an 8088 cycle or a refresh cycle is in progress
- an arbitration logic ensures that refresh has highest priority. Z80 has equal priority to 8088 except in cases where both access shared memory (Z80 wins).
- if shared RAM is 'busy' at the time of Z80 access, the Z80 will execute wait states until the RAM is free
- extra +1 wait cycle on machine one (M1) cycles when accessing shared memory. WAIT is also used When the RX50 board decides it needs additional time.
In any case, the Z80A is held in a wait state no longer than ~ 2 us.
References: Technical Manual 3.3.1 (page 72); 4-17 (page 115; fig.4-10) ; 4-22 (4.4.5.1) page 120.
In the light of the
deadlocks observed - will it be necessary to emulate all this?
P.S.: the READ ID fix Curt did for Osborne had no (apparent) impact on 'rainbow.c' - so i'll submit my patch - minus the keyboard workaround - to version control and hope for the best.
Currently, 'READ_ID_BLOCK_TO_DMA' and 'READ_ID_BLOCK_TO_DMA_BYTE' fail on the Rainbow with CPM 2.x (CPM 1 and DOS 3 boot, other issues with DOS 2.x remain).
