anders_bzn skrev:Jag ska ta med banden nästa gång jag är i museet. Om det är något intressant på dem får du låna dem när du fått igång TU60. Motprestationen blir att dela med dig av innehållet.
Perfekt. Jag ska göra mitt bästa för att läsa kassetterna. Fast som sagt först måste jag ju få igång TU60 bandstationen. Jag har spenderat en hel del tid med den den senaste tiden.Till en början med så gick det utmärkt spola kassetten till startläge med hjälp av knappen på framsidan. Men plötsligt så slutade drive 1 att fungera. Motoraxeln hade tappat fäste i drevet som fick kassetten att spolas tillbaka. Enligt ritningen skulle där sitta en stoppskruv med måtten #2-56 1/8. En inte helt vanlig skruv här i Sverige. Det skulle gå att beställa den från USA, men det var ju lite krångligt så jag fokuserade på drive 0 som i alla fall spolade bakåt , men inte speciellt mycket framåt.
För att testa en TU60 finns ett diagnostikprogram , ZTAAC0 som man kan ladda med hjälp av XXDP. Diagnostikprogrammet visade på problem med EOT/BOT indikeringen och mycket riktigt så hade en DEC8881 (7439) lagt av och ett byte av den gjorde att diagnostikprogrammet i alla fall kom vidare men inte tusan rörde sig drive 0. Det var fler problem. En TU60 har två motorer som driver den. En är till för att bara spola tillbaka och hålla bandet i spänn. Den andra driver framåt. Efter en längre tids ytterligare felsökning så hittade jag den 75452 open collctor drivare som kontrollerade Forward motor servot som hade gett upp.
Väl där så lossnade även motoraxeln för drive 0! Nu var båda trasiga. Lite mer studier av ritningar gav att man kanske inte använt en stoppskruv utan kanske limmat fast dem med Loctite. Inköp av Loctite, och se det fungerade utmärkt.
Nu gick det att köra diagnostiken ZTAAC0 utan fel på båda drive 0 och 1. Men inte ZTABC0. Problemet med diagnostikprogrammen är att de inte är helt lätt att tyda fel utskrifterna. Vad är det egentligen som är fel? Jag började skriva små egna testprogram i assembler. Ett program skrev kontinuerligt 0 .. 255 på bandet och ett annat läste tillbaka vad som skrivits. Logikanalysatorn berättade att den faktiskt lyckades läsa tillbaka korrekt data så man kan nog säga att en hel del fungerade. Men det är fler operationer som måste fungera. Att skriva längre assembler program var inte lockande. Det behövs en massa debugging för att få dem att fungera, i alla fall för mig som aldrig kodat pdp-11 assembler.
Jag är mer av en C kodare så jag började leta på nätet och fann den här sidan,
http://www.diane-neisius.de/pdp11/index_E.html#xinu, som inspirerade mig.
Jag började med att ladda ned Binutils 2.24 och GCC 4.8.2. Dessa packade jag i upp en folder "src" och därefter byggde jag först binutils med:
Kod: Markera allt
src/configure --target=pdp11-aout --disable-nls
make all
sudo make install
och sedan GCC
Kod: Markera allt
src/configure --target=pdp11-aout --disable-nls --without-headers --enable-languages=c
make all-gcc
sudo make install-gcc
Man behöver C-start kod också, crt0. Jag gjorde minsta möjliga som initierar stackpekaren:
Kod: Markera allt
.text
.globl _main, ___main, _start
_start:
mov $400,sp
jsr pc, _main
halt
___main:
rts pc
Jag hittade även den här printf rutinen
http://www.sparetimelabs.com/tinyprintf/tinyprintf.php. När jag kompilerade allt visade det sig naturligtvis att gcc saknade rutinerna för multiplikation, division etc, ___mulhi3, ___divhi3 etc. Jag knåpade ihop några sådana rutiner men när jag kompilerade dessa med gcc inställd för att generera PDP11/10 kod så kraschade kompilatorn. Enda sättet var att generera kod för PDP-11/40 och därefter byta ut de operationer som inte stöds av PDP-11/04, t ex ASHC och SXT.
Därefter kompilerade jag mitt lilla testprogram:
Kod: Markera allt
pdp11-aout-gcc -m10 -Ttext 1000 -msoft-float -nostartfiles -nodefaultlibs -nostdlib crt0.s printf.c test.c divmulmod.s
pdp11-aout-objcopy -O binary a.out hello.dmp
Jag talade om för länkaren att relokera koden till address 1000 hex eller 10000 oktalt och därefter fick jag objcopy att extrahera en ren binärdump av filen som jag kunde ladda in senare.
Ett test i E11 visade att programmet verkade fungera och sedan ett test på den verkliga maskinen med hjälp av PDP11GUI för att ladda programmet.
Perfekt. Printf fungerar! Fast om man tänker efter så är det ju inte mer magsikt än att få t ex en AtMega32 att göra samma sak.
Nåja, jag var nöjd. Nu kan jag gå vidare och tillverka mina egna testprogram för TU60 driven och till och med bygga ett program som läser filer via en serieport och skriver på ett band. På så sätt skulle jag kunna rekonstruera en bootbar CAPS-11 kassett, eller för den delen läsa ut innehållet på ett okänt band i CAPS-11 filformat.