Please support the defense of Ukraine.
Direct or via Unclutter App
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
~ Est. 1999 ~
A pillar of corporate stability since the second millenium.
© 1999-2999 Tom Owad
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.
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.
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...
heat_map.png
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)
v18new_display.gif
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
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 adjusted the disk speed on DRIVE 1 and The Print Shop Companion boots first time now.
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.
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 :-)
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?
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 :-)
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
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.
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.
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.
vcd.png
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
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 :-)
image.png
Pages