Jump to content

electrotrains

Members
  • Posts

    376
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by electrotrains

  1. Updated version of PCB & 3d Print files now uploaded to the github site: https://github.com/robinhedwards/A8PicoCart This rotates the purple pico by 90 degrees to make it physically impossible to connect USB when the cartridge is inserted in an Atari. This removes any risk of accidental damage to the Atari by back-powering via USB. I've also updated the firmware (& source code) to support Microcalc (Car type 52). Manual also revised slightly. Anything confusing or missing, let me know. Robin
  2. @Wrathchild that's a VERY impressive demo, which I don't think I'd seen before. The 3d is being rendered on the pico? (i.e. its not just a slideshow?). Might be worth posting it as a top-level thread in its own right, so it can get the attention it deserves! Robin
  3. The SRAM used on the Ultimate Cart has a parallel interface which is going to be way quicker than any SPI device. But parallel SRAM needs a shedload of pins and isn't really suitable for hooking up to a microcontroller, unless it is has been desigined with a interface (some of the STMicro parts are), but not the RP2040. Robin EDIT - with any luck, Raspberry Pi foundation will release a future microcontroller with more SRAM on board. Then it will be easy to provide 1meg cartridge support and match the functionality of the Ultimate cart. Some of the STM32H7 devices already have 1 meg SRAM, but they are not very cheap. I did consider doing a cartridge board with one of them a while back.
  4. Don't have any direct experience of it, but I reckon SPI SRAM will be too slow. It's not great for the random access which you need for this purpose. The part you listed runs at 133Mhz, but looks like it requires about 50 clock cycles to set up the read, then read the byte out. Think that works out about 350ns latency. That's way slower than a read from the SRAM on the RP2040 itself. You've got something like 200ns (I forget the exact figure) from reading an address to getting the data on the bus. The SRAM i used for the ultimate cart had something like a 50ns latency, and I was working with an FPGA so passing this on to the cartridge port was fast. Robin
  5. @bfollowell I've just tested the firmware uf2 file on my github page with a "fresh out the bag" purple pico, and it flashed fine, and remounted as A8-PICOCART, with the WELCOME.TXT file visible. So the firmware uf2 file on github is fine. Are you sure you downloaded a binary copy of the file from github? It sounds like the behaviour you saw can happen if the uf2 file is corrupt. I also noticed a post saying that a security feature that encrypts USB drives can cause this problem. Can you try on a different PC/OS? Do your unprogrammed purple picos flash the LED when connected to power? (without BOOTSEL pressed). Mine were factory programmed with firmware to flash the LED. Or do they show up as a USB device under windows? Robin
  6. Should be doable, relatively easy even. There is 264k of RAM on the microcontroller, and I don't think the firmware uses much of that. I think the main thing that put me off from doing this on the UnoCart was that my 6502 coding skills are pretty poor, and I couldn't face trying to write a multiple cartridge selection interface for the menu! Plus I mainly use the carts to play games, so I didn't have a great deal of motivation to do it. Robin
  7. The cartridge port is fully hooked up to the RP2040 - no signals missing, as with the Ultimate Cart. Main issue is memory - I put 1meg of SRAM on the Ultimate cart, so I could support 1meg (8mbit) AtariMax carts. RP2040 only has 264k of SRAM, limiting the maximum cartridge size. The flash (which is more plentiful) is too slow (from my experiments anyway) to service the atari bus. Robin
  8. New shell, showing the cutout for the USB cable near the edge connector: End view - it should be pretty much impossible to connect USB when this is inserted in your Atari! 🙂 New PCB (bottom side):
  9. Hi all, I got my new PCBs from China today, and the simple modification to the design works well. I've also tweaked the shell with the USB cutout in the new position. I'll post some pics later on. New version of the PCB (& gerbers) and STL files will be posted to github over the weekend probably. Also, I got 15 PCBs from Elecrow (for less than £5!) and I've got a few purple pico clones left over from my experiments, so if anybody in the UK wants a full cart with the new safer design (and 3d printed shell) then please PM me, since I might as well use up the spare bits and some of the purple PLA I purchased for the project! Robin
  10. I did a new version of the PCB last weekend which has the purple pico rotated by 90 degrees with the USB pointed downwards towards the cartridge port. My new boards shipped from China this morning, so I expect to have them in a week or so. Assuming they work fine, I'll post the new version of the PCB & gerber files on github, along with new STL files for the 3d printed shell. So if you were planning to get PCBs made, you might want to hold off for a week or so. (For those that haven't read the whole thread, the reason for this redesign is to physically prevent USB connection when the cartridge is plugged into the Atari. That removes the need for any extra components to protect the atari in the event that the device gets power through USB while connected to an unpowered Atari, and keeps it a simple and cheap build.) Robin
  11. Hi - I have been trying to PM you - is your inbox full?

    1. Wrathchild

      Wrathchild

      yep, I'll sort that out now

  12. Hi all, sorry no news on the 2600 version of this cart. Although it works fine on my 2600 Jr, the test devices I sent didn't work on other peoples 2600's, which was unexpected and took the wind out my sails. I suspect it may be because these other 2600's boot more quickly than mine, and the pico hasn't had a chance to fully initialise before the atari starts reading from the cartridge. But that's speculation until I can do more testing with a scope. So, I'll come back to this version when I've finished with the Atari 8-bit version. Robin
  13. You should be fine - I've just checked my parts drawer and I'm pretty sure when I was prototyping I used a pack of 30cm long F-F jumper wires. Worked perfectly. The main problem is the cables coming loose rather than the wire length in my experience. Robin
  14. I quite like the idea of the pico rotated by 90 degrees such that the USB socket is pointing downwards towards the cartridge port. I've had a quick look at the shell and it looks like I can accomodate that without too many changes. There don't seem to be any major downsides to this approach for the standalone cartridge. Stay tuned. Robin
  15. I agree this is a possible scenario. I'm somewhat inclined to follow your suggestion and remove the USB access from the cartridge shell. This seems like the only simple approach. Any other solution I think will require both the protection diode, and some extra circuitry (another IC) to prevent RD4/RD5 being powered when the device is plugged into USB and the atari is then powered off. This is the reason I left this stuff out - it was about to stop being a simple build, and I thought just telling people never to plug into USB when inserted in an Atari was an acceptable solution. Robin
  16. @mytek Yes, I had considered resistors on RD4/5 (along with the diode) - then, like you, I noticed the internal resistors on the Atari main board schematic and reaslised the simple approach wouldn't work. I'm afraid you are overstating what the firmware currently does - at the moment when the pico boots, it checks for 100ms for the atari clock before going into cartridge mode or mass storage mode. Once in either mode, it remains there. The situation I was concerned about was this: power up Atari with cart plugged in -> firmware cartridge mode, RD4/5 high -> plug in USB -> power off Atari -> voltage applied to RD4/5 in unpowered Atari.
  17. The aim of the project was to make an easy to assemble and very inexpensive multicart with minimal components. Others are free to improve the design at the cost of complexity of build... Having said that, I did consider adding the diode - but I'm not sure that the diode alone will offer complete protection... I managed to kill my 65XE early in my cartridge experiments by powering up a DIY cartridge before powering up the Atari - even though 5V was not connected to the cartridge port. Enough power was supplied from the cartridge through RD4/RD5 to fry the Atari MMU. So powering up the Pico board (by USB) when plugged into an Atari - even if the diode on 5V is added - still has the potential to damage the Atari if any of the GPIO pins on the Pico are not in high impedence (input) mode. (At the moment the firmware decides to go into cartridge mode if it detects the atari clock signal on an input pin within 100ms after boot. Otherwise it goes into USB mass storage mode.) Any thoughts mytek?
  18. I've uploaded a zip of the gerbers I used for Elecrow (XL/XE cased version of PCB). Hope this helps, https://github.com/robinhedwards/A8PicoCart/tree/main/pcbs/XL or XE version (fits case) Robin
  19. The OS source is here: https://github.com/robinhedwards/UnoCart/tree/master/source/Atari/UnoCartOS (A8PicoCart uses the same ROM for this) Robin
  20. Hi All, Sorry for the delay. It took me a little while to write up the project. You can find all the files (& source) for the project on the new github page: https://github.com/robinhedwards/A8PicoCart I don't think I'm going to do a production run this time to recover costs, so please consider donating if you build and enjoy one of these nice little devices 🙂 EDIT - if you spot any typos, mistakes or something needs more explanation - please ask and I'll update the page. Regards, Robin
  21. Hi All, Sorry for the lack of updates recently - I've been having an issue with my health, but hopefully normal service will be resumed soon. Since both the carts I got round to sending out to testers have worked fine on a variety of XL/XEs (NTSC and PAL), I'll probably see about open sourcing the design and code fairly soon. It doesn't seem to work on original 400/800's but I seem to remember this was the case with the UnoCart, so not unexpected. I don't have one to test with, so there won't be any progress on that front in the short term, but once it's open source.... As far as ATR support goes, it's going to be a bit hit and miss since as noted above its using a soft-OS approach based on Altirra OS. It should however, be exactly as compatible as the original UnoCart, since the code is pretty much the same. Robin
  22. Completely different in approach: Ultimate Cart uses an FPGA to emulate cartridges and had 1meg of SRAM on board. There is also a 'soft'-cpu running on the FPGA which copies data from the FAT formatted SD card into SRAM. UnoCart is a standard microcontroller, using polling to monitor the bus and fetch data from the on-board SRAM (which is only a bit more than 128k). Both used SD-cards. Main difference for a user is that Ultimate Cart can emulate 1 meg AtariMax cartridges (e.g. Space Harrier) and UnoCart can't. UnoCart can however do ATR files, which aren't possible in the Ultimate Cart since I ran out of space in the FPGA to support writing to the SD card. I suspect it could probably be made to fit with some rearranging of the software components though - I've just never got round to it. Not sure about the Pi-zero approach. Might work if you can twiddle the GPIO fast enough to keep up with the bus, and the RAM is fast enough. How long does linux take to boot? Might need to be bare-metal (no OS). Suspect even bare-metal wouldn't boot fast enough for the Atari though.... Robin
  23. Intention is to release everything, source code, gerbers, 3d print files etc etc, as with my previous Ultimate Cart project. But first I may try to sell a few completed carts to those interested to recoup project costs. But we're not at that point yet - I'm planning to send a few out to testers soon, since I want to make sure it works well on a variety of machines (NTSC is untested), and that I haven't missed anything in the cartridge emulation. Currently waiting for a new version of the 2600 PCB and purple pico's for the 8-bit version to arrive from China, plus I've been printing shells for testers that will need one. I did finally test it on my 800XL last night now that I've got a shell for it, worked perfectly which was a relief since I'd only tested it on a 65XE up to now.
  24. This is the 3d printed case (modifed from my Ultimate Cart shell), but much more robust screw holes to hold it together.
×
×
  • Create New...