Beiträge von Llama

    Ich mach den alten Thread nochmal kurz auf für eine Ergänzung:


    Nachdem meine eigenen Basteleien eine ganze Weile geruht haben, hab ich mein angedachtes Projekt jetzt doch wieder aufgegriffen. Als Nebenprodukt hab ich jetzt tatsächlich mal einen eigenständigen PngToDegas Converter fertig gemacht. ::hacking:: (siehe Anhang)


    Es ist ein kleines kommandozeilen-Tool für Windows mit dem man direkt *.PNGs in die Degas Formate *.PI1, *.PI2, *.PI3 konvertieren kann. Das *.PNG muss allerdings schon "passend" vorbereitet sein, in dem es genau eine der Atari-Auflösungen hat und die Anzahl der verwendeten Farben die auf dem Atari unterstützte Anzahl der jeweiligen Auflösung nicht übersteigen darf. Ich wollte nicht zu viel Logik in das Tool stecken. Das Tool soll sich wirklich auf die reine Konvertierung von PNG zu Degas konzentrieren. Arbeitsschritte wie die Auflösung zu reduzieren und die Anzahl Farben zu reduzieren kann man auf dem PC problemlos mit anderen Tools machen (z.B. Gimp).


    Vielleicht ist das Tool ja auch noch für jemand anderen nützlich - daher veröffentliche ich es mal hier im Anhang... :)

    Leute, ich muss euch echt dringendst auf folgendes Schnäppchen hinweisen. Der Verkäufer gibt sogar noch bis zu 10% Multi-Rabatt! Jetzt heißt es schnell sein! Einen hat er schon verkauft!!! Da kommt bestimmt in den nächsten Stunden ein riesen Ansturm, und die anderen sind mir nix dir nix wech... Also nicht lange fackeln! ::money::


    https://www.ebay.de/itm/313948346508

    Da hätte ich wirklich ein schlechtes Gewissen... :D

    ah nanu - jetzt hat er den Preis angepasst... Vorhin war er noch um den ganz unwesentlichen Faktor 100 höher :S

    Mir ist es ganz wichtig, nicht nur zu sammeln, sondern auch, mich mit den Geräten zu befassen. In den letzten 2 Jahren habe ich 6502-und 8080/8085 Assembler gelernt, außerdem ein bißchen 8086 Assembler. 68k Assembler jetzt erst seit 4 Wochen. Der Atari ST war mein erster Computer. Ich habe zu Weihnachten 1991 einen 1040 STE bekommen. Zu meinem persönlichen Jubiläum "30 Jahre Atari" wollte ich den STe mal wieder etwas "würdigen" und habe mir gedacht, da jetzt auch mal was zu programmieren. Zu Hochsprachen finde ich irgendwie nicht hin. Eigentlich wollte ich C lernen am Atari. Aber irgendwie finde ich Assembler am meisten spannend !

    Klingt gut! Ich hab das ähnlich vor. Ich möchte gar nicht eine 3-stellige Anzahl alter Rechner zusammen sammeln um sie dann nur rumstehen zu haben. Ich hab lieber eine überschaubare "kleine" Menge von vielleicht 10-15 unterschiedlichen alten, lauffähigen Rechnern und entsprechende Programmier-Doku dazu und würde gerne auf den verschiedenen Rechnern was coden (hardware-nah in Assembler). Aber irgendwie ist selbst dafür die Zeit gerade eher zu knapp, so dass ich meistens doch nur den ST anmache - der ist meistens direkt aufgebaut und den kenne ich ja schon ;)


    Aber zumindest stehen ein paar entsprechende Bücher zur Hardware des ST, Amiga, C64, Atari XL und klassischem PC und 68k, x86 und 6502 Assembler schon griffbereit im Regal.

    Hey, cool, dass du dich mit sowas auf dem ST ganz neu befasst! :mrgreen::thumbup: Gefällt mir! Bin gespannt, wohin es führen wird! ;)


    Ansonsten: man kann die Schleife vereinfachen, indem man das Bild anders einliest - und zwar so, daß zunächstmal aller Zeilen des ersten Buchstabens hintereinander im Speicher liegen, dann nachfolgend alle Zeilen des zweiten Buchstabens usf. (dann klappt natürlich der Blitter nicht mehr, aber man spart ein paar Additionen für Wechsel in der Grafik).

    Wie ich das Bild anders reinladen kann, weiß ich nicht. Natürlich hört sich das plausibel an. Aber bedenke, dann müsste ich das Bild nochmal zwischen kopieren...


    Der "Trick" ist, das nicht erst beim Reinladen im Assembler-Code zu machen, sondern eher einen kleinen Converter zu basteln, der einem die Daten "offline" aus dem PI1 Bild einfach in eine andere Reihenfolge umformatiert und in einem eigenen Format abspeichert. Also das Format hat dann natürlich nichts mehr direkt mit PI1 zu tun, sondern ist was "eigenes". Aber das eigene Format kann dann eben optimal auf das jeweilige Problem zugeschnitten sein.


    Früher hab ich solche Daten-Umformatierungs-Dinge direkt auf dem ST mit nem 20-Zeiler in Omikron Basic gemacht. Einfach die *.PI1-Datei in einen mem-block 1:1 reinladen, dann per peeks/pokes in einen zweiten mem-block umformatieren und dann den zweiten als eine *.DAT Datei auf Disk/Platte schreiben. Leider hab ich Omikron inzwischen komplett verlernt. :nixwiss:


    Im Assembler-Code liest man dann nur das *.DAT file ein und weiß ja, in welcher Reihenfolge die Daten da drin stehen. Für so einen Font - oder generell für "Tilesets" ist es am einfachsten, wenn die kompletten Daten des einzelnen Buchstaben direkt nacheinander im Speicher liegen. Und dann einfach ein Buchstabe nach dem anderen im Speicher liegt. Dann wird der Assembler-Code etwas einfacher & performanter. Man braucht nur die Adresse des Anfangs des ersten Zeichens und berechnet dann den Offset zu dem Start des gesuchten Zeichens per left-shifts des Ascii Codes. Die Longword-Tabelle kann man sich so komplett sparen.

    Und auch das abziehen der $20 vom Ascii-Wert ist nicht nötig, wenn man als Startadresse der gesamten Daten-Tabelle nicht die nimmt wo die sichtbaren Zeichen im Speicher anfangen, sondern einfach einmalig $20 Zeichen-Größen (also $20*16*32 Bytes) im Speicher von der Startadresse abzieht und dann immer diese "korrigierte" Startadresse nimmt.


    Achja - in dem Bilder-Lade-Thread hatte ich ja schon geschrieben, dass mein Ziel beim PNG-zu-Atari Konvertieren nicht nur ein *.PI1 File als Ergebnis-Format ist, sondern "eigene Formate". Was ich damit meinte war genau sowas wie hier beschrieben: eine beliebig große PNG-Datei mit einem "Tileset" entsprechend so umformatieren, dass die einzelnen Tiles einfach nacheinander im Speicher liegen...

    (Mit meinem Konverter bin ich aber auch noch nicht fertig. Ich kann inzwischen aber schon mal beliebige PNGs per libpng einlesen. Aber das eigentliche konvertieren in die Bitplanes und Umsortieren im Speicher fehlt noch...)

    Schön, dass der STE jetzt wieder tut!

    Also mich persönlich würden Erfahrungs-Berichte mit "alternativen" Betriebsystemen auf ST / Falcon auch interessieren. Insofern fände ich ein neues Thema für OS-9 auf dem ST super. Beitragen könnte ich aber wahrscheinlich nichts. Meine OS-9 Erfahrungen sind sehr eingeschränkt - und bezogen sich auch auf ein anderes 68k basiertes System. (68060 basierter VME Bus Rechner mit OS-9 und MGR drauf...)

    so so ... vom Sirius also ... :)


    Sehr schön !


    Die Wellenberge sind auch hübsch, v.a. wenn sie Echtzeit gerechnet sind. Das Flimmern im Rasterhintergrund sieht man aber auch nur, wenn man so explizit drauf hingewiesen wird.

    Hehe - jaja - Jugendsünden im Scrolltext :tüdeldü:


    Ja, die Berge sind schon in Echtzeit berechnet. Jedenfalls die Darstellung derselben. Die Höhenkarten ansich sind allerdings vorberechnete Daten - aber das ist ja normal so bei Voxel-Grafik. Ich fand damals Comanche auf dem PC so krass - und dachte: das muss doch auf dem ST auch gehen :mrgreen:


    Ja stimmt - das mit dem Flimmern in den Rastern ist nicht sehr extrem - trotzdem hat's mich heute gewundert, da mir das gar nicht in Erinnerung war. Mit HBL statt Timer B dürfte es aber wirklich noch deutlich krasser gewabert haben...

    Ich muss mal schauen ob ich den Source Code noch finde/habe.

    Hab gerade mal was rausgesucht, wo ich das glaube ich über den Timer B gemacht hatte:

    Intro zur Module Compilation #11 - Magrathea


    Einerseits für die Rasterbars im Hintergrund von der Voxel-Landschaft, und andererseits erinnere ich mich noch dran, dass ich auch bei dem Feuer-Effekt zwischen dem Scroller oben drüber und dem Feuer unten drunter die Palette umgeschaltet hab.


    Wobei: bei dem Voxel zittern die Bars im Hintergrund schon ein bissel... :grübel: Keine Ahnung was ich da vermurkst hab :nixwiss:

    PS: ich kann mir eigentlich gar nicht vorstellen, daß es nicht in dem Atari Videochip ein Register gibt, was die aktuelle Rasterzeile "weiß". Denn diese Variante mit dem indirekten Timer nach Vblank Interrupt ist schon irgendwie eine ganz schön eigenartige Sache; zwei verschachtelte Interrutpts für eine Farbinformation ist auch gut aufwendig.

    Es ist aber tatsächlich so. Der Videocontroller, also der "Shifter", hat dafür kein Register. Der Timer B zählt mit den Rasterzeilen, aber nicht von 0-199, sondern einfach immer weiter. Wenn ich also über den vblanc interrupt dem Timer B jedes Mal resette, friemele ich mir den Timer B um als Rasterzeilencounter... Das ist der Kenntnisstand bis jetzt. Ich habe auch schon einen Code dazu geschrieben. Aber bis jetzt flackert nur eine Rasterzeile in der Mitte...

    Hm - ja, das stimmt so weitgehend. Der Shifter bietet aber immerhin ein paar read-only Register, die einem mitteilen, welche Bildschirmadresse zuletzt vom Shifter gelesen wurde:


    $FF8205: Video Adresszähler Highbyte

    $FF8207: Video Adresszähler Midbyte

    $FF8209: Video Adresszähler Lowbyte


    Für den Bereich auf dem Screen, wo wirklich Daten dargestellten werden, lässt sich darüber schon auf eine Position innerhalb des Bildes schließen. Aber das taugt für Rasterbars natürlich nix, da man diese Register einerseits ständig "pollen" müsste, was hoffnungslos ineffizient ist, und man andererseits darüber nur schwer genau den Anfang einer Rasterzeile ableiten kann, da diese ja außerhalb des Bereichs liegt wo der Shifter wirklich Daten liest...


    Also der Weg über den Timer B, den man dann in jedem VBL resettet ist schon der richtige! Das hab ich damals zumindest auch immer so gemacht! ;)


    Der Vollständigkeit halber: den Horizontal Blank gibt's übrigens auch direkt auf einem 68k Interrupt Eingang und nicht nur am MFP! Am 68k hängt der HBL aber auf Interrupt Level 2 - und der hat ja niedrigste Priorität. Ich erinnere mich noch daran, das meine ersten Raster-Versuche damals mit diesem HBL waren. Aber einerseits wird dieser Interrupt dann wirklich bei jedem einzelnen Horizontalen Blank ausgeführt (und nicht nur beim x-ten, was man über den Timer B konfigurieren kann), und andererseits haben alle anderen Interrupts (VBL, MFP) ja eine höhere Priorität - was die Rasterbars immer zum Zittern gebracht hat. Das war für mich eine Sackgasse. Aber über den Timer B funktionierts!

    Mal planloserweise mit nem china logic Analyzer ein paar signale beim Einschalte gemessen.


    Reset an der am 8501 wird irgendwann High, da scheine ich schon mal kein Problem zu haben. Was mich irritiert ist das sowohl MasterClock am TED als auch SystemClock an der CPU keinen Sauber durchgehendes Taktsignal haben sondern ein Puls oder auch Nulldurchlauf auch mal 4uS statt 2uS dauern.

    Ja, das mit dem Takt ist ein gesundes Zeichen! Der sollte immer mal hin und her schalten.

    Wenn du einen LA zur Verfügung hast, könntest du ja evtl. mal den Einschaltvorgang deines Rechners mit den Bildern aus meinem Beitrag vergleichen. Bei mir war wie geschrieben die CPU defekt. Das heißt aber, dass der TED ok war. Falls es bei dir auf den gleichen Pins "ganz anders" aussieht, wäre das vielleicht ein erster Hinweis auf einen defekten TED.

    Zum PLA kann ich leider auch nichts sagen. Der war bei mir nicht das Problem - und ich hab mir auch nie angeschaut, wie der im System eingebaut ist...

    Ahja - nice! Muss ich mir mal anschauen.

    Ich hatte ehrlich gesagt noch gar nicht danach gesucht ob es sowas schon fertig gibt.


    Aber mein Ziel ist glaub ich doch ein bissl weiter gesteckt. Ich möchte am Ende beliebig große PNGs mit Tilesets zu eigenen Formaten konvertieren. Aber 320*200 PNG zu PI1 wäre dabei halt der erste Schritt als eins der Zielformate - und nützlich als proof of concept um zu sehen dass das ganze "drumherum" funktioniert (PC Format einlesen, Palette konvertieren, pixel zu Bitplane Konvertierung, little vs big endian...).

    Wie geht ihr da vor ?

    Ehrlich gesagt, steh ich gerade vor exakt dem gleichen Problem. Ich will am PC was mit "aseprite" pixeln und das dann als ein PI1 für den ST konvertieren. Mein Plan ist, auf dem PC einen Converter zu basteln, der mir BMP oder PNG (oder notfalls auch TGA) in PI1 umconvertiert.

    Aber der Plan ist noch nicht in die Tat umgesetzt... ;)

    Diese Version (ab 29 EUR) kann dann auch RGB:

    Ja genau. Diese kann RGB. Allerdings ist sie Framebuffer basiert und hat ein kleines Lag... Für Rechner mit Mausbedienung gerade noch so praktikabel, aber für mich war das Lag dann doch der Grund mich nach was anderem umzusehen. Hat sich einfach komisch angefühlt mit der Maus.


    Für Rechner mit Tastaturbedienung und ohne Action Spiele ist das Teil aber sicherlich eine Überlegung wert. Die Bildqualität fand ich ziemlich gut. (am Atari ST benutzt)

    Das zweite neue Etwas habe ich bisher nur in Richtung des Museums gerollt, denn dafür muss ich noch ein wenig mehr Platz schaffen als erwartet. Um das Problem zu visualisieren, habe ich mal einen handelsüblichen PC und einen meiner riesigen PowerMac G5 daneben gestellt. :sunny:

    Puh - am imposantesten finde ich eigentlich den Größenvergleich mit der handelsüblichen Tür hinter dem Gerät! :P

    Es ist zwar nur Software und auch nur eine Kleinigkeit, aber ich bastele gerade an einem kleinen Tool, das auf dem Atari ST in der mittleren Bildschirm-Auflösung die Maus-Bewegungen endlich "rund" macht.


    Wer das Problem nicht kennt: die mittlere Auflösung auf dem ST ist 640x200. D.h. die Pixel sind nicht quadratisch. Das Gem berücksichtigt das bei den Mausbewegungen nicht, d.h. wenn man die Maus im Kreis bewegt, dann ergibt das auf dem Bildschirm ein vertikal ausgerichtetes Oval. Fühlt sich einfach sch.... an. Hat sich schon immer sch.... angefühlt und wird es für mich auch immer tun.


    Wie auch immer: seit dem Retro-Abend gestern im Shack ::hacking:: funktioniert das Tool auch aus dem AUTO-Ordner heraus, obwohl zu dem Zeitpunkt das Gem noch gar nicht die Kontrolle über die Maus übernommen hat. Da erfreue ich mich gerade dran! :mrgreen:

    Ich hatte vor einem Jahr auch mal mit dem cross gcc herumgespielt - hauptsächlich mit den Versionen von Thorsten Otto, da es einfach die aktuelleren GCC Versionen mit den neueren unterstützten C++ Sprachfeatures sind. Mir ging es auch wirklich um modernes C++ und nicht um reines C.


    Dazu ein Hinweis von meiner Seite, falls jemand in ähnliche Probleme reinläuft: Die GCC-Version 10.1.0 (getestet mit gcc-10.1.0-mint-bin-cygwin64.tar.xz) auf Thorstens Seite hat leider einen Bug! Konstruktoren und Destruktoren von globalen Objekten werden nicht aufgerufen. Testbar ist das mit dem folgenden Code-Schnipsel


    Die erwartete Ausgabe vom Schnipsel wäre:

    Code
    ctor called!
    main reached!
    destructor called!

    Tatsächlich gibt das Kompilat jedoch nur die "main reached!" Zeile aus.

    Bei Thorstens GCC Version 9.3.1 (getestet mit "gcc-9.3.1-mint-bin-cygwin64.tar.xz") funktioniert das hingegen noch korrekt.


    Insgesamt waren meine Erfahrungen ein wenig ernüchternd. Mein Ziel war eigentlich hardwarenahe Programmierung unter modernem C++ für einen Standard 1040er mit 1MB Ram unter TOS mit möglichst wenig Bibliotheks-overhead. Die Mintlib fand ich unglaublich aufgebläht. Libcmini sah nach einem guten Kompromiss aus. Aber ich hab's damals lt. meiner Erinnerung nicht geschafft gehabt, selbst relativ triviale C++ Programme damit kompiliert zu bekommen.

    PeterSieg hast du das irgendwie hinbekommen?


    Experimentiert hatte ich auch mit compiler settings wie "-nostdlib -lgcc", aber dann fehlen gleich beim linken so völlige basics wie Implementierungen von new- und delete-operatoren und solche gcc interna wie __cxa_throw_bad_array_new_length()...


    Später hab ich dann noch das Projekt hier gefunden: atari-gcc-startup

    Aber damit herumgespielt hab ich dann nicht mehr...

    Halt mal die Politik bitte raus aus dem Forum, sonst fliegt dir das Thema ganz schnell um die Ohren.....

    ....hatte auch schon ueberlegt so ziemlich das selbe zu schreiben.....;-)

    Also das mit keine Politik...

    GEGEN BLAU/BRAUN zu sein ist keine Politik- sondern eine grundsätzlich geltende Einstellung halbwegs intellektueller Menschen, Burschen! ;)

    Blau, Braun? Da fehlt noch Grün-Gelb!

    :strom:

    Oh hübsch! Hast du vor da was zu releasen?


    Mir ist die leider ein bissel zu weit weg, und ist gerade auch nicht "urlaubszeitkompatibel"... Aber es wär schon mal wieder interessant bei sowas dabei zu sein! :)

    So ein paar Atari Disketten ....

    Was mich gerade bissl stutzig macht: auf den Disks steht oben Atari STE/TT Computer drauf... Sollte das Unix tatsächlich auf einem STE laufen? :grübel: Ich war mir bisher eigentlich ziemlich sicher, dass es eine PMMU voraussetzt...


    Wahrscheinlich waren die Disklabels damals einfach ihre Standard-Labels, die sie dann für alles mögliche verwendet haben, oder?

    Das ACSI2SD Kit ist schon OK

    Ich habe dazu noch eine Frage: Muß ich mein TOS eigentlich dafür aufrüsten?
    TOS1.02 ist im Rechner.

    Ich glaube: nein, musst du nicht zwingend aufrüsten!

    Ich hab allerdings kein ACSI2SD um's zu testen...


    Soweit ich mich erinnere ist zwar der HDD Support in TOS 1.02 noch recht buggy, aber ich hab damals Jahre lang einen STFM mit 1MB und TOS 1.02 und einer Megafile 60 betrieben - ohne Probleme. Wenn man mal davon ausgeht, dass sich das ACSI2SD nicht anders als eine Megafile 60 verhält, dann müsste das prinzipiell funktionieren.


    Ich glaub ab TOS 1.04 ist der HDD support stabiler - und 2.06 ist von der Bedienung her halt schon n bissl komfortabler. Aber wenn du erstmal mit dem ST warm werden willst, dann sollte es das TOS 1.02 tun.

    Gäbe es eigentlich Interesse an Literatur / Zeitschriften? So manches habe ich hier mittlerweile doppelt / dreifach / vierfach …

    Also prinzipiell hätte ich schon Interesse an Atari Literatur/Zeitschriften.

    ... ich schreib dir mal ne PN...