What is the floating bus?
Ramsoft describes it in detail here, but in short it means that when the Z80 reads from an unattached port like 0xFF, the ULA returns the value 0xFF unless it is currently delivering data to the display, in which case this data is returned instead. When I first read about the floating bus, I found the task of emulating the effect a bit daunting, and not really worth the effort (only a few games use the effect). However, after I managed to time the Z80 execution to a virtual electron beam I decided to give the floating bus a shot. How to simulate the effect? The ULA fetches display data in repeated 8 T-state cycles. In these cycles, the first T-state is spent to collect a bitmap byte, the second T-State is spent to collect the corresponding attribute byte. Then the ULA moves on to collect the bitmap and attribute bytes for the next screen column. After this it waits 4 T-states until it repeats the cycle. The key to simulating this is then to have the Z80 timing in perfect order and to know if and where the ULA fetches screen data at the exact moment an unattached in port is read from. I already had the Z80 timing working, and the Sinclair FAQ Wiki describes which display position is read at which processor cycle, so what I had to do was to include the current T-state when the Z80 calls the In port. If the port in question is unattached, the following steps are performed:
It took some time to get this working, but I was rewarded by a very smooth-playing Sidewize (below). A game that uses the floating bus effect to ensure that the screen is updated after the CRT has traversed the game area. The author Steve Wetherill describes how he did this in a very interesting blog post.
0 Comments
Leave a Reply. |
Archives
November 2020
Categories
All
|