Forum64

Quoted from "Diddl"

• Der CHAR Rom ist im normalen Adressbereich NICHT sichtbar.
  
  Also handelt es sich um einen eigenen Adressbus und Datenbus des Videocontrollers der nix mit der 6502 CPU zu tun hat.
  

Das ist richtig. Aus dem Char-ROM zieht ein mit 16Mhz getaktetes Shift-Register. Das kann man aus- und einblenden. Da liegt auch nicht das eigentliche Problem.

Quoted

[*]Der Datenbus zwischen Videocontroller, Char ROM und RAM:

Der Videocontroller schreibt nix ist also hochohmig. Im normalen Betrieb legt das ROM die Daten am Bus an. Durch CS Umschaltung kann das RAM diesen Job übernehmen.

Während der ATmega das RAM beschreibt, ist das ROM deaktiviert (CS) und das RAM über die WR Leitung als Eingang konfiguriert. Also in dem Fall (und NUR in dem Fall) kontrolliert der ATmega den Datenbus. Natürlich zeigt der Videocontroller in der Zeit wirre Zeichen an, ist ja egal. Schlimmstenfalls kann man ihn ja dunkel tasten.

[*]Der Takt bzw. die Geschwindigkeit des ATmega hat nix damit zu tun.

Die 74LS244 schalten den RAM weg vom Adressbus, sodass der ATmega in aller Ruhe ohne Timing Probleme Adressen anlegen kann die er will. Der Datenbus wird wird für die Zeit der RAM programmierung vom ATmega kontrolliert.
[/list]

Und hier liegt das Problem. Wie bekommst Du denn die Daten in den Mega ? - Dann aber höchstens über die 4bit vom Userport. Das ist aber eine etwas unelegante Lösung. Da braucht mal auf beiden Seiten umfangreichere Software.

Ich dachte erst, Du wolltest die Datenleitugen vom Mega abhorchen lassen, und dann parallel durchschieben.

Aber ja, ist evtl. machbar.

Michael

Diddl, Du bist auf dem richtigem Weg!

Das Flash des Atmels bietet reichlich Platz - da bekommst Du die 2 KB für den Standardzeichensatz sicher dicke unter. Dann kannst Du das SRAM bei power-on mit dem Standardzeichensatz initialisieren und Dir das EPROM sparen.
Statt über den Userport würde ich das Interface an einen der beiden ohnehin selten genutzen Kassettenanschlüsse legen. Das hat außerdem den Vorteil, daß Du Dir den Code für das serielle Protokoll direkt von den C2N232-Routinen besorgen kannst: http://www.ktverkko.fi/~msmakela/8bit/c2n232/

Unter'm Strich hättest Du damit eine 4-Chip-Lösung - sehr elegantes Design!

for(;;) :
Ich weis nicht. Externes I/O für eine interne Schaltung verwenden, die die man eigentlich viel einfacher ins System einschleifen kann. Dazu noch Software auf beiden Seiten zum Betreiben der MEGA RISC CPU, die die zigfache Rechenleistung des ganzen CBMs hat. Und das ist elegant, weil man ein paar Bauteile weniger braucht ?

Ich werde wohl alt ... ;)

Michael

Quoted from "cbmhardware"

Ich weis nicht. Externes I/O für eine interne Schaltung verwenden, die die man eigentlich viel einfacher ins System einschleifen kann. Dazu noch Software auf beiden Seiten zum Betreiben der MEGA RISC CPU, die die zigfache Rechenleistung des ganzen CBMs hat. Und das ist elegant, weil man ein paar Bauteile weniger braucht ?

Ich werde wohl alt ...

Als ich das gelesen hatte, musste ich herzlich lachen...!

Also... wenn mir jemand von einem Rechner erzählen würde, bei dem sie "damals" über einen I/O-Anschluß über ein serielles Protokoll Daten über einen Co-Prozessor in ein SRAM geschaufelt haben, das sowieso im Rechner liegt und sicher irgendwo einzublenden gewesen wäre, hätte ich spontan gefragt, ob die Entwickler damals nur besoffen gewesen waren!

Aber...

Ich denke, erst einmal ist es eine Frage des Stils: kann man / darf man / soll man so neue Technik (z.B. 20 MHz RISC CPU) in so alte Rechner einbauen. Ich glaube, die Grenzen sind sehr fliessend und jeder Bastler muß das für sich selbst entscheiden.

Wenn man die Frage mit ja beantwortet (was ich in diesem Fall nicht getan hätte, aber es ist sein Design, nicht meines), dann erkenne ich, daß dieser Weg eine Handvoll Vorteile bietet: nicht nur weniger Chips, sondern vor allem mehr Portabilität und Komfort bei der Entwicklung.

Die ganz alten CBMs haben eine andere Memory-Map als die neueren. Die 8096er haben wieder eine andere Memory-Map. Ich habe das nicht überprüft, aber ich bin mir nicht sicher, ob der FPLA-memory-decoder im 8096 / 8296(D) die Lösung ohne weiteres erlaubt, einen ROM-Sockel schreibbar zu machen, die Du gepostet hast. Wenn ich mich richtig erinnere, wird je nach Konfiguration das ROM nur für LESE-Zugriffe eingeblendet, nicht aber für Schreibzugriffe. Der Chip würde also bei Schreibzugriffen gar nicht selektiert, da nützt es auch nichts, wenn Du Dir noch R/W irgendwo her holst.
Und wenn er doch selektiert würde, und Du dann über angeflanschte TTL-Logik ein SRAM beschreibst, wäre zu prüfen, ob und wenn ja wo diese Daten noch im Speicher landen - nur im SRAM oder nicht auch noch (was ich befürchte) irgendwo in den 128KB des 8296. Das ergäbe möglicherweise Inkompatibilät mit LOS 96. In jedem Fall blockiert es den Sockel für Erweiterungs-ROMs - oder bläht die Hardware weiter auf, wenn Du zwischen Erweiterungs-ROM und SRAM umschalten möchtest.

Du musst also zig-Memory-Maps beachten - einen Kassettenport oder Userport haben dagegen alle CBMs.

Die Entwicklungswerkzeuge für die Atmels sind äußerst komfortabel, die Dinger sind sehr preiswert und bei einer so primitiven Schaltung mit gerade einmal 4 Chips käme sogar eine einseitige Platine oder sogar selbst fädeln in Betracht.

Und das serielle Protokoll muß man auch nicht erst erfinden, sondern ist schon fix und fertig.

Ist die Schaltung erst einmal fertig, ist diese 4-Chip-Lösung für andere viel leichter nachzubauen oder viel leichter zu bezahlen, als ein klassisches TTL-Grab - ich finde, das ist auch ein Vorteil.

Schlußendlich möchte ich persönlich aber keine Atmel in meiner Ein-Mega-Hertz-Maschine haben. Nicht dafür jedenfalls.

Quoted

Wenn ich mich richtig erinnere, wird je nach Konfiguration das ROM nur für LESE-Zugriffe eingeblendet, nicht aber für Schreibzugriffe. Der Chip würde also bei Schreibzugriffen gar nicht selektiert, da nützt es auch nichts, wenn Du Dir noch R/W irgendwo her holst.
Und wenn er doch selektiert würde, und Du dann über angeflanschte TTL-Logik ein SRAM beschreibst, wäre zu prüfen, ob und wenn ja wo diese Daten noch im Speicher landen - nur im SRAM oder nicht auch noch (was ich befürchte) irgendwo in den 128KB des 8296. Das ergäbe möglicherweise Inkompatibilät mit LOS 96. In jedem Fall blockiert es den Sockel für Erweiterungs-ROMs - oder bläht die Hardware weiter auf, wenn Du zwischen Erweiterungs-ROM und SRAM umschalten möchtest.

Das mit dem Beschreiben eines SRAM in den Erweiterungssteckplätzen ist von Jogi und Compirudi überprüft worden. Ist ja eigentlich auch ganz banal. Wenn man das /CS, R/W und die passende Phase von der Clock hat, müsste der Rechner schon sehr defekt sein, wenn man woanders landen will. Wenn jemand sehr schmerzfrei ist und heute noch LOS96 benutzen möchte, kann er sich doch einen Abschalter an die Erweiterung bauen.
Ich hatte vor einigen Jahren eine linear adressierbare Erweiterung gebaut, damit man sich nicht mit dem alten Murks rumärgern muss.

Quoted

Du musst also zig-Memory-Maps beachten - einen Kassettenport oder Userport haben dagegen alle CBMs.

Den Userport halte ich mir gerne für die Datenübertragung von anderen Rechnern frei. Zudem wird dort auch gerne mal ein Joystick angeklemmt. Das könnte zu lustigen Effekten bei einer internen Erweiterung führen.
Ich finden den Cassetten-Port dann eine bessere Lösung. Davon hat man zwei. Wobei ich im Moment unsicher bin, ob auch beide nutzbar sind.

Quoted

Die Entwicklungswerkzeuge für die Atmels sind äußerst komfortabel, die Dinger sind sehr preiswert und bei einer so primitiven Schaltung mit gerade einmal 4 Chips käme sogar eine einseitige Platine oder sogar selbst fädeln in Betracht.
Und das serielle Protokoll muß man auch nicht erst erfinden, sondern ist schon fix und fertig.

Ist die Schaltung erst einmal fertig, ist diese 4-Chip-Lösung für andere viel leichter nachzubauen oder viel leichter zu bezahlen, als ein klassisches TTL-Grab - ich finde, das ist auch ein Vorteil.

Die Kosten sprechen ganz klar für einen Atmel. Üblicherweise scheitern viele solcher Projekte an der Software. Warten wir einfach mal ab.

Quoted

Schlußendlich möchte ich persönlich aber keine Atmel in meiner Ein-Mega-Hertz-Maschine haben. Nicht dafür jedenfalls.

Darf auch auch mal kurz kichern ? ;)

Michael

Erst einmal sorry, daß ich diesen alten thread wieder recycle... jedenfalls habe ich so ein Ding jetzt gebaut!
Danke an Diddl und cbmhardware - ohne Eure Ideen wäre das so nie gediegen!

Ich habe eine Lösung ab 3 Chips gefunden ohne serielles Protokoll oder RISC-CPU ;-)

Ein IDT7130 1K x 8 Dual-Port-RAM, 74HCT139 und ein 74HCT74 - und als Luxus noch ein zweites IDT7130, damit ich auch bei meinem selbstdefinierten Zeichensatz mit POKE 59468,12 / 14 den Zeichensatz umschalten kann.

Leider hat sich meine Ahnung bestätigt: im 8296 bekommt der ROM-Sockel nur für Lesezugriffe ein Chip-Select, da werde ich mir noch ein neues 27512 für UE6 brennen müssen. Im 3032 funktionierts aber schon.

Bilder, Schaltplan etc. folgen... ich brauche jetzt erst einmal etwas Schlaf und dann wollen Freundin und Kinder bespaßt werden...

Dankeschön!

Mit dem "Das will ich auch haben!" müssen wir mal gucken, wie wir das machen. Auf meine Platine soll noch der NEC 7220 Grafik-Prozessor und ein Zilog Z180 für ein CP/M-System in meinem 8296 - ob und inwieweit Du oder andere daran noch Interesse haben und was dann alles auf eine (print-) Platine soll, muß man dann gucken. Anybody?

Anbei habe ich den Schaltplan und ein paar Bilder gehangen. Im Schaltplan tauchen leider noch ein paar seltsame "A0" und "jkhjkh" auf, die komischerweise nur im Druck bzw. als PDF sichtbar sind - ich weiß leider noch nicht, wie ich die entfernt bekomme.

Zu sehen ist auch mein Assistent "Sally", der eine tragende Rolle beim Testen meiner Schaltung übernahm - die SK-Gehäuse tragen nicht umsonst den Spitznamen "Sch****-Kisten"...

Neben dem 8296-Support fehlt natürlich auch noch ein brauchbarer Character-Editor, der erst noch programmiert werden will - für Anregungen aller Art bin ich natürlich dankbar!

CHARGEN.pdf

Coole Sache dieses Projekt.

Ein großes Lob an for(;; ) and natürlich auch an Sally

Falls man die Platine irgendwann mal bestellen kann: Ich bin dabei.

Jein, müsste dann schon einer sein, der in BASIC programmiert ist, und der müsste auch erst noch an die anderen Gegebenheiten angepasst werden... ist vielleicht leichter, direkt einen selbst zu schreiben - aber ich gucke mal.

Fünf Stück für 10 Euro ist ein Super-Kurs. Ich hätte als Quelle nur irgendwas an die fünf Euro pro Chip anzubieten gehabt. Also schnell zuschlagen!

Quoted from "Diddl"

Hab die Fünf ...

Glückwunsch zu Deinem Schnäppchen! Dann hast Du das wesentlichste Bauteil ja schon mal erstanden!

Quoted from "Diddl"

Hast du da zwei 1K dual ported auf deiner Lochraster? 1K sollte eigentlich genügen? Oder erlaubst du 256 Zeichen statt nur 128 und 128 invers?

Ein Zeichensatz belegt 1 KB. Daher würde EIN IDT7130 im Grunde genügen, um einen benutzerdefinierten Zeichensatz zu verwenden. Ich habe zwei vorgesehen, da mein CBM 8296 mit DIN-Zeichensatz daherkommt, der sich neben den Umlauten auch bei ein paar Grafik-Zeichen unterscheidet - viele Spiele werden damit leider bis zur Unkenntlichkeit entstellt.
Das zweite IDT7130 erlaubt es, ZWEI benutzerdefinierte Zeichensätze (in diesem Fall die original US-amerikanische Fassung) in jeweils ein RAM zu legen und wie bisher auch mit POKE 59468,12 für den ersten Zeichensatz bzw. POKE 59468,14 für den zweiten Zeichensatz umzuschalten - damit würden dann meine Spiele endlich so aussehen, wie sie sollen.
Wer diesen Zeichensatz sowieso hat (und damit mein Problem nicht) und nur einfach mal selbstdefinierte Zeichen haben möchte, kann sich ja einfach eine neue Belegung laden, wenn er was anderes haben will - deswegen habe ich den Schaltplan so gehalten, daß er sowohl mit einem, als auch mit zwei RAMs ausgestattet werden kann.
Wenn ein RAM ausgelassen wird, muss das andere RAM in beiden Fällen angesprochen werden - sonst wäre bei nur einem RAM nach einem POKE 59468,14 nix mehr auf dem Schirm.

256 Zeichen statt nur 128 zu erlauben geht so einfach leider nicht, weil das 7. Bit dafür verwendet wird, die Invertierung zu steuern - und das in Hardware, nicht in Software. Es wird gar nicht an den Zeichensatzgenerator herangeführt, sondern geht an ein Flip-Flop. Deswegen sind leider nur maximal 128 verschiedene Zeichen zur selben Zeit möglich.

Quoted from "Diddl"

Mit einem 8K dual ported RAM könnte man "echte" Hires Grafik machen. Man müsste nur wahlweise den Adressbereich an das Char RAM durchreichen und den Bildschirmspeicher mit einer Folge füllen (1, 2, 3, 4, ... 255).

Vorausgesetzt, man möchte eine Erweiterung und keinen PET-Umbau können wir am Takt des Video-Schieberegisters nichts ändern. Damit ist die horizontale Auflösung bei einem 80-Zeichen-CBM mit 80 x 8 = 640 Pixel und bei einem 40-Zeichen-CBM mit 40 x 8 = 320 Pixel festgelegt.
8 KB bietet bei monochromer Darstellung Platz für 8192 x 8 = 65536 Pixel. Bei einer horizontalen Auflösung von 640 Pixeln hätten wir 65536 / 640 = 102 Zeilen vertikal, bei 320 Pixeln immerhin 204. 320 x 200 wäre für einen 40er ja ganz okay, aber bei einem 80er sollten es schon 16 KB sein um 640 x 200 zu erlauben.

Von der Idee, den Bildschirmspeicher mit einer Folge zu füllen um ihn dergestallt als Counter zu verwenden, war ich spontan begeistert!

Es bleibt aber der Umstand zu berücksichtigen, daß das siebte Bit aufgrund o.g. Eigenart nicht verwendet werden kann - damit hätten wir einen 7-Bit-Zähler mit den Zahlenfolgen von 0-127.
3 Bit Row-Counter an A0 bis A2, 7 Bit aus dem Char-Gen-RAM an A3 bis A9, dann hätten wir zehn Adressleitungen oder 1 KB. Mit einem weiteren 4-Bit-Zähler könnte man das bis auf die 16K aufblasen. A10 am Char-Gen müsste man dazu schaltbar machen, auf GRAPHIC (dieses Signal wählt eines der beiden Zeichensätze aus) im Textmodus oder auf den niederwertigsten Zählerausgang im Hi-Res-Modus.

Diese 8 oder besser 16KB Video-Speicher sollten möglichst am Stück irgendwo im Speicher adressiert werden können, ansonsten bezahlt man das bitter bei der Implementierung von Grafik-Routinen. Wenn z.B. eine Linie gezogen werden soll, und die Routine erst mühsam ermitteln muß, in welcher Scheibe der nächste Pixel geändert werden muss, wird's gähenend langsaaaam...
Wo man 16 KB mal eben unterbringt, wäre die Frage... vielleicht könnte man das auch in den Bereich des Systems legen und Schreibzugriffe auf das RAM geben, Lesezugriffe je nach eingestellter Bank auf das ROM oder das Video-RAM.

Quoted from "Diddl"

Man könnte eigentlich statt des ROM Sockel auch den "normalen" bildschirmspeicher verwenden. Also zb. von $8400 - $87ff. Dann wäre der ROM Bereich wieder frei, ich habe da Exbasic drin oder einen Exmon. Schreibt der 6502 halt in beide RAM rein ...

Das würde natürlich auch gehen, zumindest für die ein oder 2 KB eines Zeichensatzes. Für 8 oder 16 KB eines Hi-Res-Modus natürlich nicht. Mir ist kein Programm bekannt, daß die mehreren Bildschirmseiten eines 8296 nutzt - von daher dürften keine Seiteneffekte zu erwarten sein. Dann kommen eben noch ein paar Chips dazu, um ein Chip-Selekt für das RAM zu generieren.

Bei einem 8296 hast Du ja zwei freie Sockel, ab $9000 und ab $A000. Brauchst Du denn beide zur selben Zeit? Meinem CHARGEN ist es ja egal, in welchem Sockel es eingesteckt wird - wenn Du einen Sockel hast, den Du sowieso nicht brauchst, kannst Du ja in den das CHARGEN stecken.

Quoted from "Diddl"

Aber auch wenn der ROM Breich verwendet wird, - man muss das Charram ja nicht lesen können! Im Grunde könnte man aus dem ROM lesen und beim Schreiben in den Bereich in das dual ported gehen.

Das ist eine ganz hervorragende Idee! Das muß ich zwar beim Editor des Zeichensatzes berücksichtigen, aber das ist ja kein Problem. Das werde ich auf jeden Fall berücksichtigen. Ein Schalter, der bestimmt, ob bei Lesezugriffen das RAM oder ein EPROM in einem anderen Sockel selektiert werden soll.

Nach einiger Überlegung kam ich zu dem Schluß, die Variante mit 8 oder 16 KB Dual-Port-RAM für Hi-Res-Grafik nicht weiter zu verfolgen. Wenn ich gleichzeitig Text- und Grafikmodus haben möchte, bräuchte ich ja zwei 8-KB-Dual-Port-RAMs und noch mindestens ein weiteres 1-KB-Dual-Port-RAM, deren Ausgänge ODER verknüpft würden.
Für den NEC 7220 brauche ich nur zwei I/O-Register, die ich in den Bereich des Control-Ports legen kann, die vierte 1 KB-Bank. Dann schreibe ich einfach in das FIFO des 7220 die Befehle, zeichne mir diese Linie, zeichne mir jene Linie, mach dies, mach das und der arbeitet das dann der Reihe nach ab - schneller als das jeder 6502 könnte und ohne, daß ich mir eine Grafik-Bibliothek in Assembler erstellen müsste. Und Kopfzerbrechen, wo ich die 16 KB unterbringe, oder wie ich das Bank-Switching realisiere, muß ich mir dann auch nicht machen. Der NEC 7220 verwaltet seinen Video-Speicher selbst, daher muß der nirgends eingeblendet werden. Alle Kommunikation findet über die zwei Ports statt.

Ich habe seit gestern einen Nachmieter, was bedeutet, daß ich jetzt sehr kurzfristig zum Ende diesen Monats umziehe - ich fürchte, in den nächsten Tagen und Wochen werde ich kaum Zeit haben, diese Sache weiter zu beackern - und das ausgerechnet jetzt, wo's richtig spannend wird! :-(

Laß mich auf jeden Fall wissen, welche Anforderungen das CHARGEN für Dich haben muß, dann werde ich den Schaltplan entsprechend anpassen. Wenn noch jemand Interesse daran hat und vielleicht weitere Anforderungen hat, möge er bitte jetzt sprechen oder für... :-)