Kommer adressbussen att användas till något annat än programminnet?
Oavsett så tänkte jag att om du har en 8-bitars adress kan du adressera 256 nibbles med data.
Om varje instruktion har en längd på t.ex. 4 nibbles så får du plats med 256/4 = 64 instruktioner.
Om du istället flyttar adressbussen två bitar på ROM-minnet kan du adressera var fjärde nibble på ett 1024-nibbles minne.
För att läsa in en instruktion behöver du då en 2-bitars räknare som går igenom de fyra nibble som finns på aktuell adress.
På så vis kan du plötsligt adressera upp till 256 st 16-bitars instruktioner.
Det blir krångligare om det ät 6 nibble i en instruktion... det är 'ojämnt' antal.
Så fungerar faktiskt 8-bitars AVR-proccessorer. Anger du adressen 0x10 så kommer du egentligen till 0x20. För varje adress innehåller två bytes.
Komponent för 4-bit till 8-bit konvertering
Re: Komponent för 4-bit till 8-bit konvertering
@jesse, vilken intressant idé, kör man på det är det ju lätt värt att köra lite padding mellan instruktionerna! Jag tror dock jag behåller min design för enkelheten (ökar chanserna att det i slutändan blir en fungerande grejj). 
Re: Komponent för 4-bit till 8-bit konvertering
Swech skrev:Precis... då drar du sjätte utgången till reset på kretsen...Bra förslag med 4017 komponenten, men som det ser ut nu behöver jag "bara" 6-steg
Swech
hoppas på att det inte ska behöva gå så snett i designen-
Swech
- EF Sponsor
- Inlägg: 4755
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: Komponent för 4-bit till 8-bit konvertering
Jag menar reset på 4022, inte hela cpun...
så får du endast 6 steg
Swech
så får du endast 6 steg
Swech
Re: Komponent för 4-bit till 8-bit konvertering
ah, du menar så, läste det som ett skämt att det är lika bra att resetta allt efter varje instruktion
men, precis som du säger, det första oanvända T-statet får resetta räknaren
men, precis som du säger, det första oanvända T-statet får resetta räknaren
Re: Komponent för 4-bit till 8-bit konvertering
Gjorde ett första mer seriöst försök till ISA igår,
tog bort många av de logiska funktionerna då samtliga kan skapas med en OR samt NOT. La till ett OUT register, kom ju på att man kanske vill koppla en display till datorn sen, detta görs på OUT registret med OUT funktionen
La åxå till en ytterligare branch, BRC , om föregående ALU op gav en carry. Behövs för att hantera tal större än 4-bitar. Fick ta bort rotate right dock, så vill man göra detta så får det bli 3 stycken rotate left efter varandra istället.
Är inte helt nöjd med stilen: mv <REG1>, <REG2>, <REG3> , funderar på att göra <REG1> till implicit receiver. Sen är det en begränsning i arkitekturen att "target" är olika för tex ld och mv, ld <REG>, $IMM8 => REG = $IMM8 medans MV <REG1>, <REG2> => REG2 = REG1
tog bort många av de logiska funktionerna då samtliga kan skapas med en OR samt NOT. La till ett OUT register, kom ju på att man kanske vill koppla en display till datorn sen, detta görs på OUT registret med OUT funktionen
La åxå till en ytterligare branch, BRC , om föregående ALU op gav en carry. Behövs för att hantera tal större än 4-bitar. Fick ta bort rotate right dock, så vill man göra detta så får det bli 3 stycken rotate left efter varandra istället.
Är inte helt nöjd med stilen: mv <REG1>, <REG2>, <REG3> , funderar på att göra <REG1> till implicit receiver. Sen är det en begränsning i arkitekturen att "target" är olika för tex ld och mv, ld <REG>, $IMM8 => REG = $IMM8 medans MV <REG1>, <REG2> => REG2 = REG1
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Komponent för 4-bit till 8-bit konvertering
Ska $ indikera hex eller att det inte är immediate?
Vad jag kan se så har du inte logik för annat än immediate som adresseringsmode. Eller ska det egentligen vara någon slags separata pilar mellan den interna databussen och MAR och snarast så att MAR respektive PC kan alternera för att mata adressbussen?
Om du ändå ordnar så att du kan adressera valfri del av minnet och gör instruktioner både för att skriva och läsa så kan du i princip skippa out och köra minnesmappad i/o.
Det är rätt ovanligt med treoperandsprocessorer, t.ex. VAX är vad jag minns sådan, men de flesta andra är tvåoperands. Visst blir det flexiblare med tre operander men det tar ju tid att läsa in instruktionerna och den tiden kan man istället i förekommande fall lägga på att kopiera ett av in-värdena om man behöver ha båda kvar.
Det verkar också ha tillkommit en stackpekare. Istället för push/pop så skulle du kunna ha instruktioner som använder registerpar som pekare och som laddar med autoinkrement och sparar med autodekrement eller vice versa, givetvis måste inkrement/dekrement ske på "rätt sida" av att laddningen/lagringen sker.
Fast nu börjar det likna en 4-bitars variant av 1802. Den har inget uttalat stackregister men har hela 16 (!) registerpar, typ 0-16 high/low, som dels kan användas som vanliga register men det går även att använda dem som pekare och dessutom så har processorn ingen uttalad program counter utan ett fyrabitarsregister väljer vilket registerpar som ska vara programräknare för stunden. Ett subrutinanrop kan alltså ske genom att byta program counter och återhoppet genom att byta tillbaka till föregående program counter. Mycket märklig arkitektur IMHO men det verkar ju fungera. Det finns väl en anledning till att 1802 aldrig fick något riktigt fotfäste i "riktiga" datorer. Noxon Comx 35 var väl enda hemdatorn med 1802, i övrigt har den väl mest använts dels i primitiva enkortsdatorer och dels där vi idag använder mikrokontrollers.
P.S. vad gäller 4017/4022 och instruktionerna så vinner du dessutom en del enkelhet på att ha en fast instruktionslängd eftersom du då inte behöver översätta instruktionen till antal cykler som ska köras i instruktionen. Fast allt blir ju lite märkligt om antalet klockcykler per instruktion inte är en jämn tvåpotens. Hur som helst, ifall du väljer fast instruktionslängd och "skiftad" adressbuss så behöver du antingen göra binärkodning av utgångarna från 4017/4022 eller så får du köra en trebitars räknare och avkoda exekverinsfaserna med en 3-till-8-avkodare typ t.ex. 74xx138.
Hur ska sequencern/mikrokoden se ut? Jag tycker att 6502 verkar ha en elegant lösning, en sequencer typ som 4022/4017 och sedan i princip ett maskprogrammerat rom med ingångar för lagrad instruktion och sequencerns steg och utgångar för att aktivera olika funktioner/signalvägar i processorn. I ditt fall med 4-bit-instruktioner och färre än 8 cykler per instruktion så räcker det med ett rom med 7 adressingångar. Med tanke på att det i princip inte går att få tag på så små rom utan att betala ohemult mycket så kan du kanske lika gärna bygga processorn så att du kan ha vissa instruktioner som är två 4-bit-ord långa, och därmed ha två instruktinsregister. Då blir det ändå bara 4+4+3 bitar in till rom:et, det motsvarar ett 2716 eprom, och de är säkert ändå dyrare än ett större Däremot går det åt rätt många utgångar, en variant kan kanske vara att köra nån slags "halvcykler" som gör att du för varje sequencersteg i sin tur läser ur två eller fyra adresser ur detta rom och latchar det utlästa för att få 16 eller 32 styrsignaler. (Jag vet inte hur många signaler som behövs - det räcker kanske med åtta).
Hardcorevarianten är att göra hela denna del med en diodmatris. Vissa saker kan kanske också förenklas i form av att vissa flöden styrs hårt av vissa bitar eller kombinationer av bitar i instruktionsregistret och givetvis så är första steget i sequencern alltid att läsa in en instruktion och inkrementera PC så den logiken behöver inte styras av något rom eller motsvarande.
Jag vet inte riktigt om man formellt kan säga att det är skillnad mellan mikrokod och den typ av sequencer som 6502 har.
Vad jag kan se så har du inte logik för annat än immediate som adresseringsmode. Eller ska det egentligen vara någon slags separata pilar mellan den interna databussen och MAR och snarast så att MAR respektive PC kan alternera för att mata adressbussen?
Om du ändå ordnar så att du kan adressera valfri del av minnet och gör instruktioner både för att skriva och läsa så kan du i princip skippa out och köra minnesmappad i/o.
Det är rätt ovanligt med treoperandsprocessorer, t.ex. VAX är vad jag minns sådan, men de flesta andra är tvåoperands. Visst blir det flexiblare med tre operander men det tar ju tid att läsa in instruktionerna och den tiden kan man istället i förekommande fall lägga på att kopiera ett av in-värdena om man behöver ha båda kvar.
Det verkar också ha tillkommit en stackpekare. Istället för push/pop så skulle du kunna ha instruktioner som använder registerpar som pekare och som laddar med autoinkrement och sparar med autodekrement eller vice versa, givetvis måste inkrement/dekrement ske på "rätt sida" av att laddningen/lagringen sker.
Fast nu börjar det likna en 4-bitars variant av 1802. Den har inget uttalat stackregister men har hela 16 (!) registerpar, typ 0-16 high/low, som dels kan användas som vanliga register men det går även att använda dem som pekare och dessutom så har processorn ingen uttalad program counter utan ett fyrabitarsregister väljer vilket registerpar som ska vara programräknare för stunden. Ett subrutinanrop kan alltså ske genom att byta program counter och återhoppet genom att byta tillbaka till föregående program counter. Mycket märklig arkitektur IMHO men det verkar ju fungera. Det finns väl en anledning till att 1802 aldrig fick något riktigt fotfäste i "riktiga" datorer. Noxon Comx 35 var väl enda hemdatorn med 1802, i övrigt har den väl mest använts dels i primitiva enkortsdatorer och dels där vi idag använder mikrokontrollers.
P.S. vad gäller 4017/4022 och instruktionerna så vinner du dessutom en del enkelhet på att ha en fast instruktionslängd eftersom du då inte behöver översätta instruktionen till antal cykler som ska köras i instruktionen. Fast allt blir ju lite märkligt om antalet klockcykler per instruktion inte är en jämn tvåpotens. Hur som helst, ifall du väljer fast instruktionslängd och "skiftad" adressbuss så behöver du antingen göra binärkodning av utgångarna från 4017/4022 eller så får du köra en trebitars räknare och avkoda exekverinsfaserna med en 3-till-8-avkodare typ t.ex. 74xx138.
Hur ska sequencern/mikrokoden se ut? Jag tycker att 6502 verkar ha en elegant lösning, en sequencer typ som 4022/4017 och sedan i princip ett maskprogrammerat rom med ingångar för lagrad instruktion och sequencerns steg och utgångar för att aktivera olika funktioner/signalvägar i processorn. I ditt fall med 4-bit-instruktioner och färre än 8 cykler per instruktion så räcker det med ett rom med 7 adressingångar. Med tanke på att det i princip inte går att få tag på så små rom utan att betala ohemult mycket så kan du kanske lika gärna bygga processorn så att du kan ha vissa instruktioner som är två 4-bit-ord långa, och därmed ha två instruktinsregister. Då blir det ändå bara 4+4+3 bitar in till rom:et, det motsvarar ett 2716 eprom, och de är säkert ändå dyrare än ett större
Däremot går det åt rätt många utgångar, en variant kan kanske vara att köra nån slags "halvcykler" som gör att du för varje sequencersteg i sin tur läser ur två eller fyra adresser ur detta rom och latchar det utlästa för att få 16 eller 32 styrsignaler. (Jag vet inte hur många signaler som behövs - det räcker kanske med åtta).Hardcorevarianten är att göra hela denna del med en diodmatris. Vissa saker kan kanske också förenklas i form av att vissa flöden styrs hårt av vissa bitar eller kombinationer av bitar i instruktionsregistret och givetvis så är första steget i sequencern alltid att läsa in en instruktion och inkrementera PC så den logiken behöver inte styras av något rom eller motsvarande.
Jag vet inte riktigt om man formellt kan säga att det är skillnad mellan mikrokod och den typ av sequencer som 6502 har.
Re: Komponent för 4-bit till 8-bit konvertering
Jag använder $ för att indikera att det är en 8-bit adress, # indikerar 4-bit värde, enda anledningen är att jag ska komma ihåg 
. Men precis, finns inte några "exotiska" adresserings modes, bara immediate, tänkte ett tag på att lägga till nån jmps som tar en relativ adress, men kom fram till att det inte är värt det i denna lilla design, adressen måste ju ut genom ALU:n å sen tillbaks till PC:n . Jag tänker mig att MAR är den enda som matar adress bussen, så PC lägger sin adress till MAR innan den kommer till bussen. Oftast kommer flödet PC -> MAR -> ROM -> MDR vara det som är öppet, men ibland är det smidigt, t.ex. vid ld då är det bara in med adressen i MAR. Dock är ld den minst nödvändiga instruktionen just nu eftersom allt är i ROM och det är så lite minne, om nån ska bort så är det nog denna.
Ang. 3 operander så tror jag att jag gör om så att det bara är två, det sparar ett ord minne vilket ju ger fler instruktioner i slutändan, det är så många instruktioner som just nu har 3 operander så det borde kunna ge en ansenlig minnesbesparing. Jag tror jag samtidigt ändrar så att det alltid är det första som är target, mv REG1, REG2 => REG1 = REG2 , add REG1, REG2 => REG1 += REG2 osv
Jo, jag vill verkligen kunna göra funktionsanrop så la till en liten stack (16-bitar, rättade lite fel i arkitekturen åxå i en senare rev av bilden). Jag har sett sånna "konstiga" lösningar åxå med em design om 16 general purpose register vara en används som stackpekare, en som PC mm mm, det är en spännande idé men blir lite bökigare tror jag.
Microkoden jag skrivit är bara för mig att komma ihåg. I min naivitet så tänkte jag att 16 instruktioner går att bygga helt med logiska grindar utan nån microkod alls, det kanske är ett dumt beslut? Jag har T1 och T2 hårt knutna till att lägga ut nuvarande instruktion på MDR samt PC++, T3-T6 går in i controllern. Jag velade länge på hur jag skulle göra men valde detta, nästa projekt kanske blir en microkodad controller istället.
. Men precis, finns inte några "exotiska" adresserings modes, bara immediate, tänkte ett tag på att lägga till nån jmps som tar en relativ adress, men kom fram till att det inte är värt det i denna lilla design, adressen måste ju ut genom ALU:n å sen tillbaks till PC:n . Jag tänker mig att MAR är den enda som matar adress bussen, så PC lägger sin adress till MAR innan den kommer till bussen. Oftast kommer flödet PC -> MAR -> ROM -> MDR vara det som är öppet, men ibland är det smidigt, t.ex. vid ld då är det bara in med adressen i MAR. Dock är ld den minst nödvändiga instruktionen just nu eftersom allt är i ROM och det är så lite minne, om nån ska bort så är det nog denna.Ang. 3 operander så tror jag att jag gör om så att det bara är två, det sparar ett ord minne vilket ju ger fler instruktioner i slutändan, det är så många instruktioner som just nu har 3 operander så det borde kunna ge en ansenlig minnesbesparing. Jag tror jag samtidigt ändrar så att det alltid är det första som är target, mv REG1, REG2 => REG1 = REG2 , add REG1, REG2 => REG1 += REG2 osv
Jo, jag vill verkligen kunna göra funktionsanrop så la till en liten stack (16-bitar, rättade lite fel i arkitekturen åxå i en senare rev av bilden). Jag har sett sånna "konstiga" lösningar åxå med em design om 16 general purpose register vara en används som stackpekare, en som PC mm mm, det är en spännande idé men blir lite bökigare tror jag.
Microkoden jag skrivit är bara för mig att komma ihåg. I min naivitet så tänkte jag att 16 instruktioner går att bygga helt med logiska grindar utan nån microkod alls, det kanske är ett dumt beslut? Jag har T1 och T2 hårt knutna till att lägga ut nuvarande instruktion på MDR samt PC++, T3-T6 går in i controllern. Jag velade länge på hur jag skulle göra men valde detta, nästa projekt kanske blir en microkodad controller istället.
Re: Komponent för 4-bit till 8-bit konvertering
ang display så skulle min "dröm" display vara ett fysiskt vred med 16 steg där varje steg motsvarar ett register, men vet inte hur jag skulle få till det utan ytterligare en buss... 
Re: Komponent för 4-bit till 8-bit konvertering
sådär, nu har jag postat det senaste: https://homebrewguy.wordpress.com/2015/ ... -4bit-cpu/
- Arkitekturbilden är uppdaterad
- Ändrade ISA efter MiaMs förslag
- La upp lite om min plan framöver
Fick till "mv IMM4, <REG>" i simulatorn imorse
- Arkitekturbilden är uppdaterad
- Ändrade ISA efter MiaMs förslag
- La upp lite om min plan framöver
Fick till "mv IMM4, <REG>" i simulatorn imorse
Re: Komponent för 4-bit till 8-bit konvertering
Sant, ld och mv # fyller ju just nu samma funktion.
Men om du ändå ska ha en stack så kan du väl lika gärna lägga på stöd för externt ram istället för internt stackminne?
Eventuellt kan du ha en rom-read, en ram-read och en ram-write-signal. Rom-read = "mv #", ram-read = "ld $" och ram-write = "out" (fast out får givetvis ha operand i stil med ld $). Då får du givetvis minnemappa någon utport och kanske även någon inport.
Enda användbarheten med ld just nu är ju om du gör om den så att något registerpar eller liknande kan vara adresspekare. Det vore förstås en användbar funktion även med ram. Utan en sådan funktion så blir det helt omöjligt att på något sätt adressera något indirekt, förutom om du skulle göra så att det går att köra kod ur ram.
Det går säkert bra att bygga allt i logik och skippa nån slags mikrokod.
Om du skulle välja att ha fast instruktionslängd och "skiftade" adresser så kan du ju låta ld $ och en st $ mot ram vara hårdkodade så att de lägsta bitarna i registerväljardelen av instruktionen också utgör lägsta delen av adressen. Om inte varje instruktion ska vara just 16 steg lång (lååångt) så lär du då få trolla lite med ADDRL och ADDRH så att det går att skriva endast vissa bitar. Det blir lite märkligt och inte så general purpose men det skulle då gå att nå mer minne om du skulle vilja.
Fast glöm det, det blir bara krångligt. Då är det bättre att hårdkoda så att t.ex. R15 är "program counter extension" och R14 är "memory pointer adress extension" eller nåt sånt.
Om du skippar SP så kan du göra om push och pop så att de tar en till parameter vardera, där denna parameter pekar ut valfritt register / registerpar som får agera stackpekare.
En budgetvariant på "relativa" hopp är att bara ladda låghalvan av PC vid vissa hoppinstruktioner, d.v.s. att du bara kan hoppa inom samma page.
För display kan du i princip göra så att den interna databussen och reg_sel (samt eventuella signaler för autoinkrement/dekrement på registren, ifall du lägger till det) dras till en displaymodul där du har en extra uppsättning latchar (samma typ som registren använder) som direkt driver lysdioder. Visst vore det väl snyggt med en ratt och en sjusegmentavkodare för att visa reginsterinnehåll, men det känns ju mer 70-tals-retro-dator med lysdioder som visar tillståndet för varje register binärt. Det är ju mest jobb och inte så mycket en pengafråga att ha 64 lysdioder för detta. Men i så fall är det väl lika bra att hänga på lysdioder för diverse andra funktioner också?
P.S. jag antar att du vill kunna köra den både fort, sakta och enkelstegat. Tänk på att kretsen som växlar mellan dessa lägen inte får vid växling råka ge pulser som är för korta för att vara en korrekt klockpuls. Sånt kan leda till att steg i instruktionerna körs dubbelt eller hoppas över, d.v.s. att sequencern stegar men steget blir inte riktigt kört (eller kört men med felaktiga data pga att bussen inte hinner med) eller omvänt att något görs i processorn men sequencern står still så att momentet kommer göras två gånger.
Men om du ändå ska ha en stack så kan du väl lika gärna lägga på stöd för externt ram istället för internt stackminne?
Eventuellt kan du ha en rom-read, en ram-read och en ram-write-signal. Rom-read = "mv #", ram-read = "ld $" och ram-write = "out" (fast out får givetvis ha operand i stil med ld $). Då får du givetvis minnemappa någon utport och kanske även någon inport.
Enda användbarheten med ld just nu är ju om du gör om den så att något registerpar eller liknande kan vara adresspekare. Det vore förstås en användbar funktion även med ram. Utan en sådan funktion så blir det helt omöjligt att på något sätt adressera något indirekt, förutom om du skulle göra så att det går att köra kod ur ram.
Det går säkert bra att bygga allt i logik och skippa nån slags mikrokod.
Om du skulle välja att ha fast instruktionslängd och "skiftade" adresser så kan du ju låta ld $ och en st $ mot ram vara hårdkodade så att de lägsta bitarna i registerväljardelen av instruktionen också utgör lägsta delen av adressen. Om inte varje instruktion ska vara just 16 steg lång (lååångt) så lär du då få trolla lite med ADDRL och ADDRH så att det går att skriva endast vissa bitar. Det blir lite märkligt och inte så general purpose men det skulle då gå att nå mer minne om du skulle vilja.
Fast glöm det, det blir bara krångligt. Då är det bättre att hårdkoda så att t.ex. R15 är "program counter extension" och R14 är "memory pointer adress extension" eller nåt sånt.
Om du skippar SP så kan du göra om push och pop så att de tar en till parameter vardera, där denna parameter pekar ut valfritt register / registerpar som får agera stackpekare.
En budgetvariant på "relativa" hopp är att bara ladda låghalvan av PC vid vissa hoppinstruktioner, d.v.s. att du bara kan hoppa inom samma page.
För display kan du i princip göra så att den interna databussen och reg_sel (samt eventuella signaler för autoinkrement/dekrement på registren, ifall du lägger till det) dras till en displaymodul där du har en extra uppsättning latchar (samma typ som registren använder) som direkt driver lysdioder. Visst vore det väl snyggt med en ratt och en sjusegmentavkodare för att visa reginsterinnehåll, men det känns ju mer 70-tals-retro-dator med lysdioder som visar tillståndet för varje register binärt. Det är ju mest jobb och inte så mycket en pengafråga att ha 64 lysdioder för detta. Men i så fall är det väl lika bra att hänga på lysdioder för diverse andra funktioner också?
P.S. jag antar att du vill kunna köra den både fort, sakta och enkelstegat. Tänk på att kretsen som växlar mellan dessa lägen inte får vid växling råka ge pulser som är för korta för att vara en korrekt klockpuls. Sånt kan leda till att steg i instruktionerna körs dubbelt eller hoppas över, d.v.s. att sequencern stegar men steget blir inte riktigt kört (eller kört men med felaktiga data pga att bussen inte hinner med) eller omvänt att något görs i processorn men sequencern står still så att momentet kommer göras två gånger.
Re: Komponent för 4-bit till 8-bit konvertering
just ja, nu föll poletten ner hos mig, man kan ju se RAM och ROM som separata adressrymder, bra tänkt! Jag tänkte hela tiden att jag bara hade 8 bitars adress som de delar på vilket ju skulle göra att de blir ganska små. Men nu när jag förstått detta så kommer jag göra som du föreslår och haka på en RAM på 8 bitar åxå.
mv #IMM4, <REG> : IMM4 -> <REG>
ld $IMM8, <REG> : RAM[IMM8] -> <REG>
st <REG>, $IMM8 : <REG> -> RAM[IMM8]
blir ju en instruktion extra så tar bort OUT. För display så kör jag minnesmappat, typ toppen av RAM: 0XF0 - 0xFF får gå direkt till 16 dioder.
Tror att det ökar komplexiteten att föra godtyckligt register som stackpekare och gillar min SP så kommer behålla min 4-bitars stackpekare och säga att stacken är första pagen i RAM: 0x00 - 0x0F. Skulle vara trevligt med ett interrupt system här så att man kan veta om den wrappar, men det får bli till senare projekt. Hakar på en diod på carryn i räknaren som jag anväder för SP istället så får man hålla koll på det själv, man kan ju koppla denna till en global HALT av hela datorn åxå om man verkligen vill
Jag har inte några planer på att köra några processer eller köra dynamisk laddning av koden, man bränner in en ROM image och kör. Eftersom denna image bara är 256 ord stor (ordlängd 4-bit, kommer inte köra på skiftade adresser) så tycker jag att absolut adressering borde fungera bra, eller glömmer jag något fundamentalt här? Jag har inga fler instruktioner kvar i min 4-bits rymd, klart man skulle kunna ta ett register och säga att det är adresserings mode mask, säg om 0 så är instruktionen IMM, 1 så är den REL, 4 så skulle den kunna vara REL en baspekare mm mm Men jag skulle föredra (och tror att det funkar) med bara IMM adressering. Jag hade ideen i början att köra det du kallar budget hopp , d.v.s. att man bara hoppar inom samma page, det sparar lite minne i slutändan men i och med att jag inte har några instruktioner över så betyder det att både brz och brc skulle ha denna addressering hårt i sig och att alltid bara kunna hoppa 16 ord är lite för begränsande tycker jag, klart man skulle ju kunna tänka sig att man har ett funktionsarop innangör om hoppet är för långt:
start:
call do_something_requiering_lots_of_instructions_returning_something_in_R0
sub number_of_loops, R0 // Are we done yet?
brz done // Guess we are
mv #0, R1
add #0, R1 // Omständigt sätt att brancha, men eftersom jag inte har en br op så
brz start // blir det såhär
done:
...
tror avståndet brz start samt start labeln blir precis 16 ord i detta exempel (om jag räknat rätt).
Bra insikt där med växlingskretsen för hastigheten, hade jag inte tänkt på överhuvudtaget! Hur skulle en sådan krets se ut? Ska sekvenser timern vara "intern" i CPU:n sen får man haka på en extern kristall som vid en pulse gör att den interna klockan kör igenom en full sekvens kanske?
mv #IMM4, <REG> : IMM4 -> <REG>
ld $IMM8, <REG> : RAM[IMM8] -> <REG>
st <REG>, $IMM8 : <REG> -> RAM[IMM8]
blir ju en instruktion extra så tar bort OUT. För display så kör jag minnesmappat, typ toppen av RAM: 0XF0 - 0xFF får gå direkt till 16 dioder.
Tror att det ökar komplexiteten att föra godtyckligt register som stackpekare och gillar min SP
så kommer behålla min 4-bitars stackpekare och säga att stacken är första pagen i RAM: 0x00 - 0x0F. Skulle vara trevligt med ett interrupt system här så att man kan veta om den wrappar, men det får bli till senare projekt. Hakar på en diod på carryn i räknaren som jag anväder för SP istället så får man hålla koll på det själv, man kan ju koppla denna till en global HALT av hela datorn åxå om man verkligen vill Jag har inte några planer på att köra några processer eller köra dynamisk laddning av koden, man bränner in en ROM image och kör. Eftersom denna image bara är 256 ord stor (ordlängd 4-bit, kommer inte köra på skiftade adresser) så tycker jag att absolut adressering borde fungera bra, eller glömmer jag något fundamentalt här? Jag har inga fler instruktioner kvar i min 4-bits rymd, klart man skulle kunna ta ett register och säga att det är adresserings mode mask, säg om 0 så är instruktionen IMM, 1 så är den REL, 4 så skulle den kunna vara REL en baspekare mm mm Men jag skulle föredra (och tror att det funkar) med bara IMM adressering. Jag hade ideen i början att köra det du kallar budget hopp
, d.v.s. att man bara hoppar inom samma page, det sparar lite minne i slutändan men i och med att jag inte har några instruktioner över så betyder det att både brz och brc skulle ha denna addressering hårt i sig och att alltid bara kunna hoppa 16 ord är lite för begränsande tycker jag, klart man skulle ju kunna tänka sig att man har ett funktionsarop innangör om hoppet är för långt:start:
call do_something_requiering_lots_of_instructions_returning_something_in_R0
sub number_of_loops, R0 // Are we done yet?
brz done // Guess we are
mv #0, R1
add #0, R1 // Omständigt sätt att brancha, men eftersom jag inte har en br op så
brz start // blir det såhär
done:
...
tror avståndet brz start samt start labeln blir precis 16 ord i detta exempel (om jag räknat rätt).
Bra insikt där med växlingskretsen för hastigheten, hade jag inte tänkt på överhuvudtaget! Hur skulle en sådan krets se ut? Ska sekvenser timern vara "intern" i CPU:n sen får man haka på en extern kristall som vid en pulse gör att den interna klockan kör igenom en full sekvens kanske?
Re: Komponent för 4-bit till 8-bit konvertering
Den här bloggen verkar ha kopplingar för enkelstegning och klockoscillatorer, visserligen för Z80 men det spelar ju ingen roll
https://z80project.wordpress.com/
Jag har inte tittat på detaljerna ännu, hittade just den och tänkte läsa igenom om det står nåt intressant.
Om du vill så kan du låta stackinstruktionerna respektive ld/st skiljas sig åt genom att en utgång sätts olika beroende på vad som körs. Då kan du både nå 256 nybble vanligt ram och ovanpå det ha en separat stack. Jag misstänker att det blir väl ändå svårt att få tag på ram-minnen som är så små som 256 nybble, så du lär väl ändå få ram över.
Jag vet inte var gränsen går för hur små ram man kan finna utan att behöva "konstiga" spänningar. Jag tror att för dynamiska ram går gränsen nog vid 64 kilobit eller liknande, men vet att det finns statiska ram om 1k nybble som klarar sig på 5V. Likaså är 2716 det minsta 'vanliga' eprom:et som klarar sig på 5V, de tidigare 2708 och 1702 behövde flera spänningar (och 1702 är dessutom en riktig utmaning att programmera).
Men eftersom du ändå kommer ha samma adress- och databuss för ram och rom så kunde det kanske vara läge att lägga till någon slags separat hårdvara för att kunna välja att köra kod från rom eller från en avskiljd del av ram. På så sätt kan du bränna in en 'standardkod' i rom som via någon slags I/O kan läsa in data till ram och sedan kan processorn stoppas och växlas till att köra kod från ram. (Detta skulle förstås också kräva att den area av ram som processorn kan läsa/skriva i "rom-läge" istället blir den area som kod körs ur i "ram-läge").
M.v.h. mästarn på feature-creep
https://z80project.wordpress.com/
Jag har inte tittat på detaljerna ännu, hittade just den och tänkte läsa igenom om det står nåt intressant.
Om du vill så kan du låta stackinstruktionerna respektive ld/st skiljas sig åt genom att en utgång sätts olika beroende på vad som körs. Då kan du både nå 256 nybble vanligt ram och ovanpå det ha en separat stack. Jag misstänker att det blir väl ändå svårt att få tag på ram-minnen som är så små som 256 nybble, så du lär väl ändå få ram över.
Jag vet inte var gränsen går för hur små ram man kan finna utan att behöva "konstiga" spänningar. Jag tror att för dynamiska ram går gränsen nog vid 64 kilobit eller liknande, men vet att det finns statiska ram om 1k nybble som klarar sig på 5V. Likaså är 2716 det minsta 'vanliga' eprom:et som klarar sig på 5V, de tidigare 2708 och 1702 behövde flera spänningar (och 1702 är dessutom en riktig utmaning att programmera).
Men eftersom du ändå kommer ha samma adress- och databuss för ram och rom så kunde det kanske vara läge att lägga till någon slags separat hårdvara för att kunna välja att köra kod från rom eller från en avskiljd del av ram. På så sätt kan du bränna in en 'standardkod' i rom som via någon slags I/O kan läsa in data till ram och sedan kan processorn stoppas och växlas till att köra kod från ram. (Detta skulle förstås också kräva att den area av ram som processorn kan läsa/skriva i "rom-läge" istället blir den area som kod körs ur i "ram-läge").
M.v.h. mästarn på feature-creep
