Sorry for late reply... And thanks for warm welcome.

SpocksBeer wrote on 2021-10-26, 21:39:

Will there be a way to add, say, CD images to the SD card while the unit is running either via USB or even WLAN? Could be a little inconvenient if you're using the device as your primary HD and you have to shut everything down to pull the card and add new files.

Never thought about this use-case. Will add to my TODO list.

Error 0x7CF wrote on 2021-11-05, 16:47:

Would it be possible to use it as an IDE-XT (also known as: XT-IDE, XTA) hard drive? Those are becoming very difficult to obtain, and some systems like the PS/1 will only accept drives matching the exact parameters of the original drive.

I did some research on this topic and in theory it could be possible (maybe with some special firmware), but as far as I don't have either IDE-XT harddrive or controller it seems unlikely.
I know it's unrelated, but emulator was successfully tested with modern XT-IDE controller on Juko XT motherboard.

P.S. I have one spare fully assembled and tested Rev1 board available. [Seems that I can't send PM replies due to low post count]
If you want to try it on this early stage please PM me (Don't). Device is functional but could have bugs, glitches and issues.
For CD-Audio output PCM5102 DAC is needed.

weedeewee wrote on 2021-11-05, 20:17:

@weedeewee, please PM me your contact info.

sintech wrote on 2021-11-15, 15:58:

Sorry for late reply... And thanks for warm welcome.

SpocksBeer wrote on 2021-10-26, 21:39:

Will there be a way to add, say, CD images to the SD card while the unit is running either via USB or even WLAN? Could be a little inconvenient if you're using the device as your primary HD and you have to shut everything down to pull the card and add new files.

Never thought about this use-case. Will add to my TODO list.

There may be an "inexpensive" (requires no additional hardware) to do this : simply use the computer itself to add CD images ? If your computer is connected to a local network, or if you simply have a physical CD-Rom drive connected and you're dumping CDs from win9x you could simply move your image files in the emulator, then mount whatever image you want into the drive.

I don't know if software wise that'd be doable (and if so if that's even easy to do)

sintech wrote on 2021-11-15, 15:58:

P.S. I have one spare fully assembled and tested Rev1 board available. [Seems that I can't send PM replies due to low post count]
If you want to try it on this early stage please PM me (Don't). Device is functional but could have bugs, glitches and issues.
For CD-Audio output PCM5102 DAC is needed.

Hi sintech,

Great stuff! I would love to get my hands on a kit version (or even a bare PCB) since I can solder one myself and could help with testing on various classic computers (DOS and Amiga).

Me too, I want to try, please PM me
(привет, ответь в личку)

jbenam wrote on 2021-11-21, 14:00:

Great stuff! I would love to get my hands on a kit version (or even a bare PCB) since I can solder one myself and could help with testing on various classic computers (DOS and Amiga).

Thank you, currently I'm working on rev2 pcb, so please be patient.

jack7277 wrote on 2021-11-21, 16:06:

Me too, I want to try, please PM me
(привет, ответь в личку)

I can't (because of low post count), please leave you contacts in PM.

sintech wrote on 2021-11-21, 16:12:

Thank you, currently I'm working on rev2 pcb, so please be patient. […]
Show full quote

jbenam wrote on 2021-11-21, 14:00:

Great stuff! I would love to get my hands on a kit version (or even a bare PCB) since I can solder one myself and could help with testing on various classic computers (DOS and Amiga).

Thank you, currently I'm working on rev2 pcb, so please be patient.

jack7277 wrote on 2021-11-21, 16:06:

Me too, I want to try, please PM me
(привет, ответь в личку)

I can't (because of low post count), please leave you contacts in PM.

You'll just have to post a lot more then 😉

On the matter of rev 2 pcb...
Do you think it's possible to make the pcb the size of a 2.5" drive, with the appropriate laptop connector. 44pin 2mm pitch
It would likely help out a lot of people with old machines that have parameters fixed in the bios without having them to patch the bios
though, configuring it while in use might be a bit tricky.
Bringing a usb cable out from a laptop disklocation or even an oled display with the buttons isn't something that was originally envisioned for any laptop.
Maybe just a crazy thought. probably better for rev 2.5 😉
😁

I am sorry if I missed this info - how will one control image loaging/changing? with some external device/control board?

I wonder if ATAPI commands could be used to swap drives, meaning a software could be written for each OS.

Deksor wrote on 2021-11-21, 17:26:

I wonder if ATAPI commands could be used to swap drives, meaning a software could be written for each OS.

The suggestion has been made, and if/when implemented in the firmware, a software shall have to be written for each OS

keropi wrote on 2021-11-21, 17:09:

I am sorry if I missed this info - how will one control image loaging/changing? with some external device/control board?

Yes, also, buttons on the board & oled display, and possibly via the ide interface itself, akin to what Deksor just wondered.

Deksor wrote on 2021-11-21, 17:26:

I wonder if ATAPI commands could be used to swap drives, meaning a software could be written for each OS.

I know there was a rudimentary version of this created for the IDESimulator. Another idea for those machines that have USB is a serial to USB adapter and then echo commands to the serial interface. This wouldn't help with machines that can't access the serial over USB but would get you pretty far. Like

1echo /cd/7thguest/7thguest.iso > COM1

I do it on the mister side to control terminal commands:

1:mp3
2copy .\MP3\*.* .\
3echo on
4mode COM1 BAUDHARD=1152
5echo mpg123 --list /media/fat/mp3/doom/doom.pls > COM1
6cls
7@DOOM
8echo q > COM1
9echo off
10cls
11goto quit

On the mister we have an imgset command that will tell the fpga what cd to mount to which IDE channel and it works really well. This allows for the larger plug and play packs with CD images to click to play. Here is the code for that dos utility if it will help you get closer...
https://github.com/MiSTer-devel/ao486_MiSTer/ … imgset/IMGSET.C

this is amazing, i always wanted a gotek like CDROM accessory

flynnsbit wrote on 2021-11-21, 18:02:

I know there was a rudimentary version of this created for the IDESimulator. Another idea for those machines that have USB is a […]
Show full quote

Deksor wrote on 2021-11-21, 17:26:

I wonder if ATAPI commands could be used to swap drives, meaning a software could be written for each OS.

I know there was a rudimentary version of this created for the IDESimulator. Another idea for those machines that have USB is a serial to USB adapter and then echo commands to the serial interface. This wouldn't help with machines that can't access the serial over USB but would get you pretty far. Like

Copy code to clipboard

1echo /cd/7thguest/7thguest.iso > COM1

Yes, I'm still working on an in-host-machine app to access the device. Originally I used the "SCSI Vendor-specific" command region but a lot of DOS ASPI drivers will reject these commands. I'm currently refactoring it to hide the direct-access commands inside normal SCSI CD-ROM commands so the ASPI drivers can't just ignore it, but other work got in the way (and life - my wife just gave birth) so it's not ready yet. In addition to this, it was a little annoying it needed the ASPI drivers at all, but MSCDEX drivers don't provide a way to directly send SCSI commands and accessing the hardware directly can cause serious issues (e.g. triggering EMM386 DMA crashes), so it's a little fiddly (I do still have some interesting ideas here, but it requires some FPGA logic refactoring too to include some special hacks)

Forgive me for presumptuously posting an idea off the top of my head, but what about exposing an additional LUN for image handling? Block reads could be used to get available image info/lists and block writes used for control.

Interesting idea - that might work, but MSCDEX only permits reads (and also implements a bunch of caching, so you don't even know if a read is going to hit the physical hardware), so it'd still need the ASPI driver (for writes), which is a bit of a shame. Thankfully for ASPI some of the 'standard' commands should be unskippable and allow arbitrary data, though I do want to try a few other ideas too.

Hello everyone.

For the past few days, I've been programming a CD-ROM driver .sys for MSCDEX (or compatibles) which uses CD images (cue/bin format) stored on another machine, accessed via a serial port. Yeah, I started before I found this thread and info about upcoming hardware CD emulators.

Standard PC serial ports are of course too slow for streaming video and pretty much everything else also, but the data track support is there mainly just to get games to launch without cracks and with CD audio enabled. In fact, I'm probably not even going to attempt to add any sort of receive buffer overrun or transmission error tolerance (and recovery) if I find it generally works well enough as-is on any reasonably specced hardware, let's say fast 486 or Pentium and up, with reasonable serial cable length and quality. (So far I've only been testing it using DOSBox booted to MS-DOS 6.22, it seems at 15000 cycles I can still load INSTALL.EXE from the Warcraft 2 CD and start installing the game but at 10000 I get RX overruns and everything goes down in flames, port is set to 115200bps all the time of course and full 14 bytes of UART hardware buffering is being used)

The idea is that you can have a small separate device (eg. a Raspberry Pi) running the "image server" program which will play audio tracks, then mix the audio output from that device with the audio from your DOS PC, and get CD audio that way without a CD drive or discs at all.

I may also try to do this over Ethernet later (though probably not TCP/IP, you'll need to run something to capture/send packets on lower level), but no promises there.

Anyone interested?

Put me down as interested in a hardware cd rom emulator.

Can it work with a usb stick instead of a sd card? Seems like a more practical solution.. removable, loadable from the front of the unit, don’t need a special reader, everyone has some, they are big enough. Etc.

0x90 wrote on 2021-11-28, 08:19:

Hello everyone. […]
Show full quote

Hello everyone.

For the past few days, I've been programming a CD-ROM driver .sys for MSCDEX (or compatibles) which uses CD images (cue/bin format) stored on another machine, accessed via a serial port. Yeah, I started before I found this thread and info about upcoming hardware CD emulators.

Standard PC serial ports are of course too slow for streaming video and pretty much everything else also, but the data track support is there mainly just to get games to launch without cracks and with CD audio enabled. In fact, I'm probably not even going to attempt to add any sort of receive buffer overrun or transmission error tolerance (and recovery) if I find it generally works well enough as-is on any reasonably specced hardware, let's say fast 486 or Pentium and up, with reasonable serial cable length and quality. (So far I've only been testing it using DOSBox booted to MS-DOS 6.22, it seems at 15000 cycles I can still load INSTALL.EXE from the Warcraft 2 CD and start installing the game but at 10000 I get RX overruns and everything goes down in flames, port is set to 115200bps all the time of course and full 14 bytes of UART hardware buffering is being used)

The idea is that you can have a small separate device (eg. a Raspberry Pi) running the "image server" program which will play audio tracks, then mix the audio output from that device with the audio from your DOS PC, and get CD audio that way without a CD drive or discs at all.

I may also try to do this over Ethernet later (though probably not TCP/IP, you'll need to run something to capture/send packets on lower level), but no promises there.

Anyone interested?

Much admiration for the project but seems more complicated than normal cd drive and cds. Also way too many links in the failure chain.

I think it should just be a board that screws into the bay screws (3-1/4 plus 5 1/2 adapter plates) with a display at the front for selecting iso and a usb port and some buttons. Just like OP was saying like a gotek.

0x90 wrote on 2021-11-28, 08:19:

I may also try to do this over Ethernet later (though probably not TCP/IP, you'll need to run something to capture/send packets on lower level), but no promises there.

Anyone interested?

I am already doing something like that on my 486 using a network share and SHSUCDHD. It works, but the lack of CD Audio is a real issue.

Your solution could be a pretty cool zero-cost alternative to physical emulators 😀

Interesting.
Maybe you could use mTCP ? Or would even this be too much ?

Or maybe it could simply become its own thing for the ISA bus ? Afterall not all CD-ROM drives were ATAPI. It could have a boot ROM for cd boot and a specific driver for DOS.

This would be much more complex though

electric_monk wrote on 2021-11-27, 08:13:

Interesting idea - that might work, but MSCDEX only permits reads (and also implements a bunch of caching, so you don't even know if a read is going to hit the physical hardware), so it'd still need the ASPI driver (for writes), which is a bit of a shame. Thankfully for ASPI some of the 'standard' commands should be unskippable and allow arbitrary data, though I do want to try a few other ideas too.

Sorry if this is dumb or impossible, but wouldn't it be possible to (ab)use reads of specific blocs on that theoretical dummy LUN to trigger, for example, the loading of a new image file on the actual valid LUN ?

As long as a read request reaches the underlying hardware (caching would be an issue, though), the actual block address requested could used as a command to trigger practically anything by logic running on CD emulator hardwsre. The dummy LUN could then be dynamically regenerated to, for example, contain the name of the currently in-use image exposed valid LUN at a specif bloc address.

The caching issue ( which could prevent "trigger" reads to the dummy LUN from reaching the hardware) might be addressable if an eject command can be sent through MSCDEX (no idea if this is possible) for the dummy LUN before sending "trigger" read commands or possibly by generating large dummy reads to fill the the cache with useless data first and force an actual "trigger" read to be uncacheable and reach the actual emulator hardware .

Please let me know if this theoretically makes sense . Apologies in advance if doesn't .