7800 Software Guide updated

[RevEng]

Perfect. Thanks Eric!

[RevEng]

Ok, I updated the guide in the first post and gave INPTCTRL its own section after the various chips.

 

I mostly used Dan's text, with slight modification. If anybody has technical corrections to be made here, let me know.

[EricBall]

Ok, I updated the guide in the first post and gave INPTCTRL its own section after the various chips.

 

You probably want to note it is set & locked by the 7800 BIOS so cannot be changed by the game program (2600 or 7800).

[RevEng]

You probably want to note it is set & locked by the 7800 BIOS so cannot be changed by the game program (2600 or 7800).

Understood, but is there ever an exception where it doesn't get setup by the BIOS? The reason I ask... I see some homebrews setting the low 3 bits, including programs that you and Dan have posted, with comments like "lock in 7800 mode"

 

Or are those writes just dummy writes, to enable HALT? Or just cruft?

[EricBall]

Hrmm.. I'm not sure I should be trusting my memory on this... Let me look into it. (It may have been a CYA, like doing a SEI on a 2600 game.)

 

Ok, I've reviewed the 7800 BIOS disassembly on http://www.atarihq.com/danb/files/7800bios.asm and while the BIOS locks INPTCTRL before changing to 2600 mode

LF831: LDA    #$FD    
       STA    COLUPF  
       JMP(LFFFC)         ; And use the reset vector on the cart to start

it doesn't for the 7800 mode.

LF7B9: LDX    #$16        ; finally, back to something important
       STX    INPTCTRL    ; switch out bios and use reset vector
       TXS                ; on cart to start the game.
       SED            
       JMP(LFFFC)     

So it's necessary to store #$x7 to $0000-$001F before trying to update any TIA registers.

Edited March 5, 2014 by EricBall

[RevEng]

Excellent. I'll include that locking requirement in the guide.

 

Thanks Eric!

 

[edit] Actually, it looks like Dan's text mentions the locking requirement before using TIA, so we should be set.

[RevEng]

I updated the guide with correct NTSC and PAL scanline counts, and DMA cycle-timings based on the more accurate GCC spec.

[AlyoshaTAS]

This guide is really good, it has helped me a lot in developing my emulator. I thought I might mention a few things and post some information that I did not find anywhere else.

 

First, there is a small error on page 10. In the CTRL register, CW bit should be 1 = two byte characters and 0 = single byte characters.

 

Also, mostly of interest to emulator authors, here is some information on line RAM that I deduced from the display modes. I think it helps clarify what Maria is actually doing.

 

Line RAM is 320 bytes of data that makes up a scanline (probably implemented in silicon as only 5 bits since that's all that's used.)

 

Given a graphics byte G=[G7, G6, G5, G4, G3, G2, G1, G0], and palette entry P = [P2, P1, P0], line RAM is written to depending on the 'write mode' flag.

 

if 'write mode' is true, 4 consecutive bytes are written (starting at the appropriate position given by the header.) They are:

[0, 0, 0, P2, G3, G2, G7, G6]

[0, 0, 0, P2, G3, G2, G7, G6]

[0, 0, 0, P2, G1, G0, G5, G4]

[0, 0, 0, P2, G1, G0, G5, G4]

 

if 'write mode' is false, 8 bytes are written in the following form:

[0, 0, 0, P2, P1, P0, G7, G6]

[0, 0, 0, P2, P1, P0, G7, G6]

[0, 0, 0, P2, P1, P0, G5, G4]

[0, 0, 0, P2, P1, P0, G5, G4]

[0, 0, 0, P2, P1, P0, G3, G2]

[0, 0, 0, P2, P1, P0, G3, G2]

[0, 0, 0, P2, P1, P0, G1, G0]

[0, 0, 0, P2, P1, P0, G1, G0]

 

NOTE: A byte is only written to line RAM if the value & 3 does not equal zero. If it does equal zero, it is transparent and therefore not written (or if kangaroo mode is active, written with 0x00). With this you can see why transparency doesn't work in some of the 320 modes.

 

The benefit of knowing this is that the 'read modes' now become very simple to understand.

Consider a byte of line RAM given by D = [0, 0, 0, D4, D3, D2, D1, D0]

 

'Read Mode 0' just reads the line RAM data directly, can't get simpler then that!

 

'Read Mode 2' reads depending on whether a pixel is even or odd

If it is even, the color you get is [0, 0, 0, D4, 0, 0, D1, D3]

If it is odd, then the color becomes:[0, 0, 0, D4, 0, 0, D0, D2]

 

'Read Mode 3' also depends on whether a pixel is even or odd

If it is even, the color you get is [0, 0, 0, D4, D3, D2, D1, 0]

If it is odd, then the color becomes [0, 0, 0, D4, D3, D2, D0, 0]

 

NOTE: This even/odd operation works because you can only place objects at 160 scale precision.

 

I think this clearly illustrates how Maria works internally, and provides a simpler explanation of display modes then what is in the guide. Anyway I hope it's useful. it certainly helped me make my emulator code much cleaner.

[Synthpopalooza]

Soon I am going to be making an update to the sound table in regards to using 15khz mode on POKEY. This basically takes your tuning up an octave and lets you use more accurate high notes without having to go into 16-bit mode.

[AlyoshaTAS]

Here is another useful bit of information I learned while developing my emulator that helps clarify the software guide.

 

DMA reads DO incur a penalty for the first read that would take place in a hole. This makes sense actually, since the DMA unit cannot know if it is in a DMA hole before it does the first read. Subsequent reads in the same header do not incur a penalty.

 

This makes both DMA hole tests in RevEng's test ROM work correctly, and also fixes the incredibly precise water effect in the sewer level of Scrapyard Dog.

[RevEng]

That is very precious information! Thanks for sharing.

[+Pat Brady]

Bump!

 

First of all, thanks for doing this. I’ve mostly been referring to http://7800.8bitdev.org/index.php/7800_Software_Guide which I see you have continued to update.

 

I have noticed that the text refers to “CNTSWA” and “CNTSWB” but Appendix 2 calls them “CTLSWA” and “CTLSWB” (and also “SWACNT” and “SWBCNT” as their 2600 names). That appendix has been distributed as a header file. Any objections to me changing the text to use “CTLSWA” and “CTLSWB”? It would make searching a bit easier.

[RevEng]

Nope, makes sense. I'll likely make a similar change.

 

Thanks for pointing out the inconsistency! ?

[fultonbot]

This doc is exactly what I've been looking for!  Thanks!

[SoundGammon]

Just wondering here...

 

 If you put a 6532A RIOT, which is a 2MHZ speed version, would it speed up the 7800 at all?

[RevEng]

No, because the chip would still be clocked at the same slower RIOT speed. The only difference that might make, is to allow RIOT RAM and Timers to be used reliably in 7800 mode.

[+Pat Brady]

4 hours ago, RevEng said:

No, because the chip would still be clocked at the same slower RIOT speed. The only difference that might make, is to allow RIOT RAM and Timers to be used reliably in 7800 mode.

One of the things I’ve been wondering about the 7800 is: what exactly happens if I use the RIOT RAM? I assume that if it works at all, accesses will be slow, like reading the controller ports. The SG says it “may not exist in future versions of MARIA” but if that never happened, then that’s not a compelling reason not to use it at this point. But if the clock difference means it really doesn’t work reliably, then that is a compelling reason not to use it.

[RevEng]

The address at which the RIOT RAM sits at isn't monitored for slow-down, so the RAM access will happen at 1.79MHz instead of 1.19Mhz. At that speed the RAM is likely unreliable in most consoles. The same is true for the RIOT timers... I found they were unreliable on my console, unless I hit them the timer a couple times in a row. You might be able to do the same to make the RIOT Ram more reliable, but it don't think 128 bytes would be worth the bother.

[+Pat Brady]

1 hour ago, RevEng said:

The address at which the RIOT RAM sits at isn't monitored for slow-down, so the RAM access will happen at 1.79MHz instead of 1.19Mhz.

Okay, got it. Thanks.

[+Pat Brady]

The Software Guide says the encryption area is from FF7A to FFF9.

 

The Game Standards and Procedures document says the encryption key occupies FF80 to FFF7, with FFF8 and FFF9 serving other purposes.

 

From inspection of Bruce Tomlin’s sign7800.c (which seems to work correctly) I believe FF80 to FFF7 is correct. This suggests cartridges can use the 6 bytes from FF7A to FF7F. I tested that with no problems, and have edited the document accordingly.

 

This might be an appropriate place to describe the contents of FFF8 and FFF9, but I have not yet done so.

Edited October 1, 2020 by bizarrostormy

[RevEng]

Nice catch - it's definitely ff80 to fff7.  

[RevEng]

On 4/24/2020 at 6:36 PM, RevEng said:

The address at which the RIOT RAM sits at isn't monitored for slow-down, so the RAM access will happen at 1.79MHz instead of 1.19Mhz. 

Just noticed this old, bad assumption I made. While scoping my 7800 for RIOT RAM access (relating to the Concerto project) I found that the slowdown does indeed happen for RIOT RAM too, but other things are problematic, so I documented the RIOT Limitations and Workarounds.

 

In a nutshell, it's mostly DMA that makes RIOT RAM problematic, though even with DMA off you can only use the RAM certain ways. Still not worth it.