Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » KC85 RAM-Init » Themenansicht

Autor

Thread - Seiten: -1-

000
11.05.2013, 13:53 Uhr
kaiOr

Hallo,

kurz ne Frage. Wann, wo und wie initialisert der KC85 seinen RAM bzw. wie wird der ge-NULL-t? Der klappert doch bestimmt nicht den ganzen RAM8 und alle Erweiterungsmodule ab, würde ja ewig dauern?

Ich frage weil mein SRAM-Umbau noch nicht so ganz tut. Die Blöcke in RAM8 (Block 0 bis D) sind gefüllt mit rosa Rauschen, aber mit MODIFY änderbar. RAM0 + RAM4 + RAM8 (E und F) dagegen normal.

MfG

Dieser Beitrag wurde am 11.05.2013 um 13:56 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
11.05.2013, 20:39 Uhr
maleuma

Beim POWER-ON wird der RAM von Adresse 0 bis BFFFh mit 00h beschrieben.
Dabei ist der IRM an, der RAM8 also nicht sichtbar.
Das heißt: Alle RAM8-Ebenen haben beim Einschalten des KC einen zufälligen Inhalt.

Welche CAOS-Version hast Du drin?
--
Mario.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
12.05.2013, 17:27 Uhr
kaiOr

CAOS 4.5 ist aktiv (4.2 wäre aber auch noch im ROM).

Also ist der Zufallsinhalt normal, danke.

Ich mache jetzt erstmal 3 Kreuze, RAMTEST3 läuft endlich. Hatte noch 2 Sachen nicht richtig auscodiert und spontane Abstürze, Übersprechen zwischen RAM und IRM.

Werde die nächsten Tage erstmal meinen Drahtverhau aufräumen und dann taste ich mich langsam zum IRM vor.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
14.05.2013, 21:46 Uhr
kaiOr

Sooo, Putzfrau is durch:

Überm IRM grübel ich noch.

Variante 1 - SRAM..gut und bezahlbar
Variante 2 - Dual-Port SRAM...schnell da WAIT wegfällt, aber teuer und kaum nachhaltig beziehbar wenn kaputt
Variante 3 - Dual-Port-Emulation via FPGA, doch der KC verdient eher einfache TTL-Logik und wie nachhaltig FPGAs zu beziehen sind weiß ich auch nicht

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
20.10.2013, 11:02 Uhr
kaiOr

Habe mir beim Löten gestern fast einen abgebrochen. Aber der KC machte auf Anhieb Bild, das entlohnt fürs stundenlange Grübeln.

Damit ich künftig ungebremst an der Z80-Taktschraube drehen kann, fiel die Entscheidung auf Dual-Port-RAM, denn der IRM erzeugt immer ein WAIT wenn der CPU-Zugriff nicht ins Taktregime passt.

MfG

Dieser Beitrag wurde am 20.10.2013 um 11:07 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
20.10.2013, 14:24 Uhr
kaiOr

Ein Problem habe ich noch...böse Nadelimpulse. Der Dual-Port-RAM fühlt sich mit 25ns Zugriffszeit natürlich viel früher angesprochen als es der alte DRAM jemals könnte.

Mal angenommen bei einem Vergleich zweier Adressbits muss vorher eins negiert werden. Dann kommt es durch das zusätzl. Gatter zur Zeitverzögerung und beim Vergleich zu kurzzeitigen Pegelveränderungen, die in den nachfolgenden Gattern zum Vollausschlag heranwachsen.

Wie verhindert man das am besten?

EDIT: Ein Kondensator < 100pF erstickt jetzt die Irrläufer im Keim, könnte mir bei höheren Taktraten aber wieder auf die Füße fallen.

Dieser Beitrag wurde am 20.10.2013 um 18:48 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
02.11.2013, 17:13 Uhr
kaiOr

Der Glättungskondensator war mir bei 14Mhz auf die Füße gefallen, er verzögerte auch die Auskodierung vom RAM8. Final blieb nur der Tausch, 2x DL004D gegen 2x MH74S04. Die sind verdammt schnell, eine Verzögerung kommt kaum zustande und damit auch kein Nadelimpuls..............und sie heizen schön.
Na egal, hatte die jedenfalls gerade in der Kramkiste.

Irgendwie stoße ich aber auf ein großes neues Problem, was mir sozusagen den Saft abdreht. Die interne PIO & CTC im KC sind ja nicht nur für Sound, sondern auch zur ROM/RAM/IRM-Steuerung und zur Tastaturabfrage.

Wenn ich die PIO mit 1,77Mhz programmiere und danach aber mit 14Mhz auf den RAM oder IRM zugreife den ich gerade an der PIO umgeschaltet habe, dann macht die PIO aus Sicht der CPU gerade noch Mittagsschläfchen... Wieviel Takte braucht so ne PIO nach /IORQ & /WR bis die Daten an Port A oder B verfügbar sind? Ich finde irgendwie keine sinnvollen Angaben dazu.

MfG

Dieser Beitrag wurde am 02.11.2013 um 17:26 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
03.11.2013, 14:02 Uhr
Enrico
Default Group and Edit

Ganz so genau steht das nicht da.

Da heisst es nur "Zeitverhalten siehe Byteausgabe".
Und dort dann das:

Da die Daten am Port vor aktivwerden von Ready (mit der nächsten fallenden Flanke) anliegen müssen, kannst Du von 1/2 Takt ausgehen.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
04.11.2013, 22:00 Uhr
kaiOr

Danke,

1/2 Takt ist ja noch überschaubar. In der Zeit macht die CPU 4 Takte bei 14Mhz. Verzögere ich nun das Hochtakten nach beendetem /IORQ oder IEO wird es aber auch nicht besser.

Auffällig ist, dass es meistens bei Soundausgabe passiert, z.B. im Spiel CAVE wenn ich an der Tunnelwand zerschelle oder bei LADDER wenn der Engel hochschwebt.

MfG

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
05.11.2013, 00:15 Uhr
Enrico
Default Group and Edit

Oder hast Du dabei eher ein Interrupt-Problem?
Das könnte ich mir auch noch vorstellen.
Die CPU macht 14 MHz, die PIO bleibt bei den 1,76 MHz.
Oder?

Die PIO liest doch den RETI-Befehl mit, den die CPU aus dem RAM holt.
Zwischen den 2 Befehlsteilen sind doch die Steuersignale kurzzeitig inaktiv.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
05.11.2013, 09:46 Uhr
kaiOr

Ja PIO und CTC bleiben auf 1,76Mhz, bekomme ich das im Grundgerät nicht in den Griff müsst ich auch jedes Modul umrüsten und jede Software anpassen.

Vielen Dank, wenn die PIO wirklich mitlauscht ist der Fall klar. Da wäre ich nie drauf gekommen.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
14.04.2014, 18:47 Uhr
kaiOr

Der RETI ist es leider nicht. Ob ich jetzt nach beendetem /INT, IEO oder /IOREQ noch zusätzlich 30 Takte auf 1,76Mhz hinlege ändert nichts. Inzwischen habe ich auch div. Laufzeitoptimierungen durchgeführt und einen der langsamen PROMs auf GAL getauscht.

RAMTEST3, FRACTAL4 etc.....laufen Stundenlang (effektiv ca. 5Mhz). Die Arbeit mit D004 macht auch richtig Spaß mit schnellem Terminal. Aber wehe es kommt Ton ins Spiel oder ich gebe in BASIC mal BEEP ein, dann hängt er fest.

Der Fehler tritt nicht auf wenn ich zum Refreshzyklus runtertakte. Aber dann pack ich effektiv nur ca. 3,3Mhz. Ich wollte den Refresh wegen evtl. gesteckter Module nicht ganz weglassen aber wenigstens gemäß dem neuen Takt ausdünnen.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]