EricBall

After much banging my head against the wall, I finally got the background scrolling smoothly. A lot of the problem was I couldn't keep straight which way was up. The next challenge is to integrate the code from 4K SpaceWar! 7800 and revising the display list builder to compensate for the moving background.

Mech Warrior gets old after a while. The game just starts throwing massive waves of dumb mechs at you. FF is tough to win. The tracks are also really long so you get quite the workout. But you're right that the majority of modern arcade games fall into a very small number of categories. My theory is realistic 3-D graphics restricts games to situations based on reality.

I recall playing Sargon vs MicroChess ][ on a pair of Apple ][s back in junior high. I don't recall who won though. Should be possible to duplicate the matchup with emulators.

You're right. Bruce Tomlin's ulta-mini would do 48K with a 74LS02 (and up to 1M with a PLD). And I think CPUWIZ had also developed a couple of PCBs too.

ROM is 32K without special HW. There's more address space available, but you'd need a PLD to keep the ROM from conflicting with RAM. So bankswitching would make more sense if you need more than 32K. Sprite GFX also chews up address space in 2K or 4K chunks. RAM is 4K but a lot of that gets used up for the display lists. (You do get 192 bytes of zero page, 50% more than the 2600!) For RAM heavy games (>1K needed) you probably will need to put SRAM on the cart. Also be aware that a 4 color 160res tiled background will consume about half MARIA's DMA budget. (And that's 4 colors for each row of tiles.)

related wisdom: - Don't use experimental compression software without . . . - Make sure you back up any applications you don't have install media for. This includes patches & updates to applications you do have install media for. (This goes double for device drivers and anything you aren't continuously updating.) - Try to back up configuration data too. This includes the Registry, the Protected Password Storage, and the Windows Product Registration files Finally, a backup which is readable without special software is worth double one which requires you to re-install the backup software first. (There's a rule of thumb I have had for a long while: if you don't want to type it in again, make a backup!)

The starfield now move up and down, following the sine wave, though in 8 line jumps. Smooth scrolling is next, but that requires some display list & display list list magic. I've also started using a 6502 simulator for general debugging. Since a lot of 7800 code is data movement, it's reasonable to use a general 6502 simulator. I caught a couple of bugs this way. The biggest problem is the built-in assembler isn't DASM compatible and isn't as capable. I've also made some major improvements to the SINE routine: SINE LDX #3 ; y[n+1] = y[n] - y[n-1] - y[n]/64K + y[n] SEC 3$ LDA STARY,X SBC STARYP,X STA STARYP,X DEX BPL 3$ LDA STARY+2 ; rounding EOR STARY ; reverse if negative EOR #$80 ; reverse for subtract ASL ; put in Carry LDA STARYP+3 SBC STARY+1 STA STARYP+3 LDX #2 4$ LDA STARYP,X SBC STARY ; sign extended STA STARYP,X DEX BPL 4$ LDX #3 CLC 5$ LDA STARY,X TAY ADC STARYP,X STA STARY,X STY STARYP,X DEX BPL 5$ Some of the changes are because StarY is 9.16 bits, so the MSByte is either 0 or -1 ($FF). This means the -y[n]/64K can use that byte directly as a sign extend rather than having two branches. The rounding calculation is also much simpler, again no branching required. I also realized I didn't need an extra temporary variable. Oh, I've also decreased the number of stars to those less than magnitude 5. I still can't pick out constellations though. FoV = 61 degrees horizontal, 42 degrees vertical which is fairly wide.

That was both easier & harder than I expected. The hard part was the usual lack of debugging tools on the 7800. The easy was more a reflection of how my 6502 coding skills have improved over time. Next challenge is to put in the Y & SINE routines. I also need to do some cycle counting and figure out how much CPU time the background starfield will eat. I'd really like to be able to recalculate everything every frame, but I have a sneaking suspicion I might need to interleave background & foreground processing.

Current status - static starfield complete (NTSC version) The next big step is turning the Star X,Y into DLL & DL entries and going to a dynamically built DLLs (one for on grid i.e. StarY&7=0) instead of the static DLL & DLs. Once that's done, I'll need to integrate the 4K SpaceWar! 7800 sprite to DL routine. Sorry if this is a little dense and cryptic. It's mostly for me to remind me of the design decisions which I've made (or remade). Reviewed old blog entries, found ROM memory map: 2K even star tiles, 22K (236x88) starfield tilemap, 2K odd star tiles, 2K code, 2K sprite graphics, 2K code/data/signature. Regenerated starfield tilemap & tile graphics from Yale Bright Star Catalog - all stars < 6 magnitude (visible to naked eye) mapped to 236x108 cylindar (avg of NTSC/PAL aspect ratio), trimmed to 88 rows. 236 tiles per row with first 20 tiles duplicated at end for easy wrap-around. 0,0 = bottom left (note: top left used for sprite positions) so StarY&7 is used for CHARBASE & SPRITE LSB offset on last row & sprite Ypos adjustment. Tile map stored with 0,0 at $8800. Quincunx (diagonal) sampling with bit 0 lower left and bit 1 lower middle right (next row middle at bottom middle left, right). 4836 stars in starfield. StarX is 2 bytes: 0-235 (row offset, two 4-byte DL entries per DL, width=21/20, handle wrap around by SBC & test) and -8 - -1 (Xpos + odd/even) StarY is 4 bytes (2+2 fractional). MSW is 9 bits (8 * (88-25 = 63 row) + 0-7 raster) stored as signed value for SINE routine, so the MSB is just a sign extend (very useful for the SINE routine). The initial values of StarY[n] and StarY[n-1] will need to be adjusted for PAL to keep the starmap onscreen. RAM will be primarily consumed by display lists (32 required for PAL). The two DLLs take up 213 bytes so can be stuck in $2100, which will extend into the stack page. That leaves 3.5 K for the display lists. Two possibilities exist. First, three 85 byte DLs per page. That nets 18 sprites per row. Second, allow the DLs to cross page boundaries giving 108-116 bytes per DL (depending on ZP overlap) with 24-26 sprites per row. Each player ship can use up to 4 sprite entries per row + shots. One option is to allow larger DLs for the rows which will contain the score etc. One important item for display lists, vertical scrolling and vertical wrap around. The current SW display list builder uses a additional DL pointer list entry for bottom to top wrap around. With vertical scrolling, the display list builder works in the same way. However, the bottom display list is basically just a duplicate of the top display list with the StarY & 7 offset! I will have to do some thinking to make sure the vertical shift can't push a sprite off the bottom of the screen.

Cool gameroom, although it seems a lot of the games need work. Maybe I'll actually finish the cocktail MAME cabinet I started (mumble) years ago.

Depending on the motherboard, you might already be at the max RAM (~4MB). It's probably also best to stick to DOS (hello config.sys/autoexec.bat). You should be able to run anything up to (and including) DOOM.

I think the issue is more one of timing than CPU or RAM requirements. When the game is thinking of it's next move, it's going to take a variable number of cycles to complete a search. So when to hit VSYNC? Now, it might have been possible to wrap a chunk of code in a timer test + VSYNC, but that probably would have increased the time per move by 25-50%.

Saturday my wife declared she had suffered enough cabin fever and declared we were heading out, preferably to a flea market in the area. She was looking for Premier League jerseys (ideally an authentic Joe Cole Chelsea blue), but I was keeping my eyes peeled for stuff to add to my Nintendo collection (although I've given it up for Lent, 'cause she convinced my son to do the same). I think I saw two booths with used games and premium prices. My target price these days is C$10 so seeing stuff three and four times that price doesn't inspire me to search. But another booth had a small selection but better prices. When I went back for a better look I didn't find any games, but did pick up a Super GameBoy for C$8. It turned out that the stock was from a local Cash Converters, so we drove over there to see what they had. There were a couple of N64 games (Paper Mario for me, Mario Golf for my son) but they were both over my target price so I gave them a miss. Surprisingly they had a display case full of VCS games, though it was a little wierd to see the huge number of duplicates. (I mean 2 or 3 of a title I can understand, but 10+ Defenders?)

The concept is interesting, although 12K & 256 byte samples might get a little limitting. You'd need some kind of Windows emulator for developing & testing the samples. How would you program the flash? The interface should be as asynchronous as possible (i.e. start/end points/looping), so the 7800 code can only do updates on a frame basis. Although a wavetable APU would be neat* (speech is a neat twist), I think a simple frequency generator would be much easier to use for music (though not for SFX). The easiest way is a wide accumulator with the MSB driving the output. Finally, how difficult would it be to put in a shift register (FIFO?) with an address decoder? Your code chews up a lot of cycles doing that shifting. (Also, the smaller the address footprint, the better.) * I loved my Gravis Ultrasound (original Classic); RAM+DSP+DAC. But I've always felt if they had included direct DAC access the same as a SoundBlaster Pro, they would have made a significant dent in the market. ('cause the FPS games of the time only used the SB DAC, not FM.)

Speech on the 7800 is possible, especially with a static screen. During the active screen the code would drop into a pseudo-kernel executing something like: LDY #10 TALK STA WSYNC STA AUDF0 LDA (PCMPTR),Y; PCMPTR points to pages of 4 bit PCM data xx10-xxFF INY BNE TALK The PCM would eat up 1 page per frame of sound, or 15K per second (ouch!).

One thing I've learned (and often have to remind myself) is my time is a finite resource, and needs to be treated much the same way I treat money. For example, one of the ways I "sour grapes" my desire for a pin is to tell myself I don't really have the discretionary time to spend properly maintaining and enjoying it.

WD-40 should not be used as a lubricant. It's designed to evaporate. It's best to leave WD-40 for it's original purpose - Water Displacement.

The Cuttle Cart is for the 2600 and uses a SuperCharger based audio interface. The CuttleCart2 is for the 7800 (supports both 2600 & 7800 games) and runs games stored on an MMC flashcard via a menu interface. You couldn't use an original CC for Beef Drop since it's a 7800 game.

2Gb/hour is compressed, just less compressed than what the system can do in realtime. (You may want to see if there are any settings which control the realtime compression. Some of what Susan may be seeing might be related.) Also be careful when setting those auto-record options. Check to see if there's options to make sure you don't get duplicates, repeats, and syndication of previous seasons.

And how badly have you gotten bitten by that bug? I'm just lucky I'm a natural skinflint, 'cause I so want to have a few pins & vids in the basement. Edit - I always forget that a spendthrift is anything but thrifty.

The major advantage film had over digital was resolution. But I'd be hard pressed to notice any difference between 19c Walmart prints from my wife's S3 and anything taken with a normal SLR. The big advantage digital has is the zero cost of taking a picture. No film, no developing, no bad prints.

Oh yeah. Both my wife and I love our TiVo. The only annoying item is some networks have apparently decided it's a good idea to fudge the start/end times of certain primetime shows so they intentionally overlap with the other networks. Thus my CSI:Miami (10PM) seasons pass conflicts with my Heroes (9PM) seasons pass 'cause the Zap2It guide data says Heroes lasts for 61 minutes. Thus I have to manually set up the recording for Heroes. Pfft.

For SpaceWar! 7800 I used a 352 byte lookup table for gravity. It worked fairly well.

Can you do b+20 > x ? since that would parse better to ASM.

N64 homebrews are possible, but there isn't a huge amount of development documentation available. And, somehow, I don't think the big N would look kindly on anyone selling actual homebrew cartridges. One observation I've made about homebrews is the ability to make homebrew games is inversely proportional to the generation of the console. I think there's four main reasons for this: 1. Hardware complexity. The 2600 is very simple - a 6502 CPU and a 1-D GPU, while the N64 has a CPU, a (programmable) 3-D GPU. 2. Anti-piracy measures. An NES homebrew either has to include the lockout chip, or the buyer has to mod their console. 3. Improved graphics means more detailed artwork is required. This also goes for the overall environment - i.e. level design. 4. Higher expectations. Robot Finds Kitten is amusing, but it barely compares to a first generation console title.