Vice 1.21

...Vielleicht habe ich da was wesentliches verpasst ... was muss man denn tun um dieses "Ruckeln" zu bemerken? Besonders geschulte Augen haben?....

du hast was verpasst.

nein, im vollbildmodus wurde das ruckeln von den sprites beseitigt.
lade dir mal eine spriteroutine runter und lass die sprites mal nach rechts und links wandern.
bei der alten x64.exe ist die v0 nicht gleichmäßig , stört sehr.
bei der überarbeiteten x64e.exe ist wie beim originalen c64 endlich ein sooooftscrolling.

mfg

Zitat

Bezüglich der BIOS-Versionen: Ja, die habe ich inzwischen gefunden. Ich war beim ersten Versuch wohl etwas blind. Ich wollte übrigens kein dd haben - das habe ich selbst auf meiner Linux-Kiste - sondern ein schon funktionsfähiges Image einer SD-Karte. Soweit ich verstehe braucht die Emulation ja ein fertiges, "leeres" Image, oder nicht?

Gruß,
- Spiro.

Mit einem leeren Image wirst kaum was anfagen können.
Es sei denn du kennst ein Tool mit welchen man *.img files bearbeiten kann. (files löschen, hinzufügen)

Ich weiss jetzt nicht wie weit die Emulation da ist habe das nicht getestet.

Du kannst also jetzt bei der richtigen Hardware vom C64 ein d64 erstellen. Sonst benutzt man wohl öfter das MMC mit Hilfe des Computers die SD/MMC-Karte zu beschreiben. Prg-Files kann man problemlos starten mit dem Orginal Bios. Sind die Programme in ein d64, braucht man Plugins (z.B. der TNT-Browser). Nachladen geht soweit ich weiss mit dem dfi Plugin allerdings eben nur bei entsprechend angepassten Spielen/Software. Mit dem RetroReplay hat man allerdings die Möglichkeit auch Spiele nachzuladen (entsprechendes Plugin).

Da die Emulation noch nicht ganz so weit ist, denke ich das man da doch schon ein paar Programme auf der Karte drauf haben sollte. Jedenfalls muss auf der Karte denke ich mal ja auch bei der Emulation das Bios des MMC auf der Karte sein(?).

Zitat

Originally posted by super_castle
...Vielleicht habe ich da was wesentliches verpasst ... was muss man denn tun um dieses "Ruckeln" zu bemerken? Besonders geschulte Augen haben?....

du hast was verpasst.

Ich habe mir mal den Startscroller von Giana Sisters angeguckt und ja, wenn ich genau hingucke ist der nicht ganz regelmäßig.
Im Spiel selbst wenn ich auf auf die Spielfiguren schaue fällt mir der Effekt aber nicht auf.
Demnächst mal auf dem DTV testen obs da flüssiger ist

compilier mit acme die untere datei und probiere einmal x64.exe in volbild und dann die neue x64e.exe mit vollbild.

;--------------------------------------------------------------------------
;
; Sprite - wir lassen einen fliegen ....
;
;
; Quelle : http://www.minet.uni-jena.de/~andreasg/c64/c64_vic_html.htm
; Sehr empfehlenswerte Seite zum Thema VIC 6569
;
; Erweitert : 03/2004 M. Sachse http://www.cbmhardware.de
;
;--------------------------------------------------------------------------
!to "sprite.prg",cbm
;--------------------------------------------------------------------------
; sys-Zeile fuer den Basicstart
;--------------------------------------------------------------------------

*= $0800
!byte $00,$0c,$08,$0a,$00,$9e,$32,$30,$36,$34,$00,$00,$00,$00

;--------------------------------------------------------------------------
* =$0810 ;Startadresse
;--------------------------------------------------------------------------
start sei
jsr $e544 ; clrscr
lda #$07 ; Bildschirm in schwarz
sta $d020
sta $d021
ldx #$3f ; Spritedaten ....
sprin lda sprdat,x
sta $3000,x ; ... einlesen
dex
bpl sprin
lda sprdat+63 ; Spritefarbe holen
sta $d027 ; und setzen
lda #$80 ; X-Position #128
sta $d001
lda #$c0 ; Spritepointer Sprite 1 setzen
sta $07f8 ; $3000 = $c0*$40
lda #$01 ;
sta $d017 ; X-Zoom
sta $d01d ; Y-Zoom
sta $d015 ; Sprite 1 an
ldx #$00 ;
loop: txa ; X-Reg. in Akku
sta$d000 ; Psition setzen
dir: inx ; Main Loop : Richtung
jsr space ; Space Taste abfragen
jsr Delay ; etwas Zeit verschwenden (Delay)
loc: cpx #$ff ; Position abfragen
bne loop ; loop bei nicht erreicht
jsr finit ; ansonsten Daten fuer Move nach links und Zoom (X/Y)
cpx#$30 ; Position abfragen
bne loop ; loop bei nicht erreicht
jsr binit ; ansonsten Daten fuer Move nach rechts und kein Zoom (X/Y)
jmp loop ; und weiter im Loop

space lda $dc01 ; Space ?
and #$10
beq end
rts

end : lda#$00
sta $d015 ; Sprite 1 aus
jmp $ea81 ; wieder ins Basic
rts

finit lda #$ca ; $ca = dex
sta dir ; schreiben
lda #$30 ; neue Koordinate
sta loc+1 ; schreiben
lda #$01 ; X/Y Zoom an
sta $d017
sta $d01d
rts

binit lda #$e8 ; $e8 = inx
sta dir ; schreiben
lda #$e9 ; neue Koordinate
sta loc+1 ; schreiben
lda #$00 ; X/Y Zoom aus
sta $d017
sta $d01d
rts

;---------------------------------------------------------------------------
; Ein bischen Delay durch Warten auf den Rasterstrahl
;---------------------------------------------------------------------------

Delay:
ldy#$00
lda$d012
cmp#$00
bne Delay
iny
cpy#$03
bne Delay+2
rts

;---------------------------------------------------------------------------
; Ein sehr ideenreicher Sprite
;---------------------------------------------------------------------------

sprdat !byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $ff, $ff, $ff
!byte $ff, $ff, $ff, $0e ;-spriteDaten
;-

Zitat

Original von BastetFurry
MTools?

Naja, Linux-Kram.

Kenn jemand auch etwas für windows?

-----------

Und in der mmc64 Emulation läuft zu 95% nix.
Normale prg's starten sehr selten (oder stürzen spätestens nach ein paar Sekunden ab), DFI funktiniert auch nicht, und und und...

Hui, unglaublich! Die 'NEWS' Sektion sagt es gibt einen neuen Fullscreen Modus fuer X. Vielleicht ist das einer der zur Abwechslung sogar ... funktioniert!

Bislang hat noch nie ein Fullscreenmode von VICE bei mir unter Linux funktioniert.

Und mit XRANDR machen es die meisten anderen ja auch.

Gleich mal testen... ... schade. Wieder nichts (seufz). Wieder ein Fenster so gross wie der gesamte Desktop. Auf den winzigen Inhalt wird man ja in BUGS hingewiesen, das ist nicht das Problem - da kann man ja hoffen.

Vielleicht sollte ich einfach aufhoeren einen virtuellen Desktop zu benutzen. Obwohl ... wirklich jedes, aber auch absolut jedes andere Programm komm damit bislang klar ... und benutzt den aktiven Ausschnitt... mplayer, scummvm, dosbox, exult, prboom, openttd, diverse andere Emulatoren ... seufz. Nur VICE und UAE, die beiden schaffen es schon seit Jahren beharrlich bei mir keinen Vollbildmodus auf dem Screen zu zaubern. Bei uae wundert mich das kein bischen, da passiert ja schon seit Jahren nix mehr. Aber Vice?

Manchmal frage ich mich ob ich der einzige User bin der einen VD benutzt, aber angesichts der Tatsache dass dieses anderen Programme damit phantastisch klarkommen ...

Nun, die denkbar beste Loesung waere sich an freedesktop Vorgaben zu orientieren.

Siehe auch: http://www.freedesktop.org/wiki/Software_2fxfullscreen

X ist eine zu komplexe Sache und sollte dringend mal gesund geschrumpft werden, missen will ich's aber nicht.

Zitat

Original von Nightshade

Code

1. user@nowhere:~/var/binaries/Vice-Emul/bin$ ./x64
2. *** glibc detected *** realloc(): invalid size: 0x00000000004bb2e0 ***
3. Aborted

Ich habe das mal etwas genauer analysiert, leider bisher ohne Lösung des Problems.

Folgendes passiert:
In src/vicii/vicii-sprites.c steht der Pointer sprline beim ersten Aufruf von vicii_sprites_init_sprline() auf irgendwelchem Müll (z.B. eben 0x4bb2e0), obwohl er theoretisch mit NULL initialisiert sein müsste. Dadurch kracht es dann in der glibc wenn realloc() versucht, zuerst free() aufzurufen.

Ich habe schon versucht, den Pointer beim ersten Aufruf von vicii_sprites_init_sprline() noch einmal explizt auf NULL zu setzen, dann klappt zwar realloc(), aber es kracht kurze Zeit später mit einem Segfault, in valgrind sieht man nur recht chaotische Speicherzugriffe.

Auch ein Versuch, lib_malloc(), lib_calloc(), lib_realloc() und lib_free() mit einem globalen Mutex zu schützen brachte keinerlei Verbesserung, also scheint es wohl auch keine race conditio zu sein?

Weiß jemand vielleicht schon mehr?

Grüße, Felix

versuchs mal damit, ich muss die alle 3 hernehmen damit vice 1.21 funktioniert

Juhuu, das haut hin, vielen Dank Und endlich sieht FLI und Co auch ohne Realtime-Scheduling gescheit aus, mit 1.20 wollte das nicht klappen

Nur der Vollständigkeit halber noch eine kleine Änderung, die ich vorgenommen habe, damit es sich überhaupt compilieren lies:

Zitat

Original von BastetFurry
Jaja, die lieben Pointer.... ich meide sie in allem was sich nicht Assembler nennt, wenns geht. Natürlich nicht umbedingt nen 150 KiByte Array BYVAL, das wird schön BYREF übergeben, aber ansonsten, lieber keine Pointer.

Uhh, das sieht mir verdächtig nach VisualBasic aus :p

Ohne Pointer geht nichts, nur gibt es da ganz brauchbare Kapselungen, die in manchen Sprachen (z.B. C++) auch teilweise schon eingebaut sind.

Abgesehen davon: Im Code stand
static BYTE* sprline = NULL

also auf NULL initialisiert. Trotzdem hatte der Pointer bei der ersten Verwendung einen Phantasiewert. Das ist ein sehr seltsamer Effekt, irgendwas anderes muss da versehentlich dran rumgepfuscht haben.

Sowas /könnte/ man mit nem Watchpoint debuggen, wenn der GDB in Debian Etch AMD64 nicht so grauenhaft kaputt wäre

Aber nachdem das Problem mit den hier geposteten Patches verschwunden ist (danke nochmal *g*) hat es ja anscheinend schon jemand anders debuggt

Grüße, Felix

Zitat

Original von BastetFurry

Dann sollte man davon ausgehen das da auch NULL drin ist und nicht irgendein Schmarn.
Vielleicht mal direkt dahinter ein if(sprline != NULL)printf("FEHLER: sprline ist nicht NULL\n"); oder so.

Also ich entwickle ja nicht am Vice, hab mir das nur mal eher kurz angeschaut, weil es halt nicht funktionieren wollte.

Das blöde hier war: Es ist eine globale Variable, die steht dann wahrscheinlich einfach so im BSS-Segment (?), jedenfalls wird bei der Initialisierung kein Code ausgeführt, überprüfen kann man an dieser Stelle also nichts.

Die erste Verwendung ist in einer Funktion, die nicht davon ausgeht, dass der Pointer NULL ist. Die Funktion braucht aber als Zusage, dass /entweder/ der Pointer NULL ist, /oder/ auf einen bereits allokierten Speicherbereich zeigt. Also kann man auch hier nicht wirklich was überprüfen.

Langer Rede kurzer Sinn: So ein Bug kann eigentlich nur dadurch entstehen, dass /anderer/ Code diese globale Variable überschreibt (was seinerseits wohl wieder nur durch vermurkste Zeiger passieren kann), bevor sie jemals verwendet wird.

Das Problem hier ist aber nicht die Verwendung von Zeigern an sich. Vice ist hauptsächlich in C geschrieben, das kennt nicht die "Referenzen" von C++, also kann man da kaum ein sinnvolles Programm ohne Zeiger schreiben. Das Problem ist, dass man mit Zeigern diszipliniert umgehen muss Wenn ein Pointer erstmal irgendwo in die Prärie zeigt, fliegt einem eben was um die Ohren -> daraus leitet sich schonmal die Grundregel ab, undefinierte Pointer /immer/ auf NULL zu setzen...

Grüße, Felix