Es ist auf jedenfall umständlicher als auf dem PC was mit einem aktuellem Eprom Brenner zu brennen.
Es ist auch einfacher, einen C64-Emulator zu starten, als den C64 einzuschalten. 
Posts by detlef
-
-
Ich frag mich, warum man sich das wirklich antut und mit dem C64 Eproms brennt. Retro hin oder her. Aber da nehme ich lieber den TL866 II oder den Plus. Ich weis noch was das früher immer für ein Krampf war bis ein Eprom gebrannt war! Ne danke... dann lieber was moderne!
Ist halt Retro. Ich käme auch nicht auf die Idee, weil ich das früher auch nicht gemacht habe. Ich hatte sehr früh in der Firma einen Stand-Alone-Programmer zur Verfügung hatte.
Aber wenn ich das früher mit dem C64 gemacht hätte, dann hätte ich bestimmt wieder den gleichen Programmer wie damals und würde auch hin und wieder ein Eprom damit brennen.
-
Ich habe eine ganze Zeit mit einem Tektronix 405x Computer gearbeitet. Den konnten wir in der Schule im Fach Mathematik nutzen. Vektorgrafik-Bildschirm mit sehr langer Nachleuchtzeit – eigentlich jeweils bis zum Löschen des gesamten Screens.
Sowas hattet ihr in der Schule?
-
deinesemikolontasteistkaputt.
-
3D Kino mag ich auch nicht sonderlich, strengt mich unheimlich an.
Ich auch nicht. Bei 3D-Filmen im Kino fehlt mir irgendwie das Kinoerlebnis. Mit der Brille geht das Gefühl der großen Leinwand verloren.
Die ersten 15 Minuten ist das ganz lustig, aber dann nervt es eigentlich nur noch.
-
Ich hatte hier auch zwei USBASP, die beide keine ATMEGA erkennen wollten.
Ich habe mir dann bei ebay einen anderen gekauft, der hat auf Anhieb funktioniert.
Ich hatte irgendwo gelesen, dass ältere USBASP mit neueren Atmels nicht wollen/können. Da hilft wohl auch kein Firmware-Update.
Mit Windows hatte ich jetzt keine Probleme, aber vielleicht habe ich auch Zadig verwendet. Weiss ich nicht mehr, ist schon wieder 10 Monate her.
-
Ich habe hier schon 1982 im Copyshop gestanden und die MOS-6502-Handbücher kopiert.
Zwischen Matrize und Normalpapierkopierer kann ich mich noch dunkel an Nasskopierer (oder so ähnlich?) erinnern,
-
Auf einem Raspi programmiert niemand in COBOL, ja egal, man könnte aber trotzdem?
Nein, ich brauche keine Hochsprache um auf einem "echten Computer"(?) Programme für den C64 umwandeln zu lassen. Es interessiert mich einfach der Machbarkeit wegen.
Und die Machbarkeit ist auf dem C64 eben nicht gegeben.
Du kannst vermutlich auf dem C64 irgendwelchen Quellcode, der wie COBOL aussieht, übersetzen oder starten. Mit einem Programm, das sich möglicherweise COBOL-Compiler nennt. Das hat aber mit dem tatschlichen COBOL, wie es damals eingesetzt wurde, überhaupt nichts zu tun.
Weil die COBOL-Umgebung eben nicht nur die Sprache war. Das COBOL-Feeling wird nicht aufkommen. Also was bringt das dann?
-
joshy Der Tretroller- Vergleich hinkt, wenn hier nur die Geschwindigkeit und Grösse der Massenspeicher bemängelt wird. Und das hat sich am C64 doch extrem verbessert?
Also ist es nicht eher so, das der C64 damals ungeeignet war, jetzt aber wesentlich besser dasteht, wenn es ein modernes COBOL für ihn gäbe, was die neuen Möglichkeiten nutzt?
Was ist denn daran noch Retro, wenn das dann eine SD2IEC oder sonstige Hardwareerweiterungen braucht. Dann kann man das doch gleich auf dem PC oder auf dem Raspi machen.
-
Wenn der Dissassembler eine GUI besitzt fände ich es praktischer die zu bearbeitenden Bereiche z.B. mit der Maus zu markieren anstatt das über Config Files zu realisieren.
Inzwischen sind wir hier ziemlich offtopic. Vielleicht könnte das Thema Disassembler mal ein Mod in einen eigene Thread verschieben?
Also das klappt vermutlich nicht so einfach mit dem Markieren, weil der Anfang der Bereiche oft mitten in einem Mehrbyte-Befehl liegt, solange Daten als Code interpretiert werden. Man muss die Bereiche schon byte-genau angeben können.
Außerdem will man evtl. die Datenbereiche genauer spezifizieren. Soll da ein DB oder ein DW oder ein DW mit Offset generiert werden. Oder will man den ASCII-Code als Kommentar dazu haben. Bei DW ist noch wichtig, ob Code oder Daten-Labels erzeigt werden sollen.
So sieht z.B. bei meinem Disassembler die Konfigurationsdatei aus:
Display MoreCode -
Das PET/C64-Basic macht seine indirekten Sprünge über den Stack. Das habe ich auch in anderen Programmen schon häufiger gesehen. Da muss man sogar noch die Sprungadresse korrigieren, damit sie passt.
Ich habe auch schon über automatische Erkennungen nachgedacht, aber letztendlich wird es bei vielen Programmen dann doch nicht funktionieren.
Vielleicht ist es auch beim Z80 einfacher als beim 6502 - keine Ahnung.
-
Display More
Außerdem finde ich so einen "intelligenten" Disassembler schwerer umzusetzen.
Naja, vollautomatisch wird es wohl auch nicht gehen.
Eine manuelle Nachanalyse wird man wohl immer benötigen.
Ich denke aber das man das Konzept "DATA first" auch so für den Z80 umsetzen kann.
Meiner Meinung nach ist dabei egal ob ein Code viele SystemAdressen anspringt/liest/schreibt oder nicht.
Man muss halt nur wissen wo der Code startet.
Und wie werden die Programmteile gefunden, die nur über Adresstabellen angesprungen werden?
Wenn man so einen Disassembler über das PET-Basic laufen lässt, würden vermutlich 90% des Codes nicht als Programm erkannt.
Bei meinem 6502-Disassmbler kann ich einfach die Programm- und Datenbereich über eine Konfigurationsdatei vorgeben.
Ich mache dann CODE FIRST und schaue dann, an welchen Stelle illegale Opcodes oder Sprünge ins Nirvana stehen. Man sieht dann meist auf einen Blick, wo diese Bereich beginnen und enden. Meistens erkannt man auch gleich, ob es sich um Adressetabellen handelt.
Das wiederhole ich dann so lange, bis keine illegalen Opcodes und keine illegalen Sprungziele mehr vorhanden sind. Das sieht man sehr schön an der Liste der externen Labels. Das ganze dauert dann vielleicht 30 Minuten bei einem 10K großen Programm, aber dafür habe ich in der Zeit auch schon Teile des Programms analysiert.
Das einzeige, was der Assembler automatisch versucht, ist die Erkennung von Unterprogrammen und abgeschlossenen Routinen (anhand der Branches). Da werden dann zur Übersicht automatisch Trennlinien eingezogen.
Ganz übel ist natürlich selbstmodifiziernder Code. Wenn ich sowas sehe, höre ich sofort auf. So ein Mist interessiert mich nicht und wird daher nicht analysiert.
-
ich erkenne es in den XML-Dateien wieder, die heute wohl zu C#-Programmen gehören.
Und in C# schieb ich ein Programm auf den Server, und ohne die zugehörige XML-Datei mit den Einstellungen des Frameworks, Datenbankpfaden usw. läuft da gar nix. Und mit verschiedenen XML-Dateien kann ein Programm z.B. in der Produktiv- oder in der Testumgebung laufen.
Achso, die Konfigurationsdateien meinst du. Ja ist korrekt. Die gibt es.
-
ich erkenne es in den XML-Dateien wieder, die heute wohl zu C#-Programmen gehören.
-
Ich persönlich würde eher zu sowas greifen. https://www.octopus-office.de/…-von-farbbaendern-schwarz
Jo! Da weiss man, was man bekommt, weil man genau weiss, was drin ist. Auch wichtig: die Kompatibilitätsliste.
Da hat jemand eine lukrative Marktlücke entdeckt.
"What is this? Piss with ink!". Wer weiss aus welchem Film das stammt.
-
Ein Lötkolben ist ein Werkzeug. Das darf auch mal so aussehen, als wäre es benutzt worden.
Und auf die Idee, die Lötspitze explizit zu reinigen, bin ich auch noch nicht gekommen. Die wird beim Löten saubergehalten, in dem ich sie regelmäßig am Messingschwamm abstreife.
-
Damit man irgendwie was Programmieren kann?
Das ist das grösste Problem bei neuen CPUs. Kein Compiler... kein Interpreter...
Aber da der Computer, der hier diskutiert wird, niemals gebaut werden wird, braucht man auch keine Programmiersprache.
gleiches gilt uebrigens fuer haemische Kommentare
War jetzt gar nicht hämisch gemeint. Das ist eine Diskussion, wie sich jeder seinen persönlichen Retro-Computer vorstellt.
Das ist doch ok. In dem einen oder anderen Vorschlag findet man sich wieder, in den meisten eher nicht.
Der keineste gemeinsame Nenner liegt gefühlt bei 10 Prozent.
-
Damit man irgendwie was Programmieren kann?
Das ist das grösste Problem bei neuen CPUs. Kein Compiler... kein Interpreter...
Aber da der Computer, der hier diskutiert wird, niemals gebaut werden wird, braucht man auch keine Programmiersprache.
-
Arbeitet von euch denn jemand an der Implementierung einer Programmiersprache z. B. ?
Vermutlich nicht. Wozu auch?
-
Aus dem BASIC können direkt Funktionen des Betriebssystems aufgerufen werden (sog. *-Kommandos).
Es können scheinbar beliebig viele ROMBänke (max. 8 KB pro Bank) eingesteckt/-gebaut werden, von denen (ich glaube) 8 gleichzeitig aktiviert sein können. Diese werden als eine Art Laufwerk angesprochen. Aktivierung und Deaktivierung erfolgt durch einen einfachen Befehl. Gleiches funktioniert auch mit zusätzlichem RAM.
Die Möglichkeit, Maschinensprache direkt in Basic-Programme einzubauen, ist ja weithin bekannt.
Interessant. Du schreibst, du bist kein Programmierer, beschreibst aber in deinem Beitrag fast nur Features die eigentlich nur für Programmierer relevant sind. Bist du sicher, dass die Features auch alle für Programmierer sinnvoll waren und entsprechend genutzt wurden?
EDIT: Ich habe gerade nochmal zum BBC Master gegoogelt. Dazu findet man fast nicht. Nicht mal einen richtigen Wikipedia-Artikel.
