Bevor wir ein anderes Zahlensystem eingeführt wird, was nur für Computer relevant ist, sollte erstmal auf der ganzen Welt das metrische System eingeführt werden.
Frank schrieb: > Josef G. schrieb: >> Man stelle >> sich vor, welche Aufbruchstimmung ein solches Vorhaben erzeugen >> würde. > > Mann stelle sich vor, welche Panik ein solches Vorhaben in der > Bevölkerung erzeugen würde. Schon allein weil 99% der Bevölkerung gar > nicht verstehen würden, wozu sie da gezwungen werden sollen. Und alle Lehrbücher müssten neu aufgelegt werden! Rechtschreibreform war dagegen Kindergeburtstag! Sicherlich gut als Konjunkturbelebungs-Post-Corona-Projekt. Zusammen mit KI-Ethik-Regulierung. Fußball gucken macht jetzt ja auch kein Spaß mehr, da hat man wieder mehr Zeit :-)
Frank schrieb: > Schon allein weil 99% der Bevölkerung gar nicht verstehen würden, > wozu sie da gezwungen werden sollen. Das Hexsystem lernen doch heute die meisten Schüler im Unterricht. Und allgemein herrscht doch eine positive Einstellung zu Computern, da würde die Einführung des Hexsystems nicht als Zwang empfunden.
Michael W. schrieb: > Und alle Lehrbücher müssten neu aufgelegt werden! Ein vergleichsweise kleines Problem. Den größten Aufwand sehe ich im Maschinenbau bei der Umstellung der Maße.
Josef G. schrieb: > Ein vergleichsweise kleines Problem. Den größten Aufwand > sehe ich im Maschinenbau bei der Umstellung der Maße. Meiner Meinung müssen solche Spinner wie Du die Freiheit haben, auch solch einen völligen Blödsinn zu propagieren. Wenn eine Gesellschaft oder ein Staat jedoch nicht völlig verdummt ist und auch nur ein wenig auf sich achtet, so wird er diesem Blödsinn nicht folgen. Und das ist gut so. Dein Problem ist, dass Du das nicht verstehst.
Josef G. schrieb: > Und allgemein herrscht doch eine positive Einstellung zu Computern Nein. Es herrscht eine positive Einstellung zum Daddeln und zu "Geräten". Aber von Computern im Sinne von Computern verstehen die meisten Leute kaum etwas.
Josef G. schrieb: > Man stelle sich vor, welche Aufbruchstimmung ein solches > Vorhaben erzeugen würde. Ähem, so gut wie keine. > Schon allein das könnte den Umstellungsaufwand aufwiegen. Nein.
Josef G. schrieb: > Den größten Aufwand sehe ich im Maschinenbau bei der Umstellung der > Maße. Nicht nur im Maschinenbau, sondern in der gesamten Physik und damit in allen Naturwissenschaften und überall in der Technik. So müssten bspw. sämtliche SI-Vorsätze (Mikro, Milli, Kilo, Mega usw.), die ja für Tausenderpotenzen stehen, abgeschafft und durch neue ersetzt werden, bspw. durch Potenzen von 256. Die Einheiten km, mA, MΩ und kJ würden durch (nach heutigem Verständnis) "krumme" Einheiten ersetzt werden. Wie lange so eine Umgewöhnung dauern kann, sieht man am PS, das in Deutschland seit 1978 keine gesetzliche Einheit mehr ist (im Osten sogar schon seit 1970 und in der Schweiz seit 1950). Trotzdem wird im normalen Sprachgebrauch die Leistung von Automotoren immer noch in PS statt in kW angegeben. Vielleicht haben sich ja in 20 Jahren alle an das kW gewöhnt. Aber dann kommst du und willst auch das kW verbieten. Sogar eine der sieben SI-Basiseinheiten, nämlich das Kilogramm, müsste abgeschafft oder zumindest umbenannt werden. Bei Wahlen, Steuersätzen und Preisnachlässen müsste die Angaben statt in Prozent in "Pro256" erfolgen. Potentielle Alkoholsünder hätten es noch schwerer, unter dem Limit zu bleiben, das dann nicht mehr in Promille, sondern in "Pro4096" angegeben wird. Falls du beabsichtigen solltest, eine neue Partei namens "Sedimalpartei Deutschlands" oder "Partei deutscher Sedimalisten) (SPD bzw. PDS ;-)) zu gründen, hoffe ich im Sinne maximaler Transparenz für die Wähler, dass das Wahlergebnis dieser Partei eine Zahl sein wird, die in allen Zahlensystemen gleich aussieht :) Oben habe ich MΩ als Beispiel für eine in Zukunft unzulässige Einheit genannt. Wie sieht es eigentlich mit der Farbkodierung von Widerständen und Spulen aus? Für die Kodierung im Hexadezimalsystem müssten ja sechs neue Farben hinzukommen. Ich habe manchmal jetzt schon Schwierigkeiten bei der Unterscheidung einiger Farben (bspw. rot ⟷ orange, orange ⟷ braun und braun ⟷ violett). Wie soll das erst mit 16 Farben werden?
Yalu X. schrieb: > Wie soll das erst mit 16 Farben werden? Vier verschiedene Farben codieren eine Viererziffer. Zwei nahe beieinander liegende Ringe eine Hexziffer.
Yalu X. schrieb: > > Oben habe ich MΩ als Beispiel für eine in Zukunft unzulässige Einheit > genannt. Wie sieht es eigentlich mit der Farbkodierung von Widerständen > und Spulen aus? Für die Kodierung im Hexadezimalsystem müssten ja sechs > neue Farben hinzukommen. Ich habe manchmal jetzt schon Schwierigkeiten > bei der Unterscheidung einiger Farben (bspw. rot ⟷ orange, orange ⟷ > braun und braun ⟷ violett). Wie soll das erst mit 16 Farben werden? Gute Unterscheidbarkeit ist natürlich wichtig: Die neuen Farben sollten in Ihren Wellenlängen nicht zu nahe beieinander liegen. Dies lässt sich einfach erreichen, in dem man die bisherige Beschränkung auf das für Menschen sichtbare Farbspektrum aufhebt, also auch Farben im Bereich des Infrarot und Ultraviolett verwendet.
Josef G. schrieb: > Vier verschiedene Farben codieren eine Viererziffer. > Zwei nahe beieinander liegende Ringe eine Hexziffer. Die heutige E192-Reihe kommt mit 5 Ringen (3 für die Mantisse, 1 für die Zehnerpotenz und 1 für die Toleranz) aus. Möchte man mindestens dieselbe feine Abstufung und denselben Wertebereich gemäß deinem Vorschlag (de facto Viersystem) erreichen, braucht man 8 Ringe (5 für die Mantisse, 2 für die 16er-Potenz und 1 für die Toleranz). Da wird es auf einem 1/8-Watt-Widerstand schon ganz schön eng, und man braucht schon gute Augen, um die Ringe noch voneinander trennen zu können. Philipp Klaus K. schrieb: > also auch Farben im Bereich des Infrarot und Ultraviolett verwendet. Ja, das wäre eine Option :)
Yalu X. schrieb: > Die Einheiten km, mA, MΩ und kJ > würden durch (nach heutigem Verständnis) "krumme" Einheiten ersetzt > werden. Wobei schon bisher gerade in der Elektronikbranche krumme Zahlen an der Tagesordnung sind. Also 4700 Ohm beispielsweise. Und ergibt es dann überhaupt irgendeinen Sinn, am bestehenden 3*2^n System E3,E6,E12,... festzuhalten? Wieso 3?
:
Bearbeitet durch User
Yalu X. schrieb: > Da wird es auf einem 1/8-Watt-Widerstand schon ganz schön eng, Dann verwendet man beim Farbcode halt ausnahmsweise das Oktalsystem. Dann hat man zwei Farben weniger als heute, du hast ja geschrieben, dass zehn verschiedene Farben schwer auseinanderzuhalten sind. Josef G. schrieb: > Vorteil von Oktal ist das nicht so umfangreiche Einmaleins. > Ich könnte mich notfalls auch mit Oktal anfreunden. An meinem > 8bit-Computer würde das nichts ändern, der Hex-Ziffernsatz > bliebe auch dann sinnvoll. In der derzeitigen Implementierung > hat die Tastatur ohnehin nur acht Zifferntasten für 76543210 > mit FEDCBA98 als Shift-Ebene darüber.
:
Bearbeitet durch User
Ich hab die Lösung: Josef IST ein Computer 😀 Daher kann er uns mit viel Liebe und stoischer Ausdauer über Jahre hinweg die Vorteile seiner eigenen Architektur näher bringen. Computer, seid willkommen - auch in diesem Forum!
Menschmaschine schrieb: > Ich hab die Lösung: Josef IST ein Computer 😀 Nach aktuellem Gender-Zeitgeist vielleicht sogar ein TRANSputer! ;-)
Josef G. schrieb: > Dann verwendet man beim Farbcode halt ausnahmsweise das Oktalsystem. Wir könnten uns ja ungefähr in der Mitte treffen und das 10er-System verwenden. So als Kompromiss. Ok?
malsehen schrieb: > NON und NOL habe ich mir schon immer gewünscht! Ein langer NoOp-Befehl ist nützlich zB. für if-else-Strukturen, um den kürzeren Zweig so zu verlängern, dass die Laufzeit für beide Zweige gleich lang wird.
:
Bearbeitet durch User
Kann man in die Core auch die Möglichkeit einabeun dass man anstatt 8Bit gleich 10Bit für Dezimalsystem nimmt? So würden wir 1024 können und diese Kürzen. Kann man dafür ein Registerbefehl einbauen? So würde mit zwei weiteren Bits zusätzlich noch Phase und Flag ein Richtungszeiger darstellen können!
Yalu X. schrieb: > Vielleicht haben sich ja in 20 Jahren alle an das kW gewöhnt. Dabei könnte sich die Elektromobilität als hilfreich erweisen. Leistung in kW und Akkukapazität in kWh passen irgendwie gut zusammen. Glücklicherweise ist noch niemand auf die Idee gekommen, die Akkukapazität in Äquivalenzlitern Benzin anzuzeigen. Josefs Revolution fehlt indes noch das zündende Transportmittel. Also jene technologische Umwälzung, an die man das Hex-System ganz natürlich dranhängen könnte.
Josef G. schrieb: > malsehen schrieb: >> NON und NOL habe ich mir schon immer gewünscht! > > Ein langer NoOp-Befehl ist nützlich zB. für if-else-Strukturen, > um den kürzeren Zweig so zu verlängern, dass die Laufzeit für > beide Zweige gleich lang wird. Und fürs Timing bei der Emulation von Peripherie (UART, I²C, etc) in Software. Das dürfte der Hauptgrund dafür sein, dass viele Padauk µC solche Befehle aufweisen.
(prx) A. K. schrieb: > Josefs Revolution fehlt indes noch das zündende Transportmittel. Also > jene technologische Umwälzung, an die man das Hex-System ganz natürlich > dranhängen könnte. Mengenlehre in der Grundschule.. Ich finde ich diesem Zusammenhang die Hexzahlen recht praktisch und zum Teil auch unterhaltsam, denn man sieht u.a. Zusammenhänge, die einem sonst gar nicht auffallen. Beispielsweise hat MWS weiter oben 0A0D am Ende vergessen. Wirklich brauchen tut man es nicht, die "Kommunikation funktioniert auch so, aber wenn man so ein Hexprogramm in Dos codet, dann macht man das gewissermaßen automatisch. Früher gab es noch das 12er System, das ist eigentlich auch sehr gut. Bei den Uhren und Kalendern sind noch 12er, 7 Tage und 60er Sekunden bzw. Minuten wichtig, und das 60er System ist ganz schön alt. Aber mal im Ernst, ich finde nicht, dass z.B. jeder Kalenderrechnen im Kopf können (o.ä), es macht doch auch mal Spaß, ein stiller Genießer zu sein.
(prx) A. K. schrieb: > fehlt indes noch das zündende Transportmittel. Ein kleiner Hobby-Computer mit einem Zeichensatz, der neben Buchstaben und Sonderzeichen auch einen auf sechzehn Ziffern erweiterten Ziffernsatz enthält ...
Josef G. schrieb: > MaWin schrieb: >> Ah. Ein Raspberry Pi. > > Gerne. Falls er einen entsprechenden Zeichensatz hat. Der große Erfolg des Raspberry Pi ist ja auch ohne Deinen komischen Zeichensatz eingetreten. Also ist das eher ein Gegenbeispiel zu Deiner Idee.
Andreas S. schrieb: > Der große Erfolg des Raspberry Pi ist ja auch > ohne Deinen komischen Zeichensatz eingetreten. Das sagt nichts aus über die Frage, welchen Erfolg ein Computer mit einem solchen Zeichensatz hätte.
Hat hier einer der Mitleser ein DE0 oder ein DE0-CV Board?
:
Bearbeitet durch User
Josef G. schrieb: > Das sagt nichts aus über die Frage, welchen Erfolg > ein Computer mit einem solchen Zeichensatz hätte. Ich kenne zwar nicht im Detail Deine Geschäftszahlen, aber ich schätze, dass doch etwas weniger bo8h gebaut und verkauft wurden als Raspberry Pis.
Andreas S. schrieb: > Ich kenne zwar nicht im Detail Deine Geschäftszahlen, aber ich schätze, > dass doch etwas weniger bo8h gebaut und verkauft wurden als Raspberry > Pis. An der Börse gibt es Leerverkäufe . . . ;-)
Beitrag #6753232 wurde von einem Moderator gelöscht.
Die Software der Hauptplatine ist jetzt auch als Assembler-Quelltext verfügbar. https://www.bo8h.de/Downloads/
Die Labels in den Quelltexten sind automatisch generiert und lauten deshalb alle L.nnnn, wobei nnnn die zugehörige Adresse ist. Das ist für den Assembler aber ohne Belang, man kann sie auch umbenennen oder im Text Zeilen entfernen oder hinzufügen, so dass die Adressen nicht mehr stimmen, der Text wird dennoch korrekt assembliert. Auch die am linken Rand stehenden Adressen stammen vom Disassembler und werden vom Assembler ignoriert. Da jetzt die Quelltexte zur Verfügung stehen und die Software leichter zu bearbeiten ist, habe ich einiges geändert, insbesondere die Kommandos MDAT und EDAT. Diese Kommandos dienen zum manuellen Erzeugen und Bearbeiten von Daten des Typs "local fixed", die an ein Programm angehängt werden können.
Beitrag #6970690 wurde von einem Moderator gelöscht.
Josef G. schrieb: > Die Labels in den Quelltexten sind automatisch generiert und lauten > deshalb alle L.nnnn, wobei nnnn die zugehörige Adresse ist. Das automatische generieren von Labels in Assemblerquelltexten ist eine gute Idee. Vielleicht kann man das ja sogar noch weiter entwickeln? z.B. ist es nervig ständig die gleichen Mnemonics zum Ausführen von Schleifen einzutippen. Das könnte man abkürzen, in dem man einfach nur den Code in der Schleife markiert und den Assembler automatisch die dazu notwendigen Befehle erzeugen lässt. Man könnte die Code z.B. in Klammern einschließen oder Einrücken, um Schleifen zu markieren. Wo wir schon dabei sind: Man könnte den Assembler ja auch die Registerzuweisungen automatisieren lassen? z.B. schreibe ich als Platzhalter "x" und der Assembler weist x einem Register zu.
Josef G. schrieb: > man kann sie auch umbenennen > oder im Text Zeilen entfernen oder hinzufügen, so dass die Adressen > nicht mehr stimmen, der Text wird dennoch korrekt assembliert. Das ist der Sinn eines Assemblers. Das war schon beim guten alten 6502 und noch früher der Fall. Da hast du nix neues erfunden.
Klaus schrieb: > Das ist der Sinn eines Assemblers. Ich hab das nur ausdrücklich hingeschrieben, damit manche Leute, die mir jede Dummheit zutrauen, nicht auf die Idee kommen, dass meine Labels gar keine richtigen Labels sind.
MWS schrieb: > Litzen von Weichen, Schienen, Lampen, Hausbeleuchtungen usw. Sicher > interessant anzuschauen, aber außer für den/die Bauer oder Betreiber des > Ganzen völlig sinnlos, nicht übertragbar auf irgendeine vergleichbare > Anlage, nicht demontier- oder zusammensetzbar. Für den außenstehenden > Betrachter in gewisser Weise faszinierend, auch nett anzuschauen, das > war's dann aber auch schon. Wer keine Ahnung hat, und nur Strippen zusammensteckt bei der Eisenbahn hinterlässt so ein Chaos. ICH hatte JEDEN Magnet-Artikel eine Nr. gegeben. Ich wusste auf den Plan genug wo die war (habs ja hingeschrieben) und die selbe Nr. auf den schönen blauen Schaltpult geschrieben. JEDER Kabel war gebündelt mit Tesafilm und mit einer Nr. versehen. Ich hätte Technisch gesehen, jede Weiche in weniger wie 2 Min sauber entfernt ohne die anderen Kabel auch nur belästigt. Und genau so ist / sollte das auch mit Bastelprojekten sein. Ich stecke z.b. die Leitungen von LCD-Display (160*) in einen (nicht geschrumpften) Schrumpfschlauch wenn ich sie mit Litzen verlege. Habe ich mal 20 Meter für 5 Euro in China besorgt. Das bündelt Kabel sehr sauber. Klar ist das mehr Aufwand. Aber ich weiß genau wie beim Programmieren auch noch nach 30 Jahren was ich da gebaut / programmiert habe. So was nennt man Ordnung.!! Und wenn ich Techniker in der Firma gesehen habe, die Reparaturen durchgeführt haben, weiß ich wie schlampig die Studierten Leute arbeiten. Von Telekom-Techniker rede ich lieber gar nicht. Mein Schreibtisch sieht immer aus wie nach ein Bombeneinschlag. Das liegt daran das mein Kurzzeitgedächtnis sehr gut arbeitet. Aber ich merke mir nicht alles was ich gemacht habe. Also muss da Ordnung rein.
bork schrieb: > > Das automatische generieren von Labels in Assemblerquelltexten ist eine > gute Idee. Vielleicht kann man das ja sogar noch weiter entwickeln? z.B. > ist es nervig ständig die gleichen Mnemonics zum Ausführen von Schleifen > einzutippen. Das könnte man abkürzen, in dem man einfach nur den Code in > der Schleife markiert und den Assembler automatisch die dazu notwendigen > Befehle erzeugen lässt. Man könnte die Code z.B. in Klammern > einschließen oder Einrücken, um Schleifen zu markieren. > > Wo wir schon dabei sind: Man könnte den Assembler ja auch die > Registerzuweisungen automatisieren lassen? z.B. schreibe ich als > Platzhalter "x" und der Assembler weist x einem Register zu. Dann ist es kein Assembler mehr, sondern ein Compiler.
Gibt's eigentlich schon einen Forth-Compiler für die CPU. Das wäre doch mal ein schönes, übersichtliches Projekt.
Philipp Klaus K. schrieb: > Dann ist es kein Assembler mehr, sondern ein Compiler. Ich will aber nicht Python compilieren, sondern assembler programmieren. Warum hält man die Assembler künstlich begrenzt?
bork schrieb: > Das könnte man abkürzen, in dem man einfach nur den Code in > der Schleife markiert und den Assembler automatisch die dazu notwendigen > Befehle erzeugen lässt. Der MACRO - Assembler wurde bereits erfunden. Vor 1980. Vor dem IBM PC. http://bitsavers.trailing-edge.com/pdf/phaseOneSystems/oasis/Macro_Assembler_Reference_Manual_Mar80.pdf Seite 28, unten, da findest du genau "deine Idee" mit der Schleife. Gruss
Angehängte Dateien:
-
oasis.PNG
58 KB
Erich schrieb: > http://bitsavers.trailing-edge.com/pdf/phaseOneSystems/oasis/Macro_Assembler_Reference_Manual_Mar80.pdf > > Seite 28, unten, > da findest du genau "deine Idee" mit der Schleife. Bin begeistert, vor allem auch von dem Manual. Liesst sich wie ein Retro-Scifi. Schönes Logo. >MAKES MICROS RUN LIKE MINS Ja, läuft denn auch der BO8 wie ein Mini oder sind wir in diesem Thread doch noch in den 1970ern?
bork schrieb: > Philipp Klaus K. schrieb: >> Dann ist es kein Assembler mehr, sondern ein Compiler. > > Ich will aber nicht Python compilieren, sondern assembler programmieren. > Warum hält man die Assembler künstlich begrenzt? Weil es wenig Sinn ergibt, einen Compiler zu schreiben, den dann (nicht "künstlich begrenzt[en]") "Assembler" zu nennen, damit Programmierer, die eigentlich in einer Hochsprache programmieren, sich so fühlen können, als seien sie Assemblerprogrammierer. Macros im Assemblercode zu verwenden ist das eine (habe ich auch schon gemacht), aber die von dir vorgeschlagene Registerallokation überschreitet meiner Meinung nach klar die Grenze zum Compiler. Wenn du Python nicht magst: es durchaus noch andere Hochsprachen, insbesondere C.
Habe meine Implementierung von Conway's Game of Life überarbeitet. Bisher stand für die Zeitentwicklung nur die Standard-Regel 23/2 zur Auswahl, jetzt kann man beliebige Regeln vorgeben. Ausserdem steht eine alternative Berechnung der Zahl der Nachbarn zur Wahl, bei der die Kanten-Nachbarn das doppelte Gewicht der Eck-Nachbarn haben. Die Summe kann die Werte 0 bis 12 haben. Das Programm ist jetzt Teil der Basis-Version der Teststeckkarte und steht bereits nach dem Programmieren des FPGA zur Verfügung. Ein Laden vom PC über RS232 ist nicht mehr erforderlich. Ausserdem gibt es jetzt zwei PC-Programme zum Erstellen und Anzeigen des Kopfteils der Software von Steckkarten. Das soll das Erstellen von Karten-Software erleichtern. https://www.bo8h.de/Downloads/
Für den auf der Grundlinie liegenden Bindestrich schlage ich jetzt die Bezeichnung hb vor (hyphen on baseline).
Josef G. schrieb: > Für den auf der Grundlinie liegenden Bindestrich schlage > ich jetzt die Bezeichnung hb vor (hyphen on baseline). Der Vorschlag wurde angenommen. (Stempel)
Josef G. schrieb: > Habe meine Implementierung von Conway's Game of Life überarbeitet. Wann wird es denn eine CPU-Implementierung im GoL auf deiner CPU geben? Das GoL ist ja bekanntermassen ein Turing-Vollständiger zullulärer Automat.
MaWin schrieb: > Warum ist das T zu unverhältnismäßig fett? Bei mir sind die Zeichen 6 Pixel breit, dazu kommen ein Randpixel links und ein Randpixel rechts. Deshalb gibt es keine schmale senkrechte Mittellinie. Probleme gibt es beim 'T' und beim 'I'. Ich meine, beim 'T' kann man mit der 2 Pixel breiten Mittellinie leben. Beim 'I' hab ich schon viel herumprobiert, aber immer noch keine zufriedenstellende Lösung gefunden. Die Gesamtbreite von 8 Pixeln je Zeichen ergab sich dadurch, dass es keinen Hardware-Zeichengenerator gibt, sondern die CPU selber die Pixel ins Video-RAM schreibt.
Ach. Ein I soll das sein. Ich dachte es wäre eine bildliche Darstellung altrömischer Gebäudekunst.
Angehängte Dateien:
-
Zeichen.png
944 Bytes
Sorry, nochmal eine kleine Änderung bei R, X, Y. Bei X, Y ist es eine Rückkehr zur vorherigen Version.
Josef G. schrieb: > Bei mir sind die Zeichen 6 Pixel breit, dazu kommen ein Randpixel > links und ein Randpixel rechts. Warum machst du die Zeichen nicht einfach 7 Pixel breit (plus ein Randpixel rechts)? Das linke Randpixel brauchst du nicht, der Zwischenraum kommt ja vom Zeichen zur Linken. Die meisten Fonts auf vergleichbaren Systemen arbeiten so. Das würde viele spiegelsymmetrische Zeichen (z.B. " ' ! w m) vereinfachen und einige seltsam dicke Linien (z.B. y Y T $ | +) vermeiden. Dein I ist seltsam und das G sieht eher wie eine missratene 6 aus. Den "auf der Grundlinie liegenden Bindestrich" kenne ich unter dem Namen "Unterstrich", aber dafür etwas breiter. Im Gegensatz zum hb ist der auch universeller einsetzbar. Dein jetziger Font wirkt unregelmäßig. Für OCD ungeeignet.
S. R. schrieb: > Die meisten Fonts auf vergleichbaren Systemen arbeiten so. Solche Fonts sehen ja auch durchaus akzeptabel aus. Josef wählt aber schon aus Prinzip und sehr zielsicher immer die schlechtesten Lösungen aus und hält sich dann für besonders progressiv.
Angehängte Dateien:
-
bind.png
448 Bytes
S. R. schrieb: > Das linke Randpixel brauchst du nicht Doch. Am linken Bildschirmrand, und rechts neben einer Grafik. > Dein I ist seltsam Zugegeben. Im Bild die vorherige Version. Wäre vielleicht besser. > Den "auf der Grundlinie liegenden Bindestrich" > kenne ich unter dem Namen "Unterstrich" Ist was anderes. Siehe Bild. Den Unterstrich als Bindestrich zu verwenden finde ich hässlich. Im Bild ausserdem eine angedachte Version der Ziffer C.
Josef G. schrieb: > Im Bild ausserdem eine angedachte Version der Ziffer C. Sorry, aber entweder sind das Pixelfehler oder Absicht. Bei Absicht sieht es einfach scheiße aus...
Josef es wäre gut wenn du dich mal mit Typografie beschäftigst oder mal einen gelernten Grafiker kontaktierst. Der kann dir dann mal eine Einführung in Grundlagen geben, darauf kannst du dann aufbauen
Wie gesagt, ein Typograf hat das gelernt und nicht ohne Grund. Es gehört einfach einiges an Wissen dazu. Wenn du es nur für dich fürs stille Kämmerchen machst ists ok, wenn du aber mehr Leute erreichen willst, muss man auch dafür was können. So ist das einfach nur Murks was du da ablieferst und offenbar merkst du es selbst nicht.
Du magst technisch einiges drauf haben. Mache dort weiter und verschwende deine Zeit nicht mit diesem grafischen Kram. Das ist leider nur lächerlich. Du kannst besseres
Josef G. schrieb: >> Das linke Randpixel brauchst du nicht > Doch. Am linken Bildschirmrand, und rechts neben einer Grafik. Ein analoges Bildschirmsystem hat am linken Bildschirmrand keine Pixel (weil da die Elektronenkanone nicht hinschießt, Stichwort "Overscan") und für deinen Emulator kannst du mit Software einen Rand zaubern. Moderne Computer haben auch kein Problem damit, den linken Bildschirmrand zu benutzen. Um ein Pixel pro Zeile besser aussehen zu lassen, lässt du über 600 Pixel pro Zeile (deinen Font) schlechter aussehen. Klingt für mich nach einem faulen Kompromiss. Dein Gesamtbild sollte als Ganzes akzeptabel aussehen, also optimiere für den Durchschnitt. >> Dein I ist seltsam > Zugegeben. Im Bild die vorherige Version. Wäre vielleicht besser. Nee, die sehen beide doof aus. >> Den "auf der Grundlinie liegenden Bindestrich" >> kenne ich unter dem Namen "Unterstrich" > Ist was anderes. Siehe Bild. Den Unterstrich als > Bindestrich zu verwenden finde ich hässlich. Stimmt. Der Unterstrich ist tatsächlich kein Bindestrich. Aber den Bindestrich auf die Grundlinie zu verlegen ist auch nicht besonders sinnvoll. Josef G. schrieb: > Wie wär's damit? Auch nicht besser. Dafür extra unruhig.
Tom schrieb: > So ist das einfach nur Murks was du da ablieferst und offenbar merkst du > es selbst nicht. Hehe. Das ist bei Josef gewissermaßen ein Problem der ersten Stunde. Er hat es noch nie gemerkt.
Angehängte Dateien:
-
Zeichen.png
914 Bytes
Die aktuelle Version. So werd ich's wohl lassen. S. R. schrieb: > Aber den Bindestrich auf die Grundlinie zu verlegen > ist auch nicht besonders sinnvoll. Tatsache ist, dass der Unterstrich oft als Bindestrich verwendet wird. Ich finde das hässlich. Mein hb ist eine Alternative. Und das Minus gibt es ja weiterhin.
Josef G. schrieb: > Tatsache ist, dass der Unterstrich oft als Bindestrich > verwendet wird. Ich finde das hässlich. Zum Verständnis: Dein Font würde einen Bindestrich als Unterstrich rendern? Das ist gefährlich... Da verzerrt dein Font den Sinn des Inhaltes!
Angehängte Dateien:
-
bind.png
452 Bytes
Andre schrieb: > Dein Font würde einen Bindestrich als Unterstrich rendern? Wie meinst du das? Mein hb ist das Zeichen 0x40 des Zeichensatzes, also das Zeichen vor dem $. Der Unterstrich ist im Gegensatz dazu das unterstrichene Leerzeichen. Der liegt tiefer und ist breiter.
Josef G. schrieb: > Tatsache ist, dass der Unterstrich oft als Bindestrich > verwendet wird. Ich finde das hässlich. Dann verwende doch einfach einen Bindestrich als Bindestrich.
Yalu X. schrieb: > Dann verwende doch einfach einen Bindestrich als Bindestrich. Warum verwenden so viele Leute den Unterstrich als Bindestrich? Doch offensichtlich, weil machmal das Minus nicht gut passt.
Hallo, Josef G. schrieb: > Warum verwenden so viele Leute den Unterstrich als Bindestrich? Zeig mal ein Beispiel. rhf
Ich finde das ja nett das Josef alle Anwender des Systems hier über die Änderungen informiert, aber dazu hätte es auch gereicht sich eine Notiz an den Monitor zu kleben. Wer hier neu ist und sich wirklich noch fragen sollte warum die bo8 trotz des neuen Zeichensatzes wohl weiterhin bei Anwenderzahl=1 verbleiben wird, dem kann ich nur wärmstens www.bo8h.de empfehlen. Nicht verzagen, neben Auslassungen zur Gendersprache und weiteren eher wahllos herausgegriffenen Themen, gibt es durchaus was zum bo8 System. Wenn vorhanden auf SW Monitor ansehen, den Augen zuliebe. Wir erfahren für welche FPGA Boards es als Konfiguration vorhanden ist (bedeutet 'vorhanden' oder 'dokumentiert und getestet'?) und das die bo8 auf Einfachheit getrimmt wurde, was sich scheinbar ausschliesslich darin zeigt das sie keine IRQs kennt. Ende. Also ab zur Download Sektion und sich den Klumpatsch mal ansehen. Auf der Seitenzahl die ein normaler MCU Hersteller braucht um klar gegliedert nur die Features seiner MCU zu beschreiben, finden wir ascii plain text, in der CPU, Sytem und alles andere 'beschrieben' werden. Also Microchip braucht dazu ein 70S DB und 600S Family Referenz + dutzendweise flankierende Informationen und Appnotes alleine für die MCU. Mir fallen für Inhalt und Darstellung eine Menge Wort ein. Übersichtlich, strukturiert, selbsterklärend, ausführlich, sind alle nicht auf dieser Liste. Also mal in die TXT Files sehen, denn irgendwo muss doch stehen wie ich aus aus nichts und einem Zip File, zu einem System komme. Ja, in einigen TXT Files steht wirklich text und nicht nur hex codes. Mag sein das man die alle durchlesen muss bis da irgendwann mal die Infos kommen die es brauchen würde. Aber huch, da ist C-Code, also mal wahllos reinschauen:
1 | printf("\n\n ACHTUNG - wenn Grafikfenster offen dann nicht klicken"); |
2 | printf("\n\n Gefahr von FATAL ERROR // Grafik beenden mit ESCAPE"); |
Ich denke sowas nennt man dann gleichbleibende Qualität? Der große Vorteil der bo8 ist das sie keinerlei Vorkenntnisse verlangt. Da ohnehin alles anders gemacht wurde als jeder andere es tut, würden die eh nichts nützen und selbst wenn, kann man trotz jeder menge Vorkenntnisse das System trotzdem nicht bauen. Scheinbar nicht mal Josef, denn wer sich bei 'Bildern' ein real aufgebautes FPGA Board erhofft, weil er nicht ganz versteht in welcher Art ein und Ausgaben erfolgen, erlebt auch hier eine Enttäuschung dieser völlig unbegründeten Erwartung an eine Dokumentation und Website, die seit so vielen Jahren existiert und deren einziger Entwickler und Anwender seit langer Zeit seine vordringlichste Aufgabe ich absoluten marginalien sieht, die im besten Fall sin nlos sind im schlechtetsten Fall bestehende Projekte nutzlos machen würden. Das es die Erweiterungskarten nicht gibt, weil es keine Steckplätze gibt, weil die auf einer Hauptplatine sitzen würden, die es nicht gibt und es nicht mal das Blockschaltbid einer Hauptplatine gibt, geschweigedenn Schematic + PCB, erschliesst sich dem aufmerksamen Leser ja noch zwischen den Zeilen und den Dingen die eben NICHT da sind. Meine Frage ans Forum: Gibt es hier wenigstens EINE Person die jemals den Kram auf realer FPGA HW zum laufen bekommen hat und bestätigen kann das dieses System mehr ist als der aufwändigste Trollthread ever? Ich schlage eine Challenge vor: Die virtuelle MC-Net Medaille 'Härtester unter der Sonne' geht an den der es zuerst schafft aus den allgemein verfügbaren Informationen ein System zu bauen und ein Hello World Programm zu schreiben. Josef darf allerdings nicht teilnehmen. Die Prioritäten an diesem Projekt sehe ich nicht so sehr in wiederholten homöopatischen Änderungen am Zeichensatz, bei dem für alle ausser Josef unsichtbar irgendwo ein pixel dazugekommen ist oder verschwand. Klar, die dienen ja nur als Aufhänger den Thread oben zu halten, weil die zahllosen Anwender des Systems scheinbar völlig ohne Rückfragen mit der umfangreichen Doku zurechtkommen oder sich über Flaschenpost und Dosentelefon unterhalten, denn ich habe auch keine andere bo8 Usergroup finden können. Meine Prio Liste hätte nur zwei Punkte: 1. rm -rf * 2. start from scratch
Roland F. schrieb: > Josef G. schrieb: >> Warum verwenden so viele Leute den Unterstrich als Bindestrich? > > Zeig mal ein Beispiel. Beitrag "Re: 8bit-Computing mit FPGA"
Max M. schrieb: > Gibt es hier wenigstens EINE Person die jemals den Kram auf realer FPGA > HW zum laufen bekommen hat und bestätigen kann das dieses System mehr > ist als der aufwändigste Trollthread ever? Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA"
:
Bearbeitet durch User
Angehängte Dateien:
-
leerzeichen.png
276 Bytes
Josef G. schrieb: > Roland F. schrieb: >> Josef G. schrieb: >>> Warum verwenden so viele Leute den Unterstrich als Bindestrich? >> >> Zeig mal ein Beispiel. > > Beitrag "Re: 8bit-Computing mit FPGA" Viele Programmiersprachen erlauben keine Bindestriche und Leerzeichen in Identifiern, also wird als Ersatz oft der Unterstrich genommen. Das betrifft aber vor allem (wie auch in dem von dir verlinkten Beispiel) die Leerzeichen, da Bindestriche auch in natürlichen Sprachen eher selten auftreten. Viel wichtiger als der von dir erfundene alternative Bindestrich wäre deswegen ein alternatives Leerzeichen. Der angehängte Screenshot enthält links das klassische und rechts meinen Vorschlag für das alternative Leerzeichen, das auch in Identifiern verwendet werden kann. Um die beiden leicht voneinander unterscheiden zu können, steht das alternative Leerzeichen auf dem Kopf ;-) Da dein bo8h sowieso nur in der von dir entwickelten Assemblersprache programmiert werden kann, könntest du deren Syntax so abändern, dass auch ganz normale Bindestriche und Leerzeichen erlaubt sind.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Viel wichtiger als der von dir erfundene alternative > Bindestrich wäre deswegen ein alternatives Leerzeichen. Vielleicht hätte ich meinen alternativen Bindestrich einfach alternatives Leerzeichen nennen sollen. Er ist genau das.
:
Bearbeitet durch User
Max M. schrieb: > und das die bo8 auf Einfachheit getrimmt wurde, was sich > scheinbar ausschliesslich darin zeigt das sie keine IRQs kennt. Keine Flags ausser Carry, nur 1 Adressierungsart zum Speicher, nur 1- und 2-Byte-Befehle, nur 1 oder 2 Zyklen je Befehl.
Max M. schrieb: > wiederholten homöopatischen Änderungen am Zeichensatz Zugegeben. Aber einen halbwegs akzeptabel aussehenden 6x9-Pixelfont scheint es sonst nicht zu geben. Da hat es halt etwas gedauert. Ich hoffe sehr, dass mir keine weitere Änderung mehr einfällt.
Hallo, Josef G. schrieb: > Beitrag "Re: 8bit-Computing mit FPGA" Die dort gezeigten "Bindestriche" sind keine Bindestriche, sondern Platzhalter für Leerzeichen. Solltest du eigentlich wissen. rhf
Max M. schrieb: > Also mal in die TXT Files sehen, denn irgendwo muss doch stehen > wie ich aus aus nichts und einem Zip File, zu einem System komme. Steht auf der Seite Hardware im Verzeichnis info. Fotos hier im Thread: Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA" Das Emulationsprogramm mit der abschreckenden Warnung, die du zitiert hast, braucht man nicht, wenn man das System auf einem der FPGA-Boads realisieren will. Die Warnung betrifft nur dieses eine C-Programm, alle anderen C-Programme für Linux-PC sind unproblematisch.
Yalu X. schrieb: > Viele Programmiersprachen erlauben keine Bindestriche und Leerzeichen in > Identifiern, also wird als Ersatz oft der Unterstrich genommen. Die im Vergleich zu bo8 um ein Vielfaches verbreitetere Programmiersprache Whitespace benötigt nicht einmal einen Unterstrich. > Das > betrifft aber vor allem (wie auch in dem von dir verlinkten Beispiel) > die Leerzeichen, da Bindestriche auch in natürlichen Sprachen eher > selten auftreten. Viel wichtiger als der von dir erfundene alternative > Bindestrich wäre deswegen ein alternatives Leerzeichen. Einer der Kritikpunkte bei klassischem Whitespace besteht ja in der ternären Zeichenkodierung. Mit zusätzlichen Leerzeichenarten könnte man also einen neuen, wesentlich komfortableren Whitespace-Dialekt schaffen. Das könnte letztendlich den Durchbruch sowohl für Whitespace als auch bo8 bringen. > Der angehängte Screenshot enthält links das klassische und rechts meinen > Vorschlag für das alternative Leerzeichen, das auch in Identifiern > verwendet werden kann. Um die beiden leicht voneinander unterscheiden zu > können, steht das alternative Leerzeichen auf dem Kopf ;-) Bei quadratischen Fonts ließen sich auf diese Art und Weise sogar vier verschiedene Leerzeichen darstellen. > Da dein bo8h sowieso nur in der von dir entwickelten Assemblersprache > programmiert werden kann, könntest du deren Syntax so abändern, dass > auch ganz normale Bindestriche und Leerzeichen erlaubt sind. Auch in klassischem Whitespace gibt es einen Assembler-Dialekt. https://de.wikipedia.org/wiki/Whitespace_(Programmiersprache)
Andreas S. schrieb: >> Das >> betrifft aber vor allem (wie auch in dem von dir verlinkten Beispiel) >> die Leerzeichen, da Bindestriche auch in natürlichen Sprachen eher >> selten auftreten. Viel wichtiger als der von dir erfundene alternative >> Bindestrich wäre deswegen ein alternatives Leerzeichen. > > Einer der Kritikpunkte bei klassischem Whitespace besteht ja in der > ternären Zeichenkodierung. Mit zusätzlichen Leerzeichenarten könnte man > also einen neuen, wesentlich komfortableren Whitespace-Dialekt schaffen. > Das könnte letztendlich den Durchbruch sowohl für Whitespace als auch > bo8 bringen. > >> Der angehängte Screenshot enthält links das klassische und rechts meinen >> Vorschlag für das alternative Leerzeichen, das auch in Identifiern >> verwendet werden kann. Um die beiden leicht voneinander unterscheiden zu >> können, steht das alternative Leerzeichen auf dem Kopf ;-) ich verstehe die Beschränkung auf einen 8-Bit-Zeichensatz nicht. Auch auf 8-Bit-Rechnern kann man UTF-8 verwenden. In Unicode finde ich auf Anhieb 17 Leerzeichen und zwei Tabulatorzeichen.
Philipp Klaus K. schrieb: > Auch auf 8-Bit-Rechnern kann man UTF-8 verwenden. Warum gibt es im Unicode noch immer keinen Satz von 16 Ziffern in einem zusammenhängenden Code-Bereich?
Josef G. schrieb: > Warum gibt es im Unicode noch immer keinen Satz von > 16 Ziffern in einem zusammenhängenden Code-Bereich? Es gibt auch keinen zusammenhängenden Bereich, der alle Buchstaben einschließlich der Umlaute enthält. Trotzdem kann ich auf meinem PC deutsche Texte schreiben. Ebenso kann der PC 0x5a als 90 interpretieren. Wie er das trotz des von dir festgestellten Mangels im Unicode zustande bringt, ist mir ein Rätsel (da scheint irgendeine höhere Macht dahinter zu stecken). Aber Hauptsache, er macht es richtig.
Yalu X. schrieb: > Ebenso kann der PC 0x5a als 90 interpretieren. Es ist umständlich wegen der Lücke zwischen 9 und a. Und weil a auch als Buchstabe interpretiert werden kann.
Josef G. schrieb: > Warum gibt es im Unicode noch immer keinen Satz von > 16 Ziffern in einem zusammenhängenden Code-Bereich? Weil kaum jemand außer Dir einen Bedarf dafür sieht.
Hallo Josef, bitte mach mal einen Screenshot! Bin sehr daran interessiert!
Aszur schrieb: > bitte mach mal einen Screenshot! Von was? Meinen Zeichensatz findest du hier: Beitrag "Re: 8bit-Computing mit FPGA"
:
Bearbeitet durch User
Josef G. schrieb: > Yalu X. schrieb: >> Ebenso kann der PC 0x5a als 90 interpretieren. > > Es ist umständlich wegen der Lücke zwischen 9 und a. Mag sein, aber mein PC hat sich deswegen noch nie beschwert. Ganz im Gegenteil: So schnell, wie bei der Eingabe von 0x5a der Dezimalwert 90 herausgeschossen kommt, scheint ihm die Umwandlung richtig Freude zu machen. > Und weil a auch als Buchstabe interpretiert werden kann. Deswegen stelle ich der Hexzahl den Präfix 0x voran, damit weiß mein PC genau, was ich damit meine. Ich könnte stattdessen für die Hexziffern von A bis F – wie von dir vorgeschlagen – auch kleinere Buchstaben nehmen, also so:
1 | 0123456789ᴀʙᴄᴅᴇꜰ |
Aber das scheint mein PC überhaupt nicht zu mögen:
1 | 5ᴀ -> invalid decimal literal |
2 | 0x5ᴀ -> invalid hexadecimal literal |
Deswegen lassen wir das doch am besten wie es ist, und mein PC und ich sind beide glücklich :)
Yalu X. schrieb: > wie von dir vorgeschlagen Nein. Bei mir sind 0..9 und xA..xF gleich hoch.
:
Bearbeitet durch User
Josef G. schrieb: > Und allgemein herrscht doch eine positive Einstellung zu Computern Haha. Nein. Es herrscht eine allgemeine positive Einstellung zum Herumdaddeln. Computer sind nach wie vor Nerdkram.
Josef G. schrieb: > Nein. Bei mir sind 0..9 und xA..xF gleich hoch. Ja, aber nur deshalb, weil die Ziffern sinnloserweise zu klein geraten sind und nicht wie in fast allen gewöhnlichen Fonts die Höhe von Großbuchstaben haben. Korrektes Fazit: Du nutzt kleinere Großbuchstaben als Ziffern. Senkrechte Striche in Zeichen mal ein und mal zwei Pixel breit zu machen sieht übrigens furchtbar aus!
:
Bearbeitet durch User
Thorsten S. schrieb: > weil die Ziffern sinnloserweise zu klein geraten sind Ist nicht sinnlos, sondern macht es möglich, die Ziffern auch mit Überstrich zu schreiben. Das kann man nutzen, um längere Ziffernfolgen optisch zu strukturieren, so dass das Einfügen von Punkten oder Kommas nicht mehr nötig ist. Aber ich gebe zu, besser sähe es aus, wenn die Ziffern ebenso hoch wie Großbuchstaben wären. Vielleicht findet ja mal jemand eine bessere Lösung. > Senkrechte Striche in Zeichen mal ein und mal zwei Pixel > breit zu machen sieht übrigens furchtbar aus! Zugegeben, schön ist es nicht. Wie oben schon geschrieben: Bei mir gibt es keinen Hardware-Zeichengenerator, sondern die CPU schreibt selber die Pixel ins Video-RAM. Deshalb sind die Zeichen 8 Pixel breit, inclusive ein Randpixel links und ein Randpixel rechts. Es gibt deshalb keine schmale senkrechte Mittellinie. Unter diesen Vorgaben ist die gefundene Lösung halt ein Kompromiss. S. R. schrieb: > Warum machst du die Zeichen nicht einfach 7 Pixel breit (plus > ein Randpixel rechts)? Das linke Randpixel brauchst du nicht, > der Zwischenraum kommt ja vom Zeichen zur Linken. Die meisten > Fonts auf vergleichbaren Systemen arbeiten so. Ich hab mal irgendwo eine Darstellung gesehen, wo Zeichen rechts neben einer Grafik direkt am Grafik-Rahmen klebten. Damals hab ich mir geschworen, wenn ich mal selber einen Font gestalte, dann werden die Zeichen einen linken Rand und einen rechten Rand haben.
Josef G. schrieb: > Ist nicht sinnlos, sondern macht es möglich, die Ziffern auch > mit Überstrich zu schreiben. Als sich vor einer sehr, sehr, sehr langen Zeit die Menschheit aufmachte sich auf Zahlensysteme, Zeichensätze und Darstellungen zu einigen, hätten solche Überlegungen vielleicht Sinn gemacht. Aber ausser Dir sieht niemand der anderen 8 Milliarden Menschen ein Problem darin, Kommas und Punkte zu verwenden statt erst global neue Zeichensätze einführen zu müssen um merkwürdige Strichkunst zu verwenden, die ein einzelner Josef für so erstrebenswert hält. Warum sollte irgendjemand ausser Dir Ziffern mit Überstrich schreiben wollen? Also gegen Dich war Don Quijote ein sehr nüchterner, reflektierter Mensch der sein Handeln den bereits getroffenen Mehrheitsentscheidungen untergeordnet hat, jederzeit einer sachlichen Diskussion zugeneigt war und sich auch überzeugen ließ von sinnlosem Tun abzulassen. MC.net ist Deine Rocinante und von Zeit zu Zeit findet sich sogar ein Sancho 😂😂😂 Dieser Thread dient doch nur dem Zeitvertreib und der Belustigung aller. Man lacht sich kringelig über Dich und triggert Dich immer wieder mit irgendeienm Mist, auf den Du Dich dann dienstbeflissen stürzt. Aber nichts von dem was irgendjemand hier sagt wird jemals bis an Dich herandringen. Also, wohlan bome. Vorwärts immer, rückwärts nimmer!👍
Josef G. schrieb: > Tatsache ist, dass der Unterstrich oft als Bindestrich > verwendet wird. Ich finde das hässlich. Mein hb ist > eine Alternative. Und das Minus gibt es ja weiterhin. Ich würde einwerfen, dass ich den Unterstrich noch nie bewusst als Ersatz für einen Bindestrich wahrgenommen habe. Als Ersatz für (verbotene) Leerzeichen hingegen schon. Ob der Unterstrich nun ein oder zwei Pixel höher steht, ändert an der Hässlichkeit der Unterstriche auch nichts. Als Alternative gibt es CamelCase, was aber wieder andere Probleme hat. Sind halt alles Kompromisse. Josef G. schrieb: > Aber einen halbwegs akzeptabel aussehenden 6x9-Pixelfont > scheint es sonst nicht zu geben. Stimmt. Das liegt aber in erster Linie daran, dass sowohl ein 5x7-Pixelfont als auch ein 7x9-Pixelfont ein wesentlich ruhigeres, in sich stimmiges Bild ergeben. Dein Font ist schlicht unruhig. Josef G. schrieb: > Ich hab mal irgendwo eine Darstellung gesehen, wo Zeichen rechts > neben einer Grafik direkt am Grafik-Rahmen klebten. Damals hab ich > mir geschworen, wenn ich mal selber einen Font gestalte, dann werden > die Zeichen einen linken Rand und einen rechten Rand haben. Naja, wenn da offiziell schon kein Sinn hinter steht, dann kritisiere ich das mal nicht weiter. Ich würde dir empfehlen, mal einen 5x7-Font zu nehmen, der links einen und rechts zwei Pixel frei lässt, oder einfach Grafiken nur rechts von einem Leerzeichen zu rendern. Systeme mit echter Grafikunterstützung stellen Grafiken übrigens pixelgenau dar, dann muss der Font da keine Rücksicht drauf nehmen.
Josef G. schrieb: > Ich hab mal irgendwo eine Darstellung gesehen, wo Zeichen rechts > neben einer Grafik direkt am Grafik-Rahmen klebten. Was weniger ein Fehler des Zeichensatzes als vielmehr des Programmierers ist. Josef G. schrieb: > Damals hab ich > mir geschworen, wenn ich mal selber einen Font gestalte, dann werden > die Zeichen einen linken Rand und einen rechten Rand haben. Was die schlechtestmögliche Lösung für das Problem ist. Aber im Finden von schlechten Lösungen für einfache oder gar nicht vorhandene Probleme bist du ja Experte.
Beitrag #6995270 wurde von einem Moderator gelöscht.
Karl schrieb: > Aber im Finden > von schlechten Lösungen für einfache oder gar nicht vorhandene Probleme > bist du ja Experte. Auch diese Fähigkeit muß man erstmal haben. Ich bin sicher es gibt Jobs, wo genau diese Begabung benötigt wird...
MaWin schrieb: > Computer sind nach wie vor Nerdkram. Nö, verwenden tut sie jeder. Aber nicht jeder geht in deren Tiefe. Aber das ist bei Autos nicht anders, Jeder verwendet sie, aber die Wenigsten schrauben am Motor rum.
Und ich möchte mal wissen, wie viele von denen, die hier beim Ablassen von abfälligen Bemerkungen um die Wette eifern, schon selbst eine funktionierende CPU entworfen und gebaut haben.
Sinus T. schrieb: > Und ich möchte mal wissen, wie viele von denen, die hier beim > Ablassen > von abfälligen Bemerkungen um die Wette eifern, schon selbst eine > funktionierende CPU entworfen und gebaut haben. Das Abfälligsein basiert auf dem Umstand, dass dadurch unbewusst die eigenen Defizite kompensiert werden sollen. Ein Mensch mit innerem Frieden und innerer Größe bleibt stets wohlwollend und unterstützend, weil er diese Kompensation nicht benötigt. Aber man sollte sich nicht selbst belügen: Wir alle haben innere Defizite. :-) Allen einen schönen und entspannten Sonntag!
C3PO schrieb: > Ein Mensch mit innerem > Frieden und innerer Größe bleibt stets wohlwollend und unterstützend Gerüchteweise wandern diese Wundertiere zu schnell ins Nirwana ab, weshalb es hienieden so wenige davon gibt. ;-)
Sinus T. schrieb: > abfälligen Bemerkungen Wer diesen Mamutthread bereits seid Jahren verfolgt, weiß auch wie es dazu gekommen ist. Veruch mal eine sinnstiftende Diskussion mit Josef zu führen. Es geht schon lange nicht mehr um die BO8. Niemand behauptet es sei leicht sowas zu bauen, aber diese extrem bizarre Gedankenwelt in der Josef lebt, die sich auf alles erstreckt das er anfasst, von der BO8 Architektur, über Hex Zahlen die das Dezimalsystem ersetzen sollen, Zeichensätze für 7seg Anzeigen die ausser Josef niemand verstehen kann, der Farbgebung, die Doku im allgemeinen, das ist es was zu Spott annimiert. Und mehr als Spott bleibt nicht, denn mit Josef zu diskutieren ist so lustig wie mit einem Käsehobel zu ornanieren. Das ist kein Technik Thread. Das ist ein psycho Thread in der zufällig Technik vorkommt.
Max M. schrieb: > von der BO8 Architektur, Was konkret? Die fehlenden Interrupts? Die Änderungen am Befehlssatz habe ich da zusammengefasst: Beitrag "Re: 8bit-Computing mit FPGA" Und es gab eine wesentliche Verbesserung am Timing: Beitrag "Re: 8bit-Computing mit FPGA"
Gerade gefunden in einem Nachbarthread: S. R. schrieb: > Andre G. schrieb: >> An Interrupts habe ich noch gar nicht gedacht ... > > Die meisten CP/M-Computer kommen ohne Interrupts aus, > obwohl der i8080 damit umgehen kann. Aber nicht gut. > Mein CPU-Emulator lässt die deswegen einfach weg.
Dazu sollte man vielleicht erwähnen, dass CP/M für Systeme ohne Interrupts entworfen wurde. Mein i80-Emulator soll auch nur CP/M (und passende Anwendungen) laufen lassen, deswegen ist das akzeptabel. Fehlende Interrupts beschränken die Möglichkeiten eines Systems massiv; bei CP/M wurde das in Kauf genommen, schon für MP/M reicht das m.W. nicht mehr.
Habe die Software der Test-Steckkarte überarbeitet. Meinen missglückten Versuch einer Gleitpunkt-Intervall-Arithmetik und einige weitere Kommandos habe ich entfernt, ausserdem einige Kommandos umbenannt. Die Dokumentation ist jetzt übersichtlicher, siehe die Seiten Hardware und Testcard des Download-Files. Wie schon die Software der Hauptplatine ist nun auch die Software der Test-Steckkarte als Assembler-Quelltext verfügbar, siehe das Verzeichnis tasm des Download-files. https://www.bo8h.de/Downloads/
Josef G. schrieb: > Da manche FPGA-Fachleute Vorbehalte gegen asynchrone Resets haben, > habe ich den CPU-Reset in einen synchronen Reset umgeschrieben. Lothar M. schrieb: > Josef G. (bome) schrieb: >> Altera hat keine Probleme mit asynchronen Resets, Xilinx schon. > Nein, auch das ist ein falsch erfasstes Gerücht. Altera hat > ausschließlich Flipflops mit asynchronem Reset. > Xilinx Flipflops können diesen Modus auch. Bin verwirrt. Vielleicht sollte ich die Umschreibung auf asynchronen Reset rückgängig machen. Dann könnte die CPU unverändert für eine ASIC-Realisierung übernommen werden.
Josef G. schrieb: > Dann könnte die CPU > unverändert für eine ASIC-Realisierung übernommen werden. Aber sicher! Das wird die neue Konkurrenz zu ARM und RISC-V!
Falk B. schrieb: > Josef G. schrieb: > >> Dann könnte die CPU >> unverändert für eine ASIC-Realisierung übernommen werden. > > Aber sicher! Das wird die neue Konkurrenz zu ARM und RISC-V! Nun lass ihn doch. Lass ihn investieren. Mal wirtschaftlich so richtig auf die Fresse fallen mit seinen Träumereien. Vielleicht weckt ihn das auf, wenn schon kein Jahrzehnt Spott hier im Forum. @Josef: Das wird die Weltrevolution. Damit wirst Du sie alle in die Knie zwingen. Bist ein gemachter Mann!
Josef G. schrieb: > Dann könnte die CPU unverändert für > eine ASIC-Realisierung übernommen werden. Oder für eine Realisierung mit Antifuse-FPGA.
Josef G. schrieb: > Oder für eine Realisierung mit Antifuse-FPGA. Auch das, Josef! Super! Egal wie Du es anstellst, Du kannst nur noch gewinnen! Packs an!
Und lass uns alle an Deinem Erfolg teilhaben. @Admin: Vorsorglich bitte schon mal die Extra-Rubrik Bo-CPU einrichten!
Josef G. schrieb: >> Dann könnte die CPU unverändert für >> eine ASIC-Realisierung übernommen werden. > > Oder für eine Realisierung mit Antifuse-FPGA. Deine BO8 läßt sich nur auf Anti-Logik FPGAs implementieren, denn nur die haben die essentiellen NFW, OMG und IDC Gatter! NFW (no fucking way) OMG (oh my god) IDC (i dont't care) ;-)
Josef ist wie Jesus. Er opfert sich, mit dem Ziel, eure Trollereien in einem einzigen riesigen Thread zu bündeln, damit die anderen Threads friedlich bleiben. Leider funktioniert das natürlich nicht. (Anders kann ich mir das ganze hier einfach nicht erklären.)
Josef G. schrieb: > Josef G. schrieb: >> Da manche FPGA-Fachleute Vorbehalte gegen asynchrone Resets haben, >> habe ich den CPU-Reset in einen synchronen Reset umgeschrieben. > > Lothar M. schrieb: >> Josef G. (bome) schrieb: >>> Altera hat keine Probleme mit asynchronen Resets, Xilinx schon. >> Nein, auch das ist ein falsch erfasstes Gerücht. Altera hat >> ausschließlich Flipflops mit asynchronem Reset. >> Xilinx Flipflops können diesen Modus auch. > > Bin verwirrt. Vielleicht sollte ich die Umschreibung auf > asynchronen Reset rückgängig machen. Dann könnte die CPU > unverändert für eine ASIC-Realisierung übernommen werden. Man kann auch beide, dediziert synchron und deziert asynchron globalen reset in den Code schreiben, dann aber in der Tophierarchie nur den einen verwenden und darauf setzen das die tool-chain die Logik des jeweils unbenutzen Resets entfernt. So findet man das beispielsweise an diesem älteren ATA-Interface-Core: https://opencores.org/projects/ata Dann gibt es die Möglichkeit FF-primitive in der Netzliste/backanotiertes VHDL per script zu ersetzen eben bei Xilinx FDCP (asynchron) durch FDRS (synchron). Und es gibt auch compile-Schalter die versuchen, das automatisch zu schaffen. -- Man kann auch die CPU-Register unterteilen in die: *die beim PowerUp von der Hardware initialisiert werden *die bei von der Software beim Booten initialisiert werden (bspw. Stackpointer, Interruptvektorregister) *die die garnicht initialisiert werden müßen (bspw. manche pipelineregister, Synchronizerstufen) Nach meinen Erfahrungen erleichtert dergleichen insbesonders das Place&Route und führt zu schnelleren Compile-Flow Zeiten und ggf. höherer schnellere Taktung. -- Prinzipiell ist m.E. Xilinx die bessere Architektur, wenn man gewillt ist, auch auf solche Details wie eben synchronen Reset zu achten. https://www.xilinx.com/support/documentation/white_papers/wp272.pdf https://www.xilinx.com/support/documentation/white_papers/wp275.pdf Bei Xilinx kann man auch noch weiter unterscheiden, ob family-/ oder Baustein davoer (Spartan-6 etc.). Da abe series-7 den synchronen set weiter vereinfacht hat. Da ist ein reset auf '1' besser als ein Reset auf '0'. https://docs.xilinx.com/v/u/en-US/ug429_7Series_Migration S. 4 - 8: Abschnitt "Use of control signals"
Hab mit meiner alternativen Zählweise in Game of Life experimentiert und eine hübsche Regel gefunden. Startbild war ein Quadrat 8x8.
Blendende Aussichten schrieb: > Mal wirtschaftlich so richtig auf die Fresse fallen mit seinen > Träumereien. Wie soll Josef mit der bo8 wirtschaftlich auf die Fresse fallen können? Das System wird verschenkt und kommerziellen Support sehe ich auch keinen. Investitionen auch keine, abgesehen von Freizeit. Josef G. schrieb: > Hab mit meiner alternativen Zählweise in Game of Life > experimentiert und eine hübsche Regel gefunden. > Startbild war ein Quadrat 8x8. Sieht schick aus. Hat was fraktalartiges.
S. R. schrieb: > Das System wird verschenkt und kommerziellen Support sehe > ich auch keinen. Investitionen auch keine, abgesehen von Freizeit. Josef, lass Dich von diesen Schwarzmalern bloß nicht abhalten die Bo8 CPU zum Erfolg zu führen! Wie weit bist Du schon mit der ASIC-Realisierung? Gibt es inzwischen weitere Test-Karten? Mit dem Game of Life hast Du bereits eine eine echte Killer-App am Start. Bleib dran!
Beitrag #7120232 wurde von einem Moderator gelöscht.
Beitrag #7120244 wurde von einem Moderator gelöscht.
Es ist übrigens bemerkenswert, daß Hewlett Packards frühere Taschenrechner bestimmter Modellserien auch alle das interne "breite" BCD system ausnutzen konnten und für Dezimal Arithmetik optimiert waren. Der HP-71B z.B. "Saturn" CPU, hatte die Fähigkeit mit 64-bit binären Registern zu operieren, sowohl als auch auf breite BCD Register Arithmetik umschalten zu können. Die besagten HP Rechner hatten auch einen extrem großen Exponentenbereich von +499 bis -500. Siehe auch hier: https://en.wikipedia.org/wiki/HP_Saturn
:
Bearbeitet durch User
Beitrag #7120306 wurde von einem Moderator gelöscht.
Beitrag #7120567 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
7seg3.png
248 Bytes -
Zeichen.png
886 Bytes
Franz schrieb: > Ich habe nicht verstanden wofür das Ganze gut sein soll. Als Spielzeug für Hex-Fans. Auch ein Hex-Befürworter Beitrag "Re: Willkommen in der Winterzeit" Es gibt eine kleine Änderung am CPU-Reset. Seit der letzten Software-Änderung der Testkarte braucht man nur noch eine PS2-Tastatur und einen VGA-Monitor (möglichst 1280*1024), um das System zu testen, inclusive Game of Life. SD-Karte und RS232 werden nicht mehr gebraucht. Für die Tastatur-Beschriftung empfehle ich, kleine Papier-Stücke mit Tesafilm auf die Tasten zu kleben, die kann man nachher wieder ablösen. Das aktuellste FPGA-Board ist das DE0-CV.
Josef G. schrieb: > Auch ein Hex-Befürworter > Beitrag "Re: Willkommen in der Winterzeit" Oh, seid ihr jetzt schon zwei? Ach ne, war ja ein Smiley hinter, weil Josef mit seiner BO8 der mc.net running Gag ist. Josef G. schrieb: > Es gibt eine kleine Änderung am CPU-Reset. Das heißt alle Anwender müssen jetzt ihr Setup ändern? Okay, hast Du ja nun gemacht. Erledigt.
Angehängte Dateien:
-
DE0n.jpg
140 KB -
DE0n-PS2.png
19 KB
Das DE0-CV scheint derzeit nicht lieferbar zu sein. Problemlos lieferbar und immer noch aktuell ist das DE0-nano mit Cyclone IV. Ich habe darum meine Realisierung mit DE0-nano neu aufgebaut. Ein Problem beim DE0-nano ist die Stromversorgung. Die 5 Volt vom USB-Anschluss und ein optionales zusätzliches Netzgerät sind über Dioden entkoppelt. Um sicherzustellen, dass das Netzgerät die Versorgung übernimmt, braucht man ein Netzgerät mit etwa 5.4 Volt. Das Angebot an solchen Netzgeräten scheint derzeit ein wenig besser zu sein als bei meinem Kauf. Die Tastatur hatte ich bisher mittels eines Pmod-Moduls von Digilent an 3.3 Volt betrieben. Jetzt hängt sie über eine eigene Schaltung an 4.7 Volt, damit man auch andere Tastaturen verwenden kann. Die Beschaltung der PS2-Signale ist die gleiche wie bei den Terasic-Bords mit fest eingebautem PS2-Anschluss. Die Last 330 Ohm an 3.3 Volt habe ich hinzugefügt, weil mir die sonst auftretende Stromrückspeisung suspekt ist. Die VGA-Schnittstelle besteht aus einer D-Sub-Buchse und fünf Widerständen, 340 Ohm in den drei Farb-Leitungen und 121 Ohm in den beiden Sync-Leitungen. Angeschlossen sind ausserdem die Module Pmod-SD, Pmod-RS232 und zweimal Pmod-SSD von Digilent. Die 7-Segment-Anzeigen werden nicht unbedingt benötigt. Auch RS232 und SD-Karte kann man weglassen, man sollte dann aber die beiden sonst offenen FPGA-Eingänge mit Pullups versehen.
:
Bearbeitet durch User
Es gibt eine Änderung am Assembler. Der Offset 0 bis F beim Label-Aufruf ist jetzt signed. 8 bis F steht für -8 bis -1.
Josef G. schrieb: > Der Offset 0 bis F beim > Label-Aufruf ist jetzt signed. 8 bis F steht für -8 bis -1. Das heißt, man kann keine allzu weiten Sprünge mehr machen ;-) Was macht man mit den tausenden von bisherigen Programmen für Deine CPU? Muss man die jetzt alle umschreiben?
Frank M. schrieb: > Das heißt, man kann keine allzu weiten Sprünge mehr machen ;-) Große Sprünge konnte man mit der BO8 doch nie machen :-| Das ist eine Lehr-CPU. Anhand der kann man lernen wie man ein Projekt nicht machen sollte, wie wichtig lesbare Dokumentation gewesen wäre, was alles an der Kommunikation schieflaufen kann und was die wichtigsten Punkte sind, wenn man sicherstellen will das wirklich niemand jemals auf die Idee verfallen wird das Produkt zu nutzen oder sich auch nur daran zu beteiligen. Und da muß ich Josef mein großes Lob aussprechen. Das hat er alles bravourös herausgearbeitet. Wenn man einfach konsequent alles völlig anders macht, hat man eine reelle Chance erfolgreich zu sein.
Max M. schrieb: > Das ist eine Lehr-CPU. > Anhand der kann man lernen wie man ein Projekt nicht machen sollte, Auch Anti-Patterns sind wichtig! Kein Witz!
Frank M. schrieb: > Josef G. schrieb: >> Der Offset 0 bis F beim Label-Aufruf ist >> jetzt signed. 8 bis F steht für -8 bis -1. > > Das heißt, man kann keine allzu weiten Sprünge mehr machen ;-) Die Änderung betrifft nur den Assembler, nicht die CPU. Fast alle Label-Aufrufe sind ohne Offset.
Ein Beispiel für die Anwendung des Offsets:
1 | =LABEL GTMXI |
2 | ... |
3 | ... |
4 | B.VS LABEL+1 |
GTMXI ist ein Makro und steht für GTMX IXE GTMX. B.VS Rückwärtssprung falls V gesetzt. Ziel ist IXE. Bei meinem Assembler hat eine Code-Zeile maximal 8 Byte. Mit Label-Offset -8 bis +7 können mindestens alle Bytes der Zeile adressiert werden, in welcher das Label steht, und alle Bytes der vorherigen Zeile.
:
Bearbeitet durch User
Josef G. schrieb: > GTMX IXE GTMX Dieser opcode ist für mich nicht intuitiv verständlich. Ich habe ja schon den einen oder anderen Assemblerquelltext gelesen und ein paar wenige auch geschrieben, aber hierfür ist vmtl. mein IQ zu gering...
Hans schrieb: > Ich habe ja schon den einen oder anderen Assemblerquelltext gelesen und > ein paar wenige auch geschrieben, aber hierfür ist vmtl. mein IQ zu > gering... Du spricht mit einem Menschen, der seine SEHR eigene "Logik" besitzt, die dem Rest der Welt nicht zugänglich ist. Dieser Mensch ist ein Autist. https://de.wikipedia.org/wiki/Autismus
Josef G. schrieb: > GTMXI ist ein Makro und steht für GTMX IXE GTMX. > B.VS Rückwärtssprung falls V gesetzt. Ziel ist IXE. Besser hättest du es nicht ausdrücken können.
Hans schrieb: > Josef G. schrieb: >> GTMX IXE GTMX > Dieser opcode ist für mich nicht intuitiv verständlich. Das ist kein OpCode, sondern das sind drei OpCodes. Genauer: Es sind nicht OpCodes, sonder drei Mnemonics. Hab ich hier ausnahmsweise in eine Zeile geschrieben. Schreibt man normalerweise untereinander. GTMX - Get Memory X - Lade Inhalt der Speicherzelle, auf welche das Adressregister X zeigt, in den Akku. IXE - Inkrementiere X und tausche Akku mit Register B. Insgesamt werden also 2 Byte in das Dppelregister AB geladen.
Falk B. schrieb: > Dieser Mensch ist ein Autist. Endlich hat Josef eine Diagnose. Oder Falk ist ein Spinner. Mindestens eins ist wahr.
Josef G. schrieb: > GTMX - Get Memory X - Lade Inhalt der Speicherzelle, > auf welche das Adressregister X zeigt, in den Akku. > > IXE - Inkrementiere X und tausche Akku mit Register B. > > Insgesamt werden also 2 Byte in das Dppelregister AB geladen. Es gibt also das Register X (vmtl. 16 Bit), den Akku A (8 Bit) und das B-Register (8 Bit). Ist X auch ein Doppelregister (XY?) oder sind die verschiedenen Register unterschiedlich breit? Gibt es weitere Register? Der 6502 hat ja deren auch nicht soviel (A, X, Y, SP, PC, Flags)...
Hans schrieb: > Gibt es weitere Register? 8bit-Computer: bo8h Siehe Abschnitt "Die CPU". 8bit-CPU: bo8
MaWin O. schrieb: > Endlich hat Josef eine Diagnose. Die hat er schon seit Jahren. Er akzeptiert sie nur nicht. Von seinem Standpunkt aus gesehen ist er der einzige normale auf der ganzen Welt.
MaWin O. schrieb: > Endlich hat Josef eine Diagnose. > Oder Falk ist ein Spinner. > Mindestens eins ist wahr. Auch ein Spinner kann eine richtige Diagnose stellen...
Smith schrieb: > Die hat er schon seit Jahren. Er akzeptiert sie nur nicht. Von seinem > Standpunkt aus gesehen ist er der einzige normale auf der ganzen Welt. Das hat Josef nie behauptet. Was soll also Deine Behauptung? Vermutlich projizierst Du nur Deine eigenen Störungen oder Probleme auf einen Dritten.
Liest hier jemand mit, der ein DE0-CV besitzt? Da müsste man nichts basteln, auch das RS232-Modul kann man weglassen. Der Code ist ohne Timing-Constraints. Er funktioniert trotzdem. Lasst das System doch mal laufen und postet ein paar Bilder.
Naja, Ausdauer und absolute Überzeugung hat er ja, der Joseph. Aber im Gegensatz zu seinem historisch/biblischen Namensvetter wird das wohl nix mit der neuen Religion . . . ;-) "mostly harmless" trifft es ganz gut . . .
:
Bearbeitet durch User
Josef G. schrieb: > Hab mit meiner alternativen Zählweise in Game of Life experimentiert Könnte man das etwas näher ausführen, wie das geht? Die Bilder finde ich cool.
Gregor schrieb: > Könnte man das etwas näher ausführen, wie das geht? In der Standardversion haben alle 8 Nachbarn einer Zelle (4 Kanten, 4 Ecken) das gleiche Gewicht, die Summe hat die Werte 0 bis 8. Es gibt dann verschiedene Varianten des Spiels, je nachdem bei welchen Werten der Summe eine Zelle bleibt oder ensteht. In meiner alternativen Version haben die Kanten das doppelte Gewicht, die Summe hat die Werte 0 bis 12. Und auch hier hat man verschiedene Varianten wie in der Standardversion. In meiner Realisierung wählt man zuerst zwischen Standardversion und alternativer Version. Dann kann man für alle 9 oder 13 Werte der Summe einzeln festlegen, ob eine Zelle bleibt und ob eine Zelle entsteht. Das Startbild erstellt man jeweils vorher im Texteditor. Ein beliebiges nichtleeres Zeichen ergibt eine aktive Zelle. Insgesamt waren die Ergebnisse bei meiner alternativen Version eher enttäuschend, man erhält meist sehr schnell ein leeres Spielfeld oder ein unbegrenztes Wachstum. Die Ästhetik der obigen Bilder entsteht ganz einfach durch die Symmetrie des Startbildes. Ähnliche Bilder gibt es auch in der Standardversion.
Nochmal zu Game of Life Im Emulator funktioniert nur der Einzelschrittbetrieb.
Josef G. schrieb: > Insgesamt waren die Ergebnisse bei meiner alternativen Version eher > enttäuschend, man erhält meist sehr schnell ein leeres Spielfeld oder > ein unbegrenztes Wachstum Hast Du nichts Sinnvolleres mit Deiner Zeit zu tun? Welche produktiven Ergebnisse Deiner Arbeit gibt es die irgendwo in ernsthaftem Einsatz sind? Bislang sind von Dir hier nur technische Spielereien und Träume von einer Hexzeichen- beglückten Welt aktenkundig.
Jan V. schrieb: > Hast Du nichts Sinnvolleres mit Deiner Zeit zu tun? Welche produktiven > Ergebnisse Deiner Arbeit gibt es die irgendwo in ernsthaftem Einsatz > sind? Du glaubst also nur produktive Dinge seien sinnvoll? Denk mal darüber nach.
Josef G. schrieb: > https://sedimal.eu 'Wir sind für die Einführung des Sedimalsystems als Zahlensystem für den Alltag.' Wer ist 'Wir'? Du und die Stimmen in Deinem Kopf?
Max M. schrieb: > Josef G. schrieb: >> https://sedimal.eu > > Wer ist 'Wir'? Na die "Sedimal Society of Europe" Wer die ist? Steht doch auch da: > Wer wir sind > Die Seite ist eine Initiative einer Einzelperson. > Eine Sedimal Society of Europe gibt es bisher nicht. Die Seite hätte durchaus das Potential, so eine Art Postillon für E-Techniker zu werden. Aber so wie ich das hier sehe meint es der Autor tatsächlich ernst. Egal, einfach trotzdem als Satire werten, dann ist das durchaus lustig.
Max M. schrieb: > Josef G. schrieb: >> https://sedimal.eu > > 'Wir sind für die Einführung des Sedimalsystems Hab ich geändert.
Hans schrieb: > Josef G. schrieb: >> GTMX IXE GTMX > Dieser opcode ist für mich nicht intuitiv verständlich. 😂😂😂 SCNR
Max M. schrieb: > Wer ist 'Wir'? > Du und die Stimmen in Deinem Kopf? Das ist der Pluralis Majestatis. Hier mal Josef in Aktion: https://www.pinterest.es/pin/385902261808641874
Andreas S. schrieb: > Josef G. schrieb: >> Man stelle sich vor, welche Aufbruchstimmung ein solches >> Vorhaben erzeugen würde. > > Ähem, so gut wie keine. Wir haben das mal gemacht, in HEX zu zählen. Das DAUERT, bist das kannst! Wir sind so derart an der 10er gewöhnt, dass wir schon mit dem 12er der Römer nicht klarkommen oder dem 5er der Agypter. Nene, das wird nichts werden. Was man mal machen könnte, wäre den Franzosen ihre Darstellung von Zahlen zu vereinfachen. Es ist nicht einzusehen, dass römisch-agyptisches System bis 60 - mit dem 2-fach-5er unseres Indisch-arabischen Systems mischen und dann 0...60 zählen und nicht bis 59 dann aber 60 ...79 und nicht konsequent bis 80 um dann ab 80 bis 99 zuzählen. Das sind 3 Zahlensysteme vermixt! und zudem 3 Bereiche um die 100 abzubilden. quelle merde
Oswald schrieb: > Andreas S. schrieb: >> Ähem, so gut wie keine. > > Wir haben das mal gemacht, in HEX zu zählen. Das DAUERT, bist das > kannst! Es dauert offenbar, bis DU das kannst. Ich habe wenig Probleme damit, in Hex zu rechnen. Gerade bei der Low-Level-Programmierung ist man doch ständig damit beschäftigt. Zugegebenermaßen ist mir das Dezimalsystem aber doch geläufiger. > Nene, das wird nichts werden. Das ist doch auch meine Aussage. Ich teile Josefs Auffassung doch nicht im geringsten. > [Französische Sprache] > Das sind 3 Zahlensysteme vermixt! und zudem 3 Bereiche um die 100 > abzubilden. Nein, in der französischen Sprache bzw. dem frankophonen Kulturkreis wird ebenfalls im Dezimalsystem gerechnet. Nur die Bezeichnungen bestimmter Zahlenbereiche ist etwas speziell. Im schweizerischen Französisch wird aber ganz normal bis 99 gezählt, d.h. auf 69 folgt 70 (septante), dann 80 (octante, nicht 4*20) und 90 (nonante, nicht 4*20+10). Im belgischen Französisch zählt man aber 69, 60+10 (soixante-dix) bis 60+19 (soixante-dix-neuf), aber dann 80 (octante, nicht 4*20 (quatre-vingt)), 90 (nonante), usw..
Angehängte Dateien:
-
Lern.png
852 Bytes
Oswald schrieb: > Wir sind so derart an der 10er gewöhnt, ... > Nene, das wird nichts werden. Ein kleiner Rahmen mit vier Stäben, auf jedem vier Kugeln zum hin und her schieben. Damit könnten Kinder das Zählen lernen.
Josef G. schrieb: > Ein kleiner Rahmen mit vier Stäben, auf jedem vier Kugeln zum > hin und her schieben. Damit könnten Kinder das Zählen lernen. Zwei Hände mit je fünf Fingern. So lernen Kinder zählen.
Josef G. schrieb: > Ein kleiner Rahmen mit vier Stäben, auf jedem vier Kugeln zum > hin und her schieben. Damit könnten Kinder das Zählen lernen. Pass mal auf, daß das nicht Graf Zahl sieht, der beißt dir in den Hals! https://www.youtube.com/watch?v=W9M39CVxLEA
Josef G. schrieb: > Ein kleiner Rahmen mit vier Stäben, auf jedem vier Kugeln zum > hin und her schieben. Damit könnten Kinder das Zählen lernen. Smith schrieb: > Zwei Hände mit je fünf Fingern. So lernen Kinder zählen. Kein Problem. Dazu hat Josef den BO5H4f7 Handmodifikator entwickelt. Damit einfach einen Finger abtrennen, dann passt das wieder zu den 4 Kugeln.
Josef G. schrieb: > Ein kleiner Rahmen mit vier Stäben, auf jedem vier Kugeln zum > hin und her schieben. Damit könnten Kinder das Zählen lernen. Nö, 4 Stäbe/Kugeln ist definitiv falsch, denn das würde dann beim Abakus ein Zahlensysten mit Basis 4 definieren. Für's Hexadezimalsystem müßten es 16 Kugeln pro Stab sein. Mit der Anzahl der Stäbe bestimmt man dann die höchtste darstellbare Zahl. Mit 2 Stäben wäre das 255 (dezimal), 3 Stäbe wären dann 512 usw. usw.. Praktisch (im alltäglichen Leben) ist diese Zählweise allerdings wenig intuitiv und schlichtweg unbrauchbar. Die Präfixe von Einheiten sind mit diesem Zahlensystem praktisch nicht mehr nutzbar und darstellbar. Die Krux mit diesem System sieht man ja schon bei den Größenangaben von Speichern, wo 1k eben nicht mehr 1000 sondern 1024 ist. Noch verückter wird es bei M (1024x1024). Derart krumme Zahlen kann sich kein Mensch wirklich vorstellen, geschweige denn merken. Es hat schon einen Grund warum sich weltweit in den meisten Ländern, das metrische auf 10 basierende System durchgesetzt hat.
Hallo, Zeno schrieb: > Derart krumme Zahlen kann sich kein Mensch wirklich vorstellen, > geschweige denn merken. Die sind aber nur scheinbar krumm, weil du sie aus dem Dezimalsystem heraus betrachtest. Aus Sicht des 16er-Systems sind die Zahlen nicht krum. rhf
Roland F. schrieb: > Die sind aber nur scheinbar krumm, weil du sie aus dem Dezimalsystem > heraus betrachtest. Aus Sicht des 16er-Systems sind die Zahlen nicht > krum. Stimmt. Aber der Josef ist trotzdem ein Fall von ICD-10, F84.5. https://de.wikipedia.org/wiki/Autismus#Asperger-Syndrom
Beitrag #7299775 wurde vom Autor gelöscht.
Produktmanager schrieb: > Du glaubst also nur produktive Dinge seien sinnvoll? > Denk mal darüber nach. Du glaubst also nur solche Spinnereien seien sinnvoll? Denk mal darüber nach. Zeno schrieb: > Es hat schon einen Grund warum sich weltweit in den meisten Ländern, das > metrische auf 10 basierende System durchgesetzt hat. Natürlich hat es das. Irgendeinen gibts aber immer der was nicht einsehen mag. Insbesondere dann wenn dieser sonst keine wichtigeren Probleme hat.
:
Bearbeitet durch User
Roland F. schrieb: > Die sind aber nur scheinbar krumm, weil du sie aus dem Dezimalsystem > heraus betrachtest. Aus Sicht des 16er-Systems sind die Zahlen nicht > krum. Ja natürlich sind sie im Hexadezimalsystem nicht krumm, ebenso wie Binärzahlen im Binärsystem oder Oktalzahlen im Oktalsystem nicht krumm sind, dennoch tue ich mich damit schwer die Realität in diesem System abzubilden. So wird es wohl dem größten Teil der Menschheit gehen. Wir sind es einfach gewöhnt im Dezimalsystem zu zählen und zu rechnen, selbst die Amis rechnen in ihrem nicht metrischen System dezimal. Ob das dezimale Rechnen von der Anatomie des Menschen, also den 10 Fingern her rührt, darüber läßt sich trefflich streiten, aber vermutlich hat genau das eine Rolle gespielt.
Jan V. schrieb: > Irgendeinen gibts aber immer der was nicht einsehen mag. Insbesondere > dann wenn dieser sonst keine wichtigeren Probleme hat. Naja ganz so kann man es eben auch nicht sehen. In der Welt der Technik und speziell in der Welt der digitalen Datenverarbeitung haben auf dem binären System aufbauende Zahlensysteme schon eine Bedeutung und sind dort auch sinnvoll. Aber sie sind eben nur dort nach menschlichen Verständis sinnvoll anwendbar. Mit anderen Worten, für Josef's FPGA macht solch ein binäres System durchaus Sinn. Wenn es auch für Josef sinnvoll ist und er auch damit im Alltag vernünftig rechnen (anwenden) kann, was ich bezeifle, dann ist es ja gut und seine Sache, aber der überwiegende Teile der Menschheit denkt eben anders. Ich stelle mir gerade vor Josef geht zum Bäcker und verlangt E Brötchen oder beim Fleischer FAg Wurst. Ich schätze da wird der Bäcker/Fleischer wohl die Männer mit den weißen Jacken zum hinten zu machen rufen.
Falk B. schrieb: > Stimmt. Aber der Josef ist trotzdem ein Fall von ICD-10, F84.5. Und Falk ist möglicherweise ein Fall von ICD-10, K02.9, und leidet häufiger unter ICD-10, J06.9.
Zeno schrieb: > Ich stelle mir gerade vor Josef geht zum Bäcker und verlangt E Brötchen > oder beim Fleischer FAg Wurst. Ich schätze da wird der Bäcker/Fleischer > wohl die Männer mit den weißen Jacken zum hinten zu machen rufen. Wenn sich das Sedizmalsystem wirklich etablieren würde, gäbe es auch entsprechende Ziffernbezeichnung für dezimal 10-15, so dass es zu keinen Verwechslungen mit den Buchstaben A-F mehr käme. Josef ist immerhin so weitsichtig, diesen wesentlichen Unterschied zu unserem "Behelfshex" zu erkennen. Die vor einigen Jahrzehnten versuchte Einführung von (dezimalen) Neugrad, dem ein Vollkreis 400° hat, ist bekanntlicherweise auch ziemlich gescheitert, obwohl hier die Hürde durchaus geringer gewesen wäre. Es gab schlichtweg keinen hinreichenden Leidensdruck, der so etwas rechtfertigte. Ich kann mich aber noch an meine Grundschulzeit erinnern, in der unsere Klassenlehrerin die Umstellung auf Neugrad behauptete und wir auch das Umrechnen übten. Aber ich weiß nicht, ob dies so durch den Lehrplan vorgegeben war oder eher ihrer eigenen Weltanschauung entsprach. Interessanterweise wird das Neugrad mittlerweile als Gon bezeichnet und ist in den EU-Staaten und der Schweiz sogar eine gesetzliche Einheit. Angeblich soll es auch in der Robotik und Automatisierungstechnik verwendet werden, weswegen Schrittmotoren meist 200 Schritte pro Vollkreis hätten. https://de.wikipedia.org/wiki/Gon
Andreas S. schrieb: > Die vor einigen Jahrzehnten versuchte Einführung von (dezimalen) > Neugrad, dem ein Vollkreis 400° hat, ist bekanntlicherweise auch > ziemlich gescheitert, obwohl hier die Hürde durchaus geringer gewesen > wäre. Die USA sind auch nicht vollständig metrisch, das wird sich auch nie ändern. Hinter den Kulissen in der Industrie sind die aber metrischer als das allen auch nur ansatzweise bewußt ist. Aber selbst die NASA macht immer noch Misch Masch.
Falk B. schrieb: > Die USA sind auch nicht vollständig metrisch, das wird sich auch nie > ändern. Das ist die Untertreibung des Jahres. Ein Maßsystem, in dem praktisch nichts auf irgendwas anderem aufbaut und individuell bizarre Umrechnungsfaktoren benötigt, ein Maßsystem, in dem die eigentliche Dimension weggelassen und nur das Präfix verwendet wird ("thou", "mil", "micron") ... Wusstest Du, daß die USA zwei verschiedene Füße haben, und daß die Verwendung der Füße von Bundesstaat zu Bundesstaat unterschiedlich gehandhabt wird? https://www.nytimes.com/2020/08/18/science/foot-surveying-metrology-dennis.html?searchResultPosition=23 > Hinter den Kulissen in der Industrie sind die aber metrischer als das allen auch nur ansatzweise bewußt ist. Das dürfte ausschließlich die Elektronikindustrie betreffen. Sonst aber nichts.
Andreas S. schrieb: > Die vor einigen Jahrzehnten versuchte > Einführung von (dezimalen) Neugrad, Für den Vollkreis sollte man auch nach Umstellung auf hex eine durch drei teilbare Maßzahl beibehalten, damit der Eckwinkel des gleichseitigen Dreiecks eine ganze Zahl bleibt.
Josef G. schrieb: > Für den Vollkreis sollte man auch nach Umstellung > auf hex eine durch drei teilbare Maßzahl beibehalten, > damit der Eckwinkel des gleichseitigen Dreiecks eine > ganze Zahl bleibt. Interessant, das war offenbar der Grund für das damalige Scheitern der Neugradeinführung. Wäre man damals also konsequenter vorgegangen und hätte Neugrad und Sedezimalsystem zusammen eingeführt, wäre das also erfolgreich durchgelaufen.
DerEinzigeBernd schrieb: >> Hinter den Kulissen in der Industrie sind die aber metrischer > als das allen auch nur ansatzweise bewußt ist. > > Das dürfte ausschließlich die Elektronikindustrie betreffen. Sonst aber > nichts. Naaa, das betrifft auch die Industrie und den Maschinenbau, allen voran die Autoindustrie. Selbst Harley Davidson baut seit über 10 Jahren metrisch! Kein Wunder daß die USA nicht mehr "great" sind ;-)
Beitrag #7300075 wurde von einem Moderator gelöscht.
Beitrag #7300135 wurde von einem Moderator gelöscht.
Andreas S. schrieb: > enn sich das Sedizmalsystem wirklich etablieren würde Ja wenn, aber wir leben im Heute und jetzt, also mit nicht etablierten Sedizmalsystem, da ist es dann auch völlig schnuppe ob wir passende Bezeichnungen/Symbole für die Hexdezimalzahlen A-F haben. Falk B. schrieb: > Aber selbst die NASA > macht immer noch Misch Masch. Nicht nur die NASA, das war und ist auch in anderen Industriebereichen so. Durfte ich fast 30 Jahre selbst erfahren, was das für ein großer Mist ist, wenn in einer Baugruppe Metrisch und Zoll gemixt ist. 1/8" und M3 ist z.B. so ein übler Kandidat, der optisch nicht auf den ersten Blick unterscheidbar ist. Eine M3 Schraube bekommt man bei 1/8" problemlos eingedreht. Sie klappert zwar ein bischen aber sie wird "fest". Am Ende hat man dann eine 1/8" Schraube übrig, die natürlich nicht in eine M3-Gewindebohrung eingeschraubt werden kann. Man muß dann halt alles wieder auseinander nehmen und schauen wo man die falsche Schraube eingesetzt hat. Mit den Schlüsseln ist es genau so eine Kacke, weil die Stufungen so fein sind, daß man die Schlüssel teilweise kaum unterscheiden kann - man merkt es erst wenn man sie benutzt. DerEinzigeBernd schrieb: > Wusstest Du, daß die USA zwei verschiedene Füße haben, und daß die > Verwendung der Füße von Bundesstaat zu Bundesstaat unterschiedlich > gehandhabt wird? > > https://www.nytimes.com/2020/08/18/science/foot-surveying-metrology-dennis.html?searchResultPosition=23 Die Amis haben halt ne Vollmeise - mehr kann man dazu nicht sagen. Josef G. schrieb: > Für den Vollkreis sollte man auch nach Umstellung > auf hex eine durch drei teilbare Maßzahl beibehalten, > damit der Eckwinkel des gleichseitigen Dreiecks eine > ganze Zahl bleibt. Ach Josef da ist wohl eher der (Dein) Wunschtraum Vater des Gedankens. Die Umstellung wird nicht kommen und so müssen wir uns keine Gedanken um den Vollkreis machen.
Beitrag #7300151 wurde von einem Moderator gelöscht.
Klaus schrieb: > Max M. schrieb: >> Josef G. schrieb: >>> https://sedimal.eu > > Die Seite hätte durchaus das Potential, so > eine Art Postillon für E-Techniker zu werden. Hätt ich nix dagegen.
Josef G. schrieb: > Hätt ich nix dagegen. Du weißt aber schon, was der Postillon für eine Seite ist, oder?
Hab die Seite https://sedimal.eu überarbeitet. Josef G. schrieb: > Von den FPGA-Boards, für welche eine Realisierung des Projekts > existiert, sind nur noch das DE0-CV und das DE0-nano aktuell. Beim > DE0-nano müsste man einiges basteln. Beim DE0-CV braucht man lediglich > eine PS2-Tastatur mit neuer Beschriftung. > > Aus der Sicht von FPGA-Fachleuten hat das Projekt Qualitätsmängel. Da > sind die fehlenden Timing-Constraints und die Takterzeugung durch > Teiler-Flipflops. Jeder Takt wird aber über ein Taktnetz verteilt. Ein > weiterer Kritikpunkt waren die zwei Takteingänge der CPU. Man kann aber > beide an denselben Takt anschließen. > > An der CPU mag man die fehlenden Interrupts kritisieren. Aber das > Gesamt-Projekt zeigt, dass man damit dennoch einiges machen kann. Laut > Aussage eines anderen Forennutzers kam sogar das klassische > Betriebssystem CP/M ohne Interrupts aus.
Smith schrieb: > Josef G. schrieb: >> Hätt ich nix dagegen. > Du weißt aber schon, was der Postillon für eine Seite ist, oder? Der Vergleich hinkt aber etwas, denn der Sachverhalt ist hier ja der, dass Artikel auf dem "Post" dinge beschreiben, die es real nicht gibt, die dafür aber lustig sind und Spass macht. Hier ist das eher anders herum: Ich kann mir nicht vorstellen, dass es Spass machen kann, mit solch einem System zu arbeiten.
Thomas U. schrieb: > Ich kann mir nicht vorstellen, dass es Spass > machen kann, mit solch einem System zu arbeiten. Warum? Weil Andere hier das auch sagen? Oder hast du dir selber eine Meinung gebildet?
Josef G. schrieb: > Warum? Weil Andere hier das auch sagen? Magst Du das mit Deiner User Comunity weiter diskutieren? So lange wie es Dein System nun schon gibt und so lange wie Du der größten deutschspachigen Website für Elektronik und Computer schon damit auf die Nerven gehst, sollte es doch bereits wackere Mitstreiter geben. Wenn man nach einer derart langen Zeit eine Nutzeranzahl von NULL hat und es niemanden gibt der die eigene Irrfahrt unterstützt, würde man sich doch mal die Frage stellen können woran das liegen könnte. Außer Dir wollen vielleicht noch drei Leute weltweit das Hexadezimalsystem einführen. Deutlich mehr halten es für eine gute Idee sich das Gesicht zu tätowieren und die Zunge spalten zu lassen. Das mal dazu in welcher Liga der geschmacklichen Irrläufer das spielt. Alle Welt daddelt mit einer Vielzahl an Kleincomputern aus allen Epochen der Technikgeschichte herum, aber nur Josef Gnadl mit der BO8. Also ganz offensichtlich macht Deine BO8 weniger Spaß als alle anderen Systeme. Glückwunsch zu den neuen, etwas weniger schrecklichen Farben Deiner Website. Der Inhalt ist nur immer noch uninteressant und eher unfreiwillig komisch.
Es gibt ein paar Aktualisierungen: Im VHDL-Code habe ich die internen Tristates entfernt. Das reduziert die Anzahl der Warnungen bei der Synthese, bei Quartus sogar drastisch. Die "Steckkarten" sind jetzt nur noch RAM-Erweiterungen ohne zugeteilte IO-Adressbereiche. Alle IO-Erweiterungen sind jetzt in der einen Entity expa zusammengefasst. Weitere Schnittstellen kann man als Unter-Entity der Entity expa hinzufügen. In der Toplevel-Entitiy der FPGA-Boards sind nur noch in der Port-Deklaration die zusätzlichen IO-Signale einzutragen. Auch am CPU-Befehlssatz gab es nochmal eine Änderung: Symmetrisch zum Befehl CP.V (V wird V xor U) gibt es jetzt den Befehl CP.U (U wird V xor U). Letzterer ersetzt den Befehl CR.V, welcher dieselbe Operation und dann ein RU.A ausführte. Die Kombination mit RU.A sollte die Berechnung der Parität und die Gray-Code-Konvertierung beschleunigen. Beides wird man jedoch, falls benötigt, ohnehin besser lösen durch spezielle IO-Hardware. 8bit-Computer: bo8h / 8bit-CPU: bo8 https://www.bo8h.de
Josef G. schrieb: > Auch am CPU-Befehlssatz gab es nochmal eine Änderung: Symmetrisch zum > Befehl CP.V (V wird V xor U) gibt es jetzt den Befehl CP.U (U wird V xor > U). noooooo, jetzt hab ich gerade ASICs machen lassen 🥺
Mampf F. schrieb: > noooooo, jetzt hab ich gerade ASICs machen lassen 🥺 Es tut mir leid, aber ich muss meine Bestellung Deiner ASICs stornieren, weil ich nun mit solch einem veralteten Kram nichts mehr anfangen kann. Vielleicht kannst Du ja noch Parkbänke oder Müsliriegel daraus pressen lassen.
Josef G. schrieb: > Symmetrisch zum > Befehl CP.V (V wird V xor U) gibt es jetzt den Befehl CP.U (U wird V xor > U). Letzterer ersetzt den Befehl CR.V, welcher dieselbe Operation und > dann ein RU.A ausführte. Die Kombination mit RU.A sollte die Berechnung > der Parität und die Gray-Code-Konvertierung beschleunigen Aha. Einfach und logisch. Und auch vollkommen nutzlos, wie selbst der TO erkennt. Josef G. schrieb: > Beides wird > man jedoch, falls benötigt, ohnehin besser lösen durch spezielle > IO-Hardware. Gut, das war also der Sketch zum Dienstag. Danke, habe sehr gelacht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.