Darkhog

Basically if I ever get into making a 7800 game and wanted it to be physical, I need one flashcart that's cheap, supports 7800 and has pokey emulation (I'd rather not have to scrape off Pokey from existing games as I don't want to destroy anything).

Attaching the result file containing mapping of the extra variables ($2200-$27FF). Could be pasted into 7800basic.h right after definitions for var0-99. Would love to see my contribution realized in future release of 7800basic. 7800_extravars.h

On such a limited system 128 extra bytes to store stuff in is actually pretty great for bigger games, but I don't know if it is possible to use with DPC+ kernel? I mean, I know there's DPC+ stack, but bb still lacks any reasonable way of turning the stack into just extra variables (and before you bring up certain thread that is linked from the bb docs, no that's not reasonable. Reasonable would be if you could just dim stack bytes like regular variables).

The advantage of this approach is on the programmer's side. Since to 2600 it would be technically just two regular joysticks, you could use the regular code to handle it, no special ASM required. Right joystick's direction inputs become the A/B/X/Y buttons, left joystick becomes the d-pad and the fire buttons act as L/R buttons.

Yeah, I'm looking at that code but don't understand it at all, lol.

Ok, I've found that by doing it like this: z = __leveldata0[gamelevelpointer] DF4FRACINC = 0 pfcolors: z end I can get my code to at least compile - but the color is all wrong and it doesn't read from the variable at all (seems like it's using the address the variable is stored at as color instead of the value of it)!

I know it's not Linux, but mac, but on Linux when I got this kind of error it usually meant that the file didn't have the execution privilege set. Tried doing chmod +x on it?

Not talking about connecting a genesis pad, but more of a crazy idea that I unfortunately have no skills or tools to pull out myself. It would connect to BOTH left and right joystick ports (meaning it would be only suitable for single player games), the left joystick's, well, joystick would be mapped to a dpad, while the right joystick would have its direction mapped to 4 buttons (let's call them a, b, x, y) in a standard configuration, while fire buttons of either would be mapped to L/R on the pad. Overall, the entire contraption would be reminiscent of a SNES gamepad, only without start/select buttons and with two cables sticking out of it.

So in my game I was making on Kick (sorry for the rather abrupt end of stream by the way, power went out and only recently got it back) I had a title screen playfield that used pfcolors (using DPC+ kernel). That part works fine. However after switching to the game state (ended up making a finite state machine), I am using the COLUPF/COLUBK to quickly set the color for the entire playfield (want it to be a single color anyway) and those seem to not work with DPC+? //edit: Seems like I can't use DF4FRACINC = 0/pfcolors to do that either, since the color comes from the data array, not defined statically and it throws a syntax error when trying to compile with code like this: DF4FRACINC = 0 pfcolors: __leveldata0[gamelevelpointer] end

Live now, btw.

Yeah, but that requires working around that and what if the code in the separate file simply CAN'T be compiled on its own since it relies on aliases defined in main source or code from other modules? Anyway, since it seems that there's no such feature, I have opened an issue on github with my thoughts on how it could be implemented.

Follow in advance to not miss it! https://kick.com/ultimateperfection

Can't wait! BTW. Since I never used VSCode (more of an Atom guy), will it update automatically once the new version is out, or will I have to re-download it?

From what it seems, the OP wants to create a shop system, so he/she doesn't need to do it every frame. Having separation done this way every so often (not every frame) wouldn't be that bad and it would improve readability. Heck, 1s could be separated on one frame, 10s on the next and so on, and the player wouldn't even notice. Of course if it would to be done every frame, it would be bad for performance, but since it seems to be needed only every so often, readability of the code is more important.

Seems like it, thank you!