mirror of
https://github.com/TomHarte/CLK.git
synced 2024-11-26 23:52:26 +00:00
Copy in some notes, expand line buffer.
This commit is contained in:
parent
a5765abbad
commit
b7d80f5ed1
@ -67,7 +67,12 @@ enum class MemoryAccess {
|
||||
};
|
||||
|
||||
// Temporary buffers collect a representation of each line prior to pixel serialisation.
|
||||
//
|
||||
// TODO: either template on personality, to avoid having to be the union of all potential footprints,
|
||||
// or just stop keeping so many of these in the 9918.
|
||||
struct LineBuffer {
|
||||
LineBuffer() {}
|
||||
|
||||
// The line mode describes the proper timing diagram for this line.
|
||||
LineMode line_mode = LineMode::Text;
|
||||
|
||||
@ -77,6 +82,10 @@ struct LineBuffer {
|
||||
|
||||
// The names array holds pattern names, as an offset into memory, and
|
||||
// potentially flags also.
|
||||
union {
|
||||
// The TMS and Sega VDPs are close enough to always tile-based;
|
||||
// this struct captures maximal potential detail there.
|
||||
struct {
|
||||
struct {
|
||||
size_t offset = 0;
|
||||
uint8_t flags = 0;
|
||||
@ -86,6 +95,12 @@ struct LineBuffer {
|
||||
// Four bytes per pattern is the maximum required by any
|
||||
// currently-implemented VDP.
|
||||
uint8_t patterns[40][4];
|
||||
};
|
||||
|
||||
// The Yamaha VDP also has a variety of bitmap modes, the widest of which is
|
||||
// 512px @ 4bpp.
|
||||
uint8_t bitmap[256];
|
||||
};
|
||||
|
||||
/*
|
||||
Horizontal layout (on a 342-cycle clock):
|
||||
|
@ -480,6 +480,25 @@ template<bool use_end> void Base<personality>::fetch_yamaha_refresh(int start, i
|
||||
|
||||
template <Personality personality>
|
||||
template<bool use_end, bool fetch_sprites> void Base<personality>::fetch_yamaha(int start, int end) {
|
||||
/*
|
||||
Per http://map.grauw.nl/articles/vdp-vram-timing/vdp-timing.html :
|
||||
|
||||
The major change compared to the previous mode is that now the VDP needs to fetch extra data
|
||||
for the bitmap rendering. These fetches happen in 32 blocks of 4 bytes (screen 5/6) or
|
||||
8 bytes (screen 7/8). The fetches within one block happen in burst mode. This means that
|
||||
one block takes 18 cycles (screen 5/6) or 20 cycles (screen 7/8). Though later we'll see
|
||||
that the two spare cycles for screen 5/6 are not used for anything else, so for simplicity
|
||||
we can say that in all bitmap modes a bitmap-fetch-block takes 20 cycles. This is even
|
||||
clearer if you look at the RAS signal: this signal follows the exact same pattern in all
|
||||
(bitmap) screen modes, so in screen 5/6 it remains active for two cycles longer than
|
||||
strictly necessary.
|
||||
|
||||
Actually before these 32 blocks there's one extra dummy block. This block has the same timing
|
||||
as the other blocks, but it always reads address 0x1FFFF. From an emulator point of view,
|
||||
these dummy reads don't matter, it only matters that at those moments no other VRAM accesses
|
||||
can occur.
|
||||
*/
|
||||
|
||||
(void)start;
|
||||
(void)end;
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user