• Please review our updated Terms and Rules here
  • From now on we will require that a prefix is set for any items in the sales area. We have created regions and locations for this. We also require that you select a delivery option before posting your listing. This will hopefully help us streamline the things that get listed for sales here and help local people better advertise their items, especially for local only sales. New sales rules are also coming, so stay tuned.

Looking for an 8" floppy drive

No. You'll limit yourself to a specific data encoding format... once you're in the firmware, there is no need to limit yourself like circuitry. The answer is in the first quote above.
Click to expand...

I download my software into the MCU for a specific applicaiton, so it doesn't matter. There are wide range of encoding schemes, each with its own timings. For example, the simple fixed-frequency PLL setup falls to pieces if you're trying to read a Victor 9000 floppy using an ordinary drive (zoned recording). You could certainly do the same using an FPGA.

There's no one-size fits all in the floppy field. Not by a long shot. It's even a mistake to assume that a sector is always a power of 2 bytes long.
 
What possible today is beyond old floppy assumptions.

What possible today is beyond old floppy assumptions.

It's even a mistake to assume that a sector is always a power of 2 bytes long.
Click to expand...
Exactly. Which is why a microcontroller today can do it better than any 'canned' circuit.

We have very fast micros with lots of on-board rom space for firmware. This results in low chip count and better designs than anything we have.

There's no one-size fits all in the floppy field.
Click to expand...
There doesn't need to be. It can decode the data without knowing the sector data length in advance... its not an automata. You can't really do that with a FPGA.

But that's the near future... a little off topic from selecting an 8" drive. :)
 
Last edited:
Aren't you essentially talking about a Catweasel? I have a couple and use them extensively. I also did a MCU-based version using an ATMega128 a few years ago--I did post it here then. Other USB-based solutions exist--the Kyroflux and Deviceside are two that come to mine.

The hard part isn't the hardware--anyone can write a transition sampler. Most MCUs have a "capture" feature on the timer that makes it as easy as rolling off a log. The tough part is interpreting what you get. It isn't just FM, MFM, MMFM. There are group codes to deal with and then the filesystem setup. When all you have a single disk containing the data to retrieve, it's pretty hard.

I've got a Compugraphic typesetter 8" disk with Hebrew text on it. Care to have a crack at it? There's no English anywhere.
 
Last edited:
Hebrew Floppies?

Hebrew Floppies?

I've got a Compugraphic typesetter 8" disk with Hebrew text on it. Care to have a crack at it? There's no English anywhere.
Click to expand...
I'll have to guess what the meaning of your comment so it may take a few guesses:

* Maybe you're meaning to say that you have to read hebrew to determine the sector skew of CP/M disk format? (Did you mention CP/M skew?) If that's what you're trying to say, the blame goes to Gary Kidall for using a skew table instead of a disk interleave. When the FDCs got better, that should have eradicated like the Y2K bug.

If you want to know the skew table of a system, just hang a fake drive on the system and present a fake directory with one file that is one track and one sector big. As the host tries to read the file, the fake drive saves the order of the sectors and head change requested by that system - that reveals all. IF it reads the last sector with a side/head change you know its cylinder style. If it just steps on the same side, you know the other side (if any) is after the that side is exhausted. I'll add that to my uFDC.

An easier way is to create a text file on the system with repetitions of characters for each consecutive sector. Write it to floppy then read that raw floppy format to see a clear pattern without learning Hebrew. Just load the file with a sector count of "1"s then a sector count of "2"s etc. That will reveal the skew.

* If you really must reconstruct sector skew by Hebrew, think like Bletchley Park. Look for pattern replications transitioning sector boundaries but character-skewed in alternate cases... like "This is a || sector bound" and "This is || a sector bound" (I'm using language sentences just for illustration). Data replications are more common than you'd think staring at Hebrew or binary. A program can sift this better. When you find the same pattern across sectors on one, character-skewed across another sector or another floppy's sector, then you have the sector skew. Additional cases will further confirm the value.

By the way, the character-skewed is important as it is the link pattern shown to exist across the boundary in cases of character skewing, thus making the statistical case that the link is true and thus its sector offset is the sector skew

The hard part isn't the hardware... tough part is interpreting what you get... it's pretty hard
Click to expand...
No it isn't. But hard is usually relative.

Aren't you essentially talking about a...
Click to expand...
Nope, not a one.
 
Last edited:
If you're talking about timing domain transitions, you're talking about a Catweasel-type affiar. It does just that, recording the time between transitions as as stream of 7-bit values, with the MSB being an index indicator.

No it isn't. But hard is usually relative.
Click to expand...

Okay, I'll ship you the file. Nothing spectacular, just ordinary MFM data. No idea of the filesystem details or what the character set might be or how it's represented. I'll give you the file and you provide the Hebrew text, say, a week from today? Remember that the Compugraphic is a photoypesetter, so there's no correspondence between the character codes and any sort of real computer code. And this is a data disk--no system disks are available. In other words, no Rosetta Stone.

How about it?
 
...you're talking about... recording the ...transitions as as stream of 7-bit values... MSB being ...index
Click to expand...
That's coarse.

Okay, I'll ship you the file...you provide the Hebrew text, say, a week from today?
Click to expand...
If you had sincerely asked for help and I wasn't busy I'd have taken the challenge to extract the sector skew for you.

I don't need to know Hebrew any more than the floppy needs to know Hebrew.

As I've given you the algorithm and you have both the time and interest in solving your puzzle... now you have everything you need.

Let me know how its going.
 
Last edited:
You would need to know the character coding used on Chuck(G)'s disk in question to extract human-readable Hebrew text from it, just as you would need to know ASCII (or possibly EBCDIC) coding to extract human-readable English text from an ordinary MS-DOS floppy.
 
NF6X said:
You would need to know the character coding used on Chuck(G)'s disk in question...
Click to expand...
No, we're talking about extracting the sector skew as far as I can tell. Asking someone to translate Hebrew for him in 7 days just sounded facetious so I couldn't take it as a serious request for help.

What you're talking about is his asking someone to provide a missing application program for his disk. That has nothing to do with FDCs and FDDs we've been talking about.
 
You also assume there is enough data on the disk to confidently find these patterns. If, for example, there are only a bunch of small files, you would not have enough overlap to be sufficiently sure of any layout... even if you understood the contents.
 
SomeGuy said:
You also assume there is enough data on the disk...
Click to expand...
No, I wrote, "think like Bletchley Park" ... they thought about the problem, hypothesized a weakness, looked for it until they found it, and then got a foothold into the Enigma Cipher. (If anyone wants to quote history, yes the British had the research from the Poles that was very important.)

Note I mentioned looking across several floppies. Think of it as Bletchley Park looking through many intercepted ciphertext messages until they found the pattern which got into the code. I did not assume the algorithm has to work on the first sector you look at... If I did, quote it.

Note that there are not that many possibilities for sector skew numbers. You should just be able to generate the 7 likely values and and see what doesn't crash. It might even be easier to use each complete disk assumed skew results and use a program to analyze that for the patterns.
 
Last edited:
Sector skew is child's play. Filesystem and character representation is unknown. It might be safe to assume that a character is probably 16 bits, but that's not a known, nor is the collating order of the characters. Since this phototypesetter takes cartridges with a lot more than 256 characters, we don't even know the character bit length. Add in details such as kerning information and you've got a real puzzle.

Expecting a character to be 8 bits long is naive. This is what I get to work with frequently. It isn't easy, even after nearly 30 years of doing it.
 
Cryptanalysis turned to single alphabet N-bit substitutions:

Cryptanalysis turned to single alphabet N-bit substitutions:

...nor is the collating order of the characters...cartridges with a lot more than 256 characters... and you've got a real puzzle
Click to expand...
There are old algorithms for post WW1 cryptanalysis that will help with that. The "Index to Coincidence" (IC) applied to Hebrew character statistics will let you break it down if you have N-bit substitutions for single alphabet Hebrew characters in normal prose.

You can use I.C. to determine the likely language of some forms of ciphertext without even knowing the decryption yet. Its also useful for identifying how many alphabetic substitutions are used in a polyalphabetic encryptions... for example, if you know its English you can run the IC algorithm for assumed numbers of alphabets and when you have the right number, the IC will be as expected.

That's more complicated than what you have. You have a single alphabetic substitution cipher... in your case a n-bit typeset code to a Hebrew character. You should be able to whittle that done much easier.

What it would do for you if you can get that data for Hebrew (it would exist but availability... who knows) it would organize the N-bit representations into sets of likely character substitutions. With that you can use common digrams to trigrams to get the neighboring letters to the letters you already have and before you know it you have more characters than missing characters. At some point you might need a linguist to fill in sentence gaps with likely words/letters. All you need is the set of solutions for the number a characters used in your puzzle.

Here some books:
Elementary Cryptanalysis - A Mathematical Approach, by Abraham Sinkov (has the IC algorithm on my cover)
Cryptanalysis - A study of ciphers and their solution, by Helen Fouche Gaines

A lesser book representing some algorithms in BASIC:
Codes Ciphers and Computers - an introduction to information security, by Bruce Bosworth.

If you want the big picture on the history of Cryptanalysis the classic is:
The Codebreakers - The story of secret writing, by David Kahn (history through pre-WW2)

I'll post the ISBN numbers for each book if you request.
 
Last edited:
Tandon Floppy Drive Manuals

Tandon Floppy Drive Manuals

tingo said:
...User guide is useful to have...
Click to expand...
These are the files I have on Tandon floppy drives:

This is a brochure but the last page appears to be a short spec on the model TM-848-E
198511 Tandon Brochure.pdf . . . . http://maben.homeip.net/static/S100/tandon/brochure/198511 Tandon Brochure.pdf
Note that the brochure refers to SS and DS as TM-848E-1 and TM-848E-2 so when buying a TM-848E... be sure what you get.
The stand-out features appear to be:
--- LSI circuitry, microprocessor-controlled.
--- Buffered seek.

The prefix of the following filenames are just my method of organizing... the suffix is the original name.
These are for TM-848-1 and TM-848-2 models:
Floppy Drive - 5.25in - Tandon - TM100 (Printed).txt
Floppy Drive - 8in -Tandon - TM848 floppy disk drive.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy disk drive.jpg
Floppy Drive - 8in -Tandon - TM848 floppy side.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy side.jpg
Floppy Drive - 8in -Tandon - TM848 floppy top.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy top.jpg
Floppy Drive - 8in -Tandon - TM848 service manual 1982.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 userMan 1983.pdf
Floppy Drive - 8in -Tandon - TM848 Specification and Schematic.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 Specification and Schematic.pdf
Floppy Drive - 8in -Tandon - TM848 userMan 1983.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 userMan 1983.pdf


Might also want to look around the tandon root directory one level up from those.
 
Last edited:
JDallas said:
These are the files I have on Tandon floppy drives:

...These are for TM-848-1 and TM-848-2 models:
Floppy Drive - 5.25in - Tandon - TM100 (Printed).txt
Floppy Drive - 8in -Tandon - TM848 floppy disk drive.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy disk drive.jpg
Floppy Drive - 8in -Tandon - TM848 floppy side.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy side.jpg
Floppy Drive - 8in -Tandon - TM848 floppy top.jpg . . . . http://maben.homeip.net/static/S100/tandon/photos/Tandon TM848 floppy top.jpg
Floppy Drive - 8in -Tandon - TM848 service manual 1982.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 userMan 1983.pdf
Floppy Drive - 8in -Tandon - TM848 Specification and Schematic.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 Specification and Schematic.pdf
Floppy Drive - 8in -Tandon - TM848 userMan 1983.pdf . . . . http://maben.homeip.net/static/S100/tandon/diskette/Tandon TM848 userMan 1983.pdf
Click to expand...
Actually that last one (1983) is the -E user manual I mentioned.
 
MikeS said:
No, that's for the -1 and -2 (belt drive, TTL); lots of docs out there for those, but not so much for the -E...
Click to expand...
Correct. I would want them until I had the equivalent -E documents which are rare.
Thanks for the note to check that user manual as being for -E in fact. I had not noticed.
 
You must log in or register to reply here.
Back
Top