RIOT limitations and workarounds - Revision history

MSaarna: /* Making RIOT timer and RAM operations more reliable */

2023-02-21T02:18:04Z

‎Making RIOT timer and RAM operations more reliable

MSaarna: /* Making RIOT timer and RAM operations more reliable */

2023-02-21T02:15:25Z

‎Making RIOT timer and RAM operations more reliable

MSaarna at 22:18, 28 August 2020

2020-08-28T22:18:53Z

MSaarna at 02:36, 24 August 2020

2020-08-24T02:36:28Z

MSaarna at 18:36, 10 August 2020

2020-08-10T18:36:02Z

MSaarna at 18:35, 10 August 2020

2020-08-10T18:35:04Z

MSaarna at 23:33, 9 August 2020

2020-08-09T23:33:55Z

MSaarna at 23:33, 9 August 2020

2020-08-09T23:33:37Z

MSaarna: /* Making RIOT RAM and timer operations more reliable */

2020-08-09T19:17:28Z

‎Making RIOT RAM and timer operations more reliable

MSaarna: /* Making RIOT RAM and timer operations reliable */

2020-08-09T19:02:09Z

‎Making RIOT RAM and timer operations reliable

@@ Line 32: / Line 32: @@
      sta TIM64T
      lda INTIM
-     cmp #9 ; should always be the value you stored, less 1.
+     cmp #9 ; immediately reading the value returns what you stored, less 1.
      bne Repeat64T

@@ Line 28: / Line 28: @@
 The easiest way to make the RIOT timer writes reliable in 7800 mode (without having to turn off DMA) is to double-check the value you've just tried to write, and repeat it if required...
      lda #10
      sta TIM64T
      lda INTIM
@@ Line 38: / Line 38: @@
 In theory you could take the same approach with RIOT RAM reads and writes, but in practise checking the consistency of reads and writes isn't tenable. If you wish to use RIOT RAM, it should probably be kept to periods of VBLANK, or when DMA is disabled.
 ==Authorship==
 RIOT Limitations and Workarounds was written by Mike Saarna (aka RevEng) as original content for 7800.8bitdev.org.

@@ Line 3: / Line 3: @@
 <blockquote>This chip is used only for I/O in 7800 mode, whereas in 2600 mode it also supplies access to all RAM and timers.</blockquote>
-...without a lot of technical explanation as to why this is. In fact, if you test this RIOT functionality, at first it would seem to be working just fine. However the longer you test with real world examples, you would would discover that the RIOT RAM and timers are indeed sometimes unreliable.
+...without a lot of technical explanation as to why this is. In fact, if you test this RIOT functionality, at first it would seem to be working just fine. However the longer you test with real world examples, you would would discover that the RIOT timers and RAM are indeed sometimes unreliable.
 The Memory Map appendix of the Software Guide goes into a little more detail, blaming the RIOT RAM reliability issue on speed differences. While this may be true for access at Maria speeds, at 6502 speeds this explanation isn't the whole story.
-==Why RIOT RAM and timers are unreliable in 7800 mode==
+==Why RIOT timers and RAM are unreliable in 7800 mode==
-There's are two main reasons why accessing RIOT RAM and timers is unreliable - DMA, and Maria's own logic failings.
+There's are two main reasons why accessing RIOT timers and RAM is unreliable - DMA, and Maria's own logic failings.
 ===DMA===
@@ Line 18: / Line 18: @@
 This may manifest differently on different consoles, with some consoles being seemly immune to the issue, likely due to rate of transition (hang-time) of the relevant lines when the 6502 is halted.
-The heavier the DMA is while you attempt to write to RIOT RAM or timers, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off. In fact, the 7800 BIOS actually turns off DMA and uses RIOT RAM to boot into 2600 mode.
+The heavier the DMA is while you attempt to access RIOT timers or RAM, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off. In fact, the 7800 BIOS actually turns off DMA and uses RIOT RAM to boot into 2600 mode.
 ===Logic Problems===
@@ Line 24: / Line 24: @@
 When the 6502 accesses TIA or RIOT addresses, Maria is responsible for slowing down the clock it feeds to these chips, as well as managing the chip enable and write enable lines. It seems to do a great job keeping track of the timing required for regular 6502 access modes - Absolute, Absolute Indexed, Indirect Indexed - but Maria's internal counters that manage the timings of the various lines go completely haywire when you try to execute code out of RIOT RAM.
-==Making RIOT RAM and timer operations more reliable==
+==Making RIOT timer and RAM operations more reliable==
 The easiest way to make the RIOT timer writes reliable in 7800 mode (without having to turn off DMA) is to double-check the value you've just tried to write, and repeat it if required...

@@ Line 5: / Line 5: @@
 ...without a lot of technical explanation as to why this is. In fact, if you test this RIOT functionality, at first it would seem to be working just fine. However the longer you test with real world examples, you would would discover that the RIOT RAM and timers are indeed sometimes unreliable.
-The Memory Map appendix of the Software Guide goes into a little more detail, blaming the RIOT RAM reliability issue on speed differences. While this may be true for access at Maria speeds, at 6502 speeds this explanation seems to be fiction.
+The Memory Map appendix of the Software Guide goes into a little more detail, blaming the RIOT RAM reliability issue on speed differences. While this may be true for access at Maria speeds, at 6502 speeds this explanation isn't the whole story.
 ==Why RIOT RAM and timers are unreliable in 7800 mode==
-In a word, the reason why writing to the RIOT RAM and timers are unreliable, is DMA. When Maria halts the 6502 for DMA, it doesn't have a corresponding halt line for the RIOT chip, so RIOT continues to run while the 6502 is halted. If the halt begins in the middle of a RIOT update, the address and write enable asserted by the 6502 will disappear on RIOT mid-operation.
+There's are two main reasons why accessing RIOT RAM and timers is unreliable - DMA, and Maria's own logic failings.
 This may manifest differently on different consoles, with some consoles being seemly immune to the issue, likely due to rate of transition (hang-time) of the relevant lines when the 6502 is halted.
-The heavier the DMA is while you attempt to write to RIOT RAM or timers, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off.
+The heavier the DMA is while you attempt to write to RIOT RAM or timers, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off. In fact, the 7800 BIOS actually turns off DMA and uses RIOT RAM to boot into 2600 mode.
 ==Making RIOT RAM and timer operations more reliable==
-The easiest way to make the RIOT timer writes reliable in 7800 mode (without having to turn off the display) is to double-check the value you've just tried to write, and repeat it if required...
+The easiest way to make the RIOT timer writes reliable in 7800 mode (without having to turn off DMA) is to double-check the value you've just tried to write, and repeat it if required...
      lda #10
@@ Line 28: / Line 35: @@
      bne Repeat64T
-If you're checking INTIM during the visible screen, it should also be noted that DMA may make it difficult to catch the exact moment when 0 is reached, because the timer will switch to single-cycle resolution at the time. In this case you can either work with an offset value (e.g. add 10 to the timer value you want when setting the timer, and then act accordingly when INTIM is at 10 or less.) or you can use the RIOT interrupts, and rely on TIMINT instead of INTIM.
+If you're checking INTIM during the visible screen, it should also be noted that DMA may make it difficult to catch the exact moment when 0 is reached, because the timer will switch to single-cycle resolution at the time. In this case you can either work with an offset value (e.g. add 10 to the timer value you want when setting the timer, and then act accordingly when INTIM is at 10 or less.) or you can use the RIOT interrupts, and just check TIMINT instead of INTIM.
-...provided you're happy with jumping through these hoops for 128 bytes. RIOT RAM usage is far less tested at this point than the timers, so you may well encounter other previously undiscovered issues.
+In theory you could take the same approach with RIOT RAM reads and writes, but in practise checking the consistency of reads and writes isn't tenable. If you wish to use RIOT RAM, it should probably be kept to periods of VBLANK, or when DMA is disabled.

← Older revision		Revision as of 18:36, 10 August 2020
Line 38:		Line 38:
	bne WriteLoop		bne WriteLoop

−	...provided you're happy with jumping through these hoops for 128 bytes. RIOT RAM usage is far less tested at this point than the timers, so you may well encounter other previously undiscovered issues.	+	...provided you're happy with jumping through these hoops for 128 bytes. RIOT RAM usage is far less tested at this point than the timers, so you may well encounter other previously undiscovered issues.

← Older revision		Revision as of 18:35, 10 August 2020
Line 5:		Line 5:
	...without a lot of technical explanation as to why this is. In fact, if you test this RIOT functionality, at first it would seem to be working just fine. However the longer you test with real world examples, you would would discover that the RIOT RAM and timers are indeed sometimes unreliable.		...without a lot of technical explanation as to why this is. In fact, if you test this RIOT functionality, at first it would seem to be working just fine. However the longer you test with real world examples, you would would discover that the RIOT RAM and timers are indeed sometimes unreliable.

−	The Memory Map appendix of the Software Guide goes into a little more detail, blaming the RIOT RAM reliability issue on speed differences. While this may be true for access at Maria speeds, ~~otherwise~~ this ~~story~~ seems to be fiction.	+	The Memory Map appendix of the Software Guide goes into a little more detail, blaming the RIOT RAM reliability issue on speed differences. While this may be true for access at Maria speeds, at 6502 speeds this explanation seems to be fiction.

← Older revision		Revision as of 23:33, 9 August 2020
Line 15:		Line 15:

	The heavier the DMA is while you attempt to write to RIOT RAM or timers, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off.		The heavier the DMA is while you attempt to write to RIOT RAM or timers, the more likely it is that you'll run into issues. Conversely, the reliability issues go away if Maria has DMA turned off.
		+

	==Making RIOT RAM and timer operations more reliable==		==Making RIOT RAM and timer operations more reliable==

@@ Line 27: / Line 27: @@
      bne Repeat64T
-If you're checking INTIM during the visible screen, it should also be noted that DMA may make it difficult to catch the exact moment when 0 is reached, because the timer will switch to single-cycle resolution at the time. In this case you can either work with an offset value (e.g. add 10 to the timer value you want, and then act accordingly when INTIM is 10 or less.) or you can use the RIOT interrupts, and rely on TIMINT instead of INTIM.
+If you're checking INTIM during the visible screen, it should also be noted that DMA may make it difficult to catch the exact moment when 0 is reached, because the timer will switch to single-cycle resolution at the time. In this case you can either work with an offset value (e.g. add 10 to the timer value you want when setting the timer, and then act accordingly when INTIM is at 10 or less.) or you can use the RIOT interrupts, and rely on TIMINT instead of INTIM.
 In theory you could take the same approach with RIOT RAM writes if desired...