How about I post a 2880k floppy image here and you can hook it up to a url link at first, so we can try it out? Later it would be nice to have it grab an image from somewhere else, although at the moment I'm not sure how we would host that, unless it were on Github somehow.

The machines i currently emulate will max out at 1.44MB disks - although I have been meaning to add support for GLaDISK which would support more...

I'll try it again and see what happens. How big is the VHD image?

There's a resource file thats around ~8MB gzipped that contains it

Actually I thought I tried loading a 2880k image locally and it worked... but perhaps it just happened to based on the disk layout. I'll put together a 1440k image. We're busting out of the seams with applications now and we can just barely fit most of the good stuff on a 2880k image, but the native C compiler and dev kit won't fit on that.

There's a resource file thats around ~8MB gzipped that contains it

Perhaps the resource is being async loaded and the emulator started prior to its full arrival?

Actually I thought I tried loading a 2880k image locally and it worked... but perhaps it just happened to based on the disk layout. I'll put together a 1440k image. We're busting out of the seams with applications now and we can just barely fit most of the good stuff on a 2880k image, but the native C compiler and dev kit won't fit on that.

I've actually never tried it!

Perhaps the resource is being async loaded and the emulator started prior to its full arrival?

we can speculate but the console should show!

we can speculate but the console should show!

I don't know how to do that or even know I should do that? Perhaps there should be a console window automatically shown so users can see what is happening? Or even have one attached to the bottom of the emulator 3-4 lines, expandable. I'll play around with it.

we can speculate but the console should show!

I don't know how to do that or even know I should do that? Perhaps there should be a console window automatically shown so users can see what is happening? Or even have one attached to the bottom of the emulator 3-4 lines, expandable. I'll play around with it.

the browser console is part of Chrome/Firefox/Safari, not part of MartyPC itself.

it's usually Ctrl + Shift + J (Windows/Linux) or Cmd + Option + J (Mac)

various debugging messages will be shown here, as well as script errors

Very cool! Thanks for posting the screenshot. Did @Vutshi send you an ELKS image? I have been swamped but haven't forgotten you want one for a web demo.

Yes, I shared a couple of images, but they are not standard ELKS configurations.

my floppy drive emulation is sort of high level and so the size of a drive mostly determines what size they end up when formatted, but doesn't restrict you from reading as much as the BIOS will let you.

The standard ELKS configuration uses BIOS INT 13h calls for all floppy and disk access, as well as finding out what the BIOS thinks the media size is. It sometimes "probes" the floppy by reading various tracks or sectors, as ELKS requires a fixed/known CHS for all media. This is usually less important on floppies, but sometimes problematic on HDDs.

Does MartyPC do any INT 13h emulation, or does it just run a standard BIOS for the machine being emulated? The latter should work, as most BIOSes themselves probe the floppies, although some only use the CMOS drive settings.

You can't load a hard disk image, it is statically configured at startup

Is this because MartyPC is just running say, an XT/IDE BIOS? I don't know much about how that works technically. ELKS also will read the first sector of a DOS floppy or hard drive partition in order to get the CHS data it needs, if the media is DOS FAT format. FAT includes that information in the BPB of the first sector.

Does MartyPC do any INT 13h emulation, or does it just run a standard BIOS for the machine being emulated? The latter should work, as most BIOSes themselves probe the floppies, although some only use the CMOS drive settings.

Marty is a low level emulator so it's all done by whatever BIOS image you have loaded. The IBM PC and XT BIOS despite being listed as not having compatibility with 1.44MB drives doesn't seem to have a problem reading them. Other machines, not so much. It won't work on a Tandy 1000.

You can't load a hard disk image, it is statically configured at startup

Is this because MartyPC is just running say, an XT/IDE BIOS?

It's more of a UI thing, really. I never implemented browsing for a VHD, they are usually stored in /media/hdd, and you can select one when the machine is off through a quick access menu. If there is a rationale to switch between hard disks on the web, we could upload multiple disk images that can be swapped out by turning off the machine and selecting a new one.

But uploading large hard disk images may get impractical as a WASM thread only has so much memory and of course a hard disk image has to be held in memory on the web as there's no disk to write to.

uploading large hard disk images may get impractical as a WASM thread only has so much memory and of course a hard disk image has to be held in memory

I see, that makes sense. @toncho11, for the ELKS image on copy86.sh, that's a floppy image too, not HDD, right?

ELKS has had a lot of additions lately, so I'd vote for a 2880k floppy image, rather than 1440k, as that will also allow more graphics programs to be run, including the updated Nano-X based on Microwindows, as well as all the TTY/Text UI programs like ttypong and ttyclock, etc.

Sorry, left corner.
https://copy.sh/v86/ is able to handle all sorts of HDD images. I never had a problem with that. Also https://copy.sh/v86/ is a fast x86 emulator. It is not bound to a specific x86 generation. It is as fast as your host machine could run it.

It's really no problem to just use a small VHD, 10 or 20 MB. There's no reason to restrict yourself to a floppy. Any unused space will be gzipped away.

When I was talking about memory issues, I was referring to UI considerations if someone tries to upload their old 2GB Maxtor or something. A WASM thread can get around 1GB of memory reliably and so a disk image must be under that

Also https://copy.sh/v86/ is a fast x86 emulator. It is not bound to a specific x86 generation. It is as fast as your host machine could run it.

I'm not suggesting you throw out the v86 version. It's good to have a fast version. But MartyPC can show you exactly how ELKS "Linux for 8086" runs on, well, a 8086. Someone considering putting it on their real 8086 system can test-drive it more effectively.

(Current mouse inaccuracies aside)