Posts by Korodny

    Ich würde eine einheitliche - schwarze - Schachtel mit Stülpdeckel suchen, die ungefähr deine gewünschten Maße hat. Anstatt sie zu bekleben, oder jede Schachtel einzeln bedrucken zu lassen, machst du einfach pro Spiel einen maßgeschneiderten "Überzieher", wie ihn diverse Publisher damals schon genutzt haben: Aus dünnem Karton oder dicken Papier wird eine "Hülle" gebastelt, die sämtliche Spiel-spezifischen Drucke aufnimmt und von oben über die eigentliche (schwarze) Spiele-Box drüber gezogen wird.


    Mit ein bisschen herumprobieren sollte sich ermitteln lassen, wie man eine solche Hülle am besten druckt und zusammenklebt - und wie eng sie sein muss, damit sie sicher sitzt. Erstellen kann man die Hülle auf dem heimischen Drucker, weil ja nur vergleichsweise dünnes Material bedruckt wird.

    Das ist die kleinste Übrung :D

    Danke. Ich hab HANSE2.TXT mal kurz überflogen:


    Ist ein bisschen schwer lesbar, weil beinahe alle Zeichenketten, die das Programm ausgibt, nicht Bestandteil des BASIC-Codes sind sondern beim Programmstart aus der Datei "d" gelesen werden. Andererseits vereinfacht das natürlich die Übersetzung erheblich, weil (fast) nur der Inhalt von "d" übersetzt werden muss. Kannst du die Datei mal noch extrahieren und anhängen?


    Mehr als die Hälfte der Zeilen ist deutlich länger als 80 Zeichen, das müsste man auf mehrere Zeilen aufteilen. Ist aber lediglich Fleißarbeit: die Zeilennummern sind schön im 10er-Abstand.


    Der Rest des Codes scheint - abgesehen vom Zeichnen der Landkarte - eigentlich ziemlich gut verwendbar. Locate, CLS und diverse Befehle für Farbänderungen müsste man anpassen, manchmal ist die Syntax etwas anders (Open, Input#), aber im Großen und Ganzen ist das gut machbar, meine ich. Sind weniger als 500 Zeilen Code, das Meiste nur Wertzuweisungen, FOR-Schleifen, IF-Abfragen - das kann man unverändert weiter übernehmen.


    Das Zeichnen der Landkarte würde ich sowieso irgendwie optimieren wollen, das ist aktuell ja (auf dem C64) ziemlich grauenhaft gelöst.

    Naja, bei einem BASIC-Projekt könnten ja viele Leute mithelfen, das ist ja nicht umsonst eine Einsteigersprache. Ob jemand jetzt Texte übersetzt, Code optimiert oder die Spielmechanik analysiert und ggfs. verbessert, kann dann ja jeder für sich entscheiden.


    Wenn jemand den BASIC-Source der CPC-Version nach ASCII konvertieren und hier zur Verfügung stellen kann, wäre das doch schon mal ein Anfang. Selbst wenn nie was daraus wird, wäre das sicher interessante Lektüre.

    Oh, die Frage hatte ich ganz übersehen: Ja, die D44X sind sehr weich und leise, trotzdem noch ein klar definierter (und hörbarer) Druckpunkt. Speziell im Vergleich zu dem Zeug, was in einem Competition ursprünglich verbaut war, sind die himmlisch - noch weicher brauchst du m.E. auf keinen Fall zu suchen. Ich lasse den rechten Feuerknopf in meinen Competitions immer original - weil ich den eh nie benutze - habe also den direkten Vergleich: rechts brauche ich ein Vielfaches der Kraft zum "feuern" und der Schalter löst locker drei mal so laut aus wie der von ZF.

    Eine Frage. Hat jemand von euch noch einen guten Link zu Cherry D44X Mikroschaltern, bei dem der Versand nicht mehr kostet als die Schalter selbst?

    Cherry wurde von ZF übernommen. Die haben Cherry dann wieder abgestoßen, aber große Teile des Schaltergeschäfts (außerhalb von Computertastaturen) behalten. Deswegen sind "Cherry D44x" jetzt eigentlich "ZF D44x" - wenn irgendwo noch "Cherry" angeboten wird, sind das entweder Restposten oder der Verkäufer hat seine Produktbeschreibung noch nicht aktualisiert.


    Also geh mal noch nach ZF d44x suchen. Meine letzten Käufe sind schon etwas her, deswegen kann ich nicht mit aktuellen Links dienen.

    Mal eine C64 BBS ausprobieren? Sind halt eigentlich für Farbe ausgelegt - keine Ahnung, was ein PET mit den Farbcodes in PETSCII macht. Dafür aber immerhin 40 Zeichen. Laut Commodore BBS Outpost sind "Borderline" und "Cottonwood" auch per Modem erreichbar (Achtung - Auslandsgespräch...).


    Wo hast du denn die deutschen Boxen gefunden? Gibt's da irgendwo eine Übersicht, oder hast du einfach im Netz nach Nummern gesucht?

    Wollte auch gerade ein altes Smartphone vorschlagen...."Altes Smartphone als digitaler Bilderrahmen" ist ja ein eher gängiger "Hack", weswegen ich davon ausgehe dass auch problemlos Apps für diesen Anwendungsfall zu finden sind. Wenn noch ein Smartphone herumliegt, dass einen externen Bildschirm ansteuern kann, dürfte das die einfachste Möglichkeit sein.

    Aquabyss ist 2018 mit einem Mords Teaser-Video angekündigt worden. Bis heute gibt es keine Bilder oder Videos vom eigentlichen Spiel - der Hauptentwickler hat aber letzten November schon mal bei a1k angefragt ob man zu Weihnachten 2020 das unfertige Spiel verkaufen soll.


    Ein zweites Projekt zu starten, es mit einem Posting voller Absichtserklärungen ("wir werden...") anzukündigen - ohne dabei auch nur eine einzige bereits umgesetzte Zeile Code zu erwähnen, während man gleichzeitig schon von Vorbestellungen, Rabatten und Shareware-Preisen spricht - ist.. äh... unglücklich.


    Mein Verbesserungsvorschlag: Ball flach halten bis es was zu zeigen gibt.

    Ja, das ist Bitmap-Grafik - muss es sein, weil im Textmodus in Hires eine Farbe (Hintergrundfarbe) in allen Bildschirmzellen auftauchen muss, während sich bspw. bei Cave Wizard Zellen mit blau/weiß (Himmel) und schwarz/grau (Höhle) zu sehen sind - und zwar in der selben Bildschirmzeile, also auch keine Raster-Interrupts. Und Sprite Overlays scheiden aufgrund der Größe der Fläche und der vielen bewegten Objekte auch aus.


    Kannst du mit einem Action Replay auch sehr leicht überprüfen: "Edit Screen" aufrufen und lostippen - wenn sich nur die Farbe aber nicht der angezeigte Inhalt ändert, ist es eine Bitmap.


    Ja, das ist mit VSP realisiert, der Effekt wird im C64-Wiki recht gut erklärt. Es gibt eine ganze Reihe von Titeln, die Bitmaps scrollen - einige werde hier aufgezählt.

    Hihi, "Günstig" und "USB, GPU, Ethernet"? Du hast ja bescheidene Ansprüche ;)


    Die ZZ9000 bietet GPU, Ethernet, 1 GB Z3-RAM und Unterstützung für USB-Massenspeicher - allerdings nicht als Bootlaufwerk. Ist für günstige 350+ Euro zu haben.


    M.E. brauchst du erst mal IDE. Entweder per beliebiger Z3- oder CPU-Karte, oder per SCSI->IDE-Adapter - die scheint es inzwischen bei ebay sehr günstig zu geben? Ist natürlich immer Glückssache, ob die auch am Amiga problemlos funktionieren.


    Dann hast du zwei Möglichkeiten: Einen IDE-CF-Adapter, das ist praktisch ein rein mechanischer Adapter, in den du eine "beliebige" (sofern sie am Amiga funktioniert...) CF-Karte reinsteckst. Oder einen weiteren Adapter: IDE->Sata, die gibt es sogar bei Vesalia für unter 12 Euro. Und da dann deine SSD anschliessen. Ist halt Adapter an Adapter, also quasi Kompatibilitätslotterie.

    Finde ich persönlich zu einschränkend. Jedes Mal, wenn man eine andere Utility haben möchte, muß dafür extra ein Menü der OS-Oberfläche aufgerufen werden.

    Verstehe ich nicht, wie willst du denn sonst zwischen Utilities wechseln, wenn nicht per Menü?

    DIe Frage ist, ob es für einen reinen Textmodus überhaupt genügend Anwendungen gibt. Typische Spiele (bis auf harmlose Vertreter wie Minesweeper und Superhirn) fallen da schon komplett heraus.

    Spiele brauchen (von ganz wenigen Ausnahmen abgesehen) beim besten Willen kein OS. Und bei bestehenden C64-Anwendungen liegt der
    Anteil der Software, die im Grafikmodus läuft, irgendwo bei... 5 Prozent?


    (Edit: im Übrigen laufen 99% aller Spiele - von Kleinigkeiten wie Titelbildschirm abgesehen - im Textmodus)


    Der Textmodus ist optimal für alle Diskettenoperationen und Dateimanagement, einen "Launcher", Textbearbeitung im weitesten Sinne, Chat, Anzeige großer Textmengen (Mailbox, einfacher, C64-gerechter Online-DIenst/"Konverter"), Char- und Sprite-Editoren usw. Also im Grunde das, was man heute so brauchen könnte.


    Was nicht geht, ist die Kategorie "Ich will einen Windows-PC imitieren" - also Sachen wie Browser, Twitter und WYSIWYGPYHWA1TO ("What You See Is What You Get Provided You're Happy With A 1965 Typewriter's Output").

    Meine persönliche Ansicht ist ohnehin, daß der Fensteransatz heutzutage nicht mehr aktuell ist. Soll heißen: Fenster sind auf dem C64 eher überflüssig.

    Sehe ich genauso. Fenster brauche ich nur für (a) Multitasking oder (b) Anwendungen die mehrere Projektdateien gleichzeitig offen haben. Also auf dem C64 maximal, wenn ich unbedingt einen Explorer-ähnlichen Dateimanager implementieren will - wer das will, soll Fenster im Dateimanager implementieren, nicht im OS: GEOS TopDesk hat das bspw. so gemacht.


    Nur dass "heutzutage nicht mehr" die falsche Wortwahl ist - GEOS (und m.W. auch sonst niemand) hat je Fenster implementiert. GEOS kann Dialogboxen, das ist was anderes. Fenster einzubauen ist eine ziemlich neue Idee.

    Laufwerkstreiber sollte man m.E. tunlichst vermeiden

    Sehe ich nicht so. Auf Systemen ohne Jiffy (ja, die gibt es) sind Laufwerkzugriffe ohne Schnellader einfach nur quälend langsam. Daher sollte man sowas weiterhin optional halten.

    Das ist der Punkt, wo mir jegliches Verständnis für deinen Ansatz verloren geht. Du willst, dass dein theoretisches OS neue Hardware voraussetzt - aber das Kernel ROM soll unverändert bleiben, weswegen du die Laufwerkstreiber selber implementieren willst? Das macht doch überhaupt keinen Sinn. Wenn ich in einem Modul schon RAM und Massenspeicher unterbringe, dann natürlich auch neue ROMs.

    Aber dann bist du ja wieder bei einer Speicherverwaltung angelangt, die wolltest du doch vermeiden?

    Nur für Programme, aber nicht für das OS selbst. [...] Wenn z. B. ein Dateiauswahlfenster am Bildschirm erscheinen soll [...]

    Ein Dateiauswahlfenster ist Bestandteil des OS, nicht der Anwendung. Nenn doch mal ein Beispiel für einen Anwendungsfall für eine (echte) Speicherverwaltung innerhalb einer Anwendung. Mir fällt nichts ein.

    Hmmm... halte ich persönlich immer noch für viel zu wenig. Wenn ich das richtig verstanden habe, soll dieser wenige Speicher dann u. U. noch auf mehrere Programme aufgeteilt werden. Um unter diesen Bedingungen zu programmieren, bräuchte man unbedingt einen externen Ramspeicher und einen Programmaufbau, bei dem die zu bearbeitenden Daten ständig in einen Puffer geladen und von dort geschrieben werden. Da das aber ziemlich langsam ist, stellt sich schon die Frage, welche Art von Programmen für solch ein System angedacht sind.

    Oh, ich bin völlig deiner Meinung dass das zu wenig freier Speicher ist. Deswegen meine Bewertung als "Tech-Demo": Ich finde solche Projekte sind immer vom falschen Ende her gedacht: "Kriege ich das alles auch auf einem C64 implementiert?" statt "Was brauchen Anwendungsentwickler/Anwender eigentlich auf einem C64?".


    "Mehrere Programme" soll C64OS aber m.W. nicht können. Man kann lediglich wie bei GEOS oder STOS kleine Utilities (Taschenrechner) in irgendeinen Speicherblock laden - der dann aber vermutlich auch für andere Sachen mitbenutzt wird (als Cache o.ä.).

    Also ich hätte keinen Plan, was ich mit dem OS machen sollte...

    Naja, wenn du dich für den Grafikmodus entschieden hast, ist sein textbasiertes OS natürlich für dich natürlich sinnlos - das ist dann aber nicht die Schuld des OS.

    Im Endeffekt ist die beste Lösung immer noch, daß das "OS" aus einer Sammlung von diversen Bibliotheken besteht, darunter die erwähnten Treiber als auch die GUI.

    Laufwerkstreiber sollte man m.E. tunlichst vermeiden - die Nutzung der ROM-Routinen spart maximal viel Speicher und ist maximal kompatibel, außerdem lässt sie dem Nutzer die Wahl ob bzw. wie viel Geld und Aufwand er in die Beschleunigung welcher Laufwerke investieren will. Dann bleiben nicht mehr viele systemweite Treiber übrig - mir fallen nur Maustreiber und Echtzeituhr ein. Alles andere (RS-232, Drucker, Ethernet) würde ich als anwendungsspezifische Treiber bezeichnen. Die würde zwar auch das OS mit verwalten und konfigurieren, aber die sind eher ein "Afterthought": Nicht ständig geladen, werden in den Anwendungsspeicher geladen, Laden und ggfs. Initialisieen übernimmt die Anwendung - da brauche ich beim "OS"-Design nicht viel Rücksicht nehmen.


    Wenn Kernel und DOS von den ROMs übernommen werden, bleibt natürlich nicht mehr viel klassisches "OS" übrig, aber ich glaube mit dieser sprachlichen Ungenauigkeit können wir leben.

    So in etwa, nur daß die Routinen halt in getrennten Dateien vorliegen, die einzeln geladen werden können, und nicht als ein großer monolithischer Block, der viel Speicherplatz verbraucht, egal welchen Teil man davon wirklich benötigt.

    Aber dann bist du ja wieder bei einer Speicherverwaltung angelangt, die wolltest du doch vermeiden?

    Es gab halt kein richtiges GUI-Toolkit (wie die damalige Macintosh Toolbox) außerhalb von ein paar zentralen Grafik-Basics (und auch keine UIGs).

    Natürlich hatte GEOS ein UI-Toolkit - sogar eines, das deutlich mächtiger war als die ersten Versionen von AmigaOS. Dass viele GEOS-Anwendungen grausig ausgehen haben, dürfte eher an dem von dir erwähnten Mangel an Guidelines und der mangelnden Erfahrung der Entwickler gelegen haben. Ausgewiesene Feature-Monster, die mehr GUI-Funktionalität benötigt hätten, waren GEOS-Anwendungen ja nun nicht.


    Auf einem 8-Bit-Rechner ist das m.E. eine einfache Kosten-/Nutzen-Rechnung: C64OS kann kein echtes Multitasking, also wieso einen Fenstermanager implementieren? Nur damit der Launcher nutzbar bleibt, während ich den Taschenrechner offen habe? Brauche ich bei einem 40x25-Zeichen-Display wirklich in der Größe veränderbare Layoutboxen?

    Ich denke, man sollte das dynamisch anlegen, sodass nur die UI-Sachen im Speicher gehalten werden müssen, die von einer App verwendet werden. 95% der C64-OS-Apps werden z.B. keine Bitmap-Darstellung benötigen – dann sollten auch weder die nötigen Routinen noch der Grafikbildschirm Speicher verschwenden.

    Ein UI-Toolkit, das zu viel Speicher frisst, gehört halt nicht auf einen 8-Bit-Rechner ;)


    Ein UI-Toolkit ist im Optimalfall so klein (und nützlich), dass ich das als fertige Bibliothek in einem beliebigen Projekt nutzen kann - auch einer Textverarbeitung, die auf einem nackten C64 läuft und von 1541 gestartet wird. Damit erhöht der Toolkit-Autor die Chance, dass das Ding ein bisschen Verbreitung findet. Dass es dann zusätzlich noch in einem OS/CRT-basierten-Launcher/HD-Browser-TUI/... Verwendung findet, erhöht wiederum die Chance dass jemand seine Software für Letzteres umsetzt.


    Ein GUI um ein OS und zusätzliche Hardware herum zu designen, limitiert dagegen von Anfang an den Nutzen des Toolkits - ich kann das Toolkit nur benutzen, wenn ich meine Anwendung komplett auf das OS anpasse - und damit den möglichen Nutzerkreis auf Nutzer des OS beschränke. Ganz abgesehen davon dass sowohl ich als auch jeder Nutzer die jeweilige Zusatzhardware besitzen müsste.


    Aber das Thema hatten wir ja schon mal. Einigen wir uns darauf, dass ich recht habe :D

    1.) Nur 20 kb (= $5000) für Programme frei.

    Das ist sehr wenig. Ehrlich. Für eine rein textorientierte GUI ist das echt wenig.

    20 KB nach Laden des Launchers. Ich glaube 30 KB sind für Anwendungen frei.


    Wenn man sich Greg's Videos ansieht, ist klar dass da nicht viel Speicher übrig bleiben kann: Er hat nicht nur einen Fenstermanager implementiert, sondern auch ein echtes UI-Toolkit - inklusive Layout-Boxen und komplexer Listviews (beide in Echtzeit in der Größe veränderbar), Tabs, Drop-Down-Menüs, Scrollbars usw. Das System verwaltet einen Text- und einen Grafikbildschirm und kann an beliebiger Y-Position zwischen beiden umschalten usw. usf.


    Das ist mehr eine Tech-Demo (natürlich eine recht eindrucksvolle) als sonst irgendwas. Ich sehe auch gerade zum ersten Mal, dass er das OS verkaufen will, damit schränkt er die Verbreitung des Systems sowieso von Anfang an massiv ein...

    2.) Das OS läuft nicht von einer üblichen C64-Originalhardware.

    Wie er selber sagt, ist Grundvoraussetzung ein Datenträger, der über Unterverzeichnisse verfügt. Und natürlich auch groß genug ist für die ganzen OS-Dateien. Und der natürlich schnell genug ist, um die ganzen Dateien in vertretbarer Zeit nachzuladen. Es ist also nur sehr eingeschränkt ein OS für den C64, mehr ein OS für den C64+modernem Datenträger. Das erklärt dann auch, warum sowas nicht schon früher in den 80ern geschrieben wurde: Diese Datenträger gab es damals schlicht nicht.

    Sicher, aber wenn ich nur Original-Commodore-Laufwerke habe, brauche ich ja kein *OS*, sondern maximal ein einfaches UI-Toolkit? Als 'OS' taugen Action Replay o.ä. für 15x1-Besitzer deutlich mehr als alles andere.

    WYSIWYG macht auf einem C64 heute keinen Sinn mehr, da man sich da sehr stark einschränkt - druckbar ist nur, was auch auf dem Bildschirm darstellbar ist. Bei 320x200 Pixeln, 64 KB und 1 Mhz ist das nicht viel... Bullet Points? Proportionalschrift? Trennlinien? Tabellen? Grafiken?


    Ich würde deswegen eine Textverarbeitung modular gestalten. Text und Disk-Menü (Laden, Speichern etc.) sind immer im Speicher. Der Rest des Programms sind Module, von denen immer nur eines gleichzeitig aktiv ist:

    • Editor
    • Formatvorlagen
    • Layout / Preview
    • Output
    • (Spellchecker, Import von Fremdformaten...)

    Im Editor wird der Text eingegeben bzw. geändert. Textauszeichnungen (Überschrift1, Überschrift2, Kursiv, Zitat, Quelltext usw.) werden als Markdown notiert.


    In den Formatvorlagen bestimme ich, wie die einzelnen Textbestandteile aussehen (Schriftart und -größe, Zeilenabstände und Ausrichtung...). Als Endanwender nutze ich dieses Modul eher selten.


    Im Layouter lege ich fest, ob das fertige Dokument Kopf- und Fußzeilen hat (und was da rein soll) oder ein Standard-Briefkopf verwendet werden soll, wie viele Spalten der Haupttext hat, ob irgendwo Platz für Grafiken vorgehalten werden muss und welche das sein sollen usw. "Preview" rendert eine stark vereinfachte Vorschau einer Seite des fertigen Dokuments.


    Output generiert irgendetwas, dass ein Drucker auswerten kann und speichert das oder schickt es an den Drucker - "modern" wäre hier Postscript, ob man noch ESC/P-Drucker unterstützen müsste ist m.E. fraglich. Dazu ein Datei-Format, was anderswo weiterverarbeitet werden kann: RTF oder ODT.


    (Monochrome) Grafiken werden mit einem externen Programm bearbeitet. Eines, das möglichst sechs Hires-Bitmaps als zusammenhängende Grafik im Speicher halten kann - in allen möglichen Anordnungen von 1920x200 über 640x600 bis 320x1200. Eventuell wird beim Abspeichern ein kleiner, separater "Thumbnail" mit abgespeichert, der dann vom "Layout"-Modul der Textverarbeitung für Previews verwendet wird.