Atari 260ST Erstkontakt - Hilfe gesucht!

  • Hier ein Link zur Geschichte der Kommunikationen von Atari in den Markt ...mit zeitangaben (falls neu für uns...)

    Beim Lesen merkt man, dass die Marketing Abteilung doch einiges Angekündigt hat und dann doch nicht "geshipped" hat.


    https://mcurrent.name/atarihistory/tramel_technology.html

    ... immer locker bleiben ...

    Einmal editiert, zuletzt von DerSatelitt ()

  • (und 520ST+): Dezember 1985

    Das kann nicht sein, mein Onkel hatte seinen 520ST+ mit BOOT-ROMs schon im Spätsommer, und zwar ganz normal bei einem der ersten ATARI-Händler in Rhein-Main (Landold in Maintal) gekauft. Ich hatte gerade mal ein paar Monate einen C64, und da hüpfte der schon weiter auf so ne fette Maschine. Meinen ersten 520er konnte ich mir dann nach Weihnachten leisten, Weihnachtsgeld, Zeitungen austragen und solche Sachen. Der hatte dann aber gleich richtige ROMs, war ein runtergesetzter Vorführrechner bei Escom.

    Hmm, möglicherweise eine frühe Lieferung? Laut diversen Fachzeitschriften waren 520ST+, 260ST und die große Floppy SF314 "pünktlich zu Weihnachten 1985" zu haben ;) (Im Endeffekt kann ich mich ja nur an Daten aus div. Fachzeitschriften etc. halten - da war ich mit 3 Jahren einfach noch zu jung :mrgreen::mrgreen: )

  • ie der 520ST+, mit 32 Stück 4164 (die sind bis auf fehlende Adressleitungen pinkompatibel zum 41256) in Huckepackbauweise. Müsste man direkt mal probieren, ob das wirklich geht...

    Auf der Seite 149 von der Ausgabe Happy Computer Januar 1986 ist die Anleitung um den Speicher im Huckepack zu vergrößern.

    http://ftp.pigwa.net/stuff/col…page=148&zoom=190,495,595


    Hier gibts auch diese Chips zu kaufen ... ein bisschen Juckts....

    https://www.jameco.com/z/41256…ge-Nibble-Mode_41398.html


    Desweiteren:

    Da ist auch ein kurzer Absatz, wie man die Größe des Speichers in basic prüfen kann. (Ich krieg das aber nicht hin)

    ein print peek(1070) gibt bei mir die Zahl 4. Laut dem Artikel müßte nach der Erweiterung hier 1000000 oder so stehen. Also würde ich erwarten dass da zuvor 500000 steht. Aber ein peek auf eine 16bit breite Adressezelle kann ja nur bis 65536 tragen. Also müßte man doch noch weitere benachbarte Speicherzellen peeken und dann irgendwie zusammen addieren... oder ?

    ... immer locker bleiben ...

    Einmal editiert, zuletzt von DerSatelitt ()

  • Der große Witz an der Kiste ist, dass sich das GEM scheinbar im ROM befindet. Das ist nämlich schon geladen, wenn nach der TOS-Diskette gefragt wird.

    Du hast es nicht verstanden:


    a) BOOT-ROM: KEIN GEM/TOS/AES/VDI/XBIOS,BIOS/GEMDOS im ROM, sondern nur ein Hintergrundbiild mit der statischen Anzeige, man möge doch eine Diskette mit RAM-TOS einlegen, und eben dem entsprechenden Bootloader. ich glaube Maus rumschieben und Tastenklick konnte das BOOT-ROM großzügigerweise auch noch, aber das wars. Die Atompilze könnten auch aus dem ROM sein.


    b) TOS-ROM: GEM/TOS/AES/XBIOS,BIOS/GEMDOS im ROM - alles da um direkt loszulegen. Nur eben die erste Version, 1.00 von 1985 war noch recht fehlerhaft, gelegentlich Datenverlust im Festplattenbetrieb. Außerdem nur FAT12 (max 32MB prop Partition), aber wegen der Fehler sollte man nicht mehr als 10 MB pro Partition einrichten!


    a) gab es nur, weil b) noch nicht zur Markteinführung fertig war.

    1ST1

    Einmal editiert, zuletzt von 1ST1 ()

  • Da bewegt sich nichts. Das einzige was aktiv ist ist die Schaltfläche OK. Hier vermute ich dass es ein Bild ist (da in Farbe es so flashy leuchtet und womöglich ist in einem besonderen Grafikmodus sich befindet?).

    Ah, so sieht das in Farbe aus. Hab ich damals beim Onkel immer nur in Monochrome gesehen.


    Das ist auf jeden Fall kein besonderer Grafikmodus, sondern da werden einfach Farbpaletten durch die Farbregister durchgerollt, das ist im Shifter ganz primitiv zu machen. Den Effekt beherrscht z.B. auch das Malprogramm Neochrome, da gibt es dieses berühmte Wasserfall-Bild, was genau diesen Effekt nutzt.

    1ST1

  • Was sind denn nun aber eigentlich DIE Unterschiede zwischen einem 520er und einem 260er

    Wie ich schon schrieb, bis auf die Typenbezeichnung und dass den 520er auch mit HF-Modulator im Prinzip bei den ausgelieferten Rechnern technisch quasi kein Unterschied. Wenn du dir die 260ST Platine ansiehst, da ist auch ein Platz wo man den Modulator bestücken könnte. An der Stelle findet man aber beim 260er ebenso wie bei den 520ern ohne Modulator nur eine kleine fliegend aufgebaute Schaltung aus 2 oder 3 Widerständen und einem Transistor, die H- und V-Sync zu Composite-Sync zusammen mischen und dann auf Pin Pin 2 des Monitorsteckers raus haut. Bei den ST und STE mit HF-Modulator liegt auf Pin 2 Composite Video was als "Abfall" im HF-Modulator eh aus allen Signalen zusammen gemischt wird.

    1ST1

  • Nun, der QL kam zu ähnlicher Zeit mit 128kB Speicher raus.

    Der QL hat aber auch kein 192kB großes Betriebssystem, oder? Und außerdem wurde der QL von Anfang an mit vollwertigen ROMs ausgestattet. Das hat Atari in den 6 Montaten, in denen zuvor an TOS gearbeitet wurde, nicht hinbekommen. Selbst ROM TOS 1.00 was ja dann ein paar Monate später endlich verfügbar war, hatte noch Bugs ohne Ende, die sich vor allem im Festplattenbetrieb zeigen.

    "Vollwertige ROMs am Anfang"? Nein. Der QL wurde anfangs mit einem 16kB-Rom-"Außenbordmotor" (dem sog. Kludge) geliefert, weil anfänglich das Betriebssystem und Basic nicht ins vorgesehene ROM gepaßt haben. Daher musste man den eigentlich für ROM-Add-ons vorgesehenen SLot nutzen, um den Rest reinzupacken. Erst nach ein paar Monaten wurden alle bis dahin ausgelieferten QLs zum ROM-Tausch zurückgerufen.

  • Da man ohne ROM-TOS mit dem 260ST nicht besonders viel anfangen kann (es geht halt furchtbar schnell der Speicher aus), wurde der erstmal nicht (ge-) und deswegen wohl auch nicht (ver-)kauft.

    Das stimmt nicht. Den 260ST hat man zeitgleich mit dem 520ST beworben und angekündigt.

    "Angekündigt" - mag sein. "Auf dem Markt"? Eher nicht so. Ich war damals Student und hab' ziemlich viel bei meinem Stamm-Atari-Händler in Stuttgart rumgelungert (Nebenjob). Einen 260ST habe ich dort nie gesehen. Der Händler hat einfach keine hergetan. 520er, später dann der "+" und alles, was dann noch so kam.

    Einmal editiert, zuletzt von tofro ()

  • Da ist auch ein kurzer Absatz, wie man die Größe des Speichers in basic prüfen kann. (Ich krieg das aber nicht hin)

    ein print peek(1070) gibt bei mir die Zahl 4. Laut dem Artikel müßte nach der Erweiterung hier 1000000 oder so stehen. Also würde ich erwarten dass da zuvor 500000 steht. Aber ein peek auf eine 16bit breite Adressezelle kann ja nur bis 65536 tragen. Also müßte man doch noch weitere benachbarte Speicherzellen peeken und dann irgendwie zusammen addieren... oder ?

    _phystop ist eine Longword-variable im Systemvariablenbereich des STs, die angibt, wo der Speicher oben aufhört. Deswegen muß man auch ein Long peeken, wie du richtig sagst, also


    Code
    100 LET phystop = 65536 * (256 * PEEK(1070) + PEEK(1071)) + (256 * PEEK(1072) + PEEK (1073)) 

    (Leider kann das Atari-BASIC keine longs direkt PEEKen)


    Eine 4 an 1070 erscheint mir aber nicht besonders logisch - das wären schon über 64MByte...

    Einmal editiert, zuletzt von tofro ()

  • tofro Danke Dir für den Anstoss.

    Mit der Formel kam bei mir was riesiges raus. Aber das Prinzip habe ich verstanden - danke.

    Da ich langsam denke... hab ich das folgende gemacht und sehe als Ergebnis 512kB.


    Einzelne peeks ausgegeben und mit Blatt Papier und Stift... :)

    (2048*256 + 8) : 1024 = 512kB

    ... immer locker bleiben ...

  • bzgl was denn nun genau in den ROMs bei TOS-RAM enthalten ist (also nur zwei ROM Bausteine)

    sagt das Buch "ATARI ST Profibuch, Seite 637ff; 1. Auflage 1988) das folgende:


    Zitat


    Als Boot-ROMs werden zwei 64KBit-ROMs der Organisation 8K x 8bit verwendet, welche den Adressraum von $FC 0000 bis $FC 3FFF belegen.
    In diesen 16 KByte ROM ist zunächst ein Programmabschnitt für die Grundsysteminitialisierung enthalten, sowie Daten für die Bildinformation, die vom angeschlossenen Monitor wiedergegeben wird, während das eigentliche TOS von der Systemdiskette in den Arbeitsspeicher geladen wird.


    Teile einiger BIOS- und XBIOS-Routinen, die für lesende Diskettenzugriffe erforderlich sind (wie sollte sonst etwas von Disk geladen werden können) sind ebenfalls in den Boot-ROMs vorhanden. Es handelt sich dabei um die BIOS-Funktionen #4("Rwabs, jedoch nur Lesen) und #7(Getbpb), und die Funktionen #1("Ssbrk" und #8 (Floprd) des XBIOS.

    Wow.

    Heute kam das Buch nämlich :) freudig....

    ... immer locker bleiben ...

  • Wie wäre es denn, wenn einfach mal das Programm nochmal benutzt wird, was ich mal gepostet hatte ??

    Da gab es nicht nur ein ACC drin sondern auch ein PRG. Das kann man wunderbar direkt starten und es klärt alle Rätsel.


    Ich kann die Rechnung auf dem Zettel nicht nachvollziehen. Wo kommt das z.B. plötzlich die "6" bei 6x256 her ??

    Die "8" in der $1070 wäre das, was man lt. Anleitung m.E. mit 256 multipliziert, dann die $1071 addiert und die Summe nochmal mit 65536 mal nimmt. Das Ergebnis sollten dann schon Bytes sein. Und da kommen ganz schön viele raus - weshalb da irgendwas nicht paßt.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Hallo ThoralfAsmussen


    Wo kommt das z.B. plötzlich die "6" bei 6x256 her ??

    --> das ist der Buchstabe "b" wie Berta. An den Spalten oben habe ich a,b,c,d rangeschrieben.


    Ausgefüllt steht da:

    2048*256 + 8 = 524296 bytes

    524296 bytes / 1024 bytes = 512 kB


    Mit 65536 machte ich gar nicht, weil das "obere word" null war (1072 und 1073)



    Das memtest tool hatte ich (und total vermasselt darauf in einer Antwort einzugehen :sad: ) nochmals entpacken lassen. Ich sehe da aber tatsächlich nur ein ACC und kein PRG Datei. Also nur eine Datei kommt da raus.



    Dass Du bei Peek(1071) den Wert 2048 bekommst, zeigt aber, dass da mehr als 8 bit gelesen wurde, also wohl ein Wort (16 bit)

    Das ist was, was mich jetzt ein bisschen beschäftigt. Ich weiß nicht warum das so ist.

    (... braucht erstmal n Kaffee ... )(letzter UrlaubsTag... grummel...

    ... immer locker bleiben ...

  • ThoralfAsmussen


    Kommando zurück !

    Problem war, dass ich doch erst seit vorgestern ein 720kB Laufwerk habe.

    Bis dahin nur das 354 mit 360kB. Mit diesem "kleineren" Laufwerk versuchte ich das ramfrei.tos auszuführen.

    Es hat nur die ACC Datei extrahieren können da die Disk dann voll war.


    Jetzt mit einem DL1314 Laufwerk (720kB) konnte ich es vollständig auspacken lassen.





    Und das Programm ist Super !!




    Interessant ist trotzdem zu wissen, wie man die Speicherinfo anständig aus den "Systemvariablen" ausliest. Ich selbst bin zu newbie mit Atari :)

    ... immer locker bleiben ...

  • Kann ich nur beipflichten. Atari ist ein wirklich schönes System. Und gerade jemand, der von bißchen was strukturierterem herkommt (wie MSX), sollte das eigentlich SEHR gut gefallen.

    Man muß sich halt bißchen reinbasteln und erstmal einen kleinen Satz an ProgrammHelferlein zusammenhaben, dann ist das ein sehr feines und individuelles System.


    Außerdem ist es wirklich fabelhaft dokumentiert - und die Sachen sind auch mittlerweile wirklich alle im Netz zu bekommen. Und es gibt da auch, aufgrund Masse, auch ein schöne Abstufung ziwschen Beginners - Fortgeschrittener und Vollprofi-Literatur.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Kann ich nur beipflichten. Atari ist ein wirklich schönes System. Und gerade jemand, der von bißchen was strukturierterem herkommt (wie MSX), sollte das eigentlich SEHR gut gefallen.

    TOS ist sehr modular aufgebaut, faktisch alle Bestandteile des Betriebssystems, z.B. GEMDOS, AES, VDI, Desktop usw. sind beim Systemstart bzw. teils sogar während der Laufzeit durch leistungsfähigere Varianten austauschbar, das System ist dadurch sehr stark individualisierbar und an neue Hardware und sonstige Gegebenheiten anpassbar. Wenn man z.B. eine Grafikkarte einsetzt, lädt man das passende VDI dafür und ist fertig. Braucht man neue Dateisysteme, lädt man Metados (oder Extendos) mit entsprechenden Dateisystemtreiber (das müssen nicht nur ISO/High-Sierra für CD-ROMs sein!) und funzt, das können auch Netzlaufwerke etc sein. Vektorzeichensätz bindet man mit GDOS ins System ein, man braucht nur noch Anwendungen, die GDOS unterstützen (Atari Works, Microsoft Write (!) und was es da sonst noch so gab).


    GEM ist grundsätzlich für Multitasking vorbereitet, nur der Unterbau ist es - bis auf die ACCs - nicht, aber mit Erweiterungen wir Magic!, Geneva oder MultiTOS/MiNT geht das, und alle sauber programmierten GEM-Programme (also zumeist neuere) laufen darin problemlos.


    Das ist aber eine Frage des RAMs, mit 512kB ode 1 MB kommt man da - im Gegensatz zum Amiga - nicht weit, MultiTOS/MiNT mit seinem Unix/linux-artigen Kernel bringt auf einem ST mit "nur" 4MB eher garnix (wenn man da es schafft einen Desktop zu laden, fühlt man sich wie auf einem 260ST mit RAM-TOS...), die beiden anderen gehen aber ganz gut.


    Auch das "Aufbohren" des bestehenden Desktops erinnert stark an das, was erst viel später mit Windows wieder möglich wurde, eine 68030 vorrausgesetzt, und eine unterstützte TOS-Version vom ROM ins RAM umkopiert und zurückgemappt (romram.prg, gemram.prg etc.) und WinX ermöglichen da einige Einstellmöglichkeiten selbst mit dem originalen Desktop, so dass man den kaum noch wieder erkennt...


    Und was auch schön ist, vor allem für Programmierer, die mit anderen Systemen arbeiten, speziell auf der BIOS, XBIOS, GEMDOS-Ebene ist TOS sehr stark an CP/M bzw. MS-DOS angelehnt, die Funktionsummern und Parameter der Betriebssystemfunktionen, sind weitestgehend identisch, was die Portierung von Software zumindestens auf dieser Ebene stark vereinfacht. Auch das Standard-Dateisystem ist bekannt, weil es FAT12 bzw. FAT16 ist, wie bei MS-DOS.


    Was zu vermissten ist, ist eine standardmäßige Shell/CLI, so wie beim Amiga usw. Rexx wäre auch toll gewesen. Es gibt zwar welche, wie command.prg, ashell oder die Mupfel in Gemini, aber sehr weit kommt man damit nicht. Der einzige Lichtblick, den es da gibt, ist die bash (und bourne-shell, etc.) unter MiNT, wenn man dieses in der vollen Ausbaustufe mit den ganzen Gnu-Paketen installiert, aber dafür braucht man halt wieder auch ne fette Kiste.


    Aber zum Glück, vielleicht auch dank fehlender Shell, ist das Meiste auch per Maus-Schubsten zu erledigen.

    1ST1

  • Nun, der QL kam zu ähnlicher Zeit mit 128kB Speicher raus. Der originale Würfelmac auch.

    Der QL hat kein GUI, von daher ist der fein raus. Und der 128k-Würfelmac ist unbenutzbar, warum Apple den rausgebracht hat verstehe ich genausowenig. Meiner bescheidenen Meinung nach ist der Mac erst mit dem Mac Plus brauchbar geworden.

    Der Mac hatte so viele Routinen im ROM, dass auch ein 128k Mac mit MacWrite, MacPaint und ein paar anderen Programmen – für die damalige Zeit – relativ gut funktionierte. Ein externes Diskettenlaufwerk hat da aber schon vieles erleichtert. Ich habe damals eine 128k Platine lose gekauft (aus einer Service-Werkstatt) und mit grün Monitor und losem Diskettenlaufwerk (alles ohne Gehäuse betrieben. Im Vergleich zu dem, was heute üblich ist, natürlich limitiert, aber damals nicht unbrauchbar.

    Ja, ich fand das auch immer erstaunlich wie klein die Mac-Programme unter System 6/7 auf einen 68k Mac waren - und zwar sowohl im RAM als auch auf dem Datenträger. Unter Windows haben die gut das zwei- bis dreifache gebraucht.

    Das Genie beherrscht das Chaos