Does Harmony support the 3E+ Bankswitching?

[Does Harmony support the 3E+ Bankswitching?]

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+).

 

 

[Harmony cart can’t run CHESS...]

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

 

 

 

[Wizadry on the Woodgrain - Tiki]

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!

[Congo Bongo?]

24 minutes ago, Bomberman94 said:

MANY thanks for a PAL60 version and the update! Must I change the extension „.e7“ or does it work with my Harmony cartridge as is?

 

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!

[Congo Bongo?]

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

[ChronoScroller]

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).

[Atari Age Homebrew Roms?]

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

[ChronoScroller]

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.

[Reverse bit-generation in C at compile-time]

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)

[Software maze wall detection]

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.

[Playfield lines vs object lines]

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

[Homebrew C64 VIC FGPA - parallels to ARM assist]

On 2/7/2021 at 12:28 PM, bcombee said:

If I were making a TIA replacement with FPGA, I'd want it to still feel like the TIA... here's some ideas:

 

1. automatic playfield mode - you could preload left/right playfield bitmaps and colors for each scanline, perhaps using per-pixel color and a higher resolution.  The FPGTIA would automatically replay the playfield on playfield on later screen refreshes, freeing up the 6502 to focus on the players and balls.  I could see this using a page flipping mechanism too so you could load one playfield while not disturbing the display of the current one.
2. player positioning via X register write - instead of having to time in a scanline when to write to HMOVE, you could just directly modify the position register
3. expand to full 256 colors that GITA supports by adding 1 more bit of luminance

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

[Congo Bongo?]

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

[Congo Bongo?]

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.

[Congo Bongo?]

1 hour ago, 7800Knight said:

I'm not exactly a techie here.  But I do want to know something.

 

The Atari 2600 could NOT pull off a three-quarter isometric view and Congo Bongo firmly proved that.  Given the limitations of the hardware, how can one work with that?

 

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

[Atari 2600 Centipede Hack/Hombrew?]

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 exact speed of the TIA]

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.

[New Batari one-line sprite Kernel / demo]

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

[Atari 8-Bit/5200 Homebrew Completed/WIP in 2021]

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. 

[Hellway, an Atari 2600 homebrew with love]

1 hour ago, Karl G said:

I do agree with @splendidnut's thoughts ...

 

I believe you mean @Pat Brady's thoughts.  

[new homebrew: SISYPHUS]

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.

[Hellway, an Atari 2600 homebrew with love]

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

[Entombed and Towering Inferno story on the radio]

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?"

 

 

[not extra overscan cycles in DPC+, right?]

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.

[not extra overscan cycles in DPC+, right?]

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.