Vielleicht dumme Reparaturfrage...
Außenhülle des 220V-Kabels der Bohrmaschine ist gerissen, zur Reparatur hab ich das gekürzt.
Die Enden waren ursprünglich verzinnt, macht man ja nicht mehr... Die Litze lose fesschrauben macht man ja noch weniger. Ne "richtige" Crimp-Zange hab ich nicht, brauche ich auch viel zu selten. Ich werde mal einen Nachbarn danach fragen, der Elektriker war, aber ansonsten:
Was wäre denn die beste Pfusch-Lösung ohne crimpen?
Wozu braucht man denn hier ein Floppy-Programm? Für den vorgesehenen Anwendungsfall reicht es völlig, am Start der Datei (=Anfang des Texts) anzufangen und sich dann Sektor-Weise vor- und zurück zu bewegen....
Es reicht also völlig, sich beim schrittweisen Laden die Position von bereits gelesenen Sektoren in der richtigen Reihenfolge irgendwo zu merken - dann kann man sich auch problemlos im Text wieder rückwärts bewegen.
Stimmt irgendwie, so völlig frei muss der Zugriff für den Zweck gar nicht unbedingt sein.
Zeppelin oder Defender?
Mit viel Aufwand und Beschränkungen gäbe es eine Chance, wenn Du Dich an den internen Aufbau der Diskette ranmachst.
Aber dann würde es nicht mehr mit beliebigen Geräten funktionieren, sondern nur noch mit von Dir unterstützen Standard-Formaten und Geräten wie 1541 laufen. Und die 1541 direkt zu programmieren wäre dann auch hilfreich.
Ich hatte in den 80ern mal meine Floppy (war allerdings eine 1570) mit Lichtschranke gegen Diskettendiebstahl gesichert. Die Lichtschranke bestand aus einer LED und einem Phototransistor aus einem Technik-Baukasten. Das ganze hatte ich mit dem Control-Port des C64 verbunden und der hat viel Lärm gemacht, wenn man die Diskette entwenden wollte.
Müsste eigentlich auch mit der internen Lichtschranke gehen, oder?
Datasetten-Tasten und Lichtschranke der 1541 wären neuartige Eingabegeräte...
Fehlt nur noch die Spielidee dazu.
Die Zeit war wohl reif dafür.
Aquarius mit Play-Taste
Und mit Lichtschranke
Ein Bekannter von mir aus Dresden hat da ein bisschen Erfahrung in dem Gebiet. Ein Großteil der diskreten Elektronikbauteile kamen wohl von dort, ICs weiß ich jetzt nicht.
8087 waren in der Konstruktion dort sehr gesucht, da hat sich Schmuggel gelohnt.
Das Keyboard-Gedudel erinnert mich an Loco ab 0:39, aber nur 2 Takte. Und das ist von Jean Michel Jarre.
Von Photoline gibt es jetzt wohl die erste ARM-Testversion
...oder gar linear...
Müsste das nicht heißen, dass ein Sudoku mit 5 leeren Feldern 5mal so lange braucht wie eines mit 1 leerem Feld?
Ich hab noch einen Vinyl-Schnipsel auf der Tastatur ausprobiert, ist vermutlich die gleiche Technik, die northstarex nutzt.
Klebt bombig, und der Glanz ist wie von einer normal abgegrabbelten Tastatur.
Schneiden dürfte etwas mühe machen. Genau die Kanten der Tasten zu treffen wäre perfekt, aber das ist schwer zu machen.
Bisschen kleiner mit Abstand zum Rand kann man zwar sehen, fühlt man aber nicht beim Tippen.
Bisschen überstehend ist allerdings schlecht, selbst an den Ecken. Das fühlt sich scharfkantig an, und auf Dauer wird man da bestimmt auch den Aufkleber abheben.
Mir ist noch aufgefallen, wie sehr sich die Original-Beschriftung trotz der dicken Folie abhebt.
Alte PC-Tastatur mit DIN-Stecker gereinigt. Gebleicht wird die nicht, auf Schönheit kommt es nicht an, ist als Reserve für die Bandsäge in der Fertigung. Aber die Auswirkung des alten Aufklebers könnte hier interessant sein. Vielleicht kann man ja auch kreativ bleichen, indem man die Gehäuse mit Mustern abdeckt?
vermutet er, dass die Type im Video davor schon mehrfach die Register gesetzt hatte. Es war also nicht leer. Hat er beim Erstellen des Videos bloß nicht dran gedacht.
Ja das meinte ich. Aber wo ich mir das Video jetzt nochmal angucke, da war das wohl die falsche Erklärung. Der Poket ja mit den Datazeilen im ersten Durchlauf alles auf 0, beim 2. Durchlauf müsste er dann imho das Problem bekommen...
Ich hab leider grad keinen Emulator zur Hand und kann alles nur aus dem Gedächtnis sagen.
kommt kein Ton und auch ein nachfolgendes korrektes Poken funktioniert dann nicht mehr.
Das hatte ich noch überlesen:
Das unterste Bit von 4 steuert die Hüllkurve, den Lautstärkeverlauf des Tons, ADSR.
Ist es gesetzt, dann laufen Attack/Decay/Sustain ab. Ist Sustain 0, weil es noch nicht in Register 6 geschrieben wurde, dann endet der Teil schnell bei Lautstärke 0.
Ist es gelöscht, dann läuft der Release-Teil ab, der Ton klingt dann vom Sustain-Level bis Laustärke 0 aus.
Setzen und löschen müssen sich abwechseln. Beim ersten Lauf des Programms endet der Ton mit Sustain-Level 0. Beim 2. Lauf bleibt der Ton dann bei 0, weil das Bit in SI+4 nie gelöscht wurde.
...Soweit jedenfalls die Theorie, aber das ist wohl nicht wirklich das Problem, oder nur zum Teil. Runstop/Restore setzt glaub ich eh alles im SID auf 0.
Mein Verdacht: Rumfummeln an an AD, SI+5, bringt was durcheinander, während grad die AD-Phase läuft. Da gibt es einen Bug im SID, an den ich mich aber nicht mehr richtig erinnere, und testen kann ich grad nicht. Probier mal Si+5,0, wie im Video, und dann probier mal weitere Läufe mit anderen Werten.
Warum wäre das "richtiger" als die 0?
Beides startet den Release-Teil, in dem der Ton ausklingen kann. 32 lässt dabei den Sägezahn als Wellenform an, man kann das Ausklingen hören. 0 schaltet jede Wellenform ab, der Ton endet sofort.
Ich weiß die Speicheradresse nicht auswendig aber ist das Register für die Lautstärke gesetzt?
Das ist das SI+24,15 am Ende.
Nun frage ich mich zum einen natürlich, warum geht das nur in dieser Reihenfolge? Und zum anderen, warum hat das beim Ersteller des Videos funktioniert?
Control-Register (SI+4) muss zuletzt. Oder besser: Die anderen Register sollten vorher geschrieben werden, damit man weiß, was drin ist.
Wenn man so vor sich hinexperimentiert, dann lässt man das Programm ja gerne mal mehrmals laufen, und dann sind die anderen Register im vorigen Lauf ordentlich gefüllt worden.
Ich würde gar nicht lange damit rumärgern — Einfach ins C64 Handbuch schauen. Da wird ordentlich erklärt, wie man den SID in BASIC nutzt.
Wenn ich mich richtig erinnere, dann war im HAndbuch das Gate-Bit nicht richtig benutzt. Dort wurde der Ton mit SI+4,0 abgewürgt. Richtig wäre, nur das untere Bit zu löcschen, hier SI+4,32
REU lebt davon, schnell Speicher kopieren zu können. Sowas wie Bitmaps in 1 Frame zu kopieren und anzuzeigen geht mit der Georam einfach nicht. Oder echte 64KB Speicher restlos füllen. Oder Daten mit 1 MHz sampeln.
Das Verarbeiten von Daten ist mit der Georam einfacher, aber der geringere Aufwand bringt keine großartigen Vorteile. Wenn juckt es, dass man 1000 Datensätze 0,25 Sekunden schneller nach einem Anfang durchsuchen könnte, oder dass ein Packer 0,06 Sekunden schneller wäre?
Außerdem gibt es das schon und ich fände es interessant, meine Idee mal in Realität zu sehen, weil es das noch nicht gab
Wäre vielleicht ein Fall für Vektor-Grafik, oder im Stil von Thrust.
Ich weiß nicht so recht, ob das links/rechts-Problem wirklich so wichtig ist.
Mir fallen 2 Spiele mit entsprechender Steuerung ein, Rally Speedway am C64 und Death Rally unter DOS, und Probleme hatte ich nicht. Wobei da die Geraden aber auch meist kurz waren, ich am Ende noch meine Fahrtrichtung wusste und das auch am Scrollen gesehen habe. Ohne Scrolling könnte das was anderes sein.
Könnte ein aufgemotztes Rally Speedway werden.
Hoogo ich bin mir nicht sicher, ob ich verstehe was Du meinst. Was ist denn zu tun, um den Basic Editor soweit zu zu reduzieren?
Wenn ich mich da mal erinnern könnte 
Da war irgendein Vektor. Wenn man Return drückt, dann wird die aktuelle Zeile tokenisiert, und auf dem Weg dorthin gab es einen Vektor...
Das ist alles Teil des VC20-Assemblers?
Vielleicht lässt der sich auch "andersrum" denken: Der normale Basic-Editor bleibt weitgehend aktiv, und nur bei Druck auf Enter wird Dein Programm aktiv und sieht sich die Eingaben an?
