Posts by pgeorgi

    dann brauche ich auch keine Versionen meines Emulators dafür anzubieten.

    Konsequenter wäre es wohl. Aus Erfahrung kann ich sagen, dass die gute alte Sitte, überhaupt keine binaries anzubieten, auch für befremdliche Reaktionen sorgt. Bei coreboot überlassen wir den "Kundenkontakt" denen, die Nerv dafür haben, da werden auch manche grantig weil es nichts "offizielles" gibt...


    Aber immerhin hat man sich keine Arbeit gemacht, für die man angepflaumt wird, und es gibt auch keine Verwirrung, ob die binaries funktionieren.

    Es ist auch völlig schnurz.

    Es widerlegt die Aussage, dass eine Kollision angeblich erst dann stattfindet, wenn die Pixel der Sprites gemalt werden. Die Sichtbarkeit ist unerheblich. Wichtig ist die Position der Sprites.

    Richtiger wäre wohl "wenn die Pixel gemalt würden": dem Dokument auf zimmers.net zufolge, das ich hier irgendwann verlinkt habe, gibt es engines für Vordergrund, Hintergrund, den Rahmen und jedes Sprite, die für jedes Pixel bestimmen, ob und was sie an der Stelle malen würden und dann eine Priorisierung, was davon auf dem Bildschirm landet. Wenn zwei Spriteengines sagen, sie hätten was beizutragen, werden deren Kollisionsbits gesetzt.

    Wenn solche Probleme in einer Veröffentlichung auftreten, ist das ein ziemlich deutlicher Hinweis darauf, dass die Entwickler selbst kein Windows verwenden.


    Warum sollten die dann irgendeinen Aufwand auf sich nehmen, eine Plattform zu unterstützen, die sie nicht interessiert?


    Einen Psion Port pflegen die ja auch nicht, nur weil ich gern einen hätte. Wenn ich das will, muss ich halt selbst Hand anlegen.

    Eine Verzögerung von einem Screen wäre ja eine fünfzigstel Sekunde. Die Frage ist, wann genau das Kollisionsregister aktualisiert wird. Wenn der Rasterstrahl eine bestimmte Position erreicht? Oder wenn er sie zum zweiten Mal erreicht?

    Soweit ich die Beschreibung verstehe, werden die Bits gesetzt, sobald der VIC-II an der Stelle ist, wo die Kollision auftritt. Also: für jedes Pixel auf dem Screen: gucke, was gerendert werden soll. Wenn mehrere Sprites dran sind (oder Sprite + Hintergrund), setze das entsprechende Bit.


    Daraus könnte eventuell was für detect werden, wenn es 1/50 Sekunde dauern darf (plus Overhead). Grobe Idee:

    1. Bereite einen Puffer vor

    2. Speichere aktuelle Rasterzeile

    3. Solange man nicht "einmal rum" ist (also die Rasterzeile anders war und wieder gleich der gespeicherten wird):

    3a. Lies das Kollisionsregister. Wenn es eine Kollision gibt, speichere sie weg. (zum Beispiel 256 byte Puffer mit $d01e als Index, Platzprobleme ignoriere ich hier mal)


    check könnte dann im Puffer gucken, ob die entsprechende Kombination gesetzt ist oder nicht.


    Das wäre immer noch nicht perfekt, weil bei sehr knappen Situationen mehrere Kollisionen in eine zusammengefasst werden könnten (der VIC ist arg schnell), aber das Risiko sollte damit deutlich kleiner sein, alle Kollisionen werden erfasst und die Laufzeit wäre planbarer (halt immer ungefähr 1 Frame).

    Ich hab festgestellt, dass der VIC auf das Kollisionsregister erst beim zweiten Impakt reagiert

    Bei mir reagiert das Kollisionsregister meistens erst bei der zweiten oder dritten Abfrage. Ich glaube das hat nichts mit der Anzahl der Kollisionen/Impacts zu tun, sondern ist einfach zeitabhängig.

    Code
    1. A collision of sprites among themselves is detected as soon as two or more
    2. sprite data sequencers output a non-transparent pixel in the course of
    3. display generation (this can also happen somewhere outside of the visible
    4. screen area).

    (aus http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt)


    Von daher gibt es eine Verzögerung von bis zu einem Screen. Das macht natürlich auch Experimente wie "paarweise aktivieren und gucken, ob das Register triggert" sinnlos, weil die Sprites dann einige Frames lang durchflackern würden. Weitere Kollisionstests müssten dann über die Koordinaten der Sprites vorgenommen werden, was natürlich unscharf bleibt, wenn man nen Haufen Sprites mit komplizierten Formen hat, die mehr-oder-weniger überlappen und man wissen will, genau welche zwei von denen überlappende Pixel haben.

    Falls also ausser Frank irgendjemand diese Dateien hat, die er mal auf Github und anderen Plätzen veröffentlicht hatte, wäre ich durchaus neugierig. Immerhin basieren diese ja auf vielen meiner Ideen und insbesondere dem angepassten CP/M BIOS dazu.

    Die BOM unter https://github.com/kneehighspy…mmodore%20C64%20V0.3.xlsx enthält einen Xilinx XC95144XL-7TQ100C, von daher würde ich mal davon ausgehen, dass der Rest des Repos ebenfalls das neue Design beschreibt?


    (Im Übrigen ist DL2DW laut einiger Quellen ein Dirk W., kein Frank)

    War angeblich auch nötig, weil Commodore Australia gedroht haben soll, jeden einzelnen Z80 aus dem C128 rauszulöten, bevor sie dort in den Verkauf gehen, weil Z80 ja mal so gar nicht geht.

    Wie verhindert man das? Die Kiste startet nicht mehr ohne!

    Es gibt irgendwo eine ausführliche Beschreibung vom Startvorgang des C128. Wenn ich mich richtig erinnere, dann gibt es technische Gründe dafür, dass der C128 zunächst mit dem Z80 startet.


    Wenn du eine Quelle für die Australien Geschichte hast, gerne mal posten.

    Zu den Australiern hat Bil Herd was auf Reddit geschrieben: "We didn't tell management that we had built in the Z80 until it was too late to stop us. We got a telex from CBM Australia telling us that they would "personally" open the C128's and remove the Z80s if we insisted on shipping with it, which just made us want it more."


    Die Reihenfolge ist wohl eine etwas andere (der Z80 war schon eingeplant), aber die Australier waren über den Z80 wohl nicht sonderlich glücklich - die Drohung, ihn auszubauen, inklusive.

    Tja und außerdem einen Z80 aber nur für CPM.

    Tatsächlich ist der Z80 die erste der beiden CPUs im C128, die aktiv wird.

    War angeblich auch nötig, weil Commodore Australia gedroht haben soll, jeden einzelnen Z80 aus dem C128 rauszulöten, bevor sie dort in den Verkauf gehen, weil Z80 ja mal so gar nicht geht.

    Wie verhindert man das? Die Kiste startet nicht mehr ohne!

    Weil es kein Basic-Programm ist.

    Die meisten Spiele sind auch keine BASIC-Programme. Und trotzdem kann man sie mit RUN starten.

    Die liegen dann halt auch bei 2063 oder so, statt bei 33095. Ist für eine BASIC-Erweiterung etwas unpraktisch, wenn sie dort rumliegt, wo das BASIC Programm hin soll.

    Wenn du willst, schick tsb.obj durch irgendeinen Packer, der dir daraus ein Programm mit BASIC-Start baut und die Daten an Ort und Stelle legt, bevor dorthin gesprungen wird. Exomizer oder so.

    Mir wurde mal gesagt, dass die deswegen so schnell waren weil sie eben nicht die einzelnen Produkte eingetippt haben sondern nur die Preise

    Könnte auch Plus gewesen sein, mit den Nummern. Da ging das auch ziemlich flott voran. Ich habe jedenfalls schon oft gehört, daß Kassierer sich früher viel mehr Nummern merken mussten. Heute kommt das ja praktisch nur noch bei Sachen zur Anwendung, die an der Kasse gewogen werden.

    An Bons, wo einfach nur Preise drauf standen, und man deshalb überhaupt nicht nachvollziehen kann, was man gekauft hat, erinnere ich mich aber auch noch. Gut möglich, daß das die von Aldi waren.

    Aldi Nord vs Aldi Süd. Ich glaube, Süd hat Preise getippt und sich auf 10 Preisgruppen beschränkt, Nord hat Produktnummern gehabt, die haben ja auch früher angefangen, ihre Produktpalette zu erweitern.