-
Notifications
You must be signed in to change notification settings - Fork 0
Progress
The timing outputs are generally working though use of dividing counters. I have a feeling I need to correct the horizontal bit counters (H1, H2 SH2 et al) so that H1 remains low for the first clock cycle (I think it currently goes high on as soon as the 6M clock goes high).
In order to make better use of hardware clock functionality (e.g. Spartan 6 global clock lines) I will look at ensuring the CUS27 implementation is defined in the top-level module and the relevant signals passed into the more generic modules. This way a Spartan 6 specific implementation of CUS27 can be implemented if/when required. At the moment because of the relatively low operating frequency the generic implementation should theoretically suffice for now)
So after much time trying work out how this chip would work in a single layer scenario I was able to produce a scrolling simulation of a single layer of the start of the first level. The screen was generated to a format that I could import into the VGA Simulator by Eric Eastwood. The result was a colour correct image with a mostly correct bitplane representation of the level background (TODO: Upload image).
As I have been only working with a single layer I have plenty of time to synchronise the tilemap address generation with the horizontal scroll offset. My next task was to multiple tilemap address generation for two layers...
From looking at the schematics and the video module of the MAME implementation, there appears to be multiplexing of the two layers using the S2H clock signal - this means that I have two pixels to perform processing for the first layer followed by two pixels on the second layer. This cycle repeats once more before the output for full 8 pixel tile should have been generated. Within these 8 pixels I need to perform, for each layer, 2 RAM lookups from the tilemap in VRAM (tile code and attributes) and generate 2 ROM addresses (once for the first nibble of the tile's bitplanes and again for the second nibble); both nibles shared the same tile code and color attribute information taken from the associated RAM lookup.
I have drawn up various timing diagrams and implemented various prototypes to meet the requirements of the layer multiplexing but so far have not made much progress. The best so far results seem to break down as soon as the scroll offset changes :(
The implementation of this is really hanging off the progress of CUS42. Currently it is hacked to get an output based on the current CUS42 single layer implementation.