Alles anzeigen
You are right:
17 passes in about an hour.
Ich habe einen 74S08 auf einer ISA-Karte gefunden und teste den grad.
Wasn’t going to be that easy was it ….. I re-read some of the superpet gazette articles and they reported no known issues with the single board version. Will power up my SP and check out the IC’s used ..
Kaum zu glauben, die Post war turboschnell:
Beide LS gegen S getauscht: Nach wie vor hängt OS/9 nach ein paar Minuten. 
GNAAAA
Kannst du nochmal zusammenfassen wie der stand jetzt ist, was geht, was geht nicht? Ich lese: jetzt geht wieder alles, außer OS9 wenn keine tastatureingabe kommt?
Ich bin ja kurz davor dir den anderen nachbau der MMU zu kaufen 
Kannst du nochmal zusammenfassen wie der stand jetzt ist, was geht, was geht nicht? Ich lese: jetzt geht wieder alles, außer OS9 wenn keine tastatureingabe kommt?
Gerne!
- alle Speichertestprogramme vom Macher des Super-OS/9 laufen fehlerfrei über Stunden durch
- der Waterloo Modus mit seinen Programmiersprachen ist absolut stabil- zumindest, was ich testen konnte
- 6502 Modus einwandfrei
- COM-Master im 6809-Modus einwandfrei
- OS/9 läuft deutlich besser, hängt aber dennoch nach ein paar Minuten
Kurzum:
Ohne OS/9 würde man nicht merken, dass was fehlt.
Ganz andere Frage: Ist sichergestellt, daß das verwendete OS/9 Image fehlerfrei ist?
Funktioniert das auf einem originalen MMF 9000?
Ganz andere Frage: Ist sichergestellt, daß das verwendete OS/9 Image fehlerfrei ist?
Funktioniert das auf einem originalen MMF 9000?
Ich kann nochmal ein anderes Image testen… hab aber wenig Hoffnung.
Ob es auf einem Originalen MMF/SuperPET läuft, weiß ich nicht.
Evtl. kann AndyG das mal testen?
Sure, happy to test … I use zoom floppy to create the disks from the .d80 image
Just give me a few days as work is taking my time right now ….
I also tested another image from zimmers… guess what? 
I could play adventure for at least 10 minutes… then it froze again.
I passed on most of the os/9 images to Bo having collected them from various people over time and also built some application images (c compiler, forth) up by taking files from os/9 images for the dragon 64.
One thought, have you monitored the 5v voltage regulators on the board ? Are they dropping a little over time and when hot ?
I passed on most of the os/9 images to Bo having collected them from various people over time and also built some application images (c compiler, forth) up by taking files from os/9 images for the dragon 64.
One thought, have you monitored the 5v voltage regulators on the board ? Are they dropping a little over time and when hot ?
I was also thinking that it might be a thermal problem. However I doubt that OS/9 would then work properly (for some minutes) when rebooting the computer after a freeze (as thermal situation will not improve when just resetting it). Hence I would still rather suspect some kind of timing problem. I haven't monitored the hardware design discussion closely here, is there an oscillator on the SuperPET board that could probably adjusted/replaced to be slightly faster or slower? I understand that the MMU does some "nasty" tricks with the addressing (address latch $EFFC and /FIRQ), hence probably here some timings are "wrong" (which wouldn't occur with other SuperPET software). Maybe as first step also the /FIRQ line could be monitored with a scope, just to check which signals/timings appear there as long as OS/9 is running well and comparing it with the frozen state. I guess this first check might already reveal good insights, no need to use a logic analyzer.
One thought, have you monitored the 5v voltage regulators on the board ? Are they dropping a little over time and when hot ?
The regulators seem to be fine- at least from output voltage perspective.
Even when "icecold" (switching everything on after a few hours off) OS/9 froze.
Hence I would still rather suspect some kind of timing problem. I haven't monitored the hardware design discussion closely here, is there an oscillator on the SuperPET board that could probably adjusted/replaced to be slightly faster or slower? I understand that the MMU does some "nasty" tricks with the addressing (address latch $EFFC and /FIRQ), hence probably here some timings are "wrong" (which wouldn't occur with other SuperPET software). Maybe as first step also the /FIRQ line could be monitored with a scope, just to check which signals/timings appear there as long as OS/9 is running well and comparing it with the frozen state. I guess this first check might already reveal good insights, no need to use a logic analyzer.
I tried to scope /FIRQ line... but I may be to silly- or my oscilloscope (40Mhz but very broken) isn't able to get a good picture.
But when I switch to AC I can see some impulses at idle and some more when loading/activity.
Guess what: Since I'm doing this there is NO CRASH WHATSOEVER?! 
Longest time between two keyboard inputs are now 20 minutes- and it is still not frozen.
What a crazy system that is...
Alles anzeigenOne thought, have you monitored the 5v voltage regulators on the board ? Are they dropping a little over time and when hot ?
The regulators seem to be fine- at least from output voltage perspective.
Even when "icecold" (switching everything on after a few hours off) OS/9 froze.
Hence I would still rather suspect some kind of timing problem. I haven't monitored the hardware design discussion closely here, is there an oscillator on the SuperPET board that could probably adjusted/replaced to be slightly faster or slower? I understand that the MMU does some "nasty" tricks with the addressing (address latch $EFFC and /FIRQ), hence probably here some timings are "wrong" (which wouldn't occur with other SuperPET software). Maybe as first step also the /FIRQ line could be monitored with a scope, just to check which signals/timings appear there as long as OS/9 is running well and comparing it with the frozen state. I guess this first check might already reveal good insights, no need to use a logic analyzer.
I tried to scope /FIRQ line... but I may be to silly- or my oscilloscope (40Mhz but very broken) isn't able to get a good picture.
But when I switch to AC I can see some impulses at idle and some more when loading/activity.
Guess what: Since I'm doing this there is NO CRASH WHATSOEVER?!
Longest time between two keyboard inputs are now 20 minutes- and it is still not frozen.
What a crazy system that is...
Maybe capacity of scope taps fixes the issue
Still running?
Still running?
NOPE.
But no change in the scoped /FIRQ-line. I think longest time was about 20-25min.
Next try was only 10min.
It seems the more I interact with the system, the earlier it freezes.
So was this the first run today? That went the longest? Then it would hint a thermal problem. -> Maybe it IS the 7805.
Have a Traco at hand that you could swap it for temporarily? Or Feed 5V with an external supply.
if you order some of these here ..let me know, then I will add some for me too
So was this the first run today? That went the longest? Then it would hint a thermal problem. -> Maybe it IS the 7805.
Have a Traco at hand that you could swap it for temporarily? Or Feed 5V with an external supply.
I don't think it is. The "cold" output of the regulator is about 5.01V, after about 30 minutes it's 4,99V, which both should absolutely be in spec.
There is no ripple whatsoever (scoped + measured with my rohde & schwarz UDS5) and last but not least: waterloo cobol is rock solid (running since one hour without any issues).
But you are right: It seems the first boot of OS/9 is the longest lasting one...
Will change back to OS/9 now and "stop the time"
https://idoregesz.hu/product/d…onverter-to3-1541-12v-5v/
if you order some of these here ..let me know, then I will add some for me too
Nope, it has to stay absolutely original- so no DC-DC-converter planned.
Vielleicht ein thermischer Fehler in einem anderen Bauteil?
Versuche doch mal wie es läuft, wenn Du einen Ventilator in den offenen Rechner blasen lässt.
https://idoregesz.hu/product/d…onverter-to3-1541-12v-5v/
if you order some of these here ..let me know, then I will add some for me too
Die Dinger wollte ihr doch einem CBM nicht ernsthaft antun. Wie sieht das denn aus? 
Wie passt ein thermischer Fehler zu dem Fehlerbild, dass der Rechner bei Tastatureingaben nicht abstürzt? 
Oder ist das inzwischen nicht mehr so?
Die Dinger wollte ihr doch einem CBM nicht ernsthaft antun. Wie sieht das denn aus?
Gut, wenn die "modernen" DC-DC-Wandler mit einer Blechkappe verkleidet werden könnten...
Aber zur Fehlereingrenzung würde ich das durchaus in Erwägung ziehen - Ich glaube aber nicht, das es ein Thermischer Fehler ist...
Ich glaube aber nicht, das es ein Thermischer Fehler ist...
Der Ventilator-Test würde recht schnell Aufschluß darüber geben.
Der Verdacht eines Refresh-Problems ist für mich auch noch nicht ausgeräumt.
Ich möchte mich mal kurz einklinken. Ich bin auch bei der Refresh - Theorie. Bei einem Kaypro hatte ich nach einer Reparatur das gleiche Phänomen) (läuft solange er beschäftigt ist, Absturz nach ein/zwei Minuten idle) und musste dann lernen, dass es 4164 mit 128 Refreshzyklen gibt und solche mit 256. Ich hatte natürlich den falschen eingebaut, und den vertrug der Kaypro nicht.
Das dumme an der Theorie ist, dass die 4164 von TI wohl schon ausprobiert wurden, und die haben afair den 128er Refresh und müssten eigentlich beide Refresh-Arten vertragen.
In #413 hatte ich ja schonmal die 4164 Vergleichstabelle verlinkt:
Laut der brauchen die TI 256 Refresh-Zylken, die Mostek (sind ja aktuell noch drin?) hingegen 128.
Meiner Meinung nach müsste die Refresh-Erzeugung mal meßtechnisch auf den Prüfstand.
Der Ventilator-Test würde recht schnell Aufschluß darüber geben.
Der Verdacht eines Refresh-Problems ist für mich auch noch nicht ausgeräumt.
Stimmt, um andere ICs zu prüfen und auszuschließen...
Allerdings würde ich auch den 5V-Regler ausschließen wollen... wie CBM_Ba schon geschrieben hat, hat er sich die 5V-Schiene mit dem Oszi angesehen und es hat sich auch nach längerer Betriebszeit die Spannung gerade mal sich um 15 bis 20mV geändert. Damit würde ich ihm zustimmen, das die 5V-Schiene OK ist.
Ich denke auch, das hier noch ein Refresh/Timing-Problem ist... vielleicht fühlt sich ein D-Latch oder sonst was sporadisch angesprochen, obwohl das nicht passieren sollte. Könnte eventuell ein Pull-Up oder Pul-Down Widerstand zu groß dimensioniert sein (4,7KOhm) und die entsprechenden Eingänge nicht "In Time" auf den benötigten Pegel ziehen? In etlichen Siemens-Geräten habe ich Pull-Ups mit 2,2KOhm oder 1,2KOhm gesehen.
Wie passt ein thermischer Fehler zu dem Fehlerbild, dass der Rechner bei Tastatureingaben nicht abstürzt?
Oder ist das inzwischen nicht mehr so?
Es ist schon so, dass der Rechner auch bei/während Tastatureingaben abstürzt. Aber es dauert eindeutig länger, als wenn man ihn idlen lässt.
Wenn man eine Taste dauerhaft betätigt lässt, hängt er sich ewig nicht auf, spinnt aber unmittelbar danach, wenn man bspw. das Directory aufrufen will.
In #413 hatte ich ja schonmal die 4164 Vergleichstabelle verlinkt:
https://www.minuszerodegrees.net/memory/4164.htm
Laut der brauchen die TI 256 Refresh-Zylken, die Mostek (sind ja aktuell noch drin?) hingegen 128.
Meiner Meinung nach müsste die Refresh-Erzeugung mal meßtechnisch auf den Prüfstand.
Die Mostek sind noch drin und damit läuft er als MMF ohne jegliche Ausfälle.
Mit den TI lief er am schlechtesten, kann aber auch an defekten RAMs an sich gelegen haben, welche trotz positivem Test ne Macke haben?
Was mir noch auffällt.. der LS273 (u3) der MMU hat keinen Decouplingcap und ist mit einer recht ellenlangen Leitung der letzte im Bunde der die 5V bekommt. Könnte auch so ein Ding sein.
Evtl mal von unten einen dazupacken.
Auf der anderen Seite ist Der LS02 (U5) mit GND ganz hinten. Evtl dessen GND mit dem C4 verbinden.
