The Atari 2600's HMOVE circuitry is, to put it mildly, interesting. I was just examining the schematics for it earlier today and figured out a trick that might be useful for some applications, most notably kernels in the style of Homestar Runner or Ruby Runner which move some sprites left and right by eight pixels on alternate scan lines.
The "classic" approach, invented by David Crane almost 30 years ago, was to only move sprites by seven pixels instead of eight and then shift the data byt
I haven't gone into much detail elsewhere about the 4A50 cart and some of the techniques it uses, but since people may find it interesting I'll discuss it here.The heart of the cartridge is a Xilinx CPLD. This device has 36 macrocells connected to 32 I/O pins. While it's a step up from the 22V10 used in Al's bankswitch carts, it's still very cheap as such devices go.Another key to the cartridge is a 14.31818Mhz oscillator. Although many RAM-plus carts get by with some simple RC circuitry for
Although I may still make a couple more tweaks, I would say that anyone with a Cuttle Cart 2 can now safely start development on 4A50-based projects. Use the banking file in the previous blog entry.I don't yet have EEPROM support in the CPLD, but expect that I will soon. I have in-circuit programming working for DOS-based PC's with printer ports. On a Compaq Presario 2100 (booting DOS off floppy and running off a RAMdisk) it takes 38 seconds to program and verify the Archon demo in the previo
The basis game engine on Ruby Runner is now functional. The rubies and stones now fall, and can even slide sideways. They sometimes slide when they shouldn't, but I should be able to fix that. My original design intention had been to use the LSB of each character code to indicate whether the character was "slippery", but some temp character codes generated for moving items have the bit set when they shouldn't, which messes things up. I think I'll have to simply use a lookup table to allow ea
So far I've got the kernel going along with the ability to move the player and animate a few things. Here's an actual screen capture (running a 4A50-equipped Z26).That is not a mockup. The game is really displaying all that. Well, it is using flicker blinds, but because they are only used for vertical smoothing and color enhancement, the flicker really isn't objectionable. Here's what a single (non-phosphorescent) frame looks like:It doesn't look nearly as nice, but unlike most flickering 26
I decided to try out some kernel experimentation to see how well Toyshop Trouble could work on the 7800. Things seem like it could work decently, though the lack of cycle-accurate emulation support would probably make it too difficult to get working. Things could be a bit better if the write mode 2 transparency logic used the upper data bits, but even without that ability it should be pretty nicely workable.
The game would run in 320B mode. Four toys per line, each with two independent co
She was a good sweetie. I don't know why I first mentioned early in our relationship (1998) that I still enjoyed playing the 2600, but Dawn quickly fell in love with Millipede. She'd had a 2600 as a youth (four-switch version) but never got any cartridge newer than Burgertime.
Seven years.
Cory Maye, a man who was on death row for having shot an intruder who happened to be a police officer, has bee moved off death row. I've read some of the trial and hearing transcripts of the case, and it sure seems like some prosecutors are more concerned in convictions than in justice.
At trial, Cory Maye testified that he was awakened by the sound of someone bashing at his door, went to the bedroom, got a pistol, and got down on the floor watching the doorway. When door was breached, Cor
IntroductionOne of the first steps in creating a game is often designing a screen layout. On some systems this is fairly straightforward. On something like the Channel F, the screen has a certain resolution (e.g. 128x64) and a certain number of colors; any screen layout with the proper resolution and number of colors is feasible.The 2600, however, is another story. Although it's possible to look at some proposed screen layouts and say "Yeah, that would be easy" or to look at others and say "N
Well, I've come up with a cheap method of adding a serial EEPROM to a cart. Albert's F8/F6/F4 board should be easily adaptable to the purpose. The EEPROM may be accessed much faster than the EEPROM in a MemCard/Atarivox--a rate of 298kbps. Indeed, it's 33% faster than even 4A50's EEPROM access which is itself quite impressive for a 6502.
Code to access the EEPROM must be stored in a pair of adjacent banks; 0 and 1 are recommended, but 2 and 3, 4 and 5, or 6 and 7 could be used if desired.
This is an extension of my brick-buster kernel demo, with some collision-detection code added. As you move your player left and right, the program will highlight the bricks you're over on rows 1, 3, and 5. The collision-detect code is presently a bit too slow to be practical (though it does manage to run three times in vblank, which would be barely enough to allow for three balls bouncing, the timing is really very tight). The technique is nonetheless interesting and may be useful elsewhere.E
Here's a little demo of an RPG kernel on the Supercharger. It includes source, so you can see how to set things up for a 6K game. Note that I did not bother putting in correct checksums, so Stella will probably squawk.Note that this kernel has some considerable room for improvement. Some comments:-1- This kernel does three playfield stores per scan line. Using reflected playfield mode, and using separate playfield data for even and odd frames, this could be reduced to two. This would also e
My next little project is called BTP2. I've got the data tables designed, but still need to come up with the code to drive them. It's somewhat related to a recent thread. So now you have to speculate what crazy idea I might be thinking of.
Clues:
Stereo, 15.75KHz
46 cycles/scan line
Any guesses?
One thing I was pondering recently while evaluating the feasibility of the Wormy project is the question of whether to shoot for a 4K or a banked cartridge. Certainly during the heyday of the 2600, 8K and even 16K carts were hardly uncommon, and yet there is a certain 'purist' side of me that favors 4K. How should one best decide?To be sure, there's nothing that prevents going to a banked cartridge after starting out planning a 4K one. It only took a couple hours to split Strat-O-Gems from on
Atari paddles jitter. This is a consequence of a design which makes the wiper resistance part of the measurement. There's another way to read a potentiometer which works better: put a fixed voltage on the pot and measure the voltage at the wiper. Although severe grunge can still cause slight jitter, it will generally be on the order of 2-3 degrees--far less than in the normal design.In addition to the jitter problem, Atari paddles are time-consuming to read. Because measurements take many mi
BTP2 music sounds even better than expected when I put in some real music. I need to put in some real logic for music handling so I can sustain notes (and not use 16 bytes per beat!) but this clip shows the full five octave range of BTP2 with a recognizable tune.
New Year--maybe time for a new blogI've been doing 6502 coding for many years, having started with a VIC-20 many years ago. It wasn't until I had my Commodore 64 that I started trying to figure how to really "push the envelope", though looking at what people have done since I moved on to the PC makes my efforts seem puny by comparison (I did, by myself, figure out how to scroll sprites into the left and right borders, though).To this day, I take great pride in figuring out efficient ways to cod
This version adds explosions when monsters are hit by falling rocks or rubies. I'm not really happy with it, but figured I'd let CC2 users play with it. There are a surprising number of different ways a rock can hit a monster, and I don't yet have special handling for most of them, so things can get a little strange.
Setting difficulty to B/A allows the game to be single-stepped via the fire button. This makes it possible to see what's happening with monster and rock movements as well as
Here's a little animation routine that would be quite suitable for use as a title screen in a banked game (this demo is just under 3K and would probably take about 2-2.5K if written more efficiently). The technique I use here has some limitations, but allows some magic unlike anything the 2600 has seen before.
A text logo scrolls up like the Star Wars opening crawl, scrolling off the top of the screen.
The logo then zooms out from the center of the screen, then shrinks diagonally to the cent
Based on some discussions in "The project after the project..." I decided to test out whether a ball-based kernel would work for a Juno-First style background. My conclusion: it works and is doable with a reasonable cycle load and in a reasonable amount of code on a banked cart, and horizontal motion looks great. Vertical motion is not so great, unfortunately. The pixels seem to be horizontally "jumpy" and I don't see any good remedy for that which would still have the dots move vertically.
I'm just about done with 4A50 EEPROM access. I'm a bit surprised by how zippy the EEPROM code can be with a fairly small amount of logic to support it.The biggest limitation is that the EEPROM code must be located in $0000-$3FFF of RAM, $0000-$3FFF of flash, or $8000-$BFFF of flash. Accessing RAM from $4000-$7FFF or ROM from $C000-$FFFF will disrupt EEPROM access.Otherwise, the code that I was expecting to be a real pain in the tusch is actually pretty compact, though it is of necessity split
Reading a paddle on the 2600 is a pain. Reading all four paddles on the 2600 is an even bigger pain. I think I've come up with an approach that will mitigate things somewhat. This technique requires knowing the magic index value for the current scan line; these values go "0 1 0 2 0 1 0 3 0 1 0 2 0 1 0 4" etc. corresponding to what bit in a gray code should be flipped. If the magic index value for a scan line is known, reading all four paddles takes 26 cycles; if it's not known, it takes 32 c
I've managed to patch version 2.13 of Z26 to support 4A50 bank switching. I've sent the code to Eckhard for his approval; if he likes it, I should be able to release it. It auto-assumes that a 64K or 128K file is 4A50 format, and includes bank-switches in the log file. For example (left columns elided)
nvbdIZC 8c 11 00 f1 b8a6: 0c 44 6e nop 6e44 (*BANKS 22000/1E000/1C100*)
nvbdIZC 8c 11 00 f1 b8a9: 4c 89 b7 jmp b789
nvbdIZC 8c 11 00 f1 b789: 85 02 sta WSYNC
nvbdIZC 8c 11 00 f1
It's been awhile since I've posted about the 4A50 cart, so many people may be thinking it's been abandoned. It actually still is a work in progress, despite some "shiny object syndrome" that resulted in things like Strat-O-Gems.I worked awhile ago with Chad Schell to produce some VHDL for 4A50 and unfortunately did not have time then to diagnose it other than to determine that something didn't work. Hopefully within the next few days I'll be able to diagnose exactly what it IS doing and take t
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord