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

70 posts / 0 new
Last post
Offline
Last seen: 10 hours 47 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
Very nice.  I will pull it

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

 

Offline
Last seen: 10 hours 47 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
Color looks good in this

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

 

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Yeah I found was was going on

Yeah I found was was going on, it was mostly DHIRES that was throwming me off. Turns out my lovely super optimization (Basically I reconstruct 14 pixels in one go in one 64 bits integer, and process that) 'forgot' to reverse the color bit nibles... it was very subtle as not ALL the colors were wrong, but it was messing up the table I used... and throwing off the colors for HIRES, so when I fixed one, I broke the other :-)

I also fixed the colors in LORES and DLORES mode in this version. It handle the 'monochrome' too, but rather 'meh' -- I have some more code to convert colors to luminance, I'll fix that soon.

 

The current git version has a crash if a WOZ you load has non standard track aligned -- the code to handle it is there, but is #if 0! in mii_floppy.c; doh. I'll push a fix for that a bit later. Must have disabled at accidentally while fixing something else :-)

Also current git doesn't 'clear' the CRC field if there is one and you write to the file. Next version clears it properly to mark it unused.

 

Currently every single WOZ I tried worked, however I KNOW the 'custom non standard bit timing' need some work.. Still not bad for a first shot at it.

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Another new version

This time I made a 'bitstream' view for the floppy that are loaded. It shows the head read & write with live updates. Completely gratuitous, but hey ;-)

Also added support for write protected floppies, and a new about box!

BTW Curerntly the only WOZ that doesn't boot is Print Shop Companion. Not sure why as I do support the specified 'random bits' etc...

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
New version 1.8 released.

New version 1.8 released. Lots of cool stuff, most notably spinning floppies! You see the real bitstream view of the disk, the head moving, and a heat map of what's been read/written to the tracks. Pure bling!Also loads of improvements for the video, oh and also new driver for Super Serial Card and a Ramworks III memory extension.

 

(GIF doesnt' do it justice, the real view is butter smooth)

 

Offline
Last seen: 10 hours 47 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
I will pull again and give it

I will pull again and give it a try.

 

mmphosis's picture
Offline
Last seen: 3 months 1 day ago
Joined: Aug 18 2005 - 16:26
Posts: 437
The Print Shop Companion disk

I appreciate you updating the program.

Have you tried The Print Shop Companion disk again?

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.

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
I have a .woz of the print

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!

mmphosis's picture
Offline
Last seen: 3 months 1 day ago
Joined: Aug 18 2005 - 16:26
Posts: 437
mmphosis wrote:Or, maybe I
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.

mmphosis's picture
Offline
Last seen: 3 months 1 day ago
Joined: Aug 18 2005 - 16:26
Posts: 437
The Print Shop Companion
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's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Actually, MII's driver is

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 head, eventually :-)

 

Offline
Last seen: 10 hours 47 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
BusError wrote:Actually, MII
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?

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Theres 54000 bits in that

Theres 54000 bits in that noise track, software would have to have a pattern recognition with a window at least as large as this to find it doesn't change :-)

Offline
Last seen: 10 hours 47 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
But does it pick the same

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.

Offline
Last seen: 1 day 15 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 982
Some details on the innerworkings of 'weak bit' copy protections

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

mmphosis's picture
Offline
Last seen: 3 months 1 day ago
Joined: Aug 18 2005 - 16:26
Posts: 437
the WOZ image
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.

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Thanks for the input guys, I

Thanks for the input guys, I'll have another crack at it and report! I suspect it might be a case of the wrong 'pattern' of random that I have been returning. 

 

In the last version I added my own internal 'signal analyzer' to the floppy disk driver; basically I can dump (sometimes huge!) equivalents to having a digital probe attached to it, so I've got the tools, I just need the time :-)

 

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
 Released v1.9 of MII on

 

Released v1.9 of MII on github. Tons of new stuff under the hood. Fixed a couple of bugs a in the floppy driver (quarter step motor).

Added some new color options. Another NTSC and the Mega2 colors.

Entirelly redid the video, has some new 'artifacts' in HGR, the 'bit patterns' are displayed in lowres mode, well TONS of stuff...

ALMOST have the vapor lock working too.. (still need some more debugging)

Video driver only update the video when lines changes, saves tons of CPU

Also massively accelerated the emulation in general. MII used to use 25% of a core here, now around 9% :-)

 

There are also a few bits I didn't 'plug' yet -- theres an emulated mockingboard that works (bar the audio output, small detail ;-))

 

https://github.com/buserror/mii_emu

 

BusError's picture
Offline
Last seen: 4 months 2 weeks ago
Joined: Jul 9 2023 - 06:39
Posts: 63
Exemple of the new LORES

Exemple of the new LORES monochrome rendering with a mix of bit pattern and blending. I stared quite a bit at my CRT to get that :-)

 

Pages

Log in or register to post comments