MAMEWorld Forums - News - Re: Star Rider emulation progress

> > Its a phase locked loop to line up the flux timing. if you're "flux-ifying" a
> > 'cooked' apple .d0 or .p0 file (converting it from a bunch of in-order sectors back
> > to original address marks and data marks with proper timing) you mostly don't have
> to
> > worry about the pll other than getting the bitcell size right.
> >
> > LN
>
> Wow. Most of the time I 'sort of' get what everybody's talking about, but you sir,
> just blew my mind.. maybe even made it sort of explode... I dunno... yet.
>
> X

Definitions:
.do file = "cooked" (containing nothing but raw sector data) Apple2 disk dump with the sectors in Apple2 DOS3.3 order (0, 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, 9, 1, 8, 15) and no metadata

.po file = "cooked" Apple2 disk dump with the sectors in ProDOS order (0, 8, 1, 9, 2, 10, 3, 11, 4, 12, 5, 13, 6, 14, 7, 15) and no metadata

flux = the positive or negative magnetic charge (i.e. its up or down direction and its relative strength) on any specific part of a diskette; data is stored by the distance between 'flux reversals' where the flux crosses the 0 line and becomes positive or negative from being negative or positive respectively.

GCR = Group Code Recording, a scheme for encoding data onto a diskette using a specific arrangement of flux reversals; a variant of GCR is used to encode data on apple2 diskettes

address mark = a string of (on apple2: GCR) encoded by flux reversals which comes at the beginning of a sector which consists of a fixed header/preamble, the sector's number, the track number, and a checksum code to ensure that the sector and track numbers were read correctly; note that .do and .po files do not store this data, it is implied by the position of the data within those files!

data mark = a string of (on apple2: GCR) encoded by flux reversals which comes after the address mark and consists of a fixed header/preamble and the sector's data, plus a checksum code to ensure that the sector data was read correctly. note that .do and .po do not store the checksums, they are assumed to be correct.

"flux-ifying" = an invented term for the process of taking a .do file or .po file and converting it back to the analog or digital-timing-delta flux waveform which would have represented it on a disk. This is an inherently lossy process due to lack of track and sector metadata from the .do and .po file formats

PLL = Phase locked loop, one of several ways of adjusting the timing window for where you expect a flux transition to happen in a flux stream/waveform, and when you do see one, adjust your expectation slightly for the next one. if you don't see one, do nothing. If you see a flux transition where you didn't expect to see one at all, ignore it, but (optionally) adjust the PLL expectation as well. A good PLL is an important part of reading data from a diskette in most systems due to drive speed variations, dirt, and other noise, by rejecting noise and spurious transitions from where they should not be occurring. A bad PLL can make reading data from a disk much much harder than it should be.
The apple2 does NOT USE A PLL in the real system.

bit-cell or bitcell: the expected length of the shortest possible flux transition interval for a given disk or format. i.e. if a disk shows flux states of NNNNNNPPPPPPNNNNNNPPPPPPPPPPPPPPPPPPNNNNNN (where N is negative and P is positive oriented magnetic fields) and the actual data is 0 for no flux change and 1 for yes flux change (i.e. NRZ 'non return to zero' encoding), the data extracted from this will be 1 1 1 0 0 1 with a bit-cell size of 6
Additional diagram:


NNNNNNPPPPPPNNNNNNPPPPPPPPPPPPPPPPPPNNNNNN  = magnetic flux direction
-.....1.....1.....1.....0.....0.....1.....- = extracted bits
~~___~~~___~~~___~~~___~~~___~~~___~~~___~~ = PLL window (~ = bit expected, _ = reject)

"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"