jrok

No! I mean, it depends on what you put in there, how you structure your code, etc. But I've never had trouble with it, including in games that have multiple screens/segments or whatever you want to call them. For instance, I used it to crunch almost 1000 machine cycles in Circus Galacticus, and that had several screens with unique functions (including making use of RevEng's brilliant title screen kernel). I guess everyone codes differently, but I try to use it exclusively for longer math, bounding box detection and multiple-case trees (such as AI decision trees), and keep those operations separate from the "daily grind" of animation routines, sprite positioning, sound effects, etc. In other words, I shove the boring stuff in there that is helpful during the program's highest activity (the main game loop, usually) but that doesn't *directly* affect screen updates. Sure, you could spend RAM on avoiding certain routines within the statement, but if the stuff going on in there isn't A/V related, then who cares if it's running in the background of a "Character Selection" screen or something?

Wasn't talking about the fast-fetch stuff during the kernel. The ARM code that makes that work runs fast enough that the 6507 isn't aware of anything. In DPCplus_kernel.asm you'll see: ; do a callfunction here lda #255 sta CALLFUNCTION <after CF> <--- NOTE this is not really in the file ; copy modified data back (just need first 6 bytes, which is sprite sort data) ldx #256-19 copyfromfetcherloop the sta CALLFUNCTION triggers custom ARM code. The ARM remembers where it left off (the <after CF>) and then puts a NOP on the data bus. The 6507 sees the NOP and does nothing until the custom ARM code is finished running, at which point the ARM code puts a JMP <after CF> onto the bus (this is because the 6507 thought it was running real code, and thus was advancing where in the ROM it thought it was). The number of NOPs the Atari processes depends on how long the custom ARM code takes to run. What the 6507 on a real Atari sees is this: lda #255 sta CALLFUNCTION NOP NOP ... NOP JMP <after CF> ldx #256-19 Stella doesn't emulate the run-time for the ARM code, so what the 6507 in Stella sees is this: lda #255 sta CALLFUNCTION ldx #256-19 As an example, when the speech subroutines in Frantic need to refill the audio buffer, the real 6507 will see 200+ NOPs (about 6 scan lines) while the ARM is filling the buffer. The emulated 6507 sees 0 NOPs. Thanks, Spiceware. I think I understand. So, how can I count how many NOPs the 6507 sees at runtime in my program?

Thanks, Spiceware. Do the cycles the ARM code uses correspond solely to changes in sprite registers? Does anyone know if fast-fetch mode possible in the bB DPC kernel? Thanks, Scumsoft. Yeah, it's possible. I was updating all the virtual p1 x positions during Vblank, so I tried moving that into the main loop. Not sure if it fixed anything, but it's the only thing I could think to do. ChargeDPC_080111.bin

Well, I doubt we could have 50 sprites flying around, but hundreds of dots should be possible. You would just have to make some creative use of the sprites and flicker. For instance, in the following binary the first example shows a grid of 384 dots (using both P0 and P1), and the second example shows a 9x6 dot grid, using only a single player sprite. Press and release the fire button to toggle between examples. Dots.bas.bin It looks okay in Stella with Phospor turned on. I just mocked these up real quick, but ultimately for a "dot-eater maze game", I think the idea would be to make use of the multiplexed P1 in the DPC+ kernel. In that case, you could potentially have 9 independent sprite rows on one frame, resizing them to %00000011 to get 27 dots. Then you could do the same on the next frame, but reposition their x to create a 30hz grid of 54. By tracking the position of the "eater" versus the grid, you could resize each sprite accordingly, making the dots vanish as you "eat" them. 54 isn't a heck of a lot of dots, but it's probably doable in pure bB (DPC+).

I confess that I'm stumped. I'm definitely running a steady 262 scanlines in Stella now, and I think I've kept an accurate count of my cycles. Maybe I can try posting a version for you that omits a certain large element, like the enemy knight, and see if that alters your output?

Why don't you make one with dots worth 10 points each? Or is RT supposed to write "your" game? I need to learn before I write code. I don't know how. If you mean that you don't have any programming experience at all, then perhaps you should start simple. I'd think that asking someone to write your game for you defeats the purpose of the hobby. RT is referring to the setup of the bB 1.0 standard kernel, which draws the entire screen at once, including the five objects he mentioned and the playfield pixels. Atari's Pac-Man "dots" were done with done with playfield pixels (which is why they look more like "dashes"), and the three ghosts were created by flickering player0 and player1 on alternating frames. I'd recommend you also go with playfield pixels for your dots. I'm just asking for a snippet of code. What about the Pac-Man clones with dots, not "Video Wafers?" I would need extra big sprites for the characters to to make dots, because the "lanes" would have to be 3 playfield pixels wide. Oh, well that's simple then. Just write a custom kernel that allows you to display both missiles and the ball on every line. Then, perhaps with 30hz flicker, you could get up to 8 square "dots" on each scanline. It's an easy fix... just a "code snippet" really. RT could you jump on that ASAP, so that Junior Pac can complete his masterpiece?

Its normal to learn while you write code. If you can't handle RT's example you really should be experimenting with other peoples code or start with far simpler things before you try and write a full game. I don't know what you mean. I can handle RT's code. I think he means that you've just been handed a boat, a paddle, a net, a brand new fishing pole and a bucket of bait, but now you are asking someone to catch the fish and cook them for you. Before you go any further, you might want to spend a few days modifying and experimenting with RT's code here. All of us were beginner programmers at one time, and I guarantee that's how most of us began to understand code and start writing our own.

Why don't you make one with dots worth 10 points each? Or is RT supposed to write "your" game? I need to learn before I write code. I don't know how. If you mean that you don't have any programming experience at all, then perhaps you should start simple. I'd think that asking someone to write your game for you defeats the purpose of the hobby. RT is referring to the setup of the bB 1.0 standard kernel, which draws the entire screen at once, including the five objects he mentioned and the playfield pixels. Atari's Pac-Man "dots" were done with done with playfield pixels (which is why they look more like "dashes"), and the three ghosts were created by flickering player0 and player1 on alternating frames. I'd recommend you also go with playfield pixels for your dots.

Why don't you make one with dots worth 10 points each? Or is RT supposed to write "your" game?

Thanks, slim! Let me know how far you can get, high score, etc.

Hey RT, I haven't taken a look at your code yet, but I know I did a 32x24 pf-avoidance routine for Circus Galacticus. If I recall correctly, I wound up doing most of the sprite coord-to-pf coord and case conditions during vblank to get the timing right. You might want to try stuffing some of the math into a vblank routine to cut down on cycle use.

New Build: I think I've resolved all of the program's timing issues, so this should work harmoniously with Harmony Carts now. I changed the bonus structure a bit. Now, players earn an extra life at the 500 point mark, and Castles always repair a max of 5 hit points at the beginning of a wave (this may change again at some point, along with scoring in general). I think the difficulty curve is a bit smoother now, and it should be easier for players to at least reach wave ten and duel the wizard. New ROM attached here and in first post. ChargeDPC_073111.bin

Thanks RevEng. I think I might try that in a future build, since I'm wasting some cycles testing the bounding boxes of various enemies (although, I guess I might have to keep doing this if batari's pixel collisions don't work for resized p1's)

Why not jump to code in another bank at the start of vblank, and return when the code is done? Do you mean something like: vblank goto VertBlankStuff bank2 bank 2 VertBlankStuff (code to run during vblank) return otherbank Would the only additional cycles used be for the bankswitch, in that case? [EDIT] Actually, taking a second look at the above code, I guess that wouldn't work. Could you give me example of what you're thinking?

I'm getting an even 262 scanlines on my binary. Could it be related to your PAL setup? Can Harmony be manually set to run NTSC programs? In fact Harmony has 3 different firmwares (NTSC, PAL50, PAL60), I use PAL60, but actually I don't know what are the differences between those firmwares. Perhaps Fred could explain. My NTSC roms run fine with PAL60 firmware. I think it's a good idea if someone with NTSC firmware tests your latest binary. Hmm, on second thought, I think the problem is on my end. For some reason, my autoexec file for testing scan wasn't working on my x64 computer, where I did most of my testing. The autoexec would load into Stella, but it wouldn't break the program while running. This might be my fault too, so I'll have another look at it over there before I would call it a Stella bug. It seems like most of the extra cycles are being executed when the Enemy Knight is on the screen. Is it your experience that this is when the screen bounce usually takes place? Or is it whenever the horse is moving, no matter what is on screen? Thanks. It also seems like the cycles are fine throughout the first level, then they begin to jump starting with level 2. Is that also what you are seeing? [EDIT] Okay, I just ran the program again in Stella 3.4.1, and this time made it to Level 3 with an even 262 scanlines (I might have gone even father, but accidentally hit "Escape"). I'm really clueless about what's going on, except maybe that some set of conditions is getting tripped at a certain point during play that screws up the timing from that point on.

I'm getting an even 262 scanlines on my binary. Could it be related to your PAL setup? Can Harmony be manually set to run NTSC programs? In fact Harmony has 3 different firmwares (NTSC, PAL50, PAL60), I use PAL60, but actually I don't know what are the differences between those firmwares. Perhaps Fred could explain. My NTSC roms run fine with PAL60 firmware. I think it's a good idea if someone with NTSC firmware tests your latest binary. Hmm, on second thought, I think the problem is on my end. For some reason, my autoexec file for testing scan wasn't working on my x64 computer, where I did most of my testing. The autoexec would load into Stella, but it wouldn't break the program while running. This might be my fault too, so I'll have another look at it over there before I would call it a Stella bug. It seems like most of the extra cycles are being executed when the Enemy Knight is on the screen. Is it your experience that this is when the screen bounce usually takes place? Or is it whenever the horse is moving, no matter what is on screen? Thanks.

I'm getting an even 262 scanlines on my binary. Could it be related to your PAL setup? Can Harmony be manually set to run NTSC programs?

Hey Philsan, your program needs to make the bank jump to a label in bank 2. Something like: goto StartSetup bank2 rem ***************************************************** rem * BANK 2 rem ***************************************************** bank 2 rem fix for issues running on harmony cart, place right after bank declaration temp1 = temp1 StartSetup rem REQUIRED DPC+ POINTER SETUP rem DF0-3 control PF rem DF4 controls PF colors rem DF6 controls BK colors rem these are all in fractinal increments, DF4 and DF6 should be double the value of DF0-3 rem Currently set to a playfield height of 23 lines tall for ScoreRegion fix DF0FRACINC = 32 DF1FRACINC = 32 DF2FRACINC = 32 DF3FRACINC = 32 DF4FRACINC = 64 DF6FRACINC = 64 ... Otherwise, the kernel is just running and doing nothing.

New version of Charge! is up. I've tried to do more extensive documentation for this build, all of which I've added to the first post, along with a copy of the new binary. The main change is that I've added scoring and an HUD to track remaining lives and health. This involved eliminating a running tally of remaining dragons to be slain, but I don't think that's such a big sacrifice. There have also been some graphical and gameplay changes, including: Revised horse handling. Acceleration/deceleration is much faster and more responsive. Revised Dragon sprites, including a "divebomb" sprite state. I actually what I thought was a pretty cool animated version of this, but I think it's too costly in terms of memory and cycles. Revised Dragon/Wizard movement and AI. [* Revised repair phases, including bonus lives, health regeneration and Castle Rebuild boosts. Twenty levels included (after wave 10, waves will loop to Wave One, but the numbers for waves 11-20 will include an underline beneath them) Underpowered the Foot Soldiers slightly, making it more difficult for them to destroy your Castles. Revised jousting somewhat to make it a little more forgiving. If a Knight catches you in a sweet spot, however, prepare to be bounced around and torn up by his sword. Overall, I think I'm happy with the game's progress. I don't think I'll be able to develop it with Batari's new 1.1d build, unfortunately, sicne the program makes extensive use of my VBLANK routine, and it doesn't seem that there's much room left for that with the new kernel, but that's okay. I think I've robbed the cupboard bare of RAM (without going to the stack, which probably wouldn't be useful for my game). I've used all 26 bytes of RIOT RAM available, as well as the x coordinates and NUSIZ registers of unused virtual players. I have a few bits left over that I can put to use in the main loop, but other than that I think I'm maxed out. One thing I am curious about is whether I can modify the core files to zero out the y coordinates and heights of my unused multiplexed sprites, and recover those bytes for other uses. If so, I think I can squeeze in my "Rescue the Captured Damsel" gameplay, as well as a few other surprises. In any case, I think this is mostly shaping up the way I imagined it. Thanks to everyone in the community for your help and ideas so far. Cheers, J ChargeDPC_072811.bin

Random Terrain tells you what's wrong in the post above.

I'm not sure what the issue is either, but yes I've experienced it and it seems to be related to whitespace. I've had to CTRL-Z through dozen changes and generally walk on eggshells, adding hard returns where none seem needed, yet seem to satisfy the compiler.

You need to indent this stuff: COLUBK=$00 COLUPF=$58 player0x=50:player0y=50 player1x=20:player1y=20

Gah! I've been testing this thing so much lately, I'm getting careless about removing little diagnostic snippets. In version 4, I accidentally left the Dragon's breath stuck on it's fastest speed... probably making the game pretty tough to advance in. The speed of the fire columns is supposed to start slow and get faster when certain waves are passed. This version fixes that. Also, in the interest of making testing easier, players start each game with 9 lives (each new knight beginning with 9 Armor) and each surviving castle heals 10 points instead of five between waves. That should make progress a bit easier, so hopefully someone will be able to reach the Wizard boss level. Cheers, J ChargeDPC_5.bin

Oh yeah, thanks for setting me straight. I was up all night working and my little grey cells seem to have misfired. The new version is looking good! Thanks, man! Let me know how far you get.