• 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.

Pertec ISA interface card

Proof of concept was pretty easy--I've got a PCI Digital I/O board here 3x8255s on it and wire-wrapped up the support and interface logic on a separate board and hooked it to my Fujitsu drive, so I could manipulate the various signals and see how the drive reacted. I'm pretty confident that I understand the operation.
 
wuauu... my English is not 100% perfect, so please correct me if I understood wrong: you have a PCI i/o card which has 3 x 8255 ( like this one - http://www.intersil.com/data/fn/fn2969.pdf ) which you use as a logical data analyzer to dump the signals. And I'm lost here. Is it possible to see some pictures and a block schematic? also - who manufactured that card? I'm working with data acquisition modules hooked to an ARM 32bit micro controller running Unix BSD - some PhD work I need to finish. Maybe your pictures will spark me an idea.

The best approach should be a USB(host) to SCSI (peripheral) converter (http://www.ratocsystems.com/english/products/U2SCX.html ) + a SCSI(host) to pertec(peripheral) converter. Your magic should go inside the second converter, so any system should know there's an USB tape connected and should treat it like one.
 
It's not quite that simple, but yes, it's a PCI card, an older version of this one. But it doesn't stop there--said card interfaces to another interface board containing various drivers, receivers, latches, and an LS280 parity generator chip--and terminators.

If you don't have a tape drive that transfers data really fast, it works pretty well, but is far from a final solution. It lets me know that I've got the right interpretation of the signals.
 
I think this may help
http://www.sydex.com/pertec.html

pertec protocol explained in details.

there's a US guy selling two Qualstar 1260 tape drives on ebay, unfortunatelly he described me the pertec connectors (three rows of pins) on a private message.
US$999, after the message exchange that price jumped from US$120 with NO reason.
 
good. Now, here's a little detail about what I do for PhD. I will ask for an excuse about my English, which sucks, so I have to talk like kids to be sure my words are fully understood.

I'm working at a monitoring/warning system based on ARM microcontrollers. I managed to compile Unix FreeBSD 8.0 on a Marvell openRD platform ( http://www.newit.co.uk/ - go to "shop" and look for "openrd ultimate"). I have several USB data acquisition units ( http://www.bmcm.de/us/prgr-meassyst.html#external - search for "usb-AD"). With their help (long live the bavarian measuring systems, they are the kings) I managed to bypass their i386-based libraries and talk directly to USB-AD. I can read volts and logic states and I can also create voltage output and digital states. Problem is... USB-AD has only 4 digital inputs and 4 digital outputs, but my project is based on analog stuff so... not a real problem. I worked with USB-AD and I am really impressed by its performance. I can fully program it to do almost anything - from controlling/reading states of "french potatoes cooking" process to complicated industrial stuff involving PID algorithms, so I can recommend the following procedure...

For this pertec pain-in-the-butt system, there IS a problem. The "bmcm.de" product which I recommend is... the USB-PIO (search on the site, bmcm.de -> english -> products -> usb-pio). That unit is connected to USB and has 24 channels, some of them can be programmed to be bi-directional. Now... if I follow the protocol I posted earlier and I also use two (or three?) USB-PIO units, it is possible that the PERTEC communication protocol can be implemented using a C program and the LibAD (C) bmcm deutschland, which is supported by any i386 CPU architecture.
Basically, those usb-pio can read states and output states according to the pertec protocol, in order to send and receive data to the tape.
With a little "tune-up", the C program can use the stdin/stdout in order to send/get data to/from tape.

"Dreamland example" (tape.c does not exist yet)

# cc tape.c -o tape
# tar -cf - /kits/windows |gzip -9 - |./tape -send

what does this mean:

cc tape.c -o tape -compile the program - we suppose I drunk enough beer to write a perfect program and to build an error-free binary file;

tar -cf windows.tar /kits/windows -create an uncompressed archive called "windows.tar" which contains all the files in the folder /kits/windows
gzip -9 windows.tar -compress the windows.tar into windows.tar.gz and removes windows.tar

tape -send windows.tar.gz - the "dreamland example" program which sends the file to the tape.

now the pipe stuff:

tar -cf /kits/windows -|gzip -9 -

tar creates the uncompressed archive (which goes out to the typing terminal as the " - " specifies). Data from the tape terminal is captured via pipe ( " | " ) by gzip, which compresses it and also outputs to the stdout. "tape" program in the current folder ("./") captures the data from stdout (standard output - typing terminal, " - " ) and sends it to the tape.

another example: my cat played with the remote controller, TV started to act funny and I filmed everything. The film is stored on a 9 track tape via ./tape -send pussycat.avi (dreamland - fictional not-yet implemented program).
I can play the film using ./tape -get - |mplayer -cache 32768 -fs -

./tape gets the data and sends it (" | ") through the pipe to mplayer, which fills its cache then plays the film. I tried this with a DDS 8mm tape drive and it played like a youtube flash film via an internet connection on 14k baud old modem. I mean like sh*t. Slow transfer rate from tape to mplayer. ( this time for real - the commands are: dd if=pussycat.avi of=/dev/nsa0 for transfer to the tape, cat /dev/nsa0 |mplayer -cache 32768 - to play the film from the tape ).

Now - this "tape.c" should be the "alice in wonderland" software which I can help to develop using those usb-pio units. Or I can start building it around Xmas this year (if wife stops her shopping marathon, which is improbable)

Also, these units can be programmed in Windows (9x, XP, 7, vista - which sucks) using their specific libraries, which come on CD when product is purchased. I hate the world of Billy the Evil (Microsoft) so my conclusion stops here, I did no further research in this area.

My spare time is limited and I can't start the work. Also, I have no USB-PIO units to have the required i/o lines. But maybe somebody can get the idea and make it work.

Also, I did some extensive research on every tape drive documentation available at bitsavers.org - no hardware (block) schematics with no detail about pertec. Nothing.
I also found this: http://openswitch.com/HDW-BX100.aspx - this thing can talk to pertec tape drives. I wrote them about details, but probably I have to buy one and somehow reverse-engineer the protocol. Again, no spare time.

I hope this can also help and I can also offer support for software programming, but limited on Unix FreeBSD only - I quit linux when RedHat 8.0 went out to the world and no updates in this area for a long time.
 
Last edited:
My reply was a joke--who do you think put the web page up? I know a bunch more about this that I didn't put up on the page for brevity's sake.

One of the issues with this interface is that some pins need to latch if a transient signal goes by; others are steady-state. With your ARM solution, you'll need to provide 3V-to-5V logic translation.

I've got the Verilog written and simulation-tested for a Xilinx XC95108 CPLD, coupled with your favorite 8-bit µC--the various registers and so on are selected by a 3-bit register address and 8 bidirectional data lines and RD/WR strobe lines. Parity for writing is also generated. I haven't taken it to prototype yet, as it's a low-priority item.

A FPGA would also be an option, but the 3-to-5 volt logic translation comes into play--and there are a lot of signal lines.

I'm just a dumb old engineer, with no PhD.... :sigh:
 
Last edited:
well, it's never late for me to learn from others, older than me, which already got their PhD in <life experience>. some 10 years ago CPLDs were popular in eastern europe universities. I learned about verilog in theory, I only saw once the transfer process to a xilinx board. Don't know what happened to the CPLDs in my university, they came and vanished away. I prefer to work old-school, pen and paper. Modern design software have some problems, for example a power line has some magnetic influence on signal lines, which translates in low transfer rates due to interference. I noticed that hand-made boards work better than automatic-generated PCBs if some lines are kept away from other lines.
Now - I need to get a dictionary in order to understand the words "latch" (is that 74LS373/374? ) and "assert". You guys have words for everything. And maybe then I can understand why 3v to 5v translation is needed, now it's complete darkness.
I only saw the pinout signals, did not read anything else... so I am sorry I did not catch the joke :( Please please when you have any spare time, update that pertec web site. I will start the paper work as soon as I can.
 
Last edited:
No problem; my name is written very small at the end.

A lot of what I learned was by constructing various prototype controllers. My most successful used three 8255 PPI chips and a bunch of external logic. I abandoned the idea of doing an ISA-bus controller fairly early on--some drives read data at 1MB/sec., which is too fast for reliable operation on an ISA bus. So a microntroller with a bunch of local RAM is definitely the way to go--add your interface of choice; I like RS232C because just about anything can be made to work with it, but USB is also another option.

"Assert" means to create a signal condition that is true, regardless of polarity. So if, for example, a "write" signal was active-low, "asserting write" would mean to bring that signal low. "De-assert" is the opposite. If the same signal were active-high, then "asserting write" would mean bringing that signal to a high level. You will see these terms used in a lot of chip documentation.

"Latch" is pretty much just that--it's anything that can be made to remember a signal, when that signal is conditioned by another "strobe" line.

CPLDs are very useful, even today. The require no added configuration memory, are ready to go immediately upon application of power and can be still have in 5V logic.

The 3V to 5V thing refers to the fact that traditional TTL logic levels operate at 5 volts and that modern CMOS operates at 3 volts (or lower; 1.8V logic is very common). That means that the output of 5V logic must be attenuated so it will not destroy 3V devices. Some 3V logic can drive 5V logic directly, but it depends upon the devices. The 74LVC family of logic can be used to translate between the two logic levels.

If you need a bunch of I/Os and are comfortable with microcontroller programming, you may want to look at Digilent's Uno32 or Max32 boards using the PIC32 microcontroller. The Uno32 has 42 lines of I/O; the Max32 has 83 I/O lines available. Both are inexpensive and have a toolset written for them.
 
In my country we say the good women are always hard to find/hard to get. It's the same with other things men are in love. So maybe someone will be able to get this:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=190547771824&ssPageName=STRK:MEWAX:IT

I mailed him asking about any "scsi" or '-S" written on the tape, and about any adapter inside. No answer yet. It costs me 4 times its value to bring it to Romania... I hope it's the "pertec-to-scsi-adapter-included" version.

Thanke you for information, no more darkness in the area :eek:nfire: It seems the old soviet influence is still alive, because until today I ignored the modern 3.3V and 1.8V specifications. In any project I build, I use only solid stuff, hard to destroy parts. Old russian us-microchip-clones are the favorites. Those guys were building ceramic chips, were boiling them in oil and then were thrown away outside in the snow. All the chips which still worked in the specified parameters were sent to production. The rest were melted again. I never saw any soviet microchip blown/burned/malfunctioned. 5V and 12V only. Their encodings is hard to read and to understand, and they also consume a lot of power. Also, old soviet tape drives still respected pertec standard - the interfacing cables were a nightmare, they were obsessed with dimensions and shielding, but quality of the wires was extremely poor. I could not find any intact soviet tape drive, only pieces. Their motors are still hunted today, you can bring down a tree with one of those. I wonder if the old 8" soviet floppy drives were using pertec standard because whatever pieces I could find, they had the same connector as my qualstar 1052 and the other tape drives I saw.
 
Last edited:
That Qualstar 1260 is a Pertec interface--I can tell just from the cable coming out the rear of the unit. SCSI interface Qualstars used 50-pin Centronics/Amphenol connectors.

But observe: there are two (2) 50-pin connectors that belong to a standard Pertec interface. There are many other 50-pin interfaces, none of which resemble Pertec. Your 8" drive was most likely a Shugart SA-800 type of interface. There are also 50-pin QIC tape interfaces as well as SCSI interfaces and probably about a dozen other types of 50-pin interfaces, none of which are compatible with each other.

The cable on the Qualstar terminates into a 68-pin D-subminiature connector (DD68-M). I do have the pinout of that one.

Voltages are moving lower for two reasons--one is the smaller geometry of semiconductor features; the other, related, is that the lower voltage reduces the amount of heat generated when a component changes from one state to the other--and as components speed up, more heat is generated. So the heat dissipated is proportional to V², and of course dV/dt. One pays for this, however, in lower noise tolerance.

Most new mobile devices use 1.8V logic.

I seem to recall that the Soviets used the DEC LSI-11 clone CPU in a lot of equipment, including a pocket calculator!
 
now this one is SCSI!!!!

http://global.ebay.com/Qualstar-9-track-tape-drive-with-conversion-software/130563763026/item

it's Qualstar 1260S.

and it has the pertec-to-scsi converter.

It costs me around US$900 to bring it to Romania. I can't afford that yet. And that guy somehow blocked any messages to his account so no contact is possible before placing the bid.
For a pertec-to-scsi converter this drive is perfect. I would build it but it's too far away and too expansive to bring it here, I make this ammount of money in 6 months of work - it's normal, we are the european union.
 
Last edited:
qualstar 1260 with pertec interface, US$100, two pieces.

http://global.ebay.com/Qualstar-Magnetic-Tape-Transport-Pertec-1260-900013/260854317640/item

I got a pertec to scsi converter from another qualstar tape drive, the last one, don't remember its encoding name. I will try to clone it. PCB is labeled as following:

Qualstar PCBA 500417
PCB 500416-01-1 REV C
the working voltage is +5V only.

I have no information on the following parts:


F82C5086 B
P82C5060-32 D
these chips might be FPGAs; no idea about specifications/pinouts; I wonder if their configuration can be read.

PLS153N - programable gate arrays, found on google - no idea about programming or reading the configuration;

8464A-10L, made in Japan - DIL28 - SRAM memory, no idea about specifications/pinouts;

PCF8582-E, DIL08, 256x8 CMOS EEPROM, i2c bus interface;


if I get to read the configuration of all those chips, I may be able to compile everything into a FPGA or as a program inside a microcontroller, and get the first pocket-sized pertec-to-scsi converter kit. Need help.

Another curiosity:
http://www.openswitch.com.br/en/HDW-BX100.aspx
these guys say they implemented a pertec interface using an ARM microcontroller. telephone switch which can do backup on pertec tapes.
 
Last edited:
MYTH CONFIRMED:

Qualstar 3400 series have a pertec to scsi converter inside which works independent from the tape drive. Standard 5VCC power supply. Three cables needed: 1. power (+5V); 2. SCSI + terminator, any SCSI controller, max speed must be set below 5MBytes/s in the bios of the controller; 3. two cables for connecting the PERTEC buses (J71 on card goes to J1 on tape drive; J72 goes to J2, this fits to any western or ex-soviet-block PERTEC tape drives). No other cables required. Pay attention to the power supply connectors, you MUST identify the pins with a multimeter by checking the corresponding capacitor pins (+ and -) on the converter board. The 3400 series PERTEC-SCSI controllers are identified by ADAPTEC SCSI adapters as Qualstar 34xx, both with and without the pertec interface hooked to the pertec tape drive.

I hooked some open reel to reel tape drives to a 3420 converter: a Qualstar 1052 and a bulgarian ISOT CM-509. Operating system - Unix FreeBSD 6.2. Standard sequential access SCSI driver "device sa" (/dev/sa*, /dev/esa*, /dev/nsa*). Horrible speed transfers - between 10 and 48 kBytes per second.

I could manage to dump raw data only using the 'tail' command. 'dd', 'cat' and 'less' do not work. Tape density can be controlled via the 'mt' utility (mt density 0x02 for 1600cpi) - see man mt for details. Dumping raw data is more simple with pertec-ISA controllers.

!!!!Advice!!!!!: avoid converting SCSI to PERTEC - the transfer will be limited by the technology of the tape drive. Limited speed. It is possible to play a mp3 but not video.

Now - for the older, more experienced people here: who can help me with datasheets of those microchips I listed in the previous posts - for compiling all data inside a single microcontroller?
 
Pertec interface isn't difficult, why do you need to reverse-engineer what are probably custom parts? Pertec is about as dumb as you can get--you toggle GO with other lines set to what you want to do. If you're reading, the interface throws 8 bits of data at you and asserts a "read data" flag and any error flags. You grab it, because the interface does not check to see if you got it. Write is the same, but in reverse--the interface doesn't check to see if the write data lines have data, it just takes whatever's there. Parity generation is up to you.

Signal protocol is OC output with 220/330 termination. Some error flags are only asserted during the transfer of a byte, others stay asserted until a condition is cleared.

Data transfer tops out at 1MB/sec, depending on the formatter. Some will blast data at the full rate, others will dribble it at you as it happens.

There is no magic to this, nor are there any secrets. Just lots of signal lines and OC drivers.
 
Pertec interface isn't difficult, why do you need to reverse-engineer what are probably custom parts? Pertec is about as dumb as you can get--you toggle GO with other lines set to what you want to do. If you're reading, the interface throws 8 bits of data at you and asserts a "read data" flag and any error flags. You grab it, because the interface does not check to see if you got it. Write is the same, but in reverse--the interface doesn't check to see if the write data lines have data, it just takes whatever's there. Parity generation is up to you.

Signal protocol is OC output with 220/330 termination. Some error flags are only asserted during the transfer of a byte, others stay asserted until a condition is cleared.

Data transfer tops out at 1MB/sec, depending on the formatter. Some will blast data at the full rate, others will dribble it at you as it happens.

There is no magic to this, nor are there any secrets. Just lots of signal lines and OC drivers.


Would you happen to know of a document that covers this interface? It sounds pretty straightforward, but if i would venture into the Pertec interface business, I'd want to have a pinout, timing diagram, and a description of the error flags.
 
Back
Top