Does Harmony support the 3E+ Bankswitching?

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

 

 

[+Andrew Davie]

Looks like CDFJ is the best solution.

[+batari]

3E+ is not yet supported. Note that when I am able to implement this, it will be Harmony Encore only.

[+splendidnut]

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. 

[+batari]

  

1 minute ago, splendidnut said:

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. 

For now, sure.

However, I am working on a bankswitch method that essentially opens up the entire 6502 usable memory space as 32k RAM or ROM and bankswitching becomes (essentially) transparent to the programmer.

 

In a sense, DPC+ and CDFJ's power for making kernels can be matched by simply having a ton of RAM.

[+SpiceWare]

18 hours ago, splendidnut said:

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. 

 

That's correct, for DPC+ use of ARM code is optional, for CDFJ it is required. Doing that simplified CDFJ's driver code, which helped to free up more ROM and RAM for the game to use.

[+batari]

In case anyone didn't see it, I posted the new bankswitch method here:

 

 

Of course, for ARM fans, work will proceed on bus stuffing as well.

 

On that note, upon further examination of 3E+ and of Harmony Encore hardware, in order for this scheme to work, the short answer is that some form of bus stuffing has to be done. Because of this, 3E+ support is being put on the back burner. I would suggest taking a look at the new scheme I proposed above, though, as it can break out of some of the conventional limitations of cart RAM, and will be far easier to implement on Harmony Encore hardware.

[PAH]

On 3/5/2021 at 11:55 AM, batari said:

On that note, upon further examination of 3E+ and of Harmony Encore hardware, in order for this scheme to work, the short answer is that some form of bus stuffing has to be done. Because of this, 3E+ support is being put on the back burner. I would suggest taking a look at the new scheme I proposed above, though, as it can break out of some of the conventional limitations of cart RAM, and will be far easier to implement on Harmony Encore hardware.

@batari I assume 3e+ needed bus stuffing because Stella's implementation had a custom peek function in the past.  It no longer does.  Does that mean that Harmony Encore could now support 3E+ without bus stuffing?  If so, any chance 3E+ will be supported?  Thanks.