Announcement: there is an English version of this forum on 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.
Thread beobachten
Seitenaufteilung abschalten