Ah-ha! I've got it!Currently, the code is set up for six sprites - the player and five enemies. Each frame one sprite moves one pixel. So it takes 24 frames for a sprite to move horizontally from one PF block to the next.Now, what if I change this to fractional positioning for the enemies. The player I'll leave be because he can change direction in mid-move. What if I want to still limit myself to one full sprite movement update per frame. Okay, so let's make it take 30 frames for the enem
In Leprechaun my plans are to only go through the full movement routine for one sprite each frame. Although I haven't cycle counted the routine, I have a sneaking suspicion it will take too long to do more than one sprite per frame. (As it is, I think I'll end up having to shove it in before VSYNC so I can leave after VSYNC for setting up the sprite bitmaps.Anyway, I have two alternatives for sprite movement. I can either move only one sprite one pixel per frame (with a hack for making fallin
Ugh. Leprechaun's movement routine chews up 637 bytes; over half the free space (1133 bytes) I have in BANK 3. Sigh, I'm sure I can juggle some stuff around, but fewer free bytes means fewer features.
Made some minor revisions to my tracker code and posted it to [stella]; no feedback yet (whine). One thing I'm not happy with is the byte to note ratio being 2+. This chews up ROM space much faster than I imagined. Certainly with a lot of repeated sequences, the total bytes per song will come down, but even my demo takes 168 bytes. Which kinda puts my idea of dedicating a page of ROM in Leprechaun for music to be woefully inadequate. I could probably come up with a data format which would lo
Ta-da! This is something I've been wanting to do for a long while - a VCS music tracker format. Forgive the tacky Fuji logo, it's the first VCS program I did years ago. I re-used it so I didn't have to spend too much time putting together something which would generate a stable screen.Format details:Two layer list format: top layer is a a song which is a list of 16 bit pointers to seqences (note lists); bottom layer are sequences which are a list of 1-n byte lengths, volume, notes and escape
Following on with my idea to re-use the player movement logic with the enemy "AI", I've been doing some thinking. Basically, the enemies will have two modes: chase & hunt (each enemy working independently). In chase mode the enemies move in the direction of the player, i.e their virtual joystick is pointed towards the player. However, if they get blocked, they flip into hunt mode. In hunt mode their virtual joystick changes direction (clockwise or counter clockwise, randomly, mirror?).
I've been working on & off changing my if logic into 6502 ASM. Most of it is straight-forward CMP / BNE stuff. Not very complex, but a big whack of code. There is some optimization (folding & combining endpoints), but nothing major. I've pushed a couple of things down into the GRID subroutines, but I'm really starting to worry about how much code space this will require. Especially since I haven't even started thinking about the enemy logic.Which got me to thinking. How difficult w
A good example of top down design and bottom up programming. The spreadsheet method made designing the player movement truth table much easier than trying to figure out the if cases from scratch. From that I could then do a pseudo code version of the if statement logic (see 20050823.txt). Since it was in a spreadsheet I could do different sorts to see whether there was any benefit to doing the tests in different orders (e.g. check the button down cases before checking the different grid cases
So, I've reviewed the source code and re-aquainted myself with it. Since the kernel and the sort routines are working, my next focus is on player movement. From a code perspective this will turn into a bunch of IF statements, but first I need to come up with the truth table to ensure no conditions get missed. I'm doing this in a spreadsheet. Each row is one set of conditions. I take a generic condition (e.g. Grid = open) and break it into two conditions (Grid = open & Grid_Down = {Gold,
Features:- 6K SC binary w/ header (8448 bytes total)- performs both bankswitching and SC RAM writes- tested on an actual 2600+SC (back in 2004) (although I now have a 7800+CC2 as well)- functional kernel w/ sprite repositioning- semi-intelligent flicker / partial sort routineLEPRCHN.ASM : wrapper- includes, equates, ZP variables, SC headerLEPBANK1.ASM : level data- background playfield bitmaps- SC RAM space for forground player/leprechaun sprite bitmaps- SC RAM space for player color / XPOS arra
I think I've found the most recent source code. I need to do some re-assemblies and diffs to make sure I know which is what. Then comes the big challenge, making head & tails out of the code.
A recent ArsTechnica entry about Zeta brought back memories of BeOS, and my mostly failed attempts to get it running on the hardware I had access to. Hey! I've got a "new" PC, might it be compatible? Most assuraddly so. Cool. Of course, it's the one hooked up to my Tempest cabinet, so the monitor is rotated, which makes it a little difficult to use. But it's BeOS!
I'm getting ever closer to completion of my Tempest cabinet. The rear door has been completed (although I might sand down the length, it's a might bit tight). I've been working on getting Atomic FE set up. I think the next step is getting the software on the PC and the game-specific configs done. I've soldered some speaker wire to the on/off button, now I need to find a SPMT switch to put at the other end. I also need to hack up my extension cord and connect the main on/off switch and the d
Yeah! Finally found a cam lock for the coin door at a local hardware store. So now my cabinet has a door (no mechs though). I also bought a sheet of MDF and had it cut (thanks Home Depot) for the back door. So, current to-dos:Woodworking: Cut the MDF to length (easy work with a circular saw), add the notch & cover for the monitor, add top & bottom "latches", paint.Software: Play around some more with AtomicFE, try out the patched version, create a layout / background I'm happy with,
A month or so ago I bought KotOR (on sale for C$10). I'd borrowed and finished it over a year ago, but I figured enough time had passed that I would enjoy it again. This time I also decided to try it as a (mostly) solo DS character (female level 5 soldier level 10+ guardian w/ high wisdom). Unfortunately, I'm now at Manaan (having completed Tatooine and Kashyyyk) and my alignment is swinging dangerously back to neutral. I just can't make the choices (particularly party conversations) require
My arm is still tingling. I was connecting up the receiver/amplifier in my Tempest cabinet when my hand brushed the dangling monitor on/off switch. Silly me I had left the monitor plugged in. Well, it turns out that switch is line AC, not a sense DC. Now "120" AC isn't as bad as the 240 they use elsewhere (which can kill), but it'll still make you yell and jump.Current beauty shot of my Tempest MAME cabinet. Just added the speaker marquee this weekend.Still to do:1 - coin door: need a lock,
It will be interesting to see how Video Google plays out. Already it looks like a decent way for video artist and budding filmmakers to distribute demo reals. (Assuming you can load the keywords so someone can find it.) But, already I see some problems:1. What's the point of capturing TV feeds if they aren't available for viewing? Heck, all they are really doing is capturing & indexing the closed captions. (Which is probably in violation of some copyrights.) Plus, they are making it da
Although I keep trying to limit the number of projects I'm working on at one time, I keep adding new ones.My latest is TiVo. I realized that my wife has several shows that she enjoys watching which often get taped & watched later due to RL scheduling conflicts. Hmm... we keep using the same tape over & over for time-shifting. Sounds like TiVo would be a good fit and an excellent birthday present. (October)Except for one snag. TiVo doesn't offer listings outside of the US & UK.
I discovered a while back the Expensive Planetarium starfield required too much ROM space for its own good. After some debate, I decided to recode it as 236x80 tiles (versus 216x90), which will nicely map from $9000-DFFF, leaving $8xxx and $Exxx for sprites (w/ 4K:16 line holey DMA) and $Fxxx for the actual code. This does mean the aspect ratio is wrong, but I'm willing to live with that. (Well, it was only "correct" at 0 degrees declination.)Anyway, Saturday I went back to the source file I
First, a version of the paddle proof of concept which uses a DLI instead of a pseudo kernal. This increases the amount of CPU time available to the rest of the program at the cost of the number of paddle positions (0-31 for NTSC).Second, a trackball proof of concept. I don't have one myself so I can't test it out. Again, a DLI is used to sample the trackball multiple times per screen.
I'm nearly done a DLI version of my paddle proof of concept & trackball proof of concept. (Just need to fix an error in my ROM to RAM copy routine, I used the wrong label.) I'll put them up tonight. Hmm... just to complete the set I should do one for the driving controller too.In non-7800 geek news I made a bezel for my Tempest cab and put the glass back in. It looks really, really nice. Unfortunately, the next to-do is a biggie - getting the software set up on the PC so it's functional
Figured out what the problems were. The main one was my ROM->RAM copy routine needed to be reworked since it had to copy more than 128 bytes.Attached is a simple test program which displays all 6 graphics modes onscreen. Press player 1 button to enable kangaroo mode, press player 2 button for colorkill (may be combined). (CC2 7800_8K 78QUICK, should work on both NTSC and PAL)Okay, what are you looking at, eh? The screen is divided into 9 areas (3x3 grid):320A (pallete 0-3) 320C (palette 0
SpaceWar! 7800I was looking at my Expensive Planetarium code and realized I had made it 216 tiles per line rather than 256; which means I don't need to have any fancy wrap around code because the last 40 tiles are duplicates of the first 40. Ah, well.I'm also thinking that instead of creating a separate EP.bin and then trying to integrate the code into SW78, I'll try to add it to SW78 in the first place. Harder to start, but easier in the long run.I'm also trying to think if there's anything e
I've worked out the rest of the X positioning code, but I'll post and comment on it later.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 mean
Greetings to the 20 readers who visited yesterday.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).On the 7800 tiles are drawn using 5 byte DL entries. Each
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord