And that precisely is why I waited out with the PC/104 version roll out. 😁
I will rework it once @polpo finishes the version 1.2 and then I will probably release the board. I've seen somebody try to copy my work some time ago and they failed badly... I would rather see it to be finally open for everybody to use.
Delphius wrote on 2023-11-05, 17:42:Almost like there is a data line that is bridged with it. I have been testing short circuit from that pin but all that I can find it connecting to is U5 pin 9. There must be something I am missing or not understanding.
[...] I have checked all my work over a few times under the microscope and everything looks good as far as I can tell.
Bridges actually can hide quite well near the package under a TSSOPs (not applicable here) and aren't completely impossible under the SOICs also... if you're probing and seeing real signal activity (and not just noise) on the isolated RESET line, there really isn't many places where it could pick that up: it's indeed routed from the ISA slot (backside of the card, pad 2 on the ISA connector), directly to U5, pin 9:
If it'd be caused by a bridge, you could look at U5, pin 10 and see if it's what you're seeing on pin 9 (or simply if those two are bridged):
There also is a chance of a wrong IC in position U5 (only mentioning this, because something similar has happened before 😉. It should be a 74LVC14 in that place and a 74LVC00 at U6.
There's maybe one more thing you could verify: check if there's no bridges / connections / jumpers on the header footprint right at the ISA slot:
If the signal activity is on the RUN side of things, then U6, pin 12 & 13 might be worth a look also.
MJay99 wrote on 2023-11-06, 12:49:Bridges actually can hide quite well near the package under a TSSOPs (not applicable here) and aren't completely impossible unde […]
Delphius wrote on 2023-11-05, 17:42:Almost like there is a data line that is bridged with it. I have been testing short circuit from that pin but all that I can find it connecting to is U5 pin 9. There must be something I am missing or not understanding.
[...] I have checked all my work over a few times under the microscope and everything looks good as far as I can tell.Bridges actually can hide quite well near the package under a TSSOPs (not applicable here) and aren't completely impossible under the SOICs also... if you're probing and seeing real signal activity (and not just noise) on the isolated RESET line, there really isn't many places where it could pick that up: it's indeed routed from the ISA slot (backside of the card, pad 2 on the ISA connector), directly to U5, pin 9:
reset.jpg
If it'd be caused by a bridge, you could look at U5, pin 10 and see if it's what you're seeing on pin 9 (or simply if those two are bridged):
rdack.jpg
There also is a chance of a wrong IC in position U5 (only mentioning this, because something similar has happened before 😉. It should be a 74LVC14 in that place and a 74LVC00 at U6.
There's maybe one more thing you could verify: check if there's no bridges / connections / jumpers on the header footprint right at the ISA slot:
D7.jpg
If the signal activity is on the RUN side of things, then U6, pin 12 & 13 might be worth a look also.
busoe.jpg
Thanks for the help in troubleshooting this. I am trying not too make too many posts during my path of discovery, so here is the latest.
It would be nice to know if the data on the reset line is normal or not. I have the ISA pin 2 line taped off so everything generated here should be isolated to the picogus. I created a gif capture of what my oscilloscope is picking up off of the reset line right as the computer starts up and the picogus is powered on. This data is consistent every time it turns on. I don't expect this to be normal, but I have checked the schematics and PCB and checked everything I can think of so far and I can't find any short circuits. As far as I can tell this is only between U5 and the ISA pin 2, which leaves me to believe there is something generating from U5. Overall it leads me to believe that I have deeper issues going on, but I am just trying to decide my next move. I will also note again that running in pg-mpu mode works perfect every time, so it is something happening in one of the other processes. In console debug, most of the time the pico fails to even register anything on startup or is cut off immediately. Then randomly it will fully initialize a few times in a row. I am tempted to try hot air and reseating some of these chips, but I don't know which to try first. Also, my picogus is socketed and I am wondering if that was a mistake as well.
@Delphius - Thanks for attaching that capture of your scope. If you have the reset line disconnected from the ISA bus, you'll need to tie it to ground so it's not floating. In your photo on the Github issue, I see you have a jumper header already on it, so just closing that should be simple. If RESET is left floating, I wouldn't be too surprised by the "activity" that you're seeing on it. I've seen simply touching the board being enough to "drive" the floating reset line high or low.
All in all, I'm really stumped by the behavior you're seeing on your build, especially in that you see the MPU firmware working just fine. Code that uses the DAC shouldn't really affect the RESET or RUN lines since physically the DAC signals are far away and isolated to the part of the board under the DAC module. Code-wise, there really shouldn't be much of a difference either. Nothing's really sticking out to me as a culprit so I'm totally at a loss. Very early on in the development of PicoGUS, I did run into spurious resets caused by certain bus activity which caused me to start using a 74LVC14 Schmitt trigger inverter, and then later switching to a 74AHC14, and now in my latest hardware designs, pulling reset down and RUN up, adding a capacitor, etc.
Socketing the Pico is totally fine – all of the "Femto" PicoGUSes are socketed and I've not had any reports of issues with them.
polpo wrote on 2023-11-06, 18:32:@Delphius - Thanks for attaching that capture of your scope. If you have the reset line disconnected from the ISA bus, you'll need to tie it to ground so it's not floating. In your photo on the Github issue, I see you have a jumper header already on it, so just closing that should be simple. If RESET is left floating, I wouldn't be too surprised by the "activity" that you're seeing on it. I've seen simply touching the board being enough to "drive" the floating reset line high or low.
All in all, I'm really stumped by the behavior you're seeing on your build, especially in that you see the MPU firmware working just fine. Code that uses the DAC shouldn't really affect the RESET or RUN lines since physically the DAC signals are far away and isolated to the part of the board under the DAC module. Code-wise, there really shouldn't be much of a difference either. Nothing's really sticking out to me as a culprit so I'm totally at a loss. Very early on in the development of PicoGUS, I did run into spurious resets caused by certain bus activity which caused me to start using a 74LVC14 Schmitt trigger inverter, and then later switching to a 74AHC14, and now in my latest hardware designs, pulling reset down and RUN up, adding a capacitor, etc.
Socketing the Pico is totally fine – all of the "Femto" PicoGUSes are socketed and I've not had any reports of issues with them.
Ok good to know. That makes sense that the line would need to be grounded to keep it from floating, and I think you have actually mentioned that already. I do have a jumper that I can throw on that pin set and while it does clear the floating signals that are coming through that line, the picogus still behaves the same. So far adding capacitors, blocking off ISA reset pin, and grounding out the reset line do not change anything. So at this point I am going to start looking for other areas that might be causing problems. I think it is a gremlin specific to this build now. I have also given it a test in an i430VX, a 440BX, and two other AG430HX motherboards and the results seem to be the same so I don't think it is a compatibility issue.
I am not too concerned though I wouldn't mind getting to the root of the issue. I have considered ordering parts for a second one and see if I have better luck with that as I continue to debug this one. But thinking it might be worth it to hold out until revision 1.2 so that I can test something fresh. Even if this adapter turns into an MPU only card, I can't complain too much about that for the price of the parts. I might remove and reflow some of the chips to see if changes anything.
I've been trying to get the Masteries version of the PicoGUS working in the PC/104 slot of my Icop Vortex86-6071 board with no success. The card is recognized fine on my NuXT in both the ISA and PC/104 slots, so the board itself is fine, but I always get the "no PicoGUS detected" on the Vortex86-board. The ISA bus speed has been lowered to 8.3MHz and IRQ/DMA has also been set to ISA mode, but same error no matter what settings I use.
Having a look at the pgusinit source it seems it's trying to communicate with the card via port 0x1D0, so could it possibly be that the port is already being used by something else on the Vortex86-board, which interferes with the initialization? Any suggestions on BIOS-settings I could try, or would it be possible to build a version of the PicoGUS firmware+pgusinit that uses some other port?
britelite wrote on 2023-11-16, 10:37:I've been trying to get the Masteries version of the PicoGUS working in the PC/104 slot of my Icop Vortex86-6071 board with no success. The card is recognized fine on my NuXT in both the ISA and PC/104 slots, so the board itself is fine, but I always get the "no PicoGUS detected" on the Vortex86-board. The ISA bus speed has been lowered to 8.3MHz and IRQ/DMA has also been set to ISA mode, but same error no matter what settings I use.
Having a look at the pgusinit source it seems it's trying to communicate with the card via port 0x1D0, so could it possibly be that the port is already being used by something else on the Vortex86-board, which interferes with the initialization? Any suggestions on BIOS-settings I could try, or would it be possible to build a version of the PicoGUS firmware+pgusinit that uses some other port?
It would be possible to have a firmware/pgusinit that uses another port, but there's a quick sanity check you can do. Each of the firmwares are usable without using pgusinit on their default port (GUS 240h, Adlib 388h, MPU 330h, and so on...), so could you try using a game that uses sound? Adlib is probably the most foolproof. If the game does not work, there may be an incompatibility with Vortex86 based boards unfortunately. I don't have one to test with so I'm not sure if it would work or not.
Today I released the PicoGUS 2.0 board! It is available on my Tindie store: https://www.tindie.com/products/polpo/picogus … -isa-retro-pcs/ [edit: they're sold out already!]
As always all design files are on the project github, in the "hw-chipdown" folder. Unfortunately this is not a DIY-friendly design. Technically it's possible to hand-assemble, but there are tiny 0402 passives and the RP2040 QFN package. There are Gerber and BOM/CPL files so you can have the project fully assembled at PCBA capable places like JLCPCB (where I had mine made), and if you make a lot the cost per board can get quite low. Also in the design files are a .stl for a 3D printed bracket, and a .step and drawing .pdf for the custom metal bracket.
The main benefit of this board (in addition to the possibility of "mass production", and the cool metal bracket) is the USB-A connector so you can easily plug in USB joysticks. The latest firmware has a preview of joystick functionality: plug in an Xbox 360 or DualShock 4 pad and you can use them in your DOS games. This functionality is also possible with the original PicoGUS design, you just need to use a powered USB OTG cable on the Pico's micro-USB B port to plug in your joypad.
polpo wrote on 2023-11-16, 16:25:It would be possible to have a firmware/pgusinit that uses another port, but there's a quick sanity check you can do. Each of the firmwares are usable without using pgusinit on their default port (GUS 240h, Adlib 388h, MPU 330h, and so on...), so could you try using a game that uses sound? Adlib is probably the most foolproof. If the game does not work, there may be an incompatibility with Vortex86 based boards unfortunately. I don't have one to test with so I'm not sure if it would work or not.
Tried both the latest Adlib and GUS firmwares but no luck, so unfortunately it seems like the Vortex86-board is the culprit.
britelite wrote on 2023-11-16, 18:46:Tried both the latest Adlib and GUS firmwares but no luck, so unfortunately it seems like the Vortex86-board is the culprit.
Oh no! I should try to find one of these Vortex86 boards and see what the problem is... they're very interesting. I'll add a note that they are not yet compatible to the compatibility wiki page.
polpo wrote on 2023-11-16, 16:35:The main benefit of this board (in addition to the possibility of "mass production", and the cool metal bracket) is the USB-A connector so you can easily plug in USB joysticks. The latest firmware has a preview of joystick functionality: plug in an Xbox 360 or DualShock 4 pad and you can use them in your DOS games. This functionality is also possible with the original PicoGUS design, you just need to use a powered USB OTG cable on the Pico's micro-USB B port to plug in your joypad.
I was surprised to see this as a feature. Is it limited to just four buttons? I currently have a USB4VC that has the ability to map things to keyboard presses. But that connects to the keyboard connector of the PC.
But still, this is amazing what you've pulled off, and the price is outstanding. You're fulfilling a lot of the fantasy that was the BitchinFastAudio 3000, but at 1/4-1/6th the price if the cost of an FPGA ODE is anything to go on for what an ultimate FPGA sound card would cost.
polpo wrote on 2023-11-16, 16:35:[edit: they're sold out already!]
Great job!
polpo wrote on 2023-11-16, 16:35:As always all design files are on the project github, in the "hw-chipdown" folder.
I see you went with a a digipot in the end 😀
SScorpio wrote on 2023-11-17, 00:28:I was surprised to see this as a feature. Is it limited to just four buttons? I currently have a USB4VC that has the ability to map things to keyboard presses. But that connects to the keyboard connector of the PC.
But still, this is amazing what you've pulled off, and the price is outstanding. You're fulfilling a lot of the fantasy that was the BitchinFastAudio 3000, but at 1/4-1/6th the price if the cost of an FPGA ODE is anything to go on for what an ultimate FPGA sound card would cost.
Yes, it's emulating a normal game port so it's limited to 4 axes and 4 buttons. Mapping to keyboard presses would be great, but the PicoGUS would require a TSR to do that. I've thought about emulating the Gravis GRiP or MS Sidewinder digital game port protocols to allow for more axes/buttons, but I'm not really sure how widely supported they really are...
And thanks! I only just recently watched eeguru's presentation on the BitchinFastAudio 3000 and it really is surprising how much overlap this project on a small RP2040 and some PSRAM has has with what he proposed. And FreddyV's PicoMEM will bring in even more like microSD based storage, RAM expansion, network devices, etc.
rasz_pl wrote on 2023-11-17, 03:15:Great job! […]
polpo wrote on 2023-11-16, 16:35:[edit: they're sold out already!]
Great job!
polpo wrote on 2023-11-16, 16:35:As always all design files are on the project github, in the "hw-chipdown" folder.
I see you went with a a digipot in the end 😀
Thank you for those suggestions you made! I also thanked you in the silkscreen on the back of the PicoGUS 2.0. In this thread, you were the first person to suggest using a Pico and PSRAM to accomplish my goal, and it's worked amazingly well. Thanks again.
oof, sold out in a couple of hours? Congrats 😀 any idea when you could be restocking? I'd happily try to grab one if there's a chance, I love to support such projects and toy with them!
polpo wrote on 2023-11-17, 04:10:Yes, it's emulating a normal game port so it's limited to 4 axes and 4 buttons. Mapping to keyboard presses would be great, but the PicoGUS would require a TSR to do that. I've thought about emulating the Gravis GRiP or MS Sidewinder digital game port protocols to allow for more axes/buttons, but I'm not really sure how widely supported they really are...
CH and Thrustmaster also both had their own protocols, that were more supported. Later Thrustmaster stuff switched to a keyboard passthrough so the stick and single trigger were on the game port, with everything else being key presses. If you had a throttle and pedals then those were the second stick axis. Thrustmaster handled this by having a programmable chip on the joystick itself, so you'd essentially flash the key mappings when changing to different games.
Lots of old DOS games didn't have the ability to remap controls, so a TSR wouldn't be horrible as you could call it along with a mapping file parameter to switch what the controls do on a per-game basis.
polpo wrote on 2023-11-17, 04:10:Mapping to keyboard presses would be great, but the PicoGUS would require a TSR to do that.
TSR wont cut it, any self respecting game remaps keyboard interrupt handler and uses own one reading raw 0x60h Keyboard controller port
https://www.youtube.com/watch?v=njeViEGaP-8
https://github.com/root42/doskbc/blob/f0e3e7c … 758425/DOSKBC.C
Note the later (much nicer to the hardware) version
"This version doesn't use the enable/disable calls and also calls the original keyboard handler for improved compatibility with less compatible systems like the PC Jr and Tandy 1000."
still wouldnt see any keypresses injected by external TSR: https://github.com/root42/doskbc/blob/main/DOSKBC.C
There are two ways going about it. One is what PS/2 mod people are doing by swapping keyboard controller, for example Re: Native PS/2 mouse implementation for 386/486 boards using the keyboard controller
Problem with swapping keyboard controller is in some computers it still manages A20 and/or Turbo on random IO pins so cant make universal replacement plug&play solution nor "pull out your keyboard controller, PicoGUS will take over" wouldnt work 100% of the time.
SScorpio mentioned the other method:
SScorpio wrote on 2023-11-17, 12:55:Later Thrustmaster stuff switched to a keyboard passthrough so the stick and single trigger were on the game port, with everything else being key presses.
This is the true universal always works way, Amstrad did the same with PC1512 with joystick port directly in the keyboard and keyboard being able to remap it to whatever you wanted. This is also how barcode scanners used to function 😀 why fuss with software/controllers when you can intercept keyboard. As a bonus you get full keyboard remapping capability on a hardware level.
Requires 4 spare IOs (6 if also injecting ps2 mouse), add a plug for a keyboard DIN/ps2 in/out dongle and you are in business. Pico code and hardware interface https://github.com/No0ne/ps2pico https://github.com/No0ne/ps2x2pico
USB mouse is doable without the need for additional hardware, this: Another PS/2 Mouse ISA (ISA8) card adapter but with pico. I think Scrap Computing already implemented something half way there requiring custom mouse driver ..hmm searching, yes here it is https://www.youtube.com/watch?v=gkQ3zS-_Q1w ISA Blaster: DirtyRat Project (USB Mouse on a Pico-powered ISA card in DOS) (Part 2) [Scrap Computing]
One undeniable bonus of digital joystick modes is much faster readout, dont have to spin in place for up to 1ms 😀 but software directly supporting digital modes already required very fast computers where this didnt matter 🙁
rasz_pl wrote on 2023-11-17, 14:27:USB mouse is doable without the need for additional hardware, this: Another PS/2 Mouse ISA (ISA8) card adapter but with pico. I think Scrap Computing already implemented something half way there requiring custom mouse driver ..hmm searching, yes here it is https://www.youtube.com/watch?v=gkQ3zS-_Q1w ISA Blaster: DirtyRat Project (USB Mouse on a Pico-powered ISA card in DOS) (Part 2) [Scrap Computing]
Adding USB mouse support is on my list but I don't think I'll be going the route of emulating a serial mouse, which always seemed slow and unresponsive to me. Instead, I'm thinking of emulating a Logitech or Microsoft InPort bus mouse card. Ctmouse doesn't support bus mice but the Logitech or Microsoft drivers should work fine.
polpo wrote on 2023-11-17, 16:13:I'm thinking of emulating a Logitech or Microsoft InPort bus mouse card. Ctmouse doesn't support bus mice but the Logitech or Microsoft drivers should work fine.
werent those implemented with 8255 PPI?
since 8255 doesnt have counters wouldnt that mean interrupts triggered on every mouse encoder change and burning tons of cpu? Q46369 implies only two reads are sufficient, how would that work?
https://jeffpar.github.io/kbarchive/kb/046/Q46369/ https://dosbox-x.com/doxygen/html/classPC98__ … ouse__8255.html
https://www.minuszerodegrees.net/msmouse/MS%2 … bus%20-%201.png
U1 ?
U2 74LS125 4 tri-stated buffers, for what?
U3 8255
U5 ?
U6 AM25LS2521 quad comparator for address decoding?
U7 74LS245 buffering databus
Edit: https://www.reddit.com/r/vintagecomputing/com … in_in_ibm_5160/
U1 cd4020 a single counter!
U5 64H101 = 74H101 = single flipflop
So its not braindead after all, its super clever to somehow decode two quadrature signals using one counter?
nvm my ramblings, obviously InPort/Bus Mouse is the way to go, 2-4 IO reads for complete mouse position.
Looking forward to trying out a few DOS games with a Dualshock4 controller, when I get the free time.
I don't love most legacy controllers of the original DOS era. Well I do, nostalgically, but not so much from a function and ergonomics point of view!, haha.
Congrats & thx polpo on the v1.x firmware and v2 board, super cool developments on all fronts.
