Welche Video-Modes können ST und STE?

[czietz]

..und das ist *nicht* CAB, die noch die Isolierkörper im Lager haben und auf Anfrage für 'n Arm und 'n Bein die Pins da reindrücken würden?

Nun, ich habe in der Tat bei CAB gekauft, weil sie (vergleichsweise) preiswert waren. Ich hatte auch keine Probleme mit deren Produkt, aber 2 Stück ist halt auch keine statistisch aussagekräftige Menge. Die nächstteurere Option nach CAB wären PLCC-Plugs von Winslow Adaptics gewesen (http://www.winslowadaptics.com/gfx/productgroups/PLCC%20Plugs%20Surface%20Mount/PLCC%20plugs%20I2.pdf), in Deutschland z.T. bei RS Components erhältlich.

[Paradroid]

Ich habe übers Wochenende ein 3D-Modell eines neuen Isolierkörpers  gemacht, da ich selbst CAB zu teuer finde - trotz einem Rabatt von über 40% bei Abnahme großer Stückzahl. Wie teuer dieses neue Werkzeug wird, erfahre ich noch diese Woche - dann entscheidet sich, ob es CAB oder was Eigenes wird.

Das Produkt "Indivision AGA MK2cr" kostet für den Amiga schon knappe 150,- EUR, und der kleine Bruder "Indivision ECS", welcher keinen DVI-I Ausgang hat, kostet knapp 100,- EUR. Wenn ich für den 40-poligen Shifter eine Zielmarke von 120,- EUR ausrufe, wird das schon sportlich, weil ich überhaupt keine Vorstellung habe, welche Stückzahlen zu erwarten sind. Ich fürchte, dass eine Version für den großen Shifter nicht viel teurer sein darf, sonst wird sie einfach nicht angenommen.

Ich habe auch ein nettes Angebot hier aus dem Forum bekommen, mich mal in ST-Dinge wie Demos und Sync-Tricks einzuführen - dafür schonmal herzlichen Dank. Ich hoffe, dass ich das annehmen kann - wenn ich es dieses Jahr zur Nordlicht in Bremen schaffe.

Was mir aber weiterhin fehlt, wäre ein Programmierer, der ein Config-Tool für diesen Framebuffer schreiben kann. Dieser Mensch müsste eine GUI programmieren können, aber auch keine Angst vor hardwarenaher Programmierung haben, da z.B. ein SPI-Flash über bit-banging zu beschreiben ist. Wir werden eine Rescue-Diskette erstellen müssen, falls beim Flashen etwas schief läuft, und der DVI-Ausgang dann "tot" sein sollte - die müsste ohne user-Interaktion einfach das Flash wieder herstellen (ein paar hundert k, also der kleinere Teil einer DD-Disk).

Jens

[1ST1]

Ich finde es übrigens schön, dass du in den ST-Markt einsteigst. Vielleicht kommt von dir in Zukunft ja noch mehr, du könntest z.B. Speichererweiterungen (von klein auf 4 MB, Alternate-RAM für ST/STE/MegaSTE, Falcon-RAM, evtl. auch mal mit Gaga/Tuxie wegen Übernahme Produktion Lightning, Thunder, Storm diskutieren, falls die einverstanden sind. Auch bei der MonSTer-Erweiterung für ST/STE/Mega-STE bestünde Bedarf. Turbokarten sind sicher auch interessant, und wenn es nur eine (überarbeitete) Neuauflage von PAK/FRAK/... wäre. Wiederauflage von Grafikerweiterungen und Karten wäre vielleicht auch interessant. Auch das Thema ct60e und SuperVidel wäre was heißes, sofern Willy da mit sich reden lässt. Außerdem SCSI/ACSI-zu-SD/SCS/CF, IDE-Controller, Netzwerkkarten, usw. Die Übernahme von der CosmosEx-Produktion scheinst du gerade verpasst zu haben, schade, ein sehr sexy Produkt, was jeder ST-User gebrauchen könnte, wenn man gerade mal wieder eine Charge in der Produktion erwischt - und gib das mal einem Amiga-Freak in die Hand und schau was der für sich draus macht... ParCP-USB ist auch so eine Kleinigkeit, die momentan nur in 10er-Batches handgelötet wird, und die Amiga-Leute könnten von dem Teil auch begeistert sein, wenn es die Software dazu für die Plattform gäbe. Der Atari-Markt ist sicher längst nicht so groß wie der Amiga-Markt, aber es gibt mehr als hier im Forum aktiv sind, es gibt ja auch noch weitere englische/französische/spanische Foren und viele nutzbare Synnergien. Außerdem ist der Atari-Markt, was verfügbare, oder gerade eben nicht verfügbare Hardware angeht, sehr fragmentiert, alles kommt aus irgendwelchen Ecken, jeder macht was anderes, aber man muss ständig suchen was wo es gibt und verpasst dann die nächste Auflage usw. weil man mal einen Tag zu spät in irgendein Forum reingeschaut hat. Das hat alles seine Vor- und Nachteile und sicher wird nicht jeder Entwickler kooperieren wollen, wofür man natürlich auch Verständnis zeigen muss, aber für reine aufrüstwillige Anwender wäre es fein, wenn man alles aus einer überschaubar kleineren Anzahl Quellen zuverlässig bekommen könnte.

[Paradroid]

1ST1, jetzt mal langsam mit den jungen Pferden. In erster Linie ist der 40-Pin Shifter interessant, danach schaue ich mir an, was unterm Strich übrig geblieben ist.

Für eine Speichererweiterung brauche ich sicher keine Business-Übernahme. 68k Prozessoren kenne ich wirklich *sehr* gut, und kann ihnen "speicher satt" verpassen, ohne dass ich ein fremdes Design übernehmen muss. Wie es aussieht, muss ich aber auch ohne dass ich Speichererweiterungen baue einiges über den ST und seine Erweiterungen lernen, denn da scheint es zwei 4MB-Erweiterungen zu geben, die sich auf die MMU quetschen (und dabei den Sockel gewaltig ausleiern), und noch Signale vom Shifter holen.

Wenn ich einen DVI-Adapter für den Shifter mache, läuft das auf den "Turmbau zu Babel" hinaus, weil dann ein Adapter für die Speichererweiterung drin ist, und noch einer für DVI. Die Abschirmung geht dann ganz sicher nicht mehr drauf, und ob das noch ins Gehäuse passt, darf zumindest mal auf die "sollte-man-checken"-Liste gesetzt werden.

Bevor ich aber irgendwem irgendwas verspreche, suche ich weiter nach jemandem, der GUI-Tools auf dem ST schreiben kann. Nicht umsonst - ich verdiene Geld (zumindest beabsichtige ich das), also werden Programmierer selbstverständlich auch bezahlt. Entweder projektbezogen (freelancer/Selbständige), oder als Aushilfe (450-EUR-Basis) oder regulär angestellt, wenn kein anderer sozialversicherungspflichter Job ausgeführt wird. Bisher habe ich in dieser Hinsicht null Rückmeldung, aber ohne Software ist Silizium bekanntermaßen nur Sand. Und den kauft keiner.

Jens

[czietz]

Wie es aussieht, muss ich aber auch ohne dass ich Speichererweiterungen baue einiges über den ST und seine Erweiterungen lernen, denn da scheint es zwei 4MB-Erweiterungen zu geben, die sich auf die MMU quetschen (und dabei den Sockel gewaltig ausleiern), und noch Signale vom Shifter holen.

Es gibt im ST einfach keine einzige Stelle (kein einziges IC), an dem alle benötigten Signale für solch eine Erweiterung gebündelt anlägen. Die MMU generiert die Row- und Column-Adressen für das DRAM und verwaltet den Zugriff darauf. Immer abwechselnd bekommt einmal der Shifter ein neues Datenwort und einmal der CPU-seitige Bus (d.h. 68000, aber auch DMA oder Blitter) Zugriff. (Während des Strahlrücklaufs werden die Shifter-Zyklen stattdessen für DRAM-Refresh verwendet, wobei auch hier die MMU die Adressen generiert.)

Die Datenbits liegen nicht an der MMU an, aber immer am Shifter an, an der CPU nur in jedem zweiten Zugriff. Daher ist so eine 4-MB-RAM-Erweiterung mit Shifter und MMU verbunden.

Dieser von der MMU verwaltete Speicher wird ST-RAM genannt und ist universell einsetzbar, da für CPU, DMA, Shifter erreichbar. Außerdem kann er von allen TOS-Versionen ab 1.00 verwaltet werden und entsprechend von allen Anwendungen genutzt werden.

Nun kann man Speicher auch direkt am 68000 anschließen und in den sonst unbelegten Adressbereich zwischen 4 MB und 14 MB (10 MB beim MegaSTE) einblenden, wenn man entweder SRAM verwendet (Lösung MonSTer) oder sich um das DRAM-Refresh selbst kümmert (Lösung Magnum ST). Dieses sogenannte Alternate-RAM (Alt-RAM) kann aber nur mit TOS 2.06 verwaltet werden. Zudem kommen nicht alle Anwendungen damit klar, sei es, weil sie ihren Speicher auch für DMA-Transfers oder als Bildschirmspeicher nutzen wollen, sei es, weil sie einfach nicht erwarten, Zeiger auf Adressen größer 4 MB zu verwalten.

Wie Du siehst, gibt es zwei grundverschiedene Lösungen für Speichererweiterungen im ST, die beide ihre Vor- und Nachteile haben.

[1ST1]

Und den RAM dockt man besser am Shifter an, so wie es z.B. Lynxman macht. Platine auf die MMU draufstecken ist keine gute Idee, da leiert der lapprige Sockel noch mehr aus. Man kann die Adress-Signale, RAS und CAS an den Widerständen zwischen MMU und RAM abgreifen, entweder anlöten, oder du erfindest irgendwas mit Klemmen. Ich habe bei meiner eigenen RAM-Erweiterung damals eine Adapterplatine gemacht, die man an den Widerständen festlötet und auf der Platibe war dann ein DIL-Sockel für Flachbandkabel. Je nach originaler Speicherausstattung des ST (1 oder 2 Bank) muss man zusätzliche Leitungen von der MMU holen, die sind dann nicht auf Widerstände geführt.

Sandwitchbauten lassen sich vermeiden, in dem man möglichst viele Funktionen auf ein Board packt, RAM+HDMI-Adapter zum Beispiel... Oder man geht den radikalen Weg, damit hast du ja schon Erfahrung, und baust ein 1040-ST-Reloaded-Board, wo der ganze Krempel schon drauf ist. (also nicht sowas IMHO halbgares wie die erste C64-Reloaded-Version wo wir uns in die Haare bekommen haben) - 4 MB RAM, TOS 2.06 umschaltbar, HD-Modul, HDMI-Adapter, IDE, AltRam, 16MHz Turbo oder vielleicht gleich ne 68080, ....

[Paradroid]

Klingt demnach so, als ob ein DVI-Framebuffer auf dem Shifter auch die Datenleitungen an einem dokumentierten Anschluss herausführen sollte, damit eben kein Turmbau zu Babel stattfinden muss.

Oder gleich eine 4M ST-RAM Erweiterung mit auf die Karte, was aber wieder einen MMU-Adapter erfordern würde. Hmm.. ob das die Akzeptanz der (geplanten) Hardware verbessern würde? Es ist absolut nicht mein Ding, Hardware zu verkaufen, für die Lötarbeiten beim Einbau erforderlich sind. Schon das Herausnehmen eines Chips ist in meinen Augen grenzwertig für einige Benutzer, aber bei DILs gehe ich das Risiko ein.

Bei einem PLCC ist das schon was Anderes, und wenn dann noch das on-Board D-Ram lahmgelegt werden muss, hört es für die Meisten ganz auf.

Hat noch niemand eine Erweiterung gebaut, bei der die MMU aus dem Sockel genommen wird, diese dann auf der Erweiterung in einen Sockel gesetzt wird und dann ein Adapter in den MMU-Sockel gesteckt wird? Dann kann der Speicher auf dem Mainboard ganz einfach lahmgelegt werden (meine Erweiterung hat ja dann Kontrolle über RAS/CAS). Der Benutzer müsste halt einen PLCC-Chip aus dem Sockel ziehen, aber es wäre immerhin löt-frei.

1ST1: Auch wenn mein Herz mehr in Richtung Commodore schlägt, ist der Atari ST ein klassischer Computer, der ebenfalls seinen Platz in der Computergeschichte hat. Das bedeutet: Ich habe mit der Hardware, die ich in Verkehr bringe, eine gewisse Verantwortung, dass die Geräte nicht unnötig verbastelt werden. Sprich: Löten und Löcher ins Gehäuse sägen ist beides zu vermeiden.

Jens

[1ST1]

@Paradroid - deswegen ja am Ende der Vorschlag mit dem ST-Reloaded-Board. Die große Schwierigkeit beim 1040 ST ist, dass es mindestens 3 grundverschiedene Boardlayouts gibt, wo CPU, RAM usw. völlig wo anders sitzt, das ist z.B. beim A500 viel einheitlicher. Außerdem - obwohl das kennt man auch von Commodore - mal sind Chips gesockelt, mal nicht, MMU/GLUE sind bei späten Boardversionen teils sogar SMDmäßig aufgelötet, nothing for beginners... Man kann ja auch dazu einen Umbauservice anbieten, Rechner einschicken, und mit neuer Platine kommt er zurück. (Bedingung: Rechner muss grundsätzlich funktionsfähig sein, sonst fängt der Umbau erstmal mit Debugging an... Oder inklusive Reparatur per Aufpreis)

[goetz @ 3rz]

Dieser von der MMU verwaltete Speicher wird ST-RAM genannt und ist universell einsetzbar, da für CPU, DMA, Shifter erreichbar. Außerdem kann er von allen TOS-Versionen ab 1.00 verwaltet werden und entsprechend von allen Anwendungen genutzt werden.

(und der kann max. 4 MB groß sein)

Nun kann man Speicher auch direkt am 68000 anschließen und in den sonst unbelegten Adressbereich zwischen 4 MB und 14 MB (10 MB beim MegaSTE) einblenden, wenn man entweder SRAM verwendet (Lösung MonSTer) oder sich um das DRAM-Refresh selbst kümmert (Lösung Magnum ST). Dieses sogenannte Alternate-RAM (Alt-RAM) kann aber nur mit TOS 2.06 verwaltet werden. Zudem kommen nicht alle Anwendungen damit klar, sei es, weil sie ihren Speicher auch für DMA-Transfers oder als Bildschirmspeicher nutzen wollen, sei es, weil sie einfach nicht erwarten, Zeiger auf Adressen größer 4 MB zu verwalten.

Wie Du siehst, gibt es zwei grundverschiedene Lösungen für Speichererweiterungen im ST, die beide ihre Vor- und Nachteile haben.

Ja, wobei ich noch ein paar Punkte ergänzen möchte:

• Die Einschränkung "viel RAM nur mit TOS 2.06" ist so hart nicht ganz richtig. Auch Maschinen mit alten ROMs (1.x) können bspw. MagiC oder MiNT booten, und dann auch mehr als 4 MB verwalten, da diese Betriebssystemaufsätze/ersatze die nötigen Funktionen TOS206-kompatibel (und mehr) mitbringen.
• Ich kenne keine Anwendungen, die Probleme mit mehr als 4 MB haben, wenn sie ab 1990 sind. Die mussten alle auf dem Atari TT laufen, und dafür sowieso damit klarkommen.
• Programme, die ernsthaft mehr als 4 MB RAM benötigen, oder Multitasking-OSse (wo mehr RAM immer gut ist), haben aber auch kein Problem mit TOS 2.06 untendrunter. Ich sehe da keinen Ausschluß bzw. kein Problem. Sicher gibt es Software, die Probleme bspw. mit großen Adreßräumen haben (Tempus der Editor, in der Version bis irgendwann 1988), nur ist das echt steinaltes Zeuch. Und wer das dringend noch haben will/muß, der rüstet seinen ST nicht mit 14 MB auf (weil wozu denn), _oder_ lebt einfach damit, dass die Software diesen Speicherbereich (Alt-RAM) dann halt schlicht nicht mitnutzt. Ist ja kein großer Verlust, als diese Software rauskam gab es ja auch nicht mehr Speicher.

[czietz]

Hat noch niemand eine Erweiterung gebaut, bei der die MMU aus dem Sockel genommen wird, diese dann auf der Erweiterung in einen Sockel gesetzt wird und dann ein Adapter in den MMU-Sockel gesteckt wird?

Es gibt so ausgefallene Lösungen, wie diese hier: https://forum.atari-home.de/index.php?topic=13517.msg216138#msg216138 mit Zwischensockel für die MMU, um dieser bis zu 14 MB unterzuschieben.

Die STC schrieb auch über solche Lösungen: http://www.stcarchiv.de/stc1990/12_ramerw.php. (Suche nach "Lösung MMU-Huckepack".)

Allerdings ist mir keine aktuelle RAM-Erweiterung bekannt, die so arbeiten würde.

[Paradroid]

Vielen Dank an Alle - in Sachen Verständnis des ST habe ich einen großen Schritt vorwärts gemacht und sehe die Parallelen zum Amiga deutlich klarer. Wo der Thread-Titel hier um Video-Modes geht, würde ich gern wissen, ob die CPU wirklich immer jeden zweiten Zyklus des ST-Ram bekommt, oder ob es Video-Modes gibt, die der CPU Zyklen klauen können?

Beim Amiga ist das abhängig von der Auflösung und Farbtiefe und kann so weit gehen, dass über die gesamte Bildschirmzeile kein Chipram-Zugriff für die CPU oder den Blitter möglich sind, weil die gesamte Speicherbandbreite für den Video-DMA benötigt wird. Gibt es solche Modes auch auf dem ST(E)?

Die Suche nach einem fähigen ST-Programmierer läuft weiter; ich habe Uwe Seimet angeschrieben, der aber bis auf eigene Software scheinbar nichts weiter auf dem ST programmieren möchte. Er hat mich hierher verwiesen, hier würde ich "bestimmt fündig" - will mal sehen

Jens

[czietz]

Wo der Thread-Titel hier um Video-Modes geht, würde ich gern wissen, ob die CPU wirklich immer jeden zweiten Zyklus des ST-Ram bekommt, oder ob es Video-Modes gibt, die der CPU Zyklen klauen können?

Nein, so etwas ist im ST technisch nicht möglich.

[1ST1]

Wo der Thread-Titel hier um Video-Modes geht, würde ich gern wissen, ob die CPU wirklich immer jeden zweiten Zyklus des ST-Ram bekommt, oder ob es Video-Modes gibt, die der CPU Zyklen klauen können?

Beim Amiga ist das abhängig von der Auflösung und Farbtiefe und kann so weit gehen, dass über die gesamte Bildschirmzeile kein Chipram-Zugriff für die CPU oder den Blitter möglich sind, weil die gesamte Speicherbandbreite für den Video-DMA benötigt wird. Gibt es solche Modes auch auf dem ST(E)?

Wie Christian schon schrieb, die Aufteilung der Speicherbandbreite zwischen CPU und Shifter ist starr. Das heißt, der Shifter bekommt immer, was er will. Die CPU muss sich die Rest-Bandbreite aber mit anderen DMA-Geräten teilen: ACSI/Floppy und Blitter. Erst beim Falcon ist das in höheren Videomodis anders, da kann der Videl durchaus auchmal die CPU etwas ausbremsen, insbesondere wenn man den Videl mit höherem Basistakt versorgt.

Es ist ja jetzt schön Sommer, man kann draußen im Garten sitzen, auch Abends, ich hätte da eine spannende Lektüre für dich, die viele solche Fragen rund um ST, STE und TT klärt (nur leider nicht für den Falcon): https://www.dev-docs.org/docs/htm/search.php?find=_o -> Und dann diesen Schinken hier runterladen: "ATARI Profibuch ST-STE-TT (Rev 11, Public Domain) [1992]" (auf https://www.dev-docs.org findet man auch alle möglichen Schaltpläne usw.)

[Paradroid]

Nur kurz ein Lebenszeichen von mir: Ich fahre zur Nordlicht und würde mich freuen, dort neben C64- und Amigagesprächen auch etwas mehr über den ST zu lernen. Vielleicht ist ja auch jemand mit ST dort und kann mir einen Einsteigerkurs geben? Speziell interessiert mich, ob/wie Atari ST und Ethernet funktionieren. Bitte nicht hier in diesem Thread diskutieren, denn hier geht es ja noch um Video-Modes und "alles rund um Bildschirm".

Außerdem suche ich immer noch nach einem Programmierer, der GUI-Tools auf dem ST programmieren kann. Ohne den wäre eine Hardware ziemlich eingeschränkt.

Jens