RC/RC3600/Logbog

Fra DDHFwiki
< RC‎ | RC3600
Skift til: Navigation, Søgning

Mål / Hvad vil vi ?

Ideen med dette projekt at at få en RC3600 til at fungere. Bla. til at understøtte Privat:IDAG projektet.


Opgaver

Noter

Logbog

(i læsevenlig rækkefølge)


2013-01-31

Vi tog udgangspunkt i en ramme fra et rack med blandede nødder Rammen blev afmonteret og stillet på vores test bord, hvor vi vil gøre vores første armbøjninger med hardwaren, inden vi skal have ”disk” på.

Strømforsyningsopstart:

For at give en passende belastning monterede vi et AMX kort i kabinettet, så vi kunne checke, at strømforsyningen havde det godt. (RC3600 er baseret op switch-mode strømforsyninger, som opfører sig mærkeligt, hvis der ikke er belastning på). AMX kortet blev valgt som prøveklud, da vi har masser af den slags kort.

Vi satte strøm på dyret og noterede os at ”strømforsyning ok” LED’en på forsiden ikke lyste. Vi så også, at en af blæserne ikke roterede. Multimeteret sagde, at 5V så godt ud, men at +/- 12V var død.

Efter at have motioneret stik osv. måtte vi konstatere, at 12V kortet ikke virkede, hvorfor vi måtte på strandhugst i en anden 3600. Vi monterede en anden 716 (?) og tændte op igen og så straks, at LED’en var glad. En efterprøvning med multimetret gav LED’en ret :-).

CPU opstart

Det var nu tid til at montere rammen med CPU721, MEM720, AMX701 og TCP frontpanel, og efter, vi havde sat strøm på igen, kunne vi konstatere, at CPU’en rent faktisk kørte, og at 128K ord hukommelse virkede. Vi forbandt en terminalemulator på vores PC med TTY0 og gemte 65 i AC0 og udførte programmet DOA 0,TTO. Og sandelig om der ikke kom et flot A på skærmen.

Skift af blæser.

Resten af aftenen gik med at skifte den defekte blæser, hvor vi igen måtte på strandhugst i andre 3600.



2013-02-07

Dagens plan var at boote CPU’en fra den sekundære TTY port. Hvis vi kan få dette til at virke, kan vi slippe for at prøve at interface PTR. PH havde konstrueret et par kabler, som skulle forbinde vores pc com porte med TTY portene.

TTY test

Først prøvede vi at aktivere de interne TTY test programmer, som dels kan skrive linier med 80 tegn

!”#$%&’()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno

Og dels kan echo TTI->TTO, og begge testprogrammer fungerede perfekt. Herefter satte vi begge TTY’er op til at køre 9600 på jumperne i MEM720, og begge test programmer fungerede stadig fint.

Første boot.

Vi kiggede i en række strimler, vi har arvet fra Ballerup kommune og valget faldt på et testprogram, som kunne måle timing på samtlige instruktioner i CPU’en. Test programmet var interessant, fordi vi både kunne boote fra TTI1 og se programmet benytte TTY0.

Vi forsøgte at hælde strimlen i hovedet på TTY1, men boot loaderen lod kun til at læse de første få ord. Vores konklusion var data-overrun, da der ikke er flow kontrol på TTY portene. Vi forsøgte at sætte hastigheden ned til 1200 igen, men det hjalp ikke. Herefter blev der sat throttle på afsendelsen af tegn (wait imellem hver tegn), men det lykkedes stadig kun at få de første få ord ind i hukommelsen. Så var det, at det gik op for os, at bootloaderen var 2 delt i en bootstrapper og en egentlig loader. Problemet var at bootstrapperen korrekt tog device nummer (=TTY1) fra switchene på TCP’en (og virkede derfor korrekt). Den bootstrappede loader havde PTR hard coded :-(. PH byggede en on-the-fly udskiftning af device no i de IO instruktioner, der kom forbi throttlen. Og så YES, så virkede det !!! Selv med 9600 og uden throttle :-)

AMX test

Næste opgave var at prøve, at få AMX test programmet til at virke, men det lykkedes ikke. CB skriver en lille stump kode til næste gang, der kan motionere en AMX port.

Vi prøvede med andre testprogrammer uden held, da det viser sig at der er en række forskellige loadere, som vores on-the-fly conversion ikke fik fat i. Vi overvejer om, vi skal give PC->USB->Parallelport->noget logik->PTR port et forsøg alligevel…


2013-02-14

  • Mogens Pelle (COMAL80/Butler) kom forbi – vil gerne deltage i COMAL take #2.
  • Nye borde - flytte RC3600 opstilling dertil.
  • Prøve PTR500 direkte
  • Skære kabel over så det kan interface med PC printer port, men stadig virker ”lige igennem”. Forbinde handshakes til fornuftige handshakes i Centronix.

2013-02-21

  • Opsætte Bærbar til multiboot (Win/FB91)
  • Kort Nico gennemgang af Mediakonverter – konklusion PHK raw reader er bedre.
  • Forsøge at få PC til at tale med RC3600, men kan ikke få PPI til at virke over USB/LPT i FreeBSD – Finder dock med LPT til bærbar næste gang.
  • Lodde kabel (uden læsebriller :-()
  • Fedte med at få FB91 ordentlig op og køre med X, KDE osv.

2013-02-28

  • Finde dokumentation på PTR500 (tak Finn) for at se logik i anden ende af kabel (se vedlagte)
  • Dock + PPI fungere perfekt – eksperimenterer med at få LPT port til at køre passende og finde ud af hvilke Centronix signaler vi kan binde på de tre kontrolsignaler CHARREQ, CHARRDY, !PTRRDY (se vedlagte).
  • Skrue på C program til at uploade kode til RC3600.

Tanken var, at vi kunne laver programmer i emulatoren og enten linke disse i ABS format til direkte boot eller simpelhen dumpe emulator RAM med tilhørende registre og så uploade hele molevitten til RC3600. Vi vil til sidstnævnte løsning have brug for at kunne konfigurere emulatoren til kun at bruge 63k ord, så den sidste k kan bruges til boot loader. Boot sekvens bliver herefter

  1. Reset+Load læser std boot i adr o0-o37
  2. stdboot loader vores boot i o100-o377
  3. vores boot flytter op o177700 modtager 0-o77777
  4. vores boot initialisere resten af cpu state registre, imask, IP, IOStat eller kan vi bare lave en IORST ? Det giver nok nogle fejl, men de kan vel overleves, Alternativt skal vi fange CPU i ildelokationen i emulatoren, før vi dumper.

2013-03-07

  • Vi fik kablet
    kabel mellem rc3600 ptr og PC printer port
    til at fungerer således at en PC nu kan agere PTR500 og oploade en fuld memory på 10sek :-)

Ideen med at flytte et live image fra simulatoren kan let realiseres ved at benytte "power-fail" i emulatoren og så dumpe memory til disk når koden udfører en HALT. Da simulatoren kører 32kord kan vi blot flytte vores boot loader op over 32kord.


2013-03-14

(Ingen RC3600 aktivitet, da aftenen gik med at overføre filer fra en gammel Atari)


2013-03-21

(Færdiggøre Atari overførsel)


2013-03-28

(Påske)


2013-04-04


2013-04-11

  • Flytte udstyr til reol så vi kan frigøre arbejdsbord.

Status til generalforsamling

Projektet startede for alvor op i begyndelsen af Januar, hvor PH og jeg fandt diverse hardware frem fra diverse konfigurationer, vi har i arkivet.

Målet er en kørende RC3600 i samme konfiguration som den maskine både PH og CB trådte vores barnebitsko i på Slagelse Gymnasium anno 1978-1982. Konfigurationen er sat udfra det, der er nødvendigt for at kunne afvikle IDAG på maskinen:

Hardware - CPU med mindst 32kWord og standard enheder (TTY0, TTY1, RTC, PTR, PTP) - AMX med otte serielle kanaler - En floppy station med 2 drev, således at vi kan afvikle MUS baseret RC-BASIC - DCC701 / DCA701 Diablodisk, således at vi kan afvikle DOMUS baseret RC-BASIC

Software: - DOMUS med rel. linket RC-BASIC - MUS med abs. linket RC-BASIC


2013-08-15

Jeg har lavet et særskilt projekt for RC/RC3600/Turbo-Diablo delen.

I den forbindelse får jeg brug for et "DKP-exerciser" program der kan kommanderes rundt med og jeg er begyndt at skrive et sådant.

Da min PC ikke har en parallel port kan jeg ikke AUTOLOAD'e fra vores snyde-PTR, men TTYI/TTYO device er 8-bit clean og man kan derfor fint autoloade fra den også.

Jeg har nu den mest bizarre tool-chain jeg nogen sinde har brugt:

  • Et shell-script laver en '_.ptr' fil ud af min kildetekst (CRNL, NUL leader/trailer, TAB expansion)
  • I RC3600 emulatoren med et DOMUS image kører man 'DOMAC BIN.$PTPN LIST.$TTY $PTRN'
  • Den resulterende '_.ptp' fil køres igennem et python-script der lave en AUTOLOAD kompatibel "hulstrimmel" (NUL leader/trailer, start byte, længde-ord)
  • Denne kan derefter AUTOLOAD'es via PTR eller TTYI i emulatoren eller på den "rigtige" maskine.

Det må kunne gøres nemmere...

/phk


2014-10-24

(arbejdet med at få en matrix verision op at køre er nu droppet til fordel for en lettere omskrivning af den oprindelige kode)

(Status på det emulerede miljø med billede af alle skærme)


2014-10-30

(...Father, it has been a while since my last confession...)

I aften tog vi fat på at få $MCDR på benene. I den anden ende af $MCDR sidder en RC3671C stregkort/hulkortlæser, som skal bruges til at læse løbskort i det IDAG projekt, vi gerne skulle have til at køre på vores RC3600, når det store COMAL event løber af stabelen næste år.

RC3671C er en relabled DOCUMATION TM-200, og da vi til vores skræk ikke kunne finde noget dokumentation i vores wiki arkiv på læseren, gik vi på bitsavers og fandt heldigvis en fuld manual på DOCUMATION M-200, som - så vidt vi kan vurdere - er præcis samme maskine, - dog uden mulighed for at læse stregkort.

Første opstart

Vi startede op med den normale procedure med variotrafoen på 170V, men det var lige i underkanten for at få blæseren, der skal separere kortene, til at køre. Op på 190V og så skete der noget.

  • Lamptest ok
  • Kortene blev løftet ok
  • Microswitch til lokal (operation) ok

Og så tryk på [reset] for at prøve om den kunne læse nogle kort, men så stoppede festen - det gad den ikke. Vi prøvede med kortene vent på andre måder og med mere eller mindre tryk på indbakken uden held. Først, da vi simpelhen skubbede kortene ind i halsen på korttransporten, fik rullerne fat og kortet smuttede igennem. Feederskoen kørte heller ikke hvergang, men med lidt manuel motion, kom den til at køre bedre.

Af med beklædningen og her kunne vi se, at det hele så fornuftigt ud pånær feederskoen, som vi ikke var klar over, om den havde den rigtige vandring. Mere skomotion og vi blev enige om, at det ikke var helt ved siden af. Vi noterede os, at vi ikke kunne føle vacuum på skoen, selom den er perforeret på en hel flade. Vi monterede beklædningen igen for at undgå falsk luft, og nu var den faktisk bedre til at føre kort igennem, men stabiliteten var stadig dårlig. Vi prøvede igen med forskellige kort, feedertryk osv. - uden held.

Under operationen fik vi også variotrafoen op på normal spænding (mærkepladen fra '76 siger faktisk 230V!) for at se, om blæser/vacuum kom til at virke bedre. Det hjalp dog ikke, og konklusionen var 'synkronmotor'. Vi fik da testet at elektrolytter ikke var konverteret til kinapuf.

Efter at have forsøgt en god halv times tid prøvede PH at trykke på en gummirulle, og den var blød som smør. Ved nærmere eftersyn viste det sig at gælde for alle fire gummiruller. Øv! - Pause indtil vi får hekset nogle nye ruller.

Næste gang bliver værkstedsbordet ryddet, så vi kan skille fætteren ad og få metalkernerne i gummirullerne ud, så vi kan sende dem til regummiering. Vi har fundet en lokal 'gummimand' i nærheden af Tapeten.


2014-11-06

(skille dyret ad + billeder)


2014-10-20

(skaffe gummiruller og færdigrense)


2014-10-27


2015-01-29

Vedr. FD703 test, strimlen vi har er -1635 og i forhold til dokumentationen for -1669 "mangler" der nogle tests.

på -1635 er...

start addresse 0405 er "skift I/O addresse"

start addresse 0406 er "skriv test-diskette"

  • RCSL 52-AA 899 RC3600 CPU 720 EXT TEST
   Kørt "15 PASS OF 10 RUNS"
   Strimlen autoloader og kører automatisk, hvis man sætter switches til 0
  • RCSL 44-RT 1647 RC3600 EXTENDED MEMORY TEST
   Kørt "5 PASS OF 5 RUNS"

2015-02-01

Og jeg har samlet kortlæseren (flere gange :-)), og korttransporten ser ud til at være fin, men et eller andet i logikken gør, at den kun vil læse præcis to kort, før den melder "Pick Error". Det er lige meget, om jeg bruger stregkort eller hulkort, og jeg har vist prøvet stort set alle kombinationer af switchsettings (bag på) med samme resultat.

Jeg tror, at der er noget galt med den sensor, som skal holde øje med om der er plads i udbakken. Selv om jeg holder et kort i udgangsslidsen af læseren, læser den stadig sine to kort. Hvis sensoren også bruges til at konstatere, om der rent faktisk kommer et kort helt igennem, kunne det være grunden til at den stopper efter 2 kort. Der er ikke direkte noget i trouble-shooting-tabellen, der adresserer dette. Jeg må studere manualen igen.

2015-02-05

AMX

Hul igennem efter at io-adressen på AMX702 blev sat til 8#52 (switche var inverteret). Kanal 0 virker ikke uanset om der udskiftes til AMX702 fra SG - der er enten fejl på kabel mellem kortkant og stik eller mellem stik og RS232 fordelerpanel. Men de andre kanaler virker fint, når CO046 eller CO048 bootes op (testet kanal 1 og 2)

15.02.05,  19.09.43:  TERMINAL 01 IDLE??
ATT BASIC� REV. 01.24
READY           
15.02.05,  19.16.13:  TERMINAL 02 IDLE

Selvom vi ikke skulle få kanal 0 til at virke burde det være muligt at køre med kanal 1-4 istedet for 0-3.

Floppy

Drev 1 er sat til og ser ud til at virke.

Der er udført en fuld diskcopy fra 0->1 af en boot diskette (SG0114) og den nye diskette booter fint i drev 0.

>FDCOP
FROM UNIT: $FD0
TO UNIT: $FD1    
>S
KILL FDCOP

Boot

DOMUS REV 02.01
>S
BOOT CO046
>COPS
CORE: 08623, TERM 32: 4000
CORE: 04623, TERM 01: 2000
CORE: 02623, TERM 02: 2000
DATE (YY.MM.DD)=
TIME (HH.MM.SS)= ??
00.00.00,  00.00.00:  TERMINAL 32 IDLE

Referencer

Tak

Fodnoter

Skabelon:Reflist