mirror of
https://github.com/TomHarte/CLK.git
synced 2025-08-15 14:27:29 +00:00
Copy in some notes, expand line buffer.
This commit is contained in:
@@ -67,7 +67,12 @@ enum class MemoryAccess {
|
|||||||
};
|
};
|
||||||
|
|
||||||
// Temporary buffers collect a representation of each line prior to pixel serialisation.
|
// 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 {
|
struct LineBuffer {
|
||||||
|
LineBuffer() {}
|
||||||
|
|
||||||
// The line mode describes the proper timing diagram for this line.
|
// The line mode describes the proper timing diagram for this line.
|
||||||
LineMode line_mode = LineMode::Text;
|
LineMode line_mode = LineMode::Text;
|
||||||
|
|
||||||
@@ -77,6 +82,10 @@ struct LineBuffer {
|
|||||||
|
|
||||||
// The names array holds pattern names, as an offset into memory, and
|
// The names array holds pattern names, as an offset into memory, and
|
||||||
// potentially flags also.
|
// 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 {
|
struct {
|
||||||
size_t offset = 0;
|
size_t offset = 0;
|
||||||
uint8_t flags = 0;
|
uint8_t flags = 0;
|
||||||
@@ -86,6 +95,12 @@ struct LineBuffer {
|
|||||||
// Four bytes per pattern is the maximum required by any
|
// Four bytes per pattern is the maximum required by any
|
||||||
// currently-implemented VDP.
|
// currently-implemented VDP.
|
||||||
uint8_t patterns[40][4];
|
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):
|
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 <Personality personality>
|
||||||
template<bool use_end, bool fetch_sprites> void Base<personality>::fetch_yamaha(int start, int end) {
|
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)start;
|
||||||
(void)end;
|
(void)end;
|
||||||
}
|
}
|
||||||
|
Reference in New Issue
Block a user