Color grid demo

[EricBall]

This is just a quick demo which displays all 256 colors the 7800 is capable of. Source code is included for those interested. And it should autodetect PAL/NTSC and adjust. (Did any released games do this, or does sole credit belong to Eckhard?)

colorgrid.zip

[DanBoris]

Is the screenshot a video capture or did it come from an emulator?

 

Dan

[EricBall]

Is the screenshot a video capture or did it come from an emulator?

 

Snapshot from MESS (not a screen cap, using the built in capture function.) I don't have a 7800 (yet).

 

It would be interesting if someone could make a video capture to assist in color correcting the emulators.

[Eckhard Stolberg]

I tried your demo on my PAL 7800 (I'm too lazy to drag out the NTSC console too at the moment) and it works pretty nicely. There are some small problems though. The first line of text only shows the letter 0-C. E and F are missing. In the second line of text (the one starting with 1) it shows the first two scanlines of the 0-C text and then continues to display the '1' as it should. The rest of the display is fine.

 

For a screen capture of your demo you should ask Mitch. He once did some screen shots of Atari's 7800 colour test program for me. The pictures were a bit too fuzzy to get proper palette colour values from it, but since your demo shows larger colour blocks, it might work better.

 

I found the PAL/NTSC test in the Asteroids game that was inlcuded with the BIOS in the PAL 7800. So it should be possible to use this BIOS in NTSC 7800s too. AFAIK there are no other games that are compatible with both TV formats.

 

 

Ciao, Eckhard Stolberg

[EricBall]

The first line of text only shows the letter 0-C. E and F are missing. In the second line of text (the one starting with 1) it shows the first two scanlines of the 0-C text and then continues to display the '1' as it should. The rest of the display is fine.

 

Sounds like I'm asking to much of Maria

 

The first line of text is 16 indirect sprites with double wide characters and 5 direct sprites each 8 bytes wide. It sounds like Maria runs out of cycles before all of the indirect sprites are displayed.

 

The color and number updates are handled by an NMI routine. Again, since Maria is using all of the cycles trying to display everything there's no time left for the CPU to do the updates before the start of the next line.

 

I just need to come up with a different (less time consuming) way to display the first 0-F. Just one of the pitfalls of developing with an emulator. However, it should be possible to use this to clarify the cycle times given in the 7800 documentation.

 

Oh, and if someone is going to do a screen capture, I can create a version which doesn't display the digits.

[EricBall]

Okay, I've reworked the demo so it uses less cycles to display the digits. The digits can also be turned off by setting the P1 difficulty switch to A.

 

The one good thing about this is it has given me some hints about MARIA cycle counts. The following is a rough guide: 2 cycles / RAM byte, 3 cycles / ROM byte, approx 400 cycles available per line.

 

Unfortunately, this means my clouds demo will remain a demo since there is no time left to display any other sprites. Sigh.

colorgrid.zip

[Eckhard Stolberg]

I tried your new demo on my PAL 7800, and the full text in the "0-F" line is now showing. But the problem of the first two scanlines of the "0-F" text appearing in the "1" line too is still there. Those two scanlines seem to be flickering.

 

Switching the letters off doesn't really work. The letters are always there. The difficulty switch only changes the outline colour from white to black.

 

BTW, I think there is a listing of DMA timings at the end of the 7800 programmers guide, if you want to know for sure how much you can expect of the MARIA chip.

 

 

Ciao, Eckhard Stolberg

[+Mitch]

BTW, I think there is a listing of DMA timings at the end of the 7800 programmers guide, if you want to know for sure how much you can expect of the MARIA chip.

 

Yes there is, it's on page 19.

 

Mitch

[EricBall]

Unfortunately, the timing list has "Indirect/2 byte 9 cycles" and "character map access 3 cycles". So the question was whether the indirect time included the character map access. Based on this demo and my cloud demo, I believe it does.

 

Now, does anyone have documentation on how INPTCTRL works? I guess I could look at the MESS source or the wiring schematics.

[jindroush]

Now, does anyone have documentation on how INPTCTRL works?  I guess I could look at the MESS source or the wiring schematics.

 

What schematics? Everything is IMO hidden inside the Maria. And if I'm not mistaken, no mentions in MESS code either, except for:

 

if(data & 0x01)

{

maria_flag=1;

}

if(!a7800_ctrl_lock)

{

a7800_ctrl_lock = data & 0x01;

a7800_ctrl_reg = data;

 

//this does os/cart bankswiting

if(data & 0x04)

memcpy( ROM + 0xC000, a7800_cart_bkup, 0x4000 );

else

memcpy( ROM + 0xC000, a7800_bios_bkup, 0x4000 );

}

[cschell]

Actually it's accomplished in a latch outside the Maria chip. You can get it off the schematics. Here's the pretty much how it works, as edited from an email I sent to Eckhard a long while back:

 

 

It's all done with a single 74LS174, which is a hex D-type flip flop with clear. The flip flop is cleared upon system reset (power up.)

 

Data is latched into the flip flop on the rising edge of its clock, and its clock signal is controlled by the OR'd combination of the Maria's TIA_CS line and essentially the ~WE signal. So it seems that you write to this flip flop whenever you write to the TIA. (I don't know what exactly causes the Maria TIA_CS line to go low. CS = chip select by the way.)

 

Only D0-D3 are connected to this flip flop, so the upper nibble does nothing in external logic. The remaining two gates of the flip flop are used to delay the activation of the external HALT line for the 6502. This probably is so that the 6502 can't be halted before the system has had a chance to initialize. Basically HALT will be enabled after the second transition of the flip flop's clk line after reset.

 

The way I see the external logic is as follows: (D0-D3 are data bus lines)

 

D0: 1 = lock mode. Once a 1 is latched into the flip flop on d0, the clk line of the flip flop is locked high, so it's state can no longer be changed.

 

D1: 1 = Maria Enable, 0 = Maria Disable. (It's tied to the MEN line on the Maria chip.) 7800 RAM is disabled when Maria is disabled. I don't know exactly how the Maria works, so what else disabling the Maria does I don't know.

 

D2: 0 = Enable BIOS ROM, and tie cart lines A12, A14, A15 low. 1 = Disable BIOS Rom, Cart address lines = actual address lines.

 

D3: 1 = enable TIA video pull ups, and I believe disable Joystick button 2. 0 = disable TIA video pullups, and activate button 2. This has NO external effect on the Maria.

 

Chad

[Heaven/TQA]

eric, is your source code of the demo available?

 

hve

[EricBall]

Heaven: The source is in the ZIP file. Not much in the way of comments though.

 

Chad: Thanks, I had started to puzzle it out from the schematics. It's surprising the amount of random logic on the 7800.

[doppel]

I thought writing to the color registers during on-screen rendering of line RAM was supposed to result in color stretching, whether or not the color reg being written to was actually in use. But I don't see any. Is this behavior not properly emulated on the emulators, or does somebody know something I don't?

 

I was in the middle of writing my own palette demo for the 7800 a few days ago, and I had already calculated the minimum cycle requirements (195 counting worst-case startup and shutdown), and strangely enough we both had the same idea (8 bytes of three-color stripes per object, 5 objects), though mine would have had the colors arranged the other way, and no letters.

 

I stopped midway through when A. I saw no possible way to update 16 color regs on one scanline after DMA, and B. somebody (you) had already beaten me to it about 7 years ago.

[EricBall]

I thought writing to the color registers during on-screen rendering of line RAM was supposed to result in color stretching, whether or not the color reg being written to was actually in use. But I don't see any. Is this behavior not properly emulated on the emulators, or does somebody know something I don't?

I haven't kept up on 7800 emulator accuracy, but it's certainly possible that:

1. writing color registers doesn't cause color stretching, or

2. writing color registers causes stretching on real hardware, but isn't emulated correctly

3. writing color registers causes stretching on real hardware and in current emulators

 

Of course, if the side effect only occurs under some circumstances (i.e. only while DMA is active) then you may get a combination of all three possibilities.