Posts by Llama

    Oder nur die Caps getauscht worden? Der ist vom Atariservice original versiegelt (2 übereinander klebende Garantiesiegel). Vielleicht haben die auch die falsche Tastatur eingebaut und die HDD gleich mitgetauscht? MK1722 ist zu groß für Falcon 030

    Nein - es sind nicht nur die Caps getauscht worden. Bei der echten Falcon-Tastatur ist auch das Plastik-"Brett" unterhalb der Tasten dunklem grau. Bei der fehlenden Taste im Bild oben sieht man aber, dass das "Brett" auch hell ist.

    Hallö,

    mir stellt sich die Frage ob es den Falcon auch mit weißen Tasten gab (sieht besser aus) oder ob da schonmal jemand daran herumgefummelt hat?

    Also mein Falcon hat zwar auch weiße Tasten, aber nur weil da definitiv jemand dran rumgefummelt hat. In meinem Fall hat ein Vorbesitzer wohl eine Tastatur mit deutschem Layout gewollt. Auf dem Falcon Typenschild unten am Gehäuse steht hingegen: FALCON030 ITA. Es ist also wohl ursprünglich ein italienischer Falcon gewesen. Da die 1040 ST Tastaturen technisch identisch sind, war die wahrscheinlich einfach verfügbarer als eine echte Falcon Tastatur. Kannst ja mal dein Typenschild mit dem Tastaturlayout vergleichen. Wenn die auch nicht zueinander passen sollten tippe ich auf den gleichen Grund der Änderung.

    Puh - das sind aber viele Wünsche auf einmal! :D


    Also das mit den Wildcards sollte sogar eigentlich schon tun. Das hab ich extra eingebaut und beim Testen sowieso oft verwendet. Probier's mal aus!


    Zu den anderen gewünschten Features: ehrlich gesagt ist das Tool ja nur ein Nebenprodukt von was anderem. Quasi nur Mittel zum Zweck. Und da es hier ja diesen Thread gibt, hab ich's halt soweit als minimales Tool "fertig" gemacht, dass es auch jemand anderem von Nutzen sein könnte.

    Aber ob ich darüber hinaus noch sehr viel Zeit in das Tool reinstecken will glaub ich gerade eher nicht...


    Auf dem ST gibt's doch bestimmt schon Tools, die zwischen den verschiedenen ST-üblichen Formaten hin und her konvertieren können oder? Das Problematische ist ja hauptsächlich der eine Schritt von der "neuen" in die "alte" Welt. (Ok - und zurück von der "alten" in die "neue" Welt würde auch noch Sinn machen - vielleicht mache ich das doch noch irgendwann...)

    Hmm... ich glaube, das was du beschreibst könnte bei Truecolor-Bildern Sinn machen. Wenn man z.B. ein 24 bit Truecolor-Bild nach 16 bit Highcolor konvertieren will. In beiden Fällen wird dort direkt die Farbe jedes Pixels unabhängig voneinander kodiert - allerdings bei unterschiedlicher Genauigkeit. Dein vorgeschlagenes Verfahren dürfte dort die sonst sichtbaren "Höhenlinien" reduzieren. Ist quasi eine Form eines "Dithering" Algorithmus.


    Bei den Atari Grafik-Modi (und damit auch den Degas-Grafikformaten) handelt es sich aber um Bild-Kodierungen, in denen zu jedem Pixel nur der Index (z.B. 4bit/pixel) in eine Palette abgespeichert wird - und dann für jeden Eintrag der Palette (von insgesamt 16 Einträgen) dann die RGB-Farbwerte als 16 Bit Werte, von denen nur 9 Bits verwendet werden (je 3 Bits pro R, G und B Kanal).


    Meine Beschreibung der Reduktion von 8-Bit pro Kanal zu 3-Bit pro Kanal bezog sich nur auf die Konvertierung der Einträge der Palette. Dein Verfahren lässt sich aber glaube ich nicht sinnvoll auf die Palette übertragen.


    Bei meinem Tool hab ich auch bewusst auf ein "Dithering" verzichtet. Ich glaube, das kann man besser mit Gimp auf dem PNG erledigen. Mir war es lieber, dass das Tool nicht zu viel selbst macht. So hat man auf PNG Ebene bereits mehr Kontrolle darüber, wie nachher auf Atari das Bild repräsentiert wird. Z.B. wird bei bestimmten PNGs, die auch schon als Index-Pixel und Palette abgespeichert sind, die Reihenfolge der Farben in der Palette beibehalten. Das kann z.B. wichtig sein, wenn man durch Paletten-Cycling eine Animation im Bild vortäuschen will. (Stichwort: Neochrome Wasserfall).

    Die Palette zu konvertieren war nicht so schwierig.


    Bei Bildern, die im PNG Format schon palettiert abgespeichert sind wird die Palette mit 8 Bit pro Farbkanal abgespeichert. Also für die drei RGB Farben dann insgesamt 24 Bit. Das sind 16,7 Mio mögliche Farben (und damit mehr als die 262144 vom VGA Standard).


    Auf dem Atari ST (nicht STE) sind es jedoch nur insgesamt 3 Bit pro Kanal, was genau die 512 verschiedenen Farben ergibt.


    Um von den 8 Bit pro Farbkanal auf die 3 Bit pro Kanal herunterzurechnen, hab ich einfach den jeweiligen 8 Bit Wert um 5 Bit nach rechts geshiftet. D.h. die höherwertigsten 3 Bits bleiben erhalten und die niederwertigen 5 Bit werden einfach "abgeschnitten".


    Natürlich führt das ggf. dazu, dass der ST die feinen Farbnuancen nicht sinnvoll darstellt, aber das ist nunmal das Hardware-Limit des STs.

    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... :)

    Jetzt mal ehrlich - genau so checke ich, ob ein 9V-Block noch ok ist, wenn ich kein Messgerät zur Hand habe. Und das funktioniert ziemlich gut.

    Man braucht halt etwas Erfahrung welches Bizzeln welchem Ladezustand entspricht. :D

    Hmmm... Muss man seine Geschmacksnerven dann nach überstandener Corona Infektion diesbezüglich dann auch "neu kalibrieren" oder klappt das dann noch wie gehabt? :/

    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.

    Gute Anzeige!

    ohje... ohne (mental/wirr/deppert)... das gibt sicher Abmahnungen :stupid:

    Ach dafür steht das!

    Und ich dachte immer, das sei schon n bissl gewagt, dass dir da immer offen (männlich/weiß/deutsch) in Stellenanzeigen fordern... :grübel:

    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...)

    Egal, aktuell ziert sie mein Nachtkastl am Bett und erquickt mit mit ihrer automatischen Dimmfunktion (welche selbstredend! zusätzlich noch in der Helligkeit reguliert werden kann).
    Elektrosmog und Abwärme erzeugt die EC-10 wohl wie ein MRT, aber ich schlaf trotzdem (oder deswegen?) ganz gut. :D

    Vielleicht wär das ein guter Zeitpunkt, den Rauchmelder im Schlafzimmer nochmal zu prüfen ;)

    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: