1
0
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:
Thomas Harte 2023-01-21 23:04:48 -05:00
parent a5765abbad
commit b7d80f5ed1
2 changed files with 42 additions and 8 deletions

View File

@ -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):

View File

@ -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;
}