VOGONS


PicoMEM : Pi Pico on ISA, with full Memory and I/O bus access

Topic actions

Reply 360 of 362, by carlostex

User metadata
Rank l33t
Rank
l33t
FreddyV wrote on 2025-12-17, 18:23:
Hi, […]
Show full quote

Hi,

Still working on the PicoMEM 2, probably not available before March next year (Will send this board to prod next week and hope it work)

The attachment PicoMEM2.png is no longer available

I confirmed the DMA is working and even got GUS mixing working (No DMA support Yet) plus Sound Blaster (With DMA) working.

Here is an audio output of the PicoMEM 1.5 GUS:

The attachment Solstice_PicoMEM_GUS_Mono.mp3 is no longer available

I imagine this is with the RP2350

Reply 361 of 362, by Caligula

User metadata
Rank Newbie
Rank
Newbie
carlostex wrote on 2026-01-05, 14:00:
FreddyV wrote on 2025-12-17, 18:23:
Hi, […]
Show full quote

Hi,

Still working on the PicoMEM 2, probably not available before March next year (Will send this board to prod next week and hope it work)

The attachment PicoMEM2.png is no longer available

I confirmed the DMA is working and even got GUS mixing working (No DMA support Yet) plus Sound Blaster (With DMA) working.

Here is an audio output of the PicoMEM 1.5 GUS:

The attachment Solstice_PicoMEM_GUS_Mono.mp3 is no longer available

I imagine this is with the RP2350

From the pincount this looks a RP2350 B. The RP2350A and RP2040 have a smaller case with only 15 pins per side.

Reply 362 of 362, by Kahenraz

User metadata
Rank l33t
Rank
l33t

I am very interested in these features for DOS:

- Memory emulation with 16Kb Address granularity:
> 128Kb of RAM can be emulated from the Pi Pico internal RAM with No Wait State. (4MHz ISA)
> We can emulate the whole 1Mb of RAM address space from the PSRAM. (With 6 Wait Stated for 4MHz ISA)
> EMS Emulation of Up to 6 / 7 MHz. (Only 4Mb for the moment as using the LoTech EMS Driver)
> Memory emulation is also used to add (4Kb of "Private" memory for the PicoMEM BIOS Usage)
> 16Kb of RAM is also added for disk access (Or other) even if 512Kb only is used for the moment.

I have an issue with trying to use UMBs on motherboards and either not being able to find enough or having them conflict with motherboard resources, leading to instability. Would something like this create a UMB "mask" over the motherboard's main UMBs (memory over 640K) that is guaranteed to be safe for programs to load into completely?

For example, I have an industrial socket 775 motherboard which has unusable UMBs in DOS, unless I disable USB 2.0 in the BIOS. And even then, I feel like I'm fighting for memory above 640K. I would love for there to be a way to reclaim UMBs for my drivers without sacrificing motherboard features that I want available in other operating systems.