joyceforum.de

Moin Paul,
ich habe einmal in den man-Pages zu meinem Linux system nachgesehen, also grundsätzlich ist "pbm" ausgeschrieben "portable bitmap file format". Übersetzt: portables Bitmap Datei Format". Nachfolgend die Kurzbeschreibung aus der man-Page:

pbm(5) File Formats Manual pbm(5)

NAME
pbm - portable bitmap file format

DESCRIPTION
The portable bitmap format is a lowest common denominator monochrome
file format. It serves as the common language of a large family of
bitmap conversion filters. Because the format pays no heed to effi‐
ciency, it is simple and general enough that one can easily develop
programs to convert to and from just about any other graphics format,
or to manipulate the image.

Kurz: es ist der kleinste gemeinsame Nenner eines Bildformates ohne besondere Rafinessen, Haken und Ösen und soll so recht einfach in andere Bildformate konvertierbar sein. BMP's können wegen ihrer vielen Formate (im Dateikopf der Daten definiert) recht komplex sein.

Gruss
Kurt

Ich antworte mir mal selbst, hab' zu schnell auf 'Senden' gedrückt.

Da die Sache auf Deiner Seite immer umfangreicher wird, erscheint es mir sinnvoll, mein ursprüngliches Konzept dahingehend abzuändern, dass ich versuche die C Header-Dateien als Pascal INC-Dateien zu verfassen und damit loslege. So weit daneben liegen meine Grafik-Calls verglichen zum Joyce nun doch nicht. Das könnte vorerst sinnvoller sein, außerdem ergibt so ein 2tes Standbein. Mal sehen, auf was für Probleme ich stoße, wenn ich Turbo-Pascal installiere, von der Benutzung ganz zu schweigen

Gruß
Kurt

Moin Bernd,
Du bringst mich in Zugzwang bezüglich des HPGL-Interpreters. Die Treiber für die seriellen Schnittstellen & den I2C-Bus (am Multicomp) samt Doku haben mich bis vor einer Woche reichlich beschäftigt. Dafür kann ich aber jetzt diese Punkte als "benutzbar" abhaken. Insbesondere die Sache mit der (I2c-) RT-Clock war mir so wichtig, dass ich das Interpreter-Projekt als Nachfolgeprojekt zurückgestelt habe. Mein Plan ist, den Interpreter zum "Bitte 8-Bit"-Treffen (wenn es denn hoffentlich stattfinden kann) fertig portiert zu haben. Mir fehlt einfach Software, mit der ich die Pixelgrafik beschäftigen kann, unter CPM gibt es nichts gescheites...

Schau'n mer mal..

Kurt

Moin,
32-bit Integer wird genuegen - also lag ich mit meiner Vermutung richtig. Das erleichtert mir die Arbeit. Ich bearbeite gerade den MCode-Block am Anfang von KERNEL.INC. Dast Du den Assembler-Code zur Hand ? Anhand des Hex-Codes die Befehle zu suchen ist doch etwas frickelig...

Wie mir aufgefallen ist, ist der Code "leicht" selbst modifizierend. Ich hoffe das vermeiden zu koennen, da der C-Compiler eventuelle Variablennamen im Assembler-Code akzeptiert und ungekehrt der Assembler diese richtig aufloest. Diese speziellen Klimmzuege waeren also nicht notwendig.

Gruß
Kurt

Moin,
ich habe mir den PASCAL-Code einmal genauer angesehen. Es werden global nur 2 Variablen als REAL benutzt. An anderer Stelle kommen noch welche als locale REAL's vor. Vom Zahlenwert her wird sicherlich nie +/-2^31 ueberschritten. Wenn dem so ist, wuerden 32-Bit Variablen ausreichen. Ich vermute einmal (ich habe nicht nachgesehen), dass das verwendetet Pascal keine 32-bit INTEGER kennt, deshalb die REAL's. Fuer die Portierung sind also nur einige zusaetzliche Math-Funktionen zu schreiben, welche die 4 Grundrechenarten in 32-Bit ausfuehren koennen plus convertieren 16-Bit <--> 32-Bit. Den entsprechenden Code habe ich bereits in meiner xgraph-Bibliotek vorliegen - die Elipse geht nur mit 32-Bit Rechnung. Das reduziert alles auf Fleißarbeit plus Copy-und-Paste. Eingedenk der Tatsache, das die Ueberraschung meist im Detail liegt, denke ich, das es machbar ist.


Gruß
Kurt

Moin Bernd,
versuchs mal hier:
https://retrobrewcomputers.org/doku.php ... lerk:start

Unten auf der Seite sind die Download-Links

Gleitkomma-Rechnung:
An soetwas wie "Bruch-Rechnung" hatte ich gedacht. Da fallen mir gleich meine Sünden aus der Grundschule ein...,man war das schwer
Ich will die Hoffnung nicht gleich aufgeben, den sobald Bezug auf Gleitpunktrechnung genomen wird, bauen die Compiler immer gleich alles mögliche aus ihren Bibliotheken in den Code mit ein. Was meist im Ergebnis ein dickes Runtime-Modul und damit ein großes Programm bedeutet. Der von mir verwendete C-Compiler ist recht gut im einbinden von Assembler-Code. Vielleicht kann ich auf dem Wege die Sache klein halten. Das sehe ich aber erst, wenn ich mir dein Programm genauer ansehe. Da ich mein aktuelleas Hardware-Projekt soweit abgeschlossen habe, ist wieder Zeit für was anderes...

Gruß
Kurt

Hallo,
tolle Sache dein HP-GL-Intrpreter. Da habe ich doch gleich einen neuen Projekt-Punkt fuer meine Multicomp xgraph Bibliothek: die Funktionsaufrufe von C nach PASCAL portieren oder besser Dein Programm nach C. Da koennten sich ganz neue Anwendungsmoeglichkeiten ergeben. Da ich aber weder PASCAL noch C Spezialist bin, muss ich mir das noch einmal genauer ansehen. Die Gleikomma-Rechnungen koennten zum Problem werden, der von mir benutzte C-Compiler kann nur Integer16. Vielleicht kann man das entschaerfen...


Gruß
Kurt