Etwas Reserve schadet nie. Die Voltzahl sollte aber natürlich stimmen. Und das Netzteil sollte stabilisiert sein, weil sonst unter geringerer Last wesentlich höhere Spannungen raus kommen können.
Posts by LogicDeLuxe
-
-
Über den Sinn der Sache könnte man sicherlich streiten, ich denke da an den Turbo von TC64 in Verbindung mit der
internen 1541 Ultimate von Ultimate 64.
Da das TC64 selbst zwei 1541 emulieren kann, sehe ich da den Reiz nicht.
-
Ob das reicht, wenn bei einem Backup praktisch "gleichzeitig" beide Disks gleichzeitig lesen bzw. schreiben?
Man könnte elektronisch die Möglichkeit vorsehen, die Daten direkt von einem Laufwerk auf das andere durchzuschleusen. Softwareseitig müßte man da nur noch sicherstellen, daß der Schreibvorgang nicht mitten im Sektor anfängt oder aufhört. Diese Methode hat X-Copy am Amiga mit den hauseigenen Zwischenstecker auch angewandt.
Aber es muss dann auch einen Use-Case geben.
Da sehe ich auch das Hauptproblem. Obwohl viele Software und Dokumentation am C64 hartnäcking am "0:" festhalten, geht auch gleichzeitig so ziemlich jede C64-Software davon aus, daß es kein "1:" gibt. Eine entsprechende Unterstützung müßte erst noch geschrieben werden. Diesen Umstand hat man auch beim SD2IEC geschickt bedacht, wobei mehrere Laufwerke selbst da eher ein Exot sind.
-
Gibt es vielleicht irgendwo im Programm einen Befehl, der solch eine Routine aufruft?
Irgendwo auf ein BRK gelaufen? Und das kann bei einem Absturz ja leicht passieren. Wenn das Programm vorher munter Systemadressen überschreibt, kann das schon die wildesten Symptome geben.
-
Eine Zeile hat ca 60 Taktzyklen Platz. Habe ich dann 60 Taktzyklen Zeit für mein Unterprogramm. Oder habe ich Zeit, bis zur nächsten Zeile bzw. bis zum erneuten Erreichen der Zeile ?
In Badlines hat die CPU deutlich weniger Taktzyklen zur Verfügung als in anderen Zeilen. Taktzyklen muß man in den allermeisten Fällen sicher nicht abzählen, aber man sollte die Routinen schon so gestalten, daß die so schnell wie möglich, die gewünschten VIC-Register setzen. Was danach noch in der Routine passiert, kann sich Zeit lassen, sollte aber schon zum Ende kommen, bevor der nächste Interrupt fällig ist, weil sich sonst die Routinen in die Quere kommen.
Alles über das Timing findet sich hier: http://www.cebix.net/VIC-Artikel.txt
Dann noch eine Frage. Die Lage der Rasterzeilenabfrage hat ja letzten Endes mit dem Bildaufbau nichts zu tun, oder ?
Ein Rasterzeileninterrupt ist dazu da, daß man keine Rasterzeilenabfrage machen muß.
Um ein Gefühl für das Timing zu bekommen, erwähne ich gerne nochmal meine Empfehlung, am Anfang und Ende jeder Interruptroutine jeweils unterschiedliche Rahmenfarben zu setzen, um eine visuelle Repräsentation zu bekommen. Das kann man später, wenn das Timing erstmal sitzt, natürlich wieder rausnehmen.
-
Immerhin ist "Hyper Hyper" ja ein echter "Scenetrack", wo sonst wurden Mitstreiter der Scene mal so namentlich aufgelistet...
Ist doch wie ein "Greetings-Part"...
Ich hoffe, das war ironisch. Soweit ich das in Erinnerung habe, fanden das nicht alle Mitstreiter so witzig, mit diesem Stümper verglichen zu werden. Wobei ich "Hyper Hyper" ja noch als echtes Stück durchgehen lasse. Der ganze Rest, der danach kam, sind doch nur schamlos kaputtgecoverter Hits. Mit Trance, wo er sich selber einordnet, hat das für mich nichts zu tun.
-
Ich würde da nicht nur eine IRQ-Routine mit Verzweigewurst machen, sondern 4 getrennte IRQ-Routinen machen, die jeweils am Ende den IRQ-Vektor auf die nächste Routine setzen. Wenn das CIA-Timing nicht unbedingt gebraucht wird, würde ich den CIA-IRQ deaktivieren. Damit spart man sich auch die Abfrage zur Feststellung, was den IRQ ausgelöst hat. Sofern die KERNAL-IRQ-Routinen benötigt werden, würde ich in einer der IRQ-Routinen einfach am Ende nach $ea31 springen.
Für's Debugging empfiehlt es sich, am Anfang und Ende jeder IRQ-Routine die Rahmenfarbe zu ändern, damit man sieht, wie sich die CPU-Zeit verteilt und kann direkt erkennen, wo es eng wird.
Das dürfte alles so gängige Praxis sein.
-
Didn't decide which one yet, but I'd just like to see a different processor (8051? 8048? Z80? 1802? hehe) play SID music
Z80 isn't that unusual. You can do that on a C128.
-
I have 3 questions:
1. Can I run the FPGASID, standalone just as a SID chip with default settings, without connecting any of the separate wires? After looking through the manual I think so, but I'd like to know for sure.
2. Do still need a +9V or +12V supply? I guess so, for the analog output stage?
3. Are the caps (on pins 1-4) needed? Guess not, but who knows
1. If you don't need the 2nd SID, you don't need the extra wires. Those are for the addressing logic and the 2nd channel audio out.
2. The +9/+12V is required indeed. I actually had the issue of missing 9V on my C64 and fixed it. The SID was audible, but very quite.
3. The filters are digital and thus don't need capacitors.
-
Der C64x hatte immerhin Cherry MX verbaut, soweit ich das in Erinnerung habe. Benutzt den jemand regelmäßig, oder ist das auch nur ein Staubfänger? Bei Letzterem wäre die Tastaturqualität wirklich egal. Ich denke mal, daß wird beim Maxi nicht viel anders enden, zumal er im Vergleich zum C64x doch eher bescheiden ausgestattet ist.
Wie gesagt, anders sieht es natürlich aus, wenn die Tastatur vollständig kompatibel zum Original-C64 wäre und als Ersatzteil dienen kann. Dann wäre die Qualität natürlich wesentlich mehr von Bedeutung. Vielleicht sollten die doch noch schnell bei Unicomp was mit bewährter Knickfedertechnik fertigen lassen.
-
Ich habe auch schonmal von dieser anderen Tastatur gehört, aber auch noch nie gesehen. Würde mich mal interessieren, was da verbaut ist.
Die aus C64-Tastaturen bekannte Mitsumi-Mechanik gibt es statt der Metallfeder auch mit einer passenden Gummifeder. Die haben dann ein deutliches taktiles Feedback, aber fühlen sich auch an wie Gummi. Kann es sein, daß Mitsumi auch mal diese Variante verbaut hat?
Oder waren das evtl. noch Überreste aus dem VC20-Bestand? Zur VC20-Tastatur habe ich das hier mal auf die Schnelle gefunden:
http://www.vcfed.org/forum/sho…them-all-working&p=538430
Die hatte also Gummiglocken mit Kohlekontakt. Dann wäre die reguläre Mitsumi-C64-Tastatur sogar eine Aufwertung gegenüber dem VC20. Also hier hat Commodore definitiv nicht am falschen Ende gespart. Ich denke Mitsumi war schon eine gute Wahl, ohne das die Kosten explodieren oder die Qualität leidet. Hätte man sich mit der Tastaturfertigung damals an IBM oder Cherry gewandt, wäre entweder der C64 deutlich teurer gewesen, oder die Tastaturqualität deutlich schlechter.
An Kostenreduzierung erkenne ich an der C64-Tastatur eigentlich nur den gequetschten Aufdruck komplett auf der Oberseite, wie die Tastenkappen zuletzt gefertigt wurden.
-
Ich ging immer davon aus, dass bei einem Neueintrag das Verzeichnis der Link-Kette entlang gesucht wird und die nächste freie Lücke sucht. Da hilft die BAM auch nicht.
So wird zunächst gesucht, ob es freie Einträge in den vorhandenen Directoryblocks gibt, richtig. Ist dies nicht der Fall, wird dann mit Interleave 3 weitergezählt, und von da aus der nächste Block belegt, der in der BAM eben als frei markiert ist. Ist kein solcher vorhanden, gibt es ein DISK FULL zurück. Ob da auch leichtsinnigerweise Spur 18, Sektor 0 mit einbezogen wird, sollte dieser Block als frei markiert sein, habe ich nicht geprüft.
d.h. man weiß trotz BAM auch nicht unbedingt den nächsten freien Block, wenn man nicht wirklich die Link-Kette durchgegangen ist.
Für das Folgen der Link-Kette (um daraus die BAM zu generieren) ist VALIDATE zuständig. Das sollte man auch unbedingt ausführen, wenn der Verdacht besteht, daß mit der BAM was nicht stimmen könnte. Sonst könnte nämlich jeder weitere SAVE Dateien abschießen. Das ist eine Tücke, die bei Verwendung von Diskwizzard durchaus passieren kann, wenn man unvorsichtig ist, weil dieses Programm eben auch die BAM ignoriert.
Die 664 freien Blöcke haben ja die 19 Sektoren vom Spur 18 schon abgezogen (vom der Gesamtanzahl 683).
Die werden nicht mitgezählt, weil sie nicht für Dateien vorgesehen sind. Dennoch funktionieren dort auch Dateien, was dann aber die Anzahl der möglichen Verzeichniseinträge reduziert.
-
Wie gesagt eine Qualitativ gute Tastatur wird fur Commodore als ehemaliger Schreibmaschinenhersteller obligatorisch gewesen sein.
Die Commodore-PC-Tastaturen haben dann aber doch nachgelassen. Statt Platine kam dann die Folienvariante der Mitsumi-Mechanik zum Einsatz. Da hatte ich schon abgeriebene Kontakte, was ich beim C64 bisher noch nicht geschafft hatte.
Aber selbst IBM hat nicht nur ordentlich gebaut. Die PCjr-Tastatur hat da z.B. ein ziemlich schlechten Ruf. Und dann gab's auch mal eine Model M2, die trotz Beibehaltung der Knickfedermechanik niemanden überzeugen konnte und schnell wieder vom Markt verschwand.
-
Vielleicht weil der C64 weniger Komplex ist als ein Amiga
Der Amiga ist von Grund auf anders designt, aber nicht wirklich komplexer. Durch den Verzicht vieler analoger Komponenten ist er sogar leichter zu emulieren. Tatsächlich hatte ich bei Amiga-Emulatoren schon lange das Gefühl, nah am Original zu sein, als C64-Emulatoren noch weit davon entfernt waren. Schwächen sehe ich eigentlich nur dort, wo sie alle Emulatoren systembedingt eben haben.
-
Wenn ich heute einen Schutz in einem Programm einbaue, wird es sellbst
mit einem Emulator schwer, diesen zu entfernen.
Da stellt sich natürlich die Frage nach der Wirksamkeit des Schutzes. Wenn das Ding bereits im Emulator läuft, ist das Diskettenimage doch bereits eine Datei, die man mühelos kopieren kann. Und wenn der Ursprung eine echte Diskette war, ist da dann wohl auch bereits eine Kopie von gemacht worden, wenn es im Emulator läuft.
Ein Doingle ist natürloich relativ sicher. Kommt jedoch drauf an wie das implementiert ist.
Typische C64-Dongles waren ein Widerstand am Kassettenport. Ein Nachbau würde wohl nichtmal als Reserve-Ingenuering durchgehen.
-
Ist zwar nicht C64, aber passt hier ganz gut: https://hempuli.itch.io/baba-is-you
Da muß man nämlich schon sehr abstrakt denken. Die Demo zeigt das Konzept ganz gut. Die Vollversion mit stark überarbeitetem Sound und Grafik (immer noch Retrostil) ist auf den üblichen Platformen zu haben und fordert den Denkapparat ganz gewaltig. Wer nicht abstrakt um 100 Ecken denkt, hat keine Chance.
Und auch wenn das Spiel von der Optik ein bisschen an Boulder Dash erinnert, so ist es doch zugbasiert. Also Denksport ganz ohne Action, und mit unbegrenztem Undo.
-
"Besser" bedeutet für manche halt automatisch "näher am Original". Und sobald ich etwas mache, was dem widerspricht, wird es als negativ angesehen. Ich hoffe halt, dass wir am Ende einen sehr guten Bomb Jack Port hinlegen werden – ohne uns sklavisch am Original festzuhalten.
Dann nennt es halt Remake. Da steht es dem Erschaffer frei, wie nah er am Original arbeitet oder Sachen neu interpretiert.
Die meisten werden das sowieso als "bessere" Portierung einstufen
Eine Portierung impliziert, daß es auf Daten und/oder Quellcode der Originalversion zurück greift. Ich glaube, die Bezeichnung "Remake" trifft es doch besser.
-
Daher halte ich persönlich es aus Entwicklersicht für sinnlos, Zeit und Energie in Kopierschutz-Mechanismen zu stecken.
Entwickler, die Kopierschütze einsetzen, nehmen an, daß die meisten Verkäufe direkt nach Erscheinen getätigt werden, noch bevor ein Crack kommt. Allerdings halte ich diese Sichtweise für überholt, weil doch kaum noch einer am Erscheinungstag in den Laden spaziert und sich ein Spiel kauft. Die Eiligen haben doch längst vorbestellt, und das ist schließlich nicht vom Kopierschutz abhängig.
Trainer einzubauen und das ganze somit den Begriff "Cracken" gar nicht verdient, dass teilweise defekte Versionen veröffentlicht werden, weil Geschwindigkeit (Firstrelease) wohl höher honoriert wird als Qualität und dass man selbst vor Gamepreviews "Crackintros" davorpackt mutet oft sehr lächerlich an...aber das ist ein anderes Thema.
Das gab's aber auch früher schon zu Genüge. Viele Titel wurden aus den Firmen geschmuggelt und teils sogar schon vor dem regulären Veröffentlichungsdatum rausgehauen. Kopierschutz gibt's da oft gar nicht, weil nicht für die Öffentlichkeit bestimmt, und daß da noch Fehler drin sind, wundert dann auch nicht, wenn es praktisch noch eine Betaversion ist.
Solche Titel würde ich dann aber Bootleg und ggf. auch Trainer nennen, aber nicht Crack. Leider wird das in den Intros nicht wirklich unterschieden.
-
Das Directory geht in 18/1 los.
Und zwar auch dann, wenn in 18/0 ein anderer Folgesektor steht. Der wird vom DOS ignoriert.
Zweiter Block ist 18/4 usw...
Nicht zwangsläufig. Im Normalfall ja, aber wenn der Sektor belegt ist, sollte das DOS auch einen anderen Folgesektor wählen. Und wenn das Directory manipuliert wurde, sind auch andere Sektoren möglich.
An der BAM fummelt ein Directory-Editor aber gar nicht herum.
Sollte es aber, wenn das Directory um ein oder mehrere Blocks verlängert wird. Auf jeden Fall ist das so eine Tücke im Disk Wizard. Beim Verlängern also immer an Validate denken. Sonst könnten mit dem nächsten SAVE Dateieinträge überschrieben werden.
-
Erzähl, mir mehr. Also geben DVD-Player per Hdmi typischerweise 800x576 aus?
Natürlich nicht. Es ging um Chameleon, und bei so einer Auflösung kann man einen ganzzahligen Scaler verwenden. Ein VGA-Monitor sieht keinen Unterschied zwischen 702x576, 720x576 oder 800x576, denn er kennt keinen Pixeltakt. Bei TFT's sieht's allerdings schon wieder etwas anders aus, denn diese resampeln, was Einfluß auf die Qualität haben kann. Bei so niedrigen Auflösungen wie beim C64 sollte es da allerdings keine Auffälligkeiten geben.
Ich habe an den D520 Entwickler nämlich den Wunsch nach einem 720x576 Modus herangetragen.
Was ist ein D520 Entwickler?
Was macht denn am meisten Sinn, wenn man an einem Fernseher(welcher eben kein 4:3 Format erzwingen kann) ein korrektes Seitenverhältnis haben möchte?
Bei HDMI würde ich immer die Option auf Pillarbox begrüßen. Kann die Playstation 3 auch, sowohl bei PS1-Titeln wie auch bei DVD-Wiedergabe.
