EricBall

http://www.classicgaming.com/vcsp/ http://www.classicgaming.com/2600ce/ Personally, VCSp seems like the way to go: figure out how to make the circuit board as small as possible, add screen & controls, then build a case around that; versus the 2600ce method of coming up with a case design then trying to figure out how to make everything fit.

Note: I have no interest in making the cartridges myself. I hadn't considered the possibility of canibalizing other 7800 carts. That would certainly work around the PCB issue, although it would increase the effort to make carts. Mitch & Happy_Dude, you didn't answer my questions.

For those of you who haven't been watching the project diary at http://www.livejournal.com/users/spacewar_a78/ you will be happy to know that the game is progressing nicely. My current problem (other than some elusive bugs) is the ROM is nearly 4K. (Actually, I am quite happy that I have been able to accomplish as much as I have in 4K.) In 4K I should be able to have a functional game, complete with gravity. Unfortunately, there won't be any frills. (Ships will wink out of existance when hit etc.) The advantage to sticking to 4K is the game can be put in a standard 2600 4K cartridge (though it won't play on a 2600 obviously). So there shouldn't be any problem convincing AtariAge and other sites to make real carts for those people who want them. However, if I go beyond 4K then a new PCB will have to be made, and I don't know if demand will be sufficient for the upfront costs. It might be possible to use 2600 style F8 bankswitching, although the result will be more like 6K due to mirrorring requirements. Plus no emulator support and a lot of additional complexity. So I put it out to the community. How many of you would buy SpaceWar! 7800 on a cartridge? How much are you willing to pay for it? Would you be content with a no-frills 4K version? What if the 4K version was available on a cartridge, but the 8K version was only playable via an emulator or RAM cart (e.g. CC2)?

Although this is true for C and C++, some languages use array indicies of 1 to n. Trying to write to (and sometime read from) array elements outside of these bounds can cause problems. (Trust me, I one had a bug in a program which wrote to array[-1]. It took a long time to figure it out because the program didn't crash until it exitted.) Ahh, but you have. stdlib is a C library with a bunch of functions. cin & cout are part of the C++ iostream library.

IMHO one of the things NES homebrewers need to do is to write code which doesn't require complex mappers. Sure MMC3 & MMC5 have some neat capabilities, but then you are limitting yourself to emulators or canibalizing specific carts. If an NES homebrew uses an LS161 style mapper (i.e. one which can be created with off the shelf TTL logic or simple PLAs), or even no mapper at all, then it is at least feasible to manufacture the cartridges inexpensively. (Yes, the NES has a lockout chip, but defeating it is an easy mod.)

Since most 7800 code comes down to data movement and basic operations (versus time-critical), it might be possible to write something for the 7800 using cc65. Obviously anything text based is out without a lot of work. But efficiency is still the name of the game and even though cc65 was written explicitly for the 6502, I think the objective was more to be able to compile as much legal C as possible versus creating efficient 6502 code.

Find yourself a partner that already knows C++. That's the only way you are going to survive that kind of course. Besides, real C programmers use pointers. All the compiler is doing is checking that your program is legal C++ syntax. It's kinda like a spell checker - it doesn't care whether your sentances make sense, or that the plot doesn't have holes in it.

I've extracted my Videobrewery diary from Google's cache and put it on http://www.livejournal.com/users/spacewar_a78 and started updating it with my current progress.

Some other advice - Although C++ is a popular programming language, IMHO, it's not the easiest one to start learning with. You might be better starting with straight C, Pascal or even Basic until you are comfortable with procedural language concepts. (Non-procedural languages are a different breed entirely.) Once you have that done you can work on adding OOP. - Programming is breaking ideas down into very simple tasks, then linking those tasks into routines and then integrating those routines into applications. - Don't start programming with the things which happen first in time, concentrate on the most basic functions of the program and build out from there. - Don't re-invent the wheel! Most HLLs have function libraries which can speed up development considerably. - Don't just learn from your mistakes, anticipate where you might make an error.

Although it should be possible to accomplish what you want to do with DASM, you will probably be better off using the same 6502 assembler that other NES homebrewers use. The .bank etc commands are used by the assembler to handle the NES mapper (bankswitching) and iNES file format.

Ahh, the eBay feedback Mexican standoff. But in this case the guy that shoots first gets the sharp end of the stick. Anyway, in my little eBay experience negative feedback hurts sellers far more than it hurts buyers. No one wants to buy from a seller with negative feedback, but a seller often can't be as picky about buyers. Plus, the seller usually fronts the $$, so if often taking the greater risk. So go ahead an leave the negative feedback & try to be as accurate as possible with the reason (given space limitations). And if they choose to retaliate, make sure you provide additional comments to both feedbacks. And if you really feel that you have been burned, you could always see if you can get a refund or work through eBay's various programs.

Yeah, I snagged that earlier once I learned that the problems weren't temporary. It doesn't have my most recent updates, although those I think I can recreate.

Check out my 7800 mega sprite demo (source included) http://ericball.atariage.com/balldemo.zip

Sigh, I had just posted an update to my SpaceWar 7800 diary, gotten a comment even, and was thinking that I should make a copy for myself "just in case". And although I could make nasty comments about lack of backups, this incident has motivated me to make a backup of my documents.

Is it just me or has this topic turned into Aliens vs Predator?

Am I correct in assuming that I will need to replace the power supply in order to use a PAL 7800 in North America? (I'd use by PC's video capture card, which handles PAL, instead of a TV.)

Buncha stuff 1. The NES can produce 53 colors (black + 4 grey/white + 4 shades of 12 colors), using a method very similar to the 2600/7800 (which had 256 colors: 16 shades of 15 colors & greyscale) with 4 luma values for each chroma phase. The 3 NES color emphasis bits could be used to create additional colors, but not on a per pixel basis (maybe per line). The one advantage with the NES is all of the colors (other than black) have a higher base luma than the 7800, so are inherently brighter than 50% of the colors on the 7800. 2. I suspect that some of Bry's judgements have more to do with the TV he has than the inherent limitations of the 7800. 3. The NES NTSC pixel aspect ratio is about 10:9, while the 7800 NTSC pixel aspect ratio is 5:3 (160) or 5:6 (320). The closest to square pixels is a PAL 7800 in 320 mode, where the pixels are very, very close to square. I've also been looking at the sound capabilities of the NES and there is no contest, even against a POKEY. DMA streamed delta modulation for sampled sound! Wow!

In order to even consider doing something of this scale I'd have to be provided with the full, well commented, source code for the game. ('cause the game isn't just the graphics, it's the gameplay. And that isn't trivial to reproduce.) Agreed. The Castlevania screen shot in particular shows a considerable number of background tile colors, which would be more difficult to duplicate on the 7800. On the NES tile palette selection is done via the Attribute table (which affects blocks of tiles), while on the 7800 it's part of the display list entry. On the 7800 it's preferable for the background (or at least a full row of tiles) to use the same 4 color palette; changing the palette mid-row would require an additional display list entry = increased complexity & CPU usage.

The 2600 part of the 7800 gets used for sound and joystick/paddle/switch I/O. And the 7800 dev docs refer to the 2600 dev docs for that info.

Hmm, well since the files are 4 color, you should be able to convert it to any number of graphic formats using Irfanview (e.g. BMP, PCX) and use a paint with a very zoom / pixel editing capabilities. Of course, that then leaves you with a file you would then need to convert back into a bin/a78, for which a tool doesn't exist yet. (And no, I have no plans to write such a converter either.)

The 7800 does contain the RIOT and TIA chips used in the 2600 and also uses a 6502 based CPU. However, the 7800 only uses the RIOT to interface with the joysticks & switches (but doesn't use the timer or RAM), and only uses the TIA for sound to interface with the paddles and buttons. The 7800 does not use the TIA for graphics, but uses the MARIA GPU; which has very, very different graphics capabilities than the TIA. The 5200 & 8 bit computers are souped up 2600s from a graphics standpoint; just with the dedicated ANTIC GPU automatically updating the player/missile graphics every line and changing the color of the playfield every pixel.

The 7800 does contain the RIOT and TIA chips used in the 2600 and also uses a 6502 based CPU. However, the 7800 only uses the RIOT to interface with the joysticks & switches (but doesn't use the timer or RAM), and only uses the TIA for sound to interface with the paddles and buttons. The 7800 does not use the TIA for graphics, but uses the MARIA GPU; which has very, very different graphics capabilities than the TIA. The 5200 & 8 bit computers are souped up 2600s from a graphics standpoint; just with the dedicated ANTIC GPU automatically updating the player/missile graphics every line and changing the color of the playfield every pixel.

Okay, I've been looking at some NES development docs, so i have a better feel for what the NES can do. One important item is the NES is more "fixed function" than the 7800, though it appears there are "tricks" which can be done in code or via "mappers" (logic in the cart, mostly for bankswitching, but sometimes for much more) which involve changing the PPU (the NES GPU) state in the middle of the frame. Typically these tricks are CPU intensive since they require tight syncronization between the CPU and PPU. The 7800 has very few "tricks" both because they typically aren't necessary (i.e. the flexibility exists already), and also because the CPU mostly can't change MARIA GPU processing on the fly. CPU <-> GPU coupling The 7800 MARIA GPU shares RAM, ROM & access time with the 6502. So while MARIA is creating each line of the display, the 6502 is halted. A 7800 game may also have to spend significant time creating the display lists. The NES PPU has it's own address space, which is only indirectly accessible by the CPU. This gives the game more processing time since the 6502 is not halted during picture processing. However, the CPU can only access PPU address space (to update the tile maps) during VBLANK. Advantage NES - more CPU processing time One interesting item is the 7800 MARIA/TIA registers are mapped to zero page addresses while the NES PPU/pAPU registers are not. So register accesses require one less byte and one less cycle on the 7800, but an NES game uses these registers far more than a 7800 game. Interesting design choices. Cartridge RAM/ROM A mentioned, the NES CPU and PPU have separate address spaces. The NES cartridge connector reflects this, having separate CPU and GPU address and data buses, and separate ROMs for the CPU and PPU. This automatically makes NES carts larger and more expensive than the basic 7800 cartridge. The big N also went with a hardware lockout chip while Atari went with a software digital signature. It goes without saying that later NES cartridges were more complicated (RAM, battery backed RAM, mappers, huge ROMs) than Atari made 7800 carts. Advantage NES - 'cause Nintendo spent more $$ System RAM While both the NES and the 7800 contain 4K of RAM, there are some important differences. The NES splits the RAM into 2K usable by the CPU for general storage and 2K for the PPU (indirectly accessible by the CPU) used for the tile maps (with additional on cart CPU and PPU RAM possible). The 4K of 7800 RAM is completely accessible by the CPU, but a large chunk of it (2K or more) will be used for display lists and tile maps (depending on the game). A few 7800 carts also had additional RAM for general storage. Advantage NES - fixed function uses less RAM Tile processing The NES has a fixed 32x30 tile map (with scrolling), with 8x8 tiles. The tiles are 3 colors (plus background/transparent), with a block of 2x2 tiles having the same palette (of 4). The 7800 has more flexible, though similar, tile capabilites; but they consume a large chunk of the processing power of the MARIA GPU (tiled background = fewer sprites per line). The NES also requires less CPU power to achieve the same result. Advantage NES - simple & effective fixed function versus CPU & GPU hungry flexibility Sprite processing The NES has 64 sprites (max 8? per line), though it may be possible to change this on the fly to increase the total number of sprites displayed. Each 8x8 or 8x16 sprite has 3 colors (plus background/transparent) out of 4 different palettes (different palettes than tiles). The 7800 can display an enormous number of sprites (not fixed size either and with better color capabilities) both onscreen (256 easy) and on a single line (30 with no background). The problem is the CPU processing required to build the dynamic display lists. Advantage 7800 for pure sprite capabilities, but NES gets the nod for easier to use Conclusion: Although the 7800 MARIA GPU has the capability of creating better graphics than the NES, it is hamstrung by the amount of CPU power required to maintain the display lists needed to create those graphics. Plus, the 7800 GPU halts the CPU while the graphics are being created, further reducing the amount of CPU time available to the game. The NES wins out with it's easy to use fixed function GPU which leaves the CPU free to execute more code per frame.

Re: 7800 being as super 2600 As Drac said, the 7800 MARIA GPU is unlike anything the 2600 (or 5200 & 8bit, which really are the super 2600s) has. The 7800 is to the 2600 in the same way the PS2 is to the PS1. Both the 7800 and the PS2 contain compatible hardware used to play the 2600/PS1 games which is not used in 7800/PS2 mode. Not having programmed the NES, I cannot compare it directly to the 7800. However, the MARIA GPU is fairly powerful (though not without some limitations), and there are impressive games for the 7800 including several very good arcade ports. Re: Donkey Kong Country for the SNES It is my understanding that this game is more an example of what can be done with massive storage space and pre-rendered sprites than an example of what the SNES hardware can do on it's own. Re: colors The Atari consoles (and probably the computers) all create color via direct Y/C. And because the Y output is linear, that means (due to how gamma works) that ~50% of the colors are fairly dark on a normal TV. This probably is more an issue for current developers (who use emulators with over-bright palettes) than the original developers (who would have tested on real hardware, though maybe with "hot" TVs). I will agree that probably the biggest factors in 7800 development are time, money & effort. I can see that the hardware is capable of great things, but I don't have enough time to create huge games. The main limitations of the 7800 hardware are: 1. TIA sound versus POKEY cost 2. ROM size versus bankswitching cost 3. CPU time (for both game logic and time required to build the MARIA display list) versus graphics complexity & game responsiveness 4. no generic framebuffer (not that the 7800 has the CPU power to really use a framebuffer anyway) 5. MARIA GPU power (and RAM) for massive numbers of sprites with a tiled background 6. Only 3 colors per sprite (although sprites can be layered)

My 3 year old sometimes manages to persuade me to play a game or two while he watches. The only problem is he typically loses interest before I do. I'm also trying to teach him not to simply rip the cartridges out (while the 2600 is still on) when he's done. He also enjoys watching me play various N64 games and has a small library of his own PC games (though he needs help with the mouse).