Beiträge von 5ace

    Nochmal ein letzter Bump meinerseits...

    Wir treffen uns zu einem geselligen Abend im Wirtshaus ohne Hardware und unterhalten uns über alles Rund um den C64 bzw. dem Retro-Computing als Thema.


    Morgen, Donnerstag, den 04.04.2024 um/ab 18:30 Uhr.
    Ginnheimer Wirtshaus

    Am Ginnheimer Wäldchen 8, 60431 Frankfurt am Main

    Hallo an alle!

    Als Erinnerung:
    Das angedachte Treffen ist in 9 Tagen am
    Mi, den 04.04.2024 um/ab 18:30 Uhr
    und offiziell hat bisher nur zorro zugesagt.


    Ort:
    Ginnheimer Wirtshaus

    Am Ginnheimer Wäldchen 8, 60431 Frankfurt am Main

    Ich hoffe es melden sich noch weitere Teilnehmer/Interessenten bzw. entschließen sich spontan zum Treffen dazuzustoßen.
    Ich werde da sein; diesmal jedoch keinen Tisch reservieren.

    LG + bis dahin

    Ich schlage einfach mal gleich den ersten Donnerstag (4.4.24) vor.

    Bisher war das immer Freitags. Ich bin aber nicht daran gebunden. Nur Mittwochs geht bei mir gar nicht.

    Gut, Donnerstag würde bei mir auch funktionieren.
    Dann halten wir mal Do., den 04.04.2024 fest.

    knobby Ich hoffe bei Dir passt das auch.
    Ebster Evtl. könntest Du diesen Termin auch in die WA Gruppe posten.

    Vielleicht meldet sich ja noch jemand.
    ( finchy  centaur2 usw... Was ist mit euch? )

    Die Erinnerung an das Treffen werde ich diesmal spätestens eine Woche vorher schreiben.

    Hallo an alle!

    Ich möchte mal vorsichtig das nächste Treffen irgendwann zwischen Anfang bis Mitte April vorschlagen.
    Bitte macht eure Terminvorschläge, wir wählen dann den passendsten Tag aus.

    zorro

    knobby

    X-Raffi

    nichtschwimmer

    Beschreibung:
    Wir treffen uns zu einem geselligen Abend im Wirtshaus ohne Hardware und unterhalten uns über alles Rund um den C64 bzw. dem Retro-Computing als Thema.

    Hier ist nochmal der Ort:

    Ginnheimer Wirtshaus

    Am Ginnheimer Wäldchen 8, 60431 Frankfurt am Main
    Jeder ist willkommen!

    …schade das nicht alle da waren :!:


    Wir hatten trotzdem Spaß :thumbsup:

    Ja, das fand ich auch. Es war ein toller abend.

    Das nächste Treffen würde ich pers. schätzungsweise in ca. 6 bis 8 Wochen ansetzen bzw. planen.
    Gerne kann auch jemand anderes das Ruder übernehmen und einen Termin vorschlagen, falls es kurzfristiger sein soll.


    ich habe es leider zu spät gesehen, da war schon etwas Anderes geplant.


    Bis zum nächsten mal.

    Kein Problem. Beim nächsten mal bist Du dabei.

    (Soll heissen: Die Erinnerung würde ich dann zwei Tage vorher schreiben ;) )

    zorro

    knobby

    X-Raffi
    Ich werde morgen einen Tisch für Do., den 04.01.2024 für 4 Personen ab 18:30 Uhr reservieren, d.h. ich gehe davon aus, dass ihr dabei sein werdet. (Einwendungen könnt ihr noch bis morgen mittag absetzen.)
    Falls sich noch jemand an dem Abend zu uns gesellen möchte, ist er gerne willkommen.

    Vielen Dank für die ersten Rückmeldungen.

    Als Zeitraum für das Treffen scheint sich also das Ende der ersten Januarwoche für die meisten anzubieten, d.h. zwischen Do., den 04.01.2024 und So., den 07.01.2024.
    Auf den genauen Tag können wir uns ja noch einigen. Schreibt am besten, welcher Tag euch am besten passt bzw. welche Tage nicht in Frage kommen.
    Von der Uhrzeit her würde ich ab ca. 17:00 Uhr vorschlagen.

    Wir warten noch bis Ende der Woche, um zu sehen, ob sich weitere Interessenten melden und dann den Termin festmachen und einen Tisch reservieren.
    Ich hoffe die anderen melden sich noch.

    ------
    1ST1 Danke für die Info.
    Ebster Vielen Dank.
    Der Retroluzzer Ist aufgrund der Distanz verständlich.




    Hallo liebe Leute,

    evtl. könnten wir uns mal wieder zum "Frankfurter Nerd Stammtisch" im Ginnheimer Wirtshaus treffen.
    Wie sieht es aus? Besteht Interesse?
    Wer wäre dabei und wann würde es euch passen?

    Ich gebe mal nachfolgend alle Namen an, die irgendwie oder irgendwann einmal in diesem Thread erwähnt wurden.
    Falls Ihr nicht direkt zur Zielgruppe gehört, fühlt euch bitte nicht gestört, sondern einfach nur gegrüßt.

    finchy

    mrr19121970

    zorro

    Fulgore

    Ebster

    centaur2

    nichtschwimmer

    Masterhit

    X-Raffi

    cmc1976scs

    @Pentagon

    Ballblazer

    knobby

    ch1ller

    WTE

    Der Retroluzzer

    GuNKeN

    Hoeppie

    Retro Haudegen

    AntaBaka

    Dirk Vroomen

    Telespielator

    Green

    Örg

    1ST1

    nalkem

    daybyter

    Draco

    sewulba

    AREA51HD

    Bolzgramm

    Ein großes Lob und sehr viel Respekt wegen der ganzen Arbeit, die Du da reingesteckt hast! (Besonders, dass Du da dran geblieben bist, weil das Spiel ja extrem umfangreich ist.)


    ----
    Laut gedacht:

    Die Lösung zu den o.g. Bedienungs-Spaß-Hemmern könnte ein neuer Player für die D42 Daten sein, d.h.

    - einfacher Splitscreen und den Text und das Menü unten anzeigen.

    - Wenn der Cursor über den Rand der Bitmap wäre, würde er anzeigen, ob eine Bewegung in die Richtung möglich ist.
    (((- Über "M" rechts unten könnte man ins Menü gelangen. Oder man spart sich das auch ;) )))
    - Die Raumbeschreibung würde einfach in den Textzeilen angezeigt werden, d.h. simpler geht es nicht, weil sich das Layout nicht ändern würde.
    - Auf Animationseffekte beim Verlassen eines Raumes würde ich gänzlich verzichten.
    - Edit: auch kein Softscroll o.ä., sondern ein "weiter" oder "zurück" Button im Textbereich zur Anzeige des weiteren bzw. vorherigen Textes, der Einfachheit halber und damit der Spielfluß nicht gestört wird.
    (Mir fällt noch auf, dass ich 2 mal "Look at" dort stehen habe, d.h. sollte "Use" lauten.)

    Als Anregung der mögliche Bildschirmaufbau:


    Was wären momentan die "Schwierigkeiten"?
    - eigentlich nur das Entpacken der Daten und der Texte (beim Anzeigen: Zeilenumbruch etc....); der Rest ist einigermaßen einfach bzw. "geschenkt". (evtl. nochmal das Thema mit dem Fastloader.)
    (...)

    Danke für die Rückmeldungen.

    hab's bis "Level 2" geschafft. :)

    Ich selbst habe es bis zum dritten Level geschafft (siehe Screenshot). Theoretisch gibt es 8 Level.

    Ändert sich außer den Farben was in den "Leveln". Konnte nicht feststellen dass die Baddies z.B. aggressiver werden, die ja ohnehin schon sehr zahm sind. ;-)

    Das Verhalten ändert sich nicht. Die Gegner haben nur mehr Energie.
    (((Da man Schläge nicht blockieren kann und man deshalb länger beim Gegner stehen muss, ... wird das Spiel "schwieriger".)))

    Aber in den letzten 2 Beispielen finde ich nichts davon, sondern das wirkt halt einfach nur wie ein "Test", so nach dem Motto "ich hab mal ein Kung-Fu-Spiel angefangen aber hatte nach ein paar Stunden keine Lust mehr".


    Ich seh das wie ZeHa, dass es in dieser rudimentären Form eher den Charme einer Assemblerroutinendemo hat.


    Das Crap-Fu hat einen Reiz, nur wären so typische "Mindestanforderungen", wie eine Energieanzeige, eine Punkteanzeige und ein "Game Over" nicht verkehrt, damit man es als Game einstufen kann. :)

    Beides stimmt, d.h. zum einen wollte ich nicht zuviel Zeit reinstecken bzw. fehlte mir die Lust die Details auszuarbeiten/fertigzustellen oder insgesamt etwas zu "perfektionieren" bzw. zu tief in die Fehlerbehebung zu gehen.
    Auf der anderen Seite ist es interessant auszutesten, wieviel man von einer Spielidee weglassen bzw. abstrahieren kann, so dass nur der Kern oder auch einfach nur ein interaktives Konzept übrigbleibt.
    Ich bin mir sicher, dass der Craprunner mit anderen Grafiken, besserem Sound und einem Fix für den offensichtlichen Programmierfehler, besser angenommen werden würde.
    Zumindest Craptain Future hat's approved. ;)

    Eine Nachfolge-Version zu CrapFu mit den genannten Mindestanforderungen sollte machbar (=noch im Rahmen) sein.
    (((Auf der anderen Seite habe ich jedoch noch viele Ideen für weitere Crap- bzw. Minigames.)))
    Unterm Strich freut es mich ungemein, dass Ihr (z.T.) gefallen an den Spielchen/"Tests" findet.

    Retrofan

    Zumindest in Vice und in Kernal64 funktioniert das Streaming von Sound-Dateien (Raw 8-Bit unsigned bei ca. 11Khz klingt okay (Umwandlung mit Audactity)).
    Es gibt emulatorbedingte Speichergrößeneinschränkungen für die Dateien.

    Anbei die ASM-Testroutine, welche die zwei Basic Parameter "Url" und "TimerFreq" benötigt:
    TimerFreq = 985248.4 / Hz
    also bspw. 985248.4 / 11025 = 89 für ca. 11Khz




    Die Routine läuft zwar im Hintergrund (NMI). Ich habe sie jedoch nicht sauber verlassen, d.h. das Hauptprogramm läuft einfach in einer Endlosschleife (Sollte keine Basic Erweiterung o.ä. werden).
    Um die Soundqualität selbst habe ich mich auch nicht gekümmert.
    Zwar nutze ich die "Mahoney"-Methode (6581); jedoch hört man ein Rauschen oder "Störungen", welche ich nicht weiter verfolgt habe...
    sndstream.prg

    Interessant wäre es zu erfahren, ob das Testprogramm auf echter Hardware läuft.

    ---


    Alles, was man für ein Podcast-Programm jetzt noch brauchen würde ist, einwenig Webspeicher für die .raw-Dateien und evtl. eine Playlist als .txt.
    (((Zum Träumen: schön wäre es, wenn man archive.org anzapfen könnte; ich habe einige Samples gefunden, die sich direkt abspielen lassen; Falls man on-the-fly WAV umwandeln bzw. "brauchbar" auslesen könnte, hätte man damit gewonnen...)))




    pottendo

    Die beiden Testprogramme funktionieren jetzt.
    Vielen lieben Dank für die schnelle Umsetzung und dafür, dass das WiC64 überhaupt in Vice emuliert wird!

    Ich denke, dass die Größe in Zukunft noch heraufgesetzt werden müsste/sollte; im besten Fall natürlich variabel.
    (((Vorerst genügt es jedoch, wenn die Stelle an der die Änderung stattfinden müsste, klar ist.)))

    ----
    Courage

    Folgende Punkte bitte nur als Vorschläge/Anregungen verstehen, falls Du/ihr sie nicht bereits berücksichtigt habt.

    Aus meiner Sicht wird folgendes benötigt:
    1.) Eine Art von "Seek" oder "Offset", d.h. eine Anzahl von Bytes, die bei einem Abruf übersprungen werden. Momentan würde das in einer Schleife geschehen, welche einfach Dummy-Reads durchführt, bis der richtige Offset erreicht ist.
    2.) Die Rückgabe/Berücksichtigung von mehr als 16-Bit bei den Dateilängenangaben oder -positionen.
    3.) Falls es nützlich oder technisch notwendig/sinnvoll ist, eine Art close- oder reset-Befehl, um ein erneutes Einlesen der gleichen oder nächsten Datei "schneller" durchführen zu können.

    (Genauso könnte man vielleicht, auch im Hinblick auf die Emulatoren, über einen optionalen Parameter nachdenken, der diesen "reset" oder "close", nach einer bestimmten Anzahl an gelesenen Bytes, automatich durchführt.)


    ----

    pottendo

    Courage

    Zwei mögliche Anwendungsfälle, die mir in den Sinn kommen, wären:

    - Ein Web-Browser, d.h. hier könnte man größere Seiten (>64KB) stückweise nachladen und wäre nicht auf eine Speichererweiterung o.ä. angewiesen bzw. man könnte mit weniger C64-Speicher für das "Vorhalten" der Seite auskommen.
    Erklärung: Hier würde eine .html-Datei je nach Scrollposition mehrfach geöffnet und nur z.T., bspw. für eine "Bildschirmgröße" lang, ausgelesen werden.

    Bsp.: Die Seite "https://de.wikipedia.org/wiki/Commodore_64" ist größer als 350KB.


    - Video-Streaming: Ein Video, welches aus einer einzigen großen Datei besteht, könnte frameweise in den Speicher abgerufen werden., d.h. der Vorgang entspricht eigentlich einem langsamen Download.
    Erklärung: Hier wird eine Datei einmal geöffnet und langsam eingelesen. Der Vorteil wäre, dass man kein extra .php-Skript o.ä. für die Stückelung der Datei benötigen würde.

    (...)


    (((Zur Info: Ich programmiere und nutze nur den Emulator und keine echte Hardware, d.h. crossdevelop..)))

    Ich hoffe ich bin hier richtig. Ich erhalte einen Fehler.

    Über das Kommando $01 rufe ich eine Url auf und fülle den Bildschirm in einer Schleife (Joystick Port2 Änderung zum Fortschalten).

    Im Kernel64 funktioniert es.
    VICE stürzt bei mir ab und zwar, wenn eine große html-Datei (>64KB ?) angefordert wird.


    Anbei der Test, der sich nur in der Url unterscheidet:
    testOkay.prg
    testNotOkay.prg

    Code: Log von testOkay.prg mit kleiner Seite
    1. do_command_01:
    2. 0000: 68 74 74 70 73 3a 2f 2f 77 77 77 2e 63 36 34 2d |https://www.c64-|
    3. 0010: 77 69 6b 69 2e 64 65 2f 77 69 6b 69 2f 57 69 43 |wiki.de/wiki/WiC|
    4. 0020: 36 34 |64 |
    5. do_http_get: URL = 'https://www.c64-wiki.de/wiki/WiC64'
    6. http_get_alarm_handler: got 24169 bytes, URL: '', http code = 200
    7. send_binary_reply: sending


    Handelt es sich dabei um einen dummen Benutzer- oder Konfigurationsfehler oder lässt sich da tats. etwas verbessern?


    -----

    (((
    Folgend eigentlich allg. Fragen zum WiC64, d.h. eher nachrangig:
    - Welche Größe können Dateien max. haben?
    - Würde sich ein Streaming umsetzen lassen, indem man eine große Datei öffnet und immer ein Stück nachlädt oder gibt es Restriktionen (Dateigröße/Timeout)?
    - Edit: Die Dateigröße hat ja nur 2 Byte Platz, heisst das, dass diese Information bei großen Dateien dann inkorrekt ist oder nicht zurückgegeben wird?

    )))

    Vielen Dank!

    Noch als Zusatz für oben:

    (...)