splendidnut

I don't have a working build at the moment. Lol. You can try playing around with the colors using the version from this post: Colors will look weird on PAL60 since it's using the NTSC-based color selections. But it should work. I played around with it real quick in Stella. If you set the colors to 35, E7, DC, 4C, that should provide a decent starting point.

Sorry, no actual updates on this. I've been playing around with different bank-switching schemes, but that's about it. I've also thought about the PAL color issue. I think the green background is pulling the orange cliff more towards being a yellow color. So, I'll probably play around with switching the colors to just browns and blues for PAL. I will admit that I did get distracted going down another rabbit hole: But that might actually help pull this project along, since they'll both need the same or very similar game logic.

Here's a link to Eckhard Stolberg's ATARI 2600 VCS SOUND FREQUENCY AND WAVEFORM GUIDE, stored in Andrew Davie's new Atari 2600 Technical Tiki: http://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=Sound-Frequency-and-Waveform-Guide

Ultimately, my goal is to make this into a full game, with a sub-goal of trying to do this in parallel with the 2600 version I'm working on. So far, this one (7800) version has stolen my attention. I have a few other projects in the works that I'll be juggling around (to keep things interesting). So, no promises, but we'll see where this goes. Anyways, here's an update with some of the movement code stolen from my 2600 version. It's not perfect nor complete, but it's fun to play around with. I've fixed Bongo's colors using the darker shades in the $3x hue range, as that provides the best contrast/color appearance both in an emulator and on a CRT. Let me know what you think. Enjoy. congo-(20210313).a78

Thanks. Congo Bongo is one my favorites. I was a bit surprised with how well the background graphics scaled down to 160 horizontal pixels. My backup plan was to try and figure out how to wrangle one of the 320 pixel modes, but after seeing the results of this, I decided it was completely unnecessary. As for reuse in games like Zaxxon, it's a mixed bag. Currently, this engine doesn't support any form of scrolling. But I'm trying to keep the display list generator code as a separate module, so it could be shared/re-used in other projects. Scrolling on the 7800 is something I'm interested in doing, but I wanted to get a basic single screen engine going first. For this, I might not add scrolling due to the amount of tiles the first level uses (90-95% of a graphics 'bank' is used for the character-set tiles). Maybe, at some point when this is more in a "game" demo state. Indeed. That's my current goal, keeping the background 160A. I'm definitely happy with how the background turned out. As for sprites, I have a feeling the most will end up 160B. But I'm going to try and keep some at 160A (the monkeys). We'll see how things go. I've seen a few mockups floating around by @Defender_2600, which inspired me to look into this on the 7800.

Nope... no account necessary. You just need to go to https://www.twitch.tv/zeropagehomebrew

Trying putting double quotes around the file path/names. "kernel.asm" instead of kernel.asm "..\..\projects\demo.asm" instead of ..\..\projects\demo.asm

I thought it was established that, for Circus Convoy, it IS a Truck Convoy.... hence, it would be on the highway. Truck convoys (semi-trucks toeing multiple trailers, or flatbeds) are rare, but they do exist.

Fixed Bongo and added more sprites. Bongo and the explorer guy are 160B, and the monkeys are 160A. I changed the background color because the red was starting to bother me.... Redrum... lol Bongo seems a bit "pinkish" in emulators, but appears to me to be orange/red-ish on real hardware (NTSC CRT TV) Enjoy. congo_demo-(20210308).a78

Yup. My UnoCart is currently at v17.... and I'd like to try out this common firmware on it. But I don't have a ST-link programmer, so my only option would be to Load/Flash from the SD card.

Any chance of getting a load-from-SD version of the firmware for the UnoCart?

Screenshot added to first post.

My advice to @bogax It really sounds to me like you should just jump over the cliff and fully use assembly language. Especially since you are asking for an IF CARRY construct.

Well, you are abstracting away cycle counting. Stop doing that! Lol.

I have no horse in this race. I'm just going along with the idea that some users are asking for a different abstraction to access extra "RAM". Yes, at the end of the day, DPC+ ram access mainly works best/fastest when treated like a queue/stack. And that's probably the best abstraction to use for accessing it. But, it's always nice to have other abstractions available too. The whole point of using any language other than Assembly language is for the abstractions they provide. Addendum: I'm mainly here, because I enjoy these kinds of discussions.

So this DPC+ thing would be "somewhat" reasonable then? You could require the user to prefix the DPC+ variable access with "DPC->" or something similar.

I wrote about it here (no public release yet): Still needs quite a bit of working... but it's actually, somewhat usable.

Actually, you can take advantage of the same var being read/modified/written to. So it could be done like this: LDX #memIndex STX DF0LOW LDA DF0DATA clc adc #3 STA DFOPUSH Granted, for more complicated expressions, it would have to be as you wrote. Always a good question to ask. The language is called Basic. All depends on how "basic" you want to make the language for the users.

Hmmmm.... At some point, I should dust off the C cross-compiler I was writing, and getting that ready for public consumption.

For DPC+, if you limited it to 256 extra vars (page aligned), then for 8-bit vars, the assembly becomes: ;-- setup to read extra variables (only need to do once after end of kernel) LDA #extraVarPage ;-- which 256-byte page to use in DPC+ memory STA DF0HI ;---- then for writing a variable: (value to write in Accumlator) LDX #varIndex STX DF0LOW STA DFOWRITE ;--- OR for reading to a variable (value read into Accumlator) LDX #varIndex STX DF0LOW LDA DF0DATA EDIT: mixed my reads/writes.... ugh

Currently, the easiest way to access/use DPC+ Memory is using a Stack like system (that's just how it's designed)... but it can also be accessed like RAM. I kinda do this in ChaoticGrill. It just requires that the Data Fetcher be set before every memory access. DPC+ Memory access could easily be made easier without the need for complicated ARM programming. Essentially batariBasic would just need to be modified to "hide" that the memory is not as easily accessible as regular zeropage memory. Same with SuperChip RAM, CBS+ RAM, E7 RAM... etc. A new bank-switching scheme COULD (or a new varient of DPC+) be developed that gave a "window" into extra RAM, BUT that would require one of the SD Cart developers to implement it. OR support could be added to batariBasic to support one of the other bankswitching schemes... it just takes time/willingness of someone to do it. Granted... I have limited knowledge of batariBasic, but I believe these things are possible.

Wow, those screenshots look great!

Hey all, Here is an early attempt at a graphics engine for Congo Bongo. I've worked on this mainly over this past week. This morning I finally added the ability to have a movable sprite (Bongo himself), so I figured it would be good time to show off. For the engine itself, currently it's using the 160A graphics mode. The cliff-side is using Indirect (Charactor) Mode. The water, the trees, the bridge, and the skull are applied as "decal" sprites over top of that. And then Bongo is added at the end. To generate the graphics, I'm using an artwork processing tool that I've developed. The tool let's me easily convert image files I've cut/copy/pasted from an arcade screenshot. It currently generates a tileset/tilemap usable with this style engine. So far, it only generates 160A graphics, but I'd like to eventually get it working for ALL the graphics modes. 160B is next on the table... which is needed to improve the appearance of Bongo. The background is static (no animated water yet), but Bongo is movable with the joystick (NOTE: it's just quick and dirty movement code). Enjoy. congo.a78 Edit: Screenshot for those who asked:

To the best of my knowledge, CDFJ wasn't designed to be used without ARM code. I'm not really interested in writing ARM code. So for my case, DPC+ would be the best option. I was "trying" to avoid it, but it seems to be the best way to avoid bank-switching hell.

I'm open to any suggestions for the colors... especially for the PAL-side of things, since I only have the Stella emulator palette to check those against.