TROGDOR

I've spent the last couple days working on the kernel for The Battle of Midway. Here's the evolution. All three of the following kernels do the same thing. They display both planes, both missiles, and the bomb on every scanline, with full vertical resolution for both display and movement. Kernel 1 The original kernel was crap, which I wrote 3 years ago. To its credit, it does actually work, but in a horribly inefficient way. When you see the code, you'll understand why I was itching to rewrite it. NormalKernel LDX #ENABL TXS LDX #184 LDY #0 LDA #0 STA Temp4 STA Temp5 ;------------------------------------------------------------ JMP KernelLoop align 256 SkipPlane0Draw LDA #0 ;2 (+1 from previous branch.) STA Temp4 ;3 Update the buffer. NOP ;2 NOP ;2 NOP ;2 NOP ;2 BEQ ContinueKernel0 ;3 Block = 17 cycles. SkipPlane1Draw LDA #0 ;2 (+1 from previous branch.) STA Temp5 ;3 Update the buffer. NOP ;2 NOP ;2 NOP ;2 NOP ;2 BEQ ContinueKernel1 ;3 Block = 17 cycles. KernelLoop CPX BombYHi ;3 Preload the BombY comparison. STA WSYNC ;3 ; New scanline starts here. PHP ;3 sets ENABL STA GRP1 ;3 STY GRP0 ;3 CPX Bullet1Y ;3 PHP ;3 sets ENAM1 CPX Bullet0Y ;3 PHP ;3 sets ENAM0, Total 21 ; Reset the stack TXA ;2 LDX #ENABL ;2 TXS ;2 TAX ;2 Block = 8 cycles. ; Determine P0 graphics for next line. SEC ;2 ; TXA ;2 A now holds scanline. Careful! This is implied from above. SBC Plane0PosYHi ;3 ADC #9 ;2 BCC SkipPlane0Draw ;2 or 3, Block = 9 TAY ;2 LDA (Plane0GfxLo),Y ;5 STA Temp4 ;3 This is the buffer for the next player graphics. INY ;2 LDA (Plane0GfxLo),Y ;5, Block = 17 ContinueKernel0 LDY Temp5 ;3 Pull the graphics for P1 from the buffer. DEX ;2 CPX BombYHi ;3 Preload the BombY comparison. STA WSYNC ;3 Block = 11, Total = 66 ;---------------------------------------- ; Next scanline starts here. PHP ;3 sets ENABL STA GRP0 ;3 STY GRP1 ;3 CPX Bullet1Y ;3 PHP ;3 sets ENAM1 CPX Bullet0Y ;3 PHP ;3 sets ENAM0, Total 21 ; Reset the stack TXA ;2 LDX #ENABL ;2 TXS ;2 TAX ;2 Block = 8 cycles. ; Determine P1 graphics for next line. SEC ;2 ; TXA ;2 A now holds scanline. Careful! Implied from stack hack. SBC Plane1Y ;3 ADC #9 ;2 BCC SkipPlane1Draw ;2 or 3, Block = 9 TAY ;2 LDA (Plane1GfxLo),Y ;5 STA Temp5 ;3 This is the buffer for the next player graphics. INY ;2 LDA (Plane1GfxLo),Y ;5, Block = 17 ContinueKernel1 LDY Temp4 ;3 Pull the graphics for P1 from the buffer. DEX ;2 TitleKernelEntry CPX #ShipZone ;3 ; CPX BombYHi ;3 Implied above. ; STA WSYNC ;3 Impiled above. BNE KernelLoop ;2 or 3, Block = 13, Total = 71 ;------------------------------------------------------------ This beast would load up P0 graphics for the current line and the next line, storing the next line in a temp var. On the next line, it would do the same thing with P1. In this manner, it could write both P0 and P1 on every line. It barely fit in the time constraints. Kernel 2 It only took me 4 years, but I finally fully understand how the VDEL buffers work and are meant to be used. Kernel 2 is a rewrite of the first kernel, but making proper use of VDEL for P0. This removes the need for the temp variables, and saves enough time that I was able to squeeze it down to a 1LK. It could be optimized further using the DCP skipdraw, which would shave off 6 more cycles. It currently uses all 76 cycles, although 3 of those cycles are a NOP. Is there a cleaner way to declare a 3 cycle NOP in dasm? NormalKernel LDX #ENABL TXS LDA #1 STA VDELP0 ;Enable VDEL for P0, so it can write early in the line. LDA #0 STA VDELP1 ;Enable VDEL for P0, so it can write early in the line. LDX #183 LDY #0 LDA #0 STA Temp4 STA Temp5 ;------------------------------------------------------------ JMP KernelLoopEntry align 256 SkipPlane0Draw ;3 from branch LDA Temp4 ;3 cycle hack to load 0. JMP ContinueKernel0 ;3 Block = 9 cycles. SkipPlane1Draw ;3 from branch LDA Temp4 ;3 cycle hack to load 0. JMP ContinueKernel1 ;3 Block = 9 cycles. ;------------------------------------------------------------ KernelLoopEntry STA WSYNC KernelLoop ; New scanline starts here. CPX BombYHi ;3 PHP ;3 sets ENABL STA GRP1 ;3 CPX Bullet1Y ;3 PHP ;3 sets ENAM1 CPX Bullet0Y ;3 PHP ;3 sets ENAM0, Total 21 ; Reset the stack TXA ;2 LDX #ENABL ;2 TXS ;2 TAX ;2 Block = 8 cycles. (29) ; Determine P0 graphics for next line. SEC ;2 ; TXA ;2 A now holds scanline. Careful! This is implied from above. SBC Plane0PosYHi ;3 ADC #9 ;2 BCC SkipPlane0Draw ;2 or 3, TAY ;2 LDA (Plane0GfxLo),Y ;5 ContinueKernel0 STA GRP0 ;3 Block = 19 (48) SEC ;2 TXA ;2 A now holds scanline. SBC Plane1Y ;3 ADC #9 ;2 BCC SkipPlane1Draw ;2 or 3, Block = 9 TAY ;2 LDA (Plane1GfxLo),Y ;5 Block = 18 (66) ContinueKernel1 DEX ;2 TitleKernelEntry .byte #$04 ;3 cycle NOP .byte #$00 CPX #ShipZone ;2 BNE KernelLoop ;2 or 3, Block = 10, Total = 76 Kernel 3 This kernel uses quick load masking. It does the same thing in only 60 cycles. NormalKernel LDX #ENABL ;2 TXS ;2 LDA #1 ;2 STA VDELP0 ;3 Enable VDEL for P0, so it can write early in the line. LDA #0 ;2 STA VDELP1 ;3 Disable VDEL for P1. LDX #ENABL ;2 LDY #184 ;2 LDA #0 ;2 ;------------------------------------------------------------ JMP KernelLoop ;3 This jump is necessary because of the align. align 256 KernelLoop CPY BombYHi ;3 STA WSYNC ;3 ; New scanline starts here. PHP ;3 sets ENABL STA GRP1 ;3 CPY Bullet1Y ;3 PHP ;3 sets ENAM1 CPY Bullet0Y ;3 PHP ;3 sets ENAM0, Total 18 ; Reset the stack TXS ;2 (20) LDA (Plane0GfxLo),Y ;~6 AND (MaskGfx0Lo),Y ;~6 STA GRP0 ;3 Block = 15 (35) LDA (Plane1GfxLo),Y ;~6 AND (MaskGfx1Lo),Y ;~6 Block = 12 (47) DEY ;2 TitleKernelEntry CPY #ShipZone ;2 BNE KernelLoop ;2 or 3, Block = 7 (54) ;+6 from above (60) One interesting thing about this kernel is it uses the Y index for everything. This means I can preload X with #ENABL, and it only takes me one instruction to reset the stack hack. Even with the WSYNC I've got 16 more cycles to burn, which I could use to add multiline color or a variable height ball or missile. The trickiest part about using the mask is correctly preloading the mask and graphics vectors. Here's the support code to set up the vectors: UpdateSpriteDirs LDX Plane0Dir LDA SpriteLookupTable,X SEC SBC Plane0Y STA Plane0GfxLo LDX Plane1Dir LDA SpriteLookupTable,X SEC SBC Plane1Y STA Plane1GfxLo LDY #>Plane00 STY Plane0GfxHi LDY #>Plane00 STY Plane1GfxHi ... LDA #>KernelMask ; Set up the mask for the normal kernel. STA MaskGfx0Hi STA MaskGfx1Hi LDA #<KernelMask SEC SBC Plane0Y STA MaskGfx0Lo LDA #<KernelMask SEC SBC Plane1Y STA MaskGfx1Lo ... SpriteLookupTable .byte #(<Plane00 + .byte #(<Plane01 + .byte #(<Plane01 + .byte #(<Plane02 + .byte #(<Plane02 + .byte #(<Plane02 + .byte #(<Plane03 + .byte #(<Plane03 + .byte #(<Plane04 + .byte #(<Plane05 + .byte #(<Plane05 + .byte #(<Plane06 + .byte #(<Plane06 + .byte #(<Plane06 + .byte #(<Plane07 + .byte #(<Plane07 + ... align 256 (184 bytes of whatever data you want to put here.) Plane00 dc.b #%00111000 dc.b #%00010000 dc.b #%00111000 dc.b #%01111100 dc.b #%11111110 dc.b #%00010000 dc.b #%00010000 dc.b #%00010000 Plane01 etc... The +8 in the LookupTable sets the origin at the bottom of the target graphics data. For the plane graphics data, you can put anything in the first 184 bytes of the page, but Plane00 has to be at least 184 bytes away from the start of the page. Also, be careful that you don't have so many animation cells that you go into the next page. For this game, I had 8 lines x 8 graphics = 64 bytes. 184 + 64 = 248, so I'm safe. When setting the mask and graphics vectors, the vector high bytes are static. The vector low bytes are calculated by subtracting their vertical location from the mask origin label. And the mask: ;----------------------------------------------------- align 256 .byte #0 .byte #0 ... repeat for a total of 184 zeros. .byte #0 .byte #0 .byte #$FF .byte #$FF .byte #$FF .byte #$FF .byte #$FF .byte #$FF .byte #$FF .byte #$FF KernelMask .byte #0 .byte #0 ... repeat for another 184 zeros. .byte #0 .byte #0 The key here is that the mask label goes right after the $FF "enable" bytes. The align is necessary to make sure the high byte of your mask vector points to the correct page. Here's the latest Battle of Midway zip with the source, which now uses the masking kernel. It's almost a playable game now. My next blog update should have a playable version. tbom19b.zip

I've considered the alternative, but it eats even more cycles: LDA #SPRITEHEIGHT; 2 DCP SpriteTemp; 5 BCC SkipDraw; 2 LDA (GfxPtr),Y; 5 STA GRP0; 3 ReturnFromSkipDraw;+17 cycles This will work if you already have 0 stored in GRP0, and if you pad an extra 0 at the end of the player graphics. But, this won't work using VDEL. I need to write to GRP0 even when it's zero, to allow VDEL to work as expected. But, if I write GRP0, I'll have to make the SkipDraw section longer. SkipDraw ; 3 cycles from the previous branch. Total must be 12 to sync with kernel code. LDA #0; 2 STA GRP0; force 4 cycle absolute. JMP ReturnFromSkipDraw; 3 LDA #SPRITEHEIGHT; 2 DCP SpriteTemp; 5 BCC SkipDraw; 2 LDA (GfxPtr),Y; 5 STA GRP0; 3 NOP; 2 ReturnFromSkipDraw;+19 cycles So I'm looking at 19+19 = 38 cycles for 2 sprites with skipdraw, or 15+15+3 = 33 cycles for 2 sprites with masking. Are there any other possibilities? Ah, I've thought of one improvement. I only need VDEL on one of the two sprites. So I can squeeze it down to 19+17 = 36 cycles for two skipdraw sprites. If I understand VDEL correctly, I can set VDEL on P0, store the P0 graphic in the VDEL buffer, then write P1 (in non-VDEL mode), and that will write out P0 and P1 simultaneously, during horizontal blank. Edit: I've shaved off another cycle: SkipDraw ; 3 cycles from the previous branch. Total must be 11 to sync with kernel code. LDA #0; 2 STA GRP0; 3 JMP ReturnFromSkipDraw; 3 LDA #SPRITEHEIGHT; 2 DCP SpriteTemp; 5 BCC SkipDraw; 2 LDA (GfxPtr),Y; 5 STA GRP0; 4 (force absolute mode) ReturnFromSkipDraw;+18 cycles So now I'm down to 17+18 = 35 cycles for 2 sprite skipdraw with VDEL.

8k ROMs are a thing of beauty. Rather then spending all my time optimizing a 4k ROM, I can spend my time writing features, and not worrying as much about it being super optimized. It also allows me to try some ROM-intensive techniques to speed up my kernel. In a recent post, vdub_bobby mentioned a nice masking technique to quickly draw a player sprite: This code can even be used with animated sprites. If you set GfxPtr correctly, it will load garbage while the mask is on, and then load the proper graphics when the mask is off. So you can point GfxPtr to different animation cells on different frames, as long as their size matches the mask size. And you don't even have to worry about zero padding. The problem I'm seeing with this implementation is timing. If either of the indirection calls crosses a page boundary, the instruction will take 6 cycles instead of 5 cycles. This has two negative implications. The algorithm will potentially take 15 cycles instead of 13, and you'll have to use a WSYNC because the time can vary. The only way I see this as avoidable is if you use half vertical resolution. For example, you could use 88 zeros, then 8 player graphics, then another 88 zeros. Same with the mask. In my case, I'm using full vertical resolution. That's 184 zeros, 8 mask bytes, and another 184 zeros, which will cross a page boundary at some point. The only way to avoid the page boundary is to use 3 pages: 184 zeros 8 mask 64 zeros 64 zeros 8 mask 184 zeros 124 zeros 8 mask 124 zeros That eats 768 bytes of ROM, but it will allow you to pick a mask that spans 192 bytes and never crosses a page boundary. (Correct me if I'm wrong on this, or if there is an easier way to do it.) The other problem is the animated sprites. There's no way I'm going to try to zero pad all my animations, so I'm going to live with the fact that a page boundary may be crossed when loading the player graphics. This will force me to use a WSYNC. Since I've already taken that hit, I may as well allow the boundary crossing on the mask as well. So my mask becomes: 184 zeros 8 mask 184 zeros That's 376 bytes wasted. I can live with that in an 8k ROM. So the end result is I have a variable time graphics algorithm that will take at most 15 cycles, require a WSYNC, and will burn 376 bytes of ROM on a mask. Can anyone offer any optimization on this, or is this as good as it gets?

If I had infinite free time, I would write the game Nort.exe for the 2600. In Nort.exe, you are a computer program, trying to survive deep in the bowels of the Vista Operating System. The game would consist of 4 phases: Phase one: DRM Due to an errant MD5 checksum calculation, Vista's DRM has incorrectly matched your program file with "Britney_Spears_-_Baby_One_More_Time.mp3". Your program file is now targeted for deletion. Use your tank process to destroy the DRM subprocesses and escape. Phase two: Windows Defender Windows Defender has misidentified your program as an ActiveX virus. Your program has been targeted for quarantine and deletion. You must drive your instruction cycle to out maneuver the Defender subprocesses attempting to quarantine you within their paging boundaries. Phase three: Rootkit A Sony Rootkit has installed itself on the system's boot sector. It has decided that your program was installed by a competitor, and has targeted your program file for deletion. You must escape to the safety of the L2 Cache before the rootkit's self-replicating code consumes you. Phase four: Out of Memory The Kernel has locked up, and is now consuming memory at an alarming rate. A thrashing swap file is threatening to overwrite your program. You must blast through the incoming write packets and seize control of the Kernel to prevent total system failure.

Underball, maybe you should take some remedial legal classes. Most of your assertions are wrong, at least according to common copyright law. Courts are there for individuals and large corporations alike. If you really wanted to take legal action against someone for appropriating your copyrighted work, you can, and the courts will take you seriously. It's true that criminal courts have higher priorities, and would likely ignore any criminal complaints. But a civil court would take up the issue. You do not have to submit a work for copyright protection in most countries. Copyright is implied. From wikipedia: "In all countries where the Berne Convention standards apply, copyright is automatic, and need not be obtained through official registration with any government office. Once an idea has been reduced to tangible form, for example by securing it in a fixed medium (such as a drawing, sheet music, photograph, a videotape, or a computer file), the copyright holder is entitled to enforce his or her exclusive rights." You don't have to prove monetary damages to prevent unauthorized distribution. You only have to prove that you are the copyright holder, and that the offender is distributing your work without permission. The EFF has won several lawsuits against companies for violations of the GPL, pertaining to open source software. That software is freely distributed, but users are still bound by the terms of the license. Homebrews have similar legal protection. It's up to the authors whether they want to waive that protection. The method of distribution is irrelevant. The creator of the work still retains the copyright. Absolutely wrong. Everything posted on the internet does not magically become public domain. A work only becomes public domain if the author explicitly waives all rights to the work, or if the copyright expires by the passage of time. I'm not a lawyer, but I play one in a video game. And I've read way too many slashdot copyright discussions to let those incorrect statements be taken as fact. Feel free to correct me if I'm wrong on any of this, but site your sources. I got most of this from wikipedia. Having posted all this, I'm not saying everyone should go sue-happy. But copyright law is a protection and a deterrent against having your work appropriated without your permission. It's there as a fall-back option if a simple, polite request to stop distributing your work is ignored. Wickeycolumbus, if you feel strongly about your work being on the site, just send them an email asking that it be removed. From what I've read on the site, they will respect the request. I noticed that Master of Arcturus is on the site too. I don't really mind that. However, when my games eventually make it to cartridge form, I would probably tell pdroms they can only post my games if the descriptions clearly state that they are not in the public domain. They're covered by the license in the README, included with the binary.

This is exactly why GMOs are heavily regulated in Europe.

I just noticed these posts. Thanks guys. Glad the code was useful John, and that you liked the game so much. Unfortunately, v0.18 is the latest version, and there are still bugs in it. But I'm sure I'll be doing more work on it in the future. I got bogged down in the code to do nested recursion of the maze. As an alternative for score display, you can take a look at The Battle of Midway in my blog. That uses the playfield graphics to do an 8 digit display. It consists of 6 score digits with a hard-coded zero to make the score 7 digits, and a final digit to display remaining lives. I've been considering writing code to make that same display fit into a 48-bit sprite display, using 4-pixel-wide numbers. Bobby, what's MoT? Do you mean Master of Arcturus?

Thanks Chris. I figured out what I was doing wrong. After trying various values, I finally got wise and opened up the Stella TIA debugger. I've never had to use the TIA panel before, but this time it proved essential for finding the bug. The sprites were strobed in the right locations and the HMOVE was executing at the correct cycle, but I noticed the HM values for P0 and P1 were both 0, even though I had just written an 8 to both registers. Well, that's the problem. I wrote an 8. What I needed to write was an $80, because the HM registers only use the upper 4 bits. Once I changed that value, everything fell into place, and I now have a title screen with no artifacts. Thanks again.

With the Atari movie coming up, I've had some motivation to do more coding. I took another look at The Battle of Midway this weekend, and here are the results. More entitlement. tbom17.zip New Features: tbom16.asm 7/13/08 - Removed unnecessary procedural subroutines, freeing up some ROM and cycles. - Expanded the ROM out to 8k. VSync and Overscan are in bank1, Kernels are in bank2. - Displays title with fade-in effect and player's plane. - Integrated include files into the main .asm file. tbom17.asm 7/14/08 - Added score display in playfield graphics. - Added scoring: Bombing the ship 10 points, hitting the enemy Zero, 50 points. - Added sound effects for crashing airplane. - Added player life count, and game end when all lives are lost. - Resets the bomb and bullet when they hit. To Do: Remove HMOVE artifact from title screen. Multiple vectors for AA fire. Time-based high-res physics engine for Zero. Proper physics engine for player plane, to allow for engine stalling. AI to control Zero flight patterns. AI targeting for AA fire and Zero fire. Known Issues: - None so far. Game Controls: - Press fire to start the game. - Left and right control the pitch of the plane. (As in aviation pitch. Ironically, it does also change the pitch of the plane's engine, to represent stress on the engine.) - Fire button fires the machine guns. The machine guns will overheat if you hold the button too long. I'll probably pull the overheat feature, since it eats a byte of RAM and doesn't add much to the game. - Pressing down on the controller will drop the bomb. Development Notes: One benefit of having all these open projects is I'm getting tons of code reuse. Building 8k ROMs is second nature now, and it only took about half an hour to expand this ROM from 4k to 8K. I also dropped in the score display code from Hunt the Wumpus and from Stellar Fortress to compare them. For now, I'm going to use the Stellar Fortress playfield score display, but it may change back to player graphics before I'm done. My main concern when displaying the score is using as little of the screen realestate as possible, so I try to keep it in 5 scanlines. Either implementation will allow me to display a 7 digit score and a one digit life count. I had wanted to clear up that HMOVE artifact before posting this, but it's proving troublesome. This is my first attempt at using a cycle 73 HMOVE, which is that much harder when trying to implement it with a 48 bit display. The pixel movement wasn't happening as expected, and the title came out completely garbled. I have two questions about this: - When it says HMOVE at 73 cycles, does that mean the HMOVE write starts at the 73rd cycle, or ends at the 73rd cycle? - I'm guessing that all the move registers have to be set to 8 to prevent any motion. This makes the HMCLR register useless in this mode. So I punted for now, and just displayed the title with the artifact. As a demo feature, the game will randomly pick one of the two enemy capital ships when you press the reset switch, so you'll see the battleship Yamato more often. Here's the cartridge label mock-up I posted some time back:

An exceptional game s0c7! I just played it all the way through. The monster graphics look great. You made good use of multicolor. The difficulty level is just right. It took several attempts to get through the game. I also liked the quirky yet menacing title music. Well done.

Maybe Trogdor needs to be pushed to finish Hunt The Wumpus. Indeed.

Those are good suggestions, but I'm going to take a different approach. I found this copyright lawsuit story to be inspirational. The photographer in this story represented himself, although given the detail in the case, he must have had some legal background. Still, the result of the case is interesting. He was only awarded $4400 for the product that was infringed. But, he was awarded an additional $10,000 statutory damages for willful infringement, and another $5000 for the removal of the photographer's watermark. So my solution is simple. I've added a watermark to my ROMs. (Good luck finding it.) If the watermark is not removed, it will be easy to prove that my work was stolen. If the watermark is removed, I can collect another $5000 in damages. So certain unnamed people (cough Randy cough) had best be careful or they'll be looking at a $25 + $10,000 + $5,000 lawsuit if my copyrights are not respected. It would only take one lawsuit like this to shut him down permanently. I encourage other developers to follow in suit. (Pun intended.) I also think it's a good idea for anyone releasing a homebrew game to clarify the copyright status of the game in their blog/post and with a README.txt included in the distribution. Unless they really don't care, which is also fine.

Entitlement. sf23.zip New Features: sf22.asm 3/2/08 - Added preliminary title music. - Reorganized bank data. All kernels will now live in bank 2. Bank 1 contains the VBlank and Overscan. sf23.asm 5/24/08 - Changed cannon graphics. Uses lower vertical resolution. Cannon is larger. Now has 16 rotational animation positions instead of 8. - Added Title Screen mode. Press the fire button to begin the game. - Added Title graphics. To Do: - Rewrite the kernel to squeeze out more cycles and allow for some extra features. - Improve the Plasma Cannon graphics. Currently only 8 directions are implemented. This will be expanded to 16, as was done with the player's ship. - Design the Stellar Fortress destruction animation. - Title screen and title music. - Targeting computer for missiles. - Add starting level selection and gradual difficulty increase per level. Known Issues: - There seems to be a glitch in the title music. It misses a beat every few seconds. Gonna have to figure that out. - The mapping for player shot collisions with the fortress shield are still off by a couple pixels. - The final game will not have the fortress cannon shooting all the time (at least, not on most of the lower levels...) I need to implement a feature that will detect when a hole has been poked in the shield so the cannon can fire out. Development Notes: I broke a lot of game features when I moved the banks around and added the title mode. Most of the work I did for the last 3 months was cleaning up everything that was broken. But the original functionality is back, and the reorganization will make future development cleaner. I also beefed up my copyright notice, so none of my games will get Hozed. For clarification, the games that I post in this blog are not open source, nor are they public domain. I will retain all copyrights. People are welcome to look through the code for ideas, and can reuse individual subroutines if they find them useful. But I don't want any of these games placed on a ROM cartridge or CD without my permission first.

I see Atari homebrews as something different than most software programs. Atari games fall more under the category of art, and I think that's why most homebrewers are protective of their code. The best analogy I can think of is painting. If you're working on an elaborate painting, you might want to show your progress to friends. But it can be awkward when a friend makes a suggestion (hey, you should paint a couple trees in that corner, and you think to yourself, I really don't want to paint any trees in that corner.) Then if you take a long time to finish the painting, someone comes along and starts finishing the painting for you. It may make the painting better, or worse, but it still feels like creative encroachment. Two things you seldom see collaborative work on are paintings and books, because they are very personal creative endeavors. Video games are similar, and I think the only reason most video games have multiple contributors is the fact that most video games (beyond the scope of the Atari 2600) require so much effort that only a group of people could ever hope to complete it. Granted, my games will take eons to complete, but I've never abandoned them. I always come back and continue work.

Yep, a guy sold some unauthorized copies of games made by "hoser" on eBay, here's a thread about it. IIRC there were more threads about that but i could only find this one at the moment. This guy also sold a Hunt the Wumpus game, here's a pic... Well that's what I get for not logging into Atariage for 3 months. I hope that wasn't my binary in that Hunt the Wumpus game. Then again, I'm also hoping most Atari collectors will be smart enough to research Ebay sales before buying, especially for rare or unknown game titles. It looks like that tool still managed to sell two copies. For what it's worth, my source code and binary distributions aren't open source. I've got this copyright notice in all my blog releases: ; Copyright 2008 by Bill Collins ; This code and the corresponding binary game may not be distributed commercially ; without the expressed written consent of the author. I don't mind people looking at the source code to get ideas, but I put that copyright notice in there to prevent exactly what hoser is doing.

Hunt the Wumpus has a 6 digit display you're welcome to use. Version 17 includes the source code.

One of these things is not like the other things. Communist Mutants from Space was a great game. With progressive difficulty and lots of optional features like time warp, shields, penetrating shots, and guided shots, it was one of the better Galaxian style shooters for the 2600.

LOL only if the rest of the game contained a virus. After the first 4K, where is the rest of the bankswitching? From what I've heard, the game uses addresses $FFF6 through $FFF8 as a 24-bit control register. Reads to these addresses will store a 17-bit vector that points to the destination bank. (The upper 7 bits of address $FFF8 are unused.) A read to address $FFF9 executes the bank switch to the bank specified by the 17-bit vector. Once you're in the destination bank, the internal destination address is pulled off the stack, and code execution continues normally. Pretty crazy stuff. Hopefully Stella 2.6 will add support for this methodology, so we can try Molten Core in an emulator!

Technically that should have been 192p. Actually it is 192i. They're using VDEL. People keep going on about the graphics, but the most impressive feature in this game has got to be the bankswitching. Word on the street is this will be packaged in a 512 megabyte ROM cartridge, consisting of 131072 4k banks! Surely this will be the greatest game for the Atari 2600 since Blazemonger spontaneously ported itself in 1993!

I have a bank switching strategy that has worked well in my 8k games. I only allow one entry point into bank 2, and one return point back to bank 1. The program flow is: There are several advantages to this system: - The re-entry points from one bank to another don't have to be saved because the program flow is hard-coded with JMPs. (i.e. when you return back to bank 1, a JMP will take you back to the start of the Overscan code.) This saves two stack bytes of RAM. - Calling bank-switched subroutines eats a lot of extra cycles. This is avoided. - It's easy to balance the content between bank 1 and bank 2 to keep ROM use evenly distributed. If your VBlank and Overscan code is larger than your Kernel code, you can relocate some of the end of the VBlank code or the start of the Overscan code into Bank 2, while maintaining the same flow. The same is true if your Kernel code is larger than your VBlank and Overscan. For example, you could move some of the Kernel initialization code into Bank 1 with the VBlank. - Kernel code is usually self-contained. For example, if you're displaying text in your kernel, the graphics for that text will generally only be used inside the kernel. Likewise, many overscan functions, such as random number generators, joystick reading, sound effects, and AI, would never be used in the kernel, so it makes a good logical split for bank switching. - If you need to set up vectors in your Bank 1 VBlank, you can still reference data locations in Bank 2. For example, if you want to display a 6 digit score in your kernel, you can set up the 12 vector bytes in the VBlank of Bank 1, and then use the vectors in Bank 2. If the score graphics are defined at symbol "Numbers" at location $1C00 in Bank 2, the code in Bank 1 can still reference the symbol Numbers, even though the symbol's data technically lives in Bank 2. It will safely load the correct location, as long as it doesn't try to actually use the vector content until it's in Bank 2. - Bank switching is confusing enough as is. The ROM code for single-point bank switching is small and simple. By only having one return point, you are less likely to create bugs by mis-referencing data across banks.

I've read that the system has 8 colors, which I thought were red, green, blue, and gray in color mode, and black, white, and 2 shades of gray in b/w mode, as suggested by the Colortest demo. Does the system only have 6 colors? As for programming for the Channel F, I'd love to eventually, but I need to finish some Atari projects before I take on another system.

I wonder how they'd look if you used black and white mode, or else used blue as the background? Not sure you can really tell without real hardware, alas. Unfortunately, red on blue, or vice versa, is one of those contrasts that make your eyes bleed. Black and white might be okay for asteroids, given that the original was monochrome vector. It's too bad the system won't let you use black with the three primary colors. Empire:

I checked out the Channel F this weekend. It's an interesting beast. In many ways it's the opposite of the Atari. Poor colors and sound, but great at complex full screen images with no flicker. The existing games for this system don't even begin to unlock its potential. Risk and Empire would be great ports for this system. Adventure could probably be ported too, but it would take some work. An incredible asteroids, too. Imagine how lame the Atari would be if development had stopped after its first 26 games. With better coders, this system could have given Atari a run for their money. Here's some mock ups I threw together.

I just tried out the WIP demo. This is destined to be come a new Atari classic. Excellent work.

FYI, I'm starting a new Atari cleaning business. I charge $1000 per cleaning. That may seem like a lot, but then you can sell the final product for $4000, so you're really making $1000 on the deal. However, I do charge extra to clean nobes... In all seriousness, the only thing that's going to get cleaned is the buyer.