Jump to content
electrotrains

UnoCart-2600 : a DIY SD multi-cart for the 2600

Recommended Posts

I'm interested in one if they play/ever play melody games.

 

 

Supporting melody games is technically challenging as the memory map differs between the SOCs used in UnoCard and harmony / melody, but it should be possible if someone sits down and implements it - the UnoCard firmware is open source ;)

  • Like 1

Share this post


Link to post
Share on other sites

 

 

Supporting melody games is technically challenging as the memory map differs between the SOCs used in UnoCard and harmony / melody, but it should be possible if someone sits down and implements it - the UnoCard firmware is open source ;)

 

harmony/melody uses a 70mhz arm cpu. the more recent sophisticated mappers like cdw (super cobra arcade and draconian are the first games to use it) require quite a beefy processor to emulate.

Share this post


Link to post
Share on other sites

harmony/melody uses a 70mhz arm cpu. the more recent sophisticated mappers like cdw (super cobra arcade and draconian are the first games to use it) require quite a beefy processor to emulate.

 

 

 

The UnoCard is based on a STM32F407xxx, which has an ARM Cortex M4 core clocked at around 160MHz. The MCU could run the the game code directly, no emulation required.

Edited by DirtyHairy
  • Like 1

Share this post


Link to post
Share on other sites

 

 

The UnoCard is based on a STM32F407xxx, which has an ARM Cortex M4 core clocked at around 160MHz. The MCU could run the the game code directly, no emulation required.

Wow. That's awesome. :thumbsup:

 

It means the next hyper awesome dpc/cdw stuffing the bus ++ might be able to take advantage of that extra headroom on the UNO and not run on the stock Harmony.

Share this post


Link to post
Share on other sites

I may consider adding support but first...

A few question (due to lack of knolege on source):

 

1:What are the reqired files I need to build?

2:What is the source language (I'm assuming it's some sort C Flavor)?

3:I found the Stella Dpc+ source, will that help?

 

Thanks

Edited by Trip2018

Share this post


Link to post
Share on other sites

Hello can I buy 2x??? I want try make TIA chipmusic...

You are obsessed with Chip Music Matej :)

Share this post


Link to post
Share on other sites

Couldn't resist a quick attempt to make a "label" for the cart with the 3d printer. That looks much nicer and hides my slightly ragged cut for the SD card slot.

 

attachicon.gifP1160761.jpg

 

would you share that file so we can print that label ourselfs? pretty please! :)

Share this post


Link to post
Share on other sites

I have added support for large (up to 512kb) 3F images to the firmware. As such files exceed the amount of RAM available on the STM32F4x (the firmware has 160k available for cartridge images), the banks that exceed this limit are copied to flash when the image is launched. I have used ZackAttack's and my own audio test ROMS from this thread for testing.

 

The changes are not yet integrated in the main repository, but they are available in my fork on GitHub. I have attached a build of the updated firmware. In order to program the firmware, you need a ST-Link V2 USB programmer (<10€ on eBay or Amazon) that you connect to your UnoCard (you have to power the cart with your VCS during programming).

 

firmware.zip

Edited by DirtyHairy
  • Like 6

Share this post


Link to post
Share on other sites

Hello every one!

 

As ElectroTrains has mentioned, I will be producing the 2600 UNO for the Americas (United States, Canada, Mexico, South America). I am offering them at US$35.00 plus my standard shipping rates ($10 US//$15 Canada & Rest of World). SHIPPING COSTS CHANGED: $15 for rest of world FOR ONE CART!

 

If you want to buy more than one cart, shipping for rest of world is still $20. This allows you to save $5 US shipping can still combine up to three items

 

I have to charge 8% sales tax to anyone in California. Sorry. Gotta keep it legal!

 

If you are interested, send me a PM or contact me at macrorie "at" thebrewingacademy dot com or marlin4 "at" gmail dot com

 

For this price, it will be the bare cartridge. However, for US$5 more, I will put it in a nice 3D printed cart with a paper front label and paper end label (waterproof) of your choice. (See pictures)

post-16779-0-16853600-1527330995_thumb.jpg

post-16779-0-58802400-1527331007_thumb.jpg

post-16779-0-71673800-1527331022_thumb.jpg

post-16779-0-08554800-1527331044_thumb.jpg

post-16779-0-19285100-1527331074_thumb.jpg

post-16779-0-59647600-1527331084_thumb.jpg

Edited by MacRorie
  • Like 12

Share this post


Link to post
Share on other sites

I might have missed it but can this handle newer games like Draconian or ones that use the Melody boards.

Share this post


Link to post
Share on other sites

I might have missed it but can this handle newer games like Draconian or ones that use the Melody boards.

I asked the same thing. I'm hoping to get the chance to add support but for now it doesn't. :(

Share this post


Link to post
Share on other sites

AFAIK the hardware is slightly different. But not that much that the games could not be adopted quite easily.

Share this post


Link to post
Share on other sites

To elaborate a bit ;)

CDF and DPC+ games run ARM Thumb code directly on the MCU. The ARM code interacts with the 6502 code through registers in cartridge space. In case of DPC+, the game code is self contained while on CDF, it can call utility functions in the driver code.

Implementing the parts of the DPC+ that dont involve running native code is just an excercise in patience, nothing complicated there (CDF is completely geared towards running ARM code, so that doesnt make a lot of sense there). The tricky part is running the ARM code.

The SOC on the UnoCard is a STM32F4xxx which is built around an ARM Corex M4 core. It can run Thumb code, so that is a match. The complicated part is the memory layout that differs between the STM32 and the LPC that is used on the Harmony / Melody. RAM and ROM are located at different addresses between the STM32 and LPC. Part of this could be taken care of by reconfiguring the STM32 (relocating the vector table and switching the lower memory layout), but fixing RAM access requires either patching the ARM code (messy and potentially unreliable) or relinking the ARM for the STM32 (in other words: a separate ROM for the UnoCard). Or a better idea ;)

 

So, in a nutshell: I am pretty sure that the deed can be done, I have done some proof-of-concept level tests in emulation, and I plan to take a closer look at it eventually, but certainly not tomorrow or even this summer. However, Electrotrains kindly made hard- and software open source on Github, so anyone who wants can give it a try. I am happy to share my current analysis and offer advice, but my time is currently very limited, and this is not an easy project: you should be sure that you really understand everything I wrote above, understand the Stella (or 6502.ts) source for DPC+ / CDF and get yourself in the position to modify and build the firmware before expecting serious help from me. Needless to say, this also requires consent and potentially support from the CDF / DPC+ community.

Edited by DirtyHairy
  • Like 4

Share this post


Link to post
Share on other sites

Part of this could be taken care of by reconfiguring the STM32 (relocating the vector table and switching the lower memory layout), but fixing RAM access requires either patching the ARM code (messy and potentially unreliable) or relinking the ARM for the STM32 (in other words: a separate ROM for the UnoCard). Or a better idea ;)

 

Not sure if this is a better idea, but couldn't the Memory Protection Unit (MPU) be configured so a protection fault is generated anytime an access to LPC RAM is attempted? The handler would fix up the address for reads and writes. If the access was for execution it would just return to the correct execution point in the STM32 RAM. Fortunately the STM32 is significantly faster due to the fact that it's clocked higher and doesn't suffer from the hardware bug that cripples the LPC when running arm code from ROM. The speed up of all the code that doesn't access RAM would hopefully offset the penalty of fixing up the address when RAM is accessed. If not the program could probably be patched on the fly to eliminate most of the protection faults.

  • Like 1

Share this post


Link to post
Share on other sites

 

Not sure if this is a better idea, but couldn't the Memory Protection Unit (MPU) be configured so a protection fault is generated anytime an access to LPC RAM is attempted? The handler would fix up the address for reads and writes..

 

 

I thought about that too, but I dismissed it as too complicated (at least for my tastes ;) ). In order to make this work for data access, the fault handler has to inspect the faulting code and either emulate the faulting instruction or patch it dynamically. Furthermore, if the access was relative, this gets even more messy. Still, if someone has the skill and patience to implement this, it should provide 100% compatibility without the need to relink the images.

 

What I did was patching everything that looks like a pointer to RAM in the image, together with a bit of heuristics to avoid false positives. With this approach, I was able to get several DPC+ games to run successfully on the modified memory map in 6502.ts.

Edited by DirtyHairy

Share this post


Link to post
Share on other sites

Just ordered a cart from MacRorie. Going to port over the Strong-ARM driver and see how well bus stuffing works with the STM32.

Share this post


Link to post
Share on other sites

Got my UnoCart today, absolutely love it. (love the 3d printed end label - thanks Robin)

 

I'll adapt a long dead Midnight Magic cart as a housing for this little beauty with some dremel action.

 

Anyone know of a label suppler in the UK who does cart labels?

 

I know pboland does some excellent labels but it's expensive to ship a single label from the US to the UK..

 

:thumbsup: electrotrains & dirty hairy

  • Like 1

Share this post


Link to post
Share on other sites

AFAIK the hardware is slightly different. But not that much that the games could not be adopted quite easily.

By "adopted" do you mean the ROMs would have to be modified to run on the UNO, or could the firmware be made to utilize unmodified Harmony ROMs?

 

This is actually a promising development. If sometime in the future the source for new Melody boards dries up, homebrew may live on with special cost reduced UNO boards. Also potentially the faster ARM may allow for more powerful games? Or is existing hardware about tapped out?

Share this post


Link to post
Share on other sites

By "adopted" do you mean the ROMs would have to be modified to run on the UNO, or could the firmware be made to utilize unmodified Harmony ROMs?

See above

 

Also potentially the faster ARM may allow for more powerful games? Or is existing hardware about tapped out?

I suppose the kernel running on the 6507 is maxed out with busstuffing. But the ARM code, even though running at 70MHz, already has to be optimized for speed too in some cases. So I suppose UnoCard's 160MHz would help here.
  • Like 1

Share this post


Link to post
Share on other sites

Cart arrived and love it. A couple of questions. What is the max size sd card supported? When I try to go through the game list, it jumps from games starting with the letter c to w in the menu screen. I am playing this cart on a 7800. I will test it later on a 2600.

Share this post


Link to post
Share on other sites

Cart arrived and love it. A couple of questions. What is the max size sd card supported? When I try to go through the game list, it jumps from games starting with the letter c to w in the menu screen. I am playing this cart on a 7800. I will test it later on a 2600.

 

 

 

Good to hear! I am not 100% satisfied with the labels. My printer needs a new fuser, I think. I actually ordered a new one that should be here Monday. If anyone wants a new label, just let me know and I will send one along.

 

As for not seeing files, it may be that those files do not comply with what UNO wants to see as far as extensions/file formats. Are the files all in the same format? Also, there is a limit to the number of files that UNO will display/see at any one time, so you might want to put them in separate subdirectories.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...