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.
-
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.
-
@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
-
@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.
-
@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.
-
@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]
-
@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".
-
@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.
-
@john-0 sagte in Tortoise Git, Dateien und Icons:
@SeppJ
Dazu passt folgender Link Thema FORTRAN II.Das ist noch richtige Programmierung
-
@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).
-
@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-0Die 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-4Die 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-5Dann als Ergänzung von Enthusiasten (AmigaOS 3.1/3.2)
ROM Kernel Reference Manual, Changes and Additions
-
@SeppJ sagte in Tortoise Git, Dateien und Icons:
Das ist noch richtige Programmierung
Lange leben die COMMON und DATA Blöcke.
-
@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.
-
@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.
