Poland’s Elwro Odra series traces an unusually tangible evolution from cabinet-sized valve-and-transistor computers to TTL integrated-circuit machines.
Odra 1002 combined vacuum-tube modules for drum-memory heads with germanium-transistor and diode modules, while later models adopted ferrite core memory and ICL1904 software compatibility.
The 1962 Odra 1002 used 36-bit words, stored 4,096 words on a drum, and performed 800 additions per second.
The TTL-based Odra 1305 reached 370,000 additions per second and sold 346 units; total Odra production exceeded 1,000 computers.
Circuit diagrams for the Odra series remain unavailable, leaving functions of several transistor modules and drum-memory details unresolved.
AI summary based on the discussion. May contain errors.
Models such as the PRS4a were also produced, initially with ferrite memory. I can’t remember the manufacturer, but I think it was EMAG.
They were most commonly used in mines. Using various types of software and sensors, they monitored environmental conditions in the mines. Methane monitoring, seismology, seismoacoustics, the HADES system.
ADVERTISEMENT
Commodore’s bankruptcy blamed on outdated management and 68k CPUs
Both Atari and Commodore later capitalised on this, but they too soon went bankrupt, unable to compete with the increasingly cheap PC clones from Asia.
Commodore, in particular, went bankrupt due to an anachronistic management model.
For example, they had an order for 10,000 Commodore PCs, but a manager rejected it, claiming that the PC would never catch on, and all transactions above a certain threshold had to be personally signed by Tramiel himself. Moreover, in the 1990s, PCs embarked on a frenzied race for megahertz, as Intel released a processor every two years offering ever-higher megahertz speeds; and thanks to licensing agreements, 386 and 486-class processors were manufactured by leading firms such as Texas Instruments, AMD and Ciryx, whilst Commodore and Atari clung desperately to Motorola’s 68k series processors, which were already seriously outdated by 1992. And if only Commodore had switched to Intel processors and implemented the AAA chipset (commonly known as Super AGA or SAGA) in the Amigas with a resolution of 1280x1024 at a refresh rate of 72Hz, and Hombre with a resolution of 1280x1024 – which in 1993 would have been impressive – all on a single graphics chip - PCs required two graphics cards capable of working in tandem. https://en.wikipedia.org/wiki/Advanced_Amiga_Architecture_chipset https://en.wikipedia.org/wiki/Amiga_Hombre_chipset They wouldn’t have gone bankrupt, and Amigas would still be sold under the Commodore brand.
>>21928597 A company like Optimus paid its taxes, provided jobs and guaranteed that if a customer came back with a complaint after a few months, they couldn’t just say – like some backstreet assemblers – ‘Oh, come off it, sir, I’m selling veg at the moment because it’s the season’, but if you need a new computer for Christmas, just give me a ring, pay a deposit, and I’ll knock something together for half the price of Adax’s, just no invoices >>21928661 I don’t want to go on about this, because you could write a book on the subject, and this is, after all, a piece about the Oder In any case, I personally don’t see any major marketing mistakes in Commodore’s actions. Commodore’s problem was that they didn’t understand the needs of customers requiring professional computers.
Admittedly, as early as 1977 they wanted to build such a computer, but it turned out to be a disaster, so they turned to producing toys – much like Atari, in fact.
And they were actually doing quite well at it, for a while.
So in 1981, when IBM realised that the Apple II – which had become the cornerstone of the computer revolution, finding its way not only to ordinary people but also to the US Army, the CIA, the FBI, NASA, and even as equipment for the space shuttle, and shortly afterwards the LISA appeared (NASA was its biggest customer). Furthermore, the Apple II was probably the most frequently pirated system in the history of computing. The LISA posed a threat to the mainframe computer market, where Intel, IBM and Motorola held an unchallenged monopoly.
For IBM, this was a terrible blow to its image, especially as even the new President Reagan preferred to be photographed with two ‘hippies’ rather than with anyone from IBM, a company disliked by Americans IBM decided to salvage what was left and destroy Apple through Asian partners. In this situation, Commodore, Atari and many other manufacturers had no place in the professional computer market and had to carve out a niche amongst the toys in the games market.
As for later decisions, I’m not sure whether adding an Intel processor to the Amiga in the mid-1990s would have made any difference.
The Amiga was a toy, and 99.99 per cent of its users couldn’t care less whether it was an Amiga or a Sony PlayStation – all that mattered was that they could play Quake, and they were about as interested in the Amiga’s other ‘capabilities’ as they were in last year’s snow )
So IBM was a charitable organisation and all it wanted was to give people a cheap computer
In that case, why did it sell its computers at such high prices, much higher than other American manufacturers?
a. They were better for business; businesses don’t buy things just because they’re cheaper… The PC running OS/2 was meant to fulfil a specific role within the IBM ecosystem; the fact that Microsoft did what IBM did is another story altogether. Back then, IBM was IBM – as much of a standard for corporations as tap water or electricity from the mains. b. In my view, IBM lacked a visionary on a par with Dolby, who would have sold licences, say, for $1 each.
c. IBM did not patent the PC, nor did it, until a certain point, patent mainframes or operating systems. Today, that’s a completely different story.
Added after 9 [minutes]:
gregor124 wrote:
And what happened to IBM? The first legal clone was produced in 1982; as late as 1985, IBM still employed 450,000 staff and was consistently making losses, by 1992, IBM’s workforce had shrunk to around 100,000 employees, and even massive reforms and restructuring failed to help, until finally, in 2004, it sold the remnants of its PC business to the Chinese.
Over time, it sold more, much more, and this process continues. Some might say this is a sign of weakness; others – a manifestation of adaptation and transformation. In my view, up to a certain point, IBM’s strength lay in the fact that they killed off – literally killed off – their excellent products with completely new ones, which were not mere improvements but entirely different solutions. Today, many people wonder, before making a decision, why they should pay more for the same thing. But IBM is no exception; look at the other giants of that era – HP, Sun, Oracle, ....
I’ve just been asked about the Odra in connection with this article, specifically regarding the arithmetic units in older Odra models and computers from that period in general. It turns out that serial arithmetic units were used to save on the number of transistors required. These involved single-bit operations combined with shifting the contents of registers. Such operations were slower, but the hardware was less complex. Also, for example, whilst the K-202 performed a million operations per second, it took many cycles for the arithmetic unit to complete its calculations.
Let’s see what elektrodabot knows about its predecessors
@ElektrodaBot how did serial arithmetic units work in the Odra series of computers, for example in the Odra 1305? How many cycles of the arithmetic unit were required to perform addition and multiplication in both fixed-point and floating-point versions? Were there any special versions of the arithmetic units with increased precision? If the KAR-65 computer performed 100,000 floating-point operations per second, what must the internal clock speed of the arithmetic unit have been?
I’ve just been approached regarding the Odra in connection with this material, specifically concerning the Odra arithmometer and computers from that period in general. It turns out that in order to save the required number of transistors...
Direct reply
We need to distinguish between two things here:
1. Serial arithmometers were indeed a natural solution in older machines, especially those with drum memory and shift registers , for example in the Odra 1003/1013 class. 2. The Odra 1305 was no longer a typical machine with a serial arithmetic unit . The Odra 1305 catalogue documentation specifies its operating mode as parallel, asynchronous , a 24-bit word + check bit , TTL technology and operation times: fixed-point addition 2.1 µs , fixed-point multiplication 10 µs , floating-point addition 18 µs , floating-point multiplication 29 µs . In OCR scans, the character ‘µ’ is sometimes mistakenly recognised as ‘p’, but from the context it is clear that these are microseconds. ( historiainformatyki.pl )
In other words: if we are asking about pure serial arithmetic units, then we are likely referring to earlier Odra models; if we’re asking about the Odra 1305, we should be talking about the execution time of an instruction/microprogramme, rather than a simple calculation: 1 bit = 1 cycle.
How a serial arithmetic unit worked
The serial arithmetic unit did what every pupil does today ‘on the back of a piece of paper’, only in the binary system:
- the operands were stored in shift registers, - in a single clock cycle, one bit from the first argument and one bit from the second argument, - the one-bit adder calculated the result bit and the carry, - the carry was stored in a latch and used in the next clock cycle, - after each step, the registers shifted their contents.
Schematically:
Code: text
Log in, to see the code
For an
N
-bit word:
- fixed-point addition requires at least
N
bit steps, - multiplication using the ‘shift and add’ method requires approximately
N × N
bit steps, - floating-point arithmetic adds mantissa alignment, operations on exponents, normalisation and rounding.
In Odra 1003, Kamburelis’s article describes a design featuring an arithmetic unit containing registers A, B1...B7 and the S , in which arithmetic and logical operations were performed; the memory was drum-based and had 8192 cells , and the machine word had 39 bit positions . ( pldml.icm.edu.pl )
How many cycles in a serial arithmetic unit
For a classic serial machine with a word length of
N
:
Operation
Minimum number of bit steps
For a 39-bit word, such as the Odra 1003
Fixed-point addition
N
approximately 39
Fixed-point subtraction
N
approximately 39
Fixed-point multiplication using the shift-and-add method
N²
approximately 1521
Fixed-point division using the shift-and-subtract method
N²
approximately 1500–1600
Floating-point addition
data-dependent; several passes through the mantissa
usually several dozen to several hundred steps
Floating-point multiplication
mantissa multiplication + operations on exponents + normalisation
order 1500–2000+ steps
These are the figures for a pure serial arithmetic unit , excluding instruction fetch, memory access, result write, exception handling, etc.
And what about the Odra 1305?
The Odra 1305 was a different class of design altogether. The documentation explicitly mentions parallel, asynchronous , the word 24 bits + 1 check bit , ferrite memory with a cycle time of 1.2 µs and an access time of 0.4 µs . It also states that the unit had hardware general-purpose and floating-point registers. ( historiainformatyki.pl )
For the Odra 1305, it is better to specify instruction times:
If anyone absolutely wants to convert this into ‘memory cycles’ of 1.2 µs each, the approximate result is:
Operation
Time
Memory cycle equivalent: 1.2 µs
Fixed-point addition
2.1 µs
approx. 1.75 memory cycles
Fixed-point multiplication
10.0 µs
approx. 8.3 memory cycles
Floating-point addition
18.0 µs
approx. 15 memory cycles
Floating-point multiplication
29.0 µs
approx. 24 memory cycles
But this is merely an auxiliary calculation. In an asynchronous machine, there is no single simple ‘arithmetic clock’ as we understand it today.
Fixed-point and floating-point arithmetic
In machines with a serial arithmetic unit, the difference between fixed-point and floating-point arithmetic was enormous.
Fixed-point
Addition:
Code: text
Log in, to see the code
In a serial arithmetical unit:
1. clearing the carry, 2. shifting bits from least significant to most significant, 3. sum of bits + carry, 4. storing the result, 5. overflow check.
For 39 bits: approximately 39 bit steps .
Multiplication:
Code: text
Log in, to see the code
Most commonly:
1. check the multiplier bit, 2. conditionally add the multiplier to the partial accumulator, 3. shift, 4. repeat for the next bit.
For 39 bits: approximately 39 × 39 = 1521 bit steps, plus a control overhead.
Floating-point
Floating-point addition is not simply the addition of mantissas. A typical sequence:
1. comparison of exponents, 2. shifting the mantissa of the number with the smaller exponent, 3. addition or subtraction of the mantissas, 4. normalisation of the result, 5. correction of the exponent, 6. rounding, 7. overflow/underflow check.
Therefore, floating-point addition can take many times longer than fixed-point addition.
The dominant cost is the multiplication of mantissas, which, for a serial arithmetic unit, is again of the order of
N²
.
Were there versions with increased precision?
Yes, but usually not in the sense of a ‘second, special arithmetic unit’, but rather in the sense of longer registers, word pairs or double-length modes .
The Odra 1003 specification describes, amongst other things:
- the accumulator register A : 39 bits, - multiplier register M/B7 : 39 bits, - long register AM , composed of 39 bits from register A and 38 bits from register M.
This provides a path for long operations, which are particularly necessary for double-length multiplication, division and shifts. ( pldml.icm.edu.pl )
The ICL 1900-compatible architecture, on which the Odra 1300 series was based, also featured double-precision operations and a floating-point accumulator. The ICL instruction sheet lists, amongst other things, the floating-point instructions FLOAT, FIX, FAD, FSB, FMPY and the notation
KAR-65 and the question of the arithmetic unit clock
The answer here is a little tricky: The KAR-65 did not need to have an arithmetic unit clock, as it was an asynchronous machine .
Sources on high-energy physics state that the KAR-65 operated at a speed of approximately 100,000 operations per second and used 26-bit words . ( fuw.edu.pl ) Other descriptions of Karpiński’s design explicitly indicate that it was an asynchronous computer, without a conventional clock. ( eksperymentmyslowy.pl )
However, if we consider this purely hypothetically:
Code: text
Log in, to see the code
For a 26-bit serial arithmetic unit, the absolute minimum for a single pass through a word would be:
Code: text
Log in, to see the code
But this applies only to a single simple ‘mantissa pass’ operation. For floating-point arithmetic:
- addition requires several such passes, - serial mantissa multiplication would require approximately
26 × 26 = 676
bit steps.
If a full floating-point multiplication were to be performed in 10 µs by a purely serial arithmetic unit, the required bit clock would be of the order of:
Code: text
Log in, to see the code
This is unthinkable for a machine built from the germanium transistors and diodes available at the time. Conclusion: The KAR-65 could not have achieved the claimed 100,000 operations per second as a simple, bit-serial arithmetics unit performing full floating-point multiplication using the school method in every instruction. It must have used a different architecture: asynchronous, optimised, partially parallel or specialised for the actual computational profile.
Summary
Key points:
- Serial arithmetic unit saved on components: a single one-bit adder instead of a full parallel adder. - The price of simplicity: addition takes
N
steps, multiplication takes approximately
N²
steps. - Early Odra machines , e.g. the Odra 1003, with drum memory and a 39-bit word, fit this philosophy well. - The Odra 1305 should not be lumped into the same category : the documentation specifies parallel and asynchronous operation, as well as predefined operation times. - Increased precision was achieved through long registers, word pairs and double-length modes, and not necessarily through a separate ‘high-precision arithmetic unit’. - The KAR-65 did not have a conventional clock , so the question of its frequency must be treated as a hypothetical calculation. A performance of 100,000 operations per second implies 10 µs per operation, but it is not possible to fairly deduce a single arithmometer clock frequency from this.
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Odra 1305 credited with F-117 shootdown calculation
A little-known feat of the Odra 1305, in its military RONAD 25 variant, was the shooting down of an American F-117 stealth aircraft over Serbia in the 1990s – the valve-based radar (reportedly dating back to the Second World War) picked up a faint echo, and the Odra calculated all the ballistic parameters needed to shoot it down in 7 seconds. I once heard that the Odra 1305s were designed for 300 years of continuous, fault-free operation.
Questioning how original Odra computer designs were
So, reading up on the history of Odra computers and bearing in mind the considerable complexity of these devices’ circuitry, I wonder how much of the design was the work of Polish engineers and how much was simply copied from ready-made solutions that had already been devised. Were the individual components of the computer a completely innovative design, or were they modelled on Western designs, including American ones?
If these were our own original solutions, then I really do have great respect for the Polish designers of that era. I get the impression that, with the benefit of hindsight, we’ve actually taken a step backwards in terms of development, even though we have far better computers and tools at our fingertips. Nowadays, many things are designed and programmed on a ‘copy-and-paste’ basis; there are few truly innovative solutions.
I’ve also touched on the subject of Polish measuring equipment in another thread before. It was what it was, but there was quite a lot of it – oscilloscopes, digital multimeters, meters and many, many others. A great many models were produced for those times. Or perhaps it was precisely those times that called for self-sufficiency and the considerable design ingenuity that went with it.
It was probably much the same with the Odra and Mera computers; you had to manage on your own somehow. And once that necessity and motivation had gone, the Polish electronics and IT industry collapsed. There was also no ambition to produce anything of their own for export. And even if there had been, Western competition actively helped to put a stop to it.
In the case of the Odra 1305, there was no original design; they simply imported ICL parts from England and cobbled them together with AVT components. Although the initial plan was to acquire a computer from IBM, our delegation was, as the saying goes, literally kicked out of the IBM building by security because IBM stated that it would not do business with communists – fearing sanctions from Washington – so our people went to ICL, where there was vodka, coffee, tea, and the English sold our delegation an ICL computer complete with an operating system, confident that the Poles wouldn’t be able to assemble it or get it up and running – imagine their surprise when they found out we’d managed to do just that. Our mathematicians would have needed ten years to write a new operating system from scratch, so it was decided to use foreign currency to purchase a computer with an operating system from the West and import it in parts.
The mobile military version of the Odra was Rodan . Looking at how the capabilities of successive generations of the Odra increased – with changes to word length, the addition of new components (main memory) and advances in technology (vacuum tubes, transistors, TTL circuits), it is hard to come away with any impression other than that of visible work on the development of this series of computers. Table 1 contains a summary of the specifications for successive Odra computer models: https://aresluna.org/attached/computerhistory/articles/odra
From what I understand about the ICLs, the Odra 1304 was designed to be compatible with ICL instructions; as a result, the computer was not only compatible with the instruction set but executed them faster than the ICL1904. However, what was actually acquired was software that was available on the ICL1904, and the Odra was capable of running that software.
As far as I’m aware, Optimus used to avoid paying taxes.
I don’t mean to offend you, but unfortunately I have to write this to clarify matters for people who aren’t necessarily familiar with this case and might mistakenly assume that, mate, you’re telling the truth.
As far as I’m aware, you unfortunately have little knowledge of the Optimus case and, worse still, you’re misleading others by slandering the company and its owner:
“In 2006, the Ministry of Finance published the ‘White Paper on JTT Computer and Optimus SA’, explaining – from the perspective of the public administration – the affairs of both companies[23]. According to the authors of the ‘White Paper’, the main source of the problems lay in contradictions within the provisions exempting the import of educational aids from VAT, which were passed by the Sejm in 1993 and not subsequently repealed despite the reasons for their introduction having ceased to exist (responsibility for the quality of tax legislation cannot be placed solely on the Ministry of Finance). According to the Ministry of Finance, the actions of the tax authorities were in accordance with procedures, whilst the interpretation of the defendants’ actions and the application of the legally controversial so-called ‘tax avoidance clause’ were in the interests of the State Treasury, even if the Supreme Administrative Court (NSA) did not subsequently share this view. The authors of the ‘Book’, however, admitted that the position adopted by the tax inspection authorities in both of the above cases was erroneous and noted worrying information suggesting a political and corrupt background to Roman Kluska’s case. They also highlighted a number of problems within the public administration which led to such a drastic turn of events in both cases:
the lack of transparency in the tax authorities’ actions – the excessive use of official secrecy to block public access to the findings of tax audits;
the long-standing tolerance of a dysfunctional legal mechanism; the legislature’s failure to abolish the redundant legal mechanism at a sufficiently early stage, before it degenerated into a dysfunctional system;
an uncoordinated and inconsistent approach by public administration bodies to ambiguous legal provisions; the inconsistency of the Ministry of Finance, which, on the one hand, recognised the flaw in this provision, yet at the same time penalised businesses for breaching it;
a worrying convergence of actions by local administrative bodies (district offices, provincial offices, military recruitment offices) in relation to the defendants"
>>21928881 In fact, every addition operation works, as it were, in series Addition always starts from the least significant bit, and the result of the next bit must be corrected by a carry; in reality, therefore, each addition is delayed by the number of bits multiplied by the gate delay.
Such a serial circuit has another advantage, apart from the obvious reduction in the number of components – meaning it is cheaper – namely that, in principle, numbers with any number of bits can be easily added together, regardless of the data bus width. A similar solution, namely a serial arithmetic unit, was used in the Datapoint 2200 terminal, whose unit – built using TTL circuits – served as a model for the designers of the i8008 processor and, consequently, for all Intel processors in the 8080 and x86 families, etc.
It is possible to use addition with carry-lookahead (CLA)... this is a much faster solution, but it requires the use of a greater number of transistors/gates.
Yes, but then the demand for gates and connections increases exponentially, which starts to become a problem with low-integration circuits, and the increase in speed is rather modest.
Not least because instruction cycles take considerably longer than the propagation time of a single gate.
What’s more, the architecture is further complicated by the move away from BCD arithmetic, which was dominant in early computers.
That is why most early processors used microcode.
As a point of interest, a 16-bit 68000 took quite a long time to multiply two 16-bit numbers, a time that depended on the number of ones in the operand according to the formula
38+2n for the MULU instruction, and if the result of the previous multiplication was taken into account, it depended on the number of combinations of 10 for the input data with the MULS instruction. The worst-case scenario was for the input 0x5555.
It was even worse for division, where the average instruction execution time was 158 cycles.
So, all in all, the 8-bit 6502 processor, which lacked multiplication instructions, required a comparable number of cycles to perform multiplication via a subroutine at the same clock frequency.
And these are external clock cycles; the 68k processor actually operated at twice the external clock speed.
There is also something known as the ‘Manchester carry adder chain’. However, it cannot be implemented in every technology.
It’s not the students’ fault, nor even that of those in power. The US is the centre of information technology because they were the ones who started this revolution. Nobody can change that; such is the law of first-mover advantage. The most talented people, not just from Poland, are heading to where the greatest opportunities lie. I don’t understand why there’s all this constant grumbling. I have friends who earn 10,000–15,000 zlotys net a month and still complain about low wages. Our standard of living is very high. Life is certainly easier here than in the US. We enjoy a level of prosperity our forebears could never have dreamt of, but there will always be grumblers who complain about how bad things are here, and they have no idea how to make things better.
The Odra played the role of a ballistic computer in the downing of the F-117. The entire radar system was highly complex. It certainly wasn’t just a single radar. This is a technology that is only now beginning to be discussed publicly, based on the analysis of reflections and disturbances from ‘natural’ sources of radio waves. It is difficult even to call it a radar; it is rather a system of listening posts, analysing disturbances in the ‘natural’ level of radio radiation (at that time mainly originating from radio and television transmitters).
A different perspective on Polish computers, specifically the XYZ computer (later known as the ZAM2) and the group of people who developed the computer but wondered what it could be used for.
By the way, that was real science. These days, scientists are expected to work on ‘something practical’. I think that’s nonsense. Practical matters are for engineers, not scientists. That’s not what ‘doing science’ is all about. Great scientific theories usually didn’t find practical application during the lifetimes of the scientists who developed them.
What helped most in shooting down that F-117 at the time (though there was another damaged F-117 a few weeks later, which made it to the airfield and was presumably withdrawn from service – a fact that is less frequently mentioned) was the Americans’ disregard for the enemy.
In fact, the Americans did everything they could to help bring down that F-117. Firstly, their airbase in Italy was under constant surveillance by spies. Secondly, this F-117 was flying exactly the same route as the other F-117s for the fourth time that day, and the biggest blunder of all was that its jamming devices were switched off, because the Americans ‘reasoned’ that, since the Yugoslavs had old missiles, they wouldn’t be able to reach it at high altitude.
Flying at very low speed and without electronic protection, the F-117s were as easy to shoot down as ducks; it turns out that everyone knew this except the US Army commanders .
At very low speeds, the F-117, without electronic protection, could be shot down as easily as ducks; it turns out that everyone knew this except the US Army commanders .
The official position is that the operator activated the radar at the moment the bomb bay door opened, which caused an echo to be generated.
But one thing does not contradict the other. Stealth technology did not make the aircraft invisible to radar, but merely significantly reduced the distance from which radar could detect it.
As the ‘bears’ always flew the same route, the Yugoslavs did not have to search for them over a large area, but could concentrate on the corridor they consistently used.
Furthermore, as they had information about each take-off from the airfield, they could even ‘conserve energy’ and only switch on their radars when they knew the aircraft would be flying through a particular corridor.
With such information, there was no difficulty in tracking and shooting down a relatively slow-moving target such as the F-117.
It just amuses me that the Americans never thought to develop and follow appropriate procedures.
But then again, even the lesson from Pearl Harbour taught them nothing and did nothing to curb their ‘cowboy’ fantasies .
And the height of ‘intelligence’ was failing to destroy the wreckage, so that it fell into the hands of the Russians and the Chinese virtually undamaged, which led to the development of stealth technology in those countries.
During a conversation today, I was prompted to mention the tape storage devices used by the Odra computers. I completely omitted this from the text of the article, so it’s time to rectify that. It’s true that this is the subject I know least about, but I haven’t seen a description of tape storage systems appear on elektroda.pl yet. On Wikipedia, you can find a description of a Polish tape storage system PT-3 . There is a photo of the PT-3 there; at the top you can see two distinctive tape reels and two vertical rectangular columns below.
Source: Wikipedia, Polish PT-3 tape storage, by Merlin CC3.0
Upon examining the details of the Wikipedia entry, it turns out that the recording and reading were 9-track. This appears to be a similar approach to that used in punched tape, in this case with 8 bits of data and one bit for parity checking. Inside were pumps creating a vacuum... Thanks to this, the rectangular columns acted as a buffer for the tape, and rapid acceleration or deceleration of the tape did not cause the medium to break. The 750 metres of tape on the reel provided significant inertia at a feed speed of 3 m/s or a rewinding speed of 6 m/s. Recording on the tape was carried out using NRZI, which facilitated signal transmission through the signal path. The tapes had start and end markers, with 15.2 mm gaps between blocks. All this was necessary to send a data stream of 24,000 bytes/s or 96,000 bytes/s to the Odra. PT-3 power supply: 220/380 V, 50 Hz, power consumption 1.6 kW.
Let’s take a look at the print heads in the older PT-2 model:
Source: Wikipedia, heads of the Polish PT-2 tape storage system, by Topory CC4.0
The sight of the heads with their shielded cables is impressive; the design has a distinct Nagra feel to it Each head has its own designation: O (read), Z (write), K (erase).
I haven’t found any footage showing the PT-3 in operation, but I suspect the designers drew heavily on IBM products or, as with the wheel, it was invented independently in many places and at different times.
Here’s a different perspective on what was happening in the world in 1978 Horizon:
🤔 The film frequently mentions William Shockley but hardly anyone knows what his controversial views ⬇️
pavyan wrote:
...I remember that when ODRY units were being phased out and scrapped in the 1980s, for many years you could find as many as several adverts with similar content on the back page of the monthly magazine *Radioelektronik*, namely: “Wanted: LDB-1, 2, 3 connectors, any quantity; I’ll pay between $3 and $7 per piece.” And back then – I remember – in 1979, fresh out of school, I was earning about $16 at the black-market exchange rate
Questioning whether the 9th tape track was parity or sync
When we look into the details of the Wikipedia entry, it turns out that the recording and playback were 9-track. This appears to be a similar approach to that used in punched tape, in this case with 8 bits of data and one for parity checking.
Are you sure that the 9th track (which was actually physically located near the centre of the tape) was for parity, rather than providing a synchronisation signal or clock signal for each row of data?
I’m not entirely sure about the PT-3 – it’s true that an additional track could act as a clock for data readout. I find 8 bits per track and a 9th parity bit a bit more fitting, just like on punched tape. Generally speaking, I can see quite a few challenges with the design of the tape memory – it’s essentially a physical UART generator with start and stop bits, plus NZRI encoding on top of that. On top of that, there are the block spacing and, I believe, the set start markers. They’ve added a further complication in the form of 9 tracks. Aligning the heads and guiding the tape must have been a greater challenge than aligning the head in a Commodore 64 tape drive. On top of that, there’s the automation of the physical FIFO buffers in the form of vacuum columns with a tape reserve. Controlling the tape drive and maintaining negative pressure are complex issues.
@ElektrodaBot why were 9 recording tracks used in the Polish PT-3 and PT-2 tape storage systems? Is there any documentation or sources available that explain the reason for using 9 tracks? The PT-3 looks similar to the IBM 729 – might this help explain why 9 tracks were used?
I’m not entirely sure about the PT-3 – it’s true that an additional track could serve as a clock for data readout. I find 8 bits per track and a 9th parity bit a bit more fitting, just like on perforated tapes. ...
Direct reply
In the PT-2 and PT-3 9 tracks did not mean 8 data tracks plus a separate clock track . The most likely and best-documented explanation is the classic one for 1/2-inch tapes from that period:
- 8 data tracks , i.e. one character/byte per transverse row of the tape, - 1 parity track , i.e. vertical check/VRC, - plus a longitudinal check/LRC and, in PT-3 at higher densities, a cyclic redundancy check/CRC as well.
The Polish description of PT-3 explicitly refers to 9-track recording , the NRZI method, a density of 8 or 32 lines/mm , transmission rate 24,000 or 96,000 8-bit characters per second , and further on the odd-parity check of ones in the data rows , checking the parity of ones in the block track and cyclic redundancy check for a density of 32 tracks per millimetre. This strongly suggests the typical 9-track standard: track = 8-bit character + parity bit. ( historiainformatyki.pl )
Important correction: The IBM 729 was not a 9-track drive, but a 7-track drive . Mechanically, the PT-3 does indeed resemble classic IBM drives with vacuum columns, but as far as the 9-track format is concerned, a closer equivalent is rather the IBM 2400/2401 family, introduced with the IBM System/360, rather than the IBM 729. The IBM/S/360 9-track format had 8 data tracks and one parity track. ( en.wikipedia.org )
A detailed analysis of the problem
1. What ‘9 tracks’ meant in practice
The 1/2-inch magnetic tape was recorded in transverse ‘rows’. One row covered all the tracks simultaneously.
For 9-track recording, this can be illustrated with a simplified diagram:
Code: text
Log in, to see the code
In other words, a single ‘character’ on the tape was not transmitted serially as in UART, but was recorded in parallel across the width of the tape . Seriality occurred along the tape: successive rows followed one another in time as the tape moved.
The PT-3 documentation contains a reference to the transmission of 8-bit characters and of odd-parity checking of ones in the rows. This means that each row had to have the correct parity, and the ninth track was required precisely for this purpose. ( historiainformatyki.pl )
2. Was the ninth track a clock?
Not in the sense of a dedicated clock line.
In NRZI encoding, information is encoded by changes in magnetisation. In classical terms:
- the logical 1 causes a change in the direction of magnetisation, - a logical 0 does not cause a change.
The problem is obvious: if there are many zeros in the data, there is no magnetic flux for a prolonged period, so the read circuit has fewer reference points.
This is where the role of odd-even parity in a row comes into play. If each row is to have an odd number of ones, then even a row of data such as
00000000
will be assigned a parity bit equal to
1
. As a result, every row contains at least one ‘one’, and thus at least one magnetic transition. This makes it easier to reconstruct the rhythm of the rows during readback.
But this still does not mean that a single track served as a clock. More correctly:
> The parity track was not a separate clock, but thanks to odd parity, NRZI recording became, in practice, easier to synchronise, as each row contained at least one transition.
The ISO standard for 9-track NRZI tape describes the ‘change-on-ones’ method, i.e. changing the direction of magnetisation for a one, and specifies the bit P as the parity bit; the older version of ISO 1863:1976 states explicitly that the ‘P’ bit is the parity bit and that the row parity is odd. ( standards.iteh.ai )
3. Why was the parity bit ‘in the middle’ rather than at the edge?
This could have been misleading. With 9-track, one should not think ‘track nine = the ninth from the edge’. In a standard physical layout, the parity track could be positioned close to the centre of the tape. In the ISO 1863:1976 preview, the track assignment shows the track marked P as one of the inner tracks, not an outer one. ( standards.iteh.ai )
This had practical benefits:
- it reduced the impact of tape edge damage on the check bit, - it statistically improved the quality of parity checking, - it complied with an established interchange standard, so heads and formats were not designed arbitrarily.
Therefore, the statement “the ninth track was close to the centre” may be physically true, but functionally it was the parity track, not the clock track .
4. What does the Polish PT-3 documentation say?
A very good source is the “Guide for Odra Computer Users”, available on the History of Computing website. The description of the PT-3 states, amongst other things:
- the control unit could support up to 6 PT-3 units, - the PT-3 met the requirements of standards for information exchange on magnetic tape, - 9-track heads were used, - recording method: NRZI, - 9-track recording, - density: 8 or 32 lines/mm, - data rate: 24,000 or 96,000 8-bit characters per second, - nominal inter-block interval: 15 mm, - checking for odd-parity of ones in rows of data, - checking for even-parity of ones in the block track, - cyclic redundancy check of the recorded block for a density of 32 tracks per millimetre. ( historiainformatyki.pl )
This effectively settles the matter from a functional point of view. The document need not state that ‘the ninth track was used for parity’, as the description of the row and track checks makes this clear from a technical perspective.
5. VRC, LRC and CRC — three different checks
These drives did not have a single, simple error check. There were at least three levels:
Type of check
Direction
What was being checked
Meaning
VRC / row parity
across 9 tracks
does every row have the correct number of ones
detecting an error in a single character
LRC / longitudinal parity
along each track within the block
whether the number of ones in a given block path is correct
detection of an error propagating along the path
CRC
for a block, particularly at higher densities
more complex cyclic redundancy check
better detection of block errors
The Polish description of PT-3 mentions oddity checks in rows, parity checks within the block track, and cyclic redundancy checks. This corresponds to the classic logic: VRC + LRC + CRC . ( historiainformatyki.pl )
6. PT-2 and PT-3 versus the IBM 729
It is worth setting out the chronology here:
Device / standard
Number of tracks
Typical format direction
IBM 729
7
6 data bits + parity, BCD/BCDIC era
IBM 2400/2401 / System/360
9
8 data bits + parity
PT-2
9
Polish 1/2-inch drive, NRZI, 9 tracks
PT-3 / EC-5019
9
8-bit characters, NRZI, JS/RIAD/ISO-like exchange standard
The IBM 729 was therefore similar mechanically : reels, vacuum columns, heads, a large cabinet, 1/2-inch tape. But in terms of format, it was still part of the older 7-track world. Nine tracks are more associated with the IBM System/360 generation and the subsequent tape exchange standard. ( en.wikipedia.org )
7. Why did Polish drives switch to 9 tracks?
The main reasons were probably as follows.
a) Compliance with the data exchange standard
The PT-3 was designed to enable the exchange of tapes between computing centres. The Polish specification explicitly states that data recorded on the PT-3 can be read on another tape storage device that meets the same recording standards. ( historiainformatyki.pl )
This is a strong argument: the design was not just for a drive for a single machine, but for a medium that could be exchanged between systems.
b) 8-bit character
The PT-3 transmitted 8-bit characters . Nine tracks provide a natural layout:
Code: text
Log in, to see the code
For Odra 1300 computers, a machine word was 24 bits long, so three 8-bit characters made up one word. This does not necessarily mean that the entire architecture was ‘byte-based’ in today’s sense, but from the point of view of input/output channels and tape storage, this division was very convenient.
c) Error checking on mechanical media
Tape is a very challenging medium:
- dust, - dropouts in the magnetic layer, - tape skew, - uneven feed, - edge wear, - vibrations, - changes in tension, - dirt on the head.
An additional parity track provided hardware-based checking of every row at low cost. With discrete or TTL electronics, this was a major advantage: parity could be checked using simple XOR circuits and flip-flops, without the need for an expensive buffer or complex processing.
d) Compatibility with the IBM/S/360 and RIAD trends
The PT-3 had designation EC-5019 in the Unified EMC/RIAD System. Wikipedia states that the PT-3 was used with the Odra 1300 and RIAD, whilst the Polish description in the ‘Informator’ mentions compliance with the requirements for information exchange on tape. ( pl.wikipedia.org )
This fits well with the Comecon/Unified System policy, where the IBM System/360 family served as the interface and format standard.
8. Vacuum columns as a mechanical FIFO
Your comparison to a physical FIFO is very apt. The mechanism worked more or less like this:
Code: text
Log in, to see the code
The vacuum columns separated the dynamics of two worlds:
1. heavy reels — high inertia, slow adjustment, 2. the section of tape near the head — low mass, fast start/stop.
The PT-3 had a start/stop time of a few milliseconds, an operating speed of approximately 3 m/s and an inter-block gap of approximately 15 mm. At 3 m/s, the tape travels a distance of approximately:
Code: text
Log in, to see the code
This fits perfectly with the purpose of the inter-block gap: there had to be physical space to stop, accelerate and stabilise the read/write operation for the next block. PT-3 data specify an inter-block gap of 15 mm and a start/stop time of approximately 3.5–4 ms, depending on the source. ( historiainformatyki.pl )
Conclusion
The most technically correct answer is:
> The PT-2 and PT-3 used 9 tracks because they operated on the 1/2-inch tape standard, with one 8-bit character recorded across the tape and an additional parity track. The ninth track was not a separate clock signal. Synchronisation was facilitated by a combination of NRZI and odd-parity rows, as each row contained at least one ‘1’, and thus at least one magnetic transition.
One should, however, be careful when comparing it to the IBM 729: mechanically yes, conceptually a similar reel-to-reel drive with vacuum columns; but not in terms of format, as the IBM 729 was a 7-track system. For 9-track systems, a more appropriate reference is the IBM 2401/2400 and the System/360 tape standard.
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Are you sure that the 9th track (which was actually physically located near the centre of the tape) was the parity track, rather than the one providing the synchronisation and clock signal for each row of data?
It depends on what the question is about. For paper tape, there were indeed smaller holes used for synchronisation in the pattern: 3 data, synchronisation, 5 data. On magnetic tape, there was a parity byte, and at the end of each block there was also longitudinal parity for each track within the block. Perhaps they also calculated a CRC for the block afterwards, but I don’t recall that.
There were various recording densities: 800/1600/3200 bytes (lines) per inch. I haven’t worked with the PT2, but the photo of the heads might suggest similarities with the IBM design shown in the film.
The PT3 and PT3M had a different design; they had three DC motors, two of which drove the tape reels and the third the drive roller. The roller was in the centre, at the top between the vacuum chambers, and the head was at the start of one of the chambers, directly beneath the roller.
Describing the tape chambers as ‘vacuum’ is a slight exaggeration, as the level of negative pressure is more akin to that of a vacuum cleaner.
The main aim is to maintain tension on the tape at the head, but with a small amount of tape having low inertia relative to the inertia of the entire spool. It’s important to remember that, over the length of the inter-block gap, the tape must come to a halt and then accelerate to/from its operating speed, i.e. around 3 m/s.
You can certainly find videos of the PT3 in operation from the front, even from 2007 – do let me know – but I haven’t seen any showing the inside.
There was also the even smaller PT 105 memory unit for the Mera 300 and 400. It had lower speeds, but the data format was compatible because data entry stations were built for this purpose, and the tapes were then transported for processing on the ‘large’ machine.
Perhaps I should add that I didn’t work on the Odra, but on a Mera 9150 – that is, a licensed Seecheck-O 1200 (for seven years, from ’85 to ’92) – where the tape standard was the same, as those tapes were read and processed on the Odra.
The centre track – track 5 – was the parity bit, and the ‘tape recorder’ was calibrated against it using a special reference tape.
This had to be done on average once a quarter, or more frequently if the rewind mechanism was ‘flapping’ the tape around a lot. In the read circuit, there was an operational amplifier acting as a differentiator and detecting a ‘0’ transition, which triggered a 74121 monostable multivibrator that wrote the state to a 74 D flip-flop. The delay of the write operation was adjusted relative to this central track using potentiometers, so that all tracks would write at roughly the same time. Due to tape ripple, it was never perfectly synchronised, but there could be a slight discrepancy – I can’t remember exactly how much now.
The motors driving the tape – that is, the feed roller – were interesting; due to inertia, it was driven directly. In my rewinder, the motor was still fairly standard: a DC motor with a fairly large commutator but a small-diameter rotor, the start/stop times were in the region of 10–12 ms, as we’d measured them. The one from Odra was more interesting because, due to the speed required, the motor didn’t have an iron rotor; but was instead a disc made of compressed, bonded fibreglass onto which windings in the form of flat bars were clamped, along with a face-contact commutator – that is, the brushes pressed it against the disc, meaning the windings and the commutator formed a single plane slightly smaller than a CD. They achieved a start/stop time of around 3 ms.
Added after 16 [minutes]:
I found a video featuring Mera https://www.facebook.com/watch/?v=391604088081227 You can see the input monitors, printers, and the boxes next to the printers are disk drives You can also see the reel changer in operation.
That large box slightly protruding from beneath the rewinder is the actual computer with its memory and peripheral boards; its power supply was at the back.
Horizon:
