splendidnut

Finally, a place I can go to that will (or at least potentially) have all the bankswitching schemes. I usually end up running into at least two different versions of Kevin Horton's document when searching for that information. Thanks!

Should work as is. I used the ".e7" extension specifically for Harmony use. It is used to avoid issues with the cart-type auto detection failing to detect the bank-switching this uses. Enjoy!

You might also want to check out the Veronica project: https://blondihacks.com/veronica/

PAL version? Sure. I took a guess at the colors being I have no access to a PAL TV. Might as well provide an update. I've added jumping. It works relatively well, but ultimately gives the player a bit too much freedom to move thru the level. Currently only Stage 1 is enabled. I have most of the data necessary for the other stages, but need to handle sprite clipping (ducking into pits) and making the water a hazard. Enjoy. NTSC Version: congo_poc_NTSC_20210220.e7 PAL60 Version congo_poc_PAL60_20210220.e7

The 'unlocked' version does clean up the rockiness a bit... quite a bit actually. There's still a little bit, at the faster speeds, due to the rolling effect of the ChronoColor(TM).

If you took a bit of time and looked around the forums, you would stumble upon the following:

Works on my regular Harmony cart on a CRT TV (NTSC). Movement appears a bit rough though, kinda like it's scrolling over a rocky surface.

Interesting, though I wouldn't call that lazy code being as that seems a bit more work than writing a simple 'for' loop to do the job. ADDENDUM I just looked thru my projects and I wrote a tool to generate a file containing a table of reversed values for use in Paint The City. (25 lines)

Looks about right to me. You could swap out some of the branch logic and have a lookup table for which PF byte to use (y value used in the LDA PF0Ptr,y instructions). That would save cycle time and take about the same amount of space.

Instead of your current Scanline counter, have two counters: one for counting the playfield rows, and the other for counting scanlines within the playfield rows. Then change the end of your loop code (starting with LDX Scanline...) to something like: dec lineCnt ;5 [58] bpl VisibleScreen ;3 [60/61] lda #3 ;2 [62] sta lineCnt ;3 [65] dec pfLineCnt ;5 [70] bpl VisibleScreenAfterWSYNC ;3 [73] The only thing I didn't add was the "lda DataPF0,x".... if you can find some way to squeeze that in (get rid of the unnecessary? TAY and the need for INX near the beginning of the loop), that might work

Once those ideas are implemented, you've basically ended up with an ANTIC/GTIA combo.

Rant tomorrow? Maybe... I'll probably forget what I'm suppose to be ranting about. ANYWAYS... Food for the savages. Here's Stage 1 with the first attempt at player movement. Enjoy. congo_poc_move_around_stage_1.bin

Potentially. I was going to go off on a crazy rant about throwing in the towel on the project, and then put the icing on the joke cake by posting my latest updates on the POC. But I held back... maybe tomorrow.

Uh, I think I proved that it is possible... but maybe that's just my opinion?

Hmmm, mushrooms that look like mushrooms, and a screen border? Sounds like you are looking for the Atari 7800 version of Centipede. Or if you don't care about the border, the 5200 version. It would be a somewhat difficult task to do better looking mushrooms on the Atari 2600. The current version uses playfield pixels (4px wide) for them... which would have to be converted to sprites to gain resolution. And then you'd have too many sprites on a line. Lots of flicker It could potentially be done using a 32-char text kernel... but it would still be flickery, and would it really be worth the effort? You're really talking about a rewrite from scratch as opposed to a simple hack. It might be a fun project for someone to do. Activision games looked great because they really focused on what creative things they could do within the hardware constraints. They really designed the games for the hardware.