Hohoho ...!
Das ist aber gar kein Mega65.
Du hast völlig recht. Es ist offensichtlich ein VC20, erkenntlich am hellen Gehäuse, es muss Weihnachten 1981 sein. Man sieht es vor allem am Poster hinten, Kim Wilde, eindeutig, 1981 hatte sie diese Frisur ... 
Wen's interessiert: Ich habe die Teile, die mich vom Compendium besonders interessieren, auf etwas besserem Papier in A5 drucken und lochen lassen und in einen "Präsentationsordner" (https://www.amazon.de/Esselte-…ef_=ast_sto_dp&th=1&psc=1) gegeben. Dort kann ich einzelne Seiten leicht durch neuere Versionen austauschen. Das erinnert mich an mein C-Lab Notator Handbuch Ende der 80er Jahre 
Ich persönlich würde nicht so viel zahlen für einen MEGA65.
Ich auch nicht! 
Aber ich gehe natürlich davon aus, dass es sich um einen ehrlichen Verkäufer handelt, der einen allfälligen Käufer auch darauf hinweist, dass er den MEGA65 durchaus auch neu (und nicht gebraucht) erwerben könnte und für das neue Produkt auch 1.000 EUR weniger zahlen würde, also er den Mehrpreis lediglich damit rechtfertigt, dass sein Produkt schon gebraucht ist und er es ggf. um ein paar Wochen früher in den Händen halten kann. 
Würden wohl viele mit Angebot und Nachfrage argumentieren.
Ja, da hast du völlig recht. 
Und wenn er einen Käufer findet, dann hat der Preismechanismus auch funktioniert. Der "Markt" hat - wie wir immer wieder erkennen können - keine soziale/gesellschaftliche Funktion. Aber genau da greift meiner Meinung nach das Recht ein und beschränkt die Möglichkeiten einer völlig freien Preisbildung. Und wenn dem Käufer unterstellt werden kann, dass er nicht aus Leichtsinn oder Unerfahrenheit gekauft hat, dann greift die Strafbestimmung ja ohnehin nicht!
Ich wollte ja nur am Stammtisch labern 
Natürlich vollkommen ohne Bezug zu den letzten Posts, denn es gilt ja klar die Unschuldsvermutung und ich will sicherlich niemandem etwas unterstellen: Kleiner Auszug aus dem österreichischen Strafgesetz 
Wer außer den Fällen des § 154 gewerbsmäßig die Zwangslage, den Leichtsinn, die Unerfahrenheit oder den Mangel an Urteilsvermögen eines anderen dadurch ausbeutet, daß er sich oder einem Dritten für eine Ware oder eine andere Leistung einen Vermögensvorteil versprechen oder gewähren läßt, der in auffallendem Mißverhältnis zum Wert der eigenen Leistung steht, ist mit Freiheitsstrafe bis zu drei Jahren, wenn er jedoch durch die Tat eine größere Zahl von Menschen schwer geschädigt hat, mit Freiheitsstrafe von sechs Monaten bis zu fünf Jahren zu bestrafen.
Für den MEGA65 kommt (zumindest jetzt noch), nachdem er im Handel frei erhältlich ist, keine Bestimmung wie für Sammler- und Liebhaberobjekte in Frage ...
I am seriously considering selling the machine because the documentation is incomplete and I do not have the time to figure out things that hard way, It is 2024.
Yes, you should! This device is so obvious not right for you. The entire development team makes an incredible (unpaid) contribution here - without any complaining. I think the decision to prioritize the documentation for Basic is completely right. MEGA65 primarily wants to appeal to beginners. Developers of compilers surely have ways and means to compensate for the incompleteness in documentation. Take the time to browse the posts on this forum, check out Dan's Digest. Almost everything is already discussed here! Or ask a question. But complaining does not bring us forward. If this is not efficient enough for you, sell the machine, there are others waiting for the devices.
2) Du verlässt dich irgendwo auf Default-Werte in den (VIC IV-)Registern. Ich habe aus leidvoller Erfahrung feststellen müssen, dass man lieber alles explizit setzt.
You're right, absolutely. I tried to address this and set all necessary VIC registers explicitely, but of course I can always forget something But in this case, I don't think VIC settings are the problem, because I did some tests together with Skulleater and we could narrow the problem definitively down to the loading routine, which for some reasons failed on Skulleaters system.
Just tested again on my real Mega65 and it is as Gurce described in the other thread ...
Dddaaannn from discord mentioned that POKE 1,135 was another way to get the load working. It seems to relate to a change in rom 920384 relating to io register $01 and c64 memory mapping.
Ok, thanks for the informations, I am on vacation now, but when I am back home, I will test the POKE 1,135 solution with another testing routine for Skulleater. Let's see ...
Hi, Detlev!
Schau Dir mal den Welcome Guide von dddaaannn an (https://dansanderson.com/mega65/welcome/) an, deckt viel ab an Informationen, die im Handbuch so nicht enthalten sind. Mir hat der Welcome Guide sehr geholfen. Dan hat auch einen Blog (https://dansanderson.com/) mit interessanten Infos zum Mega65.
Sieh Dir vielleicht auch den Mega65 Filehost (https://files.mega65.org/) an, da gibt es jede Menge Demos und Projekte, die den Einstieg etwas erleichtern
Alles Gute für den Einstieg!
Matthias
still have to test this on my real Mega65 but I really want to know why the way you load a game lead to corrupted graphics
So strange 
... but now we have something to start with. Tempus executes at $5000 while the bitmap data is at $2000 (which was necessary because I was technically unable to combine HiRes bitmaps with 16-color sprites with the bitmap at another location as $2000), perhaps this collides somehow with the way the program itself is loaded, just a first guess, but still it is strange anyhow ...
Die C64 IF Abfragen waren nur als Beispiel, wie man es besser nicht macht.
Ok, das hab ich echt falsch verstanden ...
Das sind alleine 8 IF/THENś nur für die Richtungsabfrage. Eine neunte käme hinzu für den Feuerknopf.
Hi. Als Alternative würde ich folgendes vorschlagen:
Die Portafrage mit J=JOY(1) gibt Werte von 1 bis 8 bzw. 128 für den Feuerknopf.
D.h. ich hol mir die Werte exklusive dem Feuerknopf mit J AND 15 (dadurch fällt das 128 weg)
Dann bereiten wir 2 Arrays vor, zum Beispiel
DIM CX(8) mit den Werten 0,1,1,1,0,-1,-1,-1
In der Loop wird dann der Index (J AND 15) aus dem Array gelesen.
D.h. ist der Joystick rechts oben, rechts, rechts unten ergibt das mit Index 1,2 oder 3 ein Delta-X von Plus 1
Ist der Joystick links unten, links, links oben ergibt das mit Index 5,6 oder 7 ein Delta-X von Minus 1
In der Loop muss jetzt das DeltaX nur durch eine Arrayabfrage stattfinden:
dx=CX(J AND 15)
Das dx verändert dann in der Bewegungs-Loop die x-Koordinate der Spielerposition.
Dadurch ersparst du dir alle IF-Abfragen und erhöhst die Geschwindigkeit auf ca. das 2,5-fache
Immer wenn sie den 2. Button drücken macht der Computer ein Reset. Wenn sie keinen drücken, macht er trotzdem einen Reset.
Meines Wissens gibt es das auch nicht beim Xemu-Emulator. Bin hier aber nicht auf dem allerletzten Stand.
Der Emulator unterstützt Attic
Am Besten, das Spiel läuft nur auf dem R6-MEGA65, dann sind fast alle gleichermaßen ausgeschlossen
MC64 hat eigentlich nur eine Frage wegen des 2. Buttons gestellt ...
Nur weil mein R3 vielleicht, eventuell man weiß es nicht nur einen Butten unterstützt möchte ich nicht ausgeschlossen werden.
Seh ich ganz genauso! Ich würde es mit meinem R3 selbst auch gerne spielen
Abgesehen davon sind wir bei den Sprites doch "eingeschränkt" auf die Bänke 4 und 5, sofern das Nexys unterstützt werden soll - denn dort gibts kein Attic.
War es nun eigentlich möglich mit einem R3 Board Joysticks mit 2 Buttons anzusprechen ?
Da bin ich überfragt. Ich weiß wie 1 Button implementiert ist (Bit 7), aber ich kann natürlich nicht ausschließen, dass es neben 56320/56321 auch noch andere Register gibt, mit denen der Status vom 2. Button abgefragt werden kann ...
Besser ist das. Die Sprites nehmen derzeit 43KB ein und das ist gerade etwas mehr als die hälfte.
Ja, überhaupt kein Problem. Ganz im Gegenteil, je mehr unterschiedliche Bewegungen, umso interessanter das Spielerlebnis
Und man hat unter S-Basic nur einen bestimme Anzahl für seine Sprites. Hängt mit dem Speicher zusammen.
Der MEGA65 bietet uns hier super Möglichkeiten; Wir sind zwar wie früher mit 8 gleichzeitig limitiert, aber wir haben ein extrem schnelles DMA (auch in BASIC) und wir haben viel Speicher im ATTIC RAM. Üblicherweise ändert man bei Spriteanimationen den Spritepointer. Ich möchte das aber jetzt bewusst etwas überstrapazieren: Wir könnten sogar die Spritepointer oder einzelne Spritepointer gleich lassen und dafür laufend Spritedaten vom ATTIC in den lower RAM schieben.
In einer Sekunde kann BASIC65 mit EDMA über 3000 (!) Einzeltransfers von 168 Bytes Daten durchführen. Natürlich muss in einer Sekunde sonst auch noch viel gerechnet werden (Joystick input, Move Sprites, Töne spielen, KI, etc), aber mit 10% der verfügbaren Rechenleistung bekämen wir satte 30fps für 8 Sprites hin, ohne auch nur ein einziges Mal einen Pointer zu ändern. Das ist natürlich nur ein Rechenbeispiel, denn natürlich werden wir mit den Pointern arbeiten, aber ich wollte v.a. klarstellen, dass wir - was den Speicher anbelangt - mit großer Sicherheit an keine Grenze stoßen werden
Obwohl die Daten 168 Bytes für das 1. Bild und direkt dahinter
die nächsten 168 Bytes für das 2. Bild im Speicher liegen.
Du hast es zwar eh schon selbst beantwortet. Aber ja, bei Fullcolor 16x21 Sprites brauchen wir jeweils 3 x 64-Byte-Slots, daher muss der Pointer jeweils um 3 erhöht werden. Die jeweils letzten 24 Bytes (192-168) bleiben dann halt unbenutzt ...
Meine Überlegungen ist es mit EDMA die Sprites aus einer anderen RAM Bank rein zu kopieren.
Die Sprites müsste ich in der Datei dann entsprechend anordnen, das es mit einem EDMA Kommando erledigt ist.
Für Grafik habe ich aber normal nur Bank 4 und 5, oder kann ich noch andere verwenden ?
Ja, das entspricht auch so in etwa meinem Informationsstand. Mit den 16-Bit-Pointer und dem (unveränderten) 64-Byte-Slots sollten wir jetzt 4MB adressieren können. Allerdings gibt es im lower RAM nur die Banks 0-5, also bleiben uns praktisch vor allem Bank 0, Bank 4 und Bank 5. Aber, wie du richtig geschrieben hast, limitiert uns das nicht in der Anzahl der Sprites. Wir nutzen einfach ATTIC RAM und holen uns die jeweils benötigten mit EDMA irgendwo in den lower RAM (Bank 0, 4 oder 5) für den Fall, dass wir in diesen Bänken zu wenige Speicher für alle Spritedaten haben ...
Am schwierigsten fand ich, dem Computergegner sinnvolles Karate beizubringen
Hi! Wir werden das mit einem Algorithmus machen. Für mich ergibt das zum jetzigen Zeitpunkt am meisten Sinn, wir haben eine hohe Taktfrequenz zur Verfügung und die würde ich auch gerne nutzen. Tabellen wären meine erste Wahl, wenn ich wenig Cycles habe und ich Berechnungen eben mit "Vorausberechnungen" ersetzen muss, haben aber dann auch das Problem, das bestimmte Moves nach einiger Zeit für den Spieler vorhersehbar werden. Ich kann mir aber durchaus vorstellen, dass wir einzelne Aktionen/Reaktionen auch mit einer Tabelle lösen, etwa wenn der Algorithmus in der schwierigsten Einstellung keine adäquat komplizierten Angriffs-/Abwervektoren berechnet ...
