splendidnut

For Champ Games, the game logic programmed in C code running on the ARM chip. That runs during VBlank/Overscan while the 6507 runs NOPs (or some form of idle loop). During the display kernel, the 6507 is then used to run the display code which is fed to it via the ARM chip. That allows LDA #immediate instructions to be used in place of the longer load instructions, thus allowing more TIA registers to be changed per scanline than usual. Currently, I believe there is no way to harness that power via bBasic. You'd have to program in 6507 assembly (for the display kernel) and C and use the ARM compiler/toolset. Ask Spiceware about it, or check out: OR, you can just program in 6507 assembly and use the DPC+ as an advance bankswitching scheme like I did for ChaoticGrill.

Thanks! It shouldn't be too hard to get this working (famous last words).... Overall I'm quite happy with how this turned out for something that was started spur of the moment. I've been very tempted to try and do this as a cross-platform project... but I need to get this to a point where the graphics engine is in a "similar working state" as Paint The City was when I first posted that.

Thanks James! After all the color tweaking I've done, I usually come back to defaults. There are some fun color tweaks and combos that be found... but what I have now seems to work best for a jungle. I'll probably bump up the brightness on the background colors a bit (they're a bit too dark on some hardware variants). But, for the other colors, I'm quite satisfied. I think the bright blue and orange combine quite nicely for the light sand color. I might provide some actual "palette" selection for the game itself to compensate for people's preference and system color differences. I definitely like Variant 2 best for Stage 2... although I might change the upper right area to use the sandy color since that hints nicely at the next stage, Rhino Ridge. I'll probably go thru and add a bit more playfield details to the stages... since the backgrounds of Stage 1 and 2 are a bit plain compared to some of the background details seen in stages 3 and 4.

Here's a link with the scanline counts for a bunch of games: http://www.digitpress.com/library/techdocs/vcs_scanlines.htm

Using Stella, I checked the Gorf ROM and it appears to only use 260 scanlines instead of the usual 262... so your RetroTink might not like that.

It should run... it uses the same bankswitching scheme as M-Network's Burgertime. Maybe the Harmony Encore isn't detecting the bankswitching scheme properly. After unzipping, you could try renaming the file extension from .bin to .e7 and see if that helps.

And here's one with all the stages: congo_poc-(20210119).bin Same as before with the joystick controls for changing the colors around. Select switch can be used to move thru the different stages: Stage 1 -- Primate Peak Stage 2 (2 variants) -- Snake Lake variant 1 -> light-colored ground variant 2 -> dark-colored ground Stage 3 -- Rhino Ridge Stage 4 -- Lazy Lagoon NOTE: If you have issues running it, try changing the file name from .bin to .e7

I don't believe it's ETIM's mod that's flaking out... it's either your RetroTink Pro or your LG CX OLED that doesn't like the off-spec VSYNC signal generated by the original Asteroids ROM.

The ball object uses the same color as the Playfield. A bit of a non-starter, but it could potentially be used to animate the water; though, I'm not sure how much of a burden that would be. I'd want to get a simple version of the sprites in there before attempting to do that. If you're referring to the missiles (which I think you are), they could be used to add the water. BUT, they each share their color with their respective player object (i.e. Player0/Missile0 share a color, as do Player1/Missile1) so that wouldn't work too well once sprites are added in (i.e. color conflicts/contrast issues). And I already have plans for potentially using the missiles to handle the falling coconuts and/or adding shadows on the ground for the coconuts. With all that said... the very next stage (Level 2) has a lot of water in it (snapshot uses colors: D5, 87, AC, 3A): So I need to take that into consideration Thanks for the suggestions. Glad you like it.

Don't you just love/hate when that happens

Could you please add the list of nominated entrees in each category to a separate post (or original post) in each of the voting threads? After voting, it would be nice to still -easily- see what games were in that category.

Some Tools:

Alright... last one for the day. I've added the ability to change the colors with the joystick. There are 4 colors in the palette, 2 background and 2 foreground, numbered 0..3. The left most set of digits is the currently selected palette index. The right most set of digits is the current color value. Joystick controls are: Left/Right changes hue. Up/Down changes brightness. Fire button selects next palette index. Right difficulty switch controls whether primitive color blurring is enabled... it's flawed, and I'm not sure if it's really necessary. But it's there to try out. I've chosen a better set of colors for the defaults. Enjoy. congo_poc.bin

@SpiceWare Thanks for the nudge. It was in the back of my mind to attempt that... but I thought mid-line color changes would be the ticket, but that was a bit of a pain. Doing 4 colors seems to work somewhat well... Will need to tweak them though -- currently the blue I used appears a bit garish on a real CRT. It's probably going to be a bit of a trial and error to find the right colors. ROM: congo_poc.bin

Welp... ended up going down the rabbit hole with this. I started looking thru my "in-progress" disassembly of Congo Bongo, starting the debate of whether to do a hack of the original 2600 game or start from scratch. While I do enjoy the 2600 version, and it would be relatively easy to do some hacking and cleanup on that, it doesn't quite have the flexibility to easily add levels. So I would probably start from scratch, and lean more towards looking like the arcade. So, I ended up doing a "quick" mockup of Level 1 to show what it could look like: Adding water to the scene would take a bit of figuring out, but probably some form of mid-screen color changes I think the other levels could easily be drawn in a similar fashion. And then they would all be using the same display engine, unlike the original 2600 version. ROM: congo_poc.bin

I agree with you. Yeah, they could have done something better with the buttons. But: * A remote control would have added to the cost. Probably not much... but they were probably trying to hit a specific price point without sacrificing a "cool" feature like the ability to use real carts. * Adding buttons on the controller would have required a different connector/interface, breaking compatibility with original hardware/controllers. At the end of the day, you're paying for a piece of hardware that's meant to let you enjoy the common games from the 2600 era on your modern TV... albeit with some odd inconveniences caused by the disconnect between old ways and new ways of gaming. Personally, I prefer the original hardware... but I also have CRTs lying around and an older LCD TV which works well with the original system. Using Stella on a Mac/PC also works well and is probably the more convenient way to play for some/most people. Would I ever buy a Retron 77? Probably not... mainly because I'm a developer and spend most my time using Stella on a PC or Mac, to play and develop.

You're paying for the hardware... Last I checked, hardware isn't free

Oh boy, the categories have just about doubled! We're in for a long show.

This probably should be posted in the BBasic sub-forum. But I can give an answer for the last question: You only have 6 code banks available in DPC+ (24k). The other 8k is used as follows: 4k is used for the Display Data RAM. 3k is used by the DPC bankswitching driver. 1k is used for music frequencies/only accessible via ARM code.

Ok, so it was a stupid mistake on my part. The sound/music engine is a modified version copied from ChaoticGrill. So the right difficulty switch turns the music on/off. BUT, with this, the game starting sequence is completely based on detecting the countdown tune finishing. So, if the music is off when this game is started, the game won't start until you turn on the music. Oooops. So, I've switched to using a regular timer for the start sequence... and I've removed the music on/off switch. Here's the fixed version: PaintTheCity-(early_demo)-(20210104).bin

I sent Fred my CPU that was found to be having issues with the Concerto (menu working, but games not loading at all). Hopefully it will help him figure out some of these issues.

Ok, it appears something is wonky in the music engine. Currently the code is dependent on that working completely working for the game to start. I switched to starting the game in running mode, and things work now, but no music. I'm going to try and fix that and post another build, hopefully soon.

Thanks for testing! With your results, I'm definitely leaning more toward there being a general issue with my code.

Potentially. It's one of the ones I'm interested in doing at some point. No promises though.

Just tried it on my Atari 7800 (early NTSC model), and I get the same results as Al_Nafuur... so there must be a stray read/write or some odd-ball initialization issue with the game state machine. Very odd that it runs fine on a 2600, but not on a 7800. I'll have to dig further.