Home
SpaceWar! 7800
 
 [Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Eric Ball's LiveJournal:

    [ << Previous 20 ]
    Friday, May 13th, 2005
    2:13 pm
    too many bits
    Well, started the task of adding Expensive Planetarium into SpaceWar! 7800 (4K version). The first step was to simply put the tile map and the tile sprites in and rejigger the DL building code to include them. Maybe start to look at splitting out the spaceship code into 16 lines. But I've run into a slight problem, it doesn't want to fit into 32K. This is what I had when I just dropped the EP data in:

    $8000 - EP tile map: 90 rows of 256 bytes (22.5K!)
    $DA00 - EP sprites: 2 * 8 rows of 256 bytes
    $EA00 - SpaceWar sprites: 8 rows of 256 bytes (want to make 16 rows)
    $F200 - SpaceWar code (which previously was at $F800-$FFFF)

    So although it fits in 32K, it's not sitting on the 2K/4K boundaries required for HoleyDMA. So either $8000,$9000... for 2K or $8000,$A000... for 4K. Hmm... I guess I could move the EP sprites to $8000, then I'd have:

    $8000 - EP sprites (have to pick either odd or even, since I'd have to use 2K DMA)
    $8800 - EP tiles
    $E200 - 3584 bytes of unused space
    $F000 - SpaceWar sprites
    $F800 - SpaceWar code

    Okay, what about the 4K holey DMA idea? Re-jigger again...

    $8000 - SpaceWar sprites (16 line ships, 8 line other stuff)
    $9000 - EP tiles
    $EA00 - space
    $F000 - EP sprites - won't work 4K odd...

    Okay, so #2 is the way to go. Horizontal scrolling won't be as smooth since I don't have the odd/even tiles. Hmmm... Maybe redo the EP tiles to 88 rows (or just drop the top & bottom rows). Then we have:

    $8000 - EP even sprites
    $8800 - EP tiles
    $E000 - EP odd sprites
    $E800 - free space
    $F000 - SpaceWar sprites
    $F800 - SpaceWar code

    I like it!
    Thursday, April 21st, 2005
    1:13 pm
    Expensive Planetarium
    It's been over a year since I did any serious work on SpaceWar! 7800. Discovering the 7800 NTSC BIOS digital signature code fails using a 2600 style 4K cartridge really depressed me. I also got distracted by numerous other projects, so it's taken me a long while to get back the desire & drive to pick up the code again. (I should also note that there are several 7800 homebrews being actively developed on www.atariage.com, including clones of Burger Time & Q*bert and a Pipe Dream variation on Tetris.)

    Now that I'm no longer constrained to a 4K ROM I need to go back and almost start from scratch. My first task is to recreate the Expensive Planetarium from the original PDP SpaceWar!, which was an accurate starfield background.

    Last year I translated the Yale star information into quincunx sampled tile lists. (So I might need to revisit it just to make sure it doesn't come out upside down.) The Expensive Planetarium drawn using 256 8x8 pixel tile sprites, with each sprite having 8 "stars" in a quincunx pattern either on or off. (Actually, there are two sets of tile sprites, odd & even, to make up for the 160 positioning in 320 mode.) The actual star map is 90 rows of 256 tiles (each tile is 1 byte). This makes the starmap effectively 2048x720 pixels (360x180 degrees).

    (I should note that EP will force me to continue to use 8 line DLLs and 320A mode.)

    I've worked out the code to translate the X position into three 5 byte DL entries. (Necessary to handle wrap around.) Y position is a little trickier. First, there are two partial zones at the top and the bottom of the screen. Second, the partial zones will affect the effective Y position of the other sprites.

    Last night I rediscovered how to do vertical motion on the 7800 again (0,0 is the top left corner) and realized I had to add any Y adjustments to the sprite in order to make the DL index calculation work. This means the Y adjustment is the height of the last zone and an increasing Y adjustment appear to move towards the bottom of the background. (So, again 0,0 is the top left corner of the background.)

    I have a nasty feeling that the partial zones are going to make wrap around mucho difficult, but that's a task for another day.
    Thursday, December 9th, 2004
    9:00 pm
    Well, I finally took the time to do a little testing with my CC2. 7800_4K+78BIOS worked, 4K+78BIOS failed, but 4K+78QUICK worked. Hmm... maybe the BIOS is doing a test which is kicking it into 2600 mode. A scan of the Keith Henrickson/Daniel Boris disassembly confirmed it - starting at $F8E7 the BIOS runs a full RAM test which fails because the 2600 cart is shadowed at $1800-$1F00.

    Oh well. I guess this means I don't have any reason to limit myself to 4K. Hmm, what will I do with all of that address space? Gotta work on that Expensive Planetarium and maybe convert my graphics to 320B...
    Friday, April 2nd, 2004
    8:48 am
    I went to www.TheVideoGameShow.com this past weekend (a video game swap-meet out in Mississauga) and bought a 7800. I have also ordered one of Chad Shell's CuttleCart2s. This will allow me to develop and test on an actual 7800 instead of only using a emulator. So I'm going to put further development on hold until I get my new toy.

    On a down note, I asked PackRat Video Games to make me an actual cart, and it failed their tests. We're not sure if it's a problem with their 7800, some kind of software bug, or the whole "7800 game using a 2600 cartridge" idea is bogus. Sigh!
    Thursday, March 18th, 2004
    4:38 pm
    respawn - binary updated
    I've added in respawn (cost 54 bytes). 54 bytes left, though I haven't moved the startup code, so there may be another 90+ bytes there.

    I'd like to see if I can squeeze in my debris idea but I'm not sure I'll have the code space. It will also chew up a bunch of RAM, which means fewer shots. Hmm, need to look at the impact of moving display list index out of ZP.

    I think I am going to leave out player-player collision detection. I just can't see the value. It also might cause big issues with the respawn routine (which doesn't check for a player collision).

    I guess the next thing is to work on adding different options & option combinations. Suggestions welcome!
    Tuesday, March 16th, 2004
    9:53 pm
    I've done some code tweaks - figuring out more efficient ways of doing things and now have 108 bytes free. There's 128 bytes unused in the 2K graphics, unfortunately it's sixteen separate 8 byte blocks. Hmmm, I wonder if some/all of the init code can be shoved in there. That way the penalty for jumping from block to block won't be an issue.

    I re-verified the gravity index calculations, since I did those so long ago. I'm also staring at the display list builder and wondering if it can be folded in some way.

    I am disappointed that I am not getting any feedback or suggestions.
    Monday, March 15th, 2004
    8:15 am
    Well, saved 50 bytes by rewritting the DLL creation routine to use the DLL LUTs, thereby reducing the size of the ROM DLL table.

    Other places I'm looking at saving space:
    1. Figure out something constructive to do with the sixteen 8 byte gaps in the sprites.
    2. Work out a way to chop out some of the zeros in the gravity MSB LUTs.
    3. Review the code to see if there are ways to recode routines for reuse or to reduce the number of bytes required.
    Saturday, March 13th, 2004
    2:59 pm
    Download updated
    Rather than delay the relase to add features, I've just fixed the velocity limiter and increased the number of shots. My next task will be to start finding places and ways to save bytes. (Only 35 bytes left!)

    The big thing I really need to add is player respawning. I also haven't added player-player collision detection. Then I want to try to add some difficulty options. (Like different levels of gravity, thrust, and maybe limitted shots and thrust.)

    I am interested in what people think of the game. Alot of things can be tweaked very easily, including: shot speed, shot life, gravity, thrust, and speed of rotation.
    Friday, March 12th, 2004
    9:29 pm
    4K or not 4K, that is the question
    After much deliberation, I have come to the decision to limit SpaceWar! 7800 to 4K.

    It really comes down to drive. I am certain that I can "finish" a 4K SpaceWar! 7800 (cramming in as many features as the space allows). But I suspect that a 32K version might never get completed.

    32K would give me the space to put in a huge number of features. But each of those features takes time to develop, code & debug. And this project has taken 6 months already. Plus those features deserve all of the passion and enthusiasm which can be put into them.

    Meanwhile, there are other projects I have on the backburner, and some ideas for even more projects. Maybe I will come back and make a 32K SpaceWar! 7800 someday, but not today.
    9:19 pm
    Found it! I realized that the thrust problem wasn't with the velocity limitting since I had seen it when that code wasn't being executed, and when it was executed the speed stuttered. So I turned off the velocity limitter and just experimented, trying to figure out what combination of factors caused the problem to occur.

    Hmm, seems to happen when I press the key for thrust. Hmm, the ship seems to rocket off in the reverse direction than it was pointing. Could the problem be with the thrust LUT? No, I can be thrusting in that direction okay, then zing.

    But, the problem was almost certainly with the thrust code. It only happened when I was thrusting. (Which was good, 'cause I thought it might have been an errant pointer; which would have been a b*tch to track down.) So print out the thrust routine and take it line by line.

    Nope, not a parameter or register mismatch. The logic looks right, but what about this BCC at the end of one if/then/else branch. Will the Carry flag always be 0? Yes, because... oh ... ahh ... bingo!

    Okay, now that I've figured that out, what else needs to get done before I update the ZIP? Hmmm...
    Monday, March 8th, 2004
    7:08 am
    Found another bug (more of a logic error really). Thinking that the thrust problem might be caused by jumping over the velocity limitting code (which is in the gravity routine, which is off for ease of debugging), I enabled that. I'm glad I did, 'cause it currently only changes the integer portion of the velocity. But since the fractional portion rolls over, this means the ship's speed stutters badly when it hits that peak velocity. Some additional code to fix the fractional portions too should do the trick.

    I realized one problem with a 8K bankswitched cart would be no current emulator supports such a scheme. Although it might be possible to fake it, there would be some additional work.

    I'm leaning towards staying with the 4K cart size, as much to test the market as anything else.

    Gotta fix the bugs in this version first though!
    Saturday, March 6th, 2004
    10:15 pm
    I think I managed to fix all of the bugs in the collision detection routine. I had to take a break for a couple of days so I could look at it with fresh eyes and force myself to work out what the code was doing, and not just what I thought it should be doing.

    Of course now I've seen the effect a bug in my thrust routine. The ships sometimes rocket off for no good reason. Sigh

    I should also come up with some kind of restart for after a player is destroyed before I update the current version files.

    I am also pondering whether I should take this game beyond the 4K limit I imposed on myself. I have a few options:
    1. Stick with 4K, but that will probably mean I will not be able to add any significant enhancements.
    2. Go to 8K, but use a standard Atari 2600 VCS F8 bankswitching, so only 4K is accessible at a time. This will mean that I won't have 8K of usable space because sprite data and some other things will need to be in both banks. It will probably be effectively 6K or less.
    3. Go with a flat 8K ROM. This would require a 7800 specific PCB at the minimum. There may also be value in going back and changing the sprites to 16 high versus the current two stacked 8 high sprites.

    I dunno, there's still something appealing about sticking with 4K, but there's stuff I'd love to add in if I had the code space.

    7800 SpaceWar+!
    Thursday, March 4th, 2004
    7:18 am
    The collision detection routine has been integrated with 50 bytes to spare! Of course the game locks when there is a collision, but that will be fixed.

    Wheee! Of course 50 bytes ain't much for further improvements. And right now when a player gets hit, they disappear forever. Ahh, well, worry about what to add in later.

    And, who knows, there may be some water left in that stone I can squeeze out.
    Wednesday, March 3rd, 2004
    5:29 pm
    Redid the shot creation routine. I guess I need to integrate the collision detection routine. 330 bytes left
    12:44 pm
    More tweaks to the current code, checking the player destroyed flag. Modified the fire button code not require doing an AND and saved a couple of bytes. Reordered the fire to be after shot movement. Still need to make the shot appear outside of the player.

    409 bytes left
    7:11 am
    Reviewing both the new collision detection code and the rest of the source. Looking for tweaks but also trying to anticipate problems. Like not letting the player rotate after they have been destroyed since I use the rotation also as the dead flag.

    I also need to rewrite the shot creation routine since the "laser bolt" starts in the middle of the firing player. That wouldn't work - automatic collision.

    I think I'm also dreading what the byte count is going to be...
    Monday, March 1st, 2004
    3:20 pm
    Thinking about 9 bit logic got me to wondering whether there were any other places in the code which could also benefit. I was hoping that I could use it in the gravity routine, but it doesn't apply. However, I did find a tweak which saved a couple of bytes.

    The collision detection code is coming along; I'm almost done typing in the different pieces. The only thing left is the Y delta routines. Then dump it into the code and fix up the out of range branches.
    Sunday, February 29th, 2004
    9:21 pm
    Working on the collision detection code doing my typical top-down into bottom-up development. I start by doing a quick top-down breakdown to isolate the innermost routine, then build from the inside out.

    The inside of the collision detection routine is the bitwise AND of the player and shot (and debris if I have the code space) sprites. The rest of the collision detection routine works out from there.

    But before we get to the bitwise comparision the sprite positions are compared to ensure the sprites overlap. The difference in the positions also feeds the sprite line pointers and the shift logic vector.

    The problem is this bounding box logic was complex because it has to handle wrap around. So almost triple the code was required to handle the variations. Then I had a revelation.

    The issue is both the X and Y positions are 8 bit unsigned values, so subtracting one from the other requires 9 bits for the result. The additional code worked around only having an 8 bit result. But then I realized the carry bit is the 9th bit I need to determine whether the 8 bit result was positive (carry set) or negative (carry clear).

    It's looking to be a fairly large routine too and handling the outer loops will be unfun.
    9:13 pm
    Migrated to LiveJournal
    I've just finished cut & pasting my Videobrewery development diary into LJ; saved from oblivion by Google's cache. (Videobrewery was hacked and it's database destroyed; no backups existed.) The latest entry I had to redo from memory. I was debating whether I wanted to continue my diary, but as I got back to working on my code, I wanted to continue to share what I was working on. (And keep track of that important byte count!)

    I realize that this kind of diary is probably a little outside of the LJ norm, and I hope that TPTB won't mind too much.
    Friday, February 20th, 2004
    12:00 am
    Found the bug. I had a TYA where I wanted a TAY in the joystick handling routine. One of those bugs which are obvious but you can't find them 'cause you know what it should say.

    Adding to the difficulty is that none of the emulators have any debugging options. I ended up writing to the CTRL register which V7800 logs. It looks like MESS has a debugger, but no info on using it. Maybe I can persuade the new 7800 to add an option which would log the register contents when a NOP is executed.

    Anyway, I've now modified the kernel with the improvements from my ball demo. The ZP end of list index was easy but inverting the Y axis was trickier - lots of changes.

    Now to work on collision detection. 415 bytes left.
[ << Previous 20 ]
Current source and binary   About LiveJournal.com