Keine 64 MByte-SIMMs in CyberStormPPC :-(
Frank Busse
ein MAC-Händler hat mir zwei 64 MByte-SIMMs geliehen.
Beschriftet mit TRTI-1999, einseitig, 8 Chips.
In einem seiner MACs werden sie mit den vollen 64 MByte, in einem
anderen Modell nur mit 16 MByte erkannt.
Das gleiche in der CyberStormPPC von DCE, sie werden nur mit
jeweils 16 MByte erkannt. :-(
Aus der Traum von 256 MByte auf der CyberStormPPC. :-(
Gruß
Frank.
--
Frank Busse, Neuhofen/Pfalz, Germany
EMail: Amiga...@t-online.de
PGP public key on request
-- MicroDot 1.18 via FakeUUCP 0.40
Michael Ulbrich
>ein MAC-Händler hat mir zwei 64 MByte-SIMMs geliehen.
[...]
>Das gleiche in der CyberStormPPC von DCE, sie werden nur mit
>jeweils 16 MByte erkannt. :-(
>Aus der Traum von 256 MByte auf der CyberStormPPC. :-(
Die CyberstormPPC kann nur maximal 128MB in 4x 32MB-Modulen verwalten...
Gruß aus Berlin
--
Amiga-Spezialitäten: http://www.shopnfun.de/amiga/
Chris Classen
Hi!
> Aus der Traum von 256 MByte auf der CyberStormPPC. :-(
256MB kriegst Du AFAIK sowieso nur im A1200 unter, beim
A4000/3000 liegt die Grenze bei den bekannten 128MB.
Das liegt, habe ich mir sagen lassen, an dem CPU Slot
der jeweiligen Rechner.
- MacZPoint 1.98 -
Gunther Nikl
> Frank Busse bemerkte am 19-Mai-01 23:17:29:
>>Aus der Traum von 256 MByte auf der CyberStormPPC. :-(
>
> Die CyberstormPPC kann nur maximal 128MB in 4x 32MB-Modulen verwalten...
Das ist ja eigentlich zur Genuege bekannt. Was mich jedoch verwundert
ist, das man im A1200 256MB unterbringen kann. Was ist da anders?
Gunther
Michael Ulbrich
>Michael Ulbrich <m.ul...@shopnfun.de> wrote:
>> Die CyberstormPPC kann nur maximal 128MB in 4x 32MB-Modulen verwalten...
> Das ist ja eigentlich zur Genuege bekannt. Was mich jedoch verwundert
> ist, das man im A1200 256MB unterbringen kann. Was ist da anders?
Der von C= zugewiesene Adressraum des CPU-Slot ist beim A3/4000 nur 128MB.
Alles andere wäre wiedermal ein Hack.
Beim A1200 steht dieses Problem nicht so direkt, mehr als 8MB Ram sind dort
immer ein Hack.
Oliver B. Warzecha
<591.541T2650T13...@shopnfun.de>:
> Gunther Nikl bemerkte am 21-Mai-01 09:02:29
>
>>Michael Ulbrich <m.ul...@shopnfun.de> wrote:
>
>>> Die CyberstormPPC kann nur maximal 128MB in 4x 32MB-Modulen verwalten...
>
>> Das ist ja eigentlich zur Genuege bekannt. Was mich jedoch verwundert
>> ist, das man im A1200 256MB unterbringen kann. Was ist da anders?
>
> Der von C= zugewiesene Adressraum des CPU-Slot ist beim A3/4000 nur 128MB.
> Alles andere wäre wiedermal ein Hack.
> Beim A1200 steht dieses Problem nicht so direkt, mehr als 8MB Ram sind dort
> immer ein Hack.
Ist so die Frage. Wenn ich in das Hardware Manual gucke, dann steht da
"32-bit memory expansion space" für $08000000 bis $10000000. Bis
$80000000 aufwärts ist dann "ZIII-Expansion Space". Eine legale Methode
wäre also, das RAM in den Bereich einzublenden und via Z3-Autoconfig
einzublenden. *schwitz* Also das RAM einblenden und einfach einen
Confignode(?) dafür anzulegen, damit keine andere Erweiterung da
reingelegt wird. Okay, es klingt doch nach ziemlichem Hack.
Jedenfalls wird der 32-bit memory-Bereich z.B. auch auf dem A2k mit
B20x0 benutzt. Allerdings scheint die entsprechende Abbildung K-1 auf Z3
beschränkt zu sein, man könnte also genausogut behaupten: Wenn kein Z3,
dann ich machen meine eigene Memorymap und gut ist.
--
OBW - Hilfe bei Einrichtung neuer Newsgruppen? ment...@dana.de
"Omega Metallicus is of course old Etruscan for "Let's Party"[...]
Experiments on live guitars were carried out in the most human
conditions imaginable." Steve Hackett, liner notes from "Darktown"
Rudolph Riedel
Moin Moin!
> > Das ist ja eigentlich zur Genuege bekannt. Was mich jedoch verwundert
> > ist, das man im A1200 256MB unterbringen kann. Was ist da anders?
P5 hat sich nicht an die Vorgaben gehalten, das ist anders.
> Der von C= zugewiesene Adressraum des CPU-Slot ist beim A3/4000 nur 128MB.
> Alles andere wäre wiedermal ein Hack.
> Beim A1200 steht dieses Problem nicht so direkt, mehr als 8MB Ram sind dort
> immer ein Hack.
Laut V40_Release_Notes gibt es im A1200 seit Expansion 40.2
den gleichen 128meg Raum ab $08000000 für RAM wie im A3K.
Aber Auto-Konfig ist ja zu kompliziert wenn man schon eine
A1200 Turbokarte entwirft... :-)
Gruss, Rudolph
Thomas Richter
Hi,
>> Der von C= zugewiesene Adressraum des CPU-Slot ist beim A3/4000 nur 128MB.
>> Alles andere wäre wiedermal ein Hack.
>> Beim A1200 steht dieses Problem nicht so direkt, mehr als 8MB Ram sind dort
>> immer ein Hack.
> Ist so die Frage. Wenn ich in das Hardware Manual gucke, dann steht da
> "32-bit memory expansion space" für $08000000 bis $10000000. Bis
> $80000000 aufwärts ist dann "ZIII-Expansion Space". Eine legale Methode
> wäre also, das RAM in den Bereich einzublenden und via Z3-Autoconfig
> einzublenden.
Sicher, soweit ist das doch prima.
> *schwitz* Also das RAM einblenden und einfach einen
> Confignode(?) dafür anzulegen, damit keine andere Erweiterung da
> reingelegt wird. Okay, es klingt doch nach ziemlichem Hack.
Fragt sich, wie da die ConfigNode erstellt wird. Falls von der expansion
library, so ist das genau richtig. Falls nicht, so haben wir das Problem,
dass man auf die Weise kaum garantieren kann, dass Expansion diesen
Bereich auch wirklich freihält.
> Jedenfalls wird der 32-bit memory-Bereich z.B. auch auf dem A2k mit
> B20x0 benutzt.
Nicht per AutoConfig, sondern per "Hack mich!". Der Speicher wird vom
"Debug-ROM" im F-Space von Hand installiert.
> Allerdings scheint die entsprechende Abbildung K-1 auf Z3
> beschränkt zu sein, man könnte also genausogut behaupten: Wenn kein Z3,
> dann ich machen meine eigene Memorymap und gut ist.
Auch das kann man so oder so machen. GVP-Karten linken ihren Speicher
IMHO sauberer AFAIK im Diag-Init ein, von Hand per exec-Aufruf - da
braucht es keinen undokumentierten F-Space-Hack. Hat natürlich den
Nachteil, dass dieser Speicher nicht autokonfigurierend erscheint
(wirklich autokonfigurierend kann natürlich kein 32-Bit Speicher im
A2000 sein) und damit Exec im Chip-Mem landet. Gegen letzteres kann
man natürlich andere Mittelchen verwenden. Mit anderen Worten,
Geschmackssache. Ich mag die GVP-Lösung lieber.
Grüße,
Thomas
______________don't_cut_here,_it_could_damage_your_terminal____________________
_______ _____ _____
/ / / / / / / EMAIL: th...@einstein.math.tu-berlin.de
/ /____/ / / /____/ http://www.math.tu-berlin.de/~thor/thor/index.html
/ / / / / / \ PGP available on request, finger print:
/ / / /____/ / / 11 FC 46 B0 7F 42 43 AC 38 A4 78 9A 24 BC 77 BE
_______________________________________________________________________________
Thomas Didjurgies
ich habe noch einen alten Werbeprospekt fuer den A4000. In diesem steht,
dass max. 2GB !! RAM verwaltet werden koennen.
Gruss Thomas
--
Homepage: http://home.t-online.de/home/Lucutus
System:
A4000T/PPC 200/060, 128MB, CVPPC, Prelude, IOBlix + Ethernet,
ISDN-Master II ...
Draco/060, 128MB, DMotion + DV, Toccata, Ariadne ...
CDTV/MP3-Decoder ..
Thomas Richter
> Hallo Leute,
> ich habe noch einen alten Werbeprospekt fuer den A4000. In diesem steht,
> dass max. 2GB !! RAM verwaltet werden koennen.
Ja, diese Marketingleute... Soviel kann die CPU addressieren. Nicht, dass
man soviel hineinstecken könnte.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
>
> Nicht per AutoConfig, sondern per "Hack mich!". Der Speicher wird vom
> "Debug-ROM" im F-Space von Hand installiert.
>
Der Grund warum praktisch alle Phase5 Produkte ihr Ram per *Hand*
einbinden ist ganz einfach.....erkennung der simm config und dann
das autosizing um einen linearen speicherbereich zu erzeugen.
>> Allerdings scheint die entsprechende Abbildung K-1 auf Z3 beschränkt zu
>> sein, man könnte also genausogut behaupten: Wenn kein Z3, dann ich
>> machen meine eigene Memorymap und gut ist.
>
> Auch das kann man so oder so machen. GVP-Karten linken ihren Speicher
> IMHO sauberer AFAIK im Diag-Init ein, von Hand per exec-Aufruf - da
> braucht es keinen undokumentierten F-Space-Hack. Hat natürlich den
Jaja..die poesen poesen hacks, die es dir ueberhaupt erst erlauben einen
68060 zu booten. Also ehrlich..wird dieses "was ist der boeseste hack"
spielchen bei 8-9 Jahre alter HW nicht so langsam laecherlich...oder
muessen wir noch in das 10te gehen ?
P.S. Sighhhh
Thomas Richter
>> Nicht per AutoConfig, sondern per "Hack mich!". Der Speicher wird vom
>> "Debug-ROM" im F-Space von Hand installiert.
>>
> Der Grund warum praktisch alle Phase5 Produkte ihr Ram per *Hand*
> einbinden ist ganz einfach.....erkennung der simm config und dann
> das autosizing um einen linearen speicherbereich zu erzeugen.
Aha, und warum macht es GVP dann nicht so, und erreicht das gleiche?
Vor- und Nachteile beider Methoden meine ich erwähnt zu haben, korrekt?
Das *ich* meine *privaten* Vorlieben für dokumentierte Methoden habe, doch
auch, oder? Das dies meine Meinung ist, und Geschmackssache, doch auch,
oder?
>> Auch das kann man so oder so machen. GVP-Karten linken ihren Speicher
>> IMHO sauberer AFAIK im Diag-Init ein, von Hand per exec-Aufruf - da
>> braucht es keinen undokumentierten F-Space-Hack. Hat natürlich den
> Jaja..die poesen poesen hacks, die es dir ueberhaupt erst erlauben einen
> 68060 zu booten. Also ehrlich..wird dieses "was ist der boeseste hack"
> spielchen bei 8-9 Jahre alter HW nicht so langsam laecherlich...oder
> muessen wir noch in das 10te gehen ?
> P.S. Sighhhh
Nicht klar geworden, worum es ging? Ich habe nicht *ein* Wort vom 68060
erwähnt, sondern wie man m.E. Speicher am saubersten in das System einbindet.
Wenn Dir der Unterschied nicht klar geworden ist zwischen Prozessoranbindung,
und Speichereinbindung... Nicht kritikfähig heute, der Hörr Schmidt?
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
>>> Nicht per AutoConfig, sondern per "Hack mich!". Der Speicher wird vom
>>> "Debug-ROM" im F-Space von Hand installiert.
>>>
>
>> Der Grund warum praktisch alle Phase5 Produkte ihr Ram per *Hand*
>> einbinden ist ganz einfach.....erkennung der simm config und dann das
>> autosizing um einen linearen speicherbereich zu erzeugen.
>
> Aha, und warum macht es GVP dann nicht so, und erreicht das gleiche?
>
Ich denke mal, dass GVP das mit ihrem custom asic reglen....der chip
der jedem GVP die gleiche expansion id verpasst hat.
Custom ASIC == teuer (viel platz,viele stueckzahlen noetig)
FPGAs == billig(eingeschraenkter logik platz und relativ langsam)
extrem teuer(etwas mehr platz und
ein wenig schneller)
> Vor- und Nachteile beider Methoden meine ich erwähnt zu haben, korrekt?
>
Ist das nicht *egal* ? Der Vorteil eines ""system-konformen"" Einbindens
des Rams fuer eine HW die nicht weiterentwickelt wird ist keiner.
Die Diskussion darueber ist einfach ueberfluessig.
> Das *ich* meine *privaten* Vorlieben für dokumentierte Methoden habe,
> doch auch, oder? Das dies meine Meinung ist, und Geschmackssache, doch
> auch, oder?
>
Der Fragesteller wollte doch nur wissen warum er keine 4*64MB Simms in
seine CyberstormPPC packen kann und warum das "undokumentiert"
bei der BlizzardPPC geht.
Es wurden einfach daemliche Designentscheidungen von Commodore 90-92
getroffen und das xyz Firmen nach CBM's Abgang ihre Designs den
*Beduerfnissen* angepasst haben sollte wohl nachvollziehbar sein, selbst
fuer Prinzipienreitern der heiligen RKM/HW Inquisiation.
>>> Auch das kann man so oder so machen. GVP-Karten linken ihren Speicher
>>> IMHO sauberer AFAIK im Diag-Init ein, von Hand per exec-Aufruf - da
>>> braucht es keinen undokumentierten F-Space-Hack. Hat natürlich den
>
>> Jaja..die poesen poesen hacks, die es dir ueberhaupt erst erlauben
>> einen
>> 68060 zu booten. Also ehrlich..wird dieses "was ist der boeseste hack"
>> spielchen bei 8-9 Jahre alter HW nicht so langsam laecherlich...oder
>> muessen wir noch in das 10te gehen ?
>
>> P.S. Sighhhh
>
> Nicht klar geworden, worum es ging? Ich habe nicht *ein* Wort vom 68060
> erwähnt, sondern wie man m.E. Speicher am saubersten in das System
> einbindet. Wenn Dir der Unterschied nicht klar geworden ist zwischen
> Prozessoranbindung, und Speichereinbindung... Nicht kritikfähig heute,
> der Hörr Schmidt?
>
Herr Richter...sie haben auch ueber das sogenannte undokumentierte boese
"debug-rom" gelaestert, in dem bei allen 68060 Karten und bei den meisten
anderen Turbokarten wie auch *ihrer* Karte die Initialisierung steckt.
Wenn man dieses Rom auch fuer andere Resident Module nutzt ist das mehr
als legitim.
Chris Classen
Hi!
> > ich habe noch einen alten Werbeprospekt fuer den A4000. In diesem steht,
> > dass max. 2GB !! RAM verwaltet werden koennen.
>
> Ja, diese Marketingleute... Soviel kann die CPU addressieren. Nicht, dass
> man soviel hineinstecken könnte.
Das ist, glaube ich, durchaus möglich. 16MB auf der Hauptplatine, 128MB
auf der TK, eine Daughterboardplatine mit zahlreichen Zorroslots, wovon
jeder mit reichlich Speicherkarten/Controllern mit Speicheroption bestückt
ist - warum nicht?
/|
=Chris Classen= | o
=Jo...@jamiga.insider.org= o
Rock&Pop Cellist
____________________________________________
- MacZPoint 1.98 -
Thomas Richter
> Hi!
> Das ist, glaube ich, durchaus möglich. 16MB auf der Hauptplatine, 128MB
> auf der TK, eine Daughterboardplatine mit zahlreichen Zorroslots, wovon
> jeder mit reichlich Speicherkarten/Controllern mit Speicheroption bestückt
> ist - warum nicht?
Weil der Autoconfig-Raum nicht groß genug ist?
Thomas Richter
In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>>> Der Grund warum praktisch alle Phase5 Produkte ihr Ram per *Hand*
>>> einbinden ist ganz einfach.....erkennung der simm config und dann das
>>> autosizing um einen linearen speicherbereich zu erzeugen.
>>
>> Aha, und warum macht es GVP dann nicht so, und erreicht das gleiche?
>>
> Ich denke mal, dass GVP das mit ihrem custom asic reglen....der chip
> der jedem GVP die gleiche expansion id verpasst hat.
> Custom ASIC == teuer (viel platz,viele stueckzahlen noetig)
> FPGAs == billig(eingeschraenkter logik platz und relativ langsam)
> extrem teuer(etwas mehr platz und
> ein wenig schneller)
Aha, also haben wir zumindest mal festgestellt, dass es auch anders geht,
korrekt? An der Stelle mag ich auch einwenden, dass auch 060er Support ohne
F-Space ROM möglich ist, würde nur zusätzlichen Aufwand (Bank-Switching etwa)
bedeuten.
Dies macht das P5-Vorgehen wohl billiger, einfacher - was ich nicht bestritten
haben will - aber immer noch nicht besser oder konformer.
>> Vor- und Nachteile beider Methoden meine ich erwähnt zu haben, korrekt?
>>
> Ist das nicht *egal* ?
Mir *nicht*.
> Der Vorteil eines ""system-konformen"" Einbindens
> des Rams fuer eine HW die nicht weiterentwickelt wird ist keiner.
Die Hardware - nein. Die Software, schon.
> Die Diskussion darueber ist einfach ueberfluessig.
Ich vermute, Du verwechselst hier etwas. Das o.g. Vorgehen mag durchaus
für diverse Software Probleme erzeugen - ich darf mal rasch an den Enforcer
erinnern? Nicht, dass er *jetzt* noch Probleme hätte, aber wir sind uns
doch soweit darüber im Klaren, dass der Enforcer hier korrekt und die P5-
Einbindung hier nicht korrekt war, oder?
>> Das *ich* meine *privaten* Vorlieben für dokumentierte Methoden habe,
>> doch auch, oder? Das dies meine Meinung ist, und Geschmackssache, doch
>> auch, oder?
> Der Fragesteller wollte doch nur wissen warum er keine 4*64MB Simms in
> seine CyberstormPPC packen kann und warum das "undokumentiert"
> bei der BlizzardPPC geht.
Gut, das ist eine andere Diskussion.
> Es wurden einfach daemliche Designentscheidungen von Commodore 90-92
> getroffen und das xyz Firmen nach CBM's Abgang ihre Designs den
> *Beduerfnissen* angepasst haben sollte wohl nachvollziehbar sein, selbst
> fuer Prinzipienreitern der heiligen RKM/HW Inquisiation.
Aha, und darum kann Firma PQS entscheiden, dass sie nun nur noch ihren eigenen
Richtlinien folgen wollen und Softwareentwicklern damit Knüppel zwischen
die Beine werfen, indem man dokumentierten Richtlininen zuwiderläuft?
Nur weil die Hardware nicht weiterentwickelt wird, bedeutet dies doch nicht
automatisch, dass die damit verwendete Software genauso wenig weiterentwickelt
wird. Und als Programmierer muss ich mich nach irgendeinem Dokument richten.
Und das *wird* nunmal das RKRM sein, und nicht die nicht-verfügbaren
internen Dokumente von PQS.
>> Nicht klar geworden, worum es ging? Ich habe nicht *ein* Wort vom 68060
>> erwähnt, sondern wie man m.E. Speicher am saubersten in das System
>> einbindet. Wenn Dir der Unterschied nicht klar geworden ist zwischen
>> Prozessoranbindung, und Speichereinbindung... Nicht kritikfähig heute,
>> der Hörr Schmidt?
> Herr Richter...sie haben auch ueber das sogenannte undokumentierte boese
> "debug-rom" gelaestert, in dem bei allen 68060 Karten und bei den meisten
> anderen Turbokarten wie auch *ihrer* Karte die Initialisierung steckt.
In der 2060 - ja. In den GVP nein.
> Wenn man dieses Rom auch fuer andere Resident Module nutzt ist das mehr
> als legitim.
Nein. Der F-Space ist als "reserved" dokumentiert, und nicht als "reserved
for custom specific implementations". Dass es bequem und billiger war, ihn
zu benutzen brauchst Du nicht zu sagen und will ja niemand bestreiten.
Dass 060-er Support ohne F-Space schwieriger wäre und weitere Hardware benötigt
hätte auch. Das macht die ganze Konstruktion aber trotzdem kein Bit besser.
Es bleibt bei einer richtlinienwidrigen Ausnutzung eines Speicherraumes. Dies
ist keine Einstellungssache, dies ist Tatsache.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hi Ralph,
>
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
>>>> Der Grund warum praktisch alle Phase5 Produkte ihr Ram per *Hand*
>>>> einbinden ist ganz einfach.....erkennung der simm config und dann das
>>>> autosizing um einen linearen speicherbereich zu erzeugen.
>>>
>>> Aha, und warum macht es GVP dann nicht so, und erreicht das gleiche?
>>>
>
>> Ich denke mal, dass GVP das mit ihrem custom asic reglen....der chip
>> der jedem GVP die gleiche expansion id verpasst hat.
>
>> Custom ASIC == teuer (viel platz,viele stueckzahlen noetig) FPGAs ==
>> billig(eingeschraenkter logik platz und relativ langsam)
>> extrem teuer(etwas mehr platz und ein wenig
>> schneller)
>
> Aha, also haben wir zumindest mal festgestellt, dass es auch anders
> geht, korrekt? An der Stelle mag ich auch einwenden, dass auch 060er
GVP konnte sich den Spass um 1990 leisten weil sie die Stueckzahlen
verkauft haben. ASICs fangen ab 10000-20000 an.
> Support ohne F-Space ROM möglich ist, würde nur zusätzlichen Aufwand
> (Bank-Switching etwa) bedeuten. Dies macht das P5-Vorgehen wohl
> billiger,
> einfacher - was ich nicht bestritten haben will - aber immer noch nicht
> besser oder konformer.
>
Also du bezeichnest ein overloading der chipram 0 oder f80000 addresse als
*konformer*, um bei einem reset als *erster* agieren zu koennen ?
Ich wuerde sowas als megahack bezeichnen, der extrem inkompatibel bei
neuen Kickroms oder HW Initialisierungen gewesen waere, da es keinem
Exec/Coldstart Protokoll folgt.
Ooops..die 2630 benutzt auch diesen Hack...schande aber auch:-)
>>> Vor- und Nachteile beider Methoden meine ich erwähnt zu haben,
>>> korrekt?
>>>
>
>> Ist das nicht *egal* ?
>
> Mir *nicht*.
>
>> Der Vorteil eines ""system-konformen"" Einbindens des Rams fuer eine HW
>> die nicht weiterentwickelt wird ist keiner.
>
> Die Hardware - nein. Die Software, schon.
>
>> Die Diskussion darueber ist einfach ueberfluessig.
>
> Ich vermute, Du verwechselst hier etwas. Das o.g. Vorgehen mag durchaus
> für diverse Software Probleme erzeugen - ich darf mal rasch an den
> Enforcer erinnern? Nicht, dass er *jetzt* noch Probleme hätte, aber wir
> sind uns doch soweit darüber im Klaren, dass der Enforcer hier korrekt
> und die P5- Einbindung hier nicht korrekt war, oder?
>
Die P5 Einbindung bei der MK3/PPC/BlizzardPPC war eine Komplettloesung,
wo es irrelevant war ob diverse configdevs existierten oder nicht.
Die CBM 68040.library und Enforcer funktionierten sowieso prinzipbedingt
nicht korrekt damit.
Das dir das nicht passt, weil du unbedingt das Rad neu erfinden wolltest
ist *dein* persoehnliches Problem. Nicht das Problem des Produktes.
>>> Das *ich* meine *privaten* Vorlieben für dokumentierte Methoden habe,
>>> doch auch, oder? Das dies meine Meinung ist, und Geschmackssache, doch
>>> auch, oder?
>
>> Der Fragesteller wollte doch nur wissen warum er keine 4*64MB Simms in
>> seine CyberstormPPC packen kann und warum das "undokumentiert" bei der
>> BlizzardPPC geht.
>
> Gut, das ist eine andere Diskussion.
>
>> Es wurden einfach daemliche Designentscheidungen von Commodore 90-92
>> getroffen und das xyz Firmen nach CBM's Abgang ihre Designs den
>> *Beduerfnissen* angepasst haben sollte wohl nachvollziehbar sein,
>> selbst
>> fuer Prinzipienreitern der heiligen RKM/HW Inquisiation.
>
> Aha, und darum kann Firma PQS entscheiden, dass sie nun nur noch ihren
> eigenen Richtlinien folgen wollen und Softwareentwicklern damit Knüppel
> zwischen die Beine werfen, indem man dokumentierten Richtlininen
> zuwiderläuft?
>
Warum beschwerst du dich nicht bei NVidia, Apple und sonstwem, dass
sie keine HW Dokumentation rausgeben um "Softwareentwickler" Knueppel
zwischen die Beine zu werfen. Im Computermarkt wird es immer
schwieriger in irgendeinerweise an Dokumentation zu irgendeinem
komplexeren Produkt herranzukommen....that's life.
Wann realisierst du endlich, dass es fuer eine Firma die eine Loesung
verkaufen will es *irrelevant* ist wenn ein Programmierer irgendwo
sitzt und *seine* "partielle" Loesung dafuer anbieten will, ob aus
kommerziellen gesichtspunkten, sendungsbewusstseins oder irgendeiner
anderen Motivation.
Das *Du* gerne mit HW rumspielst und alle moeglichen netten Sachen
damit machen willst ist ja verstaendlich....aber das ist deine
"persoehnliche" Sache und nicht Bestandteil des Funktionskataloges
des Produktes.
> Nur weil die Hardware nicht weiterentwickelt wird, bedeutet dies doch
> nicht automatisch, dass die damit verwendete Software genauso wenig
> weiterentwickelt wird. Und als Programmierer muss ich mich nach
> irgendeinem Dokument richten. Und das *wird* nunmal das RKRM sein, und
> nicht die nicht-verfügbaren internen Dokumente von PQS.
>
"weiterentwickelt" ist doch eine rein subjektive Sache.
Hardware/Software Produkte werden schon seit langem
durch NDAs/Nichtdokumentieren usw. als Instrumente
eingesetzt, um seine strategischen Interessen durchzusetzen.
Das ist gang und gebe im gesamten Computer Markt.
Das mag dir nicht passen...mir teilweise auch nicht, teilweise
nuetzt es mir....nur ich jammere hier nicht seit 3 Jahren rum, wenn
mir einer nicht das gibt was ich will.
>>> Nicht klar geworden, worum es ging? Ich habe nicht *ein* Wort vom
>>> 68060
>>> erwähnt, sondern wie man m.E. Speicher am saubersten in das System
>>> einbindet. Wenn Dir der Unterschied nicht klar geworden ist zwischen
>>> Prozessoranbindung, und Speichereinbindung... Nicht kritikfähig
>>> heute, der Hörr Schmidt?
>
>> Herr Richter...sie haben auch ueber das sogenannte undokumentierte
>> boese
>> "debug-rom" gelaestert, in dem bei allen 68060 Karten und bei den
>> meisten anderen Turbokarten wie auch *ihrer* Karte die Initialisierung
>> steckt.
>
> In der 2060 - ja. In den GVP nein.
>
Wenn sie address overloading benutzt, dann viel Spass mit deinen
virtuellen neuen 68k Rom Entwicklungen:-))
Das ganze ist doch eine Phantomdebatte...
>> Wenn man dieses Rom auch fuer andere Resident Module nutzt ist das mehr
>> als legitim.
>
> Nein. Der F-Space ist als "reserved" dokumentiert, und nicht als
> "reserved for custom specific implementations". Dass es bequem und
> billiger war, ihn zu benutzen brauchst Du nicht zu sagen und will ja
> niemand bestreiten. Dass 060-er Support ohne F-Space schwieriger wäre
> und weitere Hardware benötigt hätte auch. Das macht die ganze
> Konstruktion aber trotzdem kein Bit besser. Es bleibt bei einer
> richtlinienwidrigen Ausnutzung eines Speicherraumes. Dies ist keine
> Einstellungssache, dies ist Tatsache.
>
Ach:-)
Woher willst du denn wissen was zwischen Entwicklern und CBM an
Kommunikation lief bis 1994 ?(Die 2.0 RKMs sind von 89-91)
Wenn man der CBM Logik zum A3000 gefolgt waere, haette es kein
IO auf CPU Karten geben duerfen. Zu den 1200 Uhrporterweiterung
hab ich auch meine "persoehnliche" Meinung...aber offensichtlich
sind dort Produkte entstanden, die die Leute unbedingt haben wollten,
weil sie ihnen einen Mehrnutzen gegeben haben.
Stoehn...
Thomas Richter
>>> Custom ASIC == teuer (viel platz,viele stueckzahlen noetig) FPGAs ==
>>> billig(eingeschraenkter logik platz und relativ langsam)
>>> extrem teuer(etwas mehr platz und ein wenig
>>> schneller)
>>
>> Aha, also haben wir zumindest mal festgestellt, dass es auch anders
>> geht, korrekt? An der Stelle mag ich auch einwenden, dass auch 060er
> GVP konnte sich den Spass um 1990 leisten weil sie die Stueckzahlen
> verkauft haben. ASICs fangen ab 10000-20000 an.
Sicher, hat auch niemand bestreiten wollen. Und, macht dies den F-Space
Hack ein Bit konformer?
>> Support ohne F-Space ROM möglich ist, würde nur zusätzlichen Aufwand
>> (Bank-Switching etwa) bedeuten. Dies macht das P5-Vorgehen wohl
>> billiger,
>> einfacher - was ich nicht bestritten haben will - aber immer noch nicht
>> besser oder konformer.
> Also du bezeichnest ein overloading der chipram 0 oder f80000 addresse als
> *konformer*, um bei einem reset als *erster* agieren zu koennen ?
Denke schon. Zumindest kommt mir niemand in die Quere. Addresse 0 ist
hierbei "die Wahl".
> Ich wuerde sowas als megahack bezeichnen, der extrem inkompatibel bei
> neuen Kickroms oder HW Initialisierungen gewesen waere, da es keinem
> Exec/Coldstart Protokoll folgt.
Das hat auch nichts mit Exec zu tun. Das Boot-Rom kann Exec immer noch
von Hand hinterherstarten. Inkompatibel? Nein, die Startaddresse der ROMs
ist ja auf dokumentiertem Wege herauszufinden.
> Ooops..die 2630 benutzt auch diesen Hack...schande aber auch:-)
Schön auch. Hab' auch eine zuhause. Macht bedeutend weniger Probleme...
>> Ich vermute, Du verwechselst hier etwas. Das o.g. Vorgehen mag durchaus
>> für diverse Software Probleme erzeugen - ich darf mal rasch an den
>> Enforcer erinnern? Nicht, dass er *jetzt* noch Probleme hätte, aber wir
>> sind uns doch soweit darüber im Klaren, dass der Enforcer hier korrekt
>> und die P5- Einbindung hier nicht korrekt war, oder?
> Die P5 Einbindung bei der MK3/PPC/BlizzardPPC war eine Komplettloesung,
> wo es irrelevant war ob diverse configdevs existierten oder nicht.
Es war P5 *egal*, aber es ist nicht *irrelevant*. Du verwechselst hier
zwei Dinge.
> Die CBM 68040.library und Enforcer funktionierten sowieso prinzipbedingt
> nicht korrekt damit.
"Prinzipbedingt" bedeutet "weil mir Richtlinien egal waren", sehe ich das
richtig? Enforcer gab's auch für den 68060 - später, natürlich, keine
Frage.
> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden wolltest
> ist *dein* persoehnliches Problem. Nicht das Problem des Produktes.
Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer weiter,
als ein Teil des Geschäfts. Anderer Name, ziemlich der gleiche Code.
>> Aha, und darum kann Firma PQS entscheiden, dass sie nun nur noch ihren
>> eigenen Richtlinien folgen wollen und Softwareentwicklern damit Knüppel
>> zwischen die Beine werfen, indem man dokumentierten Richtlininen
>> zuwiderläuft?
> Warum beschwerst du dich nicht bei NVidia, Apple und sonstwem, dass
> sie keine HW Dokumentation rausgeben um "Softwareentwickler" Knueppel
> zwischen die Beine zu werfen.
Wenn ich einen PC/Apple hätte, würde ich das auch. Abgesehen davon:
Zwischen "undokumentiert" und "als etwas anderes dokumentiert" sehe ich
auch gewisse Unterschiede. Es ist nicht so, dass P5 undokumentierte Dinge
anders als CBM gemacht hätte. Es ist vielmehr so, dass man Dinge *entgegen*
der Richtlinien gebaut hat. Auch wieder ein kleiner diffiziler Unterschied,
nicht war?
> Im Computermarkt wird es immer
> schwieriger in irgendeinerweise an Dokumentation zu irgendeinem
> komplexeren Produkt herranzukommen....that's life.
Aber nicht der Punkt.
> Wann realisierst du endlich, dass es fuer eine Firma die eine Loesung
> verkaufen will es *irrelevant* ist wenn ein Programmierer irgendwo
> sitzt und *seine* "partielle" Loesung dafuer anbieten will, ob aus
> kommerziellen gesichtspunkten, sendungsbewusstseins oder irgendeiner
> anderen Motivation.
Du versteht offenbar nicht, worauf ich hinauswill. Hätte CBM nie eine
Speichertabelle herausgegeben, nach der man sich hätte richten können, so
wäre dieses Problem auch nicht entstanden, weil auch nie irgendjemand
einen Enforcer danach hätte schreiben können, der auf allen Maschinen
läuft. Es wäre bei herstellerspezifischen Lösungen geblieben. Ob man
das nun wiederum gut findet, ist eine andere Sache. *Ich* nicht.
> Das *Du* gerne mit HW rumspielst
Nein. Ich spiele gerne mit dokumentierten Interfaces herum.
> und alle moeglichen netten Sachen
> damit machen willst ist ja verstaendlich....aber das ist deine
> "persoehnliche" Sache und nicht Bestandteil des Funktionskataloges
> des Produktes.
Auch falsch. Der Funktionskatalog ist nunmal dokumentiert, nachzulesen,
aufgeschrieben. Und *das* wurde ignoriert.
>> Nur weil die Hardware nicht weiterentwickelt wird, bedeutet dies doch
>> nicht automatisch, dass die damit verwendete Software genauso wenig
>> weiterentwickelt wird. Und als Programmierer muss ich mich nach
>> irgendeinem Dokument richten. Und das *wird* nunmal das RKRM sein, und
>> nicht die nicht-verfügbaren internen Dokumente von PQS.
> "weiterentwickelt" ist doch eine rein subjektive Sache.
> Hardware/Software Produkte werden schon seit langem
> durch NDAs/Nichtdokumentieren usw. als Instrumente
> eingesetzt, um seine strategischen Interessen durchzusetzen.
> Das ist gang und gebe im gesamten Computer Markt.
> Das mag dir nicht passen...mir teilweise auch nicht, teilweise
> nuetzt es mir....nur ich jammere hier nicht seit 3 Jahren rum, wenn
> mir einer nicht das gibt was ich will.
Ich jammere nicht. Ich sage nur, was zutrifft.
>> In der 2060 - ja. In den GVP nein.
> Wenn sie address overloading benutzt, dann viel Spass mit deinen
> virtuellen neuen 68k Rom Entwicklungen:-))
Das hat aber auch rein gar nichts damit zu tun. Und, seit wann habe
ich *irgendwas* mit 68K-ROM Entwicklungen zu tun, oder wollte damit
zu tun haben, oder irgendwas anderes? Erkläre mir mal bitte, was das
mit der MMU zu schaffen haben soll. Wenn Du meinst, diese ganze
ROM-Update Geschichte sei auf meinem Mist gewachsen, oder fände meine
Zustimmung - Bedaure.
> Das ganze ist doch eine Phantomdebatte...
Hallo, Herr Phantom.
>> Nein. Der F-Space ist als "reserved" dokumentiert, und nicht als
>> "reserved for custom specific implementations". Dass es bequem und
>> billiger war, ihn zu benutzen brauchst Du nicht zu sagen und will ja
>> niemand bestreiten. Dass 060-er Support ohne F-Space schwieriger wäre
>> und weitere Hardware benötigt hätte auch. Das macht die ganze
>> Konstruktion aber trotzdem kein Bit besser. Es bleibt bei einer
>> richtlinienwidrigen Ausnutzung eines Speicherraumes. Dies ist keine
>> Einstellungssache, dies ist Tatsache.
> Ach:-)
> Woher willst du denn wissen was zwischen Entwicklern und CBM an
> Kommunikation lief bis 1994 ?(Die 2.0 RKMs sind von 89-91)
Wenn, dann wurde es nicht aufgeschrieben, ich finde dazu nichts auf
der Dev-CD. Eine nicht verfügbare Dokumentation kann ich nicht lesen,
und hilft nichts. Darüber kann man spekulieren, aber nicht steiten.
> Wenn man der CBM Logik zum A3000 gefolgt waere, haette es kein
> IO auf CPU Karten geben duerfen.
Solange man diesen IO durch Autokonfig einbindet ist das bestens.
> Zu den 1200 Uhrporterweiterung
> hab ich auch meine "persoehnliche" Meinung...
Ich auch, und?
> aber offensichtlich
> sind dort Produkte entstanden, die die Leute unbedingt haben wollten,
> weil sie ihnen einen Mehrnutzen gegeben haben.
Ja, aber auch das will ich doch gar nicht bestreiten. Du versteht immer
noch nicht, was ich sagen will. Zu schade, wirklich.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hi Ralph,
>
>>>> Custom ASIC == teuer (viel platz,viele stueckzahlen noetig) FPGAs ==
>>>> billig(eingeschraenkter logik platz und relativ langsam)
>>>> extrem teuer(etwas mehr platz und ein wenig
>>>> schneller)
>>>
>>> Aha, also haben wir zumindest mal festgestellt, dass es auch anders
>>> geht, korrekt? An der Stelle mag ich auch einwenden, dass auch 060er
>
>> GVP konnte sich den Spass um 1990 leisten weil sie die Stueckzahlen
>> verkauft haben. ASICs fangen ab 10000-20000 an.
>
> Sicher, hat auch niemand bestreiten wollen. Und, macht dies den F-Space
> Hack ein Bit konformer?
>
Ich halte die Nutzung des f00000 Bereichs von *CPU Slot* Karten
*nicht* als Hack. Ich halte sie fuer absolut Systemkonform.
Wenn Zorro Karten sich dort *absolut* einblenden wie der Evolution,
dann ist das ein Hack.
>>> Support ohne F-Space ROM möglich ist, würde nur zusätzlichen Aufwand
>>> (Bank-Switching etwa) bedeuten. Dies macht das P5-Vorgehen wohl
>>> billiger, einfacher - was ich nicht bestritten haben will - aber immer
>>> noch nicht besser oder konformer.
>
>> Also du bezeichnest ein overloading der chipram 0 oder f80000 addresse
>> als
>> *konformer*, um bei einem reset als *erster* agieren zu koennen ?
>
> Denke schon. Zumindest kommt mir niemand in die Quere. Addresse 0 ist
> hierbei "die Wahl".
>
Woher soll denn deine CPU Karten HW wissen, was fuer eine init sequenz
nach einem System Reset ausgefuehrt werden muss. Der f00000 Bereich
ueber den module vector oder resident module halte *ich* fuer
systemkonformer als so ne brachial bank switching loesung.
>> Ich wuerde sowas als megahack bezeichnen, der extrem inkompatibel bei
>> neuen Kickroms oder HW Initialisierungen gewesen waere, da es keinem
>> Exec/Coldstart Protokoll folgt.
>
> Das hat auch nichts mit Exec zu tun. Das Boot-Rom kann Exec immer noch
> von Hand hinterherstarten. Inkompatibel? Nein, die Startaddresse der
> ROMs ist ja auf dokumentiertem Wege herauszufinden.
>
Du uebersiehst da eine Kleinigkeit(siehe oben)
>> Ooops..die 2630 benutzt auch diesen Hack...schande aber auch:-)
>
> Schön auch. Hab' auch eine zuhause. Macht bedeutend weniger Probleme...
>
inwiefern macht die b2060 denn Probleme beim usern....das sie mit
"deiner" Vorstellung wie das System zu funktionieren hat kollidiert
ist *dein* Problem.
>>> Ich vermute, Du verwechselst hier etwas. Das o.g. Vorgehen mag
>>> durchaus für diverse Software Probleme erzeugen - ich darf mal rasch
>>> an den Enforcer erinnern? Nicht, dass er *jetzt* noch Probleme hätte,
>>> aber wir sind uns doch soweit darüber im Klaren, dass der Enforcer
>>> hier korrekt und die P5- Einbindung hier nicht korrekt war, oder?
>
>> Die P5 Einbindung bei der MK3/PPC/BlizzardPPC war eine Komplettloesung,
>> wo es irrelevant war ob diverse configdevs existierten oder nicht.
>
> Es war P5 *egal*, aber es ist nicht *irrelevant*. Du verwechselst hier
> zwei Dinge.
>
Fuer das Produkt ist es irrelvant weil es eine komplette Loesung
darstellt. Das dies mit *deinen* Vorstellungen kollidiert und es *dir*
Arbeit macht, um *deine* SW darauf zum lauffaehig macht, ist
fuer den Produzent offensichtlich irrelevant.
>> Die CBM 68040.library und Enforcer funktionierten sowieso
>> prinzipbedingt nicht korrekt damit.
>
> "Prinzipbedingt" bedeutet "weil mir Richtlinien egal waren", sehe ich
> das
> richtig? Enforcer gab's auch für den 68060 - später, natürlich, keine
> Frage.
>
Welche Richtlinien denn jetzt ?
Die ConfigDev, 680x0 "API" "Richtlinien" ?
Jetzt warte ich aber mal auf die RKM und AmigaMail Definition, die
diese beschreiben....
In Wirklichkeit bezeichnest du etwas als Richtlinie, die als "Notbehelf"
von einem *3rd* Party Produkt(Enforcer) "dokumentiert" wurde.
(Wenn Enforcer ein CBM Produkt gewesen waere, haettest du wohl
kaum den Source von Michael bekommen).
Ich kann ja verstehen, dass du M.Sinz als "richtungsweisend" akzeptierst,
aber sorry...wo ist denn da jetzt der Unterschied zu dem fuehrenden
3rd Party Hersteller, der den Amiga Markt eigentlich von 94-99
*getragen* hat. Beide 3rd party....
>> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden
>> wolltest ist *dein* persoehnliches Problem. Nicht das Problem des
>> Produktes.
>
> Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer weiter,
> als ein Teil des Geschäfts. Anderer Name, ziemlich der gleiche Code.
>
Und ? Was hat das mit Phase5 Produkten zu tun ?:-)
>>> Aha, und darum kann Firma PQS entscheiden, dass sie nun nur noch ihren
>>> eigenen Richtlinien folgen wollen und Softwareentwicklern damit
>>> Knüppel zwischen die Beine werfen, indem man dokumentierten
>>> Richtlininen zuwiderläuft?
>
>> Warum beschwerst du dich nicht bei NVidia, Apple und sonstwem, dass sie
>> keine HW Dokumentation rausgeben um "Softwareentwickler" Knueppel
>> zwischen die Beine zu werfen.
>
> Wenn ich einen PC/Apple hätte, würde ich das auch. Abgesehen davon:
> Zwischen "undokumentiert" und "als etwas anderes dokumentiert" sehe ich
> auch gewisse Unterschiede. Es ist nicht so, dass P5 undokumentierte
> Dinge anders als CBM gemacht hätte. Es ist vielmehr so, dass man Dinge
> *entgegen* der Richtlinien gebaut hat. Auch wieder ein kleiner
> diffiziler
> Unterschied, nicht war?
>
Das bestreite ich ganz einfach...
>> Im Computermarkt wird es immer schwieriger in irgendeinerweise an
>> Dokumentation zu irgendeinem komplexeren Produkt
>> herranzukommen....that's life.
>
> Aber nicht der Punkt.
>
>> Wann realisierst du endlich, dass es fuer eine Firma die eine Loesung
>> verkaufen will es *irrelevant* ist wenn ein Programmierer irgendwo
>> sitzt und *seine* "partielle" Loesung dafuer anbieten will, ob aus
>> kommerziellen gesichtspunkten, sendungsbewusstseins oder irgendeiner
>> anderen Motivation.
>
> Du versteht offenbar nicht, worauf ich hinauswill. Hätte CBM nie eine
> Speichertabelle herausgegeben, nach der man sich hätte richten können,
> so wäre dieses Problem auch nicht entstanden, weil auch nie irgendjemand
> einen Enforcer danach hätte schreiben können, der auf allen Maschinen
> läuft. Es wäre bei herstellerspezifischen Lösungen geblieben. Ob man das
> nun wiederum gut findet, ist eine andere Sache. *Ich* nicht.
>
Da schaue ich doch mal in die "configvars.h" und was sehe ich da
For "debugging and diagnostic use" darf man die configdev liste per hand
scannen. Was sagt uns das....jede 680x0.library ist "nicht systemkonform".
Die 68040.library von CBM ist automatisch system konform, da sie vom
System Vendor kommt.
Enforcer/MuForce faellt unter "debugging" und ist somit "freigesprochen"
der Laesterung der heiligen RKMs.
>> Das *Du* gerne mit HW rumspielst
>
> Nein. Ich spiele gerne mit dokumentierten Interfaces herum.
>
>> und alle moeglichen netten Sachen damit machen willst ist ja
>> verstaendlich....aber das ist deine
>> "persoehnliche" Sache und nicht Bestandteil des Funktionskataloges
>> des Produktes.
>
> Auch falsch. Der Funktionskatalog ist nunmal dokumentiert, nachzulesen,
> aufgeschrieben. Und *das* wurde ignoriert.
>
Nirgendswo wird von Phase5 als Funktion angegeben, dass es mit
"Enforcer,mu#?" laeuft.
Wenn du auf die OS "APIs" hinweisst, stimmt es doch einfach nicht.
>>> Nur weil die Hardware nicht weiterentwickelt wird, bedeutet dies doch
>>> nicht automatisch, dass die damit verwendete Software genauso wenig
>>> weiterentwickelt wird. Und als Programmierer muss ich mich nach
>>> irgendeinem Dokument richten. Und das *wird* nunmal das RKRM sein, und
>>> nicht die nicht-verfügbaren internen Dokumente von PQS.
>
>> "weiterentwickelt" ist doch eine rein subjektive Sache.
>> Hardware/Software Produkte werden schon seit langem durch
>> NDAs/Nichtdokumentieren usw. als Instrumente eingesetzt, um seine
>> strategischen Interessen durchzusetzen. Das ist gang und gebe im
>> gesamten Computer Markt. Das mag dir nicht passen...mir teilweise auch
>> nicht, teilweise nuetzt es mir....nur ich jammere hier nicht seit 3
>> Jahren rum, wenn mir einer nicht das gibt was ich will.
>
> Ich jammere nicht. Ich sage nur, was zutrifft.
>
Du hast offensichtlich eine selektive Wahrnehmung bzgl. gewissen
"dokumentierten" Interfaces und ein nichtwissen bzgl. CBM/3rd
party Kommunikation.
>>> In der 2060 - ja. In den GVP nein.
>
>> Wenn sie address overloading benutzt, dann viel Spass mit deinen
>> virtuellen neuen 68k Rom Entwicklungen:-))
>
> Das hat aber auch rein gar nichts damit zu tun. Und, seit wann habe ich
> *irgendwas* mit 68K-ROM Entwicklungen zu tun, oder wollte damit zu tun
> haben, oder irgendwas anderes? Erkläre mir mal bitte, was das mit der
> MMU zu schaffen haben soll. Wenn Du meinst, diese ganze ROM-Update
> Geschichte sei auf meinem Mist gewachsen, oder fände meine Zustimmung -
> Bedaure.
>
Diese ganze virtuelle Debatte bzgl. rom module slot dreht sich doch nur
darum, dass es *eventuell* mal eine neuere HW und neuere Roms gegeben
haette.(Phantomdebatte).
Das Rom Module Interface war 3rd parties bekannt....ein bankswitching
halte ich fuer extrem unsicher bei "neuerer" "virtueller" 68k HW
Entwicklung, da es sich *vor* dem Rom einblenden wuerde.
>> Das ganze ist doch eine Phantomdebatte...
>
> Hallo, Herr Phantom.
>
>>> Nein. Der F-Space ist als "reserved" dokumentiert, und nicht als
>>> "reserved for custom specific implementations". Dass es bequem und
>>> billiger war, ihn zu benutzen brauchst Du nicht zu sagen und will ja
>>> niemand bestreiten. Dass 060-er Support ohne F-Space schwieriger wäre
>>> und weitere Hardware benötigt hätte auch. Das macht die ganze
>>> Konstruktion aber trotzdem kein Bit besser. Es bleibt bei einer
>>> richtlinienwidrigen Ausnutzung eines Speicherraumes. Dies ist keine
>>> Einstellungssache, dies ist Tatsache.
>
>> Ach:-) Woher willst du denn wissen was zwischen Entwicklern und CBM an
>> Kommunikation lief bis 1994 ?(Die 2.0 RKMs sind von 89-91)
>
> Wenn, dann wurde es nicht aufgeschrieben, ich finde dazu nichts auf der
> Dev-CD. Eine nicht verfügbare Dokumentation kann ich nicht lesen, und
> hilft nichts. Darüber kann man spekulieren, aber nicht steiten.
>
Auf keiner Dev-CD sind z.b. die exzellenten Devcon Ordner enthalten.
Dann gibt es auch noch die Frage..welche Dev-CD ?
Die Cats, die danach von AT/A+(Olsen) oder dann H&P.
Dann gab es BIX und das europaeische Developernetz und dann halt
auch noch direkte Kontakte zu CBM Engineering von 3rd Parties.
>> Wenn man der CBM Logik zum A3000 gefolgt waere, haette es kein IO auf
>> CPU Karten geben duerfen.
>
> Solange man diesen IO durch Autokonfig einbindet ist das bestens.
>
Stop...der A3000 hat keine Int2/Int6 Leitung am CPU Slot aus
systemidiologischen Gruenden wie Dave Haynie es mal erklaert
hat.(Aus 3rd Party Sicht machte das Fehlen der Leitungen nie Sinn).
>> Zu den 1200 Uhrporterweiterung hab ich auch meine "persoehnliche"
>> Meinung...
>
> Ich auch, und?
>
>> aber offensichtlich sind dort Produkte entstanden, die die Leute
>> unbedingt haben wollten, weil sie ihnen einen Mehrnutzen gegeben haben.
>
> Ja, aber auch das will ich doch gar nicht bestreiten. Du versteht immer
> noch nicht, was ich sagen will. Zu schade, wirklich.
>
Sicherlich weiss ich worum es dir geht. Dein Problem ist ganz einfach,
dass ein Hersteller(und eine gewisse Person) nicht alles so implementiert
und offengelegt haben, damit du keine Mehrarbeit mit dem
*selbsteruebernommenen* "support" dessen Produkte hast.
Um das was dir nicht passt alle paar Monate mal "aufleben" zu lassen
greifst du dann zu der Argumentationskeule "nicht Systemkonform".
P.S. Apropo Systemkonform...wo steht es eigentlich geschrieben, dass man
das input.device mit Unit 1(alias VBLANK_UNIT) oeffnen darf,
weil man 2 bytes sparen will.("vnc.library" 3.73)
Wer im Glashaus sitzt,.....:-)
Michael Ulbrich
Ralph, sieh es doch mal so: wohl 80% von hard- und Software meines hier
laufenden A4k sind vermutlich Hacks im Sinne der C= - Dokus.
Damit habe ich keine Probleme, solange ich das weiß und somit darauf
vorbereitet bin, daß es Probleme geben kann, wenn irgendein anderer
Hard-/Softwareentwickler zu ähnlichen Lösungen greifen muß, weil es
auf Grund der Entwicklung eben nicht anders geht. Es vermeidet für mich
nur die sowieso nutzlose Suche nach "Schuldigen", wenn irgendwas anders
läuft als bei jemand anders in anderer Konfiguration.
So verstehe ich erstmal "Hack" als Abgrenzung gegenüber einem in den alten
Unterlagen eindeutig definierten Vorgehen.
Der Unterschied liegt für mich eher in unnötigen Hacks und in unvermeidbaren.
Logisch, daß C= den 060er wohl kaum schon eingeplat hat.
Michael Ulbrich
>In de.comp.sys.amiga.tech Thomas Didjurgies <Luc...@t-online.de> wrote:
>> ich habe noch einen alten Werbeprospekt fuer den A4000. In diesem steht,
>> dass max. 2GB !! RAM verwaltet werden koennen.
>Ja, diese Marketingleute... Soviel kann die CPU addressieren. Nicht, dass
>man soviel hineinstecken könnte.
Ich habe jetzt nirgends nachgeschaut (wozu auch, Thomas weiß das sowieso... ;)),
Z3 sollte aber mehr können oder ist z.B. die FastLaneZ3-variante mit 256MB im
Z3 schon illegal gelöst? Es sollten doch auch 4x FastLane mit je 256MB gehen?
IMHO ist das Problem doch nur der CPU-Slot?
Thomas Richter
> Thomas Richter bemerkte am 22-Mai-01 12:09:19
>>In de.comp.sys.amiga.tech Thomas Didjurgies <Luc...@t-online.de> wrote:
>>> ich habe noch einen alten Werbeprospekt fuer den A4000. In diesem steht,
>>> dass max. 2GB !! RAM verwaltet werden koennen.
>>Ja, diese Marketingleute... Soviel kann die CPU addressieren. Nicht, dass
>>man soviel hineinstecken könnte.
> Ich habe jetzt nirgends nachgeschaut (wozu auch, Thomas weiß das sowieso... ;)),
Auswending auch nicht. RKRM-HW gibt den Addressraum 0x80000000 bis 0x10000000 als
Z3-Config aus, das w"aren 1792 MB oder wirklich fast 2GB. (Ich staune auch).
Z3-Erweiterungen k"onnen im Prinzip bis zu 1GB Speicher signalisieren (auch
RKRM-HW, p433)
> Z3 sollte aber mehr können oder ist z.B. die FastLaneZ3-variante mit 256MB im
> Z3 schon illegal gelöst? Es sollten doch auch 4x FastLane mit je 256MB gehen?
Doch, denke schon.
> IMHO ist das Problem doch nur der CPU-Slot?
Dazu kann ich nicht viel sagen, bedaure...
Thomas Richter
>> Hack ein Bit konformer?
> Ich halte die Nutzung des f00000 Bereichs von *CPU Slot* Karten
> *nicht* als Hack. Ich halte sie fuer absolut Systemkonform.
> Wenn Zorro Karten sich dort *absolut* einblenden wie der Evolution,
> dann ist das ein Hack.
Erstens, nein. Zweitens, ja, sicher.
>>> Also du bezeichnest ein overloading der chipram 0 oder f80000 addresse
>>> als
>>> *konformer*, um bei einem reset als *erster* agieren zu koennen ?
>>
>> Denke schon. Zumindest kommt mir niemand in die Quere. Addresse 0 ist
>> hierbei "die Wahl".
> Woher soll denn deine CPU Karten HW wissen, was fuer eine init sequenz
> nach einem System Reset ausgefuehrt werden muss.
Bank-Switching ausschalten, damit kommt das Kickstart ab Adresse 0 zu
liegen. Rest automatisch wie gehabt.
> Der f00000 Bereich
> ueber den module vector oder resident module halte *ich* fuer
> systemkonformer als so ne brachial bank switching loesung.
Solange man auf die Software im F-Space nach Einschalten verzichten
k"onnte - damit könnte man klarkommen. Kann man aber nicht, da liegt
auch Hardware. Hardware ist aber anzumelden.
>>> Ich wuerde sowas als megahack bezeichnen, der extrem inkompatibel bei
>>> neuen Kickroms oder HW Initialisierungen gewesen waere, da es keinem
>>> Exec/Coldstart Protokoll folgt.
>>
>> Das hat auch nichts mit Exec zu tun. Das Boot-Rom kann Exec immer noch
>> von Hand hinterherstarten. Inkompatibel? Nein, die Startaddresse der
>> ROMs ist ja auf dokumentiertem Wege herauszufinden.
>>
> Du uebersiehst da eine Kleinigkeit(siehe oben)
Aha? Klär' mich auf.
>>> Ooops..die 2630 benutzt auch diesen Hack...schande aber auch:-)
>>
>> Schön auch. Hab' auch eine zuhause. Macht bedeutend weniger Probleme...
>>
> inwiefern macht die b2060 denn Probleme beim usern....das sie mit
> "deiner" Vorstellung wie das System zu funktionieren hat kollidiert
> ist *dein* Problem.
Das ist nicht *meine* Vorstellung. Das ist die aufgeschriebene Vorstellung,
und danach richte ich mich.
>>> Die P5 Einbindung bei der MK3/PPC/BlizzardPPC war eine Komplettloesung,
>>> wo es irrelevant war ob diverse configdevs existierten oder nicht.
>>
>> Es war P5 *egal*, aber es ist nicht *irrelevant*. Du verwechselst hier
>> zwei Dinge.
>>
> Fuer das Produkt ist es irrelvant weil es eine komplette Loesung
> darstellt.
Aha. Software gehört nicht zum Produkt? Das Funktionieren von Software
dritter Parteien, die sich nach den RKRMs richten, ist nicht Teil des
Produktes? Eine recht eigenwillige Vorstellung.
> Das dies mit *deinen* Vorstellungen kollidiert und es *dir*
> Arbeit macht, um *deine* SW darauf zum lauffaehig macht, ist
> fuer den Produzent offensichtlich irrelevant.
Da es den Produzenten nicht mehr gibt, ist es sowieso irrelevant.
>>> Die CBM 68040.library und Enforcer funktionierten sowieso
>>> prinzipbedingt nicht korrekt damit.
>>
>> "Prinzipbedingt" bedeutet "weil mir Richtlinien egal waren", sehe ich
>> das
>> richtig? Enforcer gab's auch für den 68060 - später, natürlich, keine
>> Frage.
>>
> Welche Richtlinien denn jetzt ?
> Die ConfigDev, 680x0 "API" "Richtlinien" ?
> Jetzt warte ich aber mal auf die RKM und AmigaMail Definition, die
> diese beschreiben....
> In Wirklichkeit bezeichnest du etwas als Richtlinie, die als "Notbehelf"
> von einem *3rd* Party Produkt(Enforcer) "dokumentiert" wurde.
Und so in der 68040.library implementiert wurde, die Produkt von CBM
war, und vom gleichen Autor stammt.
> (Wenn Enforcer ein CBM Produkt gewesen waere, haettest du wohl
> kaum den Source von Michael bekommen).
Sicher.
> Ich kann ja verstehen, dass du M.Sinz als "richtungsweisend" akzeptierst,
> aber sorry...wo ist denn da jetzt der Unterschied zu dem fuehrenden
> 3rd Party Hersteller, der den Amiga Markt eigentlich von 94-99
> *getragen* hat. Beide 3rd party....
Dass Mike Produktentwicklung für CBM gemacht hat? Das er seine
Lösungen dokumentiert hat, ich aber immer noch keine Dokumentation von P5
habe, obwohl ich mich danach gerichtet hätte?
Bedaure sehr, es ist nunmal schwierig, sich nach Dokumenten zu richten,
die man nicht haben darf. Zen-Computing?
>>> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden
>>> wolltest ist *dein* persoehnliches Problem. Nicht das Problem des
>>> Produktes.
>>
>> Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer weiter,
>> als ein Teil des Geschäfts. Anderer Name, ziemlich der gleiche Code.
>>
> Und ? Was hat das mit Phase5 Produkten zu tun ?:-)
Nix. Ich wehre mich nur gegen Deine irrtümliche Feststellung, das Rad neu
erfunden zu haben. Ich habe den Reifen runderneuert, ja. Das Rad ist noch
immer das gleiche.
>> Wenn ich einen PC/Apple hätte, würde ich das auch. Abgesehen davon:
>> Zwischen "undokumentiert" und "als etwas anderes dokumentiert" sehe ich
>> auch gewisse Unterschiede. Es ist nicht so, dass P5 undokumentierte
>> Dinge anders als CBM gemacht hätte. Es ist vielmehr so, dass man Dinge
>> *entgegen* der Richtlinien gebaut hat. Auch wieder ein kleiner
>> diffiziler
>> Unterschied, nicht war?
>>
> Das bestreite ich ganz einfach...
HW-RKRM, Seite 314, F000-0000: "Reserved, Do not use".
Falls Du andere, neuere Dokumente hast, so lese ich diese gerne (wirklich!).
>> Du versteht offenbar nicht, worauf ich hinauswill. Hätte CBM nie eine
>> Speichertabelle herausgegeben, nach der man sich hätte richten können,
>> so wäre dieses Problem auch nicht entstanden, weil auch nie irgendjemand
>> einen Enforcer danach hätte schreiben können, der auf allen Maschinen
>> läuft. Es wäre bei herstellerspezifischen Lösungen geblieben. Ob man das
>> nun wiederum gut findet, ist eine andere Sache. *Ich* nicht.
>>
> Da schaue ich doch mal in die "configvars.h" und was sehe ich da
> For "debugging and diagnostic use" darf man die configdev liste per hand
> scannen. Was sagt uns das....jede 680x0.library ist "nicht systemkonform".
> Die 68040.library von CBM ist automatisch system konform, da sie vom
> System Vendor kommt.
> Enforcer/MuForce faellt unter "debugging" und ist somit "freigesprochen"
> der Laesterung der heiligen RKMs.
Wurde später von Mike dokumentiert, wissen wir doch beide. Siehe oben.
>> Auch falsch. Der Funktionskatalog ist nunmal dokumentiert, nachzulesen,
>> aufgeschrieben. Und *das* wurde ignoriert.
> Nirgendswo wird von Phase5 als Funktion angegeben, dass es mit
> "Enforcer,mu#?" laeuft.
Ahja? Steht da im Handbuch, dass man bestimmte Software nicht einsetzen kann,
obwohl sich diese an Herstellervorgaben hält?
> Wenn du auf die OS "APIs" hinweisst, stimmt es doch einfach nicht.
>> Ich jammere nicht. Ich sage nur, was zutrifft.
>>
> Du hast offensichtlich eine selektive Wahrnehmung bzgl. gewissen
> "dokumentierten" Interfaces und ein nichtwissen bzgl. CBM/3rd
> party Kommunikation.
Letzteres sicherlich, da die Dokumente nicht zugänglich sind/waren.
An Dokumente, die ich nicht kenne, kann ich mich nicht richten.
>> Das hat aber auch rein gar nichts damit zu tun. Und, seit wann habe ich
>> *irgendwas* mit 68K-ROM Entwicklungen zu tun, oder wollte damit zu tun
>> haben, oder irgendwas anderes? Erkläre mir mal bitte, was das mit der
>> MMU zu schaffen haben soll. Wenn Du meinst, diese ganze ROM-Update
>> Geschichte sei auf meinem Mist gewachsen, oder fände meine Zustimmung -
>> Bedaure.
>>
> Diese ganze virtuelle Debatte bzgl. rom module slot dreht sich doch nur
> darum, dass es *eventuell* mal eine neuere HW und neuere Roms gegeben
> haette.(Phantomdebatte).
Was, von wem? Von mir nicht. Mein Einwand gegen den F-Space ist, dass ich
diesen Speicherbereich mappen muss, obwohl keine ConfigDev darauf hinweist,
und nicht mal klar ist, wie man sie zu mappen hat. Der F-Space bei P5-
Produkten ist dabei noch das kleinste Problem.
> Das Rom Module Interface war 3rd parties bekannt....ein bankswitching
> halte ich fuer extrem unsicher bei "neuerer" "virtueller" 68k HW
> Entwicklung, da es sich *vor* dem Rom einblenden wuerde.
Richtig, müsste. Phantomdebatte? (-;
>> Wenn, dann wurde es nicht aufgeschrieben, ich finde dazu nichts auf der
>> Dev-CD. Eine nicht verfügbare Dokumentation kann ich nicht lesen, und
>> hilft nichts. Darüber kann man spekulieren, aber nicht steiten.
> Auf keiner Dev-CD sind z.b. die exzellenten Devcon Ordner enthalten.
> Dann gibt es auch noch die Frage..welche Dev-CD ?
> Die Cats, die danach von AT/A+(Olsen) oder dann H&P.
Habe 2. und 3. vorliegen. Falls Du noch mehr/weiter Dokumente hast,
bitte gern.
> Dann gab es BIX und das europaeische Developernetz und dann halt
> auch noch direkte Kontakte zu CBM Engineering von 3rd Parties.
Nehme ich gern entgegen. Wirklich.
>>> Wenn man der CBM Logik zum A3000 gefolgt waere, haette es kein IO auf
>>> CPU Karten geben duerfen.
>>
>> Solange man diesen IO durch Autokonfig einbindet ist das bestens.
>>
> Stop...der A3000 hat keine Int2/Int6 Leitung am CPU Slot aus
> systemidiologischen Gruenden wie Dave Haynie es mal erklaert
> hat.(Aus 3rd Party Sicht machte das Fehlen der Leitungen nie Sinn).
Halte ich für einen Design-Bug. Darüber braucht man nicht streiten...
>> Ja, aber auch das will ich doch gar nicht bestreiten. Du versteht immer
>> noch nicht, was ich sagen will. Zu schade, wirklich.
> Sicherlich weiss ich worum es dir geht. Dein Problem ist ganz einfach,
> dass ein Hersteller(und eine gewisse Person) nicht alles so implementiert
> und offengelegt haben, damit du keine Mehrarbeit mit dem
> *selbsteruebernommenen* "support" dessen Produkte hast.
> Um das was dir nicht passt alle paar Monate mal "aufleben" zu lassen
> greifst du dann zu der Argumentationskeule "nicht Systemkonform".
Du kannst dies alles doch nachlesen, siehe RKRMs.
> P.S. Apropo Systemkonform...wo steht es eigentlich geschrieben, dass man
> das input.device mit Unit 1(alias VBLANK_UNIT) oeffnen darf,
> weil man 2 bytes sparen will.("vnc.library" 3.73)
> Wer im Glashaus sitzt,.....:-)
Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den ich
beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine Paranoia?
Ach, weisst Du, Programmfehler zum Vorwurf zu machen... ...sicher mache ich
Fehler. Was willst Du beweisen? Das ich welche mache, hätte ich auch so
zugegegeben. Ich schreib' sie sogar in die Revisionsreports.
Thomas Richter
Hi Ralph,
> Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den ich
> beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine Paranoia?
> Ach, weisst Du, Programmfehler zum Vorwurf zu machen... ...sicher mache ich
> Fehler. Was willst Du beweisen? Das ich welche mache, hätte ich auch so
> zugegegeben. Ich schreib' sie sogar in die Revisionsreports.
Falls es diesen Bug mal gab... Er ist seit geraumer Zeit behoben. Ich grabe jetzt
nicht die Versionshistory aus um nachzusehen, wann, müsste aber schon eine
ganze Weile her sein. Soviel zum Thema Glashäuser. Übrigens, wenn Dir das Spiel
Spaß macht: War natürlich nicht der einzige Bug in der 3.73. Willst Du mir
beim Debuggin helfen? (-;
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hi Ralph,
>
>> Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den
>> ich beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine
>> Paranoia?
>
>> Ach, weisst Du, Programmfehler zum Vorwurf zu machen... ...sicher mache
>> ich Fehler. Was willst Du beweisen? Das ich welche mache, hätte ich
>> auch so zugegegeben. Ich schreib' sie sogar in die Revisionsreports.
>
> Falls es diesen Bug mal gab... Er ist seit geraumer Zeit behoben. Ich
> grabe jetzt nicht die Versionshistory aus um nachzusehen, wann, müsste
> aber schon eine ganze Weile her sein. Soviel zum Thema Glashäuser.
Das war afaik die letzte oeffentliche Version.
Es ist mir eigentlich auch egal, weil ich es nicht benutze....viel mir
nur bei einer Problemanlyse vor einigen Monaten auf.
> Übrigens, wenn Dir das Spiel Spaß macht: War natürlich nicht der einzige
> Bug in der 3.73. Willst Du mir beim Debuggin helfen? (-;
Noe...ich fand ihn nur passend in dem diskutierten Kontext:-)
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hi Ralph, In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de>
> wrote:
>
>>> Sicher, hat auch niemand bestreiten wollen. Und, macht dies den
>>> F-Space Hack ein Bit konformer?
>
>> Ich halte die Nutzung des f00000 Bereichs von *CPU Slot* Karten
>> *nicht* als Hack. Ich halte sie fuer absolut Systemkonform.
>> Wenn Zorro Karten sich dort *absolut* einblenden wie der Evolution,
>> dann ist das ein Hack.
>
> Erstens, nein. Zweitens, ja, sicher.
>
Es ist wohl sinnlos mit dir darueber zu argumentieren.
>>>> Also du bezeichnest ein overloading der chipram 0 oder f80000
>>>> addresse als
>>>> *konformer*, um bei einem reset als *erster* agieren zu koennen ?
>>>
>>> Denke schon. Zumindest kommt mir niemand in die Quere. Addresse 0 ist
>>> hierbei "die Wahl".
>
>> Woher soll denn deine CPU Karten HW wissen, was fuer eine init sequenz
>> nach einem System Reset ausgefuehrt werden muss.
>
> Bank-Switching ausschalten, damit kommt das Kickstart ab Adresse 0 zu
> liegen. Rest automatisch wie gehabt.
>
Echt ?..woher will denn eine 3rd party HW genau wissen in welcher
(timing) sequenz nach einem Reset das system angesteuert werden
muss.
Sicher weiss man das bzgl. einem 68k aber nicht bzgl. einem *System*.
Mir ist keine Dokumentation bekannt, wo das definiert wird...
>> Der f00000 Bereich ueber den module vector oder resident module halte
>> *ich* fuer systemkonformer als so ne brachial bank switching loesung.
>
> Solange man auf die Software im F-Space nach Einschalten verzichten
> k"onnte - damit könnte man klarkommen. Kann man aber nicht, da liegt
> auch Hardware. Hardware ist aber anzumelden.
>
Wo steht denn das man HW anmelden muss ?
Ich sehe auch keine Anmeldung fuer pcmcia, ide und andere
*Commodore* local HW in der configdev list.
In configvars.h steht nur, dass ****Zorro**** Boards per configdev
im system eingetragen werden.
Deine Wahrnehmung ist selektiv bzgl. dieser Geschichte.
>>>> Ich wuerde sowas als megahack bezeichnen, der extrem inkompatibel bei
>>>> neuen Kickroms oder HW Initialisierungen gewesen waere, da es keinem
>>>> Exec/Coldstart Protokoll folgt.
>>>
>>> Das hat auch nichts mit Exec zu tun. Das Boot-Rom kann Exec immer noch
>>> von Hand hinterherstarten. Inkompatibel? Nein, die Startaddresse der
>>> ROMs ist ja auf dokumentiertem Wege herauszufinden.
>>>
>
>> Du uebersiehst da eine Kleinigkeit(siehe oben)
>
> Aha? Klär' mich auf.
>
Siehe oben
>>>> Ooops..die 2630 benutzt auch diesen Hack...schande aber auch:-)
>>>
>>> Schön auch. Hab' auch eine zuhause. Macht bedeutend weniger
>>> Probleme...
>>>
>
>> inwiefern macht die b2060 denn Probleme beim usern....das sie mit
>> "deiner" Vorstellung wie das System zu funktionieren hat kollidiert
>> ist *dein* Problem.
>
> Das ist nicht *meine* Vorstellung. Das ist die aufgeschriebene
> Vorstellung, und danach richte ich mich.
>
>>>> Die P5 Einbindung bei der MK3/PPC/BlizzardPPC war eine
>>>> Komplettloesung, wo es irrelevant war ob diverse configdevs
>>>> existierten oder nicht.
>>>
>>> Es war P5 *egal*, aber es ist nicht *irrelevant*. Du verwechselst hier
>>> zwei Dinge.
>>>
>
>> Fuer das Produkt ist es irrelvant weil es eine komplette Loesung
>> darstellt.
>
> Aha. Software gehört nicht zum Produkt? Das Funktionieren von Software
> dritter Parteien, die sich nach den RKRMs richten, ist nicht Teil des
> Produktes? Eine recht eigenwillige Vorstellung.
>
Die MMU Steuerung ist Sache des Produktes....dementsprechend ist externe
MMU Software irrelevant fuer die Funktion des Produktes.
<cut>
>
>> In Wirklichkeit bezeichnest du etwas als Richtlinie, die als
>> "Notbehelf" von einem *3rd* Party Produkt(Enforcer) "dokumentiert"
>> wurde.
>
> Und so in der 68040.library implementiert wurde, die Produkt von CBM
> war, und vom gleichen Autor stammt.
>
Jetzt wird es interessant...woher weisst du denn von *CBM* wie eine
680x0 library zu implementieren ist. Und seit wann hat eine
Implementation mit einer Definition zu tun ?
Wie schon oben beschrieben, macht die CBM 68040 library in ihrer
*Implementation* auch ein Check auf lokale HW wie PCMCIA und
haengt dann den entsprechenden Adressbereich in den MMU Baum.
Genauso macht es auch die Phase5 library mit lokalen resourcen
auf *ihrer* HW.
>> (Wenn Enforcer ein CBM Produkt gewesen waere, haettest du wohl
>> kaum den Source von Michael bekommen).
>
> Sicher.
>
>> Ich kann ja verstehen, dass du M.Sinz als "richtungsweisend"
>> akzeptierst, aber sorry...wo ist denn da jetzt der Unterschied zu dem
>> fuehrenden
>> 3rd Party Hersteller, der den Amiga Markt eigentlich von 94-99
>> *getragen* hat. Beide 3rd party....
>
> Dass Mike Produktentwicklung für CBM gemacht hat? Das er seine Lösungen
> dokumentiert hat, ich aber immer noch keine Dokumentation von P5 habe,
> obwohl ich mich danach gerichtet hätte?
>
Ich habe gerade den 0xf00000 bereich fuer cpu slot karten als private
spielwiese dokumentiert. Nur irgendwie willst du dich nicht dran halten.
Wodran liegt das blos:-)
Du argumentierst einfach so wie es dir gerade passt....einmal ziehst
du das RKM herran und verdammst 3rd party "Erweiterungen" und
dann wird auf 3rd party definitionen als "Kanon" hingewiesen.
Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
dokumentiert.
Man darf gerne privat in dem *existierenden* MMU Table rumfuschen.
Man darf aber nie die Kontrolle uebernehmen.
Das ist eine klare Dokumentation:-) Sie kollidiert halt nur mit *deinen*
Interessen.
> Bedaure sehr, es ist nunmal schwierig, sich nach Dokumenten zu richten,
> die man nicht haben darf. Zen-Computing?
>
Ich dachte du richtest dich nur nach RKM Dokumenten....
>>>> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden
>>>> wolltest ist *dein* persoehnliches Problem. Nicht das Problem des
>>>> Produktes.
>>>
>>> Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer
>>> weiter, als ein Teil des Geschäfts. Anderer Name, ziemlich der gleiche
>>> Code.
>>>
>
>> Und ? Was hat das mit Phase5 Produkten zu tun ?:-)
>
> Nix. Ich wehre mich nur gegen Deine irrtümliche Feststellung, das Rad
> neu erfunden zu haben. Ich habe den Reifen runderneuert, ja. Das Rad ist
> noch immer das gleiche.
>
Die sogenannte "neue" Bereifung laeuft ohne einen signifikanten
Unterschied verglichen zur "alten" Bereifung, da der Reifen eigentlich
immer in der Garage steht.
>>> Wenn ich einen PC/Apple hätte, würde ich das auch. Abgesehen davon:
>>> Zwischen "undokumentiert" und "als etwas anderes dokumentiert" sehe
>>> ich auch gewisse Unterschiede. Es ist nicht so, dass P5
>>> undokumentierte Dinge anders als CBM gemacht hätte. Es ist vielmehr
>>> so, dass man Dinge
>>> *entgegen* der Richtlinien gebaut hat. Auch wieder ein kleiner
>>> diffiziler Unterschied, nicht war?
>>>
>
>> Das bestreite ich ganz einfach...
>
> HW-RKRM, Seite 314, F000-0000: "Reserved, Do not use".
>
> Falls Du andere, neuere Dokumente hast, so lese ich diese gerne
> (wirklich!).
>
Und ich behaupte ganz einfach, dass der Bereich fuer CPU Slot
Karten zur freien Nutzung da ist.
>>> Du versteht offenbar nicht, worauf ich hinauswill. Hätte CBM nie eine
>>> Speichertabelle herausgegeben, nach der man sich hätte richten können,
>>> so wäre dieses Problem auch nicht entstanden, weil auch nie
>>> irgendjemand einen Enforcer danach hätte schreiben können, der auf
>>> allen Maschinen läuft. Es wäre bei herstellerspezifischen Lösungen
>>> geblieben. Ob man das nun wiederum gut findet, ist eine andere Sache.
>>> *Ich* nicht.
>>>
>
>> Da schaue ich doch mal in die "configvars.h" und was sehe ich da
>
>> For "debugging and diagnostic use" darf man die configdev liste per
>> hand scannen. Was sagt uns das....jede 680x0.library ist "nicht
>> systemkonform". Die 68040.library von CBM ist automatisch system
>> konform, da sie vom System Vendor kommt. Enforcer/MuForce faellt unter
>> "debugging" und ist somit "freigesprochen" der Laesterung der heiligen
>> RKMs.
>
> Wurde später von Mike dokumentiert, wissen wir doch beide. Siehe oben.
>
Sicher weiss ich das....aber du argumentierst mit Inhalten aus Mike's
Dokumentation als waeren diese von CBM und das entspricht einfach
nicht den Fakten.
>>> Auch falsch. Der Funktionskatalog ist nunmal dokumentiert,
>>> nachzulesen, aufgeschrieben. Und *das* wurde ignoriert.
>
>> Nirgendswo wird von Phase5 als Funktion angegeben, dass es mit
>> "Enforcer,mu#?" laeuft.
>
> Ahja? Steht da im Handbuch, dass man bestimmte Software nicht einsetzen
> kann, obwohl sich diese an Herstellervorgaben hält?
>
Da es kein definiertes MMU Handling vom OS gibt, ist das Sache des
CPU Karten Herstellers.
>> Wenn du auf die OS "APIs" hinweisst, stimmt es doch einfach nicht.
>
>>> Ich jammere nicht. Ich sage nur, was zutrifft.
>>>
>
>> Du hast offensichtlich eine selektive Wahrnehmung bzgl. gewissen
>> "dokumentierten" Interfaces und ein nichtwissen bzgl. CBM/3rd
>> party Kommunikation.
>
> Letzteres sicherlich, da die Dokumente nicht zugänglich sind/waren. An
> Dokumente, die ich nicht kenne, kann ich mich nicht richten.
>
>>> Das hat aber auch rein gar nichts damit zu tun. Und, seit wann habe
>>> ich
>>> *irgendwas* mit 68K-ROM Entwicklungen zu tun, oder wollte damit zu tun
>>> haben, oder irgendwas anderes? Erkläre mir mal bitte, was das mit der
>>> MMU zu schaffen haben soll. Wenn Du meinst, diese ganze ROM-Update
>>> Geschichte sei auf meinem Mist gewachsen, oder fände meine Zustimmung
>>> - Bedaure.
>>>
>
>> Diese ganze virtuelle Debatte bzgl. rom module slot dreht sich doch nur
>> darum, dass es *eventuell* mal eine neuere HW und neuere Roms gegeben
>> haette.(Phantomdebatte).
>
> Was, von wem? Von mir nicht. Mein Einwand gegen den F-Space ist, dass
> ich diesen Speicherbereich mappen muss, obwohl keine ConfigDev darauf
> hinweist, und nicht mal klar ist, wie man sie zu mappen hat. Der F-Space
> bei P5- Produkten ist dabei noch das kleinste Problem.
>
Warum musst *du* den denn mappen. Das ist Sache des Herstellers.
Das ist doch das was *du* nicht realisieren willst.
<cut>
>> Stop...der A3000 hat keine Int2/Int6 Leitung am CPU Slot aus
>> systemidiologischen Gruenden wie Dave Haynie es mal erklaert hat.(Aus
>> 3rd Party Sicht machte das Fehlen der Leitungen nie Sinn).
>
> Halte ich für einen Design-Bug. Darüber braucht man nicht streiten...
>
Hab ich auch dafuer gehalten...aber laut Dave Haynie war das
*gewollt*. Dafuer haben sie dann beim A4000 die Moeglichkeit
von Zorro Karten alle Ints zu genieren eleminiert(gewollt).
Beim A3000 ging das noch.
>>> Ja, aber auch das will ich doch gar nicht bestreiten. Du versteht
>>> immer noch nicht, was ich sagen will. Zu schade, wirklich.
>
>> Sicherlich weiss ich worum es dir geht. Dein Problem ist ganz einfach,
>> dass ein Hersteller(und eine gewisse Person) nicht alles so
>> implementiert und offengelegt haben, damit du keine Mehrarbeit mit dem
>> *selbsteruebernommenen* "support" dessen Produkte hast.
>> Um das was dir nicht passt alle paar Monate mal "aufleben" zu lassen
>> greifst du dann zu der Argumentationskeule "nicht Systemkonform".
>
> Du kannst dies alles doch nachlesen, siehe RKRMs.
>
Und die sind nicht alles und zweitens dokumentieren die auch nicht alles
was du hier immer vorbetest bzgl. configdevs.
>> P.S. Apropo Systemkonform...wo steht es eigentlich geschrieben, dass
>> man
>> das input.device mit Unit 1(alias VBLANK_UNIT) oeffnen darf,
>> weil man 2 bytes sparen will.("vnc.library" 3.73) Wer im
>> Glashaus sitzt,.....:-)
>
> Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den ich
> beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine
> Paranoia?
>
Noe..
>
> Ach, weisst Du, Programmfehler zum Vorwurf zu machen... ...sicher mache
> ich Fehler. Was willst Du beweisen? Das ich welche mache, hätte ich auch
> so zugegegeben. Ich schreib' sie sogar in die Revisionsreports.
>
Ich mache dir das nicht zum Vorwurf. Ich renne hier doch nicht mit
der "nicht Systemapproved" Keule rum wie du.
Es passte nur aus meiner Sicht im Kontext bzgl. "Systemkonform"
und sollte unter dem Motto "wie man in den Wald schreit schallt es herraus"
gesehen werden:-)
Chris Classen
Hi!
> > Das ist, glaube ich, durchaus möglich. 16MB auf der Hauptplatine, 128MB
> > auf der TK, eine Daughterboardplatine mit zahlreichen Zorroslots, wovon
> > jeder mit reichlich Speicherkarten/Controllern mit Speicheroption bestückt
> > ist - warum nicht?
>
> Weil der Autoconfig-Raum nicht groß genug ist?
Hm.
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Die MMU Steuerung ist Sache des Produktes....dementsprechend ist
> externe MMU Software irrelevant fuer die Funktion des Produktes.
Aber nicht 'fuer die bestmoegliche Funktion'. Du behinderst
die Entwicklung. Egal ob es jetzt um 5KB - wohl halt
peinlicher - Dokumentation fuer die Phase5 HW oder um
Weiterentwicklung von SFS geht. Es ist egal was du machst.
Durch deine hervorragend ausgepraegten Charakterschwaechen
stehst du den Leuten einfach immer nur im Weg. Wenn man es
mit dir nicht doch noch irgendwie gut meinen wuerde, muesste
man FESTstellen, du bist die Definition eines 'geborenen Loosers'.
--
PIK
Thomas Richter
> <th...@gibbs.math.tu-berlin.de> wrote:
Hi Ralph,
>> Falls es diesen Bug mal gab... Er ist seit geraumer Zeit behoben. Ich
>> grabe jetzt nicht die Versionshistory aus um nachzusehen, wann, müsste
>> aber schon eine ganze Weile her sein. Soviel zum Thema Glashäuser.
> Das war afaik die letzte oeffentliche Version.
Stimmt.
> Es ist mir eigentlich auch egal, weil ich es nicht benutze....viel mir
> nur bei einer Problemanlyse vor einigen Monaten auf.
Schön und gut. Jetzt aber herzugehen und einen Bug für "absichtlich Os
unkonform" unzudeklarieren darf ich auch etwas seltsam finden, oder?
>> Übrigens, wenn Dir das Spiel Spaß macht: War natürlich nicht der einzige
>> Bug in der 3.73. Willst Du mir beim Debuggin helfen? (-;
> Noe...ich fand ihn nur passend in dem diskutierten Kontext:-)
Aha, somit ist die Belegung des F-Space auch ein Bug? (-:
Ralph Schmidt
<P...@amigo.ping.de> wrote:
> Abs: la...@t-online.de (Ralph Schmidt) Bet: "Re: Keine 64 MByte-SIMMs in
> CyberStormPPC :-("
>
>> Die MMU Steuerung ist Sache des Produktes....dementsprechend ist
>> externe MMU Software irrelevant fuer die Funktion des Produktes.
>
> Aber nicht 'fuer die bestmoegliche Funktion'. Du behinderst die
fuer die bestmoegliche MMU funktion laeuft doch linux und netbsd auf
dem board und das wurde nicht "behindert". Was denn nun ?:-)
> Entwicklung. Egal ob es jetzt um 5KB - wohl halt peinlicher -
5kb ?
> Dokumentation fuer die Phase5 HW oder um Weiterentwicklung von SFS
geht.
Ich blockiere keine SFS Weiterentwicklung...
Thomas Richter
>>> Ich halte die Nutzung des f00000 Bereichs von *CPU Slot* Karten
>>> *nicht* als Hack. Ich halte sie fuer absolut Systemkonform.
>>> Wenn Zorro Karten sich dort *absolut* einblenden wie der Evolution,
>>> dann ist das ein Hack.
>>
>> Erstens, nein. Zweitens, ja, sicher.
>>
> Es ist wohl sinnlos mit dir darueber zu argumentieren.
Natürlich. Es ist ja alles nachzulesen.
>>> Woher soll denn deine CPU Karten HW wissen, was fuer eine init sequenz
>>> nach einem System Reset ausgefuehrt werden muss.
>>
>> Bank-Switching ausschalten, damit kommt das Kickstart ab Adresse 0 zu
>> liegen. Rest automatisch wie gehabt.
>>
> Echt ?..woher will denn eine 3rd party HW genau wissen in welcher
> (timing) sequenz nach einem Reset das system angesteuert werden
> muss.
> Sicher weiss man das bzgl. einem 68k aber nicht bzgl. einem *System*.
> Mir ist keine Dokumentation bekannt, wo das definiert wird...
Bitte erkläre, wozu das notwendig ist. Ein Ziehen von Reset sollte
ausreichen. "PPC-Emulation" lasse ich nicht gelten. Man würde dann ein
System ohne Bankswitching und F-Space emulieren. Abgesehen davon,
die 2630 hat hier keine Mucken gezeigt.
>> Solange man auf die Software im F-Space nach Einschalten verzichten
>> k"onnte - damit könnte man klarkommen. Kann man aber nicht, da liegt
>> auch Hardware. Hardware ist aber anzumelden.
> Wo steht denn das man HW anmelden muss ?
Wozu hat man sich AutoConfig ausgedacht?
> Ich sehe auch keine Anmeldung fuer pcmcia, ide und andere
> *Commodore* local HW in der configdev list.
"Quod licet Iovi, non licet bovi". (-: CBM hat dokumentiert, wo ihre
Hardware liegt, wie man feststellt, ob sie vorhanden ist, und wie
man sie zu mappen hat. P5 ist nicht der Hersteller des Systems, sondern
3rd-Party, und hat nichts dergleichen dokumentiert.
> In configvars.h steht nur, dass ****Zorro**** Boards per configdev
> im system eingetragen werden.
> Deine Wahrnehmung ist selektiv bzgl. dieser Geschichte.
Nein, Du verstehst nicht, wozu man Kompatibilität braucht, und Du
verstehst offenbar nicht die ganze Idee hinter AutoConfig. Im Gegen-
satz zur (damaligen) PC-Welt war die Anmeldung von Hardware über
dokumentierte Strukturen ein klarer Vorteil, der Vorwärtskompatibilität
und Zusammenarbeit von Komponenten verschiedener Hersteller mit einem
Minimum von Problemen für den Benutzer ermöglicht hat. Siehst Du denn
nicht, dass diese "ich mach' was mir passt" Einstellung dem ganzen
Konzept zuwiderläuft?
>>> Fuer das Produkt ist es irrelvant weil es eine komplette Loesung
>>> darstellt.
>>
>> Aha. Software gehört nicht zum Produkt? Das Funktionieren von Software
>> dritter Parteien, die sich nach den RKRMs richten, ist nicht Teil des
>> Produktes? Eine recht eigenwillige Vorstellung.
> Die MMU Steuerung ist Sache des Produktes....
Nein. Der Produkte (Plural!) im System. Es gibt auch noch mehr
Karten im System außer den P5-Boards. Und die müssen miteinander
zusammenarbeiten können, und bedürfen somit einer *dokumentierten*
Methode, wie MMU-Bäume aufzubauen sind.
> dementsprechend ist externe
> MMU Software irrelevant fuer die Funktion des Produktes.
Da sie mit den MMU-Tabellen "des Produktes" arbeiten muss eben nicht.
Da für das Resource MMU keinerlei Zugriffsfunktionen existieren, ist
somit "per Definitionem" jede "externe" Software ein Hack, und jed-
weder Zugriff auf dieses Resource ist verbaut. Interessanterweise gibt
es aber eine Menge von Anwendungen, für die eine solche Zusammenarbeit
wünschenswert wäre.
>> Und so in der 68040.library implementiert wurde, die Produkt von CBM
>> war, und vom gleichen Autor stammt.
> Jetzt wird es interessant...woher weisst du denn von *CBM* wie eine
> 680x0 library zu implementieren ist. Und seit wann hat eine
> Implementation mit einer Definition zu tun ?
Von Mike Sinz?
> Wie schon oben beschrieben, macht die CBM 68040 library in ihrer
> *Implementation* auch ein Check auf lokale HW wie PCMCIA und
> haengt dann den entsprechenden Adressbereich in den MMU Baum.
Sicher. Ist ja auch ein Resource des *Herstellers*, und nicht
eines Drittanbieters.
> Genauso macht es auch die Phase5 library mit lokalen resourcen
> auf *ihrer* HW.
Wenn "P5"-Hardware ohne ein Amiga-Motherboard ausgekommen wäre,
wäre das ja wohl auch Ok. Aber besagte Hardware ist ja wohl
eine Karte FÜR die Hardware des Herstellers.
>> Dass Mike Produktentwicklung für CBM gemacht hat? Das er seine Lösungen
>> dokumentiert hat, ich aber immer noch keine Dokumentation von P5 habe,
>> obwohl ich mich danach gerichtet hätte?
>>
> Ich habe gerade den 0xf00000 bereich fuer cpu slot karten als private
> spielwiese dokumentiert. Nur irgendwie willst du dich nicht dran halten.
> Wodran liegt das blos:-)
Sehr einfach. Weil Du es mir nicht hast dokumentieren wollen. He, es ist
ja nicht so, dass ich Dich nicht gefragt hatte. Wir wollen doch mal klar-
stellen, dass *DU* es warst, der nichts hat sagen wollen, und nicht ich,
der nicht hat zuhören wollen.
"Nicht daran halten" ist auch ein ziemlicher Witz. Schau Dir eventuell mal
irgendeine der letzten Mu-Releases an. Ich halte mich da ziemlich gut
'dran, in der Hoffnung, auch ohne Deine offenbar existierende, aber mir
nie zur Verfügung gestellte Dokumentation so halbwegs das richtige
getroffen zu haben. *DAS* stinkt mir - Ratespielchen, und dann noch
Anschuldigungen, dass ich Produkte supporte, die Dir *Deinen eigenen
Aussagen gemäß* schnurzegal sind.
- Ich bekomme hier Vorwüfe, mich an Dokus nicht zu halten, Die Du mir
nicht hast geben wollen,
- Produkte zu supporten, die Du nicht mehr supporten willst.
Zen Computing? "Keyboard broken, press any key to continue."
> Du argumentierst einfach so wie es dir gerade passt....einmal ziehst
> du das RKM herran und verdammst 3rd party "Erweiterungen" und
> dann wird auf 3rd party definitionen als "Kanon" hingewiesen.
Aha, die 68040.library von CBM war also 3rd-Party, gelle?
> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
> dokumentiert.
Wo, wann?
> Man darf gerne privat in dem *existierenden* MMU Table rumfuschen.
> Man darf aber nie die Kontrolle uebernehmen.
> Das ist eine klare Dokumentation:-) Sie kollidiert halt nur mit *deinen*
> Interessen.
Diese Dokumentation ist etwa genauso geistreich wie die C-64-Speicherver-
waltung: Man darf in jede Speicherzelle reinschreiben, es sei denn, ein
anderer hätte sie schon belegt. Wie bekommt man das heraus? Nicht mein
Problem. Tja, und wenn man nicht aufpasst, stürzt es eben ab.
Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>> Bedaure sehr, es ist nunmal schwierig, sich nach Dokumenten zu richten,
>> die man nicht haben darf. Zen-Computing?
> Ich dachte du richtest dich nur nach RKM Dokumenten....
Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss* ich
mich hier nach Angaben von Produktentwicklern richten, die für CBM
gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den Buckel runter"
konterst...
>>>>> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden
>>>>> wolltest ist *dein* persoehnliches Problem. Nicht das Problem des
>>>>> Produktes.
>>>>
>>>> Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer
>>>> weiter, als ein Teil des Geschäfts. Anderer Name, ziemlich der gleiche
>>>> Code.
>>
>>> Und ? Was hat das mit Phase5 Produkten zu tun ?:-)
>>
>> Nix. Ich wehre mich nur gegen Deine irrtümliche Feststellung, das Rad
>> neu erfunden zu haben. Ich habe den Reifen runderneuert, ja. Das Rad ist
>> noch immer das gleiche.
>>
> Die sogenannte "neue" Bereifung laeuft ohne einen signifikanten
> Unterschied verglichen zur "alten" Bereifung, da der Reifen eigentlich
> immer in der Garage steht.
Ich weiß nicht, was Du mit Deinem System so anstellst, aber meine Reifen
sind recht gut warmgelaufen.
Bietet P5 "defensiven" Speicherschutz auf ROM-Module im RAM ohne dass
ein versehendliches Schreiben gleich einen Guru-2 auslöst?
Bietet P5 "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf
einem 68060?
Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes Debugging-
Tool a la "Guardian Angel"?
Funktioniert das zusammen mit Shapeshifter-Videotreibern?
Momentan läuft hier schon mal MuForce, MuFastRom, MuProtectModules.
MuGa zum Debugging, MuEVD für die Mac-Emulation, wenn ich sie mal anschalte.
Auf der GVP lief noch MuFastZero.
Tut mir leid, meine Garage bleibt doch meist leer, insbesondere da der
Wagenpark in Zukunft noch etwas größer werden wird.
>> Falls Du andere, neuere Dokumente hast, so lese ich diese gerne
>> (wirklich!).
>>
> Und ich behaupte ganz einfach, dass der Bereich fuer CPU Slot
> Karten zur freien Nutzung da ist.
Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis 0xe000 0000
für mein Privatvergnügen. Wer immer da reinschreibt oder ihn belegt, hat
verloren. (-; Hört sich nach einem lustigen Spiel an...
Ist Dir ein Begriff wie "Standardisierung" geläufig, und wozu das dient? (-:
Wie dem auch sei, gut das wir's jetzt wissen, F-Space ist sowieso schon
reserviert von der MMU, und jetzt habe ich auch Deinen Segen dafür, richtig?
Sag' mir jetzt noch bitte, welches Mapping braucht der F-Space, und die
Doku, die ich bräuchte, wäre schon mal in der nächsten Phase.
>> Wurde später von Mike dokumentiert, wissen wir doch beide. Siehe oben.
>>
> Sicher weiss ich das....aber du argumentierst mit Inhalten aus Mike's
> Dokumentation als waeren diese von CBM und das entspricht einfach
> nicht den Fakten.
Da war nichts mehr von CBM übrig...
>> Ahja? Steht da im Handbuch, dass man bestimmte Software nicht einsetzen
>> kann, obwohl sich diese an Herstellervorgaben hält?
> Da es kein definiertes MMU Handling vom OS gibt, ist das Sache des
> CPU Karten Herstellers.
Siehe meine Argumentation oben - Du bist nicht der "lone ranger", dessen
Hardware allein im System laufen muss. Da Zusatzboards anderes
Mapping benötigen, und der Hersteller kaum alle weiteren Boards kennen
kann, ist *diese* Definition wenig zweckdienlich und extrem kurzsichtig.
>> Was, von wem? Von mir nicht. Mein Einwand gegen den F-Space ist, dass
>> ich diesen Speicherbereich mappen muss, obwohl keine ConfigDev darauf
>> hinweist, und nicht mal klar ist, wie man sie zu mappen hat. Der F-Space
>> bei P5- Produkten ist dabei noch das kleinste Problem.
>>
> Warum musst *du* den denn mappen. Das ist Sache des Herstellers.
> Das ist doch das was *du* nicht realisieren willst.
Weil diese Auffassung Nebenwirkungen hat und Interoperabilität auf
diese Weise nicht zu gewährleisten ist?
>> Halte ich für einen Design-Bug. Darüber braucht man nicht streiten...
> Hab ich auch dafuer gehalten...aber laut Dave Haynie war das
> *gewollt*. Dafuer haben sie dann beim A4000 die Moeglichkeit
> von Zorro Karten alle Ints zu genieren eleminiert(gewollt).
> Beim A3000 ging das noch.
Naja, wie man's nimmt. Vermutlich weil man Int2/6 von Zorro nicht
per Paula disablen kann und somit exec/Disable() nicht mehr geht.
Unpraktisch, irgendwie vergurkt, bitte... Ich behaupte nicht, CBM
hätte nur glorreiche Tage gehabt. Dazu hatte ich mit meinem erst-A2000
auch zu viele Probleme, kann man alles nachlesen...
>> Du kannst dies alles doch nachlesen, siehe RKRMs.
> Und die sind nicht alles und zweitens dokumentieren die auch nicht alles
> was du hier immer vorbetest bzgl. configdevs.
Wie ich schon sagte: Schick' mir halt mehr Dokus, ich habe nichts
dagegen, auch andere Boards zu supporten, bitte, gern gescheh'n. Nur lasse
ich mich nicht gern dafür auch noch vollmaulen.
>> Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den ich
>> beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine
>> Paranoia?
> Noe..
Aha, und warum verwechselst Du dann einen ganz offensichtlichen Bug mit
einem "angeblichen" Spareffekt von zwei Bytes? Ich dachte, es sei ziemlich
bekannt, dass ich zu der Fraktion gehöre, die Speicherverbrauch und
Speed eher hinter Stabilität stellen...
>> Ach, weisst Du, Programmfehler zum Vorwurf zu machen... ...sicher mache
>> ich Fehler. Was willst Du beweisen? Das ich welche mache, hätte ich auch
>> so zugegegeben. Ich schreib' sie sogar in die Revisionsreports.
> Ich mache dir das nicht zum Vorwurf. Ich renne hier doch nicht mit
> der "nicht Systemapproved" Keule rum wie du.
> Es passte nur aus meiner Sicht im Kontext bzgl. "Systemkonform"
> und sollte unter dem Motto "wie man in den Wald schreit schallt es herraus"
> gesehen werden:-)
Traf dafür aber ziemlich daneben. Ansonsten buddel' ich mal ein paar Bugs
Deinerseits aus und wir sind den Rest des Jahres damit beschäftigt, und
gegenseitig mit Bugreports alter Software zu überschütten... (-:
Albernes Spiel, lassen wir das. Wenn Dir neue Bugs auffallen, so her damit, ich
mache schließlich genug davon.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
>>>> Ich halte die Nutzung des f00000 Bereichs von *CPU Slot* Karten
>>>> *nicht* als Hack. Ich halte sie fuer absolut Systemkonform.
>>>> Wenn Zorro Karten sich dort *absolut* einblenden wie der Evolution,
>>>> dann ist das ein Hack.
>>>
>>> Erstens, nein. Zweitens, ja, sicher.
>>>
>
>> Es ist wohl sinnlos mit dir darueber zu argumentieren.
>
> Natürlich. Es ist ja alles nachzulesen.
>
>>>> Woher soll denn deine CPU Karten HW wissen, was fuer eine init
>>>> sequenz nach einem System Reset ausgefuehrt werden muss.
>>>
>>> Bank-Switching ausschalten, damit kommt das Kickstart ab Adresse 0 zu
>>> liegen. Rest automatisch wie gehabt.
>>>
>
>> Echt ?..woher will denn eine 3rd party HW genau wissen in welcher
>> (timing) sequenz nach einem Reset das system angesteuert werden
>> muss. Sicher weiss man das bzgl. einem 68k aber nicht bzgl. einem
>> *System*. Mir ist keine Dokumentation bekannt, wo das definiert wird...
>
> Bitte erkläre, wozu das notwendig ist. Ein Ziehen von Reset sollte
> ausreichen. "PPC-Emulation" lasse ich nicht gelten. Man würde dann ein
> System ohne Bankswitching und F-Space emulieren. Abgesehen davon, die
> 2630 hat hier keine Mucken gezeigt.
>
Das hat nichts mit PPC Emulation zu tun.
Fakt ist, dass nirgendswo definiert ist welche Timings man einhalten
muss bzgl. *Amiga System HW* nach einem *Reset*.
Dementsprechend ist alles was sich *davor* einblendet extrem
risikobehaftet.
>>> Solange man auf die Software im F-Space nach Einschalten verzichten
>>> k"onnte - damit könnte man klarkommen. Kann man aber nicht, da liegt
>>> auch Hardware. Hardware ist aber anzumelden.
>
>> Wo steht denn das man HW anmelden muss ?
>
> Wozu hat man sich AutoConfig ausgedacht?
>
AutoConfig bezieht sich auf *Zorro2/Zorro3*...mein gott.
Abgesehen davon war die Autoconfig HW *und* SW
Definition auch nicht der Weisheit letzter Schluss.
Implementiert nach HW Vorgaben ohne ein weitergehendes
Design. PCI ist aus meiner Sicht in allen Belangen besser
bzgl. *Autoconfig*.
>> Ich sehe auch keine Anmeldung fuer pcmcia, ide und andere
>> *Commodore* local HW in der configdev list.
>
> "Quod licet Iovi, non licet bovi". (-: CBM hat dokumentiert, wo ihre
> Hardware liegt, wie man feststellt, ob sie vorhanden ist, und wie man
> sie zu mappen hat. P5 ist nicht der Hersteller des Systems, sondern
> 3rd-Party, und hat nichts dergleichen dokumentiert.
>
Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis
gesichert hat und mit ihren Entwicklungen Standards gesetzt
hat(CGFX).
>> In configvars.h steht nur, dass ****Zorro**** Boards per configdev im
>> system eingetragen werden. Deine Wahrnehmung ist selektiv bzgl. dieser
>> Geschichte.
>
> Nein, Du verstehst nicht, wozu man Kompatibilität braucht, und Du
> verstehst offenbar nicht die ganze Idee hinter AutoConfig. Im Gegen-
> satz zur (damaligen) PC-Welt war die Anmeldung von Hardware über
> dokumentierte Strukturen ein klarer Vorteil, der Vorwärtskompatibilität
> und Zusammenarbeit von Komponenten verschiedener Hersteller mit einem
> Minimum von Problemen für den Benutzer ermöglicht hat. Siehst Du denn
> nicht, dass diese "ich mach' was mir passt" Einstellung dem ganzen
> Konzept zuwiderläuft?
Willst *du* mir wirklich erklaeren wie autoconfig funktioniert ?:-)
Phase5 hat ein integriertes Produkt angeboten, wozu auch die
komplette MMU Steuerung gehoert. Es wurde lokale IO/Mappings
genauso gehandelt wie CBM in ihrer 68040 library....configdevs
sind laut RKM/include nur fuer Zorro2/Zorro3 configs vorgesehen.
>
>>>> Fuer das Produkt ist es irrelvant weil es eine komplette Loesung
>>>> darstellt.
>>>
>>> Aha. Software gehört nicht zum Produkt? Das Funktionieren von Software
>>> dritter Parteien, die sich nach den RKRMs richten, ist nicht Teil des
>>> Produktes? Eine recht eigenwillige Vorstellung.
>
>> Die MMU Steuerung ist Sache des Produktes....
>
> Nein. Der Produkte (Plural!) im System. Es gibt auch noch mehr Karten im
> System außer den P5-Boards. Und die müssen miteinander zusammenarbeiten
> können, und bedürfen somit einer *dokumentierten* Methode, wie MMU-Bäume
> aufzubauen sind.
>
Was du gerne haettest entspricht aber nicht der Realitaet. Die MMU
Ansteuerung war *immer* Teil der CPU Hardware.
Von Hurricane(68030), Mercury und anderen 040 Karten, DKB 060,
GVP 060 und allen Phase5 060/040 Produkten.
Das *ist und war* die Realitaet....
>> dementsprechend ist externe MMU Software irrelevant fuer die Funktion
>> des Produktes.
>
> Da sie mit den MMU-Tabellen "des Produktes" arbeiten muss eben nicht. Da
> für das Resource MMU keinerlei Zugriffsfunktionen existieren, ist somit
> "per Definitionem" jede "externe" Software ein Hack, und jed- weder
> Zugriff auf dieses Resource ist verbaut. Interessanterweise gibt es aber
> eine Menge von Anwendungen, für die eine solche Zusammenarbeit
> wünschenswert wäre.
>
Es waere noch mehr wuenschenswert....zu dumm nur, dass es heute
*irrelevant* ist. Ich habe auch immer gesagt, dass um 94 rum es noch
Sinn gemacht haette ein *MMU* API zu definieren....der Zug ist aber
seit Jahren abgefahren.
>>> Und so in der 68040.library implementiert wurde, die Produkt von CBM
>>> war, und vom gleichen Autor stammt.
>
>> Jetzt wird es interessant...woher weisst du denn von *CBM* wie eine
>> 680x0 library zu implementieren ist. Und seit wann hat eine
>> Implementation mit einer Definition zu tun ?
>
> Von Mike Sinz?
>
Im Status eines 3rd Party Entwickler hat er 1997 dokumentiert wie
er 1991/2 die 68040.library entwickelt hat.
CBM hat dies *nie* dokumentiert. Da die library passive war, war
es egal ob irgendwer die MMU spaeter uebernommen hat, wie
z.b. Enforcer oder deine SW.
Die Phase5 MMU Ansteuerung war immer aktiv.
Darum geht es hier.
>> Wie schon oben beschrieben, macht die CBM 68040 library in ihrer
>> *Implementation* auch ein Check auf lokale HW wie PCMCIA und
>> haengt dann den entsprechenden Adressbereich in den MMU Baum.
>
> Sicher. Ist ja auch ein Resource des *Herstellers*, und nicht eines
> Drittanbieters.
>
Und ?
>> Genauso macht es auch die Phase5 library mit lokalen resourcen auf
>> *ihrer* HW.
>
> Wenn "P5"-Hardware ohne ein Amiga-Motherboard ausgekommen wäre, wäre
> das ja wohl auch Ok. Aber besagte Hardware ist ja wohl eine Karte FÜR
> die Hardware des Herstellers.
>
Phase5 hat es als Komplettloesung betrachtet.
>>> Dass Mike Produktentwicklung für CBM gemacht hat? Das er seine
>>> Lösungen dokumentiert hat, ich aber immer noch keine Dokumentation von
>>> P5 habe, obwohl ich mich danach gerichtet hätte?
>>>
>
>> Ich habe gerade den 0xf00000 bereich fuer cpu slot karten als private
>> spielwiese dokumentiert. Nur irgendwie willst du dich nicht dran
>> halten. Wodran liegt das blos:-)
>
> Sehr einfach. Weil Du es mir nicht hast dokumentieren wollen. He, es ist
> ja nicht so, dass ich Dich nicht gefragt hatte. Wir wollen doch mal
> klar- stellen, dass *DU* es warst, der nichts hat sagen wollen, und
> nicht ich, der nicht hat zuhören wollen.
>
Weil ich die HW Dritten wie dir nicht dokumentiere, da es aus meiner
Sicht zur Funktion des Produktes nicht noetig ist.
> "Nicht daran halten" ist auch ein ziemlicher Witz. Schau Dir eventuell
> mal
>
> irgendeine der letzten Mu-Releases an. Ich halte mich da ziemlich gut
> 'dran, in der Hoffnung, auch ohne Deine offenbar existierende, aber mir
> nie zur Verfügung gestellte Dokumentation so halbwegs das richtige
> getroffen zu haben. *DAS* stinkt mir - Ratespielchen, und dann noch
> Anschuldigungen, dass ich Produkte supporte, die Dir *Deinen eigenen
> Aussagen gemäß* schnurzegal sind.
>
Wann kapierst du endlich, dass das *dein* Problem ist, dass *du* dir
ausgesucht hast, weil du entschieden hast dich nicht an die Nutzungs-
definition des MMU Trees zu halten. Ich habe dir immer gesagt, dass
jeder gerne im MMU Tree rumspielen kann wie er lustig ist. Das er
aber niemals die Kontrolle ueber die MMU komplett uebernehmen
kann, weil es sonst nicht gesichert funktioniert.
> - Ich bekomme hier Vorwüfe, mich an Dokus nicht zu halten, Die Du mir
> nicht hast geben wollen,
Ich mache dir doch keine Vorwuerfe. Mir ist es egal was du machst.
Was *mir* nicht egal ist, wenn wieder solche Keulen wie
"nicht Systemkonform" kommen, nur weil ich mit dir nicht
kooperiere.
> - Produkte zu supporten, die Du nicht mehr supporten willst.
>
Dann "supporte" sie doch.
> Zen Computing? "Keyboard broken, press any key to continue."
>
>> Du argumentierst einfach so wie es dir gerade passt....einmal ziehst du
>> das RKM herran und verdammst 3rd party "Erweiterungen" und dann wird
>> auf
>> 3rd party definitionen als "Kanon" hingewiesen.
>
> Aha, die 68040.library von CBM war also 3rd-Party, gelle?
>
Nein. 3rd Party *ist* Enforcer und seine *Not Loesung* Dokumentation
der *configdevs* und wie irgendwann mal die 68040.library *implementiert*
wurde.
>> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
>> dokumentiert.
>
> Wo, wann?
>
>> Man darf gerne privat in dem *existierenden* MMU Table rumfuschen. Man
>> darf aber nie die Kontrolle uebernehmen. Das ist eine klare
>> Dokumentation:-) Sie kollidiert halt nur mit *deinen* Interessen.
>
> Diese Dokumentation ist etwa genauso geistreich wie die
> C-64-Speicherver- waltung: Man darf in jede Speicherzelle reinschreiben,
> es sei denn, ein anderer hätte sie schon belegt. Wie bekommt man das
> heraus? Nicht mein Problem. Tja, und wenn man nicht aufpasst, stürzt es
> eben ab.
>
Genau...als waere es anders mit irgendeinem anderen MMU Interface
heute an das sich sowieso keiner ausser du dran haelt.
Deswegen war seit der 68040.library *immer* der gemeinsame Nenner,
dass man auf *eigene* Gefahr im MMU Tree werkelt.
> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>
Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme loesst
und von jedem unterstuetzt wird.
>>> Bedaure sehr, es ist nunmal schwierig, sich nach Dokumenten zu
>>> richten, die man nicht haben darf. Zen-Computing?
>
>> Ich dachte du richtest dich nur nach RKM Dokumenten....
>
> Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss* ich
> mich hier nach Angaben von Produktentwicklern richten, die für CBM
> gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
> berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den Buckel
> runter" konterst...
>
Wie es in den Wald reinschallt, schallt es herraus.
>>>>>> Das dir das nicht passt, weil du unbedingt das Rad neu erfinden
>>>>>> wolltest ist *dein* persoehnliches Problem. Nicht das Problem des
>>>>>> Produktes.
>>>>>
>>>>> Ich habe nicht das Rad neu erfunden. Ich pflege nur den Enforcer
>>>>> weiter, als ein Teil des Geschäfts. Anderer Name, ziemlich der
>>>>> gleiche Code.
>>>
>>>> Und ? Was hat das mit Phase5 Produkten zu tun ?:-)
>>>
>>> Nix. Ich wehre mich nur gegen Deine irrtümliche Feststellung, das Rad
>>> neu erfunden zu haben. Ich habe den Reifen runderneuert, ja. Das Rad
>>> ist noch immer das gleiche.
>>>
>
>> Die sogenannte "neue" Bereifung laeuft ohne einen signifikanten
>> Unterschied verglichen zur "alten" Bereifung, da der Reifen eigentlich
>> immer in der Garage steht.
>
> Ich weiß nicht, was Du mit Deinem System so anstellst, aber meine Reifen
> sind recht gut warmgelaufen.
>
> Bietet P5 "defensiven" Speicherschutz auf ROM-Module im RAM ohne dass
> ein versehendliches Schreiben gleich einen Guru-2 auslöst? Bietet P5
Wen interessiert das ? Es hat 0.000000000001% Effekt, da du mit
Sicherheit weisst, dass so eine "Protection" keinen signifikanten
Schutz bietet besonders bei der minimalen Bedeutung von random
writes bzgl. System Crashes. Ein Placebo/Alibi Feature.
> "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf einem
> 68060?
> Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes
> Debugging- Tool a la "Guardian Angel"? Funktioniert das zusammen mit
Guardian Angel Remix wurde von Bjorge mittels Cyberguard sourcen entwickelt...
95-96 rum. 3-4 Jahre vor deiner *Reimplementierung*.
> Shapeshifter-Videotreibern?
>
Die liefen auch *vor* muforce.
> Momentan läuft hier schon mal MuForce, MuFastRom, MuProtectModules.
> MuGa zum Debugging, MuEVD für die Mac-Emulation, wenn ich sie mal
> anschalte. Auf der GVP lief noch MuFastZero.
>
Und ? 99% der Features funktionierten auch vor dem neuen API.
> Tut mir leid, meine Garage bleibt doch meist leer, insbesondere da der
> Wagenpark in Zukunft noch etwas größer werden wird.
>
>>> Falls Du andere, neuere Dokumente hast, so lese ich diese gerne
>>> (wirklich!).
>>>
>
>> Und ich behaupte ganz einfach, dass der Bereich fuer CPU Slot Karten
>> zur freien Nutzung da ist.
>
> Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis 0xe000
> 0000 für mein Privatvergnügen. Wer immer da reinschreibt oder ihn
> belegt,
> hat verloren. (-; Hört sich nach einem lustigen Spiel an...
>
Tja...der Bereich ist jetzt auch weg mit der grex:-)
> Ist Dir ein Begriff wie "Standardisierung" geläufig, und wozu das dient?
> (-:
>
Sicherlich...nur habe ich dir immer gesagt, dass seit Jahren kein neuer
MMU Standard mehr *Sinn* macht, weil es keine signifikant neue
HW fuer 68k geben wird und die alten Tools neu implementiert werden
muessen(Hast du ja offensichtlich gemacht) ohne einen signifikanten
Mehrnutzen(ausser Sendungsbewusstsein fuer T.Richter) ergibt.
> Wie dem auch sei, gut das wir's jetzt wissen, F-Space ist sowieso schon
> reserviert von der MMU, und jetzt habe ich auch Deinen Segen dafür,
> richtig?
>
*Mir* ist egal was *Du* bzgl. MMU Ansteuerung machst.
Was *mir* nicht egal ist sind solche Sachen wie "Nicht Systemkonform".
> Sag' mir jetzt noch bitte, welches Mapping braucht der F-Space, und die
> Doku, die ich bräuchte, wäre schon mal in der nächsten Phase.
>
Ich supporte keine 3rd party HW AmigaOS Ansteuerung, weil ich auf
die korrekte Funktion *meiner* Definition angewiesen bin beim User.
>>> Wurde später von Mike dokumentiert, wissen wir doch beide. Siehe oben.
>>>
>
>> Sicher weiss ich das....aber du argumentierst mit Inhalten aus Mike's
>> Dokumentation als waeren diese von CBM und das entspricht einfach nicht
>> den Fakten.
>
> Da war nichts mehr von CBM übrig...
>
Wie ich schon sagte...du argumentierst gerade so wie es dir passt und
haelst dich nicht mal an deine eigenen Regeln, dessen "Verfehlung" du
anderen hier vorhaelst.
>>> Ahja? Steht da im Handbuch, dass man bestimmte Software nicht
>>> einsetzen kann, obwohl sich diese an Herstellervorgaben hält?
>
>> Da es kein definiertes MMU Handling vom OS gibt, ist das Sache des CPU
>> Karten Herstellers.
>
> Siehe meine Argumentation oben - Du bist nicht der "lone ranger", dessen
> Hardware allein im System laufen muss. Da Zusatzboards anderes Mapping
Das ist aber die *Realitaet* seit den ersten 68030 boards bis zu den 060
Boards gewesen. Was du hier gerne haettest ist eine *Utopie*.
> benötigen, und der Hersteller kaum alle weiteren Boards kennen kann, ist
> *diese* Definition wenig zweckdienlich und extrem kurzsichtig.
>
Wenn keine signifikante 68k HW mehr seit Jahren gekommen ist, ist es
nicht "kurzsichtig" sondern eine effiziente nutzen/aufwand abschaetzung.
Es geht nicht darum, dass ein globales MMU API nuetzlich ist. Sondern
darum, dass es *heute* unsinnig ist, da es keinen signifikanten
Mehrwert fuer Entwickler(welche?) gibt.
Desweiteren wurden auch diverse 3rd party Gfxboards auch mittels
speziellem Mapping supportet.
Das Feature wurde ja dann spaeter auch von Nils in P96 implementiert,
fuer Villagetronic Produkte.
>>> Was, von wem? Von mir nicht. Mein Einwand gegen den F-Space ist, dass
>>> ich diesen Speicherbereich mappen muss, obwohl keine ConfigDev darauf
>>> hinweist, und nicht mal klar ist, wie man sie zu mappen hat. Der
>>> F-Space bei P5- Produkten ist dabei noch das kleinste Problem.
>>>
>
>> Warum musst *du* den denn mappen. Das ist Sache des Herstellers. Das
>> ist doch das was *du* nicht realisieren willst.
>
> Weil diese Auffassung Nebenwirkungen hat und Interoperabilität auf diese
> Weise nicht zu gewährleisten ist?
>
komisch...es gab auch eine zeit *vor* der mmu.library.
>> Und die sind nicht alles und zweitens dokumentieren die auch nicht
>> alles was du hier immer vorbetest bzgl. configdevs.
>
> Wie ich schon sagte: Schick' mir halt mehr Dokus, ich habe nichts
> dagegen, auch andere Boards zu supporten, bitte, gern gescheh'n. Nur
> lasse ich mich nicht gern dafür auch noch vollmaulen.
>
Ich argumentiere zurueck nach der netten aussage wie
"nicht systemkonform".
>>> Ich will nichts sparen. Ich habe höchstens einen Bug verbrochen, den
>>> ich beheben werde. Danke für den Bug-Report, das wird gefixt. Kleine
>>> Paranoia?
>
>> Noe..
>
> Aha, und warum verwechselst Du dann einen ganz offensichtlichen Bug mit
> einem "angeblichen" Spareffekt von zwei Bytes? Ich dachte, es sei
> ziemlich bekannt, dass ich zu der Fraktion gehöre, die Speicherverbrauch
> und Speed eher hinter Stabilität stellen...
>
Ich kenne keins deiner Programme als *Nutzer* naeher um solche
Ueberlegungen zu treffen.
Es ist mir auch prinzipiell egal....ich spiele mich hier nicht als
"nicht systemkonform" Inquisation auf.
Das ist der einzige Punkt warum ich ueberhaupt geantwortet habe.
Thomas Richter
>> Bitte erkläre, wozu das notwendig ist. Ein Ziehen von Reset sollte
>> ausreichen. "PPC-Emulation" lasse ich nicht gelten. Man würde dann ein
>> System ohne Bankswitching und F-Space emulieren. Abgesehen davon, die
>> 2630 hat hier keine Mucken gezeigt.
> Das hat nichts mit PPC Emulation zu tun.
Dann argumentiere nicht damit.
> Fakt ist, dass nirgendswo definiert ist welche Timings man einhalten
> muss bzgl. *Amiga System HW* nach einem *Reset*.
> Dementsprechend ist alles was sich *davor* einblendet extrem
> risikobehaftet.
>> Wozu hat man sich AutoConfig ausgedacht?
> AutoConfig bezieht sich auf *Zorro2/Zorro3*...mein gott.
Achwas?
> Abgesehen davon war die Autoconfig HW *und* SW
> Definition auch nicht der Weisheit letzter Schluss.
> Implementiert nach HW Vorgaben ohne ein weitergehendes
> Design. PCI ist aus meiner Sicht in allen Belangen besser
> bzgl. *Autoconfig*.
Nur dass es damals kein PCI gab, und dass kein Amiga PCI unter-
stützt, und dass AutoConfig damals die Wahl war, wenn man neue
Hardware supporten wollte.
>> "Quod licet Iovi, non licet bovi". (-: CBM hat dokumentiert, wo ihre
>> Hardware liegt, wie man feststellt, ob sie vorhanden ist, und wie man
>> sie zu mappen hat. P5 ist nicht der Hersteller des Systems, sondern
>> 3rd-Party, und hat nichts dergleichen dokumentiert.
> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis
> gesichert hat und mit ihren Entwicklungen Standards gesetzt
> hat(CGFX).
Standards, die nicht dokumentiert sind, helfen niemandem. Ich warte
immer noch auf Dokumente.
>> Nein, Du verstehst nicht, wozu man Kompatibilität braucht, und Du
>> verstehst offenbar nicht die ganze Idee hinter AutoConfig. Im Gegen-
>> satz zur (damaligen) PC-Welt war die Anmeldung von Hardware über
>> dokumentierte Strukturen ein klarer Vorteil, der Vorwärtskompatibilität
>> und Zusammenarbeit von Komponenten verschiedener Hersteller mit einem
>> Minimum von Problemen für den Benutzer ermöglicht hat. Siehst Du denn
>> nicht, dass diese "ich mach' was mir passt" Einstellung dem ganzen
>> Konzept zuwiderläuft?
> Willst *du* mir wirklich erklaeren wie autoconfig funktioniert ?:-)
Anscheindend hast Du nicht kapiert, wozu man überhaupt sowas wie
AutoConfig eingeführt hat.
> Phase5 hat ein integriertes Produkt angeboten, wozu auch die
> komplette MMU Steuerung gehoert.
Und ich erkläre Dir jetzt zum zweiten Mal, dass ein Amiga eben kein
"komplettes Produkt" ist, sondern mit Produkten anderer Leute zusammen-
arbeiten muss. Wenn ihr eure eigene Hardware gebaut hättet, in die man
nichts anderes als P5 hineinstecken kann, dann ja. Aber das wäre kein
Amiga gewesen.
>> Nein. Der Produkte (Plural!) im System. Es gibt auch noch mehr Karten im
>> System außer den P5-Boards. Und die müssen miteinander zusammenarbeiten
>> können, und bedürfen somit einer *dokumentierten* Methode, wie MMU-Bäume
>> aufzubauen sind.
> Was du gerne haettest entspricht aber nicht der Realitaet.
Entspricht der Realität bis auf Karten eines gewissen Herstellers, der
nicht genügend Bedacht bei der Konstruktion ihrer Hardware angewandt
hat. Alles schön und gut, das könnte man ja verkraften, wenn man wüsste,
wie das funktioniert.
>> Da sie mit den MMU-Tabellen "des Produktes" arbeiten muss eben nicht. Da
>> für das Resource MMU keinerlei Zugriffsfunktionen existieren, ist somit
>> "per Definitionem" jede "externe" Software ein Hack, und jed- weder
>> Zugriff auf dieses Resource ist verbaut. Interessanterweise gibt es aber
>> eine Menge von Anwendungen, für die eine solche Zusammenarbeit
>> wünschenswert wäre.
> Es waere noch mehr wuenschenswert....zu dumm nur, dass es heute
> *irrelevant* ist.
Offenbar nicht irrelevant genug in Anbetracht der Mail, die ich dazu
bekomme.
> Ich habe auch immer gesagt, dass um 94 rum es noch
> Sinn gemacht haette ein *MMU* API zu definieren....der Zug ist aber
> seit Jahren abgefahren.
Dann, lieber Ralph, verstehe ich nicht, warum Du hier immer noch aufkreuzt.
>>> Jetzt wird es interessant...woher weisst du denn von *CBM* wie eine
>>> 680x0 library zu implementieren ist. Und seit wann hat eine
>>> Implementation mit einer Definition zu tun ?
>>
>> Von Mike Sinz?
> Im Status eines 3rd Party Entwickler hat er 1997 dokumentiert wie
> er 1991/2 die 68040.library entwickelt hat.
> CBM hat dies *nie* dokumentiert.
Da kam niemand mehr dazu, dies zu dokumentieren... Es hatte damals noch
niemand verstanden, dass man hier eine API braucht.
> Da die library passive war, war
> es egal ob irgendwer die MMU spaeter uebernommen hat, wie
> z.b. Enforcer oder deine SW.
> Die Phase5 MMU Ansteuerung war immer aktiv.
> Darum geht es hier.
Aktiv? In dem Sinne dass es eine nicht-dokumentierte API gibt, ohne
irgendwelches Locking, Zugriffsprotokolle oder sonstiges? Ich danke.
>> Sicher. Ist ja auch ein Resource des *Herstellers*, und nicht eines
>> Drittanbieters.
> Und ?
P5 ist nicht CBM und P5 hat die Motherboards nicht gebaut.
>>> Genauso macht es auch die Phase5 library mit lokalen resourcen auf
>>> *ihrer* HW.
>>
>> Wenn "P5"-Hardware ohne ein Amiga-Motherboard ausgekommen wäre, wäre
>> das ja wohl auch Ok. Aber besagte Hardware ist ja wohl eine Karte FÜR
>> die Hardware des Herstellers.
> Phase5 hat es als Komplettloesung betrachtet.
Was der Realität zuwiderläuft. Eine Karte kann ich nicht in die
Steckdose stecken und damit arbeiten. Sie ist Teil eines Gesamtsystems.
>> Sehr einfach. Weil Du es mir nicht hast dokumentieren wollen. He, es ist
>> ja nicht so, dass ich Dich nicht gefragt hatte. Wir wollen doch mal
>> klar- stellen, dass *DU* es warst, der nichts hat sagen wollen, und
>> nicht ich, der nicht hat zuhören wollen.
> Weil ich die HW Dritten wie dir nicht dokumentiere, da es aus meiner
> Sicht zur Funktion des Produktes nicht noetig ist.
Vielleicht aber aus der Sicht anderer Leute? Vielleicht ist "Funktion
des Produktes" in Deiner Sichtweise etwas zu eng definiert?
>> "Nicht daran halten" ist auch ein ziemlicher Witz. Schau Dir eventuell
>> mal
>>
>> irgendeine der letzten Mu-Releases an. Ich halte mich da ziemlich gut
>> 'dran, in der Hoffnung, auch ohne Deine offenbar existierende, aber mir
>> nie zur Verfügung gestellte Dokumentation so halbwegs das richtige
>> getroffen zu haben. *DAS* stinkt mir - Ratespielchen, und dann noch
>> Anschuldigungen, dass ich Produkte supporte, die Dir *Deinen eigenen
>> Aussagen gemäß* schnurzegal sind.
> Wann kapierst du endlich, dass das *dein* Problem ist, dass *du* dir
> ausgesucht hast, weil du entschieden hast dich nicht an die Nutzungs-
> definition des MMU Trees zu halten.
Ich habe noch immer keine "Nutzungsdefinition des MMU-Trees". Was ich
habe sind einige nicht belegbare Aussagen Deines (schlechten) Design-
geschmackes.
> Ich habe dir immer gesagt, dass
> jeder gerne im MMU Tree rumspielen kann wie er lustig ist. Das er
> aber niemals die Kontrolle ueber die MMU komplett uebernehmen
> kann, weil es sonst nicht gesichert funktioniert.
Dafür, dass es nicht gesichert funktioniert, funktioniert es aber
sehr gut... und wenn Du nicht siehst, dass obiges keine Definition eines
Designs ist, dann kann ich Dir auch nicht helfen.
>> - Ich bekomme hier Vorwüfe, mich an Dokus nicht zu halten, Die Du mir
>> nicht hast geben wollen,
> Ich mache dir doch keine Vorwuerfe. Mir ist es egal was du machst.
Dafür, dass es egal ist, reden wir aber schon sehr lange.
> Was *mir* nicht egal ist, wenn wieder solche Keulen wie
> "nicht Systemkonform" kommen, nur weil ich mit dir nicht
> kooperiere.
Weil es nicht systemkonform ist, weil es keine anderslautenden Dokumente
gibt. Dem Punkt könntest Du abhelfen, weigerst Dich aber beharrlich.
>>> Du argumentierst einfach so wie es dir gerade passt....einmal ziehst du
>>> das RKM herran und verdammst 3rd party "Erweiterungen" und dann wird
>>> auf
>>> 3rd party definitionen als "Kanon" hingewiesen.
>>
>> Aha, die 68040.library von CBM war also 3rd-Party, gelle?
> Nein.
Danke. Mehr wollte ich nicht wissen.
>>> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
>>> dokumentiert.
>>
>> Wo, wann?
Ich wiederhole diese Frage.
>> Diese Dokumentation ist etwa genauso geistreich wie die
>> C-64-Speicherver- waltung: Man darf in jede Speicherzelle reinschreiben,
>> es sei denn, ein anderer hätte sie schon belegt. Wie bekommt man das
>> heraus? Nicht mein Problem. Tja, und wenn man nicht aufpasst, stürzt es
>> eben ab.
> Genau...als waere es anders mit irgendeinem anderen MMU Interface
> heute an das sich sowieso keiner ausser du dran haelt.
Auch nachweislich nicht korrekt...
> Deswegen war seit der 68040.library *immer* der gemeinsame Nenner,
> dass man auf *eigene* Gefahr im MMU Tree werkelt.
Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist
kein Design.
>> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
> Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme loesst
> und von jedem unterstuetzt wird.
Ich behaupte nicht, Weltprobleme zu lösen. Ich behaupte, für ein paar
MMU-spezifische Probleme eine brauchbare API definiert und benutzt zu
haben, und dass, obwohl Du weiterhin versuchst, mir Steine vor die Beine
zu werfen.
>> Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss* ich
>> mich hier nach Angaben von Produktentwicklern richten, die für CBM
>> gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
>> berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den Buckel
>> runter" konterst...
> Wie es in den Wald reinschallt, schallt es herraus.
Und dann werden noch Lügen verbreitet, wie es Dir passt. Wirklich nett...
Herr Schmidt, ich hatte damals höflich angefragt, und mir den Ton von
Etienne Voigt - falls Du Dich noch entsinnen kannst - verbitten lassen.
*DU* warst derjenige, der nur herumgemault hat.
Interessanterweise waren Anfragen an andere Leute, wie etwa Mike Sinz,
da sehr viel erfolgreicher.
Wie kommt das wohl, dass man von Dir bestenfalls vollgemault wird, aber
keine Antworten bekommt?
>>> Die sogenannte "neue" Bereifung laeuft ohne einen signifikanten
>>> Unterschied verglichen zur "alten" Bereifung, da der Reifen eigentlich
>>> immer in der Garage steht.
>>
>> Ich weiß nicht, was Du mit Deinem System so anstellst, aber meine Reifen
>> sind recht gut warmgelaufen.
>>
>> Bietet P5 "defensiven" Speicherschutz auf ROM-Module im RAM ohne dass
>> ein versehendliches Schreiben gleich einen Guru-2 auslöst? Bietet P5
> Wen interessiert das ?
Offenbar genug. Mich interessiert's.
> Es hat 0.000000000001% Effekt, da du mit
> Sicherheit weisst, dass so eine "Protection" keinen signifikanten
> Schutz bietet besonders bei der minimalen Bedeutung von random
> writes bzgl. System Crashes. Ein Placebo/Alibi Feature.
Kleine Saure-Trauben Reaktion gefällig?
>> "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf einem
>> 68060?
>> Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes
>> Debugging- Tool a la "Guardian Angel"? Funktioniert das zusammen mit
> Guardian Angel Remix wurde von Bjorge mittels Cyberguard sourcen entwickelt...
> 95-96 rum. 3-4 Jahre vor deiner *Reimplementierung*.
Ich habe erstens nichts re-implementiert, und zweitens kooperiert besagtes
Tool immer noch nicht mit anderen MMU-Hacks. Versuche mal sowas parallel
zu einem anderen "aktiven" MMU-Tool zu starten und Du merkst den Unter-
schied zwischen einem Design und einem Hack.
>> Shapeshifter-Videotreibern?
> Die liefen auch *vor* muforce.
Aber nicht "mit" Enforcer.
>> Momentan läuft hier schon mal MuForce, MuFastRom, MuProtectModules.
>> MuGa zum Debugging, MuEVD für die Mac-Emulation, wenn ich sie mal
>> anschalte. Auf der GVP lief noch MuFastZero.
> Und ? 99% der Features funktionierten auch vor dem neuen API.
Aber nicht miteinander und in beliebiger Kombination. Ich glaube, entweder
hast Du oder willst Du nicht verstehen, was das ganze soll.
"Alles, was ich nicht gemacht habe, taugt nichts".
Du bist noch armseliger, als ich dachte.
>>>> Falls Du andere, neuere Dokumente hast, so lese ich diese gerne
>>>> (wirklich!).
>>> Und ich behaupte ganz einfach, dass der Bereich fuer CPU Slot Karten
>>> zur freien Nutzung da ist.
>> Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis 0xe000
>> 0000 für mein Privatvergnügen. Wer immer da reinschreibt oder ihn
>> belegt,
>> hat verloren. (-; Hört sich nach einem lustigen Spiel an...
> Tja...der Bereich ist jetzt auch weg mit der grex:-)
Nö, er ist von mir soeben reserviert worden, und was andere machen, inter-
essiert mich nicht. Und was ich damit anstelle, ist meine Sache, und
Dokumente dazu verbreite ich nicht, und wer immer was damit anstellt außer
mir soll zur Hölle fahren, und supporten tu' ich das erst recht nicht.
P5-Logik.
>> Ist Dir ein Begriff wie "Standardisierung" geläufig, und wozu das dient?
>> (-:
> Sicherlich...nur habe ich dir immer gesagt, dass seit Jahren kein neuer
> MMU Standard mehr *Sinn* macht,
Offenbar immer noch genug Sinn für einige Leute. Weil *DU* nicht verstehst,
wozu das ganze sein soll, oder weil Du nicht willst, dass jemand in *Deine
Geniale Software* (tm) hineinsieht, blockierst Du hier.
> weil es keine signifikant neue
> HW fuer 68k geben wird und die alten Tools neu implementiert werden
> muessen(Hast du ja offensichtlich gemacht) ohne einen signifikanten
> Mehrnutzen(ausser Sendungsbewusstsein fuer T.Richter) ergibt.
Ich habe kein *Sendungsbewusstsein*. Ich habe nur genug von den "Designideen"
eines gewissen Herrn. Ich habe das Zeug, wie ich schon mehrmals gesagt hatte,
implementiert, weil ich es für eine interessante Aufgabe hielt. Klar, sowas
verstehst Du nicht. Dass ich es nicht verkaufen kann, war mir sowieso schon
klar.
>> Wie dem auch sei, gut das wir's jetzt wissen, F-Space ist sowieso schon
>> reserviert von der MMU, und jetzt habe ich auch Deinen Segen dafür,
>> richtig?
> *Mir* ist egal was *Du* bzgl. MMU Ansteuerung machst.
So egal, dass wir immer noch reden, gelle?
> Was *mir* nicht egal ist sind solche Sachen wie "Nicht Systemkonform".
Was es nicht ist - den Beweis bleibst Du immer noch schuldig. "Ich definiere
als Konform" halte ich für keinen Beweis.
>> Sag' mir jetzt noch bitte, welches Mapping braucht der F-Space, und die
>> Doku, die ich bräuchte, wäre schon mal in der nächsten Phase.
> Ich supporte keine 3rd party HW AmigaOS Ansteuerung, weil ich auf
> die korrekte Funktion *meiner* Definition angewiesen bin beim User.
*Deiner* *Top Secret* Definition von Usern, die Du nicht mehr supporten
willst? Du widersprichst Dir in Deiner seltsamen Logik doch nur selbst.
Entweder Du machst nichts mehr, dann darf Dir der Zirkus auch egal sein,
oder Du machst noch was, und dann solltest Du an weiteren Entwicklungen
auch interessiert sein. Aber einerseits zu behaupten, Du hättest Interesse
an der "korrekten Funktion Deiner Hardware" und andererseits zu behaupten
"das hätte doch alles keinen Sinn mehr" ist ein Widerspruch in sich.
Ich glaube, das wirkliche Problem liegt da ganz woanders... ...und es
ist alles so wunderbar durchsichtig und für jederman offensichtlich.
>>> Sicher weiss ich das....aber du argumentierst mit Inhalten aus Mike's
>>> Dokumentation als waeren diese von CBM und das entspricht einfach nicht
>>> den Fakten.
>>
>> Da war nichts mehr von CBM übrig...
> Wie ich schon sagte...du argumentierst gerade so wie es dir passt und
> haelst dich nicht mal an deine eigenen Regeln, dessen "Verfehlung" du
> anderen hier vorhaelst.
Meine Regeln sind, dass ich mich daran halte, was dokumentiert ist. Ich
habe null Dokumentation von Dir. Ich habe massig Dokumente von Mike bzgl.
68040-Lib, die er für CBM entwickelt hat.
Es steht Dir immer noch frei, das zu ändern.
>>> Da es kein definiertes MMU Handling vom OS gibt, ist das Sache des CPU
>>> Karten Herstellers.
>>
>> Siehe meine Argumentation oben - Du bist nicht der "lone ranger", dessen
>> Hardware allein im System laufen muss. Da Zusatzboards anderes Mapping
> Das ist aber die *Realitaet* seit den ersten 68030 boards bis zu den 060
> Boards gewesen. Was du hier gerne haettest ist eine *Utopie*.
Interessant, eine lauffähige Utopie. (-:
>> benötigen, und der Hersteller kaum alle weiteren Boards kennen kann, ist
>> *diese* Definition wenig zweckdienlich und extrem kurzsichtig.
> Wenn keine signifikante 68k HW mehr seit Jahren gekommen ist, ist es
> nicht "kurzsichtig" sondern eine effiziente nutzen/aufwand abschaetzung.
Stattdessen steckst Du, statt das Zeug an einem Nachmittag mal auszugraben,
(Aufwand null, Nutzen imens), Deine Zeit lieber in immer die gleiche
Argumentation. Ich sage Dir auf die Nase zu, dass das absolut nichts mit
Nutzen oder Aufwand oder sonst was zu tun hat, und dass Du hier angebliche
Argumente vorschiebst.
Optimiere den Nutzen, verhindere den Aufwand, schicke mir das Zeug zu.
Fertig.
> Es geht nicht darum, dass ein globales MMU API nuetzlich ist. Sondern
> darum, dass es *heute* unsinnig ist, da es keinen signifikanten
> Mehrwert fuer Entwickler(welche?) gibt.
Welchen "effektiven Nutzen" hat heute ein PPC-Board? Keinen? Warum machst
Du das? Du bist schon wieder dabei, irgendwelche Unsinnsargumente vorzu-
schieben. Es geht doch im Grunde gar nicht darum, habe ich recht?
Es geht darum, dass *Du* recht haben willst, und dass Du nur zu gerne
das Ekel spielst. Das hingegen gelingt Dir ganz ausgezeichnet.
> Desweiteren wurden auch diverse 3rd party Gfxboards auch mittels
> speziellem Mapping supportet.
> Das Feature wurde ja dann spaeter auch von Nils in P96 implementiert,
> fuer Villagetronic Produkte.
Die Picasso-IV hat zwar ein dynamisches Mapping, aber die MMU-Verwaltung
für diese Karte ist statisch und bedarf keiner besonderen Tricks. Die meldet
sich schon korrekt an. Dass man hier optimieren kann, ist eine andere Sache.
>>> Warum musst *du* den denn mappen. Das ist Sache des Herstellers. Das
>>> ist doch das was *du* nicht realisieren willst.
>>
>> Weil diese Auffassung Nebenwirkungen hat und Interoperabilität auf diese
>> Weise nicht zu gewährleisten ist?
> komisch...es gab auch eine zeit *vor* der mmu.library.
Ach, sag' bloß? Und, konnte ich MMU-Hacks sicher parallel laufen lassen?
>>> Und die sind nicht alles und zweitens dokumentieren die auch nicht
>>> alles was du hier immer vorbetest bzgl. configdevs.
>>
>> Wie ich schon sagte: Schick' mir halt mehr Dokus, ich habe nichts
>> dagegen, auch andere Boards zu supporten, bitte, gern gescheh'n. Nur
>> lasse ich mich nicht gern dafür auch noch vollmaulen.
>>
> Ich argumentiere zurueck nach der netten aussage wie
> "nicht systemkonform".
Ich frage auch nicht zum ersten Mal. Ich habe Deine Spielchen nur so satt,
weil man im Grunde genommen genau weiß, worum es geht. Mit "standardkonform"
oder nicht hat es schon lang' nichts mehr zu tun.
>> Aha, und warum verwechselst Du dann einen ganz offensichtlichen Bug mit
>> einem "angeblichen" Spareffekt von zwei Bytes? Ich dachte, es sei
>> ziemlich bekannt, dass ich zu der Fraktion gehöre, die Speicherverbrauch
>> und Speed eher hinter Stabilität stellen...
> Ich kenne keins deiner Programme als *Nutzer* naeher um solche
> Ueberlegungen zu treffen.
Nein, stattdessen formulierst Du lieber Unterstellungen, ist schon klar.
Macht sich ja auch einfacher. Ich befürchte fast, das war ein Schuss in den
Ofen.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
>>> Bitte erkläre, wozu das notwendig ist. Ein Ziehen von Reset sollte
>>> ausreichen. "PPC-Emulation" lasse ich nicht gelten. Man würde dann ein
>>> System ohne Bankswitching und F-Space emulieren. Abgesehen davon, die
>>> 2630 hat hier keine Mucken gezeigt.
>
>> Das hat nichts mit PPC Emulation zu tun.
>
> Dann argumentiere nicht damit.
>
Tue ich doch gar nicht(Du hast das gemacht).
Das bezieht sich auf die Amiga System HW.
Bitte lies doch mal *genau* was ich sage.
>> Fakt ist, dass nirgendswo definiert ist welche Timings man einhalten
>> muss bzgl. *Amiga System HW* nach einem *Reset*. Dementsprechend ist
>> alles was sich *davor* einblendet extrem risikobehaftet.
>
>>> Wozu hat man sich AutoConfig ausgedacht?
>
>> AutoConfig bezieht sich auf *Zorro2/Zorro3*...mein gott.
>
> Achwas?
>
Du hast doch was anderes behauptet.
>> Abgesehen davon war die Autoconfig HW *und* SW Definition auch nicht
>> der Weisheit letzter Schluss. Implementiert nach HW Vorgaben ohne ein
>> weitergehendes Design. PCI ist aus meiner Sicht in allen Belangen
>> besser bzgl. *Autoconfig*.
>
> Nur dass es damals kein PCI gab, und dass kein Amiga PCI unter- stützt,
> und dass AutoConfig damals die Wahl war, wenn man neue Hardware
> supporten wollte.
>
Agreed...das war aber eigentlich nicht der "Punkt":-)
Das bezog sich auf das API Interface und deren Nuetzlichkeit
fuer Zwecke wie generelle Adressraum/Cache Definition und
die Limitierung der Diags bzgl. extensiven Rominhalten >64KB
>>> "Quod licet Iovi, non licet bovi". (-: CBM hat dokumentiert, wo ihre
>>> Hardware liegt, wie man feststellt, ob sie vorhanden ist, und wie man
>>> sie zu mappen hat. P5 ist nicht der Hersteller des Systems, sondern
>>> 3rd-Party, und hat nichts dergleichen dokumentiert.
>
>> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis gesichert hat
>> und mit ihren Entwicklungen Standards gesetzt hat(CGFX).
>
> Standards, die nicht dokumentiert sind, helfen niemandem. Ich warte
> immer noch auf Dokumente.
>
Der Standard wird durch die Konfiguration des Boards definiert.
>>> Nein, Du verstehst nicht, wozu man Kompatibilität braucht, und Du
>>> verstehst offenbar nicht die ganze Idee hinter AutoConfig. Im Gegen-
>>> satz zur (damaligen) PC-Welt war die Anmeldung von Hardware über
>>> dokumentierte Strukturen ein klarer Vorteil, der
>>> Vorwärtskompatibilität und Zusammenarbeit von Komponenten
>>> verschiedener Hersteller mit einem Minimum von Problemen für den
>>> Benutzer ermöglicht hat. Siehst Du denn nicht, dass diese "ich mach'
>>> was mir passt" Einstellung dem ganzen Konzept zuwiderläuft?
>
>> Willst *du* mir wirklich erklaeren wie autoconfig funktioniert ?:-)
>
> Anscheindend hast Du nicht kapiert, wozu man überhaupt sowas wie
> AutoConfig eingeführt hat.
>
Sigh..
>> Phase5 hat ein integriertes Produkt angeboten, wozu auch die komplette
>> MMU Steuerung gehoert.
>
> Und ich erkläre Dir jetzt zum zweiten Mal, dass ein Amiga eben kein
> "komplettes Produkt" ist, sondern mit Produkten anderer Leute zusammen-
> arbeiten muss. Wenn ihr eure eigene Hardware gebaut hättet, in die man
> nichts anderes als P5 hineinstecken kann, dann ja. Aber das wäre kein
> Amiga gewesen.
>
Man arbeitet mit den Leuten zusammen mit denen man einen gemeinsamen
Nenner hat und dessen Interessen sich kombinieren.
>>> Nein. Der Produkte (Plural!) im System. Es gibt auch noch mehr Karten
>>> im System außer den P5-Boards. Und die müssen miteinander
>>> zusammenarbeiten können, und bedürfen somit einer *dokumentierten*
>>> Methode, wie MMU-Bäume aufzubauen sind.
>
>> Was du gerne haettest entspricht aber nicht der Realitaet.
>
> Entspricht der Realität bis auf Karten eines gewissen Herstellers, der
> nicht genügend Bedacht bei der Konstruktion ihrer Hardware angewandt
> hat. Alles schön und gut, das könnte man ja verkraften, wenn man wüsste,
> wie das funktioniert.
>
Das stimmt doch einfach nicht. Ich habe dir genug Beispiele von Firmen
gegebenen, die fuer ihr Produkt ein eigenes MMU setup mitlieferten, da
ohne dieses ihr Board mit AmigaOS nicht funktioniert haette.
*Genau* das gleiche mit Phase5.
>>> Da sie mit den MMU-Tabellen "des Produktes" arbeiten muss eben nicht.
>>> Da für das Resource MMU keinerlei Zugriffsfunktionen existieren, ist
>>> somit
>>> "per Definitionem" jede "externe" Software ein Hack, und jed- weder
>>> Zugriff auf dieses Resource ist verbaut. Interessanterweise gibt es
>>> aber eine Menge von Anwendungen, für die eine solche Zusammenarbeit
>>> wünschenswert wäre.
>
>> Es waere noch mehr wuenschenswert....zu dumm nur, dass es heute
>> *irrelevant* ist.
>
> Offenbar nicht irrelevant genug in Anbetracht der Mail, die ich dazu
> bekomme.
>
Das haengt wohl von den Motiven jedes einzelnen ab, warum er
interessiert ist.
Mein Punkt ist nur, dass es keinen *Sinn* mehr macht, weil keinen
praktischen Mehrwert fuer die meisten User und auch Entwickler.
Aber das ist doch jedem einzelnen ueberlassen....
>> Ich habe auch immer gesagt, dass um 94 rum es noch Sinn gemacht haette
>> ein *MMU* API zu definieren....der Zug ist aber seit Jahren abgefahren.
>
> Dann, lieber Ralph, verstehe ich nicht, warum Du hier immer noch
> aufkreuzt.
>
Wirst du jetzt wieder persoehnlich ?
>>>> Jetzt wird es interessant...woher weisst du denn von *CBM* wie eine
>>>> 680x0 library zu implementieren ist. Und seit wann hat eine
>>>> Implementation mit einer Definition zu tun ?
>>>
>>> Von Mike Sinz?
>
>> Im Status eines 3rd Party Entwickler hat er 1997 dokumentiert wie er
>> 1991/2 die 68040.library entwickelt hat. CBM hat dies *nie*
>> dokumentiert.
>
> Da kam niemand mehr dazu, dies zu dokumentieren... Es hatte damals noch
> niemand verstanden, dass man hier eine API braucht.
>
Ach..von 1991-94 kam keiner zur Dokumentation ?
Ich sehe das eher unter dem Aspekt, dass CBM es nicht dokumentieren
wollte aus Konkurrenz Situation bzgl. 3rd Party Unternehmen.
Jeder in dem Bereich hat das "Rad" neu erfinden muessen fuer ihre
spezielle HW.
>> Da die library passive war, war es egal ob irgendwer die MMU spaeter
>> uebernommen hat, wie z.b. Enforcer oder deine SW. Die Phase5 MMU
>> Ansteuerung war immer aktiv. Darum geht es hier.
>
> Aktiv? In dem Sinne dass es eine nicht-dokumentierte API gibt, ohne
> irgendwelches Locking, Zugriffsprotokolle oder sonstiges? Ich danke.
>
Es ist ein privates API fuer private Funktionialitaet bzgl. Phase5 HW/SW
und es war nie ein Design fuer *oeffentliche* Nutzung gedacht.
(Das habe ich dir auch immer wieder gesagt)
Desweiteren kann man sowieso kein MMU API designen, dass eine
*freie* Nutzung dieser zulaesst. Somit wird es immer funktionale
Kollisionen geben oder ein Einschraenkungen, die irgendeinem wieder
nicht passen.
>>> Sicher. Ist ja auch ein Resource des *Herstellers*, und nicht eines
>>> Drittanbieters.
>
>> Und ?
>
> P5 ist nicht CBM und P5 hat die Motherboards nicht gebaut.
>
Sicherlich ist P5 nicht CBM. Sowie Richter nicht CBM ist.
>>>> Genauso macht es auch die Phase5 library mit lokalen resourcen auf
>>>> *ihrer* HW.
>>>
>>> Wenn "P5"-Hardware ohne ein Amiga-Motherboard ausgekommen wäre, wäre
>>> das ja wohl auch Ok. Aber besagte Hardware ist ja wohl eine Karte FÜR
>>> die Hardware des Herstellers.
>
>> Phase5 hat es als Komplettloesung betrachtet.
>
> Was der Realität zuwiderläuft. Eine Karte kann ich nicht in die
> Steckdose stecken und damit arbeiten. Sie ist Teil eines Gesamtsystems.
>
Als Gesamtsystem innerhalb des AmigaOS 3.1 Kontextes.
>>> Sehr einfach. Weil Du es mir nicht hast dokumentieren wollen. He, es
>>> ist ja nicht so, dass ich Dich nicht gefragt hatte. Wir wollen doch
>>> mal klar- stellen, dass *DU* es warst, der nichts hat sagen wollen,
>>> und nicht ich, der nicht hat zuhören wollen.
>
>> Weil ich die HW Dritten wie dir nicht dokumentiere, da es aus meiner
>> Sicht zur Funktion des Produktes nicht noetig ist.
>
> Vielleicht aber aus der Sicht anderer Leute? Vielleicht ist "Funktion
> des Produktes" in Deiner Sichtweise etwas zu eng definiert?
>
Und ?..Jede Firma definiert ihr Produkt aus *ihrer* Sicht. Wie du deins
aus deiner Sicht definierst.
>>> "Nicht daran halten" ist auch ein ziemlicher Witz. Schau Dir eventuell
>>> mal
>>>
>>> irgendeine der letzten Mu-Releases an. Ich halte mich da ziemlich gut
>>> 'dran, in der Hoffnung, auch ohne Deine offenbar existierende, aber
>>> mir
>>> nie zur Verfügung gestellte Dokumentation so halbwegs das richtige
>>> getroffen zu haben. *DAS* stinkt mir - Ratespielchen, und dann noch
>>> Anschuldigungen, dass ich Produkte supporte, die Dir *Deinen eigenen
>>> Aussagen gemäß* schnurzegal sind.
>
>> Wann kapierst du endlich, dass das *dein* Problem ist, dass *du* dir
>> ausgesucht hast, weil du entschieden hast dich nicht an die Nutzungs-
>> definition des MMU Trees zu halten.
>
> Ich habe noch immer keine "Nutzungsdefinition des MMU-Trees". Was ich
> habe sind einige nicht belegbare Aussagen Deines (schlechten) Design-
> geschmackes.
>
*Es ist ueberhaupt kein Design*.
Es ist aber der common Nenner seit dem MMUs auf CPU Karten im
AmigaOS 3.1 genutzt wurden.
>> Ich habe dir immer gesagt, dass jeder gerne im MMU Tree rumspielen kann
>> wie er lustig ist. Das er aber niemals die Kontrolle ueber die MMU
>> komplett uebernehmen kann, weil es sonst nicht gesichert funktioniert.
>
> Dafür, dass es nicht gesichert funktioniert, funktioniert es aber sehr
> gut... und wenn Du nicht siehst, dass obiges keine Definition eines
> Designs ist, dann kann ich Dir auch nicht helfen.
>
Du willst immer noch nicht verstehen was ich sage.
Ich verstehe ja, dass ein MMU oeffentliches API *nuetzlich* ist...aber ich
sehe darin keinen Sinn mehr nach 1997....nachdem es keine signifikante neue
68k HW mehr gibt gab es aus einer Nutzenanalyse keinen Sinn mehr macht
ein MMU API zu unterstuetzen.
Hast du es *jetzt* realisiert ?
>>> - Ich bekomme hier Vorwüfe, mich an Dokus nicht zu halten, Die Du mir
>>> nicht hast geben wollen,
>
>> Ich mache dir doch keine Vorwuerfe. Mir ist es egal was du machst.
>
> Dafür, dass es egal ist, reden wir aber schon sehr lange.
>
>> Was *mir* nicht egal ist, wenn wieder solche Keulen wie
>> "nicht Systemkonform" kommen, nur weil ich mit dir nicht
>> kooperiere.
>
> Weil es nicht systemkonform ist, weil es keine anderslautenden Dokumente
> gibt. Dem Punkt könntest Du abhelfen, weigerst Dich aber beharrlich.
>
Also wenn ich dir sage wie das Mapping ist, ist es ploetzlich
"systemkonform" ?
>>>> Du argumentierst einfach so wie es dir gerade passt....einmal ziehst
>>>> du das RKM herran und verdammst 3rd party "Erweiterungen" und dann
>>>> wird auf
>>>> 3rd party definitionen als "Kanon" hingewiesen.
>>>
>>> Aha, die 68040.library von CBM war also 3rd-Party, gelle?
>
>> Nein.
>
> Danke. Mehr wollte ich nicht wissen.
>
Und was ziehst du wieder fuer Schluesse ?
>>>> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
>>>> dokumentiert.
>>>
>>> Wo, wann?
>
> Ich wiederhole diese Frage.
>
Ich habe es dir und mehrmals auf .programmers gepostet.
Die common MMU Tree Nutzung seit der 68040.library.
"Man kann auf eigene Gefahr alles im MMU Tree anstellen,
so lange man die Kontrolle nicht uebernimmt. Das funktioniert
mit jeder HW, wenn man *weiss* was man tut."
>>> Diese Dokumentation ist etwa genauso geistreich wie die
>>> C-64-Speicherver- waltung: Man darf in jede Speicherzelle
>>> reinschreiben, es sei denn, ein anderer hätte sie schon belegt. Wie
>>> bekommt man das heraus? Nicht mein Problem. Tja, und wenn man nicht
>>> aufpasst, stürzt es eben ab.
>
>> Genau...als waere es anders mit irgendeinem anderen MMU Interface heute
>> an das sich sowieso keiner ausser du dran haelt.
>
> Auch nachweislich nicht korrekt...
>
Was ist nachweisslich nicht korrekt ?
Welche CPU Board Firma haelt sich denn an die MMU Library Definition ?
>> Deswegen war seit der 68040.library *immer* der gemeinsame Nenner, dass
>> man auf *eigene* Gefahr im MMU Tree werkelt.
>
> Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist kein
> Design.
>
Es wird keine Zeit mehr dafuer, weil der Zug abgefahren ist.
Die Zeit war 1994.
>>> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>
>> Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme loesst
>> und von jedem unterstuetzt wird.
>
> Ich behaupte nicht, Weltprobleme zu lösen. Ich behaupte, für ein paar
> MMU-spezifische Probleme eine brauchbare API definiert und benutzt zu
> haben, und dass, obwohl Du weiterhin versuchst, mir Steine vor die Beine
> zu werfen.
>
Ich werfe dir doch keine Steine in den Weg...du hast dir halt einen
*steinigen* Weg *ausgesucht*. Ich mache einfach nur *gar nichts*
und fuer das *gar nichts* machen, bekomme ich dann nette "Huldigungen"
in speziellen Docs, als haettest du ein Recht darauf, dass ich dich
unterstuetze.
>>> Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss*
>>> ich mich hier nach Angaben von Produktentwicklern richten, die für CBM
>>> gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
>>> berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den Buckel
>>> runter" konterst...
>
>> Wie es in den Wald reinschallt, schallt es herraus.
>
> Und dann werden noch Lügen verbreitet, wie es Dir passt. Wirklich
> nett...
>
Welche Luegen denn ?
> Herr Schmidt, ich hatte damals höflich angefragt, und mir den Ton von
> Etienne Voigt - falls Du Dich noch entsinnen kannst - verbitten lassen.
> *DU* warst derjenige, der nur herumgemault hat.
>
Wie z.b. "nette Kommentare in den Docs" obwohl ich dir nichts getan hatte
ausser das ich gesagt habe, dass ich keinen Sinn in deiner Taetigkeit
gesehen habe. Das fuehrte dann dazu, dass du EMail Inhalte an PIK
weitergeleitet hast und dementsprechend ging das dann in diesem Medium
alle paar Monate weiter.
> Interessanterweise waren Anfragen an andere Leute, wie etwa Mike Sinz,
> da sehr viel erfolgreicher.
>
Ist doch ok, wenn er dir das alles dokumentiert, was er mal gemacht hat.
Schoene Geste. Nur hat er aber kein Interesse mehr an Amiga SW/HW,
im Gegensatz zu mir.
> Wie kommt das wohl, dass man von Dir bestenfalls vollgemault wird, aber
> keine Antworten bekommt?
>
Wie kommt das nur, wenn man "nein" sagt und mehr nicht, dass das
dann zu netten Kommentaren fuehrt und oeffentlichen Schlammschlacht
seitens PIK und dir(ist nicht systemkompatibel).
Auf der 3.5 Mailingliste gab es dann auch aehnliches.
Ueber *dich* habe ich mich oeffentlich in keinster Weise geaeussert.
Ich habe es diverse Male per "Email" versucht, dass du endlich mit dem
Kram aufhoerst bzgl. meiner Person....hat leider nichts gefruchtet.
>>>> Die sogenannte "neue" Bereifung laeuft ohne einen signifikanten
>>>> Unterschied verglichen zur "alten" Bereifung, da der Reifen
>>>> eigentlich immer in der Garage steht.
>>>
>>> Ich weiß nicht, was Du mit Deinem System so anstellst, aber meine
>>> Reifen sind recht gut warmgelaufen.
>>>
>>> Bietet P5 "defensiven" Speicherschutz auf ROM-Module im RAM ohne dass
>>> ein versehendliches Schreiben gleich einen Guru-2 auslöst? Bietet P5
>
>> Wen interessiert das ?
>
> Offenbar genug. Mich interessiert's.
>
>> Es hat 0.000000000001% Effekt, da du mit Sicherheit weisst, dass so
>> eine
>> "Protection" keinen signifikanten Schutz bietet besonders bei der
>> minimalen Bedeutung von random writes bzgl. System Crashes. Ein
>> Placebo/Alibi Feature.
>
> Kleine Saure-Trauben Reaktion gefällig?
>
Nein. Ich bezweifele *wirklich* den Sinn. Das ganze wurde auch
schon 1995/1996 diskutiert und ich war genau der gleichen Meinung.
Und du bist bestimmt intelligent genug, um die Wirksamkeit dieses
Schutzes realistisch einschaetzen zu koennen.
>>> "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf einem
>>> 68060?
>>> Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes
>>> Debugging- Tool a la "Guardian Angel"? Funktioniert das zusammen mit
>
>> Guardian Angel Remix wurde von Bjorge mittels Cyberguard sourcen
>> entwickelt...
>> 95-96 rum. 3-4 Jahre vor deiner *Reimplementierung*.
>
> Ich habe erstens nichts re-implementiert, und zweitens kooperiert
> besagtes Tool immer noch nicht mit anderen MMU-Hacks. Versuche mal sowas
> parallel zu einem anderen "aktiven" MMU-Tool zu starten und Du merkst
> den Unter- schied zwischen einem Design und einem Hack.
>
>>> Shapeshifter-Videotreibern?
>
>> Die liefen auch *vor* muforce.
>
> Aber nicht "mit" Enforcer.
>
Mit CyberGuard sollte das aber kein Problem gewesen sein:-)
Jedenfalls kein prinzipielles Designproblem.
>>> Momentan läuft hier schon mal MuForce, MuFastRom, MuProtectModules.
>>> MuGa zum Debugging, MuEVD für die Mac-Emulation, wenn ich sie mal
>>> anschalte. Auf der GVP lief noch MuFastZero.
>
>> Und ? 99% der Features funktionierten auch vor dem neuen API.
>
> Aber nicht miteinander und in beliebiger Kombination. Ich glaube,
> entweder hast Du oder willst Du nicht verstehen, was das ganze soll.
> "Alles, was ich nicht gemacht habe, taugt nichts".
> Du bist noch armseliger, als ich dachte.
>
Falsch...ich habe kein Problem damit anzunehmen, dass dein
MMU API *brauchbar* ist und mit hoher Wahrscheinlichkeit
besser ist, als das private und nicht "designte" 680x0.library API.
Ich verstehe nur den Nutzen/Sinn *heute* nicht mehr.
Aber das ist *meine* Auffassung der Dinge. Wie ich schon
mehrmals gesagt habe, reagiere ich hier nur auf diese
"system inkompatibel" Geschichte.
>>>>> Falls Du andere, neuere Dokumente hast, so lese ich diese gerne
>>>>> (wirklich!).
>>>> Und ich behaupte ganz einfach, dass der Bereich fuer CPU Slot Karten
>>>> zur freien Nutzung da ist.
>>> Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis
>>> 0xe000
>>> 0000 für mein Privatvergnügen. Wer immer da reinschreibt oder ihn
>>> belegt, hat verloren. (-; Hört sich nach einem lustigen Spiel an...
>
>> Tja...der Bereich ist jetzt auch weg mit der grex:-)
>
> Nö, er ist von mir soeben reserviert worden, und was andere machen,
> inter- essiert mich nicht. Und was ich damit anstelle, ist meine Sache,
> und Dokumente dazu verbreite ich nicht, und wer immer was damit anstellt
> außer mir soll zur Hölle fahren, und supporten tu' ich das erst recht
> nicht. P5-Logik.
>
kommerzielle effizienz Logik.
Das GRex ist eine Erweiterung des Cyberstorm/BlizzardPPC Produktes,
dass schon eine notwendige MMU Steuerung beinhaltet.
Glaubst du etwa ich/andere "lizensieren" sich von dir den mmulib
source + 68k library src oder passen die eigene 68k library an fuer
eine Flashnutzung im Jahre 2001, wenn die hinreichend notwendige
Technologie schon existiert ?
>>> Ist Dir ein Begriff wie "Standardisierung" geläufig, und wozu das
>>> dient?
>>> (-:
>
>> Sicherlich...nur habe ich dir immer gesagt, dass seit Jahren kein neuer
>> MMU Standard mehr *Sinn* macht,
>
> Offenbar immer noch genug Sinn für einige Leute. Weil *DU* nicht
> verstehst, wozu das ganze sein soll, oder weil Du nicht willst, dass
> jemand in *Deine Geniale Software* (tm) hineinsieht, blockierst Du hier.
>
Die ist nicht genial..habe ich nie behauptet.
>
>> weil es keine signifikant neue HW fuer 68k geben wird und die alten
>> Tools neu implementiert werden muessen(Hast du ja offensichtlich
>> gemacht) ohne einen signifikanten Mehrnutzen(ausser Sendungsbewusstsein
>> fuer T.Richter) ergibt.
>
> Ich habe kein *Sendungsbewusstsein*. Ich habe nur genug von den
> "Designideen" eines gewissen Herrn. Ich habe das Zeug, wie ich schon
> mehrmals gesagt hatte, implementiert, weil ich es für eine interessante
> Aufgabe hielt. Klar, sowas verstehst Du nicht. Dass ich es nicht
> verkaufen kann, war mir sowieso schon klar.
>
Es gibt doch ueberhaupt kein Design...also habe ich auch keine Ideen
zu diesem haben koennen.
>>> Wie dem auch sei, gut das wir's jetzt wissen, F-Space ist sowieso
>>> schon reserviert von der MMU, und jetzt habe ich auch Deinen Segen
>>> dafür, richtig?
>
>> *Mir* ist egal was *Du* bzgl. MMU Ansteuerung machst.
>
> So egal, dass wir immer noch reden, gelle?
>
Ich habe schon mehrmals gesagt, dass ich hier nur mit dir kommuniziere
wegen deiner netten "system inkompatibel" bezeichnung.
>> Was *mir* nicht egal ist sind solche Sachen wie "Nicht Systemkonform".
>
> Was es nicht ist - den Beweis bleibst Du immer noch schuldig. "Ich
> definiere als Konform" halte ich für keinen Beweis.
>
Ich habe dir zum Thema configdev nodes wohl genug gesagt.
>>> Sag' mir jetzt noch bitte, welches Mapping braucht der F-Space, und
>>> die Doku, die ich bräuchte, wäre schon mal in der nächsten Phase.
>
>> Ich supporte keine 3rd party HW AmigaOS Ansteuerung, weil ich auf die
>> korrekte Funktion *meiner* Definition angewiesen bin beim User.
>
> *Deiner* *Top Secret* Definition von Usern, die Du nicht mehr supporten
> willst? Du widersprichst Dir in Deiner seltsamen Logik doch nur selbst.
>
Wer sagt denn, dass ich diese nicht mehr supporte ?
> Entweder Du machst nichts mehr, dann darf Dir der Zirkus auch egal sein,
> oder Du machst noch was, und dann solltest Du an weiteren Entwicklungen
> auch interessiert sein. Aber einerseits zu behaupten, Du hättest
> Interesse an der "korrekten Funktion Deiner Hardware" und andererseits
> zu behaupten
> "das hätte doch alles keinen Sinn mehr" ist ein Widerspruch in sich.
>
Falsch.
o Ich habe interesse, dass die flash,ppc.library,scsi korrekt funktioniert,
was nur mit der existierenden MMU Loesung *fuer mich* garantiert
ist.
o Ich habe Interesse, dass das grex produkt korrekt bzgl. MMU
Nutzung funktioniert.
o Ich habe Interesse, dass der MorphOS startup korrekt funktioniert.
> Ich glaube, das wirkliche Problem liegt da ganz woanders... ...und es
> ist alles so wunderbar durchsichtig und für jederman offensichtlich.
>
Wirklich ?:-)
Du meinst, weil du etwas geschaffen hast was besser ist als was ich
mal vor 7 Jahren programmiert habe, dass ich "neidisch" bin ?
Das ist *nicht* der Fall.
Ich habe eine *Meinung* zu dem Sinn der Aktion im Kontext der
*Marktsituation*, aber das sei doch dir ueberlassen was du machst.
Ich blockiere dich doch in keinster Weise *aktiv*. Ich habe kein
Problem damit wenn irgendwer die 680x0 libraries aus dem System
auf *eigene* Gefahr entfernt.
(Ich habe mich in *keinster* Weise bei Frank Wille zu seinem utility
geaeussert und habe auch kein persoehnliches Problem mit ihm
bzgl. seiner ppclib Emulation)
Du solltest echt keine Annahmen bzgl. meiner Motivation machen,
weil die nicht so einfach schwarz&weiss funktioniert wie du es
wohl glaubst
>>>> Sicher weiss ich das....aber du argumentierst mit Inhalten aus Mike's
>>>> Dokumentation als waeren diese von CBM und das entspricht einfach
>>>> nicht den Fakten.
>>>
>>> Da war nichts mehr von CBM übrig...
>
>> Wie ich schon sagte...du argumentierst gerade so wie es dir passt und
>> haelst dich nicht mal an deine eigenen Regeln, dessen "Verfehlung" du
>> anderen hier vorhaelst.
>
> Meine Regeln sind, dass ich mich daran halte, was dokumentiert ist. Ich
> habe null Dokumentation von Dir. Ich habe massig Dokumente von Mike
> bzgl.
> 68040-Lib, die er für CBM entwickelt hat.
> Es steht Dir immer noch frei, das zu ändern.
>
Ich habe doch gesagt, dass ich kein Interesse daran habe, weil ich noch
Interesse an der *SW* habe. M.Sinz hat dieses nicht.
>>>> Da es kein definiertes MMU Handling vom OS gibt, ist das Sache des
>>>> CPU Karten Herstellers.
>>>
>>> Siehe meine Argumentation oben - Du bist nicht der "lone ranger",
>>> dessen Hardware allein im System laufen muss. Da Zusatzboards anderes
>>> Mapping
>
>> Das ist aber die *Realitaet* seit den ersten 68030 boards bis zu den
>> 060 Boards gewesen. Was du hier gerne haettest ist eine *Utopie*.
>
> Interessant, eine lauffähige Utopie. (-:
>
Ich will doch nicht abstreiten das es laeuft.
>>> benötigen, und der Hersteller kaum alle weiteren Boards kennen kann,
>>> ist
>>> *diese* Definition wenig zweckdienlich und extrem kurzsichtig.
>
>> Wenn keine signifikante 68k HW mehr seit Jahren gekommen ist, ist es
>> nicht "kurzsichtig" sondern eine effiziente nutzen/aufwand
>> abschaetzung.
>
> Stattdessen steckst Du, statt das Zeug an einem Nachmittag mal
> auszugraben,
> (Aufwand null, Nutzen imens), Deine Zeit lieber in immer die gleiche
> Argumentation. Ich sage Dir auf die Nase zu, dass das absolut nichts mit
> Nutzen oder Aufwand oder sonst was zu tun hat, und dass Du hier
> angebliche Argumente vorschiebst.
>
Falsch. Ich habe noch ein aktives Interesse daran und zweitens wuerde
ich dir sowieso nichts dokumentieren nach diversen *persoehnlichen*
Aktionen deinerseits.
> Optimiere den Nutzen, verhindere den Aufwand, schicke mir das Zeug zu.
> Fertig.
>
Noe.
>> Es geht nicht darum, dass ein globales MMU API nuetzlich ist. Sondern
>> darum, dass es *heute* unsinnig ist, da es keinen signifikanten
>> Mehrwert fuer Entwickler(welche?) gibt.
>
> Welchen "effektiven Nutzen" hat heute ein PPC-Board? Keinen? Warum
> machst Du das? Du bist schon wieder dabei, irgendwelche Unsinnsargumente
> vorzu- schieben. Es geht doch im Grunde gar nicht darum, habe ich recht?
>
Fuer mich hat MorphOS einen kommerziellen und idiellen Zweck.
Die PowerHW wird auch noch kommerziell verwertet.
Wenn ich kein Interesse mehr gehabt haette und du mir nicht
diverse Male ueber den Fuss gelaufen waerst, haette ich dir
eventuell die Sourcen gegeben.
> Es geht darum, dass *Du* recht haben willst, und dass Du nur zu gerne
> das Ekel spielst. Das hingegen gelingt Dir ganz ausgezeichnet.
>
Inwiefern spiele ich das Ekel ?:-)
Ich beleidige dich nicht, ich sage nichts zur Qualitaet deiner
Programme. Ziehe nicht ueber dich her in diversen Medien.
Verteile nicht Inhalte von privaten EMails and dritt Personen.
Das einzige was ich dir sage ist...*nein*.
>> Desweiteren wurden auch diverse 3rd party Gfxboards auch mittels
>> speziellem Mapping supportet. Das Feature wurde ja dann spaeter auch
>> von Nils in P96 implementiert, fuer Villagetronic Produkte.
>
> Die Picasso-IV hat zwar ein dynamisches Mapping, aber die MMU-Verwaltung
> für diese Karte ist statisch und bedarf keiner besonderen Tricks. Die
> meldet sich schon korrekt an. Dass man hier optimieren kann, ist eine
> andere Sache.
>
Es ging um die "optimierung bzgl nonguard".
>>>> Warum musst *du* den denn mappen. Das ist Sache des Herstellers. Das
>>>> ist doch das was *du* nicht realisieren willst.
>>>
>>> Weil diese Auffassung Nebenwirkungen hat und Interoperabilität auf
>>> diese Weise nicht zu gewährleisten ist?
>
>> komisch...es gab auch eine zeit *vor* der mmu.library.
>
> Ach, sag' bloß? Und, konnte ich MMU-Hacks sicher parallel laufen lassen?
>
Ich habe keine anderen MMU hacks benutzt. Dementsprechend hatte
ich keine Probleme:-)
>>>> Und die sind nicht alles und zweitens dokumentieren die auch nicht
>>>> alles was du hier immer vorbetest bzgl. configdevs.
>>>
>>> Wie ich schon sagte: Schick' mir halt mehr Dokus, ich habe nichts
>>> dagegen, auch andere Boards zu supporten, bitte, gern gescheh'n. Nur
>>> lasse ich mich nicht gern dafür auch noch vollmaulen.
>>>
>
>> Ich argumentiere zurueck nach der netten aussage wie
>> "nicht systemkonform".
>
> Ich frage auch nicht zum ersten Mal. Ich habe Deine Spielchen nur so
> satt, weil man im Grunde genommen genau weiß, worum es geht. Mit
> "standardkonform" oder nicht hat es schon lang' nichts mehr zu tun.
>
Mich hat diese Aussage "veraergert", weil ich sie als persoehnlichen
Angriff werte, von denen du ja schon diverse gemacht hast.
>>> Aha, und warum verwechselst Du dann einen ganz offensichtlichen Bug
>>> mit einem "angeblichen" Spareffekt von zwei Bytes? Ich dachte, es sei
>>> ziemlich bekannt, dass ich zu der Fraktion gehöre, die
>>> Speicherverbrauch und Speed eher hinter Stabilität stellen...
>
>> Ich kenne keins deiner Programme als *Nutzer* naeher um solche
>> Ueberlegungen zu treffen.
>
> Nein, stattdessen formulierst Du lieber Unterstellungen, ist schon klar.
> Macht sich ja auch einfacher. Ich befürchte fast, das war ein Schuss in
> den Ofen.
>
Was denn fuer "Unterstellungen" ?
Irgendwie habe ich den Eindruck, dass du was in meinen Aussagen
reininterpretierst was ich niemals gesagt oder gemeint habe.
Thomas Richter
Hi Ralph,
>>> Das hat nichts mit PPC Emulation zu tun.
>>
>> Dann argumentiere nicht damit.
> Tue ich doch gar nicht(Du hast das gemacht).
Bitte lies' oben noch einmal, was genau Du geschrieben hattest.
> Das bezieht sich auf die Amiga System HW.
Wenn ich eine PPC-Emulation der 68K-Seite fahre, warum interessiert
mich dann, ob ich Bankswitching auf einer (dann zu emulierenden)
Karte mache? Ich würde natürlich eine Karte emulieren, die keine
derartige Hardware benötigt, bzw. den betreffenden Teil von Exec
neu schreiben.
>>> AutoConfig bezieht sich auf *Zorro2/Zorro3*...mein gott.
>>
>> Achwas?
> Du hast doch was anderes behauptet.
Ich behaupte, dass wenn ich dafür Sorge tragen will, dass
Hardware verschiedener Hersteller zusammenarbeiten soll,
Autoconfig eine gute Sache(tm) ist.
>>> Abgesehen davon war die Autoconfig HW *und* SW Definition auch nicht
>>> der Weisheit letzter Schluss. Implementiert nach HW Vorgaben ohne ein
>>> weitergehendes Design. PCI ist aus meiner Sicht in allen Belangen
>>> besser bzgl. *Autoconfig*.
>>
>> Nur dass es damals kein PCI gab, und dass kein Amiga PCI unter- stützt,
>> und dass AutoConfig damals die Wahl war, wenn man neue Hardware
>> supporten wollte.
> Agreed...das war aber eigentlich nicht der "Punkt":-)
> Das bezog sich auf das API Interface und deren Nuetzlichkeit
> fuer Zwecke wie generelle Adressraum/Cache Definition und
> die Limitierung der Diags bzgl. extensiven Rominhalten >64KB
Sicher, Zorro lässt auch in vielen Dingen zu wünschen übrig,
ebenso Autoconfig. In Z-3 hat sich einiges, aber nicht alles
getan. Cache-Modi muss man ja trotzdem noch "raten", aber man darf
konservativ zumindest IO-Boards als "Cache-Inhibit" fahren, ohne dass
dieses Zeug einem um die Ohren fliegt. Nur, *eine* Definition ist
mir lieber als *keine* Definition.
>>> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis gesichert hat
>>> und mit ihren Entwicklungen Standards gesetzt hat(CGFX).
>>
>> Standards, die nicht dokumentiert sind, helfen niemandem. Ich warte
>> immer noch auf Dokumente.
> Der Standard wird durch die Konfiguration des Boards definiert.
Was mir nichts hilft, da ich die Konfiguration des Boards nicht kenne.
>>> Phase5 hat ein integriertes Produkt angeboten, wozu auch die komplette
>>> MMU Steuerung gehoert.
>>
>> Und ich erkläre Dir jetzt zum zweiten Mal, dass ein Amiga eben kein
>> "komplettes Produkt" ist, sondern mit Produkten anderer Leute zusammen-
>> arbeiten muss. Wenn ihr eure eigene Hardware gebaut hättet, in die man
>> nichts anderes als P5 hineinstecken kann, dann ja. Aber das wäre kein
>> Amiga gewesen.
> Man arbeitet mit den Leuten zusammen mit denen man einen gemeinsamen
> Nenner hat und dessen Interessen sich kombinieren.
Und Interesse bezüglich zukünftiger Entwicklungen und einer gewissen
"Defensivität" des Designs - wollen wir das mal so ausdrücken - waren
nicht vorhanden?
>> Entspricht der Realität bis auf Karten eines gewissen Herstellers, der
>> nicht genügend Bedacht bei der Konstruktion ihrer Hardware angewandt
>> hat. Alles schön und gut, das könnte man ja verkraften, wenn man wüsste,
>> wie das funktioniert.
> Das stimmt doch einfach nicht. Ich habe dir genug Beispiele von Firmen
> gegebenen, die fuer ihr Produkt ein eigenes MMU setup mitlieferten, da
> ohne dieses ihr Board mit AmigaOS nicht funktioniert haette.
> *Genau* das gleiche mit Phase5.
Zumindest kann ich Dir versichern, dass ich von keinen Problemen mit Boards
anderer Hersteller weiß. Ok, das muss natürlich nichts heißen, aber etwas
komisch ist es doch schon, dass ich nur mit einer Sorte Boards Probleme
hatte, und sonst nichts.
>>> Es waere noch mehr wuenschenswert....zu dumm nur, dass es heute
>>> *irrelevant* ist.
>>
>> Offenbar nicht irrelevant genug in Anbetracht der Mail, die ich dazu
>> bekomme.
> Das haengt wohl von den Motiven jedes einzelnen ab, warum er
> interessiert ist.
Natürlich.
> Mein Punkt ist nur, dass es keinen *Sinn* mehr macht, weil keinen
> praktischen Mehrwert fuer die meisten User und auch Entwickler.
> Aber das ist doch jedem einzelnen ueberlassen....
Seufz. Das Problem ist doch, dass nicht jeder einzelne entscheiden kann, ob
er Dokumentation hat oder nicht.
>>> Ich habe auch immer gesagt, dass um 94 rum es noch Sinn gemacht haette
>>> ein *MMU* API zu definieren....der Zug ist aber seit Jahren abgefahren.
>>
>> Dann, lieber Ralph, verstehe ich nicht, warum Du hier immer noch
>> aufkreuzt.
> Wirst du jetzt wieder persoehnlich ?
Tschuldige. Will sagen: Wenn *es* keinen Sinn mehr hat, warum reden wir
hier?
>>> Im Status eines 3rd Party Entwickler hat er 1997 dokumentiert wie er
>>> 1991/2 die 68040.library entwickelt hat. CBM hat dies *nie*
>>> dokumentiert.
>>
>> Da kam niemand mehr dazu, dies zu dokumentieren... Es hatte damals noch
>> niemand verstanden, dass man hier eine API braucht.
> Ach..von 1991-94 kam keiner zur Dokumentation ?
Offenbar nicht.
> Ich sehe das eher unter dem Aspekt, dass CBM es nicht dokumentieren
> wollte aus Konkurrenz Situation bzgl. 3rd Party Unternehmen.
> Jeder in dem Bereich hat das "Rad" neu erfinden muessen fuer ihre
> spezielle HW.
Du weißt doch auch, dass das nicht stimmt. Meine GVP-040 läuft auch mit
der Mike-Sinz 68040.library (v37). Nicht sonderlich gut, da die Lib genug
Macken hat - allerdings nichts MMU relevantes, sondern eher betreffs der
FPU-Emulation. Die Karte war derart gebaut, dass ein solches Problem eben
nicht auftritt, alle Erweiterungen werden angemeldet und werden demnach
korrekt gemappt.
*Wenn* CBM unterlassen hat zu dokumentieren, so sehe ich das etwa genauso
arg wie die nicht vorhandene P5-Dokumentation. Zumindest habe ich letzt-
endlich die Dokus, die ich brauchte.
>>> Da die library passive war, war es egal ob irgendwer die MMU spaeter
>>> uebernommen hat, wie z.b. Enforcer oder deine SW. Die Phase5 MMU
>>> Ansteuerung war immer aktiv. Darum geht es hier.
>>
>> Aktiv? In dem Sinne dass es eine nicht-dokumentierte API gibt, ohne
>> irgendwelches Locking, Zugriffsprotokolle oder sonstiges? Ich danke.
> Es ist ein privates API fuer private Funktionialitaet bzgl. Phase5 HW/SW
> und es war nie ein Design fuer *oeffentliche* Nutzung gedacht.
> (Das habe ich dir auch immer wieder gesagt)
Diese API brauche ich ja auch nicht, sofern man von API sprechen mag.
> Desweiteren kann man sowieso kein MMU API designen, dass eine
> *freie* Nutzung dieser zulaesst.
Definiere "freie Nutzung". Einfach darauf herumschreiben kann man nicht,
natürlich. Davon abgesehen kann man mit "Mu" aber sehr frei auf der
MMU herumwerkeln.
> Somit wird es immer funktionale
> Kollisionen geben oder ein Einschraenkungen, die irgendeinem wieder
> nicht passen.
Das ein Interface jedweder Art Einschränkungen erzeugt will ja niemand
leugnen. Aber besser als "kein Interface" ist es allemal.
>>>> Sicher. Ist ja auch ein Resource des *Herstellers*, und nicht eines
>>>> Drittanbieters.
>>
>>> Und ?
>>
>> P5 ist nicht CBM und P5 hat die Motherboards nicht gebaut.
>>
> Sicherlich ist P5 nicht CBM. Sowie Richter nicht CBM ist.
Nein, aber soweit Sinz CBM war und ich weiß, wie deren Ideen aussahen.
>>>> Wenn "P5"-Hardware ohne ein Amiga-Motherboard ausgekommen wäre, wäre
>>>> das ja wohl auch Ok. Aber besagte Hardware ist ja wohl eine Karte FÜR
>>>> die Hardware des Herstellers.
>>
>>> Phase5 hat es als Komplettloesung betrachtet.
>>
>> Was der Realität zuwiderläuft. Eine Karte kann ich nicht in die
>> Steckdose stecken und damit arbeiten. Sie ist Teil eines Gesamtsystems.
> Als Gesamtsystem innerhalb des AmigaOS 3.1 Kontextes.
Besteht 3.1 nur aus P5? Fragwürdig, und sehr kurzsichtig. Dass es läuft will
ich ja nicht bestreiten.
>>> Weil ich die HW Dritten wie dir nicht dokumentiere, da es aus meiner
>>> Sicht zur Funktion des Produktes nicht noetig ist.
>>
>> Vielleicht aber aus der Sicht anderer Leute? Vielleicht ist "Funktion
>> des Produktes" in Deiner Sichtweise etwas zu eng definiert?
> Und ?..Jede Firma definiert ihr Produkt aus *ihrer* Sicht. Wie du deins
> aus deiner Sicht definierst.
Ich kann nur sagen, was an mich herangetragen wird - offenbar ist Deine
Einschätzung von dem, was ein Board tun oder lassen sollte, wohl zu eng
gegriffen.
>> Ich habe noch immer keine "Nutzungsdefinition des MMU-Trees". Was ich
>> habe sind einige nicht belegbare Aussagen Deines (schlechten) Design-
>> geschmackes.
> *Es ist ueberhaupt kein Design*.
Ok, endlich mal eine Aussage. (-: Das will ich meinen, es ist keins.
> Es ist aber der common Nenner seit dem MMUs auf CPU Karten im
> AmigaOS 3.1 genutzt wurden.
Genutzt wurden. Sicher, unbestreitbar. "Benutzbar sind" aber wohl eher
weniger.
>>> Ich habe dir immer gesagt, dass jeder gerne im MMU Tree rumspielen kann
>>> wie er lustig ist. Das er aber niemals die Kontrolle ueber die MMU
>>> komplett uebernehmen kann, weil es sonst nicht gesichert funktioniert.
>>
>> Dafür, dass es nicht gesichert funktioniert, funktioniert es aber sehr
>> gut... und wenn Du nicht siehst, dass obiges keine Definition eines
>> Designs ist, dann kann ich Dir auch nicht helfen.
> Du willst immer noch nicht verstehen was ich sage.
> Ich verstehe ja, dass ein MMU oeffentliches API *nuetzlich* ist...aber ich
> sehe darin keinen Sinn mehr nach 1997....nachdem es keine signifikante neue
> 68k HW mehr gibt gab es aus einer Nutzenanalyse keinen Sinn mehr macht
> ein MMU API zu unterstuetzen.
Moment mal, hier stimmt schon wieder etwas nicht... Unten erzählst Du was
von wegen "neue Hardware"(GRexx), hier sagst Du "es gibt keine signifikante
neue Hardware". Kann oder kann ich nicht diese Hardware mit einem Amiga,
der nunmal mit einem 68k läuft, betreiben? Oder merkt der 68K davon über-
haupt gar nichts? Im letzteren Fall wäre mir das recht gleich.
Darf ich daraus schließen, dass Du diese Hardware für "nicht signifikant"
und nicht "wert einer Überlegung bezüglich eines konservativeren Designs"
hältst?
> Hast du es *jetzt* realisiert ?
Schön, dass Dir die ganze 68K-Schiene egal ist - habe ich ja verstanden.
Und weil *Dir* die 68Ks egal sind, dürfen sie auch allen anderen gleich
sein?
>> Weil es nicht systemkonform ist, weil es keine anderslautenden Dokumente
>> gibt. Dem Punkt könntest Du abhelfen, weigerst Dich aber beharrlich.
> Also wenn ich dir sage wie das Mapping ist, ist es ploetzlich
> "systemkonform" ?
Es würde einem System folgen, ich wüsste was zu tun wäre, und Ruhe wäre.
Ich hätte genug Grund, Dir zu danken.
>>>> Aha, die 68040.library von CBM war also 3rd-Party, gelle?
>>> Nein.
>> Danke. Mehr wollte ich nicht wissen.
> Und was ziehst du wieder fuer Schluesse ?
Dass es offenbar bei CBM damals durchaus ein Design für MMUs gab, dies
aber nicht oder nicht mehr von CBM dokumentiert wurde und erst nachträglich
von einem ehemaligen Entwickler zusammengetragen wurde?
>>>>> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
>>>>> dokumentiert.
>>>> Wo, wann?
>> Ich wiederhole diese Frage.
> Ich habe es dir und mehrmals auf .programmers gepostet.
Nun, ich verstehe ja nicht, was Du unter "öffentlicher Dokumentation"
verstanden haben willst. Ein "tu doch was Du willst" halte ich jedenfalls
nicht dafür. Unter "öffentlicher Dokumentation" hätte ich eher etwas wie
die "Autodocs" für eine 68040-Library verstanden, nebst Anhang bzgl. deren
MMU Belegungen. Ziemlich genau etwas der Größenordnung, was ich von Mike
bekommen habe - vielleicht nicht so gut poliert.
> Die common MMU Tree Nutzung seit der 68040.library.
> "Man kann auf eigene Gefahr alles im MMU Tree anstellen,
> so lange man die Kontrolle nicht uebernimmt. Das funktioniert
> mit jeder HW, wenn man *weiss* was man tut."
*Seufz* Und das ist eine Dokumentation?
>>> Genau...als waere es anders mit irgendeinem anderen MMU Interface heute
>>> an das sich sowieso keiner ausser du dran haelt.
>>
>> Auch nachweislich nicht korrekt...
> Was ist nachweisslich nicht korrekt ?
> Welche CPU Board Firma haelt sich denn an die MMU Library Definition ?
Ich rede nicht von Firmen. Seit wann arbeitet noch eine Firma an Amiga-
Hardware?
>>> Deswegen war seit der 68040.library *immer* der gemeinsame Nenner, dass
>>> man auf *eigene* Gefahr im MMU Tree werkelt.
>>
>> Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist kein
>> Design.
> Es wird keine Zeit mehr dafuer, weil der Zug abgefahren ist.
> Die Zeit war 1994.
Na schön, niemand kann ersthaft noch Amiga-Hardware erwarten. Warum bedeutet
dies, dass niemand mehr damit arbeiten darf, und daran arbeiten darf? Warum
muss Deine Meinung hier ausschlaggebend sein?
>>>> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>>
>>> Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme loesst
>>> und von jedem unterstuetzt wird.
>>
>> Ich behaupte nicht, Weltprobleme zu lösen. Ich behaupte, für ein paar
>> MMU-spezifische Probleme eine brauchbare API definiert und benutzt zu
>> haben, und dass, obwohl Du weiterhin versuchst, mir Steine vor die Beine
>> zu werfen.
> Ich werfe dir doch keine Steine in den Weg...du hast dir halt einen
> *steinigen* Weg *ausgesucht*. Ich mache einfach nur *gar nichts*
Ja, eben. Stattdessen wird man bei - so finde ich berechtigten - Anfragen
angemault.
> und fuer das *gar nichts* machen, bekomme ich dann nette "Huldigungen"
> in speziellen Docs, als haettest du ein Recht darauf, dass ich dich
> unterstuetze.
Ich beklage mich über meineserachtens fehldesignte Hardware und ein
Übermaß an Hacks, das nicht hätte sein müssen. Das fängt bei Kleinigkeiten
wie der F-Space-Belegung an und hört bei Seltsamkeiten wie residenten
680x0-Bibliotheken auf. Das das alles funktioniert, ist klar. Nur, darum
geht es nicht vordringlich. Dinge sind auf eine derart unvorsichtige und
- teilweise sogar so möchte ich sagen "töpelhafte" - Weise zusammengesteckt,
dass mir das Grausen kommt. "Damals" war schon klar, dass es eventuell auch
andere Wünsche seitens PPC-Benutzung der User gab. Damals gab es schon "VMM",
und dennoch wurden die Call-Outs der 68060-Lib entfernt (-> man denke etwa
an fsin.x (a0) mit a0 "swapped out"). Damals gab es schon Wünsche nach
alternativen CPU-Bibliotheken oder alternativen Graphikbibliotheken. Nein,
hatte der User einmal P5, so musste er dabei bleiben - das fing bei der
68060.library an und hört bei CGFx auf, die sich auf irgendwelche Internals
der CPU-Library verlassen muss, weil Autokonfig nicht "die Wahl" war, aus
welchen Gründen auch immer. Dokumentation dazu gab es nicht, an existierende
APIs, die man durchaus hätte benutzen können, zum Teil mit einem *Minimum*
an Mehraufwand hat man sich nicht gehalten. Und darüber soll ich in Jubeln
ausbrechen?
>>>> Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss*
>>>> ich mich hier nach Angaben von Produktentwicklern richten, die für CBM
>>>> gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
>>>> berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den Buckel
>>>> runter" konterst...
>>
>>> Wie es in den Wald reinschallt, schallt es herraus.
>>
>> Und dann werden noch Lügen verbreitet, wie es Dir passt. Wirklich
>> nett...
>>
> Welche Luegen denn ?
Etwa wie oben, dass ich mir jetzt vorwerfen lassen muss, nicht freundlich
genug gefragt zu haben. Etienne hatte Dich damals - und das muss ich
zugeben - angep**. Einiges war damals sehr schief und sehr zu meiner
Enttäuschung danebengelaufen.
>> Herr Schmidt, ich hatte damals höflich angefragt, und mir den Ton von
>> Etienne Voigt - falls Du Dich noch entsinnen kannst - verbitten lassen.
>> *DU* warst derjenige, der nur herumgemault hat.
> Wie z.b. "nette Kommentare in den Docs"
Was ja wohl einige Monate später erst erfolgte? Bitte, bleiben wir doch
bei der Kausalität.
> obwohl ich dir nichts getan hatte
> ausser das ich gesagt habe, dass ich keinen Sinn in deiner Taetigkeit
> gesehen habe. Das fuehrte dann dazu, dass du EMail Inhalte an PIK
> weitergeleitet hast und dementsprechend ging das dann in diesem Medium
> alle paar Monate weiter.
Das war zu dem "mal wieder ein Problem" im cyberscsi und Co, wo Du ziemlich
unvorsichtig vorgegangen bist, und ich dann noch eine Antwort von wegen
"lass' mich in Frienden" bekommen habe. Übrigens nicht das einzige Problem
vom cyberscsi, leider.
>> Interessanterweise waren Anfragen an andere Leute, wie etwa Mike Sinz,
>> da sehr viel erfolgreicher.
> Ist doch ok, wenn er dir das alles dokumentiert, was er mal gemacht hat.
> Schoene Geste. Nur hat er aber kein Interesse mehr an Amiga SW/HW,
> im Gegensatz zu mir.
Und *weil* Du Interesse hast, behälst Du Informationen vor und blockierst
deshalb?
>> Wie kommt das wohl, dass man von Dir bestenfalls vollgemault wird, aber
>> keine Antworten bekommt?
> Wie kommt das nur, wenn man "nein" sagt und mehr nicht, dass das
> dann zu netten Kommentaren fuehrt und oeffentlichen Schlammschlacht
> seitens PIK und dir(ist nicht systemkompatibel).
Erstens, ich habe mit Ralphael nichts zu tun. Was er macht ist sein Bier,
und der Ton ist durchweg daneben. Haben wir das klargestellt?
Zweitens: Zu besagten Schlammschlachten hast Du immer wieder Anlass gegeben
durch gekonnt miss-launige Reaktionen auf durchweg höflich gemeinte Anfragen.
> Auf der 3.5 Mailingliste gab es dann auch aehnliches.
Weil ich mal wieder ein Problem mit dem cybscsi und Co hatte von wegen
der schlauen Idee "ich mounte und blockiere Filing-Systeme selbst". Es
ist einer der Punkte, an denen man merkt, dass der Autor offenbar nicht
gründlich nachgedacht hatte, oder nicht gründlich getestet hatte, oder
beides. Bei Dir deswegen anzufragen... sein wir mal ehrlich, was wäre
das Resultat gewesen?
> Ueber *dich* habe ich mich oeffentlich in keinster Weise geaeussert.
> Ich habe es diverse Male per "Email" versucht, dass du endlich mit dem
> Kram aufhoerst bzgl. meiner Person....hat leider nichts gefruchtet.
Du hast ja auch nichts getan, um meine Meinung zu ändern...
>>> Es hat 0.000000000001% Effekt, da du mit Sicherheit weisst, dass so
>>> eine
>>> "Protection" keinen signifikanten Schutz bietet besonders bei der
>>> minimalen Bedeutung von random writes bzgl. System Crashes. Ein
>>> Placebo/Alibi Feature.
>>
>> Kleine Saure-Trauben Reaktion gefällig?
>>
> Nein. Ich bezweifele *wirklich* den Sinn. Das ganze wurde auch
> schon 1995/1996 diskutiert und ich war genau der gleichen Meinung.
> Und du bist bestimmt intelligent genug, um die Wirksamkeit dieses
> Schutzes realistisch einschaetzen zu koennen.
Sicher, die wenigsten Abstürze passieren deshalb. Das allein ist auch
nicht nur der Grund für dieses Feature. Es ist auch in Hinblick auf
bestimmte Emulationsanwendungen entwickelt worden.
Wie dem auch sei, es ist eines der neuen Features, in das einiges an
Arbeit geflossen ist.
>>>> "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf einem
>>>> 68060?
>>>> Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes
>>>> Debugging- Tool a la "Guardian Angel"? Funktioniert das zusammen mit
>>
>>> Guardian Angel Remix wurde von Bjorge mittels Cyberguard sourcen
>>> entwickelt...
>>> 95-96 rum. 3-4 Jahre vor deiner *Reimplementierung*.
>>
>> Ich habe erstens nichts re-implementiert, und zweitens kooperiert
>> besagtes Tool immer noch nicht mit anderen MMU-Hacks. Versuche mal sowas
>> parallel zu einem anderen "aktiven" MMU-Tool zu starten und Du merkst
>> den Unter- schied zwischen einem Design und einem Hack.
>>
>>>> Shapeshifter-Videotreibern?
>>
>>> Die liefen auch *vor* muforce.
>>
>> Aber nicht "mit" Enforcer.
> Mit CyberGuard sollte das aber kein Problem gewesen sein:-)
> Jedenfalls kein prinzipielles Designproblem.
Mit VMM oder ähnlichen "aktiven" Tools hingegen schon.
>>>> Momentan läuft hier schon mal MuForce, MuFastRom, MuProtectModules.
>>>> MuGa zum Debugging, MuEVD für die Mac-Emulation, wenn ich sie mal
>>>> anschalte. Auf der GVP lief noch MuFastZero.
>>
>>> Und ? 99% der Features funktionierten auch vor dem neuen API.
>>
>> Aber nicht miteinander und in beliebiger Kombination. Ich glaube,
>> entweder hast Du oder willst Du nicht verstehen, was das ganze soll.
>> "Alles, was ich nicht gemacht habe, taugt nichts".
>> Du bist noch armseliger, als ich dachte.
> Falsch...ich habe kein Problem damit anzunehmen, dass dein
> MMU API *brauchbar* ist und mit hoher Wahrscheinlichkeit
> besser ist, als das private und nicht "designte" 680x0.library API.
> Ich verstehe nur den Nutzen/Sinn *heute* nicht mehr.
Definiere den Nutzen eines Amigas. "Benutzen" tu' ich den sowieso nicht
mehr im üblichen Sinne. Vielleicht schreibe ich mal einen Brief darauf,
das ist es schon in punkto "ernsthaft benutzen". Ich arbeite auf einem PC,
und der Amiga ist in dem Sinne vollkommen nutzlos. Ja, und? Schmeiß' ich
die Kiste deswegen in die Ecke?
> Aber das ist *meine* Auffassung der Dinge. Wie ich schon
> mehrmals gesagt habe, reagiere ich hier nur auf diese
> "system inkompatibel" Geschichte.
Dann sollten wir obiges "nutzlos" doch besser beseite lassen.
>>>> Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis
>>>> 0xe000
>>>> 0000 für mein Privatvergnügen. Wer immer da reinschreibt oder ihn
>>>> belegt, hat verloren. (-; Hört sich nach einem lustigen Spiel an...
>>
>>> Tja...der Bereich ist jetzt auch weg mit der grex:-)
>>
>> Nö, er ist von mir soeben reserviert worden, und was andere machen,
>> inter- essiert mich nicht. Und was ich damit anstelle, ist meine Sache,
>> und Dokumente dazu verbreite ich nicht, und wer immer was damit anstellt
>> außer mir soll zur Hölle fahren, und supporten tu' ich das erst recht
>> nicht. P5-Logik.
> kommerzielle effizienz Logik.
Und Du meinst nicht, dass man sich damit irgendwann mal in's eigene
Bein schießt, weil etwa Produkte anderer Leute damit nicht zusammen-
arbeiten werden? Weil niemand dafür Software entwickeln kann, weil es
keine Dokumente dafür gibt?
> Das GRex ist eine Erweiterung des Cyberstorm/BlizzardPPC Produktes,
> dass schon eine notwendige MMU Steuerung beinhaltet.
> Glaubst du etwa ich/andere "lizensieren" sich von dir den mmulib
> source + 68k library src oder passen die eigene 68k library an fuer
> eine Flashnutzung im Jahre 2001, wenn die hinreichend notwendige
> Technologie schon existiert ?
Und Du meinst nicht, dass es eventuell sinnvoll wäre, eine mächtigere
API zu wählen, für die Tools nebst Sourcen nebst Doku existieren, eine
*offene* API, anstelle eines geschlossenen Designs? War da nicht mal
was von wegen "open system architecture" oder so?
Frage: Warum ist PCI so gut?
>>>> Ist Dir ein Begriff wie "Standardisierung" geläufig, und wozu das
>>>> dient?
>>>> (-:
>>
>>> Sicherlich...nur habe ich dir immer gesagt, dass seit Jahren kein neuer
>>> MMU Standard mehr *Sinn* macht,
>>
>> Offenbar immer noch genug Sinn für einige Leute. Weil *DU* nicht
>> verstehst, wozu das ganze sein soll, oder weil Du nicht willst, dass
>> jemand in *Deine Geniale Software* (tm) hineinsieht, blockierst Du hier.
> Die ist nicht genial..habe ich nie behauptet.
Also, wo liegt dann das Problem?
>>> weil es keine signifikant neue HW fuer 68k geben wird und die alten
>>> Tools neu implementiert werden muessen(Hast du ja offensichtlich
>>> gemacht) ohne einen signifikanten Mehrnutzen(ausser Sendungsbewusstsein
>>> fuer T.Richter) ergibt.
>>
>> Ich habe kein *Sendungsbewusstsein*. Ich habe nur genug von den
>> "Designideen" eines gewissen Herrn. Ich habe das Zeug, wie ich schon
>> mehrmals gesagt hatte, implementiert, weil ich es für eine interessante
>> Aufgabe hielt. Klar, sowas verstehst Du nicht. Dass ich es nicht
>> verkaufen kann, war mir sowieso schon klar.
> Es gibt doch ueberhaupt kein Design...also habe ich auch keine Ideen
> zu diesem haben koennen.
Ok, wenn man's halt so sagen will...
>>> Was *mir* nicht egal ist sind solche Sachen wie "Nicht Systemkonform".
>>
>> Was es nicht ist - den Beweis bleibst Du immer noch schuldig. "Ich
>> definiere als Konform" halte ich für keinen Beweis.
> Ich habe dir zum Thema configdev nodes wohl genug gesagt.
Ja, ein CPU-Board ist kein Zorro, darum tu' ich, was ich will.
Gut, logisch haltbar. Verquere Logik die Probleme bei Konfiguration
und Kooperation zu genüge erzeugt, aber bitte.
Den Beweis, dass jemand den F-Space oder andere PPC-belegte Address-
räume einmal freigegeben hat, bleibst Du mir schuldig? Oder willst
Du weiter behaupten "ich definiere das als richtig und somit ist
es richtig". Literatur habe ich angeführt?
>>> Ich supporte keine 3rd party HW AmigaOS Ansteuerung, weil ich auf die
>>> korrekte Funktion *meiner* Definition angewiesen bin beim User.
>>
>> *Deiner* *Top Secret* Definition von Usern, die Du nicht mehr supporten
>> willst? Du widersprichst Dir in Deiner seltsamen Logik doch nur selbst.
> Wer sagt denn, dass ich diese nicht mehr supporte ?
Du? Etwa beim cyberscsi-Problemen?
>> Entweder Du machst nichts mehr, dann darf Dir der Zirkus auch egal sein,
>> oder Du machst noch was, und dann solltest Du an weiteren Entwicklungen
>> auch interessiert sein. Aber einerseits zu behaupten, Du hättest
>> Interesse an der "korrekten Funktion Deiner Hardware" und andererseits
>> zu behaupten
>> "das hätte doch alles keinen Sinn mehr" ist ein Widerspruch in sich.
> Falsch.
> o Ich habe interesse, dass die flash,ppc.library,scsi korrekt funktioniert,
> was nur mit der existierenden MMU Loesung *fuer mich* garantiert
> ist.
> o Ich habe Interesse, dass das grex produkt korrekt bzgl. MMU
> Nutzung funktioniert.
> o Ich habe Interesse, dass der MorphOS startup korrekt funktioniert.
Inwieweit ändert das etwas an meinen Feststellungen zu den 68ks? Wird Morphos
auf einer 2060 oder einer MK-II laufen? Hast Du noch Interesse daran, diese
zu supporten? Wenn nein, so sehe ich den Grund nicht, warum Du hier soviel
Worte machst und nicht einfach sagst, was hier vor sich geht. Wenn ja, warum
behebst Du nicht mal ein paar kleine Probleme von cyberscsi oder hilfst, damit
auch Drittparteien etwas vom Support haben?
>> Ich glaube, das wirkliche Problem liegt da ganz woanders... ...und es
>> ist alles so wunderbar durchsichtig und für jederman offensichtlich.
> Wirklich ?:-)
> Du meinst, weil du etwas geschaffen hast was besser ist als was ich
> mal vor 7 Jahren programmiert habe, dass ich "neidisch" bin ?
> Das ist *nicht* der Fall.
Du verhältst Dich aber ziemlich genau so... Etwa "das braucht doch
eh' keiner" und "das ist doch eh' alles abgekupfert".
> Ich habe eine *Meinung* zu dem Sinn der Aktion im Kontext der
> *Marktsituation*, aber das sei doch dir ueberlassen was du machst.
> Ich blockiere dich doch in keinster Weise *aktiv*. Ich habe kein
> Problem damit wenn irgendwer die 680x0 libraries aus dem System
> auf *eigene* Gefahr entfernt.
> (Ich habe mich in *keinster* Weise bei Frank Wille zu seinem utility
> geaeussert und habe auch kein persoehnliches Problem mit ihm
> bzgl. seiner ppclib Emulation)
Nicht? Nun, ich habe andere Geschichten von Frank gehört, Gerüchte,
natürlich...
> Du solltest echt keine Annahmen bzgl. meiner Motivation machen,
> weil die nicht so einfach schwarz&weiss funktioniert wie du es
> wohl glaubst.
Ok, also, was ist Deine Motivation, fragen wir doch einmal um das
zu klären.
>> Meine Regeln sind, dass ich mich daran halte, was dokumentiert ist. Ich
>> habe null Dokumentation von Dir. Ich habe massig Dokumente von Mike
>> bzgl.
>> 68040-Lib, die er für CBM entwickelt hat.
>> Es steht Dir immer noch frei, das zu ändern.
> Ich habe doch gesagt, dass ich kein Interesse daran habe, weil ich noch
> Interesse an der *SW* habe. M.Sinz hat dieses nicht.
Und oben sagst Du mir, Du hättest kein Interesse an den 68K-Kisten?
Wie geht das nun zusammen?
>>> Das ist aber die *Realitaet* seit den ersten 68030 boards bis zu den
>>> 060 Boards gewesen. Was du hier gerne haettest ist eine *Utopie*.
>>
>> Interessant, eine lauffähige Utopie. (-:
> Ich will doch nicht abstreiten das es laeuft.
Wie ich sagte, ich habe jedenfalls mit *keiner anderen* Karte irgend-
welche Probleme.
>> Stattdessen steckst Du, statt das Zeug an einem Nachmittag mal
>> auszugraben,
>> (Aufwand null, Nutzen imens), Deine Zeit lieber in immer die gleiche
>> Argumentation. Ich sage Dir auf die Nase zu, dass das absolut nichts mit
>> Nutzen oder Aufwand oder sonst was zu tun hat, und dass Du hier
>> angebliche Argumente vorschiebst.
> Falsch. Ich habe noch ein aktives Interesse daran und zweitens wuerde
> ich dir sowieso nichts dokumentieren nach diversen *persoehnlichen*
> Aktionen deinerseits.
"..sowieso nichts..." natürlich auch beim damals erfolgten "ersten Kontakt".
>> Optimiere den Nutzen, verhindere den Aufwand, schicke mir das Zeug zu.
>> Fertig.
> Noe.
Danke, das wollte ich nur wissen. Ein weiteres Indiz für meine Beweis-
führung.
>>> Es geht nicht darum, dass ein globales MMU API nuetzlich ist. Sondern
>>> darum, dass es *heute* unsinnig ist, da es keinen signifikanten
>>> Mehrwert fuer Entwickler(welche?) gibt.
>>
>> Welchen "effektiven Nutzen" hat heute ein PPC-Board? Keinen? Warum
>> machst Du das? Du bist schon wieder dabei, irgendwelche Unsinnsargumente
>> vorzu- schieben. Es geht doch im Grunde gar nicht darum, habe ich recht?
> Fuer mich hat MorphOS einen kommerziellen und idiellen Zweck.
> Die PowerHW wird auch noch kommerziell verwertet.
Und ich rede über 68K-Hardware.
> Wenn ich kein Interesse mehr gehabt haette und du mir nicht
> diverse Male ueber den Fuss gelaufen waerst, haette ich dir
> eventuell die Sourcen gegeben.
Ich habe damals gefragt, und durchaus nicht unhöflich. Jetzt kommen
Argumente wie "ich hätte ja im Prinzip, wenn nicht..". Hast Du aber
nicht, und auch damals nicht. Bitte, Ralph, keine Märchenstunde. Tu
es einfach, und es ist Ruhe.
>> Es geht darum, dass *Du* recht haben willst, und dass Du nur zu gerne
>> das Ekel spielst. Das hingegen gelingt Dir ganz ausgezeichnet.
> Inwiefern spiele ich das Ekel ?:-)
> Ich beleidige dich nicht, ich sage nichts zur Qualitaet deiner
> Programme. Ziehe nicht ueber dich her in diversen Medien.
> Verteile nicht Inhalte von privaten EMails and dritt Personen.
> Das einzige was ich dir sage ist...*nein*.
"Nutzlos" und "wer braucht das schon". Naja, wie man's nimmt.
>>> Desweiteren wurden auch diverse 3rd party Gfxboards auch mittels
>>> speziellem Mapping supportet. Das Feature wurde ja dann spaeter auch
>>> von Nils in P96 implementiert, fuer Villagetronic Produkte.
>>
>> Die Picasso-IV hat zwar ein dynamisches Mapping, aber die MMU-Verwaltung
>> für diese Karte ist statisch und bedarf keiner besonderen Tricks. Die
>> meldet sich schon korrekt an. Dass man hier optimieren kann, ist eine
>> andere Sache.
> Es ging um die "optimierung bzgl nonguard".
Ist auf "Mu" umgestellt, übrigens schon eine ganze Weile. Notwendig ist
es sicher nicht.
>>>>> Warum musst *du* den denn mappen. Das ist Sache des Herstellers. Das
>>>>> ist doch das was *du* nicht realisieren willst.
>>>>
>>>> Weil diese Auffassung Nebenwirkungen hat und Interoperabilität auf
>>>> diese Weise nicht zu gewährleisten ist?
>>
>>> komisch...es gab auch eine zeit *vor* der mmu.library.
>>
>> Ach, sag' bloß? Und, konnte ich MMU-Hacks sicher parallel laufen lassen?
> Ich habe keine anderen MMU hacks benutzt. Dementsprechend hatte
> ich keine Probleme:-)
Sicher, glaub' ich Dir. (-:
>>> Ich argumentiere zurueck nach der netten aussage wie
>>> "nicht systemkonform".
>>
>> Ich frage auch nicht zum ersten Mal. Ich habe Deine Spielchen nur so
>> satt, weil man im Grunde genommen genau weiß, worum es geht. Mit
>> "standardkonform" oder nicht hat es schon lang' nichts mehr zu tun.
> Mich hat diese Aussage "veraergert", weil ich sie als persoehnlichen
> Angriff werte, von denen du ja schon diverse gemacht hast.
Das trifft sich gut, da ich diverse Aussagen von Dir auch als Angriff
werte... ...von denen ich ja auch schon diverse gehört habe.
>>> Ich kenne keins deiner Programme als *Nutzer* naeher um solche
>>> Ueberlegungen zu treffen.
>>
>> Nein, stattdessen formulierst Du lieber Unterstellungen, ist schon klar.
>> Macht sich ja auch einfacher. Ich befürchte fast, das war ein Schuss in
>> den Ofen.
> Was denn fuer "Unterstellungen" ?
"Absichtlich wegoptimiert um zwei Bytes zu sparen" waren wohl Deine Worte?
Nunja, lassen wir das. Im Eifer des Gefechts vergreift man sich schonmal.
> Irgendwie habe ich den Eindruck, dass du was in meinen Aussagen
> reininterpretierst was ich niemals gesagt oder gemeint habe.
Siehe oben, so emfindlich bin ich nicht, also Schwamm' drüber.
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> >> Ich sehe auch keine Anmeldung fuer pcmcia, ide und andere
> >> *Commodore* local HW in der configdev list.
> >
> > "Quod licet Iovi, non licet bovi". (-: CBM hat dokumentiert, wo ihre
> > Hardware liegt, wie man feststellt, ob sie vorhanden ist, und wie man
> > sie zu mappen hat. P5 ist nicht der Hersteller des Systems, sondern
> > 3rd-Party, und hat nichts dergleichen dokumentiert.
>
> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis
> gesichert hat und mit ihren Entwicklungen Standards gesetzt
> hat(CGFX).
Das hat keinen Bezug auf die von dir kommentierte Textpassage.
--
PIK
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> > Entwicklung. Egal ob es jetzt um 5KB - wohl halt peinlicher -
>
> 5kb ?
Ehh... ich dachte du wirst eher das "peinlicher" beanstanden. |-)
> > Dokumentation fuer die Phase5 HW oder um Weiterentwicklung von SFS
> > geht.
>
> Ich blockiere keine SFS Weiterentwicklung...
Dann schick mir mal die 1.84 sources. Du machst deine PowerPC
MorphOS Version und 'wir' die 68k AmigaOS Version. Oder stoert
dich da etwas dran?
--
PIK
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Ich glaube, das wirkliche Problem liegt da ganz woanders... ...und es
> ist alles so wunderbar durchsichtig und für jederman offensichtlich.
Bingo! :-))
--
PIK
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
> Hi Ralph,
>
>
>>>> Das hat nichts mit PPC Emulation zu tun.
>>>
>>> Dann argumentiere nicht damit.
>
>> Tue ich doch gar nicht(Du hast das gemacht).
>
> Bitte lies' oben noch einmal, was genau Du geschrieben hattest.
>
Sigh..du hast "PPC Emulation" geschrieben..darauf habe ich
geantwortet...es hat nichts mit PPC Emulation zu tun. q.e.d
Das bezieht sich auf die Zeit zwischen 68k Reset und
Zugriff auf das Motherboard chipset und Initialisierungssequenz dieser
HW.
Das wurde *nie* dokumentiert.
>> Das bezieht sich auf die Amiga System HW.
>
> Wenn ich eine PPC-Emulation der 68K-Seite fahre, warum interessiert mich
> dann, ob ich Bankswitching auf einer (dann zu emulierenden) Karte mache?
> Ich würde natürlich eine Karte emulieren, die keine derartige Hardware
> benötigt, bzw. den betreffenden Teil von Exec neu schreiben.
>
Gnar..das hat nichts mit ppc und emulation zu tun.
Wenn irgendeine HW Resetet wird dann muss man sich
meistens an bestimmte initialisierungs/timing spielregeln halten.
>
> Und Interesse bezüglich zukünftiger Entwicklungen und einer gewissen
> "Defensivität" des Designs - wollen wir das mal so ausdrücken - waren
> nicht vorhanden?
>
Da das API privat war gibt es keine "Defensivitaets" Problem, da man
es neueren Beduerfnissen anpassen kann.
Eigentlich die defensivste Einstellung ueberhaupt. Nichts als
oeffentliches API dokumentieren, was nicht dafuer geeignet ist.
>>> Entspricht der Realität bis auf Karten eines gewissen Herstellers, der
>>> nicht genügend Bedacht bei der Konstruktion ihrer Hardware angewandt
>>> hat. Alles schön und gut, das könnte man ja verkraften, wenn man
>>> wüsste, wie das funktioniert.
>
>> Das stimmt doch einfach nicht. Ich habe dir genug Beispiele von Firmen
>> gegebenen, die fuer ihr Produkt ein eigenes MMU setup mitlieferten, da
>> ohne dieses ihr Board mit AmigaOS nicht funktioniert haette.
>> *Genau* das gleiche mit Phase5.
>
> Zumindest kann ich Dir versichern, dass ich von keinen Problemen mit
> Boards anderer Hersteller weiß. Ok, das muss natürlich nichts heißen,
> aber etwas komisch ist es doch schon, dass ich nur mit einer Sorte
> Boards Probleme hatte, und sonst nichts.
>
Hurricane2800 brauchte spezifische MMU Setups. Die Leute mit den
ersten A3000 040 Karten wie Mercury brauchten das auch.
>> Ich sehe das eher unter dem Aspekt, dass CBM es nicht dokumentieren
>> wollte aus Konkurrenz Situation bzgl. 3rd Party Unternehmen. Jeder in
>> dem Bereich hat das "Rad" neu erfinden muessen fuer ihre spezielle HW.
>
> Du weißt doch auch, dass das nicht stimmt. Meine GVP-040 läuft auch mit
> der Mike-Sinz 68040.library (v37). Nicht sonderlich gut, da die Lib
> genug Macken hat - allerdings nichts MMU relevantes, sondern eher
> betreffs der FPU-Emulation. Die Karte war derart gebaut, dass ein
> solches Problem eben nicht auftritt, alle Erweiterungen werden
> angemeldet und werden demnach korrekt gemappt.
>
Schau dir die Karten davor an und die 060 Karten.
>
> Moment mal, hier stimmt schon wieder etwas nicht... Unten erzählst Du
> was von wegen "neue Hardware"(GRexx), hier sagst Du "es gibt keine
> signifikante neue Hardware". Kann oder kann ich nicht diese Hardware
> mit einem Amiga, der nunmal mit einem 68k läuft, betreiben? Oder merkt
> der
> 68K davon über- haupt gar nichts? Im letzteren Fall wäre mir das recht
> gleich.
>
Es gibt keine neuen cpu boards von xyz Entwicklern. Die Leute die
noch was machen haben ihre eigene Loesung.
> Darf ich daraus schließen, dass Du diese Hardware für "nicht
> signifikant" und nicht "wert einer Überlegung bezüglich eines
> konservativeren Designs" hältst?
>
Sie beruht auf existierenden Technologien.
Als signifikant wuerde ich neue 68k cpu boards erachten.
>> Hast du es *jetzt* realisiert ?
>
> Schön, dass Dir die ganze 68K-Schiene egal ist - habe ich ja verstanden.
> Und weil *Dir* die 68Ks egal sind, dürfen sie auch allen anderen gleich
> sein?
>
Was dir gleich ist, ist deine Sache.
>>> Weil es nicht systemkonform ist, weil es keine anderslautenden
>>> Dokumente gibt. Dem Punkt könntest Du abhelfen, weigerst Dich aber
>>> beharrlich.
>
>> Also wenn ich dir sage wie das Mapping ist, ist es ploetzlich
>> "systemkonform" ?
>
> Es würde einem System folgen, ich wüsste was zu tun wäre, und Ruhe wäre.
> Ich hätte genug Grund, Dir zu danken.
>
>>>>> Aha, die 68040.library von CBM war also 3rd-Party, gelle?
>>>> Nein.
>>> Danke. Mehr wollte ich nicht wissen.
>> Und was ziehst du wieder fuer Schluesse ?
>
> Dass es offenbar bei CBM damals durchaus ein Design für MMUs gab, dies
> aber nicht oder nicht mehr von CBM dokumentiert wurde und erst
> nachträglich von einem ehemaligen Entwickler zusammengetragen wurde?
>
Prinzipiell hat die CBM 68040.library ueberhaupt kein sogenanntes Design.
>
>>>>>> Apropo P5 hat auch die MMU Nutzung ihres Systems immer oeffentlich
>>>>>> dokumentiert.
>
>>>>> Wo, wann?
>
>>> Ich wiederhole diese Frage.
>
>> Ich habe es dir und mehrmals auf .programmers gepostet.
>
> Nun, ich verstehe ja nicht, was Du unter "öffentlicher Dokumentation"
> verstanden haben willst. Ein "tu doch was Du willst" halte ich
> jedenfalls nicht dafür. Unter "öffentlicher Dokumentation" hätte ich
> eher etwas wie die "Autodocs" für eine 68040-Library verstanden, nebst
> Anhang bzgl. deren MMU Belegungen. Ziemlich genau etwas der
> Größenordnung, was ich von Mike bekommen habe - vielleicht nicht so gut
> poliert.
>
Und ich sehe diese Information als nicht nuetzlich fuer mich an.
>> Die common MMU Tree Nutzung seit der 68040.library.
>> "Man kann auf eigene Gefahr alles im MMU Tree anstellen,
>> so lange man die Kontrolle nicht uebernimmt. Das funktioniert mit
>> jeder HW, wenn man *weiss* was man tut."
>
> *Seufz* Und das ist eine Dokumentation?
>
Das ist genau die Dokumentation/Schilderung des seit Jahren benutzten
MMU Zugriffs aller moeglichen Leute. Der kleinste gemeinsame Nenner.
>>>> Genau...als waere es anders mit irgendeinem anderen MMU Interface
>>>> heute an das sich sowieso keiner ausser du dran haelt.
>>>
>>> Auch nachweislich nicht korrekt...
>
>> Was ist nachweisslich nicht korrekt ? Welche CPU Board Firma haelt sich
>> denn an die MMU Library Definition ?
>
> Ich rede nicht von Firmen. Seit wann arbeitet noch eine Firma an Amiga-
> Hardware?
>
An neuer 68060 cpuboard HW sicherlich nicht...das ist ja auch der punkt
>>>> Deswegen war seit der 68040.library *immer* der gemeinsame Nenner,
>>>> dass man auf *eigene* Gefahr im MMU Tree werkelt.
>>>
>>> Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist
>>> kein Design.
>
>> Es wird keine Zeit mehr dafuer, weil der Zug abgefahren ist. Die Zeit
>> war 1994.
>
> Na schön, niemand kann ersthaft noch Amiga-Hardware erwarten. Warum
> bedeutet dies, dass niemand mehr damit arbeiten darf, und daran arbeiten
> darf? Warum muss Deine Meinung hier ausschlaggebend sein?
>
Diese Meinung ist auschlaggebend fuer *mich*. Ob sie andere teilen ist
ihnen ueberlassen.
>>>>> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>>>
>>>> Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme
>>>> loesst und von jedem unterstuetzt wird.
>>>
>>> Ich behaupte nicht, Weltprobleme zu lösen. Ich behaupte, für ein paar
>>> MMU-spezifische Probleme eine brauchbare API definiert und benutzt zu
>>> haben, und dass, obwohl Du weiterhin versuchst, mir Steine vor die
>>> Beine zu werfen.
>
>> Ich werfe dir doch keine Steine in den Weg...du hast dir halt einen
>> *steinigen* Weg *ausgesucht*. Ich mache einfach nur *gar nichts*
>
> Ja, eben. Stattdessen wird man bei - so finde ich berechtigten -
> Anfragen angemault.
>
>> und fuer das *gar nichts* machen, bekomme ich dann nette "Huldigungen"
>> in speziellen Docs, als haettest du ein Recht darauf, dass ich dich
>> unterstuetze.
>
> Ich beklage mich über meineserachtens fehldesignte Hardware und ein
> Übermaß an Hacks, das nicht hätte sein müssen. Das fängt bei
> Kleinigkeiten
> wie der F-Space-Belegung an und hört bei Seltsamkeiten wie residenten
> 680x0-Bibliotheken auf. Das das alles funktioniert, ist klar. Nur, darum
> geht es nicht vordringlich. Dinge sind auf eine derart unvorsichtige und
> - teilweise sogar so möchte ich sagen "töpelhafte" - Weise
> zusammengesteckt, dass mir das Grausen kommt. "Damals" war schon klar,
> dass es eventuell auch andere Wünsche seitens PPC-Benutzung der User
> gab. Damals gab es schon "VMM", und dennoch wurden die Call-Outs der
Ich halte von generellen/app sensitiven VMMs im Amiga Kontextes nichts
und ich konnte es auch nie bei mir zum Leben erwecken.
> 68060-Lib entfernt (-> man denke etwa an fsin.x (a0) mit a0 "swapped
> out"). Damals gab es schon Wünsche nach alternativen CPU-Bibliotheken
> oder alternativen Graphikbibliotheken. Nein, hatte der User einmal P5,
> so musste er dabei bleiben - das fing bei der
Die Optimierung der mathe bibiliotheken war ein Auftrag fuer die V43,
weil Phase5 dachte, dass schnellere FPU Emulation einen hoeheren
Wert hat als ein "theoretischer" Support von VM, dass sowieso nie
stabil aus System imminenten Gruenden lief.
Und wenn du hier schon von Hacks/System Konform redest, dann
solltest du wirklich nicht mit VM argumentieren.
> 68060.library an und hört bei CGFx auf, die sich auf irgendwelche
Warum sollte sich Phase5 fuer den Support von Konkurrenz Graphik-
bibliotheken in irgendeiner weise interessieren. Reichlich naiv:-)
> Internals der CPU-Library verlassen muss, weil Autokonfig nicht "die
> Wahl" war, aus welchen Gründen auch immer. Dokumentation dazu gab es
> nicht, an existierende APIs, die man durchaus hätte benutzen können, zum
> Teil mit einem *Minimum* an Mehraufwand hat man sich nicht gehalten. Und
> darüber soll ich in Jubeln ausbrechen?
>
Nimm es hin wie ein Mann:-)
>>>>> Die gehen nicht mehr in die 68040-Geschichte hinein. Insofern *muss*
>>>>> ich mich hier nach Angaben von Produktentwicklern richten, die für
>>>>> CBM
>>>>> gearbeitet haben. Wie gesagt, Deine Wünsche hätte ich auch gerne
>>>>> berücksichtigt - ich habe gefragt. Wenn Du mit "Rutsch mir den
>>>>> Buckel runter" konterst...
>>>
>>>> Wie es in den Wald reinschallt, schallt es herraus.
>>>
>>> Und dann werden noch Lügen verbreitet, wie es Dir passt. Wirklich
>>> nett...
>>>
>
>> Welche Luegen denn ?
>
> Etwa wie oben, dass ich mir jetzt vorwerfen lassen muss, nicht
> freundlich genug gefragt zu haben. Etienne hatte Dich damals - und das
> muss ich zugeben - angep**. Einiges war damals sehr schief und sehr zu
> meiner Enttäuschung danebengelaufen.
>
Ich habe dir nur gesagt, dass ich es als sinnlos erachte und dir ein
klares nein gegegeben. Das ganze lief auch noch in der H&P Phase
ab.
>>> Herr Schmidt, ich hatte damals höflich angefragt, und mir den Ton von
>>> Etienne Voigt - falls Du Dich noch entsinnen kannst - verbitten
>>> lassen.
>>>
>>> *DU* warst derjenige, der nur herumgemault hat.
>
>> Wie z.b. "nette Kommentare in den Docs"
>
> Was ja wohl einige Monate später erst erfolgte? Bitte, bleiben wir doch
> bei der Kausalität.
>
Und ? Ich kann mit "nein" umgehen. Du musstest nachkarten.
>> obwohl ich dir nichts getan hatte ausser das ich gesagt habe, dass ich
>> keinen Sinn in deiner Taetigkeit gesehen habe. Das fuehrte dann dazu,
>> dass du EMail Inhalte an PIK weitergeleitet hast und dementsprechend
>> ging das dann in diesem Medium alle paar Monate weiter.
>
> Das war zu dem "mal wieder ein Problem" im cyberscsi und Co, wo Du
> ziemlich unvorsichtig vorgegangen bist, und ich dann noch eine Antwort
> von wegen
> "lass' mich in Frienden" bekommen habe. Übrigens nicht das einzige
> Problem
> vom cyberscsi, leider.
>
Ich habe dir auch gesagt, dass ich seit der 8.0 in keinster Weise mehr
dafuer zustaendig war.
>>> Interessanterweise waren Anfragen an andere Leute, wie etwa Mike Sinz,
>>> da sehr viel erfolgreicher.
>
>> Ist doch ok, wenn er dir das alles dokumentiert, was er mal gemacht
>> hat. Schoene Geste. Nur hat er aber kein Interesse mehr an Amiga SW/HW,
>> im Gegensatz zu mir.
>
> Und *weil* Du Interesse hast, behälst Du Informationen vor und
> blockierst deshalb?
>
Wie ich dir schon sagte...alles was mit BlizzardPPC/CyberstormPPC/MK3
zu tun hat ist von Interesse fuer mich.
>>> Wie kommt das wohl, dass man von Dir bestenfalls vollgemault wird,
>>> aber keine Antworten bekommt?
>
>> Wie kommt das nur, wenn man "nein" sagt und mehr nicht, dass das dann
>> zu netten Kommentaren fuehrt und oeffentlichen Schlammschlacht seitens
>> PIK und dir(ist nicht systemkompatibel).
>
> Erstens, ich habe mit Ralphael nichts zu tun. Was er macht ist sein
> Bier, und der Ton ist durchweg daneben. Haben wir das klargestellt?
>
> Zweitens: Zu besagten Schlammschlachten hast Du immer wieder Anlass
> gegeben durch gekonnt miss-launige Reaktionen auf durchweg höflich
> gemeinte Anfragen.
>
>> Auf der 3.5 Mailingliste gab es dann auch aehnliches.
>
> Weil ich mal wieder ein Problem mit dem cybscsi und Co hatte von wegen
> der schlauen Idee "ich mounte und blockiere Filing-Systeme selbst". Es
> ist einer der Punkte, an denen man merkt, dass der Autor offenbar nicht
> gründlich nachgedacht hatte, oder nicht gründlich getestet hatte, oder
> beides. Bei Dir deswegen anzufragen... sein wir mal ehrlich, was wäre
> das Resultat gewesen?
>
Ich weiss nicht was du meinst. Ich bezog mich auf eine EMail bzgl.
dem 0x10000 Problem einigen "netten" Kommentaren dort auf der 3.5 ML,
die mir zugetragen wurden.
>>>>> "Cyberguard" Ausgaben der irrtümlich geschriebenen Daten auf einem
>>>>> 68060?
>>>>> Bietet P5 "Cyberguard" ein funktioniertendes und kooperierendes
>>>>> Debugging- Tool a la "Guardian Angel"? Funktioniert das zusammen mit
>>>
>>>> Guardian Angel Remix wurde von Bjorge mittels Cyberguard sourcen
>>>> entwickelt...
>>>> 95-96 rum. 3-4 Jahre vor deiner *Reimplementierung*.
>>>
>>> Ich habe erstens nichts re-implementiert, und zweitens kooperiert
>>> besagtes Tool immer noch nicht mit anderen MMU-Hacks. Versuche mal
>>> sowas parallel zu einem anderen "aktiven" MMU-Tool zu starten und Du
>>> merkst den Unter- schied zwischen einem Design und einem Hack.
>>>
>>>>> Shapeshifter-Videotreibern?
>>>
>>>> Die liefen auch *vor* muforce.
>>>
>>> Aber nicht "mit" Enforcer.
>
>> Mit CyberGuard sollte das aber kein Problem gewesen sein:-) Jedenfalls
>> kein prinzipielles Designproblem.
>
> Mit VMM oder ähnlichen "aktiven" Tools hingegen schon.
>
Ich wuesste kein prinizipielles Problem mit CyberGuard...ein VM hat
nichts mit der zeropage zu tun, kann den buserror overloaden und sich
in eine existierende mmu map einblenden.
>>>>> Aha. Ich reserviere mir jetzt den Speicherbereich 0xa000 0000 bis
>>>>> 0xe000
>>>>> 0000 für mein Privatvergnügen. Wer immer da reinschreibt oder ihn
>>>>> belegt, hat verloren. (-; Hört sich nach einem lustigen Spiel an...
>>>
>>>> Tja...der Bereich ist jetzt auch weg mit der grex:-)
>>>
>>> Nö, er ist von mir soeben reserviert worden, und was andere machen,
>>> inter- essiert mich nicht. Und was ich damit anstelle, ist meine
>>> Sache, und Dokumente dazu verbreite ich nicht, und wer immer was damit
>>> anstellt außer mir soll zur Hölle fahren, und supporten tu' ich das
>>> erst recht nicht. P5-Logik.
>
>> kommerzielle effizienz Logik.
>
> Und Du meinst nicht, dass man sich damit irgendwann mal in's eigene
> Bein schießt, weil etwa Produkte anderer Leute damit nicht zusammen-
> arbeiten werden? Weil niemand dafür Software entwickeln kann, weil es
> keine Dokumente dafür gibt?
>
Userland Produkte arbeiten damit. Entsprechende Devtools, die das
wichtigste abdecken existieren auch seit Jahren.
>> Das GRex ist eine Erweiterung des Cyberstorm/BlizzardPPC Produktes,
>> dass schon eine notwendige MMU Steuerung beinhaltet.
>
>> Glaubst du etwa ich/andere "lizensieren" sich von dir den mmulib source
>> + 68k library src oder passen die eigene 68k library an fuer eine
>> Flashnutzung im Jahre 2001, wenn die hinreichend notwendige Technologie
>> schon existiert ?
>
> Und Du meinst nicht, dass es eventuell sinnvoll wäre, eine mächtigere
> API zu wählen, für die Tools nebst Sourcen nebst Doku existieren, eine
> *offene* API, anstelle eines geschlossenen Designs? War da nicht mal
> was von wegen "open system architecture" oder so?
>
Weil ich dieses open MMU API nicht als wichtig und notwendig erachte.
> Frage: Warum ist PCI so gut?
>
Es geht hier nicht darum warum PCI gut oder schlecht ist.
Der F-Space ist aus allen mir bekannten Information immer fuer das CPU
Board spezifiziert worden. CBM hatte da wohl dann ihre Debugkarte.
Es existierte ein definiertes Module Slot und ResidentScan Protokoll
fuer den Bereich, dass dir auch bekannt ist.
Der F-Space war *nie* fuer die 1MB Kickstart roms gedacht wie so
viele Leute vermutet hatten...das war 0xe00000-0xe80000.
>>>> Ich supporte keine 3rd party HW AmigaOS Ansteuerung, weil ich auf die
>>>> korrekte Funktion *meiner* Definition angewiesen bin beim User.
>>>
>>> *Deiner* *Top Secret* Definition von Usern, die Du nicht mehr
>>> supporten
>>> willst? Du widersprichst Dir in Deiner seltsamen Logik doch nur
>>> selbst.
>
>> Wer sagt denn, dass ich diese nicht mehr supporte ?
>
> Du? Etwa beim cyberscsi-Problemen?
>
Ich beziehe mich nur auf Produkte von 97(CyberstormPPC usw)
>>> Entweder Du machst nichts mehr, dann darf Dir der Zirkus auch egal
>>> sein, oder Du machst noch was, und dann solltest Du an weiteren
>>> Entwicklungen auch interessiert sein. Aber einerseits zu behaupten, Du
>>> hättest Interesse an der "korrekten Funktion Deiner Hardware" und
>>> andererseits zu behaupten
>>> "das hätte doch alles keinen Sinn mehr" ist ein Widerspruch in sich.
>
>> Falsch.
>> o Ich habe interesse, dass die flash,ppc.library,scsi korrekt
>> funktioniert,
>> was nur mit der existierenden MMU Loesung *fuer mich* garantiert
>> ist.
>> o Ich habe Interesse, dass das grex produkt korrekt bzgl. MMU
>> Nutzung funktioniert.
>> o Ich habe Interesse, dass der MorphOS startup korrekt funktioniert.
>
> Inwieweit ändert das etwas an meinen Feststellungen zu den 68ks? Wird
> Morphos auf einer 2060 oder einer MK-II laufen? Hast Du noch Interesse
> daran, diese zu supporten? Wenn nein, so sehe ich den Grund nicht,
warum
Da habe ich keine Interesse dran.
> Du hier soviel Worte machst und nicht einfach sagst, was hier vor sich
> geht. Wenn ja, warum behebst Du nicht mal ein paar kleine Probleme von
was soll da vorgehen ?..diese Produkte haben keine spezielle HW.
> cyberscsi oder hilfst, damit auch Drittparteien etwas vom Support haben?
>
ich kann da sowieso nichts mehr "beheben", weil ich seit 4 jahren keine
funktionsfaehige MK2 habe und ich auch nichts am flash rumspiele, weil
das schon mal schiefgelaufen ist bei einem privat durchgesickertem
internem MK2 "update".
Das Risiko, dass sich irgendwer seine alte HW wegen so einem update
das Flash zerschiesst ist aus meiner Sicht nicht tragbar.
>>> Ich glaube, das wirkliche Problem liegt da ganz woanders... ...und es
>>> ist alles so wunderbar durchsichtig und für jederman offensichtlich.
>
>> Wirklich ?:-) Du meinst, weil du etwas geschaffen hast was besser ist
>> als was ich mal vor 7 Jahren programmiert habe, dass ich "neidisch" bin
>> ? Das ist *nicht* der Fall.
>
> Du verhältst Dich aber ziemlich genau so... Etwa "das braucht doch eh'
> keiner" und "das ist doch eh' alles abgekupfert".
>
Die Funktionalitaet ist doch wohl eine Reimplementation von diversen
Programmen.
>> Ich habe eine *Meinung* zu dem Sinn der Aktion im Kontext der
>> *Marktsituation*, aber das sei doch dir ueberlassen was du machst.
>> Ich blockiere dich doch in keinster Weise *aktiv*. Ich habe kein
>> Problem damit wenn irgendwer die 680x0 libraries aus dem System auf
>> *eigene* Gefahr entfernt.
>> (Ich habe mich in *keinster* Weise bei Frank Wille zu seinem utility
>> geaeussert und habe auch kein persoehnliches Problem mit ihm bzgl.
>> seiner ppclib Emulation)
>
> Nicht? Nun, ich habe andere Geschichten von Frank gehört, Gerüchte,
> natürlich...
>
Echt ?..Wuerde mich ueberraschen. Ich habe mich jedenfalls keinmal
ueber ihn oeffentlich geaeussert.
>> Du solltest echt keine Annahmen bzgl. meiner Motivation machen, weil
>> die nicht so einfach schwarz&weiss funktioniert wie du es wohl glaubst.
>
> Ok, also, was ist Deine Motivation, fragen wir doch einmal um das zu
> klären.
>
Die sollte wohl klar sein....
>>> Meine Regeln sind, dass ich mich daran halte, was dokumentiert ist.
>>> Ich habe null Dokumentation von Dir. Ich habe massig Dokumente von
>>> Mike bzgl.
>>> 68040-Lib, die er für CBM entwickelt hat.
>>> Es steht Dir immer noch frei, das zu ändern.
>
>> Ich habe doch gesagt, dass ich kein Interesse daran habe, weil ich noch
>> Interesse an der *SW* habe. M.Sinz hat dieses nicht.
>
> Und oben sagst Du mir, Du hättest kein Interesse an den 68K-Kisten? Wie
> geht das nun zusammen?
>
Ich rede hier ueber die letzte Phase5 HW Generation.
>>>> Es geht nicht darum, dass ein globales MMU API nuetzlich ist. Sondern
>>>> darum, dass es *heute* unsinnig ist, da es keinen signifikanten
>>>> Mehrwert fuer Entwickler(welche?) gibt.
>>>
>>> Welchen "effektiven Nutzen" hat heute ein PPC-Board? Keinen? Warum
>>> machst Du das? Du bist schon wieder dabei, irgendwelche
>>> Unsinnsargumente vorzu- schieben. Es geht doch im Grunde gar nicht
>>> darum, habe ich recht?
>
>> Fuer mich hat MorphOS einen kommerziellen und idiellen Zweck. Die
>> PowerHW wird auch noch kommerziell verwertet.
>
> Und ich rede über 68K-Hardware.
>
Und was hat die mit unbekannten mappings zu tun ?
>>> Es geht darum, dass *Du* recht haben willst, und dass Du nur zu gerne
>>> das Ekel spielst. Das hingegen gelingt Dir ganz ausgezeichnet.
>
>> Inwiefern spiele ich das Ekel ?:-)
>
>> Ich beleidige dich nicht, ich sage nichts zur Qualitaet deiner
>> Programme. Ziehe nicht ueber dich her in diversen Medien. Verteile
>> nicht Inhalte von privaten EMails and dritt Personen. Das einzige was
>> ich dir sage ist...*nein*.
>
> "Nutzlos" und "wer braucht das schon". Naja, wie man's nimmt.
>
Das ist eine Meinungsaeusserung zum Sinn und nicht zur Qualitaet.
Wenn wer ueber "was macht es fuer einen Sinn MorphOS zu entwickeln"
argumentiert, nehme ich das zur Kenntniss. Es ist eine legitime Meinung
und unter diversen Praemissen auch logisch nachzuvollziehen.
>> Mich hat diese Aussage "veraergert", weil ich sie als persoehnlichen
>> Angriff werte, von denen du ja schon diverse gemacht hast.
>
> Das trifft sich gut, da ich diverse Aussagen von Dir auch als Angriff
> werte... ...von denen ich ja auch schon diverse gehört habe.
>
welche denn ?
Ich rede nirgendswo oeffentlich ueber dich und in diesem thread
wirst du keinen persoehnlichen und/oder qualitativen angriff von mir
finden.
Ralph Schmidt
<P...@amigo.ping.de> wrote:
> Abs: la...@t-online.de (Ralph Schmidt) Bet: "Re: Keine 64 MByte-SIMMs in
> CyberStormPPC :-("
>> > Dokumentation fuer die Phase5 HW oder um Weiterentwicklung von SFS
>> > geht.
>>
>> Ich blockiere keine SFS Weiterentwicklung...
>
> Dann schick mir mal die 1.84 sources. Du machst deine PowerPC MorphOS
> Version und 'wir' die 68k AmigaOS Version. Oder stoert dich da etwas
> dran?
1) der wird nicht "verschickt"..der ist ueber cvs erreichbar
2) du zaehlst wohl kaum als Programmierer, der das entsprechende
Filesystem/DOS Wissen hat.
Wenn T.Richter Zugriff haben will, dann kann er das gerne
haben.
anfage bei za...@vapor.com wegen zugriffsrecht.
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Das fuehrte dann dazu, dass du EMail Inhalte an PIK
> weitergeleitet hast
Na na na! Nix "weitergeleitet" und imho auch nichts zitiert.
Es kam nur eine Antwort auf die Frage 'Was meint jetzt Ralph
zu diesem Problem?'. Wenn er deine Meinung dabei zu exakt
wiedergegeben hat, so sollte er sich natuerlich entschuldigen.
Keine Frage...
Abgesehen davon aber, wuerde es mich interessieren, was dein
oeffentliches Schluchzen jetzt mit dem *eigentlichen* *Thema*
zu tun hat (?!) Hast du Angst, dass Thor deine ...ehmm..
Dokumentation "weiterleitet" und alle sich kaputt lachen??
Wenn du Angst haben solltest deinen guten Ruf zu verlieren,
so hast du dich in all den Jahren von der Realitaet abgewendet.
> und dementsprechend ging das dann in diesem Medium alle paar
> Monate weiter.
Muss man Leuten wie Etienne, mir und etlichen anderen nicht
gleich ankreiden. Auch wenn viele anderen sich besser
beherrschen koennen. Es kommt eben nur auf die Beherrschung
an.
Wir alle kennen das. In jeder Grundstufe gabs einen Knaben
dem jeder jedesmal im Vorbeigehen mit dem Fuss die Arschbacken
massierte. Den Grund kennt man selbst nicht so genau.
Anfaenglich sind solche Typen durch eine natuerliche Selektion
schon im fruehen Alter 'ausgeschieden'. Diese schoene Zeit ist
aber laengst vorbei.
Heute heisst es Zivilisation und wenn man es zulaesst darauf
angeweisen zu sein, muss man sich im spaeteren Alter mit
dem 'Plattaerschen' abgeben. Und genau das gilt es eben zu
vermeiden.
THOR bin ich daher nicht explizit fuer diese oder jene
(durchdachte!) technische Loesung dankbar, sondern, dass er
sich nicht zu schade ist, mich und andere von der Abhaengigkeit
von solchen Typen sogut es geht zu befreien. Vor solch einem
Idealismus kann ich nur den Hut ziehen.
--
PIK
Raphael Pilarczyk
Bet: "Re: NewSFS (Re: Keine 64 MByte-SIMMs...)"
> 1) der wird nicht "verschickt"..der ist ueber cvs erreichbar
Wurde 'registriert'.
> 2) du zaehlst wohl kaum als Programmierer, der das entsprechende
> Filesystem/DOS Wissen hat.
Darueber weisst du wohl genausoviel wie ueber die RKMs.
> Wenn T.Richter Zugriff haben will, dann kann er das gerne
> haben.
Nix Richter. Der ist mit Mu und P5 Boards ausgelastet.
--
PIK
Thomas Richter
> Bet: "Re: NewSFS (Re: Keine 64 MByte-SIMMs...)"
Hallo Raphael,
>> 1) der wird nicht "verschickt"..der ist ueber cvs erreichbar
> Wurde 'registriert'.
>> 2) du zaehlst wohl kaum als Programmierer, der das entsprechende
>> Filesystem/DOS Wissen hat.
> Darueber weisst du wohl genausoviel wie ueber die RKMs.
Nun, langsam. Ich bin ja durchaus bereit, Ralph zu glauben - ohne
irgendeine handfeste Dokumentation ist das allerdings ziemlich
schwer.
>> Wenn T.Richter Zugriff haben will, dann kann er das gerne
>> haben.
> Nix Richter. Der ist mit Mu und P5 Boards ausgelastet.
Ich befürchte, Du hast hierbei recht. Sogern ich auch an einem FS arbeiten
wollte, zeitlich momentan ziemlich unmöglich.
Thomas Richter
> In article <9elrl6$cbp$1...@mamenchi.zrz.TU-Berlin.DE>, "Thomas Richter"
> <th...@gibbs.math.tu-berlin.de> wrote:
Hi Ralph,
> Sigh..du hast "PPC Emulation" geschrieben..darauf habe ich
> geantwortet...es hat nichts mit PPC Emulation zu tun. q.e.d
> Das bezieht sich auf die Zeit zwischen 68k Reset und
> Zugriff auf das Motherboard chipset und Initialisierungssequenz dieser
> HW.
> Das wurde *nie* dokumentiert.
Ok, klären wir das mal genauer, weil's mich interessiert:
- Das wird doch nur dann ein Problem, wenn ich von der CPU einen Reset
für das Motherboard generiere, oder nicht? Falls nein, so würde ein Board
nie funktionieren. Falls ja, so ist auch ColdReboot() ein Problem, korrekt?
- Brauche ich für Bankswitching wirklich einen Reset? Ich denke da eher
an eine Lösung, bei der der Zugriff auf eine bestimmte Speicherzelle die
Bank-Logik deaktiviert und daraufhin auf die Motherboard-Hardware zugreift.
>> Wenn ich eine PPC-Emulation der 68K-Seite fahre, warum interessiert mich
>> dann, ob ich Bankswitching auf einer (dann zu emulierenden) Karte mache?
>> Ich würde natürlich eine Karte emulieren, die keine derartige Hardware
>> benötigt, bzw. den betreffenden Teil von Exec neu schreiben.
> Gnar..das hat nichts mit ppc und emulation zu tun.
> Wenn irgendeine HW Resetet wird dann muss man sich
> meistens an bestimmte initialisierungs/timing spielregeln halten.
Ok, sicher. Warum ist das - beim Bankswitching - von Belang? Das
Motherboard bekommt doch davon nichts mit, und wird nach einer kurzen
Setup-Sequenz des Boards selbst wie gehabt angefahren?
>> Und Interesse bezüglich zukünftiger Entwicklungen und einer gewissen
>> "Defensivität" des Designs - wollen wir das mal so ausdrücken - waren
>> nicht vorhanden?
> Da das API privat war gibt es keine "Defensivitaets" Problem, da man
> es neueren Beduerfnissen anpassen kann.
> Eigentlich die defensivste Einstellung ueberhaupt. Nichts als
> oeffentliches API dokumentieren, was nicht dafuer geeignet ist.
Wie man's nimmt - sicher. Das bedeutet aber auch, dass man eventuell
einmal die API austauschen könnte, und kann - wenn man eben nichts
dokumentiert hat. Aber genau das willst Du nun auch nicht zulassen.
>>> Das stimmt doch einfach nicht. Ich habe dir genug Beispiele von Firmen
>>> gegebenen, die fuer ihr Produkt ein eigenes MMU setup mitlieferten, da
>>> ohne dieses ihr Board mit AmigaOS nicht funktioniert haette.
>>> *Genau* das gleiche mit Phase5.
>>
>> Zumindest kann ich Dir versichern, dass ich von keinen Problemen mit
>> Boards anderer Hersteller weiß. Ok, das muss natürlich nichts heißen,
>> aber etwas komisch ist es doch schon, dass ich nur mit einer Sorte
>> Boards Probleme hatte, und sonst nichts.
> Hurricane2800 brauchte spezifische MMU Setups. Die Leute mit den
> ersten A3000 040 Karten wie Mercury brauchten das auch.
Ok, gut zu wissen. Ich denke, die meisten MMU-Setups lassen sich auch
mit MMU-Configuration nachbauen, und wenn das nichts hilft, mit einem
"Plugin" für die MMU-Library, für die es auch schon ein Design gibt.
>>> Ich sehe das eher unter dem Aspekt, dass CBM es nicht dokumentieren
>>> wollte aus Konkurrenz Situation bzgl. 3rd Party Unternehmen. Jeder in
>>> dem Bereich hat das "Rad" neu erfinden muessen fuer ihre spezielle HW.
>>
>> Du weißt doch auch, dass das nicht stimmt. Meine GVP-040 läuft auch mit
>> der Mike-Sinz 68040.library (v37). Nicht sonderlich gut, da die Lib
>> genug Macken hat - allerdings nichts MMU relevantes, sondern eher
>> betreffs der FPU-Emulation. Die Karte war derart gebaut, dass ein
>> solches Problem eben nicht auftritt, alle Erweiterungen werden
>> angemeldet und werden demnach korrekt gemappt.
> Schau dir die Karten davor an und die 060 Karten.
Ok, so es denn sein mag. Kannst Du diese Probleme näher spezifizieren?
>> Moment mal, hier stimmt schon wieder etwas nicht... Unten erzählst Du
>> was von wegen "neue Hardware"(GRexx), hier sagst Du "es gibt keine
>> signifikante neue Hardware". Kann oder kann ich nicht diese Hardware
>> mit einem Amiga, der nunmal mit einem 68k läuft, betreiben? Oder merkt
>> der
>> 68K davon über- haupt gar nichts? Im letzteren Fall wäre mir das recht
>> gleich.
> Es gibt keine neuen cpu boards von xyz Entwicklern. Die Leute die
> noch was machen haben ihre eigene Loesung.
"Eigene Lösungen" ohne "CPU-Boards"?
>> Darf ich daraus schließen, dass Du diese Hardware für "nicht
>> signifikant" und nicht "wert einer Überlegung bezüglich eines
>> konservativeren Designs" hältst?
> Sie beruht auf existierenden Technologien.
> Als signifikant wuerde ich neue 68k cpu boards erachten.
Ohne neue 68K's wohl nicht sonderlich sinnvoll. Und die gibt's nicht,
wollen mir mal absehen von einigen noch nicht nachgeprüften Werbeaussagen
von Mot bzgl. des neuen ColdFire.
>>> Hast du es *jetzt* realisiert ?
>>
>> Schön, dass Dir die ganze 68K-Schiene egal ist - habe ich ja verstanden.
>> Und weil *Dir* die 68Ks egal sind, dürfen sie auch allen anderen gleich
>> sein?
> Was dir gleich ist, ist deine Sache.
Ja, meine Sache, auch die Sache einiger tausend - soviele sind's ja wohl nun
doch noch - Amiga Anwender. Wenn davon vielleicht einige hundert Interesse
an einer Lösung meinerseits hätten, lässt Dich das vollkommen kalt? Wo ich
wirklich nichts großartiges erwarte außer einiger Dateien?
>>> Also wenn ich dir sage wie das Mapping ist, ist es ploetzlich
>>> "systemkonform" ?
>>
>> Es würde einem System folgen, ich wüsste was zu tun wäre, und Ruhe wäre.
>> Ich hätte genug Grund, Dir zu danken.
>>
>>> Und was ziehst du wieder fuer Schluesse ?
>>
>> Dass es offenbar bei CBM damals durchaus ein Design für MMUs gab, dies
>> aber nicht oder nicht mehr von CBM dokumentiert wurde und erst
>> nachträglich von einem ehemaligen Entwickler zusammengetragen wurde?
> Prinzipiell hat die CBM 68040.library ueberhaupt kein sogenanntes Design.
Ok, nennen wir es nicht "Design". Nennen wir es eben eine Methode, wie
MMU-Bäume aufzubauen sind.
>> Nun, ich verstehe ja nicht, was Du unter "öffentlicher Dokumentation"
>> verstanden haben willst. Ein "tu doch was Du willst" halte ich
>> jedenfalls nicht dafür. Unter "öffentlicher Dokumentation" hätte ich
>> eher etwas wie die "Autodocs" für eine 68040-Library verstanden, nebst
>> Anhang bzgl. deren MMU Belegungen. Ziemlich genau etwas der
>> Größenordnung, was ich von Mike bekommen habe - vielleicht nicht so gut
>> poliert.
> Und ich sehe diese Information als nicht nuetzlich fuer mich an.
Und, Du richtest somit Dein Leben reinen Nützlichkeitsaspekten aus,
andere Leut' sind Dir gleich? Und ich rede diesmal nicht von mir, sondern
von ein paar hundert, oder lass' es auch nur fünfzig oder dreißig Leute
sein, die sich dafür interessieren würden?
>> *Seufz* Und das ist eine Dokumentation?
> Das ist genau die Dokumentation/Schilderung des seit Jahren benutzten
> MMU Zugriffs aller moeglichen Leute. Der kleinste gemeinsame Nenner.
Und Du meinst nicht, dass das ziemlich armselig ist und einiger Überlegungen
bedarf - insbesondere in Bezug auf aktive MMU-Benutzung?
>>
>>> Was ist nachweisslich nicht korrekt ? Welche CPU Board Firma haelt sich
>>> denn an die MMU Library Definition ?
>>
>> Ich rede nicht von Firmen. Seit wann arbeitet noch eine Firma an Amiga-
>> Hardware?
> An neuer 68060 cpuboard HW sicherlich nicht...das ist ja auch der punkt
Ja, aber auch mein Punkt. Um "Firmen" geht es bei Amiga doch längst nicht
mehr - es geht um User.
>>>> Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist
>>>> kein Design.
>>
>>> Es wird keine Zeit mehr dafuer, weil der Zug abgefahren ist. Die Zeit
>>> war 1994.
>>
>> Na schön, niemand kann ersthaft noch Amiga-Hardware erwarten. Warum
>> bedeutet dies, dass niemand mehr damit arbeiten darf, und daran arbeiten
>> darf? Warum muss Deine Meinung hier ausschlaggebend sein?
>>
> Diese Meinung ist auschlaggebend fuer *mich*. Ob sie andere teilen ist
> ihnen ueberlassen.
Und Du meinst wirklich, dass Du das Maß der Dinge bist?
>>>>>> Tut mir leid, durchgefallen. Wir sind nicht mehr im Mittelalter.
>>>>
>>>>> Wir sind auch nicht in der heilen MU Welt, die die Weltprobleme
>>>>> loesst und von jedem unterstuetzt wird.
>>>>
>>>> Ich behaupte nicht, Weltprobleme zu lösen. Ich behaupte, für ein paar
>>>> MMU-spezifische Probleme eine brauchbare API definiert und benutzt zu
>>>> haben, und dass, obwohl Du weiterhin versuchst, mir Steine vor die
>>>> Beine zu werfen.
>>
>>> Ich werfe dir doch keine Steine in den Weg...du hast dir halt einen
>>> *steinigen* Weg *ausgesucht*. Ich mache einfach nur *gar nichts*
>>
>> Ja, eben. Stattdessen wird man bei - so finde ich berechtigten -
>> Anfragen angemault.
>>
>>> und fuer das *gar nichts* machen, bekomme ich dann nette "Huldigungen"
>>> in speziellen Docs, als haettest du ein Recht darauf, dass ich dich
>>> unterstuetze.
Vielleicht sollte ich bei der Gelegenheit mal wieder anmerken, dass die von
Dir beklagten "Huldigungen" seit mindestens 1 1/2 Jahren nicht mehr zu finden
sind?
"Recht auf" wohl nicht. Ich fühle mich aber - wie ich finde berechtigt -
ziemlich von Dir veralbert. Und vielleicht nicht nur ich allein. Weil
es im Grunde genommen weder *gegen* Dich geht, noch möchte ich irgend-
etwas *klauen*, noch Dir das Wasser abgraben, noch habe ich Interesse
PPC-seitig. Eher im Gegenteil, es geht um Support - freien Support (man,
muss ich blöd sein!) - von Hardware, für die Du Dich Deinen eigenen
Aussagen nach nicht mehr interessierst.
>> Ich beklage mich über meineserachtens fehldesignte Hardware und ein
>> Übermaß an Hacks, das nicht hätte sein müssen. Das fängt bei
>> Kleinigkeiten
>> wie der F-Space-Belegung an und hört bei Seltsamkeiten wie residenten
>> 680x0-Bibliotheken auf. Das das alles funktioniert, ist klar. Nur, darum
>> geht es nicht vordringlich. Dinge sind auf eine derart unvorsichtige und
>> - teilweise sogar so möchte ich sagen "töpelhafte" - Weise
>> zusammengesteckt, dass mir das Grausen kommt. "Damals" war schon klar,
>> dass es eventuell auch andere Wünsche seitens PPC-Benutzung der User
>> gab. Damals gab es schon "VMM", und dennoch wurden die Call-Outs der
> Ich halte von generellen/app sensitiven VMMs im Amiga Kontextes nichts
> und ich konnte es auch nie bei mir zum Leben erwecken.
Ein paar Ideen hab' ich schon. Automatisches VMM wird nicht drin sein, aber
das wissen wir ja beide, oder?
>> 68060-Lib entfernt (-> man denke etwa an fsin.x (a0) mit a0 "swapped
>> out"). Damals gab es schon Wünsche nach alternativen CPU-Bibliotheken
>> oder alternativen Graphikbibliotheken. Nein, hatte der User einmal P5,
>> so musste er dabei bleiben - das fing bei der
> Die Optimierung der mathe bibiliotheken war ein Auftrag fuer die V43,
> weil Phase5 dachte, dass schnellere FPU Emulation einen hoeheren
> Wert hat als ein "theoretischer" Support von VM, dass sowieso nie
> stabil aus System imminenten Gruenden lief.
Die Frage ist eigentlich, mit welchen Erwartungshaltungen man in die
Entwicklung hineingeht. Wenn Du "vollständiges VMM" erwartest, kann das
nicht klappen. Davon rede ich - zumindest - auch nicht.
> Und wenn du hier schon von Hacks/System Konform redest, dann
> solltest du wirklich nicht mit VM argumentieren.
Ich habe auch nicht vor, VMM ins System zu hacken. Meine Pläne gehen
in eine etwas andere Richtung.
>> 68060.library an und hört bei CGFx auf, die sich auf irgendwelche
> Warum sollte sich Phase5 fuer den Support von Konkurrenz Graphik-
> bibliotheken in irgendeiner weise interessieren. Reichlich naiv:-)
Ja, zugegeben. Trotzdem finde ich mancherlei Design - Interaktion
von CPU-Library und Graphik-Library - für nicht sonderlich gelungen.
>> Internals der CPU-Library verlassen muss, weil Autokonfig nicht "die
>> Wahl" war, aus welchen Gründen auch immer. Dokumentation dazu gab es
>> nicht, an existierende APIs, die man durchaus hätte benutzen können, zum
>> Teil mit einem *Minimum* an Mehraufwand hat man sich nicht gehalten. Und
>> darüber soll ich in Jubeln ausbrechen?
>>
> Nimm es hin wie ein Mann:-)
Danke für den seelischen Beistand. (-:
>>>>> Wie es in den Wald reinschallt, schallt es herraus.
>>>>
>>>> Und dann werden noch Lügen verbreitet, wie es Dir passt. Wirklich
>>>> nett...
>>> Welche Luegen denn ?
>>
>> Etwa wie oben, dass ich mir jetzt vorwerfen lassen muss, nicht
>> freundlich genug gefragt zu haben. Etienne hatte Dich damals - und das
>> muss ich zugeben - angep**. Einiges war damals sehr schief und sehr zu
>> meiner Enttäuschung danebengelaufen.
>>
> Ich habe dir nur gesagt, dass ich es als sinnlos erachte und dir ein
> klares nein gegegeben. Das ganze lief auch noch in der H&P Phase
> ab.
Was, bitte?
>>>> Herr Schmidt, ich hatte damals höflich angefragt, und mir den Ton von
>>>> Etienne Voigt - falls Du Dich noch entsinnen kannst - verbitten
>>>> lassen.
>>>>
>>>> *DU* warst derjenige, der nur herumgemault hat.
>>
>>> Wie z.b. "nette Kommentare in den Docs"
>>
>> Was ja wohl einige Monate später erst erfolgte? Bitte, bleiben wir doch
>> bei der Kausalität.
>>
> Und ? Ich kann mit "nein" umgehen. Du musstest nachkarten.
Ich will nur klarstellen, dass Dein "Argument" kein solches ist. Ich
kann nur wiederholen, dass ich damals die Ausbrüche gewisser Leute
sehr bedaurt habe. Zeitlich fiel das auch noch mit der ppc/powerpc-Diskussion
zusammen, mit der ich nun auch nichts am Hut hatte, und so kam das eine
zum anderen.
>>> obwohl ich dir nichts getan hatte ausser das ich gesagt habe, dass ich
>>> keinen Sinn in deiner Taetigkeit gesehen habe. Das fuehrte dann dazu,
>>> dass du EMail Inhalte an PIK weitergeleitet hast und dementsprechend
>>> ging das dann in diesem Medium alle paar Monate weiter.
>>
>> Das war zu dem "mal wieder ein Problem" im cyberscsi und Co, wo Du
>> ziemlich unvorsichtig vorgegangen bist, und ich dann noch eine Antwort
>> von wegen
>> "lass' mich in Frienden" bekommen habe. Übrigens nicht das einzige
>> Problem
>> vom cyberscsi, leider.
>>
> Ich habe dir auch gesagt, dass ich seit der 8.0 in keinster Weise mehr
> dafuer zustaendig war.
Ok, habe ich ja auch akzeptiert - und ich habe damals auch überreagiert,
zugegeben. Nur, Deine Reaktion hat mich auch *maßlos* enttäuscht. Ich hätte
etwas mehr Interesse Deinerseits erwartet.
>>> Ist doch ok, wenn er dir das alles dokumentiert, was er mal gemacht
>>> hat. Schoene Geste. Nur hat er aber kein Interesse mehr an Amiga SW/HW,
>>> im Gegensatz zu mir.
>>
>> Und *weil* Du Interesse hast, behälst Du Informationen vor und
>> blockierst deshalb?
> Wie ich dir schon sagte...alles was mit BlizzardPPC/CyberstormPPC/MK3
> zu tun hat ist von Interesse fuer mich.
Also fangen wir halt mit MK 1,2 und Co. an. Auch hier habe ich immer
noch Interesse an genügend Unbekannten. Wie sieht es hiermit aus?
Wie konfiguriert man den F-Space optimal?
>> Weil ich mal wieder ein Problem mit dem cybscsi und Co hatte von wegen
>> der schlauen Idee "ich mounte und blockiere Filing-Systeme selbst". Es
>> ist einer der Punkte, an denen man merkt, dass der Autor offenbar nicht
>> gründlich nachgedacht hatte, oder nicht gründlich getestet hatte, oder
>> beides. Bei Dir deswegen anzufragen... sein wir mal ehrlich, was wäre
>> das Resultat gewesen?
> Ich weiss nicht was du meinst. Ich bezog mich auf eine EMail bzgl.
> dem 0x10000 Problem einigen "netten" Kommentaren dort auf der 3.5 ML,
> die mir zugetragen wurden.
*Seufz* Ich weiß, das ist wieder ein Fehler... Ich beschreibe das Problem
trotzdem einmal:
OpenDevice() auf ein cybscsi & Co-Gerät. Danach HD_SCSICMD aufrufen, weil
ich Daten über das SCSI-Setup brauche. cybscsi & Co. blockiert automatisch
nach einem Medienwechsel. Ein DoIO kommt nicht zurück, die Applikation
hängt. Meine Einschätzung: Besagte Applikation wird für ein Filing-System
gehalten und aus "Sicherheitsgründen" nach dem Einlesen eines RDB kaltgestellt.
Steht davon irgendwas in devices/scsi.h? Bedaure, ich halte derartiges für
einen Hack - wenn man Probleme auf einer Ebene löst, die von einer anderen
Ebene erzeugt werden. Konzeptionell nicht überdacht, mag das Endresultat
für den User *in den meisten Fällen* noch so erstrebenswert sein wie man mag.
Ich habe mehrere Stunden dabei verbracht, ein Problem zu lösen, dass ich nicht
zu verantworten hatte, dass ich in keiner Weise reproduzieren konnte und das
letztendlich auf ein Gerät zurückging, dass ich sowieso in schlechter Erinnerung
hatte.
So, und das ist *alles*. Zufrieden?
Wie soll ich denn jetzt in Zukunft bei Problemen vorgehen? Dich fragen bringt
ja nichts. Nichts dagegen tun und das Problem ignorieren halte ich auch
für keine Lösung.
>>>>> Die liefen auch *vor* muforce.
>>>>
>>>> Aber nicht "mit" Enforcer.
>>
>>> Mit CyberGuard sollte das aber kein Problem gewesen sein:-) Jedenfalls
>>> kein prinzipielles Designproblem.
Wenn man auf die "dumme" Idee gekommen wäre, Enforcer nach ShapeShifter
zu starten, wäre man in den Genuss eines Feuerwerks gekommen...
>> Mit VMM oder ähnlichen "aktiven" Tools hingegen schon.
> Ich wuesste kein prinizipielles Problem mit CyberGuard...ein VM hat
> nichts mit der zeropage zu tun, kann den buserror overloaden und sich
> in eine existierende mmu map einblenden.
Ich denke dabei eher in Richtung "GUARD".
>>>> Nö, er ist von mir soeben reserviert worden, und was andere machen,
>>>> inter- essiert mich nicht. Und was ich damit anstelle, ist meine
>>>> Sache, und Dokumente dazu verbreite ich nicht, und wer immer was damit
>>>> anstellt außer mir soll zur Hölle fahren, und supporten tu' ich das
>>>> erst recht nicht. P5-Logik.
>>
>>> kommerzielle effizienz Logik.
>>
>> Und Du meinst nicht, dass man sich damit irgendwann mal in's eigene
>> Bein schießt, weil etwa Produkte anderer Leute damit nicht zusammen-
>> arbeiten werden? Weil niemand dafür Software entwickeln kann, weil es
>> keine Dokumente dafür gibt?
>>
> Userland Produkte arbeiten damit. Entsprechende Devtools, die das
> wichtigste abdecken existieren auch seit Jahren.
Aha, und "Userland" hat Dokumente?
Betreffs "Effizienz" - hältst Du es für "effizient", dass wir hier reden?
Wäre es nicht viel effizienter, wenn Du Dich ein kein wenig bewegen würdest?
Dann wäre mit dieser leidigen Diskussion ein- fÜr allemal Schluß. In
Bezug auf Kommunikationseffizienz ein klares Plus. Meinst Du nicht? (-:
>>> Glaubst du etwa ich/andere "lizensieren" sich von dir den mmulib source
>>> + 68k library src oder passen die eigene 68k library an fuer eine
>>> Flashnutzung im Jahre 2001, wenn die hinreichend notwendige Technologie
>>> schon existiert ?
>>
>> Und Du meinst nicht, dass es eventuell sinnvoll wäre, eine mächtigere
>> API zu wählen, für die Tools nebst Sourcen nebst Doku existieren, eine
>> *offene* API, anstelle eines geschlossenen Designs? War da nicht mal
>> was von wegen "open system architecture" oder so?
> Weil ich dieses open MMU API nicht als wichtig und notwendig erachte.
Und Du meinst nicht, dass andere Leute - darunter eventuell auch ein paar
potentielle Kunden - eine andere Einschätzung haben könnten?
Ich will das wirklich nicht überbewerten, aber man kann zu diesem Schluß
schon gelangen, wenn man meine Email mal durchblättert.
>> Frage: Warum ist PCI so gut?
> Es geht hier nicht darum warum PCI gut oder schlecht ist.
Es geht darum, warum das PCI-Design so gut ist. Anwort: Man kann es
nachlesen.
>>>>> Sicherlich...nur habe ich dir immer gesagt, dass seit Jahren kein
>>>>> neuer MMU Standard mehr *Sinn* macht,
>>>>
>>>> Offenbar immer noch genug Sinn für einige Leute. Weil *DU* nicht
>>>> verstehst, wozu das ganze sein soll, oder weil Du nicht willst, dass
>>>> jemand in *Deine Geniale Software* (tm) hineinsieht, blockierst Du
>>>> hier.
>>
>>> Die ist nicht genial..habe ich nie behauptet.
>>
>> Also, wo liegt dann das Problem?
Also, wo liegt das Problem?
>>>> Ich habe kein *Sendungsbewusstsein*. Ich habe nur genug von den
>>>> "Designideen" eines gewissen Herrn. Ich habe das Zeug, wie ich schon
>>>> mehrmals gesagt hatte, implementiert, weil ich es für eine
>>>> interessante Aufgabe hielt. Klar, sowas verstehst Du nicht. Dass ich
>>>> es nicht verkaufen kann, war mir sowieso schon klar.
>>
>>> Es gibt doch ueberhaupt kein Design...also habe ich auch keine Ideen zu
>>> diesem haben koennen.
>>
>> Ok, wenn man's halt so sagen will...
Ich möchte nur klarstellen, dass ich mich nicht zu "irgendwas" "berufen"
fühle, ok? Ich hatte einige Freude daran, das Zeug zu entwerfen, und offen-
bar einige andere Leute, es einzusetzen.
>> Den Beweis, dass jemand den F-Space oder andere PPC-belegte Address-
>> räume einmal freigegeben hat, bleibst Du mir schuldig? Oder willst Du
>> weiter behaupten "ich definiere das als richtig und somit ist es
>> richtig". Literatur habe ich angeführt?
> Der F-Space ist aus allen mir bekannten Information immer fuer das CPU
> Board spezifiziert worden.
Ok, ich bin ja durchaus bereit, dazuzulernen; also, wo finde ich derartige
Informationen?
> CBM hatte da wohl dann ihre Debugkarte.
Das entspricht auch meinen Informationen - eine hauseigene Karte, die
aber nie vertrieben wurde, und ein Addressraum, den man sich für
zukünftige Entwicklungen offenhalten wollte.
> Es existierte ein definiertes Module Slot und ResidentScan Protokoll
> fuer den Bereich, dass dir auch bekannt ist.
Ja.
> Der F-Space war *nie* fuer die 1MB Kickstart roms gedacht wie so
> viele Leute vermutet hatten...das war 0xe00000-0xe80000.
Auch ja. Inwieweit man dieses auch auf den frühen Modellen "durchaddressiert"
hat, ist eine andere Frage, aber zumindest ist der Addressbereich dafür
reserviert.
>>>> *Deiner* *Top Secret* Definition von Usern, die Du nicht mehr
>>>> supporten
>>>> willst? Du widersprichst Dir in Deiner seltsamen Logik doch nur
>>>> selbst.
>>
>>> Wer sagt denn, dass ich diese nicht mehr supporte ?
>>
>> Du? Etwa beim cyberscsi-Problemen?
>>
> Ich beziehe mich nur auf Produkte von 97(CyberstormPPC usw)
Ok, aber ich im Augenblick nicht. (-: Oder wird der F-Space etwa nicht
von der MK-II oder der 2060 benützt?
>>> Falsch.
>>> o Ich habe interesse, dass die flash,ppc.library,scsi korrekt
>>> funktioniert,
>>> was nur mit der existierenden MMU Loesung *fuer mich* garantiert
>>> ist.
>>> o Ich habe Interesse, dass das grex produkt korrekt bzgl. MMU
>>> Nutzung funktioniert.
>>> o Ich habe Interesse, dass der MorphOS startup korrekt funktioniert.
>>
>> Inwieweit ändert das etwas an meinen Feststellungen zu den 68ks? Wird
>> Morphos auf einer 2060 oder einer MK-II laufen? Hast Du noch Interesse
>> daran, diese zu supporten? Wenn nein, so sehe ich den Grund nicht,
> warum
> Da habe ich keine Interesse dran.
Ok, na dann ist doch prima. Fangen wir mit ein paar Fragen zu diesen
Boards an - zum Aufwärmen.
>> Du hier soviel Worte machst und nicht einfach sagst, was hier vor sich
>> geht. Wenn ja, warum behebst Du nicht mal ein paar kleine Probleme von
> was soll da vorgehen ?..diese Produkte haben keine spezielle HW.
Ahso? Wie wäre es etwa mit dem SCSI-Hostadapter, so als Beispiel?
>> cyberscsi oder hilfst, damit auch Drittparteien etwas vom Support haben?
> ich kann da sowieso nichts mehr "beheben", weil ich seit 4 jahren keine
> funktionsfaehige MK2 habe und ich auch nichts am flash rumspiele, weil
> das schon mal schiefgelaufen ist bei einem privat durchgesickertem
> internem MK2 "update".
> Das Risiko, dass sich irgendwer seine alte HW wegen so einem update
> das Flash zerschiesst ist aus meiner Sicht nicht tragbar.
Ok, das mag ja nur zu wahr sein. Aber warum ist es *Dein* Problem, wenn
sich jemand mit einem nicht-supporten Update seine Hardware zerschießt,
und *nicht Dein* Problem, wenn es Mucken hat?
>>> Wirklich ?:-) Du meinst, weil du etwas geschaffen hast was besser ist
>>> als was ich mal vor 7 Jahren programmiert habe, dass ich "neidisch" bin
>>> ? Das ist *nicht* der Fall.
>>
>> Du verhältst Dich aber ziemlich genau so... Etwa "das braucht doch eh'
>> keiner" und "das ist doch eh' alles abgekupfert".
> Die Funktionalitaet ist doch wohl eine Reimplementation von diversen
> Programmen.
Es geht nicht um die Funktionalität. Es geht um die modulare Bauweise
und um ein Design, welches darunterliegt, welches dies erst alles ermöglicht,
und welches auch weitere Ergänzungen erlaubt.
>>> Ich habe eine *Meinung* zu dem Sinn der Aktion im Kontext der
>>> *Marktsituation*, aber das sei doch dir ueberlassen was du machst.
>>> Ich blockiere dich doch in keinster Weise *aktiv*. Ich habe kein
>>> Problem damit wenn irgendwer die 680x0 libraries aus dem System auf
>>> *eigene* Gefahr entfernt.
>>> (Ich habe mich in *keinster* Weise bei Frank Wille zu seinem utility
>>> geaeussert und habe auch kein persoehnliches Problem mit ihm bzgl.
>>> seiner ppclib Emulation)
>>
>> Nicht? Nun, ich habe andere Geschichten von Frank gehört, Gerüchte,
>> natürlich...
> Echt ?..Wuerde mich ueberraschen. Ich habe mich jedenfalls keinmal
> ueber ihn oeffentlich geaeussert.
Jaja, doch. Aber was soll's. Ich gebe auf Gerüchte nicht viel, und
was nun da abgelaufen ist oder auch nicht... Was soll's.
>>> Du solltest echt keine Annahmen bzgl. meiner Motivation machen, weil
>>> die nicht so einfach schwarz&weiss funktioniert wie du es wohl glaubst.
>>
>> Ok, also, was ist Deine Motivation, fragen wir doch einmal um das zu
>> klären.
> Die sollte wohl klar sein....
Nein, bedaure. Bitte erkläre. Das ist mir bislang leider verschlossen
geblieben. (Und das ist jetzt nicht ironisch gemeint).
>>> Ich habe doch gesagt, dass ich kein Interesse daran habe, weil ich noch
>>> Interesse an der *SW* habe. M.Sinz hat dieses nicht.
>>
>> Und oben sagst Du mir, Du hättest kein Interesse an den 68K-Kisten? Wie
>> geht das nun zusammen?
> Ich rede hier ueber die letzte Phase5 HW Generation.
Und ich schlage vor, wir fangen einfach mal bei der vorletzten an. Auch
das wäre ja schonmal ein Erfolgserlebnis meinerseits.
>>> Fuer mich hat MorphOS einen kommerziellen und idiellen Zweck. Die
>>> PowerHW wird auch noch kommerziell verwertet.
>>
>> Und ich rede über 68K-Hardware.
> Und was hat die mit unbekannten mappings zu tun ?
Etwa das Mapping des F-Space, welches undokumentiert ist? (-:
Etwa die LVOs der 680x0-Libraries? (-:
>>> Inwiefern spiele ich das Ekel ?:-)
>>
>>> Ich beleidige dich nicht, ich sage nichts zur Qualitaet deiner
>>> Programme. Ziehe nicht ueber dich her in diversen Medien. Verteile
>>> nicht Inhalte von privaten EMails and dritt Personen. Das einzige was
>>> ich dir sage ist...*nein*.
>>
>> "Nutzlos" und "wer braucht das schon". Naja, wie man's nimmt.
> Das ist eine Meinungsaeusserung zum Sinn und nicht zur Qualitaet.
> Wenn wer ueber "was macht es fuer einen Sinn MorphOS zu entwickeln"
> argumentiert, nehme ich das zur Kenntniss.
Habe ich nicht. Ich sage nur, dass es *mich* nicht interessiert, und
dass *ich* die Motivation dahinter nicht verstehe. Ich habe nicht
vor, irgendjemand davon abzuhalten. Wenn man mich fragen würde nach
Internas meiner Programme, auch das würde ich ausbuddeln, meine Güte,
warum auch nicht. Auch hier ist, wie bei jedem Programm, nicht alles
so, wie es hätte sein sollen. Erwarte halt nur nicht, dass ich irgendwas
portieren würde.
> Es ist eine legitime Meinung
> und unter diversen Praemissen auch logisch nachzuvollziehen.
Ok, sind wir uns also soweit einig?
>>> Mich hat diese Aussage "veraergert", weil ich sie als persoehnlichen
>>> Angriff werte, von denen du ja schon diverse gemacht hast.
>>
>> Das trifft sich gut, da ich diverse Aussagen von Dir auch als Angriff
>> werte... ...von denen ich ja auch schon diverse gehört habe.
> welche denn ?
> Ich rede nirgendswo oeffentlich ueber dich und in diesem thread
> wirst du keinen persoehnlichen und/oder qualitativen angriff von mir
> finden.
Nicht? Ach, lassen wir das, ich möchte das alles nicht wiederholen.
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> In de.comp.sys.amiga.tech Ralph Schmidt <la...@t-online.de> wrote:
>
>> In article <9elrl6$cbp$1...@mamenchi.zrz.TU-Berlin.DE>, "Thomas Richter"
>> <th...@gibbs.math.tu-berlin.de> wrote:
>
> Hi Ralph,
>
>> Sigh..du hast "PPC Emulation" geschrieben..darauf habe ich
>> geantwortet...es hat nichts mit PPC Emulation zu tun. q.e.d Das bezieht
>> sich auf die Zeit zwischen 68k Reset und Zugriff auf das Motherboard
>> chipset und Initialisierungssequenz dieser HW. Das wurde *nie*
>> dokumentiert.
>
> Ok, klären wir das mal genauer, weil's mich interessiert:
>
> - Das wird doch nur dann ein Problem, wenn ich von der CPU einen Reset
> für das Motherboard generiere, oder nicht? Falls nein, so würde ein
> Board nie funktionieren. Falls ja, so ist auch ColdReboot() ein Problem,
> korrekt?
>
> - Brauche ich für Bankswitching wirklich einen Reset? Ich denke da eher
> an eine Lösung, bei der der Zugriff auf eine bestimmte Speicherzelle die
> Bank-Logik deaktiviert und daraufhin auf die Motherboard-Hardware
> zugreift.
>
Jetzt mal die 2630 als beispiel...
o reset
o bankswitching...(ich weiss jetzt nicht ob 0 oder f8)
der fuehrt dann dort diverse sachen aus(z.b. auch abfrage der amigahw
vor der exec hw initialiserung
o schaltet dann sein bankswitching aus und springt weiter ins rom
(Ignorieren wir jetzt mal, dass das 2630 von CBM ist)
Das heisst also, dass diese Methode Annahmen macht, dass keine
spezielle Timing/InitSequenz noetig ist, um eine gesicherte Funktion
der HW zu gewaehrleisten.
ich halte diese methode fuer theoretisch unsicherer als fspace, weil
dazu keinerlei informationen vorliegen, wie die 68k reagieren muss,
wenn auch das system chipset aus dem reset kommt.
Vielleicht erinnerst du dich noch...aber es gab mal kickstarts da gab
es eine ""unsinnige"" timingloop am afang.
>> Gnar..das hat nichts mit ppc und emulation zu tun. Wenn irgendeine HW
>> Resetet wird dann muss man sich meistens an bestimmte
>> initialisierungs/timing spielregeln halten.
>
> Ok, sicher. Warum ist das - beim Bankswitching - von Belang? Das
> Motherboard bekommt doch davon nichts mit, und wird nach einer kurzen
> Setup-Sequenz des Boards selbst wie gehabt angefahren?
Der Punkt ist, dass etwas zwischen motherboard chipset reset phase und
kickstart hw initphase etwas passiert und zu der Phase wurde nie etwas
oeffentlich dokumentiert.
>
>
>>> Und Interesse bezüglich zukünftiger Entwicklungen und einer gewissen
>>> "Defensivität" des Designs - wollen wir das mal so ausdrücken - waren
>>> nicht vorhanden?
>
>> Da das API privat war gibt es keine "Defensivitaets" Problem, da man es
>> neueren Beduerfnissen anpassen kann. Eigentlich die defensivste
>> Einstellung ueberhaupt. Nichts als oeffentliches API dokumentieren, was
>> nicht dafuer geeignet ist.
>
> Wie man's nimmt - sicher. Das bedeutet aber auch, dass man eventuell
> einmal die API austauschen könnte, und kann - wenn man eben nichts
> dokumentiert hat. Aber genau das willst Du nun auch nicht zulassen.
>
Weil ich mich dann auf FremdAPIs verlassen muss und das bedeutet
potentienellen support aerger.
>> Schau dir die Karten davor an und die 060 Karten.
>
> Ok, so es denn sein mag. Kannst Du diese Probleme näher spezifizieren?
>
DMA Script Controller im System ohne Snooping support. Als Beispiel.
>>> Moment mal, hier stimmt schon wieder etwas nicht... Unten erzählst Du
>>> was von wegen "neue Hardware"(GRexx), hier sagst Du "es gibt keine
>>> signifikante neue Hardware". Kann oder kann ich nicht diese Hardware
>>> mit einem Amiga, der nunmal mit einem 68k läuft, betreiben? Oder
>>> merkt der
>>> 68K davon über- haupt gar nichts? Im letzteren Fall wäre mir das recht
>>> gleich.
>
>> Es gibt keine neuen cpu boards von xyz Entwicklern. Die Leute die noch
>> was machen haben ihre eigene Loesung.
>
> "Eigene Lösungen" ohne "CPU-Boards"?
>
Z.b. fuer die GRex...ich weiss nicht was Elbox macht und ob diese
Prometheus Leute irgendeinen MMU Support benoetigen weiss
ich auch nicht.
Der Punkt war, dass in diesem Fall "wir" keine andere Loesung
brauchen, weil wir eine eigene haben, die hinreichend funktioniert.
>
> Ja, meine Sache, auch die Sache einiger tausend - soviele sind's ja wohl
> nun doch noch - Amiga Anwender. Wenn davon vielleicht einige hundert
> Interesse an einer Lösung meinerseits hätten, lässt Dich das vollkommen
> kalt? Wo ich wirklich nichts großartiges erwarte außer einiger Dateien?
>
Genauso wie es die P96 kalt laesst was CGFX macht und umgekehrt.
Genauso wie es Firma X kaltlaesst was Firma Y mit einem aehnlichen
Produkt macht.
Sei doch nicht so naiv.
>
>> Und ich sehe diese Information als nicht nuetzlich fuer mich an.
>
> Und, Du richtest somit Dein Leben reinen Nützlichkeitsaspekten aus,
> andere Leut' sind Dir gleich? Und ich rede diesmal nicht von mir,
> sondern von ein paar hundert, oder lass' es auch nur fünfzig oder
> dreißig Leute sein, die sich dafür interessieren würden?
>
Genauso wie sich Apple nicht fuer "30" Beos Leute interessiert.
>>> *Seufz* Und das ist eine Dokumentation?
>
>> Das ist genau die Dokumentation/Schilderung des seit Jahren benutzten
>> MMU Zugriffs aller moeglichen Leute. Der kleinste gemeinsame Nenner.
>
> Und Du meinst nicht, dass das ziemlich armselig ist und einiger
> Überlegungen bedarf - insbesondere in Bezug auf aktive MMU-Benutzung?
>
Sicherlich ist es armselig...aber wie ich dir schon mehrmals gesagt habe,
macht es heute keinen sinn mehr diese "armseligen" Verhaeltnisse zu
aendern, weil der Zug gerade abfaehrt in "neue" Verhaeltnisse.
>>>
>>>> Was ist nachweisslich nicht korrekt ? Welche CPU Board Firma haelt
>>>> sich denn an die MMU Library Definition ?
>>>
>>> Ich rede nicht von Firmen. Seit wann arbeitet noch eine Firma an
>>> Amiga- Hardware?
>
>> An neuer 68060 cpuboard HW sicherlich nicht...das ist ja auch der punkt
>
> Ja, aber auch mein Punkt. Um "Firmen" geht es bei Amiga doch längst
> nicht mehr - es geht um User.
>
Solange Leute noch Einnahmen mit diversen Produkten haben
(so gering sie auch sein moegen), geht es den Leuten noch darum.
>>>>> Dann wird es Zeit, das mal zu ändern, denn was Du vorschlägst, ist
>>>>> kein Design.
>>>
>>>> Es wird keine Zeit mehr dafuer, weil der Zug abgefahren ist. Die Zeit
>>>> war 1994.
>>>
>>> Na schön, niemand kann ersthaft noch Amiga-Hardware erwarten. Warum
>>> bedeutet dies, dass niemand mehr damit arbeiten darf, und daran
>>> arbeiten darf? Warum muss Deine Meinung hier ausschlaggebend sein?
>>>
>
>> Diese Meinung ist auschlaggebend fuer *mich*. Ob sie andere teilen ist
>> ihnen ueberlassen.
>
> Und Du meinst wirklich, dass Du das Maß der Dinge bist?
>
Noe..ich meine nur, dass ich das Mass aller Dinge fuer mich bin.
Wie du das Mass aller Dinge fuer dich bist.
Ich entscheide doch nichts fuer *dich*...ich entscheide fuer *mich*.
Welches "Mass" du an irgendwelche Dinge legst sei dir ueberlassen.
Sigh...ist das denn so schwierig:-)
>
> Vielleicht sollte ich bei der Gelegenheit mal wieder anmerken, dass die
> von Dir beklagten "Huldigungen" seit mindestens 1 1/2 Jahren nicht mehr
> zu finden sind?
>
Ich habe sie nie gelesen. Man hat mir nur gesagt, dass ich dort eine
"erwaehnt" wurde.
>
> Ein paar Ideen hab' ich schon. Automatisches VMM wird nicht drin sein,
> aber das wissen wir ja beide, oder?
>
sicherlich
>>> 68060-Lib entfernt (-> man denke etwa an fsin.x (a0) mit a0 "swapped
>>> out"). Damals gab es schon Wünsche nach alternativen CPU-Bibliotheken
>>> oder alternativen Graphikbibliotheken. Nein, hatte der User einmal P5,
>>> so musste er dabei bleiben - das fing bei der
>
>> Die Optimierung der mathe bibiliotheken war ein Auftrag fuer die V43,
>> weil Phase5 dachte, dass schnellere FPU Emulation einen hoeheren Wert
>> hat als ein "theoretischer" Support von VM, dass sowieso nie stabil aus
>> System imminenten Gruenden lief.
>
> Die Frage ist eigentlich, mit welchen Erwartungshaltungen man in die
> Entwicklung hineingeht. Wenn Du "vollständiges VMM" erwartest, kann das
> nicht klappen. Davon rede ich - zumindest - auch nicht.
>
alles was nicht "on-demand" ist halte ich fuer zu unsicher...siehe VMM
und aehnliche Systeme, die mit Task Datenbanken hoffen, dass sie das
Problem ""vermeiden"".
>> Warum sollte sich Phase5 fuer den Support von Konkurrenz Graphik-
>> bibliotheken in irgendeiner weise interessieren. Reichlich naiv:-)
>
> Ja, zugegeben. Trotzdem finde ich mancherlei Design - Interaktion von
> CPU-Library und Graphik-Library - für nicht sonderlich gelungen.
>
Alles eine Frage der Perspektive.
Unter PCI ist das Mapping Aufgabe der jeweiligen pci "library".
Es sollte auch kein Teil der rtg Treiber sein, weil es nicht deren
Aufgabe ist, irgendetwas bzgl. der CPU zu wissen. Sie haben
nur den Vorteil zu wissen, wie eine Gfxkarten aufgebaut ist.
Wir haben also jetzt ein chicken&egg Problem bzgl. Zorro, weil
Zorro keinerlei CacheMode Informationen definiert.
Dementsprechend wurde dieses Handling bzgl. den bekannten
Zorro Karten in der jeweiligen 680x0.library realisiert.
Ein externen Interface gab es dafuer auch.....
>
>> Ich habe dir nur gesagt, dass ich es als sinnlos erachte und dir ein
>> klares nein gegegeben. Das ganze lief auch noch in der H&P Phase ab.
>
> Was, bitte?
>
Deine Anfrage 1998.
>
>> Wie ich dir schon sagte...alles was mit BlizzardPPC/CyberstormPPC/MK3
>> zu tun hat ist von Interesse fuer mich.
>
> Also fangen wir halt mit MK 1,2 und Co. an. Auch hier habe ich immer
> noch Interesse an genügend Unbekannten. Wie sieht es hiermit aus?
>
> Wie konfiguriert man den F-Space optimal?
>
MK2,MK1 sind alles Zorro Geraete bzgl scsi.
F-Space hat nur Code.
Zum speziellen 2060 und MK2 Romaufbau kann
ich nicht viel sagen, weil ich daran nicht beteiligt
war.
>>> Weil ich mal wieder ein Problem mit dem cybscsi und Co hatte von wegen
>>> der schlauen Idee "ich mounte und blockiere Filing-Systeme selbst". Es
>>> ist einer der Punkte, an denen man merkt, dass der Autor offenbar
>>> nicht gründlich nachgedacht hatte, oder nicht gründlich getestet
>>> hatte, oder beides. Bei Dir deswegen anzufragen... sein wir mal
>>> ehrlich, was wäre das Resultat gewesen?
>
>> Ich weiss nicht was du meinst. Ich bezog mich auf eine EMail bzgl. dem
>> 0x10000 Problem einigen "netten" Kommentaren dort auf der 3.5 ML, die
>> mir zugetragen wurden.
>
> *Seufz* Ich weiß, das ist wieder ein Fehler... Ich beschreibe das
> Problem
> trotzdem einmal:
>
> OpenDevice() auf ein cybscsi & Co-Gerät. Danach HD_SCSICMD aufrufen,
> weil ich Daten über das SCSI-Setup brauche. cybscsi & Co. blockiert
> automatisch nach einem Medienwechsel. Ein DoIO kommt nicht zurück, die
> Applikation hängt. Meine Einschätzung: Besagte Applikation wird für ein
> Filing-System gehalten und aus "Sicherheitsgründen" nach dem Einlesen
> eines RDB kaltgestellt. Steht davon irgendwas in devices/scsi.h?
Diese Einschaetzung kann nicht zutreffen.
Es gibt keine "Blockierung" des SCSI Geraetes wie afaik der GVP
es macht.
Es werden auch nie Zugriffe auf das Device "kaltgestellt", da
es eigentlich jeden job replied, sobald er *fertig* ist, wobei das
von der scsi unit definiert wird. (es gibt dort keinen timer)
Bei IO_READ,WRITE usw. wird ein ChangeState check gemacht
und der ChangeState wird vom removable task in dem jeweiligen
intervall upgedated.
SCSIDirekt macht keinen Check auf ChangeState.
Aber dieser *Case* wird mit einem ganz normalen Fehler
beantwortet.
> Bedaure, ich halte derartiges für einen Hack - wenn man Probleme auf
> einer Ebene löst, die von einer anderen Ebene erzeugt werden.
> Konzeptionell nicht überdacht, mag das Endresultat für den User *in den
> meisten Fällen* noch so erstrebenswert sein wie man mag.
>
ist aber hier nicht der fall
> Ich habe mehrere Stunden dabei verbracht, ein Problem zu lösen, dass ich
> nicht zu verantworten hatte, dass ich in keiner Weise reproduzieren
> konnte und das letztendlich auf ein Gerät zurückging, dass ich sowieso
> in schlechter Erinnerung hatte.
>
kann gut sein, dass es vielleicht in einer "reselection" war und das
geraet sich nicht wieder "zurueckmeldet".
> Wenn man auf die "dumme" Idee gekommen wäre, Enforcer nach ShapeShifter
> zu starten, wäre man in den Genuss eines Feuerwerks gekommen...
>
Das Problem hat CyberGuard halt nicht.
>
> Aha, und "Userland" hat Dokumente?
>
Eigentlich das RKM:-)
> Betreffs "Effizienz" - hältst Du es für "effizient", dass wir hier
> reden? Wäre es nicht viel effizienter, wenn Du Dich ein kein wenig
> bewegen würdest? Dann wäre mit dieser leidigen Diskussion ein- fÜr
> allemal Schluß. In Bezug auf Kommunikationseffizienz ein klares Plus.
> Meinst Du nicht? (-:
>
Ohne diese Threads waere de.comp.sys.amiga.tech doch langweilig.
>>>> Glaubst du etwa ich/andere "lizensieren" sich von dir den mmulib
>>>> source
>>>> + 68k library src oder passen die eigene 68k library an fuer eine
>>>> Flashnutzung im Jahre 2001, wenn die hinreichend notwendige
>>>> Technologie schon existiert ?
>>>
>>> Und Du meinst nicht, dass es eventuell sinnvoll wäre, eine mächtigere
>>> API zu wählen, für die Tools nebst Sourcen nebst Doku existieren, eine
>>> *offene* API, anstelle eines geschlossenen Designs? War da nicht mal
>>> was von wegen "open system architecture" oder so?
>
>> Weil ich dieses open MMU API nicht als wichtig und notwendig erachte.
>
> Und Du meinst nicht, dass andere Leute - darunter eventuell auch ein
> paar potentielle Kunden - eine andere Einschätzung haben könnten?
>
Sicherlich gibt es auch Kunden/Entwickler die von Apple gerne
eine Dokumentation haben wollen, wie man unter MacOS 9
in den Privledge Mode kommt. Nur interessiert das Apple nicht...
>> Ich beziehe mich nur auf Produkte von 97(CyberstormPPC usw)
>
> Ok, aber ich im Augenblick nicht. (-: Oder wird der F-Space etwa nicht
> von der MK-II oder der 2060 benützt?
>
Da sollte nichts relevantes passieren nachdem die 680x0.library
das System uebernommen hat.
>
> Ahso? Wie wäre es etwa mit dem SCSI-Hostadapter, so als Beispiel?
>
Die siehst du wohl ueber showconfig debug...als Zorro Geraete.
> Ok, das mag ja nur zu wahr sein. Aber warum ist es *Dein* Problem, wenn
> sich jemand mit einem nicht-supporten Update seine Hardware zerschießt,
> und *nicht Dein* Problem, wenn es Mucken hat?
>
Weil ich da einen qualitativen Unterschied zwischen "es funktioniert
nicht nach t.richter std" zu die karte ist nicht mehr funktioniell sehe.
<cut..widerholung>
Oliver B. Warzecha
<9egq4i$uje$01$1...@news.t-online.com>:
> inwiefern macht die b2060 denn Probleme beim usern....das sie mit
> "deiner" Vorstellung wie das System zu funktionieren hat kollidiert
> ist *dein* Problem.
Äh... Ich habe zwar eine B2040, aber... ich werfe mal ein: ColdReboot()
geht nicht. Nur ein Setzen der Reset-Leitung (ctrl-lamiga-ramiga) hilft
dann noch weiter.
(primär in der Hoffnung, endlich mal eine Lösung für das Problem zu
sehen *aufhorch*)
--
OBW - Hilfe bei Einrichtung neuer Newsgruppen? ment...@dana.de
"Omega Metallicus is of course old Etruscan for "Let's Party"[...]
Experiments on live guitars were carried out in the most human
conditions imaginable." Steve Hackett, liner notes from "Darktown"
Thomas Richter
> Ralph Schmidt <la...@t-online.de> wrote in
> <9egq4i$uje$01$1...@news.t-online.com>:
>> inwiefern macht die b2060 denn Probleme beim usern....das sie mit
>> "deiner" Vorstellung wie das System zu funktionieren hat kollidiert
>> ist *dein* Problem.
> Äh... Ich habe zwar eine B2040, aber... ich werfe mal ein: ColdReboot()
> geht nicht. Nur ein Setzen der Reset-Leitung (ctrl-lamiga-ramiga) hilft
> dann noch weiter.
> (primär in der Hoffnung, endlich mal eine Lösung für das Problem zu
> sehen *aufhorch*)
Welche 68040.library ist im Spiel und welche reset-residenten Programme?
Funktioniert das schon *nur* nach SetPatch (ohne irgendwelche weiteren
Programme) nicht richtig?
Verwendest Du etwa ein ROM-Remapping, ggf. mittels eines Jumpers auf
dem Board? Hilft es, das abzuschalten?
Ralph Schmidt
<la...@t-online.de> wrote:
Bitte Rechtschreibfehler ignorieren:-)
Thomas Richter
>> - Das wird doch nur dann ein Problem, wenn ich von der CPU einen Reset
>> für das Motherboard generiere, oder nicht? Falls nein, so würde ein
>> Board nie funktionieren. Falls ja, so ist auch ColdReboot() ein Problem,
>> korrekt?
>>
>> - Brauche ich für Bankswitching wirklich einen Reset? Ich denke da eher
>> an eine Lösung, bei der der Zugriff auf eine bestimmte Speicherzelle die
>> Bank-Logik deaktiviert und daraufhin auf die Motherboard-Hardware
>> zugreift.
>>
> Jetzt mal die 2630 als beispiel...
Prima.
> o reset
> o bankswitching...(ich weiss jetzt nicht ob 0 oder f8)
> der fuehrt dann dort diverse sachen aus(z.b. auch abfrage der amigahw
> vor der exec hw initialiserung
> o schaltet dann sein bankswitching aus und springt weiter ins rom
> (Ignorieren wir jetzt mal, dass das 2630 von CBM ist)
> Das heisst also, dass diese Methode Annahmen macht, dass keine
> spezielle Timing/InitSequenz noetig ist, um eine gesicherte Funktion
> der HW zu gewaehrleisten.
Sofern der Init-Code die Motherboard-Hardware braucht, sicher.
Aber um eine 68060-er zu supporten, brauche ich das doch eigentlich
nicht. Ich muss "nur" die FPU erst einmal lahm legen, damit der exec-
Init-Code nicht sein frestore (a7)+ versucht, und exec seinen Dispatcher
zunächst "mit ohne" FPU-Support aufbaut. Alles weitere - eventuelle
Workarounds für mathieeesingbas, beispielsweise, kann man später per
Autoconfig erledigen. Den einzigen für 060 spezifisch kritischen Teil
ist der CPU-Detection-Code des exec-Bootstraps, und das nur deshalb, weil
er derart früh funktioniert, dass ich keinerlei Zugriff hierauf mittels
AutoConfig bzw. Expansion haben kann.
Die 2630 braucht natürlich Motherboard-Resources, für das ggf. anzuzeigende
Boot-Menü. Hatte das Ding nicht sogar einen eingebauten Monitor, den man
irgendwie anwerfen konnte?
> ich halte diese methode fuer theoretisch unsicherer als fspace, weil
> dazu keinerlei informationen vorliegen, wie die 68k reagieren muss,
> wenn auch das system chipset aus dem reset kommt.
Wie gesagt, wenn ich das chipset nicht brauche, sehe ich kein Problem.
Für 060er-Support brauche ich es sicher nicht.
> Vielleicht erinnerst du dich noch...aber es gab mal kickstarts da gab
> es eine ""unsinnige"" timingloop am afang.
Ja, klar. Diese Schleife gibt's immer noch im A2000 Kickrom.
>> Ok, sicher. Warum ist das - beim Bankswitching - von Belang? Das
>> Motherboard bekommt doch davon nichts mit, und wird nach einer kurzen
>> Setup-Sequenz des Boards selbst wie gehabt angefahren?
> Der Punkt ist, dass etwas zwischen motherboard chipset reset phase und
> kickstart hw initphase etwas passiert und zu der Phase wurde nie etwas
> oeffentlich dokumentiert.
Schon klar. Danke für die Details, man lernt nie aus.
>> Wie man's nimmt - sicher. Das bedeutet aber auch, dass man eventuell
>> einmal die API austauschen könnte, und kann - wenn man eben nichts
>> dokumentiert hat. Aber genau das willst Du nun auch nicht zulassen.
> Weil ich mich dann auf FremdAPIs verlassen muss und das bedeutet
> potentienellen support aerger.
Und wenn Dir Fremd-Anbieter Support-Service bieten? Letztendlich muss
ich mich immer auf andere Leute verlassen können, so oder so.
>>> Schau dir die Karten davor an und die 060 Karten.
>>
>> Ok, so es denn sein mag. Kannst Du diese Probleme näher spezifizieren?
>>
> DMA Script Controller im System ohne Snooping support. Als Beispiel.
Sicher, aber dazu gibt's ja ein Exec-Protokoll. Besagte Karten wurden
gebaut, *bevor* CachePre/PostDMA ins Spiel kamen?
>>> Es gibt keine neuen cpu boards von xyz Entwicklern. Die Leute die noch
>>> was machen haben ihre eigene Loesung.
>>
>> "Eigene Lösungen" ohne "CPU-Boards"?
> Z.b. fuer die GRex...ich weiss nicht was Elbox macht und ob diese
> Prometheus Leute irgendeinen MMU Support benoetigen weiss
> ich auch nicht.
> Der Punkt war, dass in diesem Fall "wir" keine andere Loesung
> brauchen, weil wir eine eigene haben, die hinreichend funktioniert.
Und die sich eventuell aufpeppen ließe durch den Zusatz von freier
Software für Null-Kosten?
>> Ja, meine Sache, auch die Sache einiger tausend - soviele sind's ja wohl
>> nun doch noch - Amiga Anwender. Wenn davon vielleicht einige hundert
>> Interesse an einer Lösung meinerseits hätten, lässt Dich das vollkommen
>> kalt? Wo ich wirklich nichts großartiges erwarte außer einiger Dateien?
> Genauso wie es die P96 kalt laesst was CGFX macht und umgekehrt.
Lässt mich zumindest nicht kalt, ich habe an P96 auch einiges gespielt.
> Genauso wie es Firma X kaltlaesst was Firma Y mit einem aehnlichen
> Produkt macht.
Da kann ich Dir mittlerweile berichten, dass das zumindest in meiner
Praxis nicht der Fall ist. Das betrifft hier lediglich Software, keine
Hardware/Software-Interfaces. (JPEG2000, konkret).
>> Und, Du richtest somit Dein Leben reinen Nützlichkeitsaspekten aus,
>> andere Leut' sind Dir gleich? Und ich rede diesmal nicht von mir,
>> sondern von ein paar hundert, oder lass' es auch nur fünfzig oder
>> dreißig Leute sein, die sich dafür interessieren würden?
> Genauso wie sich Apple nicht fuer "30" Beos Leute interessiert.
Wir reden aber auch von einem Markt, der bedeutend kleiner ist als der
von Apple, gelle? Meinst Du nicht, dass sich insgesamt mehr absetzen
ließe, wenn man miteinander statt gegeneinander arbeiten würde? Auf
diese Weise könnte man voneinander profitieren anstatt sich gegenseitig
nicht die Butter auf dem Brot zu gönnen.
>>> Das ist genau die Dokumentation/Schilderung des seit Jahren benutzten
>>> MMU Zugriffs aller moeglichen Leute. Der kleinste gemeinsame Nenner.
>>
>> Und Du meinst nicht, dass das ziemlich armselig ist und einiger
>> Überlegungen bedarf - insbesondere in Bezug auf aktive MMU-Benutzung?
> Sicherlich ist es armselig...aber wie ich dir schon mehrmals gesagt habe,
> macht es heute keinen sinn mehr diese "armseligen" Verhaeltnisse zu
> aendern, weil der Zug gerade abfaehrt in "neue" Verhaeltnisse.
"Sinn" für wen?
>> Ja, aber auch mein Punkt. Um "Firmen" geht es bei Amiga doch längst
>> nicht mehr - es geht um User.
> Solange Leute noch Einnahmen mit diversen Produkten haben
> (so gering sie auch sein moegen), geht es den Leuten noch darum.
Aber diese Firmen leben doch von ihren Kunden! Ich kenne da eine
Geschichte von einem IBM-Manager, der hat sich folgenden Satz in sein
Büro in großen Lettern kleben lassen: "Ohne Kunden ging hier gar nichts".
Ich bin durchaus der Meinung, dass Produkte und somit Firmen letztendlich
hiervon profitieren könnten.
>>> Diese Meinung ist auschlaggebend fuer *mich*. Ob sie andere teilen ist
>>> ihnen ueberlassen.
>>
>> Und Du meinst wirklich, dass Du das Maß der Dinge bist?
> Noe..ich meine nur, dass ich das Mass aller Dinge fuer mich bin.
> Wie du das Mass aller Dinge fuer dich bist.
Bin ich nicht. Ich lasse mit mir reden, bin bereit, meine Meinung zu
ändern, weiß, dass ich oft genug Unfug gebaut habe, dass man einiges
besser, anders hätte machen sollen.
> Ich entscheide doch nichts fuer *dich*...ich entscheide fuer *mich*.
Der Punkt ist eben der, dass Du damit eben nicht nur für Dich ent-
scheidest. Du entscheidest auch für ein Haufen anderer Leute, eventuell
gegen deren Interessen.
> Welches "Mass" du an irgendwelche Dinge legst sei dir ueberlassen.
> Sigh...ist das denn so schwierig:-)
Ja, diesen Punkt zu verstehen - oder sogar nachzuvollziehen - ist
sehr schwierig für mich. Das würde nur dann funktionieren, wenn Du
allein auf der Welt leben würdest - ansonsten wirst Du immer fÜr
andere Leute mitentscheiden müssen.
>> Die Frage ist eigentlich, mit welchen Erwartungshaltungen man in die
>> Entwicklung hineingeht. Wenn Du "vollständiges VMM" erwartest, kann das
>> nicht klappen. Davon rede ich - zumindest - auch nicht.
> alles was nicht "on-demand" ist halte ich fuer zu unsicher...siehe VMM
> und aehnliche Systeme, die mit Task Datenbanken hoffen, dass sie das
> Problem ""vermeiden"".
...was prinzipbedingt nicht geht, keine Diskussion. Ich stimme dem zu.
> Alles eine Frage der Perspektive.
> Unter PCI ist das Mapping Aufgabe der jeweiligen pci "library".
> Es sollte auch kein Teil der rtg Treiber sein, weil es nicht deren
> Aufgabe ist, irgendetwas bzgl. der CPU zu wissen. Sie haben
> nur den Vorteil zu wissen, wie eine Gfxkarten aufgebaut ist.
> Wir haben also jetzt ein chicken&egg Problem bzgl. Zorro, weil
> Zorro keinerlei CacheMode Informationen definiert.
> Dementsprechend wurde dieses Handling bzgl. den bekannten
> Zorro Karten in der jeweiligen 680x0.library realisiert.
Du kannst es - bei meinem Interface - im Augenblick so oder auch
anders halten. Entweder man verlässt sich auf korrektes Aufsetzen
der MMU-Konfiguration mittels einer Datenbank, die als Text-File
vorliegt. Dies fest einzucompilieren halte ich in Bezug auf
zukünftige Erweiterungen (einmal auflachen, bitte - auch so zu
verstehen, dass ich nicht alle Boards kenne) für ungünstig.
Andererseits bietet die Mu-Lib ja gerade eine *Abstraktion* der
MMU von der jeweils verwendeten Hardware, so dass die rtg-Software
prinzipbedingt *eben nichts* von der CPU wissen muss. Die gleichen
Caching-Flags würden eben auch von einer PPC-basierten Library
ausgewertet werden, nur dass das Endresultat - die Hardwaretabellen
eben - anders aussehen. Modi wie "Cacheinhibit" hat der PPC, der 68K,
und auch der Intel - darin sind sich die üblichen Prozessoren sehr
gleich.
> Ein externen Interface gab es dafuer auch.....
?
>>
>> Also fangen wir halt mit MK 1,2 und Co. an. Auch hier habe ich immer
>> noch Interesse an genügend Unbekannten. Wie sieht es hiermit aus?
>>
>> Wie konfiguriert man den F-Space optimal?
> MK2,MK1 sind alles Zorro Geraete bzgl scsi.
> F-Space hat nur Code.
Also hier: "Writethrough ROM" bzw. "Copyback ROM".
> Zum speziellen 2060 und MK2 Romaufbau kann
> ich nicht viel sagen, weil ich daran nicht beteiligt
> war.
Leider keine Zorro-Geräte, SCSI-Kontroller scheint im F-Space zu liegen.
Ich habe keine ConfigDevs. Im Augenblick "CacheInhibit".
Diese beiden oberen Zeilen lasse ich mir einrahmen, Hurra! Ich hab'
ein paar Informationen ergattert! (((-:
Danke!!!
>> *Seufz* Ich weiß, das ist wieder ein Fehler... Ich beschreibe das
>> Problem
>> trotzdem einmal:
>>
>> OpenDevice() auf ein cybscsi & Co-Gerät. Danach HD_SCSICMD aufrufen,
>> weil ich Daten über das SCSI-Setup brauche. cybscsi & Co. blockiert
>> automatisch nach einem Medienwechsel. Ein DoIO kommt nicht zurück, die
>> Applikation hängt. Meine Einschätzung: Besagte Applikation wird für ein
>> Filing-System gehalten und aus "Sicherheitsgründen" nach dem Einlesen
>> eines RDB kaltgestellt. Steht davon irgendwas in devices/scsi.h?
> Diese Einschaetzung kann nicht zutreffen.
> Es gibt keine "Blockierung" des SCSI Geraetes wie afaik der GVP
> es macht.
Mit GVP bzw. omnisci hatte ich keine Probleme... Habe ich ja selbst
zum Testen.
Wie verhindest Du beim Re-Mounten eines FS aus dem RDB, dass das
alte FS mit den nun unzutreffenden Mount-Parametern auf die Platte
zugreift? ACTION_DIE versteht das FFS ja nicht (abgesehen von den
Design-Problemen damit).
> Es werden auch nie Zugriffe auf das Device "kaltgestellt", da
> es eigentlich jeden job replied, sobald er *fertig* ist, wobei das
> von der scsi unit definiert wird. (es gibt dort keinen timer)
> Bei IO_READ,WRITE usw. wird ein ChangeState check gemacht
> und der ChangeState wird vom removable task in dem jeweiligen
> intervall upgedated.
> SCSIDirekt macht keinen Check auf ChangeState.
> Aber dieser *Case* wird mit einem ganz normalen Fehler
> beantwortet.
Ich kann Dir nur sagen, was ich gesehen habe - DoIO() hing definitiv
nach Einlegen eines anderen Mediums. Das Problem ließ sich dadurch
umgehen, dass das Gerät von Hand geschlossen und neu geöffnet
wurde - eigentlich unsinnig, wenn man nur ein paar SCSI-Kommandos
absetzen will.
>> Ich habe mehrere Stunden dabei verbracht, ein Problem zu lösen, dass ich
>> nicht zu verantworten hatte, dass ich in keiner Weise reproduzieren
>> konnte und das letztendlich auf ein Gerät zurückging, dass ich sowieso
>> in schlechter Erinnerung hatte.
> kann gut sein, dass es vielleicht in einer "reselection" war und das
> geraet sich nicht wieder "zurueckmeldet".
Wird bei OpenDevice() irgendwas auf SCSI-Ebene abgesetzt? Ein INQUIRY
mach' ich selbst. Irgendwas anderes? Start/Stop Unit vielleicht?
>> Betreffs "Effizienz" - hältst Du es für "effizient", dass wir hier
>> reden? Wäre es nicht viel effizienter, wenn Du Dich ein kein wenig
>> bewegen würdest? Dann wäre mit dieser leidigen Diskussion ein- fÜr
>> allemal Schluß. In Bezug auf Kommunikationseffizienz ein klares Plus.
>> Meinst Du nicht? (-:
> Ohne diese Threads waere de.comp.sys.amiga.tech doch langweilig.
Nehmen wir das mal als Anlass, das Gespräch noch etwas auszudehnen,
Ok?
>> Und Du meinst nicht, dass andere Leute - darunter eventuell auch ein
>> paar potentielle Kunden - eine andere Einschätzung haben könnten?
> Sicherlich gibt es auch Kunden/Entwickler die von Apple gerne
> eine Dokumentation haben wollen, wie man unter MacOS 9
> in den Privledge Mode kommt. Nur interessiert das Apple nicht...
Nur bist Du nicht Apple, der Kundenstamm ist um ein paar Größen-
ordnungen kleiner, steckt sehr viel tiefer in der Hardware, und
will besser umworben sein. Bildlich gesprochen: Ich befürchte,
Du vergleichst *Äpfel* mit Birnen. (-;
>> Ok, aber ich im Augenblick nicht. (-: Oder wird der F-Space etwa nicht
>> von der MK-II oder der 2060 benützt?
> Da sollte nichts relevantes passieren nachdem die 680x0.library
> das System uebernommen hat.
Ok, ich schreib' mir das mal auf.
>> Ahso? Wie wäre es etwa mit dem SCSI-Hostadapter, so als Beispiel?
> Die siehst du wohl ueber showconfig debug...als Zorro Geraete.
BOARDS:
Board + ROM (HD?) (phase 5): Prod=8512/24($2140/$18) (@$EA0000 128K)
Selbiges ist das SCSI? ^^^^^
Raphael Pilarczyk
Bet: "Re: NewSFS (Re: Keine 64 MByte-SIMMs...)"
> >> 2) du zaehlst wohl kaum als Programmierer, der das entsprechende
> >> Filesystem/DOS Wissen hat.
>
> > Darueber weisst du wohl genausoviel wie ueber die RKMs.
>
> Nun, langsam. Ich bin ja durchaus bereit, Ralph zu glauben - ohne
> irgendeine handfeste Dokumentation ist das allerdings ziemlich
> schwer.
"Handfeste Dokumentation"? Dafuer, dass Schmidt etwas von den
RKMs versteht, fehlen jegliche handfeste Beweise. Eine handfeste
Dokumentation waere in dem Kontext zweitrangig.
Abgesehen davon hat er imho klar zu verstehen gegeben, dass es
ausser paar Notizen keine Dokumentation gibt. Er hat solange dran
rumgestrickt bis es bei den meissten funktionierte. Etwas wie ein
'System in der Methode' oder gar ein Design gibt es nicht. Fertig,
Punkt.
> > Nix Richter. Der ist mit Mu und P5 Boards ausgelastet.
>
> Ich befürchte, Du hast hierbei recht.
Das ist ein Phaenomen. Jeder "fuerchtet" sich, der PIK koennte
Recht haben. ;-)
--
PIK
Michael Ulbrich
>Ralph Schmidt <la...@t-online.de> wrote in
><9egq4i$uje$01$1...@news.t-online.com>:
>> inwiefern macht die b2060 denn Probleme beim usern....das sie mit
>> "deiner" Vorstellung wie das System zu funktionieren hat kollidiert
>> ist *dein* Problem.
>Äh... Ich habe zwar eine B2040, aber... ich werfe mal ein: ColdReboot()
>geht nicht. Nur ein Setzen der Reset-Leitung (ctrl-lamiga-ramiga) hilft
>dann noch weiter.
Die meisten (alle???) 040er Karten von P5 hatten dieses Problem, zumindest
für MK2-040 und 1240 kann ich es auch bestätigen.
>(primär in der Hoffnung, endlich mal eine Lösung für das Problem zu
>sehen *aufhorch*)
Irgendein Problem mit dem 040er Timing beim Reset? Die jeweiligen 060er
gingen ja.
Gruß aus Berlin
--
Amiga-Spezialitäten: http://www.shopnfun.de/amiga/
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hi Ralph,
>
> Wie gesagt, wenn ich das chipset nicht brauche, sehe ich kein Problem.
> Für
> 060er-Support brauche ich es sicher nicht.
>
Es gibt auch noch movep support fuer BSC/Oktagon Kontroller
>> DMA Script Controller im System ohne Snooping support. Als Beispiel.
>
> Sicher, aber dazu gibt's ja ein Exec-Protokoll. Besagte Karten wurden
> gebaut, *bevor* CachePre/PostDMA ins Spiel kamen?
>
Tja..nur zu dumm, dass diese Script Kontroller auch Strukturen im
Ram benoetigen, *vor* der 680x0.library initialisierung und da hilft
dir CachePre/PostDMA nicht die Bohne.
>
> Da kann ich Dir mittlerweile berichten, dass das zumindest in meiner
> Praxis nicht der Fall ist. Das betrifft hier lediglich Software, keine
> Hardware/Software-Interfaces. (JPEG2000, konkret).
>
JPEG Standards sind Entwicklungen von "Gruppen" wegen einem
gemeinsamen "kommerziellen" Interesses zur Verwertung des
gemeinsamen Standards.
Ist hier wohl kaum gegeben:-)
>>> Und, Du richtest somit Dein Leben reinen Nützlichkeitsaspekten aus,
>>> andere Leut' sind Dir gleich? Und ich rede diesmal nicht von mir,
>>> sondern von ein paar hundert, oder lass' es auch nur fünfzig oder
>>> dreißig Leute sein, die sich dafür interessieren würden?
>
>> Genauso wie sich Apple nicht fuer "30" Beos Leute interessiert.
>
> Wir reden aber auch von einem Markt, der bedeutend kleiner ist als der
> von Apple, gelle? Meinst Du nicht, dass sich insgesamt mehr absetzen
> ließe, wenn man miteinander statt gegeneinander arbeiten würde? Auf
> diese Weise könnte man voneinander profitieren anstatt sich gegenseitig
> nicht die Butter auf dem Brot zu gönnen.
>
Glaubst du ernsthaft, dass man einen Kunden mehrgewinnen koennte,
wenn man die MMULib unterstuetzt....sicherlich nicht.
Apple entscheidet sowas nach strategischen Ueberlegungen...man mag
BeOS Leute nicht als Kunden gewonnen haben...man hat BeOS aber
auch keine Chance gegeben ihr Produkt im Markt zu plazieren, um
eigenen Kunden abzuwerben.
>
> Aber diese Firmen leben doch von ihren Kunden! Ich kenne da eine
> Geschichte von einem IBM-Manager, der hat sich folgenden Satz in sein
> Büro in großen Lettern kleben lassen: "Ohne Kunden ging hier gar
> nichts".
>
IBM ruehrt sich erst wenn *Geld* fliesst und das in signifikanten
Stroemen. Alle andere Aktionen werden aus Strategieueberlegungen
getroffen. Wenn du da nicht reinpasst, faellst du durch das Raster.
>> Ich entscheide doch nichts fuer *dich*...ich entscheide fuer *mich*.
>
> Der Punkt ist eben der, dass Du damit eben nicht nur für Dich ent-
> scheidest. Du entscheidest auch für ein Haufen anderer Leute, eventuell
> gegen deren Interessen.
>
Als ob du das nicht auch jeden Tag machst....du entscheidest, dass du
xyz machst und das ist gegen die Interesse von abc irgendwo anders.
Sei das jetzt mit dem Auto rumfahren, "ungruener"Atomstrom, mehr
Geld verdienst als ein anderer, mehr zu essen hast usw.
>> Diese Einschaetzung kann nicht zutreffen. Es gibt keine "Blockierung"
>> des SCSI Geraetes wie afaik der GVP es macht.
>
> Mit GVP bzw. omnisci hatte ich keine Probleme... Habe ich ja selbst zum
> Testen.
>
> Wie verhindest Du beim Re-Mounten eines FS aus dem RDB, dass das alte FS
> mit den nun unzutreffenden Mount-Parametern auf die Platte zugreift?
> ACTION_DIE versteht das FFS ja nicht (abgesehen von den Design-Problemen
> damit).
>
Das wird mittels Removable Handler gemacht, der eine Datenbank hat bzgl.
den angemeldeten removable/change handlern(die beinhalten den
"Filesystem" Task und die Unit der Geraetes...damit kann man *viel* machen)
Es werde keine Action_Dies verschickt.
Das hat auch alles nichts mit der device ebene zu tun.
>> Es werden auch nie Zugriffe auf das Device "kaltgestellt", da es
>> eigentlich jeden job replied, sobald er *fertig* ist, wobei das von der
>> scsi unit definiert wird. (es gibt dort keinen timer) Bei IO_READ,WRITE
>> usw. wird ein ChangeState check gemacht und der ChangeState wird vom
>> removable task in dem jeweiligen intervall upgedated. SCSIDirekt macht
>> keinen Check auf ChangeState. Aber dieser *Case* wird mit einem ganz
>> normalen Fehler beantwortet.
>
> Ich kann Dir nur sagen, was ich gesehen habe - DoIO() hing definitiv
> nach Einlegen eines anderen Mediums. Das Problem ließ sich dadurch
> umgehen, dass das Gerät von Hand geschlossen und neu geöffnet wurde -
> eigentlich unsinnig, wenn man nur ein paar SCSI-Kommandos absetzen will.
>
wie gesagt...es gibt dort kein locking protokoll, was mit einem
filesystem usw. zu tun hat.
>>> Ich habe mehrere Stunden dabei verbracht, ein Problem zu lösen, dass
>>> ich nicht zu verantworten hatte, dass ich in keiner Weise
>>> reproduzieren konnte und das letztendlich auf ein Gerät zurückging,
>>> dass ich sowieso in schlechter Erinnerung hatte.
>
>> kann gut sein, dass es vielleicht in einer "reselection" war und das
>> geraet sich nicht wieder "zurueckmeldet".
>
> Wird bei OpenDevice() irgendwas auf SCSI-Ebene abgesetzt? Ein INQUIRY
> mach' ich selbst. Irgendwas anderes? Start/Stop Unit vielleicht?
>
nein...Es wird einmal(oder auf bedarf) die scsi units gescanned und dann
greift OpenDevice() auf die interne unit datenbank zu.
>
>> Sicherlich gibt es auch Kunden/Entwickler die von Apple gerne eine
>> Dokumentation haben wollen, wie man unter MacOS 9 in den Privledge Mode
>> kommt. Nur interessiert das Apple nicht...
>
> Nur bist Du nicht Apple, der Kundenstamm ist um ein paar Größen-
> ordnungen kleiner, steckt sehr viel tiefer in der Hardware, und will
> besser umworben sein. Bildlich gesprochen: Ich befürchte, Du vergleichst
> *Äpfel* mit Birnen. (-;
>
Ich wollte dir nur klarmachen, dass es Leute/Firmen usw. gibt, die
gewisse strategische interessen den interessen von anderen vorzuziehen.
>>> Ok, aber ich im Augenblick nicht. (-: Oder wird der F-Space etwa nicht
>>> von der MK-II oder der 2060 benützt?
>
>> Da sollte nichts relevantes passieren nachdem die 680x0.library das
>> System uebernommen hat.
>
> Ok, ich schreib' mir das mal auf.
>
>>> Ahso? Wie wäre es etwa mit dem SCSI-Hostadapter, so als Beispiel?
>
>> Die siehst du wohl ueber showconfig debug...als Zorro Geraete.
>
> BOARDS:
> Board + ROM (HD?) (phase 5): Prod=8512/24($2140/$18) (@$EA0000 128K)
>
ja
Oliver B. Warzecha
<9epen8$m0k$1...@mamenchi.zrz.TU-Berlin.DE>:
> In de.comp.sys.amiga.tech Oliver B. Warzecha <o...@amarok.ping.de> wrote:
>> Äh... Ich habe zwar eine B2040, aber... ich werfe mal ein: ColdReboot()
>> geht nicht. Nur ein Setzen der Reset-Leitung (ctrl-lamiga-ramiga) hilft
>> dann noch weiter.
>
>> (primär in der Hoffnung, endlich mal eine Lösung für das Problem zu
>> sehen *aufhorch*)
>
> Welche 68040.library ist im Spiel und welche reset-residenten Programme?
Im Zweifelsfall gar keine.
> Funktioniert das schon *nur* nach SetPatch (ohne irgendwelche weiteren
> Programme) nicht richtig?
Das tut niemals nicht. Also eigentlich gar nicht. Daß Gurus auch nicht
wiederkommen, ist dabei übrigens impliziert...
> Verwendest Du etwa ein ROM-Remapping, ggf. mittels eines Jumpers auf
> dem Board? Hilft es, das abzuschalten?
Ja, ich verwende den MAPROM-Jumper. Ich hatte den mal eine Zeitlang aus,
ist schon eine Ecke her, und das Problem war das gleiche.
Der einzige Software-Reboot, der hier funktioniert, ist der vom SetPatch
V44 und auch PrepareEmul tat seinerzeit (mit A1200-Option(!)). Ich habe
BTW vor, das ROM-Mapping demnächst wieder abzuschalten, weil ich
MMU-Mapping einem nicht 100%ig funktionierendem Hardwarehack vorziehe.
Blizkick läuft nämlich auch nicht. :-( Bestünde die Möglichkeit, daß
MuFastROM und Blizkick die gleiche Schnittstelle zum Einbinden von
Zusatzmodulen verwenden könnten? ;)
Harry Sintonen (der Blizkick-Autor) meinte BTW, daß das
Nichtfunktionieren auf ein Hardwareproblem zurückzuführen sei. Ich nehme
stark an, daß das Reboot-Problem damit auch zusammenhängt. Mir stellt
sich nun die Frage: Ist das ein Hardwareproblem der B2040 oder meiner
Backplane im A2k (revision 4.1, auf 4.3 + nochwas upgegradet)? Bringt es
was, wenn ich mir ein Rev 6.x-Board beschaffe oder ist diese Serie B2040
"inne Wurst"? Muß ich mir gar eine andere Blizzard-Firmware
zusammenhacken? =:-)
sich ärgernd, daß er damals das Geld für eine DKB Wildfire nicht hatte,
Marius Schwarz
On 26-Mai-01, you wrote:
>> Sie beruht auf existierenden Technologien.
>> Als signifikant wuerde ich neue 68k cpu boards erachten.
>
> Ohne neue 68K's wohl nicht sonderlich sinnvoll. Und die gibt's nicht,
> wollen mir mal absehen von einigen noch nicht nachgeprüften Werbeaussagen
> von Mot bzgl. des neuen ColdFire.
Der Befehlssatz in der Bitkodierung ist nicht kompatibel, da müßte man die Befehle teilweise
emulieren (ummappen) , sonst könntest Du alle bisherigen Programme vergessen.
Der neue Coldfire hat zwar eigentlich alles was man für einen Amigabetrieb
braucht, aber ebend nichts so ganz.
Regards
--
The real Cyborg - Amigasoft and more !
Thomas Richter
>> Ohne neue 68K's wohl nicht sonderlich sinnvoll. Und die gibt's nicht,
>> wollen mir mal absehen von einigen noch nicht nachgeprüften Werbeaussagen
>> von Mot bzgl. des neuen ColdFire.
> Der Befehlssatz in der Bitkodierung ist nicht kompatibel, da müßte man die Befehle teilweise
> emulieren (ummappen) , sonst könntest Du alle bisherigen Programme vergessen.
> Der neue Coldfire hat zwar eigentlich alles was man für einen Amigabetrieb
> braucht, aber ebend nichts so ganz.
*Angeblich* hat Motorola einen Coldfire, der Befehlskompatibel zur 68K-Serie ist, mit
einigen fehlenden Instruktionen wie auch schon beim 040er oder 060er. Angeblich
gibt es eine Softwarebibliothek, die diese Befehle per Traps emuliert, d.h. den
Core einer coldfire.library.
Außer netten "Postern" von Marketing-Leuten habe ich aber noch keine Datenbücher
etc. gesehen, so dass ich das alles *sehr vorsichtig* einschätzen würde. Marketing
Leute reden viel, wenn der Tag lang ist. /-:
Thomas Richter
Hi,
>> Welche 68040.library ist im Spiel und welche reset-residenten Programme?
> Im Zweifelsfall gar keine.
Dann braucht es auch nicht zu funktionieren. (-: Eine 040er wird
typsicherweise ColdReboot() patchen müssen. (Etwa: Caches abschalten).
>> Funktioniert das schon *nur* nach SetPatch (ohne irgendwelche weiteren
>> Programme) nicht richtig?
> Das tut niemals nicht. Also eigentlich gar nicht. Daß Gurus auch nicht
> wiederkommen, ist dabei übrigens impliziert...
"Auch Gurus" oder "nur Gurus"? Der Reset nach einem Guru wird anders
erzeugt als durch ColdReboot(). Leider.
>> Verwendest Du etwa ein ROM-Remapping, ggf. mittels eines Jumpers auf
>> dem Board? Hilft es, das abzuschalten?
> Ja, ich verwende den MAPROM-Jumper. Ich hatte den mal eine Zeitlang aus,
> ist schon eine Ecke her, und das Problem war das gleiche.
Ok, Vermutung ins Blaue.
> Der einzige Software-Reboot, der hier funktioniert, ist der vom SetPatch
> V44 und auch PrepareEmul tat seinerzeit (mit A1200-Option(!)).
Verwendet beides ColdReboot().
> Ich habe
> BTW vor, das ROM-Mapping demnächst wieder abzuschalten, weil ich
> MMU-Mapping einem nicht 100%ig funktionierendem Hardwarehack vorziehe.
> Blizkick läuft nämlich auch nicht. :-( Bestünde die Möglichkeit, daß
> MuFastROM und Blizkick die gleiche Schnittstelle zum Einbinden von
> Zusatzmodulen verwenden könnten? ;)
MuFastROM bietet gar nicht die Möglichkeit, Zusatzmodule einzubinden. (-:
Meinst Du "LoadModule"? Ich denke, Harry arbeitet grundsätzlich anders,
indem er die Module im per P5-Hardware umgemappten ROM im on-Board RAM
der 2040 plaziert. LoadModule muss auf jeder Hardware laufen und ist
somit nicht Boardspezifisch. Die Module werden einfach überladen durch
den Exec-Resident-Tag-Mechanismus. Das geht leider *nicht* mit Exec und
Expansion, aber mit allem anderen.
> Harry Sintonen (der Blizkick-Autor) meinte BTW, daß das
> Nichtfunktionieren auf ein Hardwareproblem zurückzuführen sei.
Nehme ich auch an.
> Ich nehme
> stark an, daß das Reboot-Problem damit auch zusammenhängt. Mir stellt
> sich nun die Frage: Ist das ein Hardwareproblem der B2040 oder meiner
> Backplane im A2k (revision 4.1, auf 4.3 + nochwas upgegradet)? Bringt es
> was, wenn ich mir ein Rev 6.x-Board beschaffe oder ist diese Serie B2040
> "inne Wurst"? Muß ich mir gar eine andere Blizzard-Firmware
> zusammenhacken? =:-)
Ich glaube nicht, dass die Firmware hier irgendwas damit zu tun hat.
Alles andere: Ich kann nur mit den Achseln zucken, da ich die Harware-
Specs nicht habe.
Bis dahin: Probiere doch einmal aus, *welche Programme genau* nicht
richtig rebooten. Ich denke da in Richtung diverser "Reboot" oder
"Reset"-Programme, die sich sicherlich in genügender Anzahl im Aminet
finden.
Thomas Richter
>> Wie gesagt, wenn ich das chipset nicht brauche, sehe ich kein Problem.
>> Für
>> 060er-Support brauche ich es sicher nicht.
> Es gibt auch noch movep support fuer BSC/Oktagon Kontroller
Betrifft nur ältere Modelle, Oliver hatte irgendwann einmal ein Einsehen. (-:
Davon abgesehen: Auch dafür brauche ich keine Motherboard-Resources.
Da ich den Code nur vor dem Diag-Init plazieren muss, geht dies im
Prinzip über Resident-Tags. Wobei ich sogar soweit gehen würde, dann
den Usern ein Upgrade zu emfehlen oder den on-board SCSI zu verwenden
und nicht vom oktagon zu booten. Ist eh' schneller.
>>> DMA Script Controller im System ohne Snooping support. Als Beispiel.
>>
>> Sicher, aber dazu gibt's ja ein Exec-Protokoll. Besagte Karten wurden
>> gebaut, *bevor* CachePre/PostDMA ins Spiel kamen?
>>
> Tja..nur zu dumm, dass diese Script Kontroller auch Strukturen im
> Ram benoetigen, *vor* der 680x0.library initialisierung und da hilft
> dir CachePre/PostDMA nicht die Bohne.
Da ist aber auch der Cache nicht eingeschaltet und das Problem somit
nicht existent. Code/Scripte kann ich doch nach belieben in alloziertem
RAM plazieren.
>> Da kann ich Dir mittlerweile berichten, dass das zumindest in meiner
>> Praxis nicht der Fall ist. Das betrifft hier lediglich Software, keine
>> Hardware/Software-Interfaces. (JPEG2000, konkret).
>>
> JPEG Standards sind Entwicklungen von "Gruppen" wegen einem
> gemeinsamen "kommerziellen" Interesses zur Verwertung des
> gemeinsamen Standards.
> Ist hier wohl kaum gegeben:-)
Ach, gibt es kein gemeinsames kommerizielles Interesse am Amiga?
>> Wir reden aber auch von einem Markt, der bedeutend kleiner ist als der
>> von Apple, gelle? Meinst Du nicht, dass sich insgesamt mehr absetzen
>> ließe, wenn man miteinander statt gegeneinander arbeiten würde? Auf
>> diese Weise könnte man voneinander profitieren anstatt sich gegenseitig
>> nicht die Butter auf dem Brot zu gönnen.
>>
> Glaubst du ernsthaft, dass man einen Kunden mehrgewinnen koennte,
> wenn man die MMULib unterstuetzt....sicherlich nicht.
Sicher doch. Es gibt fertige und supportete Tools dafür, und von
dem, was an mich herangetragen wird, durchaus Interesse dafür.
>> Der Punkt ist eben der, dass Du damit eben nicht nur für Dich ent-
>> scheidest. Du entscheidest auch für ein Haufen anderer Leute, eventuell
>> gegen deren Interessen.
> Als ob du das nicht auch jeden Tag machst....du entscheidest, dass du
> xyz machst und das ist gegen die Interesse von abc irgendwo anders.
> Sei das jetzt mit dem Auto rumfahren, "ungruener"Atomstrom, mehr
> Geld verdienst als ein anderer, mehr zu essen hast usw.
Und, trotzdem kannst Du nicht immer das tun, was nur *Dir* am besten
passt. Man lebt "miteinander" und nicht "gegeneinander".
>> Wie verhindest Du beim Re-Mounten eines FS aus dem RDB, dass das alte FS
>> mit den nun unzutreffenden Mount-Parametern auf die Platte zugreift?
>> ACTION_DIE versteht das FFS ja nicht (abgesehen von den Design-Problemen
>> damit).
> Das wird mittels Removable Handler gemacht, der eine Datenbank hat bzgl.
> den angemeldeten removable/change handlern(die beinhalten den
> "Filesystem" Task und die Unit der Geraetes...damit kann man *viel* machen)
> Es werde keine Action_Dies verschickt.
> Das hat auch alles nichts mit der device ebene zu tun.
Nicht ganz, was ich fragen wollte. Ich meinte eigentlich eher: "Wie kannst
Du sicher verhindern, dass ein "nicht mehr benötigtes" Filing-System auf-
grundeiner Race-Condition trotzdem nicht ein CMD_WRITE verschickt?"
>> Ich kann Dir nur sagen, was ich gesehen habe - DoIO() hing definitiv
>> nach Einlegen eines anderen Mediums. Das Problem ließ sich dadurch
>> umgehen, dass das Gerät von Hand geschlossen und neu geöffnet wurde -
>> eigentlich unsinnig, wenn man nur ein paar SCSI-Kommandos absetzen will.
> wie gesagt...es gibt dort kein locking protokoll, was mit einem
> filesystem usw. zu tun hat.
Dann weiß ich auch nicht, was dort passiert ist.
>>> kann gut sein, dass es vielleicht in einer "reselection" war und das
>>> geraet sich nicht wieder "zurueckmeldet".
>>
>> Wird bei OpenDevice() irgendwas auf SCSI-Ebene abgesetzt? Ein INQUIRY
>> mach' ich selbst. Irgendwas anderes? Start/Stop Unit vielleicht?
> nein...Es wird einmal(oder auf bedarf) die scsi units gescanned und dann
> greift OpenDevice() auf die interne unit datenbank zu.
Gescannt bedeutet: Absetzen von "TEST UNIT READY?"
>> Nur bist Du nicht Apple, der Kundenstamm ist um ein paar Größen-
>> ordnungen kleiner, steckt sehr viel tiefer in der Hardware, und will
>> besser umworben sein. Bildlich gesprochen: Ich befürchte, Du vergleichst
>> *Äpfel* mit Birnen. (-;
> Ich wollte dir nur klarmachen, dass es Leute/Firmen usw. gibt, die
> gewisse strategische interessen den interessen von anderen vorzuziehen.
Ok, fein. Was sind demnach Deine strategischen Interessen?
>> BOARDS:
>> Board + ROM (HD?) (phase 5): Prod=8512/24($2140/$18) (@$EA0000 128K)
> ja
Ok, dann kann ich ja den F-Space für Schreibzugriffe "dicht" machen.
Rudolph Riedel
> Willst *du* mir wirklich erklaeren wie autoconfig funktioniert ?:-)
> Phase5 hat ein integriertes Produkt angeboten, wozu auch die
> komplette MMU Steuerung gehoert. Es wurde lokale IO/Mappings
> genauso gehandelt wie CBM in ihrer 68040 library....configdevs
> sind laut RKM/include nur fuer Zorro2/Zorro3 configs vorgesehen.
Hey Wonderboy, bring` mir mal die RAD zum laufen!
Auf meinem A500 hat die einen Reset noch überlebt,
auf der tollen P5 Hardware im A1200 aber leider nie,
soviel zum Verständnis von Auto-Config von P5...
Darum ist mein RAM auch ab $78000000 eingebunden,
obwohl es da nach CBM nichts zu suchen hat...
Und jetzt sag` noch mal, Du wüsstest, was Auto-Config ist.
Rudolph
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
>
>> Tja..nur zu dumm, dass diese Script Kontroller auch Strukturen im Ram
>> benoetigen, *vor* der 680x0.library initialisierung und da hilft dir
>> CachePre/PostDMA nicht die Bohne.
>
> Da ist aber auch der Cache nicht eingeschaltet und das Problem somit
> nicht existent. Code/Scripte kann ich doch nach belieben in alloziertem
> RAM plazieren.
>
Das sind dynamische Strukturen deren Inhalte sich jederzeit
aendern koennen von beiden Seiten aus.
> Ach, gibt es kein gemeinsames kommerizielles Interesse am Amiga?
>
Jedenfalls keins bzgl. MMU.
>> Als ob du das nicht auch jeden Tag machst....du entscheidest, dass du
>> xyz machst und das ist gegen die Interesse von abc irgendwo anders. Sei
>> das jetzt mit dem Auto rumfahren, "ungruener"Atomstrom, mehr Geld
>> verdienst als ein anderer, mehr zu essen hast usw.
>
> Und, trotzdem kannst Du nicht immer das tun, was nur *Dir* am besten
> passt. Man lebt "miteinander" und nicht "gegeneinander".
>
Dann wird es mal Zeit, dass du deine Lektion bzgl. "miteinander"
im Wirtschaftsprozess machst.
>>> Wie verhindest Du beim Re-Mounten eines FS aus dem RDB, dass das alte
>>> FS mit den nun unzutreffenden Mount-Parametern auf die Platte
>>> zugreift? ACTION_DIE versteht das FFS ja nicht (abgesehen von den
>>> Design-Problemen damit).
>
>> Das wird mittels Removable Handler gemacht, der eine Datenbank hat
>> bzgl. den angemeldeten removable/change handlern(die beinhalten den
>> "Filesystem" Task und die Unit der Geraetes...damit kann man *viel*
>> machen) Es werde keine Action_Dies verschickt.
>> Das hat auch alles nichts mit der device ebene zu tun.
>
> Nicht ganz, was ich fragen wollte. Ich meinte eigentlich eher: "Wie
> kannst Du sicher verhindern, dass ein "nicht mehr benötigtes"
> Filing-System auf- grundeiner Race-Condition trotzdem nicht ein
> CMD_WRITE verschickt?"
>
Wenn du eine Writeoperation durchfuehrst waehrend du ein Medium
wechselst, wird entweder die schreiboperation fehlschlagen wegen
scsi fehler oder das filesystem wird vorher von einem changeint
benachrichtigt.
Es passiert genau das gleich wie wenn du eine Floppy im Betrieb
entfernst. Ich denke mal nicht das du das meinst.
Wenn du meinst was passiert wenn irgendwer eine schreiboperation
auf einem filesystem durchfuehren will, dessen volume gerade nicht
im system ist....dann wird diese halt von DOS wieder verlangt.
es werden dort keine filesysteme manuell rausgekicket, action_die
verschickt usw....
es basiert alles auf dem removeable/changeint system, mit einer
kontextabhaenigen "Benachrichtigung", einem mounter der neue
volumes mit alten in der doslist vergleicht und jenachdem diese
unterschiedlich behandelt...und halt auch namenkonflikte loesst
wenn noetig.
>>> Ich kann Dir nur sagen, was ich gesehen habe - DoIO() hing definitiv
>>> nach Einlegen eines anderen Mediums. Das Problem ließ sich dadurch
>>> umgehen, dass das Gerät von Hand geschlossen und neu geöffnet wurde -
>>> eigentlich unsinnig, wenn man nur ein paar SCSI-Kommandos absetzen
>>> will.
>
>> wie gesagt...es gibt dort kein locking protokoll, was mit einem
>> filesystem usw. zu tun hat.
>
> Dann weiß ich auch nicht, was dort passiert ist.
>
ich wuerde in dem fall auf eine reselection schliessen, die
nicht beantwortet wird.
>>>> kann gut sein, dass es vielleicht in einer "reselection" war und das
>>>> geraet sich nicht wieder "zurueckmeldet".
>>>
>>> Wird bei OpenDevice() irgendwas auf SCSI-Ebene abgesetzt? Ein INQUIRY
>>> mach' ich selbst. Irgendwas anderes? Start/Stop Unit vielleicht?
>
>> nein...Es wird einmal(oder auf bedarf) die scsi units gescanned und
>> dann greift OpenDevice() auf die interne unit datenbank zu.
>
> Gescannt bedeutet: Absetzen von "TEST UNIT READY?"
>
inquiry,testunitready,capacity,modesense....alles was man braucht.
>>> Nur bist Du nicht Apple, der Kundenstamm ist um ein paar Größen-
>>> ordnungen kleiner, steckt sehr viel tiefer in der Hardware, und will
>>> besser umworben sein. Bildlich gesprochen: Ich befürchte, Du
>>> vergleichst
>>> *Äpfel* mit Birnen. (-;
>
>> Ich wollte dir nur klarmachen, dass es Leute/Firmen usw. gibt, die
>> gewisse strategische interessen den interessen von anderen vorzuziehen.
>
> Ok, fein. Was sind demnach Deine strategischen Interessen?
>
Die habe ich wohl hinreichend dargelegt
Thomas Richter
>> Da ist aber auch der Cache nicht eingeschaltet und das Problem somit
>> nicht existent. Code/Scripte kann ich doch nach belieben in alloziertem
>> RAM plazieren.
> Das sind dynamische Strukturen deren Inhalte sich jederzeit
> aendern koennen von beiden Seiten aus.
Sicher, aber trotzalledem gibt es vor dem Einbinden der 680x0-Libs kein
Problem, da kein Caching. (-:
> > Ach, gibt es kein gemeinsames kommerizielles Interesse am Amiga?
> Jedenfalls keins bzgl. MMU.
Ich korrigiere: "Deiner Einschätzung nach gibt es kein..."
Ich befürchte fast, Du bist hier einer kleinen Fehleinschätzung
aufgelaufen.
Wie dem auch sei: Es ist nicht so, dass Du etwas zu verlieren hättest.
>> Und, trotzdem kannst Du nicht immer das tun, was nur *Dir* am besten
>> passt. Man lebt "miteinander" und nicht "gegeneinander".
> Dann wird es mal Zeit, dass du deine Lektion bzgl. "miteinander"
> im Wirtschaftsprozess machst.
Schau mal, wir wissen, dass Du eine Menge schlechter Erfahrung hast
machen müssen. Ich glaube dennoch nicht, dass Du in diesem Falle
irgendetwas zu verlieren hättest - es gibt nur etwas zu gewinnen.
Ich verstehe wirklich nicht das Problem - was würde denn im schlimmsten
Falle Deiner Meinung nach passieren, was Du unbedingt vermeiden
möchtest?
>>> Das wird mittels Removable Handler gemacht, der eine Datenbank hat
>>> bzgl. den angemeldeten removable/change handlern(die beinhalten den
>>> "Filesystem" Task und die Unit der Geraetes...damit kann man *viel*
>>> machen) Es werde keine Action_Dies verschickt.
>>> Das hat auch alles nichts mit der device ebene zu tun.
>>
>> Nicht ganz, was ich fragen wollte. Ich meinte eigentlich eher: "Wie
>> kannst Du sicher verhindern, dass ein "nicht mehr benötigtes"
>> Filing-System auf- grundeiner Race-Condition trotzdem nicht ein
>> CMD_WRITE verschickt?"
> Wenn du eine Writeoperation durchfuehrst waehrend du ein Medium
> wechselst, wird entweder die schreiboperation fehlschlagen wegen
> scsi fehler oder das filesystem wird vorher von einem changeint
> benachrichtigt.
In der Hoffnung, das fs macht dies alles korrekt?
> Es passiert genau das gleich wie wenn du eine Floppy im Betrieb
> entfernst. Ich denke mal nicht das du das meinst.
Eigentlich nicht, nein.
> Wenn du meinst was passiert wenn irgendwer eine schreiboperation
> auf einem filesystem durchfuehren will, dessen volume gerade nicht
> im system ist....dann wird diese halt von DOS wieder verlangt.
Dazu müsste das fs wissen, dass die augenblicklich eingelegte
Floppy nicht zu dem Volume gehört, dass das fs verwaltet. Normaler-
weise ist das ja kein Problem, aber bei besagter Konstruktion werden
ja gewissermaßen zwei fs auf der gleichen Volume gestartet.
> es werden dort keine filesysteme manuell rausgekicket, action_die
> verschickt usw....
> es basiert alles auf dem removeable/changeint system, mit einer
> kontextabhaenigen "Benachrichtigung", einem mounter der neue
> volumes mit alten in der doslist vergleicht und jenachdem diese
> unterschiedlich behandelt...und halt auch namenkonflikte loesst
> wenn noetig.
"Von Hand" in die Device-Liste, oder wird beim Auslesen des Root-Blockes
seitens des Device-Treibers "gelogen"?
>> Dann weiß ich auch nicht, was dort passiert ist.
> ich wuerde in dem fall auf eine reselection schliessen, die
> nicht beantwortet wird.
Dann ist das zumindest insofern merkwürdig, als das dieses Problem hier
noch nie aufgetreten ist. Iomega und SCSI ist eine Sache für sich, sowieso,
aber so schlimm ist's eigentlich nun auch wieder nicht.
>>> nein...Es wird einmal(oder auf bedarf) die scsi units gescanned und
>>> dann greift OpenDevice() auf die interne unit datenbank zu.
>>
>> Gescannt bedeutet: Absetzen von "TEST UNIT READY?"
> inquiry,testunitready,capacity,modesense....alles was man braucht.
Ok.
>> Ok, fein. Was sind demnach Deine strategischen Interessen?
> Die habe ich wohl hinreichend dargelegt
Ich frage mich nur, ob die von Dir dargelegten Interessen auch wirklich
mit denen von Dir verfolgten Interessen übereinstimmen. Deine Argumentation
scheint mir nämlich nur bedingt logisch, wenn ich das zugrunde lege, was
Du sagst.
Marius Schwarz
Am 28-Mai-01 schrieb Rudolph Riedel:
> la...@t-online.de (Ralph Schmidt) schrieb am 24.05.2001:
>
>> Willst *du* mir wirklich erklaeren wie autoconfig funktioniert ?:-)
> Hey Wonderboy, bring` mir mal die RAD zum laufen!
>
> Und jetzt sag` noch mal, Du wüsstest, was Auto-Config ist.
Blizzard oder Cyberstorm?
auf der Blizzard gehts wunderbar.
Bis demnächst....
Ralph Schmidt
<th...@gibbs.math.tu-berlin.de> wrote:
> Hallo Ralph,
>
>> einem filesystem durchfuehren will, dessen volume gerade nicht im
>> system ist....dann wird diese halt von DOS wieder verlangt.
>
> Dazu müsste das fs wissen, dass die augenblicklich eingelegte Floppy
> nicht zu dem Volume gehört, dass das fs verwaltet. Normaler- weise ist
> das ja kein Problem, aber bei besagter Konstruktion werden ja
> gewissermaßen zwei fs auf der gleichen Volume gestartet.
>
Deshalb ja "kontext" abhaenige Benachrichtigung.
Beispiel.
Du hast ein zip mit 2 partition gemountet und wechselst dieses und
legst dann wieder ein zip ein.
Dann meldet der removable task einen wechsel fuer alle gerade
*aktiven* FS fuer diese unit mit dem changestate ! 0...dementsprechend
wird die aktive volume vom filesystem entweder entfernt(wenn kein lock
mehr existiert) oder als no disk present behalten(soweit ich mich jetzt erinnere).
Dann ruft er den mounter auf, der jede partition mit einer im System
vergleicht...fssm,partition layout, dostype, namen usw.
Wenn die partition gleich einer existierenden dosnode ist,
wird *nur* dieses filesystem benachrichtigt.
Wenn die partition ungleich einer existierenden ist, wird dieses
filesystem neuerzeugt und wenn dabei ein Namenskonflikt
auftritt(also 2 dh0:), wird der devnode name angepasst.
Rudolph Riedel
Tach!
> > Hey Wonderboy, bring` mir mal die RAD zum laufen!
> >
> > Und jetzt sag` noch mal, Du wüsstest, was Auto-Config ist.
>
> Blizzard oder Cyberstorm?
Blizzard 1230, jetzt 1240
> auf der Blizzard gehts wunderbar.
Ja, im CHIP. Aber wofür habe ich denn 32 MB FAST auf der Karte?
Also sorry, gleiche Baustelle anderes Problem.
Gruss, Rudolph
P.S:Wo wir schon bei Problemen sind, wie kann man doch gleich die
Blizzard abschalten? "2"? Funktioniert zumindest nicht mit meinem
Tastatur-Adapter.
Mit Reset-per-Soft hatte ich andererseits noch nie Probleme.
Andreas Berger
> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis
> gesichert hat und mit ihren Entwicklungen Standards gesetzt
> hat(CGFX).
Hm, ich habe im Januar 95 bei Frank Mariak die CGFX-share
bezahlt, AFAIK war es da (noch?) kein Phase5 Produkt (... ihren
Entwicklungen ...).
Ansonsten finde ich es Schade, das sich zwei Personen "hauen",
die beide derzeit eine Menge für den Classic schaffen.
regards, Andreas
Ralph Schmidt
<Andreas...@de.bosch.com> wrote:
> Halli-Hallo,
>
>> Fakt ist, dass P5 seit CBM's Untergang die Amiga HW Basis gesichert hat
>> und mit ihren Entwicklungen Standards gesetzt hat(CGFX).
>
> Hm, ich habe im Januar 95 bei Frank Mariak die CGFX-share bezahlt, AFAIK
> war es da (noch?) kein Phase5 Produkt (... ihren Entwicklungen ...).
>
Die CGFX Entwicklung wurde praktisch mit der CV64 finanziert und dessen
Entwicklung wurde irgendwann Sommer 94 eingeleitet. Bis die CV64 fertig
war wurde auf der PII,Spectrum usw. entwickelt.
Die 3.x war dann Teil des PowerUP/PPC Projektes, dass leider einen
anderen Verlauf nahm.
Nachdem es sich nicht mehr finanziell gelohnt hat, wurde dann die 4.x
ueber Ossowski vertrieben und die 5.x ist Teil von MorphOS.
> Ansonsten finde ich es Schade, das sich zwei Personen "hauen", die beide
> derzeit eine Menge für den Classic schaffen.
>
*Ich* haue mich nicht mit ihm:-)
Thomas Richter
> Tach!
Moinmoin.
>> auf der Blizzard gehts wunderbar.
> Ja, im CHIP. Aber wofür habe ich denn 32 MB FAST auf der Karte?
Wenn der Speicher nicht autokonfigurierend ist, und somit MEMF_KICK
nicht gesetzt ist, so kann da RAD: auch nicht hineingehen. Was nicht
MEMF_KICK ist, ist eben nicht reset-fest. Ich würde dann eher zu
statram.device oder vdisk.device raten. Die haben auch Macken, aber
*andere*. /-:
> Also sorry, gleiche Baustelle anderes Problem.
Kein Problem, sondern eher ein Seiteneffekt.
Rudolph Riedel
Hi!
[RAD ins FAST]
> > Ja, im CHIP. Aber wofür habe ich denn 32 MB FAST auf der Karte?
>
> Wenn der Speicher nicht autokonfigurierend ist, und somit MEMF_KICK
> nicht gesetzt ist, so kann da RAD: auch nicht hineingehen. Was nicht
> MEMF_KICK ist, ist eben nicht reset-fest.
Das ist ja genau der Punkt warum ich mich eingemischt habe,
als der Herr Schmidt meinte, er wüsste besser, was
Auto-Config bedeutet... :-)
> Ich würde dann eher zu
> statram.device oder vdisk.device raten. Die haben auch Macken, aber
> *andere*. /-:
StatRAM überlebt aber den Reset wiederrum nicht. :-(
Gibt es überhaupt eine RESET-feste RAM-disk welche mit
den Blizzard Karten funktioniert?
> > Also sorry, gleiche Baustelle anderes Problem.
>
> Kein Problem, sondern eher ein Seiteneffekt.
"Simple Design" und "Agressive Timing" waren dann ja wohl auch
zwei Trademarks von P5 oder nicht? :-)
Wobei so ein Stand-Mokel Anno `92 oder `94 auf der WOA allen
Ernstes behaupten wollte, dass sei ein Bug in der RAD...
Nur gestaltet sich die Suche nach Alternativen etwas schwierig.
Gruss, Rudolph
Ralph Schmidt
<Rudolph...@t-online.de> wrote:
> th...@gibbs.math.tu-berlin.de (Thomas Richter) schrieb am 29.05.2001:
>
> Hi!
>
> [RAD ins FAST]
>> > Ja, im CHIP. Aber wofür habe ich denn 32 MB FAST auf der Karte?
>>
>> Wenn der Speicher nicht autokonfigurierend ist, und somit MEMF_KICK
>> nicht gesetzt ist, so kann da RAD: auch nicht hineingehen. Was nicht
>> MEMF_KICK ist, ist eben nicht reset-fest.
>
> Das ist ja genau der Punkt warum ich mich eingemischt habe, als der Herr
> Schmidt meinte, er wüsste besser, was Auto-Config bedeutet... :-)
>
Lieber Rudolph Riedel...wo ist denn hier die logische Verbindung ?
Ich habe die Systemeinbindung der Blizzards nicht entwickelt.
AutoConfig(TM) bezieht sich auf die Zorro Geraete Einbindung
und nicht auf die von CBM definierten local ram Bereichen, welche
uebrigens fuer den 1200 zu spaet definiert wurden(AmigaMail Jan/Feb 93)
und dann erst "funktionell" ab 3.1.
Georg Steger
> > c003...@tu-bs.de (Marius Schwarz) schrieb am 28.05.2001:
>
> > Tach!
>
> Moinmoin.
>
> >> auf der Blizzard gehts wunderbar.
>
> > Ja, im CHIP. Aber wofür habe ich denn 32 MB FAST auf der Karte?
>
> Wenn der Speicher nicht autokonfigurierend ist, und somit MEMF_KICK
> nicht gesetzt ist, so kann da RAD: auch nicht hineingehen. Was nicht
> MEMF_KICK ist, ist eben nicht reset-fest. Ich würde dann eher zu
BlizKick (rom kick utility) hat ne Option, die das fixt.
--
Georg Steger
Rudolph Riedel
> > Das ist ja genau der Punkt warum ich mich eingemischt habe, als der Herr
> > Schmidt meinte, er wüsste besser, was Auto-Config bedeutet... :-)
>
> Lieber Rudolph Riedel...wo ist denn hier die logische Verbindung ?
> Ich habe die Systemeinbindung der Blizzards nicht entwickelt.
Ist mir doch egal, was Du mal entwickelt hast und was nicht.
Jedenfalls waren das Thema gerade Phase5 Turbo-Karten
und Auto-Config.
Nun ja, meine Phase5 Blizzard Turbo-Karten haben noch
nie Auto-Config gemacht, soviel dazu.
> AutoConfig(TM) bezieht sich auf die Zorro Geraete Einbindung
> und nicht auf die von CBM definierten local ram Bereichen, welche
AutoConfig bezieht sich auf alles, was ins System natlos
eingebunden werden muss.
Und was ist denn schon Zorro? Doch im wesentlichen sowieso nur
der 68K CPU-Bus.
> uebrigens fuer den 1200 zu spaet definiert wurden(AmigaMail Jan/Feb 93)
> und dann erst "funktionell" ab 3.1.
Schon klar, Phase5 hatte ja auch keinerlei direkten Kontakt zu CBM
sondern musste alles den "frei verfügbaren" Unterlagen entnehmen.
Wer soll das denn glauben?
Oh man, wird Zeit, das mal wieder brauchbare Hardware kommt.
Das "Eyetech" AmigaOne Board sieht soweit ja ganz gut aus.
Mal schauen, was mit der Software wird...
Auf so ganz tolle Super-Mega-Dongle Lösungen die ein P5 PPC-Board
vorraussetzen, damit ich dann PCI Slots im A1200 habe kann ich nämlich
gut verzichten.
Dazu müsste ich dann nämlich auch erstmal noch das PPC-Board kaufen.
604? Heute? Zu den Preisen? Bitte???
Wenigstens sieht das PCI-Board wesentlich aufgeräumter aus als das
von Elbox mit ihrem Dutzend IC`s...
Dann doch lieber irgendwann auf UAE umsteigen...
Rudolph
Oliver B. Warzecha
<c67e9fcd.01052...@posting.google.com>:
> Thomas Richter <th...@gibbs.math.tu-berlin.de> wrote in message news:<9evmpv$hta$1...@mamenchi.zrz.TU-Berlin.DE>...
>> nicht gesetzt ist, so kann da RAD: auch nicht hineingehen. Was nicht
>> MEMF_KICK ist, ist eben nicht reset-fest. Ich würde dann eher zu
>
> BlizKick (rom kick utility) hat ne Option, die das fixt.
Wenn das auch noch auf allen Blizzard laufen würde... (siehe auch mein
Posting)
Raphael Pilarczyk
Bet: "Re: Spass mit Blizzard-Karten..."
> "Simple Design" und "Agressive Timing" waren dann ja wohl auch
> zwei Trademarks von P5 oder nicht? :-)
Nicht wirklich. Eine Mk-2 mit CyberSCSI ist bzw. war imho die
langsamste 060/50 Karte auf dem Markt. :-)
--
PIK
Oliver B. Warzecha
Thomas Richter <th...@gibbs.math.tu-berlin.de> wrote in
<9erp6b$77t$2...@mamenchi.zrz.TU-Berlin.DE>:
> In de.comp.sys.amiga.tech Oliver B. Warzecha <o...@amarok.ping.de> wrote:
>
>> Das tut niemals nicht. Also eigentlich gar nicht. Daß Gurus auch nicht
>> wiederkommen, ist dabei übrigens impliziert...
>
> "Auch Gurus" oder "nur Gurus"? Der Reset nach einem Guru wird anders
> erzeugt als durch ColdReboot(). Leider.
Also: Gurus kommen nicht wieder. z.B. der Reset von CGXMode kommt nicht
wieder (die Power-LED blinkt dabei dauernd, das riecht nach einem
Softwareproblem). Wie gesagt, SetPatch macht einen Reset, der
funktioniert, genau wie PrepareEmul, aber letzteres nur mit
A1200-Option, sonst hängt er auch.
>> Der einzige Software-Reboot, der hier funktioniert, ist der vom SetPatch
>> V44 und auch PrepareEmul tat seinerzeit (mit A1200-Option(!)).
>
> Verwendet beides ColdReboot().
Ein kleines Programm, das ausschließlich ColdReboot() aufruft,
funktioniert *nicht*. Bildschirm wird grau, PowerLED blinkt, Bildschirm
wird schwarz. Danach bleibt er schwarz und die LED blinkt anscheinend
jeweils 6 mal, bevor eine kurze Pause eintritt.
>> Ich habe
>> BTW vor, das ROM-Mapping demnächst wieder abzuschalten, weil ich
>> MMU-Mapping einem nicht 100%ig funktionierendem Hardwarehack vorziehe.
>> Blizkick läuft nämlich auch nicht. :-( Bestünde die Möglichkeit, daß
>> MuFastROM und Blizkick die gleiche Schnittstelle zum Einbinden von
>> Zusatzmodulen verwenden könnten? ;)
>
> MuFastROM bietet gar nicht die Möglichkeit, Zusatzmodule einzubinden. (-:
Noch nicht. ;-)
> Meinst Du "LoadModule"? Ich denke, Harry arbeitet grundsätzlich anders,
> indem er die Module im per P5-Hardware umgemappten ROM im on-Board RAM
> der 2040 plaziert. LoadModule muss auf jeder Hardware laufen und ist
Eben, wenn ich nun den Vorgang "ROM remappen" abstrahiere, bleibt das
Hinzufügen oder Austauschen von Modulen, die sonst im ROM sind (oder mal
waren - A1000 Soundtest :) als Methode über, die ähnlich laufen müßte.
Harry benutzt ja auch zusätzliches RAM (EXTRESBUFFER), das man z.B. mit
der MMU schreibschützen könnte.
> somit nicht Boardspezifisch. Die Module werden einfach überladen durch
> den Exec-Resident-Tag-Mechanismus. Das geht leider *nicht* mit Exec und
> Expansion, aber mit allem anderen.
Wie bindet er denn exec V44 ein? Überschreiben des Images und reboot?
Was spräche dagegen, das auch zu machen?
> Bis dahin: Probiere doch einmal aus, *welche Programme genau* nicht
> richtig rebooten. Ich denke da in Richtung diverser "Reboot" oder
> "Reset"-Programme, die sich sicherlich in genügender Anzahl im Aminet
> finden.
Die taten alle nicht. =:-) Auch nicht die, welche einen Keyboardreset
imitieren. (Ist da bei mir eine CIA "inne Wurst"? Könnte es das sein?
Ich habe da so eine schwache Erinnerung mit Problemen vom Joystick im
Mausport...)
Thomas Richter
Hi Oliver,
In de.comp.sys.amiga.tech Oliver B. Warzecha <o...@amarok.ping.de> wrote:
>>> Das tut niemals nicht. Also eigentlich gar nicht. Daß Gurus auch nicht
>>> wiederkommen, ist dabei übrigens impliziert...
>>
>> "Auch Gurus" oder "nur Gurus"? Der Reset nach einem Guru wird anders
>> erzeugt als durch ColdReboot(). Leider.
> Also: Gurus kommen nicht wieder. z.B. der Reset von CGXMode kommt nicht
> wieder (die Power-LED blinkt dabei dauernd, das riecht nach einem
> Softwareproblem). Wie gesagt, SetPatch macht einen Reset, der
> funktioniert, genau wie PrepareEmul, aber letzteres nur mit
> A1200-Option, sonst hängt er auch.
Was insofern bemerkenswert ist, als das beide Programme (!) ColdReboot()
aufrufen, nur eben *vor* dem Einbinden eines Board-spezifischen Patches
durch die 68040.library.
>>> Der einzige Software-Reboot, der hier funktioniert, ist der vom SetPatch
>>> V44 und auch PrepareEmul tat seinerzeit (mit A1200-Option(!)).
>>
>> Verwendet beides ColdReboot().
> Ein kleines Programm, das ausschließlich ColdReboot() aufruft,
> funktioniert *nicht*.
*Vor* oder *nach* SetPatch?
> Bildschirm wird grau, PowerLED blinkt, Bildschirm
> wird schwarz. Danach bleibt er schwarz und die LED blinkt anscheinend
> jeweils 6 mal, bevor eine kurze Pause eintritt.
Offenbar ein Problem des Systems bei der Initialisierung nach Reset, hört
sich weniger nach Hardwareproblem an.
>>> Ich habe
>>> BTW vor, das ROM-Mapping demnächst wieder abzuschalten, weil ich
>>> MMU-Mapping einem nicht 100%ig funktionierendem Hardwarehack vorziehe.
>>> Blizkick läuft nämlich auch nicht. :-( Bestünde die Möglichkeit, daß
>>> MuFastROM und Blizkick die gleiche Schnittstelle zum Einbinden von
>>> Zusatzmodulen verwenden könnten? ;)
>>
>> MuFastROM bietet gar nicht die Möglichkeit, Zusatzmodule einzubinden. (-:
> Noch nicht. ;-)
Prinzipiell nicht - es geht nicht. Die Probleme sind, dass diverse Boards
gewisser Hersteller schon beim Hochstarten vor SetPatch die MMU belegen
wollen/müssen, dass exec bei der Initialisierung die TTX-Register belegt und
somit ein MMU-spezifisches Setup ausschaltet. Mit anderen Worten, der
Umfang von Hacks, die notwendig sind, um das zum Funktionieren zu bringen,
überschreitet um Größenordungen die Grenzen guten Geschmackes. "LoadModule"
ist hingegen konzeptionell "sauber".
>> Meinst Du "LoadModule"? Ich denke, Harry arbeitet grundsätzlich anders,
>> indem er die Module im per P5-Hardware umgemappten ROM im on-Board RAM
>> der 2040 plaziert. LoadModule muss auf jeder Hardware laufen und ist
> Eben, wenn ich nun den Vorgang "ROM remappen" abstrahiere, bleibt das
> Hinzufügen oder Austauschen von Modulen, die sonst im ROM sind (oder mal
> waren - A1000 Soundtest :)
Eben, kann LoadModule und auch SetPatch alles auch, und dazu braucht es kein
ROM-Image. Welchen Vorteil hätte man davon, das alles in ein Image-File zu
stecken?
> als Methode über, die ähnlich laufen müßte.
Nein, das funktioniert ganz anders...
> Harry benutzt ja auch zusätzliches RAM (EXTRESBUFFER), das man z.B. mit
> der MMU schreibschützen könnte.
Kein Problem. Wenn mir Harry dokumentiert, welchen RAM-Bereich er belegt, bzw.
wie ich das herausfinden kann, so nehme ich das in MuProtectModules oder ein
ähnliches Programm auf. Frag' doch einfach mal.
>> somit nicht Boardspezifisch. Die Module werden einfach überladen durch
>> den Exec-Resident-Tag-Mechanismus. Das geht leider *nicht* mit Exec und
>> Expansion, aber mit allem anderen.
> Wie bindet er denn exec V44 ein? Überschreiben des Images und reboot?
Ja, exakt.
> Was spräche dagegen, das auch zu machen?
Dass Harrys Lösung Board-spezifisch ist und auf bestimmte Hardware zugreift,
die ohne die MMU auch RAM-Remapping machen kann. Diese Lösung ist Board-spezifisch
und funktioniert so nur auf einigen P5-Boards. Auf einigen GVP-Boards ginge ähn-
liches, aber auf andere Weise. Auf anderen Boards geht dies zum Teil gar nicht,
weil diese Hardware nicht da ist. Der einige Faktor, auf den Mu sich verlassen
kann, ist die MMU (da überall vorhanden, wo Mu läuft). Und selbige wird einerseits
*immer* vom Exec-Init-Code initialisiert, und bei bestimmten Boards auch von
ROM-residenten 68060/ppc/68040-Bibliotheken, so dass ein irgendwie gearteter
Setup überschrieben werden würde.
Davon abgesehen, ich sehe einfach keine Notwendigkeit, ROM-Images zu verwenden,
da Exec KickTags die gleichen Fähigkeiten bieten, *bis* auf exec und expansion
selbst, die auf *etwas* andere Weise ins System gelangen. Und selbige kann
man auch von Hand überpatchen, ohne dass es eines Mega-Hacks bedarf.
>> Bis dahin: Probiere doch einmal aus, *welche Programme genau* nicht
>> richtig rebooten. Ich denke da in Richtung diverser "Reboot" oder
>> "Reset"-Programme, die sich sicherlich in genügender Anzahl im Aminet
>> finden.
> Die taten alle nicht. =:-) Auch nicht die, welche einen Keyboardreset
> imitieren. (Ist da bei mir eine CIA "inne Wurst"? Könnte es das sein?
> Ich habe da so eine schwache Erinnerung mit Problemen vom Joystick im
> Mausport...)
Glaube ich nicht, dass der CIA hinüber ist. Wenn die Maschine resetet, hat der
CIA seine Aufgabe erledigt.
Das Problem wird irgendein residentes Modul sein, dass "quer" im Rechner
liegt. Ich würde mal in der Richtung weitersuchen.
Oliver B. Warzecha
> In de.comp.sys.amiga.tech Oliver B. Warzecha <o...@amarok.ping.de> wrote:
>
>> Also: Gurus kommen nicht wieder. z.B. der Reset von CGXMode kommt nicht
>> wieder (die Power-LED blinkt dabei dauernd, das riecht nach einem
>> Softwareproblem). Wie gesagt, SetPatch macht einen Reset, der
>> funktioniert, genau wie PrepareEmul, aber letzteres nur mit
>> A1200-Option, sonst hängt er auch.
>
> Was insofern bemerkenswert ist, als das beide Programme (!) ColdReboot()
> aufrufen, nur eben *vor* dem Einbinden eines Board-spezifischen Patches
> durch die 68040.library.
Ja, ich habe vorhin mal doch ausprobiert, was das unten genannte
Minimalprogramm macht, wenn man es direkt aufruft. Die Antwort ist:
Sauber rebooten. Ui!
>> Ein kleines Programm, das ausschließlich ColdReboot() aufruft,
>> funktioniert *nicht*.
>
> *Vor* oder *nach* SetPatch?
Nach SetPatch nicht, vorher schon.
>> Bildschirm wird grau, PowerLED blinkt, Bildschirm
>> wird schwarz. Danach bleibt er schwarz und die LED blinkt anscheinend
>> jeweils 6 mal, bevor eine kurze Pause eintritt.
>
> Offenbar ein Problem des Systems bei der Initialisierung nach Reset, hört
> sich weniger nach Hardwareproblem an.
Den Eindruck habe ich inzwischen auch.
>> Noch nicht. ;-)
>
> Prinzipiell nicht - es geht nicht. Die Probleme sind, dass diverse Boards
> gewisser Hersteller schon beim Hochstarten vor SetPatch die MMU belegen
> wollen/müssen, dass exec bei der Initialisierung die TTX-Register belegt und
> somit ein MMU-spezifisches Setup ausschaltet. Mit anderen Worten, der
> Umfang von Hacks, die notwendig sind, um das zum Funktionieren zu bringen,
> überschreitet um Größenordungen die Grenzen guten Geschmackes. "LoadModule"
> ist hingegen konzeptionell "sauber".
Okay, das leuchtet ein.
>> Eben, wenn ich nun den Vorgang "ROM remappen" abstrahiere, bleibt das
>> Hinzufügen oder Austauschen von Modulen, die sonst im ROM sind (oder mal
>> waren - A1000 Soundtest :)
>
> Eben, kann LoadModule und auch SetPatch alles auch, und dazu braucht es kein
> ROM-Image. Welchen Vorteil hätte man davon, das alles in ein Image-File zu
> stecken?
Die externen Erweiterungsmodule (worauf ich mich beziehe), sind ja
eben *nicht* im Image-File.
>> als Methode über, die ähnlich laufen müßte.
>
> Nein, das funktioniert ganz anders...
Ist mir schon klar, ich bezog mich auf das abstrakte API "einklinken",
ich habe es mir jetzt noch nicht genauer angeschaut, aber ich glaube
nicht, daß er es großartig anders macht. Er patcht (außer bei exec V44)
eben nicht wild im gemappten ROM rum, sondern belegt freie Bereiche u.ä.
oder halt auch externes RAM.
>> Harry benutzt ja auch zusätzliches RAM (EXTRESBUFFER), das man z.B. mit
>> der MMU schreibschützen könnte.
>
> Kein Problem. Wenn mir Harry dokumentiert, welchen RAM-Bereich er belegt, bzw.
> wie ich das herausfinden kann, so nehme ich das in MuProtectModules oder ein
> ähnliches Programm auf. Frag' doch einfach mal.
Werde ich tun, ich werde mich vorher nur etwas in die Problematik
einlesen.
> Davon abgesehen, ich sehe einfach keine Notwendigkeit, ROM-Images zu verwenden,
> da Exec KickTags die gleichen Fähigkeiten bieten, *bis* auf exec und expansion
> selbst, die auf *etwas* andere Weise ins System gelangen. Und selbige kann
> man auch von Hand überpatchen, ohne dass es eines Mega-Hacks bedarf.
ACK.
>> Die taten alle nicht. =:-) Auch nicht die, welche einen Keyboardreset
>> imitieren. (Ist da bei mir eine CIA "inne Wurst"? Könnte es das sein?
>> Ich habe da so eine schwache Erinnerung mit Problemen vom Joystick im
>> Mausport...)
>
> Glaube ich nicht, dass der CIA hinüber ist. Wenn die Maschine resetet, hat der
> CIA seine Aufgabe erledigt.
>
> Das Problem wird irgendein residentes Modul sein, dass "quer" im Rechner
> liegt. Ich würde mal in der Richtung weitersuchen.
VirusZ-2 sagt:
ROMTag at $0EF6E9D8 is called 'LastGuru.rendezvous'
ROMTag at $0EF6F360 is called 'console 44.6 (31.3.2000)'
ROMTag at $0EF7331A is called 'ram 44.21 (2.9.2000)'
ROMTag at $0EF75760 is called 'IDE_scsidisk 43.35 (28.12.99)'
ROMTag at $0EF79270 is called 'filesysres 45.7 (17.9.2000)'
ROMTag at $0EF794AE is called 'fs 45.9 (3.9.2000)'
ROMTag at $0EF7FB38 is called 'ROMUpdate 44.26 (17.9.2000)'
ROMTag at $00009330 is called 'MuMove4K 40.19 (10.2.2001) © THOR'
ROMTag at $001FFB8A is called '2060-BootPrefs0'
Über die Qualität des ersteren weiß ich nix, werde das aber mal
versuchsweise rauswerfen. Ich werde wohl auch mal mit LoadModule
rumhantieren, das IDEscsi 43.35 brauche ich im A2k nicht wirklich.
In der KickMemPtr-Liste sind 10 Einträge, leider kenne ich mit diesem
Kram nicht so aus, ich tippe auf 1 Eintrag pro ROMTag, und was ist
dann der 10.?
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> > Davon abgesehen, ich sehe einfach keine Notwendigkeit, ROM-Images zu verwenden,
> > da Exec KickTags die gleichen Fähigkeiten bieten, *bis* auf exec und expansion
> > selbst, die auf *etwas* andere Weise ins System gelangen. Und selbige kann
> > man auch von Hand überpatchen, ohne dass es eines Mega-Hacks bedarf.
>
> ACK.
"Die schon wieder." ;-)
Einerseits:
Warum sollte man beim Start mit etlichen Modulen rumhantieren,
statt einfach mit dem entsprechenden Kickfile - 4 Stueck ohne
A500/A600 - zu booten? Mega-Hacks? patchproggi FROM "alterkick"
WITH "patchdatei" TO "devs:kickfile" (anschliessend neue Checksum
berechnet) und die Sache mit der exec44 war erledigt. Kein Blizkick
notwendig, habe auch sonst keine einzige Zeile in der s-s aendern
muessen.
So stell ich mir uebrigens einen Update vor und nicht den
Heckmeck den Wrobel momentan, zugegeben notgedrungen, mit Setpatch
veranstaltet.
Ich kann jetzt auch u.U. paar Sachen aus dem ROM update 'extrahieren'
um es mit LoadModule wieder in den Kick 'reinhauen'. Das ist zwar
eine Moeglichkeit, aber ist das auch eine Loesung? Alleine das
'extrahieren' ist fuer einen USER momentan nicht wirklich
"handhabbar"...
Andererseits:
Es ist klar, dass das Ganze im Gegensatz zu "von Hand ueberpatchen"
nur auf ausgewaehlter Hardware laeuft. Eng gesehen ist aber
jetzt schon die GUTE Arbeit von Piru rechtlich fraglich.
Ob er einfach eine exec.library fuer Thors "von Hand ueberschreiben"
bereitstellen kann und darf ist eine noch unbeantwortete Frage.
Das alles ist aber kein Grund um gleich mit "Mega-Hacks" um sich
zu schmeissen. Falls man sein Kickfile nicht mit Blizkick laedt,
hat die exec44 mit Blizkick ueberhaupt nichts zu tun und der
gepatchte Kick funzt mit jedem Loader der beim User auch schon
vorher funktionierte.
--
PIK
Thomas Richter
> Abs: o...@amarok.ping.de (Oliver B. Warzecha)
> Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Warum sollte man beim Start mit etlichen Modulen rumhantieren,
Weil sie zum Booten gebraucht werden?
> statt einfach mit dem entsprechenden Kickfile - 4 Stueck ohne
> A500/A600 - zu booten?
Weil es keine konsistente Methode gibt, das auf wirklich jedem
Amiga sauber zum Laufen zu bekommen?
> Mega-Hacks? patchproggi FROM "alterkick"
> WITH "patchdatei" TO "devs:kickfile" (anschliessend neue Checksum
> berechnet) und die Sache mit der exec44 war erledigt.
Nein, die Probleme fangen dann erst an. Zum an-die-Wand Hängen sind
Kick-Images auch zu schade. Also, was machst Du damit?
> Kein Blizkick
> notwendig, habe auch sonst keine einzige Zeile in der s-s aendern
> muessen.
Erzähle das Usern ohne Cybermap, etc, etc.
> So stell ich mir uebrigens einen Update vor und nicht den
> Heckmeck den Wrobel momentan, zugegeben notgedrungen, mit Setpatch
> veranstaltet.
SetPatch funktioniert wie LoadModule "sauber", dazu braucht man nichts
zu patchen. Und es läuft auch auf jedem Board, modulo Bugs, die jeder
mal einbaut.
> Ich kann jetzt auch u.U. paar Sachen aus dem ROM update 'extrahieren'
> um es mit LoadModule wieder in den Kick 'reinhauen'. Das ist zwar
> eine Moeglichkeit, aber ist das auch eine Loesung?
Für das Problem, ältere ROM-Module durch neuere so zu ersetzen, dass
es auf jedem Amiga problemlos läuft - ja.
> Alleine das
> 'extrahieren' ist fuer einen USER momentan nicht wirklich
> "handhabbar"...
Brauchst Du ja nicht. SetPatch tut es auch - automatisch. Wie man die
Files nun aufhebt, ist eigentlich egal. "AmigaOs ROM-Update" kann
nun wirklich jeder leicht handhaben. Packe es in DEVS: und es geht.
> Andererseits:
> Es ist klar, dass das Ganze im Gegensatz zu "von Hand ueberpatchen"
> nur auf ausgewaehlter Hardware laeuft. Eng gesehen ist aber
> jetzt schon die GUTE Arbeit von Piru rechtlich fraglich.
Ja.
> Ob er einfach eine exec.library fuer Thors "von Hand ueberschreiben"
> bereitstellen kann und darf ist eine noch unbeantwortete Frage.
Wie ich bereits sagte, LoadModule *kann* exec nicht ersetzen. Und ich
will wirklich kein Programm bereitstellen, dass dies kann - dies er-
fordert etwa den gleichen Patch-Aufwand, wie ein Image mittels MMU
bereitzustellen; ohne mich. Ich will sowas nicht debuggen, ge-
schweige denn mir Konflikte anhören müssen, "läuft nicht mit Programm
ABC, was ich bislang verwendete".
> Das alles ist aber kein Grund um gleich mit "Mega-Hacks" um sich
> zu schmeissen. Falls man sein Kickfile nicht mit Blizkick laedt,
> hat die exec44 mit Blizkick ueberhaupt nichts zu tun und der
> gepatchte Kick funzt mit jedem Loader der beim User auch schon
> vorher funktionierte.
Oder eben auch nicht... ...ob es einen solchen Loader gibt, wage ich
auch sehr zu bezweifeln.
Oliver B. Warzecha
<12...@js.dhis.org>:
>
> Da Hardware Reset per KeyBoard tut: Einfach benutzen ;-)
[snip]
> RUN <>NIL: PatchColdReboot
> Als *erste* Zeile in die startup-sequence, *vor* SetPatch.
Done.
Soweit keine Änderung. Bis zu dem Punkt, wo der Rechner einen wirklichen
Kaltstart machen sollte, also aus dem aus- in den eingeschalteten
Zustand übergehen sollte. Da kam er dann noch genau bis zum SetPatch und
stand dann beim Versuch des Resets.
Undone.
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> > statt einfach mit dem entsprechenden Kickfile - 4 Stueck ohne
> > A500/A600 - zu booten?
>
> Weil es keine konsistente Methode gibt, das auf wirklich jedem
> Amiga sauber zum Laufen zu bekommen?
Bingo. Gibt es aber vielleicht eine INkonsistente Methode
die auf wirklich jedem Amiga funzt?
Wenn Du Dir dabei noch Gedanken ueber A500 und A600 machst, dann
tuts mir echt leid. Wehe Du schimpfst nochmal ueber den A20 Gate
im Pentium4. ;)
> Nein, die Probleme fangen dann erst an. Zum an-die-Wand Hängen sind
> Kick-Images auch zu schade. Also, was machst Du damit?
Ich boote damit. Fuer etwas anderes haette ich momentan eh keine
Zeit. Wenn es aber wieder regnet werde ich es auf meine
unzaehligen DD-Disketten kopieren und damit Fussgaenger
bewerfen.
> Erzähle das Usern ohne Cybermap, etc, etc.
Aha. (s.u.)
> Wie ich bereits sagte, LoadModule *kann* exec nicht ersetzen. Und ich
> will wirklich kein Programm bereitstellen, dass dies kann - dies er-
> fordert etwa den gleichen Patch-Aufwand, wie ein Image mittels MMU
> bereitzustellen; ohne mich. Ich will sowas nicht debuggen, ge-
> schweige denn mir Konflikte anhören müssen, "läuft nicht mit Programm
> ABC, was ich bislang verwendete".
Ausser devs:ROM Module ist SetPATCH zum FLICKEN da, richtig?
Nicht flicken ist wohl immer besser als konform flicken.
Heinzle macht es mit einem 60KB Setpatch, der dann jeden einzelnen
Byte der Exec ueberpatcht, also besser? Na dann, nur zu. Wo bleibt er?
Ist eine neue Exec denn ueberhaupt 'entfernt geplant'?
Und was kostet mich das dann? 90DM wie beim 'upgradepatch' von 3.5
auf 3.9?
Was gibt es da also zu meckern? Eigeninitiative muesstest Du doch
selbst kleinwenig schaetzen, oder? Du kannst es nicht, Heinzle soll
es nicht und Piru hatte mal eben Zeit. Was solls. Zaubern kann er
auch nicht, es funzt also nur auf Rechnern auf welchen Kickloader
funzen. Es muss ja nicht Blizkick sein.
Solange man keine bessere Methode liefern kann und einem
ueberhaupt keine einfaellt, sollte man den Ball flach halten.
> SetPatch funktioniert wie LoadModule "sauber", dazu braucht man
> nichts zu patchen.
Dann frage ich mich warum es SetPatch heisst. #-)
Gepatcht habe ich aber auch nichts. Ich habe nur ein neues
Kickfile erstellen lassen. Muss man nur 1x tun.
Jetzt mal eine Frage: Ist es wirklich soviel komplizierter (mit Mu!)
Kick von der Platte nach FastRAM zu laden UND neu booten?
> Und es läuft auch auf jedem Board, modulo Bugs, die jeder
> mal einbaut.
Das ist ja auch nicht das Thema, weil es bei Exec und Expansion
so eh nicht geht. Eben DAS ist das Thema.
> > und der gepatchte Kick funzt mit jedem Loader der beim User
> > auch schon vorher funktionierte.
>
> Oder eben auch nicht... ...ob es einen solchen Loader gibt, wage ich
> auch sehr zu bezweifeln.
Was habe ich geschrieben?
--
PIK
Thomas Richter
> Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
>> Weil es keine konsistente Methode gibt, das auf wirklich jedem
>> Amiga sauber zum Laufen zu bekommen?
> Bingo. Gibt es aber vielleicht eine INkonsistente Methode
> die auf wirklich jedem Amiga funzt?
Nein.
> Wenn Du Dir dabei noch Gedanken ueber A500 und A600 machst, dann
> tuts mir echt leid. Wehe Du schimpfst nochmal ueber den A20 Gate
> im Pentium4. ;)
Ich mach' mir Gedanken etwa um Apollo, um die MK-III und die diversen
PPC-Boards.
>> Nein, die Probleme fangen dann erst an. Zum an-die-Wand Hängen sind
>> Kick-Images auch zu schade. Also, was machst Du damit?
> Ich boote damit.
Aha, und was sagst Du Leuten, die damit nicht booten können? Wem ist
damit geholfen?
>> Wie ich bereits sagte, LoadModule *kann* exec nicht ersetzen. Und ich
>> will wirklich kein Programm bereitstellen, dass dies kann - dies er-
>> fordert etwa den gleichen Patch-Aufwand, wie ein Image mittels MMU
>> bereitzustellen; ohne mich. Ich will sowas nicht debuggen, ge-
>> schweige denn mir Konflikte anhören müssen, "läuft nicht mit Programm
>> ABC, was ich bislang verwendete".
> Ausser devs:ROM Module ist SetPATCH zum FLICKEN da, richtig?
Tut es ja auch.
> Nicht flicken ist wohl immer besser als konform flicken.
Nein, Fehler bereinigen ist besser als Fehler ignorieren.
> Heinzle macht es mit einem 60KB Setpatch, der dann jeden einzelnen
> Byte der Exec ueberpatcht, also besser?
Wenn er es so machen würde, wäre es besser. Momentan wird exec vom
aktuellen SetPatch nicht berührt.
> Na dann, nur zu. Wo bleibt er?
Ich bin wohl kaum der richtige Ansprechpartner, um das Erscheinungs-
datum oder den Inhalt der nächsten BB zu diskutieren. Bitte frage
bei H&P an, wenn sie etwas sagen können/wollen, werden sie es tun. Ich
kann bzw. darf nicht.
> Ist eine neue Exec denn ueberhaupt 'entfernt geplant'?
Kein Kommentar.
> Und was kostet mich das dann? 90DM wie beim 'upgradepatch' von 3.5
> auf 3.9?
Auch kein Kommentar.
> Was gibt es da also zu meckern? Eigeninitiative muesstest Du doch
> selbst kleinwenig schaetzen, oder? Du kannst es nicht, Heinzle soll
> es nicht und Piru hatte mal eben Zeit. Was solls. Zaubern kann er
> auch nicht, es funzt also nur auf Rechnern auf welchen Kickloader
> funzen. Es muss ja nicht Blizkick sein.
Ja, und? Das hilft *mir* nicht. Ich kann MMU-Schutz für Harry's
ROM-Image anbieten, wenn er mag. MuFastRom mit optionalem
Kickfile-Einlinken eben nicht, aus Gründen, die ich schon mehrfach
erwähnt habe. Ich wüsste auch nicht, wozu das gut sein soll und
welchen Vorteil man davon hätte.
> Solange man keine bessere Methode liefern kann und einem
> ueberhaupt keine einfaellt, sollte man den Ball flach halten.
Ich kann eine bessere Methode liefern, mir ist eine eingefallen also
schreibe ich hier. Was exec angeht, so wäre die beste, weil problemloseste
Methode, die wenigen defekten Exec-Funktionen zu überpatchen. Es gibt
keine größeren Bugs in exec, die eine neue Version meiner Ansicht nach
rechtfertigen würden. Gleiches gilt für expansion.
>> SetPatch funktioniert wie LoadModule "sauber", dazu braucht man
>> nichts zu patchen.
> Dann frage ich mich warum es SetPatch heisst. #-)
Inwieweit ist das ein Widerspruch?
> Gepatcht habe ich aber auch nichts. Ich habe nur ein neues
> Kickfile erstellen lassen. Muss man nur 1x tun.
Und, kann man das auf jedem Rechner verwenden?
> Jetzt mal eine Frage: Ist es wirklich soviel komplizierter (mit Mu!)
> Kick von der Platte nach FastRAM zu laden UND neu booten?
Ja, sonst würde ich das nicht sagen. Ich habe oben die Gründe dar-
gelegt, warum das so schwierig ist. Ich werde das nicht nochmal alles
erzählen, bitte lies' den Thread.
>> Und es läuft auch auf jedem Board, modulo Bugs, die jeder
>> mal einbaut.
> Das ist ja auch nicht das Thema, weil es bei Exec und Expansion
> so eh nicht geht. Eben DAS ist das Thema.
Welche Fehler hat denn Exec Deiner Meinung nach, die so immens wichtig
für den Betrieb sind, dass sie ein solches Vorgehen rechtfertigen würde,
und die sich nicht durch ein überpatchen der betroffenen Funktion(en)
beheben lassen würden?
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> >> Nein, die Probleme fangen dann erst an. Zum an-die-Wand Hängen sind
> >> Kick-Images auch zu schade. Also, was machst Du damit?
>
> > Ich boote damit.
>
> Aha, und was sagst Du Leuten, die damit nicht booten können? Wem ist
> damit geholfen?
Das fuer sie keine Chance besteht, weil nicht machbar? MIR ist
damit geholfen. Ist es deswegen schlecht?
> > Na dann, nur zu. Wo bleibt er?
>
> Ich bin wohl kaum der richtige Ansprechpartner
Du weisst wie ich solche Fragen meine.
> > Und was kostet mich das dann? 90DM wie beim 'upgradepatch' von 3.5
> > auf 3.9?
>
> Auch kein Kommentar.
s.o.
> > Was gibt es da also zu meckern? Eigeninitiative muesstest Du doch
> > selbst kleinwenig schaetzen, oder? Du kannst es nicht, Heinzle soll
> > es nicht und Piru hatte mal eben Zeit. Was solls. Zaubern kann er
> > auch nicht, es funzt also nur auf Rechnern auf welchen Kickloader
> > funzen. Es muss ja nicht Blizkick sein.
>
> Ja, und? Das hilft *mir* nicht.
"Dann frage bei H&P nach." Weil es dir nicht hilft, ist es fuer
mich nicht automatisch schlecht.
> MuFastRom mit optionalem Kickfile-Einlinken eben nicht, aus
> Gründen, die ich schon mehrfach erwähnt habe. Ich wüsste auch
> nicht, wozu das gut sein soll und welchen Vorteil man davon hätte.
Ich weiss. Amiga(OS) Regel Nr 1: Patchen ist das halbe Leben.
> > Solange man keine bessere Methode liefern kann und einem
> > ueberhaupt keine einfaellt, sollte man den Ball flach halten.
>
> Ich kann eine bessere Methode liefern, mir ist eine eingefallen also
> schreibe ich hier. Was exec angeht, so wäre die beste, weil problemloseste
> Methode, die wenigen defekten Exec-Funktionen zu überpatchen.
Wenn exec damit fuer euch erledigt ist, macht mal.
Ich benutze Opus5, obwohl es die WB gibt. Alle (WB-)Programme
laufen. Und?
Vielleicht dreht er noch am Scheduler oder bringt der exec bei
selbst MemPools zu benutzen. Und?
> Welche Fehler hat denn Exec Deiner Meinung nach, die so immens wichtig
> für den Betrieb sind, dass sie ein solches Vorgehen rechtfertigen würde,
> und die sich nicht durch ein überpatchen der betroffenen Funktion(en)
> beheben lassen würden?
Ich weiss. Auf dem Migel kannst du alles ueberpatchen und umbiegen.
Mittlerweile bin ich diesen Scheiss aber satt. Das ist alles.
Warum ich eine uebergepatchte Version von 1993, statt einer
neugeschriebenen, 100% kompatiblen vom Jahr 2001 - talentierte Leute,
moderne Werkzeuge, aktuelles Wissen - benutzen soll, musst du mir
erstmal erklaeren.
Nur deswegen, weil diese 'private' Version nur auf bestimmter
Hardware laeuft? Solange Leute mit einer anderen Hardware durch
eigenwillige Erweiterungen nicht *gezwungen* sind diese Version
zu benutzen, ist das vollkommen egal.
Ich kann mit meinem Linux veranstalten was ich will. Wenn irgendeine
Soft, die mit einem off. Snapshot laeuft, bei mir nicht laufen
will, ist das MEIN Problem. Leider hat AmigaOS nicht den Status
von Linux. Leider.
p.s.:
Ich warte nur bis Haage&Co es versuchen ihm an die Karre pissen.
Dann gibts PIK mal in ganz schwarz...
--
PIK
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Anstelle von LoadModule kann man sich auch ein eigenes
> "DEVS:AmigaOS ROM Update" basteln in dem nur das drin ist was man
> braucht
"Cool. Gibts dafuer ein GUI?"
--
PIK
Thomas Richter
Raphael Pilarczyk (P...@amigo.ping.de) wrote:
> > Aha, und was sagst Du Leuten, die damit nicht booten können? Wem ist
> > damit geholfen?
> Das fuer sie keine Chance besteht, weil nicht machbar? MIR ist
> damit geholfen. Ist es deswegen schlecht?
Dir ist doch schon mit Cybermap geholfen. Wo ist Dein Problem.
> > Ja, und? Das hilft *mir* nicht.
> "Dann frage bei H&P nach." Weil es dir nicht hilft, ist es fuer
> mich nicht automatisch schlecht.
Ich frage mich letztendlich, was Du eigentlich willst.... Du hast
doch ein Tool, um das ROM durch ein RAM-Image zu ersetzen.
> > MuFastRom mit optionalem Kickfile-Einlinken eben nicht, aus
> > Gründen, die ich schon mehrfach erwähnt habe. Ich wüsste auch
> > nicht, wozu das gut sein soll und welchen Vorteil man davon hätte.
> Ich weiss. Amiga(OS) Regel Nr 1: Patchen ist das halbe Leben.
Patchen ist der halbe Absturz.
> > Ich kann eine bessere Methode liefern, mir ist eine eingefallen also
> > schreibe ich hier. Was exec angeht, so wäre die beste, weil problemloseste
> > Methode, die wenigen defekten Exec-Funktionen zu überpatchen.
> Wenn exec damit fuer euch erledigt ist, macht mal.
> Ich benutze Opus5, obwohl es die WB gibt. Alle (WB-)Programme
> laufen. Und?
> Vielleicht dreht er noch am Scheduler oder bringt der exec bei
> selbst MemPools zu benutzen. Und?
Exec alloziert selbst keinen Speicher, braucht also keine MemPools. Das
ist alles Sache der Clients. Die Frage ist, ob Programme die Speicher-
verwaltungsfunktionen verwenden, und wenn, dann wie. Memory-Pools gibt
es seit 3.0 in exec integriert. Der Scheduler funktioniert auch problemlos.
PoolMem funktioniert auch, und wird weiter funktionieren.
> > Welche Fehler hat denn Exec Deiner Meinung nach, die so immens wichtig
> > für den Betrieb sind, dass sie ein solches Vorgehen rechtfertigen würde,
> > und die sich nicht durch ein überpatchen der betroffenen Funktion(en)
> > beheben lassen würden?
> Ich weiss. Auf dem Migel kannst du alles ueberpatchen und umbiegen.
> Mittlerweile bin ich diesen Scheiss aber satt. Das ist alles.
> Warum ich eine uebergepatchte Version von 1993, statt einer
> neugeschriebenen,
Wozu? Warum sollte jemand alles neu durchcompilieren? Wird dadurch
ein Byte irgendwie "neuer" und beflügelt das den Rechner irgendwie?
> 100% kompatiblen vom Jahr 2001 - talentierte Leute,
> moderne Werkzeuge, aktuelles Wissen - benutzen soll, musst du mir
> erstmal erklaeren.
Macht absolut null Unterschied. Exec ist ein Microkernel, da ist
nicht viel `drin, was sich groß verbessern ließe.
> Nur deswegen, weil diese 'private' Version nur auf bestimmter
> Hardware laeuft?
Weil ich nicht wüsste, was der Vorteil davon ist. Durch ein neu-
übersetzen des Assembler-Sources von exec wird nichts irgendwie
besser, schneller,... Relevante Bugs sind mir nicht bekannt, hier
und da ein wenig polieren, vielleicht. Nichts, was sich nicht auch
anders lösen ließe. Einen Teil davon übernimmt sowieso schon die
040/060 Lib.
> Solange Leute mit einer anderen Hardware durch
> eigenwillige Erweiterungen nicht *gezwungen* sind diese Version
> zu benutzen, ist das vollkommen egal.
> Ich kann mit meinem Linux veranstalten was ich will. Wenn irgendeine
> Soft, die mit einem off. Snapshot laeuft, bei mir nicht laufen
> will, ist das MEIN Problem. Leider hat AmigaOS nicht den Status
> von Linux. Leider.
Eher "zum Glück"...
> Ich warte nur bis Haage&Co es versuchen ihm an die Karre pissen.
> Dann gibts PIK mal in ganz schwarz...
Sprichst Du von Dir in der dritten Person?
Grüße,
Thomas
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> Exec alloziert selbst keinen Speicher, braucht also keine MemPools.
Wie laeuft das mit zB. msgports?
> Der Scheduler funktioniert auch problemlos.
Mehr aber auch nicht (1985)
> > Ich weiss. Auf dem Migel kannst du alles ueberpatchen und umbiegen.
> > Mittlerweile bin ich diesen Scheiss aber satt. Das ist alles.
...
> Macht absolut null Unterschied. Exec ist ein Microkernel, da ist
> nicht viel `drin, was sich groß verbessern ließe.
Wo steckt eigentlich der Scheduler selbst?
> > Ich kann mit meinem Linux veranstalten was ich will. Wenn irgendeine
> > Soft, die mit einem off. Snapshot laeuft, bei mir nicht laufen
> > will, ist das MEIN Problem. Leider hat AmigaOS nicht den Status
> > von Linux. Leider.
>
> Eher "zum Glück"...
L E I D E R
> > Ich warte nur bis Haage&Co es versuchen ihm an die Karre pissen.
> > Dann gibts PIK mal in ganz schwarz...
>
> Sprichst Du von Dir in der dritten Person?
Das ist ein altbekannter Trick. Davon gibts noch etliche. Mittwochs zB.
poste ich nur in ROT13. Am Wochenenden schreib ich alles rueckwaerts.
usw. usw.
--
PIK
th...@math.tu-berlin.de
> Abs: th...@math.tu-berlin.de (Thomas Richter)
> Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
>> Exec alloziert selbst keinen Speicher, braucht also keine MemPools.
> Wie laeuft das mit zB. msgports?
Ist z.B. auch eine Funktion in der amiga.lib, ein Vierzeiler. VNC alloziert
Ports seit eh' und je' gepoolt, und das seit 1990. CreateMsgPort() ist
nur was für die "Faulen", und kam auch erst später hinzu.
>> Der Scheduler funktioniert auch problemlos.
> Mehr aber auch nicht (1985)
Muss er?
>> Macht absolut null Unterschied. Exec ist ein Microkernel, da ist
>> nicht viel `drin, was sich groß verbessern ließe.
> Wo steckt eigentlich der Scheduler selbst?
In Deinem Falle in der 68060.library.
>> > Ich kann mit meinem Linux veranstalten was ich will. Wenn irgendeine
>> > Soft, die mit einem off. Snapshot laeuft, bei mir nicht laufen
>> > will, ist das MEIN Problem. Leider hat AmigaOS nicht den Status
>> > von Linux. Leider.
>>
>> Eher "zum Glück"...
> L E I D E R
Z U M G L Ü C K.
Raphael Pilarczyk
Bet: "Re: Keine 64 MByte-SIMMs in CyberStormPPC :-("
> >> Der Scheduler funktioniert auch problemlos.
>
> > Mehr aber auch nicht (1985)
>
> Muss er?
"Exec hin oder her"
> > Wo steckt eigentlich der Scheduler selbst?
>
> In Deinem Falle in der 68060.library.
Cool. ;-)
> > L E I D E R
>
> Z U M G L Ü C K.
Welche Probleme, mit denen eben auch Linux zu kaempfen hat (?),
wuerden sich dann fuer uns ergeben?
--
PIK
th...@math.tu-berlin.de
>> > Mehr aber auch nicht (1985)
>>
>> Muss er?
> "Exec hin oder her"
Ich sehe immer noch nicht, inwiefern das eine Patch-Attacke rechtfertigen soll.
>> > Wo steckt eigentlich der Scheduler selbst?
>>
>> In Deinem Falle in der 68060.library.
> Cool. ;-)
Das Problem ist die 060-FPU, mit der der exec-Scheldurer nicht klarkommt (kommen
kann). Das machen alle 68060.libraries so, insofern kann man dies in exec jetzt
auch nicht (sinnvoll) mehr ändern, da dies vorhandene Bibliotheken aushebeln
würde. Die FPU bleibt bei einem 060-Board deaktiviert, bis die 68060.library einen
neuen Scheldurer eingepatcht hat. Das ist alles zugegebenermaßen ziemlich krank,
hat man aber der Tatsache zu verdanken, dass nach Erscheinen der 060er CBM eben
schon pleite war und demnach kein neues Exec mehr kam, dass diese CPUs sinnvoll
hätte unterstützen können.
>> > L E I D E R
>>
>> Z U M G L Ü C K.
> Welche Probleme, mit denen eben auch Linux zu kaempfen hat (?),
> wuerden sich dann fuer uns ergeben?
Die, dass die Leutchen schon jetzt nicht wissen, was der Unterschied zwischen
einem dokumentierten und einem undokumentierten Feature ist. Wie soll das erst werden,
wenn hier jeder in die Sourcen blickt und dann argumentiert "steht doch so im Quell-
text".
Die, dass es dann Duzende von fast aber nicht ganz kompatiblen Versionen gibt, die
fast aber nicht ganz miteinander zusammenarbeiten können.
Ich habe schon genug Horror vor den in Umlauf befindlichen Patches. Wie soll das
erst werden, wenn Programm xyz mit Version 47.123a, aber nicht mehr mit 48.32.23c
zusammenarbeitet, weil jemand eine "nette Idee" gehabt hat, aber die Konsequenzen
(wie so oft) nicht übersehen hat.
Es bedarf eines Mindestmaßes an Kontrolle über den Code von einer Organisation, die
kontrolliert Quellcode-Teile herausgibt und die Qualitätskontrolle durchführt. Das
muss nicht H&P oder irgendein anderer kommerzieller Anbieter sein, es kann genauso
eine Usergemeinschaft sein, oder wäre mir sogar lieber so. Aber GPL erlaubt genau
das nicht.
Raphael Pilarczyk
Bet: "Re: Open (Re: Keine 64 MByte-SIMMs...)"
> >> Muss er?
>
> > "Exec hin oder her"
>
> Ich sehe immer noch nicht, inwiefern das eine Patch-Attacke
> rechtfertigen soll.
Und? Soll ich MIR jetzt dafuer die Schuld geben?
> Das ist alles zugegebenermaßen ziemlich krank, hat man aber der
> Tatsache zu verdanken, dass nach Erscheinen der 060er CBM eben
> schon pleite war und demnach kein neues Exec mehr kam, dass
> diese CPUs sinnvoll hätte unterstützen können.
D.h. aber nicht, dass kein neues Exec kommen kann. Oder es kann
wirklich nicht?
> > Welche Probleme, mit denen eben auch Linux zu kaempfen hat (?),
> > wuerden sich dann fuer uns ergeben?
>
> Die, dass die Leutchen schon jetzt nicht wissen, was der
> Unterschied zwischen einem dokumentierten und einem undokumentierten
> Feature ist.
Was ist ein "undokumentierter Feature" und warum gibt es sowas?
Da man ja wieder am OS&Co bastelt, sollte man vielleicht einmal
bestimmen wozu es gut ist und dem Teil die ganze 'Undokumentiertheit'
nehmen (?)
> Wie soll das erst werden, wenn hier jeder in die Sourcen blickt und
> dann argumentiert "steht doch so im Quelltext".
Na wenn es denn in der Tat so im Quelltext steht, dann kann es
nicht falsch sein. Sonst bitte die Sources erst veroffentlichen,
wenn sie nichts mehr 'falsches' enthalten. :)
> Die, dass es dann Duzende von fast aber nicht ganz kompatiblen
> Versionen gibt
Was interessiert mich was dutzende oder hunderte Verrueckte, jeder
fuer sich, mit dem OS machen?? Solange es eine off. Seite gibt
wo man die off. gepflegten Versionen saugen kann ist alles ok!
Verwende ich andere Versionen und bekomme dann erst Probleme,
muss ich damit entweder leben, eine Bugmeldung an den 'wild
developer' machen oder die off. Teile des OS verwenden.
Benutzt jemand inoff. Teile und schickt Bugmeldungen - angebliche
oder echten - an die Entwickler des off. Ports, so sind die Entwickler
verpflichtet sie direkt nach NIL schicken.
Entweder ist etwas 100% zu dem off. Port kompatibel oder es ist
inkompatibel. Es ist (erst) inkompatibel, wenn es Probleme bereitet
die mit einer off. Version nicht auftretten. Fertig.
Was gibts da ueberhaupt zu jammern?
Solange es eine Koordination und eine off. Quelle gibt, kann jeder
damit machen und tun was er will (solange er damit kein Geld
verdient).
--
PIK
Joerg Hintze
Thema : Re: Keine 64 MByte-SIMMs in CyberStormPPC :-(
> Macht absolut null Unterschied. Exec ist ein Microkernel, da ist
> nicht viel `drin, was sich groß verbessern ließe.
Da scheint der Autor von BlizKick ganz anderer Meinung zu sein.
--
Gruß aus Berlin
Joerg Hintze Zconnect -> <Joerg....@Constellation.Nshift.De>
Internet -> <Joerg....@Debitel.Net>
=============================================================================
... PURITANER: Jemand der hoellische Angst davor hat,dass irgendwo irgendwer
Spass haben koennte !
=============================================================================
th...@math.tu-berlin.de
>> Ich sehe immer noch nicht, inwiefern das eine Patch-Attacke
>> rechtfertigen soll.
> Und? Soll ich MIR jetzt dafuer die Schuld geben?
Du vertrittst doch hier die Auffassung, dass ein Exec-Ersatz zwingend
notwendig ist. Ich nicht.
>> Das ist alles zugegebenermaßen ziemlich krank, hat man aber der
>> Tatsache zu verdanken, dass nach Erscheinen der 060er CBM eben
>> schon pleite war und demnach kein neues Exec mehr kam, dass
>> diese CPUs sinnvoll hätte unterstützen können.
> D.h. aber nicht, dass kein neues Exec kommen kann. Oder es kann
> wirklich nicht?
Es heisst, dass es sinnlos ist, den bestehenden Scheldurer in ROM-Exec
zu ersetzen, da dieser durch den in der 68060.library (und zwar in allen
mir bekannten Implementierungen dieser Library) wieder plattgemacht wird.
Mit Executive hatte ich auch keine rein positiven Erfahrungen.
>> Die, dass die Leutchen schon jetzt nicht wissen, was der
>> Unterschied zwischen einem dokumentierten und einem undokumentierten
>> Feature ist.
> Was ist ein "undokumentierter Feature" und warum gibt es sowas?
Das sind solche Dinge wie "AllocMem() setzt das Z-Flag, falls kein
Speicher vorhanden ist" oder "ein Gadget, dass im Bereich des Fensterrahmens
sitzt, wird beim Fensterrahmenrefresh auch ohne korrekt gesetzte Gadget-Flags
wie ein Rahmengadget behandelt", oder "der Systemfont ist topaz.8". Dinge, die
zwar in der augenblicklichen Implementation korrekt sind, aber die nicht
dokumentiert wurden, und die darum auch nicht angenommen werden dürfen, da sie
geändert werden können. Mit anderen Worten, Programme, die sich auf derartige
Dinge verlassen, werden dann auf Probleme stoßen, sobald neue Versionen der
betreffenden Os-Routinen erscheinen. Es gibt im Augenblick schon eine ganze
Menge derartiger Work-Arounds im Os.
> Da man ja wieder am OS&Co bastelt, sollte man vielleicht einmal
> bestimmen wozu es gut ist und dem Teil die ganze 'Undokumentiertheit'
> nehmen (?)
Um Himmelswillen! Je mehr man dokumentiert, desto mehr wird die
Os-Implementierung festgezurrt, und desto weniger kann man später daran ändern,
etwa um die Implementierung zu verbessern. Ein Beispiel: Hätte man nie die
exec-Speicherverwaltung dokumentiert, so hätte man diese schon längst durch
eine bessere ersetzen können. Hätte man nie den Inhalt eines FileHandles
und eines FileLocks und der dos.library dokumentiert, hätte man unter 2.0 die
BPTR gänzlich aus dem Os verbannen können. Hätte man nie einige Innerereien
der graphics.library dokumentiert, so wäre RTG nicht so haarig, wie es jetzt
ist, und V37 hätte weitaus weniger Absonderlichkeiten in Graphics. Einige
der neuen V37-Features wie "Monitor-Treiber" wurden erst dadurch möglich, dass
etwa "ColorMaps" nie dokumentiert wurden(!). ViewPorts, Views etc. hätten nie
so dokumentiert werden dürfen, man hätte dafür Konstruktor-, Destruktor- und
Zugriffsfunktionen bauen müssen.
Ein Os muss eine Schnittstelle(!) definieren, keine Implementierung.
AmigaOs geht hier teilweise viel zu weit mit der Dokumentation von Internas,
die nur zukünftigen Entwicklungen im Wege standen und stehen.
>> Wie soll das erst werden, wenn hier jeder in die Sourcen blickt und
>> dann argumentiert "steht doch so im Quelltext".
> Na wenn es denn in der Tat so im Quelltext steht, dann kann es
> nicht falsch sein.
Nicht falsch, aber "es geht niemanden was an" und ist "subject to change".
> Sonst bitte die Sources erst veroffentlichen,
> wenn sie nichts mehr 'falsches' enthalten. :)
Du verstehst offenbar das Problem bei der Konstruktion eines Os nicht ganz...
>> Die, dass es dann Duzende von fast aber nicht ganz kompatiblen
>> Versionen gibt
> Was interessiert mich was dutzende oder hunderte Verrueckte, jeder
> fuer sich, mit dem OS machen?? Solange es eine off. Seite gibt
> wo man die off. gepflegten Versionen saugen kann ist alles ok!
So, und erwartest Du, dass dies passiert? Wir haben jetzt schon einige
duzend "bessere" Ersatz-Systemlibraries, die teilweise fast, aber nicht
ganz kompatibel sind. Glaubst Du wirlich, dass User immer nur die offizielle
Version verwenden werden, und sich nicht beschweren, wenn es als solche nicht
erkannte Kompatibilitätsprobleme mit angeblich so "kompatiblen" und "so viel
besseren" Ersatz-Ossen gibt. Ich erinnere mal an die Mathe-Bibliotheken und
so einige Patches mit der mathffp.library - wo die FPU eingesetzt wird, ohne
dass sich besagte Autoren über die daraus entstehenden Konsequenzen im Klaren
sind, und auch nicht sein können, *weil* dies Internas betrifft, die nie
dokumentiert wurden. Dieses Problem wird noch sehr viel schlimmer, wenn man
ohne Kontrolle das gesamte Os offenlegt.
> Verwende ich andere Versionen und bekomme dann erst Probleme,
> muss ich damit entweder leben, eine Bugmeldung an den 'wild
> developer' machen oder die off. Teile des OS verwenden.
Aha, und das funktioniert? Das funktioniert doch jetzt schon nicht...
> Benutzt jemand inoff. Teile und schickt Bugmeldungen - angebliche
> oder echten - an die Entwickler des off. Ports, so sind die Entwickler
> verpflichtet sie direkt nach NIL schicken.
Aha, und wenn man's tut, bekommt man Ärger von wegen "aber die offizielle
Version ist doch sooo viel langsamer (0.1ms)" und "ich will aber nicht
die offizielle Version verwenden". Ich darf mal wieder an die Mathe-Biblio-
theken erinnern, wo es wirklich gute Gründe gibt, die Dinge so und nicht
anders zu erledigen. Reproduzierbarkeit der Ergebnisse auf verschiedener
Hardware zum Beispiel.
> Entweder ist etwas 100% zu dem off. Port kompatibel oder es ist
> inkompatibel. Es ist (erst) inkompatibel, wenn es Probleme bereitet
> die mit einer off. Version nicht auftretten. Fertig.
> Was gibts da ueberhaupt zu jammern?
Es gibt schon genug Konstruktionsprobleme von AmigaOs. Ich selbst will
nicht noch mehr.
> Solange es eine Koordination und eine off. Quelle gibt, kann jeder
> damit machen und tun was er will (solange er damit kein Geld
> verdient).
Die kommerzielle Seite der Sache ist mir wurscht. Was wichtig ist, ist
eine Kontrollinstanz, die die überarbeiteten Versionen überprüft, die
Verfügbarkeit sichert, und Tests durchführen kann. Ich habe nichts dagegen,
dies von einer freien Organisation durchführen zu lassen. Ich habe nur
etwas dagegen, dies unter GPL zu stellen, da GPL dieses Vorgehen eben
nicht *einfordert*. Es bedarf einer Lizenz, die zusichert, dass ver-
änderte Versionen auch eingepflegt werden, getestet werden, etc.etc.
th...@math.tu-berlin.de
> Am 06.06.2001 schrieb th...@math.tu-berlin.de (Thomas Richter) !
> Thema : Re: Keine 64 MByte-SIMMs in CyberStormPPC :-(
>> Macht absolut null Unterschied. Exec ist ein Microkernel, da ist
>> nicht viel `drin, was sich groß verbessern ließe.
> Da scheint der Autor von BlizKick ganz anderer Meinung zu sein.
Harries Veränderungen sind eher marginaler Natur, sie verändern Exec nicht groß,
sondern fixen lediglich einige relativ irrelevante Bugs. Message-Semaphores
hat etwa niemand in den letzten zehn Jahren verwendet, geschweige denn
gemischt mit "shared access". Ich sage nicht, dass man diese Bugs nicht
fixen sollte, aber dies alles bedarf keines kompletten Ersatzes von Exec.
Das lässt sich mit einer Reihe von SetFunction() genausogut und sehr viel
weniger kritisch machen. Genau dafür ist ja SetPatch gut. Ich vermute, es
ist nicht gerade bekannt, wieviel SetPatch (auch schon vor 3.5) vom Os
überpatcht hat, um gerade derartige Bugs zu fixen.
Raphael Pilarczyk
Bet: "Re: Open (Re: Keine 64 MByte-SIMMs...)"
> Du vertrittst doch hier die Auffassung, dass ein Exec-Ersatz zwingend
> notwendig ist. Ich nicht.
Es waere schoen. Zwingend ist hier gar nichts. Sei nicht unnoetig
rhetorisch.
> > D.h. aber nicht, dass kein neues Exec kommen kann. Oder es kann
> > wirklich nicht?
>
> Es heisst, dass es sinnlos ist, den bestehenden Scheldurer in ROM-Exec
> zu ersetzen, da dieser durch den in der 68060.library (und zwar in allen
> mir bekannten Implementierungen dieser Library) wieder plattgemacht wird.
a) So, als ob alle 060 fahren wuerden...
b) Wie habt ihr das blos alle das "plattmachen" so wunderbar 100%
kompatibel und 100% gleich schnell hingekriegt? Benutzt ihr alle
die gleichen Sources?
c) Laut SCOUT ist meine exec.library genauso gross, wie wenn
ich mit einem 030 boote. Oder kann ich sie unter 060 mit
besagtem Proggi entfernen? Mal versuc..%%&_((=§"$R______
> Mit Executive hatte ich auch keine rein positiven Erfahrungen.
Ich ebenfalls nicht. Keine Frage! Dynamische Prios sind eben
eine nicht ganz einfache Sache. Meine MagicWand ist aber nicht
erwaehnenswert gross. Sonst nur 'obenerwaehnte' Vorteile.
> Ein Os muss eine Schnittstelle(!) definieren, keine Implementierung.
Keule, das mein' ich doch. Ein Programmierer soll auch die Schnittstellen
benutzen und nicht die Implementierungen nachaeffen. Wo war nochmal
das Prob? Dass es welche doch machen? Lass das IHR Problem sein.
> > Was interessiert mich was dutzende oder hunderte Verrueckte, jeder
> > fuer sich, mit dem OS machen?? Solange es eine off. Seite gibt
> > wo man die off. gepflegten Versionen saugen kann ist alles ok!
>
> So, und erwartest Du, dass dies passiert? Wir haben jetzt schon einige
> duzend "bessere" Ersatz-Systemlibraries, die teilweise fast, aber nicht
> ganz kompatibel sind.
Und? Muss "Du" jetzt beim Designen neuer Klamotten diese Libs
einbeziehen? Dann halte ich Dich fuer nicht ganz dicht. Sorry.
> Glaubst Du wirlich, dass User immer nur die offizielle Version
> verwenden werden, und sich nicht beschweren, wenn es als solche nicht
> erkannte Kompatibilitätsprobleme mit angeblich so "kompatiblen" und
> "so viel besseren" Ersatz-Ossen gibt.
s.u.
> Ich erinnere mal an die Mathe-Bibliotheken und so einige Patches
> mit der mathffp.library
Der schon wieder. Was, wenn ich Dir sage, dass er sich all das
angehoert und in die Libs einfliessen lies? Das Projekt wurde
angefangen, da stand noch nichtmal fest, ob mit 3.5 ueberhaupt
angefangen werden soll und Du selbst noch behauptet hast,
eine 060Lib wird es von Dir nie geben.
Was kuemmern Sich aber ueberhaupt irgendwelche Mathelibs?
Die muessen zum OS kompatibel sein, nicht umgekehrt.
> > Verwende ich andere Versionen und bekomme dann erst Probleme,
> > muss ich damit entweder leben, eine Bugmeldung an den 'wild
> > developer' machen oder die off. Teile des OS verwenden.
>
> Aha, und das funktioniert? Das funktioniert doch jetzt schon nicht...
Wenn man mit einem neuen OS SEHR populaere Sachen 'killt' - bsp:
reqtools, MagicMenu, MultiCX usw. - sollte man die Funktionalitaet
entweder selbst auf andere (richtige?) Weise anbieten oder SEHR
gute Gruende parat haben, warum es denn ab jetzt nicht mehr funzen
kann/darf. Bei "sehr gute Gruende" geht es um den Nutzen fuer
den User.
> > Benutzt jemand inoff. Teile und schickt Bugmeldungen - angebliche
> > oder echten - an die Entwickler des off. Ports, so sind die Entwickler
> > verpflichtet sie direkt nach NIL schicken.
>
> Aha, und wenn man's tut, bekommt man Ärger von wegen "aber die offizielle
> Version ist doch sooo viel langsamer (0.1ms)"
Wenn er eine fehlerfreie, schnellere findet soll er sie doch verwenden.
Kein Problem.
> und "ich will aber nicht die offizielle Version verwenden".
Muss er nicht. Man lebt nur einmal.
> > Entweder ist etwas 100% zu dem off. Port kompatibel oder es ist
> > inkompatibel. Es ist (erst) inkompatibel, wenn es Probleme bereitet
> > die mit einer off. Version nicht auftretten. Fertig.
> > Was gibts da ueberhaupt zu jammern?
>
> Es gibt schon genug Konstruktionsprobleme von AmigaOs. Ich selbst will
> nicht noch mehr.
Quatsch.
> > Solange es eine Koordination und eine off. Quelle gibt, kann jeder
> > damit machen und tun was er will (solange er damit kein Geld
> > verdient).
>
> Die kommerzielle Seite der Sache ist mir wurscht. Was wichtig ist, ist
> eine Kontrollinstanz, die die überarbeiteten Versionen überprüft, die
> Verfügbarkeit sichert, und Tests durchführen kann. Ich habe nichts dagegen,
> dies von einer freien Organisation durchführen zu lassen. Ich habe nur
> etwas dagegen, dies unter GPL zu stellen, da GPL dieses Vorgehen eben
> nicht *einfordert*. Es bedarf einer Lizenz, die zusichert, dass ver-
> änderte Versionen auch eingepflegt werden, getestet werden, etc.etc.
Ich sag nach wie vor: LINUX oder FreeBSD. Es funktioniert.
--
PIK
th...@math.tu-berlin.de
>> Du vertrittst doch hier die Auffassung, dass ein Exec-Ersatz zwingend
>> notwendig ist. Ich nicht.
> Es waere schoen. Zwingend ist hier gar nichts. Sei nicht unnoetig
> rhetorisch.
Ich sage wie schon oben folgendes: Der Aufwand an Hacks, der notwendig
ist, eine neue exec einzupatchen, rechtfertigt in meinen Augen nicht
den Vorteil, den man daraus ziehen kann.
>> > D.h. aber nicht, dass kein neues Exec kommen kann. Oder es kann
>> > wirklich nicht?
>>
>> Es heisst, dass es sinnlos ist, den bestehenden Scheldurer in ROM-Exec
>> zu ersetzen, da dieser durch den in der 68060.library (und zwar in allen
>> mir bekannten Implementierungen dieser Library) wieder plattgemacht wird.
> a) So, als ob alle 060 fahren wuerden...
Genug, genug.
> b) Wie habt ihr das blos alle das "plattmachen" so wunderbar 100%
> kompatibel und 100% gleich schnell hingekriegt? Benutzt ihr alle
> die gleichen Sources?
So ziemlich, ja. Die Scheduler von Ralph, Carsten, Apollo, mir sind alle
ziemlich gleich. Es muss gegenüber dem Exec-Scheldurer nur eine Kleinigkeit
verändert werden, und das ist der Stack-Frame bei FPU-Benutzung.
> c) Laut SCOUT ist meine exec.library genauso gross, wie wenn
> ich mit einem 030 boote.
Ach nee, sag' bloß? (-; Wie ich schon sagte, der Scheduler ist ja auch
in der 68060.library, und nicht der in exec.
> Oder kann ich sie unter 060 mit
> besagtem Proggi entfernen? Mal versuc..%%&_((=§"$R______
Du kannst ohne 68060.library booten. Der Grund, dass dies halbwegs normal
funktioniert, liegt darin, dass die FPU vom 68060 dann ausgeschaltet ist.
Und genau dafür ist das ROM im F-Space gut, nämlich die FPU beim Einschalten
abzuschalten, damit der alte exec Scheduler nämlich *nicht* den Bach herunter-
geht. Das hätte man auch anders machen können, hat es aber nicht.
>> Ein Os muss eine Schnittstelle(!) definieren, keine Implementierung.
> Keule, das mein' ich doch. Ein Programmierer soll auch die Schnittstellen
> benutzen und nicht die Implementierungen nachaeffen. Wo war nochmal
> das Prob? Dass es welche doch machen?
Exakt.
> Lass das IHR Problem sein.
Das allein wäre nicht das Problem. Das Problem beginnt da, wo Leute diese
Programme einsetzen, und ich Probleme suchen darf, die ich nicht zu
verantworten habe. MCP hat da gut und gerne eine Menge unnötigen Ärger
gemacht.
>> > Was interessiert mich was dutzende oder hunderte Verrueckte, jeder
>> > fuer sich, mit dem OS machen?? Solange es eine off. Seite gibt
>> > wo man die off. gepflegten Versionen saugen kann ist alles ok!
>>
>> So, und erwartest Du, dass dies passiert? Wir haben jetzt schon einige
>> duzend "bessere" Ersatz-Systemlibraries, die teilweise fast, aber nicht
>> ganz kompatibel sind.
> Und? Muss "Du" jetzt beim Designen neuer Klamotten diese Libs
> einbeziehen? Dann halte ich Dich fuer nicht ganz dicht. Sorry.
Tut mir leid, das muss man beim Design des Os, und zwar deswegen, weil
die "Kundschaft" sonst herummault von wegen "aber Os 3.9 stürzt bei mir
dauernd ab". Ich habe mittlerweile in VNC auch Workarounds gegen MCP
'drin, und wurde *heftigst* darum gebeten, diese einzubauen, obwohl das
Problem bei MCP und nicht bei mir liegt. Leider, leider, ist dies eben so.
Die Anzahl der Workarounds gegen fehlerhafte Programme in Os >2.xx ist auch
nicht unerheblich.
>> Ich erinnere mal an die Mathe-Bibliotheken und so einige Patches
>> mit der mathffp.library
> Der schon wieder. Was, wenn ich Dir sage, dass er sich all das
> angehoert und in die Libs einfliessen lies? Das Projekt wurde
> angefangen, da stand noch nichtmal fest, ob mit 3.5 ueberhaupt
> angefangen werden soll und Du selbst noch behauptet hast,
> eine 060Lib wird es von Dir nie geben.
> Was kuemmern Sich aber ueberhaupt irgendwelche Mathelibs?
> Die muessen zum OS kompatibel sein, nicht umgekehrt.
Sicher, ich will ja auch niemand einen Vorwurf daraus machen, dass
man sich nicht an Dokumente gehalten hat, die es nie gab. Hier gibt
es (oder "gab es") noch einiges zu dokumentieren. Nur ist dies eben
die typische Situation, die entsteht, wenn man nicht so genau weiß,
was man tut.
Was die 68060.library angeht: Die hätte es ohne 3.9 nie gegeben,
schließlich wurde die 2060 aus den Einkünften von 3.9 bezahlt. Insofern
danke an alle Käufer.
>> Aha, und das funktioniert? Das funktioniert doch jetzt schon nicht...
> Wenn man mit einem neuen OS SEHR populaere Sachen 'killt' - bsp:
> reqtools, MagicMenu, MultiCX usw. - sollte man die Funktionalitaet
> entweder selbst auf andere (richtige?) Weise anbieten oder SEHR
> gute Gruende parat haben, warum es denn ab jetzt nicht mehr funzen
> kann/darf. Bei "sehr gute Gruende" geht es um den Nutzen fuer
> den User.
Aha, also doch. Und wie will man das mittels GPL sicherstellen? Wie
will man sicherstellen, dass jeder 1) wirklich genau weiß, was er da
anrichtet, 2) auch wirklich genug testet. Ich will eine Lizenz, die
dies *sicherstellt*, die ein Minimum an Qualitätssicherung erzeugt,
und die 3) auch verhindert, dass sich die Sourcen in alle Welt zer-
streuen, und man nie weiß, wer jetzt was genau macht, und wer die
aktuelle Version hat. GPL wird dies nicht sicherstellen können, weil
es nicht die Zielsetzung von GPL ist.
>> Aha, und wenn man's tut, bekommt man Ärger von wegen "aber die offizielle
>> Version ist doch sooo viel langsamer (0.1ms)"
> Wenn er eine fehlerfreie, schnellere findet soll er sie doch verwenden.
> Kein Problem.
Und woher weiß L.User, was eine "fehlerfreie" Version ist? Wenn Programm
X abstürzt, woher soll man wissen, dass Library Y daran Schuld ist?
>> Es gibt schon genug Konstruktionsprobleme von AmigaOs. Ich selbst will
>> nicht noch mehr.
> Quatsch.
"Face reality". Die graphics.library ist nicht sonderlich gut durchdacht,
die dos.library ist konstruktionell zum Teil wirklich Schund, und ich
rede nicht mal nur von den BPTRn. Ich rede da z.B. von Examine() und
Softlinks. Fehlende Speicher- und Objektverwaltung tun ihr übriges.
>> Die kommerzielle Seite der Sache ist mir wurscht. Was wichtig ist, ist
>> eine Kontrollinstanz, die die überarbeiteten Versionen überprüft, die
>> Verfügbarkeit sichert, und Tests durchführen kann. Ich habe nichts dagegen,
>> dies von einer freien Organisation durchführen zu lassen. Ich habe nur
>> etwas dagegen, dies unter GPL zu stellen, da GPL dieses Vorgehen eben
>> nicht *einfordert*. Es bedarf einer Lizenz, die zusichert, dass ver-
>> änderte Versionen auch eingepflegt werden, getestet werden, etc.etc.
> Ich sag nach wie vor: LINUX oder FreeBSD. Es funktioniert.
...oder auch nicht. Frage: Wie kommt es, Linux-Distributionen von
gewissen Organisationen gepflegt werden (müssen)? Ich möchte ähnliches
für AmigaOs erreichen, eine zentrale Anlaufstelle für das Os. Ich sehe
wenig Sinn dahinter, dass wie jetzt zwei Parteien entstehen (ppc.library,
powerpc.library), die beide für sich das "Recht" auf das "richtige" AmigaOs
vereinnahmen. Genau *das* darf nicht wieder passieren. He, ich bin auch
nicht immer mit Heinz einer Meinung, meistens sogar nicht, aber dennoch ist
es besser, *mit* diesen Leuten als *gegen* diese Leute zu arbeiten, da im
Endeffekt jeder davon mehr profitiert.
Raphael Pilarczyk
Bet: "Re: Open (Re: Keine 64 MByte-SIMMs...)"
> > Es waere schoen. Zwingend ist hier gar nichts. Sei nicht unnoetig
> > rhetorisch.
>
> Ich sage wie schon oben folgendes: Der Aufwand an Hacks, der notwendig
> ist, eine neue exec einzupatchen, rechtfertigt in meinen Augen nicht
> den Vorteil, den man daraus ziehen kann.
"MDot 11s, MDot 4s".
> >> Es heisst, dass es sinnlos ist, den bestehenden Scheldurer in ROM-Exec
> >> zu ersetzen, da dieser durch den in der 68060.library (und zwar in allen
> >> mir bekannten Implementierungen dieser Library) wieder plattgemacht wird.
>
> > a) So, als ob alle 060 fahren wuerden...
>
> Genug, genug.
Genug, um an der Exec nichts zu aendern? Na dann...
> > b) Wie habt ihr das blos alle das "plattmachen" so wunderbar 100%
> > kompatibel und 100% gleich schnell hingekriegt? Benutzt ihr alle
> > die gleichen Sources?
>
> So ziemlich, ja. Die Scheduler von Ralph, Carsten, Apollo, mir sind alle
> ziemlich gleich. Es muss gegenüber dem Exec-Scheldurer nur eine Kleinigkeit
> verändert werden, und das ist der Stack-Frame bei FPU-Benutzung.
Und die Sources zu dem Exec-Scheduler kann man wo saugen? Oder
meinst Du jetzt, die 060Libs patchen NUR den Stack-Frame der
Exec bei FPU-Benutzung? Dann halte ich den Spruch, dass der Scheduler
damit in der 060Lib sitzt, fuer gewagt.
> MCP hat da gut und gerne eine Menge unnötigen Ärger gemacht.
Leute die bei mir ankamen, "hilfe! hilfe!" gerufen haben nud MCP in der
WBStartup hatten, habe ich direkt wieder nach Hause geschickt. Bis
sie es lernten. Uebrigens habe ich mir damit viel Arbeit erspart,
denn: "no MCP, no probs".
> > Und? Muss "Du" jetzt beim Designen neuer Klamotten diese Libs
> > einbeziehen? Dann halte ich Dich fuer nicht ganz dicht. Sorry.
>
> Tut mir leid, das muss man beim Design des Os, und zwar deswegen, weil
> die "Kundschaft" sonst herummault von wegen "aber Os 3.9 stürzt bei mir
> dauernd ab".
> Ich habe mittlerweile in VNC auch Workarounds gegen MCP
> 'drin, und wurde *heftigst* darum gebeten, diese einzubauen, obwohl
> das Problem bei MCP und nicht bei mir liegt.
"Sachg mal", mit was fuer einem Abs... gibst Du Dich da
ueberhaupt ab? Hast Du keine bessere Gesellschaft verdient
oder wie? Das nenn' ich einen 'Absturz'. Du baust schwachsinnige
Routinen ein, weil Leute die ihre schwachsinnige UND fehlerhafte
Soft weiter benutzen wollen, sich sonst AmigaOS3.9 (was auch immer)
nicht kaufen, weil ihre schwachsinnige Soft eben dann nicht mehr
laeuft.
Hast Du fuer eine 2060 Deinen eigenen Arsch verkauft oder wie? ;)
> > Wenn man mit einem neuen OS SEHR populaere Sachen 'killt' - bsp:
> > reqtools, MagicMenu, MultiCX usw. - sollte man die Funktionalitaet
> > entweder selbst auf andere (richtige?) Weise anbieten oder SEHR
> > gute Gruende parat haben, warum es denn ab jetzt nicht mehr funzen
> > kann/darf. Bei "sehr gute Gruende" geht es um den Nutzen fuer
> > den User.
>
> Aha, also doch.
Ja, es geht immer um den Nutzen fuer den User.
> Und wie will man das mittels GPL sicherstellen? Wie will man
> sicherstellen, dass jeder 1) wirklich genau weiß, was er da
> anrichtet, 2) auch wirklich genug testet. Ich will eine Lizenz, die
> dies *sicherstellt*, die ein Minimum an Qualitätssicherung erzeugt,
Haaalllooo. Nur der off. Port hat 1 und 2 zu erfuellen.
Der Rest der Welt macht was es will. Bei AllForFree hast Du aber
auch niemanden, der Dir erzaehlt, es ist unbedingt notwendig,
dass Vinced auf die Bugs von MCP eingeht.
> und die 3) auch verhindert, dass sich die Sourcen in alle Welt zer-
> streuen, und man nie weiß, wer jetzt was genau macht
Die Koo entscheidet welche "3rd part" Sources in das off. Projekt
einfliessen. Was kuemmert es Dich, was Eugen Hacknix mit
den Sources von AddDataTypes macht??
Eine Lizenz? Eine Lizenz ist auch nur ein Wischblatt. Und eine
wasserdichte Formulierung kuemmert nur den, der es moechte.
Sonst haette ich zB. immernoch keinen 2048bit Key...
> und wer die aktuelle Version hat.
Nur die off. aktuelle Version ist aktuell. Was gibts da zum
Teufel nicht zu verstehen?? Ob jemand seine diskfont.library 44.9
oder 46.18 bezeichnet. Interessiert DICH das?
> GPL wird dies nicht sicherstellen können, weil es nicht die
> Zielsetzung von GPL ist.
Deswegen ist es wahrscheinlich auch so unpopulaer...
> > Wenn er eine fehlerfreie, schnellere findet soll er sie doch verwenden.
> > Kein Problem.
>
> Und woher weiß L.User, was eine "fehlerfreie" Version ist?
> Wenn Programm X abstürzt, woher soll man wissen, dass Library Y
> daran Schuld ist?
Wenn ProgrammX mit der off. LibraryY laeuft? Keine Ahnung...
> >> Es gibt schon genug Konstruktionsprobleme von AmigaOs. Ich selbst will
> >> nicht noch mehr.
>
> > Quatsch.
>
> "Face reality". Die graphics.library ist nicht sonderlich gut durchdacht,
> die dos.library ist konstruktionell zum Teil wirklich Schund, und ich
> rede nicht mal nur von den BPTRn. Ich rede da z.B. von Examine() und
> Softlinks. Fehlende Speicher- und Objektverwaltung tun ihr übriges.
KLAR. "Quatsch" galt der Theorie, dass dadurch neue entstehen.
> > Ich sag nach wie vor: LINUX oder FreeBSD. Es funktioniert.
>
> ...oder auch nicht. Frage: Wie kommt es, Linux-Distributionen von
> gewissen Organisationen gepflegt werden (müssen)?
AmigaOSfree kommt ja auch nicht drum herum. Sonst macht es wirklich
keinen Sinn.
> Ich möchte ähnliches für AmigaOs erreichen, eine zentrale Anlaufstelle
> für das Os.
Ah Maann. Ich rede seit Tagen DARUEBER. :-\
> Ich sehe wenig Sinn dahinter, dass wie jetzt zwei Parteien
> entstehen (ppc.library, powerpc.library), die beide für sich das
> "Recht" auf das "richtige" AmigaOs vereinnahmen. Genau *das* darf
> nicht wieder passieren.
Richtig. Wobei wirklich schlimm waere es erst, wenn beide
Loesungen brauchbar waeren.
> He, ich bin auch nicht immer mit Heinz einer Meinung, meistens
> sogar nicht, aber dennoch ist es besser, *mit* diesen Leuten als
> *gegen* diese Leute zu arbeiten, da im Endeffekt jeder davon mehr
> profitiert.
Sicher, Teamarbeit verlangt nach 'Sozialgeist'. Beiderseits.
U.U. gibt der klevere naemlich solange nach, bis er der dumme ist.
--
PIK
th...@math.tu-berlin.de
>> > a) So, als ob alle 060 fahren wuerden...
>>
>> Genug, genug.
> Genug, um an der Exec nichts zu aendern? Na dann...
Genug, um am Exec-Scheldurer im ROM nichts mehr ändern zu können, da er
de fakto irrelevant für 060-Benutzer ist.
>> So ziemlich, ja. Die Scheduler von Ralph, Carsten, Apollo, mir sind alle
>> ziemlich gleich. Es muss gegenüber dem Exec-Scheldurer nur eine Kleinigkeit
>> verändert werden, und das ist der Stack-Frame bei FPU-Benutzung.
> Und die Sources zu dem Exec-Scheduler kann man wo saugen?
Nirgens. Man muss die richtigen Personen lieb fragen.
> Oder meinst Du jetzt, die 060Libs patchen NUR den Stack-Frame der
> Exec bei FPU-Benutzung? Dann halte ich den Spruch, dass der Scheduler
> damit in der 060Lib sitzt, fuer gewagt.
Die Änderung des Stack-Frames macht leider einen Austausch des gesamten
Schedulers notwendig, auch wenn nur ein paar Befehle geändert wurden.
>> MCP hat da gut und gerne eine Menge unnötigen Ärger gemacht.
> Leute die bei mir ankamen, "hilfe! hilfe!" gerufen haben nud MCP in der
> WBStartup hatten, habe ich direkt wieder nach Hause geschickt. Bis
> sie es lernten. Uebrigens habe ich mir damit viel Arbeit erspart,
> denn: "no MCP, no probs".
Das kannst *Du* machen, aber ein Os-Programmierer nicht, denn sonst
rennen die Kunden weg.
>> Tut mir leid, das muss man beim Design des Os, und zwar deswegen, weil
>> die "Kundschaft" sonst herummault von wegen "aber Os 3.9 stürzt bei mir
>> dauernd ab".
>> Ich habe mittlerweile in VNC auch Workarounds gegen MCP
>> 'drin, und wurde *heftigst* darum gebeten, diese einzubauen, obwohl
>> das Problem bei MCP und nicht bei mir liegt.
> "Sachg mal", mit was fuer einem Abs... gibst Du Dich da
> ueberhaupt ab? Hast Du keine bessere Gesellschaft verdient
> oder wie? Das nenn' ich einen 'Absturz'. Du baust schwachsinnige
> Routinen ein, weil Leute die ihre schwachsinnige UND fehlerhafte
> Soft weiter benutzen wollen, sich sonst AmigaOS3.9 (was auch immer)
> nicht kaufen, weil ihre schwachsinnige Soft eben dann nicht mehr
> laeuft.
Du sagst es.
> Hast Du fuer eine 2060 Deinen eigenen Arsch verkauft oder wie? ;)
Heh, klär' das mal mit Mario. Ich hatte den Leuten auf der Beta-Tester
Liste lang und breit erklärt, dass dieser Müll entsorgt werden muss.
Was daraufhin ausbrauch, war ein Wehklagen ohnegleichen. Und zuguterletzt
bestimmt derjenige die Musik, der sie bezahlt. Letztendlich waren es
doch die User, die eine 68060.library wollten - und die Kohle musste
irgendwo herkommen. Also klag' nicht, freu' Dich über das Resultat, und
der Workaround macht VNC keine Spur langsamer, schlechter oder sonst was.
>> Aha, also doch.
> Ja, es geht immer um den Nutzen fuer den User.
Inwieweit steht das im Einklang mit dem obigen?
>> Und wie will man das mittels GPL sicherstellen? Wie will man
>> sicherstellen, dass jeder 1) wirklich genau weiß, was er da
>> anrichtet, 2) auch wirklich genug testet. Ich will eine Lizenz, die
>> dies *sicherstellt*, die ein Minimum an Qualitätssicherung erzeugt,
> Haaalllooo. Nur der off. Port hat 1 und 2 zu erfuellen.
> Der Rest der Welt macht was es will.
Und wie willst Du 1) & 2) für eine offizielle Version sicherstellen,
und verhindern, dass Leute nichts mehr für den offiziellen Port tun, da
sie "so viel bessere Ideen" haben?
> Bei AllForFree hast Du aber
> auch niemanden, der Dir erzaehlt, es ist unbedingt notwendig,
> dass Vinced auf die Bugs von MCP eingeht.
Nein, aber trotzdem war es wohl notwendig, auch wenn ich es nicht
mag...
>> und die 3) auch verhindert, dass sich die Sourcen in alle Welt zer-
>> streuen, und man nie weiß, wer jetzt was genau macht
> Die Koo entscheidet welche "3rd part" Sources in das off. Projekt
> einfliessen. Was kuemmert es Dich, was Eugen Hacknix mit
> den Sources von AddDataTypes macht??
Das es dann Leute verwenden, und man letztendlich die Ohren vollge-
jammert bekommt, wenn es damit nicht mehr zusammenarbeitet. Siehe eben
MCP. Hätte man damals noch mehr Os-interne Informationen für MCP gehabt,
wären noch mehr Probleme damit aufgetaucht.
> Eine Lizenz? Eine Lizenz ist auch nur ein Wischblatt. Und eine
> wasserdichte Formulierung kuemmert nur den, der es moechte.
Lizenzen kann man lesen, und ich denke schon, dass eine gute Formulierung
letztendlich der Ausgangspunkt für die Organisation sein wird, an die man
sich gern hält. Zu dem Zeitpunkt, wo Du zum Anwalt rennst, ist es so oder
so zu spät, denn ein fähiger Rechtsverdreher wird in jedem Vertrag irgend-
ein Schlupfloch für eine miese Mache finden. Eine Lizenz sollte nichts
weiter tun als eine Nettiquette auf offizieller Ebene klarstellen.
> Nur die off. aktuelle Version ist aktuell. Was gibts da zum
> Teufel nicht zu verstehen?? Ob jemand seine diskfont.library 44.9
> oder 46.18 bezeichnet. Interessiert DICH das?
Das interessiert mich dann, wenn die 46.18 Probleme macht, die ich
in console.device 47.xx beheben muss, weil 90% der Leute eine nicht
freigegebene Version verwenden, und mir die Ohren volljammern. *DAS* ist
der Unterschied. Wenn klargestellt ist, wie vorzugehen ist, und was
offiziell und was nicht ist, und dass der Erzeuger der V46 offenbar die
Sourcen gehackt hat, so gibt es gute Argumente *gegen* die Benutzung
dieser Version, die ich bei freien Sourcen nicht habe.
>> GPL wird dies nicht sicherstellen können, weil es nicht die
>> Zielsetzung von GPL ist.
> Deswegen ist es wahrscheinlich auch so unpopulaer...
Ist es auch. Ist Dir eigentlich klar, dass Netscape dank GPL kein
kommerzielles Interesse mehr erzeugt? Keine Firma kann xxx$$$ investieren,
um dann ihre Sourcen zu verschenken, das *geht* nicht.
>> Und woher weiß L.User, was eine "fehlerfreie" Version ist?
>> Wenn Programm X abstürzt, woher soll man wissen, dass Library Y
>> daran Schuld ist?
> Wenn ProgrammX mit der off. LibraryY laeuft? Keine Ahnung...
Drum.
>> "Face reality". Die graphics.library ist nicht sonderlich gut durchdacht,
>> die dos.library ist konstruktionell zum Teil wirklich Schund, und ich
>> rede nicht mal nur von den BPTRn. Ich rede da z.B. von Examine() und
>> Softlinks. Fehlende Speicher- und Objektverwaltung tun ihr übriges.
> KLAR. "Quatsch" galt der Theorie, dass dadurch neue entstehen.
Diese Probleme oben sind gerade dadurch entstanden, dass man Dinge dokumentiert
hat, die man nicht hätte dokumentieren sollen. Dadurch haben sich genug
Leute auf diese dokumentierten Details verlassen, was das ganze Desaster
ausgelöst hat. Wie soll das erst werden, wenn jeder noch die Sourcen lesen
kann und darauf zeigen kann und sagen kann, "Ja, aber da steht doch wie's
geht?".
>> Ich möchte ähnliches für AmigaOs erreichen, eine zentrale Anlaufstelle
>> für das Os.
> Ah Maann. Ich rede seit Tagen DARUEBER. :-\
Ja, aber auch eine, die dazu verpflichtet ist, sich darum zu kümmern, und
auch eine, die ihre Sourcen *einfordern* kann. Etwas, was Du bei GPL
eben *nicht* kannst.
> Richtig. Wobei wirklich schlimm waere es erst, wenn beide
> Loesungen brauchbar waeren.
Sind sie nicht?
>> He, ich bin auch nicht immer mit Heinz einer Meinung, meistens
>> sogar nicht, aber dennoch ist es besser, *mit* diesen Leuten als
>> *gegen* diese Leute zu arbeiten, da im Endeffekt jeder davon mehr
>> profitiert.
> Sicher, Teamarbeit verlangt nach 'Sozialgeist'. Beiderseits.
> U.U. gibt der klevere naemlich solange nach, bis er der dumme ist.
"Wichtig ist was hinten rauskommt", wie der Dicke mal sagte. So ganz
unrecht hat er da auch nicht.
Raphael Pilarczyk
Bet: "Re: Open (Re: Keine 64 MByte-SIMMs...)"
> > Genug, um an der Exec nichts zu aendern? Na dann...
>
> Genug, um am Exec-Scheldurer im ROM nichts mehr ändern zu können,
> da er de fakto irrelevant für 060-Benutzer ist.
Es gibt mehr 030 und 040, als 060 User. Richtig?
> > Und die Sources zu dem Exec-Scheduler kann man wo saugen?
>
> Nirgens. Man muss die richtigen Personen lieb fragen.
Wen soll Schmidt LIEB gefragt haben? Ich lach mich schlapp! ;-))
> >> MCP hat da gut und gerne eine Menge unnötigen Ärger gemacht.
>
> > Leute die bei mir ankamen, "hilfe! hilfe!" gerufen haben nud MCP in der
> > WBStartup hatten, habe ich direkt wieder nach Hause geschickt. Bis
> > sie es lernten. Uebrigens habe ich mir damit viel Arbeit erspart,
> > denn: "no MCP, no probs".
>
> Das kannst *Du* machen, aber ein Os-Programmierer nicht, denn sonst
> rennen die Kunden weg.
Koennt ihr mir den 3.9bb2 an die Bugs von Photogenics anpassen?
Danke.
> > Hast Du fuer eine 2060 Deinen eigenen Arsch verkauft oder wie? ;)
>
> Heh, klär' das mal mit Mario. Ich hatte den Leuten auf der Beta-Tester
> Liste lang und breit erklärt, dass dieser Müll entsorgt werden muss.
> Was daraufhin ausbrauch, war ein Wehklagen ohnegleichen.
Sollte das Geruecht, meisstens nur Schwachsinnige als AmigaOS
Betatester zu nehmen, weil damit angeblich der Durschschnittliche
User gut 'getroffen wird', doch Wahr sein?
> Und zuguterletzt bestimmt derjenige die Musik, der sie bezahlt.
Schoen. Ich muss naechste Woche eine Geburtstagparty schmeissen (nicht
meine). Tanzt ihr auch auf dem Tisch? Fuer Heinz und Olsen wuerde
ich 'nen Huni ausgeben. Sie duerfen auch eigene CDs mitbrigen, kein
Problem.
> Letztendlich waren es doch die User, die eine 68060.library
> wollten - und die Kohle musste irgendwo herkommen. Also klag' nicht,
> freu' Dich über das Resultat, und der Workaround macht VNC keine
> Spur langsamer, schlechter oder sonst was.
Es kostet Zeit und 'komerziell gesehen' eben auch Geld. Dafuer
haette man in 3.9 zur Abwechslung etwas sinnvolles einbauen
koennen.
> >> Aha, also doch.
>
> > Ja, es geht immer um den Nutzen fuer den User.
>
> Inwieweit steht das im Einklang mit dem obigen?
Im reinen Einklang.
> > Haaalllooo. Nur der off. Port hat 1 und 2 zu erfuellen.
> > Der Rest der Welt macht was es will.
>
> Und wie willst Du 1) & 2) für eine offizielle Version sicherstellen,
> und verhindern, dass Leute nichts mehr für den offiziellen Port tun, da
> sie "so viel bessere Ideen" haben?
Gar nicht.
> > Bei AllForFree hast Du aber auch niemanden, der Dir erzaehlt,
> > es ist unbedingt notwendig, dass Vinced auf die Bugs von MCP eingeht.
>
> Nein, aber trotzdem war es wohl notwendig
Nicht wirklich. Es sei denn, nur Betatester haben sich AmigaOS geholt.
> > Die Koo entscheidet welche "3rd part" Sources in das off. Projekt
> > einfliessen. Was kuemmert es Dich, was Eugen Hacknix mit
> > den Sources von AddDataTypes macht??
>
> Das es dann Leute verwenden, und man letztendlich die Ohren vollge-
> jammert bekommt, wenn es damit nicht mehr zusammenarbeitet.
Lass sie doch heulen! Ich selbst stehe sogar auf sowas. :) Nebenbei
koennte ich die aufmupsigeren Nieten auch noch fertig machen.
Schade, dass ich nicht so 'fett' programmiere. Ein Spass waere das...
> Siehe eben MCP. Hätte man damals noch mehr Os-interne Informationen
> für MCP gehabt, wären noch mehr Probleme damit aufgetaucht.
Wahrscheinlich so viele, dass man es mit dem neuen OS entweder
sein lassen wuerde oder sich doch fuer eine komplete
'Inkompatibilitaet' zu MCP entscheiden wuerde/muesste. Was gleichzeitig
auch die beste Loesung darstellt.
Ich kann das immernoch nicht glauben. Etwas im AmigaOS wurde
speziell fuer die MCP-Schwachmaten verdreht. Kann doch wohl nicht
wahr sein!! :-\\
Es ist nur schade, dass ich die Kommentare dazu von Nils (Goers)
nicht mitbekommen konnte. :-)
> Lizenzen kann man lesen, und ich denke schon, dass eine gute Formulierung
> letztendlich der Ausgangspunkt für die Organisation sein wird,
> an die man sich gern hält.
An die sich Leute gerne halten, die sich gerne an sie halten.
Die werden vernuenftig mitmachen, auch wenn kein Wort dazu
niedergeschrieben ist. Einige anderen kuemmert sowas eben nicht.
Punkt.
Ich kenne noch nichtmal jemanden, den die Eula interessiert.
> Zu dem Zeitpunkt, wo Du zum Anwalt rennst, ist es so oder so zu spät,
> denn ein fähiger Rechtsverdreher wird in jedem Vertrag irgend-
> ein Schlupfloch für eine miese Mache finden.
Das aber nur erst, wenn Du in diesem Fall den 'Schuldigen' ueberhaupt
ausmachen kannst.
> Eine Lizenz sollte nichts weiter tun als eine Nettiquette auf
> offizieller Ebene klarstellen.
Ist klar. Mehr wird sie auch nie sein.
> > Nur die off. aktuelle Version ist aktuell. Was gibts da zum
> > Teufel nicht zu verstehen?? Ob jemand seine diskfont.library 44.9
> > oder 46.18 bezeichnet. Interessiert DICH das?
>
> Das interessiert mich dann, wenn die 46.18 Probleme macht, die ich
> in console.device 47.xx beheben muss, weil 90% der Leute eine nicht
> freigegebene Version verwenden, und mir die Ohren volljammern.
Zu den ersten 10 guten Eigenschaften eines Programmierers gehoert
"Rueckgrat haben". Dadran musst Du noch arbeiten. Das ist eben
das was Heinz hat, auch wenn ihm dafuer leider die 6 anderen fehlen.
Ich verwese nochmals (zum wievielten Mal schon?) auf Linux.
Es funktioniert.
> Ist es auch. Ist Dir eigentlich klar, dass Netscape dank GPL kein
> kommerzielles Interesse mehr erzeugt? Keine Firma kann xxx$$$ investieren,
> um dann ihre Sourcen zu verschenken, das *geht* nicht.
Wir reden aber immernoch ueber FreeAmigaOS, oder?
> >> Ich möchte ähnliches für AmigaOs erreichen, eine zentrale Anlaufstelle
> >> für das Os.
>
> > Ah Maann. Ich rede seit Tagen DARUEBER. :-\
>
> Ja, aber auch eine, die dazu verpflichtet ist, sich darum zu kümmern, und
> auch eine, die ihre Sourcen *einfordern* kann.
Willst Du einem John Heckmeck aus Canada/Ontario verbieten koennen bzw
wollen an seiner workbench.library rumzuprogrammieren? Das wird bestimmt
lustig.
> "Wichtig ist was hinten rauskommt", wie der Dicke mal sagte. So ganz
> unrecht hat er da auch nicht.
Hab ich doch erst vor paar Tagen in .graphik geschrieben. :-)
--
PIK
Joerg Hintze
Thema : Re: Open (Re: Keine 64 MByte-SIMMs...)
> D.h. aber nicht, dass kein neues Exec kommen kann. Oder es kann
> wirklich nicht?
Es kann, aber nur in Boards die in der Lage sind das ROM zu mappen.
Der Autor von BlizKick hat die Version der exec.library auf 44.x
geschraubt und dabei ein paar Fehler in der exec.library behoben.
Ist nur halt nichts offizielles und wird wohl auch nie offiziell werden.
Falls eitwas anderes als die exec.library gemeint war so bitte ich
meine Bemerkung zu ignorieren.
--
Gruß aus Berlin
Joerg Hintze Zconnect -> <Joerg....@Constellation.Nshift.De>
Internet -> <Joerg....@Debitel.Net>
=============================================================================
... Zeit ist eine Illusion, in stand gehalten von den Herstellern des
Universums..
=============================================================================
Joerg Hintze
> Du kannst ohne 68060.library booten. Der Grund, dass dies halbwegs normal
> funktioniert, liegt darin, dass die FPU vom 68060 dann ausgeschaltet ist.
> Und genau dafür ist das ROM im F-Space gut, nämlich die FPU beim Einschalten
> abzuschalten, damit der alte exec Scheduler nämlich *nicht* den Bach herunter-
> geht. Das hätte man auch anders machen können, hat es aber nicht.
Also das mit dem booten halte ich für ein Gerücht, man kann nicht komplett
alles booten, sondern nur Teile die nicht so relevant sind oder von älteren
Disketten, aber selbst da kommt früher oder später der System Gau, jenachdem
was auf der Diskette ist.
> Tut mir leid, das muss man beim Design des Os, und zwar deswegen, weil
> die "Kundschaft" sonst herummault von wegen "aber Os 3.9 stürzt bei mir
> dauernd ab". Ich habe mittlerweile in VNC auch Workarounds gegen MCP
> 'drin, und wurde *heftigst* darum gebeten, diese einzubauen, obwohl das
> Problem bei MCP und nicht bei mir liegt. Leider, leider, ist dies eben so.
> Die Anzahl der Workarounds gegen fehlerhafte Programme in Os >2.xx ist auch
> nicht unerheblich.
Muß ich zu sagen, selber schuld. Wenn das "Master Crash Programm" verwendet
wird, so ist der jenige selber schuld. Alle wissen doch das dieses Ding Asche
ist, also warum auf so einen Mist Rücksicht nehmen ?
> Was die 68060.library angeht: Die hätte es ohne 3.9 nie gegeben,
> schließlich wurde die 2060 aus den Einkünften von 3.9 bezahlt. Insofern
> danke an alle Käufer.
Bitte !
--
Gruß aus Berlin
Joerg Hintze Zconnect -> <Joerg....@Constellation.Nshift.De>
Internet -> <Joerg....@Debitel.Net>
=============================================================================
... Ich wartete und wartete und als keine Nachricht kam, wusste ich sie
musste von dir sein....
=============================================================================
Marius Schwarz
Am 11-Jun-01 schrieb Raphael Pilarczyk:
>
> Ich sag nach wie vor: LINUX oder FreeBSD. Es funktioniert.
Wie war das doch mit RedHat ? haben einfach ne andere c lib verwendet und
schon konnte man keine Exes mehr austauschen?
Klasse!
Bis demnächst....
--
The real Cyborg - Amigasoft and more !
Marius Schwarz
On 06-Jun-01, you wrote:
>
>> Warum ich eine uebergepatchte Version von 1993, statt einer
>> neugeschriebenen,
>
> Wozu? Warum sollte jemand alles neu durchcompilieren? Wird dadurch
> ein Byte irgendwie "neuer" und beflügelt das den Rechner irgendwie?
Kanns sein, daß der Kompiler in der Zeit besser geworden ist?
oder ist der auch von 1993?
>> Nur deswegen, weil diese 'private' Version nur auf bestimmter
>> Hardware laeuft?
>
> Weil ich nicht wüsste, was der Vorteil davon ist. Durch ein neu-
> übersetzen des Assembler-Sources von exec wird nichts irgendwie
> besser, schneller,... Relevante Bugs sind mir nicht bekannt, hier
> und da ein wenig polieren, vielleicht. Nichts, was sich nicht auch
Daher gibts so viele Patches für alle möglichen Funktionen der exec, die
schneller und besser funktionieren ( meist nur schneller ) ?
Regards