Netzwerkchip wie IDE direkt am 68k BUS

[tuxie]

Hallo,

ich bin auf der Suche nach einer Netzwerkläsung die nicht den Romport belegt und dennoch schnell ist.

Ich habe mir intensiv die Beiden Projekte EtherNEA und EtherNEC angeschaut. Und da ich auch schon mit Microcontrollern gearbeitet habe bin ich der Meinung das man es hinbekommen sollte den RTL8019AS direkt an den Bus zu schliessen wie es auch beim IDE Interface gemacht wird. Was benötigt wird ist ein Freier Speicherplatz im Hauptspeicher und einen Angepassten Treiber. Ich habe mir dazu die Sourcen des Ethernec/Ethernea und ISA Adapter Treiber von Dr. Thomas Redelberger angesehen.
Theoretisch sollte es möglich sein, diese anzupassen  und auf den enstprechenden Speicherbereich zu mappen. Adressdecoder dafür sollte nicht das Problem darstellen.

Ethernet für Hades

Code: [Auswählen]

*********************************************************************************
* Bus access macros for Hades for register base hardware on the ISA bus *
* This hardware supports all(?) NE2000 (clone) cards *
* *
* Copyright 2002 Dr. Thomas Redelberger *
* Use it under the terms of the GNU General Public License *
* (See file COPYING.TXT) *
* *
* processor registers are used as follows: *
* *
* a5: will point to ISA_BASE+NE_IO_BASE ; do not change it! *
* a6: will be used temporarily *
* *
* *
* Tabsize 8, developed with DEVPAC assembler 2.0. *
* *
*********************************************************************************
* $Id$
*

* From the Hades Manual:
*
* Der Hades hat ja neben 4 PCI auch 2 ISA Schnittstellen.
* Die sind folgendermassen dokumentiert:
*
* ISA-Bus
* *********************************************************************
* DMA wird auf dem ISA-Bus nicht untersuetzt. Saemtliche Interruptsignale
* eines Slots sind zusammengefasst und werden der STMFP zugefuehrt.
*
* Slot        STMFP-Anschluss
* -------------------------------
* ISA1        IO3 Pin 28
* ISA2        IO7 Pin 32
*
* Bei Byt-Zugriffen im I/O-Bereich $FFF3'0000 - $FFF3'FFFF werden die
* Byts beim Lesen und beim Schreiben von und nach SD0-7 transferiert,
* sowohl bei high wie auch by low Byt Zugriffen. Dies ist z.B. fuer
* ET4000 Grafikkarten mit NVDI noetig.
* Im Rest dieses Bereichs wird beim Schreiben das Byt auf der anderen
* Wordhaelfte ebenfalls ausgegeben.
* 
* Adressen I/O    : $FFF0'0000-$FFF7'FFFF
* Adressen Mem    : $FF00'0000-$FF7F'FFFF
* Bus-Breite    : 16 Bit
* Groesse I/O    : 8x64 KiloByt gespiegelt
* Groesse Mem    : 8 MegaByt
* Burstmode    : Nein
* Transferrate    : 5-?
* Cachable    : Normal Nein, aber moeglich
*


*
* manifest constants
*

BUGGY_HW EQU 1 ; if defined enables code to handle buggy hardware

*
* hardware addresses
*

ISA_BASE EQU $FFF30000 ; ISA base address for Hades
NE_IO_BASE EQU $300 ; if your card is somewhere else change it.

*
* macros
*



Code: [Auswählen]

*********************************************************************************
* Bus access macros for ST/TT ACSI bus for register base hardware *
* Version for my ACSI-NE2000 interface hardware in slow mode (with the 74xx74 *
* D-flip flips for old NE1000 and older NE2000 (clone) cards *
* *
* Copyright 2002 Dr. Thomas Redelberger *
* Use it under the terms of the GNU General Public License *
* (See file COPYING.TXT) *
* *
* processor registers are used as follows: *
* d0: as ACSI is w. and you mostly need b. d0 stores intermediate *
* d6.w: will contain $88; do not change it! *
* d7.w: will contain $8a; do not change it! *
* *
* a5: will point to dmamodus; do not change it! *
* a6: will point to diskctl; do not change it! *
* *
* *
* Tabsize 8, developed with DEVPAC assembler 2.0. *
* *
*********************************************************************************
* $Id: buseneas.i 1.3 2002/06/08 16:26:52 Thomas Exp Thomas $
*

*
* manifest constants
*

TheACh EQU $60 ; ACSI channel of NE hardware (=3)
NilACh EQU 0 ; inactive ACSI channel used to deselect the
; ACSI/ISA hardware
BUGGY_HW EQU 1 ; if defined enables code to handle buggy hardware

*
* hardware addresses
*

gpip EQU $fffffa01 ; (b) 68901 input register (unused)

diskctl EQU $ffff8604 ; (w) disk controller data access
dmamodus EQU $ffff8606 ; (w) DMA mode control
dmahigh EQU $ffff8609 ; (b) DMA base address high (unused)
dmamid EQU $ffff860b ; (b) DMA base address medium (unused)
dmalow EQU $ffff860d ; (b) DMA base address low (unused)


*
* addresses of system variables
*

flock EQU $43e ; (w) semaphor to lock floppy usage of DMA


*
* macros
*



Dies sind nur ideen, und wollte mal wissen was ihr darüber denkt?

[guest522]

Die Idee hatte ich vor ein paar Jahren auch schon einmal. Ich habe sogar ein Modul dieser Art rumfliegen, dass ich mal mit dem Nova Adapter verheiraten wollte. Leider habe ich bei der Analyse der Treiber aufgegeben.
Wäre sicher ne gute Lösung.

[tuxie]

Aber ich denke wir haben hier an Board Programmierer die da uns ziemlich sicher unterstützen könnten. Ich könnte mir gut vorstellen das man den Treiber vom Hades nehmen könnte und diesen auf die im ST verwendeten Adressen umbaut. Theoretisch sind ja auch Interrupte möglich was kein Polling mehr voraussetzt wie es bei der EtherNEA oder EtherNEC gemacht wird. Ich denke das man da gute Transferraten Realisieren kann ohne das es den ST zu sehr belastet.

Edit: Genau dieses Modul habe ich hier liegen, bekommt man für Spot geld aus fern ost und ist alles drauf was man braucht. Leider keine Pinout Unterlagen dazu so das ichs ausmessen muß.

[Lukas Frank]

Schau dir mal die RIEBL Ethernet Karten Treiber an, die Karte im Mega ST hängt auch einfach am 68000 Bus ....

[guest522]

Edit: Genau dieses Modul habe ich hier liegen, bekommt man für Spot geld aus fern ost und ist alles drauf was man braucht. Leider keine Pinout Unterlagen dazu so das ichs ausmessen muß.

Ich habe die "Unterlagen" irgendwo...ich geh mal suchen.

[tuxie]

Das wäre cool da könnte ich schonmal eine Testschaltung aufbauen. GAL Listing für den decoder sollte ja auch nicht das größte Problem sein.

[guest522]

ein wenig zerknittert, aber lesbar.

[tuxie]

Klasse Dankeschön, hast du eine Idee wo man das Interface hin mappen könnte ? Am besten in einen Bereich wo es Altram, VGA, IDE und TOS2.06 nicht beeinträchtigen. Auf dem Board sind ja nur A0-A4 angeschlossen was rein theoretisch ja 31Byte sind sollten (0x1F)

[czietz]

Wenn Du Dir allerdings den Aufwand des Dekodierends der Signale LDS und UDS und des Handlings des 16-Bit Datenbusses des 68000ers ersparen willst, solltest Du -- wie bei der meisten übrigen 8-Bit-Peripherie -- alle Register des Netzwerkchips auf ungerade (oder gerade) Adressen legen. Dann brauchst Du 64 Byte Adressraum, aber auch das ist zu verschmerzen.

Oder Du findest ein Modul, bei dem der volle 16-Bit-Datenbus des Netzwerkchips herausgeführt ist. Ist vermutlich dann auch schneller.

[tuxie]

JA der RTL8019AS ist eigentlich ein 16bit Chip und die oberen Bits sind laut Schaltplan offen, gut das könnte man noch raus legen und verbinden, wäre zwar eine Friemelei aber möglich.

Warum packst du nicht einfach mit an gute Leute braucht soein Projekt.

Habe mal in der map geschaut Theroetisch sollte
$F60000 - $F6FFFF noch frei sein, ob da jetzt noch irgendwelche Extentions drauf sind kann ich nicht sagen
ftp://ftp.lip6.fr/pub/atari/Docs/hardware.txt

[czietz]

Warum packst du nicht einfach mit an gute Leute braucht soein Projekt.

Danke für das Lob, aber ich entwickele schon von Montag bis Freitag Elektronik und möchte am Wochenende auch mal was anderes machen. ;-) Außerdem habe ich persönlich keinen Bedarf für Ethernet am Atari...

Aber meine (ungetesteten) Gedanken zur Einbindung des RTL8019-Moduls an den Bus:


Atari    NIC
D0 ..... SD0
.        .
.        .
.        .
D7 ..... SD7
A1 ..... SA0
.        .
.        .
.        .
A5 ..... SA4
/RESET . RST (über einen Inverter)
??  .... INT0
??  .... INT1

Damit erscheinen die 32 Register des NICs auf ungeraden Adressen und belegen insgesamt mind. 64 Byte Adressraum. Dieser Anschluss setzt außerdem voraus (nicht überprüft), dass der NIC den Datenbus in Ruhe lässt, solange er nicht über /IORB angesprochen wird. Sonst müsste man Latches vorsehen.
Die Interrupts könnten evtl. an den MFP, falls man dort Eingangspins opfert, die sonst für die serielle Schnittstelle gedacht sind.

Wie viele Adressleitungen der Adressdecoder bekommt, hängt davon ab, ob Du die komplette Adresse dekodieren willst oder damit leben kannst, dass der NIC mehr als 64 Byte Adressraum braucht. Folgende Signale muss der Decoder erzeugen:


Zum NIC:
/IORB .. Low, wenn die Korrekte Adresse erkannt wird, /AS vom Atari low ist und R/W vom Atari high ist.
/IOWR .. Low, wenn die korrekte Adresse erkannt wird, /AS vom Atari low ist und R/W vom Atari low ist.

Zum Atari:
/DTACK . Low, wenn die korrekte Adresse erkannt wird und /AS vom Atari low ist. Achtung: Muss ein Open-Collector/Drain-Ausgang sein.


Ob das Timing passt, wäre auch noch zu überprüfen.

[tuxie]

Hi, genau so hatte ich es auch im Kopf, und wenn der Adressraum frei ist ist es ja egal wenn er mehr belegt. Für dtack hätte ich es über einen 74f03 gemacht wie beim ide Interface. Irq muss man sehen wie man ihn am besten anschließt oder verschaltet.

[czietz]

So vergleichsweise langsam wie der Atari ist, muss es vermutlich nicht mal ein Inverter aus der "F"-Serie sein, sowas wie "LS" oder "HCT" (in CMOS) würde für /DTACK auch reichen.

[tuxie]

Also beim IDE gehen nur F Typen, Hxx oder LS typen gehen nicht daher denke ich schadet es nicht F Typen zu nehmen

[czietz]

Bzgl. /DTACK muss man eher aufpassen (wenn man das aus dem Adressdecoder generiert), dass es nicht zu früh gesetzt wird, d.h. auf "low" geht. Sonst beendet die CPU evtl. den Buszyklus, bevor der NIC die Daten auf den Bus gegeben bzw. vom Bus gelesen hat. Daher hätte ich jetzt vom Gefühl her eher langsamere Logik für /DTACK verwendet. Wobei man das Timing für eine zuverlässige Funktion sowieso durchrechnen müsste...

In http://atari.8bitchip.info/aidesch.htm läuft /DTACK durch LS-Logik.

[czietz]

Ergänzung: Ein Blick in die MC68000-Timing-Diagramme zeigt, dass man schon einige Zeit hat, zwischen dem Low-Setzen von /DTACK und der Reaktion der CPU. Beispiel Read-Zykus: Wenn man es schafft, innerhalb von weniger als ca. einer Clock-Periode (125 ns bei 8 MHz) nach dem Low-Werten von /AS auch /DTACK zu setzen, hat man dann noch einmal eine Clock-Periode, bis die Daten vom Bus gelesen werden, d.h. bis der NIC reagiert haben muss. Dass bei zu schnellem /DTACK die CPU den Bus zu früh liest, sollte also doch nicht auftreten. Bei einem Write-Zyklus hat man nach dem Quittieren durch /DTACK auch über eine Clock-Periode Zeit, die Daten vom Bus zu holen.

Aber Fazit ist: Man muss das Timing wirklich durchrechnen.

[tuxie]

Will das Thema nochmal rausgraben da ja nicht Tot ist. Ich habe mit dem Entwickler des Internen Falcon Interfaces Kontakt aufgenommen und er hat mir auch die Adressen mitgeteilt. Jedoch lässt er sich nicht ganz ins Handwerk schauen.

Er hat 16Bit DMA Transfer ans laufen bekommen, würde das gern auch machen wollen sollte ja auch im ST möglich sein. Nur WIE funktioniert das ? Ich hab zwar im Profibuch nachgelesen werde aber daraus nicht ganz Schlau. Für ein Paar Tips wäre ich dankbar..

http://atari-forum.com/viewtopic.php?f=27&t=28840&hilit=rtl8019as

[Lukas Frank]

@tuxie ... er hat ja jetzt die Quelldateien zur Verfügung gestellt. Jetzt wäre es doch ein leichtes das ganze als Aufsatz für die 68000 CPU aufzubauen.

->   http://atari-forum.com/viewtopic.php?f=27&t=28840&sid=b1ab61606217f65e2f6653f3cf45eb52&start=25#p296834

[neogain]

da ist sogar ein Link für die PCB dabei. also kann man als Falcon nutzer sich diese bei OSH Park ordern und schon aufbauen. Jetzt das Ganze noch für den ST, das wäre genial

https://oshpark.com/shared_projects/lxwCvpHJ

[Lukas Frank]

Das ganze für den ST ist recht einfach weil der Falcon einen 68000 Erweiterungsbus hat mit UDS und LDS, da ist nichts 030iger dran ...

Was man im ST nicht braucht ist dieses Expand Signal. Und damit das vollständig wird bräuchte man Treiber für MiNT und MagiC ...