The 7800 and me

[opcode]

It is some time in 1984, I am about 13 years old and was checking some import magazines (I was in Brazil), when I find an issue of Enter (or something like that). Actually I was attracted by the cover, a picture of the Enterprise from the brand new Star Trek III. I start checking the magazine and find an article about the soon to be released Atari 7800. It was a total surprise, but I was delighted. I couldn't believe my eyes, some of the games looked really arcade quality.

I dreamed about it for a while (even if it had been widely released in 84, living in Brazil I could only dream about getting one), but then moved to computers and didn't heard or think much about it again until...

Fast forward to late 80s, I got a Nintendo magazine and find a few ads for stores selling 7800 games. So they actually released it, I thought. But again, living in Brazil I could only dream of getting one, and even if I could, was it still relevant? I think I was totally into Nintendo…

Fast forward again to late 90s (or was it early 2000s?) and the first 7800 emulator is released. Finally I was going to be able to try the thing. Downloaded some games and fire up the emulator. Hm, perhaps it was my impression from the 80s, I was just expecting too much. A few games later I wasn't really impressed. Never touched it again.

Fast forward to a few weeks ago. I was looking for a 2600 so that I could play some games I have here (I have many 2600s but I left them all in Brazil). Go to a flea market and find a 7800 instead. It was in good condition and price was right (about $20). Decided to take it home, I could play 2600 games anyway. Got two games with it, Pole Position II and Xevious. A few games later I was hooked, nothing like playing real hardware on a real TV. PP II is a blast, truly excellent. Xevious is excellent too, looks a bit zoomed in but a top notch port nevertheless. I decide to get the remaining 10 games from 84 (the 10 arcade ports, Desert Falcon and Ballblazer). All ports are excellent, except maybe for Galaga. Desert Falcon is so-so, not really the Zaxxon killer it obviously was intended to be. Ballblazer I never cared about, but the 7800 version looks indeed superior to all other versions. The Atari Corp games I really don't care.

 

So all the long story to say that I couldn't resist trying to program the machine. I remember that Curt tried to convince me to do something for the 7800 years ago, but once I checked the docs I thought, he must be kidding me, this is very weird hardware. Well, now that I am more willing I just gave it another try and I actually produced a simple background and sprite driver. Then I decided to take it more seriously and port some arcade game, so I chose Millipede. Native 6502 code, simple game, I could use it to get warmed up on the 7800 (and before the ColecoVision crowd decide to kill me, I must say that I plan to use it as an learning opportunity to start porting some 6502 based arcade games to the CV too).

So as usual for my arcade ports I like to use actual arcade code. I am disassembling Millipede. The question is, can the arcade code run on the 7800 after Maria has eaten up all her clock cycles? I had never to worry about that with the CV, but I am willing to find out...

 

Anyway, so far I see two approaches for the graphics:

1) Using 4 pixel wide "tiles", just like the 7800 Centipede. That is the easiest solution, as 4 pixels are a byte, and I can use indirect mode. Millipede is 240 pixels wide, but tiles are 8 pixels, for a total of 30 "tiles" horizontally. In 7800 resolution that means 120 pixels, or 3/4 of the screen, just like 7800 Centipede.

2) Using 6 pixels wide "virtual tiles". That has the advantage of giving graphics a little more detail (and make the game full screen). Disadvantages are that the graphics will look a bit stretched, it will require a little bit more processing to deal with those virtual tiles (6 pixels isn't trivial for indirect mode), and of course Maria will use more cycles (33% more). So I am not totally sure it is a viable option, but I can at least try.

 

I actually want to try solution 2 first because that would be useful for future games, like let's say, Moon Patrol.

 

Eduardo

Edited May 2, 2010 by opcode

[Bakasama]

You're developing for the 7800? Cool! So does that mean we're finally going to get a superior version of Donkey Kong?

 

So as usual for my arcade ports I like to use actual arcade code. I am disassembling Millipede. The question is, can the arcade code run on the 7800 after Maria has eaten up all her clock cycles? I had never to worry about that with the CV, but I am willing to find out...

 

I think you should ask GroovyBee about that. I think there's a lot you want to ask him about.

[Underball]

You're developing for the 7800? Cool! So does that mean we're finally going to get a superior version of Donkey Kong?

 

So as usual for my arcade ports I like to use actual arcade code. I am disassembling Millipede. The question is, can the arcade code run on the 7800 after Maria has eaten up all her clock cycles? I had never to worry about that with the CV, but I am willing to find out...

 

I think you should ask GroovyBee about that. I think there's a lot you want to ask him about.

THIS WOULD BE KILLER!!!

[Atarifever]

This is great. This is like finding out you're getting Activision support for your system. 1982-Activision support! Consider a copy sold.

[opcode]

Donkey Kong (arcade) uses 4KB of RAM, and that is all the memory the 7800 has. While I would add RAM to the cartridge, it is better to wait for Curt's expansion module, which also gives us Pokey sound.

The ColecoVision has the advantage of the resolution, which is usually more "arcade friendly". The 7800 on the other hand offers flicker free sprites and more accurate colors. Which one would play better I am not sure, the 7800 would run in 3/4 compressed mode (just like my version of Pac-Man Collection for the ColecoVision), but if well handled that shouldn't be an issue. A 7800 advantage would be the screen vertical resolution, supposing I can use 224 scanlines that would be enough to give us arcade perfect dimensions. On the other hand the graphics would look a bit stretched (though not as bad as the existing port from Atari), while the ColecoVision can keep the horizontal proportions better.

So advantages and disadvantages on both systems, but I suppose both would be good enough to satisfy the most demanding DK fans.

During MGC there was an arcade expert guy (I don't remember his name), he stopped by and played Donkey Kong Arcade for a while (on the ColecoVision) and he was impressed how accurate it was. He shown me tricks I didn't ever know about, but they all worked on my port (actually he did the same with Pac-Man Collection, a couple of tricks I had never seen, all worked).

 

Eduardo

[Jet-X]

Eduardo, great info, would love to see what you can accomplish on the 7800.

[Bakasama]

Donkey Kong (arcade) uses 4KB of RAM, and that is all the memory the 7800 has. While I would add RAM to the cartridge, it is better to wait for Curt's expansion module, which also gives us Pokey sound.

 

The reason I brought that up is because it's one of the most requested update/hacks for 7800. Players were pretty disappointed with the sound and the lack of the pie factory.

[Lord Helmet]

Oh man...Opcode developing for the 7800? Is it April 1st??

[TrekMD]

It would be awesome to have an upgraded Donkey Kong that included all 4 screens and with Pokey sound! I hope this becomes a reality!

[GroovyBee]

Anyway, so far I see two approaches for the graphics:

1) Using 4 pixel wide "tiles", just like the 7800 Centipede. That is the easiest solution, as 4 pixels are a byte, and I can use indirect mode. Millipede is 240 pixels wide, but tiles are 8 pixels, for a total of 30 "tiles" horizontally. In 7800 resolution that means 120 pixels, or 3/4 of the screen, just like 7800 Centipede.

 

Depending how many colours you want the 8 pixel wide sprites in the "background" to be you could consider 320A or 320B and centre the display accordingly. Effective use of this mode also depends on how many sprites you want to overlay over an indirect display before you run out of MARIA video cycles.

 

2) Using 6 pixels wide "virtual tiles". That has the advantage of giving graphics a little more detail (and make the game full screen). Disadvantages are that the graphics will look a bit stretched, it will require a little bit more processing to deal with those virtual tiles (6 pixels isn't trivial for indirect mode), and of course Maria will use more cycles (33% more). So I am not totally sure it is a viable option, but I can at least try.

 

If you move to 160B (4BPP) for this mode you can have 6 pixel wide sprites (with 3 bytes CWIDTH=0) in indirect mode easily. However if you want lots of sprites moving over a 160B "background" its not the graphics mode to use because you won't get many before MARIA runs out of video cycles.

[opcode]

Here is my take on this:

 

1) Indirect mode 160 2bpp for background, direct mode 160 2bpp for sprites (16 sprites max)

This is how Centipede for the 7800 works. We would need around 246 cycles for the background (26 tiles wide) and 176 cycles for the sprites (4 pixels wide, which isn't actually always the case, but anyway), for a total of 447 cycles including startups, etc. But that is the worst case, all the sprites in the same scanline. In the best case (no sprites in the scanline), we need around 270 cycles. That is about 60% of all cycles available per scanline, and in the worst case it is about 100%, pretty heavy burden for the CPU.

Detail, in this mode background "tiles" are 4 pixels wide.

 

2) Direct mode 160 2bpp for both background and sprites (16 sprites max)

Now this is only possible if we have lots of RAM, actually 8KB for the framebuffer, but let’s suppose we have it.

In this case we would need only 133 cycles for the background (using two big sprites with data from the framebuffer). Sprites are the same as solution 1, so 176 cycles. Total including everything is 334 cycles in the worst case. Best case (no sprites in the scanline) is 158 cycles (or 35%, 74% in the worst case).

That is a major improvement over solution 1, and it has a second advantage, we are using "tiles" 6 pixels wide, so the game will cover the whole screen and will give us some extra detail.

Disadvantages: it requires lots of RAM, and there is some extra CPU effort to keep the frame buffer (copying data to framebuffer, masking stuff, etc). However the background isn't updated that frequently, so that shouldn't be a big problem. But such overhead needs to be investigated further before any decision is made.

 

Other modes like direct or indirect 320 2bpp aren't possible because there aren't enough Maria cycles, colors, etc. Framebuffer 160 4bpp would require less cycles in the worst case, but more than twice in the best case, which is the case most the time. Besides, there would be a lot of overhead managing the virtual sprites and we would be limited to 13 colors.

 

So I am inclined to go with solution 2, but I still need to think about the cost of managing the framebuffer.

 

Eduardo

[GroovyBee]

1) Indirect mode 160 2bpp for background, direct mode 160 2bpp for sprites (16 sprites max)

 

I don't agree with your computation for the MARIA cycles used.

 

I get 164 cycles for indirect mode background in 2BPP. If each segment of the millipede is a 4 pixel wide sprite I get 176 cycles making a total of 340 cycles. You have 417 MARIA cycles worst case so MARIA utilisation is at 81%. If you pre-shift millipede segments and store them as characters MARIA utilisation will drop to 39% because you don't have the extra overhead of the sprites when you write the millipede data into the character RAM buffer.

 

2) Direct mode 160 2bpp for both background and sprites (16 sprites max)

 

A frame buffer would need 136 MARIA cycles in 2BPP no matter how many software sprites you used.

 

Other modes like direct or indirect 320 2bpp aren't possible because there aren't enough Maria cycles, colors, etc. Framebuffer 160 4bpp would require less cycles in the worst case, but more than twice in the best case, which is the case most the time. Besides, there would be a lot of overhead managing the virtual sprites and we would be limited to 13 colors.

 

I have used indirect mode in 320A/320B modes with no problems. In 160B mode you can have 26 colours per scan line. More if you use DLIs to change one or more colours per scan line.

 

Have a look at my Worm! or Apple Snaffle games to see 160B mode in use.

[opcode]

I don't agree with your computation for the MARIA cycles used.

 

I get 164 cycles for indirect mode background in 2BPP. If each segment of the millipede is a 4 pixel wide sprite I get 176 cycles making a total of 340 cycles. You have 417 MARIA cycles worst case so MARIA utilisation is at 81%. If you pre-shift millipede segments and store them as characters MARIA utilisation will drop to 39% because you don't have the extra overhead of the sprites when you write the millipede data into the character RAM buffer.

 

Ok, let me see if I am getting this right.

First we agree on the number of cycles for sprites, good.

For the background, indirect mode, 160 2bpp. We have a header (12 cycles). Then we have 40 graphic reads * 6 cycles (240 cycles). Finally we have 40 character map accesses * 3 cycles (120 cycles). Total = 372 just for the background.

 

 

2) Direct mode 160 2bpp for both background and sprites (16 sprites max)

 

A frame buffer would need 136 MARIA cycles in 2BPP no matter how many software sprites you used.

 

Yeah, but 2bpp gives me only 4 colors per scanline with software sprites, not very useful. I was thinking of a framebuffer for the background, plus 16 Maria sprites.

 

I have used indirect mode in 320A/320B modes with no problems. In 160B mode you can have 26 colours per scan line. More if you use DLIs to change one or more colours per scan line.

 

Yeah, I know. What I was trying to mean is that you would barely have enough cycles for any sprites.

 

Have a look at my Worm! or Apple Snaffle games to see 160B mode in use.

 

Sure, I will.

 

Eduardo

[GroovyBee]

Ok, let me see if I am getting this right.

First we agree on the number of cycles for sprites, good.

For the background, indirect mode, 160 2bpp. We have a header (12 cycles). Then we have 40 graphic reads * 6 cycles (240 cycles). Finally we have 40 character map accesses * 3 cycles (120 cycles). Total = 372 just for the background.

 

Sorry! I made a mistake in the maths earlier You need :-

 

2 x 5 byte headers (32 bytes in one, 8 in the other) at 10 cycles each making 20 in total.

40 x (3 cycles for indirect access + 3 cycles for 1 byte of graphics data).

 

260 cycles in total.

 

Yeah, but 2bpp gives me only 4 colors per scanline with software sprites, not very useful. I was thinking of a framebuffer for the background, plus 16 Maria sprites.

 

OK. Makes more sense now.

[opcode]

Sorry! I made a mistake in the maths earlier You need :-

 

2 x 5 byte headers (32 bytes in one, 8 in the other) at 10 cycles each making 20 in total.

 

The software guide I have says 12 cycles each. Which one is the correct value?

 

40 x (3 cycles for indirect access + 3 cycles for 1 byte of graphics data).

 

260 cycles in total.

 

Have you ever checked that? Because as I understand from the software guide, you need 3 cycles to read the character map, then knowing the character you need 6 extra cycles to read 1 byte of graphic data.

On the other hand I accept that it would actually mean that 1 byte in indirect mode takes 6 cycles total, and that 3 cycles per character map access is there just for the sake of completeness (though the software guide separate between graphic read (actual graphic data) and character map access). That is why I am asking if you have ever verified those values, like created a demo or something to check both cases.

Of course I would be happier if your math is the correct one, because that would make the indirect mode more attractive.

 

Eduardo

[GroovyBee]

Have you ever checked that? Because as I understand from the software guide, you need 3 cycles to read the character map, then knowing the character you need 6 extra cycles to read 1 byte of graphic data.

 

Its 8 cycles for a 4 byte DL header and 10 cycles for a 5 byte DL one.

 

You only need 6 cycles if CWIDTH=1 in CTRL. When that bit is set MARIA reads 2 consecutive bytes of graphics data per indirect access.

 

Get the GCC guide to MARIA from Curt's Atari Museum site. The one from Atari has several mistakes.

 

Of course I would be happier if your math is the correct one, because that would make the indirect mode more attractive.

 

I'm pretty sure its correct. I've used indirect in a few games .

[opcode]

Get the GCC guide to MARIA from Curt's Atari Museum site. The one from Atari has several mistakes.

 

That is what I am using, 3600 Software Guide Rev 2, 10/19/83, GCC.

 

EDIT: Ok, I see now, you mean the Maria specs. Great, thanks.

 

Eduardo

Edited May 7, 2010 by opcode

[GroovyBee]

That is what I am using, 3600 Software Guide Rev 2, 10/19/83, GCC.

You are better off with this one :-

 

http://www.atarimuseum.com/ahs_archives/archives/pdf/videogames/7800/gcc1702b_maria_specs.pdf

 

Its the one I use all the time.

[GroovyBee]

Hang on! I thought the screen was 26, 4 pixel characters wide and not 40? If its only 26 then you'll use 166 MARIA cycles. I thought I was wrong but not that wrong .

[+Mitch]

I have a small errata file for corrections to the 7800 dev docs here. If you guys find any other errors it would be great to add them to the list so future programmers don't have to find the errors out the hard way.

 

Mitch

[DracIsBack]

What'chya workin' on, Opcode ....?