• Please review our updated Terms and Rules here

MartyPC, IBM PC 5150 / XT 5160 emulator

So far, support has been added for reading HFE, MFM, PRI, PSI, IMD, with TC0 in progress. Still lots of work to do, such as writing to bitstream-level images, but the new floppy support looks promising so far.
Hope to get this release out by the end of the month.

Here's an uncracked California Games converted to MFM from a Kyroflux dump. The game looks for a sector with ID of 222 and bad data crc.

bitstream_loading..png
 
I just built MartyPC from source (cloned the git repository) on FreeBSD. It works! Nice!
 
Good work!

I also hope that .pri image will support marty pc.

I have over 2000 kinds of IBM PC copy protected game / application dumped by SCP.



It's been over 10 years since non-standard tracks/sectors were added to the PCE emulator, but it started when I suggested to the PCE creators that they provide disk images dumped from some copy-protected disks with TC (Trans Copy).This time, MartyPC is even more promising.I personally think that the .PRI images are open and have strengths in editing and converting to other images.A simple example is a game called Onslaught, which was dumped with Teledisk, but although it works on PCE or MartyPC, it doesn't work on the actual machine. As an alternative, I dumped a game disk like Lemming, which has almost the same copy protection method, converted it to a PRI TEXT file, and then added/edited the PRI-TEXT part so that Onslaught could work on the actual machine. I added detailed information about the sectors or tracks of the disk copy, and later converted it from PRI to SCP and transferred it to the actual machine diskette. As a result, it worked successfully on the actual machine.Finally, I have hundreds of images dumped to SCP from copy-protected games or applications that are not circulating on the Internet.
Good news, I have started adding support for additional floppy disk image formats.

ImageDisk (IMD) and PSI (PCE Sector Image) have been added so far, and I plan to add TeleDisk next.
 
Last edited:
Good work!

I also hope that .pri image will support marty pc.

I have over 2000 kinds of IBM PC copy protected game / application dumped by SCP.

It's been over 10 years since non-standard tracks/sectors were added to the PCE emulator, but it started when I suggested to the PCE creators that they provide disk images dumped from some copy-protected disks with TC (Trans Copy).This time, MartyPC is even more promising.I personally think that the .PRI images are open and have strengths in editing and converting to other images.A simple example is a game called Onslaught, which was dumped with Teledisk, but although it works on PCE or MartyPC, it doesn't work on the actual machine. As an alternative, I dumped a game disk like Lemming, which has almost the same copy protection method, converted it to a PRI TEXT file, and then added/edited the PRI-TEXT part so that Onslaught could work on the actual machine. I added detailed information about the sectors or tracks of the disk copy, and later converted it from PRI to SCP and transferred it to the actual machine diskette. As a result, it worked successfully on the actual machine.Finally, I have hundreds of images dumped to SCP from copy-protected games or applications that are not circulating on the Internet.

Yes, I support PRI, and now 86F as well. I would also like to support Transcopy.

After improving my FDC emulation, Formaster Copy-Lock, and Softguard SUPERLoK v2 and v3 titles work, although v3 needs an image that does not pad the bitcell count to nearest byte.
 
Last edited:

@GloriousCow

That's great.
Also it will be more helpful to support .SCP .PRI. PSI by refering PCE's source.

There are many games that are secretly dumped on the internet, but I have many more that are not public.
So I plan to perform the operation tests that were performed only on PCE in the past on MartyPC in the future.
 
I've added support for TransCopy images.

This brings the total list of image formats supported to : IMG, IMD, TD0, PSI, 86F, HFE, PRI, MFM, and TC.

I've also added support for EA Interlock and Vault PROLOK protected titles. Success in emulating PROLOK will depend on proper weak bit encoding or a weak bit mask provided by a given file format. I have been using TransCopy images produced by the flux2tc tool by NewRisingSun with success. The most recent version of PROLOK I have is 4.04 from 1989, which is probably one of the last versions, since they were basically fading into irrelevance at that point.

dbase III screenshot 01.png
 
This floppy stuff feels like it's never-ending!
We can now run XEMAG XELOK & XELOK 2 protected titles.

I added realtime disk structure visualization for bitstream-level images.

format_viz_06.gif

Now you can take a look at all the weird stuff copy-protected titles do, without needing any external visualization tools.
Disk layout won't normally change much unless you format, but it's still cool to look at.

Here's a pretty wild image, Czorian Siege (1983):

czoran_image_01.png
Empty tracks are rendered as black rings.

I'm thinking of highlighting the most recently accessed sector, so you can watch how a program reads the disk.
 
I have very preliminary support for SCP now, which means that fluxfox can finally do flux. The PLL and flux handling code should be fairly applicable to other formats as well like PFI, MFI and perhaps even Kryoflux, although handling the file set issue for Kryoflux is a bit annoying to contemplate.

My goal is to handle most clean dumps. If you have an image in rough shape you will probably need to fix/resolve and export it in a proper disk tool.

martypc_flux_02.png

I plan to disable write-back to SCP images that do not have the writeable flag set - MartyPC converts flux to bitstream internally, so if you save back to to a dumped SCP you will essentially erase all your revolutions with a perfect, synthesized flux stream, which is probably not what most people want to do with their archive collection. I doubt I will ever write to a kryoflux raw image. I consider those the granite slabs of the emulation world.

The main drawback to supporting every disk format under the sun, is that users suddenly need to educate themselves on the differences between disk image formats, what is appropriate for what purpose, and when you do or don't want to have an emulator write a specific format, which copy protection methods work with which formats, etc and so on. I figure if you've even heard of MartyPC though, there's a good chance you have a decent understanding of that stuff.
 
Excellent! Congrats on tackling this whole kettle of fish - flux-level images have never been 100% satisfactorily dealt with in PC emulation up until now, as far as I'm aware.

MAME (iirc) has this setup where you can tell it to treat an image as read-only, but have it clone the original when it's mounted, and redirect all writes to the cloned copy. Could something like that be satisfactory when the source is a flux image?

P.S.: what's the current status of VGA emulation? I've been putting some more work into my old font editor, which depends on tweaking VGA text mode here and there, so that should be fun to test in MartyPC...
 
Excellent! Congrats on tackling this whole kettle of fish - flux-level images have never been 100% satisfactorily dealt with in PC emulation up until now, as far as I'm aware.

MAME (iirc) has this setup where you can tell it to treat an image as read-only, but have it clone the original when it's mounted, and redirect all writes to the cloned copy. Could something like that be satisfactory when the source is a flux image?

MartyPC doesn't write anything back to your disk image until you click a save button. So you could load a Kryoflux image and write to it all day but it's just going to exist in memory until you save it to something. I debated the best way to handle this - the pros are that you can use your archival images without any concern that MartyPC is going to write all over them or screw them up. The cons is that you could lose work if the emulator panics or you exit while forgetting to save (i could have a reminder-popup if there are unsaved changes)

The write-clone is a good idea. I saw how WinUAE loads an SCP, but saves an ADF containing any writes you make to it alongside. PSI might be a good format for this on PC, you could add a chunk type that references the 'master' file to which it belongs, or put that in a TEXT chunk. The main problem would be you'd be unable to do any track-level shenanigans, as PSI is sector based. If we use PRI we could just store each track that is changed.

P.S.: what's the current status of VGA emulation? I've been putting some more work into my old font editor, which depends on tweaking VGA text mode here and there, so that should be fun to test in MartyPC...

I admit I sort of abandoned my VGA work once I got Wolf 3d running. VGA text mode is all sorts of busted, as I never implemented 9 column mode. I was sort of planning on fixing that for 0.3.1 - with the goal of just getting 0.3 out with the new disk stuff.

The release schedule for MartyPC has been very erratic as I tend to tackle several things at once and get bogged down slogging through it, but we do make huge strides with each release. This floppy work is 2nd only to the 8088 emulation in terms of the amount of work and research that has been required.
 
Initial Kryoflux support is in

marty_kryoflux_01.png

MartyPC will support some conveniences for Kryoflux sets - you can leave them zipped up, for one. I don't currently handle zips with multiple disks, but I think it should be possible.

There's still a lot of work to do in terms of solving flux, detecting weak bits, etc. But it's darn cool to have gotten this far. We're a long way from only supporting IMG!
 
Added MFI too. why not.

I'm going to get my wasm build back up to speed in the coming week. It's mostly a toy to run MartyPC in the browser, but if I can get "uploads" to work, you could actually convert and someday edit disk images in your browser, that would be cool.
 
Back
Top