Zum spielerischen Verständnis, wie z.B. ein Gigatron-TTL-Microcomputer funktioniert, ist dieses Onlinegame ganz interessant:
Onlinespiel zum Bau eines TTL-Computers
-
YEAH ...ich hab beim 2. Versuch doch tatsächlich das erste Level gelöst!
puh - gar nicht so einfach mit Relais....
-
woah, das ist super cool. ich hab keine ahnung von der materie, aber es macht voll spass. die ersten drei level sind geschafft.
-
Sehr coole Sache! Erinnert mich an meine Studienzeit, da hatten wir eine Übung mit "Digisim" am Mac - macht echt Spaß!
-
Ja, echt gut.
-
Voll cool das Ding!
Die Hardware ist schnell gemacht.
Der Assembler Code ist sehr gewöhnungsbedürftig ...
-
Bis Computer bin ich auch gekommen.
Irgendwie komme ich mit dem Edit ROM nicht klar. Und beim Check kommt eigentlich immer die gleiche Fehlermeldung.
Kannste mir da ein Tipp geben?
-
-
Bis Computer bin ich auch gekommen.
Irgendwie komme ich mit dem Edit ROM nicht klar. Und beim Check kommt eigentlich immer die gleiche Fehlermeldung.
Kannste mir da ein Tipp geben?
An du meinst Levels -- Software -- Low Level -- Machine Code??
Ganz ehrlich?
Ich hab einfach nur herum probiert.
Solange bis es geklappt hat.
Aber das kannst du auch getrost überspringen.
Interessant wird es eh erst danach.
Mit dem Assembler.
Die Bit Ebene des Microcode ist sogar mit zu hart.
Danach wird es richtig gut!
Der baut eine Stack Machine auf.
Eine Art FORTH.
Genial!
Es gibt sogar einen Tokenizer und einen Syntax Ruler.
-
Ne, noch bei Levels - Processor - Computer.
-
Ne, noch bei Levels - Processor - Computer.
Ah das Ding ...
Sieht nicht gut aus, funktioniert aber.
-
Genau.
Was passiert wenn du auf Check solution klickst?
Bei mir kommt immer
Auch wenn ich ROM aendere usw.
-
Komisch, hab's nochmal neu verkabelt, sah ganz schlimm aus, und jetzt geht's ploetzlich.
-
Oh Mann, ein Prozessor mit nur zwei Registern ist echt anstrengend
-
Oh Mann, ein Prozessor mit nur zwei Registern ist echt anstrengend
Ja das ist echt herausfordernd ...
Speziell da ein Register eigentlich nicht zählt, man braucht es ja immer sobald Adressen im Spiel sind.
Hinzu kommt 'immediate' geht auch nur mit dem Adress Register.
Aber die Stack Machine hebt dann alle Beschränkungen auf.
-
Bis auf "Network" hab ich jetzt alle Level.
Den letzten krieg ich irgendwie nicht gebacken.
-
Ja das block ich auch nicht so ganz. Ist das Datenbit bei jeder Flanke gültig oder nur bei Steigender? Hat das Startbit auch ein Sync?
-
"Network"
Bei mir gehen die LEDs am IO-Port an und aus, aber nicht auf der Gegenseite.
Ist das bei euch auch so?
-
Noch beim Prozessor, aber es wird langsam tricky: Das ging noch:
Aber dazu bin ich zu blöd: Wo soll R hin?
-
Überleg mal, wenn du eine Operation D=D+A machen willst, wie kommt das Ergebnis D+A ins Register D?
-
Ist das bei euch auch so?
Nee, die LED funktionieren tadellos.
Inzwischen geht auch der Code.Ist allerdings nicht meiner.
Hab jetzt irgendwo gelesen, der Emulator kann nicht mit selbst modifizierenden Code umgehen.
Deswegen ist mein Code wohl nicht gelaufen.
Network Code - Achtung Spoiler:Code
Alles anzeigen# Allocate space for variables. DEFINE sync 50 DEFINE counter 51 DEFINE y 52 DEFINE currentLine 53 DEFINE networkWire 0x6001 # (There's no particular reason # I chose slots 50–53. # More detailed descriptions below) # Initialize sync variable. # This variable will hold the # most recently measured value of # the sync bit, not the sync bit # (which is at address 0x6001) # itself. That means that between # the time that the real sync bit # changes and the time that this # variable is updated to reflect # that, their values will # be different A=0b10 D=A A=networkWire D=D&*A A=sync *A=D # Initialize y. # This variable will hold the # y-coordinate of the line on the # display screen on which we will # next print A=0x4000 D=A A=y *A=D # This code reads and prints lines # until message has terminated #~~~~~~~~~~ LABEL LineReaderPrinter # Wait for control bit. If sync bit # changes whilst waiting for # control bit, the message # has terminated #---------- LABEL WaitingForControlBit # Check sync bit A=0b10 D=A A=networkWire D=D&*A # Jump to end if different # from most recent sync bit value A = sync D=D-*A A=End D;JNE # Check data bit A=0b1 D=A A=networkWire D=D&*A # Begin when data bit is 1 A=WaitingForControlBit D-1;JNE #---------- # Initialize line to 0 (blank). # After 16 bits have been read, # the line will be printed A=currentLine *A=0 # Initialize counter to 0. # This variable will count how # many bits of the current line # have been read thus far. A=counter *A=0 # The code below reads 16 bits #•••••••••• LABEL notFinishedLine # Wait for sync bit to change #………………………… LABEL syncStillSame # Get sync bit A=0b10 D=A A=networkWire D=D&*A # Compare to current sync variable A=sync D=D-*A # Check whether it has changed A=syncStillSame D;JEQ #………………………… # Once sync bit changes, # update sync variable A=0b10 D=A A=networkWire D=D&*A A=sync *A=D # Read data bit A=0b1 D=A A=networkWire D=D&*A # Add bit to line A=currentLine *A=D+*A # Shift all bits in current line # one space to left to make room # for next bit (this is equivalent # to doubling the binary value of # the current line) D=*A *A=D+*A # Increment counter and check # whether all 16 bits have # been read A=16 D=A A=counter *A=*A+1 D=D-*A A=notFinishedLine D;JGE #•••••••••• # Set value of display address # specified by y to the value of # the line that was just read A=currentLine D=*A A=y A=*A *A=D # Set y-coordinate of next line A=0x20 D=A A=y *A=D+*A # Start next line A = LineReaderPrinter JMP #~~~~~~~~~~ LABEL End -
der Emulator kann nicht mit selbst modifizierenden Code umgehen.
Sowas gehört auch nicht zur gängigen Praxis.
-
Heutige Praxis ist es ja sowieso, dass Code nur noch aus Bibliotheken besteht, die komplett eingebunden werden, sowass jedes noch so kleine Programm plötzlich GB groß ist, wo vor einigen Jahrzehnten kB reichten bei selber Funktionalität bei abweichender Optik.
Das Hardwarezeug habe ich durch, war ganz nice, das Programmierzeug macht mir keinen Spaß, Assembler dürfte ~15 Jahre her sein bei mir...
-
Heutige Praxis ist es ja sowieso, dass Code nur noch aus Bibliotheken besteht, die komplett eingebunden werden
Bei PCs kann man das machen, aber nicht im Embedded Bereich.
Im aktuellen Projekt hatte ich die Aufgabe einen Bootloader zu schreiben, um Updates machen zu können.
Zur Verfügung stehen 12kB Flash, da verbieten sich Bibliotheken von vorn herein.
-
Das stimmt natürlich, dass sowas im µC-Bereich nicht geht.
Wobei es auch zugemüllte Embedded Systeme gibt, welche wiederum auch genug Leistung dafür haben, was natürlich eine Rechenleistungsverschwendung ist.
Erzähl mal: RS232, USB, Internet, wo kommen die Updates her? Letzteres wäre in 12kB schon eine Leistung
-
Die Rechenleistung und auch die Anzahl der Schnittstellen ist nicht das Problem.
Bei diesem Bootloader kommen die Updates über eine CAN-Schnittstelle.
TCP/IP wirst du in 12kB nicht unterkriegen, UDP/IP vielleicht, das habe ich auch selber mal geschrieben.
-
Es sind auch die optionalen Level nicht schlecht.
Zum Beispiel der Barrel Shifter.
Meine ersten Versuche sind gleich ausgeartet und unübersichtlich geworden.
Aber dann habe ich die "Custom Components" entdeckt.
Da sieht die Sache gleich besser aus:
