Ja det är alldeles för sällan det skrivs nåt här, så här kommer lite bilder på ett annat datorprojekt jag hittade på som omväxling från den stora datorn. Jag ville få nånting byggt som fungerade, så jag svängde ihop en liten mikrodator med en 6502-processor, lite RAM och EEPROM, och ett par serieinterface: http://www.update.uu.se/~bjarni/temp/6502-dator/ Brum heter den. Den har 32K RAM, 8K EEPROM, två RS-232-interface, och en behändig kontrollpanel som jag använde för att bootstrappa programmerandet. Som det är nu har kontrollpanelen bara funktionalitet för att läsa och skriva i minnet, men det finns lite förberett för instruktionsstegning och lite andra mindre funktioner. EEPROMet kan skrivskyddas med en jumper och skyddet kan även slås på och av med en särskild signal på bussen som jag tänkte koppla till en knapp på panelen. Serieinterfacet använder sig av två stycken 6402-UARTar, vilka jag valde för att de har alla kontroll- och statussignaler utdragna till egna pinnar istället för register man måste pilla med för att konfigurera gränssnittet, vilket gör att jag har kunnat designa det så att portarna kommer upp automatiskt förkonfigurerade för 9600 8N1 efter strömtillslag, vilket är en angenäm bekvämlighet. Varje port har fyra skrivregister [data, handskakning, baudrate, kontroll] och fyra läsregister [data, handskakning, status, reset]. Reset görs alltså med en läsning, för att det var bekvämt att implementera i hårdvaran och det fanns ett ledigt läsregister. Handskakningen är bara två utgående och två ingående GPIO-signaler, som man egentligen kan göra vad man vill med men som kan användas till RS-232-handskakning om man behöver. I och med att de är helt mjukvarustyrda kan man göra både gammaldags assymmetrisk handskakning och modern symmetrisk handskakning. Nivåkonverterarna är inte installerade än, så just nu är det bara dataledningarna som funkar, men det är tillräckligt för att prata med både en terminal och en terminalväxel, så jag kan programmera datorn över nät från en Linuxmaskin. :) Kontrollregistret styr antal data- och stoppbittar samt paritet på/av, udda/jämn. Statusregistret meddelar data mottagna, overrun, paritetsfel, framingfel, samt utgående databuffert tom och utgående överföring färdig. Framingfelsbitten på den ena porten har jag också kopplat till NMI-ledningen på bussen, så man kan ovillkorligt interrupta processorn genom att skicka ett break från terminalen. I NMI-hanteraren har jag ett filöverföringsprogram för att uppdatera firmwaret. Andra interrupts är planerade men inte implementerade än. Jag var för sugen på att börja skriva mjukvara. :) Chassit är nån botten med ram för framsidan som låg i min skothög hemma, och sidoplåten är utklippt ur sidan av ett gammalt trasig Tektronix-oscilloskop. Nätagget som sitter i på bilden gick sönder nästan direkt, så nu är det en liten väggvårta istället. Den får jag nog byta ut när det kommer lite mer saker i lådan. Det tomma kortet i botten är alltså en systembuss utan kontakter monterade. Det enda kortet hittills är device 0, som är serieinterfejset (inte med i bilderna, som jag tog innan jag byggt det, utom sista bilden som var mitt första test av seriekortet). Längst in, i plan med bussmoderkortet, sitter själva datorkortet, som är kanske 10x10cm och rätt fullproppat, med processor, RAM, ROM, adressavkodning, samt en massa logik som har att göra med kontrollpanelen. Mina såna där roadrunner-remsor tog slut när jag hade byggt processorkortet, så för serieportskortet ritade jag en modell och lät en kompis skriva ut lite nya på 3D-skrivare. De funkar hyfsat, men går sönder lite för lätt. Ska prata med honom om ifall det går att göra nåt åt det för nästa omgång remsor. Nu funderar jag på vad som ska bli nästa instickskort att bygga. Nån sorts lagring kanske, eller grafikkort, eller ljudkort, eller en massa GPIO, vilket jag skulle ha nytta av hemma. Ethernet är lockande också. Angående ditt nätagg Ragge så har jag inga kommentarer. Det är lite utanför mitt kunskapsområde. Men jag bidrar med hurrarop och hoppas att du får nånting byggt snart! Och 200kHz tycker jag är helt tillräckligt! Jag har förresten designat en hyfsad instruktionsuppsättning för min rördator, men inte testat den. Får ta och skriva en emulator och en assembler och prova att skriva lite program och se hur användbar den är, och hur kompakt koden blir. Kompakt kod är nog den viktigaste egenskapen jag vill ha, med den minnesstorlek jag har tänkt. Har sugnat igen på att bygga på rördatorn, så det kanske kommer ett brev om det om inte alltför länge. :) Bjarni
Bjarni Juliusson skrev den 2015-02-25 19:57:
Ja det är alldeles för sällan det skrivs nåt här, så här kommer lite bilder på ett annat datorprojekt jag hittade på som omväxling från den stora datorn. Jag ville få nånting byggt som fungerade, så jag svängde ihop en liten mikrodator med en 6502-processor, lite RAM och EEPROM, och ett par serieinterface:
http://www.update.uu.se/~bjarni/temp/6502-dator/ Wow, lite byggande iallafall! Du lyckas göra rätt snygga saker också, för mej blir det mest kråkbon tycker jag :-/
Brum heter den. Den har 32K RAM, 8K EEPROM, två RS-232-interface, och en behändig kontrollpanel som jag använde för att bootstrappa programmerandet. Som det är nu har kontrollpanelen bara funktionalitet för att läsa och skriva i minnet, men det finns lite förberett för instruktionsstegning och lite andra mindre funktioner. EEPROMet kan skrivskyddas med en jumper och skyddet kan även slås på och av med en särskild signal på bussen som jag tänkte koppla till en knapp på panelen.
Nån slags färdig monitor i EEPROMet eller nåt du micklat med själv?
Serieinterfacet använder sig av två stycken 6402-UARTar, vilka jag valde för att de har alla kontroll- och statussignaler utdragna till egna pinnar istället för register man måste pilla med för att konfigurera gränssnittet, vilket gör att jag har kunnat designa det så att portarna kommer upp automatiskt förkonfigurerade för 9600 8N1 efter strömtillslag, vilket är en angenäm bekvämlighet.
Varje port har fyra skrivregister [data, handskakning, baudrate, kontroll] och fyra läsregister [data, handskakning, status, reset]. Reset görs alltså med en läsning, för att det var bekvämt att implementera i hårdvaran och det fanns ett ledigt läsregister.
Handskakningen är bara två utgående och två ingående GPIO-signaler, som man egentligen kan göra vad man vill med men som kan användas till RS-232-handskakning om man behöver. I och med att de är helt mjukvarustyrda kan man göra både gammaldags assymmetrisk handskakning och modern symmetrisk handskakning. Nivåkonverterarna är inte installerade än, så just nu är det bara dataledningarna som funkar, men det är tillräckligt för att prata med både en terminal och en terminalväxel, så jag kan programmera datorn över nät från en Linuxmaskin. :)
Kontrollregistret styr antal data- och stoppbittar samt paritet på/av, udda/jämn. Statusregistret meddelar data mottagna, overrun, paritetsfel, framingfel, samt utgående databuffert tom och utgående överföring färdig. Framingfelsbitten på den ena porten har jag också kopplat till NMI-ledningen på bussen, så man kan ovillkorligt interrupta processorn genom att skicka ett break från terminalen. I NMI-hanteraren har jag ett filöverföringsprogram för att uppdatera firmwaret.
Andra interrupts är planerade men inte implementerade än. Jag var för sugen på att börja skriva mjukvara. :)
NMI är guld värt på 6502. Jag hade en PET 3032 en gång i tiden som jag både hårdvarumoddade och skrev mjukvara till rätt friskt. Där monterade jag en knapp till NMIn på högersidan tangentbordet för att ha den nära till :-) Jag har faktiskt fortfarande en PET700 med 6509 och 384k minne i. Jag har tänkt att jag skall nån dag porta pcc till 650x och se om det går att få igång 2BSD på den :-)
Chassit är nån botten med ram för framsidan som låg i min skothög hemma, och sidoplåten är utklippt ur sidan av ett gammalt trasig Tektronix-oscilloskop. Nätagget som sitter i på bilden gick sönder nästan direkt, så nu är det en liten väggvårta istället. Den får jag nog byta ut när det kommer lite mer saker i lådan.
Det tomma kortet i botten är alltså en systembuss utan kontakter monterade. Det enda kortet hittills är device 0, som är serieinterfejset (inte med i bilderna, som jag tog innan jag byggt det, utom sista bilden som var mitt första test av seriekortet). Längst in, i plan med bussmoderkortet, sitter själva datorkortet, som är kanske 10x10cm och rätt fullproppat, med processor, RAM, ROM, adressavkodning, samt en massa logik som har att göra med kontrollpanelen.
Mina såna där roadrunner-remsor tog slut när jag hade byggt processorkortet, så för serieportskortet ritade jag en modell och lät en kompis skriva ut lite nya på 3D-skrivare. De funkar hyfsat, men går sönder lite för lätt. Ska prata med honom om ifall det går att göra nåt åt det för nästa omgång remsor.
Hm, är det såna där remsor man har när man skall etsa kretskort? Jag måste i närtid etsa lite själv, det har jag inte gjort på 30 år så man får damma av lite gamla kunskaper. Jag skall byta till switchade nätagg i Novan jag har, serieregulatorerna har havererat allihopa och jag tänker inte fixa dom.
Nu funderar jag på vad som ska bli nästa instickskort att bygga. Nån sorts lagring kanske, eller grafikkort, eller ljudkort, eller en massa GPIO, vilket jag skulle ha nytta av hemma. Ethernet är lockande också.
Ethernet låter bra. Man måste ju göra en webbserver :-)
Angående ditt nätagg Ragge så har jag inga kommentarer. Det är lite utanför mitt kunskapsområde. Men jag bidrar med hurrarop och hoppas att du får nånting byggt snart! Och 200kHz tycker jag är helt tillräckligt!
Jag håller på att försöka fixa -100 också. Om man har två trafosar och halvvågslikriktning så måste man ta ut från andra hållet också för att inte få likströmsmagnetisering av kärnorna, så det blir shuntreglering av spänningen där.
Jag har förresten designat en hyfsad instruktionsuppsättning för min rördator, men inte testat den. Får ta och skriva en emulator och en assembler och prova att skriva lite program och se hur användbar den är, och hur kompakt koden blir. Kompakt kod är nog den viktigaste egenskapen jag vill ha, med den minnesstorlek jag har tänkt.
Har sugnat igen på att bygga på rördatorn, så det kanske kommer ett brev om det om inte alltför länge. :)
Tänkte du mikrokoda eller ha enkla instruktioner? Jag tänkte försöka undvika mikrokod helt; det blev så jobbiga matriser för att avkoda :-) -- Ragge
On 02/26/2015 07:59 PM, Anders Magnusson wrote:
Nån slags färdig monitor i EEPROMet eller nåt du micklat med själv?
Än så länge är det bara ett program som för över en image över seriesnöret och skriver den i EEPROMet, men det programmet har jag skrivit själv. Det är 248 bytes, så det får plats i sista minnessidan tillsammans med vektorerna. :)
Jag har faktiskt fortfarande en PET700 med 6509 och 384k minne i. Jag har tänkt att jag skall nån dag porta pcc till 650x och se om det går att få igång 2BSD på den :-)
Det vore nåt. Vad har 2BSD för krav på maskinmodellen egentligen?
Hm, är det såna där remsor man har när man skall etsa kretskort?
Näe, man har dem för att dra tråden i när man kopplar på vero, vilket är vad jag har byggt på, har inte etsat nåt. Jag använder Roadrunner-penna, som matar ut tunn emaljerad koppartråd som man sen löder på och bränner bort emaljen. Plastremsorna funkar som kanaler för att samla trådarna och hålla dem ur vägen för pinnarna man ska löda på.
Ethernet låter bra. Man måste ju göra en webbserver :-)
Har faktiskt ett manchesterkodnings-, nivåkonverterings- och klockregenereringschip, AM7992, som jag skulle kunna använda. Klockregenereringen i mottagaren verkar vara den jobbigaste biten med ethernet, annars är det ett simpelt protokoll. Hmm. Först blir det nog dock ett SD-interface så jag kan ha lite lokal lagring. Det är också väldigt enkelt.
Tänkte du mikrokoda eller ha enkla instruktioner? Jag tänkte försöka undvika mikrokod helt; det blev så jobbiga matriser för att avkoda :-)
Får se hur det blir. Jag har en rätt regelbunden instruktionsuppsättning och inte så komplicerade instruktioner, men en hel del adresseringssätt. Har inte räknat nånting alls på hur stora kretsarna blir, och det kanske blir styrande. Bjarni
Bjarni Juliusson skrev den 2015-02-27 14:26:
On 02/26/2015 07:59 PM, Anders Magnusson wrote:
Jag har faktiskt fortfarande en PET700 med 6509 och 384k minne i. Jag har tänkt att jag skall nån dag porta pcc till 650x och se om det går att få igång 2BSD på den :-)
Det vore nåt. Vad har 2BSD för krav på maskinmodellen egentligen? Inte så mycket, men för att det skall bli vettigt så vill man ha nån slags segmentering åtminstone. Den förväntar sig att man har hela programmet i minnet, ingen paging alltså.
Ethernet låter bra. Man måste ju göra en webbserver :-)
Har faktiskt ett manchesterkodnings-, nivåkonverterings- och klockregenereringschip, AM7992, som jag skulle kunna använda. Klockregenereringen i mottagaren verkar vara den jobbigaste biten med ethernet, annars är det ett simpelt protokoll. Hmm. Jo, jag har funderat på att göra ett sånt interface till rördatorn också. Torde inte vara jättesvårt :-)
Först blir det nog dock ett SD-interface så jag kan ha lite lokal lagring. Det är också väldigt enkelt.
Lagring är bra. Jag skall programmera upp en Arduino tänkte jag som får agera bussadapter mot Data Channel i Nova 840:n så att man kan emulera 5MB-disk och sånt :-)
Tänkte du mikrokoda eller ha enkla instruktioner? Jag tänkte försöka undvika mikrokod helt; det blev så jobbiga matriser för att avkoda :-)
Får se hur det blir. Jag har en rätt regelbunden instruktionsuppsättning och inte så komplicerade instruktioner, men en hel del adresseringssätt. Har inte räknat nånting alls på hur stora kretsarna blir, och det kanske blir styrande.
Jag tyckte det blev nog så jobbigt med statemaskiner bara för att plocka in och exekvera instruktionerna, så därför blev det Nova-arkitekturen. Först så skissade jag på att använda PDP11, men då fastnade man i dekodningsträsket iallafall... -- Ragge
On 02/27/2015 04:37 PM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-27 14:26:
Vad har 2BSD för krav på maskinmodellen egentligen?
Inte så mycket, men för att det skall bli vettigt så vill man ha nån slags segmentering åtminstone.
Exakt vad är det man bör ha?
Den förväntar sig att man har hela programmet i minnet, ingen paging alltså.
Det är ju trevligt. Hur är det med multitasking, kan den köra single address space, eller måste den swappa hela processerna? Hur mycket minne tar kärnan?
Ethernet låter bra. Man måste ju göra en webbserver :-)
Jo, jag har funderat på att göra ett sånt interface till rördatorn också. Torde inte vara jättesvårt :-)
Problemet är väl att man måste kunna klocka data i 10MHz, så rör är nog uteslutet, eller? Bjarni
Bjarni Juliusson skrev den 2015-02-27 18:10:
On 02/27/2015 04:37 PM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-27 14:26:
Vad har 2BSD för krav på maskinmodellen egentligen?
Inte så mycket, men för att det skall bli vettigt så vill man ha nån slags segmentering åtminstone.
Exakt vad är det man bör ha? Jag tror att det räcker med att kunna mappa om minnet med säg 8K-sidor. Det förenklar iallafall. Det är ju en unix så en process vill ha kod, heap och stack, och sen måste man kunna växa heapen. Man vill nog ha mer än 64k minne också, det kan bli lite trångt annars.
Den förväntar sig att man har hela programmet i minnet, ingen paging alltså.
Det är ju trevligt. Hur är det med multitasking, kan den köra single address space, eller måste den swappa hela processerna?
Som du ser ovan, man vill ha ett adressutrymme per process, därför man vill kunna mappa om minnet :-) Jag tror jag sett nån port av 2BSD som inte kräver det, men då slipper man nog IP-stacken.
Hur mycket minne tar kärnan?
På en PDP11 så tar text+data mindre än 64k iaf, beroende på hur mycket saker man har i den. Nätverksdelen kräver dessutom ett eget utrymme som är split I/D.
Ethernet låter bra. Man måste ju göra en webbserver :-)
Jo, jag har funderat på att göra ett sånt interface till rördatorn också. Torde inte vara jättesvårt :-)
Problemet är väl att man måste kunna klocka data i 10MHz, så rör är nog uteslutet, eller?
Det borde nog gå alldeles ypperligt. Det är ju inte så att rör har problem med högre frekvenser, och med ECC88 så går det till och med att ha fyrkantvågor i 10MHz, på bekostnad av elförbrukning. Fast man börjar nog med att köra SLIP eller nåt annat lättviktigt :-) -- Ragge
On 02/27/2015 06:44 PM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-27 18:10:
Exakt vad är det man bör ha?
Jag tror att det räcker med att kunna mappa om minnet med säg 8K-sidor. Det förenklar iallafall. Det är ju en unix så en process vill ha kod, heap och stack, och sen måste man kunna växa heapen. Man vill nog ha mer än 64k minne också, det kan bli lite trångt annars.
OK, men det blir nån sorts bankswitchning då, och så switchar man banker när man gör context switch? Förväntar sig kärnan att ha nån del av minnet, eller räcker det med att switcha ut en bit av processen och in med kärnan när man får en interrupt eller ett systemanrop?
Hur mycket minne tar kärnan? På en PDP11 så tar text+data mindre än 64k iaf, beroende på hur mycket saker man har i den. Nätverksdelen kräver dessutom ett eget utrymme som är split I/D.
Just I/D går ju i alla fall att göra på just 650x lyckligtvis. :)
Problemet är väl att man måste kunna klocka data i 10MHz, så rör är nog uteslutet, eller? Det borde nog gå alldeles ypperligt. Det är ju inte så att rör har problem med högre frekvenser, och med ECC88 så går det till och med att ha fyrkantvågor i 10MHz, på bekostnad av elförbrukning.
Det vore ju helt enastående! Bjarni
Bjarni Juliusson skrev den 2015-02-27 20:27:
On 02/27/2015 06:44 PM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-27 18:10:
Exakt vad är det man bör ha?
Jag tror att det räcker med att kunna mappa om minnet med säg 8K-sidor. Det förenklar iallafall. Det är ju en unix så en process vill ha kod, heap och stack, och sen måste man kunna växa heapen. Man vill nog ha mer än 64k mine också, det kan bli lite trångt annars.
OK, men det blir nån sorts bankswitchning då, och så switchar man banker när man gör context switch? Förväntar sig kärnan att ha nån del av minnet, eller räcker det med att switcha ut en bit av processen och in med kärnan när man får en interrupt eller ett systemanrop? Bankswitching ja. Det är ju typ det som det funkar med en vanlig MMU också, men då sker det "by magic". Kärnan har ett eget adressutrymme, för att komma åt processminne är det speciella subrutiner (fuword/suword etc...)
Hur mycket minne tar kärnan? På en PDP11 så tar text+data mindre än 64k iaf, beroende på hur mycket saker man har i den. Nätverksdelen kräver dessutom ett eget utrymme som är split I/D.
Just I/D går ju i alla fall att göra på just 650x lyckligtvis. :)
Hm, går det? Det har jag missat! Hur?
Problemet är väl att man måste kunna klocka data i 10MHz, så rör är nog uteslutet, eller? Det borde nog gå alldeles ypperligt. Det är ju inte så att rör har problem med högre frekvenser, och med ECC88 så går det till och med att ha fyrkantvågor i 10MHz, på bekostnad av elförbrukning.
Det vore ju helt enastående!
Allt går :-) Till och med 6J6 från 1939 var rekommenderat att användas i radioapparater upp till 250MHz... -- Ragge
On 02/27/2015 10:35 PM, Anders Magnusson wrote:
Just I/D går ju i alla fall att göra på just 650x lyckligtvis. :)
Hm, går det? Det har jag missat! Hur?
Processorn har ju en outputpinne som säger om den nuvarande cykeln är en instruktionsfetch! Det är så man gör instruktionsstegning också.
Allt går :-) Till och med 6J6 från 1939 var rekommenderat att användas i radioapparater upp till 250MHz...
Shit alltså... det är väldigt lockande! Bjarni
Bjarni Juliusson skrev den 2015-02-28 00:28:
On 02/27/2015 10:35 PM, Anders Magnusson wrote:
Just I/D går ju i alla fall att göra på just 650x lyckligtvis. :)
Hm, går det? Det har jag missat! Hur?
Processorn har ju en outputpinne som säger om den nuvarande cykeln är en instruktionsfetch! Hm, det har jag aldrig hört nån använda sig av :-) Isåfall så refererar man bara till en separat mapptabell för minnet när den bitten är satt. Men jag antar att man behöver lite mer logik också? Till exempel om man gör jmp $1234 så lär den bara ha pinnen satt när jmp hämtas? Eller är den satt under fetchandet av alla tre bytarna? Det skulle förenkla, då skulle man ju kunna göra en enkel MMU också :-)
I Nova840 så är MMUn ett instickskort man stoppar in. CPUn har ingen kunskap om det kortet överhuvudtaget och man kan rycka ut det utan att behöva ändra nåt annat så blir det en Nova utan MMU. Det dels ligger och drar i lite OC-ledningar för att man skall adressera rätt bit av minnet, dels lyssnar det om man försöker komma åt nåt man inte får. Om man försöker det (till exempel skriva till en page som är skrivskyddad) så släpper det enable för minneskorten, ställer om state till supervisor och nästa fetch så kommer den att adressera vektoradressen (040-043 beroende på trap) oberoende av vad CPUn egentligen lägger ut på adressbussen :-) Ganska smart. Det här tänkte jag använda mej av i rördatorn också. Man kan ju typ lägga till funktionalitet efter hand utan att behöva bygga om en massa saker.
Det är så man gör instruktionsstegning också.
Allt går :-) Till och med 6J6 från 1939 var rekommenderat att användas i radioapparater upp till 250MHz...
Shit alltså... det är väldigt lockande!
Precis. Kom igen nu! :-) -- Ragge
On 02/28/2015 09:56 AM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-28 00:28:
Processorn har ju en outputpinne som säger om den nuvarande cykeln är en instruktionsfetch!
Hm, det har jag aldrig hört nån använda sig av :-) Isåfall så refererar man bara till en separat mapptabell för minnet när den bitten är satt. Men jag antar att man behöver lite mer logik också? Till exempel om man gör jmp $1234 så lär den bara ha pinnen satt när jmp hämtas?
Ah, just, fasen, den säger faktiskt bara 1 på den pinnen när den hämtar själva opkodsbyten. :/ Förresten, http://visual6502.org om du inte redan kände till den.
Allt går :-) Till och med 6J6 från 1939 var rekommenderat att användas i radioapparater upp till 250MHz...
Shit alltså... det är väldigt lockande! Precis. Kom igen nu! :-)
Jag börjar med mitt SD-interface! :) Bjarni
Bjarni Juliusson skrev den 2015-02-28 21:08:
On 02/28/2015 09:56 AM, Anders Magnusson wrote:
Bjarni Juliusson skrev den 2015-02-28 00:28:
Processorn har ju en outputpinne som säger om den nuvarande cykeln är en instruktionsfetch!
Hm, det har jag aldrig hört nån använda sig av :-) Isåfall så refererar man bara till en separat mapptabell för minnet när den bitten är satt. Men jag antar att man behöver lite mer logik också? Till exempel om man gör jmp $1234 så lär den bara ha pinnen satt när jmp hämtas?
Ah, just, fasen, den säger faktiskt bara 1 på den pinnen när den hämtar själva opkodsbyten. :/ Då får man ha lite mer logik. Hm, eftersom man vet när det är fetch så kan man ju göra en riktig mmu också, med split I/D. Borde kunna funka såhär ungefär:
- Vi tänker att vi har minnet indelat i 16 pages om 4k styck, dels för data och dels för kod. - När fetch sätts, kolla om instruktionen som läses är 1, 2 eller 3 bytes lång (tabell). Låt det antalet minnesreferenser gå via en pagetabell för kod istället. Kolla samtidigt om adressen + antal cykler går till en page man inte har access till, om man inte har det så fejka att den läser jmp ($02) istället. Nu fick vi en trap :-) - Om fetch inte är satt så kollar vi bara accessen. Om man inte har access, låt instruktionen köra färdigt och ignorera minnesreferenserna, och vid nästa fetch fejka en jmp ($03). Nu har vi fått en data access trap. Så, hängde du med på hur jag tänkte? :-)
Förresten, http://visual6502.org om du inte redan kände till den.
Jo, jag har sett den :-)
Allt går :-) Till och med 6J6 från 1939 var rekommenderat att användas i radioapparater upp till 250MHz...
Shit alltså... det är väldigt lockande! Precis. Kom igen nu! :-)
Jag börjar med mitt SD-interface! :)
Lycka till! -- R
On 03/01/2015 01:42 PM, Anders Magnusson wrote:
- Vi tänker att vi har minnet indelat i 16 pages om 4k styck, dels för data och dels för kod. - När fetch sätts, kolla om instruktionen som läses är 1, 2 eller 3 bytes lång (tabell). Låt det antalet minnesreferenser gå via en pagetabell för kod istället. Kolla samtidigt om adressen + antal cykler går till en page man inte har access till, om man inte har det så fejka att den läser jmp ($02) istället. Nu fick vi en trap :-)
Och så måste vi komma ihåg var vi hoppade ifrån förstås.
- Om fetch inte är satt så kollar vi bara accessen. Om man inte har access, låt instruktionen köra färdigt och ignorera minnesreferenserna, och vid nästa fetch fejka en jmp ($03). Nu har vi fått en data access trap.
Oj, hmm. Då måste vi dels komma ihåg adressen för den föregående instruktionen, dels ogöra dess effekt i efterhand. Vi kan ju förbjuda inmappning av I/O i pageade processer för att slippa det värsta krånglet (hur undoar man en instruktion som gör en indirekt adressering av I/O-sidan). Bjarni
On Sun, Mar 01, 2015 at 05:07:22PM +0100, Bjarni Juliusson wrote:
Oj, hmm. Då måste vi dels komma ihåg adressen för den föregående instruktionen, dels ogöra dess effekt i efterhand. Vi kan ju
nja. magnus sa ju att mmu:n skulle ignorera minnesaccesser, skulle inte det helt ogöra instruktionens effekter? Eller är det sidoeffekter i CPU:n du tänker på, flaghor som sätts eller liknande? Eller är det så att jag helt har missuppfattat? /P
On 03/01/2015 05:45 PM, Pontus Pihlgren wrote:
On Sun, Mar 01, 2015 at 05:07:22PM +0100, Bjarni Juliusson wrote:
Oj, hmm. Då måste vi dels komma ihåg adressen för den föregående instruktionen, dels ogöra dess effekt i efterhand. Vi kan ju
nja. magnus sa ju att mmu:n skulle ignorera minnesaccesser, skulle inte det helt ogöra instruktionens effekter?
Nej.
Eller är det sidoeffekter i CPU:n du tänker på, flaghor som sätts eller liknande?
Ja. Processorn exekverar ju instruktionen oavsett vad den får för data från minnet. I efterhand måste vi kunna återställa ackumulatorn, X, Y, flaggorna, och stackpekaren. Så MMU:n måste komma ihåg var senaste opkoden fetchades ifrån innan trappen, så att vi kan se vad den var, ogöra effekten, och sätta tillbaka programräknaren för att starta om instruktionen. Insåg just att man lyckligtvis inte kan göra dataåtkomster med indirekt absolut adressering. Det hade varit rena döden. Enda indirekta data-adresseringen är via sida 0, som man rimligen alltid har mappad och både läs- och skrivbar. Så det där jag sa om I/O är nog ingen fara, man kan inte råka göra I/O man inte skulle ha gjort. Eller ja, förutom totalt degenererade situationer som att man gör ett indirekt hopp via en adress som ligger på skarven mellan en omappad sida och en I/O-sida, så att det slutar med att man gör en läsning till ett I/O-register två gånger. Det känns som en situation som det är helt acceptabelt att lösa genom att blänga på programmeraren. Bjarni
Bjarni Juliusson skrev den 2015-03-01 18:35:
On 03/01/2015 05:45 PM, Pontus Pihlgren wrote:
On Sun, Mar 01, 2015 at 05:07:22PM +0100, Bjarni Juliusson wrote:
Oj, hmm. Då måste vi dels komma ihåg adressen för den föregående instruktionen, dels ogöra dess effekt i efterhand. Vi kan ju
nja. magnus sa ju att mmu:n skulle ignorera minnesaccesser, skulle inte det helt ogöra instruktionens effekter?
Nej.
Eller är det sidoeffekter i CPU:n du tänker på, flaghor som sätts eller liknande?
Ja.
Processorn exekverar ju instruktionen oavsett vad den får för data från minnet. I efterhand måste vi kunna återställa ackumulatorn, X, Y, flaggorna, och stackpekaren. Så MMU:n måste komma ihåg var senaste opkoden fetchades ifrån innan trappen, så att vi kan se vad den var, ogöra effekten, och sätta tillbaka programräknaren för att starta om instruktionen. Jag tänkte mej att MMUn har två register, ett som latchar in adressen när man gör en fetch och ett annat när man inte gör det. Båda registrena är läsbara från CPUn på nät sätt så att man kan kolla var man fick en fault (och hoppa tillbaka). I fallet fault under fetch är det enkelt; då returnerar man ju alltid en jmp istället och får inga sidoeffekter. I det andra fallet så kommer man att exekvera instruktionen, men man ignorerar skrivningar och returnerar bara 0.
Det är några saker som man måste fundera på lite för att lösa. Till exempel ADC lägger ju till carryn och sätter den igen, även om man adderar med 0. Här är det en utmaning att veta vad den var innan. Eller AND, om man returnerar 0 så kommer den att cleara A. Båda ovan skulle gå att lösa eftersom man kan räkna ut vad det är som kommer att skita sig, så man kan returnera nåt bra istället :-)
Insåg just att man lyckligtvis inte kan göra dataåtkomster med indirekt absolut adressering. Det hade varit rena döden. Enda indirekta data-adresseringen är via sida 0, som man rimligen alltid har mappad och både läs- och skrivbar. Så det där jag sa om I/O är nog ingen fara, man kan inte råka göra I/O man inte skulle ha gjort. Eller ja, förutom totalt degenererade situationer som att man gör ett indirekt hopp via en adress som ligger på skarven mellan en omappad sida och en I/O-sida, så att det slutar med att man gör en läsning till ett I/O-register två gånger. Det känns som en situation som det är helt acceptabelt att lösa genom att blänga på programmeraren.
Ditt sista exempel här skulle man slippa eftersom man har koll på vad instruktionen försöker göra och om den får det. Det enda problemet här vore möjligtvis om man gör typ ett indirekt hopp där indirekt-adressen ligger i I/O-området, då kommer man att få två accesser. Men gör man det har man nog redan förlorat. Jag tror ingen MMU löser det problemet... Sen har man ju lite buggar att ta hänsyn till (eller kanske fixa?) i MMUn. Jag har nåt minne av att om man gjorde en indirektadressering och halva adressen låg på nästa sida så tog den istället första adressen från innevarande sida? -- Ragge
participants (3)
-
Anders Magnusson -
Bjarni Juliusson -
Pontus Pihlgren