Common code base with UnoCart

[Capellão]

13 minutes ago, Al_Nafuur said:

Yes!
I forgot to mention this new feature (by @MarcoJ) in my announcements.

however, when disconnecting it, it does not save the option, returning to the default "enabled".

[Thomas Jentzsch]

6 hours ago, Capellão said:

however, when disconnecting it, it does not save the option, returning to the default "enabled".

IMO it should stay enabled.

[+Al_Nafuur]

5 hours ago, Thomas Jentzsch said:

IMO it should stay enabled.

Yes this would be nice, but then we would have to change the User-Settings struct in the eeprom emulation flash area. Because of the currently 29 active firmware version and the way we update the firmware, these changes would have to be checked in all future firmware versions (see https://github.com/Al-Nafuur/United-Carts-of-Atari/blob/main/source/STM32firmware/PlusCart/Src/main.c#L1363)

 

That is the reason why we have decided to make this switch only temporary. I think this is a good solution, because only a few ROMs trigger the exit function and are therefore unplayable.

 

[Thomas Jentzsch]

8 minutes ago, Al_Nafuur said:

That is the reason why we have decided to make this switch only temporary. I think this is a good solution, because only a few ROMs trigger the exit function and are therefore unplayable.

Couldn't you auto detect if the exit will work? E.g. Indy 500 exits immediately, so I figure RESET and RIGHT are both active at startup or short after. If the PlusCart checks the state for a few frames or seconds before activating the exit functionality, we wouldn't even need that switch in such cases.

 

Or could we use other, more convenient input to disable the switch? E.g. starting the game with a console/controller switch pressed? Or by using a key as part of the filename?

[+Al_Nafuur]

13 minutes ago, Thomas Jentzsch said:

Couldn't you auto detect if the exit will work? E.g. Indy 500 exits immediately, so I figure RESET and RIGHT are both active at startup or short after. If the PlusCart checks the state for a few frames or seconds before activating the exit functionality, we wouldn't even need that switch in such cases.

Most banking schemes don't use a timer. And it would be a really big effort to add this to every scheme..

 

13 minutes ago, Thomas Jentzsch said:

Or could we use other, more convenient input to disable the switch? E.g. starting the game with a console/controller switch pressed?

 this might work, we could add a

	lda/x/y SWCHA/B

to the loading animation in RIOT RAM and peek the result (for two or three frames) during the cartridge setup in the firmware and disable the exit function. Unfortunately most of the console/controller functions are already used by the menu, so we would have to delay the detection..
  

13 minutes ago, Thomas Jentzsch said:

Or by using a key as part of the filename?

This would also be possible and a very easy way!

 

 

An other idea would be to detect the affected ROMs in the PlusStore API and tell the PlusCart during loading to disable the exit function, but this would only work for the online files not for the flash or SD files.

[Thomas Jentzsch]

14 minutes ago, Al_Nafuur said:

Most banking schemes don't use a timer. And it would be a really big effort to add this to every scheme..

But the ARM does have a timer, no?

14 minutes ago, Al_Nafuur said:

 this might work, we could add a

	lda/x/y SWCHA/B

to the loading animation in RIOT RAM and peek the result (for two or three frames) during the cartridge setup in the firmware and disable the exit function. Unfortunately most of the console/controller functions are already used by the menu, so we would have to delay the detection..

Sounds good to me.

 

Or something like the power-on dialog in Stella. Could be brought up e.g. by a long button press. For making that work, the games should be selected by button release instead of pressed. Or just start the game with a long instead of a quick button press.

14 minutes ago, Al_Nafuur said:

An other idea would be to detect the affected ROMs in the PlusStore API and tell the PlusCart during loading to disable the exit function, but this would only work for the online files not for the flash or SD files.

Also good.

Edited January 19, 2023 by Thomas Jentzsch

[+Al_Nafuur]

 

3 hours ago, Thomas Jentzsch said:

Or by using a key as part of the filename?

After thinking about it a bit, I think that's the best way to go. This solution is easy to implement and it will work on all carts with online files (even ZIP files!), flash files and SD-card files. And it will be easy to understand/see for the users that the exit functions is deactivated for this file (if we use a good key and positioning).

 

Now we just have to define how the key should look like.

 

My suggestion would be " No Exit " as key. As prefix it would be easy to detect for the firmware and easy to see for the user, but it would affect the sorting in the file list. As postfix it would also be easy to detect and it would not affect the sorting, but it may not be visible for the user. Allowing the key in the middle of the filename would take the detection a few more ARM cycles, but would less affect the sorting and the visibility.

 

Any thoughts @ZackAttack, @MarcoJ, @Andrew Davie , @Thomas Jentzsch and anyone else who cares?

 

[Thomas Jentzsch]

I would suggest e.g. "[no exit]" or "<no exit>" to make it stick out.

 

And IMO it definitely belongs to the end of the filename or the suffix. Else it will create irritating names. Maybe the user doesn't see it in the menu, but is that really important to know? Alternatively the <no exit> situation could be displayed by a special symbol at the end of the game's menu row.  

 

Also, I am still hoping for an improved firmware, which allows displaying the full filename like Harmony does.

[ZackAttack]

I do like the option of having a suffix to provide a manual override. That can always be handy to work around issues with the feature. My proposal would be a simple .noexit suffix like this: MyGameFile.noexit.bin. Then the menu code would remove the .noexit from the display name and put a "no exit" icon on the left most character. We could make that a special 7 pixel wide character and anchor it in place.

 

I like the idea of providing a menu before launching a ROM so users can configure options like 2600/7800 mode, exit/no exit, online/offline, etc.

 

9 hours ago, Thomas Jentzsch said:

Also, I am still hoping for an improved firmware, which allows displaying the full filename like Harmony does.

I'm not sure how the Harmony does it. I was thinking it would be done by scrolling the filename horizontally when it exceeds 36 characters. Maybe only scroll the selected line?

 

Whatever we decide, I can include it in the work I'm doing for 7800 support. That already has me making significant changes to the menu system and exit rom routines.

[Thomas Jentzsch]

8 hours ago, ZackAttack said:

I do like the option of having a suffix to provide a manual override. That can always be handy to work around issues with the feature. My proposal would be a simple .noexit suffix like this: MyGameFile.noexit.bin. Then the menu code would remove the .noexit from the display name and put a "no exit" icon on the left most character. We could make that a special 7 pixel wide character and anchor it in place.

That's almost what I tried to describe above, except that I would put the icon at the end. Which is probably easier to implement and keeping the sorting intact. Also, as long as the other files have no icon (or a blank there), the list would IMO a bit odd.

8 hours ago, ZackAttack said:

I'm not sure how the Harmony does it.

A long button press triggers this (games are started after a short button press, just like I suggested in my post above for the menu). The cart then simply loads the full name and displays it instead of the file list. After you release the button, the file list is displayed again.

 

If we have a menu, this could also display the full name. There is enough space.

Edited January 20, 2023 by Thomas Jentzsch

[ZackAttack]

23 hours ago, Thomas Jentzsch said:

If we have a menu, this could also display the full name. There is enough space.

That's a good idea. We could reserve 3 lines for the full name. 108 characters should be plenty. Maybe even do the scrolling as well.

 

23 hours ago, Thomas Jentzsch said:

A long button press triggers this (games are started after a short button press, just like I suggested in my post above for the menu).

Activating the submenu with a long button press sounds good. I think we'd want to stay on the submenu after the long press is released. There can be links to go back or start game.

[Thomas Jentzsch]

28 minutes ago, ZackAttack said:

That's a good idea. We could reserve 3 lines for the full name. 108 characters should be plenty. Maybe even do the scrolling as well.

Or more lines.   The longest filename in the Atarimania ROM collection has 201 chars (plus suffix).

28 minutes ago, ZackAttack said:

Activating the submenu with a long button press sounds good. I think we'd want to stay on the submenu after the long press is released. There can be links to go back or start game.

Agreed. There would have to be menu entry for exiting the submenu.

[+Al_Nafuur]

On 1/20/2023 at 11:37 AM, Thomas Jentzsch said:

If we have a menu, this could also display the full name. There is enough space.

3 hours ago, ZackAttack said:

That's a good idea. We could reserve 3 lines for the full name. 108 characters should be plenty. Maybe even do the scrolling as well.

 

Activating the submenu with a long button press sounds good. I think we'd want to stay on the submenu after the long press is released. There can be links to go back or start game.

2 hours ago, Thomas Jentzsch said:

Or more lines.   The longest filename in the Atarimania ROM collection has 201 chars (plus suffix).

Agreed. There would have to be menu entry for exiting the submenu.

 

 

The PlusCart Duo firmware is already 126 KB (129.564 Bytes), so you have 1508 Bytes for all new features!

 

 

 

[Thomas Jentzsch]

12 minutes ago, Al_Nafuur said:

The PlusCart Duo firmware is already 126 KB (129.564 Bytes), so you have 1508 Bytes for all new features!

Time for optimizing!  

[ZackAttack]

11 minutes ago, Al_Nafuur said:

The PlusCart Duo firmware is already 126 KB (129.564 Bytes), so you have 1508 Bytes for all new features!

The switch to the arm based 36char kernel should free up the 2K used by the 3 regions of firmware rom. Of course, the 36char kernel will take up some of that, but it should be much less.

[+Andrew Davie]

On 1/13/2021 at 10:45 PM, Al_Nafuur said:

Instead of migrating every new feature (32 char menu, exit function and new bankswitchings) to the UnoCart we should aim for a common code base.

It would be easier if we re-implement the SD card code into the PlusCart code (to the submenu "SD-Card" ?) and use switches to compile for the UnoCart or the PlusCart.

 

we also could use a more generic approach and switch the hardware differences directly, so we could build for:

• using lower or higher GPIO port for the data bus
• with or without WiFi module
• with or without SD-Card

 

@DirtyHairy, @Andrew Davie, @Thomas Jentzsch any ideas or suggestions ?

 

 

I'm all for common code base and switchable builds.

 

I do not feel happy "supporting" Diablo by going out of my way to be compatible; I would have dearly loved for them to share with the community as promised years ago, rather than profiting from our work without acknowledgement and in violation of what I understand the licensing to be. So, very much against that.

 

Although I did a lot of the UI menu code, I built on an existing code structure which I found complex and difficult to understand. Not saying it was wrong or bad, but definitely felt alien to me and a very different way of programming. If I were shooting for a common code base I'd probably look at rewriting the menu parts completely.

 

 

 

 

[ZackAttack]

14 hours ago, Andrew Davie said:

I do not feel happy "supporting" Diablo by going out of my way to be compatible; I would have dearly loved for them to share with the community as promised years ago, rather than profiting from our work without acknowledgement and in violation of what I understand the licensing to be. So, very much against that.

I'm not too familiar with this situation. Are you saying the project is bigger than it needs to be due to compatibility with Diablo specific hardware?

 

23 hours ago, ZackAttack said:

The switch to the arm based 36char kernel should free up the 2K used by the 3 regions of firmware rom. Of course, the 36char kernel will take up some of that, but it should be much less.

I looked into this some more and found that adding 7800 support is going to increase the size over 128KB even with the savings from switching to arm based text kernels. For now, it seems the easiest solution is to compile the non-critical functions with -Os instead of -O3. I tried this with a few of the larger files and was able to save a few KB.

 

Eventually we may need to move some stuff out of the firmware, but for now playing with -O at the file level seems to be a viable solution.

[Thomas Jentzsch]

The Harmony cart is using Thumb code to save space. Would this be an option here too? Or is this maybe done already?

[+Al_Nafuur]

2 hours ago, ZackAttack said:

I'm not too familiar with this situation. Are you saying the project is bigger than it needs to be due to compatibility with Diablo specific hardware?

🤷‍♂️

I haven't heard of @DablioGames for more than a year now.

 

Currently @Capellão is building/selling most of the PlusCarts (Duo) in Brazil. But none of their hardware needs special treatment in the code.

 

 

2 hours ago, ZackAttack said:

I looked into this some more and found that adding 7800 support is going to increase the size over 128KB even with the savings from switching to arm based text kernels. For now, it seems the easiest solution is to compile the non-critical functions with -Os instead of -O3. I tried this with a few of the larger files and was able to save a few KB.

The biggest addition in the last firmware release was the ELF lib which added ~20 KiB to the firmware.

 

2 hours ago, ZackAttack said:

Eventually we may need to move some stuff out of the firmware, but for now playing with -O at the file level seems to be a viable solution.

we might remove my (beta) DPC+ driver from the code, if we manage to wrap the driver into ACE. Since most of the DPC+ games are using custom code (except for Chaotic Grill) they will need a recompile anyway, so we might as well replace the Harmony DPC+ drivers in the ROMs too. Wrapping a custom STM32 CDF(J+) driver into ACE would be the same route without increasing the firmware size.

 

 

 

1 hour ago, Thomas Jentzsch said:

The Harmony cart is using Thumb code to save space. Would this be an option here too? Or is this maybe done already?

The STM32F4 only has Thumb..

 

 

[Capellão]

On 1/22/2023 at 1:04 PM, Al_Nafuur said:

🤷‍♂️

I haven't heard of @DablioGames for more than a year now.

 

Currently @Capellão is building/selling most of the PlusCarts (Duo) in Brazil. But none of their hardware needs special treatment in the code.

 

 

The biggest addition in the last firmware release was the ELF lib which added ~20 KiB to the firmware.

 

we might remove my (beta) DPC+ driver from the code, if we manage to wrap the driver into ACE. Since most of the DPC+ games are using custom code (except for Chaotic Grill) they will need a recompile anyway, so we might as well replace the Harmony DPC+ drivers in the ROMs too. Wrapping a custom STM32 CDF(J+) driver into ACE would be the same route without increasing the firmware size.

 

 

 

The STM32F4 only has Thumb..

 

 

needing my help, I'm available. I always try to help people who are having doubts about recording the main firmware or solving
problems.

[Mr SQL]

Thumb code looks cool, it reminds me of the 6809 where you had the option of writing 16 bit asm or splitting 16-bit registers into two 8-bit registers for faster 8-bit ops.