Revontuli

I got relatively far with the documentation and looking at the demo music files (I got the Popeye arcade theme handily playing along for a while ) - I was coming into the system thinking like a TIA coder, so I wanted to try things like echo and decay (which has been the only way I've been able to make the TIA sound halfway decent). I also found your note table which has been a huge help. A lot of my trouble has risen out of transitioning from a simple system I had near-complete control over (TIA/7800Basic) to a more sophisticated one that has a nice interface but hides/takes care of a lot of stuff for me (POKEY/Music Engine). I thnk some "features" I want to play with require a lot of micromanaging the engine (reasonably) takes care of for me, and I also will allow that there's probably an easier method to get the sound I want without ripping apart various ASM routines. It's always a trade-off, and I'm learning quite a bit about music theory and audio engineering despite myself! I've a few others things I'm still figuring out, like how CHANNMDETABL works, and generally how all the parameters work together, but- TL;DR I appreciate the work and contributions you've done already, and a tutorial would be most welcome!

Al posted in the programming forum, but in the interest of coverage and, um, interest I'll crosspost here: Dragon's Havoc will be available for sale starting at the Portland Retro Game Expo next weekend! The game should be available to order online in November - thanks for everyone's help and input!

I'll see about posting a ROM (or at least have a semi-open beta testing phase) after the Portland Expo next weekend, where it's making it's public debut. There will undoubtedly be some things I want to fix after PRGE, and the game is complicated enough I want to make sure a lot of the big things (like password system and saving) are solid. I'm trying to be a little more mindful of what builds are actually downloadable. If one is not careful, you'll find that that streamers invariably pick the *one* version where the game has an embarassing bug, and that build is in the wild and immortalized on youtube now! 😝 The first build I've upload of a game is usually the one that's downloaded the most (or very high in the running) so I want to make it as polished as I can, with the knowledge and expectation that folks will find bugs and glitches. Hopefully enough of them that I can fix before making a physical cartridge!

I've also been experimenting/learning POKEY audio within 7800Basic. I did a quick little conversion of my arrangement of Tamlin for the TIA into a straight square-wave rendition in POKEY: Tamlin with the TIA: TamlinTIA.mp3 Tamlin with the POKEY: TamlinPokeyEcho.mp3 I'll assert the TIA rendition still has a bit more character, but that's till not totally fair to the Pokey chip - I'm still messing with the timing and not really using new any frills or features beyond increased resolution/better tuning. I'm treating channels more as spaces where I'd stick any treble notes that I can, instead of as "tracks" per se, similar to how the 7800Basic TIA Tracker works. That approach made the TIA music somewhat tolerable to listen to, as while I usually had one channel for sfx and another for music, the priority system effectively gave me an extra channel. The music is almost always playing, while sfx only happen in individual events, and can "drown out" or cut off a wayward note without too much issue. I will admit I might need help - I'm about as good a musician as the TIA is an audio chip I'm having fun seeing how far I can get arranging various works of music for the POKEY, but I also know there are folks here who are far, far better acquainted with the chip. The samples above I made using the built in psound function and my own cobbled together system - I used an echo (or "shower quality") type effect when making notes with the TIA, and wanted to see how it carried over to the POKEY. For the record, though, I also got the 7800 POKEY engine properly intergrated into my 7800Basic build of Harpy's Curse, which would probably be the route to go if I get a composer to help: I also have an entire 16K of RAM (and 16K bank of ROM) that I've kept ununsed with the anticipation of storing/managing music, so we'll see how this develops. Any advice would be welcome for a poor scrub like me who's still pretty new at chiptunes

I'm messing around with a script that outputs all of Harpy's Curse levels as one big image file: I still need to get the colors and section tile sets in place, but the basics are in - it's actually good to see how it all fits together like this. Once I get proper colors and enemies in, it'll help me visualize things more concretely than my pixel->tile system. Access to a full map would totally spoil the game, of course - although it might be interesting to include one as a physical "feely" for those who buy the cartridge. I'd have to talk to Al about it, but I imagine it would be along the same lines as a game coming with a poster.

I'll see about posting ROM stuff after PRGE - there's still a lot of elements I want to fix up, as well as a few hardware elements I want to verify before seeing what would be involved in making the ROM emulator-friendly. As for minus worlds - there might be a few places where you get contrive to get yourself shunted through a wall (although I'm working on plugging those up) and you might find non-level ROM information being used as level data. In practice you're usually stuck in one or two blocks, so there isn't much to explore, and I usually try to get folks back onto the main level if they leave the screen, but it's theoretically possible to enter a glitchspace.

Harpy's Curse You are a harpy - swift of wing and vicious in nature. Banished to a deadly labyrinth, you are tasked with defeating the four keepers of the maze - only then can you face the Great Sphinx who exiled you here. The labyrinth contains legendary artifacts - feathers of legendary birds and beasts that might aid you. Great power might be found here, but you truly wish for escape, and the only way out is through the machinations of the Sphinx. New! Beta version with Saving capability (SaveKey or AtariVox or similar peripheral required): HarpysCurse_8_18_2023.bas.a78 HarpysCurse_8_18_2023.bas.bin -Explore a vast scrolling maze made up of over 500 screens! -Fly and fight your way to find new abilities and powers! -5 Bosses to find hidden among the winding passages! -Password and saving capabilities to keep your progress! The elevator pitch is: "Joust meets Metroid" I've had a thread in the programming forum, back when this was a "proof of concept" (I wasn't sure I could pull it off initially), but since I plan on having a playable demo at PRGE, I figured I could start a devoted thread to the full game in the main 7800 forum. While I plan on refining the level design and enemy behaviors, aside from music it's largely "feature complete" and I've had folks manage to play through the entire game, collecting all the items and defeating the bosses. I'm experimenting with adding POKEY-compatible audio, which is the next phase in development, plus the thousand other little things one needs to do to get a game from being "finished" to finished. Some more screenshots:

Oddly enough, I've managed to get this far (three full games and one largely feature complete) using 99% 7800Basic, with a only a tiny bit of ASM here and there. It's certainly on the "shoulders of giants," looking at and using a lot of what folks have posted as a foundation, combined with a lot of tricks I've learned over the years. The thing is, if I decided to go full ASM, I'd probably still be trying to draw a square without having the screen roll I've posted a thread on the basics of how I did the scrolling in Dragon's Havoc and Harpy's Curse - it involves having a screen (plus an extra column for the borders) worth of tile data in RAM, dividing it into two parts, and drawing them reversed. You only need to update one column of tiles at a time, and even that only when you scroll to a new column. The process fits in stock RAM, and is fast enough to do in 7800Basic with the double buffer, and still gives you time for more additional sprites, comparable to a stock NES. Dragon's Havoc could have more on-screen "sprites" than Gradius for the NES, without flickering. I'm probably going to have to dive a little deeper into assembly as I mess with the POKEY chip, but oddly I haven't found 7800Basic in any way limiting - quite the opposite. I was able to get 512 screens populated with tiles, palettes, and enemies in about 2 weeks since I had a solid pipeline that went from a bitmap I painted in photoshop go through a processing script directly to byte data. If I was deep in assembly coding, I'd have spent those two weeks trying to find which register was causing some display list list to glitch. I've nothing but respect for those who code in assembly, but I personally lack the discipline - I'm more of a designer who realized he'd have to learn to code in order to implement his ideas. I've also been involved with many projects over the years that got delayed (or even scuttled) by folks who insisted on more complicated tech than the project required. You can make a fun game without cutting edge tech - heck, you can make a fun game with 52 pieces of paper (it's called a deck of cards!) Batari Basic and 7800Basic got me started and running on the 2600 and 7800 very quickly, and debug almost as quickly, and that's honestly made a ton of difference in getting stuff working, improved, polished and finished. If I were going to do a video series, I'd probably talk more about the design than the specific code - I'd probably communicate in pseudocode if it came to that, like I did in the scrolling thread. Even the bank switching is less about coding prowess and more about strategizing what you load when, and where you place things. While I have an idea or two for my Next Big Game (I've teased the idea of an RPG a few times on streams), I'm also tempted to release a few smaller-scope games. Maybe something with the driving controller, or at least the paddles. I picked up a Quadtari...I've a few ideas on what I could do with that. Also, making a screen-by-screen platformer along the lines of a Donkey Kong-alike or Jet Set Willy could be interesting. I've yet to make a "proper" 4K 2600 game, and while I like making larger scope games, I also think the 7800 is near-perfect for quirky "golden-age arcade"/2nd console generation (i.e. early 80's single screen) style games. Dragon's Descent was meant to be one of those, something that would not look out of place in a 1983 arcade (and in turn ported to the 7800). But I still need to finish this game - my favorite game I've ever made is the next one I want to make, and yet I've somehow been able to complete a loose trilogy of games without losing interest or patience. Even with the software done, games take time - in practice it takes several months from a "final build" ROM to getting the boxes, manuals, etc. finished, printed (to say nothing of user testing) to a state where you can order a physical cartridge from Al. Harpy's Curse itself is planned to have its public debut, at least in demo/alpha form, at PRGE this year in (looks at watch) about a week and a half. I should probably post a specific thread devoted to the game in the main forum, since I've move pretty far beyond "proof of concept" by now TL;DR - long tangent-filled developer semi-rant - Hey, it's my development thread! 😜 And a demo of Harpy's Curse should be playable (but not for sale yet) at PRGE!

I certainly can get more screens - even without RLE or other types of compression (I've really only used about half my ROM space). The game actually feels like a pretty nice size, although I want to see how folks play it. While compression might be needed in the future, I like having the versatility to place blocks how I want and not worry too much if I'm "trolling" whatever compression system might be used (RLE can make things *bigger* if you're not careful!). If I did nothing *but* level with the ROM space I had left, I could probably fit over 1,000 (and probably at least doubling that with compression and careful level design). But Dragon's Descent has over 500,000 levels, each with 20-50 screens, so level size isn't everything That said, I'd probably compare the size of this game to Legacy of the Wizard, which had ~256 screens (not counting bosses) but more tiles per screen. Oddly, the bottleneck I'm most concerned about is the bank switching when rendering frames - I do logic on one bank and rendering on another, and if I take too much time things could glitch, so every new line of logic is something I need to weigh, even if the ROM banks themselves have space for it. It's something I'll be looking at more closely as I start testing this first full-featured build. I have a few other things I might add (I certainly have space for more enemy types, for instance), but the game should be played a bit by other folks first.

Achievement Unlocked: Defeat Final Boss with 100% Item Collection Yes - I got the major milestone of playing through the whole game without cheats or debug codes! And only found like 5 or 6 bugs doing it Nevertheless, the game didn't crash or run into any game-stopped glitches, and I collected all the keys, powerups, and defeated all the bosses. I need to play more on hardware at this point, and I plan on refining everything, but this still is a huge checkbox to fill in. Here is the current ROM usage: 7800basic compilation complete. User-defined 7800.asm found in current directory stack allowance: 6 nested subroutines. the canary is situated at: $1ea 5907 bytes of ROM space left in the main area of bank 1. 3310 bytes of ROM space left in the main area of bank 2. 6217 bytes of ROM space left in the main area of bank 3. 4096 bytes of ROM space left in DMA hole 0. 3556 bytes of ROM space left in the main area of bank 4. 4096 bytes of ROM space left in DMA hole 0. 4078 bytes of ROM space left in the main area of bank 5. 16383 bytes of ROM space left in the main area of bank 6. 27 bytes of ROM space left in the main area of bank 7. 1773 bytes of ROM space left in DMA hole 0. WARNING: High score support is enabled, but the hiscorefont.png was NOT imported with incgraphic. The high score display code has been omitted from this build. hiscore assembly: 636 bytes 3544 bytes of ROM space left in the main area of bank 8. custom pokeysound assembly: 743 bytes $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 61 bytes left in the 7800basic reserved area. I still have a comfortable amount of space left (the only bank that's really starting to feel crowded is Bank 7, where I store all the text and menus). Bank 6 (and the extra 16K of RAM, for that matter) are currently untouched, I have them reserved for experimenting with POKEY sound/music. While I came into the project with multibank ROM in mind, I did have a smaller scoped version in case I had to fall back on 48K structure - a smaller game, certainly, but with many of the features intact. The ZPH stream and PRGE got me to headbutt my way through my designer's block - everything could probably use some polish, but the last few weeks turned this project from an engine into a proper game. Different boss behaviors, password system dovetailing into checkpoints found in the game, 500+ screens of platforms, enemies, and items to place - it was a sprint, and I'm keeping an eye out for possible critical fixes, but for now, I'm going to get some sleep. Here are some more screenshots:

@ZeroPage Homebrew Thanks again for hosting the spotlight - it was great seeing folks play through all the games, and a really nice interview!! Now that the game is premiered, the hope is to have a demo version available for PRGE - plus I should start posting more about the features (a lot of which came together in the last week or two!) ;'

While I've been devoting a lot of my time to Harpy's Curse, I've been continuing to test, adjust, and hopefully put the finishing touches on Dragon's Havoc. No new public build just yet, but a few little fixes: -The *very first* screen is the instructions. I've got too many testers just skipping over and not noticing them, and then button mash their way through the game. Playing the game with a leaden thumb on the fire button misses most of the game's tactics, like ignoring the power pellets in Pac-Man. -A few fixes where the display doesn't erase properly between screens. It's just 1/30th of a second each time, but will hopefully will look more polished now. -The game will pause for 1-2 seconds once the player loses their last life, so the "Game Over" should seem less abrupt. -The last lair level (7-2) is a little less merciless. As I mentioned earlier, the curve was very steep. It's still very tough, but hopefully a little easier on the wrists of anyone using the Proline controller long enough to get to the stage to begin with... Here's the current compiler output, for those curious: 43 bytes of ROM space left in the main area. 59 bytes of ROM space left in DMA hole 0. 391 bytes of ROM space left in DMA hole 1. $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 905 bytes left in the 7800basic reserved area. A few bytes left, which may come in handy if any further bugs are discovered. I hope I did right by the 48K of ROM given

A verification (yes/no) before Saving/Loading is in - while I might tweak a few little things, and of course swap out the graphics and get canonical color palettes in, I *think* I have all the menus in for the game. You can input the password or load a game from the title, you can save a game or view the current password at certain checkpoints, and you can view the password or save your game at the "game over" screen, as well as just continuing from the last checkpoint. This turns out to have a lot of edge cases and overlapping states - harder than it sounds and looks to implement, and if you do it right no one should notice. If you do it wrong, *everyone* notices. The menus take up around 9k of ROM all told - I could probably optimize them a bit, but honestly that would likely make things harder to read or follow, and I'm happy it works as well as it does. I still have space on the bank (and elsewhere) for coding the ending sequence (however that turns out) and sprucing things up with some margin graphics. [EDIT] and after fixing a dumb bug I introduced trying to streamline things, I verified it works on a bona fide AtariVox/Concerto setup!

I'm working on adding the save/load system at the moment. I suppose this comes from focusing on the menus early on, and wanting a lot of features, but they're eating up the ROM bank space very quickly! I was hoping to "reserve" the DMA hole for the ending sequence, but I'll almost certainly have to use some of it to round out the menu system. A few questions regarding using the high score system to save game progress: -Are the High Score Cart and the AtariVox/SaveKey functionally identical when it comes to saving "game data"? Anything I'd need to keep in mind when hsdevice is 1 vs. 2? I'm not using the score boards, and my current plan is to have 3 save game slots, with each slot being 3 bytes or so. -What does HSC/SaveKey/AtariVox default to if the spaces haven't been used? My guess is $FF, or possibly random, but is there a recommended way of knowing if data has already been saved, or if the save system hasn't been used yet and is "blank"? My tentative plan is to have a checksum or tag for the last nibble of the save data, especially if I know the cart/vox/key defaults to $FF. [EDIT] - It looks like default values can be set to zero, then loaded (defaulting to 0) - I've been overthinking that ? A7800 supports the High Score Cart, but how does that jive with testing a save system as implemented through 7800Basic? On my system, the emulated HSC and XM run and don't crash, at least, but I'm at a place where I don't know if my code is wrong, my emulation setup/config is wrong, or it isn't actually supported yet, as it doesn't seem to "save" the data. I've just started to dig through the A7800 documentation and forum threads, but if anyone has a quick answer, it would be appreciated I'm a little hesitant to try on my physical AtariVox or SaveKey until I have it working as well as I can in software... [EDIT EDIT] I'm able to save high scores on Dragon's Havoc, at least, so I can rule out emulator configuration - I'll see if I can narrow things down. My first question still stands - any difference between the HSC and the AtariVox/SaveKey? And anything else I should keep in mind if I'm only using these peripherals to save data, and not scores, within emulation or otherwise? [EDIT EDIT EDIT] OK - I think I have the basics working, or at least what doesn't work is my fault ? Now I just need to work out the logic traps that come from having nested menus that change on context. UI is harder than you think it's going to be, even taking that it's going to be hard into account...even on 8-bit platforms, if you want to do a half-decent job with it [EDIT X4] And here's a screenshot, temp art, debug values in the corner, incorrect palettes and all! Oof, I'm going to need to add an "are you sure?" sub-menu to this, aren't I?

That did it, thank you! I figured it was a sync issue - A7800 is the one I go to when I want test accuracy, so this was a good thing to figure out (and note if others play it on A7800). Developer mode is awesome as well

Y'all called it - I took a page from Castlevania's various password systems, although those got surprisingly complicated. The icons grids from Bloodlines and 3 are a nice way to encode a bunch of booleans. I didn't want to program an alphabetical input system, and I doubt anyone wanted to use one Finalizing the level format - although in terms of appearance it's still all largely temp, test, and older sprite art - I'm getting to the actual "art" phase soon. The *types* of blocks are in, though, so I can actually think about what they'll look like. I'm looking forward to toying with how spikes, water, columns, and statues will look in various parts of the maze... Current compiler output: 7800basic compilation complete. User-defined 7800.asm found in current directory stack allowance: 6 nested subroutines. the canary is situated at: $1ea 6402 bytes of ROM space left in the main area of bank 1. <- (Main game logic) 12977 bytes of ROM space left in the main area of bank 2. <- (Level data) 6450 bytes of ROM space left in the main area of bank 3. <- (Normal game drawing) 4096 bytes of ROM space left in DMA hole 0. 6287 bytes of ROM space left in the main area of bank 4. <- (Boss drawing) 4096 bytes of ROM space left in DMA hole 0. 13861 bytes of ROM space left in the main area of bank 5. <- (More level data) 16383 bytes of ROM space left in the main area of bank 6. <-(Tentatively reserved for sound) 2393 bytes of ROM space left in the main area of bank 7. <-(Menus and other Text screens) 4096 bytes of ROM space left in DMA hole 0. 7623 bytes of ROM space left in the main area of bank 8. <-(Shared bank, .asm modules, current sfx, player and level background graphics) custom pokeysound assembly: 743 bytes $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 513 bytes left in the 7800basic reserved area. A busy week trying to finalize the rest of the game systems. Adding a feature is an O(n^2) problem, as you have to reconcile any new feature with every one you've added previously, trying to fix any bugs you've discovered or introduced... Today was coding more enemy behaviors - I think that those will be the last major CPU processes in the main game loop - if it runs OK with all this in, I'll feel much better playing with the data. I've been having fun with it, though - I'm able to combine different movement patterns with other qualities (does the enemy shoot? is it affected by gravity?) so that they can be a variety of types of enemy behavior for the player to encounter. The maze will have a few things to look for - while I do have explicit keys and locks, I also have a few powerups. I'm not making the powerups required, for the most part, but they'll be *very* nice to have. Collecting one of them will give a screen telling you what it does and how to use it - Of course, part of me was tempted to make this game as cryptic as Legacy of the Wizard or Goonies 2, but I think folks expect a little more fairness (and explanation) nowadays. I've roughly budgeted how big the game will be in terms of levels - My next step will be adding in a "blank" data to make sure it all fits and loads in ROM. I mentioned my estimate above - I think between 2 banks I can get 64 "sections" - each section being a horizontal scrolling area 8 screens long - so 512 screens total, each screen being 10x10 tiles. I could probably make even more, but I want to see how much space the other banks use once I get a better handle on how much more space other systems (particularly sound) will need. And I should see how big this much level data feels as I start planning out where to place powerups, keys, and bosses. The password system is working, although I'm not encrypting it yet, as it's currently a nice debug system to cheat progress at this point. I've a plan to use SaveKey/AtariVox as well, which will hopefully be straightforward since I'm not using any of the data to save a high score on this game. It still requires testing on physical hardware, which I have, but iterating and testing on such hardware takes that much longer, so I've been putting it off... ...oddly, the first ROM bank I'm starting to feel the "crunch" on is the one I allocated for menus. Text and proper menu/UI behavior takes up a ton of space! I have the basics in, except for the Save/Load screen. I'm pretty sure I'll be able to fit the menus in on a functional level, my main worry is how much will be left over for fun stuff like the ending, pretty title graphics, etc. Sounds and saves notwithstanding, I'm actually shifting gears into content. As mentioned above, I'm starting level design proper (not just formations to test stuff), as well as starting to doodle some sprites and pixel art again. It's tricky, though - you an *finish* a feature, but you never complete art and design, you can only to get to a point where you can say "eh, good enough." I may ask about this is a more focused post, but while performance *seems* okay on both BupSystem and the Concerto, A7800 sometimes gives a graphical "stutter" - It doesn't *seem* to be related to how busy the game is (i.e. performance as such, it happens at intervals unrelated to, say, how many enemies are on the screen), and it might be something similar to what I ran into with Dragon's Havoc, where a slight mismatch in game and display framerates "catches up" at regular intervals. As I said, it still seems to run OK on the Concerto, but I'll be testing more on A7800 (and the Dragonfly, once I get the power supply figured out) as I try my hand on including POKEY sound.

The forum thread for "Dragon's Descent" has instructions (and a ROM that should be good for this HSC) in the opening post: https://atariage.com/forums/topic/291525-dragons-descent-actionroguelike-for-the-7800-ported-from-the-2600/ I'm the designer of the game, so let me know if you have questions! I'll put the instructions here as well- CONTROLS Joystick - Move the dragon around the labyrinth. The dragon is flies through the maze, and has momentum - keep that in mind! Button - The dragon will breathe fire in the direction it is facing, left or right. SETTINGS You can change the settings by choosing the options on the title screen. If the text is gold, the setting is "on." If the text is blue, the setting is "off." Infinite Maze Mode: Game will continue indefinitely, only ending with a game over. If turned off, the game will end after you complete level 7 Random Maze Mode: You will start in a randomized maze. If turned off, the maze will be the same layout each playthrough. Music: This option on the title screen toggles music on/off Hard Mode: If turned on, walls will harm you if touched. If turned off, the walls are harmless. "Hard Mode" is the same mode as the 2600 version of the game. Maze Select: Allow you to set the random "seed" when starting the maze. Move the joystick left/right to select the left or right seed, each can be set to a value between 1 and 255. The levels are procedurally generated, but are always the same progression, and the layout can be mapped. HOW TO PLAY Depending on your game settings, you may find an end to the maze on the 7th level, or the maze can continue until you are defeated, trying to attain the highest score! Each level of the maze is made up of several rooms - you can leave through any exit on the boundaries of the screen you find. To make progress in the maze, find the key on each level, and then the level's exit. The exit, resembling a door with a key imprint, will only activate if you touch it while you have the key found on the same level. Upon each new level you will face more dangers but also potentially increased power and scoring! Avoid touching walls and enemies - doing so will deplete your hit points, and eventually end your game! Scoring comes from collecting gems and defeating monsters. You get more points for defeating monsters in deeper levels, and a slightly higher score for each shot you use with stronger fire breath. In addition to a key and exit, each level of the labyrinth has a treasure room. Treasure rooms allow you to pick one of three power ups, just wait until you see the one you want: Gem - increases your score. Heart - increases your total hit points, while completely replenishing your health. Lamp - increases the strength of your fire breath, while refilling its supply. Don't stay too long on a single level, or you may find things getting much more difficult! The deeper you explore, the more monsters, dangers, and higher scores you find... You hit points are shown next to the heart icon at the bottom of the screen. Your game will end when if the hit points reach zero. The strength of your fire breath is indicated by the color and size of the flame. If you collect a flashing lamp from the treasure room, it will increase in power but you will only have a limited amount, shown at the bottom of the screen next to the flame icon. If this supply ever runs out, you will go back your initial, weakened fire breath. You can find non-flashing hearts and lamps from fallen enemies, which will replenish a small part of your hit points or fire breath, respectively. If you survive long enough, you may reach a maximum amount of hit points or firepower, in which case your health or score will be flashing.

A few updates, and another screenshot... I expanded the level data to fit into bank 5 as well as bank 2 - I don't need it *yet*, but it will be easier to remember to do now, and make sure the branching/loading method I'm using works. I can designate a boss as a "final" one, and defeating it will go to an ending state/sequence, so you can "win" the game now, such as it currently is Started the password system, for those without a SaveKey or AtariVox (which I'm also planning to support) - I'm still working on the proper graphics and colors, but the functionality is largely there (although I'm still working on some encryption methods): I've been logging the compiler outputs - mainly to see how the project progresses as well as seeing how "heavy" each added feature is. The password screen/system weighs in around 1 kilobyte at the moment - not too bad, and within my current ROM "budget" I have for the bank devoted to menus, but text and menu systems can devour ROM space pretty quickly if you're not careful!

Getting the general foundation worked out for the whole game: 7800basic compilation complete. User-defined 7800.asm found in current directory stack allowance: 6 nested subroutines. the canary is situated at: $1ea 8012 bytes of ROM space left in the main area of bank 1. <- Main Game Logic 11153 bytes of ROM space left in the main area of bank 2. <-Level Loading/Data 6806 bytes of ROM space left in the main area of bank 3. <-Drawing Graphics 4096 bytes of ROM space left in DMA hole 0. 6364 bytes of ROM space left in the main area of bank 4. <-Drawing for Bosses 4096 bytes of ROM space left in DMA hole 0. 16383 bytes of ROM space left in the main area of bank 5.<- (more level data?) 16383 bytes of ROM space left in the main area of bank 6.<- (music/sound?) 5586 bytes of ROM space left in the main area of bank 7. <-Menus 4096 bytes of ROM space left in DMA hole 0. 7656 bytes of ROM space left in the main area of bank 8. <-Shared Bank, mostly graphics and sound currently custom pokeysound assembly: 743 bytes $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 513 bytes left in the 7800basic reserved area. Getting close to a minimal prototype - the equivalent of putting every item, key, and boss next to each other to make sure the systems all work together. I mean to have 4 keys, each of which opens 1 kind of door. Teleporters are a possible encounter - able to send you to any location in the game. On top of that, I have 4 life-ups (think Heart Containers in Zelda or Energy Tanks in Metroid) to hide in the labyrinth as well. I have 2 dummy bosses working, and I mean to up that to 5 (4 regular bosses and 1 final boss), which should hopefully be pretty straightforward now that I have 2 working. As with a lot of programming, making the 2nd element is the hardest - the 3rd and 4th are usually much easier. A lot of this week has been working on boring stuff that folks would immediately notice if it wasn't working. I need to keep track of what a player has collected, for instance, and make sure I "remember" that an item is present or gone as I load and unload different level sections. Same for bosses, and same for similar types of little things for enemy loading/unloading in a scrolling world. It's all stuff I'll likely be wrestling with throughout development, but the basic stuff is mostly in now. Being able to backtrack through the entire game makes things a lot more complicated than a simple "scroll forward" game! Oddly enough, while I mentioned playing with sound, I think the next steps I'm going to tackle are to get a space to have an ending sequence, and then a password/save system. I finally have a complicated enough game state that I can build and test that! Screenshots wouldn't be much to look at - if this were a house, it'd still be scaffolding and drywall, but the foundation is poured and the plumbing is nearly done. *Then* I can start bringing in the furniture and picking the paint colors, so to speak. I'm trying to get all the general stuff in before I work on unique elements like boss behaviors. I still have 2 banks I haven't touched, nor have I used any of the expanded RAM yet. One of the banks will almost certainly be for more level data, and the other bank will likely hold sound and music.

It's been awhile since I've posted a screenshot - more prototyping and stress-testing, really: You'll notice a life bar, collected key, 4 enemies and 2 shots onscreen. I've been modifying my level editor script from Dragon's Havoc - I can "paint" levels as a bitmap, which includes placing enemies and items, although I need to be a little careful how and where I put them, and then output it to a data array to copypaste into 7800basic. A lot of arrays and indices, often referring to other indices and arrays ? The collected key can open doors, the enemies can have different behaviors and appearances, your health meter diminishes when touching things you shouldn't, leading to a game over when its reduced to zero - all things that sound simple but are crucial to design so that all the components play nice together. The immediate next step is to organize my palettes - they fade nicely, and I can define each level's color scheme, but I need to extend that to the enemies, items, and UI elements. It's an easy step to put off, but it's a good thing to have taken care of when you're constantly testing other features. Mid-term is to get 2 types of enemies, 2 types of keys/items and a dummy boss working. If I can get 2 of something working, it's usually easy to get a third, fourth and so on. Something of a "vertical slice" to make sure each thing is working before going forward and making the full game in earnest. Once I have a gameplay "vertical slice," I might actually get around to playing with POKEY audio - I have a few ideas, but I want to see how the rest of the game's "skeleton" fits together first... Thanks again for everyone's help and advice - I imagine I'll be asking some other questions as I test these game data and mechanic systems on an expanded 7800 ROM space!

Good to know - I'll likely be testing on a Dragonfly soon as well, as I try to see if I can get Pokey-compatible sound in. My scrolling system basically involves cutting a screen-sized character map in two and shifting them a little bit on the x, but since there's no y movement, that might actually work. I still need to draw the player, enemies, and objects on top, though, and those can be anywhere. Thank you for the info - while does sound like something I could actually take advantage of, I'm going to implement some other things first and see how well everything else fits together. I might ask later, but for now I think I can work with the ROM-based graphic blocks. I'm juggling how to load and process enemies and other objects, so I'm at my own limits of hairiness at the moment I had originally thought the double buffer would protect me from multi-bank graphic block switching, and it kind of does, but one still needs to be careful! I'm re-organizing how I'm laying out my graphics blocks and bank a little, now that I realize I was butting up against some CPU/MARIA timing limits. Honestly, the new layout makes more sense - The background tiles are in the shared bank, not because they're used everywhere, but because when they are used, I'll be jumping around the most banks and likely spending the most time-per-frame there. Before, I instinctively put the text in the shared graphics block. The thing is, it that takes up a ton of space, I can really only have one characterset active at a time, and I really only need it for menus and dialogue-specific screens, so it can go in the "Menu" bank. I still have the numbers in the background tile graphics block, but honestly I could probably make an icon-based UI during gameplay that doesn't even use that. I'm basically going from 3 graphics blocks at once (one of which I wasn't really using) to 2 blocks - The biggest real change is that I'll have the player graphics share space with the enemy/object graphics, which won't be *that* big of a hit in terms of space. And if I feel risky, I might see if I can get away with putting the enemy graphics block back in bank 3, since I was still getting away with it there. Thank you again for your help - I know these are lengthy posts, but I think it's good to document the design process along with the tech. Multi-bank design is as much an art as a science!

Thank you - I suspected this was the case. I'll keep that in mind as I add to the game logic - luckily there's some space on the shared and "graphical" banks, and I might have some alternative ways to reorganize the graphics if space gets tight. It seems to work fine on the Concerto, so I'm hoping if the graphics work there they'll work on a cart. Plus, I still haven't tapped the extra bank of RAM - I know it's *possible* to put graphical data there, has anyone posted or shared methods of doing so? I imagine some careful inline assembly would be needed for a 7800Basic project.

I have a few questions - based on some bug hunting I've done this last week - hopefully this is coherent: -For 7800Basic, does all "const" care about is when it's called/defined? And it just does a string-to-number replacement at compile time? So you want to call it earlier in the file? And it doesn't care about banks? I've had some issues where it compiles and works fine on emulator, but creates strange behavior on the Concerto - putting all the "const"s at the start of the file fixed the issue. Oddly, it was a case where the emulator version probably should *not* have worked, if things are as I understand them. -I have some graphic block/bankswitching behavior that *seems* to work, but I might be getting away with something I shouldn't: *I have the bulk of my game logic in a bank with no graphics block (besides the shared one in bank 8). I use the double buffer, and use a characterset, draw and "flip" the buffer in a separate, devoted bank. This seems to work fine, on emulation and on the Concerto, but I wanted to make sure this is proper behavior. I'd rather know now than find out it won't work when I'm burning the final EPROMs! *The way I have things set up now is nice - the background gets its own full graphic block (the characterset I use for a in-game frame), as do the enemies/objects, and I can fit the logic in its own block without having to make room for the graphics there. With the "final draw" bank I have access to 3 graphics blocks (1 shared, 2 in-bank, although of course only 1 character set at a time), the game logic totally different bank. I just want to make sure I can get away with this... *Oddly, the only graphical glitch occurs when I load in a new level from *another* bank, which also has no graphical block (or draw calls) defined in it. Honestly, this is kind of expected behavior, and I get around the issue just fine for the moment (going to black and fading in, a practice which I've had recommended to me). I'm more worried that this *isn't* happening normally, even if it is, at the moment, to my benefit... *I guess my main question would be: why would the graphics glitch in "load level" bank, and not the "game logic" bank ? My going theory is that loading a new level is a longer process that might last more than a "frame" worth of time, and glitch the hidden part of the double buffer before I flip it. The bank layout as I have it below: 8723 bytes of ROM space left in the main area of bank 1. <- Game Logic here 14608 bytes of ROM space left in the main area of bank 2. <-Level Loading here 0 bytes of ROM space left in the main area of bank 3. <-Final Graphics Drawing (and doublebuffer flipping) here 3082 bytes of ROM space left in DMA hole 0. <-DMA hole created by level background character set 4096 bytes of ROM space left in DMA hole 1. <-DMA hole created by enemy graphics 16383 bytes of ROM space left in the main area of bank 4. 16383 bytes of ROM space left in the main area of bank 5. 16383 bytes of ROM space left in the main area of bank 6. 14253 bytes of ROM space left in the main area of bank 7. <- Title Screen and Menus 7841 bytes of ROM space left in the main area of bank 8. <-Shared bank with its own graphics block (player sprites, title screen/menu font - I *don't* use text in the game proper, only in menus at the moment) TL;DR - Given the bank layout above, is it ok to run the game logic in bank 1, goto bank 3, and draw everything, flip the double buffer, and then goto bank 1 for the next frame to start the logic again? Or will I ultimately glitch the graphics? Again, seems fine on the Concerto... Thanks for everyone's comments and help so far - I know my messages get pretty long and complicated, but I generally only ask for help when I'm deep in a hole, or have a complicated question

Some folks speculated that the final boss of this game would be, well, a dragon. While that's a good guess, the final boss of Dragon's Havoc will be a surprise, challenge the mind, and makes a callback to old classics of the Atari 7800 - and to prove it I'm posting a screenshot! (Before anyone takes this too seriously, please note the date I posted this, Pacific Time zone - one can never be too careful joking on the internet )

Excellent advice - and good to hear. There's a fair amount of technical information around, but finding good design practices can be harder to find (it's often in the forums, but can be trickier to search for than specific tech terms). Having the screen "black out" when switching between banks and blocks is good to know, especially as I bring in different menu screens. Atari 2600 development has taught me to be stingy with variables, and the 7800 already felt freeing before the extra bank of RAM - having an additional 16K can sound decadent if you're used to fitting game logic into 128 bytes! Of course, one can always find uses for more RAM - my priorities would be for the Pokey tunes, as you mentioned, followed by some extra display memory (mainly to give the MARIA some breathing room, the graphics seem to be under control, but it feels like I'm on the knife's edge right now). My other concern is how much a RAM bank will complicate making a physical cartridge as well as emulation - it seems like the some platforms want (at least) an adjustment to the header file. The most feasible method for adding Pokey compatibility is of course the big question for a physical cart, but moving up from 48K to larger layouts complicates production regardless.