Hornpipe2

I personally like to use BRANCH instructions instead of JMP wherever possible. It saves a byte of ROM each time, and the cycle cost is the same. There are so many branch instructions you can usually find one that will execute 100% of the time for your given application.

This is awesome, exactly what I need. Thanks so much!

I don't understand what you mean by that. Copy A to Y after the routine, or restore A from Y after the routine? Sorry, I meant the values of both A and Y are useful. Actually only A is REALLY useful, Y can be reloaded from immediate at a cost of a couple bytes. EDIT: Good solution though!

Very pretentious title for a (should be) simple concept. My two players can choose their color from 8 available by hitting left and right at the menu screen. If the player moves too far left or right, they are wrapped to the other side. If the player attempts to choose the same color as what the other player is currently sitting on, it should skip and move to the next available. Here's an example: P0 0 1 2 3 4 5 6 7 P1 Here, P0 pushing 'left' should set his color to 7. Pushing Right should make him 2 since P1 is currently occupying 1. P1 'left' should skip 0 and set P1 to 7. P1 'right' sets P1 to 2. A's value must be the same before and after the block, so save it before any changes. Y contains #15 and if used will need to be restored at the end (e.g. LDY #15) Lots of free RAM, and cycles aren't as important here as saving ROM bytes. Here's the best I can do for when P1 pushes 'left': PHA DEC P1Color LDA P1Color AND #%00000111 CMP P0Color BNE SaveP1 DEC P1Color LDA P1Color AND #%00000111 SaveP1 STA P1Color PLA

MP3 file compression generally destroys the data because it's a lossy codec. If you really need the audio around, you can use a lossless compression format like FLAC, WavPack, etc. However, using CAS files with CAS2WAV would be a better (smaller, more reliable) solution.

I would suggest Manchester coding at a data rate of 11Kbits/second. There are a number of variations on manchester coding; the essence of all of them is that your data rate is 1/2 of the bit clock rate, the output is high exactly half the time, and there will never be more than one full bit time without the output changing state. Wouldn't that speed require specialized loading code? I'm looking for a solution that makes the Atari see my CD player as a tape deck. (I may be wrong here - sorry if I don't know what I'm talking about, I've never been a cassette user, but the idea of an Atari CD-Rom is just too neat to pass up) I have no idea on the max speed POKEY will read on a CLOAD - can anyone fill me in here? Here is my thinking on how to make a dead-simple decoder. Take my 600-bit stream, stretch it out to 44.1khz so that a 0 makes a 0-volume sample and 1 makes a max-volume sample. Then, burn that. On playback you should have a signal that goes high for 1 and low for 0. Now just put that into a circuit that turns this into levels the Atari expects, and you're good to go. Wait, I think I just described the MegaCD : )

All tape drives have to decode. The POKEY can transmit binary data using FSK (two-tone) encoding, which can then be recorded directly to tape without further processing, but it cannot decode it by itself. The MegaCD looks very much like what I want to build. I'd be interested in rigging the Motor Control line to trigger a pause/unpause on the CD player. (MegaCD seems to be doing something else entirely with that line...) Hopefully I could devise something small enough to fit inside a small (or portable) CD player, leaving only an SIO cable hanging out. You'd then just advance to the right track on the CD and do a CLOAD, and you'd have an Atari CD-ROM drive. Switch to pick L/R stereo and pack twice as much on one CD. At 820 baud, stereo, you could fit ~930KiB on an 80-minute CDR. (820 baud is nearing the upper limit of the OS-routines, according to CAS2WAV documentation. I can always play with it later to see how high I can go...) This issue of Antic seems to have the schematic for the FSK decoder: does this look right? http://www.atarimagazines.com/v2n1/tapetopics.html EDIT: There's no reason I would need to stick to FSK data on CD, though, since the expectation is that data on CD would be much higher signal-to-noise ratio and isn't subject to any kind of degradation. Perhaps there is a much simpler circuit I could use to make 0s and 1s from 'audio' source? Something like Amplitude Shift Keying?

Yet another problem: you need to build a FSK decoder to pass binary data to your Atari. Not a big deal, someone already did this some time ago (can't remember the exact name of the CD-to-Atari interface, just google for it). so long, Hias This is an awesome idea and one I'd like to try. Can you help me track down the CD to Atari interface? I can't seem to find it (except one that works by IDE - not exactly what I was looking for). EDIT: Is this it? http://www.atariage.com/forums/index.php?showtopic=114001 Also helpful would be any information on what exactly the tape drive supports (pinout, special commands, etc). I've never used a 410 before. Does the 410 do the decode or is it the Atari?

I second the SIO2PC! You can build it yourself if you're handy with a soldering iron and it's very easy (about 5-10 components). They're also reasonably cheap to purchase ready-made if you'd rather go that route.

Why no NTSC prototypes? The list is so sparse we could use e.g. "Unknown Universal Prototype" (the dragster game) too, and since we can all get the ROM files online these days it's not that big of an issue if they were never 'formally' released. Maybe you could compile them in a separate sub-list?

My joystick checking routines span pages and pages. Has anyone got an efficient technique for polling joysticks? The best I can do is a series of: CheckP1Up LDA #%00000001 BIT SWCHA BNE CheckP1Down (do something) CheckP1Down LDA #%00000010 BIT SWCHA BNE CheckP1Right (do something) ... It may be that what I'm really looking for is a good solution to: (decrement a counter, but only if it's above 0) or (decrement a counter, but if it goes below 0, reset it to N)

In between drawing sprites I've been working on my title screen (really, game menu). Here's what I have so far - changes will be made, though. This is mainly just a mockup - no controls do anything yet - but the GFX pieces are almost all in place. * Splash screen displays for about 5 seconds on power-on. It's just the word 'Karate' in Japanese and does a cheap rainbow flashing. Then the menu pops up. * Enemy can be one of "human" to "c", "c-", "c--" etc. (AI difficulty level) * Color will be selected to allow both players to change their uniform * FIGHT! starts a game * Record shows matches won for each player. Reset button to revert to 0-0. Still plugging away at character graphics.

Kind of off topic, but it's still 'thrift finds'. I've been enjoying this Livejournal community recently: http://community.livejournal.com/thrifthorror/ It's called Thrift Shop Horrors. People bring cameras to thrift stores and post photos of the monstrosities they find, with commentary. Sometimes humorous.

Drawing more sprites (I think I'm up to 13 now). I added in a quick 'hack' to try turning the character around - it works great. Attached is a quick animation so you can see the effect. Also, I've assigned all the sprites I should need and have a couple to spare, which will be good as either more filler for smoothing animations, or special poses. I have an idea for the title screen that I like, but I need one of those playfield tools - anyone got a link handy, or will I need to code mine up from scratch? I had wanted to stick pretty close to IK+ controls for this, but some of those moves don't translate well so I dropped them, and in the process ended up changing the controls to be more intuitive anyway. Generally: move with U/D/L/R/UL/DL, punch with UR/DR/A, turn around with A+(U/D)L, kick with A+U,A+UR,A+R,A+DR,A+DL. It's a kicking game now I guess... Some people (okay one person, vdub_bobby haha) are asking for a binary. I have a thing about releasing anything but screenshots until it's ready for public testing. Don't worry - betas and final release will be made available, with source. I just don't feel like posting a ZIP yet with all kinds of caveats ("the only button that works currently is P0 right. Oh and don't push it too much or the game loops infinitely.") EDIT: Note to self - do something about the belt on that rotation.

I sorted out the ones I knew were uncommon and rare (judging by the colored expansion icon and what I remembered from when I played) - there may be a few more in the boxes from editions before, but nothing super-spectacular or anything.

If you play this CCG you may want to look in on my auction. I'm selling my collection in one go. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...s=tab%3DSelling

There's nothing much to see, really - screenshots tell the story just fine. I'll put one up when it's ready for testing, and of course the final version will be released for everyone. EDIT: Source too.

New changes: * Invested a little more time on the Title Screen. Now instead of Atari Rainbow it's blue with gradients at top and bottom. I've actually sectioned off areas in the center for menu items (to be displayed with 6-digit-score-routine) but they don't do anything now except draw more blue. * Dropped in the Music Kit 2.0 on the title screen. It plays the demo song, which makes everything 1000 times cooler. * Worked a little more on the battle screen. There's now a score display at the top, players at differing heights, and a little more graphics at the bottom. Sometime soon I'll get a nice background going. * Up to 3 sprites now - stand, walk, and crouch. For reference I added a couple ROM counters to my .asm to check my usage: ---- $93c bank0 program ROM free ---- $d2d bank1 t/menu ROM free Looking good so far!

Once again recommending FND - paid very quickly (even rounded up to the next dollar!), very easy transaction, couldn't have gone smoother unless I lived down the street from him : )

Well, as I posted earlier (I know because I tried to reproduce the bug in both versions) -

My understanding is the two versions of Astroblast! have already been dumped...

New changes: * Colors are now 'packed' 4 to a byte in a bizarre format, and unpacked during front-porch into 24 RAM bytes. This saves me a lot of ROM space. Bumped up max sprite height from 21 to 24 lines, and added two alternating player colors. (Incidentally the PAL60 version will feature blue-haired ninjas...) * Everything is now table-driven - no hardcoded values - so I can feel free to draw sprites of any height and run them through my bmp2h program, and they should Just Work. * Animations! My animation setup is going well enough to allow Player 0 to engage the 'walk' sprite when pressing Right on the joystick. I took a screenshot of that in action, but it's hard to tell since they look very similar. Next up I need a lot more sprites and to define some more moves, plus allowing animations to change Player X and Y values.

Unfortunately, I don't see a way that would work. My display kernel is pretty tight as-is and I think situations where the sprites are very close or very far apart would break it. It would be really awesome though!

Thanks! I'm not much of an artist so this was the best I could do... Yeah, they flicker at 30hz. I turned on "Use Phosphor" with amount 77 in Stella to capture this image.

Progress continues slowly. I wrote up a little C application to take BMP files and spit out assembler BYTE codes, so I can draw sprites in MSPaint and not have to punch in hex codes by hand. The colors are off and I end up fixing them manually, but it seems to work okay for the actual pixel on/off data. Here's the current build showing my fighters standing ready. They're 40 pixels wide, and 21 lines tall shown 3 times each, for an effective 40x63 sprite. New animation frames will probably come next, as well as dynamically building the sprite color table in RAM each frame so I can have two differently colored players. That way I can store sprite colors in a special format as there are only 4 colors used (uniform1, uniform2, skin, hair) and that means 2 ROM bits instead of 8 - I would then unpack it to 8-bit colors before starting the frame. Maybe I'll even let players pick the uniform color in the final version - we'll see.