Posts by alx

Es gibt ein neues Release: https://github.com/alexkazik/t…-browser/releases/tag/1.4

Neu:
- Fix, Einträge 107-126 konnten nicht geladen werden
- Es können Trenner angezeigt werden (Typ: 240 bzw. 0xf0)

Ich werde die gefixite (einträge ab 106 lassen sich z.Z. nicht starten) und verbesserte (trenner) version die nächsten tage veröffentlichen.

ich weiss auch nicht mehr was das war, aber nun klappts.
hier die von mir im tapecart-browser genutzten tapecart funktionen: tapecart.asm

Die Idee war es, EIN (bis zu 2MB großes) Programm darauf abzulegen.
Auf Wunsch habe ich ein Menü gebaut mit dem man kleinere onefiler laden kann.

Ich fände F5/F7 praktischer, zwei verschiedene tasten, statt das doofe shift... oder meintest du nicht f6?

Korrekt, eine Einschränkung der aktuellen Version ist dass nur Programme mit Lade-Adresse 0x0801 gestartet werden können.
Wollte ich immer mal behoben haben, aber noch nicht dazu gekommen.

Dabei.

(Die Nachricht ist zu kurz. Der Text muss mindestens 2 Wörter enthalten.)

Und war mir wieder einfiel: auf der Fujiama 2017 gab es einem C64 der von einem Raspi zero mit grafik versorgt wird, ähnliche taktik wie meine aber das Programm läuft komplett auf dem raspi und der C64 macht nix.

Quote from M. J.

Verzeih bitte die Frage: Die GPU arbeitet aus Farbgründen ja mit Multicolourbitmap-Daten. Was passiert, wenn z. B. beim Scrollen die Vordergrundgraphik die Hintergrundgraphik in einem 4x8-Farbblock überlagert? Führt das dann zu Colourclashes oder gibt es Einschränkungen in der Farbwahl oder versucht die GPU die Bilddaten so aufzubereiten, daß Farbunterschiede möglichst nicht sichtbar sind?

Es gibt drei ebenen: Vordergrund (ringe), Haupt-Screen (level), Hintergrund (blau).
Das char-raster ist an den Haupt-Screen gebunden.
Wenn der Vordergrund unpassend verschoben ist passieren artefakte wie z.B. die weissen pixel um die Ringe.
In einer anderen Version (finde das Video aber nicht) ist der platz der blau um die ringe herum ist grösser und es gibt keine clashes.
Die vordergrund (colorram) und hintergrund farben sind überall gleich, nur die zwei farben vom screen werden geutzt.

Quote from LogicDeLuxe

Würde man im oberen und unteren Rahmen noch per DMA $d021 beschreiben, könnte man sogar etwas Farbe hinbekommen.Auch eine Display-List, wie bei Atari und Amiga könnte man per DMA erzeugen, also vorprogrammiertes Beschreiben von VIC-Registern, die dann zyklusgenau (soweit der VIC sie zur Verfügung stellt) ausgeführt werden. Dann währen z.B. CPU-schonende FLI-Modi machbar.
Und wo die Grafik schon von extern kommt, da würde allein ein Chunky-Mode die Software schon stark vereinfachen. Auch virtuelle Screens wären sicher hilfreich, um die CPU zu entlasten.

Dafür benötigt man DMA, damit die GPU auf den C64 zugreifen kann - das kann das kleine ding was ich da habe nicht (zumindest nicht gleichzeitig).

Pro Char auf dem Bildschirm sind (wahlweise) 1 oder 2 byte um den char auszuwählen, der hat 8 oder 10 bit (also 256 oder 1024 chars).
Die (zwei) Farben werden nicht pro bild-position sondern pro char vergeben. Damit kann man zwar nicht das selbe char in verschiedenen farben nutzen aber es ist viel einfacher das bild zu verwalten.

Quote from ogd

Gibt es Screenshots oder Renderings davon?

Anbei die Bilder der Hardware und ein Video von meinem (einzigen) Beispiel Programm.

Rechts oben das gelbe Gedöns ist ein Sprite, alles andere ist Muticolor Bitmap, bestehend aus einem Hintergrund (in diesem Demo ungenutzt) einem 128*64 char grossen Screen und einem (full-screen-grossen) overlay (text oben und die drei ringe).

Quote from ogd

Wie kommuniziert dein Coprozesser mit der 6510-CPU?

Gar nicht.
Die CPU kann per IO1/IO2 Register/Speicher im CoPro setzen.
Bei jedem VIC zugriff wird die /EXROM Leitung auf Masse gezogen, die Adress-Leitung auf 0x7fff und die Daten-Leitung auf das gewünschte gesetzt - und das alles zu je genau dem richtigen Zeitpunkt.

Ich hatte mal angefangen einen VIC Coprozessor zu entwickeln:
- Steckt am Modulport
- Berechnet drei übereinander gelegte Bilder zu einem
- Wenn der VIC grafiken laden will wird ihm der Speicher "Weggenommen" und die berechneten Daten direkt auf den Bus gelegt

Mit anderen Worten: die Grafik wird vorberechnet und der VIC gibt sie aus (mit allen üblichen einschränkungen).

Dies ging gerade so mit einem PSoC5 (80Mhz ARM mit kleinem CPLD in einem Chip).
Dabei ist der CPLD-Teil zu klein und der zugriff auf das RAM vom CPLD aus zu langsam.

Aber mit z.B. einem raspberry pi zero und einem grösseren cpld oder kleinen fpga sollte nicht nur das sondern auch 3d möglich sein.

Ich hätte gerne den FTP-"Kernal" auf meinem WLAN-Modul für den Super-Kernal.
Kann jemand mein Modul Programmieren?

Quote from Yan_B

@alx wieder mit Hardware, nehme ich mal an, oder? Habe ich einfach mal so aufgenommen.

Passt, danke.

dabei.

(Die Nachricht ist zu kurz. Der Text muss mindestens 2 Wörter enthalten.)

Oder schau dir den EasyProg source an.

Moin, sorry dass es so lange gedauert hat, aber nun gibt es eine neue version des Browsers.
Jokers Aufgaben 2 und 3 sind erledigt, der Trennstrich noch nicht.

Ich habe die Software erweitert so dass nun wenn man die Restore-Taste länger drückt ein zweiter Reset ausgelöst wird. Ist z.B. mit dem SuperKernal praktisch.
https://github.com/alexkazik/restore-reset

Quote from Der Retroluzzer

Was ist denn der Sinn eines SCPU-Emulators, wenn ich nicht mal ein Programm laden und starten kann?

Ich kompiliere das weil ich den x64 benutzen möchte - alles andere wird automatisch mit kompiliert. Hab spass damit oder lasse es.

Quote from Der Retroluzzer

Das ist ja kacke. Wieso wird das dann überhaupt mir released wenn es nicht funktioniert?

Weil es andere sachen kann... Auf meiner Seite ist nun auch eine SDL-Version für ältere Rechner.