Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » AC1 Portnummern für GIDE, USB und Netzwerk » Themenansicht

Autor

Thread - Seiten: -1-

000
04.10.2011, 20:38 Uhr
jmueller

Ich möchte gern mal eruieren, wer alles am AC1 schon
GIDE, USB und/oder Netzwerk betreibt, und vorallen an welchen Portnummern.
Des Weiteren interessiert mich, welche Software es da schon gibt
bzw. portiert wurde.
Im Endeffekt interssiert mich die bereits vorhandene Variantenvielfalt.

Ich bitte deshalb die Anwender der o.g. Module/Baugruppen,
sich mal hier zu melden.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
05.10.2011, 07:44 Uhr
jmueller

Aufgrund der überwältigenden Resonanz möchte ich mal noch den Hintergrund erklären:
Also es geht mir darum, inwieweit gewisse Portnummernbereiche in JKCEMU
berücksichtigt werden sollten.
Wenn es da keine weiteren Infos dazu gibt,
werden die o.g. Dinge ganz einfach an den Portnummern emuliert,
an denen ich es für richtig halte.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
05.10.2011, 08:36 Uhr
Ralph

Da werd ich mal den Anfang machen

Ich betreibe schon seit 2008 am AC1 das GIDE auf Port 80H und USB seid 2010 auf Port FCH.
Das Netzwerk ist bei mir bei mir fast fertig aufgebaut, aber mangels Zeit noch nicht fertig.
Die Netzwerk-PIO läuft z.Zt. auf 28H, könnte aber noch geändert werden.

Soweit ich weiß, gab es für den AC1 keine Software für das GIDE und USB,
bevor ich diese selbst programmiert habe.
Nur Heiko Poppe hat noch spezielle Software für seinen AC1

Die meisten AC1 User nutzen wohl meine Programme:

Monitor ab 10.1 (USB & GIDE),
DVU (USB) und Vorgänger DiskVerU
DVHD (GIDE) und Vorgänger DiskVerHD
HRCPM (GIDE), HRDOS (GIDE) sowie die UTOOLS14 (USB), jeweils CP/M

In Entwicklung ist ein erweitertes COPAC.COM für CP/M welches AC1 Save, Turbo, USB und Netzwerk können soll.
Dabei wird aber die vorhandene Hardware genutzt.

Interessant ist evl. noch der neue Farb CPLD-BWS der bereits 2x läuft
und jetzt grad die LP gefertigt wird.
Es liegen bereits 25 Bestellungen vor und es ist zu vermuten, das er eingesetzt werden wird

Viele Grüße von Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 05.10.2011 um 10:40 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
05.10.2011, 09:36 Uhr
Heiko_P

Ich nutze seit etwa einem Jahr alle drei Baugruppen, allerdings ausschließlich unter CP/M. Eine Nutzung dieser Baugruppen mit dem AC1-Monitor habe ich derzeit nicht geplant.

Das GIDE läuft auf 40h, USB auf 84h, Netzwerk auf 88h. Ich glaube nicht, dass diese Adressvergabe der Maßstab für andere Nutzer sein sollte.

Viele Grüße

Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
07.10.2011, 23:30 Uhr
jmueller

Weitere Meldungen scheint es ja nun nicht mehr zu geben.
Da möchte ich mal zusammenfassen:

Also die Portnummernverwendung beißt sich zwischen Ralph und Heiko.
Da Heiko selbst meint, dass seine Portnummern nicht der Maßstab für andere
sein soll und da Ralph bereits einiges an Software publiziert hat,
die auch von anderen Leuten verwendet wird,
würde ich in JKCEMU die Portnummern für GIDE und USB a la Ralph umsetzen.

Beim Netzwerk habe ich noch folgenden Gedanken:
Es zeichnet sich ja ab, dass solche Entwicklungen wie Netzwerk und USB
für mehrere Computertypen (KC85, Z9001, Z1013, AC1) nachgebaut werden.
Wenn nun überall die gleichen Portnummern verwendet würden,
könnten entsprechende CP/M-Programme unverändert übernommen werden.
Der KC85 braucht wegen dem separaten Prozessorsystem in der D004
sowieso spezielle Software (Koppeltreiber) und läuft deshalb hier mal
außer Konkurrenz, aber beim Z9001 wird das Netzwerk bereits
auf IO-Basisadresse C0 betrieben
(siehe http://www.sax.de/~zander/z9001/module/tcp.html).
Warum dann nicht auch beim AC1 (und Z1013) ?

Also mein Vorschlag für "den" AC1-Quasistandard:
80-8F GIDE
C0-C3 Netzwerk
...FB (abwärts) frei für weitere Entwicklungen
FC-FF USB

Jens

Dieser Beitrag wurde am 07.10.2011 um 23:31 Uhr von jmueller editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
08.10.2011, 13:31 Uhr
Heiko_P

@Jens: Darüber würde ich gern noch mal mit dir reden, du hast dazu eine Mail von mir.

Viele Grüße

Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
04.12.2011, 09:51 Uhr
Ralph

Ich nutze diesen Thread hier, weil ich denke mein Beitrag passt da genau rein

Konkret möchte ich eine Lösung vorstellen, wie wir ZUKÜNFTIG am AC1 mit einfachstem Aufwand SEHR VIEL mehr RAM und ROM Bänke
adressieren können, ohne alles neu zu erfinden.

Konkret hat wohl jeder mind. eine 256k Präcitronik RAM Floppy im Einsatz.
Nachbauer der KombiRAMFloppy sogar zusätzlich noch bis zu 1MB Modul 3

.

Schon eine Weile hab ich mir Gedanken gemacht, wie eine KOMPATIBLE Erweiterung aussehen könnte !?

Die bisher (vermutlich nur von mir genutzte) Erweiterung der Präcitronik RAM Floppy auf 1MB schied als "Lösung" aus, denn sie blockiert:

1. 4 IO-Adressen (ECH..EFH),
2. ist sie nur bis 1MB realisierbar (oder mehr IO-Adressen werden blockiert),
3. ist umständlich im Programm zu nutzen.. und
4. benutzt sie vermutlich niemand.

Also verwarf ich diese Lösung ! Wer Sie nutzt bitte mal melden !!

Meine Lösung, die auch im HRDOS12 & HRCPM12 eingebaut ist, nutzt einfach ein weiteres 8bit LATCH, welches die weiteren Adressen liefert.

Damit lassen sich theoretisch weitere zusätzliche 256 Bänke adressieren !

D.h. 256 * 256k = 64MB bei Präcitronik und 256*1024k = 256MB bei Modul 3 !!

Praktisch kann CP/M "nur" 8MB nutzen werden, was jedoch wohl lange ausreichend ist.

Das Latch selbst läuft auf der IO-Adresse E5H, also im bei der Präcitronik RAMFloppy belegten Bereich.
Der Hardwareaufwand besteht nur aus dem Latch selbst !
Da ohnehin fast jeder diese RAMFloppy nutzt, ist auch eine mögliche Kaskadierung von mehreren Präcitronik RAMFloppy's sehr einfach möglich.
Die gesamte IO-Dekodierung für das Latch wird ja bereits auf der RAMFloppy gemacht.
Genausso sieht es für die Nutzer der KombiRAMFloppy aus

Diese Adressierungsart, werden wir beim "in Entwicklung" befindlichen "MEGA Modul" für den AC1 auch verwenden.

Ich denke damit eine gute Lösung gefunden zu haben und würde darum bitten, diese so zu verwenden odder ggf. HIER darüber zu diskutieren.

Viele Grüße vom Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 04.12.2011 um 09:58 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
04.12.2011, 20:35 Uhr
Flieger136

Im Prinzipist dies die Adressierung wie sie schon bei den Modulen 1 und 3 angewendet wurde. Wirklich eine einfache Sache - sollte auch so beibehalten bleiben. Vielleicht lässt es sich so realisieren, dass die alten Module weiter genutzt werden und die neuen Module diese Adressierungen "nur" erweitern.
vg
Gunar
--
Behandle andere Menschen so, wie du von ihnen behandelt werden möchtest...

Denke positiv oder gar nicht...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
04.12.2011, 21:04 Uhr
Ralph

Zitat:

Flieger136 schrieb
Vielleicht lässt es sich so realisieren, dass die alten Module weiter genutzt werden und die neuen Module diese Adressierungen "nur" erweitern.
vg
Gunar

Genau DAS ist es ja ! Schrieb ich ja auch ! Die alte Hardware ist problemlos verwendbar und wird nur um ein Vielfaches erweitert !
Meine HRDOS RAMFLOPPY Treiber unterstützen von 256k bis 4MB alle so aufgebauten Erweiterungen

.
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 04.12.2011 um 22:05 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
04.12.2011, 21:33 Uhr
jmueller

Zitat:

D.h. 256 * 256k = 64MB bei Präcitronik und 256*1024k = 256MB bei Modul 3 !!
...
Das Latch selbst läuft auf der IO-Adresse E5H

Ein Latch für zwei sonst voneinander unabhängige Module?

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
04.12.2011, 21:51 Uhr
Ralph

Ja klar, geht doch ohne Probleme, weil je NIE parallel zugegriffen wird. Also entweder Modul 3 oder Präcitronik RFL.
Ich bin sogar der Meinung, dass mit gleichem Latch & Prinzip Modul 1 als ROM erweitert werden könnte. Allerdings nutz selbst ich bisher nichtmal 256k aus..

Sollten wir Modul 3 mal banken wollen, wäre auch da noch Port E4H z.B. frei und nutzbar.

Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 04.12.2011 um 22:04 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
05.12.2011, 08:47 Uhr
jmueller

Modul 3 arbeitet mit Einblendung von Speicherbereichen.
Wenn nun also in dieses Latch etwas hineingeschrieben wird,
müsste automatisch ein andereres RAM-Segment eingeblendet werden,
obwohl das in dem Fall vielleicht gar nicht gewünscht ist,
weil man vielleicht gerade auf die RAM-Floppy zugreifen möchte...

Natürlich kann man das alles technisch lösen.
Meine Frage zielte deshalb auch eher auf die konzeptionelle
Sinnfälligkeit einer solchen Kopplung ab.
Aber gut, da hast Du ja nun E4h ins Spiel gebracht.

Für mich stellt sich eigentlich eine allgemeinere Frage:
Ist es denn überhaupt sinnvoll, alle möglichen alten Module aufbohren zu wollen
oder ist es nicht besser, EINE Lösung für RAM-Erweiterungen zu entwickeln,
die auch völlig unabhangig von den alten Modulen ist (andere IO-Ports)?
Mit dem Aufbohren alter Module geht man nämlich immer auch das Risiko ein,
dass dann vielleicht das eine oder andere alte Programm nicht mehr läuft.
Du versprichst zwar Kompatibilität, aber diese ist immer relativ,
denn jede Änderung bedeutet auch ein kleines Stück Inkompatibilität.

Bzgl. der Erweiterung der RAM-Floppy sehe ich wendiger Probleme,
beim Modul 3 aber schon mehr.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
05.12.2011, 14:53 Uhr
Ralph

Danke Jens ! Ich finds schön, das sich mal jemand zu meinen Ideen äußert

Zitat:

jmueller schrieb
Modul 3 arbeitet mit Einblendung von Speicherbereichen.

Stimmt, wobei genau dieser Modus von keiner mir bekannten Software benutzt wird.

Es denke, das das Einblenden des 32k Bereiches von 4000..BFFFh eher ein "Abfallprodukt" ist.

Viel cleverer und einfach zu Händeln, finde ich den speziellen M1 Modus, der die gesamten 64k
JEDER Speicherseite nutzbar macht ! und genau HIER setzt ja meine Erweiterung an,
die einfach "nur" 256 weitere Modul 3 adressieren könnte ! Da das Latch ja nach RESET
immer auf 00h steht, ist es auch egal, ob nun 256k oder 8MB im Modul3 bestückt sind !

Zitat:

jmueller schrieb
Wenn nun also in dieses Latch etwas hineingeschrieben wird,
müsste automatisch ein andereres RAM-Segment eingeblendet werden,
obwohl das in dem Fall vielleicht gar nicht gewünscht ist,
weil man vielleicht gerade auf die RAM-Floppy zugreifen möchte...

Was meinst Du ? das erschliest sich mir nicht Jens !
Das Latch wird bei der AdressBerechnung der RFL genauso 1x je Zugriff berechnet und gesetzt,
wie ohnehin das Register 15h oder E6h+E7h.
Einzig ein LDIR von Bank zu Bank geht nicht, aber jetzt ebenfalls nicht.
Ich wolllte mit der Zusammenfassung nur ein paar Bits im Latch sparen mehr nicht.
Gern können wir für die Präcitronik RFL E5h und für Modul 3 E4h oder nen anderen Port nehmen.

Wenns um das Thema RAM Banking für CP/M 3 gehen sollt, dann haben wir bereits im Zusammenhang
mit dem MEGA Modul für den AC1 ne andere Lösung im Kopf, die echtes Banking kann !

Zitat:

jmueller schrieb
Ist es denn überhaupt sinnvoll, alle möglichen alten Module aufbohren zu wollen
oder ist es nicht besser, EINE Lösung für RAM-Erweiterungen zu entwickeln,
die auch völlig unabhangig von den alten Modulen ist (andere IO-Ports)?

Das seh ich aus Softwarewarentwicklersicht vollkommen anders ! und wills auch
begründen. Wenn wir ein ganz anderes Konzept zur Verwaltung der neuen RFL
verwenden wollen, müsste
a) der Treiber 2 versch. Systeme unterstützen (und wäre damit viel größer !!)
b) Könnte ein AC1 User der nur die "neue" Floppy hätte, nicht die "alten" Tools nutzen,
wogegen die alten Tools selbst mit neuer Floppy 100% laufen !!
c) wäre ein weiterer "Standart" zu erfinden.

Zitat:

jmueller schrieb
Mit dem Aufbohren alter Module geht man nämlich immer auch das Risiko ein,
dass dann vielleicht das eine oder andere alte Programm nicht mehr läuft.
Du versprichst zwar Kompatibilität, aber diese ist immer relativ,
denn jede Änderung bedeutet auch ein kleines Stück Inkompatibilität.

Genau das passiert EBEN NICHT bei meiner Lösung Jens !

Zitat:

jmueller schrieb
Bzgl. der Erweiterung der RAM-Floppy sehe ich wendiger Probleme,
beim Modul 3 aber schon mehr.

An welche Probleme denkst Du da konkret ?

Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 05.12.2011 um 15:00 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
05.12.2011, 15:24 Uhr
jmueller

Hallo Ralph,

beim Modul 3 habe ich nicht nur den AC1, sondern auch den LLC2 im Hinterkopf.
Und ich weiß noch sehr genau, wie aufwendig und zeitraubend die Entwicklung
der Emulation dafür war, weil die Infos über die genaue Funktionsweise doch recht rar
waren und es deshalb eben ewig nicht mit der originalen Software (z.B. CP/L)
funktioniert hat. Aus diesem Grund habe ich einen gewissen Respekt vor Änderungen
am Modul 3, die zugegebenermaßen möglicherweise unbegündet sind.

Ansonsten möchte ich hier Deine Ideen und Vorschläge nicht zerreden
sondern nur hinterfragen. Deshalb gehe ich auch nicht auf die ganze Punkte einzeln ein.

Allerdings sind die Fragen mit Deinem letzten Beitrag nicht kleiner,
sondern eher mehr geworden:

Zitat:

Wenns um das Thema RAM Banking für CP/M 3 gehen sollt, dann haben wir bereits im Zusammenhang
mit dem MEGA Modul für den AC1 ne andere Lösung im Kopf !

Mit ist nicht so ganz klar, welches Problem Du mit welcher Lösung beheben möchtest.
Oder anders gefragt: Wozu willst Du denn das Modul 3 überhaupt aufbohren, wenn es
1. auf dem AC1 angeblich nicht genutzt wird
2. für die Vergrößerung der RAM-Floppy (Präcitronic) bei Dir schon eine Lösung gibt und
3. für das RAM-Banking für CP/M 3 Du auch schon eine Lösung hast?

Im übrigen dürften sich zwei RAM-Banking-Lösungen (Modul 3 vs. MegaModul) beißen.
Wie gesagt, mir ist Deine konzeptionelle Zielsetzung nicht ganz klar.
Und deshalb frage ich einfach nur, weil ich es gern verstehen möchte.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
05.12.2011, 15:48 Uhr
Ralph

Ok Jens, passt schon. Ich freu mich doch über jede Regung, auch Anregung

bzw. ggf. wenn berechtigt natürlich auch Kritik

Zunächst hab ich meinerseits KEIN Problem welches ich lösen will !

Ich hab mir einfach Gedanken gemacht, wie zukünftig eine potentielle Speichererweiterung, die ich mit MEGA Modul bezeichnet habe, aussehen kann.
Mit MEGA Modul meine ich übrigens 100% NICHT das MEGA FlashRAM/ROM vom Buebchen oder UR1968 !!

Beim bereits in Entwicklung befindlichen MEGA-Modul wollen wir auch die Möglichkeit des echten RAM Bankings sowie Monitor-ROM Banking vorsehen,
um den AC1 mal CP/M3 fähig zu machen.

Zum Modul 3: Ich bin davon ein großer Fan, weil Modul 3 im Vergleich zur Präcitronik RamFloppy:

1. schlicht viel einfacher zu händeln ist, (vorallem Softwareseitig),
2. bisher mehr Speicherraum (1MB) hat,
3. im laufenden Betrieb deutlich schneller ist, weil kein IO-Port Nadelöhr vorhanden ist,
denn ich könnte ja 64k mit einem einzigen LDIR Befehl schreiben/lesen !!
4. es Nutzer der KombiRAMFloppy gibt, die die Erweiterung gleichermaßen nutzen können

Aus all den Gründen nutze ich auf MEINEM AC1 nur Modul 3 im HRDOS

und.. genau deswegen auch meine Lösung mit dem Latch, denn es funktioniert bei BEIDEN RFL Versionen gleichermaßen und einfach.
Da beide Systeme nie parallel genutzt werden, lag der Gedanke der Zusammenfassung für beide Systeme nahe.
Ich denke, das ist ne ganz einfache und für jeden verständliche Logik.

Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 05.12.2011 um 15:51 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
05.12.2011, 16:15 Uhr
Flieger136

Auch ich nutzte auf meinem AC1 das Modul 3 aber nur mit 512kB. So gebaut 1988.
Im CP/M, welches ich nutze, wird es unterstützt.
Meine Gedanken - unabhängig von Ralph waren: RAM's auf eine Platte zu bringen: Modul3 und Präzitronik und Hauptspeicher 64K. Letzteren dann batteriegepuffert.
VG
Gunar
--
Behandle andere Menschen so, wie du von ihnen behandelt werden möchtest...

Denke positiv oder gar nicht...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
08.12.2011, 07:15 Uhr
Ralph

@jmueller... Jens, keine Antwort heißt, das Du keine weiteren Fragen oder Hinweise hast und mir folgen konntest ?

@Flieger136.. Ja im MEGA-Modul für den AC1 ist Pufferung der RAM's vorgesehen.

@all... Wer hat denn nun mehr als 256k RAMFloppy mit Präcitronik im Einsatz ?

Viele Grüße von Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 08.12.2011 um 07:16 Uhr von Ralph editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
08.12.2011, 07:55 Uhr
jmueller

Zitat:

@jmueller... Jens, keine Antwort heißt, das Du keine weiteren Fragen oder Hinweise hast und mir folgen konntest ?

Ich glaube verstanden zu haben was Du vorhast,
und das hat meinen Informationsdrang erstmal gestillt.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]