Hilfe zu Maxon Board 20 und AG-VGA

[dbsys]

Uploade die Software auf ...

https://docs.dev-docs.org

... oder hänge die hier mal an.

Guter Vorschlag!

Bitte nicht „draufsetzen“, sondern zur Verfügung stellen. Dankeschön!

[goetz @ 3rz]

Für alle die es interessiert Treiber sind gefunden worden und die KArte läuft :-)
Danke allen für die Hilfe

Ja, Ergebnisse, nicht nur „danke für den Fisch und tschüß“ rufen Bitte den Treiber veröffentlichen (dev-docs, archive.org, whatever). Und am besten noch Benchmarks (Coremark & Gembench 4 fürs hübsche Bild).

[Highspeed]

Sorry bin noch nicht dau gekommen alles ausgiebig zu testen, werde natürlich ergebnisse und Treiber später teilen.
Da der Treiber extrem schwer zu finden ist muss er auf jeden fall zugänglich sein.

[Lukas Frank]

Bin gespannt und in freudiger Erwartung ...

[Highspeed]

So nun die ersten Ergebnisse.
Coremark läuft bei 6.10, Damit läuft Sie ganz gut.
die Cloudy/Storm Kombi läuft leider nicht wenn Cloudy TOS 2.06 drinnen hat wird davon gebootet aber der Altram wird nicht erkannt. Wenn Emutos drinnen ist gibt es ein Panic Error.
Wenn in dem Board 20 TOS 2.06 oder Emutos direkt drinnen sind läuf das Board ohne Probleme nur leider halt nicht mit der Cloudy/Strom Kombi.

Treiber für Autostart in der Anlage unten wie immer Dateinamen ändern in .PRG

[Lukas Frank]

Schade das es kein CPX Modul dazu gibt. Unter AtariX läuft es mit der Meldung "Erfolgreich installiert" ...

[czietz]

die Cloudy/Storm Kombi läuft leider nicht wenn Cloudy TOS 2.06 drinnen hat wird davon gebootet aber der Altram wird nicht erkannt. Wenn Emutos drinnen ist gibt es ein Panic Error.

Der EmuTOS-Screenshot ist zum Glück eindeutig: Der Bus-Error passiert beim Zugriff aufs Alt-RAM. Der Adressdekoder auf dem BOARD20 gibt also Zugriffe auf den Adressbereich des Alt-RAM nicht an das System weiter. Ist also eine "Designschwäche" des BOARD20 - wobei es vermutlich noch nicht einmal die Magnum ST gab, als das BOARD20 designt wurde.

Noch kurz zur Frage: Wie funktioniert die Steuerung des Caches? Eine erste Analyse mit Ghidra zeigt: Das Treiberprogramm macht Zugriffe auf bestimmte Adressen (0, 2, 4), wobei die Steuersignale FC2=0, FC1=FC0=1 sind. Das ist etwas, was im normalen Betrieb nicht vorkommt. Diese Zugriffe dienen also mutmaßlich der Steuerung der Boards, z.B. des Caches.

[KarlMüller]

Schade das es kein CPX Modul dazu gibt.

Da fehtl noch die RSC-Datei und eine Konfiguration. Wobei letzteres vieleicht erst erstellt wird.

[czietz]

Schade das es kein CPX Modul dazu gibt.

Das Programm ist so geschrieben, dass es sich auch in BOARD20.ACC umbenennen lässt und dann als Accessory läuft. Bloß ohne die schon angemerkte .RSC-Datei wird das nicht funktionieren. @Highspeed : Bitte poste doch das komplette Paket aus BOARD20.PRG, BOARD20.RSC und BOARD20.INF (der Konfigurationsdatei).

[Gaga]

@czietz : dann würde das Maxonboard auch mit einer Storm ST (ohne Cloudy) nicht klarkommen, oder?

[czietz]

dann würde das Maxonboard auch mit einer Storm ST (ohne Cloudy) nicht klarkommen, oder?

Korrekt. Und auch nicht mit einer Magnum ST oder MonSTer. Der Zugriff auf den Alt-RAM-Bereich ab 0x400000 ist erkennbar durch das Board20 blockiert.

[Highspeed]

Hier sind nun alle Dateien die ich zu dem Board 20 gefunden habe.
Die Dateien auser die .PRG sind normal unter C abgelegt worden.
Für jede Hilfe wie was funktioniert usw würde ich mich freuen.

[Lukas Frank]

Von der Machart her im Prinzip so wie die Software von OverScan wie der SM124 Emulator oder Overscan TT oder ST die eine Liste verwaltet mit Programmen ...

[czietz]

Von der Machart her im Prinzip so wie die Software von OverScan wie der SM124 Emulator oder Overscan TT oder ST die eine Liste verwaltet mit Programmen ...

Wobei hier (so meine Vermutung) die Programme aus der Liste diejenigen sind, die mit abgeschaltetem Cache ausgeführt werden. Der Rest der GUI des ACC scheint ja selbsterklärend zu sein.