Jump to content

electrotrains

Members
  • Posts

    375
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by electrotrains

  1. I think we talked about this earlier in the thread? You've got something 200ns to get data on the bus after the address lines are stable. This is an interesting thread discussing the issue (using a gameboy): https://forums.raspberrypi.com/viewtopic.php?t=321846 (Looks like he got it working - though is running a faster overclock that I am) Another issue is that some of the purple pico clones come with slower (z-bit) flash rather than the "standard" winbond chip. I had to change the flash divisor on the project to make it work with this flash. So any solution might not work on some of the purple picos. But the above linked thread looks like a good place to start if you want to try to get this working. Robin
  2. It sounds like it would be doable to get this working on the 400/800. First, there is an issue probably with boot speed which is faster on these machines, and it sounds like the picocart firmware doesn’t get enough time to load from the onboard flash before the Atari starts making requests from the cart port. Some kind of two stage firmware boot might fix this, but hard to be sure. Second there is some issue with the cart/atari comms which is probably easier to fix. The firmware uses reads/writes to $d500 (cctl) to manage this. But… Without a 400/800 to experiment with, I’m unlikely to be able to resolve either. If someone in the UK was willing to lend me one, then I could have a go - though unfortunately my day job looks like its going to be a lot more demanding for the forseeable future, so I’m unwilling to commit to this right now. Maybe someone else can have a go… happy to provide suggestions and assistance if so, feel free to PM. Robin
  3. Yeah, the same idea had crossed my mind, and I ruled it out as impractical 🙂 However, if the game had been coded with the architecture in mind, you could make a VERY big bankswitching cart using the pico. Robin
  4. Sorry been away for a few weeks - just catching up. I think the on-board SPI flash is too slow to provide random access for the Atari. Hence ROMs must be copied to RAM first, and therefore a limit on the size of emulated cart to 128k. I did a few experiments but never got it running from flash. Its possible there is some other approach that might make it work, but I haven't found it. Robin
  5. 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
  6. 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
  7. @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.
  8. @Fred_M you are welcome! The labels are very nice. Would you mind if I uploaded them to the github so others can use them? I might do another version of the STL without the cutout to match these labels better. Give me a few more days to get any other feedback on the loader version of the firmware, and I will perhaps do a revised version. I might just put the firmware cartridge code back to the Phi2 version, if it doesn't help with the 400/800. Btw - the loader version of the firmware is fully self contained - so you can program a fresh pico with it, use the USB mass storage mode to copy a CAR file to the device - there's no need to put the normal firmware on at all if it the multicart aspect is not desired. Robin
  9. Okay, doesn't sound like I've improved things on 400/800 then 😞 Robin
  10. Okay, I've had a filddle with this, and rather than modify the existing firmware, please find attached a single cart version of the firmware. If you put a file named "AUTORUN.CAR" or "AUTORUN.ROM" in the root directory, it will run automatically on power up. Identification rules for ROMs as described in the manual (standard 8K & 16K or XEGs is assumed depending on the file size). If you want a different type (e.g. 128K AtariMax) - use a CAR file. It will leave any other files you have on the flash alone, so you can try out the new firmware and then flash the standard firmware back and be back where you started. Didn't have time to do XEX files this weekend - maybe later if demand. If you want to use this commercially to release games, I expect a donation to the project, and I will customise or remove the "A8PicoCart Loader" line if required 🙂 Why didn't I add to the existing firmware? I didn't want to make a mess since its not a trivial change to do nicely. This way I can go straight to a simple boot loader from the cart init vector (before the OS initialises the screen editor), so you don't get the "blue flash" when the cartridge starts. I've also recoded the Atari<->A8PicoCart interaction, so there is more hope it will work on an 400/800 since I'm not using Phi2 for the menu. There is also a bit less data (e.g. no ATR OS.ROM) so firmware might load fast enough onto the Pico such that a 400/800 doesn't need a manual push of the reset button. Any feedback on whether this actually works on an unmodified 400/800 would be appreciated. Regards, Robin a8_pico_loader.uf2
  11. You can't use sleep_us() because the loop has to be actively responding to requests from the cartridge port. Have a look at the functions in the time.h API provided, something like this (untested)... // get the time 2 secs from now absolute_time_t stopTime = delayed_by_ms(get_absolute_time(), 2000); RD5_HIGH .. while (get_absolute_time() < stopTime) { // Emulate cart .. } RD5_LOW I don't think I'll be adding this to the "official" firmware - it's just a bit too niche usage, and there isn't an existing defined CAR type that does this. But obviously, feel free to create your own version with this behaviour. Robin
  12. @dabone your boards (& shells) look really good! If you're selling them for $15 I guess you're not going to be doing much more than covering your costs & time, but can you consider making a donation to the project and including that in the total selling price, rather than leaving it to your purchasers to donate? That applies to anyone doing a run of boards for sale - please consider making a donation to the project (via the button on the github page) - I spent a good number of evenings writing the software, testing and making the cart shell design and while I'm not doing this for profit, its good to have a little money in my paypal account for when I'm gripped by the next idea for a project.
  13. Sorry for the delayed reply. Feel free to PM me the code/changes. Might be worth posting the uf2 file so others can have a play with the proposed firmware changes. Robin
  14. I think that's quite likely. I seem to remember something similar was reported with one of my earlier cart designs on the 400/800 - didn't work, but did if you press RESET on the atari. The menu not being very stable is likely to be due to a different clock signal on the 800 cart port (RAS? instead of PHI2). I think some kind of mod is possible to subsitute the signals, but I wouldn't want anyone to have to modify their hardware. Sadly, unless someone in the UK feels like lending me their 400/800 for a bit, so I can test and debug, I'm unlikely to be able to fix. But since its open source, maybe someone else with the ability will be able to take a look? Robin
  15. Looking at your photos - it looks possibly like you may have bridged two of the pico pins adjacent to the the word "TOP" on the PCB. The soldering looks a bit uneven in general, I suspect the problem lies there. EDIT - if you can try taking some more photos top and bottom with slightly sharper focus it might help diagnose. Robin
  16. That's all completely normal. With the A8PicoCart firmware - there's one meg reserved for the firmware itself, and the other 15 megs allocated for the filesystem (which is what windows can see).
  17. (1) Did the board mount as A8-PICOCART after you flashed the uf2 firmware file? (2) Check continuity (if you have multimeter) between the pins on the pico and the corresponding pads on the cartridge edge connector. (3) Check you've got no shorts between adjacent pins (again with a multimeter). (4) Check for any blobs of solder on the PCB and the pico itself. Failing that, you could set pico GPIO pin to alternate between high & low in turn (you'll need to write some code) and check you can see 3.3v and 0v on the corresponding pad. Or just start again with a new pico... 😞 But the only one I made that didn't work first time I'd forgotten to solder a pin on the pico. I've never had to re-insert or move the cartridge to get it to work. The edge connector is one I've used for previous cart designs and I think its pretty well lined up.
  18. I've had boards with both winbond and zbit - no obvious difference in price, and they are both 16meg. The firmware was initially developed on a board with winbond flash - I had to make a few changes to get it to work with zbit ones (its rated slightly slower). But its been fully tested with both types. Robin
  19. If you want a new CX40, there is also: https://atari.com/products/cx40-joystick Hoping the build quality will be ok - I've ordered one from amazon.co.uk since my original is on its last legs - due for release in a couple of weeks (in the UK anyway). Robin
  20. @mytek no problem. looking at the pico code, X to disable the picocart just sets RD4/5 low, then goes into an infinite loop. On the 6502 side it sents a message to the cart to do the above, then does a cold restart (jmp $E477). Its not clear to me at the moment why this would cause a problem. Edit - I see @Wrathchild posted similar. thanks!
  21. @mytek how are RD4/5 & S4/S5 connected to the MMU in your system? Just directly connected to the equivalent pins on the pico? Is there a schematic I can look at?
  22. I'm not sure I fully understand (I've never had a XEGS). The Altirra OS is used ONLY when an ATR is selected from the A8PicoCart menu - at all other points the system's OS is being used. So during boot, menu display, XEX/CAR selected, or X - picocart disabled - its just using the system OS. Are you saying that when you select the game slot (missile command) that the Pico menu is displayed instead, when the system boots? Can this happen on a normal XEGS? i.e. playing missile command despite a different cart being inserted? Or is it PicoCart ATR mode you are talking about? Robin
  23. @Overange That's a perfectly do-able approach. The reason I designed it with a seperate logo piece was because I wanted the logo picked out in white against a different coloured background, which can be done by changing the filament at a specificed z level. But there's no way to do that with the imprint approach you suggest. Robin
  24. 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
×
×
  • Create New...