Hallo Besucher, der Thread wurde 446k mal aufgerufen und enthält 2290 Antworten

letzter Beitrag von Claus am

Heute so gecodet...

    Kommt drauf an, ob Du kräftig das OS benutzt oder (so wie ich das früher immer gemacht habe) immer am OS vorbei programmierst.

    Der GDB stub wird durch die rechte Maustaste direkt im Kickstart nach einem Reset ausgeführt. Da ist das OS noch nicht wirklich hochgefahren.

    Der Status ist noch sehr expermimentell und funktioniert auch nur, wenn man FastRAM ab 0x200000 liegen hat. Wenn man einen Amiga hat, der nur Chipram (oder Sloram) zur Vergfügung stellt, bricht die Kommunikation ab, wenn man zu viele Bitplanes einschaltet oder den Copper zu stark wüten lässt.

    Momentant läuft das ganze auch nur auf 115200 Baud. Bin aber dabei, das ganze auf 230400 Baus hochzuoptimieren. Dann könnte man über die serielle Schnittstellt so ca. 20KB pro Sekunde übertragen.

    Zitat von peiselulli

    Kommt drauf an, ob Du kräftig das OS benutzt oder (so wie ich das früher immer gemacht habe) immer am OS vorbei programmierst.

    Teils, teils. Meine Library ist darauf ausgelegt dass man ohne OS auskommt, oder nur mit sehr wenige wie z.B. DOS um Files laden und schreiben zu können. Wenn ich an meinem Spiel arbeite, dann eben ohne OS, bei den Tools entweder mit oder auch auf dem PC.

    Meistens arbeite ich sowieso mit WinUAE, aber auch da wäre das Teil nützlich.

    Mittlerweile funktioniert mein Tool schon soweit dass ich ein PNG File laden kann, die Farben reduzieren und dann wieder als RGB oder Palettenfile speichern kann. Man kann also eine Grafik laden und angeben auf wieviele Farben es reduziert werden soll (bei RGB kann man die Anzahl beliebig reduzieren, bei PNG Palettenformat kann man sowieso nur maximal 256 Farben speichern).

    Nur die Berechnung der besten Farbe funktioniert noch nicht ganz richtig, da gibts noch Artefakte wo eine falsche Farbe ausgewählt wird, weil mein erster Ansatz zu naiv ist (aber dafür einfach zu implementieren).

    Falls jemand eine Idee hat, wie man das richtig macht, hätte ich nichts gegen ein paar Tips.

    Im Wesentlichen ist das Problem folgendes:

    Ich habe ein Bild mit (z.B. 8000) Farben. Um die auf 256 zu reduzieren, wähle ich die 256 häufigsten Farben aus damit diese erhalten bleiben. Jede der überzähligen Farben sollte dann so angepasst werden, dass aus den 256 erhaltenen Farben, diejenige ausgewählt wird, welche am "ähnlichsten" ist, und genau da hakt es noch ein wenig. Wie kann ich am Besten beurteilen welche Farbe am ähnlichsten ist?

    Im Moment mache ich das einfach so dass ich jeweils für R/G/B die Differenz bilde. Also (R0-R1) + (G0-G1) + (B0-B1). Das ist quasi die Distanz zwischen den beiden Farben. Diejenige mit der geringsten Distanz wird dann genommen. Das Problem dabei ist, dass diese Distanz bei zwei verschiedenen Farben zufällig gleich sein kann, obwohl die eine Farbe besser passt als die andere. Man muss das also irgendwie noch gewichten.

    Hallo zusammen,


    nutzt jemand von Euch ein iPhone und hat iCloud auf einem Windows-PC installiert?

    Dann dürfte aufgefallen sein, dass im "Download"-Ordner Bilddoubletten liegen, falls man am iPhone über die Bearbeiten-Funktion ein Bild am Handy zugeschnitten oder farblich verändert hat. Im iCloud-Download-Ordner im Windows liegt das originale und das bearbeitete Bild nach der Synchronisation dann nach dem Schema IMG4711.jpg und IMG4711(Edited).jpg vor (IMG4711(Bearbeitet).jpg kommt gelegentlich auch vor). Auf dem Telefon selbst liegen nur die Originale und eine Konfigurationsdatei zu jedem Original mit Modifikationseinstellungen. In geteilten iCloud-Alben sieht man dagegen (in reduzierter Qualität und unter anderen generischen Dateinamen) immer das zuletzt veränderte Bild.


    Mich interessieren aber die veränderten Bilder in hoher Qualität aus dem Download-Ordner. Ich brauche die Originale nicht. Wenn man nun eine Foto-Safari hinter sich hat, kann es viele solcher Doubletten geben, bei denen man die Originale nicht haben will (ich bin so jemand, ich bearbeite fast jedes Foto sofort im iPhone, um nicht hinterher an einem Rechner sitzen zu müssen um da nochmal jedes Bild anzulangen).


    Um die unbenötigten Originale nicht mühsam von Hand aus dem Download-Ordner löschen zu müssen, habe ich ein Python-Skript geschrieben und mit py2exe in eine Win32-Exe umgewandelt, die auch unter einem 64Bit Windows 10 ausführbar ist.


    So installiert und benutzt man das Programm:


    1.) Die Zip-Datei in einen eigenen Ordner entpacken - da ist die Exe drin, eine Python-Bibliothek und eine .ini-Datei

    2.) Die .ini-Datei öffnet man mit einem Texteditor und schreibt da den Pfad rein wo das iCloud-Downloadverzeichnis sich befindet. In der betreffenden Zeile muss worrtwörtlich

    path = Pfad

    stehen, d.h. nicht "path= Pfad" oder "path =pfad", ich fange solche Eingabevarianten nicht ab.

    Auch auskommentieren ist nutzlos, wenn man mehrere optionale Pfade in der .ini-Datei führen will, darf der String "path = " nicht in der Zeile vorkommen.

    Ich nehme einfach "# Pfad". Da kann anstelle des Hashes aber alles mögliche andere stehen, nur eben kein "path = " String.

    Ich weiß nicht ob es eine Art "Standardystem" gibt, das einem das Parsen erleichtert. Auch Case-insensitives Parsen kennt Python 2.7 nicht (Version 3 aber schon, aber damit arbeite ich (noch) nicht.

    3. Zieht die Exe mit der rechten Maustaste auf den Desktop, lasst sie da fallen und wählt "Verknüpfung erstellen".

    Ich habe mir dann noch ein schönes Icon aus der Standard-Bibliothek für die Verknüpfung ausgesucht (rechte Maustaste auf die Verknüpfung -> Eigenschaften -> Anderes Symbol)


    Beim Doppelklick geht ein Konsolenfenster auf und gibt Aktivitätsmeldungen aus. Gelöschte Dateien gehen in den Papierkorb, so dass sie wiederherstellbar sind. Achtung: ab dem Zielort wird rekursiv gelöscht, d.h. auch in allen Unterverzeichnis-Strukturen.


    Also wer mag, gerne runterladen und auch benutzen. :-)

    Zitat von Bytebreaker

    stehen, d.h. nicht "path= Pfad" oder "path =pfad", ich fange solche Eingabevarianten nicht ab.

    Auch auskommentieren ist nutzlos, wenn man mehrere optionale Pfade in der .ini-Datei führen will, darf der String "path = " nicht in der Zeile vorkommen.

    Ich nehme einfach "# Pfad". Da kann anstelle des Hashes aber alles mögliche andere stehen, nur eben kein "path = " String.

    Ich weiß nicht ob es eine Art "Standardystem" gibt, das einem das Parsen erleichtert. Auch Case-insensitives Parsen kennt Python 2.7 nicht (Version 3 aber schon, aber damit arbeite ich (noch) nicht.

    Das kann man eigentlich recht einfach machen.

    1. Zeichen einer Zeile prüfen ob es ein '#' ist. Wenn ja, dann Zeile ignorieren Damit kann man dann einfach Kommentare machen.

    2. path = lstrip(line.split('=', 1)[1]) (nicht getestet, aber so in etwas solllte das funktionieren).

    https://www.w3schools.com/python/ref_string_split.asp

    https://www.tutorialspoint.com…space-in-string-in-Python


    Damit wäre es dann egal ob der User blanks zwischen den '=' hat.

    Gerade Python hat eh sehr viele Funktionen die einem die Arbeit extrem erleichtern. :)

    @ sparhawk:


    Vielen Dank für Deine Hinweise, und ja, sowas in der Art müsste ich dann eben manuell abfragen.

    Die meisten Kommandozeilen-Tools sind da entsprechend eingabetolerant, ich hatte bloß gehofft, es gibt eine Art "eingebaute" automatische Hilfe beim Abfragen von Eingaben. In Python 3 kann man mit der Casefold-Funktion beispielsweise die Groß/Kleinschreibung ignorieren und sich einfach mal so eine Art Parser-Baukasten schreiben, den man dann immer wiederverwendet - da war ich dann zu bequem, weil außer mir wahrscheinlich kein anderer dieses Tool noch nutzen wird - aber wenn man etwas aus Prinzip richtig machen will, sollte man die Mühe eigentlich noch reinstecken. Werde ich machen, so wie ich dazu komme.

    Wieder ein großes Stück am Z80 Disassembler voran gekommen. 8o



    Jetzt würde ich theoretisch kein Z80 Buch mehr benötigen,

    weil der DisAss sämtliche Informationen eingebaut hat. :bgdev

    Das ist noch eine Spielerei aus der ersten Version vom Disassembler.


    Farbe 1 = CHAR(0)

    Farbe 2 = CHAR(1) - CHAR(31)

    Farbe 3 = CHAR(32) - CHAR(128)

    Farbe 4 = CHAR(129) - CHAR(255)


    Es gibt noch eine weitere Version von so einer grafischen Anzeige.

    Dort kann man sich später gezielt bestimmte Werte anzeigen lassen.

    Zitat von Bytebreaker

    Schick. Was benutzt Du als Programmiersprache?

    Auf den ersten Blick auf den Thumbnail dachte ich tatsächlich "Ach, mal wieder Excel - wie macht er das?" :D

    Visual Basic .net verwende ich. Excel habe ich in sofern verwendet das ich dort die notwendigen Daten (OpCodes, Firmware Sprungtabellen usw.) reingeschrieben hatte,

    weil man daraus sehr leicht in eine Textdatei konvertieren kann. Diese Textdateien lassen sich dann schnell und einfach im Disassembler laden und Anzeigen/Verwenden.

    Die ersten Codezeilen für die Umsetzung meines BASIC-Programms "cbmSCSIcopy64" nach GEOS/MegaPatch64 geschrieben. Als Assembler wird MegaAss 4.1 verwendet.


    Die UI funktioniert mit Dummy-Daten jetzt größtenteils. :)


    Aktuell unter VICE... wenn die UI läuft wird auf den C64 gewechselt, da VICE keine HD emulieren kann :(

    Habe mich nun auch mal an einem kleinen Oldschool-Intro versucht, basierend auf einem Musikstueck das ich angefertigt habe...



    2cool4nuskool.prg


    EDIT: Habs jetzt bei der gerade laufenden CSDB C64 Lockdown 2020 Fun Compo eingereicht: https://csdb.dk/release/index.php?id=190441

    Dank Kongo-Otto konnte ich heute das ROM-Listing in meinen Disassembler einbauen.

    Damit kann ich im Urlaub disassemblieren ohne das CPC-Intern mit zu nehmen. :thumbsup:


    PDF geht natürlich auch, aber das kann man schlecht im Disassembler einbauen. ;)

    Ich habe die Möglichkeit eingebaut im Disassembler auch auf das Buch vom Zaks zuzugreifen. :D



    Das Laden aller 612 Seiten benötigt einige Sekunden und dann

    braucht die Exe >1GB vom Hauptspeicher.


    Mal schauen wie weit ich diese Spielerei weiter verfolgen werde. :idea:

    Zitat von oobdoo

    Das Laden aller 612 Seiten benötigt einige Sekunden und dann

    braucht die Exe >1GB vom Hauptspeicher.

    Ist ein Scan so wie es aussieht, oder? Vielleicht kriegst Du es in ein textbasiertes PDF konvertiert, das sollte vermutlich den Speicherbedarf stark reduzieren. MS Word kann das mittlerweile wohl z.B. ganz gut.

    Ich habe kuerzlich mein eigenes Spiel abgetippt aus dem BASIC-Weihnachtsheft und daraufhin in einem Video dazu aufgerufen, dieses nun selbst wiederum aus dem Video abzutipppen, falls jemand Langeweile hat in Quarantaene-Zeiten...


    [Externes Medium: https://www.youtube.com/watch?v=v-rHZBJvdwc]

    Moin zusammen,


    ich hatte etwas Zeit und bin dem Aufruf von ZeHa gefolgt :-) Dabei habe ich das Spiel selber dann etwas "interaktiv" gestaltet :-)


    Bewegung tut ja auch ganz gut, wenn alle Sportstudios geschlosssen haben ... und so bin ich dann auch mal zum Skifahren gekommen... habe ich schon Jahre nicht mehr gemacht :-)


    Ansehen könnt ihr euch das ganze hier:


    [Externes Medium: https://www.youtube.com/watch?v=Ix3yUkqt5wc]


    Falls einer von euch Lust und Zeit hat den Quellcode um einen zwei Spieler Modus zu erweitern, wäre das eine Lustige Sache für die DoReCo. Ich würde dann auch noch durch nach vorne Beugen die Joystickrichtung nach vorne und hinten in die Balance-Board Konfiguration einbauen dann könnte man vorpreschen und so dem Gegner davon oder umfahren.


    Wenn man das Listing durch den BasicBoss Compiler am Ende jagt, wird es doppelt so schnell .... also sollte es trotz zweispielermodus noch genug spass machen können.