Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
FutureOS / Re: Applikation: '- FutureTex'
« Letzter Beitrag von TFM am Heute um 15:54:23 »
Welche Datei Typen wurdet ihr gerne verwenden? Was würdet ihr Euch hier wünschen?

2
Programmierung / Re: Hacking Bruce Lee
« Letzter Beitrag von Fessor am 05. Dezember 2019, 00:41:51 »
Nachdem ich halbwegs rausgefunden hab, wie man Dialoge aufrufen und Return-Werte bekommt funktioniert nun rudimentär ein INK-Selector, wenn man mit rechter Maustaste im Hauptfenster auf einen der PENs klickt.
Ich habe die Hoffnung noch nicht aufgegeben, die Grafiken als Indexed-Images hinzubekommen um wie beim CPC einfach auch nur die INK zu setzen. Mit den ganzen Arrays und Tabellen und der Neuerstellung der Grafiken aufgrund anderer Farbwerte ist die Performance des Viewers doch arg in den Keller gegangen. Da gibts also noch reichlich was zu optimieren; aber das ganze ist eh noch in der Konzeptphase und ein mehr oder weniger heftiges Neuschreiben der Routinen ist eh eingeplant.
1st: Make it Run. 2nd: Make it Fast. 3rd. Make it Nice.

Mit dem Programmcode hab ich mich auch mal wieder beschäftigt und rückwärts durch einige schon identifizierte Routinen getraced um weitere Routinen belabeln zu können.
Von den vier Eventroutinen ist dabei das Funktionsprinzip von dreien identifiziert.

Das erste Event wird beim Betreten eines Raums gefeuert und dient der Initialisierung einiger Raumabhängiger Variablen.
Das zweite Event wird im Interrupt des Gameloops aufgerufen und dient der Platzierung/Animation der "Missiles"
Drittes Event: Unbekannt
Das vierte Event wird nach dem Einsammeln einer Lampe aufgerufen und hier wird dann Raumabhängig die Abarbeitung der Einträge der Overlaytabelle gesteuert.
Anhand der Raumnummer und der x und y-Koordinate wird der entsprechende Tabelleneintrag ausfindig gemacht und das Tile aus der Karte entfernt oder eingesetzt.
Sprich: Steuerung der Hindernisse.

Die Sprites: Für jedes der drei Sprites existiert ein Offscreen-Buffer von 384 Bytes (4*3 Tiles => 8 * 48 Bytes) in dem sich die Action eigentlich abspielt. Hier wird eine Blase der Umwelt gezeichnet und das Sprite hineinplaziert und dann die Blase in den Bildspeicher kopiert. Keine Ahnung warum. Eventuell hätten Sie es nicht anders hinbekommen die Sprites flackerfrei auf den Schirm zu bekommen. Das Blitten so einer "Blase" auf den Screen sieht jedenfalls einigermaßen Effizient aus, da sie nicht viel Adressen zu kalkulieren haben. (Die Routine geht von 0x685e bis 0x68a1)

0x5c93: Szene vom Ninja,
0x5e7a: Szene von Yamo
0x6065: Szene von Bruce
Hinter den Offscreenbuffern sind jeweils 15 Bytes für Verwaltungsinformationen abgelegt, die noch größtenteils unidentifiziert sind.
Hierauf folgen dann (Interleaved) Pointer auf die Grafikdaten der Einzelsprites/Animationsphase der Sprites und (zugehörige?) Adresse auf eine Programmroutine.
Da diese Datentabelle größer ist als die Anzahl der Einzelsprites scheint das in Animationsphasen unterteilt zu sein, die sich ja aus mehreren Sprites zusammensetzen; aber das ist erstmal eine Arbeitshypothese.

Das ganze ist mal wieder eine Sammlung von Springteufeln. Hat man was entdeckt, taucht was frisches unbekanntes auf...

3
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von LambdaMikel am 04. Dezember 2019, 19:36:04 »
Wie schon Dagobert Duck sagte - wer das Bit nicht ehrt, ist des Bytes nicht wert!  :zunge0020: :smiley027:
Mehr wie acht Bit geht aber nicht, dann bin ich total besoffen.  :irre:

Nach acht Bit geht nur noch am Erdinger NIBBLen  :irre: :binkybaby: Oder Paulaner geht auch. 
Unsere Freunde aus der Freistaatlichen Weisswurst-Szene werden Dir das gerne bestaetigen.  :irre:

Schoen, dass die idiotomatische Z80-Programmierung zu solch vergeistigten Gedanken fuehrt :jubelaola:
4
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von TFM am 04. Dezember 2019, 19:27:45 »
Wie schon Dagobert Duck sagte - wer das Bit nicht ehrt, ist des Bytes nicht wert!  :zunge0020: :smiley027:
Mehr wie acht Bit geht aber nicht, dann bin ich total besoffen.  :irre:
Dafür gibt's den zweiten Register-Satz. Einfach ein EX AF,AF' und Du kannst nochmal 8 Bit nachschenken. Genaugenommen sogar Neun! Ja, die das Carry, kann auch ein's vertragen  ;)
5
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von oobdoo am 04. Dezember 2019, 18:31:57 »
Wie schon Dagobert Duck sagte - wer das Bit nicht ehrt, ist des Bytes nicht wert!  :zunge0020: :smiley027:
Mehr wie acht Bit geht aber nicht, dann bin ich total besoffen.  :irre:
6
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von LambdaMikel am 04. Dezember 2019, 15:57:21 »
or a würde gegenüber and a ein Byte im Quelltext sparen. Und einen Tastenanschlag.
Wie das? Die brauchen beide ein Byte. So weit ich mich erinnere sind das &B7 bzw. &A7.
Die Opcodes sind gleich lang; aber ein Byte im Assemblerlisting sparen zu können, was man damit alles machen kann: Schöner Dokumentieren, ein Label verständlicher benennen - vlelleicht fehlt dem Editor noch ein Byte RAM um ein unendlich cooles Feature zu vollenden! Unendliche Möglichkeiten tun sich da auf!

Wie schon Dagobert Duck sagte - wer das Bit nicht ehrt, ist des Bytes nicht wert!  :zunge0020: :smiley027:
7
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von TFM am 04. Dezember 2019, 10:08:19 »
Ja, stimmt. Du hast ja vom Quelltext geschrieben. So lassen sich leicht 0,00003% einsparen.  :flehan:
8
Programmierung / Re: Z80 Programming "Idioms"
« Letzter Beitrag von almasys am 03. Dezember 2019, 20:36:06 »
or a würde gegenüber and a ein Byte im Quelltext sparen. Und einen Tastenanschlag.
Wie das? Die brauchen beide ein Byte. So weit ich mich erinnere sind das &B7 bzw. &A7.
Die Opcodes sind gleich lang; aber ein Byte im Assemblerlisting sparen zu können, was man damit alles machen kann: Schöner Dokumentieren, ein Label verständlicher benennen - vlelleicht fehlt dem Editor noch ein Byte RAM um ein unendlich cooles Feature zu vollenden! Unendliche Möglichkeiten tun sich da auf!
9
Hardware / Re: Akku für Inicron ROM-RAM-Box und RAM-Box
« Letzter Beitrag von almasys am 03. Dezember 2019, 20:32:56 »
In der Stückliste steht Einlötakku 2,4-3,6 V, das sollte passen. Aber wenn ich die über längere Zeit laufen lasse will ich erst mal dabei sein.

Ja, der Schalter hat einen Macken. zu schwergängig und ich muss seitlich wackeln bis das grüne Lämpchen reagiert.
10
Hardware / Re: Akku für Inicron ROM-RAM-Box und RAM-Box
« Letzter Beitrag von TFM am 03. Dezember 2019, 20:12:24 »
Bist Du sicher, dass es der Kippschalter ist? Oder liegt es daran, dass Du 3 V anstatt 5 V benutzt. Bin mir fast sicher dass die RRB nicht 3 V tolerant ist. Was sagen die Hardware Maxe dazu?
Seiten: [1] 2 3 ... 10