DanBoris

I appreciate Vigo and Gorf's passion for this topic but lets try to tone it down a bit and get back to more level headed discussion of the topic. I have actually found this topic quite interesting because if I were asked which was more powerful before this I would have said 7800 without hesitation, but I now see that these two system are a lot closer then I thought. Resolution is an interesting question. Going by the specs Colecovision can do 256 pixels horizontal and the 7800 can do 320, but the 320 pixel modes can take up a lot of graphics processor bandwidth and have limited colors. For this reason most 7800 games use the 160 pixel mode. So the 7800 has a theoretical higher resolution, but the Colecovisions lower resolution is more useful. This actually highlights the difficulty of comparing systems. We all know that specs are only a small piece of the puzzle since most system can be pushed to do things that it's not apparent they could do from their specs. We can also demonstrate a systems capabilities by doing tech demos, but these don't tell the whole story either. Just because you can demonstrate something in a tech demo doesn't mean it would actually be practicle in a game. I can do demo on the 7800 that shows a 320 pixel wide display with 4 colors per line and bi-directional fine scrolling, but I probably couldn't build a game on top of it. The only way to really settle these things for sure is to try to implement certain games on each system to see what how they come out. Dan

I looked at this to and never saw a point where the valleys of the upper hills went below the peaks of the lower. By not doing that is does simplify the scrolling.

Out of curiosity I dug into Matt Patrol to see how they did it. I build a special version of MESS with the sprites disabled to see what was sprites and what was character maps. I was surprised at how much was characters. Not surprisingly both sets of mountains and the ground are characters, but the moon buggy with the exception of the wheels is also character graphics. The rocks are characters as well as the holes with the exception of the detail around the edges which must be a sprite. Dan

On the 7800 a single character can be anywhere from 1 to 16 lines high, and 1 or 2 bytes wide where each byte can be either 2, 4, or 8 pixels wide depending on the graphics mode you are using. So a character could be 2, 4, 8 or 16 pixels wide. As for "sprites", all the graphics the 7800 generates could technically be considered sprites since no one object will interfere with any other object. Because of this you could generate a sprite of pretty much any size. I think using a combination of real hardware and emulators for development gives you the best of both worlds. You really need the real hardware to be sure things will actually work, but the emulator is more convenient and in the case of MESS, which is the emulator I use, it give you access to a really nice debugger. Dan

I just posted an new entry in my Blog describing a demo of horizontal and vertical fine scrolling I created. I've included the full source along with a compiled version that can be used with an emulator. Dan

I’ve recently been doing some research into how scrolling games work on the 7800. I have created a demo program that shows a method for doing horizontal and vertical fine scrolling controlled with the player one joystick. I’ve tested this program on an emulator but on the actual hardware. The attached ZIP files contains the source and binary that can be used with an emulator. Display List The display list for the demo consists of 24, 8 line high regions. Each region will display 41 characters in the 320D mode using indirect graphics. Each region has two DL entries one to display the first 20 characters, the second to display the remaining 21. Two DLs are needed because you can’t display more the 32 characters with a single DL. Horizontal Scrolling The horizontal scrolling turns out to be pretty easy because of the way the 7800 handles wrap around of the graphics. A horizontal position of 0 – 159 is visible on the screen but anything beyond 159 won’t be displayed. If you position a graphic with an hpos just below 255 the beginning of the graphic won’t be displayed but the rest will. So to do horizontal scrolling it’s simply a matter of changing the hpos of the two dl entries on each line. You will notice that the second DL entry has 21 characters instead of 20. This is necessary because even though the screen is 40 characters wide 41 different characters will be displayed during scrolling with partial characters at either end of the line. Vertical Scrolling Vertical scrolling is a little trickier. Here we need to end up with partial characters at the top and bottom of the screen during scrolling. The cropping of the top row can easily be handled by varying the height of the top region between 1 and 8 lines. As the top region gets smaller the bottom region will needs to get bigger so its height is set to (8 – top region height). Simply changing the height of last region won’t actually give us the result we need, because as the region get smaller the top of the characters will be cropped off not the bottom. To compensate for this we need to adjust the character base pointer for just the last zone. For each line smaller we make the last region we need to move the character base pointer up one page. We can achieve this using a display list interrupt on the last zone to set the modified character base, then another one in the next zone to get it back to the default. Course Scrolling Note that what I am demonstrating in this program is just fine scrolling. Once I have scrolled a full character width or height in a specific direction I reset the scrolling back to the start of the character. It gives the appearance of continuous scrolling but I am really just repeatedly scrolling over the same characters. You could layout the entire character map for a screen in RAM or ROM then scroll the screen over that map. When you reached the end of a fine scroll you would reset the scroll and then update all the memory pointers in the display list to course scroll to the next row of column of the map.

Yes, you if you setup the display correctly you could display a full screen bitmapped image. Take a look at the title screen for Scarpyard Dog for example. Yes, you never really have to worry about erasing graphics. Each graphic "object" that Maria renders is drawn independantly to the screen so they can all freely be moved over each other without one destroying the other. Yes, and no. You do have to do a lot more manual memory management then you do in Basic, but the assembler will do some of it for you. You need to at least define where different blocks of memory start. So for example if I have a bunch of variables I need to store you could use this assembler directive to start the region: org $40 This tells the assembler to start this region at address $40. Then you can define the variables like this: xpos ds.b 1 ypos ds.b 1 temp ds.b 1 This will assign one byte for each of those variables. You don't need to worry about the exact address of each one, you just refer to it by name. So to store the accumulator in xpos you would just do: sta xpos The assembler will take care of putting in the correct address. Now on a larger scale there is a lot of work involved with deciding where to put things in memory, especially when programming the 7800. You are going to have to manage the Display List List, the individual display lists, the graphics data, as well as the variables used in your program. With the limited RAM in the 7800 this can get a little tricky. Dan

The documents you posted earlier in this thread have pretty much everything you need to know to program the 7800. I noticed the links are broken to those files now, but they can be found at other places. The 7800 is definitely an interesting console to program. I wrote a 7800 emulator back in 1999 and even though this gave me a pretty good understanding of the hardware I just couldn't understand how to use that hardware to actually produce game graphics. The breakthrough for me came when I realized that you need to create a layer between the game logic and the hardware. For example to handle the sprites in a game you would create a table in RAM that holds the information for each sprite including things like the x and y position, index to the image to display, the animation frame, etc. You would then call a routine in your graphics engine that would translate the data in that table into the actual display list entries. In this way you can build pretty much any type of graphics engine you want on top of the raw video hardware. Dan

I remember buying a really bad Berzerk knock off that I can't remember the title of. It was done in Basic and used a redefined character set in the normal text mode so everything moved in these big character sized jumps. It was really horrible. ... Just looked through Atarimania and found it, Intruder Alert by Dynasoft. I fired in up in an emulator and it's actually worse then I remember it!

I recently took a look at Matt Patrol, the Moon Patrol port for the Colecovision and the parallax scrolling it does is very impressive. I really didn't think that was possible on the Colecovision's hardware. Any idea how it was done? Dan

The comparison between the Colecovision and the 7800 is a tricky one. The 7800 can do a 320 pixel wide display as compared to the Colecovision's maximum of 256 pixels, but the 320 mode is tricky to use in actual practice so most games use the 160 pixel wide mode. In the 7800's favor the 160 modes give you a lot more colors in a single sprite then the Colecovision can do, so the Colecovision will have higher resolution sprites, but the 7800's will be more colorful. I think where the 7800 has the clear advantage is in scrolling capabilities. The Colecovision does have a few nice scrolling games but due to the way it's video hardware works there are a lot of limitations on how scrolling can be done. I took a look at the few games that the two systems have in common and to me it's a toss up. Donkey Kong looks better on the Colecovision to me, but the graphics on the 7800 version are actually a little more detailed. On the other hand Choplifter looks much better on the 7800 with more colors used in the sprites. Dan

I just played Matt Patrol the prototype of Moon Patrol for the Colecovision and I have to say it's very impressive. Does anyone have any ideas on how the paralax scrolling was done? From my understanding of the Colecovision graphics hardware I didn't even think this was possible. Dan

"less powerful" and "more powerful" are kind of sweeping, all or nothing statements. Not sure what you mean here. In terms of raw processing power, don't the 7800 and 8-bits use the same physical microprocessor? Or are you comparing MARIA with GTIA capabilities? If so, can you elaborate on GTIA's enhancements? They both use 6502 processors running at 1.79 Mhz so they are equal in that respect. To do 3D polygon games you would have to use a bit mapped display so the special video hardware in each machine wouldn't really gain you much. Manipulating a bit mapped display on the 8-bits is actually easier then on the 7800. All the 7800 graphics are actually sprites, to do backgrounds your just create a sprite that is as wide and tall as the screen. Due to the way the graphics data is normally handled in the 7800 all the data for the bitmap would not end up in a nice contiguous block of memory which would make plotting to that bitmap a lot more complex and thus slower. With that said my guess would be that the 7800 probably couldn't do much better with polygon graphics then the 8-bits could. Dan

I found another problem in the code that would prevent it from working. I am not sure what I was doing when I put that code together! I have put the updated version on my web page: http://www.atarihq.com/danb/a7800.shtml Dan

Your command line is correct, it's my code that is wrong! Replace this line: SEG.U code with this SEG code The .U tells is not to generate anything in the output file. I am not sure how I managed to compile this in the past. Dan

Hard to tell what it might do with out seeing the code for the subroutine call.s Dan

The timer (which is actually in the 6532 RIOT chip) is really important in 2600 programming but is generally not used in the 7800 because the clock speed to the 6532 shifts from 1.79Mhz to 1.19 Mhz when you read/write to it which would throw off the timing of the clock. Dan

GCC also did the Food Fight arcade game for Atari which was based on the 68000 processor. I wonder if they intended to use the 1722 version in arcade games? Dan

I just posted a description of the "hidden" 7800 control register in my Atari Age Blog.

Occasionally questions come up about the special “hidden” control register in the 7800, and I usually end up searching back through the forum archive for the answer, so I thought I’d finally document it somewhere I can find it! The purpose of this control register is to switch the 7800 from 7800 mode to 2600 mode. The register can be written to using any address between $0000 and $001F. This address range overlaps the TIA so once the register is set you need to set the lock bit (see below) before you can use the TIA. There are 4 bits in the register and they work as follows: Bit 0 (lock mode) – When set to 1 this bit locks the control register so that no more writes will affect it. The only way to clear the lock is to power cycle the console. Bit 1 (MARIA Enable) - 1 = enable MARIA (also enables system RAM), 0 = disable MARIA (only RIOT RAM is available). 0 also disables the EXTRAM signal from the expansion connector. Bit 2 (EXT) - 0 = enable BIOS at $8000-$FFFF, 1 = disable BIOS / enable cartridge Bit 3 (TIA-EN) - 1 = enable TIA video pull-ups (video output is TIA instead of MARIA) and also disables 2 button joystick mode, 0 = disable TIA video pull-ups (video output is MARIA instead of TIA). Besides the functions controlled by the register bits, it also controls the HALT input to the 6502. When the 7800 is first powered up HALT is blocked from getting to the 6502, but after 2 writes to the control register (the data written doesn’t make a difference), the HALT input will be enabled. I am not sure why this function exists. I can only speculate that it’s to prevent the MARIA from spuriously halting the 6502 until it’s properly initialized.

I've never actually seen any official documentation about this control register, but it's function has been deciphered from the schematics, you can find it in this post: Control Register Note that you should never have to do this in your own cartridges becuase the BIOS will detect the 2600 cart since it doesn't have the signature and lock the system into 2600 mode before starting the cartridge code. Also, one minor correction, the encryption signature is stored in ROM, not RAM. It is at FF80-FFF9 as you say. Dan

The second PCB contains the disk controller chip (the FD1771B) and it's supporting circuitry. You can find the schematics here: http://www.jsobola.republika.pl/schematy.htm Note that this board doesn't control the movement of the head stepper, this is done directly from the IO port on the 6532 chip in socket A104. When you hear the sound from the stepper motor is the head already at the start of end of it's travel? If it is, I would turn off the drive and manually move the head to somewhere in the middle then turn the drive back on and see if it moves the head to the end of it's travel. Note that the 810 doesn't have anything that senses whether the head is at the start or end of the travel. When the drive is turned on it just tries to move it for a period of time to be sure it's as far as it can go. If the drive can't move the head then it could be a problem with the 6532, the +12V from the power supply, transistors Q106-Q109 or diodes CR101 - CR104. Dan

Atari Star Wars in the cockpit cabinet.

Not to mention the bonus clock will run out and you'll die Anyway since you lose about a 100 pts every 2 seconds as it winds down, and you only get a random 100-300 pts a barrel whenever one comes to you, it doesn't really help too much milking points that way Shows you how much I have played Donkey Kong, never even noticed to count down bonus! Dan

Also, you can sit on one level for quite a while jumping over barrels to increase your score. At some point you do have to move on because the number of barrels and fireballs on the level will make it to hard.