Space Age 2 der 32Bit MIPS Rechner in TTL

[Fritzler]

Das PLCC mit Glas hab ich jetzt gefunden, wusste ganicht, dass es sowas auch gibt.
Mit seinen 120ns aber zu langsam. Das ist ja schon fast die halbe Taktzeit von den 4MHz und dann kommt da noch 2x nen XOR, 2x nen MUX und die HOLD Zeit des Registers will auchnoch eingehalten werden.
Auf ebay werden ja auch die normalen 27C1024 angeboten, aber zu viel höheren Preisen.
Wer kauft sowas?
Garantiert original bei Mouser für 3,xx€ und bei ebax 5€, 7€ und mehr.
(PLCC oder DIL wär egal)
Aber ich hab ja welche und mein mage passt ja.

Der 60$ im Keramikgehäuse sieht ja auch nett aus.
Aber wieso gibts die 28er EEPROM Variante nicht mehr neu, aber die 27er EPROM Variante schon? Merkwürdig.
Bei den 74181 der ALU hat Henry übrigens auf die violette Keramik Version bestanden

[Fritzler]

Dank des schnelleren aufspielen der Software konnte ich jetzt eingrenzen wo das Problem liegt, aber noch nicht was es auslößt.
Jedenfalls wird die CRC in Hardware falsch berechnet und es kann auch mal ein ganz anderes Ergebnis als vorher rauskommen.
Da ist bei der Synthese und Implementation wohl was schiefgelaufen.
Aber trotz falscher CRC müsste eigentlich das Paket trotzdem gesendet werden, aber ich empfange keins. (interner Loopback in Hardware)
In der Simulation hatte alles funktioniert, also das wird jetz lustig zu suchen.

Der GDB ist jetzt im makefile gescripted, also nurnoch ein "make upload".
Dann wird gebaut und aufgespielt.

Dann wollte ich das verify noch beschleunigen.
Denn ohne den "qCRC" Befehl wird der Speicher normal zurückgelesen.
Diesen befehl gibts leider nicht als binär, womit der INhalt als Hexstring übertragen wird.
Gleichzeitig ignoriert der GDB meine mitgeteilte Paketgröße von 8kbyte und fragt nur 1kbyte ab.
Dadurch kann ich auch die USB CDC Pakete nicht vollschaufeln.
Also schön langsam.

Daher den qCRC Befehl implementiert und da rennt er in einen Timeout.
Denn das Auslesen von 64kbyte aus dem MIPS TTL Speicher dauert länger als das Standardtimeout von 2s.
Das könnte ich jetzt hochdrehen, aber wenn das Programm immermal größer wird renn ich da doch wieder rein.
Mal gucken wie ich das löse.

[Fritzler]

Manchmal brauchts eben etwas Pause und Abstand vom Problem.
Heute dann nochmal auf den VHDL Code geguckt und direkt ein paar Verdrahtungsfehler entdeckt.
Ansonsten auch noch zwei Tristates manuell aufgelöst falls die Synthese da Mist gebaut hat.

Siehe da! Es funzt.


Das Ganze ist ein Loopback im FPGA.
Also der MII geht nicht zu einem echten Ethernet PHY, sondern TX MII ist noch FPGA intern mit dem RX MII verbunden.
Es soll ja erstmal nur getestet werden.

Als Paket wird der String "123456789" verschickt.
Das ist auch der Teststring zum Testen von CRC Implementierungen.
Der Resultierende CRC von "cbf43926" ist endlich korrekt!

Das gesendete Paket wird wieder empfangen und die Checksumme über das Ganze Paket stimmt auch.
Da kommt dann die magische Nummer "2144DF1C" raus.

Als nächstes kommen die MII Signale aus dem FPGA raus und gehen an einen PHY.
Dann guck ich mal ob ein UDP Paket an meinem PC per Wireshark ankommt.
Danach dan ICMP (Ping) einbauen.

[Fritzler]

Auch mit der Außenwelt funktioniert das jetzt!

Von einem früheren Projekt lag noch ein Eigenbau Ethernet PHY Breakoutboard rum.
Also mal an das FPGA Board angeschlossen:


Schon ließen sich die ersten Broadcasts des Heimnetzwerks einfangen:


Ein Ping geht auch:



Damit wär der FPGA Test abgeschlossen und es kann an der Software weitergearbeitet werden.
Denn jetzt wird die Lankarte im Simulator nachgebaut.
So muss ich nicht immer an die Hardware ran um Software zu testen.

[Fritzler]

An diesem stürmischen Sonntag habe ich jetzt die Lankarte im Emulator "eingebaut".

Dies wird durch ein TAP Interface zum Linuxkernel ermöglicht und darauf wird dann noch eine Bridge geworfen damit es nach draußen telefonieren kann.
https://de.wikipedia.org/wiki/TUN/TAP
(Das geht in C einfacher als man denkt!)



Noch die Konsolenausgabe beim Starten des Emulators:

MIPS EMU: initialisiere Space Age 2 IOs
UART: starting xterm (pid 24380) on /dev/pts/12
Lankarte: FIFO init
Lankarte: TAP name: tapSP2
Lankarte: TAP fd: 11
Lankarte: erstelle Netzwerbruecke eth0 -> brSP2 -> tapSP2
Lankarte: sudo ip link set tapSP2 up
Lankarte: sudo ip link add brSP2 type bridge
Lankarte: sudo ip link set tapSP2 master brSP2
Lankarte: sudo ip link set dev eth0 down
Lankarte: sudo ip addr flush dev eth0
Lankarte: sudo ip link set dev eth0 up
Lankarte: sudo ip link set eth0 master brSP2
Lankarte: sudo ip link set dev brSP2 up
Lankarte: sudo dhclient brSP2
MIPS EMU: alloziere MIPS CPU Speicher
MIPS EMU: fülle MIPS CPU Speicher (74732 bytes)
MIPS EMU: starte MIPS CPU

Ja, der Emulator richtet die Brücke automatisch ein

[Chefbastler]

Bin gespannt wann der erste Beitrag hier mit dem Rechner geschrieben wird.

[Fritzler]

Du wirst lachen, ich hab schon geguckt inwiefern Lynx portierbar wäre
https://de.wikipedia.org/wiki/Lynx_(Browser)
Das sah auch erstmal vielversprechend aus.

Die Planung ist aber erstmal auf der VCFB20 Emails verschicken und lesen zu können.
Wenn das geht knöpf ich mir den Lynx vor!

[andreas6]

Arachne als Browser habe ich schon unter Dos benutzt. Dank Personal Netware hatte das einen Ip-Stack und konnte das Web benutzen. Ist zwar spartanisch und ohne Grafik, ansonsten doch nutzbar. Und wirklich lange her...

MfG. Andreas

[Fritzler]

Wenn die Quellen stimmen, dann ist Arachne schon grafisch.
Das wird etwas schwierig auf dem VT100
Aber merk ich mir mal vor falls mal eine Grafikkarte fertig wird.

Arachne sieht aber auch ziemlich tot aus, letztes Update in 2013:
http://glennmcc.org/

Bei Lynx gibts auch 2019 noch Changelogs:
https://lynx.invisible-island.net/current/CHANGES

[Fritzler]

Der lwIP läuft jetzt im Emulator!

[Fritzler]

So der LWIP läuft vollständig, also das Webserverbeispiel geht auch:


Konsolenausgabe:
init lancard err = 0

init lwip

done

netif status changed 192.168.178.220
lancard: send a packetwritten crc32: 0x2144df1c

err = 0

httpd_init
dhcp_coarse_tmr()
dhcp_coarse_tmr()
dhcp_coarse_tmr()
dhcp_coarse_tmr()
dhcp_coarse_tmr()
dhcp_coarse_tmr()
lancard: send a packetwritten crc32: 0x2144df1c

err = 0

lancard: send a packetwritten crc32: 0x2144df1c

err = 0

http_accept 0x409dc8 / 0x0
http_recv: pcb=0x409dc8 pbuf=0x409268 err=0
Received 333 bytes
First pbuf
CRLF received, parsing request
Received GET request"
Received "GET" request for URI: "/"
Looking for /index.shtml...
Looking for /index.ssi...
Looking for /index.shtm...
Looking for /index.html...
Opened.
http_recv: data 0x2d840 len 1905
http_send: pcb=0x409dc8 hs=0x402f4c left=1905
Trying to send 1072 bytes
Sent 1072 bytes
send_data end.
lancard: send a packetwritten crc32: 0x2144df1c

err = 0

lancard: send a packetwritten crc32: 0x2144df1c

err = 0

http_sent 0x409dc8
http_send: pcb=0x409dc8 hs=0x402f4c left=833
Trying to send 833 bytes
Sent 833 bytes
End of file.
Closing connection 0x409dc8
lancard: send a packetwritten crc32: 0x2144df1c

err = 0

lancard: send a packetwritten crc32: 0x2144df1c

err = 0

lancard: send a packetwritten crc32: 0x2144df1c

err = 0

lancard: send a packetwritten crc32: 0x2144df1c

err = 0

http_accept 0x409d28 / 0x0
http_recv: pcb=0x409d28 pbuf=0x409268 err=0
Received 289 bytes
First pbuf
CRLF received, parsing request
Received GET request"
Received "GET" request for URI: "/img/sics.gif"
Opening /img/sics.gif
http_recv: data 0x2e2ac len 877
http_send: pcb=0x409d28 hs=0x402ef8 left=877
Trying to send 877 bytes

[Fritzler]

Langes Wochenende, Feiertage, aber Familie besuchen is eher nich so?
Dann machen wir hier doch mal weiter!

Der lwip läuft ja schonmal auf dem FPGA mit echtem PHY.
Aber zur VCFB20 sollen Emails verschickt und empfangen werden.
Also mal zu POP3 und SMTP eingelesen und dann ersteinmal mit normalen Sockets in Linux gehackt.

Parsen der POP3 Header:


Anzeigen der eigentlichen Nachricht:
(ich musste Anhänge implementieren um diese rausfiltern zu können, sonst sieht man nur einen Wall of base64 Text)


Das läuft jetzt noch mit den synchronen Posix Sockets.
Der lwip kann ohne ein OS aber nur die asynchrone callback API-
Daher muss ich das jetzt noch so umbauen, dass das Programm mit reingereichten Buffern umgehen kann.

Danach brauchts dann noch ein TUI (Text User Interface) für das VT100.

[Fritzler]

ARGHS!
Eine weitergeleitete Email mit Anhang baut noch einen zweiten Header in die Email selber ein.
Das hat ja jetzt mal so garkein Spaß gemacht beim parsen.

Mailheader:

Code: Alles auswählen

Content-Type: multipart/mixed;
 boundary="------------13CB9E81FB5F5F352C88F54F"

Mailbody:

Code: Alles auswählen

This is a multi-part message in MIME format.
--------------13CB9E81FB5F5F352C88F54F
Content-Type: multipart/alternative;
 boundary="------------E9DFF5FDBFF962D7E7E14EB2"


--------------E9DFF5FDBFF962D7E7E14EB2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


-------- Weitergeleitete Nachricht --------
Betreff: 	Fwd: gggg
Datum: 	Sun, 12 Apr 2020 11:16:37 +0200
TEEEEEEEEEEEEEEEEEXT

Un noch was schönes neues:
subject: =?UTF-8?Q?DIn_Norm_Abst=C3=A4nde?=
Darauf hab ich jetz echt kein Bock!

[nero]

Warum nehmt ihr für die höheren Schichten nicht fertige S, in dem Fall zB mutt?

[Fritzler]

Warum nehmt ihr für die höheren Schichten nicht fertige S, in dem Fall zB mutt?

Weil das noch nicht geht.
Kein OS vorhanden, aber mutt braucht eins.

Stell es dir noch als übergroßen Mikrocontroller vor
Ein OS gibts erst mit der nächsten Entwicklungsstufe.
Dann gibts Timer, Interruptcontroller, IDE

Die Lankarte war aber erstmal reizvoller

PS:
Welcher Sepp kam auf die Idee Email Plaintext noch base64 zu encoden?
Ist aber optional.

Code: Alles auswählen

--_000_182440F6DF383F43A288C72B997B697A07D261DD58A2MEOCLINICSB_ 
Content-Type: text/plain; charset="utf-8" 
Content-Transfer-Encoding: base64

[sukram]

Sobald du im Plaintext mehr als 7bit pro Char verwendest - also alles was kein ASCII ist, wird codiert. Wäre zumindest meine Interpretation. Denn sonst würdest du bei Klartextübertragung Steuerzeichen ins Modem schicken (auf Dialin Verbindungen von anno damals gedacht)... So alt ist Email schon

[Fritzler]

Das wär durchaus ne Erklärung.

Jedenfalls hab ich jetzt mal auch per POP3 mein eigenes Postfach abgerufen und nicht nur das Testpostfach.
Das funktioniert schonmal so weit.

JETZT kann ich anfangen das auf asynchron umzubauen.

[Fritzler]

Ein erstes Lebenszeichen im Simulator mit lwip:


Jetz muss ich aber gucken wieso er nach Zeit X aufhört zu empfangen.

Aber das muss man sich mal vorstellen:
Emails abrufen in einem selbst geschriebenen Emulator, der einen selbstgebauten MIPS Rechner emuliert und dann auchnoch Netzwerk kann
Der Simulator führt nämlich das Binärfile aus dem GCC aus, das sonst auch auf der echten Hardware läuft.

[Fritzler]

Ick freu mirn Kullerkeks!

Auf dem FPGA gehts auch:


Auf dem echten Prozessor mit 4MHz ist das auch garnicht mal so langsam wie gedacht.
Das Langsame sind die 9600baud zum Terminal

[Chefbastler]

Wieviele Testmails hatt der Ludwig jetzt im Postfach?

[Fritzler]

Ooooch, so viele nu auch wieder nich.
Vllt so 3-5?

So soll das Programm dann mal aussehen:


Bisher geht nur die Taste r/R zum Abrufen der Emailheader und die Darstellung derer.

Demnächst muss dann noch eine Auswahl der Emails erfolgen mit den Pfeiltasten und dann kann man sich auch schonmal eine angucken.

[MSG]

Das Langsame sind die 9600baud zum Terminal

He, das war mal anfang der 90er High-End!

Auch wenn ich dir manchmal nicht so ganz folgen kann... es ist ein tolles Projekt!

[Chefbastler]

Das Langsame sind die 9600baud zum Terminal

He, das war mal anfang der 90er High-End!

Da darfst du nochmal 10 Jahre zurück.

[Fritzler]

He, das war mal anfang der 90er High-End!

Da darfst du nochmal 10 Jahre zurück.

Jap, son VT101 wurde doch 83 auf den Markt geworfen?

Das kann ich zwar auch auf 19200baud stellen, aber dann bekomm ich nach ein paar Zeichen ein XOFF.
Selbst mit 9600 baud kann man das überrennen wenn man nicht auf XOFF achtet-
Wir erinnern uns an einen der Bugs nach der MulDiv Karte?
Die Umwandlung Zahl -> String war dann so schnell, dass das Vt101 mit 9600 Baud überrant wurde.
XOFF/XON war da noch nicht eingebaut, weil es ja noch nicht gebraucht wurde

Der MIPS TTL Rechner hat ja 2 UART.
Da kann ich dann mal benchen inwiefern das VT101 bremmst.

Aber der UART TX Buffer wird wohl noch auf 10k ioder so aufgeblasen
Dann kann er wenigstens was per TCP empfangen/dekodieren währenddessen der UART noch die Zeichen per IRQ raushustet.

Auch wenn ich dir manchmal nicht so ganz folgen kann... es ist ein tolles Projekt!

Jo, danke.
Wenn was nicht klar ist erklär ich das gerne.
Man muss nur fragen

Das soll ein Rechner "von Grund auf" werden.
Daher wird er aus TTL gattern gebaut und bekommt mit der Zeit immer mehr Funktionen.
Mit der Netzwerkkarte zB ergeben sich jetzt sehr viele Möglichkeiten!
Wenn dann die IDE Karte für eine Festplatte corhanden ist kann ich mit einem Betriebsystem anfangen, dann wird das Teil so richtig benutzbar.

[MSG]

Da darfst du nochmal 10 Jahre zurück.

Bei uns an der Uni war der Modem Pool noch mit 9600er Modems... Deswegen meinte ich, dass das ganz ok war. Vermutlich war das seriell schneller

[Fritzler]

Was mir noch einfällt:
Da ich jetzt den xterm* nutze für die User Interface Ausgabe kann ich ja kein printf debugging mehr von dem machen was im Hintergrund abläuft.
Da muss ich wohl auch im Emulator mal den zweiten UART in betrieb nehmen.
In Grundzügen ist der ja schon da, er muss nur mit einem zweiten xterm verknüpft* werden.
Dann kann ich darauf die Debugausgaben umleiten.

Auch wenn das Programm eine Statuszeile hat für Fehlermeldungen aller Art will man ja noch wissen was genau dazu führte.

*Der Emulator öffnet einen virtual serial und wirft das einem xterm rein

[Fritzler]

Heute hatte ich eher Lust etwas an der Zeichenkodierung zu spielen.

Im Betreff einer email ist nur 7Bit ASCI erlaubt.
Daher gibts Codierungen um dort trotzdem UTF8 reinzupressen.
-> Base64
-> Quoted, quasi 8Bit als 2 HEX chars dargestellt mit einem Escapezeichen.
Beides enthält dann den UTF8 String.

Nur ein VT100 kann kein UTF8, daher müssen "böse" Bytes gelöscht werden oder Umlaute werden ersetzt durch zB ue.

Kann keiner lesen:


Die UTF8 Strings ausgepackt, aber unten rechts das ü ist Murks:


Na geht doch:

[NilsH]

Im Betreff einer email ist nur 7Bit ASCI erlaubt.
Daher gibts Codierungen um dort trotzdem UTF8 reinzupressen.
-> Base64
-> Quoted, quasi 8Bit als 2 HEX chars dargestellt mit einem Escapezeichen.
Beides enthält dann den UTF8 String.

Dabei aber nicht vergessen, dass längere Kopfzeilen in der E-Mail umgebrochen
werden können und die Angabe der Kodierung dabei auf jeder Zeile wiederholt wird!
Das hier z.B. hat Thunderbird fabriziert:

Code: Alles auswählen

Subject: =?UTF-8?Q?Falsches_=c3=9cben_von_Xylophonmusik_qu=c3=a4lt_jeden_gr?=
 =?UTF-8?B?w7bDn2VyZW4gWndlcmcuIFBvbHlwaG9uIHp3aXRzY2hlcm5kIGHDn2VuIE3DpHhj?=
 =?UTF-8?Q?hens_V=c3=b6gel_Jogurt=2c_R=c3=bcben_und_Quark=2e?=

Diese Abwärtskompatibilität bis ins Jahr 1982 ist doch toll!

[Fritzler]

BÄRGHS!
Mittendrinn wird ja auchnoch die Kodierung geändert.

Aber danke für den Hinweis, muss ich den Parser anpassen.

Beim Text gibts ja dann auchnoch Escapes ohne Ende.

[Fritzler]

So geht:
Subj: Falsches Ueben von Xylophonmusik quaelt jeden groesseren Zwerg. Poly
Da ist dann auch schon der Bildschirm zuende.

Vor allem hört das eine Coding mitten im Wort "groesseren" auf

[Fritzler]

Auch nach ü2 Wochen hab ich mich noch nicht so recht daran gewöhnt, dass ich vom Homeoffice für die Firma nahtlos ins Frickeln wechseln kann.
Is ja dieselbe Wohnung.

Jedenfalls kann das Mailprogramm jetzt auch die durch die reingekommenen Emailheader scrollen.
Damit sich dann später auswählen lässt wen man_
- löschen will
- antworten will
- oder einfach nur lesen will

Jedenfalls kam mir beim scrollen noch das hier zu Gesicht:

Subj: =?iso-8859-15?Q?Ihre_R=FCcksendung_ist_bei_uns_eingegangen?=

War ja irgendwie auch klar, dass da auch iso reinspielen kann.
Na dann bauen wir das eben früher als geplant ein.

[Fritzler]

Bei UTF8 reicht ein kleines switchcase um die paar anzeigbaren Umlaute aus dem Bereich von 2 Milliarden Buchstaben rauszufischen.
Aber vom ISO gibts mehrere Varianten und es werden nur die oberen 128 Zeichen von 8Bit codiert.
Da lohnt sich dann kein schwitchkäse im switchkäse, außerdem ist sowas hässlich.

Also nimmt man eine Tabelle, aber da hab ich jetzt auch kein Bock 16x128 Dinge einzutippen.
Hoch sollen sie leben die Designated Array Initializers vom GCC!

Code: Alles auswählen

#define INDISO(x) (x-0xA0)
#pragma GCC diagnostic ignored "-Woverride-init" // we want to first init everything to NULL and then add some chars
static const char* const isotable[16][95] = {
	
	[0 ... 15] = { [0 ... 94] = NULL },
	[14] = {[INDISO(0xA3)] = pound, [INDISO(0xA4)] = euro, [INDISO(0xA5)] = yen, [INDISO(0xA7)] = paragraph, [INDISO(0xAB)] = dubleft, [INDISO(0xB0)] = degree, [INDISO(0xB5)] = micro, [INDISO(0xBA)] = degree, [INDISO(0xBB)] = dubright, [INDISO(0xC4)] = umA, [INDISO(0xD6)] = umO, [INDISO(0xD7)] = cross, [INDISO(0xDC)] = umU, [INDISO(0xDF)] = umsz, [INDISO(0xE4)] = uma, [INDISO(0xF6)] = umo, [INDISO(0xFC)] = umu},
};
#pragma GCC diagnostic pop

Code: Alles auswählen

static const char pound[] = "GBP";
static const char yen[] = "YEN";
static const char currency[] = "CUR";
static const char paragraph[] = "PAR";
static const char degree[] = "DEG";
static const char euro[] = "EUR";
static const char dubleft[] = "<<";
static const char dubright[] = ">>";
static const char micro[] = "u";
static const char umA[] = "Ae";
static const char uma[] = "ae";
static const char umO[] = "Oe";
static const char umo[] = "oe";
static const char umU[] = "Ue";
static const char umu[] = "ue";
static const char divsign[] = "/";
static const char cross[] = "x";
static const char umsz[] = "ss";

[Konsole]

Daß das Problem "Mailprogramm für die Konsole" schon mehrfach gelöst worden ist, weißt Du aber schon?
Zumindest als Code-Steinbruch könnten taugen: mail/mailx, elm, pine, mutt.

Ansonsten: mein tief empfundener Respekt für dieses Projekt!

Grüße
Michael

[Fritzler]

Daß das Problem "Mailprogramm für die Konsole" schon mehrfach gelöst worden ist, weißt Du aber schon?
Zumindest als Code-Steinbruch könnten taugen: mail/mailx, elm, pine, mutt.

Ja türlich ist mir klar, dass es da Progamme gibt.

Dieses Projekt setzt aber auf den Selbstbau wos geht.
Bei Email geht das noch, ein Webbrowser werd ich sicher nicht selber schreiben.

Die Zeichenencodings sind jetzt auch nur der kleinste Teil des Programms.
Die Nutzung der lwip Callback API für POP3/SMTP hatte mehr Zeit verbraucht.

Ein Eigenbau OS mit Unix/Posix Syscalls is ja geplant, dann geht vllt auch mailx direkt.

Ansonsten: mein tief empfundener Respekt für dieses Projekt!

Danke dafür

[Fritzler]

Momentan sitze ich an einem Stück Code der wirklich keinen Spaß macht: Die Texteingabe!
Sowas habe ich bisher nur in halb fertig.
Denn bisher reichten für meine Programme Einzeiler für eine Konsole, aber das ist hier nicht mehr der Fall.
Zudem kann das VT100 kein Zeichen insert mit automatischen in der Zeile rumschieben.
Daher fällt wohl ne fertige lib eh raus.

Der Zeilen
umbruch soll ja nicht nur hart in einem Wort erfolgen (wie auf der Linuxkonsole), sondern auch zur Texteingabe nur an
Wortgrenzen.

Das wird noch lustig.

[Bastelbruder]

Und wenn das Bandwurmwort länger als 80 Zeichen ist, stürzt die Kiste ab und endet in einer Dauerbootloop?

[Fritzler]

DANN wird natürlich auch hart umgebrochen.
Bei länger als 160 Zeichen allerdings

Zum Anzeigen von Emails hab ich das ja schon eingebaut, das guckt obs innerhalb der letzten 80 Zeichen ein Leerzeichen findet und bricht dann dort um.
Wenn nicht, dann gibts einen harten Umbruch.

[Gernstel]

Also ich bin ja schon verblüfft, dass Du offenbar "echte" Mails von einem echten Mailserver abrufen kannst. Hast Du etwa auch die Verschlüsselung implementieren können? Ich finde ja schon die Abwicklung einer Authetifizierung aufregend genug.

[Fritzler]

Bisher ist es unverschlüsselt, aber ich kenn mich mit mbedTLS ein wenig aus.
Nur bei der TLS Schlüsselaushandlung mit 4096Bit RSA kannste bei einem 100MHz ARM schon zugucken.
Bei der 4MHz Kiste (welche auchnoch Multicycle ist, also eher knapp unter 1MHz real hat) wird das dann richtig lange dauern
Genug Speicher wäre aber da und mbedTLS kann auch über lwip quasseln.

POP3 und SMTP auth ist garnicht schwer.
Bei POP3 wirds einfach Klartext zum Server geschickt und dann wars das.
Bei SMTP wirds base64 verpackt, aber sonst auch Klartext.
Da ich meinen eigenen Mailserver habe kann ich da wenigstens ein VPN Tunnel drüberstülpen.
Auf der VCFB wird sich dann eh nur mit einem temporären Testaccount verbinden, damit Besucher emails senden/empfangen können.

Was natürlich nicht geht sind html only emails

Diese Lektüre reicht aus für POP3, mehr als Text übern Socket schieben ist es nicht:
https://de.wikipedia.org/wiki/Post_Office_Protocol

IMAP wird dann aber schon anspruchsvoller.

[Landjunge]

Würde man auf dem TTL Rechner einen distributed.net Client zum laufen bekommen bzw. dafür kompilieren können? http://www.distributed.net/Main_Page unter Downloads gibt es den Quellcode

[Fritzler]

Deren CVS ist nicht mehr erreichbar, daher kann ich nichtmal Sourcecode sehen.

[Fritzler]

Henry hat die Lankarte fertig layoutet:


6 Lagen sins geworden, weil da so viele interne Bussysteme durch die Gegend kriechen.

[Fritzler]

Die Platine ist da und schonmal besockelt.
Beim PHY und den FIFOs wurde mal von DIL abgewichen und es gibt Aufsteckplatinchen.

[Herrmann]

Ich muss mal grade meine Kinnlade vom Boden aufsammeln... 6 Lagen

[Fritzler]

Ja, zu viele Busse Kreuz und Quer.
Leider auch nicht wirklich aufdröselbar wegen der Hardware CRC Schleife.
Vor allem ist die an vielen Stellen noch gemultiplext für andere Betriebsarten oder einfach nur um per Speicherbus auslesbar zu sein.

[zauberkopf]

Mal ne Frage : Habt ihr eigentlich auch mal mit "Asynchronen CPU´s" mal zumindest theoretisch gespielt ?
Ich habe leider auch nur die Synchronen "gelehrt" bekommen, und empfinde das prinzip daher erst mal ein wenig "Brainfuck".
Aber durchaus interessant..

[Fritzler]

Habt ihr eigentlich auch mal mit "Asynchronen CPU´s" mal zumindest theoretisch gespielt ?

Gespielt nicht, aber angesehen.
Henry hatte dann auch maln Schaltplan an die Wand geworfen aus einem uralt Tischrechner.
Den hat keiner Verstanden, auch Henry nicht -> machenwa nich sowas.

Der MIPS ist es ja geworden, weil die Befehlsdekodierung schön einfach ist.
Es gibt "das Buch" zum MIPS vom Mitbegründer des MIPS selbst (Hennessy).
Der Patterson hat da auch mitgeschrieben (RAID, SPARC, Berkeley-RISC, RISC-V).
(RISC-V gabs damals noch nicht, aber das wäre echt DER KNALLER gewesen den in TTL Gattern gebaut zu haben bevors echte Chips gibt )
Nicht zu vergessen, dass es dazu schon nen Compiler gibt mit Debugger und allem drum und drann.

Dass wir momentan die Einzigen sind mit einem privaten funktionierenden 32Bit TTL Rechner ist da nur das i-Tüpfelchen

[zauberkopf]

Den hat keiner Verstanden, auch Henry nicht -> machenwa nich sowas.

Schade... Weil die Dinger scheinen echt vorteile im Betrieb zu haben.. energieeffizieter..
Oder : Das Ding brennt ohne Kühlkörper nicht durch.. läuft aber mit deutlich schneller !
Ich könnte mir auch vorstellen, das man so ne CPU direkt an ein Solarpanel betreiben kann, ohne MPPT regler..

[nero]

Ich packs mal hier rein:
Fast direkte Synthese von excelsheet zu 7400 ics.
Bzw auch aus sinnvoller hw Beschreibung zu 7400

https://media.ccc.de/v/rc3-11384-unconv ... xperiments

Irgendwie bekomme ich richtig Lust das noch auf auf mosfet runter zu brechen und einzeltransistor CPUs ausspucken zu lassen.

[Fritzler]

Aus irgendwelchen Gründen sehe ich da kein Bild, aber höre Ton.
Also mal warten bisses auf YT hochgeladen ist.

Irgendwie bekomme ich richtig Lust das noch auf auf mosfet runter zu brechen und einzeltransistor CPUs ausspucken zu lassen.

Andere haben schon gebaut:
http://www.megaprocessor.com/

Wobei der MIPS TTL auch eine "Excelsynthese" hat.
Der Mikrocode ist zwar handgeklöppelt, aber das sollte mit Kommentaren, farblichen Markierungen und Bitbeschreibungen möglich sein.
Sonst blickt da am Ende keine Sau mehr durch wieso welches Bit gesetzt ist.
Ein programm ließt diese Tabelle ein und spuckt die passenden ROM Images aus oder spielt diese direkt per Debuginterface aufs Endgerät.