Thanks for the explanation.

The reason I'm asking is that I did some benchmarks on my ZuluSCSI using a 16-bit Adaptec 1540B SCSI controller and it beat my PicoMEM on raw throughput on a 386, so I thought it may well be down to 8 vs 16-bit bus.

douglar wrote on 2025-09-01, 23:33:

FreddyV wrote on 2025-09-01, 17:59:

douglar wrote on 2025-08-31, 18:58:

I think the XTide project might have that need pretty well covered.

PicoMEM with my latest test firmware is now much faster than XTIDE, and it is even much faster on 8088/8086 PC (thanks to RAM to RAM copy and no IO)

So it sound like you are saying that XTide gets < 900KB/s using PIO transfers, but you are able to get something between 1MB/s to 2MB/s using MIO transfers, yes?

Does it use a buffer in an upper memory block to do the transfers ?

Hi,

900kb/s and more is impossible on an 8bit isa bus.

You are probably talking about xtide bios with a disk on an ide connector.

I talk about the 8bit xtide isa card
Yes, transfer is done via a buffer in ram

vetz wrote on 2025-09-02, 14:29:

Have there been any thoughts on a 16-bit version for increased throughput performance for 286+ systems? PicoMEM getting really good as an alternative to IDE to CF/SD (especially with all the extra features).

Nope.
Ian scott picoide is 16bit.
16bit isa is complex to do with a pico

vetz wrote on 2025-09-02, 18:17:

Thanks for the explanation.

The reason I'm asking is that I did some benchmarks on my ZuluSCSI using a 16-bit Adaptec 1540B SCSI controller and it beat my PicoMEM on raw throughput on a 386, so I thought it may well be down to 8 vs 16-bit bus.

Zuluscsi is doing only disk.

Scdi and ide use 16bit data, 4 bit address max and does only one think: disk

Isa is 8bit data 20bit address and io/mem signals, it is more complex to do...

vetz wrote on 2025-09-02, 18:02:

douglar wrote on 2025-09-02, 17:47:

vetz wrote on 2025-09-02, 14:29:

Have there been any thoughts on a 16-bit version for increased throughput performance for 286+ systems? PicoMEM getting really good as an alternative to IDE to CF/SD (especially with all the extra features).

I asked that question about 2 years ago. The answer at that time was that going to the wider bus would require more wait states on memory mapped features, which wasn't desirable.

But on a 16-bit computer the memory features are much less needed as almost all machines except the original 5170 already have minimum 640kb memory and its normally easy to expand it on the motherboard. I'd gladely trade it for increased disk performance on my 386. The disk/floppy features and USB mouse makes it usable even on a 486.

Exact.
Memory on 16bit isa for 16bit isa machines is useless And disk on 16bit isa is slow compared to an ide interface.

The nature of the picomem disk emulation make it really competitive already vs a 16 bit isa based disk.
Picomem can be seen like a really fast 8bit isa card.

I am thinking about PicoMEM to replace cards in my A2286 setup. According to the compatibility-listing the A2286 should work with PicoMEM (A2088XT is listed as problematic)
Currently I am using: (VGA,Sound, Network). The Soundcard offers primary ide for a cf-card. I am using ontrack-disk-manager.

https://youtu.be/P2z_6hgYvcs

Here are my thought's:
1. Making use of 4MB EMS to get much more out of win1x-3x, making use of deluxe-paint 640x and higher resolutions
2. Using ADLIB /CMS Support.
- What about MIDI (currently using midi via sound card) ?
- What about PC-Speaker Input (currently connected from brigeboard to sound card) it's nearly a must have for me.
- What about Covox-Emulation? (must be LPT2, LPT1 is blocked by the amiga) (would be a nice add-on)
3. Harddrive Emulation to get rid of CF-Card solution possible?
4. Currently using EtherlinkII ISA, NE2000 support is possible but only on wifi, I use lan-cable

Thx
Doc

Hi,

I purchased and am using a PicoMem in a DecPC lpx 486 dx2 66. Works great! But the hd disk access is slow. I get that it’s on an 8-bit bus.

I’m trying to use my AHA 1542CP SCSI adaptor with a SCSI2SD board, but it will not work with the pico installed. Is this impossible to do or is there a conflict that I can fix?

I’d like to have the faster disk access for the HDD for later dos games. Thank you!

shan2752 wrote on 2025-09-14, 01:18:

Hi, […]
Show full quote

Hi,

I purchased and am using a PicoMem in a DecPC lpx 486 dx2 66. Works great! But the hd disk access is slow. I get that it’s on an 8-bit bus.

I’m trying to use my AHA 1542CP SCSI adaptor with a SCSI2SD board, but it will not work with the pico installed. Is this impossible to do or is there a conflict that I can fix?

I’d like to have the faster disk access for the HDD for later dos games. Thank you!

What firmware are you running? Latest firmware has improved speed as far as I know.

I did update it to the latest non test firmware. Now I am having an issue with EMM386, if I try to use it, there’s some kind of conflict and fails to boot into DOS. So I cant use any upper memory with the pico.

I wish there was some testing information out there for 486 and later systems. Didn’t you older pc users know about the Commodore Amiga? Gaming on these old dos systems is just awful and I don’t know how you put up with it when the Amiga was so far superior.

shan2752 wrote on 2025-09-14, 01:18:

Hi, […]
Show full quote

Hi,

I purchased and am using a PicoMem in a DecPC lpx 486 dx2 66. Works great! But the hd disk access is slow. I get that it’s on an 8-bit bus.

I’m trying to use my AHA 1542CP SCSI adaptor with a SCSI2SD board, but it will not work with the pico installed. Is this impossible to do or is there a conflict that I can fix?

I’d like to have the faster disk access for the HDD for later dos games. Thank you!

Could be that your BIOS Adress conflicts.
Try change SCSI Card BIOS Address to different one from PicoMem.

Just got my PicoMEM, updated the firmware, and I’m loving it so far! I'm running it on a Mitac 286 that appears to have 1MB of RAM, but I can't seem to access more than 640KB. I honestly don’t remember much from my 286 days—probably blocked it out along with my CGA trauma 😅.
I was hoping to squeeze out a few extra KB of conventional memory and tap into that sweet 4MB of EMS, but no luck so far (see attached pics). What’s odd is that CheckIt shows a few spots available in upper memory, so something’s clearly there—but I haven’t been able to make use of it.
Has anyone run into similar issues or have suggestions on what to check next?

UPDATE:
Once I realized that PICOMEM requires an entire contiguous memory segment—rather than a fragmented equivalent spread across multiple segments—I understood I needed to relocate the Picomem board’s BIOS to the unused portion of another segment (C800). Wonderful piece of tech!

Got my PicoMEM today with MicroSD and put in my Amstrad 1640HD20. Tried to make a 255MB image file right away but it just says "write to file failed". But why? There's working HDD-image on card already and it boots nicely from there.

Ok, there's a bug so need to update to latest test firmware.

PM_Aug25_Test: Test firmware with added Covox (August 2025 Test)
!! Firmware released as test, can be found under the test sub folder. !!
New : Covox support added, enable it using PMININT
New : Disk access now use the FatFS Fast Seek, for a huge disk access speedup. Disk image must not be fragmented : Backup the SD, Format and re copy the Disk image.
! Fix the Disk image creation menu from the BIOS
! Audio mixing (Adlib) has almost no more cut during disk Access

How well does this thing work with faster ISA bus speeds? Will it work on a 9.54 mhz bus?

I shared this in the PicoGUS thread too, but I think it might be relevant to some people here as well:

A somewhat related project was just launched, called Picovox.

As the name implies, the Picovox is kind of like a PicoGUS or a PicoMEM, only it connects to a parallel port instead of an ISA slot, and it aims to emulate most parallel port sound devices. There is already partial support for the Covox Speech Thing, FTL sound adapter, Stereo-on-1, Disney Sound Source (DSS) and OPL2LPT.

As with the PicoMEM, non-sound functionality is also being considered as a future addition. For instance a virtual printer that saves "prints" as PDF files to an SD card. So that would in essence make it a more of a multi-purpose software-defined parallel port device. But at least initially, sound device emulation will be the primary goal.

The developer, @jansakos, is working on this for his Bachelor's thesis, and aims to add support for additional devices as well. Help is welcome!