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

[Thomas Jentzsch]

Why don't you post at YouTube? Either in English or by using DeepL (much better than Google Translate).

Edited May 17, 2019 by Thomas Jentzsch

[DFL]

Why don't you post at YouTube? Either in English or by using DeepL (much better than Google Translate).

I posted, with the link to the original GIthub, but the comment was removed a few minutes later.

[Thomas Jentzsch]

I posted, with the link to the original GIthub, but the comment was removed a few minutes later.

Then you should report to YouTube and cross fingers.

[Fabianojs]

SHAME

 

https://www.youtube.com/watch?v=u9bGDOkhPTc

 

 

Changing only the title and the author's name was the worst thing I've ever seen. And if I understood, the guy is saying that he did the project. Really shame!

At no point in this video does he claim to be the author of the project, but he does not give due credit to the original author either

 

 

Enviado do meu iPhone usando Tapatalk

[Shawn]

At no point in this video does he claim to be the author of the project, but he does not give due credit to the original author either

 

 

Enviado do meu iPhone usando Tapatalk

 

I'm curious about which version of Boulder Dash is being shown on that SD cart at the end of the video. Someone care to look to confirm if that is the public demo or the retail release? If it's the later I would not be surprised.

[alex_79]

It's the second public demo:

http://atariage.com/forums/topic/220986-boulder-dash-demo-v2/

[Shawn]

It's the second public demo:

http://atariage.com/forums/topic/220986-boulder-dash-demo-v2/

 

Thank goodness.

[xefned]

I was glad to see the video, if nothing else, just to learn about Bee Ball. It's now on my Unocart.

[Thomas Jentzsch]

 

I'm curious about which version of Boulder Dash is being shown on that SD cart at the end of the video. Someone care to look to confirm if that is the public demo or the retail release?

Definitely the demo.

[DFL]

At no point in this video does he claim to be the author of the project, but he does not give due credit to the original author either

 

 

Enviado do meu iPhone usando Tapatalk

Yes, he does...

Check this video

https://www.youtube.com/watch?v=eJ02M_0QL3E

"MY new work" ... "I was working for the last days"

 

Working changing the text as I see.

 

Anyway, showing the video without the real author's name is bad enough, even if he had not said it was his work (and he did anyway)

[Gyro]

Hello all. Recently bought a Uno and I love it, works great with my light sixer except for Pitfall 2. I put in the 10/2018 firmware upgrade and it's playable now, but the screen flips. I'll be glad when it is up and working but I have PLENTY to play in the meantime.

[matt2d2]

Got an UnoCart very recently, and loving it! To the crew involved in making it happen - great work!

 

I decided to go with this even though I have a boatload of carts. This is just so much simpler a way to play games on actual vintage hardware.

 

The UnoCart came with label stickers in Atari style. The supplied 3d printed cart case looked good, and fit like a glove with the two 2600 systems I tried it on. I dragged and dropped some roms onto an old FAT32 SD card, and UnoCart read it perfectly. Navigation with the stick was fine. Appreciate being able to skip by the page using the stick. I wish that when you go into a directory, and then back out, the menu remembered where you were vs starting back at the top. There is a limit of 12 characters for names, but not a big deal to me.

 

I played a bunch of favorites, and UnoCart worked great. Amazing really, and so much fun. I didn't play any home brews, but something to try. Wanted to try Starpath games, but I only have audio versions of those. I wish there was a way to get back to menu without powering the system off and on. Blaming this on Atari for having only one controller button!

 

My opinion is that UnoCart is a great little device that you should buy.

Edited May 31, 2019 by matt2d2

[Windless]

Hi,

 

I took a look at the unocart code, and there is something I wish I could understand better : because the clock signals are not available to the cartridge port, synchronization with the 6507 clock is made by monitoring changes on the address bus. The code seems to consider that the address is stable if it gives twice the same reading. Is this enough in real cases ? If e.g. one bit would take a tenth of a cycle (1/12.000.000 seconds) more the others and the stm32f4 discovery board runs at max speed (168MHz), the bit would be lagging for 14 stm32 cycles, enough to read twice the same value and think the address but is stabilised.

 

The specification of the 6502 tells that the address is stable at max 325µs after the clock signal, but does not say how long it takes to stabilize once it started changing.

 

Did you find a specification fo that ? Did you test until it appear to be stable on you 2600 ? I'm very curious about this. (I was planning to make a cartridge emulator on a bluepill and then found you work)

[ZackAttack]

Hi,

 

I took a look at the unocart code, and there is something I wish I could understand better : because the clock signals are not available to the cartridge port, synchronization with the 6507 clock is made by monitoring changes on the address bus. The code seems to consider that the address is stable if it gives twice the same reading. Is this enough in real cases ? If e.g. one bit would take a tenth of a cycle (1/12.000.000 seconds) more the others and the stm32f4 discovery board runs at max speed (168MHz), the bit would be lagging for 14 stm32 cycles, enough to read twice the same value and think the address but is stabilised.

 

The specification of the 6502 tells that the address is stable at max 325µs after the clock signal, but does not say how long it takes to stabilize once it started changing.

 

Did you find a specification fo that ? Did you test until it appear to be stable on you 2600 ? I'm very curious about this. (I was planning to make a cartridge emulator on a bluepill and then found you work)

 

Keep in mind the peripheral clock is typically slower than the core CPU clock. You're correct though. It's possible to get a stable address that is not the next actual address. In practice this isn't really an issue because it's no different than having a really fast rom. There will be some transient values driven on the data bus while the address settles down, but eventually the correct address/data pair are produced and because there's a considerable delay between when the address is valid and the data is read it's always sorted itself out in time. The one exception to this is pitfall 2 because a lot more processing is done for each address and sometimes this can trip it up.

 

I made a custom firmware build that logged the stable addresses to SD card when we were troubleshooting an issue with a specific system. On my 2600 jr it would pick up at least one wrong address for every right address.

 

You could poll for longer but the problem with that is it increases latency and could lead to a failure to service the data bus in time.

 

To get around this problem and allow useful work to be done in place of the address polling I keep track of what the next ROM address would be and wait for the address bus to be set to that before proceeding to update the data bus. This allows the data value to be calculated in advanced and also eliminates servicing any transient address values. The only downside is that you have to emulate enough of the 6502 to know which rom address comes next. For my purposes it's not difficult since I run all my game logic in ARM and only use a few load/store instructions to update the TIA registers. That project is also open source.

[Windless]

 

Keep in mind the peripheral clock is typically slower than the core CPU clock. You're correct though. It's possible to get a stable address that is not the next actual address. In practice this isn't really an issue because it's no different than having a really fast rom. There will be some transient values driven on the data bus while the address settles down, but eventually the correct address/data pair are produced and because there's a considerable delay between when the address is valid and the data is read it's always sorted itself out in time. The one exception to this is pitfall 2 because a lot more processing is done for each address and sometimes this can trip it up.

 

I made a custom firmware build that logged the stable addresses to SD card when we were troubleshooting an issue with a specific system. On my 2600 jr it would pick up at least one wrong address for every right address.

 

You could poll for longer but the problem with that is it increases latency and could lead to a failure to service the data bus in time.

 

To get around this problem and allow useful work to be done in place of the address polling I keep track of what the next ROM address would be and wait for the address bus to be set to that before proceeding to update the data bus. This allows the data value to be calculated in advanced and also eliminates servicing any transient address values. The only downside is that you have to emulate enough of the 6502 to know which rom address comes next. For my purposes it's not difficult since I run all my game logic in ARM and only use a few load/store instructions to update the TIA registers. That project is also open source.

 

 

There will be some transient values driven on the data bus while the address settles down, but eventually the correct address/data pair are produced and because there's a considerable delay between when the address is valid and the data is read it's always sorted itself out in time.

 

Ok, so there should be no problem, since the databus is tristate for a rather long time after the address bus is stabilised, so no colision if possible on the bus when writing. (well, except if the TIA is trying to write on the data bus, then let's hope impedance is high enough ^^)

 

Otoh it probably means you need to take moe care when emulating write access to cartridge RAM, I'll have a look at the code.

 

 

To get around this problem and allow useful work to be done in place of the address polling I keep track of what the next ROM address would be

 

 

Impressive

 

 

That project is also open source.

 

 

Thank you.

 

nice ! I wanted to do something similar for the GMB, but it only can read the rom andwrite to video memory athalf the neededspeed, so switched to 2600.

[+ZeroPage Homebrew]

ZeroPage Homebrew recently live streamed an UnoCart special on Twitch with the world premieres of the following UnoCart ONLY games:

 

- Gorilla Force (2019 WIP) by Zachary Scolaro aka ZackAttack and Jason Davidson aka MayDay
- Wushu Masters (2019 WIP) by Zachary Scolaro aka ZackAttack and Jason Davidson aka MayDay

 

We also go through a run down of the pros and cons of the UnoCart vs the Harmony Cart. Enjoy!

 

 

[Mr SQL]

On ‎5‎/‎31‎/‎2019 at 10:19 AM, matt2d2 said:

Wanted to try Starpath games, but I only have audio versions of those. I wish there was a way to get back to menu without powering the system off and on. Blaming this on Atari for having only one controller button!

 

My opinion is that UnoCart is a great little device that you should buy.

Try this one: 

It should play great on your UNO cart. For the ZeroPage crew and anyone running Stella (including the Retron77 latest community firmware) make sure to turn off phosphor frame merging if it is on by default, or the game won't render properly like it does on classic hardware. 

 

[+Karl G]

Are 128K ROMs supported on the 2600? The website says up to 64K but I just wanted to make sure. If 128K is supported, which bankswitching schemes are compatible? I tried a DFSC ROM with no luck.  Thanks!

[+MacRorie]

5 hours ago, Karl G said:

Are 128K ROMs supported on the 2600? The website says up to 64K but I just wanted to make sure. If 128K is supported, which bankswitching schemes are compatible? I tried a DFSC ROM with no luck.  Thanks!

NOTE: 256k .3E files must have the extension .3E in order to be correctly loaded.  Note:  The table does not reflect the fact that currently shipping firmware will allow the use of 256k .3E ROMs.

 

[+-^CrossBow^-]

11 minutes ago, MacRorie said:

NOTE: 256k .3E files must have the extension .3E in order to be correctly loaded.  Note:  The table does not reflect the fact that currently shipping firmware will allow the use of 256k .3E ROMs.

 

I really need to send mine in for a FW update... Keep meaning to do it and I just squirrel moment onto other things.

 

[+MacRorie]

3 minutes ago, -^CrossBow^- said:

I really need to send mine in for a FW update... Keep meaning to do it and I just squirrel moment onto other things.

 

I hear that.  Seems like time is moving faster all the time

[DirtyHairy]

9 hours ago, Karl G said:

Are 128K ROMs supported on the 2600? The website says up to 64K but I just wanted to make sure. If 128K is supported, which bankswitching schemes are compatible? I tried a DFSC ROM with no luck.  Thanks!

They are definitely supported. I am not 100% sure about which firmwares @MacRorie currently lets you choose from, but the more recent once that supports @ZackAttack's ACE format also contains supports for 3F and 3E images with up to 512k RAM. I just checked (I haven't touched the firmware in a while), but my own fork also supports BF/BFSC images with 256k ROM.

 

Now that the Pink Panther prototype is released, I'd also like to add support for the related banking scheme. Adding DF(SC) should be a trivial modification of BF(SC), so I'll go for an update that supports BF(SC), DF(SC) and Pink Panther.

[+MacRorie]

40 minutes ago, DirtyHairy said:

They are definitely supported. I am not 100% sure about which firmwares @MacRorie currently lets you choose from, but the more recent once that supports @ZackAttack's ACE format also contains supports for 3F and 3E images with up to 512k RAM. I just checked (I haven't touched the firmware in a while), but my own fork also supports BF/BFSC images with 256k ROM.

 

Now that the Pink Panther prototype is released, I'd also like to add support for the related banking scheme. Adding DF(SC) should be a trivial modification of BF(SC), so I'll go for an update that supports BF(SC), DF(SC) and Pink Panther.

If the most current version of firmware is the 09 Oct 2018 version then that is what carts are currently being shipped with.  I will update the manual to note that it does BF/BFSC up to 256k

 

[Shawn]

I'm surprised it hasn't been mentioned yet... so.... Any plans on implementing support for Pink Panther?

[+MacRorie]

1 hour ago, DirtyHairy said:

They are definitely supported. I am not 100% sure about which firmwares @MacRorie currently lets you choose from, but the more recent once that supports @ZackAttack's ACE format also contains supports for 3F and 3E images with up to 512k RAM. I just checked (I haven't touched the firmware in a while), but my own fork also supports BF/BFSC images with 256k ROM.

 

Now that the Pink Panther prototype is released, I'd also like to add support for the related banking scheme. Adding DF(SC) should be a trivial modification of BF(SC), so I'll go for an update that supports BF(SC), DF(SC) and Pink Panther.

 

Just now, Shawn said:

I'm surprised it hasn't been mentioned yet... so.... Any plans on implementing support for Pink Panther?

DirtyHairy seems to be on it!