Posts by Bytebreaker

Der CPC war schon ziemlich toll. Meilenweit dem C64 überlegenes Basic, Text und Grafik zugleich möglich ohen Tricks und Einschränkungen, höhere Auflösung bei mehr Farben ohne 8x8 Kachel-Grenzen für das Färben von Bereichen, größere Farbpalette, 80 Zeichen-Editor schon 1984 mit dem CPC 464. Und CPM-fähig noch vor dem C128. Und demoszene-mäßig halt auch ziemlich schicke Titel dabei (vgl. "Batman Group"). Er hatte halt keine Sprites. und weil Home Computer in Wahrheit Spielkonsolen waren und keine Arbeitsrechner, hat er eben gegenüber dem Cevi den Kürzeren gezogen. Zum Arbeiten für den Hausgebrauch war es aber DAS Gerät.

Der C64 ist auch bei mir der wichtigste Rechner geworden, wichtiger noch als mein Amiga. Aber der CPC rockt schon ziemlich, wenn man die C64-Fanboy-Brille mal einen Moment abnimmt.

@Telespielator

Will nicht Haare spalten, hab mich evtl. auch nur unglücklich ausgedrückt. Ich schrieb „kommerziell erfolgreich keinen Automat nur für ein Spiel“. In Wiki steht „kommerzieller Durchbruch“ des Konzepts durch dem Atari 2600. Das Konzept hat Atari aber nicht erfunden, sondern Magnavox und Fairchild.

Für mich war die Odyssey irgendwie noch keine echte Spielkonsole, aber ein Meilenstein und zuerst da war sie trotzdem.

@Telespielator

Die Magnavox Odyssey ist echt ein Sonderfall, dem ich schlecht widersprechen kann.

Bezogen auf Arcade-Spiele im herkömmlichen Sinn würde ich mich an die Wikipedia-Aussage halten, dass man hier erstmals kommerziell erfolgreich keinen Automat nur für ein Spiel gebaut hat, sondern einen Automat für alle möglichen neu erschaffbaren Spiele. Und als Home Computer zählt der 2600 nur durch die Erweiterbarkeit um Tastatur und Basic Modul.

Wobei auf der anderen Seite ich behaupten würde, dass so gut wie alle Home Computer primär wie Spielekonsolen behandelt wurden.

Also ich schließe mich der Atari 2600 Fraktion an. Die VCS Konsole war sehr anspruchsvoll zu programmieren. Nur 128 Bytes (!) RAM und man war gezwungen mit seinem Code immer hinter dem Rasterstrahl zu bleiben. Aus dieser Warte sind Spiele wie Pitfall richtiges Coder-Gehirnmuskelgeprotze, das Respekt ausgelöst hat bei allen die die Materie verstehen. Die CPU war ja gut und mit 1.1 MHz auch nicht langsam. Die Peripherie drumherum war die große Herausforderung. Außerdem hat man mit dem 2600 erstmals Hardware nicht extra für ein einzelnes Spiel gemacht sondern eine Hardware für alle möglichen Spiele.

Da fällt mir zudem noch etwas ein, wo wir es vom Thema Uhren hatten: im Pforzheimer Technikmuseum steht ein Apparat, da hängt man bis zu 8 Quarz Armbanduhren in so Halterungen. Diese drehen sich dann um verschiedene Achsen, dabei wird die Stetigkeit des Quarz Taktes gemessen um zu wissen, ob die Uhren auch bei ständiger Bewegung um alle Achsen genau gehen. Das Ergebnis wird als Protokoll auf Endlospapier gedruckt. Das Gerät kommt aus den 60er Jahren.

Ich finde das nicht primitiv sondern bewundernswert.

Oder man nehme (auch wenn es jetzt kein wirklich schönes Thema ist), die Evolution der Computer durchs Militär. Es gab schon im 2. Weltkrieg Feuerleitrechner und die Seeschlacht von Midway fand erstmals erfolgreich jenseits der Sichtweite statt. Man denke auch an die Enigma Maschine, die sogar einen noch besseren Nachfolger hatte, der aber nie in große Serie ging.

Primitiv ist auch das für mich nicht. Müsste ich das alles lernen wäre es intellektuell so schwer wie ein Studium von heute, nur eben mit anderen Inhalten und Wissensständen.

Ich habe in der aktuellen Amiga Future einen Testbericht zur aktuellen Amiga/C64 Forever verfasst, mich am Rande auch auf das Lizenzthema bezogen, aber eine positive Kritik geschrieben.

Vor 2 Jahren hielt ich Cloanto ebenfalls für Bloatware, aber man muss auch schauen was es kann, was es kostet und für wen es gedacht ist. Die meisten Foristen hier dürften komplett eigene selbstorganisierte Emulations-, Dateiablage- und Entwicklungsumgebungen haben, ganz zu schweigen von der obligatorischen Echt-Hardware. Da wirkt die Cloanto-Software wie eine intellektuelle Beleidigung für Retro-Szener.

Aber „wir“ sind gar nicht die Zielgruppe. Zielgruppe sind Leute mit Null Ahnung, aber eben doch Interesse an der alten Welt. Für 10 Euro einen komplett vorkonfigurierten Einstieg bieten mit hoher Peripheriegerätekompatibilität, vorinstallierten Systemen und Spielen und einer eigenen Datenbank die man selbst erweitern und pflegen kann, das ist ok. Hinzu kommen noch Komfortfunktionen die nur Cloanto hat (virtuelle Original-Keyboards, noch einfachere USB-Joystick-Anbindung). Nach der Logik müsste man auch schlecht über Amikit denken und auch das kostet 10 Euro und verdient den Preis.

Irgendwann werden einige Anfänger, die mit Cloanto eingestiegen sind, sich emanzipieren und es nicht mehr brauchen. Darüber in die Retro Szene gekommen zu sein war dann aber doch etwas Gutes.

@atomcode

Danke für dein Feedback. Ich möchte Dich dann aber bitten die Skript-Version aus Eintrag 8 dieses Threads zu nehmen oder die aktualisierte Standalone-Exe in Eintrag 5.

Hier werden die letzten 1-16 Datas des Streams nämlich ordentlich in eine Zeile gepackt statt jeweils 1 Wert pro Data-Zeile. Außerdem ist ein Bug in der ausgegeben Hex-Darstellung behoben bei Ladeaddressen < $1000.

Diese Version ist zudem noch nicht nach Python 3 übersetzt und es wäre mir eine Ehre wenn du kurz prüfen würdest ob das Umbauen der letzten Data-Zeile Python-3 konform ist und diesen Abschnitt ggf. anpasst.

Edit:

Wenn du magst nehme ich dann die finalen py2, py3 und Standalone Versionen, lade sie auf csdb und packe Dich in die Credits.

Hier

Basic und Maschinensprache mit C64 Studio

Heißt es:

Quote from Endurion

C64Studio kann in einem Projekt beliebige Files verwalten; kompiliert werden kann davon aber jeweils immer nur ein Hauptfile; sonst das aktuell fokussierte.

Bezüglich Data-Zeilen. (Leider nur) über das Menü kannst du einen Binär-Editor aufmachen: File->New->Binary Editor. Dort kannst du binäre Dateien öffnen bzw. in verschiedene Formate umwandeln. Auf dem zweiten Reiter kannst du mit To/From BASIC oder ASM in die jeweilige Richtung im- bzw. exportieren. Ist alles etwas rudimentär, die BASIC-Unterstützung ist bei weitem nicht so ausgereift wie die Assembler-Unterstützung.

Dieser Stand ist 4 Jahre alt da hat sich sicher was getan.

Wobei laut Entwickler-Website

http://www.georg-rottensteiner.de/de/index.html

ist in der Feature-Liste bis nicht von Basic DATA die Rede. Ist ja auch mehr was für Assemblanten das Ganze.

@atomcode

Ich nutze bisher acme (und sehr wenig ca65). Hätte ich C64 Studio in Benutzung und DATA Support wäre eingebaut, wäre ich wohl nie auf die Idee gekommen diese Python-Übung zu machen.

Möglichkeiten, DATA zu generieren gibt es ja wie Sand am Meer.

Es geht ja nicht immer nur darum etwas zu machen was es vorher nicht gab sondern man lebt sein Hobby aus und macht als Nebeneffekt etwas das sich sogar benutzen lässt.

Tolle Arbeit, Will!

Aus Abwärtskompatibilitätsgründen habe ich noch immer ein Win32 Python 2.7 auf einem 64Bit Windows 10. pip meldet mir immerzu dass ab Januar 2020 Schluss ist mit Python 2.7 Support.

Ich muss früher oder später Python 3 lernen.

Jens Schönfeld ist einerseits dafür bekannt, gute Hardware zu entwickeln, andererseits soll er selbst versucht haben, eine Art Monopolist zu werden und hat wohl auch unfreundliches und hartes Geschäftsgebaren gezeigt. Zumindest Hörensagen.

Ich bin beim Amiga nur noch Zuschauer und hoffe, dass die c64 Szene frei, unabhängig und vor allem preiswert bleibt.

Es klappt sogar, echte Basic-Programme die ab $0801 starten, in DATAs zu wandeln und dann nach Copy Paste in VICE mit einer Poke-Schleife ab 2049 zu laden und zu starten. Im Basic-Speicher steht dann das Listing.

Absurd und sinnlos, aber macht Spaß.

So, kleines Update:

In Eintrag 5 findet ihr unter dem bestehenden Link die aktualisierte Version des Dataliners als pyhon-unabhängige Windows-Exe. Allerdings muss das zu data-isierende PRG nach wie vor entweder im gleichen Ordner vorliegen in dem die Exe mit den 2 Zusatzdateien ist oder der Order mit dem Dataliner ist in der Windows Path Variable registriert.

Die jetzige Version schreibt bis zum Ende Datas hintereinander und bricht in jeder Zeile vor dem 80. Zeichen um, auch die letzten 1 bis 16 Werte.
Außerdem wurde ein kleiner Bug in der Hexdarstellung entfernt bei Ladeadressen < $1000. Die Mindestgröße bleibt 19 Bytes. Für 19 bytes und weniger brauche ich keinen DATA-Konverter.

Die Python-Skriptversion hänge ich hier spaßeshalber an. Ich benutze selbst aber nur noch die Windows-exe.

Quote from Kongo-Otto

Aber warum muss die Datei mindestens 19 Byte groß sein?

Das liegt an der Art, wie ich den Datenstrom in je 16 kommagetrennte DATA-Werte pro Zeile aufteile.

Das Skript setzt zwingend voraus, dass es von Anfang an ab jeder 16. Stelle etwas zu trennen gibt und will mindestens einmal eine zweite Zeile mit mindestens einem Wert geschrieben haben. Das wären 16+1=17. 19, weil das Skript immer die ersten 2 Bytes des Datenstroms herausrechnet, weil unterstellt wird, dass dort die Ladeadresse steht, die man in der DATA-Zeile ja nicht braucht. Das Skript will also haben, dass unter Abzug von 2 Bytes mindestens 17 übrig sind, 16 für die erste Zeile und mindestens 1 Wert für die zweite. Heißt in Summe 19 Bytes. Das Skript fragt vorher die Dateigröße ab und meckert auch, wenn man zu wenig Parameter übergibt.

Sicherlich kann man auch so programmieren, dass nur Programme ab 3 Bytes Größe verarbeitet werden. Auch die allerletzten DATAs, die nicht mit 16 aufgehen, stehen als Einzelwerte untereinander statt in einer Zeile. Auch das geht schöner.

Für meinen persönlichen Hausgebrauch reicht es aber und es arbeitet korrekt. Sogar mit einer 7 MB großen Excel-Datei. Da hat er dann eben ein 38 MB großes Textfile erzeugt.

Diese beiden Themen (Datei-Mindestgröße und letzte Datazeile schön machen) sind auf jeden Fall ein Thema für einen Regentag wo ich Stoff zum Knobeln haben will. Wenn es eine neue Version geben sollte, lade ich sie hier hoch.

Den Dataliner gibt es jetzt auch als 32 Bit Kommandozeilen-exe für Windows, ohne dass man dazu Python installiert haben muss.

Einfach entpacken und dafür sorgen, dass der Ordner mit der dataliner.exe und den 2 Zusatzdateien in der Windows Path-Variable registriert ist. Dann kann man dataliner.exe von jedem Ort im Dateisystem aus per Kommandozeile aufrufen.

Dataliner Downloadlink

Der Dataliner frisst alle Binaries, auch Word-Dateien. Hab es spaßeshalber mal probiert.

Quote from oobdoo

Wofür braucht man heute noch Datazeilen?

Wofür beschäftigt man sich heute noch mit dem C64. Oder gar dem CPC?

Edit:
Es war hauptsächlich eine Programmierübung für Python. Ich hätte es auch in C64 Basic oder Assembler machen können. Als Basic-Coder nutze ich außerdem gern Assembler-Schnipsel aus Basic heraus um Dinge schneller zu erreichen, z.B. Linien ziehen auf einer HiRes Bitmap und die Parameterübergabe kommt über Basic.

Ich möchte denen, die es interessieren könnte, den Python Dataliner von mir kurz vorstellen.

- In Windows Kommandozeile zu verwenden
- Python.exe sollte in der Path-Umgebungsvariable stehen

Syntax:

python dataliner.py programm.prg data.txt 9000

programm.prg = die in DATAS zu zerlegende Binärdatei (ggf. "/"-getrennte Pfadangabe voranstellen, z.B. z:/dateien/programm.prg)
Das PRG muss ein C64 Assemblerprogramm ohne Basic-Header sein, welches in den ersten zwei Bytes die Startaddresse enthält.

data.txt = Die zu erstellende Textdatei mit fertigen DATAs ((ggf. "/"-getrennte Pfadangabe voranstellen, z.B. z:/dateien/data.txt)
9000 = Beginn der DATA-Zeilennummern. Es wird in 1er Schritten hochgezählt

Es wird im ausführenden Verzeichnis eine temporäre Datei output.txt angelegt und nach Gebrauch wieder gelöscht. Sie enthält das Ergebnis der Wandlung von Binär-Bytes nach dezimale ASCII-Zeichen.

Die zu scannende Binärdatei muss mindestens 19 Bytes groß sein. Die DATAs werden zu je 16 in eine DATA-Zeile gepackt.
Die Addressbytes ganz am Anfang werden nicht in die DATAs übernommen.
Es wird aber dem Anwender ausgegeben wo das Programm normalerweise am C64 starten würde und wie man seine For Next Einleseschleife dann in C64 Basic setzen muss.
Der DATA-Rest < 16 Werte wird momentan als eine DATA-Zeile pro Wert genieriert. Diese kosmetische Sache behebe ich später noch. Natürlich wird sich auch der Code optimieren lassen.

P.S.: Das xeyes-Programm kann man mit sys 49152 starten. In VICE Alt-Q nicht vergessen um die Maus zu aktivieren.

P.S. 2: Ich dachte ich antworte hier auf meinen vorherigen Thread zum Thema "Hilfe! Poken von Opcodes ins RAM führt zu nichts". Der neue Thread ist ein Versehen, ein Mod kann gerne diesen Eintrag zusammenführen, wenn möglich.

@syshack

Danke für den Link.
Ich habe bereits einen DATA-Zeilengenerator fertig, und zwar in .... Python!

Der hat noch kleine Bugs drin, aber er macht zu 99% schon jetzt das Richtige. Man braucht nur eine C64 PRG-Datei ohne Basic Header im Dateisystem von Windows oder wo auch immer Pythoncode laufen kann. Man kann dem Programm übergeben ab welcher Basic-Zeilennummer er starten soll, liest das PRG binär byteweise aus, schreibt pro Byte kommagetrennte Integerwerte in immer neue DATA-Zeilen in ein Textdokument und packt immer 16 Werte in eine Zeile, den nicht mit 16 aufgehenden Rest mit einem Wert pro Zeile (das kriegt man aber auch irgendwie in eine Zeile rein).

Ich kann dann copy paste in VICE machen aus dem Texteditor heraus.

Die Geschichte in Post 1 ist eine Trockenübung gewesen, z.B. damit ich weiß, dass wenn der Code 6 Bytes fasst, das Einlesen bei 49152 beginnt und bei 49152+5 endet und nicht +6. Das ist zwar einfache Arithmetik, aber in meinem Fall ständige Quelle von Flüchtigkeitsfehlern.

@SamW

Erledigt. Ordnung muss sein.

Als Data-Import heißt es dann:

1 for i=49152 to 49152+5
2 read p:poke i,p:next
3 sys 49152

100 data 169,1,141,0,4,96

run

Ich habe es jetzt gemacht und wenn man poked wie in Post 1 schreibt er ein „A oben links auf den Screen.

Das heißt, so wie man es aufsteigend aus dem RAM liest kann man es auch genau so poken.

@syshack

Danke, gefixt in Post 1.
Es steht immer noch die falsche hi lo folge, an die setze ich mich Mittags hin wenn ich Pause habe.