Nachfolger des RR-Net

Zitat von jackdaniels

also kein netzwerk am amiga damit möglich? kein netzwerk am a500?

Für 100MBit Netzwerk am A500 mit ACA520 habe ich eine andere Idee. Dafür wird der lokale Expansionsport der ACA520 aufgebohrt und eine andere Netzwerkkarte entwickelt. Es hat sich herausgestellt, dass der Wiznet-Chip für den Amiga überhaupt nicht geeignet ist - zu langsam und zu eingeschränkt. Für den C64 super, aber für den Amiga gibt es schon einen erwachsenen TCP/IP Stack, da muß man nichts mehr mit Hardware kaspern, die letztlich nur Einschränkungen einführt.

Jens

Nur 8K, und die auch nur um $8000-Bereich. Zusätzlich sind im Clockport-Mode ein paar wenige Bytes des ROM sichtbar, damit die MAC-Adresse nicht immer manuell eingetippt werden muss.

Die 8K dienen als Hardware-Init, inklusive DHCP, nameservice und early-bootloader, der immer eine feste URL anfährt um dort das *eigentliche* Programm zu holen. Ram wird eingeblendet in 32K-Bänken zwischen $4000 und $c000, insgesamt gibt es davon 4 Bänke, was ausreichen sollte, um einen minimal-Browser basierend auf dem hier zu machen. So müsste sich eigentlich etwas basteln lassen, was sich anfühlt wie "the internet is my harddrive", aber trotzdem keine Kenntnisse benötigt in Sachen "wie starte ich ein Spiel".

Jens

Als ich gestern geschrieben habe, dass der Chip zu langsam für den Amiga ist, meinte ich damit den 8-Bit schmalen Bus. Damit könnte ich am Amiga nur einen Bruchteil der Daten übertragen, die _eigentlich_ über das Netzwerk kommen könnten. Der Wiznet Chip ist nämlich ein 100MBit Chip, also auf jeden Fall schneller als das alte RR-Net. Nicht, dass das am C64 irgendeine Bedeutung hätte

Ein Kernal am Expansionsport kann ich auf der Karte nicht unterbringen. Ich habe schon ziemliche Verrenkungen gemacht, um überhaupt Ram und Rom unterzugringen, da blieb kaum Platz für einen großen Logikchip. Die Logik ist komplett in einem 16V8 untergebracht, der auch noch an einer ungünstigen Stelle auf der Platine liegen muß, weil er sich sonst mit den hohen PLCC-Chips des MMC Replay ins Gehege kommt.

Das Einblenden zwischen $4000 und $c000 mache ich wirklich mit Ultimax, und es ist der geringen Logikmenge im 16V8 geschuldet: Ich hatte einfach nicht genug Banking-Bits, deswegen musste ich den eingeblendeten Block vergrößern. Auch die Programmierung der Register wird etwas ungewöhnlich. Ob das alles wirklich so funktioniert wie ich mir das vorstelle, muß sich erst noch mit dem nächsten Prototypen herausstellen. Ich bin momentan noch dabei, die Logik vorzubereiten - die soll erstmal komplett durchkompilieren, bevor ich die Platine bestelle, denn "umverdrahten" geht auf einer 4-Lagen Multilayerkarte nur _sehr_ eingeschränkt.

Jens

Mahlzeit,

die Logik kompiliert jetzt durch - ich musste noch ein paar Pins tauschen, aber jetzt passt's auch in ein GAL16V8. Neue Musterplatine ist bestellt, kommt spätestens nächste Woche. In Anhang die aktuelle Software-Beschreibung, für die ich gern von den Codern hier nen Kommentar hätte. Ich hatte zwischendurch mal ne Version, bei der RAM noch nach $dfxx gespiegelt werden konnte, aber da wir keinen Freezer bauen wollen, braucht man an der Stelle auch keinen Speicher. Oder doch?

Jens

Zitat von Diddl

Das Banking ist echt gewöhnungsbedürftig, aber vollkommen ok.

Es gibt in einem 16V8 halt extrem wenig Logik, sehr wenige Pins und keiner von denen "registered", weil sonst zwei Input-Pins wegfallen. Da muß man sich halt was einfallen lassen

Zitat von Diddl

Ich fänds gut, da könnte man Code lagern, mit dem man das RR-Net bedient, quasi ein API oder eine Art Driver wie man heute sagt.

Das Problem mit $dfxx ist, dass dort evtl. andere Dinge liegen, wie z.B. eine REU oder ein zweiter SID. Außerdem wäre es nur dann interessant, wenn dieser mirror-Bereich auch dann sichtbar ist, wenn der "normale" RAM-Bereich abgeschaltet ist. Was nicht gehen wird (aufgrund der eingeschränkten Logikmenge) ist, gleichzeitig ROM bei $8000 und den RAM-Mirror bei $df00. Mit der aktuellen (und per Definition unveränderlichen!) Verdrahtung würde bei eingeschaltetem ROM in $df00 entweder auch ein ROM-Mirror auftauchen, nämlich von $9f00, oder gar nichts - hier kann man sich nich die sinnvollere Variante auswählen.

Um's zu entschärfen könnte ich den $df00-Bereich read-only machen. Das wäre ohnehin hilfreich, denn dann kann Software nur dann etwas im RAM überschreiben, wenn sie das vorher auch wirklich eingeschaltet hat. Ein Stück Software das einfach nur auf $dfxx herum-probe'd um herauszufinden welche Hardware evtl. angeschlossen ist, würde keinen Schaden anrichten. Noch weiter entschärfen könnte man's, wenn man nur eine oder zwei der vier Bänke in dem Bereich sichtbar machen kann. Auf die Weise könnte man vor dem Setzen des Shutup-Bits auch entscheiden, ob der $df00-Bereich sichtbar bleiben soll.

Zitat von Diddl

Wenn das RAM aktiv ist, ist das kompromisslos, es kämpft mit eventuell vorhandenen anderen Speicher (interner RAM, BASIC ROM) um den Datenbus? Oder ist man automatisch im Ultimax Modus? Ist das nicht gefährlich für C64 Komponenten? Der angekündigte CPU Crash kommt mir noch harmlos vor.

Es wird automatisch und Zyklus-für-Zyklus in den Ultimax Mode geschaltet. Wenn die CPU außerhalb des RAM-Bereiches zugreift, wird keinerlei Veränderung in der Memory Map vorgenommen und es ist alles so wie man's von einem C64 kennt. Innerhalb des Bereiches $4000 bis $bfff wird auf Ultimax umgeschaltet und RAM eingeblendet. Da im Ultimax innerhalb dieses Bereiches überhaupt kein Gerät auf den Bus gelassen wird, kämpft da auch nichts, sondern RR-Net MK3 sorgt dafür, dass der Bus wirklich frei ist. Keinerlei Gefahr.

Der "angekündigte CPU crash" kommt einfach daher, dass der C64-Speicher (RAM und ROMs) abgeschaltet wird, und man evtl. nicht weiss, was dafür eingeblendet wird. Besonders findige Coder können sicherlich coole Routinen erdenken, die sich selbst weg-mappen und dann nahtlos im expansion-Ram weiter laufen, aber mit der Riesenmenge Speicher die es jetzt insgesamt gibt, erscheint mir das nicht wirklich notwendig.

Jens

Neuer Prototyp ist da. Zwar noch nicht ganz auf Herz und Nieren geprüft (muß noch an anderen Boardrevisionen testen), aber das Wichtigste geht schonmal:

- 8 bytes EEPROM sind im Clockport mode sichtbar (für MAC Adresse)
- im expansion port mode startet es als 8k Cartridge
- EEPROM kann beschrieben werden und ist nach dem Start sauber schreibgeschützt
- RAM kann eingeschaltet und beschrieben werden, ohne dass der C64-Speicher getrasht wird
- RAM wird nach $dfxx gespiegelt wenn "shutup mode" eingeschaltet wird (trampoline code, Vektoren)
- Wiznet chip kann im clockport- und expansion port mode initialisiert werden, beantwortet PINGs

Ein neues Inside_RR-Net_MK3 gibts auch.

Das neue Board ist ein paar Zehntel kleiner als der erste Prototyp, damit's etwas luftiger mit Chameleon und MMC Replay passt. Und es geht ziemlich kuschelig zu auf dem Board:
RR-Net_MK3_Proto.jpg
RR-Net_MK3_on_Chameleon.jpg
RR-Net_MK3_on_Chameleon2.jpg
RR-Net_MK3_on_MMCReplay.jpg
RR-Net_MK3_on_NordicReplay.jpg

Weitere Tests folgen, ich halte Euch auf dem Laufenden

Jens