VOGONS


First post, by VileR

User metadata
Rank l33t
Rank
l33t

When programming for DOS, I typically use native Windows development tools and do most of my quick testing/debugging in an emulator. So my workflow involves very frequent file transfers from the host (Windows) to the emulated machine. When the emulator is DOSBox, its filesystem integration makes this quick and painless.

But in PCem or 86Box it gets a little more cumbersome. There may be ways to do this if the emulated system has networking (or even a CD-ROM), but let's say it doesn't. To copy anything from the host filesystem to the hard drive image, you can either:

  • Shut down the emulator, mount the image in whatever host tool you use, do your writing, restart the emulator, then wait for the emulated machine to POST etc.
  • Keep the emulator running, and use a temporary diskette image for the transfer: switch to e.g. WinImage, create/open a disk image, add your files, save, close, switch back to the emulator, mount, and copy.

As you can imagine, with frequent compile/test cycles, both of these methods get old REAL fast. However, the floppy-image method can possibly be automated (albeit in a hackish sort of way).

I'm thinking of a quick-'n'-dirty tool to let you select (and keep) a list of files, then do the image creation and file transfer in one click. Something like AutoHotkey combined with ImDisk Virtual Disk Drive should do the trick.
I've actually started working on this, but:

  • Does something like this already exist? (I couldn't find anything, but if there is such a tool, I wouldn't need to duplicate the effort.)
  • If not: would this tool be useful for anyone else?

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 1 of 21, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

For that kind of thing I like to use GNU mtools on my Linux system.
A line like mcopy -i disk.img build/from.com ::TO.COM can easily be added to a Makefile.
I don't know whether there is a Windows port of it, though.

Reply 2 of 21, by VileR

User metadata
Rank l33t
Rank
l33t

Yep, that's an option. In Windows, the abovementioned ImDisk does the same.
However my thought is to handle the required actions on the emulator side as well, probably by sending GUI events/keystrokes. There aren't too many of them, but even the manual eject/mount/copy/unmount dance does get old after a while.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 3 of 21, by superfury

User metadata
Rank l33t++
Rank
l33t++

Can't you exploit the IMD disk image format to format a 64K(1 byte less, so 65535 bytes/sector) sectors disk with 256 sectors/track, 80 tracks(for compatiblity), then a simple 4-byte header (start of the first sector, the boot record sector usually) followed by the file in all remaining sectors you want to transfer as the file system and complete disk? Then you can transfer a huge amount of data using the floppy disk standard(although formatted to the maximum supported amount)? That's 16MB/track, for a whopping of 1.2GB using said disk image for one huge file? of course, the last sector can be less than 64K to signify EOF(also signified by a sector read failure on any track, so that can be used as a EOF marker(together with maximum disk sector being reached as a reason), skipping the need for the header altogether, thus creating a disk image out of a file essentially?

Although you'll need a simple tool to format it like that? Although in the end, the maximum size will be a bit lower(since sector sizes need to be a power of 2, so 32K sectors except the final sector, requiring smaller sector powers of 2). Although to do non-power of 2 transfers for the final sector, you'll effectively need said header anyway(to perform rounding down of the final data)?

So that's a 4-byte file size header combined with the rest of the disk needing to be 32K sectors for containing all file data(thus allowing 32K*256*80*2=1.28GB of storage, with 4 bytes being reserved for the file size, thus 4 bytes less of floppy disk space for your single file)? Of course, that file can also be things like a simple .zip archive(which can be easily unpacked using any tool, e.g. pkunzip or linux commands)?

In linux (or perhaps MS-DOS too), this can be easily done by a simple program to read the first 4 bytes, then the rest of the data from disk according to that, finally unpacking it with a unpacker?

Last edited by superfury on 2020-04-11, 09:39. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 21, by VileR

User metadata
Rank l33t
Rank
l33t

That sounds a bit like making three left turns when you can turn right... and I don't think the emulated DOS would support these oddball formats, anyway?
To transfer large amounts of data there's always a CD-ROM image (although, with the time it'd take to copy all that data inside the emulated machine, the "live injection" approach may not be worth it).

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 5 of 21, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I think this came up on the pcem forums but Sarah wasn't interested in the VPC/Vmware approach due to dealing with multiple operating systems both on guest and host or mabye I'm thinking of someone else, would have to track down the post.

How To Ask Questions The Smart Way
Make your games work offline

Reply 6 of 21, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Why not considering networking?
I do the same on QEMU, too, and I have SLIRP or TUNTAP networking options with the host. On Windows host, I use TUNTAP. On Linux host, I use SLIRP which gives access to SMB shares on the host.

Reply 7 of 21, by VileR

User metadata
Rank l33t
Rank
l33t

I've never actually tried networking with PCem/86box, but I should mention that my emulated target is about as minimal as it can be: 8088 CPU, 640K RAM, DOS only.
Such a guest machine should handle mTCP + an 8-bit NE2000 packet driver, but that means FTP for file transfers - kinda inconvenient for very frequent compile/test cycles. As for complete network solutions that allow remote shares, all reports I've seen indicate failure (and on the real hardware, they're usually very RAM-hungry when they do work).

My automated floppy transfer kludge is coming along, but if there's a convenient networking solution for XT-class DOS guests in PCem/86box, I wouldn't mind trying it out!

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 8 of 21, by mbbrutman

User metadata
Rank Member
Rank
Member

Have you thought of using FTP with a batch file?

For my testing I have a batch file and a text file. The batch file fires up FTP and has it redirect STDIN from the text file. The text file has all of the input that FTP would need to sign on, change directories, and transfer a file. It is not as convenient as having a drive letter right there, but typing "get" (the name of my batch file) is pretty quick once it is setup.

Reply 9 of 21, by VileR

User metadata
Rank l33t
Rank
l33t
mbbrutman wrote on 2020-04-11, 01:01:

Have you thought of using FTP with a batch file?

For my testing I have a batch file and a text file. The batch file fires up FTP and has it redirect STDIN from the text file. The text file has all of the input that FTP would need to sign on, change directories, and transfer a file. It is not as convenient as having a drive letter right there, but typing "get" (the name of my batch file) is pretty quick once it is setup.

That's more like it - sounds like an elegant solution! I should probably try to set up host-guest networking and give this a shot.

However, I think my "quick file injection" Windows tool is pretty much finished already.... so, if anyone feels like doing a bit of testing, I'd appreciate the input:

Filename
PCemuFileInjector.zip
File size
319.01 KiB
Downloads
789 downloads
File license
Public domain

Should be quick and easy to use:

  • If you don't have it already -- install ImDisk Virtual Disk Driver (takes care of creating the temporary disk images transparently)
  • Just run the tool, and select (or drag/drop) the files you want to transfer.
    Whenever you have the emulator window open at the DOS prompt, you can simply click "inject files", and it'll do all the work for you - including COPY/XCOPY commands, if you select the respective option.
InjShot.png
Filename
InjShot.png
File size
9 KiB
Views
11277 views
File license
Public domain

My use-case involves frequently updating and transferring the same file(s). In that case, you can simply keep the tool open with a fixed file list: when you click "inject", it'll always grab the most recent copies from the host filesystem.

If anything isn't working right, you can also tick "debug info" for more verbose output to help troubleshooting. But hopefully that should be rare, unless there's something massive I've missed...

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 10 of 21, by ViTi95

User metadata
Rank Member
Rank
Member

Hi VileR! I've been looking for a solution to copy files to 86box directly and found this thread, but I haven't been able to use your tool with 86box 3.11. Maybe can you update it to support this version? Or there is a new way to copy files?

Thanks!

https://www.youtube.com/@viti95

Reply 11 of 21, by superfury

User metadata
Rank l33t++
Rank
l33t++

If using FTP, UniPCemu can also act like a PPP server as well as a serial modem capable of connecting to it (using TCP connections like Dosbox). So if you can use virtual serial ports on the host, you can connect UniPCemu to one end (like using COM0COM) as a modem and allow the other side to be connected to your emulator (which uses it's own serial port to access it like a normal serial Hayes modem). Then it's simply a matter of using miniterm or some other dial-up terminal to dial to the PPP server (which can be the very same UniPCemu app instance if configured for that), then start a PPP IPv4 driver to get network connectivity. SMB works on the PPP connection, although only within the same network as the client (so with other clients also connected to the UniPCemu PPP server using dial-up, verified with multiple Windows 95 instances myself). FTP is also possible using the same method (which doesn't have the shortcomings of the SMB protocol requiring the same network, as the host network isn't available to clients connected (although the internet is) due to the way subnet broadcast works) to connect to any other client on both networks.
Although oddly enough UniPCemu can't perform ARP to it's own host machine it's running on (Windows 10 at least) somehow. It will simply fake the ARP reply to itself using it's known host data (from the server settings) in that case though.

Although that assumes your emulator can use direct serial port access (physical or emulated doesn't matter in this case) like Dosbox can with it's "directserial" serial mode setting.

Tried the PPP connection myself using the Arachne web browser's own drivers (it's miniterm to dial, combined with lsppp or pppd or any other compatible IPv4 PPP driver after that). With autoconfiguration it requires a passive option for the proper PPP to start, but with manual text-mode login it can also work properly on PPP (selecting empty username and password and the protocol being given as ppp (lower case)).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 12 of 21, by ViTi95

User metadata
Rank Member
Rank
Member

I've discovered a better way, using MSCDEX with 86box CD emulation. If you map a Windows folder to a 86box CD drive, the files are always updated, so no need to mount/unmount the drive. This way I can copy files very fast and without having to create images nor something like that.

https://www.youtube.com/@viti95

Reply 13 of 21, by superfury

User metadata
Rank l33t++
Rank
l33t++

SMB using UniPCemu server should be possible in theory.
Just use a virtual serial port like COM0COM to create a virtual serial port.
Then connect modern windows to the serial port on one end and UniPCemu emulating a modem on the other end (directserial). After that, use Windows to dial to the server's own TCP port using PPP to archieve a direct dial-up connection with any connected clients.

After that is setup, another client can connect to the server as a normal client (using Dosbox's hayes modem, UniPCemu or other compatible TCP-based dial-up modem).

Then, since both the Windows(running SMB) and a client(which connects using SMB) are connected on the same local network(within UniPCemu's server) they can connect through SMB.
Didn't go past two Windows 9x clients in Dosbox tho, but they can see each other and transfer files.

Don't know if a MS-DOS SMB client exists though. Also you might need to enable SMB 1.0 inside Windows 10 and up (it's disabled by default for security reasons).

https://serverfault.com/questions/1055050/smb … s-10-1809-fails says that some modern issues of Windows might have issues, but I don't know if it's fixed in newer versions.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 14 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

PCem is too limited, but 86Box maybe supports serial/port emulation by now.
If so, one of the null-modem programs can be used.
FileMaven v3 or the Central Point Commute software works, too.

Re: 386 , what can I do with it?

Just map one emulated port to one physical port of a 2x USB serial adapter with a null-modem attached.
The other application (DOSBox etc) then uses the other physical port.
Works on Linux, too.

Or install a null-modem driver. On XP x86, the free driver ComEmulDrv from MixW2 can be used.
http://www.mixw.de/activex.htm

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 15 of 21, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

maybe, I don't understand the question, because PCem/86Box is using VHD for HDD image format - that is directly mountable as Windows drive:

"Windows Computer Management --> Storage --> Disk Management --> Action --> Attach VHD"

I wonder how you created PCem/86Box hdd image in the first place, because the usual way (at least that I use) is the exact same steps:

"Windows Computer Management --> Storage --> Disk Management --> Action --> Create VHD"

One more time - sorry, if I am misunderstanding somehow the question...

Reply 16 of 21, by superfury

User metadata
Rank l33t++
Rank
l33t++
Jo22 wrote on 2023-01-18, 12:30:
PCem is too limited, but 86Box maybe supports serial/port emulation by now. If so, one of the null-modem programs can be used. F […]
Show full quote

PCem is too limited, but 86Box maybe supports serial/port emulation by now.
If so, one of the null-modem programs can be used.
FileMaven v3 or the Central Point Commute software works, too.

Re: 386 , what can I do with it?

Just map one emulated port to one physical port of a 2x USB serial adapter with a null-modem attached.
The other application (DOSBox etc) then uses the other physical port.
Works on Linux, too.

Or install a null-modem driver. On XP x86, the free driver ComEmulDrv from MixW2 can be used.
http://www.mixw.de/activex.htm

As for nullmodem, I used COM0COM myself testing UniPCemu's serial dial-up server. Although I needed to add a bugfix I made myself to the COM0COM driver source code to fix some detection issues with it (to allow UniPCemu to use it's documented detection algorithm, which is bugged in the last release. Then there's the whole W10 driver signing issue, requiring unsafe boot to even use the fixed device driver) if using specific COM0COM support. And unfortunately a full two-to-one serial port for full modem emulation can't be done using it (connecting two lines from a second outputting port to the first port, making the second set of DTR/RTS lines into two extra status lines for full Hayes modem emulation). Haven't found any driver capable of that, unfortunately.
Windows 10 combine two virtual serial ports with different wirings into one serial port?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 17 of 21, by VileR

User metadata
Rank l33t
Rank
l33t
mattw wrote on 2023-01-18, 13:45:

maybe, I don't understand the question, because PCem/86Box is using VHD for HDD image format - that is directly mountable as Windows drive

Last I checked it was not possible to update the contents of HDD images from the host while they were being used by the emulator (and for good reason).

ViTi95 wrote on 2023-01-12, 10:37:

Hi VileR! I've been looking for a solution to copy files to 86box directly and found this thread, but I haven't been able to use your tool with 86box 3.11. Maybe can you update it to support this version? Or there is a new way to copy files?

Thanks!

Yeah, it's been too long and I definitely need to update this for the newer 86box interface... hard to find the time lately but I'll see what I can do.

But it's good to know that new 86box supports mounting local folders as CD-ROMs - that sounds much better for emulated machines with a CD drive.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 18 of 21, by ViTi95

User metadata
Rank Member
Rank
Member

The local folder CD-ROM in 86box is near to a perfect solution, it basically works similar to a read-only shared folder. No need to update anything, just copy files between the CD mapped drive and the hard disk drive via DOS. With a simple batch script you can copy the whole folder into the hard drive directly.

This method has optimized my develop workflow a lot when 86box is required (you know, never trust DosBox).

https://www.youtube.com/@viti95

Reply 19 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

I'm using a multi USB serial adapter box for such experiments.
It has 4 ports - two are connected by a nullmodem, the others have test plugs attached.

I assume with an additional circuit using an dual opto-coupler (one LED, two phototransistors or photodiodes) it's possible to tap a serial line, too.

Two discreet transistors (BC548, 2N2222A etc) will do, too.
One transistor is used for TXD to RXD, while another transistor in parallel is used to send a copy of the data to another port's RXD.
The sending part can be done via pull-up/pull-down, I assume.

Anyway, the signals are TTL, anyway. Only a few USB to RS-232 converters do +12/-12v, afaik.
Those converters that I've seen in the past years use +5v/0v rather. Or worse, +3.3v/0v. +/- 3v is the very limit for RS-232 when it comes to detecting data, afaik.

Edit: This is slightly off-topic, but I do often use such nullmodem connections to link two ham radio programs.
Like for example, the virtual TNC of Direwolf or MixW2 and the APRS map programs (UI-View, Xastir).
UI-View runs on Windows 3.1x (286/386+), UI-View32 on Windows 95 and up.
Maybe they're useful for testing UniPCemu, not sure.

Edit: As a source for APRS PR signals, WebSDR of Uni Twente can be used.
In USA, APRS is on 144.390 MHz/FM. The rest uses 144,800 MHz/FM.
Packet Radio (APRS) is also sent by the International Space Station on 145,800 MHz in FM.
Heavens Above (Android, Web) or STS+ (DOS) can predict the current position and flight path.

Attachments

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//