Revontuli

Thank you! That did it - when all else fails I suppose I should re-read the documentation! With the DMA holes, it seems like you'll get 8k of graphics per bank (unless you're sticking with zone-locked graphics and some custom ASM code) correct? The scrolling code I use assumes zone-aligned tiles, but the characters and objects can be anywhere on the screen. 8k per bank in a 128k ROM is a nice amount, although I can imagine using the RAM to store more level tiles, etc. as previous posts have suggested. Regardless, this frees up a ton of space and simplifies a lot of my bookkeeping (graphics *here*, code *there*). I usually try to learn something new with each game, and I'm looking at banksets (and data compression) for the platformer I'm working on. Thanks again for the help!

I'm porting over my scrolling system, and seem to be most of the way there, but I'm having trouble with A7800 emulating the POKEY sound on my ROM when turn banksets on. I have POKEY@450 set in the source code. I'm not sure if it's a case of the headers needing to be set a certain way (setting Pokey@450 on its own using 7800Header doesn't seem to work), but my current setup is a 128kROM16kRAM(x2 for banksets). Everything else, graphically, seems to be working ok at this point.

A lot of the games I've made for the 7800 were meant to fill in genre gaps in its library. I generally try to add my own spin on the games instead of direct remakes, but the missing/underrepresented genres certainly have informed what I've chosen to code. Instead of remaking R-Type or Columns or Metroid, I'll try to add some unique story, graphics, and mechanics to make the game my own, (insert any "we have [popular game] at home!" memes here). I'll also add that most of these games are for sale in the AtariAge store (or I plan for them to be) if you're in the mood to play a puzzler, shmup, or MetroidVania on the 7800. Dragon's Cache, for instance, is a puzzle drop game that supports 2-player head-to-head, along the lines of Columns or Tetris, and is something the 7800 totally needed, IMHO. Dragon's Havoc is a side-scrolling shooter, another genre oddly missing from the 7800 (Plutos and Sirius never got out of prototype phase, IIRC). It was fun leveraging the 7800's graphical system to implement parallax scrolling - easier to do than on the NES. It also has 2-player simultaneous play! Harpy's Curse is currently in testing, but is my stab at a MetroidVania - it's more like "Joust Meets Metroid" but has over 500 screens (1000+ with a second quest in the work) to explore and uses horizontal scrolling engine. Each project I endeavor to learn more about the 7800, and build of off the code I wrote from the previous games. I've currently got a platformer and an RPG in tentative works, and seeing how they develop, and I usually post more about them in the programming forum as I make progress. The 7800's potential combined with its original, neglected library is one of the reasons I homebrew for it. If I make a shmup or platformer for the NES, it's one of hundreds that already exist. If I make a shmup or platformer for the 7800, it's nearly unique and feels like it's filling in a gap.

Found out yesterday! Thanks to everyone for playing! Take a look at the nominated games here and cast your votes for the games of your choice here!

Found out yesterday! Thanks to everyone for playing! Take a look at the nominated games here and cast your votes for the games of your choice here!

Got the news yesterday! Thanks to everyone for playing, and for those who have helped with my various coding questions during the development process! Take a look at the nominated games here and cast your votes for the games of your choice here!

Got the news yesterday! Thanks to everyone who has helped out or played the game! Take a look at the nominated games here and cast your votes for the games of your choice here!

I'm using 7800Basic, which handles a lot of the graphics weirdness the 7800 requires, and using that interface I'm simply drawing a lot of 16x16 pixels elements (Display Lists, or "sprites") as tiles: It's a 6x8 tile map, that moves around with a 1-tile margin on all sides. Yes, that means I call "plotsprite" 48 times, and they're not guaranteed to be entirely within 1 zone, so in a way I'm usually calling it 96 times. I know there's a possible workaround for vertical shifting, but that would also change a lot of how I'd thinking about making a 4-way scrolling system in the first place. The "mask" is just another graphic I draw on top of the whole thing, with a black border and a transparent interior (magenta being the transparent color for this example): Combining the two we get a scrolling "window" that hides the constantly shifting tile margins: As you can see, there's a lot of space that's blacked out at any given time, but that extra portion could be on any side (top, bottom, left, or right) of the scrolling map, so I'm literally covering my bases. Of course there are any number of ways to optimize this, but I found it to be a good starting point.

DragonsVerseScrollPrototype_2_1_2023.a78 This is still something of a tease - not even really worth posting as a "coming soon" game yet - I've been outlining various RPG mechanics, what might fit within 7800 performance and ROM space, and what kind of RPG I'd like to personally make. I figured I'd post this little "sketch" before various 7800 tricks and developments make it obsolete. It's as much a test of "how many Display List Lists can I fit onscreen in a very ineffecient scrolling system." as much as a test of how my overworld map *could* work. It's really pretty simple, I just draw a ton of single DLLs as map tiles, and have the crystal ball graphic act as a mask for the edges. I don't do any optimization, each "tile" is a "sprite" - no optimization of colors, but that also means I can paint the world how I want. It also means each tile can be whatever palette I want, and they're pretty easy to animate since they're drawn each frame. I'll admit the lookahead isn't great, but MARIA gets a little overwhelmed with any more graphics drawn, especially with the crystal ball "mask" on top. I *can* add a character (and drop shadow) in the middle, and kept the text counters from the sample code I started from as a way of seeing how much text I can plot to the screen under the main scrolling section of the screen. The map is small, at 16x16. I have a few ways I could make it bigger, but that wasn't the thing being tested in this prototype - it was mainly the way one looks at and travels the map. The graphics are also incredibly temporary - I just wanted to get one animated and throw in a few palettes to make sure the system worked. If I can do it once, I can do it many, many times. I'm looking at a lot of elements, like ROM/RAM layouts, this new banksets feature that just got 7800Basic support, how much text I could fit into a hypothetical game, how much information I can squeeze out of a SaveKey/AtariVox save slot (my go-to for a save system), etc. etc. even as I plan out what the actual game could and would be like, so there's a lot of moving targets and specs at the moment. And yes, you'll likely play as a dragon. I find it odd that folks find this odd - given the choice between playing as a plumber or a primal flying force of destruction, I'd generally opt for the latter within a video game Honestly, my working design is that this would be a roving monster party, kind of like a Shin Megami Tensei group or Pokemon team without a human in the center. I'll post any other little developments or prototypes here as I tinker with things. I'll also add I have at least one other project in the works (post-Harpy's Curse) I want to get to before this, so, again, don't hold your breath for too long. And don't wait for this to be released before getting the already released games in The Dragon Trilogy

No need to apologize! I feel a little bad for jumping in and pushing certain limits from the get-go! I'm very excited about a feature that more than doubles the graphics I can have access to (as well as free up more ROM space for code). I also know this is a beta, and part of the development process. I try to make sure any issues I find are not a result of my own ignorance, and I try to narrow down what a given problem might be first, but I appreciate your work and efforts!

I'm gradually getting the bankset stuff to work - While I'm not porting Harpy's Curse itself to a bankset system, I'm trying to move a lot of its code over as a proof-of-concept as I start another project that will take advantage of a lot of its codebase. My current stumbling block is reconciling multibank layout with the bankset - This code compiles but A7800 has trouble running it (removing the "set banksets on" will get it working again): set banksets on set romsize 128kRAM __StartROM BACKGRND = $0A goto __StartROM bank 2 bank 3 bank 4 bank 5 bank 6 bank 7 bank 8 [EDIT: It seems to work ok with romsize 128K but not romsize 128kRAM] I'm also trying to gauge how much graphical space I actually have when considering the DMA holes and extra RAM. I will say I'm having flashbacks to the first time I shifted from one 48k bank to several 16k ones I'm at that point where I'm trying to implement an awesome feature (banksets) while stuck in the weeds of getting it to work! I think I'll move my further questions to their own thread, to avoid crowding this one (who knows, maybe it will aid in a tutorial eventually) - I have a project I've working on that can hopefully take advantage of the extra graphical (and DMA hole-free code) space!

I'm finally getting around to trying banksets, which it taking some getting used to. I take it these errors are normal? A7800 does seem to run the final ROM image. [...compile messages...] 7800basic compilation complete. User-defined 7800.asm found in current directory too many endif's too many endif's too many endif's too many endif's stack allowance: 30 nested subroutines. the canary is situated at: $1c1 stack allowance: 30 nested subroutines. the canary is situated at: $1c1 Complete. (0) starting bankset symbol transfer. bankset symbol transfer complete. stack allowance: 30 nested subroutines. the canary is situated at: $1c1 28169 bytes of ROM space left in the main area. $1880 to $1fff used as zone memory, allowing 31 display objects per zone. 2401 bytes left in the 7800basic reserved area. [...more compile messages...] I'm realizing how much I'll have to switch around the programs I used to use for testing ROM builds. I take it that we'll, at the very least, need to upgrade firmware for the Concerto/Dragonfly? I will miss BupSystem for testing - I respect the accuracy of A7800 emulation, but I need to remember the macros and environment variables to use to run the darn thing from the command line (or otherwise go through 8 menus to test a build XD) Again, the added functionality is very much appreciated (I've always run out of graphic block space first, before ROM, RAM, and even CPU cycles) - but I want to make sure that, as I change how my pipeline works, I'm not forgetting anything or getting something wrong this early on!

Thank you for the demo - I had the chance to play through it and I think it does exactly what you wanted it to. To me, at least, I see what you were going for, and I didn't need to see an entire port of Link's Awakening to see the potential for 7800 games. This is also making me reevaluate using 160B for backgrounds moving forward - this shows the dynamic of how drawing "a few larger objects" can be faster than "a lot of smaller ones," something that can be very true on the 7800. A system to optimize a set of 160A display lists might be slower than just calling one big 160B list, and the latter approach is certainly a lot simpler! I was turned off a bit by using 160B in the past due to performance concerns and it effectively halving the amont of graphics I could use (and I found graphics banks tended to fill up before RAM and ROM), but given larger ROM banks and bankset bankswitching, this looks like it will be much less of a problem in the future. My scrolling engine assumes 160As for the background, with around 5-10 sprites to spare per zone, but seeing this I want to see what I can get away with using 160Bs. I ran into performance issues with an earlier game, but looking at this demo and how I was doing things, it might be due more to CPU logic than graphic chip limitations. Regardless, the fact that you can make a full background of 160Bs and have enough sprites to spare for other elements is impressive! Making a full game would be a lot of work, of course, particularly design-wise, but technically adding things like collision, etc. would be pretty straightforward in that the processes to do so are known (PEEKing the screen data would be fine for a game like this, for instance) I'm already integrating some of the ideas here into my own prototypes for future projects, so I've gotten quite a bit of value out of it. This is a technical demo, and criticizing it on design grounds is like criticizing a speed-record-breaking sports car because you don't like its color Wonderful work, and thank you again for posting!

It should be in the next wave of releases in the AtariAge store!

Thank you (and thank you for the build) - I figured this was the process, but currently have no way of testing it! I uploaded the Concerto/Pokey build to the original post.

I usually post in the 7800 forums, and I'm honestly not sure how much crossover there is between this forum and that one, but I figured this might be of interest for a few who might not know about the series of games I've developed over the last few years... The "Dragon Trilogy" is a set of games, each a different genre, using dragons as a sort of motif: Dragon's Descent (a port of the 2600 version) - an roguelite arcade/action dungeon crawler. Thousands of possible levels. Dragon's Cache - A match-3 puzzle drop game in the tradition of Columns. 2-Player versus available, along with a battle and time attack mode. Dragon's Havoc - A shoot-'em-up with parallax scrolling, 20+ levels and 7 bosses. 2-Player simultaneous play available. And, currently in development, Harpy's Curse, a sort of "Joust Meets Metroid" labyrinth with power ups, bosses, and 500+ screens worth of scrolling regions to explore. The forum threads also have something resembling devlogs as the games evolved from testing prototypes to releases. Most of these are (or will be) in the AtariAge store as well! If you have a 7800, or are curious about the system, there should be something in at least one of these games to interest you

I just posted a "for your consideration" build - it's not the complete game (this demo goes to 6-1), but has the stage select automatically activated so folks can see/play later portions of the game quickly and easily. Hopefully this will help folks on the fence of purchasing the full, physical version! Links are in the original post and here: DragonsHavoc_Dec_2022_Demo.bas.a78 DragonsHavoc_Dec_2022_Demo.bas.bin

I tried messing with the 7800header - if it's "fixed" on the Concerto w/ POKEY, does it typically "break" for, say, the DragonFly? Removing the @450 tag removes ability for the DF to play the POKEY soundtrack, which makes sense but, again, I've no way of knowing if it fixes it for the Concerto at this time, at least on my end, and I want to keep the number of iffy ROMs floating around to a minimum I can try posting the fix - or anyone who got it working on their Concerto has my blessing to posting a ROM of the game with the fixed header in this thread.

Awesome! I agree that the banksets are the big thing, but I appreciate the pokey sfx pitch shift, since that allowed me to make the music tracker for Harpy's Curse much, much more easily The bankset stuff is a big deal (gfx bank space is typically the first thing I run out of or have to restructure for, *way* before ROM and RAM) - Harpy's Curse is effectively finished (or at least finished as far as fitting into its 128kROM16kRAM layout), but I'm certainly keeping a 2x128K ROM in mind for a possible platformer to follow. Is there any documentation out yet on how to properly use banksets in 7800Basic (as opposed to asm), or it is that coming soon? Amazing work as always - 7800Basic makes developing for the 7800 a ton of fun, thank you!

Took a "break" from POKEY testing and level design to update and test how saving data might work - Although I'll probably hold off on making this public until I get other stuff working. Allowing saves through peripherals basically guarantees the game won't work on most emulators, and makes debugging much, much more complicated, and will only work for the small percentage of folks who have a compatible peripheral. JS7800 might work with it, but I think the save game slots will be shared by everyone with the link. There's a reason I put a password system in place as a backup That said, I had to do some updating but it seems to work on my SaveKey and Dragonfly (now to test on the AtariVox and Dragonfly, the Concerto and SaveKey, AtariVox and Dragonfly, etc. etc. - you might see why I've held off on this, it makes POKEY testing on peripherals easy by comparison ) I hope I can at least get it properly working on the published cartridge version. The method to access the 2nd quest is current being tested, this is all feeding back to testing the password system and save games. I'll probably try to upload a final "beta" build for the new year - It's a full game as it stands, with bosses, intro, musical score, ending - the whole deal. The proper "2nd Quest" I'm working on is really for those who have already beaten the game and think it's too easy, so I want to spend some time to make sure I do the quest justice. It's also for those who think I should do more with the little secret I put in!

Thank you! I knew there were combinations of the extra RAM and POKEY addresses that didn't play nice on certain setups - I haven't actually done much header editing yet, so I'll see how it works out. I also need to see if those settings play nice with other emulators/sd carts/etc. I'm still trying to keep the variety of ROM builds to a minimum (ideally 1) until I have a "final" build, feature-wise. Then, the priority is getting a proper cartridge build - after that I'll worry about about more compatibility across the various 7800 setups. I'm glad the game at least seems playable on most modern emulators, POKEY addresses and Prosystem emulation notwithstanding. There's still a way for just about everyone to play it, even if it's JS7800. I'm pushing to get the last features in (one smaller secret leading to a much bigger one), hopefully having something a little after New Years!

If it's benign, then that should be OK (it's the same amount of cycles either way, just a little confusing since I have Music Off/TIA/On, with "On" meaning "Pokey" as options) - thanks! Updated to 7800Basic v.2 (which seems to be fine once I remembered to add the pokeysound update from this thread) - I'll need to play more to make sure nothing has changed or glitched. @Lord_of_Sipan Here's a concerto build to try - with the warning that I don't know if this will *actually* work since I lack this specific hardware: HarpysCurse_12_23_2022_ConcertoPokey.bas.a78 HarpysCurse_12_23_2022_ConcertoPokey.bas.bin

OK - I might give this a try. I was holding off on updating to 7800Basic v.20 (updating compilers late in a development cycle is just asking for trouble - it even caused a bit of a speed bump in "Dragon's Havoc" when I had to redo the larger sprite rendering). Another reason I was holding off was I don't want to get into a state where I'm managing multiple ROMbuilds for different emulators (even having a "savekey"-less build was a pain and caused issues when trying to make a definitive build on previous games). What happens if the POKEY *isn't* at $450 (or anywhere)? The documentation implies that setting the address will have the ROM assume *something* is there...

7800Basic on the Concerto seems to have some problems finding the POKEY chip - I know there's been some work on making the process more straightforward, but I'm not sure what the current process is (for a while you needed to change the header, or give it a different address location) - I also don't have a good way of checking if it works on my end as my Concerto lacks a POKEY compatible chip.

I've regretably had to stop supporting the Prosystem emulator - it has trouble rendering graphics a certain way, and seems to have issues with ROM sizes larger than 48K (at least when I build them) that otherwise run fine on hardware and other emulators. It hasn't been updated since 2015, and I try to keep compatibly more in line with more recent emulators: -BupSystem is the one I usually use when I'm testing features - it's quick and easy to use. -JS7800 can play the game in a browser (just turn off VSync in its settings if it's running slowly). -MAME A7800 is probably the most accurate (and supports things like save peripherals), and I use it as a "dress rehearsal" before testing a feature on hardware. I know Prosystem used to be the go-to 7800 emulator (still kind of is for some setups), but I haven't been able to use it to test 7800 games I've been developing for a while now, and I know others have had similar experiences.