Timeline for How was Prince of Persia "better/faster" with RWTS18?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 5, 2018 at 18:45 | comment | added | supercat | @Tommy: Okay, I just looked up MFM and I had been slightly mis-remembering things. It requires that the time between flux reversals be in the range from 2 to 4 cycles (as distinct from 1-2 for FM), which I'd seen described as having 1 to 3 zeroes between bits (and confused with having 1-3 cycles between flux reversals). I think my confusion stemmed from the fact that the Disk II hardware allows a maximum of three cycles between flux reversals. | |
| Jul 5, 2018 at 17:25 | comment | added | Tommy | @supercat I think we might just be talking at crossed purposes: the rule for MFM is insert a clock bit only if the two adjacent data bits are both 0; signify special marks (index, id, data) by dropping a clock that should be there. So it's any cycle but definitely not every. So it uses the same analogue density media as FM and never outputs two consecutive transitions. Which I argue is therefore the same as FM in density terms of windows filled or empty, but with sub-window positioning. That's not how you implement it, but I think it's correct. | |
| Jul 5, 2018 at 15:42 | comment | added | supercat | @Tommy: MFM as used on PC floppy disks requires the ability to have a phase transition on every cycle. Some RLL formats push densities by about 50% by doubling the clock speed but forbidding phase transitions on consecutive cycles. I think the difference between FM and MFM is that the latter limits the number of consecutive phase transitions within a data stream in exchange for allowing two consecutive cycles without a phase transition, thus making it possible to use the presence of a higher number of consecutive phase transitions as a sync marker. | |
| May 7, 2018 at 18:17 | comment | added | Tommy | I'm super late but whatever: 4+4 is like FM, not MFM. It's a fixed pattern of clock bit, data bit, clock bit, data bit, all exactly window aligned, and hence has exactly the same data density as FM. MFM has double the clock rate but guarantees about gaps between bits, so another way to think of it is using the same window size as FM and therefore needing the same quality of data, but inferring additional information from the position of flux transition within their window. MFM has twice the data density of FM, and is about 26% more efficient than 6+2. | |
| Jun 20, 2017 at 23:00 | history | edited | Nick Westgate | CC BY-SA 3.0 |
Removed claim that 4+4 is fastest.
|
| Feb 11, 2017 at 17:03 | comment | added | supercat | ...repeatedly output ERR or shut off the motor in case of failure (I couldn't free up enough space to shut off the motor and output anything, however). Using a 4+4 scheme should have freed up a lot of space, though, and a 256-byte boot sector which started with the motor on and X loaded with the controller offset could have loaded everything else. Using a 4+4 sector might have meant the loss of one sector of storage, but that would seem a small loss. | |
| Feb 11, 2017 at 16:58 | comment | added | supercat | @NickWestgate: I find it somewhat curious that Apple didn't use a 4+4 boot sector format, even on higher-density disks, since that would have allowed the boot PROM to time out in case of failure and also maintained boot compatibility with older disks, and would have only minimally affected disk capacity. Way back when, I looked at adding a timeout and found out that the amount of ROM needed to set up X with the controller's offset from $C080 was about the same as the amount of ROM needed to add a timeout, so a version that was hard-coded for slot 6 could... | |
| Feb 11, 2017 at 16:44 | comment | added | supercat | @NickWestgate: Of the 128 possible octet values that start with a leading "1", 47 contain three or more consecutive 0's and would require fancier read circuitry. 1: Another 48 contain two or more zeroes but not 3, and would have required fancier read circuitry except that Woz figured out a way of doubling up decoding states when the MSB is set. | |
| Feb 11, 2017 at 8:32 | comment | added | dirkt | And with the reduced gaps there would also be problems writing sectors randomly, instead of writing the whole track at once as it's probably done to create the disks. | |
| Feb 11, 2017 at 7:35 | comment | added | Nick Westgate | The way the nibble encoding name is usually used is for the whole process, Any difference such that DOS 3.3 couldn't read it would be a different scheme, though your scheme would be similar if it used the same nibble values. The change from 5+3 (32 nibble values used for data) to 6+2 (64 values) required a new sequencer PROM on the disk controller card. | |
| Feb 10, 2017 at 22:40 | comment | added | supercat | Would 6+2 say anything about how the second byte of data should be encoded [e.g. I think a fast approach using one 128-byte table would build groups of three bytes from groups of four raw chunks (8 bits each before decoding or six after) by having twelve bits mapped directly but having the other twelve stored as the xor of 2-3 bits from the original data; would that still be called 6+2, or something else?] | |
| Feb 10, 2017 at 20:23 | comment | added | Nick Westgate | Yes, but from a different perspective. The encoding name refers to the way source data is split into disk nibbles. 6+2 means 6 bits get translated into one nibble, two into another (with 4 other bits to make up to six total). Each encoding scheme uses a different number of possible nibble values, not always 81. | |
| Feb 10, 2017 at 19:58 | comment | added | supercat | I'm familiar with the principles of GCR, but I'm not sure about the numbering. Since each 8-bit chunk of storage on the disk needs to hold one of 81 distinct values, is the chart simply saying that each 8-bit chunk is used to hold 4, 5, or 6 bits of useful data? Does the number after the + mean anything? | |
| Feb 10, 2017 at 16:51 | comment | added | supercat | What do 4+4, 5+3, etc. mean? I would guess the fastest format uses two bytes of raw disk data per byte of useful data storage, but what do the other numbers mean? | |
| Feb 10, 2017 at 16:20 | vote | accept | cbmeeks | ||
| Feb 10, 2017 at 10:05 | history | answered | Nick Westgate | CC BY-SA 3.0 |