BackBit cartridge on the Intellivision

[+-^CrossBow^-]

4 hours ago, cmadruga said:

Anyone tested Sorrow from Kai?

Curious about what happens when it tries to do flash save/load.

Pretty sure that all of the Kai released games are LTO only since the roms provided are encrypted to your LTOs unique ID number? So pretty sure some check is in place for that preventing the roms from working on anything else aside from the exact LTO they are programmed for.

 

I can confirm that Bad Apple is working with the latest FW and new bin2ecs converter. For those curious, the programs that use the ECS will end up being a single file that has a new .ecs extension on them so that backbit knows how to work with them.

[mr_me]

To clarify, only rom files using this style of bank switching need converting to the new .ecs file format.  The only ECS cartridge that uses bank switching is World Series, the other ECS cartridges e.g. Mind Strike, Scooby Doo, etc. should work as regular .rom or .bin files.  

[8bitwidgets.com]

1 hour ago, -^CrossBow^- said:

roms provided are encrypted to your LTOs

interesting that they could do that.  I wonder if a backbit could have something like this done for it @evietron?   I've never heard of a digital rom being encrypted to a multicart, but i respect the idea as to prevent rampant piracy.. but then again I also think most of us who know about and enjoy homebrew want to support devs for making games of theirs we like.. but regardless, everyone is different.  

 

I've emailed the developers of it to see if it will work with a backbit.  I don't know if it could be encrypted but maybe?   The price is reasonable.  17 Euro..  for a digital copy of a game like that.  However relying on LTO as the only digital means to distribute a game creates a pretty niche market.  they is talk of 300 LTO's sitting around waiting for a some configuration, but no promise as to when..  maybe spring..    i'm not holding my breath and i'm loving my backbit.. 

[+cmadruga]

Sorrow was not encrypted.

[+-^CrossBow^-]

33 minutes ago, cmadruga said:

Sorrow was not encrypted.

I stand corrected then. I know the others that I own were configured for my LTO as I had to provide my LTOs ID to get the rom and jus figured the same was done when Sorrow was offered as rom.

 

 

[8bitwidgets.com]

31 minutes ago, cmadruga said:

Sorrow was not encrypted.

that's good to know.  they did reply and said the backbit can't work with it yet, but i know ram is around the corner.  with that, i asked them to ping @evietron to convey what it would take for their games to work.  No idea if it's feasible, but I don't know enough about how permanent storage would work with an intellivision game and a multicart of any kind.  

[evietron]

12 hours ago, Caleb Garner said:

I don't know that game, but i would doubt it works at this time.  I know ram is being talked about for Chess and such.  I don't know how the rom was configured to work on the LTO..  does it know to write some chunk of data?  

 

I don't see any reason why it couldn't since it's still just SD storage which is persistent..  but i'm not sure how the rom would be written to claim some space on the sd card..  maybe this is some feature that comes with JLP?

 

@evietron do you know if there is a way to achieve this?  to have a game know how to write save data to a file on the SD card?   This seems outside the typical capabilities of an typical intellivision game. 

Saving is possible, in theory, but the specific kind of saving has to be implemented. First, I will add RAM support, then I will make saving the RAM an option, then once all that works, I can look into supporting a saving method that does not use RAM.

[+cmadruga]

If you end up implementing something that works differently from JLP flash saves, it would be important to align with Nanochess the need for Intybasic support.

That should include a way to detect whether the game is running on the Backbit, so the right instructions for saving can be used. 

I don't mind supporting more than one technology, as long as it is manageable through Intybasic.

[8bitwidgets.com]

9 hours ago, cmadruga said:

differently from JLP flash saves,

yea perhaps it's possible to replicate that approach.  Backbit isn't likely to have JLP support so if the flash save implicitly requires JLP to be active then that's a non starter, however @nanochess would be the best person to weigh in on what solutions there might be to allow backbit to support an established save standard to avoid creating a new fork in compatibility.  

[+DZ-Jay]

21 minutes ago, Caleb Garner said:

yea perhaps it's possible to replicate that approach.  Backbit isn't likely to have JLP support so if the flash save implicitly requires JLP to be active then that's a non starter, however @nanochess would be the best person to weigh in on what solutions there might be to allow backbit to support an established save standard to avoid creating a new fork in compatibility.  

 

Why is that a non-starter?  I thought Joe proposed the JLP as a standard and documented the entire architecture.  Is that not right?

 

[8bitwidgets.com]

29 minutes ago, DZ-Jay said:

Why is that a non-starter? 

because @evietron has said she doesn't see supporting acceleration as the scope of what the backbit is for all the systems it supports doesn't line up with enabling this.

 

I would love to see it if possible, but i think early on this was made pretty clear that JLP would not be in the backbit.    

Edited November 3, 2022 by Caleb Garner

[+DZ-Jay]

24 minutes ago, Caleb Garner said:

because @evietron has said she doesn't see supporting acceleration as the scope of what the backbit is for all the systems it supports doesn't line up with enabling this.

 

I would love to see it if possible, but i think early on this was made pretty clear that JLP would not be in the backbit.    

 

Wait, we're talking about NVRAM -- saved game data in persistent storage -- not hardware acceleration, encryption, or any of the other features JLP offers.

 

     -dZ.

[+cmadruga]

Indeed it’s a conversation about individual features and whether implementation is possible over time - the answer can be yes, no, maybe, later, it depends, or “we could offer something else instead”.

[+DZ-Jay]

8 minutes ago, cmadruga said:

Indeed it’s a conversation about individual features and whether implementation is possible over time - the answer can be yes, no, maybe, later, it depends, or “we could offer something else instead”.

 

I'm sorry, I was being cheeky.  Although, like you, I do not really mind supporting more than one standard, I think it would be ideal if there could be a common platform for all cartridges.  My understanding was that Joe Zbiciak was attempting that goal as well, and publishing the architecture of all his designs, including the JLP, jzIntv extensions, the ROM format, CFGVAR metadata, etc.

 

All that being said, it is not for me to tell @evietron what should be implemented in their own device.  As with my suggestion to follow the ECS bank-switching standard rather than inventing a new one, this was also a humble suggestion. :)

 

      -dZ.

[+cmadruga]

You are fine, I get you. One standard would be ideal and much easier to develop for.

 

But given the ship has sailed, having  equivalent functionalities is the next best thing in my mind. At least when it comes to impactful features like the ability to save/load a game.

 

I’m just trying the glass half full approach. 🙂

[+DZ-Jay]

1 minute ago, cmadruga said:

You are fine, I get you. One standard would be ideal and much easier to develop for.

 

But given the ship has sailed, having  equivalent functionalities is the next best thing in my mind. At least when it comes to impactful features like the ability to save/load a game.

 

I’m just trying the glass half full approach. 🙂

I agree with you.  I just wasn’t aware that the “ship has sailed.”  Like I said, I thought the NVRAM API in JLP was fully documented and available for other to implement.

 

Is it not? Or is it that it cannot be implemented as such on the Backbit?

I haven’t heard anything directly from @evietron on that, only speculation from others, but I will admit that I haven’t followed the discussion too closely.

 

   dZ.

[+cmadruga]

In my mind the ship sailed in the sense that sticking to JLP specs as a design requirement just did not happen, and the product is already out there. 

 

But I’m with you about not being entirely clear on what’s possible. 

[8bitwidgets.com]

1 hour ago, DZ-Jay said:

Wait, we're talking about NVRAM

yea but it seemed like maybe the persistent ram was made possible through the JLP standard, which means the cartridge would need to be JLP capable and the backbit isn't looking to be such a beast.  

 

22 minutes ago, DZ-Jay said:

my suggestion to follow the ECS bank-switching standard

yea i'm not sure why, but it seemed that making a new one was preferable for her.  frankly it works and with it's own bin2ecs converter, it makes the conversion path pretty painless..   thankfully there are not many bank switching games it seems so this the impact is minor..  

 

are there even many games that use JLP?  How many support load / saving?   

 

 

17 minutes ago, DZ-Jay said:

I haven’t heard anything directly from @evietron on that,

early on in the original "backbit is coming to intellivision" thread..  it was asked and she replied saying in so many words, it was outside of the scope of the backbit in her mind.  not saying it's impossible, but simply not true to her vision of retro gaming..  meaning JLP = acceleration = getting away from appreciating the limitations of each given piece of hardware the backbit supports.  

 

In my mind if JLP has a save/load function, wouldn't it require the larger JLP framework/system be in place to use it?  I don't know how "a la carte" JLP standards would be to implement.  

 

 

[+DZ-Jay]

11 minutes ago, cmadruga said:

In my mind the ship sailed in the sense that sticking to JLP specs as a design requirement just did not happen, and the product is already out there. 

 

 

Gotcha.  That’s fair.

 

11 minutes ago, cmadruga said:

But I’m with you about not being entirely clear on what’s possible. 

In any case, any implementation of these features will be welcomed.  Plus I agree that it should be supported by IntyBASIC as well.

 

    dZ.

[+DZ-Jay]

10 minutes ago, Caleb Garner said:

yea but it seemed like maybe the persistent ram was made possible through the JLP standard, which means the cartridge would need to be JLP capable and the backbit isn't looking to be such a beast.  

 

 

It’s an API.  The internal implementation does not have to be the same; but if the software access were, then existing games would be able to take advantage of it as well.

 

10 minutes ago, Caleb Garner said:

yea i'm not sure why, but it seemed that making a new one was preferable for her.  frankly it works and with it's own bin2ecs converter, it makes the conversion path pretty painless..   thankfully there are not many bank switching games it seems so this the impact is minor..  

 

are there even many games that use JLP?  How many support load / saving?   

I do not think there are many, but there are some.  It’s also a matter of reducing the friction to supporting multiple platforms.

 

I would like it to be the case that if a game originally released on a JLP board runs out, that it could be re-released easily on another board/multicart if JLP boards were not available for some reason.

 

10 minutes ago, Caleb Garner said:

early on in the original "backbit is coming to intellivision" thread..  it was asked and she replied saying in so many words, it was outside of the scope of the backbit in her mind.  not saying it's impossible, but simply not true to her vision of retro gaming..  meaning JLP = acceleration = getting away from appreciating the limitations of each given piece of hardware the backbit supports.  

 

Let us remove acceleration from this equation.  Like @evietron, I personally do not think it follows a vision of retro gaming on a particular platform, and I do not intend to use such features.

 

Flash RAM storage is another matter, for it affords many interesting and desireable applications.

 

10 minutes ago, Caleb Garner said:

In my mind if JLP has a save/load function, wouldn't it require the larger JLP framework/system be in place to use it?  I don't know how "a la carte" JLP standards would be to implement.  

Save/Load is an API that programs can use.  I believe Joe published the API with the intention of it being adopted for other emulators, boards, and multi carts.

 

Christmas Carol used save/load on a JLP board in a limited way some time before there was an LTO Flash!, and much before JLP learned to accelerate anything.  Cartridge RAM and Flash RAM were there on LTO boards from very early on.

 

    dZ.

Edited November 3, 2022 by DZ-Jay

[+llabnip]

15 minutes ago, Caleb Garner said:

are there even many games that use JLP?  How many support load / saving?   

 

From my work on Nintellivision emulator, these games use JLP:

 

    {0xef662b2b, "Grail of the Gods (JLP)",                     0,  1,  0},    
    {0xec2e2320, "Missile Domination (JLP + IV)",               1,  1,  0},    
    {0x5d6ac5a9, "Super Pixel Bros (JLP)",                      0,  1,  0},    
    {0xd63c8ad0, "JLP Test (JLP)",                              0,  1,  0},        
    {0xf0c5f311, "DK Jr (JLP)",                                 0,  1,  0},    
    {0x613e109b, "Jr Pac-Man (JLP)",                            0,  1,  0},    
    {0xc412dcde, "Jumpking Junior (JLP)",                       0,  1,  0},    
    {0xd3f14a9d, "Fantasy Puzzle (JLP)",                        0,  1,  0},   

 

Some of those games are among the best the system has to offer in terms of homebrew - and I'm always hopeful for more JLP enhanced games.  I can say that the JLP architecture has been really well documented and it's easy to work with.  Although it seems to provide more flexibility to have an alternate way to do something... often having just one solid standard makes for an easier road to widespread adoption (both for the developers and those of us writing emulators or designing new hardware).

[8bitwidgets.com]

2 minutes ago, DZ-Jay said:

then existing games would be able to take advantage of it as well.

that would be great if this could be implemented without having to implement acceleration.  I would think working with an existing API would make the job easier for @evietron but maybe it's a language issue?  She mentioned she is using python in some capacity.  I'm not sure what JLP is built on.  

 

7 minutes ago, DZ-Jay said:

that it could be re-released easily on another board/multicart if JLP boards were not available for some reason.

Ideally it would be great of backbit just did the full JLP thing, but given it's swiss army knife approach..  there may be other factors at play as the backbit supports numerous other computers / consoles.

 

11 minutes ago, DZ-Jay said:

Let us remove acceleration from this equation

I have always associated JLP with acceleration..  but it would be great to know if she's checked out the JLP API and interested to know if there are some technical hurdles to this that we're unaware of.  

 

12 minutes ago, DZ-Jay said:

Flash RAM storage is another matter,

absolutely.  saving function would be amazing.  

 

16 minutes ago, DZ-Jay said:

Save/Load is an API that programs can use.

Definitely would be great to get the final word on this.  it sounds like save/load is something she's willing to consider.  I think we all agree if we can impliment an established standard this would help support existing homebrews and allow developers to make games knowing the other major multicart for the intellivision supports the same saving standard.  

 

5 minutes ago, llabnip said:

these games use JLP:

nice thanks for that list!  Some cool games for sure.  When you say JLP does that imply acceleration?  or just some other facets of it?  

[+DZ-Jay]

8 minutes ago, Caleb Garner said:

 

I have always associated JLP with acceleration..  but it would be great to know if she's checked out the JLP API and interested to know if there are some technical hurdles to this that we're unaware of.  

 

8 minutes ago, Caleb Garner said:

Definitely would be great to get the final word on this.  it sounds like save/load is something she's willing to consider.  I think we all agree if we can impliment an established standard this would help support existing homebrews and allow developers to make games knowing the other major multicart for the intellivision supports the same saving standard.  

I edited my post above with the following, but I may as well post it as a new comment:

 

Christmas Carol used save/load on a JLP board in a limited way some time before there was an LTO Flash!, and much before JLP learned to accelerate anything.  Cartridge RAM and Flash RAM were there on LTO boards from very early on (emulator support for it was just being developed at the time.)

 

    dZ.

Edited November 3, 2022 by DZ-Jay

[+cmadruga]

23 minutes ago, Caleb Garner said:

 

are there even many games that use JLP? 

 

Yes there are quite a few.
You may not have seen them in the wild in digital unencrypted format, but there are quite a few carts. 

 

My suggestion to you is to not focus so much on how many, but notice which ones do use it. 
 

For instance, you said you did not know Sorrow from Kai. That happens to be the 2021 Game of the Year (digital format category).

 

Do yourself a favor, buy a digital copy of this great game and play it on Jzintv.

 

Then come back and tell us if you would not want to play it on your Backbit if you could. 
 

What I’m trying to say is that as a user, you should be lobbying for JLP (or JLP-alike) features to be offered, because those enable superior games.

The games you want to see more of… even though you may not have seen many so far.

[+llabnip]

17 minutes ago, Caleb Garner said:

nice thanks for that list!  Some cool games for sure.  When you say JLP does that imply acceleration?  or just some other facets of it?  

It's unclear. I support the following JLP features which has worked for all JLP games I've tried so far:

• Extra RAM
• Save to Flash (V2)
• Accelerated mul/div/crc

I do not (yet) support the banking ROM (really just ECS style banking if memory serves). 

I don't have the ability to support locking / encryption of digital ROMs.

Edited November 3, 2022 by llabnip