weedeewee wrote on 2021-12-20, 21:33:

the website says it's only for cd/dvd. Does it emulate two devices, ie master & slave, at the same time? How do you like it? […]
Show full quote

the website says it's only for cd/dvd.
Does it emulate two devices, ie master & slave, at the same time?
How do you like it?
What's the transfer speed?
... ?

Seems to be all there, just need to click through:

Port speeds Some basic testing has so far revealed the following statistics. Updated firmware in the future may change these ran […]
Show full quote

Port speeds
Some basic testing has so far revealed the following statistics. Updated firmware in the future may change these rankings.

USB0 is the fastest port, running at USB high speed (480Mbps). Via a USB OTG cable, you can connect a USB Flash drive and store your disk images there for maximum possible access speed. Thus, this is the recommended solution.

SD is the second fastest port. Almost as fast as USB0, but the port can be a little tricky to insert.

USB1 is the slowest port, running at USB full speed (12Mbps). Though it will support a disk if it's connected, this configuration isn't recommended, though is fine for firmware upgrades, connecting to a computer for command line access, and general I/O (e.g. ethernet, external control pads, and other future features)

https://issues.tattiebogle.net/dokuwiki/doku. … mulator:startup

IDE The IDE interface can be set to device 0 (also known as “master”) or device 1 (also known as “slave”) by command: […]
Show full quote

IDE
The IDE interface can be set to device 0 (also known as “master”) or device 1 (also known as “slave”) by command:

interface set [master|slave]
This can be combined with the autorun.txt startup file to ensure it's set every time the board starts up.

https://issues.tattiebogle.net/dokuwiki/doku. … :clinking_glass

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

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.

I prefer the idea of a software emulator given the actual or proposed costs of the hardware options!

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.

Another alternative in addition to those you and other people have proposed in this thread is just raw Ethernet frames as is done by EtherDFS and ATA over Ethernet (the latter I forgot about until I saw mbbrutman's post). That option, or probably any other Ethernet-based one you pursue, is going to require a packet driver or similar for the NIC, which probably makes the .SYS driver option impossible unless it is one you only ever load using DEVLOAD/DRVLOAD/etc.. Or if you instruct the user to load the packet driver from CONFIG.SYS, will it actually get loaded at the point where the INSTALL= line is? If not, I suppose that you may as well not ship it as a .SYS file - you could just do the device driver installation yourself, the book "Undocumented DOS" by Schulman et al describes how to do this (I'm assuming it's relatively easy since it's documented and there are open source tools which can do it, apologies if I am minimising the effort required!).

Note that using raw Ethernet makes the software you run on the target (Raspberry Pi or whatever) a bit more complicated than a regular TCP or UDP application with sockets, but there are examples there for EtherDFS and ATA over Ethernet (in the latter case they are vblade for Linux and I gather there is a Windows port).

Also the author of EtherDFS made ethflop for emulating a floppy drive over Ethernet.

mbbrutman wrote on 2021-11-29, 17:13:

I wouldn't use TCP/IP for something like this - it's too heavy. UDP is a much simpler protocol that will work fine on a local network, and it is simple enough to redo it in assembly.

(I'm planning my own shared drive letter device driver for mTCP that will use UDP or ATA over Ethernet to a Linux machine that hosts the storage.)

So if you go with ATA over Ethernet, it would presumably be a TSR we could use to access a device via AoE rather than having to SAN boot? That would be nice, I imagine it wouldn't have the restriction that EMM386 isn't supported either (which seems to extend to not being able to run Windows in 386 Enhanced mode, or start any DOS programs in Windows' Standard mode). I also imagine it wouldn't actually require mTCP since it's just raw Ethernet (although you might ship it as part of mTCP), or am I missing something?

Anyway thanks for mTCP, I haven't actually used it yet but I look forward to it one day 😀

I like the idea of ATA over Ethernet - it is simple and it is a standard, although rarely used now. From the DOS side it would look like a RAM disk device driver; just another block storage device. It would not be usable as a true network drive, as it would not support sharing across multiple machines at the same time. (Well, not for writes at least.) This option requires nothing from mTCP, except my general knowledge of networking and error detection/correction. But I would have to alter mTCP slightly to allow it to co-exist.

I've also thought about using IP/UDP as the underlying transport, which would make it easier for other machines to host the drive storage for the DOS machines. A server using UDP is much more flexible to run than one that uses raw Ethernet frames. And IP/UDP is routable, so you could start to think about crazy things like having the DOS machine connect to a drive *somewhere else far away*. Imagine a DOS shareware file repository that you actually connect to by adding a drive letter, and that repository can be anywhere in the world. I think that's the future of file sharing. 😀

Such a program would not coexist with the existing mTCP applications without a bit of extra work. The packet driver spec allows you to route specific packet types to programs, and the existing mTCP programs handle ARP, IP, UDP and TCP. To have a device driver for a network drive using UDP you'd have to find a way to route packets that one program didn't want to the other program.

mbbrutman wrote on 2021-12-29, 18:31:

And IP/UDP is routable, so you could start to think about crazy things like having the DOS machine connect to a drive *somewhere else far away*. Imagine a DOS shareware file repository that you actually connect to by adding a drive letter, and that repository can be anywhere in the world. I think that's the future of file sharing. 😀

archive.org could really use something like this, https://github.com/dreamlayers/em-dosbox
"To run DOS programs, you need to provide a suitable web page, load files into the Emscripten file system, and give command line arguments to DOSBox."
https://archive.org/details/softwarelibrary_msdos_games downloads whole images before running, this means ~600MB downloads to start a CD game
https://archive.org/details/msdos_The_Need_fo … al_Edition_1996
Request URL: https://ia902600.us.archive.org/cors_get.php? … dition_1996.zip ~450MB

mbbrutman wrote on 2021-12-29, 18:31:

Such a program would not coexist with the existing mTCP applications without a bit of extra work. The packet driver spec allows you to route specific packet types to programs, and the existing mTCP programs handle ARP, IP, UDP and TCP. To have a device driver for a network drive using UDP you'd have to find a way to route packets that one program didn't want to the other program.

Wouldnt worry about that. Worst case scenario those 3 people wanting to simultaneously use mTCP will install second network card, I think overwriting "PKT DRVR" string of first packet driver int handler should allow for such hack.

I just ordered myself a Tattiebogle while waiting for other options to materialise. There are several on this thread that seem drool-worthy; can't wait to see what becomes available to us amateurs who don't do a lot of soldering on our own :)

/Eirik

ltning wrote on 2022-01-19, 16:56:

I just ordered myself a Tattiebogle while waiting for other options to materialise. There are several on this thread that seem drool-worthy; can't wait to see what becomes available to us amateurs who don't do a lot of soldering on our own 😀

/Eirik

I hope you will get better results than this guy: https://www.youtube.com/watch?v=NWBXxO2YHps

ltning wrote on 2022-01-19, 16:56:

I just ordered myself a Tattiebogle while waiting for other options to materialise. There are several on this thread that seem drool-worthy; can't wait to see what becomes available to us amateurs who don't do a lot of soldering on our own 😀

/Eirik

Here's to hoping that user sintech's adapter gets produced in a larger quantity.
It works great. Does up to PIO4 & MWDMA2.
plays audiocds
emulates both a master & slave device at the same time, ie two devices. hdd, cdrom or zip drive or combination thereof. current version doesn't allow for seperate physical slave or master device.
average read speed in dos on a ISA 486 is around 1300K/s, same for cdrom.
...

Who are you ? 😁

ps. If you get your tattiebogle, could you post some transferspeeds? Thanks

weedeewee wrote on 2022-01-19, 20:03:

ltning wrote on 2022-01-19, 16:56:

I just ordered myself a Tattiebogle while waiting for other options to materialise. There are several on this thread that seem drool-worthy; can't wait to see what becomes available to us amateurs who don't do a lot of soldering on our own :)

/Eirik

Here's to hoping that user sintech's adapter gets produced in a larger quantity.

Right, how can we go about ensuring that happens? :D
If you catch me at a vulnerable moment (late at night, after much frustration with broken vintage hard/software, perhaps a couple of beers, etc.) you might find me willing to throw money after more obscure and weird hardware ;)

weedeewee wrote on 2022-01-19, 20:03:

It works great. Does up to PIO4 & MWDMA2. plays audiocds emulates both a master & slave device at the same time, ie two devices. […]
Show full quote

It works great. Does up to PIO4 & MWDMA2.
plays audiocds
emulates both a master & slave device at the same time, ie two devices. hdd, cdrom or zip drive or combination thereof. current version doesn't allow for seperate physical slave or master device.
average read speed in dos on a ISA 486 is around 1300K/s, same for cdrom.
...

It takes less than this to make me drool.

weedeewee wrote on 2022-01-19, 20:03:

Who are you ? 😁

Uhm. Someone who randomly jumps onto threads here? ;)

Nah, just another mid-life crisis, an old fart attempting to rediscover the days when computers were tools that did what you told them, not black-box devices that tell you what you may do (for them). Nothing to see. Move along.

weedeewee wrote on 2022-01-19, 20:03:

ps. If you get your tattiebogle, could you post some transferspeeds? Thanks

I can do that. What's the preferred way to measure such things on 2-486 era machines? And while here, what's the go-to defaults for benchmarking such old machines in order to produce useful results? Norton SysInfo (which I grew up with) isn't terribly useful..

/Eirik

how does one change images on this? is there some DOS utility yet or you need external control device?

ltning wrote on 2022-01-19, 20:16:

weedeewee wrote on 2022-01-19, 20:03:

Here's to hoping that user sintech's adapter gets produced in a larger quantity.

Right, how can we go about ensuring that happens? 😁
If you catch me at a vulnerable moment (late at night, after much frustration with broken vintage hard/software, perhaps a couple of beers, etc.) you might find me willing to throw money after more obscure and weird hardware 😉

No idea, I was lucky enough to catch one of his rev 1 boards.

weedeewee wrote on 2022-01-19, 20:03:

It works great. Does up to PIO4 & MWDMA2. plays audiocds emulates both a master & slave device at the same time, ie two devices. […]
Show full quote

It works great. Does up to PIO4 & MWDMA2.
plays audiocds
emulates both a master & slave device at the same time, ie two devices. hdd, cdrom or zip drive or combination thereof. current version doesn't allow for seperate physical slave or master device.
average read speed in dos on a ISA 486 is around 1300K/s, same for cdrom.
...

It takes less than this to make me drool.

doing a copy test from emulated cd to emulated hdd in windows 9x with dma mode set for both drives, I got around 2MB/s
and if I recall correctly the max dos transfer on a intel SE440BX was around 6M/s (MWDMA2 from bios i think)

weedeewee wrote on 2022-01-19, 20:03:

Who are you ? 😁

Uhm. Someone who randomly jumps onto threads here? 😉

Nah, just another mid-life crisis, an old fart attempting to rediscover the days when computers were tools that did what you told them, not black-box devices that tell you what you may do (for them). Nothing to see. Move along.

mm, maybe a better question would've been
What do you want ? 😁
( just guessing that your avatar is an image of a shadow, if not, just ignore )

weedeewee wrote on 2022-01-19, 20:03:

ps. If you get your tattiebogle, could you post some transferspeeds? Thanks

I can do that. What's the preferred way to measure such things on 2-486 era machines? And while here, what's the go-to defaults for benchmarking such old machines in order to produce useful results? Norton SysInfo (which I grew up with) isn't terribly useful..

/Eirik

Whatever you can get your hands on, checkit, speedsys... phil has a benchmark pack with several speed test softwares inside of the archive.
if you try a linux timed copy of an appropriatly sized input file read from the emu and written to /dev/null, that would do nicely 😀

keropi ? which device?

weedeewee wrote on 2022-01-19, 20:32:

mm, maybe a better question would've been
What do you want ? 😁
( just guessing that your avatar is an image of a shadow, if not, just ignore )

I have plenty worth living for, still :D

Sorry, it's exceedingly rare that people catch on - to the point where even I don't, unless it's shoved in my face ;)

weedeewee wrote on 2022-01-19, 20:32:

Whatever you can get your hands on, checkit, speedsys... phil has a benchmark pack with several speed test softwares inside of the archive.
if you try a linux timed copy of an appropriatly sized input file read from the emu and written to /dev/null, that would do nicely :)

keropi ? which device?

I have FreeBSD running on one of the machines, so I can do a dd-test from there. I have no Windows anywhere, so I'll try to find some DOS software that'll do it.

/Eirik

weedeewee wrote on 2022-01-19, 20:32:

keropi ? which device?

any really... even if something is planned I would like to know so I can make a mental note of it 😀
I have not catch up with the thread atm but if something has a way to mount images using DOS on the target system then it's an instant purchase for me

ltning wrote on 2022-01-19, 20:45:

weedeewee wrote on 2022-01-19, 20:32:

mm, maybe a better question would've been
What do you want ? 😁
( just guessing that your avatar is an image of a shadow, if not, just ignore )

I have plenty worth living for, still 😁

Sorry, it's exceedingly rare that people catch on - to the point where even I don't, unless it's shoved in my face 😉

Still plenty of moments between tik & tok 😁

I have FreeBSD running on one of the machines, so I can do a dd-test from there. I have no Windows anywhere, so I'll try to find some DOS software that'll do it.

That would suffice for me. You could try with different blocksizes for the fun of it.

keropi,
I think the tattiebogle (electric_monk 's device) had a firmware update & dos utility made ( it's mentioned in this thread) that would allow image swapping in dos with the slight caveat that it needs to be plain dos, no emm386 or other protected memory manager loaded since the utility does direct port writes.
sintech's emu also has that same functionality and caveats. also has three buttons on the board, prev image, select drive and next image at the moment. (an oled display can be attached)

edit: added some info

Yes, mine supports a DOS utility I made (and I plan to add Win16 and Win32 apps at some point, and possibly Linux for a laugh) to control, as well as plugging in a Crystalfontz USB button/display module which gives you menus you can use to switch disk images/etc. On top of that you can control it via USB (not super useful for this, but some people use it for arcade stuff, usually with a Raspberry Pi).

Edit to add: things like HDD support and simultaneous master/slave have been on my TODO list for a long time, but aren't finished yet (too many other TODOs, projects and other aspects of life in general keep requiring attention). It does support writing to disk in ZIP disk mode, of course, but that's mega different to IDE hard disk 😉

Remember to grab the newest firmware from issues.tattiebogle.net in the "DOS compatibility" thread for the best support. Old firmwares had a couple of ISA timing issues.

Today during a walk to refresh my mind I had a reflection about games on hybrid CD (with CD-DA tracks). The hybrid word led me to think of a new approach.
Instead of having a complete optical disc emulator, why not having just a partial one.

What exists :
* VCD (Virtual CD-ROM emulators) for MS-DOS and Windows 9x (post Win95A)
* expensive complete IDE ODE with or without audio support ('complete' means it can fully simulate a drive)
* Hybrid CD-ROM with CD-DA tracks
* Network mounted drive
* Big storage drive

Putting aside the complete ODE solution, it is possible for years now to mount an image from a local drive or networked drive and play a game.

But there are two problems:
* copy protection (not a problem on MS-DOS and Windows until around 1998)
* audio tracks playback

Game with audio tracks works that way:
ATAPI commands are send to the drive through the data cable to control the playback (play track #x, stop, pause). Then the drive act like an normal CD audio player converting the bit-stream to an analog signal to a stereo line-out connected to a sound card by a 3-wire cable (RLG) where it is mixed with other audio signals. On the other way, on such discs, the track 1 is special because it is the data track. Data here are decoded and transmitted on the data cable.
The two signals are transmitted in parallel and only what is passed through the data cable can be stored in RAM in used by the CPU. One note is that data from audio tracks are read to be stored in a dedicated buffer, then this buffer is used by the DAC (Digital to Analog Converter). That means during the time the buffer is read, the drive can do other things, just that the buffer had to filled fast enough for the music to not be interrupted.

There is another way to play audio tracks:
It is possible to transmits through the data cable the content of audio tracks. But in this case the CPU must do a conversion to get produce PCM data a sound card will understand. That is not possible on slow machines (pre-Pentium 150) because it require a lot a CPU power and memory bandwidth, meaning on this machines, the sound will have a lot of glitches as not everything can be handled. As most of the games with audio tracks are precisely pre-Pentium 150, that is not a solution. That is what Windows 2000 and latter do and some VCD (eg. DT) too.

So here is my though:
You can see it as a hybrid solution between a complete ODE and a VCD.
That would consist of two parts: a very limited IDE and a very light TSR program to command it.
The goal is to mount CD-ROM image as before. The ODE will ignore (return errors) most of the ATAPI commands except some needed for it to operate. When launched, the TSR will detect the ODE then when a program is launched it will scan the RAM to detect and hack ATAPI commands for controlling audio CD. It will then send a command to the ODE to access a file:
ex: play track 1 will give search file /KEY/PLAY/GAME.EXE/TRACK1
pause will gives search for /KEY/PAUSE
The KEY is just a name with forbidden characters to only allow request from the TSR.
The firmware of the ODE will look for a folder named GAME.EXE, and if it exists will look for files named TRACK1.SOME_SUPPORTED_FORMAT in there and play the file to the analog output.
The audio files would be stored on a removable media (micro-SD card). The card can be filled with the music of all games wanted.
With the following advantages:
* it is totally transparent for the user. Just mount the CD image.
* changing the original tracks by a custom playlist, even in the case a real hybrid-CD is used.
* it would not require expensive chips to do it because apart the decoding of audio files, there is no need for computing power and low cost audio hardware decoder exists for FLAC and MP3.
And with the following disadvantages:
* A TSR must be loaded that will consume precious bytes of base memory
* Two CD-ROM drives have to be configured, the ODE and the VCD meaning even more KB of memory.
* An IDE port is used with no accessible storage on it

It is surely feasible, but I say it again, this is just a thought on my part.
What do you think about it?

Datadrainer wrote on 2022-01-28, 17:48:

So here is my though:
You can see it as a hybrid solution between a complete ODE and a VCD.

This is what was already proposed few pages ago 😀 by jbenam and 0x90 working on network redirector instead of hardware addon.

Datadrainer wrote on 2022-01-28, 17:48:

The ODE will ignore (return errors) most of the ATAPI commands except some needed for it to operate

If you already build hardware IDE disk emulator emulating ATAPI on top of it is a formality. The problem is not 'how to implement ATAPI', the problem is 'how to build cheap IDE emulator' where cheap is <$100. Main problem is standard ISA bus/IDE interface access times requiring either programable logic or very fast microcontroller and dedicating whole core to IO. At page 16 of this thread I erroneously assumed Tattiebogle Implemented IDE bus by bitbanging using carefully optimized assembly language routines, turns out electric_monk went the sane route and slapped FPGA on it, and so did sintech and retrotronics.org/home-page/netpi-ide/ guy.

I still believe its in the realms of possibility to bitbang IDE (~200ns) with something as cheap as ESP32 or especially RP2040 (Pi Pico).
This would give us, counting absolute rock bottom prices at quantity, BOM:
~$2 PCB
~$2 ESP32/RP2040
~$1 SN74LVC8T245
~$2.5 SN74LVC16T245
$0.2 microsd card slot
$0.2 IDE pin header 2x40 2.54mm
$0.06 3.5mm headphone jack
~$1.5 passives (multiply by whatever if you believe in audiophoolery)

$6 and no stock/$15 at Mouser PCM1794A
or
$2 for two 8bit DACs if we dont care about audio quality 😀
and
$1.5 dual opamp (multiply by whatever if you believe in audiophoolery)
or
$4 and no stock anywhere CS4344
or
$6 pcm5102
or
$1 ESS ES9023 (integrated opamp, available at mouser)

or
free Coaxial S/PDIF and I2S outputs

$10-20 manufacturing if DIY in small batches on a kitchen table, unless you expect people with EE education to work for below McDonalds wages
or
~$5-15 if jlcpcb. Thruhole hand assembly fees, extended parts fees, it all adds up. Soldering IDE header alone is ~$2, have to select from limited, often more expensive (for example ESP32 module 2x the cost, RP2040 out of stock, DAC $6 pcm5102 instead of $1 ES9023 etc) parts list.

$2-5 taxes/import duties (for the parts between china-assembler)
$10 shipping

all in all ~$50 is doable assuming firmware written for free by community.

Datadrainer wrote on 2022-01-28, 17:48:

When launched, the TSR will detect the ODE then when a program is launched it will scan the RAM to detect and hack ATAPI commands for controlling audio CD.

no need. Afaik CDROM in DOS is implemented using Network Redirector - MSCDEX pretends to DOS to be a network drive, and on top of it exposes some additional CD related functions on one of the interrupts.
http://www.math.uni-rostock.de/~nfa506/fakecddr.html

Datadrainer wrote on 2022-01-28, 17:48:

It will then send a command to the ODE to access a file:
ex: play track 1 will give search file /KEY/PLAY/GAME.EXE/TRACK1
pause will gives search for /KEY/PAUSE

this has also been covered, caching disk access might be a problem thus you would have to
/KEY/PLAY/TRACK1/somerandoms/selfincreme/ntingstring
/KEY/PAUSE/somerandoms/selfincreme/ntingstring

Datadrainer wrote on 2022-01-28, 17:48:

The KEY is just a name with forbidden characters to only allow request from the TSR.

whole point of forbidden characters in DOS names " * / : < > ? \ | is they will be filtered out
you dont need them when using /somerandoms/selfincreme/ntingstring as an access token

Datadrainer wrote on 2022-01-28, 17:48:

* A TSR must be loaded that will consume precious bytes of base memory

no problem since we in turn get rid of physical CDROM driver

Datadrainer wrote on 2022-01-28, 17:48:

* Two CD-ROM drives have to be configured, the ODE and the VCD meaning even more KB of memory.

I dont understand why

Datadrainer wrote on 2022-01-28, 17:48:

* An IDE port is used with no accessible storage on it

Again, if you already have hardware IDE emulator everything described above is redundant.

rasz_pl wrote on 2022-01-29, 09:50:

Datadrainer wrote on 2022-01-28, 17:48:

* Two CD-ROM drives have to be configured, the ODE and the VCD meaning even more KB of memory.

I dont understand why

Because I was seeing something more like a CD audio player than a full ODE with support for ATA and ATAPI extensions. This way bus speed is not a problem because it would work with ATA-1 (PIO 0). The goal is really to just play audio tracks, not data tracks. You send the instructions to play and it plays. Period.
But the data have to be taken elsewhere: on a HDD, on a network drive, from an original image mounted as a drive with software like tools from SHSUCD or from the original CD on a real CD-ROM drive.

rasz_pl wrote on 2022-01-29, 09:50:

Datadrainer wrote on 2022-01-28, 17:48:

* A TSR must be loaded that will consume precious bytes of base memory

no problem since we in turn get rid of physical CDROM driver

It would just need to be configured in the BIOS, you load MSCDEX with ATAPI compatible driver and the TSR would do the rest. Maybe it is possible to find a way to not use MSCDEX at all, so no initialization code is needed. That would be better.

rasz_pl wrote on 2022-01-29, 09:50:

Datadrainer wrote on 2022-01-28, 17:48:

The KEY is just a name with forbidden characters to only allow request from the TSR.

whole point of forbidden characters in DOS names " * / : < > ? \ | is they will be filtered out
you dont need them when using /somerandoms/selfincreme/ntingstring as an access token

I think sending non-valid characters for filename is not a problem, as it is just a RAW RAM data, but managing thing like REST commands with valid characters is good too.

rasz_pl wrote on 2022-01-29, 09:50:

all in all ~$50 is doable assuming firmware written for free by community.

I agree with the cost, something like 50 bucks pre-assembled, and 15 bucks as a DIY would be great. This was the main purpose of my thought.

rasz_pl wrote on 2022-01-29, 09:50:

Datadrainer wrote on 2022-01-28, 17:48:

* An IDE port is used with no accessible storage on it

Again, if you already have hardware IDE emulator everything described above is redundant.

The point is, with my solution, you don't. As there is only four IDE ports on old machines, sometime even 2. That's a problem. But it could be possible to make the device external instead. Plug on a serial port. The commands sent on the serial port and to output line signal to sound cards Line-in. So no need to use a precious IDE port. And it's easier to change the SD card.

Datadrainer wrote on 2022-01-29, 19:32:

Because I was seeing something more like a CD audio player than a full ODE with support for ATA and ATAPI extensions. This way bus speed is not a problem because it would work with ATA-1 (PIO 0). The goal is really to just play audio tracks, not data tracks. You send the instructions to play and it plays. Period.

TL;DR... Not worth the resources and time to develop such specific software/hardware solution which will work only in DOS anyways... More specifically this hypothetic hardware part which only plays audio cds. At least, a proper ODE with support for at least UDMA66 can be used not only on DOS, but other operating systems, machines, consoles, and even on custom develops, which generally are the ones paying a big part of the costs anyways... Taking in count the apparent cheapstaking around the PC retro gaming community.

all in all ~$50 is doable assuming firmware written for free by community.

🙁

hyoenmadan wrote on 2022-01-30, 01:09:

Taking in count the apparent cheapstaking around the PC retro gaming community.

are you from Amiga scene by any chance? 😀

hyoenmadan wrote on 2022-01-30, 01:09:

TL;DR... Not worth the resources and time to develop such specific software/hardware solution which will work only in DOS anywa […]
Show full quote

Datadrainer wrote on 2022-01-29, 19:32:

Because I was seeing something more like a CD audio player than a full ODE with support for ATA and ATAPI extensions. This way bus speed is not a problem because it would work with ATA-1 (PIO 0). The goal is really to just play audio tracks, not data tracks. You send the instructions to play and it plays. Period.

TL;DR... Not worth the resources and time to develop such specific software/hardware solution which will work only in DOS anyways... More specifically this hypothetic hardware part which only plays audio cds. At least, a proper ODE with support for at least UDMA66 can be used not only on DOS, but other operating systems, machines, consoles, and even on custom develops, which generally are the ones paying a big part of the costs anyways... Taking in count the apparent cheapstaking around the PC retro gaming community.

all in all ~$50 is doable assuming firmware written for free by community.

🙁

As a reminder, my idea is not the basis of a project, just an idea. And my question was just, would it be useful to have such a product?

But I see the point of @hyoenmadan. He want a powerful ODE and he is going to pay the price for it. That's great because Tattiebogle made one that seems to work nicely. Though, I don't know if it support UDMA66... So not useful for him.

I am going to be provocative, but to recall two realities:
* A retro thing (here computing) is about undiscarded trash. It has value only for those who give one. That's not art, that is obsolete consumer products that can run artistic creations.
* Not anyone have the bank account to afford to spend more than $200 regularly for their retro computer. As the machine itself is just junk (no matter the condition). Example: If buying a Voodoo card cost a lot today, it is because of a bubble speculation due to the demand, not because they are becoming rare (the supply is good)... Another example: a Picasso painting is rare because it is expression and the demand is high, so is the price, that is also speculation, but more justified because a work of art is a single shot.

But if it is of an interest to materialize my idea into something it would surely be based around an Arduino with pre-made shield to read the CF, decode and play the audio. That is why it would surely be better to use a COM (serial) port than a PATA port as I was thinking before. From my point of view such a solution would be 1) affordable for anyone 2) buildable by anyone. And it can work with Windows too with the appropriate software and that bring us to a point I totally agree with @hyoenmadan, the software needs to be done and that is something that requires a lot a knowledge and time to make it lightweight and stable for at least 2 OS. But basically, it is to catch ATAPI commands to a CD-ROM drive into the RAM and send a command matching the executable name + the ATAPI command to the COM port. The micro-controller doing its stuff then to play the right music. As I see it, it seems not very difficult to implement. But maybe I'm missing something...

ps. I love all of my old hardware very much and I'm spending a fortune to upgrade and fix it... But I'm realistic about what it is. And I think it's better to have several choices rather than one.