Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Ju-Te-6K vs. KCcompact » Themenansicht

Autor

Thread - Seiten: -1-

000
17.11.2024, 18:22 Uhr
HeikoS

Liebe Forum-Mitglieder, JuTe-, EMR- und KC-Freunde,

beim Stöbern im Netz ist mir dieses Video von "Feldi/eudatux23" begegnet. Das "Intro" ist wirklich sehr bemerkenswert. Zu meiner Schande muss ich gestehen, dass mir der KCcompact um 1989/90 vollkommen unbekannt war, genau wie der JuTe 6K. Beim VCFB 2023 hatte Rene Meyer einen Vortrag zum KCcompact gehalten und man konnte ihn da auch anschauen und ausprobieren. Das fand ich sehr interessant und die technischen Parameter haben mich auch gleich an den JuTe-6K denken lassen.

KCcompact: CPU mit 4 MHz, 320 x 200 Pixel, 4 Farben (27 Farben ?) (Modus 2)

JuTe 6K: CPU mit 4 MHz, 320 x 192 Pixel, 16 Farben/Pixel

Aber der KCcompact hat einen Grafik-Controller CM 607 (Bulgarian clone of 6845), https://www.cpcwiki.eu/imgs/c/c0/Hd6845.hitachi.pdf . Das Demo-Programm stammt wohl schon aus der Zeit 1989/90. Ob man das trotzdem auch auf dem JuTe-6K hinbekommen könnte?

Meinen Versuch könnt ihr hier anschauen:

https://nextcloud-ext.peppermint.de/s/jTaJbMyDS46GqiY

Hier ist auch die Doku dazu und dort kann man auch die BIN/WAV-Dateien laden.

https://github.com/haykonus/JU-TE-6K-Demos/tree/main#kccompact-demo-f%C3%BCr-jute-6k

Das Programm läuft auf dem JuTe-6K und im JTCEMU. Ohne Bildschirmentstörung läuft es auf der JuTe-Hardware bestimmt mit Störungen, aber das habe ich noch gar nicht ausprobiert ohne die Entstörung. Da noch zwei Zeichensätze (Z9001, KCcompact) in der BIN-Datei integriert sind, ist das Programm leider noch einmal 4K länger geworden. Danke an "robbi" und "ThomasR" für die Tipps zum Zeichensatz des KCcompact.

Am Anfang hatte ich nur das Video von "Feldi". Nach einiger Zeit ist mir ein komischer Effekt aufgefallen. Die animierten Linien ragen in dem Video rechts und links über den Bereich von 320 Pixeln heraus.

Ich dachte schon, ich kann die Pixel nicht mehr richtig zählen. Deswegen habe ich das KCC-Demo-Programm mal auf dem JKCEMU laufen lassen – die KCC-Programme gibt es ja auch bei "robbi" auf seiner Seite. Da passiert das nicht, aber dafür flackert der Border-Bereich anständig … "Feldi" hatte ja in seinem Video auch geschrieben, dass das Demo-Programm auf einem emulierten Amstrad CPC 464 lief bei ihm.

Deswegen hätte ich folgende Fragen in die Runde:

- Kann jemand ein Video von der KCC-Demo auf dem originalen KCcompact zur Verfügung stellen ?

- Gibt es evtl. sogar noch den Quell-Text zu dem Demo-Programm ?

- Wie werden solche Effekte in der Demo-Szene realisiert? Da kann man doch bestimmt Eigenschaften des Video-Controllers ausnutzen ?

- Im Modus 320x200 hat der KCcompact nach Spezifikation 4 Farben zur Verfügung. Die animierten Linien sind aber mit mehr als 16 dargestellt. Wie geht das ?

Und evtl. gibt es ja hier auch einen Mathematiker, der die Funktion, welche den zeitlichen Verlauf der animierten Linien auf der Z-Achse darstellt, so beschreiben kann, wie sie im Original-Demo-Programm verwendet wird. Das habe ich nur zu 70% hinbekommen (ist auf dem Github beschrieben), da fehlt noch eine Sprungstelle nachdem die Linien unter der fetten Schrift angekommen sind. Das kann man gut sehen, wenn man beide Versionen vergleicht.

Viel Spaß beim Ausprobieren, ob im JTCEMU oder im Original-JuTe-6K.

Viele Grüße, Heiko

Dieser Beitrag wurde am 18.11.2024 um 11:11 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
17.11.2024, 19:48 Uhr
Dresdenboy

Hallo Heiko,

das ist ja mal ein Thema für mich.

Zwar habe ich den KCC hier noch nicht aufgebaut, aber zu einigen Fragen kann ich durchaus schon etwas sagen, da sie v.a. eher generischer Natur sind (Bildaufbau in den meisten älteren Computern für CRTs und damit verbundene Demoeffekte).

Zu den Linien: Wie auch im Videotext erwähnt, sind das Rasterbars, gut bekannt von C64 usw. Dabei werden ganz allgemein gesagt Palettenfarben zeilenweise neu zugeordnet. Meist werden z.B. die Hintergrundfarbe, die Randfarbe oder beide geändert, wobei dafür z.B. nur ein Palettenindex in ein Register geschrieben werden muss. Damit reichen Rasterbars auch über die Fläche mit aktiv dargestellten Pixeln hinaus. Die Verzerrungen darin deuten auf ein ungenaues Timing hin, wonach der Anfang der Zeile nicht gut getroffen wird und die Farbänderung dann im sichtbaren Bereich erkennbar wird und sich auch nicht stabil verhält. Das gut und sauber hinzubekommen ist eine Kunst. Mehr Farben sind dann natürlich einfach, da man ja ständig neue Farben aus der gesamten Palette auswählen kann. Auf mancher Hardware sind sie leichter dank entspr. Unterstützung/Signale umzusetzen, z.B. dank Wert der akt. Zeile in einem Register, ein Rasterinterrupt (Hauptschwierigkeit: Aufruf innerhalb unterschiedlich lang ausgeführter Befehle), Copper u.ä. Chips, Bit in einem Register, welches den Horizontal Retrace/Blank anzeigt. Letzteres geht auch auf EGA und VGA oder sogar dem NEC µPD7220. Für VGA unter DOS habe ich das mal in einem 31 Byte Intro genutzt: https://www.youtube.com/watch?v=qHvDrGMzdyA

Mit Quelltext kann ich nicht dienen, aber ggf. mal danach suchen. Jedenfalls wird hier Maschinencode eine Rolle spielen. Die spannenden Teile (z.B. für die Rasterbars) kann man ggf. in einem Emulator mit Debugger identifizieren.

Für den Rest der Demo wurde von der Geschwindigkeit her wohl viel BASIC verwendet. Teils wird noch mit der Bildstartadresse gespielt, um das Bild hoch/runter zu bewegen. Der Tunnel funktioniert vmtl. mit Palettenrotation. Da werden also Strukturen gezeichnet (ungünstig von vorn nach hinten, besser wäre von hinten nach vorn wg. Verdeckung) und dann wird die rote Farbe durch die verwendeten 16 Farben rotiert.

Bzgl. Funktion der Rasterbar-Bewegung: Für eine Analyse der Scrollbewegung (mit Gummiband-Effekt) von Handytests auf YT hatte ich mal ein Python-Script geschrieben, was das Video (heruntergeladen bzw. per Screengrabbing aufgezeichnet) in Einzelbildern analysiert und eine bestimmte Spalte aus den Bildern herausliest und diese Spalten aufeinanderfolgender Bilder in X-Richtung nebeneinander legt. Dann könnte man schon mehr erkennen. Eine Vorfilterung nach der lilanen Linie wäre denkbar. Im nächsten Schritt könnte man auch eine approximative Suche nach der Funktion ausprobieren.

P.S.: Du nutzt ja auch Geogebra. Das fand ich mal spannend und nutzte/zeigte es auf Arbeit. Seitdem hat es sich da intern ein unter ein paar Leuten verbreitet. Obwohl wir nie geschafft hatten, über unsere Rechtsabteilung die Lizenzierung umzusetzen (das wären nur 75€ gewesen, aber frag nicht.

).

P.P.S.: Ich fand letztens zufällig eine Seite, die ein paar einfache Demoeffekte, oft sogar in BASIC umgesetzt, erklärt: http://www.petesqbsite.com/sections/tutorials/graphics.shtml
In der Vergangenheit gab es dieses Wissen meistens über Diskmags. Aber da müssten auch noch Texte existieren. Warte... ich weiß. Bei Hugi gab es viel, was jetzt auch noch online leicht abrufbar ist: https://www.hugi.scene.org/online/ für die gesamten Diskmags sowie https://www.hugi.scene.org/online/coding/hugi%20se%204%20-%20index%20sorted%20by%20topic.htm für die Coding-Artikel.

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Dieser Beitrag wurde am 17.11.2024 um 20:03 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
17.11.2024, 21:28 Uhr
HeikoS

Hallo Matthias,

wow, danke für die sehr ausführliche Antwort!

Dann sind das in der KCC-Demo also nicht ganz zeitgenau programmierte "Rasterbars". Obwohl, wenn Feldi das auf einem emulierten Amstrad CPC 464 gestartet hat, ist das Timing evtl. etwas schlechter als auf einem original KCcompact. Wäre schon gut, das mal zu vergleichen. Ich werde es nochmal im JKCEMU anschauen. Dass das überhaupt geht im JKCEMU, ist schon eine Leistung. Und dann ist ja auch schon die Überlänge der Linien geklärt. Super! Das hatte mich am meisten verwirrt.

Deine Idee, die Rasterbar-Bewegungen per Python-Script zu "grabben" ist sehr cool. Ich habe das mal grob mit Papier und Bleistift "von Hand" gemacht, habe auch eine Kurve, aber das Modellieren einer Funktion für diese Kurve ist mir nur halb gelungen. Wie könnte man eine approximative Suche nach der Funktion ausprobieren? Ein wenig haben mir die Kenntnisse aus dem Studium zur Systemtheorie und Fourier-Analyse geholfen. Frequenzen überlagern und dann das Resultat prüfen. Das ging mit Geogebra sehr gut. Das Programm habe ich vor ein paar Tagen gegoogelt. Die kostenlose Version reicht für diese einfachen Dinge. Ist ein sehr schönes Werkzeug.

Danke auch für die Links zu den Demo-Effekten. Bisher habe ich mich in trüben Stunden einfach hingesetzt und überlegt, wie man sowas machen könnte … das Wetter ist ja trüb genug zur Zeit.

Viele Grüße, Heiko

Dieser Beitrag wurde am 18.11.2024 um 11:12 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
17.11.2024, 21:30 Uhr
Dresdenboy

Kleine Ergänzung (lieber als neue Antwort wg. Übersichtlichkeit):
Zwischen CPC und KCC gab es m.W. Unterschiede bei einem Interrupt, welcher sich auf den Bildaufbau bezieht. Aber auch so ist das Thema auch je nach Emulator mehr oder weniger genau umgesetzt. Idealerweise läuft es auf einem zyklusgenauen Emulator (so wirkt es auch schon im Video mit Farbwechseln innerhalb der Zeile) oder wenigstens mit zeilenweisen Bildupdates. Aber am Besten ist natürlich immer die richtige Hardware.
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
17.11.2024, 22:07 Uhr
HeikoS

Zitat:

Dresdenboy schrieb
Kleine Ergänzung (lieber als neue Antwort wg. Übersichtlichkeit):
Zwischen CPC und KCC gab es m.W. Unterschiede bei einem Interrupt, welcher sich auf den Bildaufbau bezieht. Aber auch so ist das Thema auch je nach Emulator mehr oder weniger genau umgesetzt. Idealerweise läuft es auf einem zyklusgenauen Emulator (so wirkt es auch schon im Video mit Farbwechseln innerhalb der Zeile) oder wenigstens mit zeilenweisen Bildupdates. Aber am Besten ist natürlich immer die richtige Hardware.

Das war ja Gedankenübertragung ... Ich habe das im JKCEMU mal genauer angeschaut. Da sehen die Linien sehr sauber aus, nur dass sie eben nicht in den Border-Bereich gehen und der Border-Bereich in verschiedenen Farben flackert ...

Na ja, der gute JuTe-6K kann das ja eh alles nicht, da musste ich eben die Bit's möglichst schnell durch die Gegend "schaufeln" ... Ist aber ein sehr interessantes Thema.

Viele Grüße, Heiko

Dieser Beitrag wurde am 17.11.2024 um 22:08 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
18.11.2024, 08:21 Uhr
Dresdenboy

Ja, Timing ist alles (in doppeltem Sinnne

).

Klar, bei Demoeffekten ist es auch ein Ziel, mit den vorhandenen Mitteln und Tricks möglichst eindrucksvolle Dinge auf den Bildschirm zu zaubern. Das kann dann auch etwas sein, wo Bild-/Textmodi auf alternative Weisen genutzt werden.

Beim BIC z.B. der schnelle Textmodus, wo direkt Zeichen und Attribute oder gar nur Attribute angepasst werden müssen. Dann gehen da auch noch 80 Zeichen (oder ggf. auch mehr mit etwas Umprogrammirung) und mehr als 25 Zeilen (z.B. auch durch halbhohe Zeichen dann 50 Zeilen) -> Zack, ein schneller (also leicht u. schnell schreibbarer), sehr bunter Klötzchengrafikmodus für Effekte in z.B. 80x50.

Viele C64-Tricks nutzen ja z.B. das interne Timing des VIC IIs aus, schalten in bestimmten Zyklen Modi um oder hin und her und schon wird eine 8 Pixel hohe Text-Zeile zu einer 1 Pixel hohen, oder der Rand geht oben und unten oder mit sehr genauem Timing auch links und rechts auf für Sprites und sogar ein Hintergrundmuster-Zeichen.

Da habe ich aber keine Ahnung, ob es entspr. (auch einfache) Möglichkeiten beim Ju-Te-6K gäbe.

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
18.11.2024, 11:10 Uhr
HeikoS

Hallo Matthias,

die Demo-Szene ist ja eine eigene Welt für sich. Danke für die sehr interessanten Einblicke ! Dass bei den Linien in der KCC-Demo Tricks angewendet werden, hatte ich schon vermutet, da ja allein die Anzahl der Farben der Linien nicht zum Grafik-Modus passt. Da im Video von „Feldi“ die Linien aber so zerstückelt aussehen (wie 2 Byte lange Streifen), dachte ich zuerst, dass das evtl. im 160x200 Pixel-Mode gemacht wird und zwar mit schnellen Byte-Transfer-Methoden. Da kam mir dann die Idee, das auch mit dem JuTe-6K zu versuchen. Evtl. kommen ja die „zerstückelten“ Linien auch von der Video-Aufzeichnung … ? Aber Rasterbars sind sicher die wahrscheinlichste Methode.

Der JuTe-6K kann definitiv keine anderen Methoden, als Video-RAM-Schreiben. Der zweite Prozessor im Grafikteil ersetzt eigentlich nur Zählerketten, die man auch konventionell hätte realisieren können. Die ROM-Adressen der Grafik-CPU sind auch nicht beschreibbar, selbst wenn man da einen RAM einbauen würde. Das wäre aber eine interessante Erweiterung … aber das hätte dann gar nichts mehr mit dem Original zu tun und wäre nicht mehr „Retro-Computing“.

Wenn man bedenkt, dass die JuTe-Demo nur mit Byte-Schreiben in den Video-RAM auskommt (und auch noch den Hintergrund der Logos und der großen Schrift ausblenden muss), ist das Ergebnis aber noch recht gut. Hier kann man natürlich die Austastlücke nicht mehr benutzen, um Störungen im Bild zu vermeiden, da reicht die Zeit einfach nicht. Die Anzahl der Zeilen pro Linie ist auch nicht 5 sondern nur 4, damit das gerade noch geht.

Den Tunnel-Effekt beim Schreiben der roten Schrift von links nach rechts habe ich gar nicht bewusst umgesetzt. Dafür aber neue Character-Print-Routinen gebaut, die auch universell in BASIC-Programmen verwendet werden könnten. Sie sind in FGL.asm (Fast Graphic Library) zu finden:

FGL_CHAROUT
FGL_PRISTRI

Denen kann man eine Reihe von Parametern mitgeben, u.a. einen Zoom-Faktor und Verzögerungen:

Quellcode:


;------------------------------------------------------------------------------
; FGL_PRISTRI: Gibt eine Zeichenkette mit FGL_CHAROUT aus.
;
; in:   var_T           = Zeiger auf Zeichensatz        
;       var_U           = Warten nach einer Zeichenzeile (ms)
;       var_V           = Warten nach einem Zeichen (ms)
;       var_W_lo        = Farbe         (VVVVHHHHb  V=Vordergrund, H=Hintergrund)
;       var_X_lo        = x-Byte        (0-39)
;       var_Y_lo        = y-Zeile       (0-191)
;       var_Z_lo        = ASCII         (wird automatisch gelesen 
;                                        aus String nach Funktionsaufruf)
;       var_Z_hi        = N             (Zoom-Faktor)
;
; out:  Zeichenkette auf dem Bildschirm
;------------------------------------------------------------------------------

Interessant wäre für mich noch ein Video der KCC-Demo auf echter KCcompact-Hardware und die Methode zur Approximation einer Funktion auf Basis einer vorhandenen Kurve. Geht das auch mit GeoGebra?

Wie es bei anderen JuTe-6K-Nutzern läuft (oder auch nicht …) wäre auch sehr interessant.

Viele Grüße, Heiko

Dieser Beitrag wurde am 18.11.2024 um 18:20 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
18.11.2024, 13:49 Uhr
Dresdenboy

In der Tat ist das eine Welt für sich, welche aber auch mit anderen kreativen oder nischigen Bereichen überlappt, z.B. Codeoptimierung, Spiele, Echtzeitgrafikeffekte für Medien oder Liveperformances, Sound/Musik, usw. Ein Democoder, welcher in der Gruppe "Farbrausch" (teils aus der Amiga-Szene stammend) ein sehr gutes Kompressions-Tool für x86-Exe-Dateien (kkrunchy) entwickelte, arbeitet nun an Kompressionstools für die Spieleindustrie. Ein Kompressions-Verfahren des kleinen Unternehmens wurde sogar in Hardware für die Playstation 5 implementiert.

Mit Video-RAM-Schreiben sollte natürlich auch etwas gehen. Optimieren kann man überall. Angesichts des verfügbaren RAMs kommt aber Loop Unrolling (bzw. "Speedcode") kaum in Frage. Ich habe noch nicht geschaut, wie du es gemacht hast, daher einfach mal laut gedacht: Bei dem Logo würde ich intuitiv Bereiche suchen, wo ich z.B. einfach nur Hintergrund, Vordergrund (falls verändert) oder aber mit Maske schreiben muss. Entweder zeilenweise oder besser Blockweise (z.B. mit Startadresse, Breite (in Bytes -> Loop-Iteration) und Höhe). Und da gingen auch noch Varianten, die je Zeile nur ein bis ein paar Byte schreiben ohne Innenschleife.

Diese Analyse der Bewegung kann Geogebra vermutlich nicht. Das Verfahren könnte man auch unter "Curve fitting" finden. Dafür gibt es bestimmt auch mindestens eine Python-Lib. Kommt man da nicht eher über einen Emulator und Debugger an die Berechnung oder Look Up Table?

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Dieser Beitrag wurde am 18.11.2024 um 13:50 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
18.11.2024, 18:16 Uhr
HeikoS

Das Optimieren von Code macht auch richtig Spaß ! Assembler programmiere ich ja schon sehr lange, eigentlich seit 1985. Aber Z8-Assembler erst seit ca. 2 Jahren. Das ist ein sehr schöner Prozessor, die Register sind sehr universell einsetzbar. Ohne das jetzt „Loop Unrolling“ zu nennen, sind glaube ich alle diese Tricks schon im Programm angewendet. Im Github ist das ja auch ganz kurz erläutert. Das hatte ich ja auch schon bei der Sprite-Bibliothek FCSL alles optimieren müssen, dort musste alles in 8ms (blanking phase) passieren, damit die Sprites flüssig „laufen“. Kann man alles im Github nachlesen, auch die Quelle, die als Anregung diente (ein ZX-Spectrum-Code).

Den JuTe-6K kann man sich als einen ZX-Spectrum vorstellen, nur dass es nicht nur einen Pixel-VRAM gibt, sondern 4 x 8 KB, jeweils einen für R,G,B,H - an der gleichen Stelle (4000-5FFFH) im Hauptspeicher eingeblendet. Die Auflösung ist 320x192, beim Speccy 256x192. Ein Farb-Attribut-Speicher oder einen Text-Mode gibt es nicht. Das ist eine sehr ungünstige Konstellation für schnelle, farbige Grafik. Aber das ist ja gerade die Herausforderung, die Spaß macht …

An allen kritischen Stellen in der Demo sind die Loops aufgelöst durch Code-Wiederholung mit dem REPT-Macro des Arnold Assemblers. Für die Objekte, die nicht überschrieben werden dürfen, ist ein Shaddow-VRAM angelegt um sehr schnell die Maske für den Schreibvorgang zu lesen. Zum Schreiben des VRAM’s wird PUSH verwendet, das ist die schnellste Methode beim Z8. Auch das Banner muss ja noch “geschoben“ werden. Da wird aus dem Text eine Struktur gebaut, die dann sehr schnell in den VRAM geladen werden kann für den Banner-Effekt. Aber man könnte ja mal gemeinsam das ganz genau anschauen und noch optimieren. Vielleicht geht da noch was. Wäre interessant.

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
18.11.2024, 18:35 Uhr
PC-Opa

Hallo Heiko,
deine Demo läuft auf meinem JU+TE Tiny 6k super.
Das hast du schön hinbekommen.

--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
18.11.2024, 21:02 Uhr
HeikoS

Hallo Wolfgang,

danke, das freut mich ! Da müssen wir uns nicht verstecken mit dem JuTe-6K. Der KCcompact ist sicher nicht schlecht, aber dafür war er auch vieeeel teurer ;-)

Grüße, Heiko

EDIT: So teuer sollte der KCcompact garnicht werden. Als Preis waren wohl 2.300 M vorgesehen lt. Rene Meyer. Wenn man das mit dem BIC vergleicht, recht günstig.

Dieser Beitrag wurde am 19.11.2024 um 10:29 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
18.11.2024, 21:59 Uhr
HeikoS

"Kampf der Emulatoren" JKCEMO vs. JTCEMU

https://nextcloud-ext.peppermint.de/s/JMEGcj5gmoQiQ7i

Der JKCEMU kann die Rasterbars nicht ganz synchron darstellen, auch mit 10 ms Aktualisierung nicht. Aber man sieht die hohe Geschwindkeit. Der JuTe-6k im JTCEMU schlägt sich aber wacker, wenn man bedenkt, dass er alle Bits im VRAM hin- und herschaufeln muss und keine Tricks anwenden kann ...

Grüße, Heiko

Dieser Beitrag wurde am 19.11.2024 um 07:45 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
19.11.2024, 09:22 Uhr
Dresdenboy

@Heiko

das wäre ja mal auch etwas für den BIC.

Bzgl. Optimierung: Da hast du ja offenbar schon viel herausgeholt. Durch die KCC-Vorlage bist du da auch gebunden. Aber klar, nochmal nach weiteren Optimierungen schauen hilft fast immer. Lass mal schauen, wie wir das zusammen anstellen können. Das meist noch etwas geht, kenne ich etwas ähnlich vom Sizecoding (meist 256 Byte oder ähnlich kleine Zweierpotenzen). Dann sind es aber oft nur einzelne Bytes.

Ohne Bedingungen kann man natürlich schauen, was die Stärken der Hardware sind. Z.B. wenn ich von einzelnen Farb-Bit-Speicherebenen höre, fallen mir sofort die Möglichkeiten der Bitplane-basierten Effekte auf Amiga oder Atari ST ein, wie ein geometrisches 2D oder 3D-Objekt (z.B. auch nur Linien), welches in jedem Frame in eine andere Bitplane gezeichnet wird. Zwar kann man hier nun keine einander ähnlichen Palettenfarben für die Bits nutzen, aber so etwas wie Farbmischeffekte wären möglich. Z.B. bei nicht so schnell veränderten Flächen (z.B. ein sich langsam drehendes gefülltes Dreieck).

Bzgl. Rasterinterrupts fand ich gerade das hier, wo auch der KCC erwähnt wird: https://cpctech.cpc-live.com/docs/ints.html

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Dieser Beitrag wurde am 19.11.2024 um 09:29 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
19.11.2024, 10:54 Uhr
HeikoS

Hallo Matthias,

ja, mach doch sowas mal für den BIC. Dann lassen wir sie alle gegeneinander antreten ;-)

Das Angebot zu Optimierung nehme ich gerne an. Ich hätte auch noch eine Idee für eine Portierung auf den JuTe 6K, das hier: https://zxart.ee/eng/software/demoscene/intro/256b-intro/gleest/

Ich hatte schon mal Kontakt zu "gasman", weil das in seiner Live-Coding-Umgebung ( https://bazematic.demozoo.org ) nicht lief. Hat er promt behoben. https://ioc.exchange/@haykonus Du hast natürlich vielmehr Erfahrung. Ich habe bisher kaum was in der Demo-Scene verfolgt. Wäre spannend. Ich muss aber erst wieder ein wenig Zeit dafür finden.

Viele Grüße, Heiko

Dieser Beitrag wurde am 19.11.2024 um 10:57 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
19.11.2024, 11:36 Uhr
Dresdenboy

Cool. Gasman traf ich 2023 auf der Deadline in Berlin. Er ist wirklich sehr aktiv, organisiert viel (z.B. auch demozoo.org) u. tritt auch immer wieder mal musikalisch auf Demoparties auf. Ich bin da ca. 2016 so wieder langsam eingetaucht nach den letzten Aktivitäten um 2000 rum. Vllt. kann ich ja irgendwo mal dazu mehr erzählen oder schreiben.

GleEst scheint mir auf den ersten Blick mit einer Funktion zu arbeiten, die sich über die Zeit (bzw. sich ändernde Parameter) in der Form langsam verändert. Dann werden wohl die entspr. neuen Pixel geplottet und vmtl. mit einem Ringpuffer die ältesten wieder gelöscht. Alternativ könnte man die zu löschenden Pixel auch nochmal berechnen.
Ich zähle meist 6 Pixel in einer der Linien und grob 90 Linien, die auf einmal zu sehen sind. 90*6 wären 540. Da geschätzt, könnte der wahre Wert 512 sein.
Dazu wird noch etwas mehr Dynamik über die Farbattribute eingebracht.

Bzgl. Bitplane-Effekten fand ich zufällig diese Amiga-Demo, welche das schön mit RGB nutzt: https://www.youtube.com/watch?v=9E4JBG8wT84&t=97s
So etwas (natürlich leistungsangepasst) sollte doch gut auf dem Ju-Te-6K gehen.

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
19.11.2024, 19:05 Uhr
HeikoS

@Matthias:
Bitplane-Effekte müssten tatsächlich möglich sein. Die Farben überlagern sich dann ... könnte ich ja mal ausprobieren, danke für den Tipp. GleEst habe ich noch gar nicht verstanden. Sizecoding ist ja wirklich verrückt ... vielleicht kriegen wir's ja auf den JuTe 6K.

@Wolfgang:
Noch einmal vielen Dank für Deine Rückmeldung und Dein Lob ! Ich habe erst jetzt gesehen, dass du ja einer der Glücklichen bist, die einen echten KC compact besitzten. Ich dachte immer du hättest einen BIC ... die sehen ja auch gleich aus ;-) aber das soll keine Entschuldigung sein. Könntest du uns nicht mal ein Video der KCC-Demo senden? In den Emulatoren (vor allem im emulierten Amstrad CPC 464 von Feldi) sehen die tanzenden Linien ja nicht echt aus. Da ich das Youtube-Video nun so oft gesehen habe, würde ich mich über den Vergleich mit dem Original sehr freuen.

Viele Grüße, Heiko

Dieser Beitrag wurde am 19.11.2024 um 19:07 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
20.11.2024, 10:17 Uhr
ThomasR

Avatar von ThomasR

Dafür hast Du also den KCc-Zeichensatz https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22505?f=24&t=11535 gebraucht. Deine Adaption der Demo gefällt mir sehr gut. Ich hatte leider nie genug Freizeit, mir viel Erfahrung und Routine in der Assembler-Programmierung anzueignen.

Ich habe mir den KCc gekauft, als der Preis von 999 DDR-Mark über 499 auf 249 gefallen war. Später kam ich glücklicherweise auch noch zu einer Diskettenerweiterung. Vorausschauend (möglicher Ausfall der Hardware - von Reparaturen habe ich genausowenig Ahnung) freundete ich mich mit einem Emulator an, um die Software ggf. weiter unter DOS oder Windows nutzen zu können. Es war der CPCEmu von Marco Vieth in der Version 1.4, inzwischen wird er von Rainer Loritz weiter gepflegt und hat vor zwei Jahren die Versionsnummer 2.5 erreicht. CPCEmu arbeitet auch mit den KCc-ROMs, sowohl in der Basic- als auch in der CP/M-Betriebsart. Unter CP/M kann auch neben dem von Microsoft auch BBC Basic genutzt werden.

Wenn es um das akkurate Ausführen von Demos geht, schau Dir einmal an, woran ein französischer Computerfreund arbeitet, sein schon sehr fortgeschrittener, aber immer noch in Weiterentwicklung befindlicher Emulator https://forum.system-cfg.com/viewtopic.php?f=24&t=11535 hat nicht den Anspruch, besonders schnell oder sonstwas dergleichen zu sein, sondern das erklärte Ziel, Demos - mit welchem der diversen CRTCs auch immer - pixelgenau laufen zu lassen. Das Forum hat eine Übersetzungsfunktion, ich lese die Beiträge am liebsten auf Englisch: auf Deutsch gibt es irritierende Übersetzungen wie "Eigentumswohnung" für "Elektrolytkondensator".

Eine Koryphäe auf dem Gebiet ist "Longshot", er http://www.logonsystem.eu/ beteiligt sich auch rege am Perfektionieren von "Dmanu"s Projekt.

Die Sache, den Border mit zu nutzen, kenne ich auch unter dem Begriff "Overscan" (vielleicht ist das auch nicht genau das Gleiche wie "Scanlines"). Als Beispiel schau Dir einmal das Spiel Ishido https://cpcrulez.fr/f/4l3 an.

--
Tot wie ein Dodo?
viele Informationen zu BasiCode auf basicode.de

Cu via komputilo povas Esperanto?
Jes, BasiCode!

Dieser Beitrag wurde am 20.11.2024 um 10:27 Uhr von ThomasR editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
20.11.2024, 12:45 Uhr
Dresdenboy

@Heiko:
Bzgl. Curve Fitting scheint das mit Python tatsächlich sehr einfach zu gehen:
https://www.askpython.com/python/examples/curve-fitting-in-python

@Thomas:
Cool, etwas mehr von der CPC-Demoszene zu erfahren. Bis auf die eine oder andere CPC-Demo in den Compos bekomme ich da wenig mit.

Und natürlich pushen sie die Limits, wie auch die Demos auf der Logon System Seite zeigen. Da sowohl im CPC als auch KCC ein 6845 bzw. ein Klon verwendet werden, wären auch so manche der Effekte von den neueren PC XT-Demos möglich, bspw.:
8088MPH (Video: https://www.youtube.com/watch?v=hNRO7lno_DM, auch live von der Party: https://www.youtube.com/watch?v=gdb3AQ14iVc, aufgezeichnet von einem der Haupt-Programmierer, aber teils verdeckt) und
Area 5051 (Video: https://www.youtube.com/watch?v=1Kvi56KgWas, auch live, aber prima zu erkennen).

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Dieser Beitrag wurde am 20.11.2024 um 12:51 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
20.11.2024, 17:39 Uhr
HeikoS

@ThomasR:

Ja, das war der Grund und noch einmal Danke für den Tipp zum Zeichensatz des KCc und die anderen Tipps hier. Freue mich, dass Dir der Versuch der Portierung gefällt. Die Emulatoren habe ich gleich mal ausprobiert. AMSpririT von dem französischer Computerfreund läuft sehr gut ! Tolle Arbeit. Das DEMO-Tape-File von Ulrich's Seite ( http://www.sax.de/~zander/kcc/kcc_sw.html ) konnte ich problemlos einlesen, leider dauert es eine Ewigkeit ;-) aber dann läuft es. Aber nur im CPC 664 Mode, da dort das Basic 1.1 drin ist und die DEMO auf dem KCc erwartet das. Man sieht am Bild, wie gut das emuliert wird, aber eben auch mit diesem Versatz, der auch im Video von "Feldi" zu sehen ist. Beim CPCemu konnte ich keine Tape-Files einlesen.

Es wäre ja besser, die KCc-Demo auf Disk-Files zu haben, damit das elendige Tape-Laden entfällt. Beim JKCEMU kann man ja wenigstens den Turbo-Load-Mode nehmen. Wie könnte ich diese Tape-DEMO auf "Diskette" bekommen ... ? Hast Du evtl. Discology als CPC-Disk-File ... hatte ich ge-googelt, aber keine Ahnung ob das eine gute Methode ist.

Hast Du im AMSpririT schon mal die KCc-OS-ROM und KCc-BASIC-ROM-Files laden können um den KCc damit zu emulieren? Bin mir nicht sicher, ob das überhaupt geht. Es ist ja ziemlich sicher so wie Matthias vermutet, dass die Interrupt-Behandlung beim KCc nicht 100% identisch zum CPC ist. Das hatte Matthias ja hier gefunden: https://cpctech.cpc-live.com/docs/ints.html

Aber generell ist mir jetzt schon klar, dass der KCc eine vollkommen andere "Technologie" (Rasterbars) für die Demo verwendet. Es ist also ein ungleiches Duell ... man wird am JuTe-6K natürlich nie diese Qualität erreichen. Na ja, das habe ich jetzt alles hier gelernt. Hat aber trotzdem Spaß gemacht. Nebenbei wird man noch zum KCc/CPC Experten ;-)

@Matthias:

Interessante Python Lib ! Inzwischen habe ich im Emulator die Demo schon ein wenig auseinander genommen und man müsste eigentlich die Lookup-Tabelle finden können. Mal sehen ob das gelingt. Ansonsten bleibt das jetzt einfach so. Aber das Curve-Fitting kann man bestimmt mal gebrauchen.

Viele Grüße, Heiko

Dieser Beitrag wurde am 20.11.2024 um 18:00 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
20.11.2024, 18:28 Uhr
ThomasR

Avatar von ThomasR

Zitat:

HeikoS schrieb(...)Es wäre ja besser, die KCc-Demo auf Disk-Files zu haben, damit das elendige Tape-Laden entfällt. Beim JKCEMU kann man ja wenigstens den Turbo-Load-Mode nehmen. Wie könnte ich diese Tape-DEMO auf "Diskette" bekommen ... ? (...)

Da müsstest Du mich mal anmailen, denn Files gehen hier ja leider nicht hochzuladen. Schreib an basicode@joyce.de, das landet bei mir. Ich habe auf jeden Fall die originale WELCOME.DSK vom CPC, aber auch ein kleines aus einer Zeitschrift abgetipptes Tool, das TAPE nach DISC oder umgekehrt kopieren kann.

So lange es Basic, kein Maschinencode, ist, kannst Du es aber auch selbst umspeichern, geladen hast Du es unter |TAPE, wechsle einfach auf |DISC und speichere es dort (ich hoffe, so geht es im JKCEMU, den ich ebenfalls sehr schätze, aber für CPC-/KCc-Sachen nehme ich wie erwähnt eher CPCEmu). Mit Maschinencode ist es auch nicht dramatisch, Du musst Startadresse, Länge und ggf. Startadresse kennen. Wenn es auf einer zu niedrigen Adresse beginnt, um es unter Basic behandeln (umspeichern) zu können, hilft das erwähnte Tool.

Zitat:

HeikoS schrieb(..)Hast Du im AMSpririT schon mal die KCc-OS-ROM und KCc-BASIC-ROM-Files laden können um den KCc damit zu emulieren?(...)

In dieser oder ähnlicher Richtung hatte ich bei Dmanu schon mal angefragt, aber seine Prioritäten liegen anders und es geht vorläufig leider nicht.
--
Tot wie ein Dodo?
viele Informationen zu BasiCode auf basicode.de

Cu via komputilo povas Esperanto?
Jes, BasiCode!

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
21.11.2024, 10:28 Uhr
HeikoS

Hallo Thomas,

danke für die Tipps. Hab's hinbekommen. Die KCC-Demo besteht aus 3 Teilen, aus zwei Basic-Programmen und einer BIN-Datei, die nachgeladen wird. Ich musste nur die korrekte Länge des BIN-Files ermitteln. Da KCc und CPC unterschiedliche Disk-Formate nutzen, habe ich mal für beide Systeme die Disk-Images erzeugt und hier zusammen mit dem Tape-File abgelegt, falls das noch andere User ausprobieren möchten. Damit könnte man ja auch physische Disketten für den KCc oder CPC erstellen und das auch auf echter Hardware testen. Und jetzt kann man das im "AMSpririT" auch sehr schnell laden und testen ;-)

https://nextcloud-ext.peppermint.de/s/Gg6Az6CW3f9MsMX

Mehr werde ich jetzt an dieser JuTe-6K-Demo wohl auch nicht mehr machen. Nur ein kleines Update, um das Banner noch schneller "durchzuschieben" kommt noch, das gibt der gesamten Demo dann noch mehr "Speed".

Die beiden Systeme haben, bei allen Unterschieden, aber noch eine historische Gemeinsamkeit. Der KC compact ist ja der letzte in der DDR entwickelte und verkaufte Heim-Computer und der JuTe-6K-kompakt das letzte, größere veröffentlichte Computer-Eigenbau-Projekt der DDR. Irgendwie passen sie dann doch zusammen ...

Viele Grüße, Heiko

EDIT: Die KCC-Demo besteht natürlich aus 3 Teilen, das Bild am Anfang hatte ich weggelassen, ist jetzt bei beiden Versionen, KCC und CPC, mit drin ;-)

Dieser Beitrag wurde am 21.11.2024 um 16:40 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]