Ja, hatte mich zugegeben schon etwas gewundert, wieso so lange nichts kam.zatzen hat geschrieben:Irgendwie ist die Benachrichtung in meinen emails nicht richtig angekommen, deswegen
komme ich erst jetzt zufällig in den Thread.
Ich kriege vom DOSforum irgendwie gar keine eMails. (Beim Coding-Board geht's.) Ich frage mich, was ich falsch mache. Egal. Ich gucke sowieso täglich ins DOSforum (außer wenn ich nicht da bin, wie z.B. kommendes Wochenende).
Ja, aber an der entsprechenden Stelle ging's mir ja genau darum, daß ich kein Register benutze, sondern nur das eine Bit per Carry übergebe. Und es ist auch total egal, ob es "anders gehen würde". Wie ich schon sagte: Ich optimiere für x86-CPUs - ich werde nicht für "kaputte" Emulatoren optimieren. Sowas kann man echt nicht von mir erwarten.zatzen hat geschrieben:Ich habe Dein kleines Programm mal abgetippt und kann den Fehler in meiner Dosbox Version bestätigen. Wenn man den Umweg über ein Register (AL) geht, funktioniert die Sache aber, Dosbox versaubeutelt hier also scheinbar mit dem ROR Befehl nur etwas wenn es mit Speicherzugriff zusammenhängt.
Komisch, ich hab die 64bit-Version damals gefunden und runtergeladen. Allerdings ist seit v0.74 schon seit Jahren nichts mehr passiert. Wird da überhaupt noch dran gearbeitet?zatzen hat geschrieben:Dann habe ich noch ein Problem: Für mich sieht es so aus als gäbe es Dosbox überhaupt nur in 32 Bit.
Hm... Gerade gelesen, daß es wohl "demächst" eine v0.75 geben wird. Wäre natürlich nett, wenn der Bug dann weg wäre. Oder man die Leute noch rechtzeitig darauf hinweisen könnte.
Naja, ich weiß nicht, wie es auf diversen "Mirror-"Servern aussieht. Auf https://www.dosbox.com/ (dem "Original", wo es eingestellt wird) sollte man alles, was DOSbox angeht, finden.zatzen hat geschrieben:Bei den Downloads finde ich nur den "32 Bit Windows installer".
Naja, man kann es leicht erkennen: Hat man eine 64bit-Version, wird sie auf 32bit CPUs nicht laufen, nicht wahr?zatzen hat geschrieben:Was aber nicht unbedingt heissen muss dass das Programm selbst auch 32 Bit sein muss.
Ähhh... Moment...zatzen hat geschrieben:Vielleicht hast Du für mich einen Link zu einer definitiven 32 Bit Version.
Hab gerade mal heruntergeladen. Scheinbar gibt es nur noch die kaputte Variante.
Habe aber woanders noch eine gefunden.
Hinweis: die v0.74-2 scheint die kaputte zu sein, also v0.74 (ohne "Zusatz") nehmen.
Es scheint diese nirgends mehr zu geben. Die scheinen auf ihre Neuentwicklung so stolz zu sein, daß die alte nirgends mehr zu kriegen ist... - Außer natürlich bei mir.
Guckst Du hier:
http://www.imperial-games.de/DOSBox/DOSBox_OK.zip
Ist kein Installer, sondern einfach das ganze Ding in ein Verzeichnis geschmissen und gepackt.
DIe hat übrigens garantiert nicht diesen Fehler (hab's extra geprüft). - Was natürlich nicht heißen muß, daß es nicht eventuell andere Bugs gibt, die bloß noch keinem aufgefallen sind.
Wär natürlich schon lustig, wenn's DOSbox auch für Pentium-Emulation gäbe und man auswählen könnte, ob man gerne den FDIV-Bug (in den ersten Pentium CPUs) gerne mitemuliert hätte...
Ich wäre echt froh, wenn es eine einfache Möglichkeit gäbe, die DOSBox-Entwickler auf den Bug hinzuweisen.
Scheint so zu sein. Ich finde es natürlich eine MEGA-bescheidene Idee, verschiedenen Varianten des Programms die gleiche Versionsnummer zu geben. Die v0.74 (Windows) gibts dann also scheinbar mehrmals.zatzen hat geschrieben:Komischerweise funkioniert AtavISM auf meinem Windows XP Laptop auch nicht wunschgemäß
in der Dosbox, wo man eigentlich erwarten müsste dass es kein 64 Bit Dosbox ist.
Es ist nämlich ein 32 Bit Windows.
Vielleicht ist es auch eine Frage der Dosbox-Version.
Dann scheint es ja der Mühe wert gewesen zu sein.zatzen hat geschrieben:Gerne würde ich ein bisschen Musik in AtavISM machen.
Also kann man scheinbar damit arbeiten? (Obwohl es, wenn man es mal mit dem X-Tracker vergleicht, sehr klein und unscheinbar ist und quasi nichts kann.)
Fragen dazu, für die nächste Version:
1.) Was passiert eigentlich (bzw soll passieren), wenn man beim musizieren Track/Pattern-Ende angekommen ist? a) Da bleiben?
b) Aufs nächste Pattern im Sequenzer wechseln?
c) Aufs Pattern mit der nächsthöheren Nummer gehen?
d) Beides? (D.h. auf nächsthöhere Nummer gehen UND diese im Sequenzer eintragen?)
2.) Ich könnte die Patternlänge einstellbar machen.
Womit stellt man im X-Tracker die Patternlänge ein?
Naja, LEA geht ja schon immer. Das berechnet die sogenannte "effektive Adresse". (Im Real-Mode eben den Offset, den ein angegebenes Ding (z.B. Variable/Array/Wasweißich) zum angegebenen Segmentregister hat. Im PM funktioniert das zwar ähnlich, aber weil die "Segmentregister" da eigentlich anders funktionieren, doch nicht genauso.zatzen hat geschrieben:Mittlerweile habe ich mich mal etwas weiter aus dem Fenster gelehnt was Assembler innerhalb Freepascal angeht.
Auf Datenfelder zugreifen geht über z.B. LEA EBX, <arrayname> und dann MOV AX, DS:[EBX]
Ja ich weiß. Kann man auch im RealMode benutzen, muß aber drauf achten, daß die oberen 16 Bits der "Ergebnisadresse" immer 0 bleiben, sonst Segmentüberlaufsfehler. D.h. mit Präfixcode $67 stellt man die ADRESSIERUNG auf 32bitmode (mit $66 stellt man bekanntlich Speicher-/Registerbreite auf 32bit).zatzen hat geschrieben:oder auch solche umfangreichen Konstrukte wie ADD EAX, DS:[OFFSET <arrayname> + EBX + EBX]
sind möglich und syntaktisch erlaubt.
In der 32bit-Adressierung kann man (fast) ALLE Register zur indizierten Adressierung benutzen. Man kann für eins der beiden sogar einen Faktor (1,2,4,8) angeben. ES:[Variable+EAX*4+EDX].
Oder, wenn man zweimal das gleiche Register nimmt, kann man sogar "krumme" Indizes haben, weil man z.B. EBX*4+EBX nehmen kann (jedesmal wenn EBX um 1 erhöht wird, wird die Adressierung um 5 erhöht). Damit gehen auch so Schrittweiten wie 3 oder 9...
Na egal. Da geht schon eine Menge.
Hatte mich übrigens früher gewundert, wieso der jcxz nicht für 32bit geht, also quasi ein jecxz. (also db $66; jcxz). Komischerweise muß man hier auch das Präfixbyte $67 benutzen, dann gehts. (D.h. in Abhängigkeit von ECX=0 springen, nicht nur von CX=0). So kann man schön einfach mitten aus einer Schleife springen.
Sowas muß man für den jeweiligen Einzelfall betrachten.zatzen hat geschrieben:Ich frage mich da nur was schneller ist - wenn ich einmal das EBX (oder ESI, EDI) Register fülle oder wenn ich jedesmal OFFSET in der Addressierung verwende.
Außerdem ist es auch von CPU-Generation zu CPU-Generation verschieden. Es gibt sogar einige Befehle, die auf 386er 1-2 Zyklen weniger brauchen als auf 486er.
Aber auf PC kann man sowieso nur "aufs kleinste gemeinsame Vielfache" programmieren. Man weiß ja nie, auf welchen Kisten das überall laufen soll.
Naja, Im Gegensatz zu TP, wo quasi keinerlei "Speedhacks" drin sind, sondern der Compiler genau das (und nur das) macht, was man erwarten würde, haben die Freepascal-Leute sich hier wohl einiges bei den C-Compilern abgeschaut, die selbst erkennen, ob ein direktes Register in einer Situation schneller wäre.zatzen hat geschrieben:Noch eine Sache, ich weiss nicht ob es sich bei TP genauso verhält: Ich hatte während einer For... Schleife ein paar Zeilen Assembler, in denen ich AX und BX veränderte. Dadurch funktionierte die Schleife nicht mehr richtig.
Das "einfach mal an jeder beliebigen Stelle bissel Assembler reinklatschen" ist wirklich nur was für'n Realmode und TP. In FP nehme ich an, daß ASM nur außerhalb eines sogenannten "Anweisungsblocks" passieren sollte.
Weil scheinbar der 32bit-Modus/PM korrekt emuliert wird.zatzen hat geschrieben:Übrigens hab ich Dein Programm auch mal in Freepascal geschrieben, und dort funktioniert es korrekt.
Aber mir reicht der RealMode.
P.S.: Am Ende wird AtavISM noch Dein neuer Lieblingstracker...