Hello, Guest the thread was called68k times and contains 324 replays

last post from Zaadii at the

Nachfolger des RR-Net

    Quote from 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

    Quote from Wiesel

    Der bekommt nämlich ein Bootrom und ein bischen RAM, damit man keine Treiber mehr von Disk laden muß.


    Klasse, das klingt gut.


    War da nicht mal eine Diskussion über Kernel Ersatz am Userport? Was ist denn da raus gekommen? DAS wäre DIE Kombination mit dem RR-Net Nachfolger. Kernel Ersatz, und zwar 16K geswitched, damit man weder auf Kassette noch seriellen Routinen verzichten muss.


    Und Unit 6 als ethernet device, dann würde man sowas wie

    Quote

    LOAD "MYDOMAIN/C64/JUMPMAN.P00",6

    realisieren können. :juhu:



    Wer schon mal "üben" will mit dem W5100, kann sich ja mal das Arduino Shield angucken ...

    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

    Quote from Wiesel

    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.


    128K RAM, das ist ja supergenial!


    Zwischen $4000 und $c000? Wie geht denn das, ach so im Ultramax Mode natürlich. Gefällt mir, ich will so ein Modul auf jeden Fall!



    Browser, FTP, Telnet, wäre alles denkbar. Internet als Festplatte, für single File Sachen.


    Wenn man am PC ein Server Programm schreibt, dann könnte man auch sowas wie ein SD2IEC hinkriegen. Mit D64 Support und einfache Floppy Befehle, U0 und U1, solche Sachen halt. Und natürlich einem Befehl die richtige Diskette aus einer riesigen D64 Bibliothek einzulegen. Natürlich nur für Programme, die sich an die Kernel Routinen halten ...

    Quote from thosch97

    Das mit dem Netzwerk klingt doch gut! 10 Mbit dürfte ja locker Schnell genug für den CBM-Bus sein oder?


    Du machst Witze, 10 Mbit kann bis zu 1MB pro Sekunde übertragen (1.000.000 Byte), der CBM Bus 400 Byte. Selbst 64K pro Sekunde sind für einen C64 gigantisch.

    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

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


    Quote

    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?


    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.



    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.



    Ich find das Teil super!

    Quote from 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 :-)


    Quote from 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.


    Quote from 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

    Elegant gelöst. Ein kleiner GAL für all diese Funktionalität, das erscheint mir meisterlich!



    Quote from Wiesel

    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


    Dann lieber gar nichts. Zusätzlich bringt aus meiner jetzigen Sicht eigentlich nicht viel. RAM oder ROM wenn es sonst ausgeblendet ist würde es erleichtern, es wieder zu aktivieren mit einem simplen SYS. Aber dazu kann man ja auch ganz einfach einen Reset machen.



    Tolle Sache das Modul! :thumbsup:

    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