EricBall

Pokemon has always tried to emphasize human interaction & GameBoy connectivity. Thus, if you wanted to collect every Pokemon, you had to cooperate with a friend with the other cartridge.

Ahh... the production side of things. Yeah, lot's of flux left there I imagine. The whole reason to shoot to tape is to skip the film & telecine cost. But then you have the high cost of avoiding compression on the camera side. [email protected] is the logical target (at least for capture), but that's space and bandwidth hungry. [email protected] is half the data rate, but I don't know whether that translates into a similar reduction in equipment costs. 720x480 anamorphic? Not HD, but again it depends on what equipment (used?) is available.

No, it's not a complete runnable sample. The intent was to provide some skeleton code that other 7800 programmers could use to get a head start.

I may doodle in meetings, but my efforts don't even start to compare to yours. What HD can-o-worms specifically?

In which case there may be some value in mapping various float sizes to fixed point lengths. i.e. single -> 8.8, float -> 16.16, double -> 32.32

Yes, there's always a certain percentage of mutants (or at least trainees) working at McD's. However, when I was working there the managers usually were smart enough not to stick 'em in drive thru. (Tough enough taking an order over the equivalent of a bad walkie-talkie while taking the money from someone else.) I don't believe there ever was a Big Mac without cheese. (Two all beef patties, special sauce, lettuce, cheese, pickles, onions on a sesame seed bun.) But when I worked there in high school the Quarter Ham was actually on the menu (at a lower price than the cheese version, to boot). And it's basically an industrial version of Kraft Singles in that purgatory between Cool Whip and actual cheese. My wife typically orders a Quarter Cheese plain (i.e. cheese only). Most of the time the mutants get it right, but sometimes they manage to mess it up. Never only gotten half the bun though. (Don't know how they do it now, but in my day you built quarters upside down.) And most of the time we eat in rather than doing the drive through.

The code isn't all that dynamic. The start address of each display list is fixed in memory. (A truely dynamic DLL/display list builder would build the display lists one after the other. But that would be a whole 'nother level of space versus speed.) About the only "dynamic" part of the DLL is the code creates the visible portion on the fly as part of initialization. Yeah, the whole DLL could be coded in ROM, then copied to RAM but I'd rather leverage the pointer array needed for the display list builder.

As per supercat's suggestion in my 7800 cycle counting blog entry, herein find an alternate version of my sample 7800 display list builder using the unloved (zp,x) addressing mode. The main advantage is a surprising savings of 25 cycles per sprite (161 versus 186), although some/all of this may be lost when wrap around is added. The disadvantage is the routine requires 2 bytes of zero page RAM per display list. I've also added the dummy 5 byte sprite header to set Write Mode which was missing from the first skeleton. 07/04/29 EDIT I discovered when I went to update my bouncing ball demo to use the (zp,x) display list builder that my skeleton code had a few problems. I've now completed the updates to the demo (attached). balldem2.zip

I just converted my sample display list builder (no wrap, no background) to use (ZP,X) and it does require fewer cycles (34 per DLL versus 39 & 161 per sprite versus 186). I'll modify the rest of the sample code and post it.

Floating point is most useful when you have to deal with numbers over a wide range of magnitudes. (e.g. calculating the kninetic energy of an electron travelling at half the speed of light) But in a game you typically need numbers over a finite range (i.e. +/- 1,000,000 to a precision of 0.000,001), which is exactly what fixed point provides.

Yep, she's gonna kill you if she sees it. Quick, go rent a u-store-it and dump it there. Then, you can gradually sort through it and sneak in the pieces you want to keep over time.

SpaceWar! 7800 is based on 8 line zones (for the background tiles & shot sprites), so it would be 240/8*2 = 60 bytes for PAL. However, since ZP,X is the same number of cycles as ABS,X/Y the sprite info tables could be moved into main RAM without any time penalty (extra byte though). Anyway, I'm going to go back and rework the display list builder from scratch. Really focus on cycle counts and less on space. I'll see if (ZP,X) would be better.

See my sample 7800 source code post for closer to the minimum number of cycles per sprite (186 cycles). But, as I pointed out, the SpaceWar! 7800 code has some additional requirements (i.e. wrap around) which increases the number of cycles per sprite. SpaceWar! 7800 also uses subroutines to reduce the space requirements, though maybe I need to re-think some of that. Oh, now I get why you're using (ptr,x). Hmm... An interesting idea. Too bad it would require 2 bytes per display list, that's a lot of RAM. It also requires 12 cycles for sta (ptr,x) + inc ptr,x versus 7 cycles for sta (ptr),y + iny. The 7800 also has two lists. The display list list (or DLL) which has a pointer to a display list and the number of lines (1-16) to use that display list (and is basically static). Each display list is made up of a number of 4 or 5 byte sprite headers which contain a pointer to the graphics data or tile list, the width of the sprite (1-32 bytes), the horizontal position and the palette. The "kernel" of a 7800 game is the display list buider, which maps the sprite Y postitions to display lists, then adds the sprite header to the lists.

I'm already starting to create the display list immediately after the visible screen has finished displaying. (Although that reminds me, I should update the DPP registers earlier since the display list builder might not be finished before DMA starts.) Double buffering the display lists would also increase the complexity of the display list builder and significantly cut into the number of sprites each display list could handle (since the RAM requirements would double). The problem is simplly the number of cycles it takes to create the display lists.

I've done some cycle counting of the display list builder for SpaceWar! 7800 and the results aren't pretty: 103 cycles per display list (25 NTSC, 30 PAL) 403 cycles per player sprite, +191 for horizontal wrap around 248 cycles per non-player sprite, +82 for horizontal wrap around 50 cycles per sprite header vertical wrap around 200+ cycles of overhead At 114 cycles per raster, just the display list builder is going to chew through all 62 lines of VBLANK. So, what to do? 1. Optimize where possible, but otherwise ignore it and risk having the display stutter. 2. Alternate frames building display lists and game processing. I'd need to recalculate (or fudge) all of the gravity & velocity tables since it would be effectively 30fps instead of 60fps. #2 sounds feasible, just need to add the DLI wait routine after the display list builder. Note: SpaceWar! 7800 doesn't do itself any favors when it comes to the display list builder: 1. 4 way scrolling tiled background 2. 4 way wrap around 3. player sprites are double height versus the zones

Yeah, but it also meant you could have non-integer FOR/NEXT loops. The Apple ][ had graphics routines built into both BASICs. Integer Basic even had "shape tables" although they were far too slow to use for anything serious.

Good advice, although it wasn't me who gave it.

This is hopefully the start of a series of 7800 source code skeletons, each building on the next (or variations on a theme). I'll also put this on the mailing list for good measure. This skeleton contains both a simple DLL builder and display list builder. Nothing fancy, no scrolling backgrounds or wrap-around, not even any error checking to make sure you don't add too many sprites to a display list. This is also not a complete program, though I've tried to include almost everything required. skeleton1.zip

I did a quick merge of the rest of the 4K SpaceWar! 7800 code so now the ships move & fire again. Of course there were problems - the main one being top-to-bottom wrap around. Turns out there was a bug in the 4K version, it didn't handle it properly either. Although the code wrapped around the display list pointers correctly, it didn't handle the end of display list index correctly. Thus, it tried to add the sprite to display list 0 using index 25, wiping out the display list. Ick! I still want to do some cycle counting and see if there's any possible optimization of the display list builder. I should also zero out the display lists at startup to prevent MARIA from going runaway if the active screen starts up before the display lists are built. Then I need to make a list of features to add to make the "game" itself. One of the ideas I'm toying with is an energy counter. Rotation/Thrust/Fire would deplete your energy (which would slowly replenish, but maybe make that an option). Hmm... how to handle regeneration? Would you come back with a full tank? Of course, kill counters & SFX are on the list. I don't think a one player mode is in the cards unless someone can come up with a reasonable AI. I'd also like to do some kind of title screen, but that's low priority. Oh, I'll also slow down the starfield so it's more of a slow drift. I'm also working on some sample code skeletons for other budding 7800 homebrewers. Watch AA and the mailing list.

I suspect FORTRAN still gets used a fair bit by the scientific community where "Formula Translation" is still required. (Although I bet newer languages like MATLAB have taken over a fair chunk of the pure numerical analysis.) My father told me that when he was getting his MBA he wrote a FORTRAN program to determine the possible 6x10 pentomino solutions by brute force. Apparently the CPU time it required was rather significant for the time.

Curious that the two games you are playing now are ports of PC games.

Although you may have lost Drak Tower by $1, there's no guarantee that the winner didn't have a much higher top price anyway. When I bid on eBay, I put in my top bid and walk away. If I win, great! If I lose, I just watch for the next auction. I find checking out "completed listings" to be a great way to get a feel for what an item will go for (assuming they come along more than once in a blue moon). Favorites searches with automatic emails find things I'm looking for, which I then watch to see how the price goes. (I'll typically only bid when there's less than a day to go to limit the number of irons I have in the fire.) I'm not sure I get the attraction of sealed games. It's not like Star Wars action figures where you can at least look at them, or a whiskey which gets better with age.

Given the limitations of the 2600, being able to squeeze any kind of programming language (no matter how rudimentary) into a 4K cartridge & base RAM is impressive. But although getting the elephant to dance is amazing, how well it dances is considerably less impressive. I suppose Atari could have made a a BASIC-like language which would have been more usable for creating games. The big limitation would have been the 128 bytes of RAM. But maybe something which would allow control over the 5 motion sprites.

I've merged in the initialization and display list builder code from 4K SpaceWar! 7800 and made the necessary tweaks to handle the moving zones. Fun! My main problem with this code was I kept running out of ZP RAM, which would push a (ZP),Y pointer variable to $FF, which doesn't work at all. I first ran into the problem when I put in the initialization code and tweaked the display list initialization (so the constant parts of the tile headers only get written once). Kaboom! So I dragged out the EP code and started undoing changes with no success. Then I started anew and did one thing at a time. Step #1 - add ZP RAM variables. Kaboom?!? DASM really should warn you when DS crosses a page boundary.... Okay, so that's working. I need to write the code to create the last display list based on the first display list so top/bottom wrap around works. I also want to see if there's any cycles I can squeeze out of the display list builder code somehow then do a cycle count (ugh!).

According to KLOV the following arcade games were released in 2006: Aliens Extermination from Global VR Dance Dance Revolution SuperNOVA from Konami Metal Slug 6 from SNK Playmore Rockin Bowl-O-Rama Namco 2006 Videogame The House of the Dead 4 Sega 2006 Videogame Virtua Fighter 5 Sega 2006 Videogame Pirates of the Caribbean (pinball) from Stern World Poker Tour (pinball) from Stern Pretty thin pickings. Two gun games, another DDR sequel, a 2-D side scrolling shooter, a 3-D fighter, and a trackball based bowling sim, and two new licensed pins. And the majority of the vids are sequels.