splendidnut

I'm currently playing around with 3E+ bankswitching with a project that uses 16K ROM and a single RAM bank (512 bytes). I have a regular Harmony cart and the project doesn't run on it. But it runs on the UnoCart, so I don't think anything is wrong with my project. Does the Harmony cart support 3E+ bankswitching? (It would be nice if it did. ) If not, it's not a big deal for me. I'll just switch my project to a different bankswitching scheme (probably to DPC+).

There's was some talk about this a while back, in the chess thread:

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.

The Atari 2600 main clock is 3.58 mhz which is fed to the TIA chip. The TIA chip divides this by 3 to provide the CPU clock running at 1.19mhz. 3.58 mhz is the frequency used by the NTSC color sub-carrier.

I may be mistaken, but I believe this was talked about on @ZeroPage Homebrew's show a few months back. https://www.youtube.com/watch?v=0XePsHLZDkM

I believe for Wonderboy to go on the list for this year, it requires that a download be provided and/or a video needs to be shown for this year. Last year's download/video doesn't count. The whole point of these threads is to encapsulate what happened WITHIN the year.

I believe you mean @Pat Brady's thoughts.

If you're not a subscriber, your editing abilities are limited. But you can always ask @Albert to give you edit rights for the post.

Interestingly enough, this doesn't run in Stella... but it runs just fine on real hardware. EDIT: Nevermind... I was in Developer mode... runs fine in Stella in Player mode

As posted/talked about here previously: And here: People just can't help but talk about the mysteries of Entombed over and over again. And if you dig into the archives, you can find the early days of those wondering "How did they generate those mazes?"

That's not to say that you can't do great things in bBasic using it's DPC+ scheme, as can be seen in some of the great DPC+ BBasic games like Tyre Trax, Unholy, etc.