Robotrontechnik-Forum

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

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Programmierung von Grafikeffekten auf DDR-Computern » Themenansicht

Autor

Thread - Seiten: -1-

000
24.11.2024, 13:57 Uhr
Dresdenboy

Hallo zusammen,

obwohl der Austausch zum BIC-Thread gut besucht ist und es auch eine erfreuliche Beteiligung bei Programmier-Themen gibt, dachte ich nach Heikos Ju-Te-6K-Demo-Projekt, dass es ja übergreifende Themen gibt, die je nach Hardware auch auf mehreren Plattformen umgesetzt werden können. Fokus liegt hier natürlich auf Grafikeffekten (ggf. auch Sound) wie sie in Intros/Demos aus der Demoszene u. oft auch in Spielen zu finden sind. Dazu gehören sowohl die Funktionsweise, Optimierungen und Tricks, um diese mit möglichst wenig Taktzyklen pro Bildelement umzusetzen, sowie die Eignung der Plattformen für bestimmte Effekte.

Interessant wären schonmal all jene Computer mit echtem Textmodus, idealerweise noch mit Farbattributen. Alternativ sind auch Vollgrafik-Computer geeignet, wenn diese für Pixelblöcke Farbattribute verwenden. Da ist der Vorteil, dass die zu verändernden Datenmengen überschaubar sind.

Weiterhin sínd Rechner interessant, die spezielle Eigenheiten bzw. Stärken aufweisen. Das wären z.B. Rechner mit dem U82720/µPD7220 (BIC, EC1834, VIS3-Karte usw.) oder dem 6845 u. dessen Klone (KCC), Ju-Te-6K u.a. Rechner mit einzeln schreibbaren Farb-Bildebenen und generell auch Rechner, wo der Bildaufbau irgendwie über Register änderbar ist oder Informationen über das Zeichnen der einzelnen Bildzeilen abgreifbar sind.

Das soll es erst einmal für die Einleitung gewesen sein.

Viele Grüße,
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

001
24.11.2024, 14:15 Uhr
ralle

KC85/4 via ESC-Sequenzen. Also Hintergrundfarbe tauschen und so.
https://www.youtube.com/watch?v=xC-nCm-XVBw
war vorher das falsche Video.
Jetzt aber das richtige, ein kleines BASIC: https://www.youtube.com/shorts/4oevv-e8zW8
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 24.11.2024 um 14:25 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
24.11.2024, 17:30 Uhr
kaiOr

Hat man genügend RAM im System könnte man eine Art Playback durchführen. Das muss nicht wie hier gleich Vollbild sein und die Bilddaten müssen auch nicht von extern (USB) kommen.
Sondern man könnte auch ein kleines Objekt (3D-Würfel, dynamische Kachel) während des "Ladebalkens" vorberechnen und dann als bewegliches Sprite oder als gefächerten Hintergrund plotten.

Zitat:

Dresdenboy schrieb
U82720/µPD7220 (BIC, EC1834, VIS3-Karte usw.)

Die Inkompatibilität fängt oft schon auf ein und demselben Rechner an.

Wir hatten z.B. neulich einen Thread mit GEDIT (auf A7150).

Zitat:

GRAF11.F50 wurde notwendig, da sich beim Einsatz einzelner
Importexemplare des Schaltkreises GDC (Graphics Display Con-
troller) vom Typ NEC 7220A aufgrund eines bisher nicht be-
kannten und vom Hersteller nicht eindeutig dokumentierten
Verhaltens Fehlfunktionen ergeben, die sich in der ladbaren
Grafikfirmware folgendermassen auswirken:
- fehlerhafte Darstellung des "kleinen" Grafikkursors, des
Rechteckechos (K31) und des Eingabeausschnitts (K15) (hori-
zontale Linien nicht durchgehend, sondern "durchbrochen"),
- fehlerhafte Ausfuehrung der Grafikkommandos K8 (Initiali-
siere Speicherabschnitt) und K9 (Initialisiere Speicheraus-
schnitt)("Streifenmuster" ueber die gesamte Bildschirm-
breite).
Durch eine in GRAF11.F50 vor Ausfuehrung des ersten Grafikkom-
mandos zusaetzlich durchgefuehrte Initialisierung des GDC wird
ein fehlerfreies Verhalten, unabhaengig vom konkret einge-
setzten Schaltkreistyp, erreicht.

MfG

Dieser Beitrag wurde am 24.11.2024 um 17:32 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
24.11.2024, 18:12 Uhr
Dresdenboy

@Kai
Ja, Playback kleiner Sequenzen v.a. nicht als Vollbild, sondern geschickt berechnet in wenigen sich wiederholenden Frames sind denkbar. Das kann auch zeichensatzbasiert sein. Gerade auf PETSCII-Rechnern gibt es da einen Trend und auch viel Akzeptanz.

Rechner mit viel Grafikspeicher könnten solche Sequenzen auch gleich in ihrem VRAM lagern. Mit einer leichtgewichtigen Komprimierungen (Ablegen von Bildteilbereichen, die nur gezielt überschrieben werden müssen), ginge da auch etwas, was ein <2 MHz Z80 flüssig schafft.

Bgzl. NEC µPD7220A:
Haben diese Probleme mit dem NEC-Chip vllt. etwas mit den hier dokumentierten Änderungen (siehe von mir gepostetes Bild) zu tun?

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

004
24.11.2024, 18:37 Uhr
ralle

Für den Spectrum gibt es eine Videoplayer mit Ton.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
24.11.2024, 19:07 Uhr
volkerp
Default Group and Edit

Zu 000:

KC87 (Farbe) und Z1013 (sw)
Sind geeignete Kandidaten für reinen Textmodus.
Es gibt kaum Demos für diese Systeme.

Hier im Forum gab es das „wormhole“,
Auf meiner Seite findest du 1-Bit-Sound und „Last-KC-Demo“ (große Laufschrift)
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
24.11.2024, 19:31 Uhr
HeikoS

Eine gute Idee! Ich möchte auf eine Demo für den Z1013 hinweisen, die im Juni von Dietmar (u-held) hier vorgestellt wurde. Bisher hat niemand weiter seine Arbeit gewürdigt …

<036> https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21054

Vielleicht liegt es ja auch daran, dass es auf GitHub veröffentlicht wurde.

https://github.com/duhlig/Z1013_software/tree/main/krtdemo

Ich hatte jetzt schon mehrfach Nachfragen (sogar von höchster Stelle :-) zum Laden von *.bin-, *.wav-Dateien etc. auf GitHub. Vielleicht ist dieser Hinweis ja hilfreich. Wenn auf GitHub ein Link, z.B. https://github.com/duhlig/Z1013_software/blob/main/krtdemo/krtdemo.z80 existiert, kann man die Datei nicht mit „Rechtsklick“ und „Ziel speichern unter“ laden, sondern man muss den Link anklicken und danach auf GitHub den „Download Button“ (Pfeil nach unten, Download raw file, oben rechts) anklicken. Im JKCEMU KRT-Grafik aktivieren und „krtdemo.z80“ auf 100H laden.

Hab’s hier auch mal im JKCEMU aufgezeichnet: https://nextcloud-ext.peppermint.de/s/ooA4LT8BcLeatiF

Grüße, Heiko

Dieser Beitrag wurde am 24.11.2024 um 19:38 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
25.11.2024, 19:31 Uhr
Dresdenboy

@Volker:
Die LKCC-Demo habe ich mir angeschaut. Das passt schon ganz gut. Sie braucht offenbar auch nicht einmal viel Code.

Die 1-bit-Sound-Demo schaue ich mir auch noch an. Das Verfahren ist mir manchmal schon begegnet. Ich glaube, das erste Mal auf 286 u. 386 mit PC-Speaker, wo ein Mod-Player die berechneten PCM-Daten ausgab. Spannend wäre hier, die Ausgabe mit dem Bildschirm-Update zu synchronisieren, um zeitlich beides hinzukriegen.

Bzgl. Textmode sind ja auch verschiedene Umsetzungs-Stufen denkbar, je nach Rechner und Bildausgabe-Logik. Von festem monochrom dargestellten Zeichensatz (Nachbildung versch. Helligkeiten über entspr. Zeichen) bis farbig und modifizierbare Zeichen ist ja alles denkbar. Bei PETSCII-Demos auf Commodore PET bis C64 kann man auch die Bandbreite sehen.

@Heiko:
Ich habe mir die Demo mal selbst gezogen und auch im JKCEmu starten können.

Das ist schon gut gemacht, v.a. umfangreich.

Und mit schnellen Kreisroutinen kann man da ja schon etwas schönes machen. Vor allem lässt sich noch mehr herausholen, wenn man von generischen Routinen, die alle möglichen Fälle u. Bildschirmränder beachten müssen (da war auch ein kleiner Bug in der Kreisroutine oben am Rand zu sehen) weg geht (bzw. diese nur in schwierigen Situationen nutzt) und eher spezialisierte Routinen schreibt, ginge noch mehr. Gerade auf C64, Amiga u. Co. waren die Dot Tunnel sehr beliebt. Da werden Kreise nur mit z.B. 32 Punkten dargestellt, was für einen Tunnel aus mehreren Kreisen dann schnell genug ist. Die Punkte können auch vorberechnet sein und müssen nur noch entspr. der Position verschoben werden.

VG,
Matthias

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

008
25.11.2024, 21:05 Uhr
u-held

Zitat:

Dresdenboy schrieb
da war auch ein kleiner Bug in der Kreisroutine oben am Rand zu sehen

Ich denke, da läuft die Fehlervariable des Bresenham-Algorithmus über. Das zu untersuchen hatte ich aber keine Lust mehr. Betrifft ja nur große Radien. Und die sind nicht so spannend, so lange der Mittelpunkt im Bild liegen muss.

VG,
Dietmar
--
Kompetenz simulieren

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
25.11.2024, 21:56 Uhr
HeikoS

Zitat:

volkerp schrieb
...
Hier im Forum gab es das „wormhole“,
...

Ich konnte das hier im Forum mit der Suche nicht finden. Kann jemand helfen ?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
26.11.2024, 11:06 Uhr
Dresdenboy

Ich bekam auf anderem Wege einen Vorschlag für einen Effekt, wie im Film Matrix mit den fallenden Buchstaben ("Digital Rain"). Da es für ein neudeutsch "rapid prototyping" gut in Turbo Pascal umsetzbar war (und damit auch der Algo besser lesbar ist), habe ich es mal für den BIC mit seinen Zeichencodes im Bildspeicher umgesetzt. Da die Textausgaben über eine Prozedur erfolgen, sollte das leicht anpassbar sein. Eine Lösung mit TP-Mitteln (gotoxy und write) ist langsam, mit flackerndem Cursor und reagiert auch nicht bei "keypressed". Da wäre ein direktes Schreiben in den Bildspeicher via mem[addr] sinnvoll und erspart auch die Umrechnung in Zeilen und Spalten.

Quellcode:

program digitalrain;

const len=10;
      max=60;
      width=80;
      height=25;

var pos        : array[0..max] of integer;
    c          : array[0..max] of byte;
    j          : byte;

procedure setchar(p:integer; chr,col:byte);
begin
  if (p<0) or (p>=width*height) then exit; {Position ausserhab des Bildschirms}
  port[$99]:=$49; {CURS: Cursor auf Word im Speicher setzen}
  port[$98]:=p and 255;
  port[$98]:=p shr 8;
  port[$99]:=$20; {WDAT word: Wort schreiben}
  port[$98]:=chr;
  port[$98]:=col;
end;

begin
  clrscr;
  randomize;
  port[$99]:=$4B; {CCHAR: Cursor ausschalten}
  port[$98]:=9; port[$98]:=0; port[$98]:=0;
  for j:=0 to max do               {initiale Zeichen}
    begin
      pos[j]:=random(width*height);        {Bildschirmposition}
      c[j]:=random(255);           {Zeichencode}
    end;
  repeat
    for j:=0 to max do
      begin
        setchar(pos[j],c[j],15);        {weiss}
        setchar(pos[j]-width,c[j],10);  {1 Zeile darueber hellgruen}
        setchar(pos[j]-3*width,c[j],2); {3 Z. darueber gruen}
        setchar(pos[j]-len*width,0,0);  {len Z. darueber loeschen}
        pos[j]:=pos[j]+width;           {naechste Zeile}
        if pos[j]>=(24+len)*width then  {fertig -> neues Zeichen}
          begin
            pos[j]:=random(width);      {Startposition}
            c[j]:=random(255);          {Zeichencode}
          end;                                                                  
      end;
  until keypressed;
  port[$99]:=$4B; {CCHAR: Cursor wieder einschalten}
  port[$98]:=$89; port[$98]:=$20; port[$98]:=$70;
end.

Für die ganzen port-Ausgaben zum Abschalten des Cursors oder Setzen des Zeichens wären für andere Systeme jeweils eine Anpassung bzw, einfach Weglassen des Codes nötig.

Ausgabe:

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

011
26.11.2024, 11:15 Uhr
Dresdenboy

Zitat:

HeikoS schrieb

Zitat:

volkerp schrieb
...
Hier im Forum gab es das „wormhole“,
...

Ich konnte das hier im Forum mit der Suche nicht finden. Kann jemand helfen ?

Ich leider auch nicht.

Aber wo wir bei Demos und auch effektreichen Spielen sind (Werke von Moods Plateau u.a.):
https://demozoo.org/productions/?platform=42

In dieser Demo fand ich ein Plasma für den KC 85/4:
https://demozoo.org/productions/185234/

Edit: Hier ist ein großes Plasma für den KC 85/4 in Quantum Leap): https://www.youtube.com/watch?v=JD__IUjtj5o&t=35s

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 26.11.2024 um 12:47 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
26.11.2024, 11:54 Uhr
HeikoS

Moods Plateau sind natürlich bekannt hier, das sind die absoluten Profis - "Crawler" von Moods Plateau ist manchmal aktiv hier. Ab 1:45 gibt es Rasterbars im Abspann ... ;-) ... aber weniger Lines und ohne Hindernisse ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
26.11.2024, 13:13 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Moods Plateau sind natürlich bekannt hier, das sind die absoluten Profis - "Crawler" von Moods Plateau ist manchmal aktiv hier. Ab 1:45 gibt es Rasterbars im Abspann ... ;-) ... aber weniger Lines und ohne Hindernisse ...

Grüße, Heiko

Das hört sich schon nach demoszene-interner Competition an.

Aber nochmal zu dem Plasma: Die ZX-Lösung, die ich gebaut habe (siehe hier im BIC-Thread, nutzt es ein ähnliches Prinzip wie Moods Plateau in "Quantum Leap": Ein simples Dither-Pattern als Bitmap und Änderung der Attribute.

Was hier noch nicht besprochen wurde, ist ein Plasma (oder anderer helligkeits- bzw. farbbasierter Effekt), für Textmodi, auch monochrom. Das lässt sich gut über entspr. gewählte Zeichen mit mehr oder weniger Pixeln abbilden. Den Rest macht eine flüssige Bewegung.

Hier ist ein Javascript-Beispiel eines Mandelbrot-Rotozoomers in 256 Bytes (Javascript) von Mathieu Henri:
http://www.p01.org/mandelbrot_rotozoom/

Im Vorschaubild werden andere Zeichen verwendet als dann im aktuellen Code. Ggf. musste er den Code an neuere Anforderungen der Browser anpassen. Aber die Grundidee sollte klar werden.

@alle:
Woran bestünde denn mal Interesse? Prinzipiell müsste ich zu sehr vielen Effekten (v.a. aus der Zeit vor den Shadern) die Algos oder Tricks kennen (da mich immer interessierte, wie es funktioniert bzw. ich viel ausprobiert habe) oder ggf. Material finden können.

Ich dachte z.B. an einen Bump-Mapping-Effekt. Bisher habe ich das Ende der 90er in versch. Form in Grafikmodi gemacht (DOS, Java), aber mit Text wäre ja auch denkbar. Hier ein PETSCII-Beispiel:
https://www.youtube.com/watch?v=3FFPCuDqi_g&t=203s

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

014
29.11.2024, 11:44 Uhr
HeikoS

Habe mal was für den Z1013 mit KRT-Grafik gemacht:

https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21054#248668

Grüße, Heiko

Dieser Beitrag wurde am 29.11.2024 um 14:59 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
29.11.2024, 15:08 Uhr
Dresdenboy

@Heiko:

Super, das hat also geklappt! Sehr schön, auch visuell!

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

016
29.11.2024, 16:01 Uhr
HeikoS

Danke ! Ja, ich habe GleEst akribisch filetiert und neu zubereitet ... das war die Übung, damit es dann auch für den JuTe 6K auf Z8 gemacht werden kann ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
01.12.2024, 13:35 Uhr
HeikoS

Jetzt mal was für die KC85-Freunde. Das ging nun schon wie's Brezelbacken, nachdem der Algorithmus aus dem Original extrahiert wurde. Dank der hervorragenden Dokumentation des KC85/4 (Systemhandbuch) und vielen Quellen im Internet (z.B. kc85.info) war es nicht schwer, die richtigen Anpassungen für die KC85-Grafik zu machen. Den Farb-Effekt möchte ich noch hinzufügen, das sollte mit dem KC85 gehen. Vielleicht hat auch jemand Lust da mitzumachen ?

Ich bin immer wieder beeindruckt, von dem schönen Effekt ... beruhigt sogar den Geist in dieser unruhigen Zeit, finde ich.

Es liegt wie immer alles auf GitHub:
https://github.com/haykonus/KC85-Demos/tree/main?tab=readme-ov-file#gleest-f%C3%BCr-kc854

Ich wünsche Euch allen einen schönen 1. Advent !

Grüße, Heiko

Dieser Beitrag wurde am 01.12.2024 um 16:07 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
01.12.2024, 19:18 Uhr
ralle

Du müsstest noch einen Header hinzufügen. So kann man es nicht in das Original laden.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
01.12.2024, 20:05 Uhr
HeikoS

Oh, das ist mein erstes Programm für den KC85 überhaupt. Im JKCEMU kann man es einfach als *.BIN laden. Aber mit den Details im KC und den Dateiformaten kenne ich mich nicht aus. Da bitte ich um Nachsicht oder Hilfe. Ich habe jetzt mal eine KCC- und WAV-Datei erzeugt im JKCEMU.

https://github.com/haykonus/KC85-Demos/tree/main/GleEst_KC85-4

Ich hoffe das geht jetzt und vermute, dass die Länge des Programms unbekannt war zum Laden ?

Grüße, Heiko

Dieser Beitrag wurde am 01.12.2024 um 22:49 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
02.12.2024, 07:47 Uhr
ralle

Eigentlich nicht, da man zum Saven Namen und Anfangs, wie auch Endadresse angeben muss. Optional auch eine Startadresse. Sowohl unter CAOS als auch beim Assembler. BASIC verwaltet das selbst.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
02.12.2024, 09:37 Uhr
HeikoS

Ok, dann ist mir klar was du meinst. Wenn ich im Arnold-Assembler ein Programm übersetzte, entsteht eine *.BIN-Datei. Diese hat eine bestimmte Länge. Beim Laden dieser *.BIN-Datei in den JKCEMU, wird sie einfach bin zum Dateiende an eine Startadresse geladen. Dann kann man mit MENU den Menüeintrag erzeugen und das Programm starten.

*.KCC-Dateien haben den Header, den Du erwähnt hattest, da muss man dann Anfang/Ende/Start eintragen. Beim SAVE-Befehl genau so. Danke für den Hinweis. Im Github liegen nun auch eine KCC- und eine WAV-Datei. Läuft denn das Programm nun bei Dir auf einem echten KC85/4 ?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
02.12.2024, 11:28 Uhr
ralle

Nein, noch nicht. Bin auf QRL
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
02.12.2024, 18:59 Uhr
HeikoS

Die Portierung von GleEst, inkl. des Farbeffekts s. <017> auf den KC85/4 ist gelungen :-))))

Der Speccy arbeitet mit 3,5 Mhz doppelt so schnell, aber der KC85/4 schlägt sich gut.

Update des GitHub folgt ...

@Ralle
Was ist QRL ... ? Kenne nur QRZ ;-)

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
02.12.2024, 22:32 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Der Speccy arbeitet mit 3,5 Mhz doppelt so schnell, aber der KC85/4 schlägt sich gut.

Sehr schick! Und die Farben sehen irgendwie besser aus als im Original.

Und verliert der ZX durch Wait States nicht eh etwas? Hier steht z.B. effektiv 2.66 MHz: https://worldofspectrum.org/ZXSpectrum128+3Manual/chapter8pt30.html

Gibt es das beim KC? Wenn nicht, wäre der Unterschied schon kleiner.

Und der BIC am Ende deutlich schneller.

Edit: Logikers Christmas Challenge ist nun veröffentlicht. Es geht darum, mit möglichst kleinem Code (locker <100 Byte) auf egal welcher Plattform ein Bild aus Textzeichen zu erzeugen. Diesmal ein Geschenk (im hinteren Teil des Videos): https://www.youtube.com/watch?v=3q5ZWJmMhgQ

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 02.12.2024 um 23:05 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
02.12.2024, 23:19 Uhr
HeikoS

Freut mich, wenn es gefällt ! Jetzt hast du mein Lieblingsthema getriggert … manche werden sagen, „nicht schon wieder der mit seinen Erklärungen … ;-) Das hatten wir hier schon mal ausführlich debattiert:

https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21874

Der KC85/4 löst das durch geschicktes Timing und letztlich durch WAIT-States, wie Bert oben in <004> schrieb.

Der Artikel in deinem Post bezieht sich auf den ZX Spectrum 128 +3, die sind nach der Übernahme durch Amstrad rausgekommen. Im ZX-Spectrum von Sinclair wird das anders gelöst. Dazu gibt es eine tolle Story. Im ZX-Spectrum von Sinclair wird tatsächlich der CPU-Takt für einige Perioden angehalten, wenn ein Konflikt zw. CPU und BWS(IRM)-Logik auftritt.

Im Detail ist das für den Spectrum in diesem Buch beschrieben:
http://www.zxdesign.info/book/
https://www.robotrontechnik.de/bilder/Upload_Forum/23/2n1_lqw.png

Dieses Verfahren ist sehr effektiv und soll nur wenig Verluste bringen, habe ich mal gelesen. Konnte ich auch bestätigen am JuTe-6K (s.u.).

Und hier ist die kleine Geschichte dazu …
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22012#242398

Das habe ich mal ähnlich für den JuTe 6K gebaut:
https://github.com/haykonus/JU-TE-6K-Video-HW-Patch

Herrliches Thema ... aber schon zu spät heute. Können wir ja mal weiterführen, oder auch mal Tests auf verschiedenden Rechnern machen dazu ... für heute erstmal Feier-Ahmd !

Viele Grüße, Heiko

Dieser Beitrag wurde am 02.12.2024 um 23:27 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
03.12.2024, 12:13 Uhr
HeikoS

Der PAL-Decoder ist eingebaut ... ;-)

Hier die Farb-Version von GleEst für den KC85/4 auf dem GitHub, inkl. BIN-, KCC-, WAV-Dateien.
https://github.com/haykonus/KC85-Demos/blob/main/README.md#gleest-f%C3%BCr-kc854

Im Quell-Text sind nun noch viele Kommentare an den Stellen, die angepasst wurden. Damit könnte das auch leicht an andere Rechner angepasst werden ... AC1, BIC, KCC, ... ? Vielleicht hat ja jemand Lust dazu.
https://github.com/haykonus/KC85-Demos/blob/main/GleEst_KC85-4/gleest_KC85-4.asm

@Matthias:
Hier noch eine sehr schöne Auftellung der Unterschiede zu "Contended memory" bei den unterschiedlichen Speccy-Versionen.
https://sinclair.wiki.zxnet.co.uk/wiki/Contended_memory

Grüße, Heiko

PS: Ist auch ein schöner Bildschirmschoner ... :-)

Dieser Beitrag wurde am 03.12.2024 um 12:17 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
03.12.2024, 18:36 Uhr
ralle

QRL oder QeRLustig = Arbeitsstelle.

Es funktioniert, nur nicht ganz so zentral. Kannst ja Mario fragen wie das als Bildschirmschoner funktioniert.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 03.12.2024 um 18:37 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
03.12.2024, 21:42 Uhr
FL

Ich habe die KCC und die WAV am KC85/5 ausprobiert.

Sieht super aus !!!

Gruß
Frank.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
04.12.2024, 08:06 Uhr
HeikoS

@ralle, @FL

Danke Euch für die Rückmeldungen !

Wenn man das als "reguläres" Programm bereitstellen möchte, müssten noch einige Dinge getan werden. Oleg Senin aus St.Petersburg hat das ja im Rahmen eines Wettbewerb als extrem optimiertes 256 Byte-Programm erstellt (Size-Coding). Da wurde überhaupt keine Rücksicht darauf genommen, ob das Programm jemals wieder normal beendet werden soll und brav ins OS zurückkehren kann.

Man müsste auf jeden Fall die Anfangsbedingungen besser setzen und prüfen, ob das Programm nicht irgendwo wild in der Gegend RAM-Zellen überschreibt. Aber das zu bändigen, wäre schon möglich. Infos zu "Bildschirmschoner" für KC85/3,4,5 habe ich nur als Driver für CP/M von Mario gefunden. Ob es da Konzepte und API's für den KC-Mode gibt, weiss ich nicht. Da gibt es hier sicher viel bessere Experten zu dem Thema. Wäre ein schönes Projekt ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

030
04.12.2024, 08:12 Uhr
ralle

Naja, es wird ungenutzten RAM genutzt. Faden ist auch so ein ähnliches Programm.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

031
04.12.2024, 09:36 Uhr
FL

Im Emulator habe ich gesehen, daß das Programm tatsächlich einige Bytes wild im RAM überschreibt. Das betrifft ungefähr den Bereich von 0..80h.

Ansonsten, wenn du für die Umschaltung zwischen Pixel- und Farbebene, statt "LD A,000010x0b", SET und RES nimmst, sollte es fast als "reguläres" Programm taugen.

Das Programm als Bildschirmschoner für CAOS zu installieren, wird schwierig.
Im Grundgerät gibt es keinen freien CTC-Kanal den man für die Zeitmessung nehmen kann.
Man bräuchte ein M001 oder M003 als zusätzliche Hardware.
Den Tastaturtreiber aufbohren (neuschreiben) geht vielleicht auch.

Gruß
Frank.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
04.12.2024, 11:12 Uhr
HeikoS

Ein Tipp von KaiOr zur Optimierung der Umrechung von P(x,y) in VRAM-Adressen:

Cool ! Danke.

https://github.com/haykonus/KC85-Demos/commit/8c286fcdaac9b60650214d0b124921cb491db0f1

Gibt es so einen schönen Trick auch für den KC85/3 ?

@FL:

SET und RES baue ich auch noch ein !

Grüße, Heiko

EDIT: Nur RES/SET reicht nicht, man muss noch aus (IX+1) den Registerwert holen, da man ihn nicht vom Register lesen kann. Das macht es dann nur langsamer, lasse ich mal so ... ist ja noch eine Demo ;-)

Dieser Beitrag wurde am 04.12.2024 um 12:39 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

033
04.12.2024, 18:23 Uhr
susowa

> Im Grundgerät gibt es keinen freien CTC-Kanal den man für die Zeitmessung nehmen kann

Bedingt geht CTC0, den benutzt DIASHOW für die Freigabe der Bildwechsel. Man sollte aber vorher die Lautstärke für die Tonausgabe stummschalten (Bit 1-4 PIO Port B (Adresse 89H) auf 1 setzen).

Könnte dann auch stören, wenn man den "KC85 Sound" des D001 im Bildschirmschoner benutzen möchte.

Ein echter Bildschirmschoner ist nur unter CP/M möglich, welcher dann im Grundgerät laufen muss. Unter CAOS gibt es keinen geschützten Speicherbereich, wo der Bildschirmschoner "sicher" ist - wird also schwierig ...

MfG susowa

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

034
04.12.2024, 20:18 Uhr
maleuma

Zitat:

HeikoS schrieb
Die Portierung von GleEst, inkl. des Farbeffekts s. <017> auf den KC85/4 ist gelungen :-))))

Grüße, Heiko

Sehr schön geworden, gute Arbeit. Ich habe es gerade mit dem JKCEMU probiert.
Am KC85/4 funktioniert es, beim KC85/5 werden jedoch die Pixel nicht wieder gelöscht, sodass der Bildschirm langsam voll läuft. Möglicherweise hat das mit dem 256K-RAM zu tun?
Ich habe den Quelltext aber noch nicht analysiert. Vielleicht kannst Du ja dazu noch eine Anpassung machen.
--
Mario.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

035
04.12.2024, 22:34 Uhr
HeikoS

Freut mich, dass es der KC-Gemeinde gefällt! Es ist ja auch wirklich ein sehr schöner Effekt.

Im JKCEMU 0.9.8.4 läuft es bei mir auch auf dem KC85/5. Tritt der Fehler im echten KC85/5 auf ?

Ein kleines Update habe ich gemacht. Liegt jetzt auch auf dem GitHub. Der Port 84h wurde bisher ohne vorher von (IX+1) zu lesen, "hard" gesetzt. Evtl. ist das ja das Problem.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

036
05.12.2024, 06:19 Uhr
ralle

Versionsnummer wäre nicht verkehrt.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

037
05.12.2024, 08:21 Uhr
HeikoS

Im Github kann man ja alles nachvollziehen, was gemacht wurde. Am besten jetzt immer die aktuelle (letzte) Version laden (Name ist immer gleich). Wenn man in der Historie nachschaut, sind alle vorherigen „commits“ (Versionen) zu finden. Für Versionierung ist es noch zu früh, kann man im Github aber auch machen.

Es gibt auch schon Angebote mitzumachen, das in ein „reguläres“ Programm zu überführen. Dann wird’s bestimmt auch Versionen geben. Das war ja eigentlich nur ein Test auf dem Weg zur Portierung auf den JuTe-6K mit Z8 CPU … Aber wenn es so positiv aufgenommen wird für den KC85, dann machen wir das einfach weiter :-)

Grüße, Heiko

EDIT: Links zu den "commits":

https://github.com/haykonus/KC85-Demos/commits/main/GleEst_KC85-4/gleest_KC85-4_0200H.wav

https://github.com/haykonus/KC85-Demos/commits/main/GleEst_KC85-4/gleest_KC85-4_0200H.kcc

Dieser Beitrag wurde am 05.12.2024 um 08:42 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

038
05.12.2024, 18:12 Uhr
HeikoS

Es gibt wieder ein kleines Update:

- GleEst wird besser initialisiert (kein undefiniertes Schreiben im RAM)
- es kann mit beliebiger Taste abgebrochen werden -> Reset

Die aktuellste Version ist immer hier zu finden:

https://github.com/haykonus/KC85-Demos/tree/main?tab=readme-ov-file#gleest-f%C3%BCr-kc854

Grüße, Heiko

Dieser Beitrag wurde am 05.12.2024 um 18:13 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

039
06.12.2024, 08:44 Uhr
HeikoS

Ein Tipp von Crawler:

https://github.com/haykonus/KC85-Demos/commit/136564c03e82939228f034decacbcd087fc485eb

Tastenstatus schneller abfragen (ohne CAOS-Aufruf).

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

040
06.12.2024, 11:00 Uhr
BICa5105

Ich freue mich echt, dass sich in Sachen Software und Demo wieder ein bisschen was tut auf unseren alten Kisten ;-) . ( Hier speziell Grafikeffekte)

Die ganzen "Hardware Basteleien" sind gut und schön und auch super spannend. Aber es ist auch sehr spannend dann aus dieser ganzen Hardware etwas neues sichtbares und hörbares herauszubekommen!
Das ist in den letzten Jahren leider ein bisschen "eingeschlafen".

Aber gerade das ist ja so spannend. Zu sehen was heutzutage noch mit den alten Rechnern möglich ist.
Mit neuen Ansätzen, anderem Wissen, mehr Erfahrung.
Das sieht man ja an der Demo und Programmierszene anderer Rechner. Wo Dinge entstehen welche man noch vor 30 Jahren, bzw. als diese Rechner aktuell waren, für unmöglich gehalten hat.

Falls es jemand noch nicht kennt... .
Ein gutes Beispiel dafür ist auch SymbOS ( http://www.symbos.de/ ) von Jörn Mika.

Das läuft übrigens auch auf dem KC Compact !

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

041
07.12.2024, 08:41 Uhr
ralle

Funktioniert und jetzt auch mehr mittig. Schmiert aber nach einer Zeit ab.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 07.12.2024 um 08:43 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

042
07.12.2024, 09:51 Uhr
Dresdenboy

@Heiko:
Ich habe mal im Sizecoding-Discord über deinen GleEst-Port berichtet. Da gab es Anerkennung von mehreren sehr aktiven u. auch erfolgreichen Sizecoding-Veteranen.

Falls du dich dort selbst einbringen möchtest, organisiere ich gern eine Einladung (ist wg. Spammern stark eingeschränkt). Ansonsten kann ich dich gern dort weiter vertreten.

@ralle:
Den Absturz kann man vermutlich gut im JKCEmu debuggen.

@alle:
Ich erinnere auch nochmal an die Weihnachts-Challenge vom Logiker, wo im Prinzip nur dieses Geschenk mit möglichst wenig Code reproduziert werden muss (auch genaue Anzahl Zeichen und Zeilen) - Position auf Bildschirm egal und Bild löschen ist auch nicht nötig:

Seite mit Regeln dazu: https://logiker.com/Vintage-Computing-Christmas-Challenge-2024

Edit: Code vorher nicht veröffentlichen!

Es kann auch ein BASIC One-Liner-Buch gewonnen werden.

Ich schaue selbst mal, ob ich da teilnehme. Es ist ja noch Zeit. Derzeit ist es zumindest bis Mittwoch sehr eng mit Zeit zu Hause.

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 07.12.2024 um 16:06 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

043
07.12.2024, 13:00 Uhr
Bert

Zitat:

Dresdenboy schrieb
Weihnachts-Challenge

Triviallösung für den grafikfähigen Mühlhausen-KC:

Quellcode:


10 CLS:Y=50:X=75
20 FOR I=0 TO 2
30 LINE 75,Y,255,Y,7
40 LINE X,50,X,200,7
50 X=X+90:Y=Y+75
60 NEXT
70 CIRCLE 165,215,12,7
80 LINE 165,200,140,225,7
90 LINE 165,200,190,225,7

Grüße,
Bert
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

044
07.12.2024, 14:00 Uhr
RenéB

Vorher veröffentlichen der Lösung ist ein Regelverstoß. Außerdem sind das alles ASCII-Zeichen. :-P

Dieser Beitrag wurde am 07.12.2024 um 14:00 Uhr von RenéB editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

045
07.12.2024, 16:06 Uhr
Dresdenboy

@René u. Bert:
Da es anders gelöst wurde, können wir das so stehen lassen.

Aber ich habe nochmal einen Hinweis oben eingebaut.

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

046
08.12.2024, 12:14 Uhr
HeikoS

Zitat:

Dresdenboy schrieb
@Heiko:
Ich habe mal im Sizecoding-Discord über deinen GleEst-Port berichtet. Da gab es Anerkennung von mehreren sehr aktiven u. auch erfolgreichen Sizecoding-Veteranen.

Falls du dich dort selbst einbringen möchtest, organisiere ich gern eine Einladung (ist wg. Spammern stark eingeschränkt). Ansonsten kann ich dich gern dort weiter vertreten.

@Matthias:

Wow, das freut mich natürlich besonders. In echtes Sizecoding möchte ich (jetzt) nicht einsteigen. Bin schon froh, wenn die Portierungen überhaupt laufen. Du kannst aber gerne immer von unseren Aktivitäten dort berichten und meinen Dank für die Anerkennung weitergeben !

@alle:

Ich bekomme immer wieder Tipp’s zur Verbesserung von GleEst für den KC85/4/5. Vielen Dank an die Supporter ! Wenn ihr beim Testen mitmachen wollt, bitte immer konkret mitteilen, auf welcher Platform getestet wurde (HW/EMU, Module, …) und die „commit ID“ aus dem GitHub mitteilen. Dann kann ich das exakt nachvollziehen.

Habe gerade wieder in Update auf GitHub hochgeladen.

https://github.com/haykonus/KC85-Demos/tree/main?tab=readme-ov-file#gleest-f%C3%BCr-kc854

EDIT:

- Änderungen an der Stackinitialisierung und Nutzung
- Dauertest im JKCEMU bisher überstanden

Viele Grüße + schönen 2. Advent,
Heiko

Dieser Beitrag wurde am 08.12.2024 um 14:16 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

047
08.12.2024, 13:41 Uhr
Lötspitze

Hallo Heiko,

bei GitHub steht: "Der Sound-Effekt ist nicht implementiert, da der KC85/4 keinen Sound-Chip der AY-3-Familie besitzt."
Das stimmt, aber es gibt das Modul M066 mit dem Chip. Vielleicht ist damit etwas machbar.
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=14829&highlight=m066

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 08.12.2024 um 13:41 Uhr von Lötspitze editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

048
08.12.2024, 17:46 Uhr
kaiOr

Habe spaßeshalber eine Version für den KC85/3 ge-fork-elt:
https://github.com/pontacko/KC85-Demos/tree/patch-1/GleEst_KC85-4
Auch kurz auf einem echten 3er getestet:
Die Beschränkung auf 4x8 - Farbklötze stört nicht wirklich.
Und die typischen Strichartefakte der IRM-Zugriffe sind auch kaum sichtbar. Da diese die Hintergundfarbe (hier Schwarz) haben und der größe Teil vom Bildschirm ja schwarz ist.

@Heiko: Bitte übernehmen, ich lösche das "Repository" bei mir dann wieder weg.

Gruß,
Kai

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

049
08.12.2024, 19:31 Uhr
HeikoS

Hallo Kai,

super !!! Dann hast Du die Frage aus <032> gleich mit "in die Tat umsetzen" beantwortet ;-)

Ich wollte das auf jeden Fall wegen der "Strichartefakte " auch wenigstens einmal auf einem echten KC85/3 testen. Sehr schön, wenn die Artefakte wegen dem schwarzen Hintergrund nicht stark sichtbar sind! Die Farbklötze von 4x8 sind immer noch besser als 8x8 beim Spectrum. Es war relativ klar, dass das sogar sehr gut passen würde.

Tolle Arbeit ! Ich werde das mit einbinden, immer alle Versionen für /3 /4 erzeugen und die Änderungen über einen Schalter für die Versionen entsprechend setzen, so dass die Code-Basis immer gleich ist.

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

050
08.12.2024, 19:37 Uhr
HeikoS

Zitat:

Lötspitze schrieb
Hallo Heiko,

bei GitHub steht: "Der Sound-Effekt ist nicht implementiert, da der KC85/4 keinen Sound-Chip der AY-3-Familie besitzt."
Das stimmt, aber es gibt das Modul M066 mit dem Chip. Vielleicht ist damit etwas machbar.
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=14829&highlight=m066

VG Matthias

Hallo Matthias,

das kannte ich noch nicht. Eine sehr professionelle Entwicklung inkl. Handbuch. Bin begeistert !!! Das kann man aktivieren und sogar im JKCEMU testen, da gibt es das Modul ja auch. Dann haben wir eine 150% - Portierung, weil die Farben beim KC85/4 fast Pixel genau sind, Gegensatz zum guten alten Speccy. Werde ich auf jeden Fall machen.

Viele Grüße, Heiko

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

051
09.12.2024, 03:00 Uhr
ralle

Über welchen Spektrum geht es? Der 48k hat auch keinen Ay.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

052
09.12.2024, 08:29 Uhr
HeikoS

Zitat:

kaiOr schrieb

@Heiko: Bitte übernehmen, ich lösche das "Repository" bei mir dann wieder weg.

Gruß,
Kai

Ist übernommen und in eine Quell-Datei überführt. Nochmal Danke für die Mitarbeit !

https://github.com/haykonus/KC85-Demos/tree/main/GleEst_KC85-4

Das Readme muss ich noch anpassen, die /3 Versionen liegen noch unter dem Namen KC85/4.

Mehr habe ich beim Kaffee jetzt nicht geschafft ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

053
09.12.2024, 08:32 Uhr
HeikoS

Zitat:

ralle schrieb
Über welchen Spektrum geht es? Der 48k hat auch keinen Ay.

Das stimmt, werde ich im Readme noch erwähnen. GleEst ist für den ZX-Spectrum 128 geschrieben worden. Aber der 48K kann ja auch mit einem Steckmodul erweitert werden, also das gleiche Spiel wie beim KC 85 3/4.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

054
09.12.2024, 11:45 Uhr
kaiOr

Zitat:

HeikoS schrieb
super !!! Dann hast Du die Frage aus <032> gleich mit "in die Tat umsetzen" beantwortet ;-)

Naja, die Adressberechnung beim KC85/2-3 ist nicht wirklich "schön" machbar. Theoretisch ginge es noch etwas schneller mit Lookup-Tabelle (könnte man während der Laufzeit anlegen). Man bräuchte in diesem speziellen Fall aber so 8-12 Tabellen a 256byte und müsste die Teil-Ergebinisse flink ranholen und ver-Oder-n. Lassen wir besser...

Zitat:

HeikoS schrieb
Ist übernommen und in eine Quell-Datei überführt. Nochmal Danke für die Mitarbeit !

Ich danke auch!

Die Dauer-Zugriffe auf 0000h sind allerdings wieder da. Während "djnz d_dloop" läuft HL gnadenlos über buffer2_end hinweg.

Gruß,
Kai

Dieser Beitrag wurde am 09.12.2024 um 11:46 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

055
09.12.2024, 12:18 Uhr
HeikoS

Readme ist überarbeitet, alle Versionen sind nun an der richten Stelle zu finden. Im JKCEMU lief es auch auf dem HC900 und dem KC85/2.

https://github.com/haykonus/KC85-Demos

@Kai:

"Die Dauer-Zugriffe auf 0000h sind allerdings wieder da. Während "djnz d_dloop" läuft HL gnadenlos über buffer2_end hinweg."

-> das schaue ich mir nochmal an !

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

056
09.12.2024, 13:19 Uhr
ralle

Heiko, kc8/2 ist nicht gleich kc85/2. Die erste Serie war noch etwas anders. Die 2te Serie hatte schon den Platinen-Satz des /3. Letztere meldet sich mit CAOS 2.2, während erste mit HC900-CAOS meldet.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

057
09.12.2024, 13:26 Uhr
HeikoS

Zitat:

kaiOr schrieb
... Die Dauer-Zugriffe auf 0000h sind allerdings wieder da. Während "djnz d_dloop" läuft HL gnadenlos über buffer2_end hinweg.

Das ist komisch, ich kann das im JKCEMU nicht nachvollziehen. Wie hast du das bemerkt? Wie kann ich das debuggen ?

Ist das mit dieser Änderung bei dir nicht mehr aufgetreten ?

Quellcode:


            ld      a, hi(buffer2_end)-2    
            cp      a,h 
jp      nc,loop

EDIT:

Hab gesehen ! Mit watch auf HL im Breakpoint am Anfang von d_loop. Dann war es mit der o.g. Änderung von Dir schon beseitigt. Wenn viele Augen draufschauen, haben alle was davon. Das ist ja das Schöne an OpenSouce !

Ich werde den Buffer erhöhen. Die Anzahl der Loops bestimmt ja die Anzahl der Punkte "in der Tiefe" - mal sehen ob das klappt.

Grüße, Heiko

Dieser Beitrag wurde am 09.12.2024 um 14:02 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

058
09.12.2024, 13:50 Uhr
kaiOr

Im Debugger vom JKCEMU unter Speicher einen Haltepunkt auf 0000h setzen.
Allerdings durchsucht das KC-CAOS nach Power-On,Reset,MENU immer den eingeblendeten Speicher nach Menüwörtern, also nicht wundern wenn der Debugger dann ständig stehen bleibt.

Ja, mit der Änderung war das zumindest weg.

Gruß,
Kai

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

059
09.12.2024, 14:03 Uhr
HeikoS

Zitat:

kaiOr schrieb
Im Debugger vom JKCEMU unter Speicher einen Haltepunkt auf 0000h setzen.
Allerdings durchsucht das KC-CAOS nach Power-On,Reset,MENU immer den eingeblendeten Speicher nach Menüwörtern, also nicht wundern wenn der Debugger dann ständig stehen bleibt.

Ja, mit der Änderung war das zumindest weg.

Gruß,
Kai

Gedankenübertragung ... habe es auch gerade gesehen und oben ergänzt ... Vielen Dank !

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

060
09.12.2024, 15:17 Uhr
HeikoS

@Kai:

"Die Dauer-Zugriffe auf 0000h sind allerdings wieder da. Während "djnz d_dloop" läuft HL gnadenlos über buffer2_end hinweg."

-> Das ist wirklich super, dass du das entdeckt hast. Das Schreiben auf 0000 kam ja durch Lesen von 0-Adressen aus Buffer2_end+n. Buffer2_end wird um 77h überschritten. Das ist nun durch Initialisieren bis Buffer2_end+100h gelöst.

@alle:

Nun sollten diese Probleme auf "echter Hardware" auch gelöst sein - wer testen möchte, ist herzlich eingeladen sich zu beteiligen.

https://github.com/haykonus/KC85-Demos

Grüße, Heiko

Dieser Beitrag wurde am 09.12.2024 um 16:50 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

061
09.12.2024, 15:20 Uhr
HeikoS

Zitat:

ralle schrieb
Heiko, kc8/2 ist nicht gleich kc85/2. Die erste Serie war noch etwas anders. Die 2te Serie hatte schon den Platinen-Satz des /3. Letztere meldet sich mit CAOS 2.2, während erste mit HC900-CAOS meldet.

Die Grafikhardware ist aber immer gleich gewesen, meines Wissens nach. Da sollte das Programm laufen, evtl. geht die Tastenabfrage über (IX+8) nicht überall ... guter Hinweis.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

062
09.12.2024, 16:15 Uhr
ralle

Zitat:

HeikoS schrieb

Zitat:

Die Grafikhardware ist aber immer gleich gewesen, meines Wissens nach. Da sollte das Programm laufen, evtl. geht die Tastenabfrage über (IX+8) nicht überall ... guter Hinweis.

Grüße, Heiko

Das Problem liegt eher im ROM. Da gehen einige Module nicht.

Achso, funktioniert jetzt störungsfrei.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 09.12.2024 um 16:41 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

063
09.12.2024, 16:54 Uhr
HeikoS

@ralle:
Danke für die Rückmeldung, d.h. es läuft auf deinem KC85/5 ?

Im JKCEMU funktioniert das Programm auf allen Rechnern: HC900, KC85/2-5, inkl. Tastenabfrage. Modulkompatibiliät wird evtl. beim M066 noch interessant ...

Grüße, Heiko

Dieser Beitrag wurde am 09.12.2024 um 16:57 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

064
09.12.2024, 16:58 Uhr
ralle

Ja, allerdings ist der mit 4.8 nicht aufgebaut, sondern nur der mit 4.5
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

065
09.12.2024, 17:07 Uhr
HeikoS

@ralle:

Super, die CAOS-Version spielt scheinbar keine Rolle, es werden ja auch gar keine Funktionen des CAOS benutzt, ausser die Abfrage der Tasten mit (IX+8). HC900-CAOS, CAOS 2.2, 3.1, 4.2, 4.8 wurden im JKCEKU zum Test genutzt.

@alle:

Wenn noch weitere positve Rückmeldungen kommen, würde ich mal eine Version 1.0 im GitHub anlegen.

Grüße, Heiko

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

066
09.12.2024, 17:37 Uhr
ralle

Das M066 hat eine Kennung, die du suchen lassen kannst. Also nicht nur eine Hardware Adresse 56d sondern auch ein Modulsteuerbyte.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

067
09.12.2024, 19:19 Uhr
HeikoS

Zitat:

ralle schrieb
Das M066 hat eine Kennung, die du suchen lassen kannst. Also nicht nur eine Hardware Adresse 56d sondern auch ein Modulsteuerbyte.

Ja, das wäre das nächste Projekt, aber ich werde jetzt erstmal ein wenig Pause machen. Für den Sound könnte noch wichtig sein, dass der Spectrum-Original-Code den V-Sync-Interrupt benutzt, um aus einem HALT heraus, das Programm synchron zum V-Sync abzuarbeiten. Für die Grafikausgabe hat das keine Bedeutung, aus meiner Sicht.

Wenn da jemand Lust drauf hat und Erfahrung mit dem M066 hat, wäre das nicht schlecht. Ich könnte noch den ZX-Spectrum-Code einbauen und auskommentieren.

Vielen Dank an alle, die mitgemacht haben !

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

068
10.12.2024, 13:01 Uhr
ralle

Das ist nicht das Modulsteuerbyte, sondern das Kennbyte. Das kann ausgelesen werden. Der AY hängt ständig am Bus, nur getrennt mit einem 244. Der kann nicht separat geschalten werden, da reicht es, einfach in die Register zu schreiben.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

069
10.12.2024, 14:01 Uhr
kaiOr

@ralle: Hast Du in die orig. Demo mal reingehört? Ich würde es so umschreiben:
-laufender Kompressor hinter Gipskarton-Trennwand (inkl. Lastwechsel + eiernde Riemenscheibe)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

070
10.12.2024, 14:07 Uhr
HeikoS

@Kai:
Hast Du es in dem Video angehört oder auf einem Speccy/Emulator ?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

071
10.12.2024, 14:19 Uhr
kaiOr

Habe nur im Video reingehört.
So ne Art Rasentrimmer-Geräusch mit bewegungsabhängiger Frequenz (wenn die Pixel enge Kurven machen oder sich schneller bewegen) wäre vielleicht passender.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

072
10.12.2024, 14:27 Uhr
HeikoS

Ak, ok, - im Video das geht ja noch, ich hatte es mal auf einem, scheinbar falsch konfigurierten, Emulator gehört. Das war nur "Geknatter" ... :-) Naja, das ist Geschackssache, in Kommentaren zur Original-Demo war man von dem "angenehmen sonoren" Brummen begeistert ... da sind ja wahrscheinlich eh Techno-Nerds die Zielgruppe ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

073
12.12.2024, 01:03 Uhr
Crawler

Hallo, ich finde auch, daß dies ein sehr schönes Projekt ist und wollte mich gerne beteiligen.

Unter https://gitlab.com/stefan_koch/gleest-screensaver findet ihr meinen Proof-of-Concept-Entwurf des Bildschirmschoners.

Als Timer wird die interne CTC (Kanal 2) verwendet. Das Programm wurde ans Ende des RAM 4 Bereichs verschoben, um nicht von anderen Anwendungen überschrieben zu werden.
Das funktioniert soweit bereits ganz gut. Es gibt aber sicherlich noch Möglichkeiten, etwas daran zu verbessern.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

074
12.12.2024, 08:08 Uhr
HeikoS

@Crawler:

Grandios ! Das ist wirklich super, wie hier gemeinsam tolle Dinge entstehen. Das macht wirklich Spaß !

Eine Kleinigkeit noch: Du bist in das gleiche Problem, wie ich gelaufen. BUFFER2_END wird vom Algorthmus "gnadenlos" überrannt (O-Ton KaiOr ;-) s. <060> und muss noch über BUFFER2_END hinaus initialisiert werden oder, da der Buffer jetzt schon länger als im Original ist (sieht man auch an der Anzahl der Punkte in den Linien), einfach in Zeile 294 (BUFFER2_END)-2 setzen. Sonst wird wieder 0000 beschrieben, was im Emulator nichts ausmacht, aber auf HW immer zu Problemen führte.

EDIT:

BUFFER2_LEN ist im Original 900H, jetzt ist 1000H eingestellt, das erklärt die hohe Anzahl der Punkte in den Linien (müsste A00H sein) und dann (BUFFER2_END)-2. Oder BUFFER2_LEN = 900H und beim Initialisieren noch 100H draufgeben ... (so hatte ich es gemacht).

@Kai:

"Habe nur im Video reingehört.
So ne Art Rasentrimmer-Geräusch mit bewegungsabhängiger Frequenz (wenn die Pixel enge Kurven machen oder sich schneller bewegen) wäre vielleicht passender."

Das wäre eine schöne Erweiterung ! Wir machen ja kein Size-Coding und könnten uns "austoben" ;-)

@BICa5120:

"Ich freue mich echt, dass sich in Sachen Software und Demo wieder ein bisschen was tut auf unseren alten Kisten ;-) . ( Hier speziell Grafikeffekte)"

Das finde ich auch. Matthias wäre ja der Spezi, um das evtl. auch auf den BIC zu portieren.

Viele Grüße und allen eine schöne Vorweihnachtszeit !
Heiko

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

075
12.12.2024, 15:54 Uhr
ralle

Der Bildschirmschoner für ML-DOS ist eine echte COM-Datei. Also wirksam unter CPM.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

076
13.12.2024, 08:21 Uhr
HeikoS

Wer hier mal mitgelesen hat, wundert sich vielleicht über manche Diskussionen über „BUFFER“ etc. Es ist ja schon eine etwas ungewöhnliche Art, wie das Programm (GleEst-Portierung) für den KC85/3/4 entstanden ist. Quelle war die Arbeit von Oleg Senin im Rahmen eines Size-Coding-Wettbewerbs. Ziel ist es dort, möglichst spektakuläre Effekte in Programmen mit der Länge von Zweier-Potenzen (128, 256, 512…) unterzubringen. Das ist dann eher ein Denk-Sport, als Software-Entwicklung ;-) . Oleg’s Programm ist zwar genau 256 Byte lang, verwendet aber RAM an beliebiger Stelle mit beliebiger Länge. Wie sind da eigentlich die Regeln? Als braver, normaler Programmierer kenne ich mich da nicht aus … ;-)

In GleEst werden RAM-Bereiche ab A100h und B700h benutzt. Das Programm selbst liegt auf 8000h-80FFh. Für die Portierung sollte der RAM natürlich nicht „irgendwo“ liegen. Im Quelltext wird HL mit B700h belegt und das Ende der Schleife „loop“ durch Test von Bit 6 in H geprüft (B7h -> C0h). L wird nicht geprüft. Im RAM-Bereich B700h-C000h liegen Zeiger auf VRAM-Adressen, die das Programm bis C000h füllt, dann diese Zeiger liest und damit dann Schreibzugriffe durchführt. Der Algorithmus LIEST aber über C000h hinaus auch Werte, die das Programm niemals definiert hat. Daraus resultieren Schreibzugriffe mit diesen undefinierten Zeigern. Wenn der RAM mit 00 gefüllt ist, dann auf Adr. 0000. Das kann man mit den herrlichen Werkzeugen im JKCEMU sehen. Durch Initialisieren der entsprechenden RAM-Bereiche, konnte das „gebändigt“ werden. Das ist aber nur meine Analyse. Vielleicht sehen da ja Andere noch mehr.

Beim Size-Coding ist scheinbar alles erlaubt, was funktioniert ;-) Matthias kann da ja bestimmt mehr dazu sagen. Von ihm stammt auch der Hinweis auf ein sehr interessantes Tool, ein Live-Coding-Tool für den ZX-Spectrum (kann man sowas eigentlich noch ins Deutsche übersetzen … ;-).

https://bazematic.demozoo.org/

Code eintippen, Ctrl-S und es läuft … unfassbar. Wer Lust hat, kann GleEst dort auch ausprobieren … und sofort testen. Ich habe die minimal angepasste Original-Version mal ins GitHub gepackt:

https://github.com/haykonus/KC85-Demos/blob/main/GleEst_KC85/gleest_ZX128/gleest-bazematic.asm

Einfach mit Copy/Paste kopieren und in Bazematic einfügen und dann -> Ctrl-S

Viel Spaß damit und Danke an Matthias für diesen Tipp, schon im hier im Austausch zum BIC-Thread.
Heiko

EDIT:

Ich hatte ja viel probiert im Zuge der Portierung. Hier noch das Original als BIN/ASM-File, welches mit dem Arnold-Assembler übersetzt werden kann:

https://github.com/haykonus/KC85-Demos/tree/main/GleEst_KC85/gleest_ZX128

Das kann man auch im JKCEMU schön testen:

- ZX Spectrum+ 128 einstellen
- 128 BASIC starten
- BIN-Datei laden auf 8000H
- Mit „PRINT USR 32768“ GleEst starten
- im Debugger die RAM-Zelle 0000 überwachen

Dieser Beitrag wurde am 13.12.2024 um 10:12 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

077
16.12.2024, 08:05 Uhr
HeikoS

Stefan (Crawler) hat die kleine Änderung (s. 074) noch eingebaut. Super! Drei Verbesserungen gibt es damit:

- Kein undefiniertes Schreiben auf RAM/ROM-Zellen.
- Es läuft schneller.
- Das Programm konnte noch weiter nach oben im RAM verschoben werden.

s. https://gitlab.com/stefan_koch/gleest-screensaver/

Ich bin so begeistert, dass ich nun auch endlich meinen KC85/4 einmal hervorgeholt habe. Noch einmal vielen Dank an „Mobby5“ für das Spenden der Geräte und „wpwsaw“ für die unermüdliche Arbeit beim Abholen/Verteilen/Versenden ! Sicherungshalter ist erstmal provisorisch gereinigt:

Zitat:

ralle schrieb
Der Bildschirmschoner für ML-DOS ist eine echte COM-Datei. Also wirksam unter CPM.

Der Bildschirmschoner von Stefan geht unter CAOS jetzt auch sehr gut, auch wenn man z.B. mit Basic arbeitet. Aber du könntest ja mal testen, ob das z.B. unter FORTH, EDAS … auch funktioniert.

Grüße, Heiko

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

078
16.12.2024, 10:54 Uhr
ralle

Schaue ich mal heute abend. Also, EDAS ist kein Problem. Eher WordPro und UniPic. Diese sind nun mal Speicherintensiv.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 16.12.2024 um 17:42 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

079
16.12.2024, 20:47 Uhr
HeikoS

Hallo Ralf,

danke für Deine stetigen Rückmeldungen! Ja, eine Möglichkeit wie bei CP/M den TPA zu verkleinern, so dass sich alle anderen Programme daran halten können, gibt es ja beim CAOS nicht, wie „susowa“ schon in <033> schrieb.

Stefan (Crawler) schreibt auf GitLab: „Der Bildschirmschoner wird ans Ende des RAM 4 ab Adresse 7000H geladen und kann somit i.d.R. nicht von anderen Programmen überschrieben werden. Der RAM-Bereich von 7500H-8000H dient hierbei als Arbeitsspeicher.“ In der Regel geht es gut, muss aber nicht.

Für mich ist dieses kleine Projekt auf dem KC85/3/4 damit beendet. Hat viel Spaß gemacht und habe viel gelernt dabei. Die Anlass war gut, um nun endlich den echten KC85/4 in Gang zu bekommen. Wer mag, kann ja noch den Klang dazu bauen mit dem M066. Ich muss immer noch lachen über Kai’s Beschreibung: „laufender Kompressor hinter Gipskarton-Trennwand (inkl. Lastwechsel + eiernde Riemenscheibe)“ :- )))). Müsste man dann besser machen.

Viele Grüße an alle die mitgemacht haben und an die „Mitleser“ !
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

080
17.12.2024, 06:56 Uhr
ralle

Nein, es gibt in der PC-Betriebsart ungenutzten RAM, der ansprechbar ist, aber nicht wirklich genutzt werden kann. Dahin wird das Faden. Com geladen.

Frag einfach Mario.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

081
17.12.2024, 10:51 Uhr
HeikoS

Faden97 gibt es ja sowohl als Driver für ML-DOS (läuft vermutlich auch unter MicroDOS, was ja wiederum eine CP/M 2.2-Adaption ist), als auch für CAOS. Es ist ja unbestritten, dass es unter ML-DOS/MicroDOS in einem geschützten Bereich laufen kann, unter CAOS vermutlich nicht.

Aber wie gesagt, für mich ist das Projekt an dieser Stelle beendet. Weiter einsteigen in die Programmierung von ML-DOS-Drivern möchte ich nicht. Es ist ja alles offengelegt zu GleEst für den KC85/3/4 von Stefan und mir. Vielleicht hat ja jemand der KC-Experten Lust, das auch für ML-DOS/MicroDOS umzusetzen.

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

082
17.12.2024, 15:37 Uhr
susowa

Zitat:

HeikoS schrieb
Faden97 gibt es ja sowohl als Driver für ML-DOS ... , als auch für CAOS.

Die erste Hälfte der FADEN-Geschichte hat GleEst immerhin schon geschafft.

FADEN91.KCC -> FADEN94.KCC -> FADEN97.KCC

Bis dahin war das eine CAOS-Demo.

Daraus wurde mit FADEN.COM und danach (mit der Entwicklung des DRIVER-Konzepts unter den K85 CP/M's) mit FADEN.DRV der erste richtige Bildschirmschoner für den KC85/4.

Unter CP/M läuft der Code direkt im D001 des KC85/4 und ist damit geschützt bezogen auf die CP/M - Umgebung und seine Programme.

MfG susowa

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

083
17.12.2024, 17:35 Uhr
ralle

Hier, wenn du Faden dir anschauen möchtest
http://kc85.info/index.php/download.html?view=download&id=335:m066-soundmodul-faden-demo&catid=22
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

084
17.12.2024, 20:50 Uhr
Dresdenboy

Ihr seid alle so fleißig!

Ich habe auch mal etwas weitergearbeitet. Es wird sich jetzt auch wieder mehr Zeit finden.

Die Bildkonvertierung u. Lightmap für das Bumpmapping sind fertig. Aber ich wollte schon für das Plasma einen Farbverlaufsgenerator im Textmodus haben. Ziel ist, aus einem berechneten RGB-Verlauf (Beispiele für so etwas hier: http://www.sizecoding.org/wiki/Byte_Battle#Palettes - wo 16 Farben mit 8-bit RGB-Anteilen definiert werden) dann die entspr. Zeichen- und Farbcodes zu erzeugen. Ein erster Stand in Python für Graustufen auf dem BIC:

Quellcode:

print("5 SCREEN 0")
cols = [(0,0), (8, 80), (7, 160), (15, 240)]    # Vordergrundfarben (schwarz, grau, weiß)
bcols = [(0,0), (7, 160)]                       # Hintergrundfarben (schwarz, grau)
# Tupel als (ASCII code, Schattierung) für Zeichen von 0 bis 100% Füllung
shade = [(255, 0.0), (176, 0.35), (177, 0.5), (178, 0.8), (219, 1.0)] 
line = 10                                       # Zähler für Zeilenausgabe
for intensity in range(0,256,16):               # Graustufen bis 255 in 16er Intensitätsschritten
  d=1000.0;i=0;b=0;s=1.0;c=0                    # Initialwerte für gefundene Kombination
  for asc, sh in shade:                         # Schattierungskombinationen durchlaufen
    for idx, lum in cols:                       # Farben mit Index in Palette u. Helligkeit
      for bidx, blum in bcols:                  # + Hintergrundfarben
        td = abs((lum*sh+blum*(1.0-sh))-intensity) # Berechnung Farbabstand zu bisher gefundener
        if td<d and (asc>178 or abs(lum-blum)<100): # ist Farbe näher dran und als Mischfarbe nicht zu krass
          d=td;i=idx;b=bidx;s=sh;c=asc
  print(f"{line} COLOR {i},{b}:PRINT CHR$({c});") # Ausgabe BASIC-Zeile
  line=line+10                                  # Zeilenzähler

Das sollte diesen Code erzeugen:

Quellcode:

5 SCREEN 0
10 COLOR 0,0:PRINT CHR$(255);
20 COLOR 8,0:PRINT CHR$(176);
30 COLOR 8,0:PRINT CHR$(176);
40 COLOR 8,0:PRINT CHR$(177);
50 COLOR 8,0:PRINT CHR$(178);
60 COLOR 8,0:PRINT CHR$(219);
70 COLOR 8,7:PRINT CHR$(178);
80 COLOR 8,7:PRINT CHR$(177);
90 COLOR 8,7:PRINT CHR$(176);
100 COLOR 8,7:PRINT CHR$(176);
110 COLOR 0,7:PRINT CHR$(255);
120 COLOR 15,7:PRINT CHR$(176);
130 COLOR 15,7:PRINT CHR$(176);
140 COLOR 15,7:PRINT CHR$(177);
150 COLOR 15,7:PRINT CHR$(178);
160 COLOR 15,0:PRINT CHR$(219);

Ergebnis:

Nächstes Ziel: Volle RGB-Farben. Die RGBI-Anteile kenne ich. Das sollte sich leicht generieren lassen.

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.12.2024 um 10:05 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

085
17.12.2024, 22:07 Uhr
HeikoS

@susowa:
Danke für die Erläuterungen. CP/M läuft ja, wie ich gelesen habe, direkt im D004/008 und das D001 wird im CAOS-Mode wie ein Terminal angebunden, bzw. können da natürlich ideal von CP/M abgekoppelte Programme laufen. Ein interessantes Konzept.

@ralle:
Danke für den Link. Probiere ich gleich mal aus.

@Matthias:
Schön, dass du wieder was programmierst. Eine Frage zum BIC: Kann man da den VRAM direkt schreiben/lesen ? Ist das irgendwo gut beschrieben ?

EDIT: Habe schon was gefunden: Anhang Programmierhandbuch (S.9-15): https://www.sax.de/~zander/bic/bc_phba.pdf

Und dann kommt man nur über Port 98,99 an den VRAM ran ?
So wie hier z.B. ? : https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#245482

Grüße, Heiko

Dieser Beitrag wurde am 18.12.2024 um 00:04 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

086
18.12.2024, 01:23 Uhr
Dresdenboy

@Heiko:
Leider geht es nicht direkt, sondern nur über die 2 Ports des GDC. Aber zumindest lassen sich Modi einstellen , wo man über einen Port direkt hintereinander schreiben kann. Du hattest das selbst schonmal ausprobiert.

Das war hier: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#245482

Im Prinzip wird erst einmal über ein CURS-Kommando das Startwort gesetzt (den 3. Parameter für Auswahl eines Pixels innerhalb des Worts braucht man nicht immer). Dann wird ggf. eine Maske für das Word gesetzt. Und schließlich noch über WDAT-Kommando der Schreibmodus (z.B. word, low byte, high byte in den Varianten überschreiben, setzen, löschen oder XOR-Verknüpfung). Wenn danach Bytes ausgegeben werden, landen diese linear im Bildspeicher und die Adresse zählt hoch. Wenn man den low byte oder high byte Modus nutzt, wird m.W. das andere Byte als 0 angenommen. Aber dann reicht auch 1 Byte in den Port zu schreiben, um 1 Wort zu füllen. Wobei das Füllen auch mit dem GDC selbst gemacht werden kann.

Falls man sehr schnell Bytes ausgibt, sollte auch das Status-Byte getestet werden, ob der FIFO Platz hat. Details siehe GDC-Doku.

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.12.2024 um 10:09 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

087
18.12.2024, 12:56 Uhr
Dresdenboy

Ich habe mal den BIC-Mischfarbengenerator fertiggestellt. Das scheint erst einmal zu funktionieren. Für andere Plattformen müsste die Berechnung der Farben (ggf. als vorgegebene Tabelle) für R, G, B, I, BR, BG, BB angepasst werden. Für den ZX Spectrum ist es sicher nicht so kompliziert.

Quellcode:

RF=0.299                                        # Faktor für Umrechnung Rot -> Graustufen
GF=0.587                                        # Faktor für Umrechnung Grün -> Graustufen
BF=0.114                                        # Faktor für Umrechnung Blau -> Graustufen
print("5 SCREEN 0")                             # Screenmode ohne Lücken zw. Zeilen
# Tupel als (ASCII code, Schattierung) für Zeichen von 0 bis 100% Füllung
shade = [(255, 0.0), (176, 0.35), (177, 0.5), (178, 0.8), (219, 1.0)]
line = 10                                       # Zähler für Zeilenausgabe
for coloridx in range(16):                      # Farbindex
    d=1000.;ci=0;bi=0;s=1.;ch=0                 # Initialwerte für gefundene Kombination
    # Formel von http://www.sizecoding.org/wiki/Byte_Battle#Palettes:
    # poke(16320+j,s(j)^2*255)
    # d.h. j (von 0 bis 47) läuft über Paletteneinträge R0 G0 B0 R1 G1 B1 ...
    # Anpassung für Script:
    #   - Mapping color index -> RGB-Anteil
    #   - Skalierung von 255 auf 240 geändert
    #   - Begrenzung nach unten auf 0
    CR = max(0, sin(coloridx*3  )**2 * 240)     # berechn. Rot-Anteil
    CG = max(0, sin(coloridx*3+1)**2 * 240)     # berechn. Grün-Anteil
    CB = max(0, sin(coloridx*3+2)**2 * 240)     # berechn. Blau-Anteil
    for asc, sh in shade:                       # Schattierungskombinationen durchlaufen
        for col in range(16):                   # Farben mit Index in Palette u. Helligkeit
            I=(col>>3 & 1)*80                   # Intensität 
            B=(col    & 1)*160 + I              # Blau
            G=(col>>1 & 1)*160 + I              # Grün
            R=(col>>2 & 1)*160 + I              # Rot
            for bcol in range(8):               # + Hintergrundfarben
                BB=(bcol    & 1)*160            # Blau
                BG=(bcol>>1 & 1)*160            # Grün
                BR=(bcol>>2 & 1)*160            # Rot
                # Berechnung Farbabstand zu bisher gefundener
                td = (abs((R*sh+BR*(1-sh))-CR) +# Delta Rot
                      abs((G*sh+BG*(1-sh))-CG) +# Delta Grün
                      abs((B*sh+BB*(1-sh))-CB)) # Delta Blau
                # Delta Vorder-/Hintergrund wg. krasser Sprünge
                delta_FG_BG = abs(R-BR)*RF+abs(G-BG)*GF+abs(B-BB)*BF
                # ist Farbe näher dran und als Mischfarbe nicht zu krass?
                if td<d and (asc>178 or delta_FG_BG<100):
                    d=td;ci=col;bi=bcol;s=sh;ch=asc   # bisher bestpassende Farbkombi merken
    print(f"{line} COLOR {ci},{bi}:PRINT CHR$({ch});") # Ausgabe BASIC-Zeile
    line=line+10                                # Zeilenzähler

Ergebnis:

Quellcode:

5 SCREEN 0
10 COLOR 0,3:PRINT CHR$(255);
20 COLOR 9,3:PRINT CHR$(176);
30 COLOR 9,3:PRINT CHR$(178);
40 COLOR 9,1:PRINT CHR$(178);
50 COLOR 9,1:PRINT CHR$(178);
60 COLOR 9,5:PRINT CHR$(178);
70 COLOR 9,5:PRINT CHR$(176);
80 COLOR 0,5:PRINT CHR$(255);
90 COLOR 12,5:PRINT CHR$(176);
100 COLOR 12,5:PRINT CHR$(177);
110 COLOR 12,4:PRINT CHR$(178);
120 COLOR 12,4:PRINT CHR$(178);
130 COLOR 12,6:PRINT CHR$(178);
140 COLOR 12,6:PRINT CHR$(176);
150 COLOR 0,6:PRINT CHR$(255);
160 COLOR 14,6:PRINT CHR$(176);

Ausgabe mit Vergleich:

Dieser Beitrag wurde am 18.12.2024 um 12:57 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

088
18.12.2024, 17:21 Uhr
HeikoS

@Matthias:

Schöner, gleichmäßiger Verlauf ! Machst Du damit dann noch weitere Plasmen ?

@Z9001-Fans:

GleEst gibt es jetzt auch für die Farbversion + KRT-Erweiterung des Z9001. Das Farb-Attribut ist 8x8 Pixel groß wie beim ZX-Spectrum. Ich konnte es nicht lassen ...

Dieser Beitrag wurde am 18.12.2024 um 20:15 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

089
18.12.2024, 19:03 Uhr
BICa5105

Wann gibt es GleEst für den BIC ;-) ?
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

090
18.12.2024, 20:23 Uhr
HeikoS

Zitat:

BICa5105 schrieb
Wann gibt es GleEst für den BIC ;-) ?

Könnte der Weihnachtsmann bringen ... ;-) Hatte ja oben in <085> schon mal angefragt, wie man an den VRAM des BIC rankommt. Wenn's sonst niemand machen will, würde ich es mal versuchen. Alles über IO-Befehle zu adressieren, müsste eigentlich auch gehen. Mal sehen wie schnell es dann noch ist.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

091
19.12.2024, 16:01 Uhr
BICa5105

Zitat:

HeikoS schrieb

Zitat:

BICa5105 schrieb
Wann gibt es GleEst für den BIC ;-) ?

Wenn du den Weihnachtsmann spielen möchtest ...gern ;-). Ich würde mich freuen.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

092
19.12.2024, 22:58 Uhr
HeikoS

@BICa5105:

Zum "Weihnachtsmann" will ich mich ja nicht machen ;-) ... aber mal sehen, ob zw. den Feiertagen Lust dazu aufkommt und noch Zeit dazu ist.

@Alle:

Die GleEst-Version für KC85/1 (Z9001, KC87) mit KRT-Grafik ist jetzt im GitHub:

https://github.com/haykonus/KC85-Demos/blob/main/README.md#gleest-f%C3%BCr-kc851

EDIT: Wenn jemand diese KRT-Erweiterung gebaut hat, würde ich mich über eine Rückmeldung zum Test auf realer Hardware freuen !

Grüße, Heiko

Dieser Beitrag wurde am 19.12.2024 um 23:09 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

093
20.12.2024, 07:56 Uhr
HeikoS

Huch ... ohne KRT-Grafik gibt es einen "kontrollierten Absturz" ;-) ... GleEst für Zeichengrafik könnte man ja auch noch machen ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

094
20.12.2024, 10:48 Uhr
FL

Ich habe die /3er-Version jetzt auch am echten KC ausprobiert. Paßt!

zu #74
Ich glaube hier:

Quellcode:


loop:   
        ;ld     bc,10FFh        ; nur wenige Punkte (für Test)
        ld      bc,3F06h        ; BH = Abstand Punkte, BL = Anzahl Punkte 
                        
        d_loop:

muß LD BC,3F03H hinein.

Wenn ich das richtig sehe, soll BUFFER2 in 12 Blöcke zu je 192Byte aufgeteilt werden.
Jeder Block speichert die Positionen für bis zu 64 Pixel.
Der Wert im Register C dient dazu HL nach jedem DJNZ-Durchlauf auf den Anfang des nächsten Blocks zu setzen.
Nach dem 12.Durchlauf steht dann HL genau auf BUFFER2_END.

Gruß
Frank.

Dieser Beitrag wurde am 20.12.2024 um 10:49 Uhr von FL editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

095
20.12.2024, 11:50 Uhr
HeikoS

Hallo Frank,

das könnte sein. Am besten mal ausprobieren. 3F06 ist aus dem Original-Spectrum-Code.

Hiermit kannst du es sofort und Live testen:

https://bazematic.demozoo.org/

Ich habe die minimal angepasste Original-Version mal ins GitHub gepackt:

https://github.com/haykonus/KC85-Demos/blob/main/GleEst_KC85/gleest_ZX128/gleest-bazematic.asm

Einfach mit Copy/Paste kopieren und in Bazematic einfügen und dann -> Ctrl-S

Grüße, Heiko

Zitat:

FL schrieb
Ich habe die /3er-Version jetzt auch am echten KC ausprobiert. Paßt!

zu #74
Ich glaube hier:

Quellcode:


loop:   
        ;ld     bc,10FFh        ; nur wenige Punkte (für Test)
        ld      bc,3F06h        ; BH = Abstand Punkte, BL = Anzahl Punkte 
                        
        d_loop:

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

096
21.12.2024, 00:12 Uhr
HeikoS

@FL:

Hallo Frank,
jetzt weiß ich, was du genau meinst:

Block 1 müsste auf 5C0h beginnen (nächster 192-Byte-Blockanfang). Das funktioniert auch mit:

LD BC, 3F03H

Dann würde sich das Buffer2-Ende nicht so weit nach hinten verschieben. Sehr gut analysiert !!! Einfach super, wenn mehrere Augen raufschauen ! Das war zwar im Original-Code so enthalten, ist aber auch aus meiner Sicht nicht richtig.

Das habe ich auch gleich für die KRT-Version für den Z9001 gebrauchen können. Dort werden nicht 3 Bytes (2 Bytes Adr. + 1 Byte Pixel) pro Pixel benötigt, sondern 4 (2 Bytes Adr. + 1 Byte Pixel + 1 Byte BWS-Bank). Ein Block ist 256 Bytes groß. Hier war es sehr wichtig, dass die Intialisierung des Buffer2 genau zum Füllen durch den Algorithmus passt, also der nächste Block wirklich wieder nach 256 Bytes beginnt. Das hatte ich nur durch einen Trick hinbekommen, nämlich immer FFh zum Füllen genommen, daraus ergibt sich immer die Adresse FFFFh und diese hatte ich etwas aufwendig abgefangen bei Schreibzugriffen. Ist jetzt wesentlich besser gelöst. Danke für Deine Mitarbeit !

EDIT: aktualisierte Z9001 KRT Version ist jetzt auch dem GitHub:
https://github.com/haykonus/KC85-Demos/tree/main/GleEst_KC85-1_KRT

EDIT2: aktualisierte KC85/3/4 Versionen sind jetzt auch dem GitHub:
https://github.com/haykonus/KC85-Demos/tree/main/GleEst_KC85

EDIT3: aktualisierte Z1013 KRT Version istjetzt auch dem GitHub:
https://github.com/haykonus/Z1013-Demos/tree/main/GleEst_Z1013_KRT

Viele Grüße, Heiko

Dieser Beitrag wurde am 21.12.2024 um 15:56 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

097
21.12.2024, 12:48 Uhr
Dresdenboy

Zitat:

HeikoS schrieb

Zitat:

BICa5105 schrieb
Wann gibt es GleEst für den BIC ;-) ?

Hallo zusammen,

ich bin endlich mal wieder am PC. Die Tage sind aktuell sehr familienlastig.

Ich selbst möchte auch lieber erst das Bumpmapping fertigstellen. Aber für den BIC GleEst-Port kann ich ja weiterhin Infos liefern. Vermutlich ist das aber schon deutlich mehr Aufwand. Vllt. wäre da der Rückgriff auf ROM-Routinen am praktikabelsten.

Da wäre neben dem Grafikspeicherzugriff der richtige Grafikmodus interessant. Die Bildebenen sind ausführlich in bc_serv1.pdf ("Serviceunterlagen Teil 1" bei robbi) beschrieben.

Es gäbe da den Modus 320x200 in 16 Farben, wo jeweil 4 aufeinanderfolgende Bits die Farbe angeben. Das hieße über eine entspr. gesetzte Maske (z.B. 0000111100000000b) die Bits zu setzen, also auch 3 Kommando-Sequenzen (CURS + MASK + WDAT), was schon ein paar Zyklen frisst.

Ein anderer interessanter Modus könnte "Modus 3" aus der Serviceanleitung (S. 30) sein. Da wird der Zeichengenerator deaktiviert und die Speicherworte werden als 8-Pixel-Bitmuster + Attribut für die 8 Bits verarbeitet. Das käme den Block-Attribut-Modi auf einigen anderen Rechnern nahe. Adressieren ginge zwar auch über das CURS-Kommando und den dAD-Wert (direkte Nummer des gewünschten Bits), aber würde das Attribut wieder überschreiben. Hier wäre wohl ein entspr. Setzen der Maske mit dem Bit für ein Pixel im low byte und FFh als Attributmaske im höherwertigen Byte bzw. 0, falls man das Attribut nicht nochmal ändern möchte, wäre hier möglich.

Z.B. zum Setzen von Pixel 3 mit Farbe Rot vorn und Schwarz hinten wäre die Maske (im Dokument ist Bit 0 links): FF08h (FF ist das komplette Attribut-Byte u. 8 dann Pixel 3). Dann müsste 04 und auch 08 oder einfach FF per WDAT-Kommando geschrieben werden, um das Attribut auf 04 zu setzen und das Pixel.

Heiko und ich könnten das Technische mal genauer besprechen, da das auch hier nicht so einfach in Worte zu fassen ist. Auch die Entwicklung mit JKCEmu könnte schwierig werden, da es davon abhängt, was der Emulator vom GDC umgesetzt hat. Worte schreiben usw. ginge (also die 320x200-Modus in 16 Farben-Variante), aber bzgl. "Modus 3" müsste ich nochmal in die Sourcen schauen.

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 21.12.2024 um 13:20 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

098
21.12.2024, 15:59 Uhr
HeikoS

@Matthias:

Können wir gerne machen, ich muss aber erstmal einen Grundkurs "Wie bediene ich einen BIC?" absolvieren ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

099
21.12.2024, 17:21 Uhr
ralle

Dann wünsche ich dir viel Erfolg und Spaß beim bezwingen von Margots letzter Rache.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

100
22.12.2024, 14:43 Uhr
kaiOr

Zitat:

HeikoS schrieb
Wer mag, kann ja noch den Klang dazu bauen mit dem M066. Ich muss immer noch lachen über Kai’s Beschreibung: „laufender Kompressor hinter Gipskarton-Trennwand (inkl. Lastwechsel + eiernde Riemenscheibe)“ :- )))). Müsste man dann besser machen.

Oje, damit der Entwickler nun nicht sauer auf mich wird, habe ich den origin. Sound noch mit eingebaut:
https://github.com/haykonus/KC85-Demos/compare/main...pontacko:KC85-Demos:patch-1
-M066 muss stecken
-Start mit beliebigem Zusatz-Parameter, z.B.: GLEEST4 1

Für mehr fehlt mir aber auch der Fiduz.
So etwas wie einen simplen Soft-Reset beherrscht der AY-3-8912 nicht zufällig?

Gruß,
Kai

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

101
22.12.2024, 19:08 Uhr
Klaus

Zitat:

HeikoS schrieb
...
EDIT: Wenn jemand diese KRT-Erweiterung gebaut hat, würde ich mich über eine Rückmeldung zum Test auf realer Hardware freuen !

Hallo Heiko,

da ich den KC87 nach laaaanger Zeit mal wieder aus der Versenkung geholt hatte (eigentlich wegen ELKO-Tausch), ist mir Dein Aufruf zum Test des GleEst auf der realen Hardware wieder in den Sinn gekommen. Hatte ja vor langer Zeit mal die KRT nachgerüstet.

Ist schon verrückt… wenn man einige Jahre die Kiste nicht in der Hand hatte… „wie ging das denn alles?“ … Irgendwie fängt man dann immer bei Null an …

Egal, mit einiger Leserei im Forum, habe ich es ohne Kassettenrecorder irgendwie hinbekommen.

Im KC87 habe ich neben der KRT-Grafik noch das KOMBI-Modul mit zwei Floppy-LW und das GUR-Modul stecken.
Also: Die Datei vom PC über USB zum KC87 auf CP/M Diskette transferiert. Dann mit dem DOSX (wie es Volker mal beschrieben hatte) das GLEEST.KCC gestartet.

Ergebnis … siehe Foto.
Läuft genau wie im JKCEMU

… kein Absturz … auch nach 30 Minuten alles noch ok.
Fein gemacht!

Viele Grüße,
Klaus

PS: Schon verrückt, was Ihr Drei da zaubert. Hut ab!

Dieser Beitrag wurde am 22.12.2024 um 19:10 Uhr von Klaus editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

102
22.12.2024, 19:50 Uhr
HeikoS

Kaum backt man mal ein paar Plätzchen, schon passiert hier richtig was ...

@Klaus:
Super ! Vielen Dank für den Test. Es freut mich immer besonders, wenn es denn auch wirklich auf der guten alten Hardware läuft. Dann hast Du bestimmt auch die Korrektur auf der Hauptplatine machen müssen ? Da gab es doch ein Problem mit M1 und IORQ bei INT-Annahme?. Dass ihr so etwas herausgefunden habt ... toll.

@KaiOr:
Das ist ja richtig cool. Hab's mal auf dem JKCEMU getestet. Für den "künstlerischen Ansatz" kannst Du ja nichts

... Ich bin aber nicht sicher, ob der JKCEMU das gut umsetzt. Habe aber leider kein M066. Der KC85/4 ist aber in Startvorbereitung. Das Original auf dem JKCEMU klingt eigentlich genau gleich, bis auf das hohe "Leiern", das ist beim KC viel lauter. Kannst ja mal vergleichen im JKCEMU. Hier die BIN:

https://github.com/haykonus/KC85-Demos/blob/main/GleEst_KC85/gleest_ZX128/gleest-zx128-as-8000H.bin

auf 8000h laden und in 128'er Modus: print usr 32768

@ralle:
Bin schon beim Laden und Speichern von BIN-Dateien über Kassette und *.RMC-Datei ... Wird schon

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

103
22.12.2024, 21:21 Uhr
kaiOr

@HeikoS: Mein M066 und so vieles andere liegt noch unaufgebaut...

Die ZX128-Variante klingt generell etwas tiefer würde ich sagen. Dass steht nun aber im JKCEMU nicht dabei, welchen Takt das emulierte M066 bekommt. Das echte Modul kann wohl gejumpert werden zwischen Systemtakt (~1,76Mhz) oder extra Quarz (typ. 2,00Mhz).

EDIT: Habe mal nachgeschaut, der JKCEMU emuliert beim M066 die 2Mhz-Variante, damit sind die Töne auf jeden Fall etwas höher als im ZX128 (1,77Mhz).

Grüße,
Kai

Dieser Beitrag wurde am 23.12.2024 um 10:37 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

104
22.12.2024, 22:41 Uhr
HeikoS

@kaiOr:
Aber es ist eine tolle Arbeit ! Ich würde es dann auch gerne bei mir übernehmen. Es wäre aber schön, wenn es mal auf einem echten M066 getestet würde. Vielleicht kann das ja mal jemand machen. Die BIN,KCC,WAV Dateien habe ich im Branch "patch-1" für den KC85/4 erzeugt bei mir:

https://github.com/haykonus/KC85-Demos/tree/patch-1/GleEst_KC85-4

Viele Grüße, Heiko

EDIT: @alle: starten mit "GLEEST4 1" 1 = sound enabled

Dieser Beitrag wurde am 22.12.2024 um 22:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

105
23.12.2024, 10:18 Uhr
Klaus

Hallo Heiko,

Zitat:

HeikoS schrieb
... Dann hast Du bestimmt auch die Korrektur auf der Hauptplatine machen müssen ? Da gab es doch ein Problem mit M1 und IORQ bei INT-Annahme?. Dass ihr so etwas herausgefunden habt ... toll.

… das hat einer der andere Kläuse, der Klaus Junge (paulotto) mit seiner professionellen Meßtechnik herausgefunden. Hier sind die Infos dazu.
http://www.sax.de/~zander/z9001/tip/tipf.html

Ja… ich habe diese Änderung damals beim Einbau der KRT-Grafik gleich auf der Rechnerplatine mit durchgeführt. Ob es auch ohne diese Änderung geht, weiß ich nicht.
Keine Ahnung, wie viele diese KRT-Grafik damals eingebaut haben. Mich hatte es hauptsächlich wegen dem 80 Zeichen Modus interessiert, da dieser für CP/M besser geeignet ist.
Volker und Ulrich haben ja schon sehr viel Zeit und Wissen investiert, um den Z9001/KC87 mit Hard- und Software aufzurüsten.

Viele Grüße,
Klaus

Dieser Beitrag wurde am 23.12.2024 um 10:19 Uhr von Klaus editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

106
23.12.2024, 11:53 Uhr
maleuma

Zitat:

HeikoS schrieb
Es wäre aber schön, wenn es mal auf einem echten M066 getestet würde. Vielleicht kann das ja mal jemand machen.

Ja, funktioniert auf der echten Hardware. Es tönt sofort beim Autostart. Nur beim wiederholten Aufruf des Kommandos muss der Parameter 1 angegeben werden.
Tolle Arbeit!
--
Mario.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

107
24.12.2024, 09:20 Uhr
HeikoS

@maleuma:
Vielen Dank für den Test ! Dann kann ich es ja "offiziell" in die neue Version einbauen. Noch einmal danke an KaiOr ... und man kann es ja auch abschalten, wem das "Geleier" nicht gefällt ...

@Klaus:
... da kann man schon mal durcheinander kommen, bei den vielen "Kläusen"

- ist ja schon eine Weile her, aber tolle Arbeit damals, Gruß an paulotto !

Grüße, Heiko

Dieser Beitrag wurde am 24.12.2024 um 09:20 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

108
28.12.2024, 13:24 Uhr
kaiOr

@maleuma: Das wusste ich noch nicht, dass bei Autostart Register A != 0 übergeben wird. Dann müsste man eher 'CP 1' prüfen.

Die Tage hatte ich Lust mal ein Plasma auf dem KC85 nachzuempfinden, aber irgendwie habe ich das Konzept noch nicht ganz verstanden.

Dafür hatte ich zwischenzeitlich so etwas wie einen Wasser-Effekt:

...leider nicht feinauflösend genug für'n normalen Bildschirm.

Gruß,
Kai

Dieser Beitrag wurde am 28.12.2024 um 13:51 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

109
28.12.2024, 21:37 Uhr
HeikoS

Hallo Kai,

sieht auch interessant aus. Am besten wirkt es, wenn das Bild sehr klein ist, dann kann man wirklich einen Wassereffekt sehen !

Den Sound mit dem M066 baue ich noch in den Main-Branch der KC-Demo's ein. Läuft das eigentlich auch auf dem KC85/3 ?

Bin noch ein wenig angeschlagen ... Grüße, Heiko

Dieser Beitrag wurde am 28.12.2024 um 23:40 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

110
28.12.2024, 23:29 Uhr
kaiOr

Hallo Heiko,

stimmt, für diesen Effekt währen grauer Star und abnehmbare Aschenbecher echt von Vorteil.

Wegen Sound: Die Abfrage vom M066 passiert am C(h)AOS vorbei. BASIC muss nicht extra ausgeblendet werden da nur /IORQ und kein /MREQ, einen Expander-RAM auf/ab 4000h brauchen wir auch noch nicht (solange Du keine PT3-Player-Engine + Sound-File einbindest).
Ab HC900 aufwärts muss das funktionieren.

Gute Besserung!
Grüße,
Kai

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

111
29.12.2024, 11:40 Uhr
Dresdenboy

@Heiko:
Gute Besserung!

@Crawler:
Ich habe deinen Geschenk-Beitrag beim Durchskippen in Logikers VCCC 2024 Video entdeckt! Sehr gut! Sobald mir die Familie etwas Ruhe lässt, schaue ich mir alles nochmal richtig an.

Hier für alle der Video-Link: https://youtu.be/kJYbIC-14s4

@Kai:
Ja, auch wenn nicht das Geplante erreicht wurde, kann etwas Interessantes herauskommen. Wasser würde passen oder Kaleidoskop. Wenn es chaotischer wäre, aber irgendetwas erkennen lässt, gäbe es die Kategorie "Glitch". Hier mal ein Beispiel: https://demozoo.org/productions/102255/

Jedenfalls scheint schon etwas vom Plasma drin zu stecken: Die vertikalen Farbbänder gehen in die Richtung, was man mit einer teilweisen Sinusfunktion (als LUT) und der X-Position erhalten würde. Die kleinen Wellen darauf sind vllt. nur zu hochfrequent. Ich werde dazu noch eine Erklärung vorbereiten.

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 29.12.2024 um 11:41 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

112
30.12.2024, 22:36 Uhr
Crawler

@Dresdenboy:
Ja, ich konnt's nicht lassen. :-)
Habe sogar einen Preis abgestaubt. War diesmal ziemlich tricky.

@Heiko:
Gute Besserung auch von mir!

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

113
31.12.2024, 10:13 Uhr
HeikoS

Danke an alle für die Besserungswünsche ! Es ist überstanden ... sowas braucht man nicht.

@Crawler:
Glückwunsch zum Preis ! Das muss ich mir jetzt auch mal anschauen.

@Kai:
Danke für die Infos zum M066. Dann werde ich den Ton für KC85/3+4 einbauen und auch den "Schalter" noch anpassen.

@Matthias:
Danke für die Tipps aus <097> ! Die Version mit "Modus 3" und deaktiviertem Zeichengenerator könnte man auch noch testen. Das ist vielleicht generell interessant. Na, mal sehen was das nächste Jahr bringt.

Grüße, Heiko

Dieser Beitrag wurde am 31.12.2024 um 13:31 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

114
31.12.2024, 16:54 Uhr
BICa5105

...
Dank HeikoS funktioniert das Gleest jetzt ja auch auf dem BIC :-).... .

Wer keinen BIC hat und den JKCEMU nicht bemühen möchte kann ja mal hier reinschauen:
Sound ist original vom BIC abgespielt (PT3).

https://youtu.be/LvkepkRRAdQ

LG und einen guten Rutsch
Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

115
01.01.2025, 12:08 Uhr
Dresdenboy

@Crawler:
Glückwunsch auch von mir!

@all:
Ich wünsche euch ein frohes neues Jahr und weiterhin viel Spaß mit unseren Computern!

Zum Start des Jahres habe ich noch einen passenden Effekt finalisiert, den ich gestern wg. anderer Verpflichtungen und einem kleinen Hilfseinsatz (Auto abschleppen

) nicht mehr posten konnte. Und zwar habe ich mal ein Partikelsystem in Turbopascal programmiert, welches in der Variante hier für den BIC die TP-Grafikbibliothek nutzt. Die Idee dahinter ist einfach - ich hatte das in den 90ern schon einmal für VGA gemacht.
Das funktioniert auch auf dem BIC mit Festkommazahlen sehr gut. Eine Anpassung an andere Systeme sollte auch nicht schwierig sein.
Varianten für die Darstellung wären z.B. das Löschen der gezeichneten Pixel mit der gleichen Routine u. Daten, nur mit schwarzer Farbe, oder das Löschen in jedem Zyklus (fliegende flackernde Punkte).

Der Abbruch ist per Tastendruck möglich, wird aber nur nach einer vollen Schleife (bis zum Bildschirmlöschen) geprüft.

Edit: Ich konnte auch ein COM-File bauen. Hier ist es für den BIC:
https://www.citavia.de/ddb/FIREWORK_A5105.ZIP

Der Code:

Quellcode:

program fireworks;

{$I grbs.bic}

{Verwendung Festkommazahlen als integer
 mit 7.8 bit und Vorzeichen
 Werte werden auf Fenster um Zentrum begrenzt
}

const ITERS=60;
      PARTS=30;
var i:integer;
        s:array[0..255] of integer;
        x:array[0..127] of integer;
        y:array[0..127] of integer;
        vx:array[0..127] of integer;
        vy:array[0..127] of integer;
        xbyte,ybyte:integer;
        sx,sy,pos:integer;
        winkel:integer;
        geschw:integer;

begin
    {Sinustabelle}
    for i:=0 to 127 do
    begin
        s[i]:=round(sin(i*0.0245437)*127.0);
        s[i+128]:=-s[i];
    end;

    InitGraphic; {Grafik initialisieren}
    Graphic_mc;  {320x200 in 16 Farben}

    repeat
        sx:=(random(255)-128) shl 6; {Startpunkt X}
        sy:=(random(255)-128) shl 6; {Startpunkt Y}
        {Initialwerte fuer Explosion}
        for i:=0 to PARTS do
        begin
            x[i]:=sx;
            y[i]:=sy;
            winkel:=random(255);
            geschw:=random(32)-16;
            vx[i]:=s[winkel]*geschw div 4; {v-Vektor X}
            vy[i]:=s[(winkel+64) and 255]*geschw div 4; {v-Vektor Y}
        end;

        ColorGlb:=random(8)+8; {zufaellige helle Farbe}
        
        for pos:=0 to ITERS do
        begin
            for i:=0 to PARTS do
            begin
                xbyte:=hi(x[i]);
                if xbyte>127 then xbyte:=xbyte-256; {x[i]/256}
                ybyte:=hi(y[i]);
                if ybyte>127 then ybyte:=ybyte-256; {y[i]/256}
                dp(xbyte+160, ybyte+100); {Pixel setzen}
                x[i]:=x[i]+vx[i]; {Bewegung X}
                y[i]:=y[i]+vy[i]; {Bewegung Y}
                vy[i]:=vy[i]+20;  {Gravitation}
                if y[i]>25600 then {außerhalb des Bildschirms}
                begin
                    vy[i]:=0;
                end;
            end;
        end;
        ClearScreen;
    until keypressed;
    LeaveGraphic;
end.

Dieser Beitrag wurde am 01.01.2025 um 13:06 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

116
01.01.2025, 12:41 Uhr
BICa5105

Hi Matthias,

du weißt, ich bin kein Assembler,Turbo Pascal etc. Profi :-).
Aber mal ein paar Ideen dazu von mir...vielleicht hilft es ja weiter.

Das Problem mit Grafik im SCPX Modus des BIC wurde schon mal diskutiert. Da hatte jemand ein Spiel programmiert welches im JKCEMU dann lief aber auf dem original BIC nicht.
Das liegt daran, dass der JKCEMU die SCPX Seite des BIC nicht richtig emuliert. Dort wird angenommen, dass der BIC SCP "mäßig" 100 % kompatibel zum 1715 ist. Ist er aber nicht.
Also wenn du im SCPX so etwas machen willst...dann nie im JKCEMU !! Nur auf dem original BIC.

Naja eine Lösung kam damals aber in dem Fall leider nicht raus.
Aber im SCPX5105 ist es ja so, dass man von da aus auch auf alle Grafikroutinen im BIOS zugreifen kann. Und man muss auch da den richtigen Bildschirmmodus wählen - also Screen5. Das screen Kommando gibts im scpx auch.
Und man muss den SVG richtig konfigurieren ( Über Port A 0x0A8) ) um die richtige Speicherbank und Seite zu aktivieren.

Und es gibt auch speziell für den BIC eine Datei / TurboPascal Grafikbibliothek.

Vielleicht hilft das ja ein biiiisschen weiter.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Dieser Beitrag wurde am 01.01.2025 um 12:42 Uhr von BICa5105 editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

117
01.01.2025, 12:54 Uhr
Dresdenboy

@Cornelius:
Ich kann mir das auch nochmal auf der richtigen HW anschauen, was nicht ganz so schnell gehen wird. Hattest du es probiert? Ich erinnere mich grob an solche Diskussionen. Für den Code hier hatte ich Turbo GRAPHIX Bibliotheken genutzt, die offenbar für den BIC gedacht sind.

Dort sind auch ein paar COM-Files (Tests, Fraktale, Plots usw.) dabei, die in 640x200 etwas zeigen. Ich kann nochmal schauen, wo ich diese gefunden habe. Der 320x200 16 Farben-Modus ist wohl der einzige andere Grafikmodus der Bibiliotheken. Das stammt aus dem Link von volkerp hier von Ulrich's Seite: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20540#221293

Da die Bibliotheken von 1989 stammen und bzgl. Bildungsnutzung des BIC in Turbo Pascal (hatte ich ja auch im Unterricht) dann auch Grafikunterstützung sinnvoll erscheint, vermute ich, dass das auf der HW laufen sollte.

Mein Ziel ist ja auch, die Einstiegshürde für Grafikthemen etwas zu senken, was mit umfangreichen Assemblerroutinen sicher schwieriger ist, als mit irgendwie lesbarem Hochsprachencode. BASIC kann schnell auch schlechter lesbar sein als Turbo Pascal. Man wird auch mehr zu Struktur gezwungen.

Vllt. motiviert es dich auch.

Dieser Beitrag wurde am 01.01.2025 um 13:03 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

118
01.01.2025, 13:04 Uhr
BICa5105

...

Hast alles richtig gemacht ! Es funktioniert am original BIC !
Habe es gerade getestet. :-)

Ein buntes Feuerwerk.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

119
01.01.2025, 13:05 Uhr
Dresdenboy

@Cornelius:
Super! Dann kann ich so erstmal weitermachen.

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

120
01.01.2025, 13:11 Uhr
BICa5105

...
hättest mal nur deinen Post oben nicht editieren sollen so, dass mein darauffolgender post irgendwie aus dem Zusammenhang ist.
Ging ja erst darum bei dir, dass du es im JKCEMU getestet hattest und es nicht lief sondern nur komische Zeichen in der Kommandozeile des Textmodus gemacht hat und du nach einer Idee gefragt hattest. ;-)

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Dieser Beitrag wurde am 01.01.2025 um 13:14 Uhr von BICa5105 editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

121
01.01.2025, 13:22 Uhr
BICa5105

...
Habe deine FW.com jetzt im JKCEMU getestet... Da läuft es aber auch.
Was hast du denn geändert? Wo war der Fehler ?

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

122
01.01.2025, 13:45 Uhr
Dresdenboy

Zitat:

BICa5105 schrieb
...
Habe deine FW.com jetzt im JKCEMU getestet... Da läuft es aber auch.
Was hast du denn geändert? Wo war der Fehler ?

LG Cornelius

Ah, sorry für die Verwirrung.

Das Problem war scheinbar nur das Einbinden u. Aktualisieren von einem Verzeichnis als 2. Diskettenlaufwerk, wo TP trotzdem erst nicht schreiben konnte oder zwar die Datei anlegte, aber mit 00 füllte. Ich nutzte das Verzeichnis, um den Sourcecode schneller in Notepad++ zu bearbeiten und direkt einzulesen. Ich habe die nötigen Dateien dann einfach in SCPX auf das erste LW mit Diskimage kopiert und dort gebaut.

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

123
01.01.2025, 17:21 Uhr
BICa5105

@Dresdenboy

Womit compilierst du deinen TP code zur com, damit er am BIC startbar ist ?
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

124
01.01.2025, 18:37 Uhr
BICa5105

Zitat:

BICa5105 schrieb
@Dresdenboy

Womit compilierst du deinen TP code zur com, damit er am BIC startbar ist ?

Hab das TP 3.x jetzt am BIC laufen. funktioniert einwandfrei. Da kann man alles machen.... .
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

125
01.01.2025, 18:42 Uhr
Dresdenboy

Zitat:

BICa5105 schrieb
Hab das TP 3.x jetzt am BIC laufen. funktioniert einwandfrei. Da kann man alles machen.... .

Falls du es noch nicht herausgefunden hast: Options [O] -> [C] für COM-File und dann mit [Q] zurück.

P.S.: Die Include-Datei findest du im Paket bei volkerp.

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 01.01.2025 um 19:09 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

126
02.01.2025, 17:10 Uhr
BICa5105

...
Hatte im Post 116 geschrieben, dass womöglich grafische Anwendungen unter SCPX welche im JKCEMU laufen am original BIC aber nicht laufen.
Das betrifft Programme welche mit Turbo Pascal erstellt wurden nicht! Die laufen da und da.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

127
03.01.2025, 09:51 Uhr
HeikoS

Der Original-Sound-Effekt von GleEst ist nun für den KC85/3+4 mit M066 eingebaut:

https://github.com/haykonus/KC85-Demos?tab=readme-ov-file#gleest-f%C3%BCr-kc85134

Nach einmal Dank an KaiOr ! Im JKCEMU läuft es auch auf dem KC85/3. Beim Autostart müsste es nun auch ruhig sein, wenn man Sound nicht aktiviert.

Grüße, Heiko

Dieser Beitrag wurde am 03.01.2025 um 09:52 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

128
03.01.2025, 10:01 Uhr
HeikoS

Zitat:

BICa5105 schrieb
...
Hatte im Post 116 geschrieben, dass womöglich grafische Anwendungen unter SCPX welche im JKCEMU laufen am original BIC aber nicht laufen.
Das betrifft Programme welche mit Turbo Pascal erstellt wurden nicht! Die laufen da und da.

LG Cornelius

Das könnte aber auch noch von den verwendeten Grafik-Befehlen abhängen. Hast Du alle Grafik-Funktionen der Pascal-Bibliothek ausprobiert? Habe in den 80'ern in Breitenbrunn auch viel Turbo-Pascal programmiert mit TP 3 unter CP/M. Für einen Professor, der ein gigantisches BASIC-Programm auf dem A5120 für Null-Stellen-Berechnung bei Polynomen n'ten Grades erstellt hatte. Das musste nach Pascal portiert werden ... für Geld haben wir als Studenten ja alles gemacht ;-)

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

129
03.01.2025, 15:24 Uhr
Dresdenboy

Nach dem kleinen Feuerwerksausflug habe ich mal mit dem Bumpmapping etwas erstes Vorzeigbares erstellt. Das läuft auf dem BIC (JKCEmu oder echte HW) im Textmodus. Die erste Version gibt es einmal, ähnlich wie Heikos erste GleEst-Version für den BIC, als ein reines Binary-File, welches im Emulator per Autoload ab Adresse 8100h geladen wird:
https://www.citavia.de/ddb/robotron/bicbump_0.1.zip
Der Aufruf erfolgt in BASIC per:

Quellcode:

10 screen 1:key off:locate,,0:defusr0=&H8100
20 x=usr0(0):goto 20

oder direkt als BLOAD-Binary mit dazugehörigem BASIC-Loader:
https://www.citavia.de/ddb/robotron/bump_bas.zip

Wenn ich noch einen Loop in Assembler einbaue, ginge natürlich auch ein autostartendes BIN-File.

Als nächstes bereite ich den Code schön auf und auch eine Erklärung des Effekts.

Dieser Beitrag wurde am 03.01.2025 um 15:38 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

130
03.01.2025, 18:29 Uhr
HeikoS

Sieht interessant aus. Auf dem Handy immer sehr gut, weil es da so klein ist. 16 KB - ist bestimmt in Turbo-Pascal geschrieben ... ?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

131
03.01.2025, 18:50 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Sieht interessant aus. Auf dem Handy immer sehr gut, weil es da so klein ist. 16 KB - ist bestimmt in Turbo-Pascal geschrieben ... ?

Grüße, Heiko

Ja, ein Handy hilft sicher auch.

Aber auch so finde ich es noch OK, auch besser als in 40x25, selbst, wenn da flüssiger. Kommt auch auf den Inhalt an.
Nur auf einem 65 "-Fernseher könnte es seltsam wirken. Ein CRT war da schon immer eine praktische HW-Anti-Aliasing-Lösung.

Turbo Pascal ist es nicht. Das wäre deutlich langsamer. Es läuft ja im 80x25-Modus, wobei die konstanten Bildbereiche oben und unten nach dem ersten Update nicht mehr geschrieben werden. Aktuelle Größen:

Quellcode:

Code:              99 Bytes
Variablen:          5 Bytes
Sinus-Tabelle:    256 Bytes
Bumpmap 128x25:  6400 Bytes (Worte mit Pseudo-Normalvektor-Anteilen in den Bytes)
Lightmap 128x32: 8192 Bytes (Worte mit Zeichencode + Farbattribut, erspart weiteres Lookup in einer Farbtabelle)

Das ist also schon einigermaßen auf Geschwindigkeit hin geschrieben, nur noch nicht super optimiert (mit Loop Unrolling, EXX und was alles ginge).

P.S.: Das Logo ist aus dem originalen errechnet, aber selbst nicht auf 80x25 skaliert. In 40x25 sieht es gut aus. Folgt noch.

Viele Grüße,
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 03.01.2025 um 19:59 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

132
04.01.2025, 10:28 Uhr
HeikoS

Ah, ok. Durch die großen Datenbereiche sind die 16 KB entstanden. Das Hin- und Herschieben ist noch etwas ruckelig. Das müsste doch ohne Probleme noch in der Austastlücke machbar sein? I.d.R. kann man das im JKCEMU aber auch nicht testen. Jens Müller hat für den JTCEMU die Simlation einer BLANK-Abfrage eingebaut in einer Testversion. Es geht also und wäre für viele andere Rechner auch sehr schön. Aber mal sehen, wie viel Jens noch in die EMU's investieren möchte.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

133
04.01.2025, 11:26 Uhr
Dresdenboy

@Heiko:
Der emulierte BIC gibt die GDC-Statusflags aus. Damit lässt sich das synchronisieren. Bei 40x25 scheint das locker machbar. Ich kann ja mal Zyklen zählen.

Aber bei 80x25 wird es schon eng, da die Verarbeitung pro Zeichen all das umfasst:
- 16b-Wert entspr. Verschiebeposition laden (mit Pseudonormalen) u. anpassen
- Lightmap-Adresse entspr. Bildposition u. Pseudonormale (X, Y-Anteile) ermitteln
- 16b-Lightmap-(Zeichen-)Werte and GDC schicken
Das dann 1200 bis 2000 mal pro Bildaufbau.

Edit: Gerade mal gecheckt: Inkl. Rücksprung braucht die innere Schleife derzeit 208 Taktzyklen. Selbst bei 40x25 hätte man nur 75 pro Zeichen.

Edit2: Reines Kopieren hilft hier nicht, da eh alles neu berechnet und gezeichnet werden muss. Die Beleuchtungsrichtung auf den Buchstaben verschiebt sich ständig. Aber Optimierungen sind noch drin.

Z.B. könnte der Zeichenzähler selbst in 2er Schritten inkrementiert/dekrementiert werden, um ein Shift Left zu ersparen usw. Feste Offsets können in die Daten reingerechnet werden. Dekrementierende Schleifen mit gespiegelten Bilddaten wären möglich (da der GDC mit WDAT nur inkrementell schreibt, soweit ich weiß). Usw.

Bspw. habe ich push hl und pop hl drin. Das sind zusammen schon 10% der aktuellen Iterationszeit bzw. 27% der Zielzeit für 40x25 fullscreen.

Falls aber die 80x25er (oder 80x50) optisch viel besser wären, ließe sich das Darstellungsfenster verkleinern.

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 04.01.2025 um 12:27 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

134
04.01.2025, 12:50 Uhr
HeikoS

Zitat:

Dresdenboy schrieb
@Heiko:
Der emulierte BIC gibt die GDC-Statusflags aus. Damit lässt sich das synchronisieren. ...
Matthias

Das ist oft so, aber ich bin nicht sicher, ob die Aktualisierung des FrameBuffers der Emulation synchron dazu erfolgt. Ich habe mal gelesen, dass die Aktualisierungsrate, die man einstellen kann im JKCEMU, manchmal wirkungslos ist, weil etwas anderes Vorrang hat. Müsste ich aber nochmal nachlesen. Beim JTCEMU ist das definitiv momentan nicht synchronisiert. Aber wie gesagt, es ist schon programmiert, aber noch nicht veröffentlicht.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

135
04.01.2025, 13:24 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Das ist oft so, aber ich bin nicht sicher, ob die Aktualisierung des FrameBuffers der Emulation synchron dazu erfolgt. Ich habe mal gelesen, dass die Aktualisierungsrate, die man einstellen kann im JKCEMU, manchmal wirkungslos ist, weil etwas anderes Vorrang hat. Müsste ich aber nochmal nachlesen. Beim JTCEMU ist das definitiv momentan nicht synchronisiert. Aber wie gesagt, es ist schon programmiert, aber noch nicht veröffentlicht.

Ah, verstehe. Gut zu wissen, dass da etwas in Arbeit ist. Vllt. schaue ich mir mal an, ob man da etwas unterscheiden kann (z.B. mit Bildschirmaufnahme), wenn auf VBLANK geachtet wird.

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

136
04.01.2025, 13:48 Uhr
HeikoS

Hier mal der Vergleich im JTCEMU:

Sprites MIT Synchronisierung des FrameBuffers mit VSYNC (BUSY-Signal im ES4.0)
PreView neue JTCEMU-Version X.X:

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

Sprites OHNE Synchronisierung des FrameBuffers mit VSYNC (BUSY-Signal im ES4.0)
JTCEMU 2.1:

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

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

137
04.01.2025, 15:19 Uhr
BICa5105

Zitat:

HeikoS schrieb
Hier mal der Vergleich im JTCEMU:

Sprites MIT Synchronisierung des FrameBuffers mit VSYNC (BUSY-Signal im ES4.0)
PreView neue JTCEMU-Version X.X:

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

Sprites OHNE Synchronisierung des FrameBuffers mit VSYNC (BUSY-Signal im ES4.0)
JTCEMU 2.1:

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

Grüße, Heiko

Schöne Demo für den JU-TE !!
Mit Synchronisation viel viel besser.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Dieser Beitrag wurde am 04.01.2025 um 15:20 Uhr von BICa5105 editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

138
04.01.2025, 16:35 Uhr
Dresdenboy

@Heiko:
Danke, schau ich mir mal an.

@alle:
Zur Erklärung des Bumpmapping-Effektes habe ich ein Bild erstellt.

Darin sieht man eine Oberfläche von der Seite, welche von einer Lichtquelle ("Sonne") beleuchtet wird. Es ist eine Punktlichtquelle, welche mit etwas Streuung von der Oberfläche reflektiert wird (grob angelehnt an Raytracing-Begriffe mit z.B. Phong-Beleuchtungsmodell). Das wird durch den Lichtstrahl visualisiert. Der Normalenvektor der Oberfläche bestimmt die Reflexionsrichtung.

Wenn dieses Phänomen auf einem Bildschirm dargestellt werden soll, wäre eine Möglichkeit, das Raytracing-Verfahren zu nutzen, wo von einer Kameraposition aus durch eine davor gespannte Bildebene Sichtstrahlen berechnet werden. Trifft ein Strahl eine Oberfläche, wird dessen Reflexion u. ggf. Diffuslichtanteil entspr. des Normalenvektors ermittelt. Wenn der weiter reflektierte Strahl keine weitere Oberfläche trifft, wird dessen Position ggüber. der Lichtquelle ausgewertet, um entspr. des Beleuchtungsmodells u. des reflektierenden Oberflächenmaterials die zu sehende Farbe und Helligkeit zu berechnen. Zusätzlich kann Umgebungslicht oder das anderer Lichtquellen mit berechnet werden.

Dieser ganze Aufwand wird für den Bumpmapping-Effekt stark vereinfacht, wo Voraussetzungen geschaffen werden, um alles schnell berechnen zu können u. dennoch einen ähnlichen optischen Eindruck zu erhalten:

1. Statt einer Lichtberechnung wird eine Lightmap verwendet, welche quasi ein Abbild der Lichtquelle u. deren Umgebung darstellt. Alternativ kann das auch z.B. ein Landschaftsbild sein. Dann würde sich dies im Bumpmapping reflektieren.

2. Die Kamera wird genau senkrecht über der Oberflächenbasis plaziert. Statt einem vorgegebenen Öffnungswinkel kann vereinfacht eine direkte 1:1-Abbildung auf die Lightmap erfolgen. Der gewünschte visuelle Eindruck wird durch die Parameter für die Erzeugung der Lightmap angepasst, z.B. die Größe der abgebildeten Lichtquelle mit Lichthof.

3. Die Reflexion am Normalenvektor wird nicht berechnet, sondern als Änderung eines senkrecht auf der Oberfläche stehenden Sichtstrahls in X- und Y-Richtung (oft wie bei Oberflächentexturen U und V genannt) fertig in der Bumpmap gespeichert. Das ist nicht genau sondern approximativ, aber reicht optisch aus. Schnellere Rechner könnten stattdessen aus Höhendaten der Oberfläche (das wäre eine Height Map) die Reflexionen berechnen, ggf. auch mit komplexeren Sichtstrahlen.

Umsetzung:
Somit benötigt man entspr. der Position auf dem Bildschirm eine Position je in der Bumpmap und eine Startposition in der Lightmap (einfach 1:1), berechnet die Position der Änderung in der Lightmap und nimmt den dortigen Wert für die Darstellung auf dem Bildschirm.

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 04.01.2025 um 18:41 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

139
06.01.2025, 11:47 Uhr
Dresdenboy

@Heiko:
Ich habe mal die Hauptschleife noch weiter optimiert. Wenn ich dann noch dazu wechsle, nur Farbattribute zu schreiben und die innere Schleife ausrolle, bin ich derzeit bei 59 T-States entspr. Tabelle. Das wäre zumindest theoretisch ausreichend für 40x25 Vollbildanimation.
Hier könnte es dann mit dem GDC-FIFO kritisch werden. Aber da gibt es Möglichkeiten, das Display einzuschränken für mehr Austastlücke.

Der Code sieht etwa so aus:

Quellcode:

LD      D,(HL)
INC     L
LD      E,(HL)
EX      DE,HL
ADD     HL,DE
LD      A,(HL)
OUT     (98H),A
EX      DE,HL
INC     L

Da muss ich noch die LUT-Berechnung anpassen.

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 06.01.2025 um 11:56 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

140
06.01.2025, 13:00 Uhr
HeikoS

@Matthias:
Ja, Display einzuschränken für mehr Austastlücke hattest Du ja selbst schon mehrfach vorgeschlagen bei diesen Themen. Wenn die Zeit nicht reicht, könnte man auch Berechnungen in der "non blank phase" machen und dabei Listen schreiben, die dann mit POP und OUT (98H),A in der "blank phase" in den VRAM geschrieben werden.

s. http://oldmachinery.blogspot.com/2014/04/zx-sprites.html

oder z.B.: Zeile 731: https://github.com/haykonus/JU-TE-6K-Sprites/blob/main/FCSL/FCSL.asm

in "write_sprite" ab Zeile 585 wird diese Tabelle dann benutzt.

Grüße, Heiko

Dieser Beitrag wurde am 06.01.2025 um 13:41 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

141
06.01.2025, 14:22 Uhr
Dresdenboy

@Heiko:
Vom Timing her kann man nochmal schauen u. z.B. mit vorhandenem sauberen Sync (erstmal auf VSYNC reicht) entsprechend ausarbeiten. Falls sogar eine Zeilensynchronisation klappt (sollte sehr stabil sein, damit man nicht so viele T-States mit Warten auf HBLANK bzw. Verschiebungen verschwendet. Dann ginge pro Zeile auch so etwas wie
- 16 (nehme ich an?) Iterationen direkt mit OUT (FIFO füllen)
- m Iterationen, welche zwischenspeichern u. das dann ausgeben
Das Ganze ginge vllt. noch mehrfach verzahnt.

Falls der Bildaufbau flackert, bleibt natürlich auch die Option des double bufferings.

Für die Ausgabe ginge auch POP DE: OUT (C),D: OUT (C), E (10+12+12). Für den ersten Schwung können mehrere Register auch schon vorbefüllt sein. Dann könnte durch die Verzögerung durch POP kein Problem mit dem FIFO-Füllstand sein. Das müsste ich dann entspr. checken oder einfach testen.

Der erste Link ist super detailliert - genau mein Geschmack.

Den hatte ich schon gebookmarkt, vllt. hattest du ihn schonmal gepostet und ich war da das letzte Mal noch nicht in die Tiefe eingestiegen.

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

142
07.01.2025, 16:16 Uhr
Dresdenboy

Ich habe schonmal überlegt, was die schnellste innere Schleife sein könnte, hier natürlich auch mit dem Stack, ausgerollt u. nur Farbattribute schreibend:

Quellcode:

    pop de       ; 10 delta to previous position
    add hl, de   ; 11 add delta to previous position to get current perturbed lightmap position
    ld a, (hl)   ; 7  get lightmap color value
    out (98h), a ; 11 write color value

Das wäre schon 5x so schnell wie die oberste gezeigte Variante.

Edit: Oder gleich in 37+? Zyklen (wäre tatsächlich die Hälfte von den 75 oben):

Quellcode:

    pop de       ; 10 delta to previous position
    add hl, de   ; 11 add delta to previous position to get current perturbed lightmap position, compensate outi
    outi         ; 16  get lightmap color value and write it
   ; outi         ; cheap way of doing char+attrib

@Heiko:
Ich denke natürlich auch schon über eine grafikbasierte Variante und ggf. mit kleinem Speicherverbrauch nach, damit es z.B. in einen Ju+Te 6k mit weniger RAM passt.

Da die obigen LUTs sehr groß sind, teils 128 Pixel breit (in 16b-Worten), um auch ein Byte-Alignment der Daten zu haben, wäre auch etwas wie 64x32 denkbar.

Fändest du so eine Umsetzung interessant? Wo sollten wir da starten?

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 07.01.2025 um 19:22 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

143
08.01.2025, 07:59 Uhr
HeikoS

Man muss da immer ganz schön "Erbsen" zählen, das macht ja auch am meisten Spaß, wenn man dann was gefunden hat. Der JuTe 6K hat 32 KB RAM oder sogar mehr, wenn man die ROM-Bereiche unter 8000h auch noch nutzt. Das ist gar nicht das Problem.

Die Sprites der FCSL sind alle "pre-shifted" und brauchen auch ganz schön RAM. Wenn man 8 Sprites wandern läßt, ist der RAM fast voll:

https://github.com/haykonus/JU-TE-6K-Sprites#speicherbelegung

Aber der Z8 braucht wesentlich mehr Zyklen im Vergleich zum Z80. Er hat ja auch wesentlich weniger 16-Bit-Befehle. GleEst läuft nun auch schon auf dem JuTe 6K. Der Core-Algorithmus in der 1:1 Portierung ist ca. doppelt so lang, es ist aber immer noch ausreichend schnell.

Z8: 142h (322) Bytes
Z80: 9Ah (154) Bytes

Das werde ich bald mal zeigen und auf GitHub stellen. Da ist es auch interessant, welche Unterschiede und Gemeinsamkeiten es zw. den Prozessoren gibt. Der Arnold-Macro-Assembler hat wieder unschätzbare Dienste geleistet ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

144
08.01.2025, 08:28 Uhr
Dresdenboy

@Heiko:
Die Zählerei (Zyklen oder Bytes) und Kombiniererei ist ja genau der Reiz in manchen Programmiersparten, speziell auch Sizecoding. Wobei dann eher kein Z8 in Frage käme - es sei denn, bestimmte Dinge bekommt man gut mit dieser Architektur hin.

Da kenne ich von Vince Weaver ("deater") eine spannende Seite dazu. Er ist ein Apple ][ Enthusiast auch im Bereich Sizecoding (welcher uns mal eine persönliche Videobotschaft von Steve Wozniak für eine Demoparty verschafft hat) und Prof. an der Uni Maine. Bei ihm findet man z.B. auch einen interessanten Vergleich von kleinen Algorithmen (strcat, LZSS-Dekomprimierung u. ein ganzes kleines Programm für das Linux Logo) auf aktuell 33 Befehlsarchitekturen auf 31 Prozessoren. Nicht wundern, falls es wg. Zertifikat meckert: http://www.deater.net/weave/vmwprod/asm/ll/ll.html

Dort fehlt noch der Z8.

Ich bin da auch mal drauf gekommen, da ich seit Jahren auch für x86 und Z80 (und vllt. auch bald 6502) an den kleinsten brauchbaren Dekompressionsroutinen der Welt für Sizecoding arbeite

.

Da ich gar nicht so im Bilde zum Z8 bin, habe ich mal kurz hier reingeschaut:
https://en.wikipedia.org/wiki/Zilog_Z8
und finde natürlich welchen einzigen Emulator genannt? Den JTCEMU.

Dieser Beitrag wurde am 09.01.2025 um 08:24 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

145
08.01.2025, 09:09 Uhr
ralle

Einen direkten Z8-Computer gibt es ja eigentlich nicht. Außer der Ju+Te.

Alle anderen Z8-Anwendungen sind auf der Steuerungstechnik. Also ohne Bildausgabe.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

146
08.01.2025, 23:32 Uhr
HeikoS

GleEst auf KC85/4 und Ju-Te 6K im Duett ...

Video: https://nextcloud-ext.peppermint.de/s/Jnw6gTtq3o6ZwNa

Dieser Beitrag wurde am 08.01.2025 um 23:32 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

147
09.01.2025, 00:18 Uhr
HeikoS

Zitat:

ralle schrieb
Einen direkten Z8-Computer gibt es ja eigentlich nicht. Außer der Ju+Te.

Alle anderen Z8-Anwendungen sind auf der Steuerungstechnik. Also ohne Bildausgabe.

Genau deshalb mag ich den JuTe 6K. Er ist quasi weltweit ein Unikat bzgl. der Anwendung des Z8 in einem Home-Computer. Die Grafik ist besser als bei vielen anderen Rechnern der DDR und als Eigenbau-Projekt ein eher geringer Aufwand beim Aufbau ... tolle Idee damals. Da wäre sicher noch viel entstanden ...

EDIT:
Hier kann man die Original-Artikel lesen:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22382

Dieser Beitrag wurde am 09.01.2025 um 07:55 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

148
09.01.2025, 12:11 Uhr
Dresdenboy

Zitat:

HeikoS schriebGenau deshalb mag ich den JuTe 6K. Er ist quasi weltweit ein Unikat bzgl. der Anwendung des Z8 in einem Home-Computer. Die Grafik ist besser als bei vielen anderen Rechnern der DDR und als Eigenbau-Projekt ein eher geringer Aufwand beim Aufbau ... tolle Idee damals. Da wäre sicher noch viel entstanden ...

Spannende Situation. Wie schnell kann ich mir die CPU vorstellen? Ich sehe 8 MHz und in der Doku z.B. dann für das schnellere ADD 6 Fetch + 5 Execute Cycles, wo meist noch 3 Pipeline-Zyklen abgezogen werden können. Rechne ich da richtig, dass ich so z.B. mit ADD hinter ADD von 8 Zyklen, also 1 µs ausgehen kann? Das wäre dann ja Z80@4 MHz-Niveau (nur für A,r). Ein Vorteil ggüber. Z80 und 6502 scheint mir zu sein, dass ich mit dem großen Register File nicht so viel über einen Akkumulator oder Speicher arbeiten muss.

@all:
Für alle Rechner mit dem U82720 wäre ein schneller 160x100-Grafikmodus auf Basis des Textmodus' mit dessen Attributen möglich. Hier ein mögliches Realisierungsbeispiel (Neudeutsch: Proof of Concept = POC) für den BIC (Zeile 90 geht nur auf echtem BIC oder im MAME-Emulator, welcher wiederum keine Hintergrundfarben kann, Rest geht im JKCEMU):

Quellcode:

10 SCREEN 1
20 FOR I%=0 TO 1999:PRINT CHR$(221);:NEXT I%: REM halber Block
40 OUT &H99,&H49:OUT &H98,0:OUT &H98,0 : REM CURS - Startadresse 0
50 OUT &H99,&H4A:OUT &H98,0:OUT &H98,&HFF : REM MASK - nur Attributbyte schreiben
60 OUT &H99,&H38: REM WDAT - nur Attributbyte schreiben
70 V%=0
80 FOR I%=0 TO 1999:OUT &H98,V% AND &HEF:V%=V%+1:NEXT I%
90 OUT &H99,&H4B:OUT &H98,&H03 : REM CCHAR
100 IF INKEY$="" THEN GOTO 100: REM wait

Vorteil: Für 16000 Pixel müssten nur 8000 Bytes geschrieben werden bei halbfreier Farbwahl (Vordergrund alle 16, Hintergrund 8 dunklere, was bei Nutzung des invertierten Zeichens ggf. ausgeglichen werden kann).

Edit: Für eine freiere Farbwahl wäre natürlich auch eine flexible Nutzung der Halbblockzeichen (linke bzw. rechte Hälfte gefüllt) nötig. Um das nicht separat speichern zu müssen, könnte einfach das eh nicht hilfreiche Blinken-Bit genutzt werden, welches dann nur einmal getestet werden muss bzgl. des Zeichens, danach aber drin bleiben kann und per Maske ignoriert wird.

Zumindest wären kleine Animationen denkbar (nicht nur Vollbilder, sondern z.B. auch blockweise neu geschriebene Bildbereiche).

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 09.01.2025 um 14:55 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

149
09.01.2025, 13:11 Uhr
HeikoS

Zitat:

Dresdenboy schrieb

Zitat:

Extern bekommt der Z8 im JuTe 8 MHz, intern läuft er mit 4 MHz. Ich bin immer davon ausgegangen, dass er schon mit einem 4 MHz Z80 vergleichbar ist. Aber davon haben z.B. "jutetom", "Bert", "volkerp" sicher mehr Erfahrung, vor allem was das Pipelining angeht.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

150
09.01.2025, 14:08 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Extern bekommt der Z8 im JuTe 8 MHz, intern läuft er mit 4 MHz. Ich bin immer davon ausgegangen, dass er schon mit einem 4 MHz Z80 vergleichbar ist. Aber davon haben z.B. "jutetom", "Bert", "volkerp" sicher mehr Erfahrung, vor allem was das Pipelining angeht.

Danke. Das reicht mir schon als Info. Da sind also keine Geschwindigkeitswunder zu erwarten.

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

151
11.01.2025, 10:16 Uhr
Bert

Geschwindigkeitswunder sind vom Z8 sicher nicht zu erwarten, aber viele Algorithmen sollten sich effektiver umsetzen lassen, da man einfach mit allen Registern rechnen kann.
Es entfallen die Umladeoperationen, wie sie beim Z80 noch nötig sind.

Hier dürfte aber der spezielle Aufbau des Bildspeichers beim JuTe-6k das Hindernis darstellen.
Es kann zwar jedes Pixel eine von 16 Farben annehmen, aber dazu ist i.d.R. der Zugriff auf mehrere bzw. alle vier Farbebenen nötig.

Bei Einzelpixelzugriffen wird das recht aufwendig:
1. Bestimmen der Speicherposition (8 Pixel liegen jeweils nebeneinander)
2. Auswählen Ebene 0 (6000h = 10h)
3. Setzen/Löschen des entsprechenden Bits (V/H)
4. Auswählen Ebene 1 (6000h = 20h)
5. Setzen/Löschen des entsprechenden Bits (blau)
6. Auswählen Ebene 2 (6000h = 40h)
7. Setzen/Löschen des entsprechenden Bits (grün)
8. Auswählen Ebene 3 (6000h = 80h)
9. Setzen/Löschen des entsprechenden Bits (rot)

Beim Schreiben kann man mehrere Ebenen aktivieren, aber beim Lesen jeweils nur eine, sonst kommt es zu Datenkollisionen auf dem Bus.

Einfach wird es, wenn man 8 nebeneinanderliegende Pixel auf schwarz haben möchte:
1. Bestimmen der Speicherposition (8 Pixel liegen jeweils nebeneinander)
2. Auswahl aller Ebene (6000h = F0h)
3. Löschen aller Bits

Einzelne Optimierungen sind da natürlich möglich.
Auch könnte man z.B. einfarbige Sprites (rot/grün/blau) verwenden, die unabhängig voneinander in ihrer jeweiligen Farbebene gezeichnet werden können.

Korrigiert mich, wenn ich falsch liege, ich habe bei der Programmierung des Z8 bzw. JuTe-Computers fast immer den ZDS-C-Compiler genutzt und dabei auf die Funktionen des Monitors zurückgegriffen.

Viele Grüße,
Bert
--
Viele Grüße,
Bert

Dieser Beitrag wurde am 11.01.2025 um 10:16 Uhr von Bert editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

152
11.01.2025, 15:02 Uhr
Dresdenboy

@all
Besteht vllt. Interesse an ausreichend schneller 3D-Grafik für die DDR-Rechner?

@Bert
Danke für die Erläuterungen. In die Richtung, etwas mit den Bildebenen zu machen, klingt sinnvoll und kann auch schöne Effekte ermöglichen.

Auch könnte man mit entspr. selektierten Ebenen sehr schnell verschiedenfarbige horizontale Linien zeichnen. Wenn für Anfangs- und Endbyte mit Maske gearbeitet wird und für die Bytes dazwischen einfach alle Bits gesetzt bzw. gelöscht werden, wäre das vllt. die Basis für eine Routine für gefüllte Dreiecke. Damit wäre 3D-Grafik denkbar.

Wie gut ist der ZDS-C-Compiler? Nutzt den noch jemand weiteres hier?

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

153
11.01.2025, 23:09 Uhr
HeikoS

Finale ! Die "GleEst-ifizierung" der DDR-Home-Computer soll damit erstmal beendet sein.

GleEst für den JuTe-6K ist nun auch auf GitHub:

https://github.com/haykonus/JU-TE-6K-Demos?tab=readme-ov-file#gleest

Eigentlich wollte ich ja GleEst nur für den JuTe-6K portieren. Aber um es besser zu verstehen und ein Gefühl für den Algorithmus zu bekommen, fiel mir die schöne Grafik-Demo für den Z1013 von Dietmar (u-held) ein. Und die erste gelungene Portierung war dann für den Z1013. Dann sind noch die KC85/1/3/4 und der BIC dazu gekommen.

Interessant war die Umsetzung mit Z80-Macros im Arnold-Assembler auf den Z8. Ich hatte tatsächlich schon früher mal angefangen, nur den Befehl LD als Macro umzusetzen. Ein unglaulicher Aufwand ... aber für GleEst hat dann nicht mehr viel gefehlt. Sicher nicht optimal, aber es funktioniert. Im GitHub habe ich das auch genau erklärt inkl. einer Kritik dazu. Da würden mich mal Eure Meinungen dazu interessieren. Man könnte ja auch eine echte Grammatik mit Lex und Yacc aufbauen? Aber ob es loht, damit bestehenden Z80-Code zu portieren? Wahrscheinlich eher nicht. C und andere Sprachen sind da schon interessanter!

@Bert zu <151>:

Hervorragend zusammengefasst aus meiner Sicht! Da der Video-Speicher des JuTe-6K nicht gerade optimal aufgebaut ist, sind alle Programmierungen für schnelle Effekte eine Herausforderung. Für GleEst hab ich das hier mal beschrieben. Erstaunlich, dass es dann doch bei vielen Grafik-Effekten noch so schnell ist. Vielleicht spielt da auch das Thema Pipelining mit rein, da kenne ich mich aber wenig aus.

Deine Versuche mit C auf dem JuTe fand ich sehr interessant, bin aber dann doch noch nicht dazu gekommen das mal auszuprobieren. Das mache ich aber auf jeden Fall noch! Sehr gute Vorarbeit!

@Matthias:

3D-Gafik wäre sicher sehr interessant. Da könntest Du ja auf dem BIC mal was machen im Monochrom-Mode. Da wären ja die GDC-Befehle nutzbar.

Viele Grüße, Heiko

Dieser Beitrag wurde am 12.01.2025 um 23:06 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

154
16.01.2025, 16:13 Uhr
HeikoS

Für alle Freunde des JuTe-6K, hier noch ein GleEst-Update:

https://github.com/haykonus/JU-TE-6K-Demos/tree/main/GleEst

EXX/SRP und einige PUSH/POP-Befehle wurden eingespart durch Nutzung aller 16 Z8-Register in einem Registersatz. Ist noch schneller geworden :-)

Viel Spaß beim Testen !

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

155
17.01.2025, 11:45 Uhr
Dresdenboy

@Heiko:
Sehr cool. Du wärst mit diesem Enthusiasmus, noch mehr herauszuholen, ein super Democoder!

@all:
Falls ihr mal schnell Kreise und andere schöne Dinge zeichnen wollt, solltet ihr mal den Minsky-Circle-Algorithmus anschauen. Damit lässt sich auch schnell mit ein paar Adds und Shifts eine Sinus-Welle erzeugen, z.B. für eine Sinus-Tabelle. Das wird dank der einfachen Berechnung auch gern im Sizecoding genutzt.

Die Berechnung eines weiteren Punktes auf einem Kreis mit Radius r (womit z.B. x oder y initialisiert wird, während die andere Variable bei 0 startet) um den Kreismittelpunkt (0,0) sieht so aus:

Quellcode:

    while(true)
    {
        x += d * y;
        y -= d * x;
    }

Das kann hier direkt ausprobiert werden: https://cabezal.com/misc/minsky-circles.html

Spannend für 8-bit-Rechner ist eher eine Festkomma-Variante, die sich leicht in Assembler oder auch BASIC oder Turbo Pascal umsetzen lässt.

Das kann schon so aussehen:

Quellcode:

  y -= x >> 4;
  x += y >> 4;

bzw. auf Byte-Basis:

Quellcode:

  y -= x >> 8;
  x += y >> 8;

Wenn man Grafikeffekte programmiert, kann es hilfreich sein, mit möglichst vereinfachten Varianten zu experimentieren und zu schauen, was man damit hinbekommt, anstatt eine generische, alle Fälle abdeckende Lösung mit viel Code zu nutzen.

Etwas mehr Hintergrund-Informationen u. auch weitere Ideen dazu findet ihr hier:
https://nbickford.wordpress.com/2011/04/03/the-minsky-circle-algorithm/

Hier ist mal ein Beispiel in Turbo Pascal auf dem BIC mit der Turbo Graphix Bibliothek:

Quellcode:

program Kreis;
{$I grbs.bic} { Include }

var x : integer;
    s,c,sh,ch : integer;

begin
    InitGraphic; {Grafik initialisieren}
    Graphic_mc;  {320x200 in 16 Farben}
    ColorGlb := 10;

{ Kreis in feiner Aufloesung }
    s:=80 shl 8;   {Startwert fuer Sinus-Anteil als Festkommazahl}
    c:=0;          {Startwert fuer Cosinus-Anteil}
    for x:=0 to 401 do             { pi/2*256 Schritte }
    begin
        sh:=hi(s);                 { oberes Byte }
        sh:=sh-(sh AND 128) shl 1; { Vorzeichenkorrektur }
        c:=c-sh shl 2;             { neuer Cosinus-Wert }
        ch:=hi(c);                 { oberes Byte }
        ch:=ch-(ch AND 128) shl 1; { Vorzeichenkorrektur }
        s:=s+ch shl 2;             { neuer Sinus-Wert }
        dp(ch+160, sh+100);        { Pixel setzen }
    end;                                                                        

{ Kreis in grober Schrittweite }
    s:=40 shl 8;   {Startwert fuer Sinus-Anteil als Festkommazahl}
    c:=0;          {Startwert fuer Cosinus-Anteil}
    for x:=0 to 100 do             { pi/2*64 Schritte }
    begin
        sh:=s shr 6;
        sh:=sh-(sh AND 512) shl 1; { Vorzeichenkorrektur }
        c:=c-sh shl 2;             { neuer Cosinus-Wert }
        ch:=c shr 6;
        ch:=ch-(ch AND 512) shl 1; { Vorzeichenkorrektur }
        s:=s+ch shl 2;             { neuer Sinus-Wert }
        dp((ch+(160 shl 2)) shr 2, (sh+(100 shl 2)) shr 2); { Pixel setzen }
    end;                                                                        

    readln;                        { auf Enter warten }
    LeaveGraphic;
end.

Hier muss man wieder mit den nur logischen Bitshifts aufpassen, die kein Vorzeichen beibehalten. Aber statt der IF-THEN-Lösung habe ich nun eine rechnerische ohne Sprünge umgesetzt. In Assembler ist das mit SRA nicht nötig.

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.01.2025 um 11:49 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

156
21.01.2025, 07:49 Uhr
HeikoS

Sehr interessant! Welche Algorithmen werden denn so in den einzelnen Rechnern für den Circle-Befehl verwendet? Das wäre ein interessanter Vergleich. Ob es so etwas schon gibt?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

157
21.01.2025, 14:30 Uhr
Dresdenboy

@Heiko:
Da ist der Bresenham-Algo sicher am verbreitetsten. Minsky Circle kann ich mir eher nur bei Lösungen mit wenig Platz für Code vorstellen, wo die Zeit vllt. egal ist.

Beim Spiel "Elite" wirkten die Kreise etwas mehr wie Polygone mit vielen Eckpunkten. Da fiel mir gerade ein, dass es da ja schon Analysen gibt. Die gibt es für BBC Micro hier:
https://elite.bbcelite.com/deep_dives/drawing_circles.html mit Startseite hier mit Links zum BBC-Code: https://elite.bbcelite.com/
und weiterem Sourcecode (C64-Version) hier:
https://github.com/Kroc/elite-harmless/blob/kroc/src/draw_circles.asm

Videos gibt es auch (weniger für Circles, aber generell für die Optimierungen in 3D-Grafik): https://www.youtube.com/watch?v=lC4YLMLar5I

Das ist dann schon sehr fortgeschritten. Sozusagen Elite-Code.

Aber mit Bresenham kommt man schon recht weit.

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 21.01.2025 um 14:31 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

158
21.01.2025, 17:38 Uhr
ralle

Für den Z1013 nicht uninteressant: https://www.z1013.mrboot.de/software-database/db/5e02d0cbd66c6266bafefa67e767996a-C.HUNDI/index.html

Ein animierter Hund rennt über die Wiese. Die Tage entdeckt, beim Befüllen der SD-Card.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

159
21.01.2025, 17:57 Uhr
Dresdenboy

Zitat:

ralle schrieb
Für den Z1013 nicht uninteressant: https://www.z1013.mrboot.de/software-database/db/5e02d0cbd66c6266bafefa67e767996a-C.HUNDI/index.html

Ein animierter Hund rennt über die Wiese. Die Tage entdeckt, beim Befüllen der SD-Card.

Das ist echt gut. Vermutlich sind die Einzelbilder auch alle von Hand konstruiert mit den Zeichen.

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

160
21.01.2025, 18:28 Uhr
ralle

Läuft auch auf der Originalen Hardware recht flüssig.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

161
22.01.2025, 10:45 Uhr
HeikoS

Der animierte Hund gefällt mir gut ! Das hat jemand sehr geschickt zusammengestellt.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

162
22.01.2025, 22:33 Uhr
HeikoS

Ja, den Bresenham-Algo habe ich jetzt schon oft entdeckt in den Circle-Routinen. Elite ist sehr interessant ... alles im Detail beschrieben mit sehr vielen Infos. Leider alles 6502. Müsste man auf den Z8 portieren ;-))))

Grüße, Heiko

EDIT: Wurde ja schon auf einige andere Rechner portiert ...

https://www.ricardopinto.com/2022/09/19/interview-about-elite-z80-conversions/

Zitat:

Dresdenboy schrieb
@Heiko:
Da ist der Bresenham-Algo sicher am verbreitetsten. Minsky Circle kann ich mir eher nur bei Lösungen mit wenig Platz für Code vorstellen, wo die Zeit vllt. egal ist.

Beim Spiel "Elite" wirkten die Kreise etwas mehr wie Polygone mit vielen Eckpunkten. Da fiel mir gerade ein, dass es da ja schon Analysen gibt. Die gibt es für BBC Micro hier:
https://elite.bbcelite.com/deep_dives/drawing_circles.html mit Startseite hier mit Links zum BBC-Code: https://elite.bbcelite.com/
und weiterem Sourcecode (C64-Version) hier:
https://github.com/Kroc/elite-harmless/blob/kroc/src/draw_circles.asm

Videos gibt es auch (weniger für Circles, aber generell für die Optimierungen in 3D-Grafik): https://www.youtube.com/watch?v=lC4YLMLar5I

Das ist dann schon sehr fortgeschritten. Sozusagen Elite-Code.

Aber mit Bresenham kommt man schon recht weit.

VG,
Matthias

Dieser Beitrag wurde am 22.01.2025 um 23:03 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

163
23.01.2025, 07:23 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
EDIT: Wurde ja schon auf einige andere Rechner portiert ...

https://www.ricardopinto.com/2022/09/19/interview-about-elite-z80-conversions/

Vielleicht brauchst du nun das hier? https://skoolkit.ca/docs/skoolkit-8.10/diy.html

Edit: Auf dem CPC gab es schon Aktivitäten, vllt. ist auch irgendwo etwas veröffentlicht. Zumindest gibt es ein paar Code Snippets, sogar aus der Circle-Routine.

https://www.cpcwiki.eu/forum/programming/expanding-elite/50/

Und lt. dem ersten Kommentar zu diesem Beitrag hier ist Kroc Camen gerade dabei, Elite für den Spectrum zu disassemblieren: https://universeodon.com/@markmoxon/113579875776007495
Das landet vllt. dann hier: https://github.com/Kroc

Obwohl ich mich natürlich frage, ob dir Z80-Code so viel mehr helfen würde als 6502. Am Ende muss ja eh alles für den Z8 neu aufgesetzt werden.

P.S.: Ich erinnere mich noch, wie ich beim ersten Anspielen von Elite (war glücklicherweise mit auf den kopierten Disketten (!), die ich von meinem in den Westen gezogenen Opa zum C64+1541 mit erhielt) echt erstaunt war über die Geschwindigkeit der Zeichenroutinen. Bis dahin kannte ich vmtl. eh nur Zeichenprogramme mit Kreisfunktionen und BASIC-Erweiterungen.

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 23.01.2025 um 08:48 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

164
23.01.2025, 14:58 Uhr
HeikoS

3D-Gerippe mit Rotations-Matrix zu drehen inkl. 3D-2D-Projektion war "Assembler-Sport" in den 80'ern. 87/88 haben wir in Breitenbrunn (TU-KMSt) so etwas auch auf einem KC85/3 gemacht - eine Pyramide. Das hat nur stark "gekrieselt" auf dem Bildschirm - die bekannten Störungen waren wirklich störend. Aber wir waren begeistert ! ... Elite kannte ich damals nicht ... die Spieleentwickler beim Klassenfeind waren bei den Ballerspielen wirklich sehr kreativ. Auf dem C64 hatte ich damals einiges gesehen.

Portierungen auf den Z8 aus Z80-Code wäre nicht sinnvoll. Dann schon eher einen 6502-to-Z8 Compiler bauen - oder wenigstes mit Macros eine "Portierhilfe" nutzen. Aber was bringt das und so viel Zeit hat ja niemand. Aber man könnte die schnellen Line/Circle-Routinen implementieren, die Definitionen der Raumschiffe übernehmen und die mal rotieren lassen ;-) ... beim JuTe-6K könnte man das auch mehrfarbig machen ... oh mann, soviel Stunden hat der Tag leider nicht.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

165
23.01.2025, 15:18 Uhr
Dresdenboy

@Heiko:
Die 3D-Thematik können wir hier wieder aufgreifen. Gerade die spannenden Kompromisse zw. schnell und genau oder zugeschneiderten und vielseitigen Lösungen kann hier mal besprochen und sicher auch ausprobiert werden. Jetzt kennt man die Konkurrenz ja besser.

Bzgl. Portierung: Da sehe ich auch nicht so viel Nutzen im Vergleich zum Aufwand in einer Art Übersetzungstool. Da die Algos bekannt sind, ist eine auf dem leeren Blatt gestartete Implementierung wohl am Ende am effizientesten.

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

166
25.01.2025, 20:13 Uhr
BICa5105

...
Ich habe ein paar kleine Animationen für den BIC A5105 erstellt.
Sind alle im Textscreen 0.

Damals konnte man auch schon GIF's ... ;-)

Hier alles zusammen in einem kurzen Video:
https://youtu.be/EDOAKyhjoEo

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Dieser Beitrag wurde am 25.01.2025 um 21:05 Uhr von BICa5105 editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

167
25.01.2025, 21:48 Uhr
HeikoS

@Cornelius:
Sieht super aus ! ... Spielt die Musik auch der BIC ab ?

@Matthias:
Hab schon mal eine sehr schnelle PSET/PCLR (Pixel set/clear) Funktion am JuTe-6K gebaut, mit der von links nach rechts Rauten (immer ein volles Viereck) mit Zoom-Schrittweite von 5 in 14 Schritten gezeichnet/gelöscht werden.

Da könnte man noch einen schnellen Line- und Circle-Befehl dazu bauen.

Zum Vergleich: PLOT aus ES4.0:

Grüße, Heiko

Dieser Beitrag wurde am 25.01.2025 um 22:56 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

168
26.01.2025, 12:52 Uhr
BICa5105

Zitat:

HeikoS schrieb
@Cornelius:
Sieht super aus ! ... Spielt die Musik auch der BIC ab ?

Grüße, Heiko

Nein im Video nicht. Die Musik ist nur hinzugefügt.

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

169
26.01.2025, 13:20 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
@Matthias:
Hab schon mal eine sehr schnelle PSET/PCLR (Pixel set/clear) Funktion am JuTe-6K gebaut, mit der von links nach rechts Rauten (immer ein volles Viereck) mit Zoom-Schrittweite von 5 in 14 Schritten gezeichnet/gelöscht werden.

[Bild]

Da könnte man noch einen schnellen Line- und Circle-Befehl dazu bauen.

Ja, auf jeden Fall, falls schon bei der PSET-Routine so viel herauszuholen ist. Idealerweise sollten Circle- und Line-Routinen mit spezialisiertem Code für das Pixel setzen arbeiten. Z.B. Falls Bresenham oder ein DDA-Linien-Algorithmus von links nach rechts in einem Oktanten eine Linie zeichnet, wobei in jeder Schleifeniteration die X-Position um 1 erhöht wird, kann z.B. ein Bitmuster einfach geschoben werden.

Oder falls PSET etc. eine Überprüfung auf den Bildbereich enthält, kann man sich das sparen, wenn das für eine Linie schon woanders geprüft wird.

Edit: Ich war zufällig mal wieder über die 8bit-Workshop-Seite gestolpert und schaute mal kurz rein, ob es neue Systeme oder Beispiele gibt. Da gibt es z.B. ein in C geschriebenes Beispiel für den MSX mit dem Bresenham-Algorithmus für Linien: https://8bitworkshop.com/v3.12.0/?platform=msx-libcv&file=lines.c

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 26.01.2025 um 14:31 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

170
26.01.2025, 14:30 Uhr
volkerp
Default Group and Edit

Zitat:

volkerp schrieb
Hier im Forum gab es das „wormhole“,

Sorry, das war nicht wormhole, sondern Psycho:

https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=16375
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

171
26.01.2025, 22:27 Uhr
HeikoS

Tolle Animationen ! Sehr gut gefällt mir Psycho für den KC87 ...

EARTH.KCC konnte ich nicht starten.

Die Beschreibung sieht auch komisch aus ... kann man das noch irgendwo laden ?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

172
27.01.2025, 10:00 Uhr
Dresdenboy

PSY87 ist ein weiterer richtiger Demoeffekt. Im von Volker verlinkten Thread schlug maleuma auch die Umsetzung auf HRG vor. Keine Sorge, ich werde das nicht machen

, aber hätte da eine Idee, was die Flüssigkeit der Grafik anbelangt und was auch mit farbattributbasierten Systemen denkbar wäre. Hier mal 3 Ansätze für solcherart Animationen (kennen viele sicherlich auch):

1. Farbpalettenrotation: Das wäre sehr einfach umzusetzen, aber nur für wenige Systeme geeignet, z.B. auch den BIC.

2. Farbattribute modifizieren: Mit entspr. Vorkerhungen (z.B. nicht zu dicht liegende Farbwechsel) könnten Farbattribute im einfachsten Fall nur hin- und hergeschaltet werden oder man schreibt da auch Verläufe rein, z.B. (wo es der Farbraum hergibt), rot+gelb, gelb+gelb, gelb+rot, rot+rot. Ausgefeilter wären auch komplette Farbattribut-Bilder möglich.

3. Falls man wirklich an die Pixel ran muss, ließe sich für die Bildwechsel jeweils die Veränderung ermitteln, wo man dann pro Update mit z.B. Adresslisten oder gleich entspr. großem (generierten) Code für jede Adresse und mit passenden Bit-Operationen die entspr. Pixel verändert. Bei größeren gleichfarbigen Flächen ist dann immer noch flüssige Animation möglich.

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

173
27.01.2025, 20:52 Uhr
kaiOr

Danke! Was ich da treibe/trieb ist eine Art Video-Playback und frisst viel Speicher. Die Bilddaten liegen mundfertig für den Z80 im RAM und müssen nur noch schnell abgespult werden. Ich schreibe dabei pro Bild immer den kompletten Pixel- (oder Zeichenspeicher) neu. Nur in PSYX.KCC werden einige gegenüber dem Vorbild unveränderte Bildbereiche übersprungen, rentiert sich aber kaum.
Die Idee nur die jwl. Änderungen ausgehend von einem Schlüsselbild zu verarbeiten klingt gut, lohnt sich aber nur wenn sich auf dem Bildschirm relativ wenig tut. Ist nur ein Pixel anders muss das ganze Byte neu. Die Fallentscheidung dazu, dann den Stackpointer umsetzen oder den entrollten LDIR stückeln und mit neuer Adresse weiterlaufen lassen kostet viele Takte.

Die KC87-Variante entstand im Hauruck-Verfahren. Der könnte tatsächlich noch etwas schneller. ^^

Den "psychedelischen Wirbel" bzw. die Bilddaten aus einer Formel zu ziehen wäre richtig cool.

Grüße,
Kai

Dieser Beitrag wurde am 27.01.2025 um 20:57 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

174
28.01.2025, 11:25 Uhr
HeikoS

@KaiOr:
Das ist wirklich alles sehr gut gelungen. Wie hast Du denn die Bilder erzeugt für das Video-Playback? Ich wollte auch das Programm EARTH.KCC mal anschauen, kann es aber nicht laden von hier:

<000> https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=16375

-> http://robotron.webhop.net/files/kc/earth.kcc

Hast Du das noch irgendwo? Auch der Link zum KC-Club bei der TU-Dresden geht nicht mehr. Ist das irgendwo gesichert worden ?

https://www.iee.et.tu-dresden.de/~kc-club/09/RUBRIK01.HTM
War ein Tipp von Bert im Sept. 2024.

Grüße, Heiko

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

175
28.01.2025, 13:11 Uhr
Bert

Zitat:

HeikoS schrieb
Auch der Link zum KC-Club bei der TU-Dresden geht nicht mehr. Ist das irgendwo gesichert worden ?

Bei archive.org:
https://web.archive.org/web/20240528041930/https://www.iee.et.tu-dresden.de/~kc-club/09/0900.HTML#FILES

Ansonsten hatte ich die Seite auch auf meine Platte gespiegelt.

Viele Grüße,
Bert
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

176
28.01.2025, 13:48 Uhr
Dresdenboy

@kaiOr:
Noch schneller wäre vielleicht schon zu schnell.

Es sieht auch sehr cool aus, wenn es etwas langsamer läuft (z.B. mit halbem Takt im JKCEMU). Das wäre z.B. etwas, wo man mit niedrigeren Anforderungen an die Änderungsrate mehr Aufwand in eine langsamere weiche Bewegung stecken könnte. Aber das ist natürlich auch Arbeit und lohnt sich sicher nur mit einem Ziel, z.B. eine größere Demo zu produzieren.

Die Schwierigkeiten der Fallunterscheidung würde ich z.B. in den highlevel Code verlagern, der die Daten für den KC erzeugt. Vllt. könnte dort dann auch die Abarbeitung der Entscheidung vereinfacht werden, z.B. mit einer Liste von Sprungadressen zusätzlich zu den Daten oder zumindest ein simpler Algorithmus. So könnte man etwa so etwas als Liste von 16b-Werten ablegen, die dann per RET und POP verarbeitet werden könnten. Die verarbeitenden Routinen müssten dann einfach zum Beginn der Verarbeitung direkt zurückspringen. Bspw. sollen N Worte in den Bildspeicher kopiert werden, wobei die Worte mit auf dem Stack liegen:

Quellcode:

<Startadresse Bildsegment -> DE>
<Adresse Routine um N Worte zu kopieren für RET>
<Wort 1>
<Wort 2>
...
<Wort N>
<Startadresse Bildsegment -> DE>
<Adresse Routine um M Worte zu kopieren für RET>
<M Worte>
...

Die Routine zum Kopieren könnte auch einfach ausgerollter Code zum blockweisen Kopieren Stack -> Stack sein, der mit einem Sprung zum "Dispatcher" endet, je nach Bedarf in Varianten für unterschiedliche Blockgrößen. Der Dispatcher könnte so aussehen:

Quellcode:

.dispatcher:
  pop de
  ret

Auch ginge die Ablage von (DE) und (Hl) um dann in einen ausgerollten LDI-Block zu springen. Vermutlich ist das auch hier und da im Einsatz, aber ich kenne kaum Details von Z80-basierten Demos, eher x86, Amiga, C64 usw.

Und da gäbe es sicher noch mehr, auch platzsparendere Varianten. Bildupdates sollten oft auch in rechteckigen Bereichen (oder mit Skew für schräge Bereiche) erfolgen, um den Overhead für die Adressen und Aufrufe zu minimieren.

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 28.01.2025 um 13:58 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

177
28.01.2025, 14:54 Uhr
Dresdenboy

Also der nur 985 kHz schnelle C64 kann auch ganz schön schnell zeichnen

https://8bitworkshop.com/v3.12.0/?platform=c64&file=tgidemo.c

Ansonsten sind da auch sehr viele Demo-Effekte in den C64-Beispielen. Oft sogar mit viel C-Code-Anteil und immer weniger Assembler. Die neuen Zeiten lassen grüßen (sagte er, während der C64 emuliert in einer online Entwicklungsplattform lief...).

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

178
28.01.2025, 18:59 Uhr
Dresdenboy

@kaiOr:
Ich habe mal im Sizecoding-Discord in der Z80-Ecke nachgefragt. Da gab es von Neon/Darklite und Baze/3SC die Bestätigung, dass das eine oft in Demos genutzte Technik ist, quasi die gute Form des aus dem von Malware bekannten Return Oriented Programming (sagt mir zumindest auch etwas). Ich vermute mal, dass Crawler das auch kennt.

Wer da schon angemeldet ist, kann direkt hier mitlesen. Unter "Discussions" gibt es hier einen Discord-Invite-Link: http://www.sizecoding.org/wiki/Resources

@Heiko:
Baze erwähnte auch das Zeichnen von Sprites mit der Methode. Da musste ich an deine Lib und den Artikel zu Sprites auf dem Spectrum denken. Wobei da noch nicht von der Return-Methode gesprochen wurde. Ggf. lohnt sich das nicht für rechteckige Sprite-Formen.

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

179
28.01.2025, 20:16 Uhr
HeikoS

@Matthias:
Meinst Du mit "Return Oriented Programming" das Schreiben mit PUSH in den VRAM? Das wäre ja nicht ganz korrekt, da der Code ja gewollt so geschrieben wurde, oder ich verstehe das vielleicht falsch.

@Bert:
Gut zu wissen, dass du alles gesichert hast - das Webarchiv kann ja auch mal weg sein.

Hier EARTH.KCC für den KC85/4. Sieht auch sehr gut aus:

Danke an Jens !

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

180
28.01.2025, 20:25 Uhr
kaiOr

Zitat:

Heiko schrieb
-> http://robotron.webhop.net/files/kc/earth.kcc

Hatte ich gelöscht, da im KC unpassende RAM-Bereiche überschrieben wurden...fixed. Das einzig interessante an EARTH.KCC ist, dass man beim Skalieren (hier 40x32 Pixel auf 320x256) den "Pixeln" ein eigenes Aussehen verpassen kann. So schaut es aus, als würden Klötzchen (man könnte auch Smileys nehmen) über den Bildschirm flitzen, dabei sind die doch nur starr AN oder AUS. Mittels Skalierung lassen sich die 10kByte Pixelspeicher schnell füllen, auf der einen Seite rollt man nur ein Bit ab, auf der anderen Seite PUSH-t man damit 4 Wörter -> für KC85-Verhältnisse sehr flüssig aber eben auch grobklotzig.

Zitat:

Wie hast Du denn die Bilder erzeugt für das Video-Playback?

*Uff* im Groben:
Animated-GIF -> BMPs -> zuschneiden,Größe reduzieren,S/W+Dithering, schon passend zum Darstellungsalgorithmus drehen,spiegeln etc. -> BMP-Header entfernen -> in KCEMU laden -> extra Sortierprogramm passend zum jewl. Darst.-Algorithmus ausführen -> Ergebnis in BIN -> BINs aller Bilder verketten -> an Programm anhängen -> TEST
Die Grafiksymbole vom KC87 ließen sich mittels Bitmaskierung zuordnen...

@Matthias: Danke für die Anregungen. Mich in eine höhere Programmiersprache einarbeiten um dann am PC direkte Grafikanweisungen für den KC zu generieren übersteigt erstmal meinen Horizont. Dazu bräuchte ich Sofortrente und müsste weg vom Fließband.

Grüße,
Kai

Dieser Beitrag wurde am 28.01.2025 um 20:52 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

181
29.01.2025, 07:24 Uhr
Dresdenboy

Zitat:

kaiOr schrieb
@Matthias: Danke für die Anregungen. Mich in eine höhere Programmiersprache einarbeiten um dann am PC direkte Grafikanweisungen für den KC zu generieren übersteigt erstmal meinen Horizont. Dazu bräuchte ich Sofortrente und müsste weg vom Fließband.

Vielleicht stellst du es dir nur schwieriger vor, als es ist. Eigentlich sollten höhere Programmiersprachen in den Grundlagen doch leichter zu lernen sein als Assembler.

Hierfür würde schon Python oder selbst BASIC (wie wäre es mit VBA + Excel?

) reichen. Am Ende muss man ja z.B. nur bisschen rechnen und Text schreiben. In <084> hatte ich so etwas mal gezeigt.

Kann bei dem Zeitproblem nicht das neue DeepSeek helfen?

Ich habe auch schonmal mit ChatGPT gespielt u. z.B. ein kleines Rust-Programm (wo ich noch keine Erfahrung habe) erzeugt, was aus einer Textdatei alle sich wiederholenden Teil-Zeichenketten ausgeben sollte (mit relativer Position und Länge -> gut für LZ-basierte Komprimierung). Das hat sogar auf Anhieb funktioniert.

Dieser Beitrag wurde am 29.01.2025 um 07:33 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

182
29.01.2025, 16:59 Uhr
HeikoS

Ich habe die KI mal gebeten, einen Übersetzer von 6502 in Z8 in Python zu bauen:

Quellcode:


import re

def parse_6502_assembly(line):
    """Einfache Parsing-Funktion für eine Zeile 6502-Assembler"""
    tokens = line.strip().split()
    if not tokens:
        return None, None
    opcode = tokens[0].upper()
    operands = tokens[1:] if len(tokens) > 1 else []
    return opcode, operands

def translate_6502_to_z8(opcode, operands):
    """Erweiterte Übersetzungslogik für 6502 nach Z8 mit Adressierungsmodi"""
    translation_table = {
        "LDA": "LD R0,",
        "STA": "LD",
        "LDX": "LD R1,",
        "STX": "LD",
        "LDY": "LD R2,",
        "STY": "LD",
        "ADC": "ADD R0,",
        "SBC": "SUB R0,",
        "AND": "AND R0,",
        "EOR": "XOR R0,",
        "ORA": "OR R0,",
        "BIT": "BTJZ R0,",
        "INX": "INC R1",
        "DEX": "DEC R1",
        "INY": "INC R2",
        "DEY": "DEC R2",
        "INC": "INC",
        "DEC": "DEC",
        "TAX": "LD R1, R0",
        "TXA": "LD R0, R1",
        "TAY": "LD R2, R0",
        "TYA": "LD R0, R2",
        "TSX": "LD R1, SP",
        "TXS": "LD SP, R1",
        "PHA": "PUSH R0",
        "PLA": "POP R0",
        "PHP": "PUSH FLAGS",
        "PLP": "POP FLAGS",
        "CMP": "CP R0,",
        "CPX": "CP R1,",
        "CPY": "CP R2,",
        "BEQ": "JREQ",
        "BNE": "JRNE",
        "BCC": "JRNC",
        "BCS": "JRC",
        "BPL": "JRPL",
        "BMI": "JRMI",
        "JMP": "JP",
        "JSR": "CALL",
        "RTS": "RET",
        "RTI": "RETI",
        "BRK": "TRAP",
        "ROL": "RLC R0",
        "ROR": "RRC R0",
        "ASL": "SLA R0",
        "LSR": "SRL R0",
    }
    
    if opcode in translation_table:
        new_opcode = translation_table[opcode]
        if opcode in ["STA", "STX", "STY"] and operands:
            return f"{new_opcode} @{operands[0]}, R0"
        elif opcode in ["LDA", "LDX", "LDY", "ADC", "SBC", "CMP", "CPX", "CPY", "AND", "EOR", "ORA", "BIT"] and operands:
            return f"{new_opcode} {operands[0]}"
        elif opcode in ["INC", "DEC"] and operands:
            return f"{new_opcode} {operands[0]}"
        return new_opcode
    return f"; UNTRANSLATED: {opcode} {' '.join(operands)}"

def convert_6502_to_z8(source_code):
    """Hauptfunktion zur Umwandlung des gesamten Codes"""
    translated_code = []
    for line in source_code.split('\n'):
        opcode, operands = parse_6502_assembly(line)
        if opcode:
            translated_line = translate_6502_to_z8(opcode, operands)
            translated_code.append(translated_line)
        else:
            translated_code.append(line)
    return '\n'.join(translated_code)

# Beispiel
mos6502_code = """
LDA #$10
STA $2000
INX
PHA
JSR $4000
RTS
ROL
LSR
BIT $20
AND #$0F
ORA $30,X
EOR ($40),Y
BRK
RTI
"""

z8_code = convert_6502_to_z8(mos6502_code)
print(z8_code)

... ungetestet, aber krass.

Ein wenig gut zureden musste ich schon, aber ich soll mich wieder melden, wenn ich noch Verbesserungen brauche:

--------------------------
Du:
Hast du den kompletten Befehlssatz des 6502 verwendet ?

ChatGPT:

Noch nicht ganz! Der 6502 hat insgesamt 56 verschiedene Befehle, und aktuell fehlen noch einige, z. B.:

Bit-Manipulation: BIT, AND, EOR, ORA
Arithmetik: DEC, INC (für Speicheradressen)
Verschiedene Jumps & Branches: BRK, RTI
Indirekte Speicherzugriffe: LDA ($20),Y
Ich kann die fehlenden Befehle jetzt ergänzen und auch komplexere Adressierungsmodi hinzufügen. Soll ich das tun? ?

Du:
Ja

ChatGPT:

Ich werde jetzt die restlichen 6502-Befehle hinzufügen, insbesondere:

Bit-Operationen: BIT, AND, EOR, ORA
Arithmetik & Speicher-Modifikationen: DEC, INC
Interrupts & Sprünge: BRK, RTI
Komplexere Adressierungsmodi, einschließlich indirekter Adressen
Ich aktualisiere den Code jetzt! ?

Bearbeitet
Ich habe den kompletten Befehlssatz des 6502 ergänzt, inklusive Bit-Operationen (BIT, AND, EOR, ORA), Arithmetik (DEC, INC) und Interrupt-Befehlen (BRK, RTI). Falls du noch Verbesserungen oder Tests brauchst, sag Bescheid! ?

--------------------

Dieser Beitrag wurde am 29.01.2025 um 17:16 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

183
29.01.2025, 17:26 Uhr
HeikoS

Die KI muss noch ein wenig Z8 lernen ...:

Quellcode:


Python 3.13.1 (tags/v3.13.1:0671451, Dec  3 2024, 19:06:28) [MSC v.1942 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.

================================ RESTART: C:/Users/heiko.PEPP/Documents/test.py ===============================

LD R0, #$10
LD @$2000, R0
INC R1
PUSH R0
CALL
RET
RLC R0
SRL R0
BTJZ R0, $20
AND R0, #$0F
OR R0, $30,X
XOR R0, ($40),Y
TRAP
RETI

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

184
30.01.2025, 08:50 Uhr
Dresdenboy

@Heiko:
Für den Anfang geht das ja schon. Bei Assembler darf man da eh nicht zu viel erwarten. Das hängt ja auch vom "Lernstoff" der KI ab. Und ich habe da auch öfters schon erfundene Mnemonics gesehen.

Interessant ist der 1:1-Mapping-Ansatz.

Für eine bessere Nutzung der Fähigkeiten geht wohl aktuell kein Weg über einen Decompiler (asm->C o.a.) und dann Compiler für die Zielarchitektur.

P.S.: Schön viel Z80-Material: http://www.z80.info/zip/

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

185
30.01.2025, 11:48 Uhr
Dresdenboy

@Heiko:
Nachtrag: Gerade das Parsing der Adressierungsmodi wäre noch eine Herausforderung.

@all mit BIC:
Hier ist mal eine Spielerei für die echte Hardware, die das Linienzeichnen im Komplementär-Modus nutzt, um sich schnell ändernde farbige Muster auf dem Bildschirm zu zeigen:

Quellcode:

10 SCREEN 3:CLS
20 FOR I=55000! TO 55050!:READ X$:POKE I,VAL("&H"+X$):NEXT I:DEFUSR0=55000!
30 FOR I%=&H40 TO &H60:POKE 55024!,I%    : REM Startadresse (high byte)
40 POKE 55028!,I%:POKE 55029!,I%         : REM Wert auch gleich als Maske verwenden
50 FOR J%=0 TO 255 STEP 5:POKE 55023!,J% : REM Startadresse (low byte)
60 X=USR0(0)                             : REM Linie zeichnen
70 NEXT J%:NEXT I%
80 GOTO 30                               : REM Wiederholung
1000 DATA 21,ec,d6,56,23,0e,99,46,23,ed  : REM Routine zum GDC-Register schreiben
1010 DATA a3,28,03,0d,ed,b3,15,20,f2,c9
1020 DATA 06,04,49,00,40,00,03,4a,08,08  : REM GDC-Kommando-Datenstruktur
1030 DATA 01,21,03,78,ff,ff,0c,4c,09,a0
1040 DATA 41,01,00,13,00,36,00,20,00,01
1050 DATA 6c

Der BASIC-Code pro Aufruf in der inneren Schleife ist hier auf nur noch 1 POKE und den USR0-Aufruf reduziert, da BASIC hier der limitierende Faktor ist. Dafür lässt sich einfach damit spielen. Wenn bisschen mehr Zeit ist (vermutlich nach Mitte Februar), packe ich mal alles in Assembler.

Das Format der GDC-Kommando-Datenstruktur ist hier beschrieben: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#245421

Edits: Fehler in Zeile 1040 korrigiert und Hinweis auf echte Hardware hinzugefügt.

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 30.01.2025 um 19:09 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

186
30.01.2025, 17:50 Uhr
BICa5105

...
Ich glaube da ist wo ein Fehler drin...der Bildschirm bleibt schwarz... .

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

187
30.01.2025, 18:41 Uhr
Dresdenboy

Zitat:

BICa5105 schrieb
...
Ich glaube da ist wo ein Fehler drin...der Bildschirm bleibt schwarz... .

LG Cornelius

Ohja, in Zeile 1040 war ein Fehler. Da musste an 2. Stelle eine 01 (oder 1) rein und an vorletzter Stelle eine 0 weg. Hab es korrigiert.

Und ganz wichtig: Das geht nicht im JKCEmu. Der MAME macht immerhin Muster, hat nur glaube ich den falschen Grafikmodus aktiviert. Idealerweise also auf echter Hardware testen!

Edit: Falls sich jetzt jemand fragt, was er/sie da jetzt Krasses verpasst

, ist hier mal ein Screenshot (der auch zeigt, das MAME da etwas hinkriegt):

Das Spannende daran ist die Geschwindigkeit.

Und etwas geordneter sieht es mit SCREEN 5, ohne Zeile 40 und z.B. noch STEP 1 in der Schleife in 50 aus.

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 30.01.2025 um 19:51 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

188
31.01.2025, 18:54 Uhr
ralle

Ich habe in den Webarchiv auch das Programm "Vision.sss" gefunden. Natürlich nicht das schnellste, aber schaut recht gut aus. Garantierte Funktion bis CAOS 4.5 und HC-BASIC.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

189
01.02.2025, 08:25 Uhr
Bert

Zitat:

BICa5105 schrieb
der Bildschirm bleibt schwarz... .

Bei mir im Emulator auch, aber auf der Kommandozeile gibt es eine Meldung dazu:

Quellcode:


GDC82720: WDAT: Grafikmode nicht implementiert
GDC82720: WDAT: Grafikmode nicht implementiert
GDC82720: WDAT: Grafikmode nicht implementiert

Viele Grüße,
Bert
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

190
01.02.2025, 10:46 Uhr
Dresdenboy

@Bert:
Ja, das hatte Jens auch schon bestätigt. Allerdings ist die Fehlermeldung nicht korrekt, da es hier mit den FIGS/FIGD-Kommandos zusammenhängt, die zum Zeichnen verwendet werden.

Falls jemand das mutig im Mame testen möchte, habe ich mal ein rudimentäres Script u. Hinweise hier beschrieben:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#250792

Es kann immer noch sein, dass man beim Mame mit dem Tastaturmodus mal weg von dinput auf win32 oder so stellen muss, BIC starten, beenden, wieder auf dinput stellen und dann kommen die Tasten erst an. Es kann auch noch die Reihenfolge des Starts von Mame und Autohotkey relevant sein. Das habe ich noch nicht herausgefunden. Also etwas für Mutige

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

191
03.02.2025, 22:10 Uhr
janpopan

Ich verfolgen den Thread hier und finde es toll, was hier entsteht.
Ich wollte euch nochmal auf die Demo von Steffen Albrecht aufmerksam machen, die ich erstmalig 1995 oder 1996 von Steffen selbst gezeigt bekam.

https://www.kcclub.de/index.php/downloads/download/8-musik-und-demos/212-sta-demo

Das Programm kombiniert auf dem /4 Hires und Lowres Modus durch geschicktes Timing und funktioniert vermutlich nur auf echter HW (4.1 oder 4.2) sauber.
Etwas Sound ist auch noch am Start.

VG
Jan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

192
04.02.2025, 07:00 Uhr
ralle

Nein, das STA-Demo geht bis 4.5 hoch. Von dem Programmierer kam noch Vollgas und Karate. Vollgas selber funktionierte bis zum Patch nur auf unverbastelter Hardware und CAOS-Diskette. Mittlerweile kann es von USB geladen werden.

In Sachen Grafik hat Ralf Kästner mit UniPic was schönes geschaffen, funktioniert aber auch nur bis 4.5. Ab 4.6 ist das Gerätemanagment völlig umgekrempelt. UniPic aber noch nicht umgestellt. Das ist bis jetzt nur bei Wordpro7 möglich.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

193
04.02.2025, 21:23 Uhr
janpopan

Die Power Demo von STA (Steffen A.) hat nichts mit den Spielen von STS (Stefan Scholz) zu tun.

Ralfs UniPic ist ein fantastisches Grafikbearbeitungstool für der KC, hatte aber nie zum Ziel, gleichzeitig Hires und Lowres zu nutzen. Ralf hat zudem den Hires Mode sinnvoll nutzbar gemacht und den passenden Artikel geschrieben, heute ist dies Teil von Marios CAOS Weiterentwicklung.

Das spannende an der Power Demo von Steffen ist die gleichzeitige Darstellung - also in einem Bild - von 16 Farben LowRes (Bild oben und unten) und 4 Farben Hires (Mitte).

Daher wollte ich das hier nochmal in Erinnerung rufen, eventuell inspiriert dies ja noch den einen oder anderen Demo Entwickler.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

194
06.02.2025, 09:14 Uhr
HeikoS

Zitat:

janpopan schrieb
Ich verfolgen den Thread hier und finde es toll, was hier entsteht.
Ich wollte euch nochmal auf die Demo von Steffen Albrecht aufmerksam machen, die ich erstmalig 1995 oder 1996 von Steffen selbst gezeigt bekam.

https://www.kcclub.de/index.php/downloads/download/8-musik-und-demos/212-sta-demo

Das Programm kombiniert auf dem /4 Hires und Lowres Modus durch geschicktes Timing und funktioniert vermutlich nur auf echter HW (4.1 oder 4.2) sauber.
Etwas Sound ist auch noch am Start.

VG
Jan

Danke für den Tipp ! Im JKCEMU läuft es, aber flackert ganz schön, also bestimmt nicht so, wie auf dem Original-KC - hatte aber noch keine Zeit das auf HW laufen zu lassen. Im "virtualkc"

http://floooh.github.io/virtualkc/

stürzt es gleich ab. Das spricht für die Demo ;-) ... sehr interessant !

Viele Grüße, Heiko

EDIT:

Was ist "hires" und "lowres" beim KC85/4 ? Wie schaltet man das um?

Dieser Beitrag wurde am 06.02.2025 um 09:16 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

195
06.02.2025, 09:52 Uhr
ralle

Das hat was mit der Farbauflösung zu tun. Hieß ist mit 4 Farben, also schwarz weiß rot und Türkis beliebig nebeneinander definiert. Lores mit 16 Vordergrund auf 8 Hintergrundfarben definiert.

Allerdings 2 Farben auf 8x8 beim /2;/3 und 8x1 ab dem /4. Das heißt, du kannst nicht die Vordergrundfarben ohne weiteres nebeneinander setzen.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 06.02.2025 um 10:10 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

196
06.02.2025, 11:00 Uhr
HeikoS

Danke ... ist wie immer auch gut beschrieben im KC-Handbuch:

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

197
06.02.2025, 12:11 Uhr
ralle

Theoretisch wäre durch die 2 Bilder eine Art Interlacing möglich. Aber durch die Art der Organisation ist es auch möglich, kleine Diashow zu bauen.

In BASIC kann man aber ein Bild zeigen und ein anderes Aufbauen.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

198
11.02.2025, 18:11 Uhr
FL

Ihr seit hier zwar schon drei oder vier Themen weiter. Ich komme trotzdem noch einmal mit GleEst um die Ecke.

Ich habe mir auch Gedanken über einen Bildschirmschoner für CAOS gemacht.
Hier mein Lösungsvorschlag: http://www.kc85emu.de/rt/scrsvr4.zip
Das Programm läuft im KC85/4 und /5.

Zum Messen der Zeit wird der CTC-Kanal 3 verwendet. Entgegen meiner ersten Annahme, mußte ich den Tastaturtreiber nicht aufbohren.
Statt dessen verbiegt der Schoner das CAOS-UP KBD. Dadurch kann er immer dann aktiv werden, wenn im aktuellen Programm der Cursor angezeigt ist.

Aufgerufen wird das Programm mit: %SCR [ZEIT]
ZEIT muß in Sekunden angegeben werden. Ich wollte nicht so lange warten.

Das läßt sich aber im Quellcode auch auf Minuten ändern.
Voreingestellt sind 15 Sekunden.

Zitat:

susowa schrieb
Unter CAOS gibt es keinen geschützten Speicherbereich, wo der Bildschirmschoner "sicher" ist - wird also schwierig ...

Das Programm liegt im IRM-Bereich AB00h..ACFFh (reserviert für anwenderspezifische Systemerweiterungen).
Ich denke das dieser Bereich am wenigsten genutzt wird. Bis CAOS 4.5 benötigt das Programm zusätzlich den IRM ab AA6Eh.
Der Inhalt des Speichers, der für Buffer1 und 2 benötigt wird, wird solange GleEst läuft in einem Teil des versteckten IRM gerettet.
Bleibt die Frage: Wohin den Bildschirminhalt retten, wenn der Schoner aktiv wird?

Den Code von GleEst habe ich etwas optimiert. Sonst hätte ich das ganze Programm nicht auf 512Byte gequetscht bekommen.

Gruß
Frank.

Dieser Beitrag wurde am 11.02.2025 um 18:11 Uhr von FL editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

199
11.02.2025, 18:34 Uhr
ralle

Beim KC85/5 bietet sich ein Teil des RAM an. Also eine RAM-Bank. Die wird unter BASIC eh nicht genutzt.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

200
11.02.2025, 22:08 Uhr
HeikoS

Zitat:

FL schrieb
Ihr seit hier zwar schon drei oder vier Themen weiter. Ich komme trotzdem noch einmal mit GleEst um die Ecke.

Ich habe mir auch Gedanken über einen Bildschirmschoner für CAOS gemacht.
Hier mein Lösungsvorschlag: http://www.kc85emu.de/rt/scrsvr4.zip
Das Programm läuft im KC85/4 und /5.

Zum Messen der Zeit wird der CTC-Kanal 3 verwendet. Entgegen meiner ersten Annahme, mußte ich den Tastaturtreiber nicht aufbohren.
Statt dessen verbiegt der Schoner das CAOS-UP KBD. Dadurch kann er immer dann aktiv werden, wenn im aktuellen Programm der Cursor angezeigt ist.

...

Den Code von GleEst habe ich etwas optimiert. Sonst hätte ich das ganze Programm nicht auf 512Byte gequetscht bekommen.

Gruß
Frank.

Funktioniert sehr gut (CAOS 4.2) ! Interessant, dass es doch noch eine andere Lösung mit dem CTC-Kanal 3 für die Integration in CAOS als Bildschirmschoner gibt.

Viele Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

201
12.02.2025, 22:14 Uhr
FL

Danke HeikoS!

Zitat:

ralle schrieb
Beim KC85/5 bietet sich ein Teil des RAM an. Also eine RAM-Bank. Die wird unter BASIC eh nicht genutzt.

Im Moment wird ja nur auf das gerade inaktive KC-Bild umgeschalten. Genau wie bei der Lösung von Crawler.

Denkbar währe, den RAM8-Block 13 beim /5 bzw. Block 1 beim /4 zu benutzen.
Ich bin mir nur nicht sicher. Die RAM8-Blöcke können für eine RAM-Disk genutzt werden, oder zum Beispiel von Programmen wie Unipic und Wordpro6. (O.k. mit diesen beiden Programmen wird der Schoner nicht laufen.)

Bleiben noch 6kByte übrig. Dafür könnte man einen Block im versteckten IRM nehmen.
Beim /4 ist dieser Bereich frei. Beim /5 hat man dann kein zweites RAM4-Segment.

So richtig rund ist das nicht. Aber ich kann das mal ausprobieren.

Gruß
Frank.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

202
13.02.2025, 06:24 Uhr
ralle

Tatsächlich nutzen WP6/7, Assembler und UniPic/Diashow den Mehr-RAM als Bild und Textspeicher. Bei Assembler sind es knapp 48kb für etwa 4kb Programm.

Vielleicht hilft es, ermitteln letzte RAM-Segment, aktuell beschriebenen BWS dorthin schalten und letzte Segment reinswitchen. Schoner rennen lassen.

Bei WP6/7 wird das 2te Bild, gesamt 32kb für eine Hilfeseite genutzt.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

203
13.02.2025, 10:09 Uhr
Bert

Zitat:

ralle schrieb
Vielleicht hilft es, ermitteln letzte RAM-Segment, aktuell beschriebenen BWS dorthin schalten und letzte Segment reinswitchen. Schoner rennen lassen.

CAOS ist einfach nicht für Multitasking gemacht.
So lange es keine festen Vorgaben gibt, kann es immer passieren, daß Anwendung nicht miteinander harmonieren.
Im besten Fall geht es nur einfach nicht und im schlechtesten Fall brauchst Du die Reset-Taste.

Zitat:

FL schrieb
Ich habe mir auch Gedanken über einen Bildschirmschoner für CAOS gemacht.
Hier mein Lösungsvorschlag: http://www.kc85emu.de/rt/scrsvr4.zip

Fein!

Zitat:

Zum Messen der Zeit wird der CTC-Kanal 3 verwendet.

Ich nehme gerne Kanal 2. Der läuft auch mit dem Signal /BI (50 Hz) und ist 'nur' fürs Blinken zuständig.

Zitat:

Das Programm liegt im IRM-Bereich AB00h..ACFFh (reserviert für anwenderspezifische Systemerweiterungen).
Ich denke das dieser Bereich am wenigsten genutzt wird.

Prinzipiell ist das richtig.
Ich kenne aber mehrere Programme (v.a. Spiele) die im Bereich A800h bis B1FFh wilde Schreibzugriffe machen, weil das der Farbspeicher vom 85/3 ist.

Zitat:

Bleibt die Frage: Wohin den Bildschirminhalt retten, wenn der Schoner aktiv wird?

Ich finde die Idee mit der Nutzung des zweiten Bildschirms ganz brauchbar. Auch da gibt es sicher Programme die beide Bildschirmseiten nutzen, aber einen Tod muß man sterben...

Ideal wäre es, wenn das Betriebssystem die Speicherverwaltung übernimmt und Funktionen zum Zugriff auf Speicherpages (a 128 Bytes?) anbietet.
So ähnlich funktioniert es ja auch, wenn der Speicher im Grundgerät als RAM-Disk für ML-DOS zur Verfügung gestellt wird.
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

204
13.02.2025, 16:14 Uhr
susowa

Zitat:

FL schrieb
Im Moment wird ja nur auf das gerade inaktive KC-Bild umgeschalten. Genau wie bei der Lösung von Crawler.

Und so sollte das auch vollkommen ausreichend sein. Der Bildspeicher ist ja nicht zum dauerhaften Konservieren von Speicherinhalten gedacht - ist ja kein RAM im eigentlichen Sinn.

Mit einer kurzen "Bildstörung" kann man sicher gut leben, mit Abstürzen eher nicht.

Gut, dass es beim KC85/4+ das inaktive Bild gibt!

MfG susowa

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

205
14.02.2025, 21:46 Uhr
FL

Zitat:

Bert schrieb

Zitat:

Zum Messen der Zeit wird der CTC-Kanal 3 verwendet.

Ich nehme gerne Kanal 2. Der läuft auch mit dem Signal /BI (50 Hz) und ist 'nur' fürs Blinken zuständig.

Ne, leider nicht. Dieser Kanal wird gefühlt für alles verwendet. Bei der Tondauer von SOUND fängt es an.
Deshalb die Idee mit dem CTC-Kanal 3. Der wird von allen Programmen in Ruhe gelassen. Maximal das sie den
CTC-Interrupt abfangen um auf das Loslassen der Taste zu reagieren.

Zitat:

... IRM-Bereich AB00h..ACFFh ... Ich denke das dieser Bereich am wenigsten genutzt wird.

Prinzipiell ist das richtig.
Ich kenne aber mehrere Programme (v.a. Spiele) die im Bereich A800h bis B1FFh wilde Schreibzugriffe machen, weil das der Farbspeicher vom 85/3 ist.

Diese Programme gibt es leider. Ich habe sie ehrlich gesagt verdrängt. Ab CAOS 4.6 laufen sie überhaupt nicht mehr, weil sie die SUTAB überschreiben.

Zitat:

susowa schrieb

Zitat:

FL schrieb
Im Moment wird ja nur auf das gerade inaktive KC-Bild umgeschalten. Genau wie bei der Lösung von Crawler.

Und so sollte das auch vollkommen ausreichend sein. Der Bildspeicher ist ja nicht zum dauerhaften Konservieren von Speicherinhalten gedacht - ist ja kein RAM im eigentlichen Sinn.

Es gibt Programme die beide Bildspeicher nutzen um schnell zwischen den Inhalten umschalten zu können und sich darauf verlassen, daß der Inhalt dann auch paßt. Ziel war diese Programme auch zu berücksichtigen.

Aber meine Idee aus #201 funktioniert nicht. Wenn ich auf die Ready-Meldung beim Programmstart verzichte, habe ich trotzdem nur 24 Byte frei. Das reicht für das zusätzliche Speicherschupsen nicht aus.

Zitat:

Bert schrieb
Ideal wäre es, wenn das Betriebssystem die Speicherverwaltung übernimmt und Funktionen zum Zugriff auf Speicherpages (a 128 Bytes?) anbietet.
So ähnlich funktioniert es ja auch, wenn der Speicher im Grundgerät als RAM-Disk für ML-DOS zur Verfügung gestellt wird.

Genau meine Meinung.

Das Programm habe ich noch einmal aktualisiert. GleEst verwendet jetzt den gesamten 320x256Pixel-Bildschirm.

Gruß
Frank.

SCRSVR4.ZIP

Dieser Beitrag wurde am 14.02.2025 um 21:47 Uhr von FL editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

206
17.02.2025, 18:03 Uhr
Dresdenboy

Hallo zusammen, ich melde mich zurück aus Winterurlaub bei der Schneekoppe und 1 Woche Grippe danach.

Das war auch der Grund, warum ich nichts mehr programmieren konnte, da ich die letzte Energie zum Heizen auf >40° C Fieber brauchte bzw. die kranke Familie versorgen musste. Aber krank werden im Urlaub ist ja ein Trend.

Da am Wochenende die wieder recht umfangreiche online-Demo-Party "Lovebyte" stattfand, gibt es wieder viel Neues zu sehen. Zum Glück ging es mir immerhin wieder gut genug, um es mir zumindest anzusehen.

Was davon am besten hierher passt, ist wohl der ZX Spectrum Livecoding Jam, wo 3 sehr gute Coder live vor dem Assembler sitzen und Code für Effekte schreiben, dessen Wirkung sofort zu sehen ist (HeikoS hatte das Tool auch schonmal verlinkt). Vllt. macht es ja auch euch Spaß, das anzusehen:
https://www.youtube.com/watch?v=cmnxjENwC-A

Auf dem YT-Kanal wird die Tage immer mehr von den Competitions hochgeladen. Da sind viele spannende Sachen dabei.

Es gab auch viel für Amstrad CPC und auch Exoten wie den Colour Genie (gibt's sogar gerade auf Kleinanzeigen) oder den hier im Forum schon besprochenen Videoton TVC.

Viele Grüße,
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.02.2025 um 18:42 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

207
17.02.2025, 19:07 Uhr
maleuma

Zitat:

FL schrieb

Zitat:

Genau meine Meinung.

Das Programm habe ich noch einmal aktualisiert. GleEst verwendet jetzt den gesamten 320x256Pixel-Bildschirm.

Gruß
Frank.

SCRSVR4.ZIP

Diese Lösung finde ich sehr schön. Einige CAOS-Programme werden nicht damit laufen, CAOS ist dafür einfach nicht ausgelegt. Aber ich denke, das war auch nicht Anspruch der kleinen Bildschirmschoner-Routine.
Ja, eine Speicherverwaltung wie bei ZAS 1.3+ wäre manchmal wünschenswert. Jedoch kennt kein CAOS-Programm so etwas und alle Programme müssten umgeschrieben werden.
Freuen wir uns doch einfach, dass es jetzt einen CAOS-Bildschirmschoner gibt. Ich bin schon neugierig, wie oft der beim nächsten Clubtreffen zu sehen sein wird

--
Mario.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

208
22.02.2025, 22:45 Uhr
HeikoS

@FL:
Super, dass du GleEst auf 320 Pixel erweitert hat. Das müsste ich noch übernehmen bei meinem Portierungen, schaue ich mir noch an !

@Matthias:
Ja, krank im Urlaub ist "in" ... ich hoffe Dir geht es gut und alles ist überstanden !

Matthias hatte ja hier Info’s zum Spiel Elite gepostet, was im Jahr 1984 für den BBC Micro mit 6502 herausgekommen ist. Das ist ja wirklich eines der legendärsten 3D-Echtzeit-Spiele für 8-Bitter. Sehr interessant, auch die Geschichte der beiden Programmierer, Ian Bell und David Braben.

https://rightoncmdr.wordpress.com/the-elite-story/
http://www.iancgbell.clara.net/

Das Mathematik-Studium von Bell war sicher sehr hilfreich. Interessant ist, wie geschickt sie die Algorithmen auf den 8-Bit 6502 gebracht haben. Da ist wirklich nie ein Bit zu viel benutzt, alles konsequent in den richtigen Wertebereich skaliert und immer extrem optimiert. Umso mehr hat mich verwundert, wie die Kreis-Routine in Elite realisiert ist.

Während der Linien-Algorithmus eher klassisch nach Bresenham (mit vorausberechnetem Anstieg |dx|/|dy|) realisiert ist, wurde beim Kreis-Algorithmus nicht der oft genutzte erweiterte Bresenham-Algorithmus gewählt.

https://elite.bbcelite.com/deep_dives/drawing_circles.html

Elite stellt Kreise tatsächlich aus einzelnen Strecken (Linien) dar und berechnet die Koordinaten der Linien über SIN/COS (Lookup-Tabelle) aus dem Radius und einer Schrittweite, was einem Winkel entspricht. Der Kreis wird also zerlegt in Strecken, die dann nacheinander gezeichnet werden. Es werden keine Spiegelungen genutzt, sondern es wird einmal entgegen dem Uhrzeigersinn für 360 Grad jeder Anfangs- und End-Punkt der Stecken berechnet. Für das Löschen werden dann die gespeicherten Koordinaten der Punkte genutzt (line heap). Sie werden nicht noch einmal neu berechnet.

Das wollte ich dann auf dem Ju-Te auch mal ausprobieren. So sind schon mal eine sehr schnelle Pixel- und Line-Routine entstanden. Bei den Line-Routinen hat sich dann auch wieder herausgestellt, dass in Elite die schnellste Routine implementiert ist. Nicht „self-modifying“, sondern konsequent „en-rolled“ – um mal neudeutsch zu sprechen.

Fehlte noch der Circle-Algorithmus und der damit realisierte „Hyperspace Jump“ aus Elite:

Circle (in Zeitlupe):

Hyperspace-Jump auf dem Ju-Te 6K:

Right on, RT-Commander’s !

Dieser Beitrag wurde am 23.02.2025 um 09:35 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

209
15.03.2025, 12:33 Uhr
HeikoS

Liebe Grafik-Enthusiasten,

es ist ja sehr ruhig geworden auf diesem Thread. Deshalb will ich mal wieder etwas berichten aus der "Software-Archäologie". Nachdem die KI mich kläglich im Stich gelassen hatte beim Portieren von 6502 zu Z8-Assembler, habe ich mal die einfache "I" benutzt.

Herausgekommen ist ein Cross-Assembler auf Basis von Arnold-Assembler-Macros und Python-Scripts. Damit kann man nun den 6502-Code direkt in Z8-Maschinen-Code übersetzen. Die Befehle des 6502 sind von der Anzahl her überschaubar, dafür aber sehr effektiv. Sie lassen sich alle über Z8-Befehle darstellen, aber der Z8-Code muss anschließend noch optimiert werden. Der Optimizer ist noch in Arbeit.

Der gesamte Source-Code von 'Elite' lässt sich nun schon übersetzen (natürlich läuft er nicht 1:1). Das Bin-File ist ohne Optimierung auch noch ca. doppelt so groß wie das 6502-Bin-File.

Der "Build"-Prozess läuft so ab:

Stage 1: Konvertieren der 6502-Assembler-Quelle (BeebAsm-Format) in das Arnold-Assembler-Format.
Stage 2: Separieren aller Marcos, Variablen und Funktionen über IF/THEN Bedingungen, um sie über Schalter ein/ausschalten zu können.
Stage 3: Auflösen aller 6502-Befehle über Macros in Z8-Assembler und Übersetzen des Z8/6502-Assembler-Misch-Codes in Z8-Maschinen-Code.

Durch die Schalter können gezielt die 6502-Funktionen ausgewählt werden, die z.B. für den Hyper-Jump notwendig sind und dann in eigenen Programmen verwendet werden. Hier das Ergebnis einer 1:1 Portierung aus 'Elite':

Mal sehen, wie weit man das treiben kann ... theoretisch könnte man damit auch Z80-Code erzeugen. Die Basis-Funktionen wie "Line" und "Pixel" müssten natürlich vorher im optimierten Z80-Code erstellt werden. Aber da ist ja genug Know-How hier vorhanden.

Viele Grüße aus der Weltraum-Kommando-Zentrale !
Heiko

Dieser Beitrag wurde am 15.03.2025 um 12:35 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

210
16.03.2025, 18:18 Uhr
Bert

Coole Sache!
Mit einem 'einfachen' 6505-Emulator wird man hier vermutlich nicht schnell genug.
Schwierig wird es vermutlich bei hoch optimiertem Code, der irgendwelche Seiteneffekte nutzt.

Globales Interrupthandling geht auf dem Z8 mit EI (enable interrupt) und DI (disable interrupt).
Die Frage ist, ob man das hier will (und braucht), oder ob das nur auf dem 6506 relevant ist.
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

211
16.03.2025, 23:46 Uhr
HeikoS

Hallo Bert,

am besten ist natürlich die Portierung in die jeweilge Assembler-Syntax. Die Routinen aus Elite sind von Mark Moxon so exakt beschrieben, dass man das ohne Probleme machen kann.

https://elite.bbcelite.com/cassette/main/subroutine/circle2.html

Aber die Menge der Funktionen in Elite ist so groß, dass mir die Idee einer Automatisierung sinnvoll schien. Der Z8 hat zwar viele Register, aber der 6502 ist sehr schnell mit seinen wenigen Befehlen. Die Zero-Page des 6502 macht ihn noch einmal schneller. Da wäre es gut, wenn unsere U88XX 256-Register hätten, dann wäre fast eine 1:1 Abbildung der Zero-Page möglich. So muss man da ein wenig tricksen mit fixem HI-Teil einer Page und "phase" beim assemblieren. Komisch ist auch, dass das Carry-Flag invers zu den Zilog-CPU's ist. Wer sich das ausgedacht hat ...

Bei "Circle" und "Hyperjump" ging noch alles sehr glatt, aber es gibt in dem Code natürlich viele Seiteneffekte. Da wird z.B. mit "JSR LABEL+3" eine Adresse um 3 Bytes höher aufgerufen, die Abbildung im Z8-Code ist aber nicht 3 Byte lang, sondern evtl. 5 Byte. Diese Fälle gibt es aber nur 25 Mal im Code, dafür aber 152 Mal ein relativer Sprung mit solchen Offsets beim Label. Auch wird in Teile von Befehlen gesprungen, die dann wieder einen neuen OP-Code bilden usw. ... das übliche Elend wenn man den Code dann versteht.

Da an dem Code zwei Entwickler gearbeitet haben, die ihn dann zusammengefügt haben, merkt man auch die Unterschiede. In manchen Teilen sind deutlich mehr "Schweinereien" ;-) ...

Interrups sind ja noch nicht relevant, danke für den Tipp, das hatte ich bisher einfach weggelassen. Könnte später noch wichtig werden.

Viele Grüße, Heiko

Dieser Beitrag wurde am 16.03.2025 um 23:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

212
21.03.2025, 00:16 Uhr
HeikoS

Heute hat das erste Mal die 3D-Engine aus Elite im Ju-Te 6K funktioniert. :-)

Noch absolut unoptimiert und voller Debug-Code, aber: "faszinierend" würde Spock sagen ....

Right on, Robotroner !

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

213
21.03.2025, 07:10 Uhr
BICa5105

Echt erstaunlich was auf so einem "kleinen Ding" machbar ist!

Richtig gut !
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

214
21.03.2025, 08:04 Uhr
HeikoS

Ja, das ist wirklich erstaunlich. Da werden ja keine vorher berechneten Koordinaten verwendet, die dann nur "abgespielt" werden, sondern alles wird in Echtzeit berechnet.

Die Theorie dazu ist ja nichts Außerirdisches, aber die Umsetzung in Maschinen-Code schon fast. Sehr clever gemacht. Wer da mal reinschauen möchte, hier sind die beiden wesentlichen Routinen dazu:

Anzeigen von 3D-Objekten:
https://elite.bbcelite.com/deep_dives/drawing_ships.html

Bewegen von 3D-Objekten:
https://elite.bbcelite.com/deep_dives/program_flow_of_the_ship-moving_routine.html

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

215
21.03.2025, 22:33 Uhr
HeikoS

Die erste Version Elite von 1984 löscht bei der Darstellung von 3D-Objekten diese vollständig, bevor die neue Position gezeichnet wird. Das ist leider als "Flackern" sichtbar.

Die Z8-1:1-Portierung ist noch nicht optimiert bzgl. der Geschwindigkeit. Daher sieht man das "Flackern" auch hier stark (s. <212> )

1986 gab es dann eine "flicker free" Version, bei der eine optimierte Darstellung erfolgt. Das ist gut gelungen, die habe ich mal in Z8-Code für den Ju-Te 6K konvertiert. Das sieht deutlich besser aus, aber jetzt fehlt noch Geschwindigkeit. Aber da geht noch was ...

Beam me up, Scotty !

Dieser Beitrag wurde am 21.03.2025 um 22:41 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

216
21.03.2025, 23:20 Uhr
HeikoS

Im Debug-Mode, den ich mir zum Testen gebaut habe, kann man die Arbeitsweise der "flicker-free" Version gut sehen. Oben links werden immer die Koordinaten der aktuellen Linie P1(x,y) und P2(x,y) angezeigt.

"Faszinierend ... "

Dieser Beitrag wurde am 21.03.2025 um 23:33 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

217
02.04.2025, 14:30 Uhr
HeikoS

Beim Treffen in Garitz (auch noch einmal ein großes Dankeschön an die Organisatoren) habe ich auf einem Rechner (ich denke ein KC85 /4/5 ?) eine 3D-Animation eines recht komplexen Objektes (Gebäude?) gesehen. Leider war wieder zu wenig Zeit und so habe ich da nicht noch einmal das Gespräch gesucht.

Es wäre doch schön, wenn das hier auch mal vorgestellt würde – wäre bestimmt für Alle interessant. Wer hat diese schöne Animation präsentiert ?

Viele Grüße, Heiko

Edit: Ich glaube es war gleich vorn rechts in der Reihe der "AC1-Fraktion" ...

Dieser Beitrag wurde am 02.04.2025 um 14:52 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

218
02.04.2025, 15:50 Uhr
ralle

Das Buch, was ich mit hatte, hatte in BASIC eine 3D-Zeichnung hervorgebracht.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

219
02.04.2025, 16:04 Uhr
HeikoS

@ralle:

Du hast doch in dieser Reihe an der linken Seite gesessen ... das war genau an der anderen Seite, rechts. Aber vielleicht war es das ja, kannst Du ja mal zeigen.

Viele Grüße, Heiko

Dieser Beitrag wurde am 02.04.2025 um 16:04 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

220
02.04.2025, 17:27 Uhr
ralle

Bitte sehr: https://workupload.com/file/CVpKUv2s6W7 Sind insgesamt 3 Bücher, ich denke da ist sicher was dabei. Ansonsten fragst du höflich Holger, also Ambrosius.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

221
02.04.2025, 17:46 Uhr
HeikoS

Das könnte es gewesen sein, 3. Buch, letztes Bsp.:

Eine sehr schöne Buchreihe mit vielen Beispielen gut erklärt.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

222
02.04.2025, 17:54 Uhr
ThomasR

Avatar von ThomasR

Zitat:

HeikoS schrieb
(…) eine 3D-Animation eines recht komplexen Objektes (Gebäude?) (…)

Hier https://joyceforum.de/viewtopic.php?p=1078#p1078 gibt es auch so etwas, aber das war es wohl nicht?
--
Tot wie ein Dodo?
viele Informationen zu BasiCode auf basicode.de

Cu via komputilo povas Esperanto?
Jes, BasiCode!

Dieser Beitrag wurde am 02.04.2025 um 17:55 Uhr von ThomasR editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

223
02.04.2025, 18:24 Uhr
ralle

In den kleinen Heften ist auch die Globus-Animation zu sehen. Allerdings mit einem M011.

hab jetze das Gleest laufen lassen, ganz schön krank. Da darf man nicht unter Depri leiden...
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 02.04.2025 um 18:35 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

224
02.04.2025, 19:51 Uhr
HeikoS

... ich fand immer, dass die vor-sich-hin-schlängelnden, bunten Schleifchen von GleEst eher beruhigen, aber vielleicht gab es auch schon Opfer, die dem Wahnsinn verfallen sind ;-)))

Dieser Beitrag wurde am 02.04.2025 um 19:52 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

225
02.04.2025, 19:55 Uhr
HeikoS

Zitat:

ThomasR schrieb

Zitat:

HeikoS schrieb
(…) eine 3D-Animation eines recht komplexen Objektes (Gebäude?) (…)

Hier https://joyceforum.de/viewtopic.php?p=1078#p1078 gibt es auch so etwas, aber das war es wohl nicht?

Nein, das war schon das, was Ralle beschrieben hat, denke ich. Aber das Basicode-Bsp. sieht auch interessant aus.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

226
02.04.2025, 19:58 Uhr
ralle

Zitat:

HeikoS schrieb
... ich fand immer, dass die vor-sich-hin-schlängelnden, bunten Schleifchen von GleEst eher beruhigen, aber vielleicht gab es auch schon Opfer, die dem Wahnsinn verfallen sind ;-)))

Die sind harmlos, aber die Töne. Zumal ich einen ordentlichen Lautsprecher mit Pappmembran drinnen habe.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

227
02.04.2025, 20:22 Uhr
HeikoS

Zitat:

ralle schrieb

Zitat:

Die sind harmlos, aber die Töne. Zumal ich einen ordentlichen Lautsprecher mit Pappmembran drinnen habe.

Achso ... :-)))) , ja: KC mit M066: "laufender Kompressor hinter Gipskarton-Trennwand (inkl. Lastwechsel + eiernde Riemenscheibe)" , frei nach KaiOr

Dieser Beitrag wurde am 02.04.2025 um 20:33 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

228
02.04.2025, 23:18 Uhr
ThomasR

Avatar von ThomasR

Zitat:

HeikoS schrieb (…) das war schon das, was Ralle beschrieben hat, denke ich. Aber das Basicode-Bsp. sieht auch interessant aus. (…)

Wie in dem verlinkten Beitrag angegeben kannst Du die erste Version hier. https://github.com/robhagemans/basicode...vlucht.bc3 herunterladen und hier http://web.archive.org/web/201701031528...c3logo.zip das Paket, das unter anderem die Folgeversion enthält: auch für den PC und sogar ready to use (musst nur eventuell die DOSBox bemühen).

In der ersten Version ist das EFH mit Garage, das rotiert zwar nicht von allein, aber mit Tastenbetätigungen kannst Du alles Mögliche anstellen: zoomen, verschieben, drehen …

Hier https://forum.system-cfg.com/viewtopic.php?f=12&t=9201&p=243685&hilit=BasiCode+Thomson#p243685 sind auch noch ein paar Screenshots.

Ein kleines Hindernis ist, dass alles auf Niederländisch stattfindet, aber ich habe es auch eingedeutscht https://joyce.de/basicode/joyce/bc3logo.htm , schicke mir Mail oder PN, dann sende ich es Dir gerne.

Es läuft übrigens auch super (das heißt insbesondere flott) im Java-Bascoder, der kurz vor der Fertigstellung steht.
--
Tot wie ein Dodo?
viele Informationen zu BasiCode auf basicode.de

Cu via komputilo povas Esperanto?
Jes, BasiCode!

Dieser Beitrag wurde am 02.04.2025 um 23:29 Uhr von ThomasR editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

229
04.04.2025, 08:50 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Das könnte es gewesen sein, 3. Buch, letztes Bsp.:

Das kommt natürlich nie an deinen Elite-Port ran.

Ich hatte beim Essen auf (ich glaube) ralles Platz etwas Ähnliches wie oben gesehen, was aber eher wie ein Haus aussah.

Auch noch ein kleines Update von mir (was keinen extra-Beitrag rechtfertigt):

Ich habe mal angefangen, BIC-Rasterbars zu programmieren. Erst einmal prototypisch (weil gerade zur Hand) in Turbo Pascal. Das schafft grob 30000 Leerschleifendurchläufe pro Sekunde oder ca. 10000 mit einer inneren Warteschleife mit Portabfrage drin.

Damit war schon ein simpler Ablauf umsetzbar:

1. auf Vertical Sync warten (Bit 5 von Port 98h)
2. kurze Wartephase (um in den sichtbaren Bereich zu kommen)
3. Schleife über Hintergrundfarbwerte (32-47 mit gesetztem Farbregister-Index)
3.a auf Horizontal Blank warten (Bit 6 von Port 98h)
3.b Farbwert auf Port 97h ausgeben

Das kann dann in Schleife ausgeführt werden und erzeugt schonmal ein paar Farbbalken, allerdings noch nicht sauber (kein DI aktiv und es werden die kurzen Horizontal Blank-Phasen öfters mal verpasst, da ein Port-Abfrage-Schleifendurchlauf ja schon grob eine Zeile lang dauert.).

Als nächstes kommt etwas Z80-Assembler zum Einsatz.

Viel Grüße,
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 04.04.2025 um 10:00 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

230
05.04.2025, 09:33 Uhr
HeikoS

Ich finde es schön, dass wieder etwas an dieser Stelle gezeigt wird !

@Thomas:

Ich habe zwar noch nie etwas mit einem Bascoder gemacht, aber es gibt ja wirklich viel interessante Software dafür. Mit meinen kleinen Progrämmchen versuche ich ja immer die max. Geschwindkeit aus den guten, alten Rechnern herauszuholen auf der originalen HW. Das geht ja leider mit BASIC eher nicht, es sei denn mit einem Compiler, das soll es ja auch geben für BASIC.

Der Bascoder in Java kann doch da nicht helfen, oder ? Damit kann man doch nur die Programme auf einem PC schnell laufen lassen, wenn ich das richtig verstehe. Das kann man aber doch auch, in dem man einfach die Geschwindigkeit der Emulation erhöht. Ich hoffe, ich habe das richtig verstanden.

@Matthias:

Rasterbars am BIC wären eine sehr schöne Sache !!! Das wären dann "echte" Rasterbars" im Gegensatz zu meinem Versuch beim Ju-TE-6K.

Noch eine Frage: Hast du evtl. Code-Schnipsel, um Linien mit dem BIC zu zeichnen, die der GDC erzeugt?

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

231
05.04.2025, 10:50 Uhr
ralle

Heiko, orgin und Draw kann der BIC.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

232
05.04.2025, 20:42 Uhr
HeikoS

Na ja, "Draw" kann der BIC, aber es gibt nur eine Betriebsart (Mode 0), wo der GDC hardwarebasiert die Linien zeichnet und das extrem schnell ! Das ist natürlich sehr interessant u.a. für 3D-Grafik.

Grüße, Heiko

Aus: https://www.sax.de/~zander/bic/bc_serv1.pdf -> S.23

"Um die Darstellungsmöglichkeiten bei beschränkter Bildwiederholspeicher-
größe zu erweitern, wurden Möglichkeiten geschaffen, den 64kx16 Bit großen
Video-RAM in 2 Ebenen zu 8 Bit oder vier Ebenen zu je 4 Bit aufzuteilen.
Mit dieser Aufteilung des Bildwiederholspeichers ist es möglich, den
Bildschirm in 320x200 (250) Pixel in 16 Farben oder in 640x200 (250) Pixel
in 4 von 16 Farben je Pixel aufzuteilen. Für die letztgenannte Betriebsart
sind im VIS vier Farbregister vorgesehen. Das 5. Farbregister dient zur
Speicherung der Bildrandfarbe in allen Betriebsarten des VIS.

Da in den genannten Betriebsarten aufgrund der nichtlinearen Speicheraufteilung die
Verwendung der leistungsfähigen Grafikbefehle des GDCs zur Zeichnung
einfacher Figuren wie Linien, Kreise und Rechtecke nicht oder nur bedingt
möglich ist, kann im Mode 0 der VIS, gesteuert durch das Image-Mode-Flag,
in einen Grafikmode umgeschaltet werden. In diesem Mode besteht der
Bildwiederholspeicher aus einer linear aufgeteilten Bildebene, so daß nur
eine einfarbige Grafikdarstellung möglich ist. Hier können die Vorteile des
GDCs (gleichzeitige Darstellung von Text und Grafik; schnelle, leistungs-
fähige Grafikbefehle) voll genutzt werden."

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

233
05.04.2025, 22:05 Uhr
ThomasR

Avatar von ThomasR

Zitat:

HeikoS schrieb(…)

@Thomas: (…) es sei denn mit einem Compiler, das soll es ja auch geben für BASIC.

Der Bascoder in Java kann doch da nicht helfen, oder ? Damit kann man doch nur die Programme auf einem PC schnell laufen lassen, wenn ich das richtig verstehe. Das kann man aber doch auch, in dem man einfach die Geschwindigkeit der Emulation erhöht. Ich hoffe, ich habe das richtig verstanden.(…)

Mir ist durchaus bewusst, dass es Mastermind, Sokoban, Schach, Reversi, Tetris usw. auf jedem Computer attraktiver und schneller gibt als in der BasiCode-Version.

Ist Basic schon langsam, ist BasiCode natürlich erst recht nicht schneller, das ist auch klar. PRINT AT (17,12);“Hello World“ muss schneller sein als HO=17:VE=12:GOSUB 110:PRINT “Hello World“, keine Frage.

Das Faszinierende an BasiCode ist, dass ein Programm ohne aufwändige Anpassungen auf einen anderen Computer übertragen werden kann, so können ein Atari- und ein Commodore-Nutzer unproblematisch gemeinsam arbeiten, ein Spectrum- und ein Amstrad-Nutzer können sich genauso beteiligen wie ein KC85- und ein Amiga-Nutzer.

Der neue Java-Bascoder hebt das noch einmal auf ein neues Niveau, war bisher die Programmiersprache in großen Zügen vereinheitlicht, spielt es nun keine Rolle mehr, ob man vor einem Mac, einem Linux- oder Windows-Computer sitzt.

Ein Programm wie “USA" ermüdet nun nicht mehr, indem man immer wieder neu den langsamen Aufbau der Landkarte abwarten muss, um sich die Maisstaaten, die Kartoffelstaaten, die bevölkerungsreichsten Staaten usw. anzeigen zu lassen, sondern die neue Grafik steht augenblicklich zur Verfügung.

“BC3LOGO“ (das das Agieren mit der Turtle [Schildkröte] aus der Programmiersprache LOGO nachbildet), das seiner Zeit einfach voraus war, ist nun erst sinnvoll nutzbar – der Wermutstropfen für uns hierzulande ist nur, sich die niederländischen Befehle merken zu müssen.

Aber, um endlich auf Deine Fragen einzugehen, ja, auf dem KC würde es erst ein Compiler schön schnell machen und wenigstens in einer Emulation kann man ein höheres Tempo erreichen als auf der Originalhardware, ja, der Java-Bascoder ist für aktuelle Maschinen gemacht (was nicht einmal das Smartphone ausschließen muss).
--
Tot wie ein Dodo?
viele Informationen zu BasiCode auf basicode.de

Cu via komputilo povas Esperanto?
Jes, BasiCode!

Dieser Beitrag wurde am 05.04.2025 um 22:07 Uhr von ThomasR editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

234
06.04.2025, 11:23 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
@Matthias:

Rasterbars am BIC wären eine sehr schöne Sache !!! Das wären dann "echte" Rasterbars" im Gegensatz zu meinem Versuch beim Ju-TE-6K.

Ich vermelde erste Fortschritte. Diese Woche war nicht viel Zeit, aber in kleinen Schritten kam ich voran. Nun habe ich die VSYNC-/HBLANK-Warte-Routinen als Maschinencode per inline() in Turbo Pascal eingebunden. Das hat das Zeitverhalten (verpasste Zeilen) deutlich verbessert. Die PortAusgabe ist noch in TP. Da selbst eine leere Schleife schon grob >100 T-States braucht, muss ich das auch mal in ASM machen.

Das baue ich weiter aus. Jetzt habe ich noch grob im Sekundentakt ein deutliches Hopsen drin. Obwohl ich DI eingebaut habe (wird vllt. duch ein EI von TP wieder aufgehoben?) scheint noch ein Interrupt zu stören. Oder das Timing der Schleife verschiebt sich. Ansonsten sind die Bars (noch nicht ganz sauber) ruhig. Hier mal ein Bild (ohne Farbe, da ich den 1084S wieder zur Schonung abgebaut hatte und noch keinen guten RGB-Scart-Konverter habe):

Ich habe hier erst einmal den "IN F, (C)"-Ansatz genutzt, was nur für Horizontal Blank (eh. am zeitkritischsten) aufgrund der Bitanordnung im GDC-Statusregister funktioniert. Das hatte ich hier schon vorgeschlagen: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#244224

Edit: Nach einem Austausch mit gasman und Ped7g auf dem Sizecoding-Discord im Z80-Kanal wurde nochmal klar, dass der undokumentierte Befehl "in f, (c)" nicht ganz das macht, was die Syntax suggeriert, sondern nur die Flags entspr. des Port-Wertes setzt. Das funktioniert mit dem GDC-Status-Register dennoch, wenn keine parallelen Grafik-Aktivitäten auf dem GDC laufen. Für meine Zwecke reicht es. Die anderen Methoden inkl. Jump-Table sollten wie gedacht funktionieren.

Edit 2: In der Diskussion kam sogar noch ein spannendes Praxisbeispiel für den jp (hl)-Trick zum Vorschein, ein 115200 Baud Serial Receiver für ZX Spectrum 128 von "baze" und "Zilog": https://baze.sk/zx/tukabel.asm
https://x.com/baze3SC/status/1364883125332045824

Zitat:

Noch eine Frage: Hast du evtl. Code-Schnipsel, um Linien mit dem BIC zu zeichnen, die der GDC erzeugt?

Da du ja auf den Mode 0 abzielst, kann ich mal was aus der Literatur (nicht die Doku) raussuchen. Ansonsten werde ich da auch noch eine Routine schreiben, da Cornelius auch schon fragte.

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 06.04.2025 um 19:46 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

235
06.04.2025, 22:57 Uhr
Dresdenboy

Heute konnte ich nochmal so 15 Minuten weitertüfteln, ohne dass die Familie nach mir ruft.

Bzgl. DI und EI hatte ich das EI zu früh gesetzt. Das klappt nun wie erwartet und alles ist stabil. Damit man mehr sieht, habe ich mal einen Grafikmodus mit Palettenfarben aktiviert. So kann man auch schön Vordergrund (untere Linien) und Randbereich bzw. Hintergrund (oben) erkennen. Das Bild ist nicht zentriert. Mit bisschen Timingschieberei sieht das schon recht gut aus: Am rechten Rand ist das Wechseln zu sehen, was nur noch nicht spät genug nach Erkennen der Flanke erfolgt. Der Zeitpunkt selbst schwankt zwischen den Zeilen nur wenig.:

Mit anderen Registern (Zeichenhöhe oder Bildzeilenlänge) geht auch schon etwas.

Edit: Details in Bildbeschreibung

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 07.04.2025 um 08:48 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

236
07.04.2025, 06:45 Uhr
ralle

Vielleicht geht dann auch der Lichtstift. Der wird von GDC auch unterstützt.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

237
07.04.2025, 08:44 Uhr
Dresdenboy

Zitat:

ralle schrieb
Vielleicht geht dann auch der Lichtstift. Der wird von GDC auch unterstützt.

Sollte gehen. Der Anschluss ist auch am A/V-Port herausgeführt.
--
___________________________________
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

238
07.04.2025, 11:16 Uhr
ralle

Ist halt nur nicht richtig beschrieben. Zum Zeichnen durchaus interessant.

Auf dem Schirm Tippen und bunte Kreise generieren...
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Dieser Beitrag wurde am 07.04.2025 um 13:01 Uhr von ralle editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

239
07.04.2025, 17:47 Uhr
Dresdenboy

Zitat:

ralle schrieb
Ist halt nur nicht richtig beschrieben. Zum Zeichnen durchaus interessant.

Auf dem Schirm Tippen und bunte Kreise generieren...

Da das direkt an den GDC geht ist auch das Auslesen dokumentiert. Wichtig wäre nur, ob die Signale passen.
--
___________________________________
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 07.04.2025 um 19:19 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

240
08.04.2025, 07:55 Uhr
HeikoS

@ThomasR:

Danke für Deine Erklärungen zu BasiCode. Ich habe damit ja keine Erfahrung. Es ist schon eine schöne Sache, wenn man Programme sehr einfach auf andere Rechner bringen kann.

Beim BasCoder für Java war ich nicht sicher, welche Intension da genau dahintersteckt. Das ist mir jetzt auch klar. Ich hatte noch gedacht, dass da evtl. auch ein optimierter Maschinen-Code für das jeweilige Zielsystem erzeugt wird. Vielleicht kommt das ja auch noch …

@Matthias:

Sehr schön, dass das mit den Rasterbars beim BIC schon klappt ! Da geht bestimmt noch viel.

Mir war immer so, als hättest du schon mal ein Bsp. für „GDC-Lines“ im Mode 0 gezeigt. Dann muss man das eben aus der GDC-Doku zusammensuchen. Mehrere Bildebenen müssten im Mode 0 auch möglich sein, so dass man immer im Hintergrund zeichnen lassen könnte und dann umschaltet … ? (konnte ja 1977 schon der Apple II). https://www.youtube.com/watch?v=PHfKCxjsmos

Viele Grüße, Heiko

Dieser Beitrag wurde am 08.04.2025 um 12:14 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

241
08.04.2025, 10:59 Uhr
Dresdenboy

@Heiko:
Schönes Video. Ich mag solche tiefergehenden Tüftelvideos.

Die Rasterbars habe ich gestern auch schon kurz mit Sinus-Tabelle bewegt. Das sieht schon gut und v.a. schön flüssig aus. Ich muss nur mal mehr Assembler einbauen, da TP-Code (vmtl. einfach feste Code-Stückchen zusammengesetzt) an Grenzen kommt, um z.B. alles in einer Zeile zu schaffen.

Ja, zu den Linien hatte ich etwas eher zufällig erzeugtes gepostet. Nächster Schritt wäre saubere Linien von Start bis Ende in allen 8 Oktanten im 2-Farb-Modus ohne Clipping.

Versch. Bilder mit Hintergrunderstellung sind kein Problem, da sich das sichtbare Bild einfach aus Start+Höhe+Breite (und Skip) in Wort-Genauigkeit ergibt. Die Linien können beliebig in den Speicher gezeichnet werden, auch über sichtbare Bereiche hinaus. Da wäre dann auch berechnetes Clipping nötig.

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

242
08.04.2025, 14:57 Uhr
Dresdenboy

Ergänzend zu den Ideen und Beispielen hier

Zitat:

Dresdenboy schrieb
Ich habe hier erst einmal den "IN F, (C)"-Ansatz genutzt, was nur für Horizontal Blank (eh. am zeitkritischsten) aufgrund der Bitanordnung im GDC-Statusregister funktioniert. Das hatte ich hier schon vorgeschlagen: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20544#244224

Edit: Nach einem Austausch mit gasman und Ped7g auf dem Sizecoding-Discord im Z80-Kanal wurde nochmal klar, dass der undokumentierte Befehl "in f, (c)" nicht ganz das macht, was die Syntax suggeriert, sondern nur die Flags entspr. des Port-Wertes setzt. Das funktioniert mit dem GDC-Status-Register dennoch, wenn keine parallelen Grafik-Aktivitäten auf dem GDC laufen. Für meine Zwecke reicht es. Die anderen Methoden inkl. Jump-Table sollten wie gedacht funktionieren.

Edit 2: In der Diskussion kam sogar noch ein spannendes Praxisbeispiel für den jp (hl)-Trick zum Vorschein, ein 115200 Baud Serial Receiver für ZX Spectrum 128 von "baze" und "Zilog": https://baze.sk/zx/tukabel.asm
https://x.com/baze3SC/status/1364883125332045824

gab es auch noch spannende Vorschläge aus dem Z80-Sizecoding-Kanal auf Discord:

Zitat:

Ped7g schrieb:
the in l,(c) + jp (hl) is fastest, but you need friendly values on the bus for it to work well, if it's just b6 changing and everything else is fixed, you are golden...
in f,(c) - what gasman wrote, it's flags of the value read processed, ie. 0x00 will cause ZF=1, so again depends on values, if only b6 is alternating and others are fixed and known, you can still use jp pe/po,... to check for b6 variant
...
other alternative is with enough of stable top bits doing in h,(c) instead
but that will trash lot more 256B memory "windows", which are always useful and precious resource... ?
b5 + b6 [Anm. d. Red.: GDC-Status-Bits] can be handled by jp (hl) together, 32 bytes is probably enough to fit whole handler, or you can jr to continuation

Beginnend hier: https://discord.com/channels/787349849808699433/787353321362817044/1358411158822064309

Kommentar "introspec" bzw. "spke": "Love the insanity of it, nice trick."

und von baze/3SC:

Zitat:

I wouldn't disregard Ped's suggestion of using in (c) + jp pe/po or even in a,(c) + add a,a + jp m,somewhere. It depends on whether you optimize for the overall cycle count or for the minimum lag. in l,(c) + jp (hl) will give you the smallest lag but you'll need to reset H at some point I guess. If the handler is long I'd go for in h,(c) + ld l,h + jp (hl)

https://discord.com/channels/787349849808699433/787353321362817044/1358867546937495725

So ist es hier auch mal festgehalten.

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 08.04.2025 um 14:59 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

243
09.04.2025, 11:03 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
Mir war immer so, als hättest du schon mal ein Bsp. für „GDC-Lines“ im Mode 0 gezeigt. Dann muss man das eben aus der GDC-Doku zusammensuchen. Mehrere Bildebenen müssten im Mode 0 auch möglich sein, so dass man immer im Hintergrund zeichnen lassen könnte und dann umschaltet … ? (konnte ja 1977 schon der Apple II). https://www.youtube.com/watch?v=PHfKCxjsmos

Ich zitiere dich nochmal, um dies im Zusammenhang zu halten. Was du vllt. suchst, ist ein Dokument (was ich zwar schon lange liegen hatte, aber den Riesenunterschied erst jetzt bemerkte), was ich im BIC-Thread jetzt mal erwähnt habe. Da findest du alles. Und auch mit sehr vielen Beispielen.

Wie die Bildbereiche funktionieren, ist z.B. anhand dieses Bildes hier erklärt (mit begleitendem Text natürlich):

Neben den auch aus nichtjapanischen Dokumenten bekannten Linienparameter-Berechnungsformeln gibt es im jap. Dokument viel mehr Beispiele, auch gleich mit Kommando+Parameter-Bytes, wie z.B. hier:

Diese könnten fast schon so (bis auf den fehlenden Monochrommodus) in mein BASIC-Beispiel übernommen werden.

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 09.04.2025 um 12:14 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

244
09.04.2025, 12:14 Uhr
HeikoS

Hallo Matthias,

das ist interessant. Ich habe mal alles was ich zum GDC habe auf die Nextcloud gelegt.

- INTEL (englisch)
- RFT (deutsch), oft Übersetzung der INTEL-Doku verwendet
- NEC (englisch)
- NEC (japanisch)

https://nextcloud-ext.peppermint.de/s/7Wqp44YjLBN6Htd

EDIT: Zeichnen von Vektoren wurde in RFT-Doku (Kap. 6.11) aus INTEL-Doku (Kap. 4.13) übernommen. Ist genau so in der NEC (en) Doku zu finden. Da ist die japanische Version wirklich viel ausführlicher !

@Alle:

Weitere Dokumente könnte ich noch dazulegen. Wenn jemand noch was hat, dann einfach melden.

Grüße, Heiko

Dieser Beitrag wurde am 09.04.2025 um 13:02 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

245
14.04.2025, 19:55 Uhr
Dresdenboy

@Heiko:
Die Übersetzung des jap. PDFs ist in Arbeit.

Du fragtest auch mal nach Code für den 7220. Da hätte ich z.B.:
http://www.cpm.z80.de/roche/NCRGRAF.ASM (in 8080 asm, von: http://www.cpm.z80.de/roche/ )

und
http://www.cpm.z80.de/download/nec7220.zip (x86 asm, von http://www.cpm.z80.de/binary.html )
Siehe dort Routine abline in COLNECRE.A86.

Es gibt hier und da noch mehr, was ich nachreichen werde.

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 14.04.2025 um 19:55 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

246
15.04.2025, 01:54 Uhr
Dresdenboy

Ein paar Experimente:

Rasterbars:
https://youtu.be/dxXVoCojtS0

Flash Modus beim Linien zeichnen:
https://youtu.be/gNHGpbfbr-4

Resetten des Bildaufbaus ("jetzt wird's verrückt"

):
https://youtu.be/KOvxtw4E8Yg

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

247
15.04.2025, 07:33 Uhr
ralle

Des ist heftig.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

248
15.04.2025, 10:19 Uhr
Dresdenboy

Das ist erst der Anfang.

Nun habe ich paar Minuten für weitere Details:

Das ist alles noch prototypisch in Turbo Pascal + ASM (d.h. kein tolles Timing). V.a. fehlt noch kein zyklusgenau gesyncter Ablauf, wo die Horizontal Blank Phase genau abgewartet werden kann u. Umschaltungen taktgenau gezielt erfolgen können. Das wird nochmal komplex.

Die Rasterbars ändern nacheinander die Randfarbe und danach andere Farben (daher der Versatz). Der Grafikmodus ist 2farbig.

Im Linienbeispiel mit aktiviertem Flashmodus (wo der GDC auch während der Darstellung zeichnet) sieht man darüberlaufende Streifen als Störung. Das sieht hier nicht schlimm aus, im Textmodus wird es z.B. wilder.

Der Reset des Bildaufbaus ist ein erster Test (war ja schon spät

). So (mit genauerem Timing, auch unten, wo das Bild dann zu lang wird) könnte man schon die Amiga-Workbench-Screens nachbilden.

Aber für 2 Bereiche kann der GDC das eh schon.
Ein Ziel ist, nach Aufbau des oberen Randbereichs die Sync-Parameter zu ändern, um dann mit kleinen, neu parametrierten Bildbereichen lustige Dinge tun zu können.
--
___________________________________
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

249
15.04.2025, 11:18 Uhr
HeikoS

Zitat:

Dresdenboy schrieb
Ein paar Experimente:

Rasterbars:
https://youtu.be/dxXVoCojtS0

Flash Modus beim Linien zeichnen:
https://youtu.be/gNHGpbfbr-4

Resetten des Bildaufbaus ("jetzt wird's verrückt"

):
https://youtu.be/KOvxtw4E8Yg

VG,
Matthias

Nachtschicht ;-) ... vielleicht sollten wir zum 3-Schicht-System übergehen, damit wir die wertvollen Resourcen besser ausnutzen !

Schöne Ansätze ! Bunt wäre noch schöner ... ;-)

Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

250
15.04.2025, 11:38 Uhr
HeikoS

Zitat:

Dresdenboy schrieb
@Heiko:
Die Übersetzung des jap. PDFs ist in Arbeit.

Du fragtest auch mal nach Code für den 7220. Da hätte ich z.B.:
http://www.cpm.z80.de/roche/NCRGRAF.ASM (in 8080 asm, von: http://www.cpm.z80.de/roche/ )

und
http://www.cpm.z80.de/download/nec7220.zip (x86 asm, von http://www.cpm.z80.de/binary.html )
Siehe dort Routine abline in COLNECRE.A86.

Es gibt hier und da noch mehr, was ich nachreichen werde.

VG,
Matthias

Danke für die Tipps ! Kann man gut gebrauchen, um zu sehen, ob man auf dem richtigen Weg ist. Die RFT-GDC-Doku ist ja auch sehr gut. Mir war bisher gar nicht klar, dass man beim Zeichnen von Linien mit dem GDC nicht einfach Anfangs- und Endpunkt angeben kann. Da muss die Host-CPU ja noch einiges machen vorher.

Z.B. |dx|, |dy|, Richtung berechnen. Das macht man ja eh schon in den Standard-Routinen nach Bresenham, ist also kein Problem. Diverse Bsp. aus der MP oder in Treibern in Pascal machen das auch und füttern dann den GDC. Leider kann ich es nicht testen, da ich keinen BIC habe. Behelfe mir dann wahrscheinlich erstmal mit einer Emulation der GDC FIGS/FIGD Befehle mit WDAT im VRAM, oder jemand stellt mir mal einen BIC zur Verfügung. Aber jetzt komme ich noch nicht dazu ...

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

251
15.04.2025, 22:33 Uhr
Dresdenboy

@Heiko:
Ja, Nachtschicht!

Manchmal packt es mich und es findet sich sogar noch Energie im Reserve-Akku. Das hängt ganz davon ab, wie schnell etwas klappt und wie spannend ich es finde. Bei einem Programm zur Berechnung der Fibonacci-Folge hätte ich nicht so durchgehalten.

Da ist dieses Bare Metal Hacking viel aufregender!

Bunt bekomme ich noch hin. Morgen hole ich mir für 5€ einen kleinen TV von jemandem. Mal sehen.

Zum Linienzeichnen:
Es hat was von Turtle-Grafik. Das kann auch vorteilhaft sein (Polygone). Es ist, wie es ist. Und die Berechnungen ohne Clipping sind ja nicht so wild.

Apropos Clipping: Ein mathematisch sauberer Weg wäre ja das Berechnen von Schnittpunkten mit achsparallelen Geraden (Bildränder). Da das schon in Richtung Punktrechnung geht, wäre da nicht auch eine binäre Suche möglich und sogar schneller? Weißt du, wie das in Elite gemacht wurde?

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 15.04.2025 um 22:34 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

252
15.04.2025, 23:01 Uhr
HeikoS

Zitat:

Dresdenboy schrieb

... Apropos Clipping: Ein mathematisch sauberer Weg wäre ja das Berechnen von Schnittpunkten mit achsparallelen Geraden (Bildränder). Da das schon in Richtung Punktrechnung geht, wäre da nicht auch eine binäre Suche möglich und sogar schneller? Weißt du, wie das in Elite gemacht wurde?

VG,
Matthias

Clipping hatte ich bei den ersten Circle-Versuchen mit "Elite-Code" weggelassen. Als dann der 6502-Code immer besser emuliert wurde, hatte ich es wieder reingenommen und ... es lief sofort. Ist recht komplex in 4 Teilen in Elite realisiert und als "Deep Dive Article" verfügbar ... Schön ist die Einleitung dazu:

"Space is big. Vintage computer screens, however, are not big."

-> https://elite.bbcelite.com/deep_dives/line-clipping.html

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

253
16.04.2025, 09:28 Uhr
Dresdenboy

@Heiko:
Das hat der Autor super eingeleitet!

Also Elite nutzt Division für die Gradientenberechnung und Multiplikation, um sie anzuwenden, wenn auch mit Optimierungen (z.B. Skalierung auf Bytes). Aber der "komplett im Bildbereich"-Fall wird ja sinnvollerweise abgefangen. Man kann sich für Effekte auch auf diesen beschränken.

Da müsste ich bei Elite auch mal Zyklen zählen. Meine Vermutung ist, dass eine binäre Suche schneller wäre, da immer nur um 1 bit geschoben werden muss, um ein Intervall zu halbieren (neue Koordinate = (start + ende) >> 1) und sonst nur SBC oder ADC nötig wären.

Und das kann auch nochmal (zumindest für den GDC) vereinfacht werden, indem man um den sichtbaren Bereich herum einen unsichtbaren kleinen Randbereich hat, in den Linien hineingezeichnet werden können. Dann muss ich mit der binären Suche nur in diesen Rand zurückstutzen und kann eher abbrechen.

P.S.: Mit der Funktions-Bestätigung im RESET3-Experiment wären ganz neue Grafikmodi möglich. Ein Kumpel von mir, auch "Citavia"-Gruppenmitglied, hat für das NeoGeo erstmalig eine Bildschirmdarstellung mit beliebig färbbaren Pixeln entwickelt, wo ich bisschen beim 68k-Optimieren half. Da es Sprite-basiert ist, ist das mit anderen Bildelementen kombinierbar. Wir haben also Erfahrung mit so etwas.

Dieser Beitrag wurde am 16.04.2025 um 09:43 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

254
16.04.2025, 10:23 Uhr
Dresdenboy

Zitat:

HeikoS schrieb
@Alle:

Weitere Dokumente könnte ich noch dazulegen. Wenn jemand noch was hat, dann einfach melden.

Grüße, Heiko

In diesem Beitrag hat P.S. zumindest seine Literaturliste bereitgestellt. Da könnte man nochmal abgleichen, was wir haben.

Für meine aktuellen Funde muss ich mal eine Tabelle machen.
--
___________________________________
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

255
17.04.2025, 16:23 Uhr
Dresdenboy

@Heiko:
Farbfilmchen für dich!

https://youtu.be/TSeyJxHM7U0
und
https://youtu.be/5srV9o1POLE

VG
--
___________________________________
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

256
17.04.2025, 21:47 Uhr
HeikoS

Sehr schön ! Endlich Farbfernsehen - was wir ja in der DDR schon seit 1969 hatten ;-)

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

257
17.04.2025, 21:52 Uhr
HeikoS

Zitat:

Dresdenboy schrieb

.... In diesem Beitrag hat P.S. zumindest seine Literaturliste bereitgestellt. Da könnte man nochmal abgleichen, was wir haben ...

Sehr schöne Liste von Peter, das packe ich mal in die Nextcloud !

EDIT: Ist drin: https://nextcloud-ext.peppermint.de/s/7Wqp44YjLBN6Htd

Grüße, Heiko

Dieser Beitrag wurde am 17.04.2025 um 21:57 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

258
18.04.2025, 05:02 Uhr
ralle

Heiko, SECAM.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

259
18.04.2025, 13:51 Uhr
HeikoS

@Ralle:

Ja, aber warum erzeugt der KC85/3/4 ein feindliches PAL-Signal ... ;-)

Nach dem Tipp von Volker zum Basic-Compiler im JKCEMU hatte ich gleich mal ein paar Tests dazu gemacht. Tolles Werkzeug !

Das Bsp. hier : https://thecodingtrain.com/challenges/175-3D-cube-applesoft-basic sollte doch eigentlich laufen, dachte ich. Etwas umgebaut: SIN-Tabelle, Datentyp INTEGER und alles Überflüssige in der Berechnung entfernt, waren notwendig. Double Buffer kann der KC85 4/5 auch.

Wer es mal ausprobieren möchte, kann den Quelltext im Programmier-Fenster vom JKCEMU laden, eine BIN/KCC-Datei mit dem Compiler erzeugen und es auf echter HW ausprobieren.

Es ist langsamer als ich dachte, aber das liegt auch an den nicht so schnellen Grafik-Routinen, die der Compiler einbindet. Kann man gut sehen, wenn man den Zoom-Faktor mal ändert, z.B.: „ZO = 4“. Dann gibt es einen kleineren Würfel, der sich schneller dreht.

Grüße, Heiko

Quellcode:


10 CLS
30 CX = 160 : CY = 128         : REM CENTER SCREEN POS

35 ZO = 2                      : REM ZOOM FACTOR (INVERS)

40 DIM PTS(7,2)
50 DIM RZP(7,2) : DIM RYP(7,2)
60 DIM SNE (32) AS INTEGER     : REM SIN TABLE

70 GOSUB 5000                  : REM INIT CUBE
80 GOSUB 8000                  : REM INIT SIN TABLE
90 GOSUB 2000                  : REM INIT ARRAY, ROTATE POINTS
95 ASM " CALL INIT_SCREEN"

100 REM --- DRAW LOOP
110 FOR ANGEL=0 TO 15
120 ASM " CALL SWITCH_SCREEN"  : REM BUFFER SWITCH
130 CLS
140 GOSUB 2000 : REM ROTATE POINTS
150 GOSUB 6000 : REM LINES
160 NEXT ANGEL
170 GOTO 100

2000 REM --- ROTATE POINTS
2001 CS = SNE(ANGEL+16): REM COS
2010 SN = SNE(ANGEL)   : REM SIN
2020 FOR N = 0 TO 7
2030 RZP(N,0) =   -CS * PTS(N,0)     + SN * PTS(N,1) 
2040 RZP(N,1) =    SN * PTS(N,0)     + CS * PTS(N,1)
2060 RYP(N,0) =  ( CS * RZP(N,0)/128 + SN * PTS(N,2)) / ZO + CX
2070 RYP(N,1) =  ( RZP(N,1))                          / ZO + CY
2120 NEXT N
2130 RETURN 

5000 REM --- THE CUBE
5001 PTS(0,0) = -1: PTS(0,1) = -1 : PTS(0,2) = -1
5010 PTS(1,0) =  1: PTS(1,1) = -1 : PTS(1,2) = -1
5020 PTS(2,0) =  1: PTS(2,1) =  1 : PTS(2,2) = -1
5030 PTS(3,0) = -1: PTS(3,1) =  1 : PTS(3,2) = -1
5040 PTS(4,0) = -1: PTS(4,1) = -1 : PTS(4,2) =  1
5050 PTS(5,0) =  1: PTS(5,1) = -1 : PTS(5,2) =  1
5060 PTS(6,0) =  1: PTS(6,1) =  1 : PTS(6,2) =  1
5070 PTS(7,0) = -1: PTS(7,1) =  1 : PTS(7,2) =  1
5080 RETURN 

6000 REM --- DRAW LINES
6010 LINE RYP(0,0),RYP(0,1),RYP(1,0),RYP(1,1)
6020 LINE RYP(1,0),RYP(1,1),RYP(2,0),RYP(2,1)
6030 LINE RYP(2,0),RYP(2,1),RYP(3,0),RYP(3,1)
6040 LINE RYP(3,0),RYP(3,1),RYP(0,0),RYP(0,1)
6050 LINE RYP(4,0),RYP(4,1),RYP(5,0),RYP(5,1)
6060 LINE RYP(5,0),RYP(5,1),RYP(6,0),RYP(6,1)
6070 LINE RYP(6,0),RYP(6,1),RYP(7,0),RYP(7,1)
6080 LINE RYP(7,0),RYP(7,1),RYP(4,0),RYP(4,1)
6090 LINE RYP(0,0),RYP(0,1),RYP(4,0),RYP(4,1)
6100 LINE RYP(1,0),RYP(1,1),RYP(5,0),RYP(5,1)
6110 LINE RYP(2,0),RYP(2,1),RYP(6,0),RYP(6,1)
6120 LINE RYP(3,0),RYP(3,1),RYP(7,0),RYP(7,1)
6130 RETURN 

8000 REM --- SIN TABLE
SNE(0)  = &H00
SNE(1)  = &H0D
SNE(2)  = &H19
SNE(3)  = &H25
SNE(4)  = &H31
SNE(5)  = &H3C
SNE(6)  = &H47
SNE(7)  = &H51
SNE(8)  = &H5B
SNE(9)  = &H63
SNE(10) = &H6A
SNE(11) = &H71
SNE(12) = &H76
SNE(13) = &H7A
SNE(14) = &H7E
SNE(15) = &H7F
SNE(16) = &H7F
SNE(17) = &H7F
SNE(18) = &H7E
SNE(19) = &H7A
SNE(20) = &H76
SNE(21) = &H71
SNE(22) = &H6A
SNE(23) = &H63
SNE(24) = &H5B
SNE(25) = &H51
SNE(26) = &H47
SNE(27) = &H3C
SNE(28) = &H31
SNE(29) = &H25
SNE(30) = &H19
SNE(31) = &H0D
RETURN

ASM "INIT_SCREEN:"
 ASM " LD A,(IX+1)"
 ASM " RES 0,A"
 ASM " SET 2,A"
 ASM " LD (IX+1),A"
 ASM " OUT (84H), A"
 ASM " RET"

ASM "SWITCH_SCREEN:"
 ASM " LD A,(IX+1)"
 ASM " XOR A, 00000101B
 ASM " LD (IX+1),A"
 ASM " OUT (84H), A"
 ASM " RET"

Dieser Beitrag wurde am 18.04.2025 um 14:36 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

260
18.04.2025, 15:03 Uhr
HeikoS

Läuft auch auf dem KC85/1, KC87, Z9001 mit KRT-Grafik fast ohne Änderungen. Aber da sieht man dann die etwas geringe Geschwindigkeit des Line-Befehls, da kein Double-Buffer vorhanden ist.

Quellcode:


10 SCREEN(1)
20 CLS
30 CX = 160 : CY = 96            : REM CENTER SCREEN POS

35 ZO = 2               : REM ZOOM FACTOR (INVERS)

40 DIM PTS(7,2)
50 DIM RZP(7,2) : DIM RYP(7,2)
60 DIM SNE (32) AS INTEGER     : REM SIN TABLE

70 GOSUB 5000                  : REM INIT CUBE
80 GOSUB 8000                  : REM INIT SIN TABLE
90 GOSUB 2000                  : REM INIT ARRAY, ROTATE POINTS

100 REM --- DRAW LOOP
110 FOR ANGEL=0 TO 15
130 CLS
140 GOSUB 2000 : REM ROTATE POINTS
150 GOSUB 6000 : REM LINES
155 PAUSE(2)
160 NEXT ANGEL
170 GOTO 100

2000 REM --- ROTATE POINTS
2001 CS = SNE(ANGEL+16): REM COS
2010 SN = SNE(ANGEL)   : REM SIN
2020 FOR N = 0 TO 7
2030 RZP(N,0) =   -CS * PTS(N,0)     + SN * PTS(N,1) 
2040 RZP(N,1) =    SN * PTS(N,0)     + CS * PTS(N,1)
2060 RYP(N,0) =  ( CS * RZP(N,0)/128 + SN * PTS(N,2)) / ZO + CX
2070 RYP(N,1) =  ( RZP(N,1))                          / ZO + CY
2120 NEXT N
2130 RETURN 

5000 REM --- THE CUBE
5001 PTS(0,0) = -1: PTS(0,1) = -1 : PTS(0,2) = -1
5010 PTS(1,0) =  1: PTS(1,1) = -1 : PTS(1,2) = -1
5020 PTS(2,0) =  1: PTS(2,1) =  1 : PTS(2,2) = -1
5030 PTS(3,0) = -1: PTS(3,1) =  1 : PTS(3,2) = -1
5040 PTS(4,0) = -1: PTS(4,1) = -1 : PTS(4,2) =  1
5050 PTS(5,0) =  1: PTS(5,1) = -1 : PTS(5,2) =  1
5060 PTS(6,0) =  1: PTS(6,1) =  1 : PTS(6,2) =  1
5070 PTS(7,0) = -1: PTS(7,1) =  1 : PTS(7,2) =  1
5080 RETURN 

6000 REM --- DRAW LINES
6010 LINE RYP(0,0),RYP(0,1),RYP(1,0),RYP(1,1)
6020 LINE RYP(1,0),RYP(1,1),RYP(2,0),RYP(2,1)
6030 LINE RYP(2,0),RYP(2,1),RYP(3,0),RYP(3,1)
6040 LINE RYP(3,0),RYP(3,1),RYP(0,0),RYP(0,1)
6050 LINE RYP(4,0),RYP(4,1),RYP(5,0),RYP(5,1)
6060 LINE RYP(5,0),RYP(5,1),RYP(6,0),RYP(6,1)
6070 LINE RYP(6,0),RYP(6,1),RYP(7,0),RYP(7,1)
6080 LINE RYP(7,0),RYP(7,1),RYP(4,0),RYP(4,1)
6090 LINE RYP(0,0),RYP(0,1),RYP(4,0),RYP(4,1)
6100 LINE RYP(1,0),RYP(1,1),RYP(5,0),RYP(5,1)
6110 LINE RYP(2,0),RYP(2,1),RYP(6,0),RYP(6,1)
6120 LINE RYP(3,0),RYP(3,1),RYP(7,0),RYP(7,1)
6130 RETURN 

8000 REM --- SIN TABLE
SNE(0)  = &H00
SNE(1)  = &H0D
SNE(2)  = &H19
SNE(3)  = &H25
SNE(4)  = &H31
SNE(5)  = &H3C
SNE(6)  = &H47
SNE(7)  = &H51
SNE(8)  = &H5B
SNE(9)  = &H63
SNE(10) = &H6A
SNE(11) = &H71
SNE(12) = &H76
SNE(13) = &H7A
SNE(14) = &H7E
SNE(15) = &H7F
SNE(16) = &H7F
SNE(17) = &H7F
SNE(18) = &H7E
SNE(19) = &H7A
SNE(20) = &H76
SNE(21) = &H71
SNE(22) = &H6A
SNE(23) = &H63
SNE(24) = &H5B
SNE(25) = &H51
SNE(26) = &H47
SNE(27) = &H3C
SNE(28) = &H31
SNE(29) = &H25
SNE(30) = &H19
SNE(31) = &H0D
RETURN

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

261
18.04.2025, 17:37 Uhr
ralle

Das Drehen ginge schneller, wenn beim KC85/4 (5) einzelne Bildsequenzen erzeugt werden und auf einem Datenträger, ersatzweise 4xM035 abgelegt werden und danach per Schwitch in den Bildspeicher kopiert wird. So wird das mit Globus gemacht. Einzelne Bilder werden in einem M011 abgelegt.

@Heiko, in den 1980er wurden PAL-Decoder in Serie verbaut. Das Encodieren war vermutlich nicht so aufwändig. Bei einem Color20 hätte man direkt in die Farbstufen gehen müssen. Tatsächlich wurde das französische SECAM bevorzugt.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

262
18.04.2025, 18:28 Uhr
HeikoS

@Ralle
Ja, es geht ja hier darum, die Performance des Compilers von Jens zu testen. Laden von Sequnzen ist natürlich schneller. Zu Farbe: Ja, SECAM ist aufwendiger in der Erzeugung. Das wird der Grund sein.

Die Geschwindigkeit des JKCEMU-Compilers ist schon sehr gut. Mit dem Datentyp INTEGER werden aber immer 16 Bit verwendet. BYTE wäre da bei manchen Berechnungen noch schneller. Die Programmierer von ELITE haben das ja vorgemacht. Immer im bestenmöglichen Datentyp bzgl. Geschwindkeit der Berechnungen gearbeitet - teilweise schon Daten so abgespeichert, dass die Berechnungen schneller werden.

Hier noch ein Bsp., bei dem das Löschen nicht durch CLS erfolgt sondern durch den Line-Befehl. Da sieht man sehr deutlich, dass das Zeichnen der Flaschenhals ist.

Ist nur wenig zu ändern:

Quellcode:


100 REM --- DRAW LOOP
110 FOR ANGEL=0 TO 15
120 PEN(PEN_ERASER)
130 GOSUB 6000                  : REM LINES
140 GOSUB 2000                  : REM ROTATE POINTS
145 PEN(PEN_NORMAL)
150 GOSUB 6000                  : REM LINES
160 NEXT ANGEL
170 GOTO 100

Das Zeichnen dauert zu lange, um eine flüssige Bewegung zu ermöglichen. Die Grafik-Befehle des Compilers sind aber sicher nicht auf Geschwindigkeit getrimmt, sondern eher dahingehend optimiert, dass eine Kompatibilität auf allen Systemen gegeben ist und es wird ja auch noch die Farbe berücksichtigt.

Grüße, Heiko ... da das Wetter nicht berauschend ist, kann der Rechner mal wieder richtig gefüttert werden :-)

Dieser Beitrag wurde am 18.04.2025 um 23:19 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

263
18.04.2025, 21:34 Uhr
Bert

Ich nehme mal stark an, daß der Compiler beim Mühlhausen-KC die Grafikbefehle an's CAOS (UP LINE) durchreicht. Je nach CAOS (und IRM-Aufbau) dauert das etwas. I.d.R. je neuer, desto schneller.
Aber die CAOS Routinen setzen auch die Farbe korrekt und berücksichtigen den HiRes-Mode.
Das ist ggf. redundant.

Bei GLOBUS wird auch etwas getrickst. Das arbeitet nur so flüssig, weil die Ausgabe auf 64x64 Pixel begrenzt ist:
https://github.com/boert/KC85.5_GLOBSHOW
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

264
18.04.2025, 23:12 Uhr
HeikoS

Das Gute ist ja, dass man den erzeugten Assembler-Code ausgeben lassen kann. Dort kann man sehen, wie LINE implementiert ist:

Habs mal hier abgelegt: https://nextcloud-ext.peppermint.de/s/AWawCLmwsztFMQE

Ab Zeile 1103 beginnt LINE. Einen Aufruf im CAOS von LINE (CALL F003H -> UP-Nr. 3EH) kann ich direkt nicht finden. Ich denke das ist alles von Jens neu implementiert und zwar so, dass man das auf allen anderen Rechnern (z.B. mit KRT-Grafik) auch nutzen kann. Da kann man es ja nicht weiterreichen. Der Code für den KC85/1 KRT sieht eigentlich genauso aus wie für den KC85/4, nur die Ermittlung der VRAM-Adresse und das Farbensetzen ist anders, da ja der Speicher anders organisiert ist. Jens ist verrückt ... (im positiven Sinne ;-) )

Grüße, Heiko

Auszug ab Zeile 1103:

Quellcode:


DRAW_LINE:
    LD    HL,(LINE_M_EY)
    LD    DE,(LINE_M_BY)
    OR    A
    SBC    HL,DE
    JR    NZ,DRAW_LINE1
    CALL    H_BOX
    RET    C
    JP    DRAW_HLINE
DRAW_LINE1:
    LD    DE,(LINE_M_BX)
    LD    HL,(LINE_M_BY)
    CALL    XPSET
DRAW_LINE2:
    LD    BC,0001H
    LD    HL,(LINE_M_EX)
    LD    DE,(LINE_M_BX)
    OR    A
    SBC    HL,DE
    BIT    7,H
    JR    Z,DRAW_LINE3
    CALL    I2_NEG_HL
    LD    BC,0FFFFH
DRAW_LINE3:
    LD    (LINE_M_SX),BC
    PUSH    HL
    PUSH    HL
    LD    BC,0001H
    LD    HL,(LINE_M_EY)
    LD    DE,(LINE_M_BY)
    OR    A
    SBC    HL,DE
    BIT    7,H
    JR    Z,DRAW_LINE4
    CALL    I2_NEG_HL
    LD    BC,0FFFFH
DRAW_LINE4:
    LD    (LINE_M_SY),BC
    PUSH    HL
    EXX
    POP    BC
    POP    DE
    EXX
    EX    DE,HL
    POP    HL
    OR    A
    SBC    HL,DE
    JR    C,DRAW_LINE7
    EXX
    LD    H,D
    LD    L,E
    SRA    H
    RR    L
    EXX
    LD    DE,(LINE_M_BX)
        ........
        ........

Dieser Beitrag wurde am 18.04.2025 um 23:18 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

265
19.04.2025, 09:59 Uhr
Bert

Da wurde die generische Lösung gegenüber der 'kurzen' Lösung bevorzugt. Stark.
Ich hab den ASM-Code an drei Stellen angefasst und konnte ihn mit z80asm nach binär wandeln...
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

266
19.04.2025, 11:54 Uhr
P.S.

Grafik-Programmierung ist das eigentliche HighLight in der Computerei. Da Ihr hier so eifrig diskutiert, wolle ich mich eigentlich raushalten.
Aber nach einigen Telefongesprächen mit HeikoS sind außer Anmerkungen auch Fragen meinerseits aufgetaucht:
1) 3D-Programmieung habe ich das erste Mal auf der 5.Computerfachtagung in Frankfurt/O 1988 gesehen und war sehr beeindruckt, was auf dem KC85 so alles geht - ich hatte das hier im RT-Forum schon mehrfach erwähnt ...
2) Der BIC hat zwar den GDC U82720D als Controller, aber nur mit monochomen Monitor ist das m.E. nicht wirklich brauchbar. Konnte man am BIC auch über RGB z.B. den KCM38 anschließen?
3) In diesem Zusammenhang hatten wir neulich im ISS eine Diskussion über Monitor-Bildröhren - wo kamen die eigentlich her (TUNGSRAM?), das WF hat keine produziert, außer der für den KCM38.

Hier noch zwei Hinweise zu einem ganz frühen Grafik-Programm von meinem Ex-Kollegen aus dm IBG - "Grafik 1.5":
http://www.ps-blnkd.de/KC%2085/Grafik1-5%20Beschreibung.pdf,
http://www.ps-blnkd.de/KC%2085/Grafik1-5%20ListDetails.txt

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß gar nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Dieser Beitrag wurde am 19.04.2025 um 11:55 Uhr von P.S. editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

267
19.04.2025, 12:38 Uhr
Rüdiger
Administrator

Zitat:

P.S. schrieb
Hier noch zwei Hinweise zu einem ganz frühen Grafik-Programm von meinem Ex-Kollegen aus dm IBG - "Grafik 1.5":

Hat jemand dieses Programm?
--
Kernel panic: Out of swap space.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

268
19.04.2025, 12:43 Uhr
ralle

@PS, Peter, der BIC gibt aus beiden Monitor Ausgängen an der DSE ein Bild aus. Bei Monochrom sieht man nur nicht viel, aber per RGB am AV geht es. Dazu reicht sogar ein Farb-TV mit Scart.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

269
19.04.2025, 17:40 Uhr
HeikoS

Hier der animierte Würfel noch als HC-BASIC-Programm im Vergleich zur JKCEMU-Compiler-Version:

HC-BASIC:

JKCEMU-Compiler:

Viel Spaß damit !
Grüße, Heiko

EDIT: Damit soll der JKCEMU-Compiler-Test erstmal abgeschlossen sein. Es lohnt sich schon, den Compiler zu benutzen, finde ich. Vielleicht hat ja noch jemand Programme, die man damit beschleunigen könnte.

Jetzt erstmal "Frohe Ostern !"

Und der HC-BASIC-Quellcode:

Quellcode:


10 CLS
20 PRINT CHR$(27); "3";
25 CLS

30 CX = 160 : CY = 128      : REM CENTER SCREEN POS

35 ZO = 2                   : REM ZOOM FACTOR (INVERS)

40 DIM PTS(7,2)
50 DIM RZP(7,2) 
55 DIM RYP(7,2)
60 DIM SNE(32)              : REM SIN TABLE

70 GOSUB 5000               : REM INIT CUBE
80 GOSUB 8000               : REM INIT SIN TABLE
90 GOSUB 2000               : REM INIT ARRAY, ROTATE POINTS

100 REM --- DRAW LOOP
110 FOR ANGEL=0 TO 15
111 SC = NOT SC
115 IF SC = 0 THEN PRINT CHR$(27); "3";
116 IF SC <> 0 THEN PRINT CHR$(27); "4"
130 CLS
140 GOSUB 2000 : REM ROTATE POINTS
150 GOSUB 6000 : REM LINES
160 NEXT ANGEL
170 GOTO 100

2000 REM --- ROTATE POINTS
2001 CS = SNE(ANGEL+16): REM COS
2010 SN = SNE(ANGEL)   : REM SIN
2020 FOR N = 0 TO 7
2030 RZP(N,0) =   -CS * PTS(N,0)     + SN * PTS(N,1) 
2040 RZP(N,1) =    SN * PTS(N,0)     + CS * PTS(N,1)
2060 RYP(N,0) =  ( CS * RZP(N,0)/128 + SN * PTS(N,2)) / ZO + CX
2070 RYP(N,1) =  ( RZP(N,1))                          / ZO + CY
2120 NEXT N
2130 RETURN 

5000 REM --- THE CUBE
5001 PTS(0,0) = -1: PTS(0,1) = -1 : PTS(0,2) = -1
5010 PTS(1,0) =  1: PTS(1,1) = -1 : PTS(1,2) = -1
5020 PTS(2,0) =  1: PTS(2,1) =  1 : PTS(2,2) = -1
5030 PTS(3,0) = -1: PTS(3,1) =  1 : PTS(3,2) = -1
5040 PTS(4,0) = -1: PTS(4,1) = -1 : PTS(4,2) =  1
5050 PTS(5,0) =  1: PTS(5,1) = -1 : PTS(5,2) =  1
5060 PTS(6,0) =  1: PTS(6,1) =  1 : PTS(6,2) =  1
5070 PTS(7,0) = -1: PTS(7,1) =  1 : PTS(7,2) =  1
5080 RETURN 

6000 REM --- DRAW LINES
6010 LINE RYP(0,0),RYP(0,1),RYP(1,0),RYP(1,1),7
6020 LINE RYP(1,0),RYP(1,1),RYP(2,0),RYP(2,1),7
6030 LINE RYP(2,0),RYP(2,1),RYP(3,0),RYP(3,1),7
6040 LINE RYP(3,0),RYP(3,1),RYP(0,0),RYP(0,1),7
6050 LINE RYP(4,0),RYP(4,1),RYP(5,0),RYP(5,1),7
6060 LINE RYP(5,0),RYP(5,1),RYP(6,0),RYP(6,1),7
6070 LINE RYP(6,0),RYP(6,1),RYP(7,0),RYP(7,1),7
6080 LINE RYP(7,0),RYP(7,1),RYP(4,0),RYP(4,1),7
6090 LINE RYP(0,0),RYP(0,1),RYP(4,0),RYP(4,1),7
6100 LINE RYP(1,0),RYP(1,1),RYP(5,0),RYP(5,1),7
6110 LINE RYP(2,0),RYP(2,1),RYP(6,0),RYP(6,1),7
6120 LINE RYP(3,0),RYP(3,1),RYP(7,0),RYP(7,1),7
6130 RETURN 

8000 REM --- SIN TABLE
8001 SNE(0)  = 0
8002 SNE(1)  = 13
8003 SNE(2)  = 25
8004 SNE(3)  = 37
8005 SNE(4)  = 49
8006 SNE(5)  = 60
8007 SNE(6)  = 71
8008 SNE(7)  = 81
8009 SNE(8)  = 91
8010 SNE(9)  = 99
8011 SNE(10) = 106
8012 SNE(11) = 113
8013 SNE(12) = 118
8014 SNE(13) = 122
8015 SNE(14) = 126
8016 SNE(15) = 127
8017 SNE(16) = 127
8018 SNE(17) = 127
8019 SNE(18) = 126
8020 SNE(19) = 122
8021 SNE(20) = 118
8022 SNE(21) = 113
8023 SNE(22) = 106
8024 SNE(23) = 99
8025 SNE(24) = 91
8026 SNE(25) = 81
8027 SNE(26) = 71
8028 SNE(27) = 60
8029 SNE(28) = 49
8030 SNE(29) = 37
8031 SNE(30) = 25
8032 SNE(31) = 13
8100 RETURN

Dieser Beitrag wurde am 19.04.2025 um 18:51 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

270
19.04.2025, 20:57 Uhr
susowa

Zitat:

Hat jemand dieses Programm?

Befindet sich im alten Download-Bereich der KC-Club Seite in der Rubrik CAOS -> "Programme für den KC85/3" in mehreren Versionen.

MfG

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

271
20.04.2025, 09:37 Uhr
P.S.

Zitat:

susowa schrieb

Zitat:

Hat jemand dieses Programm?

Befindet sich im alten Download-Bereich der KC-Club Seite in der Rubrik CAOS -> "Programme für den KC85/3" in mehreren Versionen.
MfG

@Rüdiger <267>
Wie auf meiner HP zu lesen ist, hatte mir Manfred Feindt das Programm nebst allen seinen Unterlagen dazu übergeben. In Benutzung hatte ich das Prgramm nur selten, weil mir die lange Kassetten-Ladezeit zu nervig war. Eine EPROM-Version war allerdings angedacht/in Arbeit (?), aber durch die gesellschaftspolitischen Umbrüche 1989/90 -> http://www.ps-blnkd.de/Nach1990.htm - dann nicht mehr vollendet ...
Wie bekannt sind alle diesbezügliche HW, SW und Unterlagen an das Elektromuseum nach Erfurt gegangen. Vielleicht kann Mario mal nachschauen, ob da noch was existiert - auch das CAOS 2.4 !
Ob die Grafik-Programme auf der KC-Club Seite mit dem von M.F. was zu tun haben, könnte evtl. an Hand der von mir verlinkten Beschreibung verifiziert werden.

Übrigens habe ich den Hinweis auf die 5. Computerfachtagung in Frankfurt/O. gefunden ->
http://www.kc85emu.de/scans/fa0189/Tagung.htm
In -> MP1988/11/328-329 - "3D-Simulation - interaktiver Entwurf von räumlichen Modellen" ist das von mir damals so bestaunte Programm von Andreas Thierbach vorgestellt worden. Auch die anderen Namen aus dem "funkamateur"-Artikel sind mir noch bestens bekannt:
- Dr. D. Scheuchner aus dem IfAM Frankfurt/O und -> https://scheuschner.de/
- Uwe Zierrott, der hatte in Frankfurt/O. einen Elektronik-Computerladen (!), war auch Entwickler/Programmierer für vieles Nützliche in damaliger Zeit -> https://www.zierott-computer.de/.
Selbst Andreas Thierbach gibt es noch -> https://www.pbp-gmbh.de/

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß gar nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Dieser Beitrag wurde am 20.04.2025 um 18:59 Uhr von P.S. editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

272
20.04.2025, 10:55 Uhr
HeikoS

@P.S.

In der MP sind ja sogar Screen-Shots zu dem gesuchten Programm zum Thema "3D-Simulation - interaktiver Entwurf von räumlichen Modellen":

Kennt jemand von der KC-Gemeinde das Programm? Existiert es noch?

Grüße, Heiko

Dieser Beitrag wurde am 20.04.2025 um 10:56 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

273
21.04.2025, 08:27 Uhr
jmueller

Heike hatte mich wegen dem im JKCEMU enthaltenen BASIC-Compiler angeschrieben.
Deswegen möchte ich hier noch folgende Infos geben:

HeikoS schrieb in 262:

Zitat:

Der BASIC-Compiler kann Programmcode für verschiedene Systeme mit unterschiedlicher Grafik-Hardware erzeugen.
Aufgrund dieser Portabilität gibt es eine generische und eine hardware- bzw. treiberspezifische Ebene.
Die High-Level-Funktionen wie Zeichnen einer Linie, eines Kreises und Füllen von Flächen sind in der generischen Ebene implementiert.
Diese rufen dann die jeweilige Funktion zum Setzen eines Pixels auf, die in der treiberspezifischen Ebene implementiert ist.
Für Code-Forscher: Die Assembler-Marken der treiberspezifischen Ebene beginnen mit X.

Würde man die High-Level-Funktionen direkt hardware- bzw. treiberspezifisch implementieren,
ließe sich noch etwas Performance herausholen.
Das würde allewrdings die Code-Erzeugung deutlich verkomplizieren.
Ich habe mir aber ehrlich gesagt schon Mühe gegeben, die Routinen performant zu implemrntieren.

Es gibt jedoch noch einen weiteren Punkt, der beim JKCEMU BASIC-Compiler etwas Performance frist:
Die Koordinaten der Grafikroutinen rechnen alle mit 16 Bit, auch die Y-Koordinate,
obwohl bei keinem der unterstützten Zielsysteme diese größer als 255 Zeichen werden kann.
Es war von mir eine gewollte Zielsetzung, auch im unsichtbaren Bereich zeichnen zu können.
Das mag auf den ersten Blich etwas sinnlos erscheinen, aber der Hintergrund ist folgender:
Möchte man z.B eine Sonne in der oberen Ecke zeichen wollen, könnte man einen Kreis malen,
der nur zu einem Viertel im sichtbaren Bereich liegt. In dem Fall soll die CIRCLE-Anweisung
nicht abstürzen.
Auch könnte man Heikos Würfel soweit vergrößern, dass beim Routieren eine Ecke mal
außerhalb des Bildbereichs rutscht. Auch da sollte die LINE-Anweisung nicht abstürzen.

Ich habe das mal mit den Grafikroutinen auf dem KC85/4 ausprobiert.
Die CIRCLE-Routine scheint kein Problem zu haben, auch im unsichtbaren Bereich zu zeichnen.
Die LINE-Routine produziert dann aber Chaos.
Ohne es nachgeprüft zu haben, denke ich, dass hier die Y-Koordinate nur mit 8 Bit rechnet,
was natürlich schneller ist, als die 16-Bit-Operationen im JKCEMU BASIC-Compiler.

Wie auch immer, aus Interesse habe ich mal die Performance verglichen,
und zwar konkret zwischen den Routinen des BASIC-Compilers im JKCEMU 0.9.8.4 mit den Grafikroutinen im CAOS 4.2.

Wichtig ist, im BASIC-Compiler das Zielsystem "KC85/4 mit Unterstützung beider Bildspeicher" auswählen
und im Reiter "Laufzeiteigenschaften" die Option "Comilieren für Produktiveinsatz" auswählen!
Nur so erreicht man die maximale Performace.

Hier nun das Testprogramm zum Zeichnen von Linien:

Quellcode:


cls
rem 27807772 Takte
gosub with_jkcemu
pause 50

cls
rem 23694063 Takte
gosub with_caos
pause 50

cls
end

with_jkcemu:
  color white
  for x=0 to 318 step 2
    line x,0,319-x,254
  next x
  return

with_caos:
  for x=0 to 318 step 2
    x2=319-x
    asm " LD HL,(V_I2_X2)"
    asm " LD (0B782H),HL"
    asm " LD HL,00FEH"
    asm " LD (0B784H),HL"
    asm " LD HL,(V_I2_X)"
    asm " LD (0B786H),HL"
    asm " LD HL,0000H"
    asm " LD (0B788H),HL"
    asm " LD A,78H"
    asm " LD (0B7D6H),A"
    asm " CALL 0F003h"
    asm " DB 3Eh"
  next x
  return

Das Unterprogramm zum Zeichnen der Linien benötigt mit der LINE-Anweisung des BASIC-Compilers 27807772 Takte und mit der CAOS-Funktion 23694063 Takte.
Damit braucht die Version mit Compiler-Routine ca. 17% mehr Zeit.
Unter Berücksichtigung der o.g. Ausführungen zeigt das aus meiner Sicht,
das die Routinen schon performant implementiert sind.

Wer die Taktzyklen nachprüfen möchte, setzt in den BASIC-Comiler-Optionen
im Reiter "Sonstiges" das Häkchen beim "Erzeugten Assembler-Code anzeigen",
assembliert diesen, damit im Texteditor die Adressen angezeigt werden
und setzt dann auf die Adresse mit dem jeweiligen GOSUB-Befehl einen Haltepunkt im Debugger.
Sobald der Haltepunkt erreicht wurde, setzt man im Debugger den Taktzyklenzähler zurück
und ruft dann die Funktion "Einzelschritt über Aufruf hinweg" auf.

Und hier nun das Programm zum Testen der CIRCLE-Funktion:

Quellcode:


cls
rem 5048899 Takte
gosub with_jkcemu
pause 50

cls
rem 4788704 Takte
gosub with_caos
pause 50

cls
end

with_jkcemu:
  color white
  for r=5 to 125 step 5
    circle 160, 128, r
  next r
  return

with_caos:
  for r=5 to 125 step 5
    asm " LD HL,00A0H"
    asm " LD (0B782H),HL"
    asm " LD HL,0080H"
    asm " LD (0B784H),HL"
    asm " LD HL,(V_I2_R)"
    asm " LD (0B786H),HL"
    asm " LD A,78H"
    asm " LD (0B7D6H),A"
    asm " CALL 0F003h"
    asm " DB 3Fh"
  next r
  return

Hier braucht die Routine des BASIC-Compilers sogar nur gut 5% mehr Zeit.
Da bin ich persönlich ganz zufrieden damit.

Wenn man sicherstellen kann, dass das Programm nicht außerhalb des Bildschirmes malen will,
wären die CAOS-Routinen besser, auch weil das erzeugte Programm kleiner wird.
Ich denke, ich werde im BASIC-Compiler eine Option einbauen, dass man wählen kann,
ob beim KC85/4..5 die CAOS-Funktionen statt der Compiler-eigenen Routinen verwendet werden sollen.

Jens

Dieser Beitrag wurde am 21.04.2025 um 08:28 Uhr von jmueller editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

274
21.04.2025, 09:33 Uhr
HeikoS

Hallo Jens,

der Compiler ist einfach super ! Dein Vergleich zeigt auch, dass die Grafik-Routinen sehr gut implementiert sind, im Vergleich zu den im OS enthaltenen (wenn denn vorhanden, wie im Fall von CAOS).

Wenn ich schreibe:

„Die Grafik-Befehle des Compilers sind aber sicher nicht auf Geschwindigkeit getrimmt …“,

dann hatte ich extrem optimierte Routinen im Hinterkopf. Ich hatte mich ja mit „ELITE“ beschäftigt und dann gerät man unweigerlich in den Wahn, jedes einzelne Bit zu betrachten. Für den Ju-Te kann hatte ich mal einen einfachen Vergleich gemacht, bei dem nur der PIXEL-Befehl durch einen extrem optimieren Code ersetzt wurde, im Vergleich zum PIXEL-Befehl des ES4.0 :
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22549#250851

Der Preis dafür:

- Mehr Speicherbedarf durch große Lookup-Tabelle für VRAM-Adressen-Ermittlung.
- Nur eine Farbe, die gesetzt wird.

Wenn man den LINE-Befehl dann noch optimiert, wie hier für die Portierung der ELITE-3D-Engine:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22549#253064

dann ist der Preis:

- X- und Y-Koordinaten mit nur 8 Bit kodiert. (also nur 256 Pixel in X-Richtung)
- Immer wenn es geht: keine Schleifen und keine CALL-Befehle verwenden (Code wird länger).
- Im Fall vom Z8 möglichst alles in einem Registersatz unterbringen (PIXEL und LINE).

Mich hatte einfach mal interessiert, was ein Compiler auf einer 8-Bit-Maschine leisten kann. Die Matrix-Berechnungen sind sicher um den Faktor 10-20 schneller mit dem Compiler und INTEGER als Datentyp (habe ich nicht genau gemessen).

Man könnte natürlich auch noch den PIXEL-Set-Befehl optimieren pro System. Das bringt wahrscheinlich am meisten (ggf. nur eine Farbe als Option). Beim Zeichnen "über den Rand" hinaus, könnte man auch "Line Clipping" implementieren.

https://elite.bbcelite.com/deep_dives/line-clipping.html

Ich war sehr überrascht, wie ELITE das gelöst hat. Es ist trotzdem noch sehr schnell.

Viele Rest-Oster-Grüße, Heiko

Dieser Beitrag wurde am 21.04.2025 um 16:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

275
21.04.2025, 14:25 Uhr
kaiOr

@Heiko: Eine Drossel dabei ist das CLS vom CAOS (je nach Version mehr oder weniger). Das muss den Speicher nämlich sehr selektiv plätten können (innerhalb der festgelegten Fenstergröße) und nicht nur den Pixel- sondern auch noch den Farb-RAM (mit Wert von 0B7A3h) und den Video-RAM wo nochmal extra die ASCII-Zeichen abgelegt sind...
Wenn Du mit dem Vorschlaghammer auf den Pixel-RAM losgehst läuft das schon schneller.

Quellcode:


ASM "CLF:"
ASM " XOR A"           :REM Pattern
ASM " LD DE,0A800h"    :REM Endpunkt
ASM " LD C,0Ah"        :REM Durchlaeufe

ASM " DI"
ASM " LD HL,0"
ASM " ADD HL,SP"
ASM " EX DE,HL"
ASM " LD SP,HL"
ASM " LD L,A"
ASM " LD H,L"
ASM "NEXT: LD B,40h"   :REM 64 x 16Byte
ASM "LOOP: PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " DJNZ LOOP"
ASM " DEC C"
ASM " JP NZ,NEXT"
ASM " EX DE,HL"
ASM " LD SP,HL"
ASM " EI"
ASM " RET"

Zitat:

HeikoS schrieb
In der MP sind ja sogar Screen-Shots zu dem gesuchten Programm zum Thema "3D-Simulation - interaktiver Entwurf von räumlichen Modellen":

Kennt jemand von der KC-Gemeinde das Programm? Existiert es noch?

Nur Bruchstücke: 3D-Grafik.zip
Die Bedienung ist sehr komplex. Lauffähig erscheint mir nur die 3D-4.KCC per Autostart, außerdem müssen extra 16k- oder 64k stecken und zuvor mit SWITCH 8 C3 aktiviert werden.

Gruß,
Kai

Dieser Beitrag wurde am 21.04.2025 um 14:29 Uhr von kaiOr editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

276
21.04.2025, 16:40 Uhr
HeikoS

Hallo Kai,

ja, CLS ist auf jeden Fall ein "Bremser". Geht viel schneller mit Deiner Routine. Beim Vergleich Compiler/HC-Basic war es in beiden Fällen drin, kann man also "rauskürzen" ;-)

"3D-Simulation" ist also doch noch vorhanden, danke ! Peter hat immer so geschwärmt von dem Programm. Die Beschreibung liest sich auch sehr gut. Alles in Assembler geschrieben, verschiedene Projektionsarten, "Überflug" und "Durchgang" im 3D-Modell möglich, sehr viele Funktionen ...

Läuft im JKCEMU ... aber nun brauchen wir wahrscheinlich "Consulting" von Herrn Thierbach ;-) ... er ist ja noch aktiv. Intuitiv ist da natürlich nichts. Aber mit Anleitung, super ! Wer damit schon mal was gemacht hat, kann sich ja mal melden.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

277
21.04.2025, 16:48 Uhr
ralle

Dann muss dem Programmierer der JKC erklärt werden, weil ein Original wird er sich sicher nicht hinstellen.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

278
21.04.2025, 18:49 Uhr
jmueller

Hallo Heiko,

ich habe jetzt erst gesehen, dass ich dich in meinem Beitrag [273] Heike genannt habe.
So ein blöder Tippfehler aber auch. Entschuldigung bitte, war nicht Absicht.

Doch nun zum Thema:
Dass du deinen Aussage in Bezug auf super optimierten Assemblercode bezogen hast, ist mir schon klar.
Sieht man ja auch thematisch an deine vergangenen Beiträge.
Da nehme ich wirklich nichts krum.
Nur wollte ich mich deswegen zum Thema äußern, um ein paar Hintergrundinfos zu geben,
mit denen der nicht ganz so involvierte Leser die Performance-Aussagen besser einordnen kann.
Ein Compiler muss bei allem, was er an Quelltext so vorgeworfen bekommt,
immer korrekten Programmcode erzeugen.
Das hat logischerweise eine höhere Priorität als schnellstmöglicher Progrmmcode.
Die große Herausforderung ist, die Code-Erzeugung soweit zu optimieren,
dass sie in der breiten Anwendung möglichst guten performanten Code erzeugt,
aber bei allen Eventualitäten niemals soviel optimiert bzw. weglässt,
dass fehlerhafter Programmcode entsteht.

Der nächste Spagat ist die Abwägung zwischen Performance und Programmgröße.
Mit gewissen Redundanzen lässt sich schnellerer Programmcode erzeugen,
aber die wirklich limitierende Größe auf einem 8-Bit-System ist der Arbeitsspeicher.
Wenn man den Compiler-Anwender nicht mit tausenden Optimierungsoptionen zuschütten möchte
(wer Interesse hat, kann sich ja mal die ganzen Optimierungsoptionen beim GNU C Compiler anschauen),
muss man einfach einen guten Kompromiss zwischen all den Anforderungen finden.
Das war zumindest für mich beim JKCEMU BASIC-Compiler die Zielsetzung.

Jens

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

279
21.04.2025, 20:40 Uhr
BICa5105

@jmueller

Hallo Jens,

als Zielsystem kann man nicht den BIC auswählen. Warum nicht?

LG Cornelius
--
https://www.youtube.com/@robotronA5105

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

280
23.04.2025, 11:30 Uhr
HeikoS

Hier noch ein „letzter Würfel“ mit dem JKCEMU-Compiler. Mit allen Optimierungen, die hier noch „eingereicht“ wurden:

- Schnelles Bildschirmlöschen (KaiOr)
- Compilieren für „Produktiveinsatz“ (Jens)
- Zielsystem: KC85/4..5 mit Unterstützung beider Bildspeicher (Jens)
[vorher war eingestellt: „KC85/2..5, HC900“, obwohl ich den Screen-Befehl nicht nutze, geht es schneller, wie Jens auch schrieb !]
- Zoom-Faktor 3 (Heiko)

Geht schon ab wie „Schmidt’s Katze“ …

Quellcode:


10 CLS
30 CX = 160 : CY = 128          : REM CENTER SCREEN POS

35 ZO = 3                       : REM ZOOM FACTOR (INVERS)

40 DIM PTS(7,2)
50 DIM RZP(7,2) : DIM RYP(7,2)
60 DIM SNE (32) AS INTEGER      : REM SIN TABLE

70 GOSUB 5000                   : REM INIT CUBE
80 GOSUB 8000                   : REM INIT SIN TABLE
90 GOSUB 2000                   : REM INIT ARRAY, ROTATE POINTS
95 ASM " CALL INIT_SCREEN"

100 REM --- DRAW LOOP
110 FOR ANGEL=0 TO 15
120 ASM " CALL SWITCH_SCREEN"   : REM BUFFER SWITCH
130 ASM " CALL CLF"     
140 GOSUB 2000                  : REM ROTATE POINTS
150 GOSUB 6000                  : REM LINES
160 NEXT ANGEL
170 GOTO 100

2000 REM --- ROTATE POINTS
2001 CS = SNE(ANGEL+16)         : REM COS
2010 SN = SNE(ANGEL)            : REM SIN
2020 FOR N = 0 TO 7
2030 RZP(N,0) =   -CS * PTS(N,0)     + SN * PTS(N,1) 
2040 RZP(N,1) =    SN * PTS(N,0)     + CS * PTS(N,1)
2060 RYP(N,0) =  ( CS * RZP(N,0)/128 + SN * PTS(N,2)) / ZO + CX
2070 RYP(N,1) =  ( RZP(N,1))                          / ZO + CY
2120 NEXT N
2130 RETURN 

5000 REM --- THE CUBE
5001 PTS(0,0) = -1: PTS(0,1) = -1 : PTS(0,2) = -1
5010 PTS(1,0) =  1: PTS(1,1) = -1 : PTS(1,2) = -1
5020 PTS(2,0) =  1: PTS(2,1) =  1 : PTS(2,2) = -1
5030 PTS(3,0) = -1: PTS(3,1) =  1 : PTS(3,2) = -1
5040 PTS(4,0) = -1: PTS(4,1) = -1 : PTS(4,2) =  1
5050 PTS(5,0) =  1: PTS(5,1) = -1 : PTS(5,2) =  1
5060 PTS(6,0) =  1: PTS(6,1) =  1 : PTS(6,2) =  1
5070 PTS(7,0) = -1: PTS(7,1) =  1 : PTS(7,2) =  1
5080 RETURN 

6000 REM --- DRAW LINES
6010 LINE RYP(0,0),RYP(0,1),RYP(1,0),RYP(1,1)
6020 LINE RYP(1,0),RYP(1,1),RYP(2,0),RYP(2,1)
6030 LINE RYP(2,0),RYP(2,1),RYP(3,0),RYP(3,1)
6040 LINE RYP(3,0),RYP(3,1),RYP(0,0),RYP(0,1)
6050 LINE RYP(4,0),RYP(4,1),RYP(5,0),RYP(5,1)
6060 LINE RYP(5,0),RYP(5,1),RYP(6,0),RYP(6,1)
6070 LINE RYP(6,0),RYP(6,1),RYP(7,0),RYP(7,1)
6080 LINE RYP(7,0),RYP(7,1),RYP(4,0),RYP(4,1)
6090 LINE RYP(0,0),RYP(0,1),RYP(4,0),RYP(4,1)
6100 LINE RYP(1,0),RYP(1,1),RYP(5,0),RYP(5,1)
6110 LINE RYP(2,0),RYP(2,1),RYP(6,0),RYP(6,1)
6120 LINE RYP(3,0),RYP(3,1),RYP(7,0),RYP(7,1)
6130 RETURN 

8000 REM --- SIN TABLE
SNE(0)  = &H00
SNE(1)  = &H0D
SNE(2)  = &H19
SNE(3)  = &H25
SNE(4)  = &H31
SNE(5)  = &H3C
SNE(6)  = &H47
SNE(7)  = &H51
SNE(8)  = &H5B
SNE(9)  = &H63
SNE(10) = &H6A
SNE(11) = &H71
SNE(12) = &H76
SNE(13) = &H7A
SNE(14) = &H7E
SNE(15) = &H7F
SNE(16) = &H7F
SNE(17) = &H7F
SNE(18) = &H7E
SNE(19) = &H7A
SNE(20) = &H76
SNE(21) = &H71
SNE(22) = &H6A
SNE(23) = &H63
SNE(24) = &H5B
SNE(25) = &H51
SNE(26) = &H47
SNE(27) = &H3C
SNE(28) = &H31
SNE(29) = &H25
SNE(30) = &H19
SNE(31) = &H0D
RETURN

ASM "INIT_SCREEN:"
 ASM " LD A,(IX+1)"
 ASM " RES 0,A"
 ASM " SET 2,A"
 ASM " LD (IX+1),A"
 ASM " OUT (84H), A"
 ASM " RET"

ASM "SWITCH_SCREEN:"
 ASM " LD A,(IX+1)"
 ASM " XOR 00000101B
 ASM " LD (IX+1),A"
 ASM " OUT (84H), A"
 ASM " RET"


ASM "CLF:"
ASM " XOR A"           :REM Pattern
ASM " LD DE,0A800h"    :REM Endpunkt
ASM " LD C,0Ah"        :REM Durchlaeufe
ASM " DI"
ASM " LD HL,0"
ASM " ADD HL,SP"
ASM " EX DE,HL"
ASM " LD SP,HL"
ASM " LD L,A"
ASM " LD H,L"
ASM "NEXT: LD B,40h"   :REM 64 x 16Byte
ASM "LOOP: PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " PUSH HL"
ASM " DJNZ LOOP"
ASM " DEC C"
ASM " JP NZ,NEXT"
ASM " EX DE,HL"
ASM " LD SP,HL"
ASM " EI"
ASM " RET"

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

281
24.04.2025, 09:16 Uhr
P.S.

Das passt vielleicht nicht ganz hier her, weil es nicht nur die KC-Welt betrifft, aber Mario Blunk hat ein Buch geschrieben über die Grundlagen der CAD-Programmierung -> http://www.blunk-electronic.de/.
Der Anlaß war gegeben, um ein - wie er schreibt "... vollständiges Verständnis über die Mechanismen zu erlagen, die für die Programmierung einer Zeichenfläche nötig sind".
Das Buch ist auch über Booklooker erhältlich -> https://www.booklooker.de/B%C3%BCcher/Mario-Blunk+Grundlagen-zur-Programmierung-einer-Zeichenfl%C3%A4che-f%C3%BCr-ein-CAD-System-Koordinatensysteme/id/A02ITEr501ZZe.

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß gar nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

282
Heute, 08:33 Uhr
P.S.

Zu <271> muss ich was berichtigen:
(Zitat) "... - Uwe Zierott, der hatte in Frankfurt/O. einen Elektronik-Computerladen (!) ..." entspricht nicht den Tatsachen.
Ich hatte Uwe Zierott und auch Dr. Scheuchner angemailt - und von Uwe kam u.a. dazu eine aufklärende Antwort:
Der Elektronik- und Computer-Bastlerladen in Frankfurt(Oder) wurde vom einem Herrn Bähr betrieben, U.Z. hatte damit nichts zu tun.
Er hat mir aber einen aufschlußreichen Text mitgeschickt bzgl. eines Youtube-Podcast "Heimcomputer in der DDR“ von Henner Thomsen und Christian Schmidt.
Von Dr. Scheuchner habe ich noch keine Antwort.

HeikoS wollte sich mit Andreas Thierbach in Verbindung setzen - Ergebnis (noch) unbekannt.

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß gar nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Dieser Beitrag wurde am 25.04.2025 um 08:34 Uhr von P.S. editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]