SScorpio wrote on 2026-01-31, 15:30:

riplin wrote on 2026-01-31, 10:52:

Super excited about this project! I ordered three, one for each of my retro system.

I was wondering, will it be possible to update images on the PicoIDE while the system is running? Looking for an easy way of sending files to my retro machines without taking up memory with network drivers in DOS.

Yes, via the web interface. But you're limited to 500KB-1MB/s.

It's much faster to just have the system powered off. Eject the SD card, insert into a new system and copy files. I use SD to IDE adapters for HDDs in my systems and this is how I get files on and off them.

That's what I'm doing right now and it gets old really fast when trying to do fast iteration during development.

riplin wrote on 2026-01-31, 22:46:

That's what I'm doing right now and it gets old really fast when trying to do fast iteration during development.

We'll see if it's only for uploading and managing image files. Sounds like you might want to be able to edit a currently mounted HDD image.

I guess you could create new ISOs and upload those and swap. Those would support hot swapping without issue.

Preordered 2 with the beige front panel. This thing looks super useful.

douglar wrote on 2026-01-31, 19:50:

Will PicoIDE support multi sector transfers?

Will it support trim? OK, I know operating systems < 2005 don't support trim, and SD's don't call it trim, but still, it would be neat to have. Although I'll admit, I'm not sure how it would work with the virtual hard drive files.

Yes, multi-sector transfers are supported. No TRIM support, but I don't think it really makes sense for fixed virtual hard drive files since nothing is ever deleted from the perspective of the PicoIDE - it just gets writes within the bytes that the image is in on the SD card.

Sorry to keep hounding with questions but here are a few more…

What transfer modes does PicoIDE support with the SD card?

Is PicoIDE going to assert and de-assert iordy or will it work under the assumption that it is fast enough that it never needs to de-assert it?

What are the fastest idle/active/hold/recovery times that you expect to handle?

Can it measure and report the DIOR#/DIOW# pulse width and cycle time from the host?

Can the end user change what is reported in ATA device identity or set features?

douglar wrote on 2026-02-01, 13:07:

Can the end user change what is reported in ATA device identity or set features?

I can answer that one since it was mentioned on the discord. The answer is yes.
edit: at least the device identity part, the features... ? dunno.

Ahhh. Discord. Sigh.

I’ll dig into https://picoide.com/docs/ and see what I can figure out

Welp. Just noticed crowdsupply only accepts payment via credit card. I don't have a credit card. 😒

OK, here is Douglar answering his own questions:

What transfer modes does PicoIDE support with the SD card?
It accesses the SD card using a native 4-bit SD interface implemented with RP2040 PIO, not SPI. It does not use UHS-I or UHS-II signaling modes.

Is PicoIDE going to assert and de-assert IORDY or assume it is always fast enough?
PicoIDE actively asserts and de-asserts IORDY to safely handle SD card latency and buffering. It does not assume it can always meet fixed PIO4 timing without wait states. IORDY can be disabled in the config file.

What are the fastest idle/active/hold/recovery times that you expect to handle?
PicoIDE is designed to do a 70 ns strobe active time and a 120 ns minimum cycle time. It does not attempt to support faster-than-spec or overclocked host timings.

Can it measure and report the DIOR#/DIOW# pulse width and cycle time from the host?
PicoIDE does not currently measure or report pulse width or cycle timing

Can the end user change what is reported in ATA IDENTIFY DEVICE or SET FEATURES?
The config file lets you set PIO and MWDMA advertisement and IORDY . I don't see any setting that let me change the ATA device name without compiling my own firmware.

I wonder if there could be an option to set the PicoIDE up like a a Creative/Panasonic or Mitsumi CD-ROM drive. It would give some additional connection options and potentially free up some resources. I look forward to trying out the IDE version. 😀

weedeewee wrote on 2026-02-01, 13:46:

Welp. Just noticed crowdsupply only accepts payment via credit card. I don't have a credit card. 😒

I thought similar to Australia, most banks in EU have a visa debit or mastercard debit facility attached directly to the bank account

DarcTangent wrote on 2026-02-03, 03:54:

I wonder if there could be an option to set the PicoIDE up like a a Creative/Panasonic or Mitsumi CD-ROM drive. It would give some additional connection options and potentially free up some resources. I look forward to trying out the IDE version. 😀

Outside of sound cards or a bundled dedicated ISA interface card, did any computers, even non-IBM compatibles have those interfaces onboard?

The PicoGUS can do Panasonic and give you an SB/Adlib, GUS, Convox, CMS, Tandy, and intelligent MIDI all in a single small ISA card. The PicoGUS was also recreated in that PC/101 or whatever it's called industrial format. But I don't recall ever seeing the later v2 which had the onboard USB port the CD emulation needs.

The three interfaces Panasonic/Mitsumi/Sony are all different which is why there were even some sound cards that had all three individual headers onboard. IDE is usable on way more systems. And if you had an really old system that could use those interfaces, then using the upcoming dual device interface of the PicoIDE running both the HDD and CDROM off a single IDE interface shouldn't limit you in HDD read speeds. So you could have just a single IDE controller in the PC if resources are that constrained.

douglar wrote on 2026-01-30, 03:41:

Finding solid state UDMA storage is pretty easy.

Finding solid state storage that you can fix to MWDMA or PIO is much more interesting, especially when working with socket 5 and older.

Hm i had no problem with industrial CF Cards since years.

SScorpio wrote on 2026-02-03, 13:12:

Outside of sound cards or a bundled dedicated ISA interface card, did any computers, even non-IBM compatibles have those interfaces onboard?...

All valid points. 😀
It will be interesting to see how the different configurations of the IDE PicoIDE perform. I can only see this project getting better. I'd still like a Panasonic or Mitsumi option to play with, but maybe that's just me.
Cheers!

SScorpio wrote on 2026-02-03, 13:12:

Outside of sound cards or a bundled dedicated ISA interface card, did any computers, even non-IBM compatibles have those interfaces onboard?

A few 3DO systems (e.g. Panasonic FZ-1, Creative 3DO blaster) used the mitsumi interface

Would it be a possibility to show the cd cover on the oled display? As it were a music player...

NeoG_ wrote on 2026-02-04, 03:16:

A few 3DO systems (e.g. Panasonic FZ-1, Creative 3DO blaster) used the mitsumi interface

If 3DO is your goal there's already the open USBto3DO project for the various models. That uses a RP2040 Pico as well.

https://consolemods.org/wiki/3DO:USBto3DO

SScorpio wrote on 2026-02-04, 23:44:

If 3DO is your goal there's already the open USBto3DO project for the various models. That uses a RP2040 Pico as well.

https://consolemods.org/wiki/3DO:USBto3DO

That's a cool board, didn't know they existed

douglar wrote on 2026-02-01, 13:57:

Is PicoIDE going to assert and de-assert IORDY or assume it is always fast enough? PicoIDE actively asserts and de-asserts IORDY […]
Show full quote

Is PicoIDE going to assert and de-assert IORDY or assume it is always fast enough?
PicoIDE actively asserts and de-asserts IORDY to safely handle SD card latency and buffering. It does not assume it can always meet fixed PIO4 timing without wait states. IORDY can be disabled in the config file.

What are the fastest idle/active/hold/recovery times that you expect to handle?
PicoIDE is designed to do a 70 ns strobe active time and a 120 ns minimum cycle time. It does not attempt to support faster-than-spec or overclocked host timings.

Whether IORDY is asserted or not doesn't have to do with SD card access. PicoIDE de-asserts IORDY while the host reads the various status registers, etc., but because of DMA between the sector buffer and the IDE data pins it's fast enough that it does not need to deassert IORDY during reads/writes from the data register or when doing MWDMA. For example from /IOR assert the PicoIDE has the data ready on the pins in about 20 ns, so it's quite a bit faster than the 50ns required in the spec for PIO mode 4/MWDMA mode 2. Reads are accelerated because while data is being transferred to the host, the PicoIDE CPU is free to read the next sector from the SD card, so SD access is not a bottleneck for sequential reads.

douglar wrote on 2026-02-01, 13:57:

Can the end user change what is reported in ATA IDENTIFY DEVICE or SET FEATURES?
The config file lets you set PIO and MWDMA advertisement and IORDY . I don't see any setting that let me change the ATA device name without compiling my own firmware.

I haven't implemented changing the ATA device name or other IDENTIFY responses in picoide.ini yet, but I plan to by the initial public firmware release. It's one of those things that are simple enough that I haven't gotten around to it yet because I'm busy fixing hairier problems.

DarcTangent wrote on 2026-02-04, 02:53:

All valid points. :) It will be interesting to see how the different configurations of the IDE PicoIDE perform. I can only see […]
Show full quote

SScorpio wrote on 2026-02-03, 13:12:

Outside of sound cards or a bundled dedicated ISA interface card, did any computers, even non-IBM compatibles have those interfaces onboard?...

All valid points. 😀
It will be interesting to see how the different configurations of the IDE PicoIDE perform. I can only see this project getting better. I'd still like a Panasonic or Mitsumi option to play with, but maybe that's just me.
Cheers!

I've had the idea in my mind to create passive plug adapters so PicoIDE could serve as an XTA hard drive or Panasonic or Mitsumi CD-ROM drive. It's certainly capable of being either one of those, just some signals need moving around. But that's one of those things I'm not going to get around to working on until after the public release, probably after I take a stab at simultaneous 2 device emulation.