EricBall
-
Posts
2,427 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by EricBall
-
-
I also think the "why composite video?" issue should be addressed. Why take the digitial signals generated on the FPGA board and convert them to interlaced analog composite when you natively have RGB ? Just so you can reuse a cheapo SNES cable and connector? On top of that, they lug a composite tube monitor from Cali to New York as a display when a DVI to HDMI adaptor and a much lighter LCD TV would have sufficed.
Composite is (relatively) easy and cheap. You can generate NTSC output with little more than a microcontroller and a resistor DAC for an output stage. HDMI OTOH is more difficult requiring dedicated silicon and licensing fees. However, VGA is just as cheap and easy as composite video and would be a logical intermediate step for HDMI.
-
1
-
-
There's no hardware mirroring or scaling of sprites on the 7800, so you'll need to create separate graphics for each. Yes, you could do it programmatically, but that would burn CPU time and some RAM. Better / easier to simply make multiple sprites. (Palette tricks, however, can be used.).
-
1
-
-
Games on the 2600 tend to be written around the display kernel. i.e. structuring game data to minimize the number of cycles required in the display kernel. Similarly, on the 7800 there is value in ensuring game data is structured so the display lists may be created as efficiently as possible. So look at your display list builder code and ask yourself "how can i make this faster?".
I'd also order the code as:
1. Wait for end of screen (via DLI)
2. Reset end-of screen flag, read controllers, update sound registers (to minimize jitter)
3. Build display lists (assuming everything can be done in one screen time you don't need to double buffer)
4. Execute game & music logic
5. Test MSTAT, if still in VLBANK then set debug indicator to green and goto 1. If not but end-of-screen flag is cleared set debug indicator to yellow and goto 1. Otherwise set debug indicator to red, goto 2 (but skip step 3)
-
2
-
-
-
7800 sprites may be more than a single byte wide (and can have some interesting bit to pixel mappings). Therefore putting each row on a separate page means MARIA doesn't have to perform any multiplication to get the data for the next row.
7800 sprites are also "upside down" - i.e. the lowest memory address contains the bottom row of the sprite.
-
1
-
-
The RAM memory map on the 7800 includes some important shadows which have to be worked around:
; 1800-203F 2K + 64 bytes ; 2040-20FF 192 bytes 0040-00FF ZP shadow ; 2100-213F 64 bytes ; 2140-21FF 192 bytes 0140-01FF SP shadow ; 2200-27FF 1.5K
The DLL doesn't take up that much space (93 bytes for a 240 line screen with 8 line zones), but the display lists for each zone can take up considerable space (depending upon the game and how the display lists are allocated). In addition, if you have a character/tile (indirect sprite) list you will probably want that in a contiguous area in RAM.
-
I'm sure you've figured this out already, but for a limited number of rotation positions, lookup tables are the way to go for direction to X,Y anything. Note: while using reflections can reduce the size of the tables, it is often outweighed by the extra code (which costs cycles & space).
For SpaceWar! 7800 I used a lot of table lookups. Thrust was approximated as an acceleration in the direction of rotation, which was then added to the current velocity (which I think had a limiter on it). The gravity of the sun was another acceleration added to the velocity from a lookup based on the ship position. The velocity then gets added to the ship position every frame to produce movement. Everything is stored as signed fixed point values.
Oh, a quick approximation for the length of the hypotenuse is max(abs(x),abs(y)) + min(abs(x),abs(y))/2.
Remember you're making a game, not a physics simulation :-)
-
1
-
-
While possible, the biggest difficulty is going to be memory to store the cell map as the 7800 doesn't have a true bitmap display. 160x200x2bpp = 8K and the 7800 only has 4K available.
-
I'd recommend avoiding the issue by creating your own game rather than trying to recreate (port is only applicable if you have the original source code) a game. (Although you can certainly take inspiration from other games.)
The reason I say this is because you will never be able to recreate the game perfectly and thus many will judge your work to be a failure - no matter what you've managed to achieve. And trying to match the gameplay is as difficult, if not more, than trying to recreate the graphics and sound.
I am not trying to put down all of the wonderful ports & recreations which were done originally or by the homebrew community. But I'd much rather play a new game that Super Mario Bros on my 7800 when I can play the original on the real hardware or an emulator.
-
At one point I did a quick comparison of the 5200 & 7800 graphics processing: https://sites.google.com/site/atari7800wiki/atari-5200
I'd recommend you first learn & program the 7800 so you have a better understanding of its capabilities and weaknesses.
And while having the source code will make porting much of the game logic easier, I think you will find the graphics are so dissimilar that anything dealing with graphic objects will need a major rewrite for efficiency.
-
2
-
-
There was a boxed version! I have seen it...the box was brown, thats all I remember but I am 100% certain it exists
Hozer games are not rare, lol
Based on my royalties, there shouldn't be many of the Hozer label variant of Skeleton out there.
-
Skeleton (boxed release, philly classic?)
I don't believe Skeleton(+) was ever released with a box. Of course, as the original Skeleton is no longer available, it's collectable along with the original release of Skeleton+ with the You Win glitch. And there's the ultra-rare Hozer Video release of Skeleton complete with unique label artwork.
-
Just finished reading. I guess I thought there would be more pluses and minuses, but it sounds like 7800 was definitely well behind capability-wise compared to the NES/SMS competition.
From a pure capabilities perspective the 7800 has definite advantages over the NES & SMS - the number of sprites MARIA can generate (per line and total) is significantly above the NES & SMS. But in practice that raw sprite power is hamstrung by available CPU time. On the 7800 every tile & sprite reduces the amount of CPU available to game processing by a significant amount due to the shared bus & the need to build display lists rather than just updating simple tables.
-
I'm going to give a try at a version that builds up the DLL along with the DLs, and see how far that gets me. RAM is pretty tight, and a dynamic scheme would give more flexibility as to how 7800basic programs could be structured visually. I'm hoping I can pull it off without the additional overhead making it cost more than my vanilla "wait for non-visible and update" routines.
A truly dynamic (i.e. no wasted RAM) DL builder is certainly possible. What you would need to do is to order your sprites by Y or loop through the list of sprites, picking out those sprites for the zone. IIRC I looked at the latter at one point and found the cycles required to loop through the list of sprites for each zone was huge. Maybe build a second table with just Y and sprite index which could then be sorted . . . still sounds like a lot of CPU cycles.
-
-
I remember trying to figure out the Robotron disassembly, but not getting very far. It's fundamentally a data structure & transform issue - how best to structure your data to make it efficient to transform into the 7800 display list structure.
-
1
-
-
Yes, look up tables are your friend; although occasionally an approximation will work well enough while being both more time & space efficient. (e.g. max(x,y)+min(x,y)/2 as an approximation for sqrt(x*x+y*y) ) For something like a golf game you could do a 256 entry LUT for a quarter of a circle so your player wouldn't be restricted to a small set of angles.
I did a version of SpaceWar! for the 7800. Calculating the LUTs for gravity was a royal pain, but the end result was worth it.
-
1
-
-
Note: while the A8/5200 & 7800 use similar terms e.g. "display list", they are used in very different ways. See https://sites.google.com/site/atari7800wiki/atari-5200
The 7800 has a 25 entry LUT from a 256 color palette. Depending upon the graphics mode, a sprite may be 1 bpp (1 color + BG), 2 bpp (3 or 4 colors + BG) or 4bpp (12 colors + BG). In addition various strategies which take advantage of the way a TV processes the video signal may be used to create additional "artifact" colors. (e.g. Tower Toppler)
-
If you really want to roll your own, then you can take a queue from NES/SNES controllers and use shift registers. A single 8-bit register will get you 8 inputs, or you could use 2 in parallel for 16 inputs, or go whole hog and chain as a bunch serially so you can use a Sinistar 49-direction joystick and 32 buttons!
Yeah, but how many cycles would it take to read the joystick?
STX SWCHA # 4 set clock pin high LDA SWCHA # 4 read data pin ROL # 2 shift bit 7 to carry (ROR for player 2) STY SWCHA # 4 set clock pin low ROR JOY1 # 5 shift C into ZP register
So that's 19 cycles for one bit, or 158 cycles (and 104 bytes) for all 8 bits. (Adding 4 cycles to set up X & Y and 6 cycles to send the LATCH, but making the first ROL into a STA.) Actually, that's not too bad.
-
That is quite brilliant, as is using all 8 RIOT pins in both ports for a one player only game.
But your 2x3 matrix only gives 6 switches, right? So wouldn't that be the same as a Genesis controller stick and reading its 2 buttons? Up, down, left & right and diagonals and two buttons already there in the Genesis pad, or can your 2x3 matrix do joystick and 4 buttons like the original post requests?
Right, this enables no more than 4 directions and 2 buttons to be managed. Nothing more than the 4 directions and 2 buttons that some other solutions can supply (like the Genesis pad, for instance). For 2 more buttons, the 2 original Atari 7800 buttons can be used (with the corresponding circuitry).
Right, and in a 7800 (which has additional internal circuitry I'd forgotten about) it would be better for a 4-way + 2-button joystick to mimic the 7800 joystick rather than some 2x3 matrix. See http://atariage.com/forums/topic/212043-atari-7800-arcade-style-joysticks/#entry2774182 for a good summary of how the 7800 joystick works.
-
You would configure the 6 switches as a 2x3 matrix, with one side of the matrix connected to the RIOT pins so they can be used as outputs. See "A matrix in the real life" on the webpage. The other side is connected to the other pins. You then strobe each output pin and read the input pins. For the if/then you would use the AND or BIT operators to test whether the input pin is high or low and act appropriately.
-
With diodes, the ghosting problem can be reduced / eliminated : http://pcbheaven.com/wikipages/How_Key_Matrices_Works/
-
The Atari 2600/7800 joystick port has 9 pins
4 connected to the 6532 RIOT - used for joystick switches (note: these can be inputs or outputs)
2 "analog" inputs connected to the TIA - used for the paddle
1 "digital" input connected to the TIA - used for the joystick button
(Note: The 2600 and 7800 are identical from a joystick port perspective - the ports are connected RIOT & TIA.)
The analog inputs work on a charge / discharge system. During VBLANK the program sets the pins to charge mode, then the program counts the number of lines during the active screen it takes for the pins to discharge. So while these inputs could be used to detect multiple buttons using different resistance values, it requires some kernel time to do so. However, there could be calibration issues as I don't know if the resistance to number of lines is consistent for everyone.
A better alternative might be to use a variation of the keypad matrix (see http://atariage.com/2600/archives/schematics/Schematic_2600_Accessories_Low.html ). This uses the 4 RIOT pins in a row & column matrix. The big advantage of going this route is keypad support is already built into emulators. You might want / need to add some diodes (along with an intelligent mapping) like they do for a keyboard matrix to limit ghosting.
Or, if it's a one player game, use both joystick ports and just the RIOT pins.
-
The 5200 was released in November 1982, so depending upon the timing of when the interview happened and when the article was published, there's a chance Perry was referring to the 5200. But probably not.
The 7800 was an oddball - created by GCC in 1983-1984 as part of their post-lawsuit relationship with Atari. It's design mantra seemed to be for better graphics, 2600 compatibility and low cost. So that isn't it either/
My guess is the product wasn't anything more than a line item on a future possibilities list - a possible market to be explored and filled. (Especially if they received lots of interest based on the article.)
Given that I'm very close to that age, I can't imagine what kind of programs Perry might have been thinking about which are particularly distinct from what the younger than 45 group would be interested in.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Differences between Atari 2600 and Atari 7800 sprite colors?
in Atari 7800 Programming
Posted
You can only change the write mode on the same line, so the only option is 320B -> 320D. Easier option is to simply have more sprites with the different eye positions.