Svenska ElektronikForumet

I slutet på förra året fick jag ett erbjudande om en ASR-33 Teletype av en forummedlem "Rauken" på Gotland. Det var ju snällt men hur får man en teletype från Gotland? Bussgods verkar inte existera på ön och annan frakt går ju inte att lösa av stora och tunga saker.

Men så bar det sig så att jag och familjen hamnade på Gotland nu på semestern och i går hämtade jag den! Har inte mer än snabbt tittat på den med den verkar vara i mycket bra skick. Stativet finns men stället för lösblad som man sätter över pappersrullen saknas tyvärr. "Start"-knappen verkar vara ett eftermontage. Den har gått tillsammans med någon tidigt PDP-11 som styrt en komponentisättningsmaskin av märket "Universal" på Ericsson i Visby (nu mer nerlagt). Den fungerade sist den kördes någon gång 80-talet. Tack Rauken!

När man körde den med PDP-8 (vet inte hur de är med PDP-11, det ska undersökas) så modifierades teletypen så att man fjärrstyra starten av remsläsaren från PDP:n. Denna modifikation finns dokumenterad och ska göras om den redan inte är gjord. PDP-8:ans teletype interface har en solenoid utgång för ändamålet.

den ser ju ut att vara i finfint skick! gratulerar.

Tack,

Nu har jag putsat upp den och den ser fantastisk ut! Inga bilder på den, men ett bevis på att den fungerar! Jag har även provat att läsa tillbaks remsan och det fungerar. Det är så sjukt HÄFTIGT! Nu ska jag bara få den att interface:a PC:n via det seriella interfacet.



Den skarpögde ser att jag lagt remsan spegelvänt i scannern! Lite ovant att man måste trycka en tangent för return och en för linefeed för att hamna i början på en ny rad. De som programmerat för Unix/Linux vet ju att det är så fortfarande när man skriver ut strängar. Man måste skriva ut tecknet både för linefeed och return...

Man kan ju också minnas varifrån förkortningen TTY kommer ifrån.

Det där med att trycka på CR och LF gäller ju i princip bara vid stand-alone
körning som du gör just nu. De system man körde mot var oftast skriva så
att varje utskrift/rad började med en LF. Varje inmatning/kommando avslutas
med en CR. Vagnen stog alltså kvar först på samma rad till kommandot
hade genererat något, då valsen matades fram och resultatet skrevs.

NC-systemen, som jag använder, är gjora så att tecknet "delete" ignoreras av systemet.
Tack vare det kan man, om man har stansat fel, backa ett steg och stansa "delete".
"delete"-tecknet är 8 hål, så det spelar ingen roll vad som är stansat tidigare.

Har även datorer denna funktion?

Ja, tecknet kan ju alla datorer använda/generera i alla fall.
Frågan är hur det tolkas/används...
Det kallades även "rubout" på Teletype'erna, förresten...

Kollade just http://en.wikipedia.org/wiki/ASCII. En fantastiskt
mängd teknikhistoria där ! Bör läsas av av alla med det minsta intresse
av dator. Kan ge en ny bild av varför saker och ting är som de är...

T.ex placerades de viktigaste kontrolltecknen för datakommunikation (då)
så att de fick maximal "Hamming distance"...
http://en.wikipedia.org/wiki/Hamming_distance

Kul att den fungerade. Det var som sagt länge sedan den användes.

//Lasse

Jag var och jobbade en hel del på Ericsson/Flextronics i Visby i slutet
av 90- och början av 00-talet (på IT-avdelningen). Möjligt att vi har
träffats om du också var där då...

Många äldre NC-system kan inte läsa remsor med ASCII-stansade hål.
De använder EIA RS-244.

Undrar om en ASR-33 är omkopplingsbar till EIA RS-244?
Jag provade faktiskt aldrig på min.

Jo du Sojdan, sen 1974

/Lasse

Nåja, nu har jag ställt ASR-33:an åt sidan och kollat lite på PDP:n igen. Får fixa lite bilder på den sen. Men nu till kvällens gärning.

Jag har mätt på "Manual timing function", dvs de pulser som genereras när man inte har maskinen i RUN men vill starta, göra DEPOSIT/EXAMIN eller SINGLE STEP. Det hela var lite intressant...

Först bilden ur DEC's förträffliga dokumentation:


Sedan verkligheten:


Man ser snabbt att MTFS3 aldrig går hög där den ska! Eftersom dessa pulser styr en massa saker så måste detta fixas först av allt! Sen kan jag ju tycka att MTFS pulserna är snarare 1,5us än de 2us som dokumentationen säger. Får läsa lite i texten om man kan hitta något om noggrannheten på pulsernas längd.

MTFS3 genereras utav MTFS0,1,2 med bara två grindar så det felet ska väl snart vara hittat!

EDIT: MTFS3=MTFS0 & !MTFS1 & !MTFS2

Ikväll mätte jag MTFS0, !MTFS1 och !MTFS2 på kretsen som gör MTFS3 av dem. Inte ett liv...

Försökte ohm:a mellan kortet där signalerna skapas och NAND kretsen där de ska skapa MTFS3, inte en antydning till kontakt. Utgången på NAND grinden kunde jag ohm:a frammåt till nästa kort, så lite rätt var det. Frågan är nog om jag bara är trött eller om det är så illa som det verkar (bakplanet). Ska kolla var dessa signalerna finns mer någonstans och mäta dem...

anders_bzn skrev:Den skarpögde ser att jag lagt remsan spegelvänt i scannern! Lite ovant att man måste trycka en tangent för return och en för linefeed för att hamna i början på en ny rad. De som programmerat för Unix/Linux vet ju att det är så fortfarande när man skriver ut strängar. Man måste skriva ut tecknet både för linefeed och return...

Det är väl i MS-DOS & co man måste skriva ut både CR+LF? I Unixvärlden så tar väl termcap å sånt hand om att göra om LF till CR/LF vid behov, d.v.s. från användarprogram så behöver man bara skriva ut LF? (Om jag inte minns galet så var det enbart CR som gällde på nån arkitektur, minns dock inte vilken, kanske något gammalt från Apple?).


Förresten, vad var ANF-10 för typ av nätverk?

Förekom det någon slags intelligent protokoll ovanpå seriesnörena för att mux'a flera användare, eller var det en användare per seriesnöre som gällde?

Ja, så är det. I DOS har man både CR&LF.

Var ANF-10 är vet jag inte men det finns kanske någon annan här som vet?

Angående CR, LF och/eller CR/LF så gäller det att hålla
reda på vad det är man talar om.

Filformat.
----------
Unix standard är "stream-LF". D.v.s att records (eller "rader" om filen innehåller
vanlig text) är avgränsad/terminerad med ett enda LF tecken. För övrigt är
data enbart ett rakt flöde ("stream") av bytes.
I andra OS som t.ex DOS/Windows är CR/LF standard.
I ytterligare andra OS som t.ex OpenVMS är det valbart. T.ex OpenVMS har
7 olika "record format" :

FIXED Specifies fixed-length records.

STREAM Specifies that the records are STREAM records; the record is viewed
as a continuous stream of bytes, delimited by a special character.
This format is compatible with RMS–11 stream files. This is valid for
sequential files only.

STREAM_CR Specifies that the records are STREAM records; the record is viewed
as a continuous stream of bytes, delimited by a CR character. This is
valid for sequential files only.

STREAM_LF Specifies that the records are STREAM records; the record is viewed
as a continuous stream of bytes, delimited by an LF character. This
is valid for sequential files only.

UNDEFINED Specifies undefined record format, which means that the record is a
continuous stream of bytes with no specific terminator. This keyword
is valid for sequential files only.

VARIABLE Specifies variable-length records. This is the default setting.

VFC Specifies variable-length records with fixed-length control fields
(VFC). This is valid for sequential and relative files.

Notera att Unix standardformat är ett av de giltiga formaten (STREAM_LF).

Filsystemet har sedan så klart "kunskap" om dessa format och gör eventuella
konverteringar vid t.ex öppning med en vanlig text-editor eller liknande. Detta
är alltså ett attribut i file-headern och måste/bör så klart stämma överens
med själva innehållet i filen.

Terminaldrivers:
------------------
Oavsett hur filen ser ut och hur den är kodad så får terminaldrivern se till att
det som skrivs ut passar den "terminal" man använder. En vanlig VT/ANSI
baserad terminal använder CR efter en rad och LF innan en ny rad. T.ex
på Unix så får drivern lägga till CR där det behövs. På OpenVMS så fixar
terminaldrivern till det beroende på filens "record attribute". Om filen redan
har både CR och LF lagrade i filen (t.ex DOS) så behövs inget läggas till.

Sen så kan det bli diverse olika problem med olika verktyg som inte
fixat att tolka de olika formaten. T.ex Notepad och stream-LF i Windows.
Wordpad (Write) fixar dock att visa även en stream-LF fil korrekt.
Problemet är lite att tolkningen måste göras genom en analys av själva
datat, så vitt jag vet så har DOS inte detta registrerat i fil headern. Unix
är jag osäker på, men jag har för mig att det inte finns så många fil attribut.

> De som programmerat för Unix/Linux vet ju att det är så fortfarande när man
> skriver ut strängar. Man måste skriva ut tecknet både för linefeed och return...

Gör man ? Använder man inte bara "\n" (LF) och sedan fixar systemet resten ?