Robotrontechnik-Forum

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

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Mehrfarbige Sprites für den JuTe-6K » Themenansicht

Autor

Thread - Seiten: -1-

000
02.02.2024, 19:52 Uhr
HeikoS

Liebe JuTe-Freunde,

in den grauen Wintertagen hat mich der JuTe-6K nicht losgelassen. Mein Gespann aus JuTe-2K und der Grafikerweiterung für den 6K funktioniert ja schon eine Weile.

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

Die Hardware hat mich schon immer fasziniert, 16 Farben/Pixel bei 320 x 192 ist schon eine tolle Sache. Auch die zweite CPU für den Bildaufbau ist eine schöne Lösung. Leider wurde 1990 dann alles hinfällig … viel Software gab es ja nicht. Jetzt ist ja schon Einiges dazu gekommen, was ich auch alles ausprobiert habe. Dank an die fleißigen Programmierer !

Also gleich mal angefangen, die ES4.0-Funktionen zu erkunden. Da gibt es ja auch schon viele Grafikfunktionen … sogar Sprites (Player), nur einfarbig, aber eine tolle Sache. Aber die Hardware kann eindeutig mehr … und so habe ich immer mal mit ein paar Assembler-Routinen versucht, Sprites mit 16 Farben/Pixel über den Bildschirm „wuseln“ zu lassen. Da ist dann mit der Zeit immer mehr zusammengekommen. Ich habe nun mal den ganzen „Spagetti“-Code zu einer Bibliothek zusammengepackt.

Hier ein Video, wie es auf meinem JuTe läuft (abgefilmt vom TFT-Monitor):

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

Hier sind die Dateien und eine kleine Doku zu finden:

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

Bisher ist das nur bei mir und bei Wolfgang (wolle1945) getestet. Bei Wolfgang sind die Farben vertauscht (die Hardware wurde ja später noch korrigiert, bei ihm aber dafür das ES4.0 angepasst). Ich würde mich freuen, wenn das viele JuTe-6K-Besitzer mal testen. Eine Version mit „vertauschten Farben“ könnte ich ja auch noch erstellen, wenn Interesse bestehen sollte.

Viel Spaß beim Testen !
Heiko

Dieser Beitrag wurde am 03.02.2024 um 12:43 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
02.02.2024, 20:36 Uhr
volkerp
Default Group and Edit

Tolle Arbeit!
--
VolkerP

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
03.02.2024, 07:23 Uhr
PC-Opa

Wird heute noch getestet...

--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
03.02.2024, 11:26 Uhr
HeikoS

Super, da bin ich schon gespannt ...

Bei Wolfgang(wolle1945) sieht es so aus ... sonst läuft es.

Viele Grüße !

Dieser Beitrag wurde am 03.02.2024 um 12:42 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
03.02.2024, 14:35 Uhr
jute-tom

Coole Sache! Ich freue mich über jeden, der sich mit dem JU+TE-Computer auseinandersetzt und sein Wissen z.B. über GitHub teilt.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
03.02.2024, 14:39 Uhr
Perser

Avatar von Perser

ich weis garnicht was ich sagen soll, ich finde das super, eine super Arbeit.

Viele Grüße
Perser

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
03.02.2024, 19:35 Uhr
HeikoS

Vielen Dank für die lobenden Worte ... das freut mich ! Vielleicht hat ja auch jemand Lust bekommen, damit ein paar neue Programme zu schreiben. Bestimmt sind auch noch ein paar Fehlerchen drin, die man im "eigenen Saft" meist nicht findet. Dann schreibt mir einfach.

Viele Grüße,
Heiko

Dieser Beitrag wurde am 03.02.2024 um 19:35 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
03.02.2024, 20:06 Uhr
PC-Opa

Hallo Heiko,
funktioniert wie beschrieben...

--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
03.02.2024, 20:41 Uhr
HeikoS

Hallo Wolfgang, liebe JuTe-Freunde,

super, danke für den Test ! Das Bild sieht sehr gut aus bei Dir.

Dazu habe ich mal eine Frage. Bei mir sind die Farbabstufungen z.B. zwischen hellem und dunklem Grün sehr schach, bei Rot aber zu stark.

Hast Du die Widerstände 160/220 Ohm am Scart-Ausgang angepasst oder ist alles nach der Originalschaltung von 1990 aufgebaut?

Ausserdem bin ich mit dem Bild, welches dieser SCART zu VGA/HDMI-Konverter erzeugt am JuTe 6K nicht zufrieden:

https://www.conrad.de/de/p/speaka-professional-av-konverter-sp-hd-sc-01-scart-hdmi-klinke-cinch-digital-1920-x-1080-pixel-989271.html

Welche Monitore oder Konverter benutzt ihr für den JuTe 6K ?

Da wäre ich für Erfahrungen und Tips von Euch dankbar.

Viele Grüße,
Heiko

Dieser Beitrag wurde am 03.02.2024 um 20:43 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
03.02.2024, 21:27 Uhr
PC-Opa

Hallo Heiko,

die Scart-Beschaltung habe ich nach der Vorlage gemacht, nur der R für die Schaltspannung stimmt nicht ganz (1,5k -> richtig ist aber 100 R). Der Rest ist richtig.

der R an Rot ist 150R!

Damit habe ich ein gutes Bild auf dem LED-TV. (siehe Foto)

Mit dem gleichen Wandler Scart zu VGA/HDMI habe ich ein leicht verschwommenes Bild mit leichtem Grünstich...
--
Gruß Wolfgang

Dieser Beitrag wurde am 03.02.2024 um 21:38 Uhr von PC-Opa editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
03.02.2024, 23:04 Uhr
Crawler

Wow Sprites auf dem Ju+Te Computer!

Aus dem README entnehme ich, daß es sich genauer gesagt um Software-Sprites (sog. "Shapes") handelt.

Hast du dir die Technik mit dem Pre-Shift für die Bit-Positionen selbst ausgedacht oder war die schon in den ES4.0-Funktionen vorhanden?
Ich nehme an, die Farbgrafik wird am Bildschirm mittels 4 Bit-Ebenen dargestellt?

Du unterscheidest im README bei der Darstellung von Pixeln je nach Belegung der "M"-Bits in der Sprite-Definition zwischen Farbe und Maske.

Quellcode:


Bit:       | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 
           |---|---|---|---|---|---|---|---|
Funktion:  | M | M | M | M | R | G | B | H |

Ich sehe das jedoch eher als Kombination von Farbe und Transparenz. Für mich sieht das sogar so aus, als hätte man hier bereits 16 Transparenz-Stufen vorgesehen. Allerdings wird das von der Hardware wahrscheinlich (noch?) nicht unterstützt. Derzeit sind die Pixel also entweder farbig oder transparent.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
03.02.2024, 23:42 Uhr
HeikoS

Hi Crawler,

der Code ist komplette Eigenentwicklung. Pre-Shift wird im ES4.0 nicht verwendet für die einfarbigen Sprites. Das wird dort immer zur Laufzeit berechnet, was Zeit kostet aber damals natürlich berechtigt war, da eher wenig RAM in den JuTe's vorhanden war.

Kannst ja mal in die Hardware-Beschreibungen schauen, ich nehme an du kennst den JuTe nicht so genau. Es gibt 4 Farbebenen, je 8K für R,G,B,H, eingeblendet in einen 8K-Slot im RAM (4000-5FFF) der Host-CPU.

Maske und Pixel-Farbe sind in einem Byte, damit ich das nicht getrennt ablegen muss. Die INIT-Routine testet beim Erstellen der pre-shifted MAPS einfach, ob min. 1 Bit des High-Nibbles 1 ist. Dann ist das ein Mask-Bit. Wenn das High-Nibble 0 ist, dann sind die unteren 4 Bits der Farbcode für die 16 Farben des Bits.

Man kann also mit dem High-Nibble keine Transparenz einstellen - kann der JuTe einfach nicht und war auch nie vorgesehen ... aber wer weiß, die Experten hier würden das bestimmt hinkriegen ;-) ...

Grüße, Heiko

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
04.02.2024, 09:20 Uhr
HeikoS

Hallo Wolfgang,

vielen Dank für die Infos. Ich werde mir die Widerstände nochmal anschauen. Vielleicht habe ich auch was falsch gemacht.

Du hast ja auch schon wieder was programmiert für den JuTe... kann man das schon laden und ausprobieren ?

Viele Grüße,
Heiko

Zitat:

PC-Opa schrieb
Hallo Heiko,

die Scart-Beschaltung habe ich nach der Vorlage gemacht, nur der R für die Schaltspannung stimmt nicht ganz (1,5k -> richtig ist aber 100 R). Der Rest ist richtig.

der R an Rot ist 150R!

Damit habe ich ein gutes Bild auf dem LED-TV. (siehe Foto)

Mit dem gleichen Wandler Scart zu VGA/HDMI habe ich ein leicht verschwommenes Bild mit leichtem Grünstich...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
04.02.2024, 10:19 Uhr
PC-Opa

Zitat:

HeikoS schrieb
Hallo Wolfgang,

Du hast ja auch schon wieder was programmiert für den JuTe... kann man das schon laden und ausprobieren ?

Viele Grüße,
Heiko

Zitat:

PC-Opa schrieb

Auf meiner HP ist alles als BIN- und WAV-Datei zum Download bereit (siehe Software). Ist halt nur in MP-Basic geschrieben. Einige Programme benötigen das ES4.0a und die ROM-Bank von V. Pohlers oder Rolf weidlich.

--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
04.02.2024, 10:20 Uhr
Perser

Avatar von Perser

habe ebenfalls einen Test gemacht und der sieht so aus

Viele Grüße
Perser

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
04.02.2024, 10:42 Uhr
HeikoS

AH, ok - Danke !

Zitat:

PC-Opa schrieb

Zitat:

HeikoS schrieb
Hallo Wolfgang,

Du hast ja auch schon wieder was programmiert für den JuTe... kann man das schon laden und ausprobieren ?

Viele Grüße,
Heiko

Zitat:

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
04.02.2024, 10:47 Uhr
HeikoS

Cool ... das sieht doch sehr gut aus. Funktioniert es auch flickerfrei auf Deinem JuTe ?

Was mir auch sofort auffällt, sind die Farben. Die sind genau wie bei mir nicht so richtig abgestuft - z.B. bei Grün. Sieht exakt wie bei mir aus. Dann muss das doch irgendwie mit dem Monitor oder den Konvertern zu tun haben. Das Bild von Wolfgang sieht aus wie aus dem Bilderbuch ... als wenn ein exakter Farb/Weißabgleich gemacht wurde ...

Viele Grüße !

Zitat:

Perser schrieb
habe ebenfalls einen Test gemacht und der sieht so aus

Viele Grüße
Perser

Dieser Beitrag wurde am 04.02.2024 um 10:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
04.02.2024, 10:55 Uhr
PC-Opa

@Heiko:
Mit dem SCART zu VGA/HDMI-Konverter habe ich auch mal meine CPC6128/464 getestet. Auch hier ist die gelbe Schrift mit einem leichten Grünstich. Das liegt dann wohl am Konverter.
--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
04.02.2024, 11:11 Uhr
Perser

Avatar von Perser

so wie es aussieht liegt das nicht am Tiny
sondern eher am Bild, original auf dem
Display sehen die Farben ganz gut aus.

Viele Grüße
Perser

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
04.02.2024, 11:28 Uhr
HeikoS

Hab ich gleich mal geladen ... :-)

Zitat:

Auf meiner HP ist alles als BIN- und WAV-Datei zum Download bereit (siehe Software). Ist halt nur in MP-Basic geschrieben. Einige Programme benötigen das ES4.0a und die ROM-Bank von V. Pohlers oder Rolf weidlich.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
04.02.2024, 15:10 Uhr
PC-Opa

Zitat:

HeikoS schrieb
Hab ich gleich mal geladen ... :-)

Zitat:

...sind halt nur kleine einfache BASIC-Programme.
Der Befehlsvorrat des MP-Basic ist sehr begrenzt und ich muß da immer viel improvisieren. Bei 6k Programmlänge ist auch nicht viel Platz.

Ich kann leider nicht in Assembler programmieren, nur ein bisschen BASIC. Aber kleine Assembler-Routinen (z.B. von Rolf) zur Darstellung von Kreisen sind da schon sehr nützlich.
Neue Routinen sollten im BASIC-Programm enthalten sein, um nicht mehrere Programme starten zu müssen.
--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
04.02.2024, 17:27 Uhr
Perser

Avatar von Perser

Zitat:

HeikoS schrieb
Funktioniert es auch flickerfrei auf Deinem JuTe ?

absolut flackerfrei und sehr flüssig, bin erstaunt.

Viele Grüße
Perser

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
04.02.2024, 18:10 Uhr
Crawler

@Heiko: Den Ju+Te kenne ich tatsächlich noch nicht so genau. Vielen Dank für die Erläuterung!

Respekt!

Dieser Beitrag wurde am 04.02.2024 um 18:13 Uhr von Crawler editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
04.02.2024, 20:41 Uhr
HeikoS

Danke für den Test und die Rückmeldung ! Dann scheint die FCSL ja schon mal recht stabil zu sein

Fehler und Schwachstellen findet man ja nur, wenn viele mitmachen.

Grüße,
Heiko

Zitat:

absolut flackerfrei und sehr flüssig, bin erstaunt.

Viele Grüße
Perser

Dieser Beitrag wurde am 04.02.2024 um 20:44 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
04.02.2024, 22:04 Uhr
HeikoS

Hallo Wolfgang,

deine BASIC-Programme sind super und es steckt viel Herzblut drin, das merkt man sofort, wenn man deine Seite anschaut. Das macht richtig Spaß ! Auch durch deine Bilder von den JuTe-Aufbauen und deinem Aufruf, neue Software zu schreiben, bin ich inspiriert worden ...

Neue Routinen müssten ja nicht unbedingt nur im Basic stecken. Wenn man die ROM-Bank nutzt, kann man ja sehr schnell eine Erweiterung laden. Man könnte im Basic-Programm auch eine kleine Abfrage einbauen die prüft, ob die Erweiterung geladen ist oder die Erweiterung sogar über einen Aufruf in der ROM-Bank vom Basic-Programm automatisch laden. Man könnte ja Rolf/Volker mal fragen, ob sie das noch einbauen würden (oder geht das sogar schon ... ?, kann ich jetzt nicht sagen).

Aber das ist letztlich ja auch die Frage, ob man selbst immer sehr nahm am Original bleiben möchte, eher auf Erweiterungen und Neuerungen setzt bis hin zum Herauskitzlen der letzten Bits (Demo-Szene). Das CAOS vom KC ist ja auch super weiterentwicket worden.

Mit den Sprite-Funktionen der FCSL kann man übrigens auch mit wenigen Befehlen einfache Texturen mit 16-Farben/Pixel schreiben (SET_SPRITE). Hab mal schnell eine Mauer gebaut

Viele Grüße,
Heiko

Quellcode:


2 BREM 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,15
BREM   1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,15
BREM   1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,15
BREM   15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15
BREM   8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,15
BREM   8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,15
BREM   8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,15
BREM   15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   8,8,8,8,8,8,8,8,15,8,8,8,8,8,8,8
BREM   15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15

10 PROC SETEB[%F7A0,13]; PROC PTC[12];

25 LET W=%E000+3; REM Sprite-Daten
30 LET X=64;      REM X-Koordinate 
40 LET Y=64;      REM Y-Koordinate
50 LET Z=0;       REM Slot
60 CALL %8300;    REM INIT_SPRITE 

80 CALL %8303;    REM SET_SPRITE 
90 LET X=X+16;    
100 IF X<((12*16)+64) GOTO 80
105 LET X=64, Y=Y+16
110 IF Y<((5*16)+89) GOTO 80

Zitat:

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
04.02.2024, 22:24 Uhr
PC-Opa

Ja, da steckt sehr viel Herzblut drin.
Ich habe immer einen JU+TE 6k Computer gewollt, der Weg dazu war sehr schwer. ......
Die Software dazu habe ich mir selbst programmiert. Schritt für Schritt sind mir dann die Programme "eingefallen". Ich finde meine Programme für das 6k-System recht brauchbar. Die sollten ja auch als Anregung für neue Programme dienen.
--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
05.02.2024, 11:21 Uhr
HeikoS

Vielen Dank ... hätte nicht gedacht, dass es bis zu den "Wahnsinnigen" (Sorry

) der Demo-Szene vorgedrungen ist.

Viele Grüße,
Heiko

Zitat:

Crawler schrieb
@Heiko: Den Ju+Te kenne ich tatsächlich noch nicht so genau. Vielen Dank für die Erläuterung!

Respekt!

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
09.02.2024, 14:25 Uhr
HeikoS

Liebe JuTe-Freunde,

noch einmal vielen Dank an die Tester der (Software ! )-Sprite-Bibliothek (FCSL) und für das positive Feedback.

Wer das „Tiny-MP-Basic-Beispiel“ auch getestet hat, wird es bemerkt haben. Das war noch nicht ganz fertig, d.h. es war nicht identisch mit dem „Assembler-Beispiel“, aber die Smiley‘s sind auch schon ordentlich „abgegangen“

.

Es gibt nun ein zweites Basic-Beispiel. Es ist jetzt identisch zur Assembler-Version und nutzt die Basic-Erweiterung von Volker. „RESTORE“ und „READ“ sind sehr nützlich. Die Basic-Erweiterung macht richtig Spaß ! Damit man nicht zwei Erweiterungen laden muss, habe ich die Basic-Erweiterung und die FCSL in ein Binary gepackt.

Ihr könnt das hier anschauen und testen:

https://github.com/haykonus/JU-TE-6K-Sprites/tree/main#mit-basic-erweiterung

Zu den BREM-Pseudo-Anweisungen im JTCEMU habe ich eine Frage:

In der Doku des JTCEMU steht:

„Der Wert 13 bzw. %0D gefolgt von einem Byte mit gesetztem Bit 7 ist ebenfalls nicht möglich, da das eine neue BASIC-Zeile bedeutet.“

Ich konnte den Wert 13 überhaupt nicht in den BREM-Zeilen ablegen, auch wenn kein Byte mit Bit7 gesetzt folgte. Also, es geht im JTCEMU nicht und aus diesem erzeuge ich immer die WAV-Files für den JuTe. Ist das bekannt? Mache ich etwas falsch? Wer genau hinsieht beim neuen Basic-Beispiel, es fehlt in dem farbigen Quadrat, welches am Anfang über den Bildschirm läuft, diese Farbe:

Ich habe für den Wert 13 einfach den Wert 12 noch einmal verwendet in der Sprite-Definition ...

Viele Grüße und wer will, Spaß beim Testen !
Heiko

Dieser Beitrag wurde am 09.02.2024 um 21:32 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
09.02.2024, 14:59 Uhr
HeikoS

@Volker , @Crawler

Da ich jetzt auf Volkers-Seite auch diesen Auszug aus der Doku als „Detail“ unter ES4.0 gefunden habe, möchte noch einmal kurz darauf hinweisen, dass es sich dabei um eine rein willkürlich gewählte, aber zu Akusprite passende, Darstellung der Software-Sprite-Pixel in der FCSL handelt. Es hat nichts mit der Hardware des JuTe 6K oder dem ES4.0 zu tun.

Quellcode:


           +-------------------------------+
Bit:       | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 
           |---|---|---|---|---|---|---|---|
Funktion:  | M | M | M | M | R | G | B | H |
           +-------------------------------+

M = Maske
R = Rot, R = Grün, B = Blau, H = Hell

Es ist kein komfortables Register, in das man die Farbe „rein-poken“ kann, da muss man beim JuTe 6K mehr tun: pro Pixel 4 x die Farbbank umschalten und jeweils die bestehenden Bits, die man nicht ändern will, im VRAM-Byte erhalten.

Vielleicht habt ihr das auch gar nicht so aufgefasst, aber es ist evtl. schlecht dargestellt auf der GitHub-Seite.

Viele Grüße,
Heiko

Dieser Beitrag wurde am 09.02.2024 um 15:02 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
10.02.2024, 18:04 Uhr
Crawler

@Heiko: Hatte das nach deiner Erläuterung in 011 schon richtig verstanden, daß die Grafikdaten in der Hardware anders abgebildet werden. Im README gibt es auch eine Stelle, wo das dann klar wird.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

030
11.02.2024, 09:16 Uhr
jute-tom

Heiko, was nutzt du für einen Assembler? https://github.com/haykonus/JU-TE-6K-Sprites/blob/main/FCSL/FCSL.asm enthält mir einige unbekannte Dinge wie Makros oder Structs.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

031
11.02.2024, 10:10 Uhr
HeikoS

Hallo Thomas, ich benutze den Arnold-Assembler. Das steht auch ganz oben im README. Den habe ich auch hier im Forum erst kennengelernt.

Viele Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
13.02.2024, 13:30 Uhr
HeikoS

Man kann mit der FCSL auch Sprites größer als 16x16 Pixel darstellen. Beim „Zusammenkehren“ der Test-Routinen zur FCSL-Bibliothek, habe ich alle numerischen Konstanten aufgelöst und durch Symbole ersetzt.

Deshalb kann man in FCSL.asm die X/Y-Auflösung an nur einer Stelle anpassen, man muss jedoch zusätzlich die Code-Basis auf „BIG“ setzen, da dann die Optimierungen durch „align 100h“ nicht mehr möglich sind (Datenstrukturen der MAPs z.B. werden > 256).

Quellcode:


;------------------------------------------------------------------------------    
; Einstellung der Parameter
;------------------------------------------------------------------------------
SP_SIZE       equ    BIG       ; notwendig für Sprites > 3x16

;------------------------------------------------------------------------------
; Sprite-Definition
;------------------------------------------------------------------------------
                    
SP_X_BYTES    equ    4         ; 4 Bytes      -> X = 24 Pixel + 8 Shift-Bits
SP_Y_LINES    equ    32        ; 32 Zeilen    -> Y = 32 Zeilen

Damit ist dann zwar kein vollständiges MOVE von Sprites dieser Größe in der Austastlücke mehr möglich, aber man kann sie immer noch bewegen (mit einigen Störungen durch konkurrierende Zugriffe der Host- und Video-CPU auf den Video-RAM) und man kann prima größere Objekte platzieren und mit größeren Schrittweiten auch „wandern“ lassen.

Das habe ich mal mit diesem „ollen“ König versucht. Da ich grafisch keine „Ader“ habe, ist der aus dem Internet und Akusprite hat versucht, ihn auf die JuTe-Farbpalette zu skalieren (habe noch ein wenig manuell korrigiert).

Hier das Ergebnis:

Ist noch im Teststadium – also noch nicht auf dem GitHUB … ich überlege, in der nächsten Version eine Routine zum Bewegen von „BIG“-Sprites einzubauen, die dann aber nicht den Hintergrund rettet, sondern mit der die Sprites auf einfarbigen Hintergründen schnell „wandern“ können. Oder man baut noch eine Option für die Anzahl der Farben ein (2,4,8,16) … dann könnte man die enorm beschleunigen oder parallel viel mehr Sprites bewegen ohne Geflacker … Was meint Ihr?

Viele Grüße,
Heiko

Dieser Beitrag wurde am 13.02.2024 um 16:33 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

033
13.02.2024, 14:51 Uhr
PC-Opa

@Heiko:
Da wird es nicht mehr lange dauern und dein erstes Game ist fertig.

--
Gruß Wolfgang

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

034
13.02.2024, 15:07 Uhr
Perser

Avatar von Perser

@Heiko
ich finde das super was du da zusammen baust,
meine Bedenken wären aber, passt das, wenn es
zu einem Spiel ausartet auch in den Speicher, ich hatte damals bei meinen Programmierversuchen einige Probleme das in den
Speicher zu bekommen.

Viele Grüße
Perser

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

035
13.02.2024, 15:45 Uhr
HeikoS

@Perser
Das ist tatsächlich ein Problem. 32K sind ja nicht viel. Für die Sprites, wenn sie sich bewegen sollen und viele Farben haben sollen, braucht man auch viel RAM. Aber der RAM könnte reichen, wenn man noch die ROM-Bank mit einbindet und etwas bei Bedarf nachladen könnte ... das müsste eigentlich gehen ...

@Wolfgang
Wenn ich alle "Werkzeuge" fertig habe, fehlt mir am Ende dann bestimmt die Idee ;-)

Viele Grüße,
Heiko

Dieser Beitrag wurde am 13.02.2024 um 15:46 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

036
11.03.2024, 22:07 Uhr
HeikoS

Liebe JuTe- und JTCEMU-Freunde,

die hier im Thread vorgestellte Sprite-Bibliothek FCSL nutzt ja spezielle Eigenschaften der Hardware des JuTe-6K, um eine synchrone und flickerfreie Darstellung der Animation zu erreichen sowie die Störungen bei Zugriff der Host-CPU auf den Video-RAM zu unterdrücken.

Es wird das BUSY-Signal genutzt, um alle Berechnungen (VRAM-Adress-Tabelle anlegen etc.) in der Zeit zu erledigen, wenn der "Elektronenstrahl" das Bild schreibt und alle Zugriffe auf den Video-RAM, wenn das Bildsignal "ausgetastet" ist.

Der JTCEMU hat das BUSY-Signal bisher nicht ausgewertet. Daher laufen alle Programme, die den Video-RAM intensiv nutzen, dort generell schneller und die Tricks der FCSL zur "flüssigen Darstellung" konnten dort nicht funktionieren.

Entwicklung und Tests sind aber am JTCEMU sehr angenehm und komfortabel zu machen ... ich habe daher einfach bei Jens Müller angefragt, ob er das BUSY-Signal an Port 3.2 der Host-CPU nachbilden und das dann mit dem Refresh des Emulator-Screens synchronisieren kann.

Hier ist das Ergebnis:

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

Jens hat es realisiert und er wird es in der nächsten Version des JTCEMU veröfftlichen. Ich darf es hier schon mal ankündigen - Super, vielen Dank an Jens dafür !

Damit laufen dann auch alle anderen JuTe-6K-Programme noch originalgetreuer auf dem JTCEMU.

Viele Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]