Thomas Harte
|
c2a7dffa7d
|
Converted the ZX80/81 video component into a ClockReceiver. As it happens, it's most convenient to take the half-cycle bus here.
|
2017-07-22 23:02:28 -04:00 |
|
Thomas Harte
|
ed28260aaf
|
Hardens the ZX80/81 video routines to ensure they never try to push data into the future and don't double-count time when pixels would ostensibly run into sync. You could previously see the CRT being handed negative run lengths if sync interrupted pixels or if a run of more than 320 pixels (my arbitrary buffer size) occurred, with corresponding poor behaviour given my use of unsigned numbers.
|
2017-07-09 19:33:05 -04:00 |
|
Thomas Harte
|
30e93979d2
|
Removed data work if sync is enabled; in that case no data is output.
|
2017-07-08 21:01:07 -04:00 |
|
Thomas Harte
|
b9dbb6bcf8
|
Discovered my timing error: the I/R <-> A loads should take an extra cycle. This means the ZX80 now finally takes the correct 207 cycles per line. Fixed the video output wave to be clocked at the appropriate rate.
|
2017-06-12 18:55:04 -04:00 |
|
Thomas Harte
|
ba5f34f827
|
Narrowed view to the centre 80% of a frame.
|
2017-06-11 17:24:32 -04:00 |
|
Thomas Harte
|
d910a4fd38
|
Adjusted to signal an interrupt during the refresh cycle rather than weirdly just afterwards. Which cuts video timing down by 4 cycles a line. There still might be a problem here somewhere though, as I'm getting 206 cycles/line and the internet states it should be 207.
Also: lots of printfs have grown temporarily as I try to figure out what I'm doing so wrong as to break loading.
|
2017-06-11 13:32:20 -04:00 |
|
Thomas Harte
|
e3ee9604a5
|
Added comments.
|
2017-06-06 18:01:33 -04:00 |
|
Thomas Harte
|
8c66e1d99d
|
Factored out ZX80/81 video and rejigged to ensure it will keep ticking over irrespective of whether the machine is supplying data.
|
2017-06-06 17:53:23 -04:00 |
|