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
Theresa Marie Schindler (Schiavo) was forced to give up the ghost one year ago today, as a result of 13 days' forced dehydration. The media portrayed the issue as a contest between spousal rights and parental rights, and between a person's expressed will to die and other people's will that the person live. The media are liars.
Although a person's spouse should generally be trusted with that person's care, there are exceptions. While Terri was alive, Michael Schiavo sired two children by h
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.
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
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 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.
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
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
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
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
Here's a kernel demo which might be useful for the game Archon. For demo purposes it can run as either 3F bankswitching (use the -g11 switch in Z26) or as 4A50. A banking file is included for Cuttle Cart 2 users.
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 rough banking file to run 4A50-format banking on the CC2, along with a little test program. The banking file has a slight bug which this program works around. In particular, the hotspots at $7Fxx don't work unless they are immediately preceded by a read operation which fetches a value $60-$6F (should be $60-$7F). It's possible to work around this this by banking a page full of the value $60 into address $1Exx, and then using "LDA $1EFF,Y" to do the read (with a Y value one higher tha
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
Some gamers love paddles. And for some games, they can be the best form of control.Many 2600 programmers hate paddles. They're a pain in the tush to read, since the programmer has to observe, with about a scan line's precision, when the paddle input changes shape.Fortunately, it's possible to ease the requirements for reading paddles considerably if one uses a little trick: although many games reset the paddle timing circuit at the start or end of VSYNC or VBLANK, there is no requirement that
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
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