Ich würde mal sagen ja.
Das wy7 ist etwas schneller, aber das macht nichts.
SRAM sind unkompliziert.
Bisher hatte ich nie Probleme, wenn die Zugriffszeit passt.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
Ich würde mal sagen ja.
Das wy7 ist etwas schneller, aber das macht nichts.
SRAM sind unkompliziert.
Bisher hatte ich nie Probleme, wenn die Zugriffszeit passt.
Ich verwende COMAL 2.01 als Cartridge und ein SD2iEC Einsteckmodul im User-Port. Leider scheint es keine Möglichkeit in COMAL zugeben qie man bei einem OPEN-Befehl eien Sekundäre Adresse mitgibt. Um ein D64-Image zu aktivieren reicht in BASIC ein OPEN 1,8,15,“CD:NAME.D64“:CLOSE 1
Geht so etwas mit COMAL gar nicht ?
Du brauchst kein Open beim Comal um Disketten Images zu aktivieren.
Es gibt ja den Comal Befehl der Befehle an die floppy sendet.
Damit sendest du einfach den CD Befehl.
soll das bedeuten, wenn /CS angeschlossen ist dann gibt das einen Black Screen?!
Wenn man dann /WE nimmt passt das?
Nee, das soll bedeuten, dass das Megabit 128 nicht perfekt ist.
Das Register soll an der Adresse $D700 schreibbar sein und kann so nicht gelesen werden.
Das ist ja okay.
Das Problem ist, dass das Register auch geschrieben wird, wenn man von der Adresse $D700 LIEST.
PRINT PEEK(55040)
Das PEEK schreibt in das Register, es ändert die Bank des Megabit 128.
Im Grunde macht das soweit nichts, es ist nur sehr UNSCHÖN, dass ein Lesevorgang zufällige Werte schreibt.
=====
So, nun kommt aber ein weiteres Problem hinzu:
Ich besitze einen Problem c128.
Der funktioniert ganz normal.
Aber er funktioniert nicht mit dem "normalen" Megabit 128.
Er funktioniert jedoch tadellos mit dem modifizierten Megabit 128 von Jood .
Der Unterschied ist einfach, die modifizierte Version des Megabit 128 von Jood macht nichts wenn man von der Adresse $D700 liest.
Weil Jood auch das R/W Signal zusätzlich auswertet.
Dh. die Version von Jood reagiert auf POKE aber nicht auf PEEJ().
=====
Das Problem meines fehlerhaften c128 ist, dass er manchmal in den IO Bereich durchschießt, auch wenn man den IO Bereich über die MMU ausgeblendet hat (Bit 0 der MMU).
Wahrscheinlich ein TTL das nicht ganz sauber funktioniert.
Oder die MMU hat was.
Keine Ahnung.
Es lässt sich nicht sauber nachstellen.
Wahrscheinlich kommt auch keine sauberes CS Signal sondern nur so Blitzer, ich weiß es nicht genau.
Aber wenn man den IO Bereich ausblendet und sehr oft von $D700 liest, dann ändert sich ungewollt die Bank.
Und das passiert genau, wenn man ein Programm startet von dem megaBit 128.
Es wird aus dem 32K Fenster gelesen und ins RAM übertragen.
Bei großen Programmen kommt es eben auch bei der Adresse $D700 vorbei.
Und dann schaltet die Bank um und es werden falsche Daten geladen, - buff, Absturz.
Deshalb bin ich mir auch nicht sicher welche Version ich veröffentliche
alle drei?
Ja, einer meiner beiden c128 hat das Problem, der andere nicht.
Deine Lösung mit /we funktioniert auf beiden c128
Die Sprint Layout- und Gerber-Dateien kann ich euch auf Anfrage gerne zur Verfügung stellen.
Oja, bitte bitte.
Ich verwende SPRINT.
Und ich liebe dieses Programm.
Die Hardware gibt es bereits.
MeGALoDOS
Aber dokumentiert ist es schon.
Ist in Arbeit.
Eigentlich wollte ich es heute bringen.
Aber nun ist das Wetter doch schön, und die Schipiste hat stärker gezogen ...
Vor dem Release gibt es noch ein Feature, dass sich Jood gewünscht hat:
https://oe7twj.at/index.php?ti…Programme_im_UC-Men.C3.BC
Frei wählbare Tasten für die Auswahl des Programm aus dem Menü.
Hmmm, mir fällt keine sinnvolle Anwendung ein im Moment ...
Wer moechte, kann die Version ausgiebig testen. Es ist auch ein "Easter egg" mit eingebaut.
Mal sehen, ob es jemand findet.
Wo, großartige Arbeit, danke sehr!!!
Öhm, also das letzte Programm, dem ich in dieser Hinsicht vertrauen würde, ist der Windows Explorer ...
Der zeigt auch Verzeichnisse nicht mit ihrem richtigen Namen an.
Das ist richtig.
Aber auch die Forum Software kommt auf dieselbe Größe ...
Das geht so ab rc3 mitunter. Ich wars nich.SCHWÖR.
Aber saugeniales Project.
Hmmm, erst seit rc3?
Es ist kein signifikanter Größenunterschied zu sehen
Wenn sich da Schadcode anhängen würde, dann müsste das doch relativ stark anwachsen?
Die EXE enthält 6502 Code.
Deine Menge.
Vielleicht irritiert das deinen Defender?
Vielleicht sollte ich diesen 6502 Code auslagern in eine eigene Datei?
Hmmm, die EXE ist frisch aus meinem Pelles C Compiler.
Und der Scan meines PC zeigt auch nichts?
Kleine Korrektur:
Für C64 Programme die über $A000 reichen wird von RAMTAS die Speicherzelle $A000 zerstört (durch den RAM Test der beim BASIC ROM aufhört).
Diese Version behebt das Problem.
.
Zeit für den Release Kandidat 3
Bugfix Release:
.
Da brauchst kein GAL, da reicht ein TTL-IC. Oder "schlimmstenfalls" ein paar Dioden.
Du hast sicher recht.
Aber ich bin ein Software Typ.
Ich liebe es, wenn ich Hardware auch im nachhinein noch modellieren kann.
Zudem kann man so gleich Funktionalität mit aufnehmen. Zb.:
Quatsch, man muss nur die eh schon existierenden /CS-Signale der ROMs auswerten. Das PLA übernimmt doch schon die ganze Arbeit.
Ja das sehe ich eigentlich genau so.
Ich denke ein kleines GAL und eine Platine und gut ist es.
Die Frage ist, ob man das DRAM damit auch gleich mit SRAM ersetzen könnte.
Jood hat da so eine SRAM Lösung für seine c128, das gefällt mir sehr gut, auch in Bezug auf die angedachte 256K Erweiterung.