ich bin gerade auf dem Nostalgie- und Retrotrip. Jetzt steht ein sehr gut erhaltener Amiga 500 auf dem Tisch. An sich läuft alles, einen Grafikfehler hab ich durch Tausch des Agnus beseitigt. Es bleibt aber noch ein kleiner, mysteriöser Fehler übrig.
Der sieht so aus. Bei bisher 2 Spielen Turrican 2 und Apydia kommt es beim Intro zu dem Effekt, daß die Animationen stark beschleunigt laufen, wie Schnellvorlauf. Der Ton ist aber massiv gebremst. Nach ner Weile fängt sich Turrican 2 im Intro wieder, man kann dann das Spiel normal starten und spielen.
Folgendes wurde schon gemacht.
Alle ICs aus den Sockeln gezogen und IC-Pins und Sockel mit Kontakt 60 besprüht
Agnus gewechselt
Denis gewechselt
Beide CIAs über Kreuz getauscht
Alle Pins an der CPU mit dem Oszi angeschaut, vor allem die drei Interruptleitungen
Systemtest mit Amiga Testkit 1.2
Das wird schwierig werden, vor allem bei den IC-Sockeln mit gedrehten
Kontakten. Da Kontakt 60 ein Kriechöl (mit oxidlösenden Zusätzen) ist,
dringt es in jeden Winkel vor. Vielleicht geht es, wenn man das gesamte
Mainboard in das Reinigungsmittel taucht und darin für längere Zeit
kräftig hin und her schwenkt.
Das klingt nach DMA-Kanälen zwischen denen zu schnell gewechselt wird, der DMA-Controller sitzt meines Wissens im Agnus, der ja kürzlich angefasst wurde, also könnte man mal da schauen. IMHO gibt es verschiedne Agnusi, Big Fat etc. die sich in der große des addresierbareb Chip-Mem's unterscheiden, ich kenn da aber jetzt keinen generellen Fehler der sich auf sowas zurückführen lässt.
Ach ja, wegen dem Sockel werden die Chips recht warm, das könnte das Verschwinden nach einiger Zeit erklären.
https://www.amigawiki.org/doku.php?id=de:parts:agnus
Am Mono könnte man sich mal die Frequenzen von HSYNC/Vsync anschauen, manche Multisyncs zeigen die im Status-OSD. Im Amiga wird ja alles, auch Videorate von einem System-Quarz abgeleitet, Probleme bei der Taktteilung könnten sich also an den Videotakten sehen lassen.
Wozu? Das Bild ist 1A. Hängt über RGB am Monitor. Andere Spiele laufen ohne Auffälligkeiten.
manche Multisyncs zeigen die im Status-OSD. Im Amiga wird ja alles, auch
Videorate von einem System-Quarz abgeleitet, Probleme bei der
Taktteilung könnten sich also an den Videotakten sehen lassen.
CPU-Takt hatte ich mit 7,09MHz gemessen, das stimmt exakt.
Ja, ist ein REV 6. Hmm, Paula kodiert die Interrupts, die an die CPU
gehen. Muss ich mal genauer messen.
Ja, IRQ kam mir auch in den Sinn, allerdings haste ja da schon mit scope gemessen. Links liegt ja der ganze Bus "frei auf dem PCB" und an die Speichererweiterung mit Echtzeituhr im Schacht denkt man auch zu letzt.
Sieht für mich auf jeden Fall auch nach einem IRQ-Problem aus.
Aber es können ja nicht nur die CIAs IRQs auslösen, sondern auch die Custom-Chips. Z.B. der Copper kann IRQs an bestimmten Rasterzeilenpositionen auslösen indem er ein Bit im Interrupt-Controller setzt.
Das wurde gerne genutzt um die CPU mit dem Bildaufbau zu synchronisieren für den Refresh etc.
Früher hätte ich das vermutlich aus dem FF gewusst...
Mein Verdacht ist ein defekter Timer bzw. Interrupt vom Timer.
Das wäre in diesem Fall wahrscheinlich der VBL-Interrupt, deshalb meine Frage, ob die Version für NTSC-Systeme gedacht ist.
Guck Dir mal das Netzteil an, je nach Amiga-Modell hat das 50/60 Hz aus der Netzfrequenz ("Tick-Signal") geliefert, womit dann der Rest synchronisiert wurde.
Edit: Kommt beim A500 nicht aus dem Netzteil, aber in Richtung VSYNC würde ich gucken, wenn es denn wirklich ein Hardwaredefekt ist.
Ja, ist ein REV 6. Hmm, Paula kodiert die Interrupts, die an die CPU
gehen. Muss ich mal genauer messen.
Ich hab mal an U3 (Paula) gemessen. Pin 18 (_INT6 von U8, CIA-B) geht nach dem Cracker Intro dauerhaft auf LOW. Die beiden anderen Pin 17 und 16 bleiben HIGH. In der fraglichen Sequenz mit der Störung pulst _INT3 von U2 (Agnus) mit ca. 2kHz.
BTW: der Referent "schwärmte" von einem speziellen Diagnose ROM, es war
wohl dieser:
Den habe ich zufällig hier, denn der Vorbesitzer hat einen 4:1 ROM eingebaut, mit Kickstart 1.3, 2.0 und 3.2 sowie dem Diagnose ROM.
Ergebnis. Alles OK. Alles Interrupts werden als korrekt diagnostiziert und die vier Timer der beiden CIAs laufen auch korrekt. Sehr merkwürdig.
Aber es können ja nicht nur die CIAs IRQs auslösen, sondern auch die
Custom-Chips. Z.B. der Copper kann IRQs an bestimmten
Rasterzeilenpositionen auslösen indem er ein Bit im Interrupt-Controller
setzt.
Das wurde gerne genutzt um die CPU mit dem Bildaufbau zu synchronisieren
für den Refresh etc.
Ist bekannt. Die IRQs werden laut Schaltplan nur von Paula kodiert. Es gibt drei Eingänge, wobei 2 von den beiden CIAs kommen. Der dritte kommt nur von Agnus, vermutlich als Sammelsignal aller Interruptquellen im Agnus.
Ich tippe immer noch auf einen Defekt in Paula an der Stelle.
Die IRQs werden laut Schaltplan nur von Paula kodiert. Es
gibt drei Eingänge, wobei 2 von den beiden CIAs kommen. Der dritte kommt
nur von Agnus, vermutlich als Sammelsignal aller Interruptquellen im
Agnus.
Ich tippe immer noch auf einen Defekt in Paula an der Stelle.
Also wenn die Paula gesockelt ist (ich mag "meine Freundin" grad nicht aufschrauben) könnt ich leihweise eine zum zeitweiligen Test im Raum 0 89 freigeben.
Später hat man den Leitungen vom Expansion jeweils einen statt zwei Pulls spendiert.
Den [Diagnose-ROM Anm.d.A.] habe ich zufällig hier, denn der Vorbesitzer hat einen 4:1 ROM
eingebaut, mit Kickstart 1.3, 2.0 und 3.2 sowie dem Diagnose ROM.
Dann würd ich den Diagnose-ROM resp die serielle Schnittstelle darin mal in Inbetriebnehmen. Der soll wirklich gut fürs debugging sein, der genannte Referent konnte damit wohl seinen "halben" DIY-Amiga in Betriebnehmen.
Also wenn die Paula gesockelt ist (ich mag "meine Freundin" grad nicht
aufschrauben) könnt ich leihweise eine zum zeitweiligen Test im Raum 0
89 freigeben.
Danke fpr das Angebot, aber der Postmann hat gerade mein Paula vorbei gebracht. Ergebnis. Der Fehler ist immer noch da. 8-(
Hast Du schon einmal einen anderen Datenträger mit dem Spiel probiert?
Häää? Ich hab ein Dutzend Spiele und ebensoviele Demos getestet, alles OK.
Der Fehler ist sehr exotisch. Es liegt nicht an der Diskette, da bin ich mir relativ sicher.
Alternativ Gegenprobe mit dieser Diskette auf einem anderen Amiga.
Hab keinen, außerdem lohnt sich der Aufwand nicht.
Online bei Diablo2 gibt es übrigens einen ähnlichen Effekt, wenn man z.B. einen Bereich wechselt, oft z.B. wenn man in eine Höhle geht. Man denkt, es passiert nichts, das Spiel bzw. die Grafikkarte stürzt ab..aber nach ein paar Sekunden geht es wieder weiter und dann eben auch ein paar Sekunden total beschleunigt.
Ist manchmal ärgerlich, wenn man noch ein paar Sekunden ErfahrungsBonusSchrein hat, um Boss-Monster zu finden (viel Erfahrungspunkte) und durch den Hänger läuft diese Zeit eben auch ungenutzt ab.
Es hat irgendwas mit Geschwindigkeit (und Synchronisation?) zu tun beim Amiga, glaube ich, der Hülsbeck hatte den Musikteil recht performant und trickreich programmiert.
Es hat irgendwas mit Geschwindigkeit (und Synchronisation?) zu tun beim
Amiga, glaube ich, der Hülsbeck hatte den Musikteil recht performant und
trickreich programmiert.
Der Amiga hat vier Stimmen aka DMA-Kanäle zum DAC, manche implementierten die Soundausgabe so, dass (bis zu) sieben (acht?) Stimmen ausgegeben wurden. Wie konkret diese "Akkustik-täuschung" gemacht wurde entzieht sich grad meiner Kenntniss. Vermutet werden kann, das die Sounddaten zweier Stimme in die für einen Kanal umgerechnet wurden, also quasi digital moduliert. Oder die DMA-Kanäle wurden schnell multiplext, also quasi die Abtastrate auf zwei Stimmen aufgeteilt... oder ... aber alles spekulatius.
Da die Grafik auch beeinträchtigt ist (wohl insbesonders die Blitter-Objects, sprites) und der Blitter auch einen DMA-Kanal hat könnte man das Problem im DMA-Bereich verorten (und damit beim DMA-Master Agnus). Aber das wurde bereits genannt.
Der DMA-Bereich definiert ja bekanntlich den Bereich des Chip-RAM's deshalb kann man an verschiedenen Kombinationen von Agnus-Varianten und timing Problemem des Chip-rAM's denken.
In der Bild-Mitte gibt es bei der Umsetzung zum characterfont Fehler,
der Bereich in der ASCII dazu steht ist wohl fehlerhaft
(beschrieben?/gelesen?).
Ja, ist mir auch schon aufgefallen. Ich hab gestern auch mal alle
Signale am Garry mit dem Oszi angeschaut, alles sauber.
Dann sind die Daten irgendwo auf dem Weg vom Diskdrive(?)->RAM-> Monitor "verloren gegangen". Spontan würde sich auf einen lokal begrenzten Speicher-IC-Fehler tippen, allerdings wird später der Font korrekt dargestellt was gegen die Speicherthese spricht. Also eher ein temporäres Daten-Busproblem, allerdings ziemlich konstant,... schon rätselhaft. Funkt der Refresh dazwischen (sähe aber auch anders aus)???
multiplext, also quasi die Abtastrate auf zwei Stimmen aufgeteilt...
oder ... aber alles spekulatius.
Ja, und da der Effekt auch bei Apydia auftritt, wo auch der Chris Huelsbeck die Musik gemacht hat, liegt es nahe, daß dort die trickreiche Software den Fehler auslöst.
Da die Grafik auch beeinträchtigt ist (wohl insbesonders die
Blitter-Objects, sprites) und der Blitter auch einen DMA-Kanal hat
könnte man das Problem im DMA-Bereich verorten (und damit beim
DMA-Master Agnus). Aber das wurde bereits genannt.
Ja. Aber es sieht so aus, als ob die CPU mit Interrupts überflutet wird, welche das Timing der Animationen steuern und dadurch der Update der Audiokanäle extrem ausgebremst wird. Die Grafikobjekte sind ja nicht gestört, alles sauber. Mit Ausnahme der kleinen Schrift, das könnten aber auch Sprites sein.
Der DMA-Bereich definiert ja bekanntlich den Bereich des Chip-RAM's
deshalb kann man an verschiedenen Kombinationen von Agnus-Varianten und
timing Problemem des Chip-rAM's denken.
Möglich, aber unwahrscheinlich. Wenn der RAM nen Treffer hätte, würde sich da auch anderswo äußern.
IMHO gab es auch andere Programme die "trickrich" mehr als vier Stimmen
abspielten, bspw. der Octalyzer. Die könnte man auch testen.
betreffs Scope Messung
Evtl vorhandene Bandbreitenbegrenzung am Scope ausgeschaltet? und manchmal ist ein Problem "weg" sobald man mit der scopespitze dran ist. Dann hat man gern ein skew signallaufzeitenproblem.
Der speicher besteht doch aus einzelnen IC's, da hat vielleicht einer davon ein Problem? Nachlöten?
Und die vielen IRQ kommen vielleicht vom Joystick? Den mal testhalber abstecken (obwohl der ja bei manchen Amigas quasi "festgewachsen ist ;-) )
Es riecht nach verkokeltem Plastik und mein Monitor ist dunkel, nur der Ton läuft noch.
Auschraub
Ist es normal, daß am Zeilentrafo karamelartige Substanz austritt? Eher nicht. Scheibenkleister! Die Warnung aller Retrokanäle vor diesem Typ Zeilentrafo hat sich mal wieder bewahrheitet! Naja, er lief bei mir vielleicht 20-30h, nachdem er sicher 20 Jahre und mehr geruht hat.
Wie konkret diese "Akkustik-täuschung"
gemacht wurde entzieht sich grad meiner Kenntniss.
Zum Beispiel sehr schnelle Wechsel, um Akkorde zu spielen. Ich weiß das aus einem Bericht, aber die Wiki-Seite weist auch auf Listings hin. Eventuell gibt es da was und könnte etwas Aufklärung beitragen.
Hast du was in dieser Richtung Falk?
Vielleicht ist es ja ganz normal, dass sich die gecrackte Software nicht
ganz so wie die originale verhält. Deswegen:
Nö. Denn ich hatte damals auch viele "Privatkopien", auch von Turrican 2, lief problemlos. Und die gleiche Software läuft auch fehlerfrei auf dem Emulator auf dem PC. Und das ist das IDENTISCHE Image, welches auf der Diskette zu finden ist, denn ich habe es dort drauf kopiert.
Hab keinen, außerdem lohnt sich der Aufwand nicht.
Tagelang planlos ICs zu tauschen und den armen Rechner in Kontaktspray
zu ersäufen, ist weniger Aufwand?
Ja ist es! Und ersäuft wurde keiner. Was für ein Gelaber!
Passt der Trafo in allen Amiga-Monitoren? (Abgesehen vom A2024, den ich hier auch noch habe)
A108[1|4][S] - eckig oder rund?
Ich werde meine Monitore mal öffnen und mit dem Bild vergleichen ...
Der Preis ist es mir wert.
Zu Deinem Problem: Ich weiß, dass die PLCC-Sockel im Amiga gerne mal ein Problem waren! Aber ob dies nun genau Deinen Fall betrifft, kann ich nicht sagen.
Eher nicht. Ich habe einen 1084S-P1, also eine Variante von Philips.
Zu Deinem Problem: Ich weiß, dass die PLCC-Sockel im Amiga gerne mal ein
Problem waren! Aber ob dies nun genau Deinen Fall betrifft, kann ich
nicht sagen.
Hab ich schon mit Kontaktspray bearbeitet, es steckt ein "neuer" Agnus drin und mit dem Oszi sehen alle Singnale OK aus.
So, ich hab nochmal den Gary und die CPU gewechselt, die gab es relativ billig auf Ebay. Ergebnis. Der Fehler ist immer noch da :-(
Ich hab auch mal das _INT6 Pin vom U8 (CIA) aus der Fassung gebogen und somit den IRQ inaktiv geschaltet. Ohne Wirkung. Die beiden Testprogramme laufen, aber zu schnell.
So langsam bin ich mit meinem Latein am Ende. Es kann sein, daß auch mein 2. Agnus den gleichen Fehler intern hat, wenn gleich das sehr unwahrscheinlich ist.
So langsam bin ich mit meinem Latein am Ende. Es kann sein, daß auch
mein 2. Agnus den gleichen Fehler intern hat, wenn gleich das sehr
unwahrscheinlich ist.
Vielleicht hilft ja hier dieser Tipp:
"Replaced Fat Agnus 8371 with a Fat Agnus 8372A on a A500 rev.5 with kickstart 1.2. The machine booted ok but for some reason every game(music graphics) I tried runs faster (NTSC?).
It was the pin41...I just used tape over it and the machine works fine."
Wie geschrieben, Agnus ist nicht gleich Agnus. (aber auch nur ne
Vermutung).
Hab ich schon. Der Pin ist offen, d.h. die Maschine kommt im PAL Modus hoch. Ich hab ihn auch schon mal auf GND gelegt, dann kommt die Maschine in NTSC hoch, das Problem bleibt aber.
Hm, das einzige was hier wohl noch nicht getauscht wurden, sind die die Speicherchips.
Ich hatte da mal bei der Inbetriebnahme eines Prototypen ( kein Amiga) Speicherfehler bei hoher Last - die Spannungsversorgung am Chip brach ein bei häufigem Addresswechsel und Checkboard-pattern. Das hatte ich allerdings nicht mit dem (langsamen) Multimeter entdeckt sondern durch Auslesen des IIC Powermonitors in der Schaltung auf dem des System-Architekt bestand. Das war noch einer der "sein Handwerk" verstand.
Vielleicht Scope an Power-Eingang des Chips anstecken und Triggerlevel auf das Minimum des Speichers stellen?
Da war die Zuleitung zu lang, schlechte Bufferung (C) könnten ein ähnliches Daten-Last-abhängiges Fehlerbild verursachen.
Ansonsten gab es halt Kombi aus Chipsatz und Fiormwareversion/Board-Revision auf denen nicht alle Spiele "liefen", weil zuviel "Tricks" verwendet.
Es gibt 2 Spiele die kurzzeitig Grafikfehler erzeugen. Alle anderen Spiele, Demos, Programme funktionieren? Das Spiel selbst läuft ja ohne Fehler, nur irgendwelche Zwischensequencen zeigen Grafikfehler. Ich würde deswegen nicht einen Fehler in der Hardware suchen. Die Spiele/Demos sind dann laut meiner Meinung etwas fehlerhaft programmiert. Diskettenfehler würde ich auch ausschließen, dann dürfte nichts mehr laufen und Lesefehler erzeugen.
Ich weiß nicht ob es für den Amiga Software gab für einen "CPU Stresstest" oder "Speichertest". Auf der anderen Seite könnte man diverse Demos testen die üblicherweise sehr Hardwarenah programmiert sind. Ein paar wenige werden einfach nicht laufen und der große Rest wird laufen.
Man bräuchte 2 identische Amigas um zu sagen bei dem einen funktioniert es und beim anderen nicht.
Die übliche 512kB auf 1MB Speichererweiterung ist sicherlich vorhanden. Nicht das hier aus Speichermangel kurz etwas schief läuft.
Es gibt 2 Spiele die kurzzeitig Grafikfehler erzeugen. Alle anderen
Spiele, Demos, Programme funktionieren? Das Spiel selbst läuft ja ohne
Fehler, nur irgendwelche Zwischensequencen zeigen Grafikfehler.
Ja. Wobei es eher ein Geschwindigkeitsfehler der Animationen ist, die Grafik ist korrekt (bis auf die kleinen Störungen im Text).
Ich
würde deswegen nicht einen Fehler in der Hardware suchen. Die
Spiele/Demos sind dann laut meiner Meinung etwas fehlerhaft
programmiert.
Mit Sicherheit nicht. Denn erstens hätte man sie so NIEMALS veröffentlicht und 2. läuft das IDENTISCHE Diskettenimage auf dem Emulator fehlerfrei. Und damals (tm) auf meinem A500 und A1200 lief es auch fehlerfrei.
Ich weiß nicht ob es für den Amiga Software gab für einen "CPU
Stresstest" oder "Speichertest".
Gibt es, hab ich schon getestet, kein Fehler feststellbar. Es ist auch mit sehr hoher Wahrscheinlichkeit KEIN Speicherproblem.
Auf der anderen Seite könnte man
diverse Demos testen die üblicherweise sehr Hardwarenah programmiert
sind.
Auch schon alles passiert.
Ein paar wenige werden einfach nicht laufen und der große Rest
wird laufen.
Apfelmus ist Mus aus Äpfeln . . .
Man bräuchte 2 identische Amigas um zu sagen bei dem einen funktioniert
es und beim anderen nicht.
Nö.
Die übliche 512kB auf 1MB Speichererweiterung ist sicherlich vorhanden.
Ja, aber beide Spiele laufen zumindest bis zum Intro auch mit nur 512kB, was sich heute kaum einer noch vorstellen kann.
Nicht das hier aus Speichermangel kurz etwas schief läuft.
Sicher nicht.
Ich hab schon "ein wenig" Ahnung vom dem, was ich tue.
soweit erstmal nachvollziehbar. Dennoch muss ich, muss man sich, eine Gegenfrage stellen. Wenn alles andere funktioniert, warum soll die Hardware defekt sein? Wenn man dafür eine plausible Antwort hat, die allen Stand hält, kann man sich weiter der Hardware widmen.
Mich stören 2 Begründungen. Das es damals funktionierte hat jetzt keine Bedeutung mehr. Wie alt sind die Disketten? Das es im Simulator funktioniert hat das 100% Gewicht? Das ist etwas nachprogrammiertes und kein echter Hardwareersatz. Verstehe mich nicht falsch, ich will deinen Tatendrang nicht bremsen. Ich denke nur langsam du suchst einen Fehler den es nicht gibt. Du darfst mich jedoch gern eines besseren Belehren.
Wenn alle Stricke reißen, muss ich mal auf dem Dachboden (nicht bei mir) schauen ob mein Amiga noch lebt und testen. Danach ergibt sich alles andere. Dann besteht die Chance deine Disketten in einem anderen Amiga zu testen.
soweit erstmal nachvollziehbar. Dennoch muss ich, muss man sich, eine
Gegenfrage stellen. Wenn alles andere funktioniert, warum soll die
Hardware defekt sein?
Weil es auf anderer Hardware und dem Emulator korrekt läuft.
Mich stören 2 Begründungen. Das es damals funktionierte hat jetzt keine
Bedeutung mehr.
Aber sicher! Das heißt, daß es mal korrekt lief!
Wie alt sind die Disketten?
30 Jahre++. Aber sie wurden fehlerfrei verifiziert. Ein derartig spezifischer Fehler auf der Diskette ist praktisch unmöglich. Ich kann das Image auch auf eine andere, ebenso alte Diskette kopieren. Es wird der gleiche Effekt sein.
Das es im Simulator
funktioniert hat das 100% Gewicht?
Ja.
Das ist etwas nachprogrammiertes und
kein echter Hardwareersatz. Verstehe mich nicht falsch, ich will deinen
Tatendrang nicht bremsen. Ich denke nur langsam du suchst einen Fehler
den es nicht gibt.
Doch, denn ich sehe ihn reproduziebar.
Wenn alle Stricke reißen, muss ich mal auf dem Dachboden (nicht bei mir)
schauen ob mein Amiga noch lebt und testen. Danach ergibt sich alles
andere. Dann besteht die Chance deine Disketten in einem anderen Amiga
zu testen.
Hat schon jemand anderes angeboten. Danke dafür, aber ich glaube nicht, daß das viel bringt. Ich stocher noch ein paar Tage rum. Wenn nix zu finden ist, bleibt es so. Hat praktisch keine Bedeutung, ist reiner, sportlicher Ehrgeiz den Fehler zu finden.
Auf dem Board gab es anscheinend mal nen Schaden durch ausgelaufene Elkos. An 2 Stellen wurde repariert, sieht aber halbwegs professionell aus. Ist aber alles weit weg von den vermutlichen Fehlerquellen. Einmal am Serialport und einmal an der 5V Verteilung. Naja, kann trotzdem irgenwo ne Leitung defekt sein oder nen Kurzschluß haben. Aber werder kann noch will ich alle Verbindungen durchklingeln! 8-0
Das könnte auch ein EMV-Problem mit dem Ton- und Bildsignal sein. Die daran schuldigen Kondensator zu finden, wird meist eine längere Safari durch die Platinen mit ungewissem Ausgang.
Also auch in einer korrekten Fassung gibt es Fehler in der Grafik (wobei ich nicht einschätzen kann, ob eventuell eine Emulation "Schuld" ist): Beim Aufwärtsscrollen im Intro wird die dritte Text-Zeile horizontal vematscht (siehe Anhang).
Tritt der Fehler nur im Intro auf? Wenn ja, dann könnte man mal in Richtung Unterschiede Intro/Spiel schauen. Beides scheint hier die selbe Grafikengine zu sein, nur das eben der Joystick beim Intro keinen Einfluß auf die Sprites hat, Graphic (sprites?) und soundeffekte scheinen gekoppelt zu sein.
"Unvollstäöndiger reset" könnte ne Begründung sein, manche Programmierer verlassen sich halt auf defaultwerte in den Registern.
Ja, wobei gefühlt es an einigen Stellen leicht zähflüssig wird.
Wenn ja, dann könnte man mal in
Richtung Unterschiede Intro/Spiel schauen. Beides scheint hier die selbe
Grafikengine zu sein, nur das eben der Joystick beim Intro keinen
Einfluß auf die Sprites hat, Graphic (sprites?) und soundeffekte
scheinen gekoppelt zu sein.
Ja logisch, muss ja synchron laufen!
"Unvollstäöndiger reset" könnte ne Begründung sein, manche Programmierer
verlassen sich halt auf defaultwerte in den Registern.
WEIIIIIIT hergeholt! Das lief alles schon fehlerfrei. Vor 35 Jahren! (UFFF)
"Unvollstäöndiger reset" könnte ne Begründung sein, manche Programmierer
verlassen sich halt auf defaultwerte in den Registern.
WEIIIIIIT hergeholt! Das lief alles schon fehlerfrei. Vor 35 Jahren!
(UFFF)
Naja, ist aber schon mal vorgekommen das der Reset-Puls nicht das richtige timing hat und so nicht alle Komponenten ordentlich anfangen. Der #RESET ist ne ziemlich lange Leitung hier. Wie wird der eigentlich erzeugt, der RESET-Puls hier? (Erg. siehe unten)
Und weil das Alter erwähnt wird, auch manche Kerkos (Klasse ?2?, X5R) verlieren an Kapazität, so das ihr Nennwert nicht mehrerreicht wird. Wenn der C in einem RC-glied zu Verzögerung/Entprellung steckt, ändert sich dann auch das Zeitverhalten der Schaltung. Hat ich mal bei der Medizintechnik, da musste die 𝜏 und so auch für 20 Jahre Kontroll-rechnen.
Lt. Schaltplan gibt es da so Verdachtsfälle mit wenigen picofarad wie den C10 oder E103.
Also auch in einer korrekten Fassung gibt es Fehler in der Grafik (wobei
ich nicht einschätzen kann, ob eventuell eine Emulation "Schuld" ist):
Beim Aufwärtsscrollen im Intro wird die dritte Text-Zeile horizontal
vematscht (siehe Anhang).
...
Irgendwie blöd, dass man das Ding nicht mehr an den Fernseher anschließen kann. Unmöglich wohl nicht, aber eben nicht mal schnell. Würde beim Atari ST jetzt auch keine Verrenkungen in diese Richtung machen wollen.
Na schauen, wie die Bild- und Sounddarstellung da rüberkommt. Man könnte zwar annehmen, dass die ähnlich wie beim Emulator funktioniert. Wäre aber eben nur ein Annahme.
Na schauen, wie die Bild- und Sounddarstellung da rüberkommt.
Hää? Der Amiga hängt an einem 1084S Monitor. Es ist vollkommen egal ob dort ein Monitor, TV-Modulator oder gar nichts dran hängt. Der Fehler wird dadurch nicht verändert, weil ganz woanders entsteht.
Hää? Der Amiga hängt an einem 1084S Monitor. Es ist vollkommen egal ob
dort ein Monitor, TV-Modulator oder gar nichts dran hängt. Der Fehler
wird dadurch nicht verändert, weil ganz woanders entsteht.
Dann kann man aber zumindest fragen, was ein Emulator genau besser macht, als die Hardware.
Man würde ja erstmal ein Timing-Problem annehmen. Aber reicht das auch?
Hää? Der Amiga hängt an einem 1084S Monitor. Es ist vollkommen egal ob
dort ein Monitor, TV-Modulator oder gar nichts dran hängt. Der Fehler
wird dadurch nicht verändert, weil ganz woanders entsteht.
Dann kann man aber zumindest fragen, was ein Emulator genau besser
macht, als die Hardware.
Man würde ja erstmal ein Timing-Problem annehmen. Aber reicht das auch?
Du hast weder das Problem verstanden noch wirklich Ahnung, wie so ein Amiga funktioniert.
Siehe Anhang, gemessen am Kollektor von Q711. Astrein und schnell,
weniger als 200ns Anstiegszeit.
OK, wieder ein Prüffall, den man abhaken kann. Bei der Gelegenheit habe ich aber gelernt des beim Agnus 50 ns Set und Hold für den Reset drinstehen.
Bei CMOS will man eigentlich 4.4V für ein High am Ausgang, da scheint der Reset schon vorher auf die Bremse zu steigen. Aber da das obere Limit für den Low-Pegel von 0.5V flott erreicht ist, passt es wohl bestens.
Also zur Analyse musste man vielleicht das Grafikfehlerbild tiefer "aufdröseln" also funktional, nicht real am IC bröseln.
Da der Hintergrund passt, wird wohl das mit den bitplanes passen, also auch der DMA-Channel über den das geht. Der Fehler liegt wohl in der Geschwindigkeit der Alienblöcke, also der Sprites oder der Blobs? (Blitter-Object). Die scheinen aber auch sauber zu sein, nur ist eben die Bewegung recht flott.
Es scheint, als ob in dieser routine eigentlich per Framecounter (oder anderes) für die nächste sequenz einige (5 frames? aka 100 ms) gewartet werden sollte, hier scheint aber zu jedem Frame die Position der Sprites/Blobs aktualisiert zu werden. Vielleicht kein Zählen der Frames (per vsync?) (damit es für PAL wie NTSC passt) sondern systemticks?
Echtzeituhr war ja optional beim Amiga (in der Speichererweiterung), womit hat man dann einen timerinterrupt/tick mit ms -Auflösung erzeugt?
Edit: grad noch mal ne fehlerfreie Version angeschaut, da dauert dieser Intro-part von oben fast 2 Minuten (statt den 10 sec wie beim fehlerhaften).
Es scheint, als ob in dieser routine eigentlich per Framecounter für die
nächste sequenz einige (5? aka 100 ms) gewartet werden sollte, hier
scheint aber jedes Frame die Position der Sprites/Blobs aktuallisiert zu
werden sein.
Genau das ist das Problem.
Vielleicht kein Zählen der Frames (per vsync?) (damit es
für PAL wie NTSC passt) sondern systemticks.
Echtzeituhr war ja optional beim Amiga (in der Speichererweiterung),
womit hat man dann einen timerinterrupt/tick mit ms -Auflösung erzeugt?
Mit den CIA Timern. Jeder hat 2 normale 16 Bit Zähler A und B sowie eine Echtzeituhr (TOD, time of day). Die Timer A und B zählen mit F_CPU/10, hier 0,709MHz, die TOD zählt bei einem CIA mit VSYNC, der ander HSYNC.
Edit: grad noch mal ne fehlerfreie Version angeschaut, da dauert dieser
Intro-part von oben fast 2 Minuten (statt den 10 sec wie beim
fehlerhaften).
Das Intro geht weiter als mein Video. Komischerweise ist nach der gezeigten Sequenz der Ton und die Geschwindigkeit wieder normal, wenn nur Standbilder und bissel Text darunter angezeigt werden! Wenn dann aber in der Introschleife wieder die Spielfigur und das Turrican-Logo erscheinen, geht der Turbo wieder los! Bei Apydia ist der Turbo immer drin.
Das leichte Flacken kommt von der Kamera, nur der flackernde Text ist real.
Man müsste wissen, woher Turrican 2 und Apidya ihr Timing beziehen, dann könnte man zielgerichteter suchen. Aber ich habe weder das Wissen, noch Können noch die Werkzeuge, den Kram zu disassemblieren.
Man müsste wissen, woher Turrican 2 und Apidya ihr Timing beziehen, dann
könnte man zielgerichteter suchen. Aber ich habe weder das Wissen, noch
Können noch die Werkzeuge, den Kram zu disassemblieren.
Hm kürzlich hab ich eine "amiga action replay" cartridge verschenkt, weil ich sie nie brauchte...
Es gibt Beschreibungen von typischen Time event quellen ("clock tick"), die scheinen sich aber eher auf OS und A1200 zu beziehen und nicht auf A500 bare metal. Da steht was von serial port aber das macht IMHO wenig Sinn.
Die CIA's als Chips haste ja zur Genüge getestet, sockel und traces scheinen ja auch OK.
Eine Idee war noch, das mglw. die Trap door als bestückt erkannt wird, aber die RTC resp der 32768Hz quarz darauf nicht richtig will. Aber von der Speichererweiterung kommt wohl kein tick-signal.
Das Intro geht weiter als mein Video. Komischerweise ist nach der
gezeigten Sequenz der Ton und die Geschwindigkeit wieder normal, wenn
nur Standbilder und bissel Text darunter angezeigt werden!
Ist wohl dann ne andere engine, wenn keine Blob/Sprites gezeigt werden.
Vielleicht belegt die Sprite(Blob routine eine resource (wie tick-quelle) die für diesen Intropart frei wird. Vielleicht wird (intern) per Multiplexor auf eine andere IRQ-Quelle umgestellt. Oder ein Timer auf anderes Tick-Signal.
Ja, die harten Amiga Coder scheinen nicht mehr gross aktiv. https://www.youtube.com/watch?v=s1lVS4tW33g
Irgendwie fühlt sich das nach dem Copper (in Agnus) an. Der startet ja abhängig von der Strahlposition bestimmte Aktionen und lässt diese auch bleiben, wenn die Position schon vorbeigezogen ist (dadurch könnte etwas schneller werden - bzw. so wirken). Und dann flimmert es auch.
Ich gehe fast davon aus, dass Du die 5V am Agnus schon mit Scope und Multimeter angeschaut hast!? (Ich habe dazu nichts geschriebenes gefunden)
Nur ein Versuch: Zieh mal die 512k Speichererweiterung heraus - sofern vorhanden.
Es wird die Vermutung "Selbstmodifizierender Code" gemacht, allerdings wusst ich nicht wie das die Probleme hier erklären sollte.
(Ach, das ist alles schon so lange her ...)
Ja, aber an die schönen Seiten der "Jugend" erinnert man immer wieder gern.
Und insbesonders an die "Freundin". (genialste Namenswahl für einen Computer ever ;-) (obwohl es angeblich nur wichtig war, das es im Alphabet vor Apple kommt) (und später kam dann einer mit "Acorn" ...) )
Ja, aber die meisten guten Programme für 68k Cpus kamen oft von Programmierern, die vorher schon viel mit dem Apple gemacht hatten.
Außerdem gab es mit diesen Cpus ja auch immer wieder und letztlich in die Sackgasse führende Kompatibilitäts-Probleme.
Irgendwie fühlt sich das nach dem Copper (in Agnus) an. Der startet ja
abhängig von der Strahlposition bestimmte Aktionen und lässt diese auch
bleiben, wenn die Position schon vorbeigezogen ist (dadurch könnte etwas
schneller werden - bzw. so wirken). Und dann flimmert es auch.
Kann sein.
Ich gehe fast davon aus, dass Du die 5V am Agnus schon mit Scope und
Multimeter angeschaut hast!? (Ich habe dazu nichts geschriebenes
gefunden)
Nein, kann ich mal machen. Nix zu sehen, alles OK.
Nur ein Versuch: Zieh mal die 512k Speichererweiterung heraus - sofern
vorhanden.
Und insbesonders an die "Freundin". (genialste Namenswahl für einen
Computer ever ;-)
In der DDR gab es ein Plattenlabel, das so hieß, das ließ das Ding in einem anderen Licht stehen. Der flackernde Fernsehmonitor und der orange Mauszeiger auf blauem Untergrund waren auch nicht so irre reizvoll ...
Kurz: Es gab auch Leute, die einen 68k lieber in einem anderen System nutzten.
Neue These: Das ist kein Fehler sondern ein unbeabsichtigt aktivierter Testmodus (Testmodus aka "Schnelldurchlauf").
Dafür spricht, das das Verhalten nur bei einem Hersteller auftritt, und das Spiel an sich wie jede aundere Software "ansich" funktioniert.
Realisiert könnte der vermutete Schnelldurchlauf über die oben vermutetet Warte/sleeproutine die eben dafür sorgt das nicht alle 20 ms aka "jedes frame" die Position der Spielfiguren neu berechnet wird, sondern nur innerhalb der normalene menschlichen Reaktionszeit (um 200 ms). In dieser Routine könnte es jetzt auch einen Test nach aktivierten Testmodus geben und gegebenfalls nicht gewartet sondern eben Schnelldurchlauf gemacht werden.
So wie manche Cheat-Modi eigentlich Modi für den Softwaretester sind, damit dieser Teile des Spiels erreichen (und damit auf Korrektheit überprüfen) kann, ohne stundenlang das Spiel fehlerfrei (ohne Leben zu verlieren) durchzuspielen. In der Release-Version bleibt dieser Testmode dann weiter drin.
Was Factor 5 damals zur Aktivierung des Testmodus ("Schnelldurchlauf Intro" verwendet haben könnte ... vielleicht ne Büroklammer im serial port, irgendein Anhängsel an irgendeinem port, Modifikation am Extension port, Floppy, PullUp am Joystick-anschluss, .... keine Ahnung.
Leider kann man damit als Nicht Factor 5 Firmenangehöriger nicht sicher sagen, was nun konkret dieses Verhalten auslöst und was man nun an der einzelnen Kiste anschauen sollte. Vielleicht Tastatur abklemmen, Joystick wechseln, Ports abklemmen (oder gerade anklemmen) ...
Aber dann nun (fast) jeder Chip gewechselt wurde und das "Verhalten" nur bei spezifischen Spielen an spezifischen Abschnitten beobachtet wird, würde ich Hardwaredefekt im eigentlichen Sinne ausschliessen.
Thema beendet. Ich hab die Kiste wieder zusammengeschraubt.
Was? So schnell schon aufgegeben? ;-)
Ich bin derzeit dabei, meinen Keller aufzuräumen und das alte Zeug darin
zu sortieren. Wenn ich damit fertig bin und noch Zeit übrig habe, werde
ich die beiden Amiga 2000 (ein A2000, und ein B2000), die dort noch
schlummern, wieder mal zum Leben erwecken. Zum Glück habe ich weder
Turrican 2 noch Apydia, so dass die Wiederinbetriebnahme aller
Voraussicht nach völlig reibungslos vonstatten gehen wird ;-)
Es war ein ungültiger Pegel von 1,3V an U3 Pin 41 (Paula, _RXD), der kam von U39 Pin 3. Ein zusätzlicher 1,5k Pull Up hieft den Pegel auf 3V ud damit halbwegs gescheiten Wert. Und siehe da, beide Spiele (Turrican 2 und Apydia) laufen sauber durch das Intro! Wie es scheint, wurde hier durch den Dauer-LOW Pegel dauerhaft ein RXD Interrupt der seriellen Schnittstelle ausgelöst, welcher durch die Software nicht korrekt verarbeitet bzw. eben NICHT ignoriert wurde!
Da dürfte dann aber U39 kaputt sein, oder die Paula.
Das Signal ist ja normal fix digital und mit gutem Pegel, ein Pullup unnötig.
Hoffe mal, es ist nur der Treiber defekt.
und Apydia) laufen sauber durch das Intro! Wie es scheint, wurde hier
durch den Dauer-LOW Pegel dauerhaft ein RXD Interrupt der seriellen
Schnittstelle ausgelöst, welcher durch die Software nicht korrekt
verarbeitet bzw. eben NICHT ignoriert wurde!
Argh! Da muss man erstmal drauf kommen :-) Sehr gut! Die Spieleentwickler haben da natürlich unsauber gearbeitet, dass sie nicht geprüft haben ob es ein Interrupt für die ser. Schnittstelle ist oder etwas anderes.
Der MC1489 hat ja intern einen 1,6K Pullip, ist wohl auch etwas grenzwertig... d.h. er kann max. ca. 1,5mA treiben.
Die
Spieleentwickler haben da natürlich unsauber gearbeitet
Die können da nix für.
Die Schnittstelle hat ja keinen Puffer, muss also sofort bedient werden, und das passiert im OS.
Leider konnte der A500 daher auch nur effektiv ~10kBaud, man konnte zwar höhere Raten einstellen, aber dann war halt immer eine lange Pause zwischen zwei schnell gesendeten Bytes.
Die Erkenntnis, das was mit der IRQ-Last nicht passt, wurde ja schon recht früh gemacht und die verschiedenen IRQ wurde ja auch auf mögliche Event-Störungen abgeklopft.
So wie es klingt, war der Ausschluß des (offenen) RS232 Interfaces als Fehlerort nicht unlogisch:
-das Test-ROM hat nichts gefunden (pustet es vielleicht seine Nachrichten über die RS232 raus?)
-Scope zeigte wohl auch keine (gültigen Events), vielleicht war der Trigger/der Trigger-Threshhold gerade ungünstig eingestellt.
-und einen (statischen) Illegalen Pegel (also Spannung mitten im verbotenen Bereich zwischen V_IL (0.8V) und V_IH (2.0V) hat man jetzt nicht unbedingt als Ursache für "hereinprasselnde" Trigger-Events auf dem Schirm. Sind die IRQ-Quellen dort (Paula (8364), pin 37 (_DKRD)) level oder edge ?
Also vielen Dank fürs Teilen des Reparatur-Berichtes, aus den Problemen bei Anderen kann man auch für eigene zukünftige Reparaturen/Designs manches lernen.
Sind die IRQ-Quellen dort (Paula (8364), pin 37 (_DKRD))
level oder edge ?
Das ist RxD, kein Interrupt.
Der Int dürfte daher kommen, das der UART immer ein Startbit sieht, und somit immer ein Byte einliest.
Da kein Puffer da ist (ich bin mir nicht mal sicher ob das Schieberegister getrennt ist) muss das Byte innerhalb kürzester Zeit (also <1Bit oder zumindest <1Byte) eingelesen werden, daher Int höchster Prio, und dann kommt ja sofort das nächste Byte ;)
Sind die IRQ-Quellen dort (Paula (8364), pin 37 (_DKRD))
level oder edge ?
Das ist RxD, kein Interrupt.
Genau genommen _RxD, also negiert (durch den erwähnten RS232-Empfänger zwischen Paula und Anschlussbuchse) .
Der Int dürfte daher kommen, das der UART immer ein Startbit sieht, und
somit immer ein Byte einliest.
Dann wird es eben zur Frage, wie die Hardware das (negierte) Startbit erkennt, am Pegel, der -dauer oder (auch) an der (einleitenden) Flanke ?!
Da gibt es unterschiedliche Implementierungen, gaaanz früher sogar mechanisch:
Beitrag "Re: Start- und Stopbit unterscheiden (RS232)"
Da kein Puffer da ist (ich bin mir nicht mal sicher ob das Schieberegister
getrennt ist) ...
"high level of software control" ist ein Euphemismus für "die Hardware ist so simpel wie es eben geht und die Software muss alles machen, inklusive des Bufferings. Aber wir haben ja etliche MHz Rechenpower dahinter, wer will schon mehr als 1000 Bytes pro Sekunde übertragen" ;)
Dann wird es eben zur Frage, wie die Hardware das (negierte) Startbit
erkennt
"Start" ist "nicht Ruhe" und schon liest das Ding 8 Bits plus x ein.
Oh da ist ja schon wieder "nicht Ruhe" also rein mit dem nächsten Byte.
Wenn da durch einen Dauerpegel eine Intflut ausgelöst wird kann es ja nicht flankengesteuert sein, gelle?
Das Problem war, das ohne ende vmtl. 00-Bytes mit maximaler Geschwindigkeit reinkommen.
Wenn bei der aus Kostengründen im ASIC "Paula" untergebrachten UART es noch nicht mal möglich ist, die Interrupterzeugung nur dann einzuschalten, wenn man sie auch wirklich braucht ...
Wenn bei der aus Kostengründen im ASIC "Paula" untergebrachten
UART es
noch nicht mal möglich ist, die Interrupterzeugung nur dann
einzuschalten, wenn man sie auch wirklich braucht ...
Dann muss man sich an den 'bewährten' Lösungsstrategien des gängigen OS Herstellers orientieren.
Anstatt den Fehler zu beheben, lieber die Baudrate herunter setzen und einen KBxxxxxx Eintrag erstellen. ;-)
Da kein Puffer da ist (ich bin mir nicht mal sicher ob das
Schieberegister getrennt ist)
Erzähl mal keinen Unsinn! Der Empfänger hat sowohl ein Schieberegister als auch Puffer! Damit hat man ein volles Byte incl. Start- und Stopbit Zeit, die empfangenen Daten abzuholen! Macht selbst bei 115200 Baud satte 86us.
Allerdings ist der Baudgenerator vom Amiga auf den Farbträger als Takt festgenagelt, sprich
SERPER =(3,546,895/baud)-1.
Warum da kein Faktor 8 drin steckt liegt vermutlich daran, daß der "versteckt" im Taktgenerator steckt, denn die 3,5MHz Farbträger sind 1/8 des Quarztaktes im System.
Wenn bei der aus Kostengründen im ASIC "Paula" untergebrachten UART es
noch nicht mal möglich ist, die Interrupterzeugung nur dann
einzuschalten, wenn man sie auch wirklich braucht ...
Doch, das geht. Ist aber, warum auch immer, nicht gemacht worden. Vermutlich ein Fehler, der aber mangels Hardwaredefekt jahrzehntelang unentdeckt blieb.
So what, ist ja keine Atomkraftwerkssteuerung.
Erzähl mal keinen Unsinn! Der Empfänger hat sowohl ein Schieberegister
als auch Puffer! Damit hat man ein volles Byte incl. Start- und Stopbit
Zeit, die empfangenen Daten abzuholen! Macht selbst bei 115200 Baud
satte 86us.
Klappt aber trotzdem nur mit Hausnummer 1000 Bytes pro Sekunde, zumindest beim Senden.
Wenn man mehr Baudrate einstellt kommen die Bytes selbst schneller, aber der Treiber lädt nicht schneller nach, also ist immer eine Lücke dazwischen.
Das passiert bei allen Raten oberhalb 9600 Baud, das hab ich damals sogar mit einem Ossi gemessen, aber ist halt auch schon 30 Jahre her.
Wenn man schneller einstellt klappt die Kommunikation immer noch ("da ist der Fehler also nicht"), dennoch geht der Transfer nicht wesentlich schneller ("was stimmt hier nicht?").
Was passiert, wenn man den Empfänger mit voller Bitrate zubrüllt hab ich nie getestet.
Ich weiß nicht mehr in welcher Programmiersprache das war, aber ich weiß noch das wir getestet haben ein 250 Byte langes Feld zu übertragen, also nicht "ein Byte und ein Byte und ein Byte" so das es am Compiler/Interpreter hätte liegen können oder so.
War was von Databecker, Pascal? Ich weiß nicht mehr. Zu alt.
Doch, das geht. Ist aber, warum auch immer, nicht gemacht worden.
Es gab doch sogar so Cheatermodule, bei denen man mit einem Poti einen NE555 einstellen konnte, der einfach Interrupts ausgelöst hat.
Die haben nix gemacht, nur die CPU abgelenkt, und schon ruckelte das Spiel und man konnte wildeste Level in aller Seelenruhe in Zeitlupe schaffen.
Erzähl mal keinen Unsinn! Der Empfänger hat sowohl ein Schieberegister
als auch Puffer! Damit hat man ein volles Byte incl. Start- und Stopbit
Zeit, die empfangenen Daten abzuholen! Macht selbst bei 115200 Baud
satte 86us.
Klappt aber trotzdem nur mit Hausnummer 1000 Bytes pro Sekunde,
zumindest beim Senden.
Schon wieder falsch. Auch der Sender hat ein Pufferregister.
noch nicht mal möglich ist, die Interrupterzeugung nur dann
einzuschalten, wenn man sie auch wirklich braucht ...
Doch, das geht. Ist aber, warum auch immer, nicht gemacht worden.
Hm, durch Verbiegen des ColdCapture Vectors kann man Programme auf dem Amiga quasie Reset-fest machen, das könnte man für diese Interruptquelle machen.
So hat man beispielsweise den TiefPass ausgeschaltet, falls es das Programm nicht selbst gemacht hat.
So hat man beispielsweise den TiefPass ausgeschaltet, falls es das
Programm nicht selbst gemacht hat.
Der Tiefpass wurde doch - wimre - durch den gleichen Pin geschaltet der auch die Power-LED Hell/Dunkel geschaltet hat. Das hatte ich bei meinem A1000 sogar noch nachgerüstet damals, ist schon etwas her :D
Anonsten konnte die interne serielle Schnittstelle auf jeden Fall stabil 19200 Baud bedienen, wenn nicht sogar 38400. Ich hatte mir damals für "mein" Mailboxprogramm einen eigenen Treiber geschrieben (in ASM), da die serial.device schon ziemlichen Overhead hatte.
Später gab es dann die 7-port A2232 Karte, ich kannte Mailboxbesitzer, die davon 3 Stück in ihrem A2000 hatten und daneben einen Berg Modems.
Mit einer kleinen Hardwaremodifikation und einer neuen Firmware für den On-Board 6502 Coprozessor konnte die A2232 dann sogar Hardware-Flusskontrolle und 57600 auf allen Ports simultan - ich meine ich hätte sogar 115200 getestet, aber bin nicht mehr sicher.
So hat man beispielsweise den TiefPass ausgeschaltet, falls es das
Programm nicht selbst gemacht hat.
Der Tiefpass wurde doch - wimre - durch den gleichen Pin geschaltet der
auch die Power-LED Hell/Dunkel geschaltet hat.
Ja, steht sogar als Note in dem Schaltplan oben: "LED off, Filters bypassed".
Ist bei A500 das Pin PA0 des U7, ein 8520 (CIA). Der TO hat diese zur Fehleranalyse über Kreuz getauscht.
Wobei wichtiger als die HW ist in der Schilderung oben die SW wie man an ROM/Spiel vorbei Register setzt indem man die EXceptions des MC68000 nutzt.
Ich hatte da so ein Progrämmchen für den Bootsector (da sind die meisten Bytes ohnehin leer), das sich zusätzlich noch reset-fest machte und bspw. den TP ausschaltete.
Auf die selbe Weise könnte man versuchen, den störenden Interrupt abzuschalten, resp. zu maskieren.
Mit einer kleinen Hardwaremodifikation und einer neuen Firmware für den
On-Board 6502 Coprozessor konnte die A2232 dann sogar
Hardware-Flusskontrolle und 57600 auf allen Ports simultan
Das konnte sie auch schon mit der Original-Ware.
Auf der A2232 werkelten komplette RS232-Chips mit HW-Handshake.
Warum wurden die nicht genutzt und stattdessen das HW-Handshake extra über einen Portbaustein gemacht?
Die "RS232-Chips" sind nur Pegelwandler, die üblichen 1488/1489 (75188/75189). Das sind die diversen 14-Pinner am rechten Platinenrand.
Du meintest vielmehr die auf der Karte verbauten UARTs, das sind die sieben 24-Pinner links von den RS232-Chips. Drunter sitzt der Baudratenquarz mit 1.8432 MHz, mit dem der Baudratengenerator dieser UARTs Baudraten bis zu 115200 Baud (1.8432 MHz / 16) erzeugen konnte.
Diese UARTs sind Abkömmlinge der Rockwell-UART 6551.
Wenigstens das Original hatte wimre einen deftigen Hardwarefehler, der das Hardwarehandshake sinnlos machte - drehte die Gegenseite das Senden ab, gehorchte die UART /sofort/, und unterbrach das gerade gesendete Zeichen, statt dessen Übertragung noch abzuschließen.
Und das war wohl nicht das einzige Problem, das diese UART hatte.
Bessere UARTs hätte es damals aber schon gegeben - die 16550 gab es bereits 1987. Und die hatte 16 Bytes Sende- und Empfangspuffer, so daß eine Karte mit mehreren UARTs keinen eigenen Prozessor benötigt hätte, um den "Traffic" abzuwickeln.
Auf der A2232 werkelten komplette RS232-Chips mit HW-Handshake.
Du meintest vielmehr die auf der Karte verbauten UARTs, das sind die
...
Diese UARTs sind Abkömmlinge der Rockwell-UART 6551.
...
Wenigstens das Original hatte wimre einen deftigen Hardwarefehler, der
Ja genau, die Hardware-Handshakesignale hatten sich nicht so verhalten wie die gängigen Modems (Zyxel, USR, ...) das erwarteten. Ich hatte mich damals sehr intensiv damit befasst.
Das sind Coverversion von Amiga-Spielen mit Akustikinstumenten und auch ein paar exotische Sachen wie Klanghölzer etc. Der absolute HAMMER! Der Künstler hat auch noch tonnenweise andere Videospielmusiken interpretiert
(neudeutsch: "gecovert" AUTSCH)
