The color limitation of Graphics Mode 0 and the POKEY limitations regarding envelopes are the reasons why the C64 did dominate ATARI 8-Bit. The C64 could display more colors at once in text mode and the sound chip had more sound envelopes at hand, that could also be filtered. The lack of colors (only 16 instead of 256) and the lack of channels (3 instead of 4) where not a problem for the consumers in the end, because they want more colors in text at once and more variation in sound at once, which the C64 did deliver.
Well, it a litte like comparing apples and oranges. The C64 was released 3 years later than the Atari. It's chips have an LSI factor 3 higher integration and the same amout of cost reduction. Add another 3 years and the C64 was blown away by the Atari 8-bit's successor design: The Amiga. So yes, newer computers are more powerful than older ones :-)
8:35 There's also Antic 3, which is like Antic 2, but 10 scan-lines high (8 x 10 pixels) for each character. Also, Graphics 7 (Antic D) takes only 4296 bytes of memory. *sigh* I miss my 130 XE!
@@rbrtck It's Screen Memory + Display List Memory. The display list tells the ANTIC how to visualize the data. Screen Memory = Bytes Per Mode Line * Mode-Lines, for example, 40*24=960 in GRAPHICS 0. Display List Memory in PAL is 3 (Empty Lines)+2 (Screen Memory Address)+Mode-Lines+3 (JUMP VBL), plus 2 if the DL crosses a 4k boundary and an additional LMS command is required, plus alignment added by the OS. In the GRAPHICS 0 example 3+2+24+2+1 = 32. Total 992 bytes.
@@jacofwudsn From GRAPHICS 0 (same as your example), I figured that the length of the DL was counted because it works out perfectly with a DL of 32 bytes (same in NTSC where I'm located). But there are in some modes more than 400 additional bytes, which seems long for a basic DL, which was why I asked. I hadn't considered the alignment that the OS used, so that must be what I was missing, but if we look at GRAPHICS 1, that is a split-screen mode that requires an additional couple of bytes for an address, so along with the OS alignment, the number of bytes this mode uses is actually 674 instead of 672. That's not much of a difference, but the difference is larger in some other modes. So I guess what the table shows is the number of bytes consumed by the OS for each mode if it were full screen (normal width), which in Atari BASIC means that 16 would be added to the mode number for the GRAPHICS command. OK, I should have thought of that. Thanks for informing me, and sorry for bugging you on this. Coming from a C64 background, I'm just so used to switching out the ROMs first and going straight to the "bare metal" of the hardware that I never thought about what the Atari OS does (I mostly ignore the Atari OS, too, when I program on this platform, unless I need to access peripherals).
@@rbrtck You are right. The table refers to the total RAM allocated by the OS routine using standard alignment. The additional memory consumption is due to the "DL itself must not cross a 1k boundary" and the "SM must not cross a 4k boundary" rule. To save money they saved some transistors in the counters on the ANTIC and rather did that in software spending more (cheap) ROM&RAM. It is similar to the C64's 1k alignment for the screen or the 16k alignment for the VIC bank. In split graphics modes 0-8/12-15, there are even two screens and a mixed D. And yes, for any reasonable project you'd always build the DL by hand.
Yes. As opposed to the C64, where VIC and CPU alternate on the bus most of the time without interference, the ANTIC really stops the CPU for every DMA access via a special pin of the 6502C used in the Atari. So depending on the mode, every scanline can be a "bad line". That why the Atari is only 30% fast then C64 with screen on, even though its running with a 100% higher clock. You can find all the details in the www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Great video thank you and I still feel the Atari is the little brother of the Amiga...I thank you Jay Miner.
That's because the Amiga was designed by Atari 8bit designers.
The color limitation of Graphics Mode 0 and the POKEY limitations regarding envelopes are the reasons why the C64 did dominate ATARI 8-Bit. The C64 could display more colors at once in text mode and the sound chip had more sound envelopes at hand, that could also be filtered. The lack of colors (only 16 instead of 256) and the lack of channels (3 instead of 4) where not a problem for the consumers in the end, because they want more colors in text at once and more variation in sound at once, which the C64 did deliver.
Well, it a litte like comparing apples and oranges. The C64 was released 3 years later than the Atari. It's chips have an LSI factor 3 higher integration and the same amout of cost reduction. Add another 3 years and the C64 was blown away by the Atari 8-bit's successor design: The Amiga. So yes, newer computers are more powerful than older ones :-)
Please continue this series!!!
I recently did with parts on how in include music. If there's something special you'd like to see, just let know.
8:35 There's also Antic 3, which is like Antic 2, but 10 scan-lines high (8 x 10 pixels) for each character.
Also, Graphics 7 (Antic D) takes only 4296 bytes of memory.
*sigh*
I miss my 130 XE!
Thanks for the feedback Stanley. Gury has updated his site accordingly.
@@jacofwudsn How are you guys calculating the amount of memory each mode uses? What does it include besides the graphics data itself?
@@rbrtck It's Screen Memory + Display List Memory. The display list tells the ANTIC how to visualize the data. Screen Memory = Bytes Per Mode Line * Mode-Lines, for example, 40*24=960 in GRAPHICS 0. Display List Memory in PAL is 3 (Empty Lines)+2 (Screen Memory Address)+Mode-Lines+3 (JUMP VBL), plus 2 if the DL crosses a 4k boundary and an additional LMS command is required, plus alignment added by the OS. In the GRAPHICS 0 example 3+2+24+2+1 = 32. Total 992 bytes.
@@jacofwudsn From GRAPHICS 0 (same as your example), I figured that the length of the DL was counted because it works out perfectly with a DL of 32 bytes (same in NTSC where I'm located). But there are in some modes more than 400 additional bytes, which seems long for a basic DL, which was why I asked. I hadn't considered the alignment that the OS used, so that must be what I was missing, but if we look at GRAPHICS 1, that is a split-screen mode that requires an additional couple of bytes for an address, so along with the OS alignment, the number of bytes this mode uses is actually 674 instead of 672. That's not much of a difference, but the difference is larger in some other modes. So I guess what the table shows is the number of bytes consumed by the OS for each mode if it were full screen (normal width), which in Atari BASIC means that 16 would be added to the mode number for the GRAPHICS command.
OK, I should have thought of that. Thanks for informing me, and sorry for bugging you on this. Coming from a C64 background, I'm just so used to switching out the ROMs first and going straight to the "bare metal" of the hardware that I never thought about what the Atari OS does (I mostly ignore the Atari OS, too, when I program on this platform, unless I need to access peripherals).
@@rbrtck You are right. The table refers to the total RAM allocated by the OS routine using standard alignment. The additional memory consumption is due to the "DL itself must not cross a 1k boundary" and the "SM must not cross a 4k boundary" rule. To save money they saved some transistors in the counters on the ANTIC and rather did that in software spending more (cheap) ROM&RAM. It is similar to the C64's 1k alignment for the screen or the 16k alignment for the VIC bank. In split graphics modes 0-8/12-15, there are even two screens and a mixed D. And yes, for any reasonable project you'd always build the DL by hand.
Do you know more about DMA Access ? Does this chip also have "bad lines" linke the C64: ruclips.net/video/A-myNx1YhR8/видео.html ?
Yes. As opposed to the C64, where VIC and CPU alternate on the bus most of the time without interference, the ANTIC really stops the CPU for every DMA access via a special pin of the 6502C used in the Atari. So depending on the mode, every scanline can be a "bad line". That why the Atari is only 30% fast then C64 with screen on, even though its running with a 100% higher clock. You can find all the details in the www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf