Deksor wrote on 2021-11-29, 11:34:

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

mTCP seems to be written C++ and also seems to be something which needs to be built into (linked with) the program using it. I'm no expert on DOS programming (on the contrary) but seems to me .sys programs really are best written in pure ASM only (well, it IS possible to use C, probably C++ too, but seems things get messy and complicated, probably at least a special linker script or custom tools for linking is required, and then there are restrictions like very little stack space guaranteed to be available unless you setup your own stack and always switch to it and back when called by DOS, there is no PSP by default so some DOS calls the C library functions want to use won't work as expected, etc., also a compiled driver will probably inevitably eat much more memory).

A separate TCP/IP implementation which is loaded as a device driver or TSR could possibly be an option, but are there any which are 1) totally free to use, 2) not memory hogs, 3) actually good?

An MSCDEX replacement (rather than a low level CD-ROM driver) written in C/C++ might be more feasible, but I'd rather avoid dealing with any ISO filesystem and DOS network redirection stuff myself (all filesystem & redirection handling is the responsibility of MSCDEX or equivalent, not the CD-ROM driver). And I've read MSCDEX replacements can have compatibility problems with games so I don't know if I want to try writing one...

Deksor wrote on 2021-11-29, 11:34:

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.

That is one option, but someone else would have to do it. I don't have the required skills to design hardware. It would also never be as low cost as a software only solution can be.

I was also thinking about possibly using a hard disk in the DOS machine to hold images (probably pre-converted to a special format, at least I wouldn't want to try parsing cue files in ASM, even in my C "image server "program I'm using a library for it), then using one sound card (GUS or WSS) for playing CD audio while another (SB compatible) is being used by the game for sound effects. An Ethernet CD driver could also support this in addition to just passing all audio requests to an external device (serial is obviously too slow). Not sure if I want to get into sound card programming though...

edit: I wonder what's the practical maximum speed of an ECP or EPP parallel port? Wikipedia claims maximum transfer rate for EPP is 2MB/s and ECP is 2,5MB/s but that sounds a bit much... probably also depends somewhat on how fast the system is? I know there were some actual CD drives which connected via parallel port back in the day, but a couple of people I asked said they were always really slow... and in any case I don't currently have the necessary cables or hardware to test any sort of parallel port solutions, seems both DOSBox or PCem don't really support anything but Covox-a-likes connected to them either.

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.)

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.)

Yes, UDP is probably the better option, but often the definition of "TCP/IP" includes UDP even if it's not strictly correct to say so. (see multiplayer menus in a lot of games, "TCP/IP stack" which also does UDP, ICMP and what not, etc.)

I might attempt to just use an IPX driver for the DOS side of this actually, at least in the beginning. Just pass some IPX broadcast packets around on the local network, they can be captured and crafted on another machine even if it's running a modern OS which knows nothing about IPX.

@Deksor, as you’ve mentioned that the IDE interface actually uses the ISA bus deep down, would it be possible to allocate a BIOS ROM in memory, just like an EEPROM would be connected to the ISA bus? Like with an XT-IDE card.

Exploiting such a connection could definitely bring some more cards to the table. For example, the ability to boot from CD when that support isn’t provided by the system BIOS.

I’m just thinking out loud here btw! 😀

Deksor wrote on 2021-11-29, 11:34:

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

IDE/ATAPI is the simplified cut down version of ISA bus.
You just described DiskOnChip https://en.wikipedia.org/wiki/M-Systems#DiskOnChip
https://hackaday.com/2018/03/30/a-retrocomput … disk-on-a-chip/
that smbaker hack culminated in https://www.smbaker.com/raspberry-pi-virtual- … -xtat-computers
You can pick this design as is, and only modify BIOS interrupt wrapper to change it from emulating floppy to whatever you want (cdrom, hdd).
It got more complicated, requires additional code to run on the host, and is less universal (works only in x86 compatible machines with free isa slot and standard bios). At that point you could just modify SHSUCDHD https://github.com/adoxa/shsucd and skip all that additional hardware.

InjecTioN wrote on 2021-11-29, 23:43:

@Deksor, as you’ve mentioned that the IDE interface actually uses the ISA bus deep down, would it be possible to allocate a BIOS ROM in memory, just like an EEPROM would be connected to the ISA bus? Like with an XT-IDE card.

Exploiting such a connection could definitely bring some more cards to the table. For example, the ability to boot from CD when that support isn’t provided by the system BIOS.

As stated above - IDE/ATAPI is the simplified cut down version of ISA bus. You only have 3 address pins and 2 chip selects to work with, and they are all hardcoded to specific registers:

1Data port
2Error / Features
3Sector Count
4Sector Number (LBA bits 0-7)
5Cylinder low  (LBA bits 8-15)
6Cylinder High (LBA bits 16-23)
7Device/Head   (LBA bits 24-27)
8Status / Command
9
10Alternate Status / Device control

jbenam wrote on 2021-11-28, 09:31:

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.

modifying https://github.com/adoxa/shsucd to add virtual audio tracks support and routine sending UDP control packet to a dedicated network server running on a rpi seems like the easiest solution. rpi could store mp3/ogg versions of those audio tracks to further help with storage, or directly read and play audio tracks from iso image it is sharing over the network.

rasz_pl wrote on 2021-11-30, 05:01:

modifying https://github.com/adoxa/shsucd to add virtual audio tracks support and routine sending UDP control packet to a dedicated network server running on a rpi seems like the easiest solution. rpi could store mp3/ogg versions of those audio tracks to further help with storage, or directly read and play audio tracks from iso image it is sharing over the network.

Well, first version I had somewhat working was just a TSR passing through everything to already loaded MSCDEX (or workalike), but sending info about audio requests over serial port to a program which loads cue/bin (single .bin 2352 bytes/sector from start to end only) and then plays PCM data via SDL2 from the bin file. Feels a bit too hacky to me to always have to make and keep a separate copy of the data track alone for mounting on DOS, but for sure it's the easiest way. 😜

At one point I actually tried to build SHSUCD* but seems newer versions of NASM don't like it at all and some effort would be required to fix the code. (the version of NASM I get from distro packages is 2.14.02 and NASM developers last released 2.15.05 so it has surely changed a lot since 0.98.39 which readme says was used to build SHSUCD*)

darry wrote on 2021-11-29, 12:19:

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.

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

Yes, I think it makes sense - you'd need to simulate a second drive (which isn't super desirable, as it's then not authentically simulating a single drive. Obviously it could be made optional, though) and you'd need to simulate a disk containing a mapping where each file mapped to a new sector. Then on DOS you'd potentially be able to send messages back by reading the files to send a message, and obviously the contents of these files could contain data coming back out of the device. Anything non-DOS or even potentially smarter MSCDEX drivers could potentially still mess it up if caching is involved, though, and it'd be pretty fiddly (every sector is 2K so that's the resolution the channel would have, so it'd be a new 2K read just to send a single value, the index of the requested file, back to the PCB). Enough to pick an ISO but not much else.

Regarding the other conversation, my IDE simulator's original firmware contained an experimental TCP/IP stack that was activated by plugging in an Amazon Basics ethernet dongle, which gave a telnet server for configuring the device. I had intentions to add a webpage and FTP too, but nobody seemed interest so I just pulled the whole thing as it had a few bugs and to save some memory.

Were there ever any quadrophonic Audio CDs? You could send data using Audio Channel Control setting volume to unused channels 2 and 3
https://makbit.com/articles/mscdex.txt
> Drives that don't support 4 output audio channels may ignore output to channels 2 and 3.

or if you dont support variable volume at all just use channel 0-1 volume settings

>Drives that do not support variable audio control will treat a setting of 0 as off and 1-0xff as on.

is PLAY AUDIO command passed directly to the drive? is mscdex validating passed data against TOC? if its not then you can pass data by defining impossible parameters (two 32bit ints so lots of room) as your commands.

rasz_pl wrote on 2021-12-01, 08:11:

Were there ever any quadrophonic Audio CDs?

They must be extremely rare if they exist at all. Wikipedia claims four channel support was dropped when CDs became a proper IEC standard.

rasz_pl wrote on 2021-12-01, 08:11:

is PLAY AUDIO command passed directly to the drive? is mscdex validating passed data against TOC?

I just did a quick test and seems no validation is performed by MSCDEX. I can put bad data in the start & length fields of a play audio request and it gets passed to the underlying device driver by MSCDEX (from MS-DOS 6.22) just fine. Whether the usual low level device drivers for ATAPI, SCSI, or w/e CD drives validate these requests is still an open question however...

I really like 0x90's solution of accessing bin/cue images on another machine via serial port, and it got my wheels turning.

What about creating a device that emulates the Microsolutions Backpack devices that connected to the parallel port? There's a Linux driver, which might provide some clues on the implementation. Could a Raspberry Pi signal fast enough that it doesn't need help from an FPGA? If so, maybe it could be a cheap alternative to mac2sd or IDE Simulator and it could be used with machines that don't have an easy way to connect a SCSI or IDE device (like laptops). Performance would obviously not be as good, but you know: trade-offs. I kind of like the idea of having a rPi with a DB-25 on the end that I can plug into any of my retro PCs for ODD emulation.

sintech 's ata/atapi emulator works with bin/cue and iso and also plays audio cd's.

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

sintech 's ata/atapi emulator works with bin/cue and iso and also plays audio cd's.

Link? I've seen their SD to HD IDE adapter but not one that does optical disc emulation.

flynnsbit wrote on 2021-12-20, 19:00:

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

sintech 's ata/atapi emulator works with bin/cue and iso and also plays audio cd's.

Link? I've seen their SD to HD IDE adapter but not one that does optical disc emulation.

it's user sintech, here on the forum, and in this thread.

Ha ha, I'm an idiot. Sorry. I use these in a lot of my builds and didn't put 2 and 2 together. http://eshop.sintech.cn/images/ST4013.jpg

flynnsbit wrote on 2021-12-20, 19:31:

Ha ha, I'm an idiot. Sorry. I use these in a lot of my builds and didn't put 2 and 2 together. http://eshop.sintech.cn/images/ST4013.jpg

erhm? just in case there's a misunderstanding...

This is what I'm referring to.

Re: Gotek like Optical Driver Emulator - Is it possible?

weedeewee wrote on 2021-12-20, 19:53:

erhm? just in case there's a misunderstanding... […]
Show full quote

flynnsbit wrote on 2021-12-20, 19:31:

Ha ha, I'm an idiot. Sorry. I use these in a lot of my builds and didn't put 2 and 2 together. http://eshop.sintech.cn/images/ST4013.jpg

erhm? just in case there's a misunderstanding...

This is what I'm referring to.

Re: Gotek like Optical Driver Emulator - Is it possible?

Yup, I understand. I thought there was a cheap solution by sintech similar to that adapter I posted(also made by sintech). I already have the IDE Simulator card which seems very similar to the one sintech posted in the thread. I thought you were referencing something that wasn't in this thread already. The only draw back when using these on a system without USB is you need a second machine to swap the disk programmatically. I have a pi sitting there that I terminal into from my dos machine to swap the discs around. It works but having a mount command that you can pass directly to the fpga would be a huge feature.

flynnsbit wrote on 2021-12-20, 20:24:

Yup, I understand. I thought there was a cheap solution by sintech similar to that adapter I posted(also made by sintech). I already have the IDE Simulator card which seems very similar to the one sintech posted in the thread. I thought you were referencing something that wasn't in this thread already. The only draw back when using these on a system without USB is you need a second machine to swap the disk programmatically. I have a pi sitting there that I terminal into from my dos machine to swap the discs around. It works but having a mount command that you can pass directly to the fpga would be a huge feature.

I have no idea if the user sintech is affiliated with the company sintech.cn
Could you post a photo of the ide simulator card you have ?

Here ya go.

Is it possible to buy it ? I see, firmware fixed ?

flynnsbit wrote on 2021-12-20, 21:03:

Here ya go. A5164D66-E05D-4502-88FE-2B9E4DF9E04B.jpeg

ah yes, you've got this one
https://shop.tattiebogle.net/product/prod_EkTnv3Tk2Trxhf

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?
... ?