Kroko Posted August 9 Share Posted August 9 Looks good to me. One question about the cartridge power switch: Will it be enough to disconnect cartridge 5V power supply or do you think anything else on the device would need to know that the cartrige power is on or off ? I think I heared that it can be a bad idea to drive the cartrige data pins when the carts own power supply is not present. But I don't remember who mentioned that and if it can really be a problem ... Link to comment Share on other sites More sharing options...
+MarcoJ Posted August 9 Share Posted August 9 22 hours ago, Al_Nafuur said: Any suggestions or objections? Wow, this has come a long way. Impressive. Have you built a breadboard prototype with a MAX-II breakout board? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 9 Author Share Posted August 9 8 hours ago, Kroko said: Looks good to me. One question about the cartridge power switch: Will it be enough to disconnect cartridge 5V power supply or do you think anything else on the device would need to know that the cartrige power is on or off ? I think I heared that it can be a bad idea to drive the cartrige data pins when the carts own power supply is not present. But I don't remember who mentioned that and if it can really be a problem ... The GPIOs of the Pi and the MAX-II are "only" 3.3V, but it still might be the reason why my SuperCharger cartridge isn't working anymore 🤔 We have one GPIO Pin left, maybe we should use it to signal the driver/emulator that the cartridge is powering off and to set all GPIOs to GND. We would need a (big) capacitor on the cart 5V to slow down the powering down.. Link to comment Share on other sites More sharing options...
Kroko Posted August 9 Share Posted August 9 (edited) 2 hours ago, Al_Nafuur said: We have one GPIO Pin left, maybe we should use it to signal the driver/emulator that the cartridge is powering off and to set all GPIOs to GND If we don't need it for anything else we should use it. People should have a good feeling to plug in their old cartridges into this console. Maybe someone here can explain why it is a bad idea to source 3.3V into old semiconductors if these are not powered. Would be interesting to know...maybe I am just paranoid. Edit: I asked ChatGPT and this is its summary: "Applying voltage or sourcing current to the data pins of an unpowered old semiconductor chip can indeed cause damage or lead to erratic behavior due to latch-up, backfeeding through protection diodes, or other unforeseen consequences. It’s important to ensure that chips are properly powered before applying any signals to their pins." Edited August 9 by Kroko 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 I am not sure if the 1N4148 is sufficient here and maybe the 33uF cap is to much.. I have connected the "CART_PWR" signal to the last free GPIO of the Pi so the Driver/Emulator knows that the cart is powered up or not. But I also connected it to one of the 12 free PINs of the MAX-II, so we can use VHDL to set the address lines faster and more safely to GND and switch the data lines to input mode (not driven by the BIA). 1 Link to comment Share on other sites More sharing options...
Kroko Posted August 10 Share Posted August 10 (edited) Forward Voltage of 1N4148 can be 1V and I think it is only rated for 150mA. I would rather use a Schottky Diode like 1N5817 which has only 0.55V and rated for 1A. Maybe you want to use a resistor from 5V to any sensing input, not sure how 5V tolerant everything is you connect the line to ... Edited August 10 by Kroko 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 42 minutes ago, Kroko said: Forward Voltage of 1N4148 can be 1V and I think it is only rated for 150mA. I would rather use a Schottky Diode like 1N5817 which has only 0.55V and rated for 1A. Yes I just threw the parts in there for the schematic. I have to check the values later.. 42 minutes ago, Kroko said: Maybe you want to use a resistor from 5V to any sensing input, not sure how 5V tolerant everything is you connect the line to ... Yeah! The 5V supply is from the Pi, but i overlooked that the GPIOs of the Pi and MAX-II are 3.3V. So we definitely need something to protected them from the 5V. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 3 hours ago, Kroko said: Maybe you want to use a resistor from 5V to any sensing input, not sure how 5V tolerant everything is you connect the line to ... 1 hour ago, Al_Nafuur said: Yes I just threw the parts in there for the schematic. I have to check the values later.. Yeah! The 5V supply is from the Pi, but i overlooked that the GPIOs of the Pi and MAX-II are 3.3V. So we definitely need something to protected them from the 5V. is there a toggle switch like this push switch? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 https://www.amazon.de/sourcing-map-6-polig-Positionen-Gleitschalter/dp/B008DFYHV2 seems to have a similar size than the 2600jr power switch and it is DPDT toggle 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 I have done some math for the cap. With 33uF it will power a simple masked ROM (~1mA) cartridge for 165ms and a more complicated multicart (~500mA) for 330ns. This should be enough time for the BIA to "shut down" the address lines and stop driving the data lines via the SN74LVC245AN (adds an additional 10ns). Link to comment Share on other sites More sharing options...
Kroko Posted August 10 Share Posted August 10 59 minutes ago, Al_Nafuur said: https://www.amazon.de/sourcing-map-6-polig-Positionen-Gleitschalter/dp/B008DFYHV2 seems to have a similar size than the 2600jr power switch and it is DPDT toggle Thats a good idea. If we have a switch that can turn on and off power to the console and at the same time 3.3V to the power sensing inputs, we don't need a diode or resistor and have the full 5V at the cartridge port. 👍 Link to comment Share on other sites More sharing options...
Kroko Posted August 10 Share Posted August 10 Is there any chance to have the possibility to connect debug cables to all signals of the cartridge port and Pi, when both cart and Pi are plugged in ? Will be hard to debug if we can't connect debug lines to monitor the signals. Or we have to make adapters which are again a little bit unstable...are you sure that you can debug all signals we need to see from MAX-II ? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 20 minutes ago, Kroko said: Is there any chance to have the possibility to connect debug cables to all signals of the cartridge port and Pi, when both cart and Pi are plugged in ? Will be hard to debug if we can't connect debug lines to monitor the signals. Or we have to make adapters which are again a little bit unstable...are you sure that you can debug all signals we need to see from MAX-II ? I wanted to keep the PCB and the costs small, so I only put a pin header for the remaining MAX-II IOs on the board. For a good debugging PIN outs of all GPIOs are certainly an advantage, but this would mean ~100 PIN headers. Link to comment Share on other sites More sharing options...
Kroko Posted August 10 Share Posted August 10 12 minutes ago, Al_Nafuur said: I wanted to keep the PCB and the costs small True, but if things don't work and you can't see whats going on, that might be frustrating ... Why do we still need the diode now ? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 10 Author Share Posted August 10 24 minutes ago, Kroko said: True, but if things don't work and you can't see whats going on, that might be frustrating ... True! I'll see how to add more headers. 24 minutes ago, Kroko said: Why do we still need the diode now ? Isn't the cap being discharged/shorted to GND without the diode if the switch is set to off? We might leave pin 3 of the switch not connected instead 🤷♂️ Link to comment Share on other sites More sharing options...
Kroko Posted August 10 Share Posted August 10 11 minutes ago, Al_Nafuur said: True! I'll see how to add more headers. Isn't the cap being discharged/shorted to GND without the diode if the switch is set to off? We might leave pin 3 of the switch not connected instead 🤷♂️ I see no reason why we need to connect it to ground...but you are right, if you connect ground to the 5V pin, a diode would protect any external power supply of cartridges that are connected to the 5V. I would probably just disconnect it from 5V an let it float. 1 Link to comment Share on other sites More sharing options...
Kroko Posted August 11 Share Posted August 11 Maybe it would still be a good idea to have a 10K pulldown resistor on the 3.3V power sensing input, because I guess it is not a good idea to let the power sensing line float. Link to comment Share on other sites More sharing options...
Kroko Posted August 11 Share Posted August 11 (edited) Looking at the schematic, I am a bit worried about the Pi_Clock (200MHz core clock?). How is this one generated ? Is it realtime or influenced by the OS on the Pi ? I would really like to have a reliable clock on the thing that is 100% predictable. And what are the possible clock speeds of the PI_Clock ? Edited August 11 by Kroko Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 11 Author Share Posted August 11 3 hours ago, Kroko said: Maybe it would still be a good idea to have a 10K pulldown resistor on the 3.3V power sensing input, because I guess it is not a good idea to let the power sensing line float. In my new design the DPDT switch pulls 3.3V to GND and leaves only the 5V floating. 3 hours ago, Kroko said: Looking at the schematic, I am a bit worried about the Pi_Clock (200MHz core clock?). How is this one generated ? Is it realtime or influenced by the OS on the Pi ? I would really like to have a reliable clock on the thing that is 100% predictable. And what are the possible clock speeds of the PI_Clock ? I "borrowed" this setup from the PiStorm project. I have to check how the core clock is activated on this pin, but if it works for the PiStorm project it should work for us too. 1 Link to comment Share on other sites More sharing options...
Kroko Posted August 11 Share Posted August 11 You feel good skipping the USB Blaster programming header for the MAX-II ? How would the "workflow" look like when the MAX-II needs to be re-programmed ? Do we need a special Pi with a specific software for downloading and plug that one in every time the MAX-II needs to be programmed ? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 11 Author Share Posted August 11 31 minutes ago, Kroko said: You feel good skipping the USB Blaster programming header for the MAX-II ? How would the "workflow" look like when the MAX-II needs to be re-programmed ? Do we need a special Pi with a specific software for downloading and plug that one in every time the MAX-II needs to be programmed ? No the MAX-II is programmed via the Pi and openocd (https://github.com/openocd-org/openocd/) similar to the way PiStorm is flashing the Max-II. That's why the PI GPIOs 24 and 25 have jumpers to the MAX flashing ports (TDI and TMS). Flashing with the PI was the only way it worked for me. 2 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 11 Author Share Posted August 11 On 8/9/2024 at 5:22 PM, MarcoJ said: Have you built a breadboard prototype with a MAX-II breakout board? Not a fully working one. There are too many cables involved and my first try with the MAX board directly connected to the Pi isn't ideal for the GPIO. So I wanted to make a simple/cheap PCB with the MAX-II already included. 1 Link to comment Share on other sites More sharing options...
Kroko Posted August 11 Share Posted August 11 Are you still confident that we can reach a point where the Raspberry Pi-OS based emulation is working well enough ? I mean without too large delays, because emulation does not get realtime priority. When I tried the bus interfacing with the pico, the sound always seemed to be kind of wrong and it was very hard to get the timing of the emulation "just right" such that most ROMs were working. Maybe I chose wrong settings on the Pi or I didn't change important timing stuff on the Pi. Somehow I got the feeling, the last little bit would only be possible with a Realtime Kernel. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted August 11 Author Share Posted August 11 33 minutes ago, Kroko said: Are you still confident that we can reach a point where the Raspberry Pi-OS based emulation is working well enough ? I am curious to find out. And there are still some optimizations left. 1 Link to comment Share on other sites More sharing options...
Kroko Posted August 21 Share Posted August 21 I am missing decoupling capacitors in your design. Did you forget them, or was this a decision you made ? Its pretty standard to have at least a few decoupling capacitors close to the CPLD ... From datasheet: "As the number of I/O pins and the capacitive load on the pins increase, more decoupling capacitance is required. As many as possible 0.1- mF power-supply decoupling capacitors should be connected to the VCC and GND pins or the VCC and GND planes. These capacitors should be located as close as possible to the MAX II device. Each VCCINT/GNDINT and VCCIO/GNDIO pair should be decoupled with a 0.1-mF capacitor." 1 Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts