Where do you live Ian? Asking to figure out shipping costs
Also, what platforms do you need?
The biggest need was a VIA MVP3 chipset Super Socket 7 board, as I've gotten multiple reports of DMA issues on those.
I have a VIA MVP4 SS7 board - PCCHIPS M585LMR (not an extra one though). I an planning to use PicoGUS on that anyway, so I can test and report you if any troubleshooting on MVP4 is useful.
Just got PCBs from JLC PCB (USD 9 for 5 PCB including shipping) and SRAM, DAC from Aliexpress 😁 Gonna order other parts from Digikey and build it 😀
I plan to build one as GUS and other one as OPL. I think I don't need the SRAM to be soldered for the OPL one ? isn't it ?
That looks great in white!
Correct, you don't need the PSRAM or the two capacitors immediately around the PSRAM chip soldered if you only want to emulate OPL. It's only used by GUS emulation.
If you plan on putting both cards in the same PC, note that pgusinit.exe doesn't support multiple PicoGUS cards in the same system so you will not be able to change the GUS base port from the default of 240h or change any other settings. Supporting multiple cards is something I'd like to do some day, but that won't be for a while.
Just wondering if there is some debug commands we can run to test the picogus to help troubleshoot any issues with the card?
I should probably write up an article about this on the GitHub wiki because there’s a lot you can do for troubleshooting…
A basic “am I alive” test that you can do on PicoGUS is to run these commands in DEBUG, with the GUS firmware loaded:
o 343 aa
i 343
This writes aa to the GUS register select register and then reads it back, so it should print back aa. If you get ff back then something is preventing the PicoGUS from responding to bus events: IOR/IOW is not working, or the address or data lines or shorted. If you get something other than aa or ff, there’s probably an issue with one or more of the data lines being shorted.
Both are acceptable. The 74CB3T3245 is theoretically better because it has the same signal propagation time as the CB3T3257 mux/demux chips, so if you can get it it's the better part to use.
Both are acceptable. The 74CB3T3245 is theoretically better because it has the same signal propagation time as the CB3T3257 mux/demux chips, so if you can get it it's the better part to use.
Thanks a lot for the info. I actually got 74CB3T3245 but got confused after looking at interactive BOM 😀 Hope TSSOP parts won't be an issue as I don't have a microscope right now.
Just a small idea, would it be possible to use a bit larger footprint (DIP would be best) in next iterations 😀
Both are acceptable. The 74CB3T3245 is theoretically better because it has the same signal propagation time as the CB3T3257 mux/demux chips, so if you can get it it's the better part to use.
Thanks a lot for the info. I actually got 74CB3T3245 but got confused after looking at interactive BOM 😀 Hope TSSOP parts won't be an issue as I don't have a microscope right now.
Just a small idea, would it be possible to use a bit larger footprint (DIP would be best) in next iterations 😀
Not to brag but I hand soldered without a scope, it was my first SMT project and got it right the first time around. Just want to point out it is not impossible, just be patient.
Last edited by appiah4 on 2023-07-01, 18:18. Edited 1 time in total.
Retronautics: A digital gallery of my retro computers, hardware and projects.
Thanks a lot for the info. I actually got 74CB3T3245 but got confused after looking at interactive BOM 😀 Hope TSSOP parts won't be an issue as I don't have a microscope right now.
Just a small idea, would it be possible to use a bit larger footprint (DIP would be best) in next iterations 😀
DIP is unfortunately out of the question, but all SOIC is a possibility with a different mux/demux chip. Masteries (author of this post) has created a version of the PicoGUS that uses an alternative mux/demux, the 74CBTLV3257, which is available in SOIC footprint. It does require extra resistors in the design, though.
I agree with appiah4, a microscope is not required. I highly recommend using a magnifier lens to check for solder bridges, though. A majority of people who have assembled their own PicoGUSes have had hidden solder bridges on the TSSOP or SOT23-5 parts.
For those who don't want to deal with soldering small SMT parts, preassembled PicoGUSes are starting to become available – just Google search and you can see Masteries selling his design, and other people have produced my original design for sale. Also there will be some new preassembled designs coming soon: one full sized design is by Studio 8502, and one miniature design is by me, inspired by the new Hand386 and Book8088 computers that were recently released. I've been reluctant to release an official preassembled version in the past because I've never been confident enough in the firmware compatibility, but this new form factor is so small and miniaturized I am using JLCPCB to do the PCB assembly, so I will have some extra to sell to interested people.
@poplo Wouldn't the 600 MHz Teensy 4.1 solve many of your emulation problems? Yes, it is more expensive than the Pico but still affordable, especially when it comes to replacing GUS...
@poplo Wouldn't the 600 MHz Teensy 4.1 solve many of your emulation problems? Yes, it is more expensive than the Pico but still affordable, especially when it comes to replacing GUS...
I’ve thought about the Teensy 4.1 and I have one waiting to be experimented with. When I started this project they were in short supply so I didn’t consider them as a viable option but now they’re more available. I still want to try one to see how well it works.
The Teensy has a lot going for it including the high clock speed, “native” QSPI PSRAM memory, and lots of GPIOs. Real floating point also is really nice. There are a few points against it though: lack of PIO, only one core, and higher cost. Also the main bottleneck for GUS emulation is PSRAM latency, and I’m not sure if the Teensy would help that as much. I also wonder what the single core and having to schedule tasks on it with an RTOS would mean for timing sensitive ISA bus events that I’m used to handling easily with the RP2040’s PIO.
PSRAM on the Teensy 4.1 defaults to 88MHz. You can push it higher, the PSRAM chip says it can run at up to 133MHz but mine only works up to 120MHz. There must be some decent overhead though because unlike the latter thread suggests, it's not even fast enough to handle 640x480x60Hz using 4-bit colors. Suffice to say the actual speed tops out at around 30MB/s max, with the worst case (missing both the CPU's cache and the FlexSPI buffer) being around 4MB/s.
But, there is plenty of RAM onboard already - you could just as easily emulate a GUS with only 512KB and not need PSRAM at all.
The Teensy has FlexIO which is similar to the Pi's PIO but not quite as flexible (particular when it comes to bidirectional pins) but I can vouch for it being able to talk to an ISA bus without serious issues.
Last edited by jmarsh on 2023-07-04, 14:22. Edited 1 time in total.
@poplo Wouldn't the 600 MHz Teensy 4.1 solve many of your emulation problems? Yes, it is more expensive than the Pico but still affordable, especially when it comes to replacing GUS...
+1 With Polpo,
Despite it is 600MHz, single core, no PIO force to use an FPGA.
And it is more fun to code on a lower speed CPU.
FreddyV and I have talked a lot together about our projects and we share a lot of opinions (but we do have some differences 😉). He is developing a card even more capable based on the Pico called PicoMEM - search for it here on Vogons for an idea of what it can do.
FreddyVwrote on 2023-07-04, 14:19:[
+1 With Polpo,
Despite it is 600MHz, single core, no PIO force to use an FPGA.
And it is more fun to code on a lower speed CP […] Show full quote
[
+1 With Polpo,
Despite it is 600MHz, single core, no PIO force to use an FPGA.
And it is more fun to code on a lower speed CPU.
-1 for freddyv
Had you been the picogus creator I would have taken your opinion seriously. The results first then fun comes after them. If you are having fun with slow MCUs programming use your joy with some ancient PIC @ 4 MHz or lower. No one hinted on FPGA usage here. If your brain is forced to use FPGA other may be smarter.
Sorry ?
i am the PicoMEM Creator, that is more "complex" than the PicoGUS for the ISA part...
I like using the Pi Pico for the PicoMEM, because it make sense, it is not a xGHz multi core CPU that can emulate the entire PC.
Also because I don't like all what is going on on the PiStorm, that is now "Emulate all the Amiga in a Pi4"...
And a Pi4 need a FPGA, to talk with the Amiga....
Use an over powered CPU, just because everybody is lazy and don't like to optimize things, it is not for me and I am proud of it....
There seems to have been a silent v1.1.1 revision to the gerbers in the git - is there anything fundamentally changed that would make rebuilding the card worthwhile?
Also, what is this Hand386 edition I am seeing on the interwebs 😁
Retronautics: A digital gallery of my retro computers, hardware and projects.
There seems to have been a silent v1.1.1 revision to the gerbers in the git - is there anything fundamentally changed that would make rebuilding the card worthwhile?
There's no functional change with the v1.1.1 gerbers, but it solves a long-standing issue with the KiCad project, the gerbers in the repo, the bom.csv file, and interactive bom at https://polpo.org/picogus/bom being out of sync with each other. Specifically it's about the 1uF decoupling capacitor on the PSRAM chip (U8) being mixed up with the 0.1uF decoupling capacitor on U9. In the v1.1 hardware revision, this 1uF capacitor was marked C9 on the board, but the BOM and KiCad had that capacitor as C10. This means when people were building their boards, they were putting the 1uF capacitor on U9 instead. Ultimately it doesn't really seem to affect performance, but it was bugging me so I fixed it. I also updated the KiCad project to specify a SN74CB3T3245 for U2, the recommended part number, instead of the 74LVC244 that I started off with.
Also, what is this Hand386 edition I am seeing on the interwebs 😁
I got a Hand386 and am pretty enthused by it. I've been having to be away from home for long periods of time to care for family members and missed being able to work on PicoGUS while away, and the Hand386 could be a nice highly portable platform to develop PicoGUS on. I was annoyed with having to deal with the ISA breakout on a ribbon cable to use a PicoGUS on the Hand386, and also its reset line is very noisy, causing spurious resets of the PicoGUS that make it unusable. I solved the reset issue by using the 74AHC logic family for U5 instead of 74LVC. Technically AHC is the "wrong" family to use because it's not TTL compatible but I specifically want the higher voltage threshold that it has to register a logic high. Since I had to make some hardware changes anyway and I was bored away from my workbench with lots of time to poke around on KiCad, I designed a version that plugs directly into the Hand386's ISA pin connector. I greatly miniaturized the PicoGUS board design to fit almost everything between the legs of the Pico, and I also integrated the DAC directly on the board instead of having to use the purple DAC module.
After teasing this design, I got to talking to some people and decided that it'd be a bit of a waste to have a PicoGUS that *only* works on a Hand386, so I set about making an adapter to allow it to plug into a regular ISA slot. Even more talking led to a few other features for this adapter. The first feature was to allow two positions for the Pico: the position first keeps the Pico fully within the PC, but the second allows the Pico to stick out. The second position is for two reasons: easy removal to swap over to a Hand386, and also for better WiFi signal when using a Pico W. With the help of yyzkevin, I hope we can get NE2000 card emulation working based on his PCMCIA projects. This will let you use WiFi on modern WPA2 networks easily on old PCs, as it just looks like an NE2000 card to DOS or old versions of Windows. The second feature for the ISA adapter is optional backfeeding of the audio and TTL MIDI back from the PicoGUS into unused pins on the Hand386 connector. This allows for a wavetable header on the ISA adapter, which can be mixed into the audio output of the PicoGUS. Also the Hand386 can be modded to play audio from the PicoGUS over its built-in speakers.
I'm working on a video outlining everything about this side project that has turned out to be pretty cool. I've made a small batch of these and they're almost all spoken for, but I'll be making another run and putting them up on Tindie soon.
Also to help compatibility on the Hand386, I've fixed some issues with the GUS emulation that also improve compatibility in normal PCs. I'll be releasing new firmware with those changes (and other changes I haven't formally released yet, like better MPU-401 emulation and new CMS and Tandy emulation code from Aaron Giles)!
I just built a second one of these things and even though there is nothing wrong with it visually (triple check visually and with a multimeter for shorts/bridges in soldering) pgusinit gives me no picogus detected 🙁 How do I go about troubleshooting this?
Retronautics: A digital gallery of my retro computers, hardware and projects.
