EricBall

Dan Boris did 78hdr which is contained in http://atarihq.com/danb/files/7800dev.zip However, I'm a proponent of including the header in the ASM for three reasons: It means I don't need to run (or learn to use) a separate tool to add the header, 'cause DASM does it automatically It means other people don't need the tool to add the header, and I don't need to give instructions either It's trivial to add, and it's possible to have DASM generate certain fields automatically.

pin 5 & 9 are the paddle pot inputs, pin 7 is +5V

That's a nice job. I have to admit I've been considering building a similar stick for the 7800. The problem with arcade joysticks is the depth means the box cannot be handheld. Did you manage to find an 8-way Wico leaf with the rubber grommet? If I were to make one, I think I would also go with Wico leafs instead of the Happ microswitches 'cause I think the hard stop / click would be very annoying. (Or maybe the Happ Ultimate optical, but they are $$.) Did you scrounge or scavenge the 9 pin cable & connector or buy them?

Whoops, forgot that PAL games didn't need the digital signature; so an unmodified NTSC 7800 would judge them to be 2600 carts.

I wouldn't trust wire colors, there's no reason they wouldn't change. You should use a multimeter to figure out which wire goes to which pin/hole.

On the 2600 the game determines the number of lines per frame (NTSC=262, PAL=312). So there are basically two options: 1. Modify the game to generate the correct number of lines per frame (typically not a simple hack). 2. Find a TV which will sync to 312 lines @ 50Hz (while still handling the NTSC colorburst & channel frequencies).

Or you can set bit 1 of CTRLPF = SCORE (left half of playfield gets color of player 0, right half gets color of player 1)

The important thing to remember is on a 2600 the game has to count the number of lines per frame, while on the 7800 the MARIA GPU automatically generates a fixed number of lines per frame (262 for NTSC, 312 for PAL). (Although a 7800 game can control the number of non-blank lines.) So a NTSC game on a PAL 7800 & PAL TV will may have garbage graphics at the bottom of the screen. A PAL game on an NTSC 7800 and NTSC TV will have the bottom chopped off. (There may also be some slight differences at the top too.) Now, a PAL 7800 to a NTSC TV or vice-versa is a completely different deck of cards. Not only are the number of lines and frame rate different, but the color signal and channel frequencies are different. So it is not surprising that such combinations would produce various picture problems. Note: It is possible for a 7800 game to determine whether it is an NTSC or PAL 7800 by counting the number of active lines per frame. This code was incorporated into Asteroids in the PAL BIOS. (Thanks Eckhard!)

You are correct. The code does not have A=0 = pixel #0; a +7 offset is required. Some other possible modifications to the given code: 1. If fineAdjustBegin is located at $xxF1 and fineAdjustTable = $xx00, then the page boundary penalty cycle can be avoided. 2. The fineAdjust table could also convert -1 to -15 to Left 6 - Right 8; which may be useful in some situations. There are other possible variations of this code (search [stella] for "Revolutionary Horizontal Positioning") most notable being variations which do not require the fineAdjust table (at the cost of some additional instructions and cycles) and ones optimized for positioning both player sprites next to one another (for 16 or 48 bit sprites). Note: when developing a repositioning routine don't forget to cycle count the right edge too! It's very easy to slip past cycle 73 if you are ending the routine with a STA WSYNC/STA HMOVE combo and add an extra line. Also don't forget that HMnn remains set even after an HMOVE. So do a STA HMCLR if you don't want sprites to move again. Oh, one other "trick". If the SEC is a CLC, then the first subtraction will be A-16. The fineAdjust table will need to be expanded to contain Left 7 to Right 8. This can be used to get one more pixel of range out of the routine.

deleted

As I told my wife, it was a good thing I'm not a collector, or it would have been hard not to spend significant $$. As it was, I picked up a complete 7800 system (including the all-important power supply) along with some carts to tide me over until my CC2 is done. Lots of 8 bit and 16 bit era stuff (lots of 2600 carts), along with a surprising number of TV-tennis games and LED based handhelds.

I plan on attending, and will be looking very hard for a 7800 for sale. PS I plan on wearing my AtariAge T-Shirt, and will have a pen for anyone who wants their copy of Skeleton, Skeleton+ or Activision Anthologies autographed. No, I won't be bringing any copies to sell.

Hmm, an interesting challenge. But I think it could be done. The main limitation would be the cartridge would have to physically fit in a 2600. So no extra address lines for the 7800 version, thus both the 7800 and 2600 versions would have only a 4K ROM address space. (Plus, the 7800 version loses access to 2K of the 4K RAM due to address shadows.) Now, the next question is whether the game can determine whether it is running in a 2600 or a 7800. That could be done by writing different values to $00FF and $01FF and then reading them. On the 2600 the read values will be the second value written, while on the 7800 it they would be different. The next challenge would be bankswitching. It should be possible for the 7800 game to use 2600 style bankswitching by writing to certain hot addresses. The one problem would be if which bank is live when the 2600/7800 starts is unknown. Then the 120 byte 7800 digital signature + 2 byte 7800 flag would have to be in all banks, along with some startup logic. One neat possibility is the 7800 version could change over to 2600 mode and start that version. (Assuming the 7800 bios doesn't lock the mode.) Of course one big problem for developing such a beast would be lack of support for 2600 bankswitching in the 7800 emulators and development carts (e.g. CC2). Though I suppose it could be added.

Since Skeleton+ has been mentioned, I will add my own C$0.03... First, both AA and PackRatVG are authorized Skeleton+ publishers and the royalty I receive is the standard $5/cart which was established back in the Hozer days. However, as has been pointed out, the labels and manual etc. are unique. PackRatVG also has clear carts available. I fully support this way of adding value and being distinctive. I do think is is unfortunate and short-sighted for AA and PackRatVG to compete on price.

As per Albert, the A7800 has two modes 2600 (TIA video and 2600 memory map) and 7800 (MARIA video and 7800 memory map) which are controlled via some descrete logic on the mainboard. However, the if 7800 BIOS determines that the cartridge is a 2600, it locks the A7800 into 2600 mode before turning control over to the cartridge ROM. As for porting games from the 2600 to the 7800 - the graphics models are very, very different. So while it might be possible to re-use a lot of the game logic; anything to do with creating the visible display would need to be totally rewritten.

Found this: http://xtronics.com/memory/how_EPROM-works.htm which gives a good overview of the various *PROM technologies.

Very cool. I'd seen some references to RFK before but didn't "get it". Did you do this using cc65 or asm? I'd be interested in seeing the source code in either case. (Might even be able to figure out the bugs Mitch saw.)

I believe flash-ROMs are a kind EEPROMs (Electrically Erasable Programmable Read-Only Memory). "Flash" usually has some connotations regarding the speed/ease of the erase/write cycle and may also imply the granularity it can be reprogrammed. (e.g. byte, row or page) The trick with EEPROMs is whether they are pin compatible with the equivalent ROM / EPROM, or have pins dedicated to programming. The erase/write method also usually requires applying weird voltages to certain pins. Oh, and PROMs (or OTP = One-Time-Programmable) exist. They are often electrically the same as an EPROM, but are in cheaper packages which lack the UV window. I also recall (from when I was working with the things 10+ years ago) occasionally finding a "bad" EPROM or EEPROM which couldn't be reprogrammed successfully. They would fail the verification step and be discarded.

This is probably over-detailed, but you asked. Each paddle is a variable resistor with the resistance related to the position of the paddle dial. Inside the 2600 the paddle is connected to a capacitor and a transistor which senses whether the capacitor has any charge. Each frame the game discharges the capacitor during vertical blanking. Then during the active screen the capacitor charges through the variable resistor in the paddle. The time required to charge the capacitor is proportional to the resistance and thus controlled by the paddle dial. The more frequently the game checks the sense transistor (typically every line), the more accurately it can determine the position of the paddle dial. This takes at least 8 cycles per paddle, or >10% of the CPU time available to draw the display.

What you describe would be implemented in hardware. A circuit (which may be built into the custom ROM) detects the power cycle and cycles through which 4K of ROM is accessed by the 2600.

That's the clock input. Pin 3 for flip flop 0. I'd use pin 22 (~OE) output enable, and tie pin 20 (~CE) chip enable to ground. ~CE high is often used to put a RAM or ROM into a low power state and it might require time to become active. ~OE controls the output and tristates the databus when high (which is what we want). correct

Get the latest bin at http://ericball.atariage.com/spacewar.zip and read the latest journal updates at http://www.livejournal.com/users/spacewar_a78/.

Nope, I used the source ZIPs rather than CVS. At least the compile instructions have been updated!

Has anyone managed to activate the debugger in MESS a7800? I've pulled down the source for 0.79, set the DEBUG file in the makefile & recompiled, turned on the debug flag in MESS.INI, started MESS from the command line with the -d parameter... Aggh!

Just some clarifications & replies. I had hoped that AtariAge and/or PackRat VideoGames (maybe even VGWiz) would be able to produce SpaceWar! 7800 cartridges. Sticking with 4K would make this very possible since they could use the same parts they use for other 4K 2600 homebrews (like Skeleton+). When I talk about no-frills, I'm not referring to the cartridge & packaging (e.g. box, label, manual etc), but more the game itself. Few variations, no title/attract screen (or score display for that matter), etc, etc. The problem with attempting a game of this scale is the huge amount of time & effort required. Hmm, maybe...