3. Tortoise Git, Dateien und Icons

Tortoise Git, Dateien und Icons

  • *

    @SeppJ sagte in Tortoise Git, Dateien und Icons:

    Aber Pascal braucht ja keine Laufzeitumgebung für Exceptions, RTTI und so, um die volle Sprachdefinition voll umzusetzen, oder? Ist aber auch ewig her, dass ich Pascal gemacht habe, und dann auch nur auf primitivem Niveau, daher verzeiht, wenn ich mich da irre.

    Wenn wir über normales Pascal reden, hast Du sicherlich Recht. Borland hat aber TurboPascal total aufgebohrt und beständig erweitert, so dass das nur noch dem Namen nach Pascal war. Und natürlich wurde von Borland OO-Programmierung in Pascal integriert.

    0

  • Also von mir aus könnt ihr ruhig weitermachen, das Eingangsthema wurde ausreichend behandelt. Wir finden uns damit ab, dass Embarcadero den Ball hat und wir keinen Handstand machen möchen, um die Projektdateien vernünftig zu pflegen.

    Ich hab aufm C64 angefangen Assembler zu programmieren, mit nem symbolischen Assembler, keine Ahnung, wie das Ding hieß. Turbo Assembler oder so? Bei einem Projekt (ich nenn's mal so, war bestimmt ne Spielerei ohne praktischen Nutzen) war der Quelltext dann so lang, dass der Assembler den Output in den Quelltextspeicher geschrieben hat und mir die letzten Zeilen Quelltext überschrieben hat. War dann sehr überrascht, dass der Assembler beim nächsten Übersetzen Fehlermeldungen ausgegeben hat, nachdem ich das Programm gestartet habe. Und beim Angucken des Quellcode- Bereichs standen da lustige PETSCII Zeichen.

    Aufm Amiga hab ich`s mit C probiert, bin aber nie über nen 5 Zeiler hinausgekommen. Hatte ein Erlebnis, das mich traumatisiert hat, und als Jugendlicher hatte man iwann auch andere Interessen, die wenig mit Computern zu tun haben. Im besagten C-Miniprogramm wollte ich ein Fenster öffnen, für 10 Sekunden anzeigen, und dann wieder schließen. Anzeigen hat geklappt, zum Schließen ist es nie gekommen. Viiiiiel später habe ich dann rausgefunden, dass der Aufruf

    Sleep( 10000 ); // hier das Amiga-OS Pendant einsetzen, kA, wie der hieß

    aus der 10000 nen short gemacht hat und die oberen 16bit des 32bit Wertes zufällig waren. Also hat der Sleep länger gedauert als geplant, damit habe ich ein paar Tage gekämpft und es dann sein gelassen. Gab damals noch kein Internet, wo man sowas hätte nachfragen können.

    Hier nochn Video von Jason Turner und nem Hobbyprojekt, wo er mit GCC für nen C64 Pong programmiert hat:
    CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

    PS:
    Hab in der dänischen C64 Datenbank 4 Demos von mir gefunden. Ich wunder mich, wie die dahin gekommen sind, bin aufm Land groß geworden und viel Kontakt außerhalb des Dorfes hatten wir nicht.

    0
    F
    *
     2 Antworten
  • F

    @DocShoe sagte in Tortoise Git, Dateien und Icons:

    Ich hab aufm C64 angefangen Assembler zu programmieren, mit nem symbolischen Assembler, keine Ahnung, wie das Ding hieß. Turbo Assembler oder so? Bei einem Projekt (ich nenn's mal so, war bestimmt ne Spielerei ohne praktischen Nutzen) war der Quelltext dann so lang, dass der Assembler den Output in den Quelltextspeicher geschrieben hat und mir die letzten Zeilen Quelltext überschrieben hat. War dann sehr überrascht, dass der Assembler beim nächsten Übersetzen Fehlermeldungen ausgegeben hat, nachdem ich das Programm gestartet habe. Und beim Angucken des Quellcode- Bereichs standen da lustige PETSCII Zeichen.

    Das ist ein schönes Beispiel dafür, weshalb ich für sowas heute moderne Tools bevorzuge, anstatt mich nochmal an die Original-Hardware zu setzen. Da wäre meine Motivation schnell am Ende 😁

    @DocShoe sagte in Tortoise Git, Dateien und Icons:

    PS:
    Hab in der dänischen C64 Datenbank 4 Demos von mir gefunden. Ich wunder mich, wie die dahin gekommen sind, bin aufm Land groß geworden und viel Kontakt außerhalb des Dorfes hatten wir nicht.

    Ist ja witzig. Ich hab vor ein paar Jahren exakt dasselbe Erlebnis gehabt, und auch ich bin auf dem Land groß geworden 😁

    War ne "Auftragsarbeit" für Leute, die ich von nem BBS damals kannte, mit denen ich mich hin und wieder zu Parties und Netzwerksessions getroffen habe. Ist witzigerweise in Turbo Pascal geschrieben, bzw. genauer etwa 10% Pascal und 90% Inline-Assembler:

    https://www.pouet.net/prod.php?which=75644

    Ist leider ziemlich CPU-lastig, DOSBox muss schon für mindestens nen guten i486 konfiguriert werden 😉

    0
    T
     1 Antwort

  • @Finnegan sagte in Tortoise Git, Dateien und Icons:

    Man merkt, dass du anscheinend nen Amiga hattest.

    Haha, ja, hatte ich. Erst nen A500, dann nen A500+ mit HDD und dann nen A3000. Hab ich aber damals alles wieder verkauft.

    Vor ein paar Jahren hab ich mir nen neu aufgebauten A1200 gekauft. Neues Mainboard, neue 030er + 882 Turbokarte mit Compact-Flash IDE, neuer Flicker-Fixer, neues Gehäuse, neues Netzteil, neue Standardbauteile, new-old-stock Laufwerk - nur Custom Chips, Abschirmblech und Tastatur aus nem originalen A1200.

    Es gibt ja etliche neuere Spiele im Retro-Stil. Vielleicht mal recherchieren, was die so verwenden.

    Pixel-Art Editoren gibt es einige. Unter denen die ich bisher probiert habe bin ich aber noch mit keinem warm geworden. Hab aber auch nicht sehr viel rumprobiert. Und die meisten unterstützen Pallette Grafiken nur so halb. D.h. intern ist alles True-Color, und die eingeschränkte Pallette wird nur mehr oder weniger emuliert.

    Mit genug Motivation und Zeit könnte ich da sicher was brauchbares finden. Aber das was mich wirklich interessiert, ist Code schreiben. Und so konnte ich mich bisher noch nicht ausreichend motivieren. Andrerseits könnte ich natürlich auch einfach ein paar Werte in ein Source-File eintippen und quasi mit Pixel-Schrott testen. Im Endeffekt scheitert es halt wirklich an der Motivation.

    Naja, mal sehen. Falls ich jemals wirklich anfange, werde ich auf jeden Fall berichten.

    0
  • *

    @DocShoe sagte in Tortoise Git, Dateien und Icons:

    Also hat der Sleep länger gedauert als geplant, damit habe ich ein paar Tage gekämpft und es dann sein gelassen. Gab damals noch kein Internet, wo man sowas hätte nachfragen können.

    Ich vermute wegen der Art des Fehlers hast Du den Aztec C Compiler genutzt (int ist 16Bit), der Lattice C interpretierte int als 32bit, so auch das Literal.

    Damals hatte man bestenfalls Zugriff aufs FidoNet, und das war teuer wegen der Telefongebühren. Die Original Dokumentation von Commodore (ROM Kernel Manuals und das DOS Manual) war sehr gut, aber auch nicht so leicht zugänglich wie heute, teuer, und als Schüler waren die komplett englische Dokumentation auch nicht so die leichteste Lektüre. Mittlerweile kann man die Bände im Internet als PDF finden. Wenn man etwas mit dem historischen AmigaOS tun will, sollte man sich die PDFs besorgen.

    Ich hatte mit GFA Basic angefangen, da war der Erfolg sehr viel schneller zu erreichen. Später habe ich dann Oberon-2 (A+L Compiler) genutzt, da man damit direkt auf die OS Funktionen zugreifen konnte. C und C++ kam dann später unter UNIX.

    Ordentliche Debugger gab es damals schon, nur musste man fürs professionelle Debuggen einen zweiten Computer nutzen, um über den seriellen Port den post mortem Debugger aufrufen zu können. Wer hatte das als Schüler?

    Ich glaube die Jungen wissen gar nicht wie privilegiert sie sind, mit solche moderner Hardware und Software Programme schreiben zu können. Ein Raspberry 1 ist soviel besser in allem was damals eine Home Computer einem bieten konnte.

    0
    J
     2 Antworten
  • Mod

    @john-0 sagte in Tortoise Git, Dateien und Icons:

    Ich glaube die Jungen wissen gar nicht wie privilegiert sie sind, mit solche moderner Hardware und Software Programme schreiben zu können. Ein Raspberry 1 ist soviel besser in allem was damals eine Home Computer einem bieten konnte.

    Aber da lernte man noch, wie ein Computer wirklich funktioniert! [/alterMann]

    0
  • J

    @john-0 sagte in Tortoise Git, Dateien und Icons:

    Die Original Dokumentation von Commodore (ROM Kernel Manuals ...) war sehr gut, aber auch nicht so leicht zugänglich wie heute

    Beim C64 gab es diese noch im kostenlos mitgeliefertem "Benutzerhandbuch".

    0
    *
     1 Antwort
  • *

    @Jockelx sagte in Tortoise Git, Dateien und Icons:

    @john-0 sagte in Tortoise Git, Dateien und Icons:

    Die Original Dokumentation von Commodore (ROM Kernel Manuals ...) war sehr gut, aber auch nicht so leicht zugänglich wie heute

    Beim C64 gab es diese noch im kostenlos mitgeliefertem "Benutzerhandbuch".

    Keine Ahnung wie das beim C64 aussah, ich hatte nie einen. In Deutschland war jedenfalls das Buch „64 Intern“ von Data Becker sehr beliebt. Und beim C128 gab es schon die Commodore Bücher von Bantam. Die ROM Kernels sind dann bei Addison-Wesley erschienen, und nur noch das DOS Manual bei Bantam.

    Beim Amiga wurde am Anfang ein Handbuch für den Computer mitgeliefert, das sich grob in den Aufbau und die Inbetriebnahme, eine kurze Einführung in das GUI und eine kurze Referenz des OS und des DOS aufteilte. Dann gab es noch das AmigaBASIC Handbuch. Man konnte also gleich mit BASIC loslegen und einfache Programme schreiben.

    Das Update auf 1.3 war einfach nur ein neues ROM und Disketten. Es hatte sich ja sehr wenig geändert. Beim Update auf AmigaOS 2.0 gab es zwei Ringbücher mit umfangreicher Dokumentation, aber zum Programmieren gab es nur die Dokumentation von ARexx. Amiga BASIC war beerdigt worden, weil Commodore keine Lizenz mehr von Microsoft mehr kaufen wollte, und das alte wegen Inkompatibilitäten nicht mehr richtig lief.

    @SeppJ
    Dazu passt folgender Link Thema FORTRAN II.

    0 2 Antworten
  • Mod

    @john-0 sagte in Tortoise Git, Dateien und Icons:

    @SeppJ
    Dazu passt folgender Link Thema FORTRAN II.

    Das ist noch richtige Programmierung 👍

    0
    *
     1 Antwort

  • @john-0 sagte in Tortoise Git, Dateien und Icons:

    Keine Ahnung wie das beim C64 aussah

    s. Bedienungshandbuch Commodore 64 bzw. ganz als PDF: C64 Bedienungshandbuch (deutsch)

    Die "ROM Kernel Reference Manual"-Bücher für den Amiga hatte ich auch (von einem Bekannten geschenkt bekommen), sie enthielten hauptsächlich eine Beschreibung aller Kernel Library-Funktionen (Exec, DOS, Intuition, ...) sowie viele Beispiele in C.
    Eine Auswahl davon habe ich unter Commodore Amiga Documentation gefunden.

    Mir hat damals am meisten Amiga ROM Kernal Reference Manual: Libraries and Devices gefallen (ich meine, ich hatte damals 5 verschiedene).

    0
    *
     1 Antwort
  • *

    @Th69 sagte in Tortoise Git, Dateien und Icons:

    Eine Auswahl davon habe ich unter Commodore Amiga Documentation gefunden.

    Es gibt deutlich mehr
    Die offizielle Developer Dokumentation für AmigaOS 1.1
    Amiga Intuition Reference Manual, ISBN 0-201-11076-8
    Amiga Hardware Reference Manual, ISBN 0-201-11077-6 (leider nur zum Ausleihen)
    Amiga ROM Kernel Reference Manual: Libraries & Devices, ISBN 0-201-11078-4
    Amiga ROM Kernel Reference Manual: Exec, ISBN 0-201-11099-7
    The AmigaDOS Manual, ISBN 0-553-34294-0

    Die offizielle Developer Dokumentation für AmigaOS 1.2/1.3
    Amiga ROM Kernel Reference, Libraries and Devices, 2nd Ed., ISBN 0-201-18187-8
    Amiga ROM Kernel Reference Includes and Autodocs, 2nd Ed., ISBN 0-201-18177-0
    Amiga Hardware Reference Manual, 2nd Ed., ISBN 0-201-18157-6
    The AmigaDOS Manual, 2nd Ed., ISBN 0-553-3440-4

    Die offizielle Developer Dokumentation für AmigaOS 2.0
    Amiga ROM Kernel Reference, Includes and Autodocs, 3rd Ed., ISBN 0-201-56773-3
    Amiga ROM Kernel Reference, Libraries, 3rd Ed., ISBN 0-201-56774-1
    Amiga ROM Kernel Reference, Devices, 3rd Ed., ISBN 0-201-56775-X
    Amiga Hardware Reference Manual, 3rd Ed., ISBN 0-201-56776-8
    Amiga User Interface Style Guide, ISBN 0-201-57757-7
    The AmigaDOS Manual. 3rd Ed., ISBN 0-553-35403-5

    Dann als Ergänzung von Enthusiasten (AmigaOS 3.1/3.2)
    ROM Kernel Reference Manual, Changes and Additions

    0
  • *

    @SeppJ sagte in Tortoise Git, Dateien und Icons:

    Das ist noch richtige Programmierung 👍

    Lange leben die COMMON und DATA Blöcke.

    0
  • T

    @Finnegan sagte in Tortoise Git, Dateien und Icons:

    @DocShoe sagte in Tortoise Git, Dateien und Icons:

    Ich hab aufm C64 angefangen Assembler zu programmieren, mit nem symbolischen Assembler, keine Ahnung, wie das Ding hieß. Turbo Assembler oder so? Bei einem Projekt (ich nenn's mal so, war bestimmt ne Spielerei ohne praktischen Nutzen) war der Quelltext dann so lang, dass der Assembler den Output in den Quelltextspeicher geschrieben hat und mir die letzten Zeilen Quelltext überschrieben hat. War dann sehr überrascht, dass der Assembler beim nächsten Übersetzen Fehlermeldungen ausgegeben hat, nachdem ich das Programm gestartet habe. Und beim Angucken des Quellcode- Bereichs standen da lustige PETSCII Zeichen.

    Das ist ein schönes Beispiel dafür, weshalb ich für sowas heute moderne Tools bevorzuge, anstatt mich nochmal an die Original-Hardware zu setzen. Da wäre meine Motivation schnell am Ende 😁

    Auch damals wurde schon gerne auf besseren Rechnern für Homecomputer entwickelt.

    0
    F
     1 Antwort
  • F

    @Tyrdal sagte in Tortoise Git, Dateien und Icons:

    Auch damals wurde schon gerne auf besseren Rechnern für Homecomputer entwickelt.

    Ich meine mich vage erinnern zu können, dass damals Doom oder Quake auf NeXTSTEP-Systemen entwickelt wurde.

    0
  • F

    @hustbaer sagte in Tortoise Git, Dateien und Icons:

    Probier nochmal puts statt printf. Ich würde mich nicht wundern wenn's damit nochmal kleiner wird.

    Ich meine mich zu erinnern dass der Hauptgrund warum Echsen von Miniprogrammen mit modernen Compilern so gross werden der ist, dass es da kreuz und quer Dependencies beim ganzen IO Zeugs gibt, inklusive Locale Support. Ich vermute dass man das besser entkoppeln könnte, wenn man gezielt auf kleine Programme optimieren will. Nur dass zahlt sich bei Runtime Libs für moderne Compiler halt kaum aus mMn. - und daher wundert es mich nicht dass ein "Hello World" Programm vergleichbar riesig wird.

    Das ist jetzt hoffentlich noch kein "Nekroposting", aber ich habe gerade wieder etwas an meinem Hobbyprojekt gearbeitet, und ein printf-basiertes "Hallo Welt" mittlerweile auf 13.440 Bytes herunter bekommen.

    Das beinhaltet:

    • Loader mit etwa 4KiB: Speicher detektieren über BIOS Memory Map, simpler Allocator für "Prozesspeicher" der vom BIOS reservierte Bereiche berücksichtigt, Interrupt Thunks für transparente Verwendung von INT-Instruktionen zu Real Mode Interrupts aus dem Protected Mode und umgekehrt, Programm-Argumente parsen und argv-Array erzeugen, Implementation OS-spezifischer Funktionen für die (pico)libc (sbrk, open, close, read, write, getenv, etc.), Protected Mode Setup und Laden des Hauptprogramms (vom Linker-Skript an die 16-bit DOS .exe "angehängt") in erweiterten Speicher.
    • Stack Unwinder der libgcc für C++ Exception Handling.
    • malloc- und printf-Implementierungen der (pico)libc.
    • das eigentliche "Hallo Welt"-Programm

    Dafür sind knapp 13 KiB echt okay finde ich 😉

    Mit <iostreams> in Form von std::cout oder std::println sind es dann etwa 650 KiB (war vorher doppelt so viel), weil wie du richtig schreibst, eine Menge Funktionen und Objekte mit herein gezogen werden, auch wenn sie nicht benötigt werden. Da sind dann z.B. so Funktionen drin wie (mal willkürlich ein paar aus der Linker map herauskopiert):

    • Klassen wie std::__cxx11::time_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > mit ihren Daten- und Funktions-Membern in verschiedensten Spezialisierungen (Template-Bloat?).
    • std::num_get<char, std::istreambuf_iterator<char, std::char_traits<char> >
    • std::money_get<char, std::istreambuf_iterator<char, std::char_traits<char> >
    • std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >

    Und das, obwohl ich nur einen fixen String ausgebe (das da oben sind ja alles Input-Funktionen).

    Ich habe den Verdacht, dass sich std::format eventuell besser entkoppeln lässt. Das ist nicht auf <iostreams> angewiesen und kann auch in einen std::output_iterator (Concept) ausgeben. Ich werde damit mal was experimentieren. Vielleicht sind Ranges und std::output_iterator-Objekte ja eine gute Alternative, wenn man "leichtgewichtige Streams" benötigt. Eine Klasse, die das Konzept erfüllt, ließe sich recht leicht für die Standardausgabe implementieren und ein eigenes println ist dank std::format_to dann auch ein Kinderspiel.

    Eine vielleicht interessante Erkenntnis hab ich noch gemacht, was die Größe der Binary aus C++-Code angeht: Exception- und RTTI-Informationen aus statischen Bibliotheken können durchaus auch mit -fno-exceptions und -fno-rtti noch in der Binary landen, wenn die Bibliothek selbst nicht ebenfalls mit diesen Flags kompiliert wurde. Ich habe daher Multilib-Kombinationen der Runtimes für diese gebaut (libstdc++ und mein Loader), die dann gelinkt werden, wenn die Binary mit diesen Flags gebaut wird. Das war letztendlich der Durchbruch, um das printf-"Hallo Welt" von über 200KiB auf die jetzige Größe zu bringen.

    Auch habe ich -ffunction-sections und -fdata-sections sowie -Wl,--gc-sections fest in der Toolchain verdrahtet. Damit erzeugt der Compiler für jede Funktion und jedes Objekt eine eigene Section in der Objektdatei, da der Linker (ohne LTO) nur ganze Sections verwerfen kann, wenn diese nicht referenziert werden. Compiler Flags wie -fvtable-gc helfen auch beim eliminieren nicht-verwendeter virtueller Funktionen und Konfigurations-Flags für die libstdc++ wie --disable-libstdcxx-verbose. Letzteres führt zu weniger ausführlichen Fehlermeldungen der Standardbibliothek (kürzere Strings) und (sehr wichtig) dass kein C++-Demangler dazu gelinkt wird.

    Wie ich schonmal erwähnte, sobald ich die Kanten alle abgeschliffen hab, werd' ich das mal für Fans der Retroprogrammierung veröffentlichen. Idee ist, dass man modernes C++ hat und direkt mit den "coolen" Sachen wie Mode 13h loslegen kann, ohne sich mit dem ätzenden Kram wie Real-Mode Speichersegmentierung und anderen Details auseinandersetzen zu müssen 😉

    0
Anmelden zum Antworten