7800 hardware facts

[SoundGammon]

One On One Basketball runs fast on an emulator. How is it in yours?

[AlyoshaTAS]

@RevEng: Yes it does support midscanline color changes.

 

@SoundGammon: The timer is too fast but the players move at the correct speed. The emulator is BizHawk from TASVideos.org, I am making a new core to replace EMU7800, so I am aiming for accuracy.

[Trebor]

Here is a video capturing the tests. Video demonstrates testing performed on two different consoles. For each instance, tests are ran through in ascending order, then descending, with approximately a 10 seconds and 5 seconds wait on each test, respectively. Both consoles report the same results:

 

https://www.youtube.com/watch?v=Z8txsnlBSWo

 

Despite both consoles providing the same test results, there are still differences between the two captures: First console shown is centered best, slightly further back and not as clear - compared to the second - but still very readable. The second console test is off centered considerably but not horribly, positioned closer to the screen, and a crisper image was captured.

 

Thanks to RevEng and others involved in the excellent research and data gathering shown above and discussed throughout this thread. It has assisted in bringing the accuracy provided under MAME for Atari 7800 emulation, and it is great news that another emulator is looking to improve its emulation accuracy as well. The very cool demo seen between the BIOS check screen and the actual testing is courtesy of CPUWIZ and his invaluable MCPDev Cart.

[AlyoshaTAS]

Thank you Trebor, I appreciate that capture video immensely. :thumbsup:

 

Thanks to RevEng as well for the A7800 Software Guide and the research in this thread, which has already saved me many headaches.

[RevEng]

It's been a while since I posted here, but I have another dma wrinkle to spell out... the 7800 Software Gude states "If holey DMA is enabled and graphics reads would reside in a DMA hole, no DMA penalty is incurred", but that doesn't appear to be true.

 

The following test creates:

• two zones, each with 2x 5-byte sprite objects with 10 bytes of graphics per sprite.
• two zones, each with 8x sprites as above, but the graphics data is in a DMA hole.

Then the test draws bars using kernel-style register hits. The X position of the color bar increases in proportion to how much DMA occurred in that zone. (fyi, the bar width is 12 Maria cycles)

 

The expected DMA for the first set sprites is 80 cycles  ((5 byte header * 2 cycles + 10 byte gfx * 3 cycles) * 2 sprites)

If we follow the guide statement, the DMA for the second set of sprites is 80 cycles ((5 byte header * 2 cycles + 0 graphics) * 8 sprites)

 

So if the guide is correct, the bar X should be the same for both portions of the screen. But they differ...

The X for the second bar is offset by 24 Maria cycles. It seems we're paying the dma penalty for the first byte of sprite graphics, at which point the hole is discovered and the object render is aborted. 

 

I think I actually inferred this a while back, as a7800 has the same assumption already coded, but I didn't have solid evidence for it until today.

 

I've updated the DMA section of the7800 Software Guide at the wiki.

 

dmaholecycles.a78

[+bsteux]

I've made a similar test on my side (mainly because I couldn't exactly understand what you have done with your bars), and I confirm your observations. Definitely, there is a penalty of 3 cycles for accessing Holey DMA, and not 0 cycles as stated by GCC Maria doc. Here is the source code for my test and the resulting pictures on a7800 v5.2 and on my old PAL Atari 7800. Almost identical, and both show a 3 cycles penalty Holey DMA access. My test just draws horizontal bars (after DMA saturation, so that they are only partially drawn depending on the number of DMA cycles left), and between each line, I add an additional holey DMA access. So by measuring the horizontal gap in pixels between the blue bars (separated by 8 lines, and thus which have 8 * (8 + penalty) DMA cycles between them), I find exactly 3 cycles penalty :

232 pixels between blue bars = 29 * 8 pixels -> 29 * 3 = 87 DMA cycles => / 8 = 11 cycles = 8 cycles + 3 penalty.

Here is the source code of my test:

 

#include "conio.h"

scattered(8, 32) holeydma char full[8 * 32] = {
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
};

void main()
{
    char i, y;
    clrscr();
    for (y = 0; y != 11; y++) {
        gotoxy(0, y);
        textcolor(y & 7);
        _ms_tmpptr = _ms_dls[X = _conio_y];
        Y = _ms_dlend[X];
        // Draw 3 grey bars, that consume (8 + 31 * 3) * 3 = 303 DMA cycles
        for (i = 0; i != 3; i++) {
            _ms_tmpptr[Y++] = full;
            _ms_tmpptr[Y++] = -31 & 0x1f;
            _ms_tmpptr[Y++] = full >> 8;
            _ms_tmpptr[Y++] = 0;
        }
        // Then draw y bars in Holey DMA, that theoretically consume 8 + penalty DMA cycles each
        for (i = 0; i != y; i++) {
            _ms_tmpptr[Y++] = 0x00;
            _ms_tmpptr[Y++] = -31;
            _ms_tmpptr[Y++] = 0x98;
            _ms_tmpptr[Y++] = 0;
        }
        // Then draw a colorful bar, that consumes 8 + (nb pixels actually drawn / 8) * 3 DMA cycles
        _ms_tmpptr[Y++] = full;
        _ms_tmpptr[Y++] = 0x40;
        _ms_tmpptr[Y++] = full >> 8;
        _ms_tmpptr[Y++] = _conio_palette;
        _ms_tmpptr[Y++] = 16;
        _ms_dlend[X] = Y++;
        _ms_tmpptr[Y] = 0;
    }
    while(1); 
}

 

[KrunchyTC]

I have a question. Is the 7800 stuck with tiled backgrounds, or can you have bitmapped BG's too?

[+bsteux]

29 minutes ago, KrunchyTC said:

I have a question. Is the 7800 stuck with tiled backgrounds, or can you have bitmapped BG's too?

You can definitely use bitmapped BG (aka immediate mode), which is cheaper DMA-wise than tiled backgrounds (aka character more). In the case of dynamic/varied BG, a bitmapped BG may consume some / a lot of RAM (and thus generally requires 16KB RAM mapped at 0x4000), and ROM to RAM copying, while using tiling is easier (it's a form of compression, an indirect graphics addressing performed by MARIA at the expense of DMA/CPU time) and generally requires less RAM / ROM. Bitmapped BG is definitely required if background must be full of 160B, 320B or 320C graphics...

[KrunchyTC]

6 minutes ago, bsteux said:

You can definitely use bitmapped BG (aka immediate mode), which is cheaper DMA-wise than tiled backgrounds (aka character more). In the case of dynamic/varied BG, a bitmapped BG may consume some / a lot of RAM (and thus generally require 16KB RAM mapped at 0x4000), and ROM to RAM copying, while using tiling is easier (it's a form of compression, an indirect graphics addressing performed by MARIA at the expense of DMA/CPU time) and generally requires less RAM / ROM. Bitmapped BG is definitely required if background must be full of 160B, 320B or 320C graphics...

I see. Thats pretty cool that the 7800 offers both options. It's good that you can save on RAM if you don't need big expensive BG's, and vice versa

 

I guess my next question is, does using bitmaps save on sprite usage? Like bitmaps don't eat into the foreground spite count?

Edited August 30, 2023 by KrunchyTC

[+bsteux]

7 minutes ago, KrunchyTC said:

I see. Thats pretty cool that the 7800 offers both options. It's good that you can save on RAM if you don't need big expensive BG's, and vice versa

 

I guess my next question is, does using bitmaps save on sprite usage? Like bitmaps don't eat into the foreground spite count?

Using bitmaps saves on sprite usage (wrt indirect access / tiling), but definitely eats into the foreground sprite count. Indeed, Maria doesn't distinguish between background and foreground, and even doesn't know about sprites. It just displays objects in order, either in immediate mode (aka sprite or bitmap mode), on in indirect mode (aka tiled mode), until it has finished or there is no DMA cycles left on the line... Completely different from the NES, but very flexible and keen to display big "sprites", bitmaps, or many small sprites at your will... The main drawback (to me) is the 6502 speed bottleneck to fill the display lists, and the memory layout which is very special and limiting (except with bankset bankswitching, which requires to handle the HALT line on cart).

[+SmittyB]

@KrunchyTC this thread might be interesting to you, and here's a link to a small bitmap demo I did. Press Select to switch between 320A and 160A modes. https://raz0red.github.io/js7800/?cart=https://atariage.com/forums/applications/core/interface/file/attachment.php?id=910920

 

[KrunchyTC]

16 minutes ago, bsteux said:

Using bitmaps saves on sprite usage (wrt indirect access / tiling), but definitely eats into the foreground sprite count. Indeed, Maria doesn't distinguish between background and foreground, and even doesn't know about sprites. It just displays objects in order, either in immediate mode (aka sprite or bitmap mode), on in indirect mode (aka tiled mode), until it has finished or there is no DMA cycles left on the line... Completely different from the NES, but very flexible and keen to display big "sprites", bitmaps, or many small sprites at your will... The main drawback (to me) is the 6502 speed bottleneck to fill the display lists, and the memory layout which is very special and limiting (except with bankset bankswitching, which requires to handle the HALT line on cart).

I see. Anything that save on sprites at all is good at least. Thanks for the input! I'm getting a better overall understanding of the 7800

[KrunchyTC]

13 minutes ago, SmittyB said:

@KrunchyTC this thread might be interesting to you, and here's a link to a small bitmap demo I did. Press Select to switch between 320A and 160A modes. https://raz0red.github.io/js7800/?cart=https://atariage.com/forums/applications/core/interface/file/attachment.php?id=910920

 

That is quite awesome 

[KrunchyTC]

12 hours ago, bsteux said:

Using bitmaps saves on sprite usage (wrt indirect access / tiling), but definitely eats into the foreground sprite count. Indeed, Maria doesn't distinguish between background and foreground, and even doesn't know about sprites. It just displays objects in order, either in immediate mode (aka sprite or bitmap mode), on in indirect mode (aka tiled mode), until it has finished or there is no DMA cycles left on the line... Completely different from the NES, but very flexible and keen to display big "sprites", bitmaps, or many small sprites at your will... The main drawback (to me) is the 6502 speed bottleneck to fill the display lists, and the memory layout which is very special and limiting (except with bankset bankswitching, which requires to handle the HALT line on cart).

https://segaretro.org/Sega_Master_System/Hardware_comparison#:~:text=The Master System is also,same reasons (see above).

 

I was reading through this page, and I think a lot of the info on this page is wrong based on what I've been told here. It says the 7800 can only display 12 colors per zone/scanline (I thought it was 25, correct me if I'm wrong), it doesn't have tile compression, can't do smooth scrolling, and can't do backgrounds without crippling performance.

Edited August 31, 2023 by KrunchyTC

[+bsteux]

5 hours ago, KrunchyTC said:

https://segaretro.org/Sega_Master_System/Hardware_comparison#:~:text=The Master System is also,same reasons (see above).

 

I was reading through this page, and I think a lot of the info on this page is wrong based on what I've been told here. It says the 7800 can only display 12 colors per zone/scanline (I thought it was 25, correct me if I'm wrong), it doesn't have tile compression, can't do smooth scrolling, and can't do backgrounds without crippling performance.

This article is partially incorrect (Maria has tile compression, handles smooth scrolling with ease (no intensive software routine required at all) and can display up to 25 colors per zone), but is correct I think in its conclusions : the limited bandwidth due to the bus sharing between Maria and the CPU is quite limiting, and the sharing of bandwidth between background and foreground graphics favors games with black or sparse background... I agree that SMS and NES with their separate video bus / memory can generally be considered more powerful than Atari 7800, but well... frankly ? IMO, I still find the Atari 7800 more "attractive", probably due to its direct link to the Atari 2600, its programming model which is indeed quite fun, and also because it didn't get the attention it deserved in its time... There are still so many things to do with it, it's still an open field...

[+Defender_2600]

10 hours ago, KrunchyTC said:

https://segaretro.org/Sega_Master_System/Hardware_comparison#:~:text=The Master System is also,same reasons (see above).

 

I was reading through this page, and I think a lot of the info on this page is wrong based on what I've been told here. It says the 7800 can only display 12 colors per zone/scanline (I thought it was 25, correct me if I'm wrong), it doesn't have tile compression, can't do smooth scrolling, and can't do backgrounds without crippling performance.

 

7800 and NES are different systems, each with their own strengths. That said, instead of continuing the usual "NES to 7800" exercise, I think the time is ripe to reverse the comparison to "7800 to NES" and, as has already been shown several times, there are 7800 games and demos that don't can be replicated on the NES without making it look like a second generation game, thus reducing the number of sprites, the size of the sprites, the colors on the screen and sometimes even the resolution.

 

The games I showed you in this discussion are an example but there are many others. Don't just stop at the technical specs, sometimes non-developer people don't have the right insights to understand the true potential of those specs and they get lost in an abstract discourse.

 

 

 

As for the Sega Master System, it is obviously the most modern and powerful system among the three mentioned, however it does not completely exceed the 7800 in the sprites and colors department. Compared to 7800, the SMS puts more colors on screen at one time for the background (SMS 31 colors from 2 palettes vs 7800 25 colors) but for the sprites the SMS has only one 15 color palette while the 7800 can use any palette available. 

 

 

I'm assuming it should have some horizontal scrolling to view all of the boxing ring but at least we wouldn't have those little Master System sprites. Both boxers are using only one 160B palette and the boxing ring two 160A palettes (shared in the 160B palette), so there are still additional colors available.

[KrunchyTC]

Ah, more insight on that generation of consoles! Thanks! And yes I agree, knowing a ton more about each console now, I used to think the 7800 was the worst by a wide margin. But realize its much closer to the SMS. Which is pretty amazing to me after thinking otherwise for over 2 decades.

Edited August 31, 2023 by KrunchyTC