Jump to content

electrotrains

Members
  • Posts

    375
  • Joined

  • Last visited

  • Days Won

    3

electrotrains last won the day on May 23 2023

electrotrains had the most liked content!

2 Followers

About electrotrains

  • Birthday 07/28/1972

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Scotland

Recent Profile Visitors

11,204 profile views

electrotrains's Achievements

Moonsweeper

Moonsweeper (5/9)

903

Reputation

  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
×
×
  • Create New...