About to give an Atari 2600 talk

[+SvOlli]

Hello,

 

I'm giving a talk called "The Atari 2600 Video Computer System: The Ultimate Talk - The history, the hardware and how to write programs" (http://events.ccc.de...ts/4711.en.html) at the 28th Chaos Communication Congress in Berlin on 2011-12-27.

 

Since I've put a lot of effort into creating this talk, I'd like to have to community here to take a look at the slides for comments, before I use them for the talk. Please keep in mind that on most slides the information is revealed piece by piece using animations.

 

Since there's an upload quota for a single file, and I can't squeeze the PDF below 2.8MB please download it from http://svolli.de/dow...php/4711.pdf.gz .

 

The final version of the slides will be released, once they're done. The talk itself will be available via streaming and recorded for later viewing.

 

I'm thankful for your input!

 

Greetings from Germany,

SvOlli

[GroovyBee]

Some comments :-

 

- Spell checking is needed!

- Some names are spelt wrong

- No mention of CC2 or Flashback 2+ or 3

- The hardware in a Flashback is not the same as the legacy consoles. Its an ASIC (NOAC for FB1) or emulation in the case of FB3.

- There is no such thing as an AMD Cortex M3 .

[GroovyBee]

I forgot to add the Kroko cart as a development tool too.

[+SvOlli]

Thanks!

 

- Spell checking is needed!

I'm no native, so I'm thankful for every hint where I went wrong. Auto spell checking of OpenOffice did not show much.

 

- Some names are spelt wrong

I took most of them via copy'n'paste from the stella mailing list archives, again please provide me with the correct names to fix them.

 

- No mention of CC2 or Flashback 2+ or 3

- The hardware in a Flashback is not the same as the legacy consoles. Its an ASIC (NOAC for FB1) or emulation in the case of FB3.

There are only 45 minutes for the talk. I chose the Supercharger as the first, and the Harmony as the most sophisticated and for still being in production, so that's why I'm short on other dev-carts.

 

The different Flashbacks are something that I want to explain during the slides. The FB 2+ is mentioned together with the FB2. FB1 and FB3 didn't get on the slides because they do not resemble the hardware, as the FB2(+) tries to.

 

- There is no such thing as an AMD Cortex M3 .

D'oh! Fixed. An updated version will go online after a couple of fixes are in.

[GroovyBee]

No problem. I'll go thorough it again later.

[+SvOlli]

New version: fixed some typos like AMD -> ARM.

[GroovyBee]

Here goes (all page numbers reference the PDF ones) ...

 

2/89 - Change "to by a" into "to buy a".

4/89 - Change "how should" to "who should".

7/89 - Change "Ted Debney" to "Ted Dabney".

7/89 - The 2600 was official retired in the early 90s.

37/89 - I don't think Activision came from nowhere .

41/89 - Change "a game modify" to "a game and modify".

41/89 - Change "there even are even" to "there are even".

45/89 - Technically the SP register is 9 bits. Its most significant bit is fixed at '1'.

47/89 - RIOT cannot interrupt the 6507 the signal is not available on the CPU.

49/89 - PHI2 would have been a handy signal on the cart port too.

50/89 - I would say "read only" and "write only" instead of "read" and "write".

74/89 - It is safer to wait for the timer interrupt flag to be set. Depending on what divide by setting you set the timer to, you might miss it reaching a zero value while polling. If you poll for the interrupt flag you'll never miss it.

76/89 - Player sprites can also be reflected to face left or right.

76/89 - You can also change player and playfield priority.

84/89 - Stating "TIA is only capable of setting the audio line high or low" is not true. You can have multiple volume levels.for each channel.

87/89 - Harmony doesn't work like that at all. It polls for the address bus to be stable. When it is stabilises it then acts on it.

 

Sorry for being picky.

[Pioneer4x4]

I haven't looked at it yet, but shouldn't it be

7/89 - The 2600 was officially retired in the early 90s.

[GroovyBee]

I haven't looked at it yet, but shouldn't it be

7/89 - The 2600 was officially retired in the early 90s.

 

Yep! I'm sure Curt or Marty would know the official date.

[+SvOlli]

2/89 - Change "to by a" into "to buy a".

4/89 - Change "how should" to "who should".

7/89 - Change "Ted Debney" to "Ted Dabney".

37/89 - I don't think Activision came from nowhere .

41/89 - Change "a game modify" to "a game and modify".

41/89 - Change "there even are even" to "there are even".

50/89 - I would say "read only" and "write only" instead of "read" and "write".

76/89 - Player sprites can also be reflected to face left or right.

These have been fixed. Thanks. But for Atari, Activision came out of nowhere.

 

7/89 - The 2600 was official retired in the early 90s.

That statement was about the "game development company Atari" not the 2600, I changed it a bit hoping that less misleading now.

 

45/89 - Technically the SP register is 9 bits. Its most significant bit is fixed at '1'.

That's not correct: technically SP register is 16 bits. The upper 8 bits are hardwired to $01. Still by reading with TSX you'll only get an 8 bit offset to $0100, changed it to that.

 

47/89 - RIOT cannot interrupt the 6507 the signal is not available on the CPU.

That slide is about the RIOT, which is capable of sending timer interrupts. On the slide about the CPU it is stated that the interrupt lines are not available. I want to point this out during the presentation.

 

49/89 - PHI2 would have been a handy signal on the cart port too.

Yes, but there's only 1 line left from 2x GND, so I chose r/w.

 

74/89 - It is safer to wait for the timer interrupt flag to be set. Depending on what divide by setting you set the timer to, you might miss it reaching a zero value while polling. If you poll for the interrupt flag you'll never miss it.

Thanks for letting me know this. I'll change my timer wait code to this. And changed the slide to a more general "wait for timeout".

 

76/89 - You can also change player and playfield priority.

This is stated in the playfield chapter.

 

84/89 - Stating "TIA is only capable of setting the audio line high or low" is not true. You can have multiple volume levels.for each channel.

87/89 - Harmony doesn't work like that at all. It polls for the address bus to be stable. When it is stabilises it then acts on it.

These two will be changed later, as it can't be corrected by just changing 2 or 3 words.

 

Sorry for being picky.

Thanks for being so picky. That's what get the flaws out of the slides.

 

An updated version is uploaded.

[potatohead]

Please tell us how this all goes! Very curious to hear their reactions.

 

My comments:

 

+1 for "Video Computer System" My favorite reference.

 

Funny you position it as eff-ed up!

 

(well it is, but...)

 

My favorite observation of the VCS is the simple, software driven video has a very curious property. That is the smarter we get about using it, the better it delivers! The number of tricks learned and optimizations done over 30 years is stunning! Great story, and a great challenge.

 

More advanced systems are "baked in" capable of what they are capable of, but not generally as exploitable as the VCS is. To me, that's the coolest attribute, and a serious attraction to programming on it. In a very real sense, the display IS the game, because they are required to be woven together in ways not common elsewhere. I think you have most of that in there though.

 

Would be nice to mention Batari Basic. One can build a simple game and experience SOME of the VCS in a day. Cool beans, and a nice platform for stepping off into assembly land...

Edited December 19, 2011 by potatohead

[GroovyBee]

Would be nice to mention Batari Basic.

 

It gets a mention too.

[potatohead]

Well dang! I didn't see it the first time.

[Rybags]

Agreed on the "VCS" reference - that was the original name and probably how most people remember it (ie those who were fans of the thing in late 70s/early 80s).

 

Might also be worth pointing out clones authorised or not, which probably increases the number of phyisically different incarnations beyond 20.

[SeaGtGruff]

Slide 51 has a typo:

 

Exact mapping: xxx0 xxFx 1NNN NNNN

 

It should be:

 

Exact mapping: xxx0 xx1x 1NNN NNNN

[SeaGtGruff]

On slide 84, the NTSC base frequency (according to schematics) should be 3579575 Hz.

 

3579575 Hz / 114 = 31399.78 Hz

 

The PAL base frequency is 3546894 Hz.

 

3546894 Hz / 114 = 31113.1 Hz

[+SvOlli]

Exact mapping: xxx0 xxFx 1NNN NNNN

 

It should be:

 

Exact mapping: xxx0 xx1x 1NNN NNNN

Nope, this is correct, as the "F" selects the function, either RAM (F=0) or IOT (F=1).

 

On slide 84, the NTSC base frequency (according to schematics) should be 3579575 Hz.

[...]

Thanks! I didn't know where to get the exact values, so I took the sound base frequencies from the manual and multiplied them with 114.

 

The first two audio slides will be done from scratch again, and maybe extended into three, if necessary.

[GroovyBee]

Nope, this is correct, as the "F" selects the function, either RAM (F=0) or IOT (F=1).

 

Personally, I'd use a different letter so that it doesn't look like you are mixing hexadecimal and binary.

[+SvOlli]

Please tell us how this all goes! Very curious to hear their reactions.

You can watch them yourself. The will be a live stream and that stream will be recorded as well. The later one I will post here. If you want to watch live, google for "28c3 live stream" or something like that.

 

Funny you position it as eff-ed up!

 

(well it is, but...)

The only other system I went in depth this far is the Commodore 64.

 

So here's some stuff I did expect, when I got the idea of digging through the manual.

- an easier way to sync precisely than on the C=64 (got that, sta $02)

- the registers are programmed line by line (got that as well, but from here I didn't get what I expected)

- the background is organized in some comprehensible way (it isn't, ordering changes from register to register)

- sprites are positioned by writing the X value to a register (the combo of RESxx, HMxx and HMOVE is nothing that I could ever thought of)

- the "write" registers can be re-read (the read register has nothing to do with the write register at the same address)

 

And these are only the big ones, I came up with in the first 5 minutes.

[+Andrew Davie]

This is excellent. Good luck with the talk!

 

I have a few comments.

 

1) It might be useful to mention that not only are there only 128 bytes of RAM, but this RAM is also used for the processor's call stack.

 

2) on slide 45 you reference the SP as offset to $100. This is not correct for the '2600. The stack is located at 0 -- sharing zero page RAM with the programmer

 

3) On slide 44 you say "opcodes take 1-3 bytes". Actually, opcodes are only one byte. It's the operands that are an additonal 1-2 bytes. So you'd be better saying that "instructions" take 1-3 bytes.

 

4) on slide 46, you reference 8K of addressing. But isn't this actually only 4K on the '2600?

 

5) on slide 47 you mention that the timer sends interrupts. This is incorrect. You have to manually poll the timer to tell when time is up.

 

6) on slide 63 the arrows comparing 1 clock cycle to 3 colour cycles is VERY misleading, as they are not to scale, drawn on top of a screen representation. This needs reworking to a separate slide, or an inset.

 

7) on slide 68, you should really indicate that the resolution is 20 bits, repeated twice (not 40 bits). To get 40 bits you have to modify on-the-fly during the middle of scanline draw.

 

you should include Boulder Dash® as an example of playfield draw lol.

 

 

Hope some of these help you out.

Cheers

A

[cd-w]

Minor point on slide 87. The Harmony cart does not use interrupts as they are too slow on the LPC2103 (ARM7TDMI) processor. Instead A12 is continuously polled for changes as follows:

1. Poll A12 until it goes high
   
2. Read address on bus
   
3. Lookup address in ROM image
   
4. Output byte on data bus
   
5. Wait for address bus to change
   
6. Float data bus
   
7. Goto 1
   

The complexity of this approach is that the Atari must be kept busy when the cart is doing other things (such as reading the SD card), or it will crash. The solution that Fred and myself came up with was to make the Atari execute code directly from its own RIOT RAM during these operations!

 

I'm interested to know more about your own development cart. The Cortex M3 wasn't yet available when we developed Harmony.

 

Chris

[+SvOlli]

This is excellent. Good luck with the talk!

Thanks!

 

1) It might be useful to mention that not only are there only 128 bytes of RAM, but this RAM is also used for the processor's call stack.

 

2) on slide 45 you reference the SP as offset to $100. This is not correct for the '2600. The stack is located at 0 -- sharing zero page RAM with the programmer

Take a look at slide 52: the CPU accesses the stack at page $100, but this is just a mirror from the zero page. And it is also stated explicitly in the quote from the manual that the 128 bytes of RAM is shared.

 

3) On slide 44 you say "opcodes take 1-3 bytes". Actually, opcodes are only one byte. It's the operands that are an additonal 1-2 bytes. So you'd be better saying that "instructions" take 1-3 bytes.

That's a good idea. Done.

 

4) on slide 46, you reference 8K of addressing. But isn't this actually only 4K on the '2600?

Nope, take a look at slide 48. The CPU addresses 8K: 4K IO-space with RAM and 4k of ROM.

 

5) on slide 47 you mention that the timer sends interrupts. This is incorrect. You have to manually poll the timer to tell when time is up.

It's a description of the chip which is _capable_ of sending interrupts, but it is not connected. I wanted to state this in the lecture. But since it's the second time that this topic is mentioned, I put that remark also on the slides.

 

6) on slide 63 the arrows comparing 1 clock cycle to 3 colour cycles is VERY misleading, as they are not to scale, drawn on top of a screen representation. This needs reworking to a separate slide, or an inset.

Thanks for the note. I resized the arrows to fit scale (20 CPU clocks, 60 color clocks)

 

7) on slide 68, you should really indicate that the resolution is 20 bits, repeated twice (not 40 bits). To get 40 bits you have to modify on-the-fly during the middle of scanline draw.

That indication is done in the following slide. I changed it to "How to squeeze this 40 bit resolution into 3 bytes?"

 

you should include Boulder Dash® as an example of playfield draw lol.

I wanted to stick to the commercial titles... I also wanted to have a examples that can be easily explained to the audience.

 

Hope some of these help you out.

Indeed they do.

 

A new version is uploaded. It contains several small fixes as well as a new font.

 

Still to be done:

- rework first two audio slides

- rework dev cart slides

- find a better letter for "F" in RIOT mapping xxx0 xxFx 1NNN NNNN

 

I also put up http://svolli.de/dow...8c3intro.bin.gz , the ROM I intend to run prior to the talk as the room fills. (If they let me.) If you want to run it on real hardware keep in mind, that it is coded for my PAL system.

 

BTW: I've got 45 minutes for the talk + some minutes for questions. My guess is that going through the slides at normal speed will take 60 minutes.

[GroovyBee]

A couple of other missing functions on RIOT are :-

 

- Port A bit 7 can be used as an edge detecting input that triggers an interrupt.

- Port B has push-pull outputs which enable it to drive transistors directly.

[cd-w]

BTW: I've got 45 minutes for the talk + some minutes for questions. My guess is that going through the slides at normal speed will take 60 minutes.

 

The usual guide is 1 slide for every 3 minutes. Don't make the classic mistake of going through the slides very quickly - you'll just leave the audience struggling to understand anything at all. Better to trim it down to the important points and make the rest available online for people who want to know more.

 

Chris

[+SvOlli]

The usual guide is 1 slide for every 3 minutes. Don't make the classic mistake of going through the slides very quickly - you'll just leave the audience struggling to understand anything at all. Better to trim it down to the important points and make the rest available online for people who want to know more.

The talk will be recorded and the video will be freely available, like the talk that inspired me to do mine, the ultimate Commodore 64 talk: http://media.ccc.de/...re_64_talk.html

 

So for this I want to cramp in as much as possible. Well, not as much as impossible. And I'm pretty sure, that I don't get shot if the talk ends after 50 minutes.

 

For the first part there slides, like the different cases for the 2600, that will be faster than the 2 slides / minute that I need to do in average. Most diagrams will show up animated, bit by bit, so that the viewer won't get hit with the information all at once.

 

So my guess is, that this one should work. I probably won't make it in 45 minutes, but in something like 50, which should also be ok.

 

I'll know more on the 27th.