EricBall

Again, thanks red for typing in the list. Skeleton+ is available from both AtariAge and Packrat Video Games, both which offer other homebrews as well. Personally, I have not heard from Randy since before his website was taken down. I received from him SGaNBv2 and $5 cash in royalties and considered the matter closed. (Although I was happy to learn that he seemed to be continuing to sell SGaNBv2 since it is a must have for any Supercharger owner.) If Randy had simply been giving away old stock, or even selling his personal collection, I might not have objected. But, to create a new catalog listing Skeleton!, I'm starting to get cranky. It would be interesting to find out what Skeleton! is. It could be the original Skeleton (which Randy did have my permission to produce), the updated Skeleton+ (which Randy does not), or (I hate to suggest it) something completely different (e.g. an unauthorized hack). In any case, my request/recommendation to all would be to restrict your dealings with Randy to SGaNBv2, until such time as he decides to formally reopen Hozer Video an clear the air of any confusion.

I half remember the game. IIRC the gameplay is similar to Galaxians/Galaga/Phoenix, so a 2600 adaptation would be similar.

Very strange. I thought it might be a problem with the TV, but you are having the same problem with different TVs too. Have you tried plugging the coax into the antenna/cable input on a VCR, and using the RCA A/V outs on the VCR? Do you know anyone else with a 2600 or CV who you could swap with? Also make sure you have the correct channel selected on the 2600/CV and the TV.

I assume the keyboard attaches to the 7800 via the joystick port. Maybe if would be better / easier to modify the code to handle input via a different method like the 2600 keypads. (Same as the Monitor cartridge.) Although I admire the effort, I wonder if will be worth it. Although 7800 Basic might be interesting, I just can't see the other two having any appeal outside of historical completeness. What is 7800 Basic capable of? Text only, or does it have some kind of graphics/sprite capabilities? 10 PRINT "HELLO WORLD" on a 7800 just seems kind of boring.

Interesting specs: * Third-generation Motorola 68HCS12 16-bit processor @ 25 MHz. * FPGA with graphics processing unit. * Graphics architecture similar to Commadore 64, Atari 800 and Apple II. * Polyphonic FM synthesis and digital sound channel. Sounds like a 286 with VGA and a SoundBlaster :wink: Oh take me back to 1989! It might be interesting to fiddle around with, depending on the pricetag, but that goes for a lot of other things which I don't have the time for too. It sounds like Nurve is trying to market this as the ultimate toy for the uber-geeks, but I'm not sure how many of those are out there.

Unfortunately, there are just too many differences between NTSC and PAL to make a universal TV standard console. Also remember that the TIA only knows how to draw a single line; it's up to the program to keep track of how many lines have been drawn and handle vertical synch. (Thus, it's possible for a 2600 game to contain both versions and make it selectable via the switches.) The MARIA (7800) handles the vertical synch automatically, and it's possible to for the game to determine the number of lines and thus NTSC vs PAL. However, the game then has to also handle 50 vs 60 Hz frame rate and 240 vs 200 lines per frame. Creating both versions of a game requires effort and is not trivial.

In my opinion, there are simple hacks (typically changes to the graphics) and hacks where the "hacker" has made significant code changes (most of the Hacks available in the AtariAge store). Hack-O-Matic facilitates the first, Distella the second.

I disagree totally. The only thing holding people back from developing for the 7800 is desire. There is plenty of documentation available online at http://www.atari7800.org/manuals/Devcard.htm. a78sign is available to create the digital signature required by NTSC systems. MESS does an adequate job of emulating the system (although it is not perfect by any means). Chad has a working prototype of the Cuttle Cart II for system testing without an EPROM (or Eckhard's RAMcart). About the only thing missing are the PCBs and cases for actual sale (and the guys at www.atari7800.com may have those too). And Senso DX is a true homebrew. (Plus the demos I and other people have done.) And the 7800 is actually easier to program than the 2600! No cycle counting required for precise timing. A big chunk of the coding is simple data movement to build the display lists. And yes, I am working on an actual 7800 game myself. Lack of free time, not desire, is my roadblock. So if you want to program a 7800 homebrew, there isn't anything hold you back. And it sounds like the market is ripe too!

First, there is no difference in AI or mazes between Skeleton and Skeleton+. I may have covered this before, but the Skeletons mostly just wander around the maze randomly. When they come to an intersection, they will randomly chose between paths. At a dead-end they do a 180. The exceptions to this are when they have been shot but not killed; in which case they turn to face the player. And second they will walk forward (if possible) if the player is in front of them, even if there are walls between the Skeleton and the player.

Both Skeleton (next to impossible) and Skeleton+ (difficult, but doable with practice & luck) are "winnable".

Since the 2600 and the 7800 both use the TIA for sound, sharing that is easy. (Especially if it sounds halfway good.) I was going to say that because the 2600 and 7800 are so different from a graphics point of view that nothing else could be shared. However, re-thinking this, there may be a chunk of game logic which could be common. How the sprites move & interact, player controls & enemy AI. It wouldn't be easy, nor always possible, but it reminds me of a story about Lode Runner (I think) being ported to two other 6502 systems. One port started with a clean slate, the other took the existing code and reworked it for the new system. Guess which finished first and had fewer bugs?

Just my C$0.03 worth (having not read the rest of the thread): As Debro says, the decision is completely up to you. But, IMHO, a new release is only warranted when you can make significant improvements to the game. Otherwise creating a sequel or a completely new game will be more rewarding.

(Note: I haven't read the entire thread, but since Skeleton is mine I will respond to the above comment.) Although there was considerable criticism made about Skeleton when it was released in cartridge form, the comments made were not the reason I created Skeleton+. No-one said "Skeleton would be ten times better if the player had a life counter". (Yes, there were several "Skeleton would be better if it had a kill counter", but that would not have improved the gameplay.) For more information about the development of Skeleton and Skeleton+, check out the pages on my AtariAge hosted website.

It might be possible to use C to generate code for the 7800. I'm finding coding for the 7800 to be mostly data movement work. And other than the DLL NMI, there isn't anything timing sensitive (though it's real easy to chew through the VBLANK time: building the DLL takes time). But ASM ain't that tough to learn if you already have a decent handle on using pointers in C. And once you learn ASM, you can start to see how a C compiler generates code. I don't know about whether it would be feasible to create a C library for the 7800. Maybe some headers. You'd probably still have to have the C compiler generate ASM files and tweak those as necessary. Maybe a 7800 specific C compiler.

Not to mention a very bizarre frame buffer memory map. (Adjacent lines are nowhere close to each other in memory.) I did a fair amount of Applesoft Basic programming back in the Apple ][+ days (along with playing the various games). I never did get into assembly language 'though; something about learning ASM on a 6809E which has 16 bit index registers.

256x200 makes sense when you have a frame buffer since it makes x,y to address calculations easier. Since the Atari 8bits all used a GPU of one kind or another without a frame buffer, it made more sense to link everything (including the CPU clock) to a single colorburst clock crystal.

This is true only of 320D mode. 320B mode has the same color capabilites as 160A (although the bit order is different). Just to clarify - positioning and transparency still use 160 resolution boundaries even in 320 modes. So 00 is transparent, while 01 is background/color 1. It means that sprite edges need to use 160 resolution, while the interior can use the background color as well.

Not so! The 7800 has four 320 modes: 320A is an 8 pixel 2 color mode (on/off), though each sprite may have a different palette (1 of 8 ) 320B is a 4 pixel 4 color mode (just like the normal 160A 4 color mode) from 1 of 8 palettes 320C is a 4 pixel 2 color mode, but each sprite may use 2 palettes 320D is an 8 pixel 4 color mode, but some of the color bits are shared and only 2 palettes are available It is possible to flip between A&C and B&D modes for each sprite. The 320 modes also have some quirks like positioning is still done at 160 resolution and transparency only works if both 160 half pixels are off, otherwise off gives the background color. I also just realized that you couldn't do a fully tiled background with either 320B or 320C; there isn't enough time each line for the GPU to draw more than the background.

Skeleton and Skeleton+ use a simple LFSR RNG which gets cycled once per frame (including during the title & end screens, so the initial state is unknown). The Skeleton "AI" uses the RNG to determine whether to turn at a branch in the maze when it isn't actively "chasing" the player. The RNG is also used to determine the damage a player's shot does to the Skeleton, and in Skeleton+, how much damage the Skeleton does per "touch" to the player. I would expect that there are many "deterministic" titles where player motion, actions & timing solely determine the outcome of the game. e.g. the ghosts in the Pacman arcade game follow a pattern or chase the player. I suspect that Video Chess does have a RNG to avoid having the game play the exact same moves all the time. This could be tested by playing several games and seeing if the computer will follow the same move sequence.

Let me see if I can explain this simply: The TIA in the 2600 (and 7800) has two independent audio channels each with volume, waveform and frequency controls. The output of each channel is a separate pin on the TIA. On the 2600 motherboard, the two pins are electrically connected before they are modulated into the RF video signal. So if you are using the RF output, you only get mono sound. The typical 2600 A/V mod, the audio signal is tapped on the motherboard, so again you get mono sound. However, if you disconnect the two pins on the TIA from the motherboard and tap them directly you get the two channels separately. For some games the two channels are used to generate a true stereo sound (e.g. Skeleton plays same sound but different volume from the two channels). Other games use the two channels in a similar but distinctive (e.g. Combat has a channel assigned to each player) or related (e.g. Synthcart) fashion. Finally, many games use the two channels very differently (e.g. Pitfall 2 has music on one, SFX on the other), so will sound "strange" when in stereo.

Based on Pitfall Harry's excellent explanation, EEPROMs will be subject to the same problem. Some types of OTPs may not be. Those which are EPROMs without a window will be; while those which are based on fuses (so programming causes an actual physical change, not just an electrical one) should not be. Check the datasheets for more info.

Typically you put a small label sticker over the window once you have finished programming the EPROM (properly labeled with a description of the contents of the EPROM). If you are really worried, use an EEPROM (electrically erasable) or an OTP (one-time programmable) which don't have windows.

A typical 7800 game is 32K or more, while the 7800 has 4K of internal RAM. RAM also gets used to build the sprite display lists for the MARIA GPU.

The bigger question is how the following should be handled: TMP EQU $80 BAD LDA TMP,Y Since a typical 6502 assembler considers all equates to be 16 bit integers. Thus LDA ZP,X is really just a special case of LDA ABS,X.

Correct. This is why it is supremo important to ensure that any lookup tables used in timing sensitive code (kernel) don't require calculations which cross page boundaries. For most 6502 instructions you can figure out the number of cycles required by counting memory accesses and remembering a couple of other rules: 2 cycle minimum, +1 for crossing a page boundary, +1 for branch taken. (There are exceptions of course...) ldy #1 = 1 cycle to fetch the opcode + 1 cycle to fetch the immediate value lda $00FF,y = 1 cycle to fetch the opcode + 2 cycles for the address + 1 cycle for the carry + 1 cycle to get the value from memory