|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
Akiko
Nutzer
06.05.2019, 08:46 Uhr [ - Direktlink - ] |
Thema: Sensible World of Soccer 95 96
Brett: Amiga, AmigaOS 4 Zitat: Naja, genau genommen ist das nur die halbe Wahrheit. Als damals Commodore hopps gegangen ist, und die Hardware Unterlagen an Escom gingen, gab es ein kleines Problem. Bei dem Transfer sind die Unterlagen zum "Floppycontroller" im A1200 verlorengegangen. Die Escom Leute haben das wohl bis zu einem gewissen Grad reverse-engineert und dann mit einem "normalen" PC-Floppy kombiniert. Floppycontroller ist in Gänsefüßchen, weil ein Großteil des Datenstroms an das Floppylaufwerk von Paula moduliert wird. Es ist eigentlich nur ein missbrauchtes Audiosignal.  -- A4000D/060 @66MHz (unmodifiziert)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/300GB SCA2 -> UW-SCSI2/Ariadne 1/GoldenGate 486SLC |
|||||
|
Akiko
Nutzer
09.11.2016, 15:06 Uhr [ - Direktlink - ] |
Thema: Amiblitz 3
Brett: Amiga, AmigaOS 4 Zitat: Bei den ersten Version von PowerUP war es richtig übel, weswegen auch WarpUP als Alternative entwickelt wurde. Bei aktuellen Version sollte das Ausbremsen (bei eine PPC der gerade nichts macht) bei etwa 1-2% liegen. Man müsste an der Stelle mal eine CyberStorm MK3 und einen CyberStorm PCC mit gleichen RAM Bausteinen vergleichen. Zitat: Jain, im Fall von MorphOS 1.4.x ja, in Fall von OS4 nein. OS4 ist viel zu dick für die viel zu kleinen Caches der MPC603e und MPC604e CPUs. Und ein generelles ja, weil die M68k CPUs nach dem Bootstrap deaktiviert werden. Aber gegen ein reines PPC System mit 604e und 603e sehen die Phase5 Karte noch immer alt aus. Es gab mal ATX Mainboards mit 603e und 604e CPUs auf denen Windows NT 3.5 und 4 gefahren wurde. Die waren richtig flott im Vergleich zu den damals üblichen Pentium 90 bis Pentium MMX 233. (Man hatte nur ein ernsthaftes Treiberproblem )Dass sie erstaunlich gut laufen liegt daran, dass du keinen gleichwertigen Vergleich hast.  Zitat: Ja, du hast was vergessen. Den Custom Chips wird der Zugriff garantiert und es nicht geschaut, ob der Zugriff wirklich erfolgt. Es kommt noch besser. Dieser garantierte Custom Chip Zugriff wird noch zwischen den Custom Chips anhand einer Prioritätsliste aufgeteilt. Im Amiga erfolgen diese Zugriffe alle per DMA, also ohne die CPU. Der Amiga hat dafür 33 DMA Kanäle (oder waren es 28 bei OCS/ECS? weiß nicht mehr so genau). Das Zugriffsfenster für die Customs Chips müssen sich Disk DMA, Audio DMA, Screen DMA und die Sprite DMA teilen. Wobei die Screen DMA über die Sprite DMA gestellt wird. Man kann den anderen DMAs mehr Reichenzeit einräumen, wenn man auf einige DMAs verzichtet. Zum Beispiel wird bei AIBB die Sprite DMA abgeschaltet, damit die Screen DMA ein paar Rechenzyklen mehr hat. Zitat: Ein VBR ins Fast RAM zu schieben bringt immer was, nur ist die non-MMU Variante vermutlich etwas flotter. Zitat: Ich habe die Variante mit einem 486SX 25Mhz (dieser Mist mit 16 Bit Datenpfad zum RAM) und einem 80387 Copro ... nunja, der Trick ist erstmal die Amiga-seitige Software zum laufen zu bringen. Ein 68040 ist da schon unangenehm, der 68060 wird zur Qual. Aber wenn es schon mal läuft - ein MSDOS 6.2/6.22 bekomme ich nicht zum laufen - keine Chance. Ein MSDOS 5.0 geht. Windows 3.11 geht. Aber ich verwende es ab und zu mal für ein Turbo Pascal oder Turbo C++, oder um alte PC DD Disketten zu lesen. Nein, die Wahreit ist, dass ich meinen A4000T weggepackt habe und stattdessen einen Xeon 1650v4 mit 64GB DDR4 ECC fahre. Da drauf ein vollverschlüsseltes Linux (auch der Bootloader GRUB ist verschlüsselt) betreibe, in dem dank KVM/qemu ein Windows 10 (7 wollte einfach nicht) mit einer GTX 1080 und einer Essence STX II per PCI-passthrough läuft. Es laufen noch diverse andere Linux Systeme dank KVM Virtualisierung da drauf. Die sind im Prinzip Buildhosts, da ich mit diesem "Monster" Bonding-Router Betriebssysteme für meinen Arbeitgeben baue. Ich habe noch andere schräge Sachen hier, Dual Itianium 2, PowerMac G5 Quad, POWER 4+, HP C8000 (mit 2x Dualcore HPPA-8900+), haufeweise ARM Kram und so weiter. Ist aber im Alltag zu nichts zu gebrauchen, außer vielleich mein "Beast", ein Dual Opteron 6174 (2x12 2.2 GHz + 128DDR3 ECC), fürs Rendern, Simulieren und Distribution bauen. PS: Wenn das hier wie Angeberei rüberkommt, so wars nicht gedacht. Ich wollte nur untermauern, dass ich gaaanz tief in der Materie drinstecke. Obwohl, etwas angeben kann ich noch. Mein Arbeitsteamkollege ist BeRo aus der Demogruppe Farbrausch. Wir basteln gerade ein paar sehr abgefahrene Router. -- A4000D/060 @66MHz (unmodifiziert)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/300GB SCA2 -> UW-SCSI2/Ariadne 1/GoldenGate 486SLC |
|||||
|
Akiko
Nutzer
09.11.2016, 06:14 Uhr [ - Direktlink - ] |
Thema: Amiblitz 3
Brett: Amiga, AmigaOS 4 Zitat: Es kommt ganz drauf an, ob der PPC aktiv ist oder nicht. Die PPC Karten sind eigentlich ziemlich "fucked-up", weil sich da der M68k und der PPC den Speicher teilen. Es kann immer nur einer auf den Speicher zugreifen. Bevor sie das machen, wird aus Cache-Coherence-Gründen (PCC und M68k müssen in ihren Caches die gleichen Daten haben - wenn der Cache den gleichen RAM Bereich abdeckt) einen echten Context-Switch durchführen, also alle Daten in den Caches und Registern in den RAM zurück schreiben. Dies bremst das System ziemlich stark aus. Und wenn man bedenkt, dass im Hintergrund immer ein PPC-Kernel läuft, dürfte das recht häufig passieren. Im Fall eines reinen M68k Amigas wird es schneller, weil Fast-RAM einzig allein für die CPU da ist. Dieser RAM ist in der Regel mit der MHz Zahl der CPU angebunden. Der Chip-RAM dagegen wird zwischen den Custom Chips und der CPU geteilt. Wenn man sich vorstellt, dass in Takten auf das Chip-RAM zugegriffen wird (also 1 2 3 4 5 ...), werden alle ungeraden Zugriffe den Custom Chips gegeben und alle geraden Zugriffe der CPU. Allein dadurch ist die Chip-RAM Geschwindigkeit schon mal nur halb so schnell für die CPU. Dann kommt hinzu, dass das Chip-RAM mit der Bus Geschwindigkeit betrieben wird, dass sind diese ominösen 28,xx MHz, die man als Quartz auch auf den Mainboards sehen kann. Und zum Schluss haben OCS/ECS Systeme nur einen 16 Bit breiten Bus und AGA Systeme einen 32 Bit breiten Bus. Zudem können AGA Systeme kaskadierte Zugriffe, die das Chip-RAM etwa 4x so schnell wie bei einem OCS/ECS System machen, aber es ist noch immer deutlich langsamer als Fast-RAM. Hmm, ob das Verschieben des VBR mit der MMU genauso effizient ist, glaube ich nicht. Gerade bei dem 68030 bekommt der RAM Zugriff, der durch die MMU läuft noch ein paar Taktzyklen Latenz dazu. Die MMU im 68030 ist nicht so hoch integiert wie im 040/060, vor allem weil letztere einen korrekte Harvard Architektur MMU haben (es sind zwei, einmal für Daten und einmal für Instruktionen). -- A4000D/060 @66MHz (unmodifiziert)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/300GB SCA2 -> UW-SCSI2/Ariadne 1/GoldenGate 486SLC |
|||||
|
Akiko
Nutzer
06.11.2016, 07:40 Uhr [ - Direktlink - ] |
Thema: Amiblitz 3
Brett: Amiga, AmigaOS 4 Das VBR ist ein Register, dass auf die Interrupt Service Routines zeigt. In der M68k Architektur werden sie Exception Vectors genannt und sind 256 32Bit Adressen, also genau 1 KiB. Diese befinden sich per Default immer an der Adresse 0 im Speicher, also im Fall des Amigas im Chip-Ram. Ab dem 68010 hat die CPU ein eigenes Register für die Startadresse dieser Vectorentabelle. Dies ist das VBR und kann ab dem 68010 auch woanders hinzeigen, zum Beispiel ins Fast-Ram, was wesentlich schneller ist. Es gibt verschiedene Programme, die 1 KiB im Fast-Ram reservieren, die Tabelle dorthin kopieren und anschließend den VBR auf die neue Tabelle zeigen lassen. Da wäre zum Beispiel das vbrmov aus dem Aminet. -- A4000D/060 @66MHz (original!)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/38GB UW-SCSI2/Ariadne 1/GoldenGate 486SLC |
|||||
|
Akiko
Nutzer
17.05.2013, 08:52 Uhr [ - Direktlink - ] |
Thema: Auf Ftps-Server mit 68k-Amiga zugreifen?
Brett: Amiga, AmigaOS 4 Zitat: Und wie ist die Performance so? Die üblichen Block-Cipher, die da verwendet werden, dürften den 68k ganz schön ins Schwitzen bringen. Oder wurde der TLS Request garnicht erst fertig durchgeführt (im den Fall hätte es ein Fallback auf eine normale Verbindung gegeben)? -- A4000D(RBM Tower)/060 @66MHz (original!)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/18GB UW-SCSI/IOBlix+Ethernet Modul/GoldenGate 486SLC |
|||||
|
Akiko
Nutzer
03.04.2005, 13:18 Uhr [ - Direktlink - ] |
Thema: Probleme mit einer PicassoIV
Brett: Amiga, AmigaOS 4 Kennt das jemand, dass die PicassoIV wild umherschaltet? Also der Monitor schaltet immer umher, aber ohne ein Bild zu liefern. Wenn ich neue Auflösungen in den Flash speichern will oder auslesen, ist der Flash immer leer. Irgendwelche Ideen? -- guru@linux:~> echo $(IFS=":";clear;cat /proc/cpuinfo|while read a b;do case ${a} in proc*)echo -n "CPU: (${b:1})-";;"model n"*)echo "${b:1}";;"cpu M"*)echo "Speed: ${b:1} MHz";;"cache s"*)echo "Cache: ${b:1}";;esac;done) |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
)