Gerade eben hatte ich nochmal das Thema Netzwerkkarten.

In einem früheren thread hatten mir schon einige dazu geantwortet. ergebnis: es gibt bis jetzt keine brauchbare lösung.

dabei möchte ich eigentlich nur, dass zwei oder mehr ataris miteinander sehr geringe informationen austauschen. nix sharing von ressourcen oder gar "echte" steuerung eines anderen ataris.

Daher meine Frage mit einem neuen Lösungsansatz:
Besteht theoretisch die Möglichkeit, dass von aussen über den PBI bestimmte Speicherbereiche mit beliebigen Informationen gefüllt werden? Oder gar über den SIO?

Der Grund für meine Frage: Wenn zwei Atari jeweils einen Speicher von z.b. 256 bytes reservieren und der andere Atari diesen Speicherbereich nutzt um Informationen abzulegen, dann könnte man damit doch schon Informationsaustausch praktizieren, oder? Ich neme an, dass der andere Atari über den PBI einen VBI auslösen können muss um Schreibzugriff zu bekommen.

Wie sieht es mit diesem Lösungsansatz aus? Ist sowas machbar?


andreas

Das würde mich jetzt auch einmal interessieren

Markus

PS: Das war beim ST nicht schlecht, da konnte man über die Midischnittstelle ein einfaches Netzwerk einrichten.

Machbar ist "alles". Aber nicht ohne Zusatz-Treiber.

Wie auch schon im alten Thread erklärt
Im Prinzip muss nur der VBI erweitert werden, der lauscht, ob von außen Daten kommen, oder nicht.
Das wäre auch bei einer "Signalleitung am PBI" der Fall.

Hallo Andreas, Leute

Wenn man sich eine kleine Hardware bastelt die einen Puffer und etwas intelligenz hat, müßte man nur noch einen Treiber schreiben der diese Hardware abfragt ob er vielleicht Daten für den Rechner hat.

Funktioniert einen Modemtreiber nicht auch so? Wird da nicht auch das Interface/Modem gefragt ob es noch Daten hat?

Mit der richtingen Software, müßte das sogar mit dem 850 funktionieren. (Wenn man die RS232 Ports als extra SIO Ports benutzt)

SIO ist meines Erachtens die beste Lösung hier. Man kann dan auch die älteren Atari's (400 und 800) und den XEGS anschliessen. Und natürlich das SIO2PC interface.

Tschüß

Mathy

Hi Mathy,

an sowas habe ich auch schon gedacht, aber was ist bei mehr als 2 Rechnern ? Bzw. dann muss an jedem 8 Bit eine RS232 vorhanden sein.

Howie

Was spricht denn nun gegen das Netzwerkinterface der Regionalgruppe Frankfurt ( http://www.abbuc-raf.de/networkd.htm )?

Es arbeitet ueber SIO, kann bis zu 8 Rechner vernetzen, ist einfach zu bauen, ueber Chinch Kanbel einfach zu verlängern und zu bedienen.

Was fehlt sind einfache Treiber, um von Basic oder Turbo Basic Daten zu senden oder zu Empfangen. Aber das sollte kein Problem sein, aus den bestehenden Quellcode einen solchen Treiber zu erstellen.

Ciao

Carsten

Hallo Carsten

cas hat geschrieben:Was spricht denn nun gegen das Netzwerkinterface der Regionalgruppe Frankfurt?

Der Mangel an Intelligenz.
Es können Daten rein kommen, ohne daß der Rechner darum gefragt hat. Daten die reinkommen müßen auf Störungen untersucht werden, weil mehrere Rechner gleichzeitig senden können.

Tschüß

Mathy

cas hat geschrieben:Was spricht denn nun gegen das Netzwerkinterface der Regionalgruppe Frankfurt ( http://www.abbuc-raf.de/networkd.htm )?

Hi Carsten,
ich hatte Jiri Bernasek dazu kontaktiert. (für die anderen: der hat das Netzwerk-interface für cervi usw. entwickelt) was nun dagegen spricht dieses interface als echtes netzwerkinterface zu nutzen, beschreibt Jiri in seiner sehr ausführlichen Antwort.

############################
Hello,

Just a few words more...

As for changing the source code - currently I don't have the necessary
free time to help you with this sort of work myself, but of course
there's no problem if you make another version yourself.

Reading my source code, you surely noticed that the whole thing is
working mostly on interrupts, which is possibly a good choice also for
handler-style operation.
But I see one big problem, which is maybe not that much visible for you,
as it should be - the interrupt-routines in my version (without OS-ROM)
are written in a tricky way (timing at the very begin of them, to be
exact), which is impossible to implement under a normal OS
interrupt-vectors. As you can also read in the text (that I've sent to
ABBUC magazine together with the code), this is a matter of hardware-bug
inside 6502 chip. If you'll write the interrupt routines in a normal
way, you'll encounter a problem of massive failing of VBI and DLI
interrupts (randomly, when the serial I/O works), making a fine-looking
screen and reasonable game-timing a big problem. Also the networking
itself should be written very carefully, to be safe even if a VBI
doesn't occur on some frames.
Also detecting of data-block-end, as seen in my code, is a bit tricky -
the POKEY's bit detecting is exactly timed (I've counted all the
clock-cycles of the whole IRQ routine).

Another possible way is to have a slow "conversation-style" game, and
use some simple way of data-sending, while the speed is not that much
important. In this case, you might be even successful just by Poking the
registers from Basic, but anyway this is a very limited way.
I must also say, that making a protocol just for one game, sending some
kind of game-status or player-positions or such a style info, is a very
complicated work, especially if you take all the possible error-events
into consideration. I did Multi Dash this way, and said myself "never
more"...
I think that the stick-info-sending-on-background style, as seen in my
code, is much better, fast and simple... And easy to use in other games,
too.

I see no point on changing the interface, like adding memory or so...
That would be a much more complicated device, without of any great
effect, but with the not very nice effect of people not wanting to build
it, and incompatibility, I'm afraid. Anyway, once the Atari is "on-line"
with the serial-data-transfer properly programmed on the interrupts
(which is necessary anyway), the rest of network-controlling is a rather
simple thing to do... I might recommend my protocol to be used, because
I think it's effective and - first of all - error-proof.
There's no problem with the master/slave system, I think, as far as it's
used only for controlling the network itself. Actually, my games are
also working this way, which doesn't mean any limitations to
game-playing on the master-system. Just the networking-protocol on
interrupts is treated a little different way, that's all...

And, of course, if you're thinking about something more than a
game-network, a real network for data-sending maybe, then everything is
completely different... I didn't ever try to create a thing like that on
Atari, so I've no ideas...

Oh, I see that I've written a lot today... But of course the above are
just hints and ideas for you - I'm not going to create a new system for
you now...

Anyway, have a nice day, and keep your nice work running

Greetings!

Jirí Bernášek - BEWESOFT
############################

Hallo Andreas,

Du hattest gefragt nach:

andreasb hat geschrieben:dabei möchte ich eigentlich nur, dass zwei oder mehr ataris miteinander sehr geringe informationen austauschen. nix sharing von ressourcen oder gar "echte" steuerung eines anderen ataris.

Genau das sollte aber mit Jiris Interface ohne weiteres gehen. Multi Dash ist schon ein ziemlich kompliziertes Spiel, da nicht nur die Positionen der Spielfiguren, sondern die gegnerrischen Figuren und das Spielfeld konstant abgeglichen werden muss.

Ich bin nicht so skeptisch wie Jiri, was eine einfache Kommunikation über SIO angeht angeht. Andere Methoden (PBI etc) sind endwender noch komplizierter oder nur durch massiveren Einsatz von externer Hardware zu vereinfachen.

Weisst Du wievel Daten (Byte) Du per Zeiteinheit übertragen moechtest?

Ciao

Carsten

wirklich sehr wenig...

8 byte sporadisch.
maximal im sekundentakt

andreasb hat geschrieben:wirklich sehr wenig...

8 byte sporadisch.
maximal im sekundentakt

Hallo Andreas,
wofür brauchst du denn die 2 Rechnerkopplung?

Bernd

Zwei Atari arbeiten gleichzeitig unterschiedliche Programme ab, die zu fast beliebigen Zeitpunkten synchronisiert werden sollen.

Zwei Atari sind das Minimum. Es sollten später auch mehrere möglich sein.

die 8 byte sind relativ hoch gegriffen. es geht nicht nur um synchronisation, sondern auch um minimalste befehle (könnte auch verschlüsselt/komprimiert sein um speicher zu sparen) die 8 byte würden schon z.t. befehle im klartext aufnehmen. z.b. "P710#155" verursacht einen poke 710, 155 beim empfänger (Hintergrundfarbe setzen) oder ein "PAUSE" hält den Empfänger an bis er wieder ein "GO" bekommt.

es geht nicht um echten datenaustausch

8 byte im sekundentakt ist äußerst grob. schneller wäre besser, aber es gibt nichts wirklich zeitkritisches.

meine jetzige lösung über ein nullmodem kabel und R: treiber ist eine absolute krücke, da der sender immer auf das ACK vom empfänger wartet. das dauert unter umständen auch schonmal bis zu einer minute. Dabei will der sender nur die info ablegen dass er fertig ist um gleich mit dem nächsten befehl weiter zu machen, was er jedoch wegen des fehlenden ACK nicht kann.

Wenn das Schiffeversenken nicht so lange her wäre, könnte ich dir evtl. den passenden Tipp geben.
Auf jeden Fall sollte man vom DFÜ weg und so eine Art-SIO to SIO einsetzen, einen Diskdrive "öffnen" und darin die Daten hin und her schieben.
Wenn die Programme sich gegenseitig synchonisieren, ist es am Sinnvollsten, das Datenpaket per SIO so klein wie möglich zu gestalten und das Timeout so kurz wie möglich.
Lediglich ein Rechner (der Master) muss längere Timeouts akzeptieren.

Nick kennedy (SIO2PC) hat schon 1986 ein kleines Programm veroeffendlicht, um Daten mit 600 Baud zwischen zwei Atari Rechner hin und her zu senden, welche mit nur einem SIO Kabel verbunden sind.

Das Programm befindet sich in der "Atari Souce" Zip Datei auf Nicks Homepage
http://www.cox-internet.com/wa5bdu/sio2pc.htm

Die Datenuebertragung geht auch mit zu 19200 baud und mit dem Netzwerkinterface der RAF sollte es auch mit bis zu 8 Rechnern funktionieren. Der Quellcode ist viel einfacher als Jiri's Beispiele, kann aber auch noch erheblich optimiert und verkuerzt werden.

8 Byte pro Sekunde sind ohne Probleme sogar von Basic aus machbar.

Ciao

Carsten

@MK: Der Datenaustausch per 2RI wäre natürlich möglich, aber da auch mal Programme und Daten nachgeladen werden, kommt es zum Timeout.

@cas: Ich habe mir den Sourcecode angesehen. Anhand der Dokumentation im Code erkenne ich, dass es auch dort zu warteschleifen kommt:

Code: Alles auswählen

 
TALKSIO.PCF
;
; The program idles here while waiting for a SERIN interrupt:
;
TIME:   LDA CH ; CTRL-A PRESSED?
        CMP #$3F + $80 ; CTRL-A
        BEQ GOT
        LDA SWITCH ; CTRL-A RECEIVED?
        BEQ GOT ; Go to transmit
        JMP TIME
GOT:    JMP TINIT


gleiches auch hier:

Code: Alles auswählen

XMTSIO.PCF
;
; The program idles here while waiting for a SERIN interrupt:
;
RLOOP:  BIT SIRF ; Serial in ready?
        BMI RLOOP ; No
        LDA #$FF
        STA SIRF
        LDA SERIN ; Yes, read byte.
        RTS
;
 

damit wären zwar keine rs232 mehr erforderlich, das Verhalten der Routine ist das selbe wie mit R-Handler.[/code]

Hallo Andreas,

zwei Ataris mit einen gemeinsamem externen Speicher mit asyncronen Zugriff zu bestücken ist extrem schwer realisierbar. Der Hardwareaufwand ist dabei enorm.

Eine Idee wäre es die Daten über ein serielles Schieberegister von einem Gameport auf den anderen zu übertragen - Vorteil - Port vom Atari ist vorhanden und man braucht nur einige Bausteine. Nachteil, langsame und zeitintensive Übertragung.

Eine andere ist die Übertragung von einem Byte. Beide Rechner haben 2 Speicherstellen, der Adressbereich muß natürlich Selektiert werden, z.B $D480 zum Empfang, $D481 zum Senden. Über den DLI Interrupt kann ein automatisches Polling (zyklisches Senden und Empfangen) erfolgen. Aufwand - 2 Speicher TTL´s zum Schreiben, 2 TTL´s zum Empfang als Leseeinheiten, 2 große GAL´s für die Adressdekodierung inklusive WR/RD Logik. Damit auch andere $D400 Erweiterungen arbeiten werden die belegten Adressen als Zugriff deaktiviert.
Wenn du willst mache ich mal einen Schaltplan davon - kann aber lange dauern.
Da liegen noch zwei Speichereigenbauten die nicht fertig geworden sind. Wenn ich doch mehr Zeit fürs Hobby hätte..........

Bernd

Hallo Bernd.
ein gemeinsamer speicher... ne, so aufwändig dann doch nicht.

Ich hatte mir so gedacht für jeden beteiligten Atari:
Externe Platine, Anschluß über SIO, Einen ID-Wahl-Schalter, 1-16KB Puffer (nimmt 64KB-128KB könnte man einen ganzen Atari übers netz clonen), LEDs für: bereitschaft, daten im puffer, senden und empfangen. Ist der Puffer noch nicht geleert worden, bekommt der Sender einen ERR gesendet, so dass er ggf. erneut senden kann.

Die hauptsächliche Intelligenz säße also bei jedem beteiligten Atari

Ausgerechnet den Gameport zu belegen halte ich für ungünstig. Wie soll man da noch spielen?

andreasb hat geschrieben:@cas: Ich habe mir den Sourcecode angesehen. Anhand der Dokumentation im Code erkenne ich, dass es auch dort zu warteschleifen kommt:

Ja, weil Nick das so programmiert hat. Das muss man aber dochnicht so machen. Die Übertragung findet im Interrupt statt. Sicherlich bekommt man mit dem Atari keine harte Echtzeitfaehigkeit hin, aber fuer das was Du vorhast sollte es doch reichen.

Auch die manuelle Umschaltung der Sende/Empfangsrichtung die Nick vornimmt muss so nicht sein.

Der SIO Bus kann wie ein Ethernet verwednet werden:

1) alle Rechner horchen auf dem Bus (nicht per polling, sondern per Interrupt)
2) wenn ein Rechner etwas mitteilen möchte, sendet der Rechner
3) alle anderen empfangen und schauen in die Daten ob die Daten für sie sind
4) wenn zufällig zwei Rechner gleichzeitig senden gibt es Datensalat auf dem Bus und beide bekommen eine Fehlermeldung. Beide Rechner warten dann je eine zufällige Zeitspanne und versuchen er erneut. Mehr Rechner, mehr Kollisionen (wie bei Ethernet).

Warscheinlich muesste man mal ein kleines Demoprogrammchen schreiben. (Aber wann nur? Woher soll ich die Zeit nehmen?)

Ciao

Carsten

Hi,

warum nach neuen Treibern suchen, neue Hardware entwickeln usw? Es müsste doch auch gehen, wenn man ein gekreuztes SIO-Kabel sich anfertigt (Data In/out und Clock in/Out) und 2 rechner damit verbindet. Dann den C: Handler benutzen! CSAVE oder CLOAD oder im DOS eben... Der Datenrecorder ist ja von Haus auch "Dumm" und es funktioniert! Timeouts sind großzügig im OS und jedes OS unterstützt C: !

Eine andere und auch sehr erweiterbare Variante wäre endlich mal den verschwendeten Bereich von $D304-$D3FF richtig auszudekodieren, also PIA $D300-$D303 und dann z.B. $D304=LAN_DATA und $D305 LAN_COMMAND mit LATCHES und Bustreibern zu beschalten. Eine kleine Platine auf der die MMU kommt und ein GAL (oder ein 74138) würde für den freien Bereich schon reichen. Dann noch den C: Handler umschreiben auf die neuen Adressen.... Man hätte dann auch noch genügent freien Adressraum für andere kleine "Hardwärchen" wie z.B. AD Wandler (Temperaturmessung), DA-Wandler für Digisound, LCD-Display uvm.

Bei der ersten Methode gehts wohl nur mit 2 XLs/XEs, bei der 2. könnte man auch ne ACIA 6850 vom ST nehmen und quasi per Midi übertragen! Damit wären dann 256 Rechner möglich...

By the way: Wer weiss von einer Software, die die illegalen und gespiegelten Adressen von $D304-$D3FF wirklich benutzt? Dürfte eigentlich keiner so machen...

Gruß,
Wolfram.