Hallo,

.. irgendwie mach ich gerade 50% der Postings in dem Forum hier, übertrieb ichs auch nicht?

Ich bin dran eine COL256 zu bauen, die Teile hab ich zusammen, jetzt warte ich noch auf den Platinensatz (hab über Rene bestellt).

In der Vorfreude habe ich mir schonmal die Unterlagen angesehen, und mir ist das Speicherlayout noch nicht so 100% klar, zumindest was unkonventionelle Auflösungen angeht.

Das ist das RAM-Multiplexing was ich aus dem Schaltplan ermittelt hatte:



Im normalen 256 Pixel breiten Modus ist alles klar, der 6845 zählt auf seinen MA Leitungen pro Zeile von 0-64, dann die Zeilen auf RA0,RA1 hoch und das alles ist auf der RAS-Phase damit innerhalb von 4 Zeilen automatisch ein DRAM-Refresh stattfindet.

CPU fängt bei A2 an weil A0-A1 zur Auswahl des Pixels, von denen pro 6845-Zyklus 4 verarbeitet und herausgeschoben werden, verwendet werden.

So, jetzt zu den "nicht-100%-Klarheiten":

• Bei 512px 16Farben ist die Timing-Konfiguration 100% identisch zu 256px 256, aber in jedem 8bit Wert sind 2 "packed" Pixel drin nach:
  
  I1 I2 B1 B2 G1 G2 R1 R2 und der 74LS157 auf der Baugruppe C demultiplext das?
  
  
• In der LOOP 10 ist in einer Tabelle beschrieben, welche anderen Auflösungen (beispielsweise) möglich sind.
  
  
  
  Bei 320 horizontal würde der 6845 jetzt aber auf den MA-Leitungen bis 80 zählen, also MA6 dazunehmen. D.h. obwohl 320x200 noch in 64KB passen würde, sind die Pixeladressen nun nicht mehr konsekutiv im Speicher, sondern "verwürfelt"?
  
  Oder übersehe ich da etwas?
  
  
• Ganz generell, der Speicherzugriff ist zwischen CPU und Darstellung zeitmultiplext, und wenn die CPU anfordert schickt die COL256 ein WAIT bis ein "Zugriffsfenster" vorbeikommt, da es ja auch asynchron ist?
  
  

Gruß,
Christian

Ich lese Deine Beiträge gerne.

Wie funktioniert eigentlich die Sache mit BANKEN bei der COL256? Mir ist klar, dass man auf den Speicher nur in 16 k Bänken zugreifen kann und dass sie COL256 ihr eigenes Banking macht, aber wie wird das gesteuert?

Es ist schade, dass der NKC so wenige Adressleitungen hat. Hier hätte man sich einige Komplexität ersparen können.

Michael

Soweit ich es sehe:

Wenn man im Steuerregister J13 das "Einblenden" aktiviert, wird der Adressdekoder J27 freigegeben. Dieser kümmert sich erstmal um die 64k Bank. Das ganze wird dann noch mittels J20/J21 und J17 mit A14=A15=1 verknüpft um nur die $xC000-§xFFFF Bank zu selektieren und ja aktiviert dann über ein OC-Gatter die BANKEN Leitung.

Damit das funktioniert mussten ja die älteren Revisionen der BANKBOOT umgebaut werden auf OC mit Pullup, damit es dann ein Wired-OR ergibt.

In der Neuauflage kann die Verknüpfung mit A14/15 totgelegt werden um ganze 64KB Blöcke einzublenden, was beim 68000er ja möglich und spürbar komfortabler ist.



Gruß,
Christian

Moin Moin,

ich gehe mal davon aus, das es die COL256-Platinen von Sascha (sEn) sind.
Da gibt es einen kleinen Unterschied gegenüber dem Original. Und zwar werden immer 64kB Blöcke angesprochen! Diese Änderung ist in der Loop 8 Seite 27 beschrieben.

Im "normal" Betrieb (256x256 256Farben) ist der Speicher linear (bei mir $A0000-$AFFFF). Dieser Bereich wird durch ein Zugriff auf ein Register ($ffffffae) ein- oder ausgeblendet.

ACHTUNG: Wenn eine Bankboot im System ist muss das BANKEN-Signal Openkollektor haben!!!

PS: @Christian: Schön das es ausser mir noch weitere Schreiber im Forum gibt

-----------------------
Gruß
-=jens=-

Menno,
da hast du dir ja selbst geantwortet

-----------------------
Gruß
-=jens=-

Meine BANKBOOT ist auch schon eine Neuauflage die den OC schon drauf hat.

War es bei der Neuauflage nicht so, dass man Jumpern konnte obs 16 oder 64K-Blöcke sind?

Bei 256x256 ist es linear ja, bei 320x200 oder so verwürfelt es sich aber offenbar? (320x200 gefällt mir besser, weils näher an 4:3 ist )

.. jetzt habe ich aber das Problem, dass meine BUS3 vollgestopft ist

Gruß,
Christian

Hallo Christian,

bei der COL256 (mit 256 Farben) wird, wenn Du mehr als 256 Pixel pro Zeile hast, nach dem 256ten Pixel die nächste Zeile begonnen, bis 4 Zeilen mit 256 Pixeln voll sind, danach wird dann der 257ten Pixel in der ersten Zeile gesetzt und wenn die voll ist, kommt der Rest von den 256 in die fünfte Zeile, danach der Rest der zweiten Zeile, usw.

Gruß Bernd

Hallo Bernd,

ich hab mir mir das jetzt mal simuliert, das wird mühsam.

Statische Bilder kann man ja vorverarbeiten, wenn man aber etwas animieren will .. für jeden Pixel erst die Adresse ausrechnen ist ja ein massiver Performance-Verlust.

Aber gut, es ist halt eine nicht spezifikationsgemäße Nutzung .. hätten die nicht damals einfach einen Grafikchip mit anständigen Hardware-Sprites nehmen können?

Gruß,
Christian

Danke für die Erklärung, jetzt ergibt die Sache einen Sinn. Das ist ja ein grauenhafter Hack mit BANKEN!

Hätte man dem NKC einfach ein paar Adressleitungen mehr gegeben, könnte man die COL256 bei 8 bit Systemen mit dem normalen Banking addressieren und beim 68k direkt.

Michael

Naja, das war halt ein gewachsenes System .. das war ja erst nur dazu da, für CP/M ein Bootrom einzublenden .. und wurde dann immer weiter verwendet.

Am Latch der BANKBOOT sind drei Leitungen ungenutzt. Daran fehlt es also nicht.

Michael

Das größere Problem am NKC-Banking sehe ich darin, dass immer ALLES umgeschaltet wird und man nur das bisschen RAM auf der BANKBOOT konsistent über alle Bänke hat (und dass erst einblenden muss, was aber die ganzen 32KB der Bankboot über den Speicher klatscht).

Kommerzielle Geräte machten das besser:
Der C128 hatte eine konfigurierbare Common Area.
Der CoCo 3 hatte 8KB Blöcke die man beliebig auf 8x8KB Bereiche mappen konnte.
Der Spektrum 128K hat die oberen 8KB umschaltbar..

Wenn man also etwas aus den unteren 32K der Bank 0 in die unteren der Bank 3 schieben will ..

• Erst in den oberen Bereich der Bank 0 kopieren
  
• Bankboot einblenden (dabei darauf achten, dass man sich nicht sein Programm abklemmt)
  
• In das Bankboot-RAM kopieren
  
• Den Programmcode, der ja in den oberen 32K der Bank 0 sein muss, ebenfalls ..
  
• In die Version des Programmcodes im Bankboot-RAM springen
  
• Bank umschalten
  
• Programmcode in die neue Bank 3
  
• Dahin springen
  
• Daten in die Bank 3 kopieren
  
• Bankboot ausblenden
  
• Daten nach unten kopieren
  
• Wiederholen, bis alle Blöcke drüben sind.
  

Bei sowas wie dem COCO3 ..

• Quellbank in momentan freien Block mappen
  
• Zielbank in anderen freien Block
  
• Kopieren
  
• ggf. alte Mappings wiederherstellen
  
• Fertig.
  

Eine korrekte MMU mit kleinen Pages wäre natürlich die angenehmste Lösung. Der 68030 kann nach (sehr, muss weiterarbeiten) schnellen Googlen bis zu 256 Byte runter?

Ich sage eben die BANKBOOT war 95% dafür da, ein BOOTROM einzublenden. Das Banking war halt "wir haben ein paar Bit frei im Latch, was machen wir damit" und 20 Adressleitungen gibt es weil HD64180 und 68008 schon angedacht waren.

Der Vorgänger war ja die im grauen Buch beschriebene BANKSELEKT (oder BOOT?), die NUR die Einblendung des BOOTROMS/RAMs gemacht hat .. auf primitivste Weise:



Die konnte man nichtmal zurücksetzen, das war nur zum starten mit ein paar Byte RAM für einen temporären Stack.

Bei "grauenhafter Hack" stimme ich dir also zu, kann mir aber recht exakt vorstellen, wie es zu diesem kam

Gruß,
Christian

Stimmt alles! Und dennoch, warum nur bis A19?

Ich fing mal mit dem Design einer MMU für die 8 bit Systeme an, aber machte das nie fertig. Die Sache ist nicht wirklich schwierig, wenn man 16 KB Frames benutzt, was bei CP/M 3 Systemen sehr beliebt war. Fuzix liefe damit auch sehr gut. Man bekommt ein Design, wo man die MMU-Karte mit einem zweireihigen Stecker bauen muss, so dass der Bus zwischen dem Teil mit virtuellen und physikalischen Adressen getrennt wird.

Man wählt also mit zwei Bits einen Frame von 8 bit aus, d.h. man bekommt einen Adressraum von 4 MB. Die komplette Umschaltung von 3 Frames sind nur drei OUTs. Das wäre auch damals zu bauen gewesen und eine sehr schöne Darstellung für ein Lehrsystem, was der NKC ja teilweise war.

Michael

Zitat: Stimmt alles! Und dennoch, warum nur bis A19?

Keine Ahnung, "936KB sollte für jeden ausreichen?" vielleicht?

Zitat: Ich fing mal mit dem Design einer MMU für die 8 bit Systeme an, aber machte das nie fertig. Die Sache ist nicht wirklich schwierig, wenn man 16 KB Frames benutzt, was bei CP/M 3 Systemen sehr beliebt war. Fuzix liefe damit auch sehr gut. Man bekommt ein Design, wo man die MMU-Karte mit einem zweireihigen Stecker bauen muss, so dass der Bus zwischen dem Teil mit virtuellen und physikalischen Adressen getrennt wird.

Also sowas wie man es ohnehin für den 68000 gemacht hat, nur dass man statt der Datenleitungen den Adressbus teilt?

Was war deine Basis, irgendeine kommerzielle MMU oder etwas mit diskreter oder programmierbarer Logik.

Ich finde immer die Hardware ist nicht allzu schwierig zu designen, aber dann die ganze Software dazu und das noch für etwas, dass vermutlich niemand anderes je benutzen wird?

Ich hab gerade mal wieder den Z80 auf dem NKC gesteckt, aber die CP/M-Diskimages die so kursieren haben alle irgendwie ihre Macken und die Karten die HDD für Z80 ermöglichen habe ich nicht.

Gruß,
Christian

Ja, genau so wie beim 68000, nur mit geteiltem Adressbus, stellte ich mir das vor. Das war alles mit TTL Bausteinen gedacht, aber halt nie realisiert. Es gibt zwar ein paar MMU ICs, aber nichts was man heute noch ohne weiteres bekäme.

CP/M ist beim NKC eigentlich nicht schwer zu bauen, wenn man weiss, wie. Die Dokumentation ist nur eine Katastrophe. Ich habe das für die SDIO zusammentragen müssen und dort auch alles dokumentiert.

Mit einer MMU wäre CP/M 3, MP/M und evtl. Fuzix drin. Freilich alles sagenhaft viel Arbeit. Sicher auch viel Spaß, aber ich habe die Zeit nicht mehr.

Michael

Ich hab sowas "früher" (also vor 10+ Jahren) gern mit CPLDs gemacht, aber die guten alten XC9500 (ohne XL) die mit 5V liefen sind ja auch schon lange obsolet, und alles moderne ist wohl 3.3V oder weniger.

Wenn ich das richtig interpretiere hattest du 4 Basisregister, die jeweils einfach die Startadresse von den physikalischen Bereichen 0000-3FFF, 4000-7FFF, 8000-BFFF und C000-FFFF darstellten.

Dazu musst du ja bloss alles ab Bit 14 durch die Blocknummer ersetzen bzw. wenn du Überlappung willst halt addieren.

Also die Lösung die der CoCo3 hatte (da allerdings mit 8x8KB):

https://subethasoftware.com/2020/04/19/understanding-and-using-the-coco-3-mmu/

Gruß,
Christian

Ja, genau so dachte ich mir das, z.B. mit zwei 74HCT670, deren Leseadressen mit A14 und A15 und deren Schreibadressen mit A0 und A1 adressiert werden.

Dazu braucht man einen Weg, die MMU transparent zu machen und ein Flipflop dafür, was insbesondere beim Reset entsprechend gesetzt wird, sowie Treiber und Dekodierung zum Schreiben. Das ist alles zusammen theoretisch nicht viel.

Michael

Meine COL256 läuft übrigens (mit ein paar "Bodgewires")..



Das ist jetzt 256x256 .. nachher mal die 320x200 testen.
Jetzt Mittagspause vorbei, weiterarbeiten

Gruß,
Christian

Ja, funktioniert alles ..
320x200, 320x240, 320x480 interlace

Damit der Speicher im "Speicherbereiche" auftaucht, muss ich aber min. 1 CPU-Waitstate stecken, da scheint das WAIT zu lange zu brauchen?

Den Monochromausgang hab ich auch mal probiert aber der hat ja VIEL zuviel Pegel. Die Doku sagt da nix zu, gibts da eine Musterlösung?

Gruß,
Christian

Dumme(?) Frage: Welche Farbgrafik ist eigentlich in der GDP64-FPGA integriert? COL256 (+CLUT?)? Oder was anderes.

Gruß, Rene