EricBall

128K? I'd get agoraphobia But if I ever get back to Leprechaun, I'll try to put in as many levels (2K each) as possible.

If someone can point me to the "ROM" for the PDP-1 Spacewar (other than through FilePlanet) I would appreciate it. It's interesting that you are okay with gravity & want more thrust, while Mitch wants less gravity and lower top speed. Smaller ships is something I've considered and may try. Would one active shot per player address your concerns about strategy? The shots are supposed to be some kind of light-based weapon, so they are unaffected by the ship's velocity. (Yes, that's also easier to code.) I haven't decided yet how I'm going to handle kills etc.

cut & paste from a PM Thanks for the compliments & feedback. Yeah, I've been thinking myself that gravity is a little strong. I'll play with it a little and see if I can come up with something better. Although, with the gravity at its current level you have to pay attention to it... Turning speed is also something I will tweak slightly, though I don't think I want to make the ships turn on a dime - too easy. I'll also decrease the shot life. I don't think I'm going to do too much with color, though I might do some stuff with different shades of grey. Sound - don't you know there's no sound in space? Seriously though, once I get the physics nailed down the next challenge will be collision detection, especially since it looks like I'm going to have to attempt to code for bit/pixel accuracy instead of simple X/Y bounding boxes.

I have added the fire code to Spacewar! No collision detection though so you will have to judge whether you hit yourself. The gravity well (singularity / star) is also displayed (and looks quite nice). I am asking for anyone and everyone to give this version a try and give me some feedback. Some items I'm interested in: - bug reports (I've only played via MESS) - shot speed, thrust, gravity & rotation speed: too fast or too slow - ship & shot size PS The 8K bin for CC2 owners is now signed. Thanks Chad for pointing out a78sign will work without the a78 header.

I've been reading through RCorcoran's PDF (up to chapter 7 so far), it's very nice. However the commentary bits need some work (though I'm pleased to see that many of my comments have been included). Sometimes it needs a some additional context, or probably should be moved to another chapter (e.g. the discussion about mul/div in chapter 6 should be in chapter 4 and have the context of the 6502 ASM book.)

MARIA is a sprite based engine, so the concept of a bitmap display doesn't exist. I guess you could do something bizarre with tiles (indirect graphics), but it wouldn't be a traditional frame-buffer bitmap. Plus, there really isn't enough time for the 6502 to be redrawing the bitmap on the fly. Nope, 320B has the same 2 bits per pixel from 1 of 8 palettes that the traditional 160B mode, though with out-of-order bits.

Of course the reason for that is the sound (except for the couple of carts with onboard POKEYs) is generated by the TIA, the same chip used in the 2600.

You might want to have a look at the source code from Skeleton+ I posted to Stellalist, and the mini project diaries on my website.

I've just added the gravity and thrust code so the ships now move. Download now! (CC2 8K bin included.)

It is open source, or didn't you see that I have included commented source? Chad's CC2 firmware doesn't handle 4K A78 files? Sounds like something which should be easy to add/fix. Otherwise add an ORG $E000 before the A78 header section and re-assemble.

Some more notes: As Albert pointed out on the front page, SPACEWAR! was originally done for the PDP-1 (although a version most likely exists for the PDP-11). I am not doing a port of any specific version, just using the basic ideas & title. Call it a homage if you will. My desire is to have thrust, gravity (with a killer signularity) and shots (not affected by gravity, just like the original). Two player only, unfortunately. I will try to put in the hyperspace manuver too. Thrust should be accurate. Gravity is approximated somewhat. Once I get the movement code done (in progress) we'll see how well it works.

I have done that; I suspected it might help. Thanks for the confirmation.

Most of the answers to these questions can be found in the project diary, but I'll answer them rather than force you to read my rambles. Right now I've got the basic display kernal working and the players rotating. Player movement (thrust and gravity) is next. I'm working on it when I can, though now that I can see something I have more incentive. The code is designed to be converted to PAL without too much trouble. Unfortunately, I doubt I will be able to put in your suggestions as I only have currently 667 bytes left in the 4K cart. (Why 4K? So it can be put on a standard 2600 4K PCB; and compete in next year's 4K compo. ) I've been working with component instead of composite for too long. I'm still puzzled why the 7800 has so many 320 modes when they can't avoid artifacts. At least you read my ramblings.

In some of my previous posts I've hinted that I have been working on a 7800 homebrew. Well, I'm now ready to reveal that I am working on bringing the PDP-1 classic Spacewar to the 7800. Although it is nowhere close to finished, you can download the current source code (with comments!) and binary. There is also a lengthy project diary over at www.videobrewery.com, for those interested in the my ramblings. 7800 Spacewar uses the 7800 320x1 mode (320A), so MESS 0.74 or better is recommended.

Isn't Pitfall 2 just one chip with the graphics and code ROMs included with the DPC logic? (At least that's what the patent seemed to suggest.) If so, then it would be impossible to hack Pitfall 2 without creating a DPC clone.

My changes to the MESS a7800 were mostly improvements to the 320 modes, and really only have an impact to Tower Toppler AFAIK. The 2600/7800 Artifacting topic has some screen shots showing the differences. Note: Tower Toppler on MESS looks different than on a real TV, see the topic for details. The MESS emulation of the 7800 is not perfect (though most games work acceptably). MESS does not model how MARIA DMA steals cycles from the 6502, nor how the 6502 clock downshifts for TIA & RIOT accesses. So any homebrews should be tested on a real 7800 (which should make Chad happy).

First, Activision is hardly profiting off the included homebrews. The popularity of the PS2 anthology proved that there was a market which they have now expanded to other systems (GBA, PC, Mac). Activision could have simply included the same titles on the new release, but they decided that many homebrews were good enough to stand shoulder-to-shoulder with the Activision label. And I, for one, am very proud to have Skeleton+ included. What I'm trying to say is the Activision library is selling the anthology, not the homebrews. The homebrews are a bonus. Second, the license agreement for the Skeleton+ binary specifically permits people to play it using an emulator, a RAM cart (e.g. Supercharger or CuttleCart) or even burn an EPROM for personal use. So anyone who wishes to play Skeleton+ can do so without buying the cartridge from AtariAge or Pack Rat. (Yet over 100 have done so.) Thus, having Skeleton+ included in the anthology deprives me of few sales but merely increases the number of people who can enjoy playing it. Finally, there is something very, very rewarding about dreaming of the day when my son can take copies of Skeleton+ to show-and-tell and say "my Dad did this", or be able to say "that's mine" any time I see someone playing Skeleton+. Personal accomplishment, ego trips, and flat out fun is why I program for the Atari 2600 & 7800, not personal profit. (Though purchasing Skeleton+ has to be the most sincere compliment I can think of.) Oh, and Activision simply asked whether any homebrewers would like to be included and I'm sure they had no shortage of volunteers. We entered into the contract willingly, knowing full well how we would be compensated.

The encryption (digital signature really) issue has been resolved, so that is no longer a road block. The basic documentation exists, MESS does a decent job emulating (though you need to recompile it for debugging), and the CC2 is in beta test. About the only thing which does not exist is the homebrew community and various bits of sample code. Programming the 7800 isn't difficult, it's still 6502 assembly. No requirement for tricky cycle counting either. Building the display list list (not a typo) is mostly just data movement. I believe there is some interest in 7800 programming, and there will be interest in buying 7800 homebrews too. And yes, I am working on a game. Watch this forum for developments in the near future (depending on my time).

http://playstation2-linux.com/projects/stella-ps2/ Looks like it's being attempted on the PS2 at least. I couldn't find a similar PSX attempt using Google. However, Activision has released a 2600 collection for the PSX, there might be others as well.

Bry, you answered your own question. The color isn't important, it's the repeating on/off pixels which cause the artifacts. The artifacts may allow colors to be shown which aren't in the 7800 palette, or display more colors than the given 320 mode is capable of. Jindroush, I suspect even in B&W 320 mode alternating on/off pixels could cause artifacts.

The two screenshots show the impact of the forthcoming changes to MESS on Tower Toppler. As you can see with the old version the player shows through the top of the space ship and the tower shows through the bottom of the space ship too. Neither occurs with the new version.

Ahh-ha! I think I understand what is happening. Because the 7800 MARIA has a 2*colorburst pixel clock, the alternating on/off pixels of the tower creates a waveform at colorburst frequency. So rather than producing the stripes shown by MESS, it gives the solid color shown in the screenshots. This reminds me of hi-res mode on the Color Computer. Although it was a 256x192 two color mode, single pixels would be either red or green/blue depending on whether it was odd or even. So Tempest, I was wrong. The 320 modes may have color artifacts (especially Tower Toppler). Whether these artifacts will occur with an S-Video mod is an interesting question. Because S-Video doesn't have a colorburst filter (notch or comb) I suspect the output will look more like MESS. I'm not sure if this effect can be easily reproduced in MESS. I suspect the programmers did a lot of trial and error development to determine what each color / stripe combination did. This also calls into question the value of 320 modes. I wonder why GCC included them.

Well, it's getting better. The ball sprites don't blend in with the tower quite as much. Don't know about the colors though. Hmm.

Great minds think alike: SEG ROM HEADER ORG ROMTOP-128 DC.B 1 ; 0 Header version - 1 byte DC.B "ATARI7800" ; 1..16 "ATARI7800 " - 16 bytes DS 7,32 DC.B "7800 Space War!"; 17..48 Cart title - 32 bytes DS HEADER+49-.,0 DC.B $00,$00,256->ROMTOP,$00; 49..52 data length - 4 bytes DC.B $00,$00 ; 53..54 cart type - 2 bytes ; bit 0 - Pokey cart ; bit 1 - Supercart bank switched ; bit 2 - Supercart RAM at $4000 ; bit 3 - ROM at $4000 ; bit 4 - Bank 6 at $4000 ; bit 8-15 - Special ; 0 = Normal cart DC.B 1 ; 55 controller 1 type - 1 byte DC.B 1 ; 56 controller 2 type - 1 byte ; 0 = None ; 1 = Joystick ; 2 = Light Gun DC.B 0 ; 57 0 = NTSC 1 = PAL ORG HEADER+100 ; 100..127 "ACTUAL CART DATA STARTS HERE" - 28 bytes DC.B "ACTUAL CART DATA STARTS HERE" ROMTOP ORG $F000

There were a couple of bugs in the MESS a7800 video driver which should be corrected in the next release. I'll give Tower Toppler a try.