TT Rom zugriff schneller machen?

[tuxie]

Sollte gehe, wichtig ist das er nicht zu langsam ist. Ich habe einen 20v8 drin inkl. Flash Möglichkeit (in System )

[Guus.Assmann]

Hallo Tuxie,

Den PALCE ist 10nS, sollte reichen. (PALCE22V10H-10PC/5 ) Oder soll ich den Gal20V8-25LP nehmen?
Kann ich bitte den Jedec-Datei und Pinbelegung bekommen?
Dann kann ich einfach das Teil programieren und einbauen.
Ich hab einige SST39SF040-70 Flashroms. (Leider QFP, aber ich kann Adapter machen nach Dil, obwohl etwas schwer...) Hier passt 4 x OS rein, hab ich jetzt mit 29F040. Sind leider 90nS.

MFG/
Guus

[tuxie]

Hm da gibt es keine Jedec Datei, die musst du dir schon selbst Assemblieren..  oder hast du keinen Gal Assembler ?

[Guus.Assmann]

Gal Assembler? Ja, es gibt wohl einige.
Hab heute noch mal mit den Atmel WINCupl versucht.
Ist nicht so Benützerfreundlich, Ein Syntacs Fehler ist oft schwerr zu entdecken und das Program stürtz mal und mal ab.
Ich denke aber, Ich hab's geschafft.
Werde Morgen mal versuchen ein Gal zu programieren und testen.

MFG/
Guus

[Guus.Assmann]

Hallo Tuxie,

Das die Signale alle am Ram-Board sind, habe ich schon gesehen. Ich habe die Schaltpläne. 
Aber noch eine Frage.
Wenn ich die Roms so lasse, (nür austauschen) und die Signale XDS0 und XDS1 aus den Gal generiere, sollte doch das CS signal aus den MMU auch eher weg gehen? Oder muss ich das einfach testen..
Wenn das so ist, kann ich auch (einfacher) die Beschleunigung ausschalten.
Dazu werde ich dann einen extra Eingang mit das generieren von XDSx durch AND verknüpfen.
So eine Lösung kann ich dann auch immer umschalten, ohne neuen Bootvorgang, "on the fly"

MFG/
Guus

[tuxie]

Ja das sollte gehen, im prinzip ist es ja das nur das xds0/1 eine Zeit X eher kommen müssen!

[Guus.Assmann]

Hallo Tuxie,

Da fiel mir Heute noch etwas ein. Und das will ich gerne hier mal "spiegeln" 
Vom MMU wird das Chip-Select Signal für den Eproms erzeugt.
Wenn ich dieses Signal direct nach XDS0/1 verbinde mittels OC Gatter (Oder Schottky Diode sogar), sollte es auch functionieren. Natürlich sind schnellere Roms da immer noch nötig. 
Dies spart viel Verdrahtung und ist sehr wenig Arbeit. Sollte so einfach sein das fast jeder es schafft.

Werde dies mal testen.

@ Alle
Wegen Test, mag ich es immer um klar zu haben was passiert.
Einfaches ein / aus Schalten habe ich da am liebsten. Also Test mit oder ohne etwas, weiter unter gleiche Bedingungen.
Es ist mich nicht klar was Gembench genau macht bei jeden Test.
Aber bei jedes Programm werden viele Teile vom Computer benützt.
Gembench ist im Ram geladen. Aber TT oder ST-Ram? Und Firmware aus Eprom oder TT Ram nach copie? Alles hat einfluss.
Daher ist jedes mal vergleichen angesagt.
Züm Beispiel den FPU-Clock.
Ich hab bemerkt das bei steigen der Clock-geschwindigkeit über 40Hmz viel weniger passiert. Also 32 Mhz nach 40Mhz hat zuname X. Aber dann von 40 nach 48Mhz ist nicht wieder X. Und nach 56Mhz ist es noch weniger. Warum? Ich denke austausch von Daten zwischen CPU und FPU ist den "Bottleneck"
Bei diesen Tests hab ich immer nür den FPU-Takt geänderd.

MFG/
Guus

[Arthur]

Die Werte der Version größer 4.03 von Exxos sind teilweise viel höher was ja nicht stimmen kann denke ich mal Die letzte originale 4.03 ist schon gut ...

Ja die Werte haben sich zum Teil geändert wobei mir direkt die Werte der FPU ins Auge fallen was ich allerdings eher positiv finde. Und zum andern finde ich halt den Loop-Modus gut da er als Stabilitätstest ganz brauchbar ist.

[ari.tao]

Jetzt wäre ich aber doch neugierig, wie weit @Guus.Assmann mit seinem Vorschlag inzwischen gekommen ist:

Da fiel mir Heute noch etwas ein. Und das will ich gerne hier mal "spiegeln" 
Vom MMU wird das Chip-Select Signal für den Eproms erzeugt.
Wenn ich dieses Signal direct nach XDS0/1 verbinde mittels OC Gatter (Oder Schottky Diode sogar), sollte es auch functionieren. Natürlich sind schnellere Roms da immer noch nötig. 
Dies spart viel Verdrahtung und ist sehr wenig Arbeit. Sollte so einfach sein das fast jeder es schafft.

[Gaga]

4 Posts nacheinander und dann noch nicht einmal direkt zum Hauptthema. Wie kann man nur so viel hier schreiben?! Ist schon anstrengend, bei solchen Betonbeiträgen zu folgen.

Inzwischen dürfte klar geworden sein, wer hier welche Meinung vertritt.

@ari.tao : warum versuchst Du Dein Talent nicht einmal mit einem Artikel in der STC?

Vorschlag zum Thema: Gembench - Gotteswerk oder Teufelszeug

[Guus.Assmann]

Hallo,

Sehr viel zu lesen....

Wenn ich einfach zwei Dioden zwischen /CS vom Rom und XDS0/1 anschliesse, bootet der TT nicht mehr. Aber ich hab noch 4 DIL 29F040 mit 90nS in mein TT.
Also werde ich erst mal schnellere Flash einbauen. Hab die aber nür als PLCC und brauche Adapter-Platinen zu machen. Lötversion, wegen bauhöhe. (Hab auch Platinen bei SEEED bestellt)
Geht also weiter.

@FPU: Könnte meine Idee stimmen dass es mit Datenaustausch zu tun hat?

@Testen von Speed: Wenn Ich je nür eine Variable ändere, kann ich sehen ob dies etwas ändert oder nicht beim testen. Dies ist für mich am wichtigsten. (Und nicht die Frage wemm ist am grössten... )

@Romspeed: Wenn ich ein Teil vom Rom ins Ram copiere und feststelle wieviel Zeit das braucht, ist dieses ergebniss nür abhangig vom Rom-Zugriffszeit. Denn alle andere einflüsse sind da immer gleich. Da hilft auch kein Cache. Oder seh ich dies Falsch?

Vergleich von "absoluten Speed" ist immer sehr schwerig, denn wass möchte man wissen. Daher auch verschiedene Benchmarks, je nachdem.

MFG/
Guus

[Johannes]

Ich habe die unsäglich lange GemBench Diskussion ausgelagert. Sorry Guus, dass Dein Thread jetzt etwas zerfleddert ist. Aber ich glaube die Herren entfernen sich ziemlich weit vom Thema.

Bitte hier nur noch über die Beschleunigung der TOS/ROM Zugriffe sprechen und nicht mehr über Messverfahren. Das könnt ihr dann hier tun:

Gembench - Gotteswerk oder Teufelszeug
https://forum.atari-home.de/index.php/topic,15023.0.html

Gruß
Johannes

[Guus.Assmann]

Hallo Johannes,

Ist mir schon Recht, es war etwas Verwirrend und manchmal nicht so "Betreffgemäsz".

@tuxie,
Gestern hab ich nochmal etwas mit WinCupl gespielt.
Es macht schon sehr viel aus, wenn ich den PALCE22V10 als Target angebe.  (Statt g20V10a !)
Also hab ich jetzt ein PalCE mit ein (fast) richtigen Address-Decoder.
Braucht nür noch invertieren vom CE.
Aber noch eine Frage. Sollte nicht das AS-Signal auch als aktiv Nul angegeben werden?

MFG/
Guus

[tuxie]

Hallo,

ja kommt darauf an wie du das machst wenn du das Signal als Aktiv Null deklarierst bei der Pin definition  dann kannst du normal mit "AS" arbeiten. Machst du das nicht dann muss natürlich in der gleichung "/AS" angegeben werden oder "!AS" je nach ASM. Und ja AS ist Natürlich Low Aktiv

[Guus.Assmann]

Hab Heute nochmal getestet. Und : Erfolg  Also es geht doch !
Beim bau der Platine für den Address-Decoder hab ich ein Fehler gesehen.
Die Signale XDS0/1 sind an Pin 15 und 16, nicht 16 und 17.
Als ich dann zwei Dioden (Germanium Typen mit Anode and 15 und 16, Cathoden an CS) angeschlossen habe and den originalen CS, dann ging es ja wie erwartet.
Also es braucht nür zwei Dioden und 90nS Flash 29F040. (oder 29F010)
Werde nochmal etwas testen und Ergebnisse melden.
Ich vergleiche dann meinen TT mit sich selbt, mit und ohne schnellere XDS.

[Guus.Assmann]

Hab Heute das Gal angeschlossen. Leider ist da etwas nicht in Ordnung, denn mein TT bootet nicht.
Muss nochmal checken was da passiert.

Mit Dioden geht es aber wohl.
Gembench Rom zugriff ändert von 227% nach 297%, also etwas zuwachs.
Hab danach mit eine Stoppuhr das booten gemessen. Mit und ohne Beschleunigung gemessen.
Je 5 mal und dann ausmitteln. (Maximale variation war 0,02 Secunden)
Ohne dauert es etwa 11,02 Secunden.
Mit Beschleunigung etwa 10,77 Secunden. Ist also etwas schneller.
Bis jetzt hab ich noch nicht festgestellt ob es Probleme gibt, aber dies halte ich für sehr unwahrscheinlich.

MFG
Guus

[tuxie]

Sehr gut

Ja sollte so sein, du veränderst damit ja das Timing und erhälst einen schnelleren Zugriff auf das Rom, du solltest das auch direkt spüren bei den Fenster Animationen, diese sind auch Spürbar schneller. Im ganzen ist es echt eine Sache wo ich nicht verstehe warum Atari das überhaupt gemacht hat. Man könnte den Zugriff sogar noch mehr beschleunigen. Man könnte die Roms mit CPU  Takt also 32mhz laufen lassen. Aber dazu müsste man eine Logic einbauen die Prüft von wo der zu griff kommt. Kommt er von der CPU dann direkt oder wenn er von z.b. Shifter oder DMA kommt dann halt über die Bustaktlogic. Ich denke damit könnte man nochmal einiges an Beschleunigung bekommen

[1ST1]

Schau mal, wie schnell/langsam damals die ROM-Bausteine waren. Und 32 MHz gehen einfach nicht, weil der TT original auf 16 MHz ausgelegt war, auch für die CPU. Da musste erst Commodore den Amiga 3000 mit 25 MHz ankündigen, dass man bei Atari das 32 MHz Daughterboard noch ins Design eingefügt hat, also quasi ein Selbstbau-68030-DX2-32. Die ROMs sitzen halt nicht auf dem Daughter-Board. Da musst du schon das Gesamtsystem hochtakten und die ROMs werden dennoch bei halben CPU-Takt bleiben.

Aber insgesamt kann man sich fragen, warum Atari bzw.Shiraz S. den TT so komplex aufgebaut hat, insbesondere wenn man mit Milan/Hades und Falcon vergleicht.

[tuxie]

@1ST1 , das quatsch was du da sagst.... er hat die Originalen Roms drin, und konnte ihn beschleunigen. Und 70ns Roms waren damals schon zu haben. Nur eben wohl teurer. Bei 32Mhz ist AS 60ns active wenn ich das richtig in Erinnerung habe. Das man wohl mit voller Geschwindigkeit nicht ganz hinkommen wird könnte sein ja, dazu muss dann wohl ein Waitstate eingebaut werden. Aber das dann dennoch immer noch schneller als so. Es sind einfach einfache Optimierungen was nichts mit Overclocking zu tun hat.

Einzigste was man machen muss ist AS, XDS0 und XDS1 direkt auf CPU Seite abgreifen, und einem GAL zuführen. Wenn Zugriff von CPU dann AS,XDS0 und XDS1 auf CPU Seite abgreifen und wenn Zugriff von woanders dann hintere den Pals auf Mainboard Seite. Die Signale liegen an den 6 Bausteinen in der Nähe der CPU an (4x74LS74, 2x PAL) und genau diese Bausteine haben wir gegen eine eigene Logic ersetzt deswegen ist der Bustakt in meinem TT nicht verdoppelt sondern verdreifacht.
Es ist nicht ganz so einfach wie ich das jetzt schreibe aber sinngemäß sollte es so gehen.

[ari.tao]

Was bringt das an CoreMarks?
Mehr, als wenn man das TOS in´s TT-RAM kopiert?