supercat
-
Content Count
7,259 -
Joined
-
Last visited
Blog Comments posted by supercat
-
-
Of course I won't give out the binary, working or not, without John's permission. If I can get it all working, I'll modify my text-to-speech program to output the codes in hex so they could be entered without needing to convert each number.If you like I'll revisit that code; it behaves differently in emulation from on a real 2600. If you ask really nicely I'll even let you have source code for it.
-
iChat is a possibility I've been considering, but only as far as conducting interviews remotely. The subjects would still need to be shot locally on high quality video. That's the tricky part.Your target format is standard DVD, right? A lot of digital cameras can do 640x480x30fps. Not as good as a professional-quality video camera, but not horrible.
-
I remember that game. Maybe I need to dig it out. When playing against the computer, a useful strategy early on seemed to be to build large flat areas 2 or 3 clicks above the ocean. The computer would build one click up from the ocean; a flood spell would thus be very effective. In later levels, though, the computer seems able to build itself out of a flood; if I can do a second flood quickly, that will help but in later levels even that's not a sure thing.
-
Don't be totally dismissive of Pong consoles. Many were based on the GI chipset and perform identically, but some others were not and thus play differently.
-
1
-
-
I had a lot of jitters before declaring Toyshop Trouble "done", but once I did the jitters went away. The game is what it is, and I have no particular desire to change anything even though there are some things I might, in retrospect, have done differently.
-
How about using five cogs for display, to allow a 4x speed boost?
-
4.77MHz (4/3 colorburst) would be fast enough, but I don't know whether those exist. (I know 14.31818MHz exists, I've used them.) And how feasible is it to generate the 14.31818MHz output clock from 4.77MHz?You can order oscillators with whatever frequency you want from Digi-Key; in moderate quantities (100 or so) they're not much more than standard ones, and even in onesie-twosies they're not too bad.
-
Netflix has a lot of items that are not available at most video stores, and certainly not from a redbox kiosk. Their low-end membership deals are pretty cheap, especially for material that would be hard to get elsewhere.
-
I don't see chip-level simulations as being very useful for playing these old arcade games. Most of the circuitry in PONG isn't doing anything 99.9% of the time, so why simulate it continuously? During vertical blank, the ball will move by amounts that are determined entirely by things that have happened earlier in the frame. The appearance of the net never changes, and the appearance of score digits only changes when certain specific events occur. Processing these things as display overlays rather than as logic would speed things considerably without affecting the user experience one iota (except by allowing the simulation to run real-time).
What I do see the simulations as useful for would be validating software emulators. Someone who studies the PONG schematic carefully should be able to produce a pixel-perfect rendition, but a failure to understand how something works could cause the look-alike to behave differently from the real thing. Even if it can only run at a frame per second or so (or even slower), it should be possible to set up a simulation script to compare the screens generated by full logic simulation with those generated by the look-alike program. Such a project could improve the acceptance of MAME simulations of hard-wired games.
-
Exactly. Unlike the 2600 where the TIA gets hammered during the kernel, the MARIA registers are rarely updated. But for the NES the VPU access registers are not mapped to zero-page even though they get used almost as much as the TIA registers.On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.Actually, it's pretty common to have some Maria accesses during the kernel to change modes mid-screen, etc. But nothing near the bashing the TIA gets. Though I doubt any machine's I/O chips get anything near the bashing the TIA gets.
You're probably right that the display list entry coding could have been done better. Again, it seems like things like indirect & write mode were added on after the original design was completed.No, I think those were in there early on, since they're so obviously necessary. More likely the Kangaroo mode was an afterthought.
I haven't spent lots of time in the 320 modes, so I can't comment on a those design suggestions. But, my guess is 160A was the original design point, with 320A added next and 320B added after. The other modes are just "free" side-effects of those three.There are two ways data can be put into the line buffer ("write mode"), and three ways the line buffer can be displayed ("read modes"). The write modes pay no regard to how data will be read out, and the read modes pay no attention to how it got in.
-
Batari used players and missiles to good effect in Rally B. He flickered things at 30Hz, and I think it was something like:
Frame 1:
Player car: Draw with blue player
Opponent #1: Blue missile
Opponent #2: Yellow player
Opponent #3: Yellow missile
Frame 2:
Player car: Draw with green missile
Opponent #1: Red player
Opponent #2: Red missile
Opponent #3: Green player
Thus:
Player car: Cyan, with blue wheels
Opponent #1: Purple, with red wheels
Opponent #2: Orange, with yellow wheels
Opponent #3: Green-yellow, with green wheels
Other colors could be chosen, of course.
-
Yes/no. I think the biggest problem is the CPU load caused by the display list and shared memory architectures. Putting MARIA on a separate bus would have freed up a huge number of CPU cycles but would have significantly increased the system cost and the CPU cost to create the display lists across the split bus. Given the display list architecture, I don't think there's many questionable design decisions beyond using the TIA for sound. (And that was an Atari cost decision.)I can see quite a few. To start with some things improvements that could have been improved very cheaply:
- Not using the upper bits of each byte for transparency determination in write mode 2
- Making Kangaroo mode a 'global' property rather than allowing it to be set for individual display items
- Putting the control byte of each display list item second instead of first, which requires an extra byte of padding for display lists, wastes two cycles per display list, and may have contributed to the extra 2 cycle delay when fetching an extended record.
- Delay the start of MARIA writes by one 320-mode pixel.
Some other things I would have liked to have seen:
- Give the Maria 64 byte of address space at $20-$3F and $120-$13F. This would allow for a full set of palette registers (32 colors rather than 16) and allow a few more options.
- Trigger an extended display list item when the 'size' is over 24 pixels, rather than just when it's 32. This would free up three bits in the control byte. For an end-of-list record, they could set the read mode. For any other record, they could set the Kangaroo mode and "holey DMA" options.
- Add a 16-color "320-dot" read mode where one bit of each pixel controls whether a color should apply to both pixels, or only to the one on the right (in which case, the pixel to the left would get its color from the pixel to its immediate left). This would allow for jaggy-elimination on graphics where every colored area is at least two pixels wide, while retaining a nice color palette.
- Allow the most significant color bit of each pixel to select the read mode used on the other bits.
- Architecture permitting, if the source address MSB is 0, "fetch" blank data at a rate of 1 cycle/byte (I don't know if the Maria needs the three cycles to plot things internally)
- Architecture permitting, have an option to use a fast memory cycle for the character data fetch in the character modes (use normal cycles for the shape data). This would require character data to be in RAM but reduce memory bandwidth.
- Allow 32-line display list zones.
- Allow options for 228 or 227.5 cycles/line and for 262, 263, or 262.5/525 line displays.
On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.I don't know how much benefit there is generally to having MARIA mapped in zero-page. For a game with a very specialized kernel it can be handy, but given that writing to the color registers will cause any pixel currently being output to be "stretched" I don't see much use for real-time register bashing outside of specialized games like Toyshop Trouble.
One of my biggest complaints is that the 7800 was designed for 160-wide graphics (same resolution as the 2600) and its ability to handle 320-wide graphics seems to have been an afterthought.I agree. I think 320 modes happened after GCC went with the 7.16MHz MARIA clock, which probably made it relatively easy to support 320 output. But then they didn't have the transistor budget to double the line RAM, so they had to figure out ways to translate 5 bits into 10 bits of color lookups.
I wouldn't mind having only 5 bits per double pixel if it were easier to set them usefully. The transparency handling is a major oops in that regard (though actually it could be nuisancesome even in 160-dot mode).
- Not using the upper bits of each byte for transparency determination in write mode 2
-
So it was 2600 in 2006. Will it be 7800 in 2007? I don't know very much at all about the 7800. Does it have the ability to do smooth horizontal scrolling? How many players per line?I'm thinking I may stick with the 2600, though I've been curious about the 7800. To really exploit the capabilities of old machines requires cycle-accurate emulation, and the 7800 just isn't there yet. Besides, the 2600 represents a much larger audience. Still, the 7800 can do some interesting stuff.
The 7800 doesn't have a hard limit on the number of players it can draw or the size thereof. Rather, it's limited by the amount of data that can be fetched from memory during a scan line. It's a clever architecture in a lot of ways, but its abilities are severely curtailed by some unfortunate design decisions. It seems like the people at GCC may have been rushed--ironic, given that once completed the 7800 sat on the shelf for a few years.
One of my biggest complaints is that the 7800 was designed for 160-wide graphics (same resolution as the 2600) and its ability to handle 320-wide graphics seems to have been an afterthought. There's a hardware line buffer which has five bits per each 160-wide pixel; normally these five bits are used to select one of 25 colors, but there are two modes which split each 160-wide pixel into two parts which different bits from the five. Unfortunately, one of the modes requires that any double-pixel must either have both pixels the same color, or must have one pixel be the 'background' color; it's not possible to have two non-background pixels in the same double pixel. The other mode avoids that limitation, but is limited by the fact that unless transparent objects are disabled (meaning all objects are drawn in an opaque box as in the arcade game "Kangaroo") it's not possible to draw pixels in color 2 or 6 unless they are sharing a double pixel with color 1, 3, 5, or 7.
-
Oh... do you use the same display list for _every_ visible display? That would be even more cool. (And makes the ZP/SP hole even more annoying I imagine.)That's the idea, precisely. Though things like score, etc. could be handled using a different display list (character mode, etc.) if desired.
I suspect the emulators don't handle DMA cycle stealing so that's why there's a difference. From the emulator perspective, it's only counting WSYNCs.The funny thing is that there's a one-line difference between the real thing and emulation whether I put the pointer updates at the start of the line or seven cycles into it. Since ProSystem is fairly new, and it's the only emulator I've tried, my guess would be that its DMA calculations are off by a line, though I'll have to play with things to see if that's what's going on. From my understanding, a change to a palette register should affect things immediately; a change to the display list that occurs within the first seven cycles won't affect the current line but instead the one after; a change after the seventh cycle won't take effect until two lines below the current line. My guess is that existing games haven't used that level of display-list bashing for some reason, though I don't know why not (it should allow for some really nice tricks).
BTW, have you checked out my Wormy demo yet (7800 prog forum)
-
Have you tested your pseudo kernel out on actual hardware? Are you updating the display list entry or the DLL entry? How do you sync with MARIA? (Since you're probably using more than 7 CPU cycles per line.)
I posted the test code up above. Push the joystick left or right to shift the routine's execution down by one or two lines. You'll see that the real machine's code execution is off a line compared with the emulation.
-
Have you tested your pseudo kernel out on actual hardware? Are you updating the display list entry or the DLL entry? How do you sync with MARIA? (Since you're probably using more than 7 CPU cycles per line.)It updates the display list itself. I've tried things two ways: preload A and X and then store them within the first six cycles after a WSYNC, or else do a WSYNC and then wait at least 7 cycles before doing the stores. Either way works with real hardware, though the code has to be run a line sooner when using the latter approach (naturally). In both cases, the real hardware requires one less WSYNC between my DLI and the start of the loop than does the ProSystem emulator.
BTW, I'm also planning to test whether a Toyshop Trouble kernel could work well on the 7800 using 320 mode. The plan would be have each of the three toys be a solid color and use register-bashing to color-stripe them. The colors of the second and third toys would be set within the first six cycles after WSYNC; the color of the first toy would be set later in the scan line (after the beam was past it). The elf would be draw with 160-dot resolution and four colors plus transparent (no need to color-stripe him). DMA requirements should be quite reasonable (three toys @ 3.5 cycles, plus the elf at 5 cycles, plus two ends of the conveyor--probably 2.75 or 3.5 cycles), but the 320-dot mode should improve some of the toys compared with the 2600's 160-dot mode. Not sure it would be worth the effort to code the game for the five or six people who might actually play it, but it would be interesting from a technical perspective.
-
I was considering starting on a project where I was going to have a bitmapped display with double height lines (kinda like graphics 7 (antic D?) on 8 bits). It would require a display list list entry for every two scan lines though.
The approach I use requires one DLL entry every 16 lines, which is the absolute minimum required for even the feeblest screen display. Everything else is done by manipulating things during display drawing. Unfortunately, I can't figure out how to make the code compatible with both the Prosystem emulator and the real hardware except by doing a really gross cheat (which would probably fail if the emulator was made somewhat more compatible).
-
Note: there's no 2LK for the 7800, so you're limitting yourself to the only half of the screen height with 128x96.My code shows each scan line of the bitmap twice. It requires servicing the display every scan line, but it's no worse than anything on the 2600 in that regard. It only uses one display list, and each item in the display list list is 16 lines high.
-
Well, I knew 6502 assembly before starting on a 2600 game, and it only took me 11 years from when I started my first game to when I published it (Strat-O-Gems, 2005). Admittedly, I wasn't working on it most of that time.
The 2600 is a very interesting platform. You need to be skilled at 6502 programming to have much of a shot at doing a kernel in assembly language (though with Batari Basic, you can do a lot without knowing much at all). Some skills from other platforms will transfer very nicely, but the 2600 uses a very different style of programming from any other system I know of.
-
There are also some nice "bonus" opcodes which are supported in DASM. These are available in NMOS-technology 65xx chips only and will not work on 65C02-based machines such as the Apple //c.
Perhaps the most useful:
DCP -- Decremenent and ComPare. Acts like "DEC", followed by CMP with the newly-decremented address. Any addressing mode except immediate.
LAX -- Load Accumulator and X register. Loads both registers. Any addressing mode except immediate (too bad!) zp+x and abs+x modes.
SAX -- Store Accumulator "and" X register. Stores the "and"ed value of both registers. Doesn't affect flags. Most LAX modes except for abs+y.
SBX -- Subtract from accumulator "and" X. Subtracts an immediate constant from the value of "A and X" and stores the result in X; accumulator unaffected. Carry-in is ignored; carry out set iff no borrow. Immediate mode only.
-
Another thing to consider is that there are no AND nor OR gates in the Pong circuit (but a lot of NANDs and NORs). If they were striving to keep the number of different chips down they would have had to add some inverters which would add at least one more chip. Also the inverted versions of V1, V2 and V4 aren't available so that may require yet another inverter chip to get these.I did offer an alternative which replaced the ORs with NANDs and didn't need inverted /V2 and /V4, but did require inverting the counter (or else using a different counter which goes down instead of up). Not sure what counters were available.
BTW, I wonder how the layout was done? Is Pong a double-sided PCB?
-
I wonder if the horizontal ball control evolved somehow during the course of the design? The circuit I described seems simpler and more straightforward than the one Atari actually used, but perhaps it took people awhile to figure out exactly how they wanted the speedups to behave? If they started out with a more complex sequence of speedups and then simplified it, it may be that the complex circuitry had been needed earlier but wasn't in the end.
-
I think "Panel II" was the best of those.
-
I would guess the song gets by because of its age. It would seem silly to censor it after it's been out 30+ years.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Technically, it's a silicon implant
in (Insert stupid Blog name here)
A blog by Nathan Strum
Posted
Trivia: the term "plastic surgery" predates the development of the synthetic resins that are now called "plastics". Indeed, the application of the term "plastic" to such resins is somewhat ironic, in that the early ones like Bakelite were quite brittle--not plastic at all.