Fw: Fw: Suche Linux-Anschluss im Raum Bi-Sennestadt

[Pfeiffer]

Moin ...


> Sicher. Hmmm, wo ist denn mein M68k Assembler Buch?
> Der M68K hatte nur MMIO, oder? Naja, kein io-bridging notwendig.
> Und einen gesegneten Interupt-Mechanissmuss, den muesstet ihr in eurem
> FPGA emulieren und dann einen PCI-Interrupt erzeugen.
MMIO ist doch was feines. Mit dem Interrupt liegst du richtig.

>>>> Der Adressbereich wird 16MB betragen und sollte ab Adresse $00000000 
>>>> bis
>>>> $010000000 gemapped werden.
>> Uhps ... eine Null zuviel, beim programmieren wieder tödlich.
>>
> Oeh, rechne, rechne, koennt das dann passen?

$ x1xx.xxxx statt $ x1xx.xxxx0 ;-)

>> Ok, das liesse sich sicherlich auch über Offsets innerhalb des Emulators
>> erledigen.
> Denke das musst du sowieso!
> Gab doch beim M68K den Addressmodus "displacement" wo man negative
> displacements angeben kann? Sehr beliebt in in der short version bei
> bootloadern um mit 0 - x irgendwas da hinten im Addr.-Raum anzusprechen
> (Der Atari hatte da glaub ich das ROM). Naja, langes Raesteln kurzer sinn:
> Du willst ja nicht, das dein emulierter Gast bei 0 - x im Stack deines
> Emulators rauskommt.
> Also muss eh jeder Speicherzugriff gegen die Grenzen getestet werden
> (addr&0x0fff...).

Vor der Null kommt $FFFF..... ja.

> Oehm, in dem Moment wenn der Kernel hochgefahren ist? Der Kernel selbst
> besteht schon aus mehreren Tasks.
Ok, verstehe.
>
>> In meiner Phantasie müsste nur der Emulator gestartet werden,
> Solange ein OS-Unterbau da ist, der etwas mehr als ein loader ist (DOS,
> selbstgeschriebner boot-foo), wird das OS auch ungefragt Rechenzeit
> "stehlen" und wenn es nur zum verwalten der HW (Timerinterupt, etc.) ist.
>
>> dieser
>> würde den Bereich PCI-Bridge als normalen Arbeitsspeicher verwenden. Die
>> Hardware übernimmt den Transfer und das Busprotokoll, könnte also als
>> Arbeitsspeicher mit extrem langen Reaktionszeiten verstanden werden.
>>
> Der Emulator benoetigt ja noch weiteres RAM, was er auch besser lokal
> hat (sonst kauf dir besser fluessigen Stickstoff und ein Satz Quarze,
> mom, mittlerweile gibts ja ColdFire, die machen, suchsuchsuch, 266MHz
> hmmm, erinnert sich noch wer an einen (humoristischen)Artikel ueber den
> naechsten Atari TT mit eingebauter Herdplatte, mitgeliefert wird das
> Buch "Cooking with the TT"), er wuerde nur die Zugriffe in/auf den Amiga
> ausgeloesst durch entsprechende M68K Befehle dorthin umleiten.
Für die x86-Hardware gibt es den Speicher ja schon geschenkt. Sollte also 
kein Problem sein dort 256/512MB zu spendieren. Der Kernel und der Emulator 
sollten vielleicht einen Bedarf von ca. 16MB haben.
>
>>> Den Emulator in den Kernel? Uhhh...
>>> Hmmm...
>>> Echte Treiber fuer die devices schreiben? Mom, ne, der Gast im Emulator
>>> soll sie ja benutzen, Doppelemulation ist doof.
>>> RT-Linux? Interruptweiterleitung in den Emulator mit RT-Tasks...
>> Auf Heise stand letztens was zu einem RT-Patch mit 50ns Rekationszeit.
>> Aber wozu RT? Da müsstest du mich mal aufklären, das Amiga-System wartet
>> in der Regel auf die CPU.
>>
>
> Der Kernel wartet aber nicht auf deinen Emulator.
>
> Warum nun Echtzeit? So etwas wie z.B. den V-Blanc interrupt (OK, falls
> der Amiga sowas hatte) einfach an einen nicht RT-Emulator weiter zu
> geben ist sinnlos. Der Kernel koennte auf die Idee kommen, deinen
> Emulator einfach mal 100ms an die Seite zu legen, um sich seiner meinung
> wichtigeren Dingen zu widmen. Nur Echtzeit garantiert dir ein Interuppt
> aehnliches Verhalten, und du willst ja nicht, das deine Soundausgabe
> stockt. Oder du verzichtest auf ein Betriebsystem.
>
> Ich hatte mir das so gedacht:
> Deine Amiga-Bridge kann den M68K-Interupt-Zyklus emulieren und loest
> darauf einen PCI-Interupt aus.
> Dein Linuxtreiber hat diesen Interupt registriert.
> Der Emulator hat zwei Tasks, einen normalen, der "stumpf" M68K Befehl um
> Befehl verarbeitet.
> Der Interupthandler deines Treibers sichert die informationen aus dem
> M68K-IACK-Zyklus weg und "stoesst" den zweiten Emulator-Task an, einen
> RT-Task (den x86-interupt verlassend).
> Dieser stopt den ersten Task, emuliert mit RT-Prioritaet nun den
> "dazugehoerigen" M68K Interrupt-vector, wenn er damit fertig ist wird
> die normale emulation weitergefuehrt (Wie auf der echten CPU).
Du steckst voll im Thema ... ich glaube dass du die Idee schon voll 
verstanden hast.
>
> Nebenbei bist du mit x86 der neueren Generation eh aufgeschmissen, dank 
> SMI.
Können die nicht kompatibel gefahren werden? OK, liegt die Hälfte oder mehr 
ungenutzt rum.

>
> @JBG: Hmmm, ist wirklich ne interessante Frage wie schnell man wohl
> M68K-Befehle emulieren kann. Aber ich denke schon, das man mit den
> modernen GHz-Boliden die 50-66 MHz der letzten 68060 topen kann.

Wenn du mal WinUAE antestest, wirst du ein vielfaches gegenüber dem 68060 
sehen. Eine 1GHz x86 CPU bring es ca. auf die 5-fache Leistung. Und das mit 
Windows drunter.

Gruß
Andre