A8PicoCart - UnoCart on a Raspberry Pi Pico

[ascrnet]

16 hours ago, akator said:

I'm curious how others are using their A8PicoCarts.  Are you only using cart formatted files?  Is it your testing cart for new releases?  Perhaps you're only putting your favorites on it?

this cartridge is my favorite for the reason that we have available the firmware source codes and it is also low cost.

 

Before my favorite was ultimate cart for the same reason, but it got damaged "I still have to revive it".😅

 

So with a little study you can add emulation support for strange or unwanted cartridges. 🤩

[mozzwald]

I've modified the A8PicoCart design to prevent back powering the Atari if USB is connected by adding a single schottky diode. The board was redone so the Pico USB-C port is on the top of the cartridge where it's easily accessible. Cart reset button is also on the top edge. The cart shell is modified to accommodate the changes and adds a hole/button to the back for the BOOTSEL button. I happen to have a dual extruder 3D printer so I made the logo printable in 2 colors in one pass. It could be easily modified to use the already available logo plate. I also created a 3D printable jig for sanding a bevel on the PCB edge which is in the repo. 

 

I had 10 boards made which I don't need all of them so made up the rest and they're up on my site for sale. Cart is dark brown with bone white inlay around the logo. A portion of the sale will go to @electrotrains.

 

My idea behind this is that having the USB port connected while the cart is in the Atari, you could do more with it. For example, you could load cart images directly from a PC. Or a FujiNet type cart could be made where it connects to an esp32 and network access is provided. Of course, this would all need implemented in the firmware.

 

https://github.com/mozzwald/A8PicoCart/tree/main/pcbs/mozzwald-edition

 

 

[electrotrains]

@mozzwald be aware that the addition of the diode is not sufficent to completely protect the atari from being backpowered. Specifically through the RD4/RD5 pins. The firmware would have to be significantly modified to remove this risk.

 

I killed the MMU in my 65XE several years ago (early in my cartridge experiments) by applying 5v to RD4/RD5 when the atari was not powered up, so it was on my mind when developing this cartridge given the dual USB/Atari power supply aspect to it.

 

There's a fuller discussion between myself and @mytek about this on page 6 of this thread.

[electrotrains]

Just to add more explanation to the danger scenario I outlined in my post on page 6:

 

1. power up Atari with cart plugged in - the firmware goes into cartridge emulation mode (RD4/5 high)

2. plug in USB

3. power off Atari - cartridge still powered by USB so firmware remains in cartridge emulation loop with RD4/5 high.

 

The end result is voltage applied to RD4/5 in an unpowered Atari.

Whether the current and voltage (3.3V) delivered by the pico GPIO will be sufficient to fry the MMU - I don't know - but I wasn't willing to do that particular test 🙂

 

To fix this, you'd need to drop out of the emulation loops (there are quite a few of them) as soon as you knew the Atari had been switched off. Possibly by detecting the lack of a Phi2? At present the cart decides whether to go into mass storage mode or cartridge emulation mode once only - when the firmware first boots (by looking for phi2 for the first 100ms).

 

Robin

[+mytek]

41 minutes ago, electrotrains said:

@mozzwald be aware that the addition of the diode is not sufficent to completely protect the atari from being backpowered. Specifically through the RD4/RD5 pins. The firmware would have to be significantly modified to remove this risk.

 

I killed the MMU in my 65XE several years ago (early in my cartridge experiments) by applying 5v to RD4/RD5 when the atari was not powered up, so it was on my mind when developing this cartridge given the dual USB/Atari power supply aspect to it.

 

There's a fuller discussion between myself and @mytek about this on page 6 of this thread.

I implemented full protection in my upcoming NUCplus4 daughter board for the 576NUC+.

 

 

It's been tested quite extensively at this point, and does allow for files to be uploaded, moved, or deleted in the A8Pico when the Atari is powered (or un-powered). However if you wish to update the firmware in the A8Pico the Atari power does need to be off, with the USB supplying the +5V. No damage will be done if the Atari power is still present, it just won't initiate a firmware upload.

[+mytek]

On 12/4/2023 at 4:41 PM, manterola said:

I have modified the copy of the conversion table (from internal? code to ATASCII) so now it should work. Please try this latest version. This does not include the latest additions (like the autorun.car feature). 

a8_pico_cart.uf2 191 kB · 3 downloads

It works

 

Thank you

 

 

EDIT: Oh I just discovered that the Left Arrow functions as the BACK key same as the 'B' key - Nice

 

Any possibility of getting the Home and End keys to jump to the very beginning and the very end of a directory? No biggie if it would be too complicated to implement, but it would be nice especially if there were a ton of files

[manterola]

13 minutes ago, mytek said:

It works

 

Thank you

 

 

EDIT: Oh I just discovered that the Left Arrow functions as the BACK key same as the 'B' key - Nice

 

Any possibility of getting the Home and End keys to jump to the very beginning and the very end of a directory? No biggie if it would be too complicated to implement, but it would be nice especially if there were a ton of files

I don't think is would be hard to implement.

Notice that the cart menu uses a byte to store the selected item. Therefore, the list displayed has only 255 items, even when the folder has more items. 

Still everything works, and the missing items can be found using search (ESC or / key).

 

 

[mozzwald]

1 hour ago, electrotrains said:

@mozzwald be aware that the addition of the diode is not sufficent to completely protect the atari from being backpowered. Specifically through the RD4/RD5 pins. The firmware would have to be significantly modified to remove this risk.

 

I killed the MMU in my 65XE several years ago (early in my cartridge experiments) by applying 5v to RD4/RD5 when the atari was not powered up, so it was on my mind when developing this cartridge given the dual USB/Atari power supply aspect to it.

 

There's a fuller discussion between myself and @mytek about this on page 6 of this thread.

Ok, I seem to have missed the memo on this bit of info. I'll figure out a way to separate them when Atari is off. Thanks for letting me know so quickly

[manterola]

I also added the diode in my design, but then I read the whole thread here, understood and I basically just installed a jumper instead. That's why making the USB port point down is critical to ensure nobody will plug the USB while the cartridge is inserted in the Atari computer.

Since my PCB design was sized for the classic brown cartridge case i couldn't do that, and it is pointing to one size.

[ascrnet]

I have already sent support for two new cartridges, I hope @electrotrains reviews them and accepts them so that everyone can use them in the future. 😎

[mozzwald]

I came up with this fix an applied it to my cart. Two N-FETs are controlled by the GPIO for RD4/5 and the Atari 5V line supplies the signal. If the Atari is turned off, the Atari 5V line will not have any power and thus no power on the signal lines. I confirmed it works by testing with a modified firmware that toggled the RD4/5 pins every 2 seconds and without the Atari 5V line, no power was on RD4/5.

 

I'll apply this fix to the other boards I already made. I'm currently using small SMD parts but will try to find some through hole ones if I can for those wanting to make their own and update my repo.

[+mytek]

On 12/7/2023 at 4:51 PM, mozzwald said:

I came up with this fix an applied it to my cart. Two N-FETs are controlled by the GPIO for RD4/5 and the Atari 5V line supplies the signal. If the Atari is turned off, the Atari 5V line will not have any power and thus no power on the signal lines. I confirmed it works by testing with a modified firmware that toggled the RD4/5 pins every 2 seconds and without the Atari 5V line, no power was on RD4/5.

Nice simple fix 👍

 

A little bit different logic than what I did, but still accomplishes the same thing and this would have worked as well on my project too. However since I needed one additional switch for another unrelated purpose the 74HCT4053 I used gave me that.

 

EDIT: mozzwald's fix could be integrated into the official A8Pico Cart, and then flip the Pi Pico board 180 and allow the USB to be connected externally through the top of the cart. That way it could be left connected without issue, and allow for safe updating of the files even with the cart plugged into the Atari. Or just go with the cart design that mozzwald has already created

[electrotrains]

4 hours ago, mytek said:

EDIT: mozzwald's fix could be integrated into the official A8Pico Cart, and then flip the Pi Pico board 180 and allow the USB to be connected externally through the top of the cart. That way it could be left connected without issue, and allow for safe updating of the files even with the cart plugged into the Atari. Or just go with the cart design that mozzwald has already created

 

Happy for others to add to and fork the design.

 

But with the pico USB port pointing down, there is no risk of damage to the Atari, and no additonal components need to be purchased.

 

And I want to keep the "official" A8PicoCart true to the original design goals i.e. a very cheap multicart that anyone with basic soldering skills could make themselves, and required no additional components beyond the pico clone.

 

Robin

[Mq.]

I know that changes to menu navigation keys are being discussed.

May I suggest menu improvements to consider when updating the firmware?

 

1. Menu operation using joystick.
Currently, you can navigate through the "up-down" menu. The fire button enters the folder or starts the game.
It would be useful to be able to move to the upper folder with a joystick, e.g. by moving the joystick to the left. This is missing for complete joystick folder navigation.

 

2. Returning to the folder above by pressing the "B" key is unintuitive. Maybe the "Bk Sp" key would be better? Or "Esc" for the folder up, and then "F" for the find function.

 

3. When there are many items in a folder, it would be useful to be able to skip entire pages (pg-up, pg-dn).

The keys are obvious, but the pg-dn function could also be assigned to moving the joystick to the right.

 

4. When we have the first item highlighted in the menu list and move up, we could scroll around the list to the last item on the last page.
Similarly, when we are at the last position of the last page, then a further move down could scroll the list to the first position of the first page.

 

I think such improvements are quite simple to implement, so please consider them or your own similar if you like my proposals.

 

A different question. Why there is xex file limit to 128kB? I know there is memory limitation, but is it exact 128kB? If there is maybe possible to serve bigger files of unusual length, then every byte more would be useful.

 

PS. I apologize for writing it down in bullet points as if it were my wish list. It's not like that, but I've been using A8PicoCart a lot lately, so things like this come to my mind. I thought that such user comments might be useful.

Edited December 9, 2023 by Mq.

[+mytek]

3 hours ago, Mq. said:

2. Returning to the folder above by pressing the "B" key is unintuitive. Maybe the "Bk Sp" key would be better? Or "Esc" for the folder up, and then "F" for the find function.

I suggested this a while back as well. This would mimic the SDrive menu functions: Escape for back, and "F" for Find. Be nice to have them match when going back and forth.  EDIT: FujiNet also uses "F" for their Find function.

 

EDIT: Unfortunately we see lots of variations on how to do the same thing. TK-II which has been around since 2015, also gets shoved to the back of the bus and rarely has its Page-Up, Page-Down, Home, End keys utilized. Also there is a nasty habit in some Multi-Carts (as well as the stock SDrive menu) to either only recognize arrow keys without CTRL, and worse yet have CTRL+Arrows equate to something else entirely. @flashjazzcat was very good about supporting the TK-II PS/2 keyboard navigation keys out of the box many years ago in the U1MB and Loader menus, as well as having non-CTRLed and CTRLed arrow keys work the same. I'd like to think this was planned, and maybe it was, but I suspect that it was lucky coincidence that we both assigned the 1200XL's shifted F1-F4 keys to the same functions. This can also be seen in The Last Word.

[Bee]

Side note- It looks like the beveled edges in the PBC is done by running a v bit down the length of the exposed edge and then flipped to run the other side, probably on a cnc router but it could be done by hand with a jig pretty easily.  I hope that helps some of you.

 

Thank you

[manterola]

This version (should) supports TK-II Home End buttons, besides the PageUp and PageDn added last week. Please test it.

Remember that it also supports PageUp and PageDn by using < and > keys.

 a8_pico_cart_with_home-end.uf2

Edited December 11, 2023 by manterola

[+mytek]

6 hours ago, manterola said:

This version (should) supports TK-II Home End buttons, besides the PageUp and PageDn added last week. Please test it.

Remember that it also supports PageUp and PageDn by using < and > keys.

  a8_pico_cart_with_home-end.uf2 191 kB · 0 downloads

I'll test it tonight when I get to my destination (heading up the mountain to my vacation home in the woods).

 

Thank you

 

EDIT: Well I thought I had a PS/2 keyboard up here, but I can't find it. Looks like I'll have to hit the thrift stores tomorrow morning, and hopefully find one.

[mozzwald]

On 12/7/2023 at 6:51 PM, mozzwald said:

I'm currently using small SMD parts but will try to find some through hole ones if I can for those wanting to make their own and update my repo.

I ended up finding a TO-92 package (through hole) MOSFET part number BS170 that work and have bodged them on a board for testing. Looks good for RD4/5. I did some other testing and when mass storage mode is activated on the RP2040, GPIO0 gets turned on with high output by the USB stack. I added a few lines after the USB init to turn off GPIO0. Not sure why it enables it and makes it high, but I had no issues with file transfer after turning off GPIO0. 

 

PCB design files have been updated in my repo with the additional FETs but I have not had any made to confirm they work. Firmware source with USB/GPIO0 fix and flashable binary are also in the repo.

 

https://github.com/mozzwald/A8PicoCart

[KRG-Rosa]

I have a question, is there or will there be a possibility to play Car files larger than 128kb?

[spicyjack]

Yeah, so I just did this...

 

 

If you have any questions, please ask me in that thread.

[+mytek]

On 12/11/2023 at 2:02 PM, mytek said:

I'll test it tonight when I get to my destination (heading up the mountain to my vacation home in the woods).

 

Thank you

 

EDIT: Well I thought I had a PS/2 keyboard up here, but I can't find it. Looks like I'll have to hit the thrift stores tomorrow morning, and hopefully find one.

I got a keyboard and was able to test the new combined TK-II PS/2 keyboard Page-Up, Page-Down, Home, and End menu navigation and It all works great

 

Thank you ever so much

[ivop]

On 5/27/2023 at 1:10 PM, electrotrains said:

I started the project after reading that the Pico was probably 5v tolerant.

For a different projected I investigated this, and it's not exactly 5V tolerant. According to Raspberry Pi's Eben Upton it's only 5V tolerant for input pins (excluding the ADC pins), not for output pins. So that's fine for an XE with a floating data bus, but not on an XL where the data bus is pulled high. It might work fine now, but it is definitely stressing the pins and it will eventually damage the oxide layer. Also, inputs are only 5V tolerant when VDDIO is 5V, and there's a non-zero time between VSYS being 5V and VDDIO being 5V. Applying 5V to an input pin before that might cause damage in the long run, too. There are already reports of people pulling up SCL and SDA to 5V to access I2C sensors and eventually experiencing problems. So IMHO using this in an XL is not entirely safe unless you cut the pullups on the motherboard.

[+mytek]

1 hour ago, ivop said:

So that's fine for an XE with a floating data bus, but not on an XL where the data bus is pulled high.

I hear your concern, but with a 4.7K pull-up you're looking at 1 ma max available current which would be pretty hard pressed to blow or damage the input protection circuit. We have yet to see any reports of failing A8Pico Carts, and they have been in the wild for several months now.

[ivop]

21 hours ago, mytek said:

I hear your concern, but with a 4.7K pull-up you're looking at 1 ma max available current which would be pretty hard pressed to blow or damage the input protection circuit. We have yet to see any reports of failing A8Pico Carts, and they have been in the wild for several months now.

Series resistors don't help to protect the RP2040. It is voltage that overstress the internal transistors, not current. It might take days, weeks, months, but it will die.

As for carts currently in the wild, I don't think they have ran thousands of hours in an XL machine yet, continuously supplying 5V to output pins.

 

It's not my intention to be a "party pooper", but I'm concerned that if I design something that sits on the bus 24/7 it's not solid enough for an XL machine. I'm looking into other solutions now. Perhaps the Teensy 4.1 with level shifters, or something in between (price wise).