letzter Beitrag von RKSoft am
Falls jemand mitwirken möchte: ich trage alle bisherigen Erkenntnisse zusammen und veröffentliche alles auf meiner Website.
http://www.cbmhardware.de/show.php?r=10&id=15
Man braucht nur einen Arduino Uno, USB<->RS232 Adapter und ein Paddle einer Bruch-1551. Und natürlich einen PC und Plus/4. 
Kenntnisse in 6502-Assembler, AVR-GCC oder C++ wären ebenfalls angebracht.
Funktioniert nun schon mal und könnte weiterentwickelt werden. Wird es aber auch so.
Toll! Machst das wirklich als Arduino Projekt, oder setzt Du direkt auf der AVR Hardware auf? Weil ich mich für stm32duino interessiere.
wieso braucht man keine Leiterplatte ? 
Für dein Projekt vielleicht 
wieso braucht man keine Leiterplatte ?
Der Arduino ist doch die Leiterplatte. Kostet voll bestückt zwischen 4-10€, je nach Quelle. Mt dem USB-RS232 und Verkabelung kann es für 15€ fertig sein. Mit dem Arduino Nano geht es auch in sehr klein und noch günstiger.
Für dein Projekt vielleicht
Da gibt es wohl eher tausende dieser Arduino-Projekte. Spricht für das Konzept dieses Aufbaus.
Ein sehr ähnliches 1551-Paddle lässt sich ebenfalls mit zwei TTLs und einem 6522A nachbilden. Bei den paar Leuten, die da vielleicht vom PC speziell zum Plus/4 übertragen möchten, wäre es aber ein unsinniger Aufwand.
Ich mache Fortschritte:
Ein internes ROM wirft schon mal eine Empfangssoftware für den Tape-Buffer (mit bequemer Syszeile) heraus und damit können dann auch große Programme (32KByte>) transferiert werden. PRG-Spiele können z.B. bei Plus/4-World heruntergeladen und in Sekunden transferiert werden. Auch für CrossDev einfach nur super bequem.
Gelegentlich werden hier Source-Schnipsel veröffentlicht: http://www.cbmhardware.de/show.php?r=10&id=15
Ein sehr ähnliches 1551-Paddle lässt sich ebenfalls mit zwei TTLs und einem 6522A nachbilden.
Durchaus noch ein bisschen interessanter wäre die Verwendung von Pin 18 der PLA. Der ist in allen 264ern unbenutzt und dekodiert auf $FD20-$FD2F wenn ich das noch richtig weiss. Bis auf einen STA in der RESET-Routine des KERNAL wird dieser Bereich nie angesprochen.
Netterweise hat der Expansionport ein paar mit 'NC' bezeichnete Pins.
Ich beobachte dieses Thema ja mit richtiger Neugier. Hoffe, daß alles bald richtig klappt. Sowas wäre der Hammer für unsere 264er
Durchaus noch ein bisschen interessanter wäre die Verwendung von Pin 18 der PLA. Der ist in allen 264ern unbenutzt und dekodiert auf $FD20-$FD2F wenn ich das noch richtig weiss. Bis auf einen STA in der RESET-Routine des KERNAL wird dieser Bereich nie angesprochen.
Netterweise hat der Expansionport ein paar mit 'NC' bezeichnete Pins.
Ich möchte lieber ohne Eingriffe in den P/4 auskommen. Wenn jemand ein Paddle der 1551 dazwischen steckt, ist 'NC' dann auch wieder 'NC'.
Ich beobachte dieses Thema ja mit richtiger Neugier. Hoffe, daß alles bald richtig klappt. Sowas wäre der Hammer für unsere 264er
Ach, das läuft schon. Im Moment habe ich aber bestenfalls ein paar Code-Beispiele oder Bilder:
Hatte eben eine erste Version der ROM-Software auf ein Eprom gebrannt und das alte "3plus1" ersetzt. Danach mal testweise Xplodeman (Bomberman Klon) transferiert und es läuft. Nettes kleines Spiel.
Jetzt habe ich schon mal eine feste Brücke für Cross-Development.
In Deutschland kenne ich niemanden, der über das technische Know-How verfügt und an einem Plus/4 etwas machen möchte. Daher ist es eine "One-Man-Show", die immer etwas dauert.
Egal, wichtiger ist, daß du uns hier auf den laufenden hälst. Sowas würde ich mir irgendwie auch für meinen +4 wünschen.
Jetzt ich doch ein merkwürdiges Problem aufgetaucht, das ich erst bemerkte, als ich gepackte Programme transferierte.
Hier wurde Kikstart 2 ,einer dieser Versionen aus dem Leveleditor übertragen. An Stelle $1082 sieht man links $21 was aber $20 sein sollte. Und dieser Fehler ist reproduzierbar ! - Ich hatte es dreimal übertragen und immer wieder $21 an der gleichen Stelle wo $20 hingehört. Danach hatte ich dann ein anderes gepacktes prg (gut 10kByte) zum Testen verwendet. Wieder war in der Nähe dieses Bereichs Bit0 einmal falsch gesetzt.
Der IRQ ist gesperrt und ich habe im AVR schon die Variable bei jedem Cycle auf 0 gesetzt, bevor diese das neue Byte aufnimmt. Der PC liest in ein Array und übertragt dieses. Da kann das Problem nicht herkommen.
Das Diag264-Modul meint, dass der Speicher fehlerfrei ist. Wonach suche ich jetzt ?
Bau dir mal eine Datei die nur aus $20 besteht und übertrage die. Dann schau nach ob noch woanders solche Fehler zu sehen sind. Sollte sich ein Muster zeigen erleichtert das das Debugging ungemein.
Die Idee ist nicht schlecht. Ich habe den Bereich von $1020 bis $8000 mit $20 gefüllt. Beim Plus/4 kurz im Monitor alles auf $00 in diesem Bereich und zweimal übertragen. Das Ergebnis ist immer gleich:
Ob ich da nicht doch mal das Bit 0 RAM tausche ?
Edit: Am RAM liegt es nicht. Nach Reset und Laden des Tapebuffer-Loaders war die Übertragung ohne Fehler. Muss wohl an der ROM-Version liegen.
ROM-Version? Du meinst die im Rechner? Welchen KERNAL hast du denn drin?
Schreib mal eine Datei mit lauter $00 als Inhalt und eine mit $FF als Inhalt und schau nach ob sich noch andere Bits ungebührlich verhalten.
Ein Problem scheinen auch diese alten und nicht besonders effektiven Packer zu sein. Habe Kikstart 2 mit Vice entpackt, $1001-$4000 gespeichert und dann neu gepackt
Das ist aber nur Rumdoktern an den Symptomen - wenn dein Übertragungsbug nur bei bestimmten Datenmustern auftritt, wird der natürlich durch Änderung der übertragenen Daten nicht mehr getriggert.
Vielleicht hast du eine Abhängigkeit zu den zuvor übertragenen Bytes, z.B. durch zu langsam auf High oder Low wechselnde Leitungen? Ich würde zB mal versuchen, das Byte vor dem betroffenen per Hexeditor zu manipulieren (zB auf 0x66 - alle Bits invertiert) um zu testen, ob der Fehler dann immer noch auftritt.
Das ist aber nur Rumdoktern an den Symptomen - wenn dein Übertragungsbug nur bei bestimmten Datenmustern auftritt, wird der natürlich durch Änderung der übertragenen Daten nicht mehr getriggert.
Nicht nur. Mit der von Speicherkarte geladenen Version ist alles fehlerfrei und wird (mit Exomizer gepackt) auch passend entpackt.
Das Problem tritt nur bei der ROM-Version auf. Ich hatte jetzt auch bemerkt, dass nach dem Übertragen und Reset, nur noch (iirc) 12277 Bytes Free angezeigt wurden. Da hilft dann nur noch Ein/Ausschalten auf 60671 Bytes free.
Ich muss da die Routine zum Initialisieren des RAM einbauen, ohne das Löschen des Tapebuffer-Loader. Dann sollte es imo funktionieren.
Grundlegend funktioniert die Übertragung fehlerfrei. Nur nach Sprung aus meinem ROM passieren merkwürdige Dinge. Da muss ich nachbessern.
Das Problem tritt nur bei der ROM-Version auf. Ich hatte jetzt auch bemerkt, dass nach dem Übertragen und Reset, nur noch (iirc) 12277 Bytes Free angezeigt wurden. Da hilft dann nur noch Ein/Ausschalten auf 60671 Bytes free.
Das sind halt C-16 Programme, die früher nur mit dem Maschinensprachemonitor geschrieben wurden und einfach alles abgespeichert wurde.
Es kann ohne weiteres sein (je nach verbauten RAM's), das auch nach 2 sek. Aus- u. Einschalten noch fast alles im Speicher steht. Abgesehen dann von den ersten paar Bytes am Basicanfang.
Wer diesen Spuk loswerden will, gehe bitte in den Maschinensprachemonitor und gebe dort folgendes ein:
F 1000 FD00 00
und löse danach einen Reset aus. Dann hat man auch wirklich wieder 60671 Bytes free.
