[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DSK to NIB Instruction

Linards Ticmanis wrote:
Actually judging by the source code, most emulators seem to "nibblize" the .dsk image internally and then feed it to the emulated controller.
Interesting. The Emulator takes the sector data and converts it into a byte stream to feed the controller? I guess it feeds standard sector headers and the like then, eh? Probably doesn't feed any sync bytes then...
I don't have any literature available on low-level disk operation. Do I get this right:
1.) the .nib format stores bytes in the same format that the Apple's CPU sees when accessing the drive controller card (disregarding the .nib overlap).
Yes. SST uses the EDD program's read a track routine to get all the bytes off the disk. Then it runs the Analyze a track function to determine the start of the track. Then it writes out 1A00 bytes of the track to a standard disk. 


2.) this is not the format that is actually stored on the disk.
No, the disk would contain fewer bytes as the arbitrary length of the track was written to the regular disk.
3.) the purpose of sync bytes is: to tell where in the bitstream a byte starts, so you don't get half of one byte and half of the next. So when reading a disk on the Apple, you throw away what you read while waiting for a sync byte, which will be aligned correctly, then the bytes after that will also be aligned correctly, so you can use them.
Not exactly. The sync bytes are aligned via the disk read circuit. The Computer waits for a valid sequence of bytes representing the sector header.
4.) sync bytes are stored with some extra bits in front of the normal bit pattern.
Beneath Apple DOS has a fantastic explaination of the hardware and sync bytes and how and why they work with A2 diskette drives.
These extra bits are not directly visible to the Apple's CPU, only to the controller card itself.
Correct, they are discarded by the read circuit of the A2 floppy disk drive. They are only detectable by the CPU with very sharp timing of the read byte from disk routine. Bad example follows to illustrate: 

Init tick counter,
Clear read latch,
Check for valid byte
Is it a byte yet?
	No, tick, got to check for valid byte
Store byte
Ticks > 8?
	No, Normal byte
	Yes, Sync byte, Flag byte
Store byte, Repeat from top
5.) when reading from a disk, there's a way to ask the controller whether you've got a sync byte or not. 

None.
6.) when writing to a disk, there's a way to tell the controller to write either a sync byte or a normal byte.
The controller can only read bytes that start with a 1, but you can write any 8 bits...
7.) You can't tell from the byte value alone whether you've got a sync byte or a normal byte. You have to ask the controller in a specific way.
You have to have a times read loop to determine if the byte read in had to discard 0 bits.
I was actually thinking of coding something on the PC side that turns the .nib image into two SST-format .dsk images (if only I knew what the SST format actually is). These could then be transferred to a real machine with ADT and reconstructed there with SST. 

Well then decode the data in a NIB.
Look at the sector data in the disks generated by SST of (ProgramX) after you transfer the image files to your PC. 
Then build the NIB file using SST and look at the bytes in that file.

Find the similarities and away you go to reverse the process.
I'm only talking of *known to work on an emulator* .nib images. These obviously don't need exact track-to-track timing or nonstandard sync stuff. Couldn't you just pick some number of bytes evenly distributed throughout the track and make them into sync bytes, since obviously the software doesn't care either way, or else it wouldn't work on an emulator. Or am I missing something here?
You are correct. Any Nib image that works in an emulator is no would not be nibble counting or track synchronizing a s that would preclude it from working. 

Thanxk,
Ed