ZackAttack
-
Posts
856 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by ZackAttack
-
-
On 4/21/2024 at 2:37 PM, Al_Nafuur said:
Everyone else who knows how to flash the PlusCart with STM32CubeProgrammer can test too.
I flashed my plus cart with 2.3.18 and it works well with the non-elf banking schemes. The elf based ones are coming back with an error. I think it may download a little different than the other schemes and could require a similar workaround too?
-
95 is my best so far. The longer delays when the frog watches you really make for some nail-biting moments. I'm not even mad at him for eating me just before I broke into triple digits.
-
1
-
-
On 10/11/2023 at 9:38 AM, -^CrossBow^- said:
Um... what about supporting the supercharger multi load games? Because, that isn't working on the current FW I have on my UNO either? Just causes crashes when trying to load up the next part of Survival Island for instance.
Looks like the changes to the supercharger support in the standard firmware could be made in UCA pretty easily. I'll try to send you a new UCA build to test in the next week or so.
-
5
-
-
On 10/7/2023 at 1:57 PM, -^CrossBow^- said:
Any idea when this test version will become a final version for others to try out?
I have some other work in progress that I want to complete before we release a new version. Unless you're seeing glitches/crashes there isn't much point in upgrading.
-
1
-
-
On 9/28/2023 at 5:52 AM, Al_Nafuur said:
Bus stuffing is only happening on 6502 writes, correct?
Correct, currently it makes use of opcodes $84, $85, $86, and $87
On 9/28/2023 at 5:52 AM, Al_Nafuur said:how important is the (write) cycle length for bus stuffing?
At what point in the cycle is the cartridge stuffing the bus, and how does the cart detects this moment (timer or changes on the data bus)?
How long is the cart stuffing the bus (till the next address bus changes or timer)?
It polls for the zero-page address that's being stuffed and puts the value on the bus right away. The value is stuffed until the next address is put on the address bus. Only 6 of 8 bits are stuffed. The other 2 are determined by which opcode is used and what the register values are.
-
Has anyone considered how to handle the carts/games that do bus-stuffing yet?
I think it would be possible to handle with a few extra ICs between the pi3 and the cart. When putting a new address on the bus, the data that may potentially be overridden by the cart is latched to an open collector buffer. Then read in the value from the cart just as you would from a ROM access. If no bus stuffing is taking place, you'll just read back the value you latched. Otherwise, the cart has free reign to pull additional bits low.
If the pi3 was replaced with something that has a higher GPIO count, the data bus could be split so that 8 IOs are always outputting to the open collector and 8 IOs are always inputting the resulting bus value.
-
1
-
-
14 hours ago, phoenixdownita said:
Is it hard to build the rollbackTo and upgradeTo binaries to round trip with then latest UCA?
Not difficult, but it shouldn't be necessary.
22 minutes ago, -^CrossBow^- said:Seems that once you update to the UCA version it won't go back. Or at least mine just throws invalid File errors when I try to run the v18 update on my cart.
The upgraders for firmwares only work for their own type. If you're on legacy/standard firmware v17 you can run v18 updater just fine, but you can't run any of the UCA updaters. If you're on a version of the UCA firmware you can run any of the UCS updaters, but you can't run any of the legacy/standard firmware updaters directly.
To switch between the two types of firmware you should use the binaries I posted here.
17to2.3.14.bin is to convert any cart on v17 or higher of the standard/legacy firmware to UCA.
UnifiedToLegacy17.ace is to convert any cart on UCA back to the standard/legacy firmware.
After running either of those to switch which firmware you are using, you can then run the corresponding updates to get to the latest version.
-
1
-
-
Would you be able to increase the capture rate and/or zoom in? I think you need to be on a scale of 50ns or less to really see what's going on.
As far as writing the data bus too early. There is a required hold time where the data bus must remain valid for a short period after the address bus has already changed. If you're not holding for the required time, it would definitely cause problems.
-
On 8/17/2023 at 11:48 AM, Thomas Jentzsch said:
BTW: Did I miss the discussion about how the StrongARM library etc.? Or has that not been discussed at AtariAge before?
It's been so long, you probably just forgot about it. I got a little sidetracked with hardware development in my quest to make these ARM enhanced games publishable to carts, and then further sidetracked trying to make them support both 2600 and 7800. But thanks to recent collaborations there's been huge progress made and there should be some playable demos coming out later this year.
-
1
-
-
14 hours ago, Thomas Jentzsch said:
But I wonder why this is even required to that extend. Developers know that having enough CPU power can lead to lazy programming. Quite the opposite of what you would expect from a 2600 game.
Ironically, it's been the opposite for me. I tend to spend way more time than I should on the display kernels because this tech allows you to squeeze more out of the TIA.
14 hours ago, JetSetIlly said:Marco and Zack are making these games regardless of whether emulation is possible. I view my role as making their life a little easier by providing tooling to make the development cycle faster and to provide insights into what is happening in their C programs.
This is a huge understatement. I use Gopher 99% of the time and only bother testing on real hardware when I'm going to share a build with other pluscart users.
15 hours ago, Thomas Jentzsch said:Yes and no. If the emulators cannot handle these ROMs for the players, then many people will be excluded from playing them.
14 hours ago, JetSetIlly said:But I definitely take your point about being able to play the games and I'm thinking hard about how to improve the situation.
How about compiling the game and emulator to webassembly and running it in web browsers? It might just be crazy enough to work.
-
1
-
-
I think it could be helpful to test the timing of only polling for A12. Could you try the following and post the results? A logic analyzer on A12, D0, and A0-A5 would be ideal.
If the logic analyzer shows the proper execution of the "lda ($b1),y" instructions, we can start adding in the remaining functionality one piece at a time. That will greatly simplify debugging because you can isolate each change and commit every time the test passes.
#define A12_MASK 0x4000 #define MANGLE_DATA(data) ((data & 0b00011111) << 1 | (data & 0b11100000) << 3) static void Test() { // Be sure IRQ disabled __disable_irq(); // Preload data for Data Bus // Leave LDA ($b1),Y on the bus to create a nop-sled. Reset vector will be 0xb1b1 which provides some cycles to collect some timing data. // Eventually the PC will roll over and the Atari will crash. So logic analyzer and/or oscilliscope should trigger on the // First A12 rising edge after the Atari is powered on GPIOA->ODR = MANGLE_DATA(0xB1); // Bus Polling Loop while (1) { // Wait for A12 high while ((GPIOB->IDR & A12_MASK) == 0) ; // Drive Data Bus GPIOA->MODER = 0xa8150554; // 0b10101000000101010000010101010100; // Wait for A12 low while ((GPIOB->IDR & A12_MASK) != 0) ; // Release Data Bus GPIOA->MODER = 0xa0000000; // 0b10101000000000000000000000000000; } }
-
I've done something similar with the Chameleon Cart. It's using a STM32G0. If you can point me to the code I could take a look and see if anything stands out. Embedding a 4k rom as a const uint8_t[4096] and a small while loop to service the bus should be all you need to get something running.
Some things to check based on the pain of developing the Chameleon Cart:
- Disable IRQ. I've been burnt so many times by enabling them for something and forgetting to disable them again.
-
Avoid initialization of large variables to keep boot time minimal.
__attribute__((section(".noinit"))) static uint8_t playfieldBuffer[192*5];
-
It's fine to leave the 4k binary in flash memory. It's never been a problem for me.
static const int8_t rom[4096]= {...};
-
The code that services the bus should be executed from RAM. The whole zerowaitstate flash gimmick works 99.9% and that .1% will crash ruin your day. Here's what I use when I want to do a quick check with 4K rom.
__attribute__((long_call, section(".RamFunc"))) static void Emulate4K() { __disable_irq(); while (1) { if((GPIOB->IDR & 0x1000) != 0) // Assumes A0-A12 are wired to GPIOB0-12 respectively { GPIOA->MODER = DATA_OUT_MODER; // Masked with 0xfff to stay in 4kb array bounds. Can cast to int8/char if your hardware has better alignment GPIOA->ODR = ((int16_t)rom[GPIOB->IDR & 0xfff]) << 6; // Shift value depends on which GPIO pins are wired to data bus } else { GPIOA->MODER = DATA_IN_MODER; } } }
- Be aware that having the SWDIO/CLK pins on the same GPIO port as your Address Bus inputs can be problematic if you don't mask them away.
-
Each track (ttt file) will have its own instruments and percussion. They can and should use both channels, but the second channel will be overridden with sound effects as needed.
-
1 hour ago, MarcoJ said:
Hi Zack. I'm interested. Do you have the TIATracker core up and running in your build?
Yes, to swap in a new ttt file you would need to place a copy of the new ttt file in the assets/sound/ folder and replace 'glafouk - Miniblast.ttt' in source/parse_assets.py with the new file name. Then you should be able to run make to build it with the new music.
1 hour ago, nooly said:I'm interested too. I could give you some TIA and other chip musics of my present and past projects:]
That would be great.
There's support for multiple ttt files in the same project, so all contributions are welcome and appreciated!
-
@8bitPoet and I have been collaborating on a new game called Mattress Monkeys and could use some help with the background music. We only have a few remaining tasks before we can release a playable demo and would really like to have some original music to go with it.
The audio engine is TIA Tracker based and there is a huge amount of storage space for audio data. Please let me know if you'd like to help out. Thanks!
Perks include:
Access to the latest build of the game
Inclusion in credits screen
A copy of the finished game cart
Forum Topic: Fluid simulation for new 2600 game concept - Atari 2600 Programming - AtariAge Forums
Code Repo: mattress-monkeys-2600
Recent Screen Shot:
-
3
-
-
On 2/1/2023 at 10:45 PM, Andrew Davie said:
It's easy enough to modify the original design, and I'm happy to assist with any changes required, if required.
I assume you'd want a couple assembled PCBs in hand before you'd attempt this. Would it make sense to design the PCB to be as small as possible and fit inside a standard cart? But try to position the ports close to the top and side so there's the possibility of creating a 3d printable shell which exposes the ports? The only downside to this would be the 3d shell having a non standard shape and size. Maybe that would just make it more interesting.
-
I quoted the front and back with https://craftcloud3d.com/ for FDM ABS with the cheapest options it works out to about $4/cart plus $20 shipping. So, buying at least 20 at a time should work out to around $5 a cart. I assume they won't be as pretty as the injection molded shells. I think it's worth it to have the ports exposed though.
jlcpcb has a 3d printing service too. They quote about $5 each plus $20 shipping. But that's for SLA resin with sanded finish and it may be possible to combine shipping if the assembled PCBs are included in the order.
If we have a design with only the front and back halves it might be viable.
-
Does anyone know approximately how much a 3d printed cart costs per unit? If it's comparable to the injection molded ones, wouldn't it be easier to go that route and let the USB, SD, and Reset button all be accessible?
36 minutes ago, bigmessowires said:How would you all feel about moving the data bus back to pins PE8-PE15, which I think is where the UnoCart had it originally?
It's just a matter of setting a few pointers in the firmware. No problem at all. ACE and ELF based games should be using those pointers and will work without any modification to the game rom itself.
44 minutes ago, bigmessowires said:I agree 5V would be better, so you're not overdriving the output of the VREG. I still worry that somebody would accidentally power the board from an ST-Link and from an Atari at the same time. For initial firmware programming, won't you have the PCB in an Atari anyway, so that you can test the board after it's programmed? Maybe there's a simple way to isolate the two power sources. Or maybe I'm over-thinking this.
If there's a 5V pin at the SWD connector, then I'd say VBUS should also be connected to 5V for consistency. Basically we need to decide whether the board is intended to be powered by the programmer / host computer, or it isn't. If it isn't, then disconnect all the power supply connections at the SWD header and the USB port.
I think you're right that USB-OTG would require 5V connected to VBUS though. I would vote to shelve the USB-OTG plans for the time being, since it does seem to complicate things.
Sounds like it might be best to always power the board from the Atari card edge connector. It requires less routing and prevents user error from potentially breaking something.
46 minutes ago, bigmessowires said:What do you think about the idea of auto-configuring BOOT0 by detecting VBUS? I think the only downside is that it would preclude any future plans of building USB functionality into the PlusCart firmware - maybe something like interactively transferring ROMs from an attached computer over a USB cable. If the USB cable were only ever used for firmware updating, then auto-configuring BOOT0 based on the USB cable's presence seems like the best idiot-proof solution to me.
Assuming they all have Wifi equipped, the USB connection wouldn't be that useful. Everything we could do with USB could be done wirelessly via WiFi. Will it really be idiot-proof though? Won't they just leave the USB cable connected and then wonder why the cart isn't working still? Using a microswitch would have the benefit of automatically reverting back to normal boot as soon as they release the button.
I don't think either approach is more right or wrong than the other. You should choose whichever you like better.
58 minutes ago, bigmessowires said:I'm not very familiar with the ESP variants. The work-in-progress PCB specifies an ESP-WROOM-02, which I think has castellated edges so it can be surface mounted or have pins soldered to it. For this purpose, I assume we'd want to surface mount it. If all the components are surface mount, it would help reduce the batch assembly cost.
Yeah, surface mount for sure. It will be nice to have a design that's easy to order fully assembled. The ESP-WROOM and family have flexible I/O, but there are some pins that are better suited for SPI than others. Also, some I/O is already in use by the module because it has external SPI flash built in. Something to keep in mind.
56 minutes ago, bigmessowires said:By the way, it should definitely be possible to hand-assemble one of these even if all the components are surface mounted, so it wouldn't be only for batch production. I've assembled similar boards with just a solder paste syringe and a $20 electric hot plate, no stencil required.
Agreed. For the higher pin count parts, I prefer surface mounted because you can do many pins at the same time.
-
2 hours ago, Al_Nafuur said:
No. It is designed to be used in unmodified standard cartridges or in @Sikor's cartridge here:
The hole is needed so that the board fits into an unmodified case. So it is non optional.
The USB port is currently only for the initial flashing or for unbricking, so it doesn't need to be accessible.
The SD-card and the ESP are optional in production. A PlusCart (or PlusCart Zero) is supposed to fit into a (unmodified) cartridge.
Won't that require destroying the label to get to the ports inside the cartridge? Would it be better to keep the hole, but place the ports on the edge of the cartridge and modify the cartridge to add the necessary holes for the ports?
-
3 hours ago, bigmessowires said:
I spent a long while reviewing the work-in-progress single PCB version of PlusCart Duo, as well as all the earlier versions of PlusCart and UnoCart. I might not be as much help with this as I’d hoped, because there’s a significant learning curve moving from Eagle to KiCad and also because I’m just not very familiar with all the project details. Here are a bunch of notes and ideas for finishing the PCB.
All your notes are super helpful. I'm looking forward to seeing where you take this.
2 hours ago, bigmessowires said:This PlusCart Duo work-in-progress is based on an earlier UnoCart PCB design by rglenn, but the most critical layout and routing from the rglenn PCB appears to have been undone. Was that necessary? Rglenn had the microcontroller square to the PCB, and all the decoupling caps carefully placed, with traces already routed through the tight space between them. PlusCart Duo WIP has the microcontroller rotated 45 degrees to the PCB, and all of the decoupling capacitors have been moved away, and the routing is unfinished. If possible, I would recommend going back to the rglenn placement and routing, or as close to it as possible, as this would save a lot of tedious P&R work.Assuming the GPIO assignments are compatible with everything we want to include I see no reason not to go with such an approach.
2 hours ago, bigmessowires said:The PCB also has all the data bus signals connected twice: to PE0-PE7 and redundantly to PE8-PE15. I would recommend to only use PE0-PE7, since this would help simplify the routing task. My understanding is PE0-PE7 is what the PlusCart firmware already uses, and PE8-PE15 is only for backwards compatibility with old versions of the UnoCart firmware. If so, I don’t think it’s worth the routing hassle. It’s not about the eight extra traces, but the extra traffic jam they may create in a crowded space on a 2-layer PCB. Just tell everyone that this PCB is compatible with the UCA firmware, but not with older UnoCart firmware.
Yes, that's what we were discussing before. I have concerns that extra traces could interfere with bus-stuffing. There's no need to retain compatibility with the older UnoCart firmware. UCA is the one that will be getting all the new features.
It really doesn't matter which GPIO are used for 6507 Address and Data bus connections. The only requirements are:
- Data bus is byte aligned
- Address bus is uint16 aligned
- GPIO 13-15 of the address bus are either grounded or NC. We don't want the performance hit of masking the address values.
2 hours ago, bigmessowires said:Is the WIP PCB specifically designed for @Andrew Davie's 3D printed case? Why does the PCB have a hole in the center? None of the other PlusCart/UnoCart PCBs that I saw have a hole there, and Andrew’s 3D-printed case doesn’t need a hole. I would suggest getting rid of the hole, to create more room and ease of routing.I second this. The need to have USB and SD ports already makes the PCB incompatible with an original, unmodified cart shell. If this were a stand-alone cart for publishing games, it would be a different story.
2 hours ago, bigmessowires said:It’s a proprietary Tag Connect footprint that won’t be usable by most people unless they have the hardware for it. I’d recommend replacing it with a standard 0.1 inch pin header anybody can easily use.
Agreed. .1 inch pin header would be ideal. (right angle for clearance)
2 hours ago, bigmessowires said:- RST - I’m pretty sure this isn’t needed for SWD. It’s not present on the ubiquitous STM32 Blue Pill and Black Pill boards, nor on Robin Edward’s original UnoCart PCB.
I vote for including nRST. In theory it can help with programming if you accidentally change the SWDIO/SWCLK pins to GPIO or alt functions. It would also be handy for communicating directly with the ESP32.
2 hours ago, bigmessowires said:- 3V3 - Is this intended so the ST Link can power the PlusCart? I thought the PlusCart was always supposed to be powered by the Atari. If that’s correct, then I would remove 3V3 from the SWD header to eliminate the possibility someone would get confused and power the PlusCart from the Atari and the ST Link at the same time.
I do think it would be good to have a power pin for the initial firmware programming. Though, in my designs I've always brought 5V to the connector because I didn't think it would be good to connect a 3v3 power source to the output of the VREG. Perhaps 3v3 should be replaced with 5V?
3 hours ago, bigmessowires said:In the schematic, BOOT0 is also left floating at an undetermined voltage if nothing is plugged into the SWD header. That won’t work reliably. For consistency with the existing PlusCart, I think it needs BOOT0 to have a pull-up resistor to 3V3, with a jumper to optionally pull it to GND, so that removing the jumper activates the bootloader. This is opposite from the ST-brand Discovery board where BOOT0 has a pull-down resistor and a jumper can be used to pull it high.I would recommend using a regular pin jumper for BOOT0, like the existing PlusCart PCB. Or if you want to get fancy, USB VBUS could be used to automatically set BOOT0 to 1 when a powered USB cable is plugged in. Put a pull-down resistor on BOOT0 so it’s normally low, and also connect it to USB VBUS. It would need a voltage divider to bring the 5V VBUS down to 3.3 volts for the BOOT0 input.Pin jumper or micro switch would be fine. BOOT0 would only be used for initial firmware flashing and unbrinking. I think a micro switch that's accessible via a paper clip sized hole would be the most professional looking option.
3 hours ago, bigmessowires said:The PCB has USB VBUS tied directly to the board’s 5V power rail. If I’m correct that PlusCart is always intended to be powered from the Atari, then this VBUS connection to 5V isn’t needed or wanted.Wouldn't it be needed for USB-OTG? I'm not that familiar with USB-OTG either. It seems like we would need to have the ability to switch power to the USB VBUS from the MCU. Maybe there's an application note for this?
3 hours ago, bigmessowires said:The USB D+ and D- traces usually have 22 ohm series resistors, but there aren’t any on this PCB. I’m not certain why they’re needed - maybe for proper electrical termination - but they’re present on most designs I’ve looked at including the Blue/Black Pill and the ST-brand Discovery board. I would recommend adding them.USB D+ also needs a 1.5K ohm pull-up resistor to 3.3V, which tells the host this is a USB Full Speed device. This pull-up is present in the Black Pill and also the ST-brand Discovery board. Without it, the PlusCart will be identified as a Low Speed device with about 1/10th the maximum data rate of Full Speed. Note the Blue Pill uses the wrong pull-up value for this: 10K ohm (this might be fixed in some versions of the Blue Pill).This all sounds good to me.
3 hours ago, bigmessowires said:@ZackAttack mentioned the possibility of USB OTG. I’m not very familiar with this, but at a minimum the board would need to connect the USB ID pin, which isn’t connected in the schematic right now. I think it'd also need a way to disable or bypass those 1.5K and 22R resistors when the cart is functioning as a USB host instead of a USB device. I would recommend not worrying about USB OTG for now.
USB-OTG is certainly the lowest priority of everything we've discussed. If it's a lot of effort, we can do without.
3 hours ago, bigmessowires said:I might also suggest reintroducing the PAL/PAL60 jumper that was previously removed. Just in case somebody sets the TV mode to the wrong value in the menu interface, and then has a hard time seeing the menus to change the value, this would provide an easy fix. With two jumpers you could have four possible states for NTSC, PAL, PAL60, and menu-selected.
This could be solved in software. We could have a region override file in the root of the SD or something if this ever becomes an issue.
3 hours ago, bigmessowires said:For USB support, An 8 MHz crystal should be connected to the PH0 and PH1 pins, with some parallel capacitors around 20 pF. But the ST design also calls for an external feedback resistor in the crystal circuit, and I’m unsure what value is needed for the resistor. The ST-brand Discovery schematic says it uses 200 ohms, but I think that’s a documentation error. I couldn't find any schematic for the DIYMORE board - maybe somebody can measure it. I found several different numbers in the STM32F407 datasheet and other ST literature, but they vary by a factor of more than a thousand! One says 200K ohms is typical, another says 1-5 megaohms at 10 MHz or 5-10 megaohms at 1 MHz, and a third does some math to calculate a value of 1326 ohms for 8 MHz with 15 pF capacitors. I don’t know what’s right.I think the application note would be the best authority on this. This would be a good reason to use the larger SMD components. We may need to hand solder new resistors onto the first prototypes if we find they are out of spec.
3 hours ago, bigmessowires said:For the new SPI flash chip, I’m assuming this should be a plain vanilla 8-pin SPI flash, not Quad SPI or something else. Is there already a plan for which pins and which SPI peripheral will be used? The SD card uses SPI2 on pins PB13-PB15. It might be possible to share that with the SPI flash chip too, just by adding an extra chip select signal, but it’s probably cleaner to use a wholly separate SPI peripheral. SPI1 at PA5-PA7 and SPI3 at PC10-PC12 are both potential options. We could look at the routing to see which choice would be easier to run the traces.
Chameleon cart uses W25Q128JVSIQ, plain vanilla 8-pin SPI flash that's cheap and easy to obtain. I think a separate SPI would be preferable.
I think it would be possible to restrict the design to only SMD components. The ESP-01S could easily be replaced with an ESP32-WROOM or similar. The pin header can be placed over a cart edge connector, making the pin header optional.
Another benefit of switching to the ESP32 is that we could add an SPI connection to it as well. My rough estimate is that a buad rate of 15MBit would be necessary to feed the Maria DMA in 7800 mode. If the ESP32 has a dedicated SPI connection it would easily hit that baud rate. Then we could put micropython on it and use the STM32 as a level converter for the ESP32. Being able to write Atari 2600/7800 games in python would be pretty cool.
-
1
-
On 1/28/2023 at 11:40 AM, bigmessowires said:
It looks like the STM32F407V is and M4 and not M4F, so I don't think @MarcoJ could be using hardware floating point support unless I've misunderstood.
Directly from ST:
That said, I have been targeting arm-v6 in all my projects because that leaves the option of using the stm32g0 when publishing individual games. I'm hoping the esp-01s can be used as a sort of GPU/co-processor eventually.
10 hours ago, bigmessowires said:I will now take off my businessman's hat, don my engineering hat, and go look at that PCB in KiCad.
Great!
-
19 hours ago, Al_Nafuur said:
@ZackAttack do we have an solution for PlusCarts without external clock?
I wasn't aware such a cart existed. If you need a quick fix you could just switch them back to internal for now. We can cross the HSE bridge later when USB is brought into the mix.
-
1
-
-
Here's my best attempt to answer all your questions. Hope this helps.
12 hours ago, bigmessowires said:External crystal oscillator - Should be easy enough, but didn't the rglenn PCB already include this? Did it need to be changed for PlusCart usage?
The WIP in the UCA github repo doesn't have an external oscillator and will need to have it added in order for USB to work properly.
12 hours ago, bigmessowires said:SPI Flash - What's this for, a future improvement to support larger ROMs? The Discovery board you're using now doesn't seem to include any SPI Flash.
I designed a standalone cart that's intended to be used for publishing games that are based on the new elf format and other modern schemes. This cart includes a 16MB SPI flash. Since the cost difference is insignificant, I think it would be wise to include it in the multi-cart. In theory we could use the SD card to emulate the SPI flash, but that would require much more effort than adding it to the PCB.
12 hours ago, bigmessowires said:Other refinements to bring it in line with the ST hardware design guidelines - Like what? Best practices on capacitor placement and trace routing, things like that?
Exactly. Capacitor placement. Trace widths and spacing. Should you decide to take on this project, I would be happy to look everything over before do a run of boards.
12 hours ago, bigmessowires said:I might suggest omitting the USB connector. It's only needed for initial programming, which can also be done more reliably with an ST-Link II V2, and those are readily available for about $10. Or design the PCB so that the USB connector is optional.
My preference is to keep the USB connector. Having the ability to unbrick without an st-link is nice for less tech savvy users. There's also the possibility of using USB-OTG in the future.
7 hours ago, bigmessowires said:Does the MCU need to have 5V tolerant I/Os? I'm guessing yes. I was unable to find an easy way to filter the results by 5V tolerance capability.
Yes. 5V tolerance is mandatory. Also, be careful when checking for 5V tolerance. Most STM32 chips have a
mix of tolerances and which pins are 5V tolerant can change depending on the pin count. The Chameleon cart uses weird pin assignments because some of the GPIOA pins are only rated for 3.3v when using the higher pin count parts.
7 hours ago, bigmessowires said:Will the firmware still work correctly at lower core clock speeds? What's the minimum speed? What breaks below that speed?
This was tested and the result was a 192MHz minimum for /Public ROMs/PlusROMs/sokoboo Plus.bin and 144MHz minimum for /Public ROMs/PlusROMs/C.A.V.E. Apocalypse/C.A.V.E. Apocalypse NTSC.bin
Currently the latest version of the UCA firmware has the stm32f407 clocked at 216MHz.
7 hours ago, bigmessowires said:Is there any specific dependency on M4 core features, or could M3 be used? Or M4F?
I believe there are some ACE files created by @MarcoJ that make use of the FPU in the M4F.
12 hours ago, bigmessowires said:The STM32F407V* are very hard to find from any authorized distributor right now, but Newark does have the STM32F407VE https://www.newark.com/stmicroelectronics/stm32f407vet6/32-bit-microcontroller-ethernet/dp/73T7121 .
jlcpcb has had these in stock every time I've ever checked. They also have a parts bin feature which lets you purchase parts ahead of time so you can be sure you'll have the parts you need in the future. I think the supply issue is more relevant to the discovery boards used in the DIY builds.
-
2 hours ago, Al_Nafuur said:
I have started to modify rglenn's PCB a few month ago and add a ESP-12F and a USB connector. I gave the WIP to @ZackAttack who might finish it someday..
I just created a PR to add the WIP to Al-Nafuur/United-Carts-of-Atari (github.com) so it's available for anyone to work on. I had planned on working this once the basic 7800 support is finished, but if someone else wants to work on the PCB before then that would be great. It still needs the external crystal oscillator, SPI flash, and other refinements to bring it in line with the ST hardware design guidelines.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
PlusCart (an inexpensive DIY WiFi multicart)
in Atari 2600
Posted
It seems to be the larger ones that run into a problem. The smaller elf test files work ok.
I shared my WIP folder with you. There are 3 files ranging from 46KB to 86KB in it that all return "ROM Download Failed"
I tried the WIFI update a few times and each time it reports software download failed.