TwentySixHundred

So when trying to launch using XM expansion im getting an error message saying "the selected software is missing one or two files" (a7800 v4.0). Im guessing i would need to download the XM puggin software but can't find any links. Then when changing the extension to "a7800 a7800 -cart1 xm -cart2 sounds.bas.a78" the ROM boots fine from ADS however still no pokey sound. There is probably something im doing wrong as it's not the first time i have had missing files issues with MAME in this case (a7800).

Thanks Mike yeah you're correct i wasn't expecting to hear it's actually working. Very strange that it works with a7800 when not bankswitching yet doesn't when using bankswitching. Hopefully this issue gets rectified on a later update of a7800 down the line. I will try the XM pluggin and see how things go or just drop pokey all together for that project. Im guessing MAME never supported pokey with bankswitching (supergames). Cheers for having a look, much appreciated 👍

Ok so an update, pokey whilst bankswitching still has me stumped. I have even created a program that's stripped of everything other then sounds alone to see what's going on. Still no dice, yet works fine when not bankswitching, anyway if the offer to have a look is still on the table that would be great 👍 Sounds.7z

That's awesome artwork, loving the unique styling 👍

Anyway as for difficulty it's fine after getting some practice IMO, although the start is very hard for a novice. Not sure of your plans and just a suggestion maybe there could be a tutorial level at the beginning or home base screen that's super easy. Other then that it's not really a big deal after getting the feel for it.

Looks sweet as mate, can't wait to give this one a whirl. Attention to detail is on point 👍

Thanks, i may very well end up taking that offer. I will give myself a day or so as it's good learning practice 👍

It's probably something im doing wrong however it works without bank switching. so i have been setting the kernel "set pokeysupport on" at the start of the program where i set the region and doublewidth ect. Then use psound 0,rpm,10,10 within the main loop and the variable rpm is what controls the frequency. I have tried moving the "set pokeysupport on" to the current bank in use that hasn't worked either. I have also made sure when initializing the kernel settings at the start of ROM that the ROM size is first to be declared. As for compiling there is no errors and does show pokeysound in the output log. See spoiler It all looks good for pokey as far as i know which leads me to think there is something going on in my code. The variable "rpm" seems to be working fine as it also controls other conditions that are working fine. I will keep plugging away and probably have a eureka moment lol

That done the trick and i could still keep includes 16x16 or less in the last bank. Only downside is the loss of ROM space, it's really chewed out a chunk of space leaving very little remaining. All good though atleast i know what's going on now, cheers for the help guys 👍 Edit: Also i have noticed pokeysupport is not setting with bankswitching, there could be something im missing though

Thanks Mike, your assumption is correct the 'incgraphic' sprites are all in the last bank (persistent). Changing the ROM size made no change either so im yet to try including before ploting the sprite. All the other sprites work fine it's just the tallsprites, im guessing tallsprite has this limitation when bankswitching (unless included within the bank). I will see how things go later today by throwing them in the same bank where plotspspite is called, cheers 👍

Thanks muddy, yeah no i wasn't using tallsprite previously and just gave it a whirl with no success on or off

Ok so a follow up i have changed one my programs over to bankswitching and everything works fine except for my large sprites. They seem to be cut in half when using bankswitching. They were fine before but now they only show the top half of the 32x32 sprites. Wondering if you guys might know why this is the case? I have read that sprites are limited to 32x16 so in order to make 32x32 you need to use two sprites. What im not understanding is why the program will display 32x32 when not bankswitching.

Thanks for the link, helps with a further understanding to the online manual

Brilliant, had a feeling that was the case, yeah just making sure i have a full understanding of all the possible options. Exactly what i was thinking and im sure that extra RAM would come in handy with certain applications, however for the moment im happy to play around with console RAM 👍

Thanks guys that summed it up, makes alot more sense now. Great to know i could use 512k if really wanting too or opt out for 144k with two persistent banks for the sacrifice of extra RAM. That means i can use the 1,535 of extra RAM at the $2200 - $2735 address locations without any dramas when using 144k ROM size? Im assuming it only effects the additional cart RAM.

Hi guys some novice questions about bankswitching and ROM sizes. Was having a dig around for more information however haven't found what im after as of yet (i think anyway). ROM sizes: So from what im understanding 128k was the limit until needing extra hardware and 48k was the limit without bankswitching. Also what is the advantages other then extra ROM for 144k over 128k? Is it just a better idea to go for the extra ROM at 144k? Bankswitching: Why is the limit of each bank reduced to 16k rather then 48k or 32k as that's the largest ROM size that doesn't need bankswitching? Also when it comes to bankswitching i read you don't need the incgraphic in the current bank to plot the sprite or maptiles? For some reason when i try this it displays a blank screen yet if i duplicate the incgraphic everything works fine.

batari Basic is what got my feet wet with programing and without it i probably wouldn't have been able to complete my life long dream of creating a 2600 game (well several now). Maybe i would have kept trying with assembler however the basic language just sits well with me and is a comfortable environment. Now with learning 7800basic and having all these resources im kind of overwhelmed with the possibilities. Thanks to everyone that puts in the hardyards maintaining these languages for us. Both bB and 7800basic are perfect for my needs and much appreciated 👍

Yeah i talked the wife into playing the game with me lol. Both ideas sound great to me, wrapping tunnels adds an extra element of strategy to the game. Pinball like bumpers will realy make the player feel helpless for that brief moment raising their anxiety about taking another hit. Personally i was thinking and im not sure what resources you have left or would like to go the route. However fuel/energy tanks for the thrusters where each player has their own tank of fuel. Maybe even random refill spawns to mix it up, as it could make for some interesting defensive play strategies. So the player that conserves fuel playing defensive could take the win so to speak. Rather then running out of fuel completely the aggressors thrusters become weaker on low fuel allowing them to salvage more fuel from a near-by spawn. Just a suggestion i thought you may like

Im a bit slow to the party (parenting can be hectic) anyway got the chance to give this game a whirl. As many have been saying i too really liking the mechanics you have going here. Takes a bit of practice although not hard to get the feel for it. I would like to leave feedback however can't find anything nick pick about so it's looking good in my eyes 👍

7800 Commando was another solid release and superior to the NES port IMO, very fun game

I always knew the system was impressive for it's time and the more i have been messing around with the 7800 programming side of things im realizing how incredible it really is. If there was no NES and the system came out when first anticipated, along with the pokey chip integrated within the system it would have been the goto console. As for software the retail releases were great however the system had so much more potential that was never unlocked. The CPU is fast and Maria is more then capable of anything the NES could do. ATM the pro system is continuously putting a smile on my face

I have tested your demos but refraining myself from going into them too deep. Im waiting for the finished product so i can really sit myself down and play it through (no rush or anything). Im like that with RPG's as i don't want the full experience of discovery spoiled when i play through. Really excited about this game 👍 TBH it's great you still have motivation to see it through, personally i struggle with my games as we're in reality, a small community so it can be hard to judge interest or desire. I find most interest and feedback comes when the game is fresh off the hotplate, then it becomes hard to judge if anyone is still interested in the fine tuning stages. Looking forward to playing this game through, and hopefully there will be a digital release. Im hoping the Downloads module will be up and running when it's completed. Al has said he is working on it and people can buy digital copies rather then cart releases if they choose. This really works for myself as i haven't original hardware anymore and use emulation for my needs. So we miss out on many great games that are cart only releases

Yeah it needs to be in the mainloop with DPC+. The only reason i could think is the value is stored as a temp variable that gets obliterated after the drawscreen function is called (unlike most TIA registers)

Thanks for sharing Matt, i was asking about something like this on discord the other night. So this example will really help to create boundaries for the playfield maps. I think i understand most of it, just need to work out the parts im not 100% sure about. 👍