supercat

Well, "BASIC PROGRAMMING" would have been great if it could have used a RAM-plus cartridge and had come with something resembling a keyboard. In many regards, it was actually more sophisticated than other systems at the time (e.g. its simultaneous display of source code, variables, stack, and output). It took almost a decade for such features to appear on "usable" computers. Pesco would have been great with some sound effects. Of course, Nukey Shay seems to have fixed that. Wish I could somehow get the Hack'Em code into the Pesco cart. Though since Ebivision's got my $$ I don't feel guilty about playing Hack'Em instead. I'll have to think about some more--there are actually quite a few 'near great' games on the 2600 and many platforms. Fortunately, some of them can be (and have been) 'corrected'.

You haven't seen my 1K Supercharger minigame (currently about about 1048 bytes including the 16 bytes of Supercharger headers, but I think I can save a few bytes). The sound effects are really lame (well, what do you expect in about 16 bytes?) and the scoring consists entirely of changing colors (adding a numerical score readout would have been about 70 bytes I didn't have). Play mechanic is functional, though, with many more on-screen objects than the 1980's cartridge version by Rob Fullup. Wonder if I should bring it to the VGS next weekend?

Hey, why not go to 32K and use four-frame animation for all the monsters? 32K doesn't cost any more than 16K these days.

Didn't someone predict that 2005 would be THE year for homebrews?

A couple of possibilities: -1- Allow the player to practice any level EXCEPT for some bonus reward levels. Clearing a practice level returns to the main title screen. -2- Allow the player to practice a level after losing all lives, with the proviso that clearing the level will not advance the player.

Interesting. So each pair of pixels is two colors from one of four palettes. Sounds nice in theory, and could probably be made to work, but one would probably end up with about the same color limits as what one has now. The game was actually designed around a black+green+red+yellow palette and for the most part that is quite satisfactory. Too bad modern computers seem to use the black+cyan+magenta+white palette which doesn't look nearly as nice. The worm may occupy hundreds of character cells. Only 15 different characters at a time, but some of those characters repeated many times. I wish I knew how to get a screen shot of this thing; winXP doesn't seem to support the print-screen function to grab screens from DOS games. Would updating display lists suffice as an alternative to redrawing lots of characters, or would it be better to plan on using 16K for charactersets and fill in the space that's not used for characters with other stuff. For some reason I thought there were two/row. Oh well, 20 display lists, then (the top three rows are text, then a wall, then 20 that the worm can occupy, then the bottom row).

Naturally, people who want a 4K game should be free to design one. I was just suggesting the above as probably the easiest way to allow people to go beyond 4K.

Back in 1994, I started a version of columns for the 2600. I got the kernel sorta working, but gave up on the game since the assembler I had was a pain, trying out code was a pain (no emulators back then), and I didn't think there'd be any interest. If anyone wonders what my efforts looked like, here it is: COL.ZIP The assembly file has been changed to assemble under DASM (unfortunately, the easiest way to do that meant converting everything to ALLCAPS) but otherwise the code is exactly what I had in October of 1994.

Some are, some aren't. Some games used analog RC timing circuits to generate vertical and horizontal positioning. By the look of it, Fonz probably did so to some extent. As such, an accurate simulation would have to take into account things like temperature, capacitor aging, and other such effects. Unlike some games which operate entirely via clocked digital logic, where two machines of the same make and model should behave 100% identically, the analog video games will all behave slightly differently. A real game might have a 'feature' that causes roads to get wavier as the player goes longer because a the audio amp generates more heat when the user as playing. Such behavior would generally be impossible to really quantify, and thus impossible to emulate. BTW, I wonder what all was on the 8-track tape that came with Fonz, and whether anyone put in their own sounds?

Right now it's only 4k - and when you run out of code space, compilation will fail. If I can figure out how to seamlessly allow bigger carts when 4k is used up, I will put this in. 888526[/snapback] How about having an 8K mode which puts the video kernel and graphics in one bank and everything else in the other? That wouldn't necessarily be the optimal division, but it should be pretty simple to do seamlessly.

My current wish item for Z26 would be a feature to mark certain addresses that, when accessed, should -1- Display a half-pixel dot on the screen, [at current scan location] -2- Start logging -3- Stop logging -4- Arm a watchdog [settable value] -5- Feed the watchdog -6- Disarm the watchdog The watchdog should trap when a program goes too long without feeding it. The intended use would be for programs which do processing in vblank/overscan but poll the RIOT to see if they need to redraw the display. If a program is written to have 4 scan lines 'slop' on RIOT polling but a particular application sometimes takes 5 between polling cycles, the display will be fine unless the slow operation occurs at an inopportune time. Having a watchdog would allow such lurking problems to be detected. Any idea if Stella will include anything like the above features?

So if I wanted to use 2K-byte character sets, eight of them would take 16K but I'd only have one register to update per frame; if I wanted to use smaller character sets, I'd have to update 40 display lists? Tough call, since using 2K character sets would not have to be wasteful if other data were interspersed with them. I could imagine Wormy working quite nicely as a 32K cartridge with 16K of that consisting of interleaved screens and characters. Well, Wormy II was a CGA game. If you like I could enclose a copy; it sorta plays on modern machines though it runs too fast [cued off frame rate]. And with artifacting, I think you'd sorta get 16 colors on sorta 320x200 resolution [since different combinations of colors in pixel pairs would yield differnet colors on screen]. Remind me how 320C works? But using multiple character sets within a 2K block would entail updating 40 display lists? Not that that'd be impossible, but it would seem more work. Cool.

What? Under Z26Win it sounds like the BoulderDash theme being beaten to death with a sack of accordions. Granted, it's a very old version of Z26Win. Do newer versions handle this mode of sound generation better? There is a switch to synchronize the emulator with the sound generation. I have found that this improves things slightly, but the timing still isn't perfect and the sound is thus still a little off. One thing you need to realize about emulators is that they don't operate cycle-for-cycle in real time (Windows won't allow that) but they operate fast enough that most things happen within 1/60 second of when they should. This is mostly fine for display updates (though sometimes things flicker when they shouldn't, or don't flicker when they should), and is even okay for 'conventional' audio (if a note is played a little early or late it's usually no big deal) but the timing jitter causes severe problems with sampled audio. That's just the nature of the beast.

I wonder if AtariAge could make any money by selling off the bare boards from recycled cartridges. I know many people have all the commons, but some people are missing a few. For $0.50-$1.00 each I might fill in my collection.

Some nice features added, but ADC #immed sometimes takes 3 cycles now instead of two. BTW, I never did understand why there wasn't a 'BIT #immed' instruction. Would have seemed logical.

What do SLO, SRE, RLA, RRA, ISB, and DCP do?

There are 32 characters that are used for animating the worm, of which at most 15 can be on screen at once (12 may be on screen in arbitrary combination, then one head front, one head-body join, and one tail back). There are about 16 other non-animated characters shapes (walls, mines, gold bags, power-ups, etc.). Each of the worm characters has eight variations. The non-animated characters have only one each. If the MARIA can read graphics from ROM, it would be a simple matter to have eight character sets and simply change the 20 display lists for the rows containing worm segments to change character sets from one frame to the next. Duplicating the non-animated characters would be somewhat wasteful, but not too bad. The other approach would be to copy the animated part of the character set between frames. If I only copy the 240 bytes that are actually needed, this might be workable. Well, there's one worm [which actually looks more like a centipede] and it's animated along its entire length. I would think 38 8x8 sprites on a scan line in 320B mode would be even more of a bandwidth drain than 40 8x8 tiles.

Cool. Means if I ever got by Dodgson cart working again I might be able to do Wormy for the 7800 in 320B mode. BTW, it needs exactly 40 columns, not 41. The game was written for a CGA, and uses simulated 8x8 character drawing (320x200x4 colors) to draw things quickly. Most of the motion in the game is done by manipulating the character set, so if memory allowed it should be possible to make Wormy run nice and zippy. The primary requirement would be recopying the shape data for thirty-two characters each frame. Since the character shapes would be 16 bytes each, that would be 512 bytes. If the code uses a tight loop: LOOP: LDA CSROM0,X STA CSRAM,X LDA CSROM0+128,X STA CSRAM+128,X LDA CSROM0+256,X STA CSRAM+256,X LDA CSROM0+384,X STA CSRAM+384,X DEX BPL LOOP That's 41 cycles/loop, times 128 loops. That's 5248 cycles, or 69 scan lines. A little over where I'd like to be, though maybe the top part of the screen could be in lower-color mode. Would the CPU get any time during the displayed part of the frame? I suppose things could probably be improved slightly if one took advantage of the fact that only 15 of the 32 characters will ever be on screen at once Would be a little more complicated than always copying all 32 characters, but the cycle saviings could be worth it. Either that, or else can the MARIA get data out of external ROM without copying it to RAM first? If so, that'd be the way to go. There are about 48 character shapes, of which 32 are animated. There are eight character sets, so they'd take up 6144 bytes total. Too much to fit in RAM, but well within the capacity of a ROM.

How about a game with a breakout-style paddle at the bottom of the screen, where the goal is to keep the ball airborne? I would think that when running the Boing! demo there are actually a lot of spare CPU cycles per scan line but they're in different places depending upon the ball's X position. Having two or more different versions of the kernel which could be selected based upon whether the spare cycles are nearer the start or end of the scan line might be helpful. For the most basic breakout-style paddleball game, you wouldn't need to do much during the scan lines since your missles (use both of them, staggered 8 pixels, to make a super paddle) could be prepositioned at the start of a frame. On the other hand, if you wanted any targets for the ball to hit, those would have to be drawn sometime.

In the interest of preventing screen-burn-in, Atari's games cycle the screen colors when they are not being played. Generally, the color cycling begins immediately (and funky colors are something of a game-over indication). Not sure about why Home Run would be red all the time unless that's just the game's color scheme.

I'm using WPLAYBIN. Though I'm thinking I may have to reexamine some of the header to make sure I didn't bump anything. How does the header in the BIN file compare with the headers of the tape blocks? Counting address changes. Interesting. Does it look at the entire address (well A0-A12) when making the determination, so the sequence: Foo: LDA $F0xx,x NOP LDA MyAddress is guaranteed to work for any value of MyAddress other than Foo+6 or Foo+7 [either of which would cause a write to address Foo+8]? If they're counting address changes, I wonder why they need the write pulse delay to be programmable? I would have guessed that they needed that to get suitable timing accuracy over a several-cycle period, but accuray within a single cycle shouldn't have been a problem. I wonder why that other document says the SC writes are based on cycles?

Well, someone just pointed me to something that makes this a little trickier than I'd thought. It's absolutely imperative that the cartridge be able to support two back-to-back "write" cycles to the same address, or else the three most popular addressing modes won't work. So the self-oscillating behavior I'd thought was a 'bug' is really a feature, though it does have to be tuned precisely. This is probably why Starpath used the funny write method they did--it eliminates these problems.

What precision? Could you use a 560+47 [total 607 nominal] or 560+75 [635 nominal], 470+150 [620 nominal], 330+300 [630 nominal], 390+220 [610 nominal], or some other such combination?

I'm working on a 1K minigame for the Supercharger and am having a couple problems. Perhaps someone else who's dealt with the thing can offer some advice. -1- The program starts fine in emulation. On a real unit, however, it dies about 2/3 of the time on startup. My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code. Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)? -2- My understanding of the Supercharger was that the first memory access over address $F000 that occurred at least four but no more than six cycles following an access to $F000-$F0FF would trigger a memory write. This would suggest that the sequence: lda $F0E7 lda $F123 would store $E7 into address $F123. This doesn't seem to work in Z26, though. It does work if I use: lda $F0E7 nop lda $F123 but that doesn't really seem right, since the address fetch for the last instruction will take place on the fifth cycle following the trigger access; it would seem that this should trigger a write on the address fetch, rather than on the following data fetch. My code currently uses (ZP),Y for all the accesses and that seems to work, but it's a real pain in the tusch. What is supposed to work there?

The Atari 2600 and 7800 both use 228 chroma clocks/line, IIRC. The Nintendo uses 227.5. A consequence of this is that on the former systems chroma artifacts stay in the same place every line and every frame, while on the latter system the chroma artifacts alternate lines and frames. This improves the graphic output considerably except when the screen is scrolling at a rate of exactly one pixel per frame, and even then it's still probably better in most ways than the 7800. I would expect that a game which took advantage of artifacting might manage to produce better graphics than one which didn't, but I don't know of any 7800 games that do. Does anyone else know? Also, it's been ages since I read the 7800 specs. Can the Maria clock out enough data to put up a full screen of 4-color 8-pixel wide tiles in 320 mode if there are no other sprites that need to be drawn?