Catch Catch playing on a 16Mhz 286 Packard Bell Victory, fullscreen at 30FPS. With the Picomem V1 acting as the hard drive and sound card (and ethernet card, though it didn't want to auth this boot for some reason). On the custom firmware as patched a couple posts above.
Acorns wrote on 2026-10-31, 00:24:Catch Catch playing on a 16Mhz 286 Packard Bell Victory, fullscreen at 30FPS. With the Picomem V1 acting as the hard drive and sound card (and ethernet card, though it didn't want to auth this boot for some reason). On the custom firmware as patched a couple posts above.
Apologies for the spam of posts, I cannot edit the existing one. Wasn't happy with the CRT's flashing in the phone camera, so reshot on an LCD.
FreddyV wrote on 2026-10-23, 10:09:Hi, Thanks 😀 Are you ok if I check and integrate some of this in next firmware ? I started also a Web interface on my side.... T […]
Vivid Warthog wrote on 2026-10-11, 11:20:Hi! Just wanted to share that I've made some work on the PicoMEM (2.0) FW fork that focuses heavily on Sound Blaster compatibili […]
Hi!
Just wanted to share that I've made some work on the PicoMEM (2.0) FW fork that focuses heavily on Sound Blaster compatibility and audio quality, plus some QoL improvements (like full setup via config.txt, so no PMINIT call is needed or firmware update from SD and access to SD card with HTTP over WiFi - so no more need to unscrew the pc tower to update the card 😁)There are also some bugs fixed, but all mentioned in CHANGES.md file.
So if you are using PicoMEM2 for SB/FM audio, you can check it out:
Hi,
Thanks 😀
Are you ok if I check and integrate some of this in next firmware ?
I started also a Web interface on my side....
The public picomem source is not the latest one, so will be lot of work to manually include this.
I also have to ensure it does not use too many ram
Hello FreddyV!
Absolutely, go ahead, grab and integrate whatever you find useful 😁
I understand that some things might be conflicting, as I've based the changes on the older code. Seems we fixed some of the same bugs (IRQ7 for example), probably in a completely different way.
I finally got the PicoMem working properly on the loaner EuroPC. I removed the PREBOOT from the config, so I was able to access the PicoMem settings and change them.
The downside to all this is that I may have to try to find another EuroPC to install the PicoMem into. I believe, that since I no longer can get an image out of mine, it’s only good for spare parts.
A couple of images of the PicoMem 2 (and 1) working on a loaner EuroPC. I’m excited to finally see it working. The only downside is that my own EuroPC seems to have deteriorated to good-for-spares condition. With time and patience, I might get it working again, but at the moment, I really don’t have the time and energy to do that.
Well, talk about a Hail Mary working out… The above are from my EuroPC with Indy 500 running from the PicoMem2.
So, I did some more probing on the mainboard, and found out that one address line from the expansion slot wasn’t making contact to one logic chip. I figured I had nothing to lose if I simply soldered a long bodge wire across the board to connect the two points, as the system wasn’t even posting. After adding the bodge, it still wasn’t posting but tried and true knocking against the tabletop sorted out that at least temporarily, and lo and behold, PicoMem was identified and the system was booting into the hard disk image I had on the SD card. You cant imagine how good it felt to hear the Planet X3 intro out of the PicoMem’s audio.
This has been a long journey, and it still isn’t quite over as I still have the issue of the system not posting without a good knock, so I need to get that sorted out still, but I accept my victories as they come.
Some more progress. I tried the probably the most obvious treatment to the non booting issue and pressed all the socketed chips, which seemed to fix it. Now the EuroPC seems to boot consistently.
I suppose I can now concentrate on configuring the PicoMem…
RetroBard wrote on 2026-11-01, 20:09:Some more progress. I tried the probably the most obvious treatment to the non booting issue and pressed all the socketed chips, which seemed to fix it. Now the EuroPC seems to boot consistently.
I suppose I can now concentrate on configuring the PicoMem…
Glad you got it working
FreddyV wrote on 2024-04-01, 13:58:Hi, […]
PeacockXT wrote on 2024-03-31, 19:56:STrRedWolf wrote on 2024-03-30, 13:17:Well, if you multiplex the data and part of the address into 16 pins... could multiplex some of the control pins as well... Adafruit PSRAM only takes 4 pins plus power and ground... so relatively easy to do with the right hardware.
I have looked at the pcb pictures and believe that 10 GPIO's handle the address Input and 8 of them handle Data I/O too. Pico GPIO has to toggle between address select, Data select, Data direction, address multipexing , and all are time critical.
Excellent programming job.Hi,
Close, it is is multiplexed on 12 Pin : A0-A7 / A8-A15 / D0-D7 then MR-MW-IOR-IOW /A16-A20
Plus 2 Pin to control the multiplexing > 14 Pin in total
Hi there FreddyV, hope you're not from Elmstreet 😀
Anway, I was looking to get the schematics of the picomem board, don't really need neither the lastest version but the earliest would be best avoided as well, but let me explain.
I love your project, yes, it does have a number of features that would help me with my "new" DX2/80, but it also has features I do not need at all like the memory related features. FDD/HDD, Audio and mouse support though are indeed features I do want.
Now, I have a few Pico's myself as well as a number of EncXxxx ethernet module, Cyclone 2 dev boards, ESP32, ESP8266 and a based Cyclone IV as well as Cyclone IV dev board with VGA output, PS/2 connector and a couple other things not relevant for my goals which involve a using about 2 of the Cyclone 2's or maybe the basic Cyclone IV (this would be the ISA interface management), one of the Pico's (mainly to have at least some work already done), the I2S module for audio output and a MilkyV-DUE 256Mb and an expansion port to allow maybe later on use the Cyclone IV dev board with VGA output to be a graphics card.
My objective is to use these components on a 16Bit card to implement the following support on ISA x86 systems:
- USB Mouse to PS/2 or BUS Mouse
- FDD Emulation
- HDD/CDROM emulation
- SB32 emulation (using the MilkyV in part due to the available RAM) ensuring full Yamaha OPL3 support, 8/16Bit Digital Audio Support and importantly, EMU8000 support.
- 1 Serial Port
- MIDI IN/OUT ports
- Ethernet Support 10/100Mbps (NE2000 emulation or maybe a 3COM or early Intel model)
- WiFi support via ESP32 (this and the ethernet are to be supported via the MilkyV since I can both connect the ENC adapter and the ESP32 to it, in particular the ESP32 has firmware that enables it to work as a Client or AP under linux making this a suitable solution)
- Expansion header allowing the board to be directly connected to the Cyclone IV dev card and have it implement MDA, Hercules, CGA, EGA, VGA, SVGA, XGA (maybe ECS/AGA, yes I now not PC modes) and if it fits on the available LEs some sort of supported 3D acceleration, if not that maybe Video decoding
- Front panel with a 2.8" Touch screen and additional SD card reader, the front panel card reader will be primarily for FDD and CDROM images, HDD images should if possible be implemented directly on the MilkyV
Another important detail I am interested in implementing is DMA support for the HDD and CDROM emulation at least for HDD if nothing else, this is in part why the FPGA is the chosen component to link and manage the ISA bus connectivity and settings. This will also enable software configuration of IRQs, DMAs, Addresses etc.
Now, I am quite aware that I will need help with a number of things but at a minimum I am certain to be capable of implementing the circuit design and have an initial working pcb if not immediately capable of having all desired features working at least their hardware implementation will be ready for the software to enable all features.
The secondary graphical card support feature in particular is certain to be the last thing to be implemented.
If you look at the feature set you will easily notice that this is basically a single (well dual) add-in board solution to get any x86 motherboard with only keyboard CPU and RAM to become a fully usable system.
One thing I will promise you is not to add to any support burden you may have from your own PicoMEM project and will for sure mention your help and base design sources where I'll be deriving part of the hardware and softare design from.
This is a project I will definitely make fully opensource and have no intent on making any profit from other than my own experience and the pleasure of getting some Retro hardware and related geeks happy 😉
The most important detail of all in my goals is that the whole shebang must run smoothly under OS/2 Warp 3 and newer 😀 Also, NT 3.51 though not as important as far as I am concerned.
If you can share the base circuit schematic in an EDA supported format I can work with and expand uppon I would be very very happy for your help, past that I won't be asking for anything else.
Best regards,
WSkinny
WSkinny wrote on Yesterday, 22:43:Another important detail I am interested in implementing is DMA support for the HDD and CDROM emulation at least for HDD if nothing else, this is in part why the FPGA is the chosen component to link and manage the ISA bus connectivity and settings. This will also enable software configuration of IRQs, DMAs, Addresses etc.
Edit -- Added some clarity--
8 bit DMA is useful for floppy drives and sound cards where there is a requirement for a minimum guaranteed data delivery rate. You don't have to worry about interrupts derailing the system. That's not the case for IDE hard drives or CD-ROMs. They don't have a minimum requirement. Doing a DMA implementation for IDE over 8 bit ISA is more complicated, would have more compatibility issues, and even in the most competitive scenario, like old processors that lacked the INSW instruction, the performance would still struggle to match the speed of FreddyV's memory mapped IO driver.
DMA became useful for hard drives when multitasking operating systems arrived, but only after Pentium chipsets allowed the processor to function while a DMA transfer was going on in the back ground. On almost everything older than a Pentium system, the CPU is essentially shut off while ISA DMA transactions are occurring, so there's no multitasking reward for DMA on ISA cards.
DMA for CD-ROM drives became useful to avoid buffer under runs when burning a CD ROM, but this isn't a CD-R, so that doesn't figure in either.
douglar wrote on Today, 12:26:Edit -- Added some clarity-- […]
WSkinny wrote on Yesterday, 22:43:Another important detail I am interested in implementing is DMA support for the HDD and CDROM emulation at least for HDD if nothing else, this is in part why the FPGA is the chosen component to link and manage the ISA bus connectivity and settings. This will also enable software configuration of IRQs, DMAs, Addresses etc.
Edit -- Added some clarity--
8 bit DMA is useful for floppy drives and sound cards where there is a requirement for a minimum guaranteed data delivery rate. You don't have to worry about interrupts derailing the system. That's not the case for IDE hard drives or CD-ROMs. They don't have a minimum requirement. Doing a DMA implementation for IDE over 8 bit ISA is more complicated, would have more compatibility issues, and even in the most competitive scenario, like old processors that lacked the INSW instruction, the performance would still struggle to match the speed of FreddyV's memory mapped IO driver.
DMA became useful for hard drives when multitasking operating systems arrived, but only after Pentium chipsets allowed the processor to function while a DMA transfer was going on in the back ground. On almost everything older than a Pentium system, the CPU is essentially shut off while ISA DMA transactions are occurring, so there's no multitasking reward for DMA on ISA cards.
DMA for CD-ROM drives became useful to avoid buffer under runs when burning a CD ROM, but this isn't a CD-R, so that doesn't figure in either.
That DMA detail is indeed interesting and important. That said, I have noted that I am implementing this on a 16Bit card 😀 which is why the FPGA frontend to the bus becomes handy. Now, DMA will be likely one of the last items on the implementation list and the only reason I am looking at that as a requirement is because I want this baby to work under OS/2 Warp 3 maybe Warp 4.x .
Would love as such the base schematic of the Picomem to give me a base to work upon and expand, yes that is me being a bit lazy but also relying on something that has worked very well for me a number of times, like for example when I made my first serial cable for my Nokia 5110 and Siemens phone, they had similar MAX232 based designs but there were some differences so I combined both designs into a single circuit needing only one single switch to select the device type from the Nokia 5110 to the Siemens (cant recall the model of that one sadly). This circuit worked beautifully for both phones so that was my first win in combining similar schematics and adapting them. In a way reminds me of Karnaugh maps hehehe (hope you know what I am referring to).
Best regards,
WSkinny, 8bits and one nibble! (possibly a nibble on the pie)
WSkinny wrote on 55 minutes ago:,DMA will be likely one of the last items on the implementation list and the only reason I am looking at that as a requirement is because I want this baby to work under OS/2 Warp 3 maybe Warp 4.x
Not sure why you think DMA is a requirement for OS/2. Could you give some additional insight into that?
Are you looking at implementing 3rd party DMA through the 8237 DMA controllers or are you looking at doing a full first party bus master design?
