Archive for the ‘Teknik’ Category

AI datorarkeologi 2026

05/04/2026

I den föregående artikeln jämförde jag en CP/M baserad dator från tidsperioden 1975-85, dock emulerad, med dagens datorer. Min konklusion var att våra nuvarande datorer i alla relevanta avseenden är från tusen till några miljoner gånger kraftfullare än gårdagens CP/M maskin som trots dess begränsningar var ett fint hjälpmedel för många småföretag.

En CP/M maskinen erbjöd t.ex. en textbehandlare för brev vilket var himmelriket jämfört med att skriva ett helt brev felfritt på en mekanisk skrivmaskin. Mot slutet av CP/M epoken fanns det redan fullständigt användbara textbehandlare t.ex. Wordstar. CP/M maskinen erbjöd också program där mitt brev automatiskt kunde omformas för olika mottagare (mail merge) vilket igen sparade mycket tid igen i förhållande till manuellt arbete där varje brev, helst felfritt, skulle skrivas ut på skrivmaskin. Det fanns primitiva databaser och program för att hantera fakturering. Maskinen var primitiv men den var användbar.

Min jämförelse av CP/M maskinen och en modern PC gjordes på min bordsdator så att jag installerade emulatorn RunCPM under Linux. Då jag lekte med emulatorn märkte jag att det skulle ha varit trevligt att inifrån CP/M kunna skriva ut text på min skrivare samt naturligtvis också kunna lagra data på klassiskt sätt genom att stansa ut en hålremsa. En stansapparat är idag svår att komma över och de är förvånande dyra, vi talar ofta om kanske en tusenlapp. Om jag kan skapa hålremsan så behöver jag naturligtvis också ett program för att läsa av en hålremsa och återskapa data. Det kunde också vara trevligt att kunna lagra data och program på magnetband på ett möjligast tidstypiskt sätt. På samma sätt som för hålremsstansen så behöver jag naturligtvis också en läsare för magnetband.

Jag beslöt att lösa problemet med hjälp av några enkla program skrivna i programmeringsspråket Python. Dessa program körs under Linux parallellt med den emulerade CP/M maskinen. Notera att en modern PC har 4-8 processorkärnor, ibland mer, vilket betyder att den fullständigt problemfritt kan emulera min CP/M maskin utan att det märkbart påverkar Linuxens, d.v.s. PC:ns kapacitet.

Hålremsa

Det första steget för att ge min CP/M emulator tillgång till en hålremsstans och motsvarande läsare är att skriva två relativt enkla python program som tar en datafil d.v.s. en serie Bytes som i princip är godtyckliga tecken som passar in i en 8-bitars Byte. Totalt finns det max 256 tecken i en åtta bitars datastruktur.

Det slog mig att jag kunde använda detta projekt till att testa hur väl AI kunde hjälp mig med programmeringen och vilken form detta kunde ta. Min diskussion med AI är alltså den ”programmering” jag gjorde. Jag använde en gratisversion av chatGPT som medhjälpare. Texten nedan visar diskussionen med AI och resultatet. Efter varje programförslag korrigerade jag AI och bad om förbättringar. Jag använde engelska under diskussionen men jag gissar att det skulle ha fungerat lika bra på svenska.

Steg 1 jag beskriver grunddesignen för AI:

(Lars) I want to encode a string of 8 bit bytes into a png image as a column of bits. Every bit consists of 10×10 pixels. A high bit is white and a low bit is black. A maximum of 128 bytes are coded into a column. When a column is full a new column is generated to the right of the previous column. Columns are separated by a double bit wide grey separator line. The number of columns in the image is not restricted. The bytes to be encoded are read from a text file given on the command line. The resulting image file is called tape.png .

(ChatGPT) This is a neat “visual tape” encoding idea. The requirements are clear enough to implement directly. Below is a complete Python script using Pillow that does exactly what you described.

Resultatet var ett körbart pythonprogram som kodade data som strimmor vertikalt ner över skärmen. I princip användbart men motsvarar inte en gammal hålremsa. Det är lätt att be om en korrektion. Tanken är att generera en bild jag kan skriva ut på skrivare och om jag så vill läsa in med hjälp av skrivarens scanner för att sedan avkoda. Stansning/avkodning görs alltså modernt via en bild av typen png d.v.s. utan fysisk stansning. Resultatet kan dock skrivas ut och mappas in i en fysisk mapp om jag vill i likhet med forntidens hålremsa som förvarades i en ask.

(Lars) Generate columns of 128 bytes in a manner of a punched paper tape. When 128 bytes has filled a column new columns are generated to the right of the previous filled column.

(ChatGPT) What you’re describing is essentially a visual punched paper tape, where each column is like a vertical slice of tape holding 128 bytes (rows), and each byte is represented by 8 holes (bits).Let me tighten and clarify the structure and give you a clean implementation that matches that mental model exactly.

För att göra hålremsan lättare att läsa för en människa separerar jag varje kodad byte med en vit rad. Vi kunde klippa ut vertikala strimmor ur den utskrivna bilden och limma ihop dem till en hålremsa som vi kunde läsa av utan större problem på optisk väg. Någon hålstansning begövs inte för en modern läsare. En svart ruta med storleken 10×10 pixlar betyder att ifrågavarande bit=0 d.v.s. låg nivå. På motsvarande sätt betyder en vit ruta att platsen ”har stansats” d.v.s. bit=1 hög nivå. Svart/vit ruta förstås så att vi i en riktig pappersremsa har en lampa på baksidan av remsan som belyser sensorer som belyser sensorer på andra sidan. Ett stansat hål ses som ljust.

(Lars) Separate bytes with white line between rows of bits.

(ChatGPT) Got it — you want the tape to be more readable by clearly separating each byte (row) with a horizontal white line.

Slutresultatet blev ett kodningsprogram som jag kunde köra från kommandoraden under Linux:

python3 encoder3.py encoder3.py

Det första kommandot python3 anger att jag vill använda python3 som tolk, det finns flera generationer av python i bruk därav python3. Jag kan enkelt modifiera programmet så att det kan köras utan explicit python3. Jag ber programmet koda sig självt och resultatet blir en bildfil tape.png . Bildfilen har följande utseende:

Bilden innehåller alltså hela texten till programmet som kodar bilden. Hålremsan skall läsas uppifrån till vänster en kolumn i taget. Det finns inga inbyggda begränsningar för hur många kolumner det får finnas i bilden. Utskrivet på en A4 sida ryms ca. 3000 tecken d.v.s. ett typisk litet program skrivet t.ex. i Pascal eller C. Jag har inte editerat en enda rad i den genererade koden, allt är skapat av chatGPT enligt mina instruktioner.

Det genererade programmet har följande utseende utan en enda editering från min sida:

import sys
from PIL import Image

# Geometry
BIT_SIZE = 10
BITS_PER_BYTE = 8
BYTES_PER_COLUMN = 128
SEPARATOR_WIDTH_BITS = 2
ROW_SEPARATOR_BITS = 1 # NEW

# Colors
WHITE = (255, 255, 255)
BLACK = (0, 0, 0)
GRAY = (128, 128, 128)


def byte_to_bits(byte):
return [(byte >> (7 - i)) & 1 for i in range(8)]


def main():
if len(sys.argv) < 2:
print("Usage: python tape.py input.bin")
return

with open(sys.argv[1], "rb") as f:
data = f.read()

# Split into columns
columns = [
data[i:i + BYTES_PER_COLUMN]
for i in range(0, len(data), BYTES_PER_COLUMN)
]

num_columns = len(columns)

# Height in bits (bytes + separators)
height_bits = (
BYTES_PER_COLUMN +
(BYTES_PER_COLUMN - 1) * ROW_SEPARATOR_BITS
)

# Width in bits
width_bits = (
num_columns * BITS_PER_BYTE +
(num_columns - 1) * SEPARATOR_WIDTH_BITS
)

# Convert to pixels
width_px = width_bits * BIT_SIZE
height_px = height_bits * BIT_SIZE

img = Image.new("RGB", (width_px, height_px), BLACK)
pixels = img.load()

current_x_bit = 0

for col_idx, column in enumerate(columns):
y_bit = 0

for row_idx, byte in enumerate(column):
bits = byte_to_bits(byte)

# Draw byte row
for bit_idx, bit in enumerate(bits):
color = WHITE if bit else BLACK

x_bit = current_x_bit + bit_idx

for dx in range(BIT_SIZE):
for dy in range(BIT_SIZE):
x = x_bit * BIT_SIZE + dx
y = y_bit * BIT_SIZE + dy
pixels[x, y] = color

y_bit += 1

# Draw horizontal separator (except after last byte)
if row_idx < len(column) - 1:
for x_bit in range(current_x_bit, current_x_bit + BITS_PER_BYTE):
for dx in range(BIT_SIZE):
for dy in range(BIT_SIZE):
x = x_bit * BIT_SIZE + dx
y = y_bit * BIT_SIZE + dy
pixels[x, y] = WHITE

y_bit += ROW_SEPARATOR_BITS

current_x_bit += BITS_PER_BYTE

# Draw vertical separator between columns
if col_idx < num_columns - 1:
for sep in range(SEPARATOR_WIDTH_BITS):
for yb in range(height_bits):
for dx in range(BIT_SIZE):
for dy in range(BIT_SIZE):
x = (current_x_bit + sep) * BIT_SIZE + dx
y = yb * BIT_SIZE + dy
pixels[x, y] = GRAY

current_x_bit += SEPARATOR_WIDTH_BITS

img.save("tape.png")
print("Saved tape.png")


if __name__ == "__main__":
main()

Följande steg är naturligtvis att låta chatGPT göra motsatsen d.v.s. skriva ett pythonprogram som läser en hålremsa lagrad som en bildfil och återskapar den kodade informationen.

(Lars) Now generate a decoder for the last version. It takes a png-file as input and produces a text file RDTAPE.txt containing the decoded bytes.

(ChatGPT) Great — now we’ll reverse the exact format you just defined.

This decoder will:

Read tape.png

Detect bits based on pixel blocks (10×10)

Skip:

horizontal white row separators

vertical gray column separators

Reconstruct bytes

Write them to RDTAPE.txt (binary-safe)

Resultatet blev ett fungerande avkodningsprogram som korrekt återskapade det kodade programmet i bildfilen tape.png.

import sys
from PIL import Image

# Geometry (must match encoder!)
BIT_SIZE = 10
BITS_PER_BYTE = 8
BYTES_PER_COLUMN = 128
ROW_SEPARATOR_BITS = 1
SEPARATOR_WIDTH_BITS = 2

WHITE = (255, 255, 255)
BLACK = (0, 0, 0)
GRAY = (128, 128, 128)


def is_white(pixel):
return pixel[0] > 200 and pixel[1] > 200 and pixel[2] > 200


def is_black(pixel):
return pixel[0] < 50 and pixel[1] < 50 and pixel[2] < 50


def is_gray(pixel):
return abs(pixel[0] - 128) < 40 and abs(pixel[1] - 128) < 40 and abs(pixel[2] - 128) < 40


def read_bit_block(pixels, x_bit, y_bit):
"""Sample center of a bit block"""
x = x_bit * BIT_SIZE + BIT_SIZE // 2
y = y_bit * BIT_SIZE + BIT_SIZE // 2
pixel = pixels[x, y]

if is_white(pixel):
return 1
else:
return 0


def is_separator_column(pixels, x_bit, height_bits):
"""Detect gray separator column"""
count_gray = 0
for yb in range(height_bits):
x = x_bit * BIT_SIZE + BIT_SIZE // 2
y = yb * BIT_SIZE + BIT_SIZE // 2
if is_gray(pixels[x, y]):
count_gray += 1

return count_gray > height_bits * 0.8


def main():
if len(sys.argv) < 2:
print("Usage: python decode.py tape.png")
return

img = Image.open(sys.argv[1])
pixels = img.load()

width_px, height_px = img.size

width_bits = width_px // BIT_SIZE
height_bits = height_px // BIT_SIZE

x_bit = 0
decoded_bytes = []

while x_bit < width_bits:
# Skip gray separator columns
if is_separator_column(pixels, x_bit, height_bits):
x_bit += 1
continue

# Read one data column (8 bits wide)
column_bytes = []

y_bit = 0
row_count = 0

while y_bit < height_bits and row_count < BYTES_PER_COLUMN:
bits = []

# Read 8 bits across
for bit_idx in range(BITS_PER_BYTE):
bits.append(read_bit_block(pixels, x_bit + bit_idx, y_bit))

# Convert to byte
value = 0
for b in bits:
value = (value << 1) | b

column_bytes.append(value)

row_count += 1
y_bit += 1

# Skip white separator row
if row_count < BYTES_PER_COLUMN:
y_bit += ROW_SEPARATOR_BITS

decoded_bytes.extend(column_bytes)

x_bit += BITS_PER_BYTE

# Write output
with open("RDTAPE.txt", "wb") as f:
f.write(bytes(decoded_bytes))

print("Decoded to RDTAPE.txt")


if __name__ == "__main__":
main()

Konklusion

Vi kan ser hur arbetsprocessen då jag använder AI för programmering förändras radikalt. Jag behöver inte längre i detalj kunna programmeringsaspråkets syntax och semantik. Jag försöker endast förklara för AI, så väl jag kan, exakt vad jag vill ha på en hög nivå i form av naturligt språk. Det är självklart att jag fortfarande måste känna problemkontexten. Jag måste ha en mental bild av hur data är kodat i Byte, Bit samt veta hur forntidens hålremsa i princip såg ut. Jag behöver däremot inte i detalj veta hur problemet skall splittras up i form av datastrukturer och funktioner för att skapa ett fungerande program, detta görs av AI.

Min uppfattning är att AI är ett verktyg som motsvarar övergången från handverktyg till långt automatiserade verkstäder. Det krävs mycket kunnande för att styra AI men kunskapen som behövs ligger på en betydligt högre abstraktionsnivå.

Jag kör den nya programkod AI ger vid varje iteration och försöker förklara för AI vad jag vill korrigera. Jag uppfattar arbetsprocessen som den jag körde med i forntiden då jag sålde egna industri mätsystem till kund. Det gällde då att själv vara i samma situation som chatGPT d.v.s. försöka förstå vad kunden egentligen försökte köpa. Då jag visste vad problemet var i detalj var inte implementationen något väldigt stort problem.

Fortsättning

Min tanke är att skapa automatik där jag använder Linux på huvuddatorn till att hantera utskrift till ”hålremsestansen”. På motsvarande sätt vill jag enkelt komma åt lagrade program och filer i mitt virtuella ”bibliotek” bestående av lagrade hålremsor. I forntiden skulle jag ha varit tvungen att gå till ett skåp och söka fram rätt hålremsa och hoppas att den var korrekt märkt, lägga in hålremsan i läsaren samt starta avläsningen. I mitt system bygger jag upp det så att jag kan be hålremsläsaren hämta rätt hålremsa och läsa av den. Mitt system motsvarar inte helt det som användes i forntiden men det är relativ nära. Jag behöver inte stiga upp ur stolen för att hämta rätt hålremsa. Jag har inte heller implementerat läsning via CP/M BIOS-anrop d.v.s. min arbetsprocess kommere att skilja sig från motsvarande process i forntiden.

Min plan är att förutom en stans för hålremsor också skapa ett enkelt sätt att inifrån CP/M skriva ut textfiler till Linux skrivare. Även här tänker jag fuska i viss mån dock så att systemet ungefär fungerar som i forntiden.

Om energi och intresse räcker till kan det hända att jag också skapar system för att lagra CP/M program och data till filer på magnetband. Jag använder i såfall linuxens ljudsystem för att skapa ljudfiler som kan läsas och återskapas till program eller data.

Mera om implementation och AI-hjälp i nästa artikel.

Datorarkeologi 2026

02/04/2026

Jag har lekt med en Clockwork PicoCalc som man kan köpa som en enkel byggsats. PicoCalc är egentligen ett tangentbord och en skärm med 320×320 pixlar d.v.s. en skärm som motsvarar en typisk hemdator från 1980-talets början t.ex. en Commodore 64. Byggsatsen görs till en fungerande dator genom att lägga till något av processorkorten Rasapberry Pi Pico, Pico2 eller Pico W. Hobbyister har också kört andra processorer och lyckats köra Linux utan större problem. Användning av andra processorer än Pico kräver dock i allmänhet att man hackar hårdvaran d.v.s. löder om själva PicoCalc. Jag tycker av princip illa om att gå in och löda i fungerande hårdvara vilket är orsaken till att jag kör en normal PicoCalc och inte Linux.

Bilden visar att Turbo pascal d.v.s. turbo har startat och programmet frågar efter den fil vi vill editera och kompilera. I vårt fall TEST.PAS. Vi ser en CP/M mikroskärm med radlängden 40 tecken. En speciell font har skapats för att få möjligast mycket text att rymmas på en rad.

PicoCalc ser ut som en normalstor kalkylator från 1980-talet i vilken man kan programmera och köra Basic, Python och Lua. Under Basic och Python fungerar den förvånande bra som en programmerbar kalkylator. Det visade sig snabbt att processorn är tillräckligt snabb och det finns tillräckligt minne för att köra operativsystemet CP/M som var dominerande från mitten av 1970-talet till mitten av 1980-talet. CP/M trängdes ut av IBM:s PC kring mitten av 1980-talet. IBM PC körde ett mycket liknande operativsystemsom CP/M kallat Ms-DOS.

https://en.wikipedia.org/wiki/IBM_Personal_Computer

https://en.wikipedia.org/wiki/CP/M

ARM processorn i en RPi Pico klarar av att emulera en Intel 8080 eller en Zilog Z80 i realtid. Pico:ns lilla minne räcker till för att ge CP/M ett fullt arbetsminne trots att en stor del av Pico kapaciteten går åt till att emulera en främmande processor.

Storleken på en Raspberry Pi Pico är ungefär två normalstora frimärken i bredd. Bildens Pico har storleken 20×50 mm.

Ett mycket vanligt programmeringsspråk på 1980-talet både under CP/M och PC-DOS var Turbo Pascal som erbjöd en enligt dåtida mått mycket trevlig programmeringsomgivning för programspråket Pascal. Pascal är ett i många avseenden mycket klarare och ”renare” programspråk än t.ex. programspråket C som användes då Unix och senare Linux skapades. Med hjälp av Turbo Pascal kunde man i akademiska sammanhang enkelt t.ex. göra statistiska analyser på en liten bordsmaskin, analyser som tidigare krävde tillgång till en stordator med all den byrokrati och kostnad detta medförde. Med hjälp av Turbo Pascal kunde man också med hjälp av diverse instickskort använda en PC för förvånande avancerade automatiska mätningar. Turbo Pascal fanns tillgängligt både för CP/M baserade datorer och för Ms-DOS maskiner d.v.s. IBM-PC samt mängder av liknande kloner.

Att köra program i 64 kilo Byte minne

Dagens datorer t.ex. en PC tenderar att ha ett centralminne på 4-32 GigaByte ibland mera. Min personliga PC som kör Linux har 32 GigaByte minne som är 500 000 gånger större än än det totala minnet i forntidens CP/M dator.

Jag kompilerade på skoj ett program TEST.PAS som ger ett nytt kommando till CP/M systemet som enligt Unix tradition kallas cat d.v.s. catenate eller skriv ut/kombinera ihop. Programmet kan läsa en eller flera textfiler och skriva ut dem till skärmen eller skicka resultatet till en annan fil. Under Linux skulle jag kunna skicka filen utan förändringar till t.ex. LPR dvs skriva ut till skrivare allt det som annars skulle gå till skärmen. Jag antar att jag inte kommer riktigt så enkelt undan under CP/M. Länken nedan diskuterar hur man kommer åt en skrivare, stans för hålremsa etc. under CP/M.

https://www.mark-ogden.uk/mirrors/www.cirsovius.de/CPM/Projekte/Artikel/Grundlagen/IOByte/IOByte-de.html

Då jag kompilerar programmet under Turbo Pascal under CP/M på PicoCalc får jag ett körbart program med storleken 635 bytes vilket motsvarar en vanlig text utskriven med 80 tecken par rad som då blir ungefär åtta rader lång. Jag testade programmet under CP/M så att jag använde det kompilerade programmet till att lista ut sig själv på PicoCalc skärmen. Texten är väldigt liten och ganska svårläst men programmet fungerade OK.

En intressant fråga blir då: Om jag tar samma program och kompilerar det under Linux (eller Windows eller Mac) hur stort blir då programmet på en modern dator? Notera att jag kompilerar för användning på kommandoraden helt utan GUI (grafiskt användargränssnitt). Om jag skulle skapa ett GUI för programmet gissar jag att det skulle växa ytterligare med kanske en faktor tio.

För kompileringen under Linux använde jag fpc d.v.s. Free Pascal Compiler som är basen i bl.a. Lazarus som idag är en trevlig omgivning för att generera program med grafiskt användargränssnitt GUI. Lazarus är mycket nära besläktad med Delphi (tidigare Borland Delphi). Lazarus är trevligt eftersom program enkelt kan skrivas för Linux, Windows, Mac, Android och FreeBSD och det finns funktionalitet som i hög grad förenklar designen av ett program med GUI. Fpc är således funktionsmässigt nära släkt med Borlands Pascal d.v.s. Turbo Pascal.

Jag kompilerade om programmet TEST.PAS under fpc med:

fpc -gl TEST.PAS

Kompileringen gick igenom utan problem men jag putsade bort en del onödiga fyllnadstecken i slutet av filen, tecken som i sig inte störde kompileringen. Då jag körde programmet:

./TEST TEST.PAS

Skrevs texten till TEST.PAS ut korrekt men jag fick ett felmeddelande på den nästsista raden (se programlistningen nedan) där programmet försöker stänga filen wrf d.v.s. en fil som används om man skulle vilja att resultatet går till en annan fil och inte på skärmen. Om jag skriver till skärmen behövs inte wrf och om jag försöker stänga wrf som aldrig har öppnats uppstår det ett fel. Felet är enkelt att åtgärda genom att kontrollera om vi har alternativet redirect innan vi försöker stänga filen. Längden på det körbara programmet blev nu under 64-bitars linux med kompilatorswitchen -gl som jag använde för att komma åt vilken rad i programmet som gav felet 420968 Byte d.v.s. ungefär 663 gånger större än under CP/M.

Om jag kompilerar om programmet efter rättning utan flaggan -gl blir resultatet 188304 Byte d.v.s. ungeför 297 ggr större än under CP/M.

Vad beror storleksskillnaderna på? En självklar orsak är naturligtvis att datorns s.k. ordlängd d.v.s. hur lång en typisk instruktion är har vuxit från 8-bitar till 64-bitar. Om vi antar att vårt program fortfarande behöver ungefär samma maskinspråksinstruktioner så kan vi få en vettigare jämförelse genom att dividera Linux-varianten med åtta d.v.s. ungefär 23538 instruktioner vilket är 37 ggr större än antalet instruktioner i CP/M varianten. Jag gissar att man genom väl genomtänkta optimeringar vid kompileringen kan krympa Linuxvarianten ytterligare. En stor orsak till att programmet har blivit större är antagligen kontroll av olika fel d.v.s. debuggning som utvecklats mycket under åren. De bibliotek vi länkar mot under Linux har bättre funktionalitet men de har också vuxit betydligt och innehåller sannolikt kod vi inte behöver. Vid kompileringen kan vi ange olika nivåer av optimering som påverkar snabbhet , minnesåtgång samt stöd för olika typer av felsökning. Körning av programmet ger:

./TEST TEST.PAS
ParamCnt=1/home/lasi/Prog/Pascal/TEST
Testing for file redirection
Got last par=TEST.PAS
TEST.PAS
program cat(input,output);
(* Make a new CP/M command cat
cat xxx yyy zzz … List all files to screen
cat xxx yyy >zzz List files xxx, yyy to the file zzz
*)
var i,nfiles:integer;
red:Boolean;
rdf: Text;
wrf: Text;
line: String[255];
destF: String[10];
function CkRedirect: boolean;
(* Is the destination a file or stdout?
The last file is assumed to be the redirection file if it exists.
Write all non redirection files to a temporary file and then
dump that to stdout or rename it to the destination file.
*)
var line:String[80];
begin
writeln('Testing for file redirection');
line := ParamStr(ParamCount);
writeln('Got last par=',line);
if (line[1] = '>') then
begin
writeln('Found redirect');
CkRedirect := True;
end;
end;
begin
writeln('ParamCnt=',ParamCount,ParamStr(0));
nfiles := ParamCount;
red := False;
if CkRedirect then
begin
writeln('Redirect');
nfiles := ParamCount - 1;
red := True;
destF := ParamStr(ParamCount);
Delete(destF,1,1); (* Remove '>') ) writeln('Redirect to:', destF); end; for i:=1 to nfiles do begin ( Type one file ) writeln(ParamStr(i)); Assign(rdf,ParamStr(i)); Reset(rdf); if red=True then begin Assign(wrf,destF); Rewrite(wrf); end; while not Eof(rdf) do begin Readln(rdf,line); if red=True then begin Write(wrf,line); end else Writeln(line); end; close(rdf); Writeln(' '); end; ( Caused error on the fpc compiler *)
if CkRedirect then close(wrf);
Writeln('Done …');
end.

Testing for file redirection
Got last par=TEST.PAS
Done …

Konklusion

Den här lilla programmeringsövningen visar egentligen hur ofattbart mycket tekniken har utvecklats under en livstid. Generellt kan man antagligen säga att alla intressanta parametrar har förbättrats med en faktor tusen eller mera. Några exempel:

  • Processons klockfrekvens 1 MHz –> 4 GHz (dagen datorer är ungefär 4000 ggr snabbare sett till processorns klockfrekvens.
  • Maskinens centralminne RAM 64 kByte –> 64 GByte (1 000 000 gånger större minne i dagens persondatorer av topp klass).
  • Skivminne/Lagringsminne 100 kByte –> 4 TByte (4 000 000 ggr större idag).
  • Maskinens pris $5000 –> $100 (50 ggr dyrare än idag). Notera att jämförelsen är felaktig eftersom penningvärdet har försämrats kraftigt på 40 år. Jag gissar att en korrekt jämförelse kunde vara åtminstone 100 ggr.

Om vi glömmer dagens AI boom där AI av vanliga användare körs över nätet och således inte belastrar den egna maskinen i någon större utsträckning så används datorerna fortfarande till liknande uppgifter som i ”forntiden” d.v.s. textbehandling, skicka brev och hantera kalkylark av olika typer. Gårdagens datorer kändes responsmässigt ungefär lika som dagens datorer. Vart har en prestandaökning på mellan 1000 och 1 000 000 ggr. försvunnit? Min uppfattning är att vi har fått en ofantlig mängd ”bling” som egentligen endast gör skärmen trevligare att titta på. Vi har halvtransparenta fönster som uppdateras hela tiden medan vi flyttar dem. En gammal dator skulle ha storknat genast. I våra datorer körs mängder av program i bakgrunden hela tiden. Program som meddelar oss att vi har fått meddelanden, program som skickar information om var vi gör till Microsoft etc. Det är lätt att bränna datorkapacitet och minneskapacitet i en värld där maskinen jag använder egentligen redan länge har varit tillräckligt kraftfull för det den skapades för.

Min laptop som också kör Linux fungerar helt OK trots att den är strax över tio år gammal. En bekant fick problem d.v.s. den heliga röken som datorn antagligen kör på slapp ut och maskinen slutade fungera. Jag hjälpte personen att rädda foton och dokument från datorn och fick sedan överta skrotet. Efter egen reparation har maskinen fungerat klanderfritt i många år. Jag kör en linuxvariant där allt onödigt ”bling” är bortplockat och maskinen fungerar bra som den är.

Ett annat intressant exempel på datorns ofantliga utveckling är ”mini”-datorn PDP-11 som operativsystemet Unix utvecklades på. Maskinen skulle ha kostat en privatperson tiotals tusen dollar att köpa. Jag har idag en replica av en PDP-11/70 d.v.s. den sista PDP:n som hade en frontpanel som tillåter mig att knappa in maskinkod bit för bit. Min replika kör, liksom CP/M på PicoCalc, en emulator men i detta fall på en Raspberry Pi 4. Den emulerade minidatorn från 1970-talet kör engefär tio gånger snabbare än orginalet trots att varje maskininstruktion emuleras av ett emulatorprogram på Raspberry Pi. En raspberry pi kostar idag beroende på variant kring 100 Euro.

Världens första egentliga superdator var Cray-1. Maskinen användes för mängder av vetenskapliga beräkningar. Man har uppskattat att en Raspberry Pi 5 (100 Euro), då man använder display hårdvaran (GPU) som en vektorprocessor är snabbare än en Cray-1 superdator. En Cray-1 behövde ungefär 115 kW eleffekt. En Raspberry Pi behöver ungefär 7W. Även på effektområdet ser vi alltså en förbättring på ungefär sextontusen gånger.

https://en.wikipedia.org/wiki/Cray-1

Landskap

02/11/2022

Området mellan Esbo Å:s och Gumböle Å:s utlopp används under sommaren som betesmark för kor. Under höst och vinter finns korna på annat håll och de stora öppna området fungerar bra för flygning med drönare. I den här videon flyger jag en rätt stor Yuneec Q500 drönare. Min goda vän Anders flyger en Dji Phantom 3 Professional. Kameratekniken i de båda drönarna är väldigt lika och det är främst en smakfråga vilkendera drönaren som producerar en bättre video. Dji Phantom 3 är eventuellt lite piggare att flyga … om detta är en fördel eller nackdel kan man fråga sig.

Video: Området mellan Esboå och Gumböleå nära åarnas utlopp kallas Glasdalen.

Nya regler för flygning med drönare kräver att drönaren är registrerad och att operatorn har avlagt ett prov på nätet. En stor drönare, båda drönarna på videon väger betydligt över ett kilogram, får inte flygas över utomstående och man måste hålla tillräckligt avstånd till hus och industri. Videons område är väl lämpat för drönarflygning men man måste medvetet undvika att flyga för nära småhusen i riktning nord ost.

Bilden visar en satellitbild av Glasdalen mellan de två åarna. Småhusområdet söder om Kristallvägen bör man vara medveten om för att inte gå för nära. Skogsområdet i väster är naturskyddsområde.

Enkelt elektronikprojekt

19/10/2022

Jag har två drontyper som jag regelbundet flyger med. DJI:s Phantom samt Yuneec Typhoon. Dronerna är rätt likvärdiga ur flygsynvinkel och kamerornas kvalitet är mycket lika. Det finns dock en betydande skillnad mellan dronfamiljerna.

Dji använder intelligenta batterier d.v.s. laddningslogiken finns i själva batteriet. Batteriet kan alltså helt autonomt följa med sin egen användning vilket är viktigt då man använder moderna LitiumPolymer (LiPo) batterier. Ett LiPo batteri tycker inte om att vara tomt men det skadas också på sikt av att vara fulladdat. Egenskaperna hos ett felbehandlat batteri förändras bl.a. så att batteriets inre motstånd stiger vilket ur dronens synvinkel syns som höjd batteritemperatur under flygningen och kortare flygtid. Dji:s batterier laddar själja ur sig till ca. 60% laddningsnivå inom några dagar om batteriet inte används efter laddning.

Yuneecs batterier är inte intelligenta d.v.s. hela underhållsansvaret faller på användaren. Det är på mitt asnsvar att se till att batterier då de lagras har en laddningsgrad kring 60% för att livslängden skall bli så lång som möjligt. Ett hjälpmedel som jag har för detta ändamål är en intelligent laddare (inte Yuneecs laddare) som har olika program för laddning, urladdning och underhållsladdning. Det jag har saknat är ett enkelt sätt att mäta batteriernas inre motstånd och det är detta denna artikel kommer att handla om.

Då ett batteri belastas kommer det att ske ett inre spänningsfall i batteriet d.v.s. den spänning man ser över batteriets poler kommer att sjunka vilket betyder att t.e.x. en drons varningssystem för låg batterispänning slår på allt tidigare ju högre det inre motståndet blir. Om dronen vid flygning behöver t.e.x. 2A ström kommer ett inre motstånd på 70 milliohm att sänka batteriets spänning med 0,14 V vilket motsvarar flera minuters flygning.

När skall jag kasta ett batteri

Ett batteri är slut då flygtiden blir för kort samt då batteriet eventuellt börja uppföra sig konstigt d.v.s. det kan efter någon minuts flygning ge en batterivarning som tvingar fram en plötslig påtvingad landning för att undvika krasch. Ett sätt att se när ett batteri börjar nå slutet av sitt liv är att mäta det inre motståndet samt naturligtvis ibland mäta den effektiva flygtiden med ett batteri.

Mätning av det inre motståndet

Bilden visar, i form av ett kretsschema, ett batteri som belastas över ett motstånd. För att kunna beräkna det inre motståndet måste vi mäta batteriets spänning obelastat (i vila) samt spänningen då batteriet är belastat. Vi vill också undvika lång urladdning innan vi mäter det belastade batteriets spänning eftersom belastningen också medför att spänningen sjunker till följd av att batteriet laddas ur.

Mätning av batteriets spänning med voltmätaren (V) obelastat då switchen är öppen och belastat då batteriet urladdas genom lastmotståndet Rl.

Då batteriet är obelastat så går det nästan ingen ström genom batteriet, endast en mycket liten läckström går genom voltmätaren kanske 1 uA. Detta betyder att den spänning voltmätaren mäter är batteriets spänning eftersom spänningsfallet över Ri är ungefär lika med noll.

Då man sluter switchen SW kommer batteriet att laddas ur med en ström som beroende av batterityp är mellan 1 och 1.5 A. Batteriets inre motstånd kommer då att leda till ett spänningsfall inne i batteriet med storleken strömmen*inre_motståndet eller Ui=I*Ri . I prktiken kan man se detta så att spänningen sjunker då batteriet laddas ur.

Då batteriet är obelastat är den mätta spänningen:

Vb = det obelastade batteriets polspänning

Då batteriet belastas mäter vi en spänning:

(1) Vl = Vb – I*Ri

Där:

I = strömmen genom lastmotståndet som vi i mitt fall vet att det är 10 ohm

Rl = lastmotståndet 10 ohm

Ri = batteriets okända inre motstånd

Vb = det obelastade batteriets spänning.

Strömmen kan vi beräkna ur den mätta spänningen med last:

(2) I = Vl/Rl

Vi kan lösa Ri ur ekvation (1) och får då:

(3) Ri = (Vb-Vl)/I

Vi byter ut I ekvation (3) mot I taget ur (2) och får då:

(4) Ri = Rl * (Vb-Vl)/Vl

Vi ser alltså att vi helt änkelt gör två spänningsmätningar den första med obelastat batteri och den andra med ett belastat batteri och därefter lägger vi in värdet i (4) tillsammans med det kända vädet på Rl=10 ohm. Lätt som en plätt där inget kan gå fel eller hur?

En Arduino Uno är ett billigt litet mikroprocessorkort med en trevlig utvecklingsomgivning. Processorn har en AD-konverter (voltmätare) med upplösningen 10 bitar d.v.s. mätområdet 0 … 5V delas in i 1024 spänningssteg. Den enklaste mätaren kunde således byggas utgående från en Arduino Uno kopplad till ett 5V relä som styr mätning av obelastat respektive belastat batteri.

Jag skrev ett litet program som gjorde ovanstående mätningar med hjälp av Uno:s AD-konverter. Resultatet blev negativa värden på den inre resistansen. Hur kan jag få negativa värden på den inre resistansen? Då vi tittar på ekvation (4) så ser vi att spänningen med last då måste vara större än det obelastade batteriets polspänning! Hur är detta möjligt?

Uno:s AD-konverter tar sin referensspänning från processorkortets 5V matningsspänning. Ett relä drar rätt mycket ström d.v.s. när relät aktiveras d.v.s. SW är slutet kommer hela processorkortets spänning att sjunka till ca. 4,5V. Plötsligt blev referensspänningen 4,5 i stället för 5V och resultatet är att det ryms 1024 spänningssteg i 0…4,5V i stället för 0…5V d.v.s. steglängden minskar och då processorn mäter det belastade batteriets spänning tror den sig mäta en spänning som är större än det obelastade batteriets spänning.

Lösningen som samtidigt testar diagnosen var att mata relät med ett separat spänningsaggregat. Processorns spänning hålls bättre konstant och felen minskar radikalt.

Nu dyker följande problem upp. Mätningar av riktiga batterier tyder på att upplösningen d.v.s. den precision vi kan uppnå vid mätningen blir av storleksorningen 10 milliOhm vilket är nästan 25% av det inre motståndet i ett typiskt batteri. En enkel kontroll visar vad detta problem beror på.

Antag att inspänningen till AD-konvertern är något över halva maxspänningen t.ex. 3.5 volt vilket motsvarar ett mätvärde på 716 enheter av 1024. Antag nu att Vb och Vl skiljer med endast en enhet och att lastmotståndet är 10 ohm. Det minsta resistansvärdet vi då kan mäta får vi genom att beräkna:

Ri = 10*(716-715)/715 = 14 milliohm … inte bra!

Slutsatsen blev att mätaren måste få en bättre AD-konverter. Ett alternativ kunde ha varit att gå över till en ARM-baserad ”BluePill” processor som erbjuder en 12-bitars AD-konverter d.v.s. med samma uppställning som för Uno och omkompilering av programkoden kunde jag få fyra gånger bättre upplösning d.v.s. ungefär 3.5 milliOhm vilket är betydligt bättre. Ett annat alternativ hittade jag i miljonlådan i form av ett litet kretskort som jag nångång skaffade för ett annat projekt. Kretsen ADS1115 erbjuder en fyrkanalig 16-bitars AD-konverter som kontrolleras över en seriebus I2C. Genom att använda ADS1115 kunde jag fortsätta att använda Arduino Uno men mäta spänningar med god precision. Voltmätaren ADS1115 marknadsförs som 16-bitars men i praktiken är det en 15-bitars konverter då jag mäter positiva spänningar. 15 bitar ger 32768 spänningssteg d.v.s. 32 ggr bättre än Uno.

Mätprogrammet går på 60-rader vilket väl ryms i en Arduino Uno som erbjuder 32k minne för program (en Commodore 64 från ungefär 1980 hade ungefär den här kapaciteten). Programmet använder ett färdigt bibliotek för kontroll av ADS1115 vilket gör programmeringen mycket enklare …

// Name= resistance_ADS1115
// Lars Silen 2022
// This is free source code. Feel free to copy and modify.

#include "Arduino.h"
#include "ADS1115-Driver.h"

#define Rly 6
uint16_t V_battery;
uint16_t V_load;
float R;
float loadResistance=10.1;

ADS1115 ads1115 = ADS1115(ADS1115_I2C_ADDR_GND);

uint16_t readValue(uint8_t input) {
  ads1115.setMultiplexer(input);
  ads1115.startSingleConvertion();

  delayMicroseconds(25); // The ADS1115 needs to wake up from sleep mode and usually it takes 25 uS to do that

  while (ads1115.getOperationalStatus() == 0);

  return ads1115.readConvertedValue();
}

void setup() {
  Serial.begin(9600);
  ads1115.reset();
  ads1115.setDeviceMode(ADS1115_MODE_SINGLE);
  ads1115.setDataRate(ADS1115_DR_250_SPS);
  ads1115.setPga(ADS1115_PGA_6_144);  // +/- 6.144 V
  ads1115.setMultiplexer(ADS1115_MUX_AIN0_GND);
  pinMode(Rly, OUTPUT);
}

void loop() {
    Serial.println("Program to measure the internal resistance of 3s and 4s Yuneec LiPo batteries");
    Serial.println("Ensure there is a very good contact to the battery.");
    Serial.println("Keep your finger on the battery side connector!");
    delay(1000);
    digitalWrite(Rly,LOW);  // Measure battery voltage
    delay(100);
    uint16_t V_battery = readValue(ADS1115_MUX_AIN0_GND);   
    Serial.print("V_battery: ");
    Serial.println(V_battery);
    Serial.println("Switch load to ON");
    digitalWrite(Rly,HIGH);  // Measure load voltage, switch load ON
    delay(10);
    uint16_t V_load = readValue(ADS1115_MUX_AIN0_GND);
    digitalWrite(Rly,LOW);
    Serial.print("V_load: ");
    Serial.println(V_load);
    R = (loadResistance*(V_battery-V_load)/V_load)*1000.0;
    Serial.print("Internal resdistance milliohm:");
    Serial.println(R,0);
    Serial.println();
    Serial.println();
    delay(5000);
}

Det färdiga mätsystemet visas i bilden nedan. Den alternativa plattformen ”Blue Pill” är det lilla processorkortet som ligger på det silverfärgade lilla nätaggregatet som används för att driva reläet. ”Blue Pill” används inte utan finns endast med som illustration. Blue Pill är sannolikt 10 ggr kraftfullare än en Arduino Uno. Både en Uno och Blue Pill kostar sannolikt kring en tia. En Arduino Uno, Mega eller Due är dock mycket lättare att komma igång med eftersom de har skräddarsytts för Arduino utvecklingsomgivningen.

Den färdiga mätaren. Batteriet kopplas till de två banan-honkontakterna. Lastmotståndet är den guldfärgade komponenten. Motståndet är 10 ohm och effekttåligheten 50W.

Programmet körs från Arduino IDE så att utskrift sker till ”Serial monitor”. Det vore enkelt att ansluta en LCD-skärm på vilken resultatet kunde visas. Att lägga till en skärm och på detta sätt göra mätaren oberoende av en PC lämnas som övningsuppgift till läsaren!

Ett gammalt batteri har mätts. Det inre motståndet har närstan fördubblats jämfört med ett färskt batteri. Notera att batteriet har tre celler d.v.s. den inre resistansen är ungefär 24 milliOhm per cell. I ett färskt batteri är motsvarande värde ungefär 14 milliOhm per cell.

Antik datorteknik, flytta filer över nätet

11/01/2022

I föregående inlägg visade jag hur jag kan använda en simulerad magnetbandstation för att flytta filer mellan min PDP11/70 och den Raspberry Pi som kör emuleringen. Systemet är något omständligt men det fungerar i princip till belåtenhet. Systemet kunde t.ex. användas till att flytta över källkoden till en lite trevligare editor till PDP11 och därefter kompilera den. Resultatet skulle vara en lite bekvämare arbetsmiljö.

Jag kan utan problem köra min PDP11 också från min ”huvuddator” d.v.s. bordsdatorn. Jag ansluter via SSH d.v.s. en krypterad dataförbindelse till Raspberry Pi och använder samma fönster till att logga in mig på PDP11. Detta betyder att jag kan jobba vid min stora bildskärm med ett ensamt terminalfönster in till PDP11. Om jag vill flytta data direkt från huvuddatorn till PDP11 utan att behöva logga in på Raspberry Pi för att fixa magnetbandet, hur gör jag då?

Det faktum att jag kan koppla upp mig till PDP11 via en SSH förbindelse till Raspberry Pi betyder självklart att jag har en fungerande nätverksförbindelse. Jag kan också kontrollera om min PDP11 syns på nätverket med hjälp av verktyget ”ping”:

ping 192.168.0.xxx

där 192.168.0.xxx är PDP11:ns IP-adress. PDP11 har en egen IP-adress trots att den kör ”inom” Raspberry Pi d.v.s. all dess IP trafik routas via Raspberry Pi. Om PDP11 svarar på en ping så betyder detta att nätverksförbindelsen i princip fungerar. PDP11 känner till kommandot ftp d.v.s. det borde vara möjligt att flytta filer direkt mellan huvuddatorn och PDP11 utan att Raspberry Pi behöver delta i operationen. En intressant detalj är att jag inte kan pinga PDP11 från Raspberry Pi d.v.s. det kort på vilket både Raspberry Pi och PDP11 kör. Däremot kan jag pinga PDP11 från min bordsdator som sitter på samma nätverk som Raspberry Pi. Problemet går att åtgärda men så långt har jag inte ännu hunnit.

En ftp server på min huvuddator

Jag började med att installera en ftp server på min huvuddator. Det finns ett antal varianter för Linux och jag valde att installera en server som heter VSFTPD. Jag kör Linux Mint som stöder denna ftp-server. Installationen gick behändigt med:

sudo apt update

Detta kommando uppdaterar Linux Mint katalog över tillgängliga applikationer.

sudo apt install -y vsftpd

Installation av ftp-servern från kommandoraden. Jag kunde likaväl ha använt ett grafiskt verktyg.

Konfiguration av servern görs i filen /etc/vsftpd.conf

sudo nano /etc/vsftpd.conf

Det lönar sig att googla på vsftpd om man behöver information om konfigurationen. Jag måste installera och konfigurera som superuser ”root” eftersom jag installerar vsftpd för alla användare på maskinen och konfigurationsfilerna i /etc är skrivskyddade eftersom jag inte vill att en eventuell besökare skall kunna gå in och konfigurera min maskin. För att jag skall kunna flytta filer från måste jag åtminstone editera /etc/vsftpd.conf så att jag tillåter skrivning till min katalog på deNeb. Detta kan jag göra genom att sätta write_enable=YES . Denna modifikation behövs om jag vill flytta filer från PDP11 till deNeb.

Flytta filer till/från PDP11

Min PDP11 representerar tidsperioden 1970 till slutet av 1990-talet. I praktiken betyder detta att de programverktyg jag har tillgång till kör i en textterminal inte i ett modernt grafiskt fönster som på min huvuddator. Det visar sig dock att man mycket bekvämt kan flytta filer mellan datorer direkt från kommandoraden på PDP11 utan att detta egentligen är komplicerat.

PTF-inloggning till min huvuddator från PDP11

Jag kopplar upp till min huvuddator ”deNeb” från PDP11. Situationen är intressant genom att det terminalfönster i vilket PDP11 kör finns på deNeb men är kopplad över en ssh-förbindelse. PDP11 kör alltså på Raspberry Pi men terminalfönstret finns på deNeb vilket man kan se i fönstrets rubrik.

Jag jobbar alltså i PDP11 och lägger upp en ftp-förbindelse till deNeb. Steg för steg gör jag:

ftp deNeb

Jag ger mitt användarnamn och password till deNeb för att släppas in i maskinen. Inloggningen är avklarad då jag får svaret ”230 Login successful”.

ftp>

Datorn kommer visa ftp> på varje rad för att indikera att jag har en aktiv ftp-förbindelse. I kommandona nedan är denna indikator bortlämnad. tex. följande kommando nedan kommer att i terminalen vara: ftp>cd Prog/PDP11 men användaren skriver endast cd Prog/PDP11 .

Jag ger nu ett kommando till ftp-servern att jag vill flytta mig till katalogen Prog/PDP11 på datorn deNeb från vilken jag vill hämta en textfil.

cd Prog/PDP11

Svaret blir ”250 Directory successfully changed”. Jag listar nu innehållet (ls) i katalogen dit jag flyttade mig på deNeb.

ls

Katalogen innehåller endast en fil med namnet deNeb.txt. Jag kan nu flytta filen från deNeb till PDP11 där jag kör mitt ftp-program med kommandor ”get”.

get deNeb.txt

… 226 Transfer complete.

Jag har nu flyttat filen till PDP11 och jag kan undersöka vad jag fick. Först går jag ut ur PDP11 med kommandot ctrl-D.

cat deNeb.txt
Resultatet blir:

This text document is moved from the Linux computer ”deNeb” to the emulated PDP11.

Filens innehåll är korrekt. Vi kan ladda in filen i texteditorn ”vi” och göra en liten förändring. Vi ändrar texten till: This text document is moved from PDP11 to ”deNeb”. Jag byter namn på filen till PDP11.txt så att jag kan verifiera att jag faktiskt har flyttat filen tillbaka till PDP11.

Vi kan nu flytta den modifierade filen tillbaka till deNeb genom att på nytt starta ftp på PDP11. Vi flyttar oss till katalogen Prog/PDP11 och använder ”put” för att flytta filen från PDP11 till deNeb.

Jag kan kontrollera vad jag har i min lokala katalog på PDP11 inifrån ftp-programmet genom att ge normala UNIX-kommandon som inleds med ”!”.

!ls
hello hello.c

På PDP11 har jag endast två filer i min arbetskatalog d.v.s. ett ”Hello world!” c-program och samma program i kompilerad körbar form.

Jag flyttar filen PDP11.txt till deNeb med ftpkommandot put PDP11.txt . Jag kan nu i ett annat terminalfönster kontrollera att filen faktiskt levererades korrekt.

Efter kommandot på PDP11 ser vi att vi har fått en ny fil på deNeb d.v.s. överflyttning i båda riktningarna lyckas utan problem.

Det är igen intressant att se hur jag utan större problem kan kommunicera mellan min huvuddator deNeb och en 30 år gammal UNIX. Det finns klara fördelar av att operativsystemen är nära besläktade. Jag tror inte att det hade varit riktigt lika enkelt att idag försöka sätta upp en förbindelse mellan PDP11 och t.ex. Windows 3.1 från 1992 …

Att ladda program på en PDP11

05/01/2022

1970-talets datorer var ofta försedda med en frontpanel med mängder av strömbrytare samt blinkande lampor. Frontpanelen var inte kosmetisk utan tanken var att användaren började med att knappa in en handfull maskininstruktioner i maskinens minne, instruktioner vars uppgift var att ladda in ett större mera avancerat laddarprogram från t.ex. hålremsa. Från hålremsa kunde man ladda in ett enkelt operativsystem eller t.ex. en Basic tolk som kunde användas till att skriva riktiga program. Det var teoretiskt, inte praktiskt, möjligt att knappa in t.ex hela tolken via frontpanelen men chansen att man gjorde något fel var så stor att det inte var något alternativ. En användbar Basic krävde någonstans mellan 4000 och 8000 instruktioner d.v.s. kanske 15000 strömbrytare måste flippas utan fel för att det skulle fungera.

Bilden är tagen från: https://obsolescence.wixsite.com/obsolescence/pidp-11-overview

Man använde oftast hålremsa för att ladda program. Hålremsa är som namnet säger en ungefär 25 mm bred pappersremsa ofta många meter lång med hål stansade tvärs över remsan. Varje stansad hålrad representerade ett tecken i binär form. Det själv inmatade programmets uppgift var alltså att läsa av hålkombinationer från en hålremsläsare och successivt mata in resultatet i minnet. Då hela remsan hade lästs matade man in en startadress från frontpanelen och tryckte på ”kör”.

En hålremsläsare är enkel att bygga själv men att bygga en hålremsstans kräver redan en del mekaniskt kunnande men inte oöverkomligt sådant. Jag tittade lite på möjligheten att bygga upp hålremsan på A4-papper i form av t.ex. en JPG bild. Man kunde då t.ex. i stället för att stansa hålremsa skriva ut program eller data i hexadecimal form, papper som kunde mappas in och sedan läsas av PDP11 via en simulerad hålkortsläsare som skulle använda OCR (Optical Code Recognition) för att återskapa innehållet i binär form för laddning till PDP11. Jag skrev på skoj ett program som dumpade data till printer i ett standardiserat format och använde därefter programmet Tesseract för att återskapa mina data. Programmet Tesseract fungerar mycket väl då man låter det läsa text skrivet på ett språk för vilket Tesseract tränats. Resultatet blev inte speciellt bra då programmet skulle läsa i princip slumpmässiga data. Felkorrigeringen bygger tydligen åtminstone delvis på att den inlästa texten matchas mot ordlistor/meningar/grammatik så att enstaka fel elimineras. Då programmet inte kunde matcha inlästa data mot en språklig databank dök det upp förvånande mycket fel kanske 1-5% av de inlästa tecknen blev fel d.v.s. systemet fungerar inte utan hjälp av mera avancerad felkontroll. Här uppfattade jag att jag hamnade i en återvändsgränd och lät bli att gå vidare.

Av en slump hittade jag efter en del googlande ett enkelt alternativ till att ladda in program till PDP11. Vi har alla sett video/film från gårdagens data center där det finns kylskåpsstora databanspelare som kontinuerligt körs/stoppas/snabbspolas. Databanspelarna var länge det huvudsakliga mediet på vilket data kunde lagras. En svindyr hårskiva rymde kanske 5 Mbyte medan ett magnetband hade nästan oändlig kapacitet sett ur den tidens perspektiv. Magnetbandets nackdel var att man då man skulle ladda in ett program måste man hitta bandet, korrekt mata in bandet i bandstationen och därefter ange vilket ”block” man ville läsa. Systemet var långsamt men blixtsnabbt jämfört med andra system t.ex. hålremsa.

Det visade sig att det fanns en fungerande simulerad bandstation som fungerar på följande sätt:

Jag skapar en katalog /home/pi/bsdtapes på Raspberry Pi där emulatorn körs. Om jag lagrar ett simulerat magnetband tq0tape.tap i denna katalog så kan jag på PDP11 som på den gamla goda tiden aktivera bandstationen och läsa bandet.

För att aktivera bandstationen i PDP11 måste man i BSD 2.11 startfilen definiera att en bandstation finns tillgänglig.

cd /opt/pidp11/systems/211bsd

Gör en kopia på initialiseringsfilen boot.ini:

sudo cp boot.ini boot.ini.backup

Editera boot.ini så att det efter set tq enabled kommer en ny rad:

attach tq0 /home/pi/bsdtapes/tq0tape.tap

Då PDP11 BSD 2.11 startar så vet systemet var det hittar bandet för bandstationen.

Processen beskrivs nedan:

Att läsa program/data från magnetband

Om jag vill flytta data eller program till PDP11 så måste jag först skapa ett läsbart magnetband d.v.s. en fil som binärt ser ut som de data vi får ut från magnetstationen.

Vi börjar med att putsa bort eventuella gamla magnetband i katalogen. Jag har en underkatalog i vilken jag sparar mina magnetband.

sudo rm tq0tape.tap tq0tape.tar

Antag att jag vill flytta en fil minFil.txt till PDP11. Jag börjar med att komprimera/packa ihop filen till en tar-fil. Filändelsen tar står för tape archive! Systemet används fortfarande i Unix/Linux maskiner även om det är många år sedan man hade en riktig bandstation att jobba mot. Resultatet blir helt enkelt en datafil.

tar cvf tq0tape.tar minFil.txt

Vi har nu ett bandarkiv tq0tape.tar som innehåller filen minFil.txt. Filen är inte ännu läsbar av PDP11 utan vi måste skriva om arkivfilen till ett simulerat magnetband. Vi gör detta med hjälp av ett enkelt Perlprogram tapadd.pl och resultatet blir en fil tq0tape.tap .

./tapadd.pl tq0tape.tar tq0tape.tap

Jag kan nu läsa bandet från PDP11 på följande sätt under förutsättning att jag har lagt till bandstationen till 211BSD :

Starta PDP11/70 under simh. Det verkar vara nödvändigt att starta om 211BSD mellan olika band. Jag har inte analyserat vad detta beror på … kanske i framtiden. Logga in på PDP11 och gå till den katalog dit du vill ha dina data. Spola tillbaka magnetbandet och läs innehållet i form av en tar-fil.:

mt rewind
tar xv

Resultatet blir att de filer som fanns på bandet lagras under dut usprungliga namnet i arbetskatalogen. Systemet fungerar förvånande bra.

Att flytta data från PDP11 via magnetband

Systemet är i princip detsamma som det ovan beskrivna men i omvänd ordning. Vi börjar med att skapa ett bandarkiv som skrivs direkt till ”magnetbandet” utan att gå över en lokal fil. Systemet är alltså:

Spola tillbaka bandet.

mt rewind

Vi antar att vi vill flytta hela arbetskatalogen till Raspberry Pi. Vi ”tarrar” då ihop hela katalogen och lägger resultatet på bandet:

tar cv .

Notera att punkten efter tar cv betyder den aktuella katalogens innehåll. Jag kunde byta ut punkten mot t.ex. hello.c varvid endast filen hello.c skulle skrivas till band.

Det vi tarrade ihop finns nu på ”magnetband” i filen tq0tape.tap på Raspberry Pi (detta kallas magi)! Vi kan nu läsa bandet på raspberry pi med hjälp av hjälp programmet tapcat.pl . Vi börjar med att konvertera magnetbandet till ett normalt Unix bandarkiv:

./tapcat.pl tq0tapes.tap > tq0tapes.tar

Vi skapade nu ett Unix bandarkiv tq0tape.tar i arbetskatalogen. Bandarkivet kan nu öppnas med:

tar xvf tq0tapes.tar

Efter detta tar kommando finns hela arkivets innehåll i arbetskatalogen där kommandot kördes.

Slutkommentar

Det är rätt intressant att jag kan använda Unixens ”tar” verktyg på en maskin från 1970-talet. Alternativt kan man säga att det är rätt fantastiskt att 1970-talets programverktyg som skapades för att hantera data-/programarkiv på magnetband fortfarande används aktivt idag trots att forntidens bandstationer har försvunnit helt och man hittar dem endast på olika tekniska muséer.

Jag kan nu hämta ett ”magnetband” d.v.s. kopiera en magnetbandsfil från min underkatalog mytapes till filen tq0tapes.tap och därefter ladda innehållet på PDP11.

Ett ännu enklare sätt att överföra filer är att använda ftp (file transfer protocol) d.v.s. vi använder nätverket för överföring utan att ha något behov av att någon bandstation på vägen. Mera om ftp i nästa artikel.

Länkar

Filtransfer via magnetband: https://github.com/rricharz/pidp11-2.11bsd/blob/master/Tape.pdf

Program tagna från https://github.com/rricharz/pidp11-2.11bsd/

Programmet tapadd.pl:

#!/usr/bin/perl -w
use strict;
if(@ARGV != 1) {
print STDERR ”Usage: $0 <filename>\n”;
exit(1);
}
add_file($ARGV[0], 512);
end_file();
end_file();
sub end_file {
print ”\x00\x00\x00\x00”;
}
sub add_file {
my($filename, $blocksize) = @_;
my($block, $bytes_read, $length);
open(FILE, $filename) || die(”Can’t open $filename: $!”);
while($bytes_read = read(FILE, $block, $blocksize)) {
if($bytes_read < $blocksize) {
$block .= ”\x00” x ($blocksize – $bytes_read);
$bytes_read = $blocksize;
}
$length = pack(”V”, $bytes_read);
print $length, $block, $length;
}
close(FILE);
}

Programmet tapcat.pl:

#!/usr/bin/perl -w
use strict;
use vars qw($filename $filenum);
if(@ARGV != 2) {
printf STDERR ”Usage: $0 <tape file> <file number>\n”;
exit(1);
}
$filename = $ARGV[0];
$filenum = $ARGV[1];
open(INPUT, $filename) || die(”Can’t open $filename: $!”);
while($filenum–) {
readfile(0);
}
readfile(1);
exit(0);
sub readfile {
my($print) = @_;
my($block);
while(defined($block = readblock())) {
if($print) {
print $block;
}
}
}
sub readblock {
my($blocksize, $bs2, $block);
read(INPUT, $blocksize, 4);
$blocksize = unpack(”V”, $blocksize);
return undef unless $blocksize;
read(INPUT, $block, $blocksize);
read(INPUT, $bs2, 4);
$bs2 = unpack(”V”, $bs2);
$blocksize == $bs2 || die(”Invalid tape format”);
return $block;

}

Arkeologi, urgammal musik

11/12/2021

Min goda vän Anders skickade mig en urgammal datafil Windows/DOS(?) sannolikt från början av 1990-talet. Filen innehåller noterna till låten Vandalen skriven av Anders Backman och Marcus Blomberg. Problemet var att ingendera upphovsmannen längre hade noterna till låten och programmet som hade använts för att skriva ner låten hade försvunnit för många år sedan vid någon dator/Windows(?) uppgradering. Anders undrade om jag hade något hjälpmedel för att lista ut vad filen innehöll eventuellt så att man kunde pussla ut hur låten gick.

Jag plockade fram en såkallad HexEditor i detta fall programmet GHex för Linux. En hexeditor klarar av att läsa godtyckliga filtyper och programmet visar två kolumner data. Den vänstra kolumnen är hexadecimala koder (siffror) och den högra kolumnen visar alla tecken som kan tolkas som text inne i filens data massa. Den högra kolumnen är alltså det läsbara som finns rad för rad i den vänstra kolumnen. Att läsa en okänd fil med en hexeditor kan ibland ge någon pekare till vilket program som i forntiden sparade filen, programmets version etc.

Då jag skrollade ner genom filen så hittade jag faktiskt lite text. Texten ingick i ett textblock i notbladet och texten var:

Bilden visar en liten del av HexEditorns skärm. Siffrorna till vänster antyder var den breda breda hexadecimala kolumnen är och visar endast den smala högra kolumnen med läsbar text. I texten fanns också namnet på de två kompositörerna Anders Backman och Marcus Blomberg. Jag putsade bort data som kunde vara känsliga om de sprids på nätet.

Eftersom filen inte innehöll enkelt igenkännbara symboler för t.ex. notvärden så blev följande steg att bena ut vilket program som eventuellt kunde ha använts för att skriva filen. Anders gissade att det eventuellt kunde ha varit ett finskt program musikantti skrivet för Soundblaster musikkortet. Anders hittade ett urgammalt tomt skivfodral som dock innehöll namnen på programmets upphovsmän. Googling på upphovsmännen gav en länk till ett gratisprogram/shareware musician som jag laddade ner och körde i DOS-emulator på min Linuxmaskin. Programmet körde men det kände inte igen filen Vandalen.mus och exempelfilerna som kom med programmet hade filtypen .NOT . Jag testade med att byta namn på Anders fil från Vandalen.mus till Vandalen.not . Samma problem kvarstod d.v.s. filtypen okänd.

Jag trodde att jag i något sammanhang hade stött på en konvertering av musik notskriftsfiler där en filtyp kunde ha varit .mus . Kunde filen eventuellt ha skapats av programmet Encore? Svar: Sannolikt inte, Encore använder filtypen .ENC .

Tid för nästa idékläckningssession. Kunde det eventuellt finnas något konversionsprogram som t.ex. kunde konvertera filtypen MUS till Encores ENC? Googling hittade ett konversionsprogram som påstod sig kunna konvertera MUS och ENC till MIDI. Då jag tittade på sidan länken pekade till så hittade jag:

We can convert MusicTime Deluxe .MUS and Encore .ENC files to a format that can be opened in other score programs or DAW/MIDI sequencer.

Ok, nu vet jag alltså eventuellt namnet på det program som har använts för notskrivningen?

Ett samtal till Anders gav som resultat att MusicTime lät bekant och att det faktiskt kunde vara det program som i början av 1990-talet hade använts vid notskrivningen.

Lite mera googlande gav en länk till en plats där jag kunde ladda ner MusicTime version 4 som en testversion. Sagt och gjort. Jag tog ner testversionen och installerade den under Windows-emulatorn under Linux. Uppackning och installation gick problemfritt och programmet startade utan några större problem. Jag flyttade Anders fil Vandalen.mus till windows emulatorns Ducuments katalog och lyckades öppna den. Filen var något skadad men fullt läslig!

Man kan tydligt se att det finns något fontproblem som beror på att jag kör under Linux och inte på en riktig Windowsinstallation. Problemet skulle med säkerhet ha gått att åtgärda genom att installera de saknade fonterna.

Min lösning var att skicka bilden till Anders som får knacka ner melodin i programmet MuseScore som vi nuförtiden använder. Fontproblemet gör att ackordanalysen försvann men antagligen kan Marcus enkelt återskapa den.

Resultatet var lyckat. Filen var i coma och höll på att glida över i bitparadiset men efter en nära döden upplevelse så återföddes filen. Det gäller nu att skriva ut en kopia som mappas in som en fysisk referens. Sannolikt kommer MuseScore att utvecklas vidare under många år varför den nya kopia Anders knackar ner nog torde vara läslig i några årtionden i framtiden.

Bananrepubliken USA?

25/09/2021

Jag har med stort intresse följt rapporteringen av auditeringen av valet i Maricopa/Arizona i USA. Eftersom jag inte har kopplingar till USA så blir antagligen den intressantaste aspekten att se hur man kommer att rapportera om detta i Europa. Kommer våra media att förbigå allt med tystnad eller kommer vi att få en hederlig rapportering?

Valmaskinens loggfiler putsades dagen innan den första ytliga kontrollen gjordes i mars. Det verkar klart att maskinen har varit i kontakt med internet via WiFi trots att tillverkaren påstår att detta inte är möjligt. Maskinen har alltså helt klart varit kopplad till Internet vilket en valmaskin absolut inte får vara.

Alla användare har använt samma password. Detta är problematiskt eftersom det då inte går att identifiera vem som gjort förändringar på maskinen ochg dess loggfiler eftersom en relativt stor grupp människor har kunnat logga in som godtycklig användare.

Videon nedan visar (på engelska) presentationen av resultaten. Det är intressant att se hur spinndoktorerna redan arbetar på högtryck för att släta över resultatet. Jag önskar mina läsare intressanta nästan tre timmar att lyssna på rapporten.

Kanske ”Banarepubliken” i rubriken är lite väl elakt då man trots allt har lyckats göra en audit … detta görs inte i en bananrepublik. Den stora frågan är om ens det här materialet leder någonstans?

Att reparera en fotoskrivare

11/02/2021

Jag köpte för ett antal år sedan en EPSON Stylus Photo PX730WD skrivare för att som gammal amatörfotograf med erfarenhet av ett riktigt mörkrum ha tillgång till den moderna motsvarigheten. Skrivaren använder sex olika bläckkassetter och fotoutskrift på blankt fotopapper blir extremt bra. Skrivaren råkade dock i likhet med min tidigare skrivare rätt snart ut för problem. Mina erfarenheter av bläckskrivare har varit följande:

  • Utskrift av färgbilder är dyrt! En sats färgkassetter kostar i orginal bortåt 100 Euro (1000 SEK).
  • Dyr utskrift leder till att jag skriver ut sällan, sparar på bläck.
  • Att spara på bläck kan leda till att skrivhuvudet torkar. Epsonskrivarna integrerar inte skrivhuvudet i kassetten vilket betyder att ett igentäppt munstycke inte fixas genom att byta kassett. Vissa andra skrivare har skrivhuvudet integrerat i den utbytbara kassetten vilket betyder att problem löses genom att byta kassett.
  • Dyr utskrift leder lätt till att jag använder ”piratbläck” d.v.s. icke märkesbläck. Jag har en känsla, utan klara bevis, av att blandning av orginalbläck och piratbläck kan leda till stopp i skrivhuvudet (detta var åtminstone fallet tidigare). Byte av bläckleverantör borde antagligen föregås av tvätt av skrivhuvudet (det finns specialmedel att köpa, se nedan).
  • Jag kan vara snål och försöka få ut de sista dropparna bläck ur de 15 ml stora kassetterna. Varför byta en kassett som ännu innehåller färg värd sin vikt i guld. Resultatet kan då vara att skrivaren suger luft in i slangen mellan kassett och skrivhuvudet. En luftbubbla blockerar helt eller delvis pumpningen av bläck vilket kan ge mycket synliga och besvärliga utskriftsfel. Dagens färgbläckskrivare marknadsförs enligt principen att det man förlorar på gungorna tar man in på karusellen d.v.s. skrivaren säljs till ett mycket lågt pris (jämförbart med en sats påfyllningskassetter) men med färgkassetter som endast delvis är fyllda för att tvinga köparen att snabbt köpa hutlöst dyr färg. Det är sannolikt att det finns köpare som byter hela skrivaren då bläcket tar slut eftersom nya bläckkassetter ligger i samma prisklass som hela skrivaren …

Ovanstående kostnadsproblem kan lösas på två sätt för den gamla PX730 skrivaren. Jag såg någonstans på nätet att man kan modifiera skrivaren så att den suger bläck direkt från flaskor på samma sätt som dagens Eco Tank skrivare. Ett annat alternativ är att använda kassetter som enkelt kan fyllas på. Jag valde det senare alternativet. För priset av en påfyllning med orginalbläck kan jag köpa en sats tomma påfyllningsbara kassetter med ett räknarchip som nollas automatiskt. En flaska bläck motsvarar tiotals påfyllningar d.v.s utskriftspriset sjunker till ungefär samma nivå som för en laserskrivare.

Fig. 1 Ett exempel på en påfyllnadssats för min skrivare. Det finns satser som också innehåller en flaska tvättmedel om skrivhuvudet delvis har torkat. Sök på ”refill kit XXXX” där XXXX är ditt skrivarmärke och modell. Notera att enkla färgskrivare tenderar att ha fyra färger d.v.s. svart + tre färger medan mera avancerade kvalitetsskrivare har fler kulörer. I mitt fall har skrivaren sex färger.
Fig. 2 En påfyllningsbar bläckkassett. Färg fylls på vid den röda korken längst trill höger. Korken i ofärgad plast närmast betraktaren i kassettens nedre hörn tas bort då kassetten är på plats så att lufttrycket kan jämnas ut.

Att fixa ett torkat skrivhuvud

Den normala metoden för att få ett torkat skrivhuvud att fungera är att använda ”head clean” d.v.s. tvätt av skrivhuvudet kombinerat med provutskrifter. Vid varje putsning (head clean) pumpar skrivaren bläck genom alla skrivarmunstycken för att öppna dem och således få till stånd en jämn utskrift. Varje ”head clean” använder rätt mycket bläck och tömmer alltså bläckkassetterna rätt effektivt. Om inte två till tre rengöringar ger önskat resultat så är det skäl att kontrollera om det finns andra orsaker till utskriftsproblemen. Den kanske sannolikaste orsaken till blockeringen för den giriga är att man har fått luft i någon eller flera av bläckslangarna. Man kan visuellt försöka se om det syns bubblor i den slang som går till den färg som ger problem. Det är dock inte självklart att man kan se bubblor eftersom bläckets färg är så kraftig. Lösningen på problemet är att fylla slangen på nytt med bläckskrivartvättmedel och tvinga ut eventuella luftbubblor.

Eliminering av luft från en slang görs på följande sätt:

Notera! Man kan inte med våld pressa in vatten/tvättmedel eller bläck genom kassettens anslutningsnippa eftersom detta förstör det mikromekaniska skrivhuvudet! Bläckslangarna måste tas loss innan man luftar någon av slangarna! Hur man tar loss slangarna beskrivs nedan för den specifika skrivaren PX730.

Se till att det finns mycket hushållspapper/pappershanddukar till hands. Stäng av skrivaren och sätt på den på nytt. Då skrivaren börjar ge ifrån sig ljud som tyder på att något rör sig så drar man ut nätsladden till skrivaren (ca. 5 sekunder efter att man satte på skrivaren kan man normalt rycka ur nätsladden). Skrivhuvudet kan nu föras i sidled så att man kommer åt skrivhuvudet. Om skrivhuvudet fortfarande är låst så får man inte använda våld utan man stänger locket till skrivaren, kopplar i strömmen på nytt och upprepar processen tills man utan våld kan flytta skrivhuvudet till ungeför mitt på pappersbanan. Skrivhuvudet är normalt mekaniskt låst och mekaniken förstörs om man flyttar huvudet med våld.

Fig. 3 Skrivarens överdel som innehåller en scanner kan vinklas upp så att man kommer åt eventuella felmatade papper samt bläckkassetterna nere till höger. Bläckkassetterna på bilden är påfyllningsbara via de färgade korkarna vid kassettens övre ända. Man kan också se slangarna, ungeför mitt i bilden, som transporterar bläck till skrivhuvudet som i bilden är parkerat på korrekt plats under EPSON etiketten strax till höger om mitten. I samma knippe som bläckslangarna till skrivhuvudet finns också en flatkabel genom vilket skrivhuvudets munstycken styrs. Hålen närmast betraktaren är luftningshål. Man bör komma ihåg att ta bort skyddskorkarna till luftningshålen innan man börjar använda skrivaren. Glömmer man att öppna luftningshålen så får man skrivproblem efter en stund då det blir undertryck i kassetterna.

Bläckmatningen till skrivhuvudet kan lossas genom att skuva loss tre skruvar. Därefter har man en pappershanduk till hands och lyfter upp plastdelen till vilken bläckslangarna är kopplade och skjuter pappershandduken under delen så att man inte får stora mängder bäck in skrivaren.

Fig. Ungefär mitt i bilden syns nu skrivhuvudet efter att det försiktigt har flyttats i sidled. I skrivhuvudets nedre höra kant ser man bläckmatningen gjord i vit plast fäst med tre skruvar. En blank skruv i mitten och två svarta skruvar som man kan skymta i bilden. Man lossar de tre skruvarna och lägger en pappershandduk över skrivhuvudet pch låter slangknippet (den vita delen) ligga på pappershandduken vars uppgift är att suga i sig bläck som droppar från färgslangarna. Notera att ingenting behöver demonteras utan man lyfter försiktigt upp den vita komponenten fäst i slangarna på papperet. Kom ihåg att starta skrivaren efter reparationen så att den själv för tillbaka skrivhuvudet i parkerat läge!

Man tar nu en liten injektionsspruta fylld med t.ex. färgskrivartvättmedel med en kort slangstump som passar till färgnippan och presser långsamt och försiktigt in vätska i slangen. Slangen är tunn och det behövs inte mycket.

Fig. Rengöringsmedel på flaska och en liten injektionsspruta försedd med silikonslang som passar till nippeln under en bläckkassett. Man fyller den lilla sprutan med en lämplig mängd rengöringsvätska t.ex. 1,5 ml och ser till att slangen inte innehåller luftbubblor. Man trycker slangen på nippeln som färgkassetten var tryckt mot och pressar långsamt vätska genom ifrågavarande färgslang. Var noga med att inte pressa luft in i slangen, man behöver inte använda hela mängden vätska! Tag loss sprutan/slangen och sätt tillbaka färgkassetten. Om det behövs så upprepas processen för övriga färger som skrivhuvudtest har visat problem med.

Putsa kring den losstagna slangfastsättningen och montera komponenten tillbaka på skrivhuvudet. Kontrollera att det inte finns bläck under skrivhuvudet på pappersbanan. Putsa vid behov. Kontrollera också att det inte finns bläck utanför skrivhuvudets parkeringspalts. Putsa vid behov. Försök inte flytta skrivhuvudet tillbaka i normalläge det är låst. Sätt helt enkelt på skrivaren med locket stängt varvid skrivhuvudet automatiskt parkeras. Notera att om arbetet av någon orsak blir på hälft så bör man se till att skrivhuvudet parkeras korrekt eftersaom huvudet annars torkar om det är felparkerat.

Montera tillbaka den färgkassett du tog loss. Det går nu att göra en ”head clean” och test av skrivmunstyckena.

Notera! Om flera skrivhuvud verkar ha problem så lönar det sig att eliminera luft/fylla ledningarna för alla färger. Tag loss en kassett i taget och montera tillbaka kassetten innan du går till följande färg. Om man av misstag lyckas montera en färg på fel plats kan det vara extremt besvärligt att putsa ifrågavarande färglinje. Tag alltså inte bort alla kassettere samtidigt utan fixa en färg i taget och lägg tillbaka kassetten då du är färdig så att inte färgerna blandas. Jobba metodiskt med eftertanke och fixa en färg i taget. Notera att varje färgslang du luftar kommer att ge ett tillskott bläck på pappershandduken. Byt vid behov!

Slutkommentar

Det är alltid väldigt trevligt då man lyckas med en reparation. Jag hade jobbat med skrivaren för ett halvt år sedan utan att få den i skick. Jag hade tvättat skrivhuvudet men vissa munstycken fungerade fortfarande inte. Jag beslöt igår (10.2.2021) att göra ett sista försök att få skrivaren att fungera … alternativet skulle ha varit att skrota den. Test av munstyckena visade nu att alla munstycken utom den svarta färgen fungerade perfekt. Det gick inte att se ett enda svart munstycke som skulle ha producerat färg. Sannolikheten för att alla svarta munstycken samtidigt skulle kunna ha fel är ganska liten varför slutledningen var att den svarta färgen hade förgmatningen blockerad av en luftbubbla. Problemet löstes ovan. Jag gissar att tvättmedlet då det fick verka under lång tid löste upp torkat bläck på skrivhuvudena.

Orsaken till att jag kontrollerade skrivaren ”en sista gång” var att jag hade hittat ett demoexemplar av en ”Eco Tank” skrivare med fyra färger. Den lyckade reparationen gjorde att jag i praktiken sparade ca. 170 Euro! Ingen dum besparing för ca. en timmes arbete. Timlönen blev helt skaplig och ännu bättre var det att skattmasen åtminstone inte ännu beskattar ogjorda utgifter!

Reparation av en Pentax K5 kamera

27/11/2020

Pentax har i många år byggt fina systemkameror som ofta har varit vattentäta/väderskyddade. Statusmässigt ligger Pentax antagligen lite i skuggan av Nikon och Canon samt engefär jämbördigt med Sony. Pentax sägs ha en mycket pålitlig användargrupp som sägs bestå främst av äldre män som använde Pentax i sin ungdom. Pentax var en av de stora tekniska innovatörerna på 1960-70-talet dock så att Nikon på det professionella området körde förbi.

I likhet med alla moderna systemkameror så monteras objektiv via en snabbfattning, bajonett. Den av Pentax utvecklade K-bajonetten har använts på licens av flera andra tillverkare vilket betyder att man har tillgång till mängder av högklassig optik på den begagnade marknaden ofta för en spottstyver.

Min Pentax K5 stomme fick plötsligt ett fel. Den tryck-knapp som frigör objektivet lossnade och försvann. Kameran är helt användbar men för att byta objektiv behövdes en liten bit tex. pianotråd som man kunde använda för att trycka ner ett frigöringslås. Inte bekvämt och allt annat än vattentätt.

Jag vet att somliga Pentaxägare har fått reservdel gratis via Pentax men det har varit oklart vilka vägar detta har skett. Då jag googlade kring detta stötte jag på nedanstående länk:

https://www.thingiverse.com/thing:1731720

Länken går till en 3D-utskriven frigöringstangent. Eftersom jag har en egen 3D-skrivare så var det naturligt att testa om det här kunde vara en lösning.

Den 3D-utskrivna nya tangenten har en axel som är mycket tunn. Detta är oftast ett stort problem vid utskrift. Utskriften av en tunn spets går så snabbt att plasten inte hinner stelna mellan plastlagren vilket leder till att komponenten ändrar form och sjunker ihop. Lösningen på detta är väldigt enkel. Om man har något annat storre objekt som man kan skriva ut samtidigt så lönar det sig att göra detta. Det större föremålet ger tid för det lilla att svalna vilket höjer kvaliteten. Ett annat lika enkelt alternativ är att i stället för att skriva ut endast ett enda litet föremål så skriver man ut, i mitt fall nio st. Efter utskrift väljer man det exemplar som blev bäst.

Frigöringsknappen för objektivet syns nere yngeför vid kl. 7 strax vänster om objektivet. Den utskrivna delen är redan på plats då jag glömde att ta en bild av situationen före den nya komponenten monterades.

Notera hur jag skrev ut 9 st nya tryck-knappar av vilka jag använde endast en.

Belysningen råkar framhäva den sandpapprade sidan av den nya frigöringsknappen. I normal belysning reagerar man inte på att delen är 3D-utskriven och inte orginal.

Lyckat ”hack”! Det är alltid trevligt då man lyckas förlänga livet på en teknisk mojäng som har ett litet men mycket störande fel. Nu blir det naturligtvis intressant att se hur länge den nya delen håller.


Pointman's

A lagrange point in life

THE HOCKEY SCHTICK

Lars Silén: Reflex och Spegling

NoTricksZone

Lars Silén: Reflex och Spegling

Big Picture News, Informed Analysis

Canadian journalist Donna Laframboise. Former National Post & Toronto Star columnist, past vice president of the Canadian Civil Liberties Association.

JoNova

Lars Silén: Reflex och Spegling

Climate Audit

by Steve McIntyre

Musings from the Chiefio

Techno bits and mind pleasers

Bishop Hill

Lars Silén: Reflex och Spegling

Watts Up With That?

The world's most viewed site on global warming and climate change

TED Blog

The TED Blog shares news about TED Talks and TED Conferences.

Larsil2009's Blog

Lars Silén: Reflex och Spegling