EricBall

It is with great joy (along with some other emotions ) that I announce the release of Skeleton+. This version has a kill counter and a life counter. Skeletons no longer kill with a single touch! I hope that this makes the game much more fun to play (and much more possible to complete). Attached are the current binaries, revised documentation and .pro file entries for Stella. I am hoping to shake out any remaining bugs ASAP so AtariAge and PackRat Video Games can start making cartridges with confidence. Please use this thread for bug reports. Please use the Skeleton+ Rants thread for flames and other negative comments. Thanks skelplus.zip

I'm not sure this will ever happen. The way the 7800 works means each line of a sprite is on a separate page. I guess this could be handled by a sprite editor, but it is more difficult than a typical 2600 sprite, where all of the bytes are in sequence. Sprites are also variable width (1-32 bytes), and there are several different graphics modes with some really strange bit to color mapping.

There's a quote which goes something like "the only person you must satisfy is yourself." If you aren't happy with it now, I can guarantee you won't be happy with it six months from now. But there's no reason that you have to tackle the re-write now. Sometimes there's nothing worse than having to work with the code you thought was done. So take a break, work on something completely different. You might find it easier to start fresh rather than try to adapt the existing code. It sounds like the change will be significant enough to warrant it. It also makes it easier to learn from your mistakes and where you had problems, than trying to buttress bad code.

Know thy market. Beanie Babies are far from a "one-of-a-kind" item, so you should be able to watch several auctions and read through more to get an idea what the going prices and shipping rates are. Look for things important to the particular market. (e.g. for Beanie Babies, collector are interested in the condition of the item, how it was stored/packaged, whether it still has the original Ty tag, and markings for differentiating varieties and "model years") Then you need to figure out things like how you are going to accept payment, how to handle shipping (including out-of-country), and steel yourself for the various problems which will arise (the bad bidders, the bad buyers, shipping problems, etc.)

Yeah, there are various ways to cause even a sophisticated disassembler to go awry. So you have to do a first pass with the disassembler, figure out where code got missed (or data was identified as code) and use that information for a second pass. Naturally, there situations (self modifying or relocating code) where even this may not be 100% effective.

Writing a disassembler is easy. I know, I've written one 'cause I want to learn more about programming the 7800. So the logical way is to have a look at some of the smaller, better, games like Joust and Xevious. The 6502 has only 256 opcodes, a limitted number of addressing modes. Determining whether a byte is code or data is easy too. The disassembler walks the code, starting from the reset, NMI, and IRQ vectors, building a tree from the branches & jumps. (Need to do that anyway to create labels.) Bankswitching could be handled in a similar manner (especially simple hot address bankswitching). But that just gets you a listing. No comments. Only hardware address labels (e.g. WSYNC). Then you have to reverse engineer the game logic. Figure out what each chunk of code or subroutine does. Figure out what each byte of RAM is used for. No way to do that automatically, and you have to have a decent knowledge of the hardware and the typical programming techniques. Heck, I've disassembled Skeleton (as a testbed) and I have problems recognizing what the code does without comments.

Correct, but you would also have to have a CPLD to duplicate the unusual Supercharger bankswitching/write logic.

As MrRetroGamer stated, one of the major reasons to snipe is to try to keep bidding levels down and not be systematically overbid. Another reason, for me, is it limits my exposure and gives me immediate feedback. For example, if there are two similar auctions going on, I snipe the first with my top bid (never, ever, bid more than you are willing to pay), and if I lose that one I can go after the second auction. If I placed my top bid on both auctions, I could end up winning both when I only wanted one. Sniping also forces a kind of cooling off period. I see an auction, I put a watch (instead of a bid) on it. I then can go away and think about it, look for similar auctions to price check, review feedback, etc. Only when the auction is seconds from closing do I need to decide whether I really want to bid. I also watch any page counters to see if there may be other snipers counting down the seconds. If there are, I might raise my top bid slightly or make it an odd amount. A dangerous and dishonest practice. A bid is a legal offer to buy at that level. Rest assured that any sniper who bids more than they are willing to pay will get burned all on their own. One of the truths demonstrated by eBay is there are very few true "one-of-a-kind" items. If you don't win an auction, just wait; another (sometimes even the exact same item) will be offered in the future.

My C$0.03: Although there might be some perceived benefit to having a standalone playback unit for Supercharger games, it still requires the buyer to have either a Supercharger or a Cuttle Cart. (Which is one of the negatives for Supercharger homebrews.) Keeping costs down may also be tricky. I suspect there are microcontrollers with onboard DACs, and maybe even onboard EEPROM which could be used. (Talking dolls are cheap because of economies of scale, allowing for cheap semi-custom VLSI chips.) Creating a "Super Chip" or "RAM +" homebrew cartridge shouldn't be expensive. A 2Kbyte RAM (smallest from Maxim/Dallas Semi) is $5.50. The bankswitching/write logic will determine the complexity & cost of the control logic (e.g. LSI, PLC, FPGA), but any >4K homebrew already has that. Standalone cartrige versions of Supercharger games may even be technically possible, with a custom loader application replacing the SC ROM. (Heck, the Cuttle Cart does this and more.)

Well, the Supercharger is 6K of RAM, although a write requires multiple cycles. The CuttleCart also has a native RAM mode. There were also several flavor's of cartridges which included RAM. See Kevin Horton's Bankswitching FAQ. Whether any of these (or similar methods) could be cheaply used for a homebrew is a different question.

Reminds me of the 8096. It has no GPRs, just zero page RAM.

Nope, BRN does exist (opcode =$21). Check out http://koti.mbnet.fi/~atjs/mc6809/Information/6809.htm. It's simply the logical inverse of BRA. You are probably correct that it was seldom used other than during debugging or patches (or self-modifying code). Of couse, I once heard that the NS32000 had a store immediate, just to be completely orthoganal.

Well, some of the branch opcodes were aliases. BHS (higher or same) == BCS, for example. But the 6809 has a full set of both signed and unsigned branches, and even a BRN (branch never) the logical inverse of BRA (always).

I wouldn't recommend the Apple ][ since it had a non-linear graphics memory map. And instead of an EPROM burner, pick up a Supercharger. It will handle 4K carts (as long as you don't read address $FFF8).

I cut my teeth learning to program assembly for the 6809E on the CoCo. When I then tried to program the 6502 (Apple ][), I couldn't figure out how they could do without 16 bit index registers. Thomas - as usual, I'm going to have to think a bit to understand your optimizations.

Nice when it can be done, but often the carry state is unknown / could be either. Don't you mean EOR #$FF, SEC, ADC #0 ?

CLV/BVC works for me as a BRA substitute. What I would love are ADD & SUB instructions so I don't have to use CLC & SEC every time. Oh, and NEG too.

Read the documentation again and now understand how holey DMA works. Going back to my previous example, let's assume that the sprite is 8 rasters high. Each raster is stored on a separate page. In order to use holey DMA rather than blank rasters, the sprite is stored at $x0yy -> $x7yy (where x > . If x=$F, then: zone header offset = 7, H8=1; sprite header high = $F4 ($FByy -> $F4yy) zone header offset = 7, H8=1; sprite header high = $EC ($F3xx -> $ECxx) Holey DMA H8 means that if A11 is high ($x8yy -> $xFyy) data = 0 (hmm... wonder how that works with Kangaroo mode...), so the sprite is automatically padded. H16 works the same way for 16 raster sprites. The docs also say this only works when A15=1 too, which is why I state x>8 above. Sprites that are not 8 or 16 rasters can still use holey DMA, but must be manually padded to 8 or 16 rasters. Oh, and my example of varying the size of the zones is usefull when you want to vertically scroll a tiled background. And yes, it does appear that a bunch of work in a 7800 game is creating the display lists. I almost wonder if it would be a good idea to double buffer the DLL.

Sorry, I haven't looked at Dan's demo. I missed that it didn't include vertical movement. I haven't done any 7800 programming myself (yet), but I have done through the documentation several times. (I think part of the problem is the wording the documentation uses isn't easy to keep straight.) Okay for vertical movement you have two options. First, if you aren't handling overlapping sprites, you simply change the offset values in the display list list entries (or the zone headers, as I call it). So for one frame you have offset = 7, dl ptr->blank rasters offset = 7, dl ptr->sprite rasters offset = 7, dl ptr->blank rasters and the next frame you move the sprite up offset = 6, dl ptr->blank rasters offset = 7, dl ptr->sprite rasters offset = 8, dl ptr->blank rasters Obviously very few games could use such a scheme. Typically there would be one zone header for the number of rasters in the character sprites (or tiles, as I prefer to think of them). So then it is a matter of changing the high address in the display list entries. zone header offset = 7; sprite header high = $7F ($86xx -> $7Fxx) zone header offset = 7; sprite header high = $77 ($7Exx -> $77xx) and the next frame you move the sprite up zone header offset = 7; sprite header high = $80 ($87xx -> $80xx) zone header offset = 7; sprite header high = $78 ($7Fxx -> $78xx) Obviously, this means that each sprite will need to be bordered by a bunch of blank rasters. The "holey DMA" bits in the zone header are supposed to help with this, but I haven't figured out how to use them yet.

Note: some ROMs (Skeleton, Garfield) explictly allow for people to enjoy them using emulators. But unless it is explictly permitted, chances are you are violating the letter of the law.

My thoughts exactly (hint.. check out the webpage) The multi-cycle write isn't a big deal since all writes are done during the vertical retrace, rather than in the kernel. Oh, using the ball or missle sprites is a major pain, since you have to set or reset a bit flag. It just takes too many cycles to use. In my Lode Runner-esque game, everything except for the player & enemies if done using the playfield. Much quicker & easier.

Dan Boris has done a moving sprite sample: http://atarihq.com/danb/a7800.shtml

Mine is a screen shot from a work in progress. But Zylon has given me some items I will try to incorporate into the actual game. The big problem with attempting to make a Lode Runner clone would be duplicating the game mechanics (e.g. relative movement speeds, enemy movement logic). Some of the levels were very dependent on the player's ability to affect enemy movement. Unfortunately, a simple name change wouldn't hold back the lawyers.

The problem is there's only 76 cycles per line to draw the screen. At a minimum I need: 16 cycles to load the playfield from ROM 20 cycles to update the playfield registers 16 cycles to load/store the two sprites 5 cycles to increment the line counter & loop 20 cycles for top/bottom tests for the sprites Which comes to 77 cycles. Ooops, too many. As I blather on about on the webpage, I will have to create a complex kernel to do what I want. But I do like ZylonBane's idea of making some lines white to highlight the ladders and ropes. And I may have to put in blank lines for sprite repositioning, as he described.

Sorry, didn't mean my statement in that way. And yes, it is very cool. (But so is the CuttleCart. Maybe this one should be the CuttleCart Pro ) This will be interesting to me if they can get the price of the PCB & parts in at a reasonable level. (And it doesn't require soldering micro surface mounts.)