Hur fungerar ABCs kontrollerkort? ( Kretsschema för kontrollerkort?)

7 posts in thread

• Erik Lundh · Msg 166 · inlagg

  2008-11-08 15:08

  Ärende: Hur fungerar ABCs kontrollerkort? ( Kretsschema för kontrollerkort?)

  Hej, jag heter Erik Lundh. På 80-talet gjorde jag mycket reverse-engineering och lågnivå hack på ABC-datorerna. Särskilt på diskkontrollers. Någonstans har jag kanske t o m kvar mina handkpommenterade disassemblat till någon eller några kontrollers. Jag skrev lite olika varianter på ”intelligenta” disassemblers samt en relokerande länkare (för .REL filer), något som Luxor inte hade själva. Diab hade en hel del av verktygen, ex länkaren för relokerbara filer, enbart i andra miljöer, tror det var antingen Unix eller det egna realtidsoperativet för Z80 (OS8). Till saken: Jag ser att ni jobbar på att få koll på flexskiveenhetens kontroller. Då skall ni veta att det på kortet finns en specialkrets som är ett slags hårdvaruskydd. Kretsen är en del i MFM-kodningen om jag minns rätt. På ett antal ställen i kontrollerprommet finns i/o inlagt som vad jag minns ställer kretsen i olika lägne och förväntar sig svar tillbaka på något sätt. Koden går vilse om kretsen inte svarar. Kretsens funktion (MFM?) havererar om koden inte vid rätt tillfällen gör I/O mot den. Denna kretse designades av Diabs grundare Lasse Karlsson och har vad jag minns beteckningar från någon italiensk firma. Det tog mig ganska lång tid att klura ut hur det hängde ihop. Jag vill minnas att Luxor tvingades köpa specialkretsarna från Diab. Ett sätt för Diab att hålla koll på royalties. På de flesta flexskivekontrollers som kom till Abc800 kunde man dessutom ladda ner egna Z80-program som exekverade i en av diskbuffertarna. För Luxors och Diabs produktion av kopieringsskyddade disketter fanns specialversioner av prommarna som kunde skriva vissa bytes mellan sektorerna. Jag tror detta skapades redan på ABC80-tiden. Standardvärdet var 0, men specialprommarna kunde skriva andra värden. Alla kontrololers kunde sedan läsa värdena. I och med att man kunde ladda ner egfna program i ram kom vi på hur vi kunde skriva dessa bytes från ramladdade kontrollerprogram, med prommet som library. Luxor hade stora produktionsmaskiner, autoloaders för 5,25 disketter, som körde fram kopieringskyddade disketter med specialprommarna. Mitt sista jobb 1984 var att ta fram ett kopieringsskydd som man inte kunde reproducera med specialprommarna. Kunderna var Pdata & Rtb, skaparna av Basregister och ord. Båda företagen hade investerat i helt nya produktgenerationer av databas resp ordbehandlare. Men Luxor ville att dessa nya produkter skulle ingå i det befintliga, för Luxor mycket gynnsamma, avtalet mellan Luxor och de två bolag som sålde program till i stort sett varje levererad ABC-maskin. Med mitt nya programskydd kunde Pdata och RTB gå förbi Luxor direkt till återförsäljarna. Luxor hade annars inställningen att man tänkte ta alla de program som RTB och Pdata skapade och köra dem i sin produktion. Deras återförsäljare skulle sedan givetvis köpa från Luxor. Men då man inte kunde producera skivor, gick återförsäljarna direkt till programförfattarna. Jag fick totalt max ca 20 000 för jobbet som tog månader. Pdata fick en kraftig vinstökning året efter. Jag har lärt mig ta bättre betalt sedan dess. BTW: Jag hittade denna lista sedan jag och några andra veteraner funderat på att emulera en ABC800 i java. Jag är ju sedan ca år 2000 djupt involverad i agile och tänkte att en komplett emulering av en Abc-maskin, utvecklad med test-driven utvecklingsmetodik (tdd) vore ett intressant exempel. Varför java? Jo därför att det är bekvämt att arbeta med saker som refactoring i det språket. Eclipse finns ju fritt. Trots att jag är gammal C++ veteran ser jag att det just nu är enklare att utveckla modernt och disciplinerat med tdd och refactoring i java. Prestanda är troligtvis fortfarande bättre i native kompilerad kod. Men utvecklingstid och värdet av exemplet blir troligtvis mycket bättre i java. Mvh /Erik Lundh Hej på er! Jag har också funderat lite i liknande banor. Har faktiskt just nu ett sd-kort inkopplat till ett abc-lab kort, med lite motstånd och en 3.3V späningsregulator. Det BÖR fungera men jag har inte hunnit testa än. Nackdelen är att man måste flippa bitarna själv och skifta in/ut dem till bytes. Jag kör helst också så mycket hålmonterat/experimentkort som möjligt. Men varför inte satsa på något enklare programmerbart, som t ex en CPLD i stil med EPM 7064. De finns som plcc, och såna socklar kan man ju löda in. Har funderat lite på att göra ett dylikt kort, som i princip är ett enkelt SPI-interface (som SD/mmc kort stödjer) för abc-bussen. Det borde bara bli CPLD:n och en 3.3V spänningsregulator + sockel för SDkorten. Dock är jag kass på VHDL, men jag har sett att det finns färdiga SPI-rutiner. Sen kan man ju sköta resten med mjukvara... En annan rolig grej som har kommit på senare tid är vinculum från FTDI som är USB-host kretsar. Jag har köpt en VMUSIC2 (se ELFA) som förutom host-interface till USB-stickor innehåller drivrutiner för FAT-filsystem och en MP3-spelare. Den pratar också en variant av SPI. Har gjort ett testprogram i basic för ABC-lab för den men det funkar inte. Projektet väntar just nu på lite mer tid... Nackdelen/fördelen är att man kör FAT-filsystem. Jag är ingen varm anhängare av ABC:ns disksystem. Man skulle ju egentligen bara kunna knåpa ihop en enkel ABC-device i stil med den UNX:-enhet som finns till den där gamla x-windows emulatorn. Robert <http://www.abc80.org/mailman/listinfo/abc80> hpa at zytor.com] <http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&Category N> &CategoryN http://www.abc80.org/mailman/listinfo/abc80
  • juhasz · Msg 167 · kommentar

    2008-11-08 16:35

    Ärende: Hur fungerar ABCs kontrollerkort ? ( Kretsschema för kontrollerkort? )

    Kul att ABC-listan börjar vakna vid liv! Jag har av och till hackat på lite ABC-emulatorer, bl a en i java. Tyvärr är koden väldigt "hack"-ig, och jag har t om tappat bort vart jag fick Z80-emuleringsklassen från. Men man kan kolla in koden på sidan. Huvudklassen heter "Simple"..... http://juhasz.se/abc80/jabc80.zip Kan inget om testdriven programmering, men skulle vara kul att vara med och bygga på något mer riktigt i java. Kan också säga att jag hackat lite i c, och där lyckats emulera vissa delar av abc806 och en diskkontroller så pass att jag kan använda HPA:s diskimage från FPGA-projektet, i alla fall för läsning. Skrivning fungerar dock inte. Den koden (kör SDL och är just nu kompilerad på mac) finns på http://juhasz.se/abc80/rabc80.c Båda koderna har stöd för UNX:-devicen från den här gamla x-windows emulatorn som ligger på devili.iki.fi (abc80-1.2) Robert
    • Erik Lundh · Msg 168 · kommentar

      2008-11-08 19:34

      Ärende: Hur fungerar ABCs kontrollerkort? ( Kretsschema för kontrollerkort?)

      TDD innebär att man bestämmer, i alla steg från det lilla till det stora, hur resultatet skall vara innan man försöker koda upp en lösning. Själva tankeprocessen att faktiskt bestämma sig för ett resultat verkar hjälpa de flesta att förenkla kodningen och höja kvaliteten. Testerna blir även en slags dokumentation. Jag och andra förordar att man dokumenterar api-er och bibliotek med en serie tydliga tester (i tdds anda, se nedan) som visar vilket beteende man kan förvänta sig. Det är lättare att hålla ajour än dokumentation. Dessutom är det lätt att fylla på testsviterna när man behöver något nytt beteende. Sedan är det bara att koda tills de nya OCH de gamla testerna funkar, så är koden bakåtkompatibel. Man måste inte, nej oftast SKALL man INTE, försöka beskriva allt beteende (alla tester) up-front. Det blir ofta bäst om man spontant beskriver de resultat man kan tänka sig, börjar koda lösningar för de testerna, och sedan skriver fler tester när insikterna ökar undre kodningen. Ordet "test" i test-driven development har tyvärr fått många att tänka i test-termer varför agile-profilen Dan North började jobba med en annan semantik för att uttrycka det många av oss fattade redan med TDD. Han kallar det BDD som står för behaviour-driven development. Resultatet blir detsamma som för de som fattat andemeningen redan med TDD, men BDD vinner en del som annars inte sett ljuset. Att beskriva hårdvara i en emulator är ett bra exempel på att söka resultat och koda tills man ser att testerna säger ok. Fungerar inte emuleringen, får man skapa nya tester som beskriver beteendet och sedan uppdatera emuleringskoden så att alla tester går igenom. TDD började med enhetstester och det mest populära ramverket i java för detta heter Junit (följer med i Eclipse och alla andra javamiljöer) Min gode vän Ward Cunningham, som även uppfann wikin, skrev FIT, ett ramverk för tdd på högre nivå, nämligen på acceptanstestnivå. Detta ramverk har sin mest populära förpackning i fitnesse. (www.fitnesse.org) Båda nivåerna av tdd är "wiki-enkla" att börja med. När jag först såg wiki på Ward's site c2.com, fattade jag inte poängen. Först när jag haft nytta av wikis gick ett stort aha-ljus upp. TDD generellt och Wards skapelser i synnerhet funkar så. Ward gjorde förresten succé på Intel genom att tdd-a en video-krets . Först i java, sedan i en microcontroller från atmel, och sist i en FPGA. Historien var att Intel bett Ward presentera principerna för Tdd för den utvecklingsenhet som gjorde Intels videokretsar. Publiken var intresserad och visste att Ward var skarp och smått legendarisk. Men tdd kunde ju inte funka hos dem. Ward gick hem och funderade. Sedan test-drev han fram en videokrets som ritade en cirkel på en vanlig TV, i tre miljöer. Hur presenterade han resulattet? Massor med PowerPoint som en slägga i huvudet? "Ha, ni har fel och jag har rätt!"? Nej, på typiskt Ward-maner stoppade han microcontroller-kortet i ena fickan och fpga-kortet i andra fickan. Sedan knallade han ner till Intel-gängets öl-kväll. Vid lämpligt tillfälle började han snacka med någon om hur kul det är när kod snurrar på flera plattformar. Det slutade med att man drog fram en tv och kopplade in Wards kort. Någon undrade hur han gjort det så snabbt utan speciella videokretsar. Varpå wrad kunde visa hur han lagt upp arbetet med FIT och fixat det från scratch på någon dag... Att emulera en ABC-maskin med både huvudprocessor och hjälpprocessorn i kontrollern fullt ut borde vara en kul uppgift. Det ultimata acceptanstestet för en abc800-emulator vore förmodligen att köra de sista utgåvorna av basregister och ord i emulator, då de till största delen är skrivna i assembler, och dessutom skyddade av mycket lurig kod i själva produkterna (som inte jag skrev) som läser av de disksignaturer som mina program skapade på skivorna. Ännu coolare, men orealistiskt vore att modellera hela ABC800, utan att använda prommarna. Jag skrev ju en del verktyg som masserade BASICII:s p-kod, te x egna versioner av squeeze och unsqueeze. Men det blev aldrig någon hel BASIC-tolk. Jag skall titta på de olika källkoderna med stort intresse! Tack! /Erik From: juhasz at abc.se [mailto:juhasz at abc.se] Sent: den 8 november 2008 17:36 To: Erik Lundh Cc: abc80 at abc80.org Subject: Re: [abc80] Hur fungerar ABCs kontrollerkort? ( Kretsschema för kontrollerkort?) Kul att ABC-listan börjar vakna vid liv! Jag har av och till hackat på lite ABC-emulatorer, bl a en i java. Tyvärr är koden väldigt "hack"-ig, och jag har t om tappat bort vart jag fick Z80-emuleringsklassen från. Men man kan kolla in koden på sidan. Huvudklassen heter "Simple"..... http://juhasz.se/abc80/jabc80.zip Kan inget om testdriven programmering, men skulle vara kul att vara med och bygga på något mer riktigt i java. Kan också säga att jag hackat lite i c, och där lyckats emulera vissa delar av abc806 och en diskkontroller så pass att jag kan använda HPA:s diskimage från FPGA-projektet, i alla fall för läsning. Skrivning fungerar dock inte. Den koden (kör SDL och är just nu kompilerad på mac) finns på http://juhasz.se/abc80/rabc80.c Båda koderna har stöd för UNX:-devicen från den här gamla x-windows emulatorn som ligger på devili.iki.fi (abc80-1.2) Robert <http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&Category
      • juhasz · Msg 170 · kommentar

        2008-11-09 03:29

        Ärende: Hur fungerar ABCs kontrollerkort ? ( Kretsschema för kontrollerkort? )

        Tack för kraschkursen i TDD! ;) Fast för emulatorer så är ju ofta målet specat på ett sådant sätt ("jag vill kunna köra programmet ZZZ för det gjorde jag för NN år sen och det var kul!) För ABC80 tror jag de ultimata testerna vore att köra RULLE.BAS (talsyntes), HIGHREZ.BAC (hugo wikströms ABC-demo med processorgenererad högupplösningsgrafik a la ZX81), eller MTASK.BAS (multitasking). Till detta krävs det att interrupter funkar väl förutom grundläggande emulering av hårdvaran. För ABC800 vet jag inte vad de ultimata testen är... Vanliga applikationsprogram tror jag är ganska lätt att få att fungera. T ex funkar kombinationen TED och ASS fint på en ganska basic emulator trots att de är rätt stora (och användbara) program... Men skrivbara diskar som funkar med UFD-dos vore ett mål. Robert
        • H. Peter Anvin · Msg 171 · kommentar

          2008-11-09 05:29

          Ärende: Hur fungerar ABCs kontrollerkort ? ( Kretsschema för kontrollerkort? )

          juhasz at abc.se wrote: Jag har som sagt skrivbara diskar som funkar med UFD-DOS i min FPGA-modell. Jag kan inte, och kommer troligen aldrig att kunna, köra HIGHREZ.BAC helt enkelt för att jag kör skärmen på VGA-timings (400/449 linjer, 60 Hz) i stället för ABC:s modifierade PAL-timings (240/312 linjer, 50 Hz.) Jag emulerar en UFD-DOS-kompatible HD disk (HD0:..HD3:) och kan följaktligen inte formattera, men det behövs inte. Alla program jag prövat fungerar; det största problemet är att ABC-klubbens port av UFD-DOS till ABC80 använder halva POKE-arean; det skulle gå att fixa utan större problem genom att mappa in ett stycke RAM i lägre halvan av minneskartan. -hpa
          • juhasz · Msg 172 · kommentar

            2008-11-09 12:22

            Ärende: Hur fungerar ABCs kontrollerkort ? ( Kretsschema för kontrollerkort? )

            Kan du guida lite till hur det är uppbyggt i din kod? Skulle vara intressant att se. Jag har kollat på din kod tidigare, men är som sagt kass på vhdl/verilog, så jag ser inte riktigt hur din modell ser ut. R
            • H. Peter Anvin · Msg 173 · kommentar

              2008-11-10 00:17

              Ärende: Hur fungerar ABCs kontrollerkort ? ( Kretsschema för kontrollerkort? )

              juhasz at abc.se wrote: Först, se artikeln i ABC-bladet som jag scannat: http://www.abc80.org/docs/kontrollern.pdf Själva hårdvaran (Verilog) är en DMA-motor som helt enkelt låter CPU:n på kontrollern programmera in ett antal bytes som dator-CPU:n ska läsa eller skriva via OUT#/OUT 0 eller DATA#/IN 0. Det finns också lite logik för att driva statusporten, STATUS#/IN 1. Resten sköts i kontroller-CPU:n program, som är Z80 assembler. I "utgångsläge" (efter RST#/IN 7 eller C3#/OUT 4) väntar den på att fyra bytes ska skrivas som är kommandot per artikeln från ABC-bladet som jag scannade häromveckan. Som sagt implementerade jag bara kommandona 0-3, som representeras av bittar. Här är det viktiga med det: om mer än en bit är satt, ska man utföra kommandona i ording, från bit 0 framåt. UFD-DOS skickar normalt kommandona 0+1 eller 2+3 i en operation (03h eller 0Ch). Kommando 0 är "läs sektor från skiva till buffer". Kommando 1 är "läs sektor från buffer till dator". (följs av 256 bytes IN 0). Kommando 2 är "skriv sektor från dator till buffer". (följs av 256 bytes OUT 0). Kommando 3 är "skriv sektor från buffer till skiva". Till syvende och sist är det rätt klart att i alla fall UFD-DOSet inte använder några av de finesser som kontrollern faktiskt har; om inte ABC-bussen hade varit så beskuren jämfört med den lokala Z80-bussen hade det nog varit betydligt billigare och snabbare att låta huvud-CPUn sköta skivhanteringen. -hpa