Wenn ich das richtig verstehe, dann muss entweder die Tastaturabfrage im C634 aktiv sein, oder das Gerät muss selber an den Spalten herumspielen und riskieren, evtl. das Programm zu stören.
Wäre es da nicht besser, das mechanisch zu lösen und unter jeder der 3 F-Tasten einen eigenen zusätzlichen Taster anzukleben?
Ich hab wenig Ahnung von Elektronik und hab ne Frage zu meinem Verständnis:
Ist eine Elektronik, die Spannung messen soll, nicht generell "hochohmig", weil sie sonst die Spannung verändern würde?
So ganz naiv müsste man ja PA0 und PB4 bis PB6 mit Masse vergleichen und das Ergebnis verANDen, oder?
Noch ein Nachtrag zum OT der G-Kräfte beim Transport:
Ich hab die Woche ein paar Infos zum Versand gesammelt. Dank Seidenstraße gibt es ja nun auch Bahntransport ab Duisburg nach China, und der Kunde hat das mal mit einer Testmaschine und Messgeräten ausprobiert. Es kam aber nur Schrott in China an. Bahntransport ist offenbar weit rabiater als Seetransport.
Wir haben Etis, die auch ein paar Monate im Regen überstehen müssen, Thermotransfer auf weißer Kunststoff-Folie, 8*8 cm.
Kann aber streifig sein, in aller Regel sind einzelne Heizelemente kaputt, was aber hier akzeptabel ist.
Hab meine Schablone grad gefunden.
Dann hau mal raus den Basic Code. Würde mich interessieren.
Ja, mich auch. Der Sys für die Rasterzeile wartet ja auf Zeile 0 oder 256, aber meist auf den falschen Wert, mit dem das meiste im Border verschwindet.
Ich hab noch ein kleines bisschen versucht, das mit anderem Wait stabil zu bekommen, hab dann aber die Lust verloren. Vielleicht hilft es zu warten, bis keine Taste mehr gedrückt ist?
So muss man halt per Tastendruck sein Glück versuchen, und manchmal passt es dann beim Loslassen.
Sind 28 Streifen +1 Hintergrundfarbe
Aber stell dir vor, da wäre ein Sprite-Editor im System gewesen, mit dem man fix Multicolor-Sprites hätte erzeugen können und ein paar Befehle, um solche Sprites zu bewegen – dann hätte es wahrscheinlich schon ganz anders ausgesehen.
Beim Speccy waren alle Befehle auf der Tastatur, und der Editor mag komisch gewesen sein, aber er hat einen darauf gestupst, was man wie eingeben kann. Er war für ahnungslose Interessierte zugänglicher, für einen Einstieg ins Programmieren imho wichtiger als die Anzahl der Farben oder die Soundfähigkeiten. Erst mit der Möglichkeit, einfach Spiele zu tauschen wurde der 64er das interessantere Gerät, und da kam die Lawine ins Rollen. Ich hatte meine erste Kassette vor dem C64, und ich kann mich nicht erinnern, dass in meiner Klasse jemand was anderes als C64 gehabt hätte.
CPC war damals glaub ich in Buchhandlungen und sowas im Schaufenster... Ich erinnere mich an eine Pyramide aus Kreisen, die mich doch beeindruckt hat. Aber der war halt nicht zum Ausprobieren verfügbar, während man im Kaufhof überall rumdrücke konnte und auche ine Datasette angeschlossen wurde, wenn man gefragt hat.
Was auch total überschätzt wird, sind so typische Grafikbefehle, wie Circle oder Line. Speziell für Spiele braucht das kein Mensch.
Das stimmt zwar, dass der "Profi"-Nutzen kaum da ist, es sei denn, man will Diagramme aus Daten erzeugen.
Aber so fing es damals an: Im Kaufhof standen verschiedene Home-Computer.
Auf dem C64 stand meist 1+1=? , Hallo und "?Syntax error, Ready."
Auf dem Speccy liefen Programme, die bunte Kreise und Linienmuster gezeichnet haben. Da konnte man reingucken, abschreiben, an den Parametern und Zahlen drehen und stundenlang Spaß haben. Nebenbei hat man eine Idee von Schleifen und Variablen bekommen.
Der C64 wurde erst interessanter, als Kasetten und Spiele getauscht wurden und jemand die wichtigsten Kommandos kannte.
In der Form wird es nicht wiederkommen, ich denke nicht, dass die Kinder noch Freizeit in Kaufhäusern verbringen.
Wenn es Ziel sein soll, Kindern das Programmieren näher zu bringen, dann müsste es etwas sein, was auf Smartphone läuft, hübsche Effekte erzeugt, die auch andere beeindrucken, und einfach über Social Media zu tauschen ist (am besten incl. der Programmiersprache und dem selbst gemachten Code)
Hat oobdoo schon besser verlinkt
Zentrifugentest, welcher natürlich nur einer der Tests ist, unserer Bauteile nicht auch selber vornehmen könnten ... bei 30.000g
Beantrage doch mal ne Railgun.
Vorallem der Transort in den Übersee Containern ist purer Stress für einige Bauteile.
Beschleunigungen von 1g und Schieflagen von 30° sind bei schlechtem Wetter nicht ungewöhnlich, aber auch 45° sind drin. Schön langsam, aber tausende Male. Bei kleinen Schiffen kann es 2g geben, bei Luftfracht kann es 3g geben, Beim Rangieren mit der Bahn auch 4g.
Das ist grad ein Thema für mich. Als ich noch schnell die Zahlen recherchiert habe, bin ich drübe rgestolpert, was Scanntronik heute macht.
Das ist jedenfalls spaßig
Zwischendurch hab ich es auch mal geschafft, auf die andere Zeile 0 oder 256 zu warten, das sah besser aus.
Kurz Angezockt:
Crusader - No remorse (1995)
Egoshooter in isometrischer Darstellung. Den Einschränkungen der Zeit entsprechend kein Scrolling, sondern weiterschaltende Bildausschnitte.
Problem: Vom Prinzip he rist es ein Egoshooter, aber in der Isometrie ist schwer abzuschätzen, wohin man eigentlich zielt, und man wird auch schonmal von Gegnern beschossen, die wegen Wänden im Vordergrund nicht zu sehen sind. Und es ist auch ein bisschen zäh.
"Bastard operator from hell" auf dem 64er ist imho besser.
Wasteland remastered
Ist im Grunde von der Bedienung her exakt wie das Original von 1988: Per Cursor in 4 Richtungen laufen, per Zahlentasten die Aktionen wählen, auch Listen und Bildschirmausgaben sind auf die gleiche Anzahl an Elementen und abgekürzte Wörter beschränkt. Das finde ich nun aber nicht "original", sondern nur unnötig umständlich. Grafisch nutzt es mehr Farben und höhere Auflösung, aber wenn man nicht pixeln kann sieht es trotzdem Scheiße aus.
Bard's Tale auf dem 64er kommt dem sehr nahe., und da stören mich die Einschränkungen nicht.
Jetzt grad wirklich am Zocken:
Creaks (2020)
Skurill wie die anderen Sachen von Amanita wie Samorost oder Machinarium. Viele Puzzlescreens mit Schaltern, Leitern und seltsamen NPCs, deren Verhalten man zum Lösen der Puzzles einsetzen muss.
Sehr wie Castles of Dr. Creep, aber nur 1 Spieler und weniger weit rumlaufen. Ich finde es knifflig, aber es strapaziert meine Geduld nicht und macht Spaß.
Du hast schneller Assembler gelernt als das spielbar in Basic gemacht 
Egon Olsen hat grad ein hübsches Beispiel, was Du in compiliertem Basic erwarten kannst. Mit 4 Sprites ist es OK, aber nix geiles.
- Wie erstellt man einen Loop indem bei Sprites sich bewegen und dabei das Sprites wechseln.
- Die Schleife sollte das Hauptprogramm nicht blockiert wird.
Die Loop zur Bewegung sieht schon fast richtig aus.
Eine Schleife, die das Hauptprogramm nicht blockiert, gibt es in diesem Basic nicht. Es gibt nur genau einen Programmfluss, nur eine Reihenfolge, in der alle Befehle nacheinander ausgeführt werden.
Aber Du kannst die Aufgabe in kleine Schritte zerlegen, eine große Schleife drumrum, und die einzelnen Schritte dann in richtiger Reihenfolge nacheinander in die Schleife reintun. "Kleiner Schritt" wären hier wirklich kleine Schritte: Schritt 1 Player1, Schritt1 Player2, Pause, Schritt2 Player1...
Ungefähr so dürfte das aussehen
On an 68000 Amiga, the throughput is about 40MB per hour.
Wie lange ich da wohl brauche um meine Videos (1,5TB) auf VideoTape zu backuppen?
Etwa 35 Stunden.
Ich glaube, da hast Du Komma und Tausender-Punkt verwechselt. Ich komme da auf 35.000 Stunden, 4 Jahre.
die sehr späte Erkenntnis, dass BRK nicht verlässlich ist
Meinst du, wenn gleichzeitig ein IRQ auftritt?
Ja, auch, in dem Fall fällt der BRK wohl unter den Tisch.
Zusätzlich habe ich noch einen Bug gemacht: Es ist ein BRK passiert, wenn weder VIC noch CIA-IRQ anliegen. Aber das ist falsch, die IRQs können ja auch in der Zeit zwischen BRK und dem Check in der IRQ-Routine gekommen sein.
Der Scheduler war in der IRQ-Routine und hat auch auf Floppy-Status geprüft und einen Thread zum Laden eines Sektors aktiviert. Und wenn ein Thread nichts zu tun hatte, dann hat er sich mit BRK beendet. Es dauerte ein paar Sekunden, aber irgendwann kam die Situation, in der BRK nicht erkannt oder nicht ausgeführt wurde, und dann wurde es übel...
Ich denke, ein threadsicheres Flag "Scheduler läuft" und ein JSR zum Scheduler sollten das Problem lösen, aber ch kann mich einfach nicht mehr zum Programmieren aufraffen.
Eine multithreading engine fuer VirtualBoy damit die Raketen auch fliegen 'wenn keiner zusieht'
Mit sowas hab ich mich auch mal befasst, ist aber lange her. Ein threadsicheres Flag ist dabei herausgekommen, und die sehr späte Erkenntnis, dass BRK nicht verlässlich ist.
Ist man dann nicht schon nahe des Gamebase-Frontends?
Ich hab mir das GB Frontend nie genauer angesehen, weil Spielesammlung nicht so mein Topic ist. Habe mir erst jetzt screenshots angesehen: Ich finde da ein paar Elemente, die mir gefallen: Zu einem Spiel-Titel werden alle möglichen Infos gesammelt.
Ich nehme an, man kann nach *Hubbard* suchen, bekommt dann alle Spiele mit Musik von Rob Hubbard und kann dann direkt das .sid-File von Spellbound finden und sidplay damit starten?
Und wenn ich nach "*dunkl*rad*" suche, dann würde die kleine Story zu Elite gefunden und Elite angezeigt, falls die Datenbank entsprechend gepflegt wäre?
Was mir eher vorschwebt:
Seit 20 Jahren werfe ich alles mögliche mit C64-Bezug in einen Ordner "C64": D64-Images, TAP-Dateien, Quelltexte, Grafik in verschiedenen Formaten, .Exe-Tools, .Sids... Und gezippt ist auch noch alles mögliche. Dann passieren auch mal Systemwechsel und Backups, die dann irgendwann wieder zusammengeführt werden: Alles in einen Ordner "C64". Versionskontrolle war früher auch noch nicht, es gab kein GIT, sondern Kopien von Dateien mit phantasievollen Namen. Vom Chaos und den Dubletten mal abgesehen sind D64-Dateien mit Bordmitteln eher schlecht zu durchsuchen. Mal eben eine Diskette mit dem "Professional-Ass" finden ist da nicht! Und GIT in D64-Dateien schon gar nicht.
Daher meine Vorstellung:
- Erstmal die Verzeichnisse scannen und alles mit Hash in die Datenbank schieben.
- Auch die Dateien aus den D64 in die Datenbank schieben und so zumindest Dateinamen durchsuchbar machen.
- Dann mehr Dateiformate mit C64-Bezug erkennen und verstehen. Bei .sid naheliegend, auch Amicapaint-Bilder oder Koala-Bilder könnten erkannt und gerendert in die Datenbank, schwieriger bei alten Quelltext-Formaten und Basic-Programmen, aber auch die könnten nach Ascii gewandelt und Kommentare und Texte indiziert werden.
Suche und Dublettensuche wären erste Anwendungen der Datenbank.
Verschobene Dateien zu erkennen, ohne Tags zu verlieren, wäre sicher gut.
Abgleich mit fremden Datenbanken wäre imho die Krönung. HVSC/CSDB-Datenbank runterladen und die Zusatzinfos für erkannte Dateien importieren, und das meiste Chaos wäre beseitigt.
In der Datenbank können von mir aus gerne noch viel mehr Dinge landen:
Tape- und SID-Dateien, Quelltexte, Koala-Bilder, die Verzeichnisse mit C64-Dateien an sich...
AUch die Programme aus den D64 könnten ausgelesen und möglichst klassifiziert in die Datenbank.
