Improving the emulators

[GroovyBee]

raz0red has been examining the source code of the Prosystem emulator and asked me the following (I hope he doesn't mind me quoting parts of the PM since it was technical in nature) :-

 

"The RIOT timer isn't being updated when a WSYNC is set. In other words, all the cycles from the time of the WSYNC to the end of the scan line don't update timer. Am I missing something or is this incorrect?"

 

and

 

"Also, it wasn't adding cycles to the timer when Maria was executing, and I am pretty certain this is incorrect as several PAL games use the timer (Xevious and Commando)."

 

I didn't know the answers so I devised the following tests :-

 

Test 1 - Wait for VBLANK to occur and time the duration of WSYNC.

Test 2 - Wait for VBLANK and then wait for MARIA to be in the active part of the display (zone 1) and time WSYNC.

Test 3 - Wait for VBLANK and then wait for MARIA to be in the active part of the display (zone 2) and time WSYNC.

 

WSYNC was timed because Sally (6502) would be held in HALT during that period and I wanted to see what would happen to PHI2 (supplying RIOTs clock).

 

I also wanted to time the WSYNC in two zones because the time taken by MARIA processing the Display List entries for those zones (in one of my games) would be different. Just in case DMA would have an effect.

 

All the tests would be run with DMA off and then DMA on.

 

Here is the code I used on the real hardware :-

 

; Test 1
; ======
; Time WSYNC in VBLANK
jsr WaitForVBlank
lda #255
sta WSYNC
sta TIM1T
sta WSYNC
lda INTIM
jsr DebugOut

; Test 2
; ======
; Time WSYNC in the active frame's 1st zone
jsr WaitForVBlank
@L1:
lda MSTAT
bmi @L1

lda #255
sta WSYNC
sta TIM1T
sta WSYNC
lda INTIM
jsr DebugOut

; Test 3
; ======
; Time WSYNC in the active frame's 2nd zone
sta WSYNC
sta WSYNC
sta WSYNC
sta WSYNC

sta WSYNC
sta WSYNC
sta WSYNC
sta WSYNC

sta WSYNC
sta WSYNC
sta WSYNC
sta WSYNC

sta WSYNC
sta WSYNC
sta WSYNC
sta WSYNC; Zone is 16 pixels high

lda #255
sta WSYNC
sta TIM1T
sta WSYNC
lda INTIM
jsr DebugOut
rts

WaitForVBlank:
@L2:
bit MSTAT
bmi @L2
@L3:
bit MSTAT
bpl @L3
rts

 

The function DebugOut just displays the contents of the A,X and Y registers. You'll also notice a write to WSYNC before I load the timer. That was to ensure that the timer is loaded in the HBLANK porch.

 

With DMA off the results are as follows :-

 

Test 1 INTIM is 0x8E

Test 2 INTIM is 0x8E

Test 3 INTIM is 0x8E

 

With DMA on the results are as follows :-

 

Test 1 INTIM is 0x8E

Test 2 INTIM is 0x8E

Test 3 INTIM is 0x8E

 

So in all cases the total 1.79MHz clocks are :-

 

0xFF-0x8E=0x71

=113 x 1.79MHz cycles

 

In the MARIA docs it quotes 114 x 1.79MHz will occur during WSYNC. So from this I conclude that PHI2 is clocked during WSYNC and Sally is HALTed. It also doesn't matter if DMA is on or off. This makes sense because the POKEY enabled carts would sound pretty weird if PHI2 was stopped or altered dramatically during audio playback.

 

Hopefully more cycle accurate emulators will be in the pipeline now .

Edited June 8, 2009 by GroovyBee

[EricBall]

IIRC Maria slows down the clock cycles when accessing the TIA & RIOT. So the RIOT timer isn't a stable clock and the number of cycles per line may depend upon whether the 7800 is doing DMA / normal code or accessing TIA & RIOT registers (i.e. sound, joystick and paddle I/O).

 

I don't know if emulators have improved, but when I was developing I would have loved an emulator which actually modeled MARIA cycles and cycle stealing halfway properly. It was far too easy to create something using the emulator as a reference which had cycle budgets beyond what the hardware could provide. I remember that someone did an Elite 3-D demo which flat out wouldn't work on anything other than an emulator.

[GroovyBee]

IIRC Maria slows down the clock cycles when accessing the TIA & RIOT. So the RIOT timer isn't a stable clock and the number of cycles per line may depend upon whether the 7800 is doing DMA / normal code or accessing TIA & RIOT registers (i.e. sound, joystick and paddle I/O).

Yep! From 1.79MHz (7.16Mhz/4) to 1.19333Mhz (7.16MHz/6) everytime TIA/RIOT are accessed.

I don't know if emulators have improved, but when I was developing I would have loved an emulator which actually modeled MARIA cycles and cycle stealing halfway properly. It was far too easy to create something using the emulator as a reference which had cycle budgets beyond what the hardware could provide. I remember that someone did an Elite 3-D demo which flat out wouldn't work on anything other than an emulator.

Been there and done that too. Its all sorted now though .

[GroovyBee]

I've read on the forum that you should be able to read the colour palette registers in MARIA using indexed absolute addressing. The following code :-

 

	ldy #0
lda P0C1,y

Returns 0x00 in A after I've already written a known value to P0C1 on my real PAL 7800. Reads from other palette registers don't return the correct value either. However, on the ProSystem emulator it returns the value written. Looking at GCC's documents they say that the only read register in MARIA is MSTAT.

[GroovyBee]

Prosystem 1.3d problems :-

 

1) POKEY sounds should not be made until 0x03 is written to SKCTL which takes POKEY out of its initialisation/reset state.

 

2) The POKEY RANDOM register isn't supported because it always returns 0x00. It should return 0xFF when bits 0 and 1 in SKCTL are set to 0. It should return values based on the top 8 bits of the 17 bit poly counter (or the 9 bit poly counter if bit 7 of AUDCTL is set) after POKEY has been taken out of initialisation/reset state (by writing 0x03 to SKCTL).

[Rybags]

01 and 10 (bin) are also valid non-init states for Pokey SKCTL.

 

I think the 5200 actually uses one of them (keyscan on, debounce off).

[Kr0tki]

FYI, the POKEY RANDOM register is fully implemented in the Atari800 emulator. It uses a 128KB (2^17) and 512B (2^9) lookup table to speed things up.

 

SKCTL's keyscan/debounce bits, however, aren't emulated properly ... yet.