atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Mi 21.07.2021, 15:30:23
-
Habe mal Platinen machen lassen und Bauteile bestellt. MC68881/16Mhz PLCC Bausteine gab es über Ebay. Baue mal eine auf ...
-
Platinen waren heute in der Post. Direkt mal eine aufgebaut. Wird auch mit TOS 1.04 als SFP004 erkannt.
-
Hast Du da einen vorhandenen Schaltplan genutzt oder alles selbst entwickelt.
Bin richtig neidisch. Das sieht toll aus. Hab leider keine Zeit weil ich beruflich
zu sehr eingespannt bin. Würde gerne mal wieder mehr machen ausser an den kurzen Wochenenden.
Zeit sollte man haben. So einfach mal ohne Unterbrechung was durchziehen.
Wär ich bloss mal Beamter geworden.
-
Nein nicht von mir, ist von Djordje Vukovic
http://hardware.atari.org/hacks/speed.htm
-
Das ganze funktioniert aber nicht. Unter TOS 1.04 und TOS 2.06 wird zwar eine SFP004 FPU gemeldet aber bei Gembench hängt der FPU durchlauf.
Im Schaltplan im Platinenprogramm ist kein Fehler und die Platine stimmt mit dem Schaltplan überein.
Da weiss ich jetzt auch nicht weiter !?!
-
Ohne jetzt lange nachgedacht zu haben: 1. Schritt wäre: Stimmt die Adressdekodierung und kommen sinnvolle Daten von der FPU rüber? SYSINFO.PRG starten, darin "F9" für Speicheranzeige, "Strg+A", um eine Adresse einzugeben, $FFFA40 eingeben und einen Screenshot des Ergebnisses posten.
-
CPUFPU.PRG meldet eine SFP004 aber Sysinfo.prg sagt keine FPU vorhanden ...
-
So falsch sieht das nicht aus. Genau bei den Adressen, bei denen man etwas erwarten würde, kommen auch Daten - und es ist auch nicht alles 00 oder FF (was auf irgendwelche Probleme beim Datenbus hindeuten würde). Du hattest doch im einem anderen Thread irgendein FPU-Test-Programm gepostet. Was sagt das denn?
Und ist die FPU sicher in Ordnung? D.h. in einem anderen Rechner getestet?
-
So halb funktioniert es ja. FPU_SOFT.PRG läuft, siehe Bild aber das HARD Programm hängt und läuft nicht genau wie der Gembench FPU Test.
Die FPU ist im Mega STE getestet mit dem Line_F Emu von Arne und dem DML FPU Testprogramm.
-
So halb funktioniert es ja. FPU_SOFT.PRG läuft, siehe Bild
Aus dem README zu FPU_SOFT: "This program does NOT use the MC68881 regardless of whether it's installed or not." Kurzum: Es nutzt die FPU nicht.
Blieben also weiterhin: Fehler im Schaltplan oder im Layout, Kontaktproblem der FPU im Sockel.
-
Den Eagle Schaltplan habe ich jetzt schon öfter überprüft und nichts an Fehler gefunden. Der Schaltplan bedingt bei Eagle ja zu 100% das Layout der Platine. Der PLCC Sockel ist neu aber ich werde da auch nochmal drauf schauen ...
-
Kann nichts finden ...
-
.
-
War mit dem Hund draussen und dachte der einzige Fehler könnte eine Fehlbelegung des Mega ST Bus Steckers sein. So Reihenfolge FC0-2 vertauscht aber alles richtig und von der CPU aus gemessen.
-
Exxos meint DSACK0 ist ja frei an der FPU und nicht belegt fluktuiert, kann das sein?
Ist ja Lowaktiv also könnte ich es mit 10k oder 4,7k high legen?
-
Exxos meint DSACK0 ist ja frei an der FPU und nicht belegt fluktuiert, kann das sein?
DSACK0 ist ein Ausgang der FPU und bezüglich des hier verwendeten 16-Bit-Betriebs steht im Handbuch des MC68881: "it is not necessary to connect the DSACK0 pin since the FPCP never asserts it in this configuration."
-
Danke, also nutzlos.
-
Du könntest Dir GFA-Basic schnappen und die Befehle aus meinem Beispiel https://www.chzsoft.de/site/site/assets/files/1041/atari_sfp.pdf (GFA-Basic jeweils rechts) eintippen und sehen, was passiert. Beachte: Ich habe das mit einem 68882 gemacht, wenn Du einen 68881 hast, können die Ergebnisse leicht anders sein.
-
Kann ich nicht!
Was soll ich ganz genau machen?
Eine Zeile eintippen und dann RETURN drücken und dann die nächste Zeile und immer so weiteer und am Ende auf RUN klicken?
Ich tippe die erste Zeile ein, drücke Return und auf dem Schirm steht dann was anderes " SDPOKE &HFFFA4A,&H541C"
-
Kann ich nicht!
Herrje. Es ist Deine Hardware. Mehr als Dir Tipps geben kann ich auch nicht. Wenn nicht, dann halt nicht.
Was soll ich ganz genau machen?
Im Editor vorher auf "Direct" klicken, um zum Prompt mit OK> zu kommen.
-
Ich kann das GFA halt gar nicht bedienen. Direct aufzurufen hilft schon mal weiter. Ich kann jetzt alles eintippen ...
Und was mache ich dann?
-
Z.B hier posten.
-
Zeile 1 ohne Fehler Meldung
Zeile 2 kommt 1D0D1608
Zeile 3 ohne Fehler Meldung
Zeile 4 ohne Fehler Meldung
Zeile 5 ohne Fehler Meldung
Zeile 6 kommt 1D0D8900
Zeile 7 kommt 1D0D3208
Zeile 8 kommt "neue Variable" und 3FF921FB30
Zeile 9 kommt "neue Variable" und 54442D18544420
-
Mal was anderes ...
Unter Hatari Setup 68000 und 68881 und TOS 2.06 kommt ein Buserror. EmuTOS auch. Emuliert Hatari nur eine Line-F FPU mit 020/30 CPU?
-
Vielleicht hilft Dir das weiter.
-
Als GFA File gespeichert und auf run geklickt ...
-
Clock an der CPU abgegriffen oder einen externen Quartz genommen?
-
16Mhz Quarz ...
-
Habe mal eine zweite Karte aufgebaut und vorher die vier TTL Bausteine in einem Bauteiltester mit OK getestet. Die Karte verhält sich genau wie die erste Karte.
@Atariosimus Die ganzen FPU Programme beenden sich kurz nach dem Start wieder oder Bomben mit 2 Bomben oder hängen einfach.
-
Zeile 1 ohne Fehler Meldung
Zeile 2 kommt 1D0D1608
Zeile 3 ohne Fehler Meldung
Zeile 4 ohne Fehler Meldung
Zeile 5 ohne Fehler Meldung
Zeile 6 kommt 1D0D8900
Zeile 7 kommt 1D0D3208
Zeile 8 kommt "neue Variable" und 3FF921FB30
Zeile 9 kommt "neue Variable" und 54442D18544420
Das sieht verdächtig nach irgendwelchen (Ab?)Tippfehlern aus, denn die Resultate können nur 4 bzw. 8 Hex-Ziffern lang sein, exakt wie in meinem Dokument. Aber 1608, 8900, 3208, 3FF921FB und 54442D18 sind ja die erwarteten Resultate. Funktioniert also, wie sie soll (in diesem Beispiel) Deine FPU.
Emuliert Hatari nur eine Line-F FPU mit 020/30 CPU?
Ja. Zitat aus dem Handbuch (https://hatari.tuxfamily.org/doc/manual.html#Atari_hardware_differences_matrix): "Memory mapped FPU add-ons, not supported by Hatari". So eine SFP-004 ist "memory mapped FPU".
-
Also ist da ein Fehler im Schaltungsdesign von Djordje Vukovic !?!
Habe mal den Howto.txt als PDF exportiert.
Hat denn jemand mal einen Schaltplan von einer Atari SFP004 Karte?
-
Die Atari SFP004 hat durch die vier anderen TTL Bausteine bis auf den 27 eine ganz andere Schaltung ...
-
Also ist da ein Fehler im Schaltungsdesign von Djordje Vukovic !?!
Schlussfolgerst Du woraus?
-
Meine Platine stimmt mit dem Schaltplan überein. Was soll es sonst sein?
-
Das sieht verdächtig nach irgendwelchen (Ab?)Tippfehlern aus...
Habe von ...
OK > print hex$(dpeek($FFFA40))
1608
eingetippt ...
print hex$(dpeek($FFFA40)) 1608
also mit Leerzeichen zwischen )) und 1608
... ansonsten keine Tippfehler.
-
Öhm, Du sollst die Antworten (also 1608, 8900, 3208, 3FF921FB und 54442D18) natürlich nicht abtippen, sondern nur die Befehle.
EDIT: Und bitte nach einem Reset ausführen. Wenn Deine vorigen Tests die FPU irgendwie "gecrasht" haben, sind die Ergebnisse nutzlos.
-
Ohne Tippfehler ...
Zeile 1 ohne Fehler Meldung
Zeile 2 kommt 1D0D
Zeile 3 ohne Fehler Meldung
Zeile 4 ohne Fehler Meldung
Zeile 5 ohne Fehler Meldung
Zeile 6 kommt 1D0D
Zeile 7 kommt 1D0D
Zeile 8 kommt 3FF921FB
Zeile 9 kommt 54442D18
-
Seltsam. Die FPU beschwert sich konsequent über eine falsche Reihenfolge der Zugriffe (1D0D = "protocol violation"), führt das Kommando aber offensichtlich aus, denn Du liest ja 3FF921FB 54442D18 = pi/2 zurück.
Mal angenommen, Du hast das - wie oben von mir geschrieben - nach einem Reset ausgeführt und davor keine Programme (auch nicht im AUTO-Ordner o.ä.) laufen lassen, die auf die FPU zugreifen, muss ich leider die gemeinsame Fehlersuche hier abbrechen, denn ich habe keine Ideen mehr.
-
Ja ist ein Atari Mega ST4 mit TOS 1.04 ohne Massenspeicher außer Floppy und da ist kein ACC und kein AUTO Ordner drauf.
Seltsam das es so halb funktioniert aber nicht richtig!
-
Habe mal gehört das es Fehler bei den Eagle Bauteilen geben soll. Die FPU stimmt und bei den vier TTL schaue ich morgen mal ...
-
Alles anhand von Datenblättern überprüft, die Eagle Bibliothek stimmt also ohne Fehler.
-
Da ist noch eine FPU Schaltung in der Doit zwar mit Fehlern aber die Adresscodierung zusammen mit FC0 und FC1 stimmt überein. AS in der Doit Schaltung sollte CS sein und AS fehlt. Das gleiche mit der Schaltung im Atari Mega STE allerdings wird im MSTE an Adressen nur A5 bis A15 genutzt also ohne A16 bis A23 ...
Gembench 4.03 erkennt die FPU nicht beim Start des Programmes also ist da irgendwie ein Fehler in der Schaltung. TOS 2.06 setzt allerdings den Cookie FPU richtig auf SFP004 ...
Kann mir jemand für zwei bis drei Tage eine Atari SFP004 ausleihen um einen Schaltplan zu erstellen. Porto übernehme ich natürlich.
-
... allerdings wird im MSTE an Adressen nur A5 bis A15 genutzt also ohne A16 bis A23 ...
Habe mal die Adressen weg genommen und die TTL Eingänge high gelegt aber das Verhalten bleibt das gleiche ohne Änderung.
-
Artur aus Polen hat mir freundlicherweise gute Fotos seiner Atari SPF004 geschickt. Die Karte hat einen 74S00, einen 74LS27 und zwei 74S30. Im ersten Anschein stimmt die Beschaltung mit meinem Nachbau überein. Zu 100% kann ich das nicht sagen weil da einige Leitungen unter Bausteine verlaufen und ich nur vermuten kann wo die hingehen ...
Wer kann mir eine Karte leihen oder einen Schaltplan zeichnen?
-
Vielleicht liegt mein Problem ja an der Wahl der HC Bausteine. Vielleicht sind ALS oder noch schneller AS besser ?
Keine Ahnung ...
-
Ein Blick ins Profibuch zeigt wo die Adresse eingeblendet ist. Müsste man mit einem GAL 20V8 wiedergeben können.
-
Ja wird ja im MSTE mit einem PAL/GAL16V8 gemacht. Aber ohne wie bei der Atari SFP004 wäre besser ...
-
Aufwändiger, nicht Besser!
-
Schnellere Gatter machen keinen Unterschied.
-
Gembench 4.03 testet nach meinem Wissen alle beide Arten der FPU Anbindung also an 68000 und ab 68020 ...
Mega STE mit 881 FPU - Test läuft und FPU wird erkannt
881 FPU in Viking ECL Grafikkarte - Test hängt, FPU wird erkannt
Djordje Vukovic SFP004 Nachbau - Test hängt, FPU wird nicht erkannt
... alles bezogen auf Gembench 4.03
Mit dem FPU Line-F Emulator von Arne und dem DML FPU Test geht es nur im Mega STE. Mit der Viking geht es nicht. Seltsam das sich die drei Sachen so unterschiedlich verhalten.
-
Faszinierend. Wenn mir irgendwann mal ein günstiger 68881 zuläuft, teste ich gerne in meinem MegaST mit Viking-Karte. (Natürlich, nachdem ich mich in einem anderen Rechner vergewissert habe, dass die FPU kein Fake und nicht defekt ist.)
-
@czietz ... Hatte mir drei vor einiger Zeit aus China über Ebay gekauft für 5,- Euro pro Stück. Alle mit dem DML Tool im MegaSTE getestet und alle in Ordnung. Eine musste ich erst sauber machen. Wieso sollten die Leute 16Mhz MC68881 faken, was vielleicht sein kann das eine mal kaputt ist. Drei bestellen und gut ist ...
-
Wieso sollten die Leute 16Mhz MC68881 faken
Gegenfrage: Wieso sollten Leute EPROMs faken? Ich hatte mal mehrere EPROMs gekauft; in einem davon war (bewiesen!) ein anderer Chip drin als draußen draufstand.
, was vielleicht sein kann das eine mal kaputt ist. Drei bestellen und gut ist ...
Für 3 FPUs (in der Hoffnung, dass eine davon echt und funktionsfähig ist) plus Versandkosten plus Steuern plus Gebühren für die Zollabwicklung zahle ich dann so viel, dass ich auch (mutmaßlich NOS) bei Kessler bestellen könnte.
-
Ja bei 20,- Euro Neu lohnt das über Ebay nicht.
-
ich bin da mittlerweile auch vorsichtig bei den Chinasellern. hatte mal 10x EEProms bestellt (AMD), davon ging noch kein einziger. Mein Prommer zeigte die erst gar nicht an. Der Siebdruck war auch sehr merkwürdig. Sah super sauper aus, aber mit Aceton konnte man das einwandfrei wegwischen. Zum Vorschein kamen dann ST Micros, was auch nicht schlimm wäre, nur konnte mein Programmer diese nicht erkennen, geschweige flashen. Und die ST's kann mein Progger auf alle Fälle. Von Gals brauch ich gar nicht erst zu reden. Die sind mittlerweile alle gefakt habe ich das Gefühl
-
@Guus.Assmann ... hat sich viel Arbeit gemacht und mir eine Liste mit den original Verbindungen einer SFP004 geschickt. Aber das alles auseinanderklamüsern ist schon viel Arbeit. Ich warte bis ich eine Kaufen oder Leihweise bekommen kann ...
-
ich bin da mittlerweile auch vorsichtig bei den Chinasellern. hatte mal 10x EEProms bestellt (AMD), davon ging noch kein einziger. Mein Prommer zeigte die erst gar nicht an. Der Siebdruck war auch sehr merkwürdig. Sah super sauper aus, aber mit Aceton konnte man das einwandfrei wegwischen. Zum Vorschein kamen dann ST Micros, was auch nicht schlimm wäre, nur konnte mein Programmer diese nicht erkennen, geschweige flashen. Und die ST's kann mein Progger auf alle Fälle. Von Gals brauch ich gar nicht erst zu reden. Die sind mittlerweile alle gefakt habe ich das Gefühl
Und deshalb bestellst du AMD?
-
ich bin da mittlerweile auch vorsichtig bei den Chinasellern. hatte mal 10x EEProms bestellt (AMD), davon ging noch kein einziger. Mein Prommer zeigte die erst gar nicht an. Der Siebdruck war auch sehr merkwürdig. Sah super sauper aus, aber mit Aceton konnte man das einwandfrei wegwischen. Zum Vorschein kamen dann ST Micros, was auch nicht schlimm wäre, nur konnte mein Programmer diese nicht erkennen, geschweige flashen. Und die ST's kann mein Progger auf alle Fälle. Von Gals brauch ich gar nicht erst zu reden. Die sind mittlerweile alle gefakt habe ich das Gefühl
Warum nicht? die EEproms sollten 70ns Zugriffszeit haben, die Micros hatten 110ns. Abgesehen davon, sollte ein Käufer schon das bekommen, was angeboten wird ;)
Und deshalb bestellst du AMD?
-
ich bin da mittlerweile auch vorsichtig bei den Chinasellern. hatte mal 10x EEProms bestellt (AMD), davon ging noch kein einziger. Mein Prommer zeigte die erst gar nicht an. Der Siebdruck war auch sehr merkwürdig. Sah super sauper aus, aber mit Aceton konnte man das einwandfrei wegwischen. Zum Vorschein kamen dann ST Micros, was auch nicht schlimm wäre, nur konnte mein Programmer diese nicht erkennen, geschweige flashen. Und die ST's kann mein Progger auf alle Fälle. Von Gals brauch ich gar nicht erst zu reden. Die sind mittlerweile alle gefakt habe ich das Gefühl
Und deshalb bestellst du AMD?
Warum nicht? die EEproms sollten 70ns Zugriffszeit haben, die Micros hatten 110ns. Abgesehen davon, sollte ein Käufer schon das bekommen, was angeboten wird ;)
-
@Guus.Assmann ... hat sich viel Arbeit gemacht und mir eine Liste mit den original Verbindungen einer SFP004 geschickt. Aber das alles auseinanderklamüsern ist schon viel Arbeit. Ich warte bis ich eine Kaufen oder Leihweise bekommen kann ...
Habe mal einen Schaltplan in Eagle gesetzt aber die Liste von Guus hat leider etliche Fehler ...
Wenn jemand Leihweise eine FPU Karte für mich hat bitte melden.
-
Guus hat nochmal nachgebessert aber immer noch Fehlerhaft ...
Wenn jemand Leihweise eine FPU Karte für mich hat bitte melden.
-
Guus sagt das es jetzt stimmt ...
Da ist noch ein Pullup der auf das ungenutzte DSACK0 der FPU geht.
-
881 FPU in Viking ECL Grafikkarte - Test hängt, FPU wird erkannt
Ich habe unterdessen auch eine MC68881-FPU ("new old stock", tatsächlich) und sie in die Viking-Karte im MegaST eingebaut. Ich kann das Beispiel in https://www.chzsoft.de/site/site/assets/files/1041/atari_sfp.pdf durchspielen und die FPU liefert auch die richtigen(*) Antworten, berechnet also korrekt den Arkuscosinus von 0. Grundsätzlich funktioniert sie also.
Auch ein kleines Testprogramm in Pure C erkennt die FPU und funktioniert damit. Aber rechenintensivere Aufgaben wie den Benchmark aus Gembench 4 oder die Kombination aus FPU.PRG + FPUTEST brechen entweder ab oder hängen. So ganz stabil ist die FPU in der Viking also auch bei mir nicht. Ich habe den Eindruck, dass sie besser funktioniert je länger der Rechner läuft. Also ist wohl irgendwas arg grenzwertig und die Bauteilerwärmung schiebt es nur ein wenig in die bessere Richtung.
Allerdings hat die Festplatte im Rechner nun eine neue Betätigung als "Kreissäge" entdeckt und der MegaST ist jetzt nur mit Gehörschutz zu ertragen. Bis ich das Problem gefixt habe, sind weitere Tests also unterbrochen.
(*) Das Beispiel in meiner PDF-Datei wurde mit einem 68882 aufgenommen. Der 68881 verhält sich geringfügig anders und setzt manchmal das Come-Again-Bit, antwortet z.B. 0x9608 statt 0x1608 oder 0xB208 statt 0x3208. Aber dies nur am Rande; es beeinträchtigt den Betrieb nicht.
-
Habe mal eine Platine gesetzt nachdem Guus sagte alles wäre richtig. Bin gespannt ...
-
Auch ein kleines Testprogramm in Pure C erkennt die FPU und funktioniert damit. Aber rechenintensivere Aufgaben wie den Benchmark aus Gembench 4 oder die Kombination aus FPU.PRG + FPUTEST brechen entweder ab oder hängen. So ganz stabil ist die FPU in der Viking also auch bei mir nicht.
Tada! 68881 in der Viking stabilisiert. Beweis:
-
68881 in der Viking stabilisiert.
Wie? Wo? Was?
-
Ich habe den Fehler gefunden. Zumindest in meinem MegaST, denn es ist nicht gesagt, dass sich alle gleich verhalten.
Hier ist das Problem zu sehen. Die hellblaue Kurve zeigt die /AS-Leitung an der FPU; also alle Buszugriffe im Rechner. (Nicht jeder Bus-Zugriff geht zur FPU, natürlich.) Die magenta Kurve zeigt die /CS-Leitung (Chip-Select) an der FPU. Wenn sie "low" ist, wird die FPU angesprochen, reagiert also auf Bus-Zugriffe über /AS usw. Dargestellt ist ein Zugriff auf ein 32-Bit-breites FPU-Register; erkennbar daran, dass zwei Zugriffe in unmittelbarer Folge passiert. Zur Erinnerung: Die 68000-CPU im ST hat nur einen 16-bittigen Datenbus und muss die 32 Bit aus dem Register folglich in zwei "Häppchen" holen.
(https://forum.atari-home.de/index.php?action=dlattach;topic=16604.0;attach=30177;image)
Was man nun sieht: Die Chip-Select-Logik hat irgendeinen Glitch, eine Race-Condition, was auch immer. Diese Nadel beim zweiten Zugriff führt dazu, dass sich die FPU kurz nicht und dann doch wieder angesprochen fühlt, also statt zwei Zugriffen letztlich drei sieht. Und das ist genau das Problem! Das passt der State-Machine in der FPU nicht und sie steigt mit einem Fehler (Status 0x1D0D, "protocol violation", wie bei Dir @Lukas Frank) aus.
Vorläufige Lösung ... eher ein Hack, ganz offensichtlich so keine Dauerlösung:
(https://forum.atari-home.de/index.php?action=dlattach;topic=16604.0;attach=30179;image)
Der 1 nF Kondensator zwischen /CS und VCC macht die Nadel auf der /CS-Leitung quasi platt. Ich will noch herausfinden, wie die /CS-Logik implementiert ist; vielleicht kann das Problem an anderer Stelle besser lösen.
-
Super, vielen Dank. Bleib dran ...
Bei mir läuft der DML Test mit dem LineA Emu von Arne Fehlerfrei durch wenn der Rechner eine ganze Zeit an ist und entsprechend Temperatur hat/bekommt.
-
Bei mir läuft der DML Test mit dem LineA Emu von Arne Fehlerfrei durch wenn der Rechner eine ganze Zeit an ist und entsprechend Temperatur hat/bekommt.
Auch das kann ich bestätigen. Noch bevor ich heute den wahren Grund gefunden habe, hatte ich gestern die FPU mittels Heißluftföhn ordentlich auf Temperatur gebracht. Zu warm zum Anfassen, also geschätzte >50°C. Dann lief der Test auch. (Wie gesagt: das war noch vor dem Hack mit dem Kondensator an /CS.)
ICs ändern ja ihr Verhalten über Temperatur. Ich vermute, die FPU wird bei der Hitze zu träge, um die störende "Nadel" noch mitzubekommen.
-
Wie schon erwähnt, war ich mit dem 1-nF-Kondensator an der FPU-/CS-Leitung nicht zufrieden, der nötig war, um die "Nadeln" zu unterdrücken und die FPU stabil zu bekommen. 1 nF ist hier schon eine vergleichsweise große Kapazität und entsprechend verschleift sie auch die gewollten Änderungen des /CS-Signals.
Daher habe ich die Nadel rückwärts durch die Dekoderlogik verfolgt und habe eine Stelle gefunden, an der ein deutlich kleinerer Kondensator ausreicht: 270 pF zwischen Pins 7 (GND) und 8 (Ausgang) des 74LS30 mit der Bezeichnung U54:
(https://forum.atari-home.de/index.php?action=dlattach;topic=16604.0;attach=30269;image)
Das wird nun die Dauerlösung. FPUTEST (mit FPU.PRG) läuft nun stabil, auch bei sehr kalter FPU. (Hinweis: Ich habe die min. nötige Kapazität nicht bis zum Ende ergründet. 22 pF reichten nicht, mit 270 pF läuft es stabil; Zwischenwerte habe ich nicht getestet.)
-
Sehr schön, vielen Dank
-
Habe bei mir dort 220pF eingelötet, hatte sonst nichts.
-
Habe bei mir dort 220pF eingelötet, hatte sonst nichts.
Ich denke, der exakte Wert ist nicht kritisch. Funktioniert's denn damit?
-
Ja
-
Guus sagt das es jetzt stimmt ...
Da ist noch ein Pullup der auf das ungenutzte DSACK0 der FPU geht.
Platinen waren heute früh in der Post. Schnell mal eine aufgebaut und funktioniert. Habe den DSACK0 Pullup vergessen, macht aber nichts. Mittlerweile bestückt. @Guus.Assmann ... soll ich dir eine Platine zuschicken?
Bei Kessler hatten nur 74S30 und der Rest nur ALS, geht aber ohne Probleme. Der DML FPU Test lief unter TOS 1.04 mit dem FPU Emulator von Arne fehlerfrei. Gembench erkennt auch die FPU, automatisch nur mit TOS 2.06 wegen Cookie denke ich mal ...
-
Eine feine Sache Frank. Nun wir wissen ja das es nicht so viel Software mit FPU-Unterstützung gibt. Welche Software könnte trotzdem von der FPU profitieren, damit sich eine Anschaffung lohnt?
-
Diverse CAD Programme aus Zeiten wo es nur die Atari ST 68000 Reihe gab ohne 68020/30 + FPU Erweiterungen. Oder man schreibt selber Programme. Auch Fraktal Programme.
-
Hallo Frank,
Sehr gut das es jetzt functioniert.
Und ja, Ich bekomme gerne eine Platine.
Hab überigens schon mal auf eine Platine ein Oscillator von 40Mhz eingesetzt. Geht prima.
Schneller ging auch, 64Mhz. Aber das bringt nichts mehr, wegen Datentransport züm FPU.
Hab dies alles getestet mit ein 16Mhz FPU...
MFG/
Guus