MII: New IIe open source emulator, mine this time!

Very nice.  I will pull it and give it a try.

Color looks good in this version!  I have had a few weird crashes when selecting disks and some other things like that.

I will pull again and give it a try.

I appreciate you updating the program.

Have you tried The Print Shop Companion disk again?

printshop-companion-disk.png

I booted it on an Apple II plus this morning. It requires 64K of RAM. The disk would boot, reboot, reboot again, eventually it booted up to the main menu. I can CATALOG the disk and it shows the name "Roland Gustafsson" in the CATALOG which makes me suspect there may be some disk shenanigans going on! Or, maybe I need to adjust the disk speed slightly on this old disk drive.

printshop-companion.png

mmphosis wrote:

Or, maybe I need to adjust the disk speed slightly on this old disk drive.

I adjusted the disk speed on DRIVE 1 and The Print Shop Companion boots first time now.

BusError wrote:

I have a .woz of the print-shop companion, and that's the only one that fails to load! Strangely, I do all the 'right things' in terms of what is documented in the WOZ format (ie returning random bits etc) but no avail there...

 

Of the whole copy protected WOZ from the catalogue I tried, this is the only one that fails!

I found 4am's "write-up" on The Print Shop Companion:

https://ia800602.us.archive.org/17/items/ThePrintShopCompanionv12_4amCrack/The%20Print%20Shop%20Companion%20v1.2%20%284am%20crack%29.txt

The interesting part is track $22 on the original disk has a long "abyss" of zero bits which will return random bits! I would question that WOZ format file, and also wonder how an emulator emulates a real drive that generates "random bits?"

4am wrote:

Unless...

Oh no.

Oh God.

Oh God no.

There's only one thing you can put on a

disk that will change every time you

read it: nothing. And by "nothing," I

mean "a long sequence of zero bits."

And that's what is on the original disk

between each of these groups: nothing.

A bit of background. When we say a

"zero bit," we really mean "the lack of

a magnetic state change." The Disk II

drive isn't digital; it's analog. If it

doesn't see a state change in a certain

period of time, it calls that a "0". If

it does see a change, it calls that a

"1". But the drive can only tolerate a

lack of state changes for so long --

about as long as it takes for two bits

to go by.

Fun fact(*): this is why you need to

use nibbles as an intermediate on-disk

format in the first place. No valid

nibble contains more than two zero bits

consecutively, when written from most-

significant to least-significant bit.

(*) not guaranteed, actual fun may vary

So what happens when a drive doesn't

see a state change after the equivalent

of two consecutive zero bits? The drive

thinks the disk is weak, and it starts

increasing the amplification to try to

compensate, looking for a valid signal.

But there is no signal. There is no

data. There is just a yawning abyss of

nothingness. Eventually, the drive gets

desperate and amplifies so much that it

starts returning random bits based on

ambient noise from the disk motor and

the magnetism of the Earth.

Seriously.

BusError wrote:

Actually, MII's driver is made for that. I use a shifting window, and if I receive 4 zeroes from the WOZ when reading, I use a 'track 36' (ie not a real track) made entirelly of 30% random 1's, ie, noise track. Clearly, in my case, it doesn't work as it should, but I verified the behaviour and it is supposed to work as 'spec' so there must be a bug somewhere in there. I'll knock it over the hea

Does that generate the same "random" bits every time?  Maybe you need to generate some random bits on the fly instead of reading them from somewhere?

But does it pick the same part of your noise track every time for the same location of zero bits?  Sometimes when something isn't working trying a totally different approach works.

In post #62, 'BusError' wrote:

" I use a shifting window, and if I receive 4 zeroes from the WOZ when reading, I use a 'track 36' (ie not a real track) made entirelly of 30% random 1's, ie, noise track. Clearly, in my case, it doesn't work as it should ..."

Uncle Bernie comments:

30% density of what ? Q3 clocks ? Or bit cells ?

I think that 30% of bit cells is too much, but I can't vouch for that. Also, the read process on a real floppy disk is not random at all. What happens with 'weak bit' copy protections is that the read amplifier slowly increases its gain if it does not 'see' a flux change (aka "1" bit) for a short while. It will increase the gain until it 'sees' a flux change again. This is not random as long as the head still engages the magnetic medium.  If the head was lifted, it would 'see' the intrinsic noise of the read amplifier, which is white noise (what you may have in your noise track) with a 1/f component added. But this is not what happens. The head stays engaged and the read amplifier will 'see' the intrinsic noise of the magnetic medium, and some of the 'grains' still are magnetized enough to cause a read pulse.

This is what you could try: for each '0000' zone, after the four '0000' bit cells have passed, define a number of bit cells where a 'random' read pulse comes, but make sure that the run length of added '0' is limited ... there must be a read pulse within a certain distance from the initial '0000'. Then, on the next read of the same place on the 'random track', move the location of the read pulse one bit cell forward or backward.

So if the copy protection check looks for a 'flux hole' it may get:

'0000' '010'

the first time it is read, but either

'0000' '100'

or

'0000' '001'

the second time it is read. And so forth.

So if the protection is looking for a 'flux hole' more than once (it has to do that in any case, otherwise the 'flux hole' could not be detected) it will get a slightly different bit pattern each time, but not totally random patterns which make no sense.

The above discussion is based on my understanding of some 'unstable sector' copy protections of the 1980s and 1990s which were non-Apple but the principle as such was the same, and what they did (seen by reverse engineering the copy protection check code) was to actually check that a) the sector had a CRC error and b) the 'unstable byte' had certain distinct values. This protection was defeated by providing several stable sectors having CRC error but were actual examples of the data read from the unstable sector on the original disk, none of them having the same data of course.

After this manipulation involving no 'cracking' of any code, as no code was changed, the copyprotected game still needed a certain 'floppy speeder' to be copied, as it was still copy protected in some sense, but this 'floppy speeder' could put more sectors down on a track (by reducing spindle speed) and could make CRC errors, so it copied the manipulated floppy disks just fine.

But again worth to be mentioned, it still needed said 'floppy speeder' to copy that disk. So people were still inclined to buy them, making a certain guy rich ;-)

This is why I never 'cracked' a piece of software that had a stubborn copy protection. A 'crack' can be copied by any school kid with just a sector copier. This is not good for the sellers of 'floppy speeders' or the likewise infamous 'happy enhancements'. So 'crackers' are the enemy of 'speeder / enhancement' producers. Which, BTW, were perfectly legal products to make and sell back in the 1980s.  The 'law' back then only prohibited the actual process of making a copy from a copyprotected disk, and only if the copy was to be given to third parties. If the copy was made to be kept as a backup, it was perfectly legal.

Compare that to the sh*itty and unacceptable situation today with the DMCA and all the digital, encrypted 'protections' on DVDs and BluRay disks. I lived in many countries and so I have a vast collection of original DVDs and BluRays from all around the world, all with different region codes. I do have DVD/BD players from each country where I ever lived, but finding a flatscreen TV which would display all the different HDMI based sources was difficult. I had to settle for a very cheap, cr@ppy, Chinese made one because all the nice, high quality, brand name ones I could find refused to show the region coded movies I bought in foreign countries (back to the vendor these nicer TVs went - I consider that a defect). Despite they all are original DVD/BD I paid my money for. The whole industry involved in that region code scam is guilty of defrauding us, the buyers of their region coded media. There should be a class action lawsuit clawing back some Trillion of US$ from them, and giving the money back to us.

- Uncle Bernie

BusError wrote:

Actually, MII's driver is made for that. I use a shifting window, and if I receive 4 zeroes from the WOZ when reading, I use a 'track 36' (ie not a real track) made entirelly of 30% random 1's, ie, noise track. Clearly, in my case, it doesn't work as it should, but I verified the behaviour and it is supposed to work as 'spec' so there must be a bug somewhere in there. I'll knock it over the hea

I was wondering if the WOZ image is correct? In other words, MII is doing the correct thing, but the WOZ disk isn't a good copy of the original.

The minimum number of unique 4-and-4 encoded values required to pass the protection is #$A0 (160)

As I have an oringal working copy of this disk, what would one do to make a WOZ image?

Also, a bit off-topic, but you mention track 36. I don't recommend doing this, but back then I was naive and wanted more disk space. I use to format disks with 36 tracks and they worked (until they didn't.) I would use LOCKSMITH or a custom call to RWTS to format track 36 and then update the VTOC to make the extra 16 sectors available.