A year ago, I created a kernel to display 13 characters per line, each of which could independently be one of two colors. Rather a neat trick, but it required a bunch of straight-line code. The only way to change the contents of a line of text was to modify the code that displayed it. On a SuperCharger, that could work, though displaying eight lines of text would use up most of the RAM; I dismissed the kernel as an interesting curiosity.
Discussions of Sudoku led me to wonder whether the
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.
Haven't posted in awhile, but I've been working on some things.
-1- Paddle fixer. Simple little circuit that should allow paddles to work beautifully even when dirty.
-2- EEPROM enhancement for AA cart.
-3- Ruby Runner
-4- The 4A50 programmer. My current programmer works, but it only runs under DOS (ugh). So I'm working on a version that will connect via serial port and run under Windows (easily adaptable for Linux/Macintosh/whatever).
-5- EEPROM emulation for Z26 (I'll of
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
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.
I've finally figured out how to get Z26 to compile, and implemented my own set of banking routines for 4A50 support. This version may be used to run the Ruby Runner WIP binaries I've posted in earlier entries. It is based on the Z26v213.tar distribution; the source code for all modified files is included.
Here it is: an animated GIF showing how the game looks. Totally unlike anything on the 2600. There's a little flicker on a real machine but not bad at all. Monsters aren't deadly yet, but you can see how they move, and how the rocks and rubies fall.
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
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
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
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
Here's a demo of an even better RPG kernel. This one shows a scrolling (control with joystick) 10x8 window into a 32x24 world. The demo requires a SuperCharger (if running Stella, ignore the checksum messages) but the plan is to do the thing in 4A50 once an emulator is available (parts of the code will be much nicer, and things like animated water will be freebies).Note that there is no restriction on tile placement; the game flickers at 30Hz, but in exchange for tolerating 30Hz flicker you ge
Here's a demo of an RPG kernel which should be quite practical in a 4A50 cart or maybe even the SuperCharger. It would require self-modifying code, but not obscene amounts (256 bytes per row, so 2.25K for a nine-row display); a SuperCharger implimentation would probably be reasonable also.The kernel supports a 9x9 display of 8x16-pixel characters with eight pseudocolors at 30Hz flicker (each character can contain two real colors, and they can be blended if desired). The graphics here aren't th
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
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
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
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
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
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.
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
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
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
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 just been feeling like doing minikernels lately. I don't know why. Maybe 'cos they offer a nice quick challenge.My latest minikernel was an effort to try doing the Warlords shields and kings all with player sprites, so as to free up missiles for additional fireballs. Turns out I forgot that NUSIZx affects missiles as well as players (grrr...) but the code is still somewhat interesting as it manages a single-line kernel with two 16-pixel-wide kings on the same scan line as two movable shi
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord