Beiträge von Peter

  • Fraktale Landschaft mit Basic und Assembler-Routinen

    Hm, dann hab ich mich wohl geirrt und es war tatsächlich aus der 64er.. ist halt schon ne Weile her..

    Inspiriert von den Optimierungsthreads die hier sonst noch so laufen... mir ist aufgefallen, dass ab dem zweiten Dreieck in einer Zeile die jeweils linke Linie doppelt gezeichnet wird.. das müsste man bestimmt besser hinkriegen.. mal sehen, ob mir dazu was einfällt.

  • Fraktale Landschaft mit Basic und Assembler-Routinen

    dann poste ich mal mein Listing - wie gesagt, nur abgetippt und in Simons Basic umgesetzt. Simons Basic muss natürlich geladen sein.

    Es gibt einen Teil wo berechnet wird und einen wo gezeichnet wird.. in beiden Teilen kann man sicher viel optimieren.. einige Linien werden doppelt gezeichnet und die Basic-Integer% sind wohl auch nicht so performant..

    Am Beginn gibt man einen "Grad" den man eingibt, und der die Feinheit des Gitters angibt.. man sollte so mit 3 starten.. 4 ergibt auch Sinn, dauert aber länger.. meine Grafik war mit 3, wenn ich nicht irre...

    viel Spaß

  • Fraktale Landschaft mit Basic und Assembler-Routinen

    Das Programm hatte ich damals auch.. ich bin aber nicht mehr sicher ob ich das in Simons Basic umgesetzt hatte, wegen der Grafik Befehle.. ich hatte es dann aber ziemlich schnell auf den PC und Turbo-Pascal portiert, da es auf dem C64 untragbar langsam war.. das muss dann so 1990 gewesen sein, da ich damals den ersten PC zwischen die Finger bekam und der C64 von da an bis vor 4 Jahren in der Kiste ruhte..


    Fraktale fand ich damals megacool, auch wenn das kein richtiges Fraktal ist.. wie Du ja schriebst.


    Grüße

    Peter

  • Der Restore-Store vor dem Aus? - Bobbel benötigt Hilfe beim Shop

    Danke an Bobbel auch von meiner Seite.. ich habe nicht oft gekauft, aber die Teile waren wichtig, um das Leben meiner Geräte zu retten. Außerdem hab ich ne 1581 nachgebaut, die ich wirklich liebe.. die Unterstützung beim Aufbau war inklusive.. wo gibt sowas sonst?


    Ich schreib Dich also einfach an, wenn mal ich mal wieder nen 6569 oder so brauche und hoffe dann, dass nochwas da ist...


    Ich verstehe Deine Entscheidung gut.. wenn ich das Hobby nicht auch mal ein Jahr vernachlässigen könnte, hätte ich es gar nicht mehr. Aber wenn man Verpflichtungen hat, kann man das eben nicht.



    all the best!

  • CBM DOS Direkzugriff Problem

    Zitat von JeeK
    Zitat von Peter

    Super Danke - jetzt tut es was es soll! Zusammen mit dem Channel-Puffer Ding hab ich heute viel gelernt!

    Du kannst dich bei den Leuten auch gerne mit einem "Like" bedanken, die dir geholfen haben. Fände ich als eine nette Geste. ;)

    Hallo Jeek, ja da hast Du sicher Recht.. wahrscheinlich bin ich nur bisschen zu altmodisch für diesen like-Kram.. ich bedanke mit eben gern konventionell.. also hier mit geschriebenem Dank. Aber versuche mich zu bessern!

  • CBM DOS Direkzugriff Problem

    Zitat von Mike

    Du mußt mit "B-P" im Kommandokanal zuerst die Startposition festlegen, bevor Du in den Puffer schreibst. In deinem Fall (mit der Sekundäraddresse 2), "B-P 2 0"


    Nebenbei: solange Du hinter "#" keine Puffernummer angibst, weißt CBM DOS der Sekundäraddresse irgendeinen freien Puffer zu, das muß nicht zwingend der bei Adresse $0500 sein.

    Hallo Mike,


    Super Danke - jetzt tut es was es soll! Zusammen mit dem Channel-Puffer Ding hab ich heute viel gelernt!

  • CBM DOS Direkzugriff Problem

    Hallo goloMAK ,


    Nein, hab ich noch nicht - mach ich aber.


    Da aber einige Basic Beispiele so funktionieren, denke ich, dass der Puffer 2 standardmäßig vergeben wird, wenn nicht ein anderer angefordert wird. Sonst wären ja die ganzen Beispielprogramme Zufallsprodukte.


    Mir ist schon klar, dass Channel nicht gleich Puffer ist.. aber zum Beispiel in "Inside Commodore DOS" von Immers und Neufeld wird es so gemacht. Das Beispiel für U1 liest den Sektor von Diskette, dann wird der Datenkanal geöffnet (die Puffernummer steht dabei NICHT im open Befehl) und dann wird explizit aus Puffer 2 gelesen (die 2 ist dabei im Quelltext hart codiert).

  • CBM DOS Direkzugriff Problem

    Hallo goloMAK


    Ich sehe ja, in welchem Puffer die Daten landen (per Speichermonitor).. und eben

    an der Sekundäradresse.

    Open 2,8,2,"#"


    Und wie gesagt, im Codebeispiel von Commodore selbst steht auch nur "#", und dann im U2 Befehl muss man den Puffer benennen.. da steht dann die 2.

  • CBM DOS Direkzugriff Problem

    Vielen Dank Mike,


    Das probier ich morgen aus!


    Btw. Ich hatte auf der Commodore Testdiskette gespickt.. da gibt es u.a. das Programm Check Disk.


    Dort wird auch mit Puffer 2 hantiert,.Ohne dass das als #2 benannt wurde. In der Literatur steht es.mal so und mal so.. oft wird behauptet, dass es die Sekundäradresse sei, die den Puffer bestimmt.. das konnte ich beim Probieren auch bestätigen... zumindest nicht widerlegen.. aber so richtig logisch ist das nicht, weil soviel Puffer hat die 1541 gar nicht.. insofern komisch.


    Ob der buffer pointer hilft.. mal sehen

    Im Beispiel auf o.g. Diskette wird der auch nicht gesetzt und genau wie bei mir, beginnen die Daten dort erst bei 501h.


    Interessant auch: bei U1 (read) und anschließendem get#2 bekommt man das Byte an 500h geliefert..


    Grüße

  • SIDKick pico Aufbau, Tipps und Fragen

    Zitat von r.cade

    Awesome project, I got mine built! Forgive my English please...


    I noticed one thing on my build. On the PWM output, there are lots of "thumps", like there is low bass output whenever registers are accessed- maybe just the volume registers, but it happens all the time.


    On DAC output, it is very clean and no "thumps".

    Hey Peter,


    i asked the same question in another thread. It seems, those "thumps" are normal on the PWM output. I even ordered a second one to check if it is any better. But it's not.


    However it is the best replacement for my dead SID so I am very happy with it. I am only waiting for the new release with included DAC.


    best regards

    Peter

  • CBM DOS Direkzugriff Problem

    Liebe Forumskollegen,


    Ich probiere immer noch ein bisschen mit dem Direktzugriff auf die CBM Floppies rum. Dabei passieren mir die seltsamsten Dinge... ich fange mal mit einem an. Vergebt mir, wenn ich den Wald nicht sehe - ich bin aber sicher, irgendwer wirds wissen.


    Als Voraussetzung für einen U2 Befehl muss man ja einen Puffer befüllen. Ich entschied mich für #2 und habe mir einen String zusammengebaut, der 255 Zeichen lang ist. Ich gehe davon aus, dass der Puffer ein Byte mehr hat, aber Strings können m.W. nur 255 wegen des Längenbytes am Anfang. Aber selbst wenn das stimmt, müsste im Puffer nun Stelle 0..255 mit meinen Daten belegt sein.


    Seltsamerweise ist Byte 0 im Puffer (Adresse $500) laut Monitor aber immer ein Wert, den ich mir nicht erklären kann (oft $0d aber wie hier auch anders $15). Ab $501 kommen dann meine Daten. Was mache ich falsch?


    Anmerkung 1: ich beende das Print# Kommando mit ";" so dass eigentlich kein CR angehängt wird.. aber wenn schon, sollte es eh am Ende stehen, nicht am Anfang.


    Es nervt mich, weil das Byte natürlich mit im Sektor auf der Disk landet..


    Hier der Code-Schnipsel. Es folgt der beiden Speicherdump ab $500

    Code
    1. 120 open 2,8,2,"#"
    2. 130 a$=">":for i=1 to 253:a$=a$+"c":next:a$=a$+"<"
    3. 140 print#2,a$;


    Dump $500..5ff nach meinem Code:

    >8:0500 15 3e 43 43 43 43 43 43 43 43 43 43 43 43 43 43 .>CCCCCCCCCCCCCC

    >8:0510 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0520 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0530 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0540 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0550 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0560 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0570 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0580 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:0590 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05a0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05b0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05c0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05d0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05e0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC

    >8:05f0 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 3c CCCCCCCCCCCCCCC<


    Hoffe, jemand kann mir das aufklären.


    Grüße

    Peter

  • Computerspiele in der DDR

    Zitat von -trb-
    Zitat von Peter

    Ich hab den ganzen Podcast durchgehört und muss sagen, dass er meine Sichtweise und persönliche Erinnerung sehr gut wiedergibt. Hut ab, wenn man das alles neu recherchieren muss und trotzdem so detailliert, differenziert und faktenrichtig wiedergibt.

    Ich nehme an, du beziehst dich auf das, was daybyter gepostet hat? Das steht auch noch auf meiner Liste.


    Die Videos von Nasentroll hab ich bis heute nicht angeschaut und sehe dazu auch keine Veranlassung. Leider geht er ja nicht mal auf die Kritik hier ein.

    Also ich beziehe mich auf das Video von "Stay forever" aus Post #34 - daybyter hatte das hier gepostet.


    Da ich den Kanal als Podcast abonniert habe, hatte ich es schon dort durchgehört. Schönes Ding, so wie alle anderen Beiträge von denen, vor allem wo es um die Hardware geht.