RevEng

I'd skip the screw entirely, so you can still get in without messing up the label. Like Mitch said, the CC2 doesn't bother with a screw under the label. In my experience the CC2 shell stays solidly together during normal usage; I've never once had it accidentally pop open. The only thing the screw likely helps with is a dropping the cart from a few feet onto a hard surface. If you want to trial it, remove the screw and put it somewhere for safe keeping, and continue to use the cart. When you're satisfied it works well, apply the label.

The interrupts (top screen, bottom screen, and user interrupt) should really be kept as simple as possible... I should underscore that in the manual. The problem with a bunch of complex code with 7800basic statements is they're likely to modify temp variables, which is problematic. Your gosub likely uses a temp variable here. I think psound might be ok for temps, so you might get away with that, if you avoid the gosub.

The Concerto Brotherhood is very selective. For those of you hitting refresh over and over again, here are some suggestions: Think only pure and worthy thoughts. The Brotherhood is listening. Focus your chi into your 7800. Go full Miyagi on that thing. Sacrifice a copy of 7800 Karateka to the 8-bit gods. Ball peen hammer works best. (If you burn it you won't hear the end of complaints about the smoke from your family. Trust me) Deleting a Karateka rom doesn't count for anything, because we've all done that before. Good luck!

The palette registers are write-only, so you can't pull info from them. You'll either need to cheat and use a debugger to peer at the memory locations those registers are at, or save the values you're about to stick in the palette registers right as you set them, and then dump the variables using plotvalue. [edit] one more handy tip. In a7800 you can advance frame by frame by hitting SHIFT+p over and over again.

Ah, I see. When I get a sec I'll see if that size= stuff can be changed. It dates back to before dasm was good with rom shifting around, but I don't think we need to do it that way anymore.

Sure, I took a quick look and it looks like you made the new features assemle-time conditional, which works for me. 👍

The pattern for a doubled quick score would be... scoreText5 = (scoreVar2&$0F)*2 scoreText4 = (scoreVar2/16)*2 (Repeat that for all of the score characters. I used both "/16" and "*2" instead of just "/8" to clear out the bottom bit.) alphachars and other character functions don't care if the graphics came in with one big chunk, or a bunch of discrete imports.

Well that's the last time I use selfies for a utility!

If you're using double buffering still, that might be the problem. (it's not designed for it) Otherwise, it should work with any screen height, but it's not really officially supported, so not deeply tested with all of the options. If it's not working for you, without double buffering, let me know.

The manufacturer for ultrahdmi is retroactive. Try hitting up the email listed under "contact", and ask if you can get the jtag version of the firmware.

I'd love to hear the details of this unexpected mirroring, and if it's been seen on more than one PAL console. It would be good to know what locations we should be avoiding, with other projects.

Yeah, it would use a lot of time done that way, but these sorts of animations don't generally need to happen every frame, so you just do one or two rows in any given frame. Millie&Molly does that to animate the monsters, and Arkanoid does it to animate metal bricks. Even if you go back to characters for the dots, I'd still recommend splitting the updates up over frames, since iterating over X times Y things is expensive. I do the same in Salvo for when you lose all of the humanoids and the grid disappears. On cycles... Counting how many cycles the 7800 has is a bit less cut and dried than on the 2600. Typically the 7800 has a buttload more cycles than the 2600 because your game logic can run during the visible screen on the 7800, but on the 2600 the 6502 is completely tied up with the display kernel. The exact number depends on how much time Maria is stealing away from the 6502 - i.e. how complex your display is, from top to bottom. To give you ballpark numbers, without taking Maria DMA into account, 7800basic has about 22000 cycles available during the visible screen, and about 8000 cycles outside the visible display during which plot* commands can execute. Even if you lose half of those cycles to Maria DMA (which would be a fairly complex display, top to bottom) that still leaves you with 11000 cycles per frame of game logic, apart from plot* commands. bB runs in overscan, and depending on the kernel gives you about 2398 (DPC+) to 2710 (standard) cycles. So I think ballparking 4x logic time in 7800basic vs bB is a fair starting point. Since the game logic runs during the visible screen, you can get a better idea of how much time any particular routine consumes, by changing the background color before and after the routine. You'll see on the screen exactly how much of the visible screen time is being used by the routine. For sure. Experimenting with a given approach, and throwing as many game elements at it as you need, is highly recommended. Then check it out in a DMA accurate emulator and/or real hardware.

Clearing and redrawing will be too slow. Check out the under the hood demo, which has easy'ish assembly routines to update the Nth plotted sprite in any given zone.

There's no hard and fast rule here, but rather some finer grained rules you need to consider for a given game design. If your character graphics didn't change palettes so very frequently, they'd win out over sprites-as-tiles. Character objects have a higher up-front cost, but due to the dynamic nature of character strings, one single character object can manage a bunch of dynamic graphics. To do the same dynamic thing with sprites-as-tiles requires a bunch of sprite objects, and while sprite objects are cheaper than character objects, replacing one character object with a bunch of sprite objects will be a loss. So much of this depends on the game design. Arkanoid and Millie&Molly require arbitrary palettes on any object in the game "grid" of objects, so using sprites is a no brainer there. I think the same is probably true here, but it's your call on how attached you are to the alternating palettes. The problem is that you have more than 256 characters in collisionMap. temp5 is only a byte (0-255) and array lookups are limited to 256 bytes max. It's an efficiency thing. But you can use peekchar with your collisionMap array if you like. Matt has an example of that in his 7800basic tips, tricks, and examples thread.

Oh, I thought you were talking about the flickering due to indexes hitting empty sprites. I see what you mean now. Basically Maria is running out of DMA time to render all of your objects. Here's your third level... In any given zone here, the palette requirement is changing every couple of graphics bytes. This means in that middle row you have 14 character objects. (a new palette means a new character object) You can do one of two things about this. You can redesign the levels to not alternate palettes, which I think would be a shame for this game. Or you can write a level loading routine to draw those 14 objects as sprites instead of characters, since sprites use less DMA compared to similarly wide character objects. This is the approach @mksmith took for Arkanoid and Millie&Molly. To keep the bouncing dots, you'd either need to take a hybrid approach - i.e. still use characters for the background with a single palette, and draw walls with sprites (which could lead to dma problems when you turn up the number of enemies, or make levels even more complex) - or you'd need to bounce the dot sprites using under the hood functionality.

It was the plotsprite tuning. One of the changes I introduced in the code broke prosystem. Between a choice of better performance vs. keeping an outdated and incomplete emulator happy, I picked better performance.

The issue of the sprites disappearing for a frame is related to your frame index, which alternates between 0 and 2, and you have 2 enemy (tallsprite) frames. With the changes in the last version of 7800basic, you should access these 2 frames with a frame parameter of 0 and 1. I switched back to the old behavior with the setting "set deprecated frameheight" at the top of the source, and the blinking is gone.

Yeah, you can't rely on the temp# variables being unused by the routines. Certain double buffer operations do indeed use the temp variables. The 7800 has enough memory that it's really not worth playing the bB game of trying to anticipate when temp variables are used or not by certain commands, and later discovering that you've unknowingly shot yourself in the foot. Just dim a few of your own temps, and run with those. It would be easier if you were able to post a specific example, because your program really shouldn't be flickering if you have doublebuffering on and have enough zone memory. I can imagine a bunch of things you might do wrong that could corrupt the display and/or flicker sprites (using temps in an interrupt, using plotchar beyond the buffer memory, ...) but it will be quicker to just look at what's going on rather than guessing.

If you have too many objects being plotted into a zone, then it can overrun the memory for that zone and corrupt the next one. It sounds to me like that's what you're describing. You can see how many display objects you have per zone in the 7800basic compile messages. It will look something like "$1880 to $1fff used as zone memory, allowing 13 display objects per zone." As to whether double-buffer will help or not. If you're getting flickering of some sprites, due to them not being plotted within a single frame, then yes. If the cause of your issue is running out of zone memory, then no. For the latter you'll need to look at giving more memory to the display, with either "set extradlmemory on" or "set dlmemory [start] [end]".

That turned out pretty well! If you're cool with it, I'll include it in the 7800basic sample graphics. There are some minor issues with chroma artifacting and the lowercase m and w letters, and maybe the ends of the uppercase K... ...the colors are more muted in photo than in real life. This 320 mode artifacting with be seen with composite/rf output, and won't be present with emulation or s-video output mods. Normally you can diminish artifacting by doubling up pixels, which may work for the K ends. That's not possible for the m and w, so I think you might want to minimize the length of the middle line. Presently the w has a shorter line than the m, and as a result w is less distracting. All of this is fine tuning suggestion, and I'm not taking away from your great job here. 👍 Here's a quick little "font check" program I threw together, which I think is handy to check for any potential issues when designing fonts. fontcheck.bas fontcheck.bas.a78 fontcheck.bas.bin

There's no auto-incrementing label names or values. I think the only way you can manage this with names is dynamic labels, and for values by using SET with whatever incrementing you need. I'm not sure exactly what you mean by arbitrary, since you can name dynamic labels as you like. Here's a example of creating a series of incrementing dynamic labels, which take on different values. I took this from the 7800basic zonememory.asm file and simplified a bit. (for the sake of having a clear example not cluttered up by various 7800basic memory allocation options) DLINDEX SET 0 REPEAT WZONECOUNT TMPMEMADDRESS SET (((DLINDEX*WMEMSIZE)/WZONECOUNT)+WDLMEMSTART) ; create symbols in the form "ZONE#ADDRESS" that point to the memory for each zone ZONE,DLINDEX,"ADDRESS" = TMPMEMADDRESS DLINDEX SET DLINDEX + 1 REPEND

To hopefully help more people get into the Christmas spirit in a 7800 kind of way, "Christmas Salvo" has been attached to the first post in this thread. Now flash cart and emulator players can also blow away robots as old St. Nick. 🎄🎅🎄👾🎄 Best of the season to all of you, and your families!

Ok, cool. Functionally that's the same thing I'm doing, so we're on the same page. If you have a multimeter handy, you might check if there's any resistance between pin 6 (fire) and 8 (gnd), when the fire button is pressed. I think I'd also look for any weird connection via pin 6 (fire) and the paddle/two-button lines 5 and 9.

I guess the germane question is what method are you using for auto-detecting the sticks? In my case, I go ahead and just setup two-button mode, and downgrade to single-button mode if INPT4/5 ever signals a single-button press. It sounds like you're doing something different.