PC Floppy Copy Protection: Xemag Xelok

#1

Post by GloriousCow » Sun, Oct 06, 2024, 5:32 PM UTC

PC Floppy Copy Protection: Xemag Xelok
martypc.blogspot.com

Re: PC Floppy Copy Protection: Xemag Xelok

#2

Post by GloriousCow » Sun, Oct 06, 2024, 5:32 PM UTC

In this post in a series on PC copy floppy protections, we take a look at XEMAG duplication's "Xelok" scheme.

Xelok was quite devious on the Apple II, implementing "fat tracks" that could not be produced with a conventional disk drive. However the PC doesn't allow such tricks, so Xelok appears a bit different on the PC platform.

We take a look at two titles that use it, Sargon III and The Ancient Art of War.

We also take note of a rather amusing bypass for this protection!

Re: PC Floppy Copy Protection: Xemag Xelok

#3

Post by ksaj » Sun, Oct 06, 2024, 5:43 PM UTC

I find it humourous that their logo looks like what happens when older generations of Windows failed on popups.

Re: PC Floppy Copy Protection: Xemag Xelok

#4

Post by GloriousCow » Sun, Oct 06, 2024, 5:46 PM UTC

ksaj wrote: post #3

I find it humourous that their logo looks like what happens when older generations of Windows failed on popups.

Or when you win solitaire!

Re: PC Floppy Copy Protection: Xemag Xelok

#5

Post by somat » Sun, Oct 06, 2024, 9:43 PM UTC

Probably a silly question. but are those images of a disks layout high enough resolution to recreate the disk?

I know it's silly because if you wanted to encode a disk image such that it works as a png you would not use a circular layout. Too many weird angles, it would make it harder than it needs to be to reconstruct.

Re: PC Floppy Copy Protection: Xemag Xelok

#6

Post by GloriousCow » Sun, Oct 06, 2024, 10:45 PM UTC

somat wrote: post #5

Probably a silly question. but are those images of a disks layout high enough resolution to recreate the disk? I know it's silly because if you wanted to encode a disk image such that it works as a png you would not use a circular layout. Too many weird angles, it would make it harder than it needs to be to reconstruct.

For the ones that I make to look pretty, the data is colored in buckets of 8 bits, using the bit-count per byte to select a shade in 8 steps from 0-255. So there's at least 8 times less data than you would need. Then it is downsampled 4x to get nice antialiasing, so that is more data loss.

I do have a bit-mode, and if you rendered at high enough resolution you could do it, maybe something like 32k x 32k. But this is a very inefficient way to store a disk image. :)