Interessant, nachdem ich letztens wieder über das HD64 gestolpert bin hatte ich mich schon gefragt ob man das auch als Modul machen könnte oder ob da Signale fehlen ... scheinbar tun sie das.
Mit dem Tang Nano 20K könnte das auch billiger werden, wobei ich mich schon wundere warum ich bei Ali das scheinbar identische FPGA-Board für 4,69€ bis 71,69€ angeboten bekommen...
Die in den ganzen Modulen verbauten Blink-LEDs haben mich etwas neugierig gemacht ... die LEDs sind billig und haben keinen externen Takt, die laufen doch sicher im Laufe der Zeit auseinander.
Also flux einen Beutel Blink-LEDs 3mm bestellt und einfach 4x4 gleiche LEDs parallel auf eine Platine gelötet.
Wie sich herausgestellt hat, ist "im Laufe der Zeit" eigentlich "sofort" ... 
Habs mir gerade nochmal im Emulator angeschaut, stimmt, zumindest die gefüllten Formen und der Kreis sind extrem langsam. Vermutlich wird da für jeden Punkte eine SetPixel-Routine aufgerufen - wird wohl mehr auf ROM Größe als auf Geschwindigkeit getrimmt sein.
Die Linien-Funktionen scheinen aber ausreichend schnell, wenn auch vielleicht nicht für ein Action-Spiel ....
Hallo zusammen,
im Plain Vanilla C64 Basic war Grafik ja ziemlich müh- und dadurch langsam.
Der C128 hatte gleich Grafikbefehle mit drin, da ging theoretisch schon deutlich mehr.
Aber: Hat irgendjemand ein paar C128 Basic Listings die irgend etwas nichttriviales mit Grafik machen?
danke,
Andy
Die Tage endlich mal dazu gekommen das KFF2 von Felix das ich mir letzte Weihnachten gegönnt hatte mal in ein selbstgedrucktes Gehäuse zu packen.
Im Nachhinein betrachtet hätte ich nach dem Ausdrucken des transparenten Knopfes für die Oberschale vielleicht auf ein nichttransparentes Filament wechseln sollen .... 
Intuitiv erwarten würde ich eigentlich auch eine Kopfgesteuerte Schleife, weil die Bedingung ja auch vorn steht
for x = 3 to 1 : print x : next
10 x=3
20 if x<1 or x>3 goto 60
30 print x
40 x=x+1
50 goto 20
60
Ich hab mir meine Jeans mit Wasserstoffperoxid versaut. Zählt das?
Stefan
Nur wenn sie Größe 64 hatte..
Der hat nichts mit dem Ansatz des Emulators zu tun, oder? Ich meine, das ist einfach ein Programmierfehler? Was ist denn Deine Quelle?
Damit meine ich daß Katakis Raster-Tricks verwendet weil bei dem Bug teilweise das Sprite nur halb gezeichnet wird.
Ich meine nicht dass er nur in Emulatoren auftritt.
Das hat mit einem "zyklenexakten" Emulator wenig zu tun: Es ist nicht sonderlich schwer für einen beliebigen Emulator(-ansatz), z.B. bei einem LDA #$01 nunmal zwei Takte verstreichen zu lassen. Tut ein Emulator das nicht, ist er einfach komplett kaputt.
Ok, ich hätte vermutet dass es bei (sehr) frühen Emulatoren durchaus welche gab die sich eben gar nicht um Takte kümmern sondern nur in etwa sagen
while (true) {
command=mem[cp];
switch (command) {
case LDA_ZP : cp++; REG[A]=mem[cp++]; Flags[Z]=!REG[A]; break;
...
}
}
und dann froh waren wenn sie damit einen 6502 fast in Echtzeit emulieren konnten (gut, das wäre auf einer schnelleren Maschine dann ohnehin kritisch geworden).
Wäre dann vermutlich eher zu Zeiten von Amiga (A64?) und Atari als auf >=Pentium PC gewesen.
Ebenso der Bildaufbau: Man hat ein aktuelles Bild, und wenn irgendwo in den Bildspeicher geschrieben oder ein Sprite-Register geändert wird, ändert man nur das Zeichen/Pixel/löscht das Sprite und malt es woanders neu. Das wäre deutlich weniger Rechenzeit.
Natürlich gehen damit dann halt die ganzen Rastertricks nicht. Und Code der X Taktzyklen verbrät weil er eigentlich Y us warten will wäre nicht mehr exakt.
Daher bitte zurück zur Frage: Welcher Anteil von Spielen läuft ohne Rastertricks und Taktzählen?
Hallo zusammen,
heutige Emulatoren nutzen die enorme Rechenleistung moderner Hardware ja gerne um alle Aspekte des C64+1541 zyklengenau abzubilden.
Frühe Emulatoren hatten da meines Erachtens andere Ziele, da ging es erstmal darum die C64-Software überhaupt irgendwie in halbwegs normaler Geschwindigkeit laufen zu lassen.
Ich frage mich nun, wie viele Spiele sind denn überhaupt "timing-kritisch", gehen also kaputt z.B. wenn CPU-Befehle nicht originalgetreu viele Takte brauchen oder der Bildaufbau in einem Rutsch statt Zeilenweise gemacht wird?
Habe mich schon ein bisschen zu dem Thema eingelesen und es sind wohl mehr als man auf den ersten Blick so denken mag, z.B. Maniac Mansion verwendet Sprite Multiplexing, angeblich auch schon frühe Spiele wie Buck Rogers und Popeye.
Bei Katakis merkt man es spätestens am Geister-Chip-Bug 
Kopierschutz/Fastloaderaspekte würde ich hier mal unberücksichtigt lassen wollen, da gibt es ja im Zweifelsfall Versionen ohne ...
Von welchen Spielen mit delikatem Timing wisst ihr noch?
danke,
Andy
Wo stecken da denn die zwei zusätzlich nötigen Logikchips? Unter dem Flash?
Hallo zusammen,
ich spiele entfernt mit dem Gedanken mir auch mal ein kleines Computerchen zu designen (Betonung auf "spiele mit dem Gedanken", real wird das in den nächsten Jahren wahrscheinlich eh nichts).
Idee wäre etwas in der Richtung eines ZX81 (also minimalistische Support-Hardware) aber mit einem ez80 oder wdc 65816 oder dergleichen und 512 KB Ram + 512 KB Flash.
Ziel ist NICHT vorrangig kompatibel zu irgend einer echten historischen Maschine zu sein.
Allerdings könnte man an der einen oder anderen Stelle vielleicht mit wenig Zusatz-Aufwand zumindest Teilkompatibilit herstellen von wegen gleicher Zeichensatz, gleiche Textmodusauflösung, gleiche Standardadresse des Bildspeichers, Basic das kompatibel zu Zx81/C64/C128 oder dergleichen (je nach CPU) ist.
Programme die tiefer in die Hardware gehen (Timing, SID, VIC, CIA ...) würden natürlich nicht laufen.
Was findet ihr, macht es Sinn Aufwand in der Richtung zu betreiben, oder ist das nutzlos wenn 90% der Programme eh nicht laufen werden?
Andy
Schade aber verständlich.
Ist der Aufwand der Betrieb des Shops oder das beschaffen und Versenden der Waren?
Wenn ersteres, wäre vielleicht ein "Shop" in EBay oder Amazon eine Möglichkeit, dann sollte der Aufwand für die Webseite und Zahlungsabwicklung minimal sein?
Gibt es beim KFF(2) eigentlich grundsätzlich die Möglichkeit, Programme von SD ins RAM des Controllers zu laden und dort laufen zu lassen?
Das Timing wird viel zu knapp sein, um noch nebenbei irgendwelches Interfacing mit Plugins zu machen, plus man müsste ja irgendein weiteres Ressourcenmanagement machen ("Plugin xyz kann nicht aktiviert werden, weil die bereits aktivierte REU schon Leitungen xyz belegt").
Aber sicher könnte man z.B. die erwähnte GeoRAM einfach in die Firmware direkt implementieren, das sollte relativ einfach sein, siehe z.B. https://github.com/KimJorgense…re/cartridges/easyflash.c für die EasyFlash-Implementierung (das ja auch RAM mitbringt) - für ein GeoRAM müsste man das wohl nur duplizieren, den ROM-Kram rausnehmen und das Umschalten des RAM-Fensters implementieren.
Ich meinte tatsächlich weniger ein Plugin, sondern eher eine komplette Ersatz-Firmware, die dann halt im RAM läuft und nach einem Neustart wieder weg ist.
Bei einer custom Fimware hätte ich irgendwie immer Angst mit das Ding zu bricken Außerdem wird man die meiste Zeit ja vermutlich die "normale" Firmware laufen lassen wollen.
Wie hast du dein Level-Set denn erstellt und wie hast du es ins Spiel bekommen um es zu testen?
Wenn du das Spiel im Speicher auf den gewünschen Stand bringen kannst würde ich mal probieren z.B. mit einem (virtuellen) Action Replay VI-Modul mit dem Freezer ein Image zu speichern.
Gibt es beim KFF(2) eigentlich grundsätzlich die Möglichkeit, Programme von SD ins RAM des Controllers zu laden und dort laufen zu lassen?
Also ich meine natürlich keine C64-Programme, sondern eher Ergänzungen oder Alternativen zur Firmware, zum Beispiel eine GeoRam-Emulation (ich weiß das KFF2 hat schon eine Reu-Emulation) oder etwas vergleichbares.
> Operation not permitted)
Ins blaue hinein: Transferprogramm mal als Admin starten?
Heute endlich mal meinen über die letzten Monate zusammengestückelten Z80-MBC2 in Betrieb genommen, und siehe da, lief fast auf Anhieb. Damit hätte ich eigentlich gar nicht gerechnet 
Nur nach dem Flashen des AVRs hatte ich das Problem dass die Terminal-Ausgaben mit der falschen Baudrate kamen. Falsche Fuses als Ursache waren ja schon recht wahrscheinlich, trotzdem mal die Gelegenheit genutzt den Logik-Analyzer einzuweihen der auch seit ein paar Monaten originalverschweißt in der Schublade lag.
Ergebnis: Statt mit 115.200 Baud sendete das Ding mit ca 7.200 Baud, also 1/16tel. Tatsächlich, ich hatte erst die Fuses, dann die Lockbits und dann das Flash beschrieben, dabei sind wohl irgendwo die Fuses nicht mitgekommen oder wieder rausgeflogen. Fuses nochmal richtig gesetzt, schon hat auch die Baudrate gestimmt.
Heute vom inzwischen eingetroffenen RTC-Modul die Diode der Batterie-Ladeschaltung entfernt und das SD-Modul mit einer gefüllten Speicherkarte bestückt, schon lief es...
Meinen ersten 64-bit-Prozessor hab ich 2005 gekauft, krass dass das schon fast 20 Jahre her ist. Ja, da sollte man wirklich mal so langsam glauben, dass 32-bit endlich beerdigt wird...
Das eine oder andere 8-bit System soll gerüchteweise auch noch laufen
Mich als Retro-Fan nervt die ständige erzwungene Aktualisierung "neuerer" Systeme massiv. Spätestens seit Internet kann man ein altes System auch nicht mehr guten Gewissens weiter nutzen wenn es keine Updates mehr dafür gibt. Klar, als Programmierer kann ich nachvollziehen dass sich niemand den Aufwand machen will ein System weiter zu unterstützen das nur noch ein paarn Hanseln verwenden. Aber ich denke da sollte man lieber mal langsam anfangen den Kram so zu bauen dass er keine Verwundbarkeiten haben kann(!) und keine Updates braucht, statt ständig neue Räder zu erfinden. Und von einer Wegwerf-Gesellschaft zu einer Weiternutz-Gesellschaft werden.
Da lobe ich mir unseren guten alten Cevi - Betriebsystem im ROM, keine Updates, keine Patches, funktioniert auch nach 40 Jahren noch, und das auch mit neuster Soft- und Hardware.
Gaming-Mäuse haben übrigens auch gerne 5,7 oder noch mehr Tasten , da könnte man 4 Farben + Color Picker drauflegen...
