User:Gpz: Difference between revisions

From vice-emu
Jump to navigation Jump to search
mNo edit summary
 
(170 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Rendering ===


== readme ==
* check and maybe also make chip specific: "AspectRatio", "TrueAspectRatio", "KeepAspectRatio"


=== nailing down Problems and what are none ===
==== call tree ====


if attaching a cart (from the commandline) does not work as expected, please do the following (and report all results):
normal rendering call sequence:


* first try with "-config nosuchfile" as first arg. if this solves the problem then it is likely no bug in the cart system itself. (phew)
* video/video-canvas.c:video_canvas_render
* second try with "+cart" as first arg. if this also works, then unfortunately there is a chance that the cart related settings in your config conflict with the cart you are trying to attach, and since we are aiming to support more than one cart at a time there is also a chance that the combination of carts you are trying to use simply doesnt work (as on the real thing) - however, due to the way the cart system works right now (associating most carts with the "Main Slot", which means only one of those can be active at a time) still in many cases, if only one other cart in the "Main Slot" has been set as default, attaching a cart should "just work". hence...
** video/video-render.c:video_render_main (renderer main)
* try without any additional args, this should replicate your problem.
** check if any cart which is not in the "Main Slot" is active, and if so disable them. they might be the cause of the conflict (save settings, and try again. if this solved it, it is not a bug)
* try without *any* args (ie, just start the emu). check the log for errors


in *any* case, attach your vicerc and binaries to your bug reports
YUV rendering call sequence:


=== list of "slots" ===
* video/video-render.c:render_yuv_image (yuv renderer main)


* "Slot 0"
switching from/to fullscreen (alt-d):
** MMC64
** Magic Voice
*** all carts that have a passthrough connector go here
*** only one cart of this type can be active at a time (although some UIs might currently allow to enable more than one at a time - this will most certainly not work)
*** "Slot 0" carts have individual "enable" switches, enabling it means enabling permanently


* "Slot 1"
* video/video-resources:set_fullscreen_enabled
** Expert
** video_chip_cap->fullscreen.enable (arch/unix/x11/fullscreen.c:fullscreen_enable)
** Isepic
*** arch/unix/x11/xrandr.c:xrandr_enable
** dqbb
**** set_xrandr
** ramcard
***** FIXME: grab/ungrab mouse pointer
*** all carts that use memory resources may go here. however to keep the list low, we only put those here that somehow make sense to be active at the same time as one of the other "Main Slot" carts.
**** arch/unix/x11/gnome/x11ui.c:x11ui_fullscreen
*** theoretically any number of "Slot 1" carts can be active at a time (although the current WIP system will probably not work with that)
*** "Slot 1" carts have individual "enable" switches, enabling it means enabling permanently


* "Main Slot"
** video_chip_cap->fullscreen.statusbar (arch/unix/x11/fullscreen.c:fullscreen_statusbar)
** all other carts go here
*** only one "Main Slot" cart may be active at a time
*** carts in the "Main Slot" must be explicitly set as default to get them enabled permanently


* "I/O Slot"
setup: video_chip_cap set in:
** reu
* arch/unix/x11/fullscreen.c:fullscreen_capability
** georam
*** all carts that use only I/O resources go here.
*** any number of "I/O Slot" Carts may be active at a time (this should actually even work)
*** "I/O Slot" carts have individual "enable" switches, enabling it means enabling permanently
 
=== Expected Behaviour ===
==== startup ====
 
* when the emu is run without arguments, all settings from the config file should be applied
* arguments override settings from the config file
* when saving the settings to the config file it is expected that on the next run of the emulator all settings will be in the same state as when they were saved.
** there is an exception to this rule: the cartridge in the "Main Slot" must be explicitly set as default before it gets saved to the config file
 
==== command line ====
* +cart should disable ALL cartridges, including eventually activated REU, Swithlink and all similar expansionport devices.
* -cartXYZ options should generally attach AND activate a cart of type XYZ
** as a consequence, attaching carts this way which are NOT in the "Main Slot" will also enable the cart permanently
 
== TODO ==
 
=== Cart System ===
 
==== general ====
 
* update all i/o resource structs to contain proper initializers for peek/dump
* when enabling/attaching "Slot 0" carts, make sure only one of them is enabled at a time
* on i/o conflict, make sure the cart from the right slot(s) are detached.
* check _shutdown functions called from the cart hooks and rename (or move) them.
* (NJ) This "if (device) {" in c64io_unregister is asking for trouble. If it gets NULL, the bug is elsewhere; even a segfault is better than silently accepting the situation. - make an assertion instead
 
==== Expansion Port Resource ====
 
* rewrite c64export.c to maintain a list of attached expansion port resources (similar to how the i/o system works)
 
=== individual Carts ===
 
==== Capture ====
 
* Disabling Cart/Exit to Basic does not work
 
==== Digimax ====
 
* improperly combines samples to mono
 
==== Expert ====
 
* mapping is partially broken
 
==== Freeze Machine ====
 
* Fastloader does not work, several other weird things happen
 
==== Magic Formel ====
 
* accessing any of the "extra ROM" features does not work
* (CZ) cartconv converts a magic formel bin into a 128k crt file. normally mf images are 96k, so the resulting crt should honour that.
 
==== Magic Voice ====
 
* NMI stuff is broken
* debug interaction with TPI
 
==== Retro Replay ====
 
* (CZ) problems with rr+reu
** how to reproduce?
* rearrange bin/crt saving
 
==== Snapshot64 ====
 
* (CZ) ?
** works for me
* (CZ) "Snapshot64" != "SuperSnapshot64", the cmdline option should be "-carts64"
<pre>
f3 schmiert bei mir ab - monitor auch
f1 freeze fängt an zu speichern und semmelt dann weg
f5 ist ja lustig - formatiert und will dann direkt das snapshot speichern - crash dann halt
f7 geht :)
</pre>
 
==== Stardos ====
 
* (CZ) file copier produces garbage
* (CZ) disk copier crashes
 
==== Super Snapshot 4 ====
 
* (CZ) ?
** works for me
 
==== Warpspeed ====
 
* (CZ) "x64 -cartcrt WarpSpeed_v2_1987.crt" gives "IO read collision detection de47 between warpspeed and warpspeed"
** can not reproduce. tried with and without rr as default cart in vicerc, and with or without +cart
 
=== new Carts ===
 
http://moogle-tech.com/blog/?p=104
 
=== Monitor ===
 
* (NJ) Cart I/O peek needs a different range; f.ex EasyFlash has only two registers (mirrored to whole $ff), but the current system shows the whole range on io.
 
=== general ===
 
* add some more _dump functions and/or functionality to SID/VIC/CIA/TPI etc
 
== Buglist ==
 
PLEASE NOTE: THIS IS '''NOT''' THE OFFICIAL BUGLIST. PLEASE USE THE BUGTRACKER. THIS LIST IS ONLY FOR MYSELF - AND MOST THINGS IN THIS LIST ARE SUBJECT TO BE MOVED INTO THE BUGTRACKER AS WELL SOONER OR LATER.
 
<pre>
 
this is work in progress, if you want to help with this document send mail to
<groepaz@gmx.net>
 
things that are needed:
 
- more examples of programs that do not work correctly
- small testcase programs that show a certain bug
- small testcase routines that exploit a certain bug to detect an emulator
- confirmation whether programs listed here work (or not) on the real c-64, or
  another emulator, or even a specific version of some emulator
 
if you report a certain problem, please include the following info to make
maintaining this list easier:
- what program are we talking about? provide a web link to the program, if
  possible use csdb as a resource
- what emulators misbehave, which don't
- does it work on the real thing? if reporting whether it works on the real
  thing (or not), also report what kind of c64 was used (model, kernal version
  etc) - sometimes very old programs rely on old buggy kernal for example.
- if you are describing a generic problem, try to be as detailed as possible
  to make it easier to find out what's the cause.
 
please notice that list is NOT meant to only focus on vice. its just that:
 
a) my main desktop is a linux box, so i am using vice most of the time
b) vice seems to have the most bugs :) many of the problematic programs in
  the list work fine in ccs, and even more in hoxs.
 
so yes, ANY emulator bugs/problems are subject to be described in this list
(that is, stick to CCS, VICE and HOXS ... i don't think any other emus can
compete yet)
 
thanks for contributions must go to:
 
Fungus (some drive stuff)
assiduous (testing lots of stuff on the real thing, list of emu checks)
iAN CooG (some more problematic programs, more testing)
GRG (confirming NTSC bugs)
Mason (more problematic programs)
Andreas Matthies (confirmed some vice bugs)
 
and last not least: various ppl at csdb for their comments on specific
programs.
 
-------------------------------------------------------------------------------
==============================================================================
C64 Emulator Issues List v0.7, last updated 13/04/2010 (w) Groepaz/Hitmen
==============================================================================
-------------------------------------------------------------------------------
 
Emulator Versions represented here:
 
- VICE v2.2 (last release)
- VICE v2.2.x(SVN) (current development version)
- HOXS64 v1.0.4.24 (OUTDATED - PLEASE TEST A RECENT (1.0.5.29) VERSION!)
- CCS64 v3.3  (OUTDATED - PLEASE TEST A RECENT (3.8) VERSION!)
 
Contents:
 
  RULES OF THUMB
  "official" buglists
 
  Test Programs
    System Checks
    Programs that contain an Emulator Check
    Programs that contain a Cartridge Check
    Ideas
 
  C64 Emulation Issues
    SID related
    issues addressed by VICE x64sc
    Cartridge related
    NTSC related
    things that aren't actual bugs that you should be aware of
   
  1541 Emulation Issues
 
  VICE GUI Issues
 
  Appendix
    NON WORKING PROGRAMS - NOT EMULATOR ISSUES
    BUGGY PROGRAMS - NOT EMULATION ISSUES
    WORKING PROGRAMS - EMULATOR ISSUES THAT HAVE BEEN FIXED
    WORKING PROGRAMS - FALSE ALARM! SOMEONE FUCKED IT UP! =)
 
==============================================================================
RULES OF THUMB
==============================================================================
 
- always use d64, plain prg and t64 seem to be problematic
- always use true drive emulation
- switch virtual device traps off
- do not use more than one drive on the virtual drive chain
- set memory reset pattern to "normal". some (buggy) programs will not work if
  eg the memory is cleared with all zeros
- use exact pal emulation (some color-mixing tricks will not work without)
- when using VICE, select resid-fp (some things do not work without)
- when using VICE, also try with x64sc (it is more accurate)
- first and foremost, always use the latest version of the emulator
- test without a cartridge
 
and the most important one: DO ALWAYS TEST ON THE REAL THING!
 
if testing on the real thing and reporting results, it would be great if you
could also the results of the <Box Check "Type"> program mentioned below
run on your reference C64.
 
- Amber Cow/Charged  http://noname.c64.org/csdb/release/?id=4820
 
"The demo was coded on Vice 1.7 and made heavy use of its bugs. Hence it
crashes on a real C64 and bugs/flickers heavily on CCS64 and all versions of
VICE after 1.7... - LOL!!! Get the old VICE 1.7 on funet, if you want to see
the demo as it was intended."
 
==============================================================================
"official" buglists
==============================================================================
 
VICE team has a known bugs list: http://www.viceteam.org/plain/BUGS
VICE bug tracker: http://sourceforge.net/tracker/?group_id=223021&atid=1057617
ccs forum: http://www.computerbrains.com/ccs64/forum/viewforum.php?f=4
hoxs ?
 
==============================================================================
Test Programs
==============================================================================
 
since the move to sourceforge, and during the partial rewrite of x64 (which
is now x64sc), a lot of test programs have been collected and/or written:
 
https://vice-emu.svn.sourceforge.net/svnroot/vice-emu/testprogs/
 
additionally, the following programs are known that do more or less
specialized hardware tests:
 
------------------------------------------------------------------------------
System Checks
------------------------------------------------------------------------------
 
Y - works as expected, N - does not give expected result(s)
 
                        CCS    VICE    VICE          Hoxs64
                        3.8    2.2    2.2.x(SVN)    v1.0.4.24
                                x64    x64sc
Box Check "Type"        Y *1)  Y *2)  Y              N *3)
 
*1) gives typical breadbox, C64 DL 6569 6526 6526
 
*2) gives typical breadbox, C64 DL 6569 6526 6526; SID model affects detected
    SID if reSID-fp is used
 
*3) although hoxs tries to model a c64c with new SID, "old" CIAs are emulated
    - this is odd to say at least, and considering how anal the creator is
    about it being a c64c, it is considered a bug here.
 
Links:
 
Box Check "Type"      http://noname.c64.org/csdb/release/?id=89406
 
------------------------------------------------------------------------------
Programs that contain an Emulator Check
------------------------------------------------------------------------------
 
Y - test passed, N - emu detected
 
                        CCS    VICE    VICE          Hoxs64
                        3.3    2.2    2.2.x(SVN)    v1.0.5.29
                                x64    x64sc
Cucumber Juice 2        Y      Y      Y              Y
Deus Ex Machina        Y      Y      Y              Y
Demus Interruptus      Y      Y      Y              Y
+h Emu-Fuxx0r v1        N      N      Y              Y
+h Emu-Fuxx0r v2        Y      N      Y              Y
Waveform Composer      Y      Y *1)  Y *1)          Y
Aurora 90%              N      Y      Y              Y
Krestage 3              Y      Y      Y              Y
Box Check "Sprite A"    N      N      Y              Y
 
*1) needs reSID-fp
 
- [ccs] Aurora90%:
                               
"i write into unused bits in $01, and measure how long it takes to loose the
info emus either don't take that bit at all, or keep it forever while real
thing accepts bits, and loose value after some time"
(Works in Hoxs64 v1.0.4.24+, Works in Vice 2.2+ with resid-fp)
 
Links:
 
Waveform Composer    http://dekadence64.org/wavecomposer.prg
Box Check "Sprite A"  http://noname.c64.org/csdb/release/?id=88933
 
------------------------------------------------------------------------------
Programs that contain a Cartridge Check
------------------------------------------------------------------------------
 
Y - test passed, N - cartridge (wrongly) detected
 
                        CCS    VICE    VICE          Hoxs64
                        3.3    2.2    2.2.x(SVN)    v1.0.4.24
                                x64    x64sc
Typical/Beyond Force    ?      Y(*1)  Y(*1)          N
 
*1) Needs special RAM init pattern. Choose "First byte: 255" to make it work in
    VICE.
 
- [hoxs] Typical/Beyond Force  http://noname.c64.org/csdb/release/?id=4136
 
the cartridge check (first file) seems to fail on vice, it gets a bit further
in hoxs but also craps out :)
 
"IIRC Typical upscroller reads some $de00/$df00 byte every frame after calling
the music routine, and if it gets the same byte back multiple times (16? 32?)
it crashes the demo. I think some part which didn't work correctly with some
cartridge, or maybe I did that just to piss people off :)
 
  org $4145
 
  LDA $DF00
.cmp
  CMP #$00
  BEQ .same
  STA .cmp+1
  LDA #$F0
  STA $4251
.x
  RTS
.same
  INC $4251
  BNE .x
 
I think I should add my comment after Hoxs64 failed it:
(Now I'm wondering if Typical works on all C64s or not!)"
 
Rubi: Needs special RAM init pattern. Choose "First byte: 255" to make it work
in VICE. This "cartridge check" will also fail on real C64 with the memory init
pattern that VICE uses by default. CPU reading from disconnected memory at
$DF00 will get the values from the VIC-II reading on Phi1. This is graphic data
for most the time (depending on the cycle) and can be the same value for 16
times or more so this "cartridge check" is crap.
 
------------------------------------------------------------------------------
Ideas
------------------------------------------------------------------------------
 
"Is it fair to use the 1541 as EMU faxxor? It's very simple to set up some
drive code that would rely on the analogue properties of the serial cable,
which would be tricky to emulate. It's all a very simple test which I
implemented some years ago. Simply generate a square waveform from the drive
to the C64 in f.e. 1KHz. Sample this waveform on the C64 in a much higher
frequency. In a pure digital world (Emulator) you would count equally many
zeros as ones but in the real world this number will differ greatly due to the
CMOS logic levels and charge times."
 
(TESTCASE WANTED)
 
==============================================================================
C64 Emulation Issues
==============================================================================
 
*** [vice] NMI timing is wrong when NMI interrupts an IRQ
 
"A bug I discovered in VICE when I coded on The Wild Bunch was that the timing
when an NMI interrupts an IRQ setup was incorrect. IIRC it was 4 cycles too
much in comparison to the real thing. All I remember was that I had to take
special precautions to old CIA, new CIA and VICE CIA. I'll try setup a test
case someday or if somebody else cares to look at it."
 
(TESTCASE NEEDED!)
 
*** crash/hang for no apparent reason
 
- [ccs] Intoxication http://noname.c64.org/csdb/release/?id=4431
 
A: Fails on the title screen in CCS64. Works on the real C64, in Hoxs64 and
  VICE.
 
*** other strange behaviour
 
- [vice] Ultima IV Gold  http://noname.c64.org/csdb/release/?id=39893
 
"The IFFL scanner sometimes hangs when you flip 1541 disks in VICE"
 
"Please note that I have not done extensive testing on real hardware. I've
never experienced a hang on real hardware, but while I have tested in VICE
hundreds of times, I've only tested on real 1541s a dozen or so times. However,
I've never managed to reproduce the bug while I have breakpoints set in VICE,
which is mysterious..."
 
(TESTCASE NEEDED!)
 
*** [vice] problem with keyboard emulation
 
- [vice 2.2] AB/Zap http://noname.c64.org/csdb/release/?id=17634
 
A: works with VICE v2.2.x(SVN) (r22447)
 
"In part 2 (the one with Drago's Porsche picture) the space detection works
badly (not at all in VICE). Simply pop into the monitor and continue from
$139c to go on."
 
"abo: There is a single raster interrupt from line 0 to line 305 each frame.
Within the remaining lines space is checked by the main loop. The problem is
that the irq terminates by calling $ea31. This routine consumes much more time
if some key is pressed, so the irq extends to line 15 - just to be re-entered.
So effectively main loop is not executed if any key is pressed.
 
This means one has to press space exactly in the moment main loop is executed
in the last 8 lines of a frame. No wonder space detection works badly.
 
It does not work in VICE because keystrokes are only distributed randomly up to
16383 cycles starting from line 0. I will raise this limit to 312*63-1=19655
cycles in post 1.22 releases, so this demo will "work" like on the real thing
then.
 
The proper fix for the demo is to jump to $ea81 instead of $ea31 to exit
interrupt as the main loop directly checks $dc01 and thus does not need any
lengthy keyboard scan."
 
- [vice] Krestology
  VIC-II shows wrong colours when switching from hires background to idle
  with borders open.
 
(NEED INFO) 
 
- [vice, ccs, hoxs] http://c64tapes.org/taps/Spectipede_1006.zip
  Tracker: https://sourceforge.net/tracker/?func=detail&aid=2110948&group_id=223021&atid=1057617
 
  Wrong emulation of illegal opcode ANE (aka XAA) makes some Mastertronic
  tape loader fail.
 
(MORE TESTCASES WANTED)
 
- [vice 2.2] CIA TOD counts incorrectly, and 50/60hz bit is ignored
 
10 ? chr$(147): c=56320
20 t=c+8: s=c+9: m=c+10: h=c+11: b=c+14
30 poke b,peek(b) and 127: gosub 100
40 poke b,peek(b) or 128: gosub 100
50 end
100 poke h,0:poke m,0:poke s,0:poke t,0
110 for i=1 to 9350: nexti
120 rh=peek(h): rm=peek(m)
130 rs=peek(s): rt=peek(t)
140 rs=int(rs/16)*10+rs-int(rs/16)*16
150 ? str$(rs)":"right$(str$(rt),1)
160 return
 
correct output:
 
PAL:  12:5 - 15:1
NTSC: 14:6 - 17:6
 
(TODO: rewrite testcase in ML for better accuracy)
 
nojoopa: Fixed/improved in r22472, but needs a better test.
 
-------------------------------------------------------------------------------
SID related
-------------------------------------------------------------------------------
 
- [ccs] Demo IV  http://noname.c64.org/csdb/release/?id=30802
 
the last part flickers
 
"A: And so it does on the real thing, however the flickers are much less
frequent and perfectly predictable. They occur 3 times per tune duration - at
the very beginning, then 8 seconds into the tune, and the third one occurs when
the melody sees a rapid change. In VICE, the flickers are very frequent and
they cause the tune to restart at times."
 
"Yet another emulator that can't handle Demo IV properly: CCS64. Flickers madly
and the music is prone to restarting."
 
(Works in Hoxs64 v1.0.4.24+, Works in v2.2.x(SVN) if resid-fp is selected)
 
- [ccs] pico/sounddemon  http://noname.c64.org/csdb/release/?id=17603
 
"SounDemons noise waveform hacks does not work in emus too, since they don't
emulate the aspect of the SID used here"
 
"CCS64 can't playback the waveforms as intended (although it passes the
emulator check in Waveform Composer), but did you check with Hoxs64? Numerous
fixes were made to it in the past to ensure that these waveforms are handled
properly."
 
(Works in VICE 2.2+ if resid-fp is selected.)
 
-------------------------------------------------------------------------------
issues addressed by VICE x64sc
-------------------------------------------------------------------------------
 
nojoopa: To clarify... these will never be emulated in the regular x64,
        unless we end up replacing x64 with x64sc.
 
*** [vice (x64), ccs] inline gfx data changes are not emulated
 
https://vice-emu.svn.sourceforge.net/svnroot/vice-emu/testprogs/VICII/gfxfetch/
 
"Simple test for support of in-line graphic _data_ changes.
Check for horizontal splits.
 
Does not work in VICE 2.2 (x64) or CCS V3.2.
 
Should probably set $d800 too, but I leave that as an exercise. :)
.C:c000  78        SEI
.C:c001  A9 1F      LDA #$1F
.C:c003  8D 18 D0  STA $D018
.C:c006  A2 00      LDX #$00
.C:c008  8A        TXA
.C:c009  9D 00 04  STA $0400,X
.C:c00c  E8        INX
.C:c00d  D0 FA      BNE $C009
.C:c00f  AD 01 38  LDA $3801
.C:c012  49 FF      EOR #$FF
.C:c014  8D 01 38  STA $3801
.C:c017  EA        NOP
.C:c018  EA        NOP
.C:c019  4C 0F C0  JMP $C00F"
 
(Works in Hoxs V1.0.4.15, Works in VICE 2.2.x(SVN) x64sc)
 
*** [vice (x64), ccs] The VIC-II implementation lacks cycle exact sprite collision support
 
(Works in VICE 2.2.x(SVN) x64sc)
 
-------------------------------------------------------------------------------
Cartridge related
-------------------------------------------------------------------------------
 
*** [vice] AR/RR cartridge freeze/restart issues
 
insert ar, freeze, restart , unfreeze a few times. vice will randomly jam. it
will fuck up eventually, and you have to actually close vice and re-execute vice
to make it work again
 
GPZ: seems to work in VICE v2.2.x(SVN) with AR and RR
 
*** [vice] Freeze is always triggered at same rasterline
 
- Turrican http://noname.c64.org/csdb/release/?id=35705
  Tracker: https://sourceforge.net/tracker/?func=detail&aid=2459243&group_id=223021&atid=1057617
 
"The Freeze function with the Action Replay does not function yet as at the
real C64. Example: With the freezing of game with Splitscreen (Turrican), the
VICE always freezes with the lowest grid line. This not possibly makes a changing,
with the text editor of the Freezemenu, the playing field."
 
GPZ: confirmed, freeze events should probably randomly distributed over a frame
    just like keyboard events
 
*** [vice] RR cartridge incomplete emulation (flash jumper, should use flash040)
 
- Crypt Game Cartridge  http://noname.c64.org/csdb/release/?id=51254
 
*** [vice] Capture
 
Disabling Cart/Exit to Basic does not work
 
*** [vice] Freeze Machine
 
Fastloader does not work, several other weird things happen
 
*** [vice] Magic Formel
 
accessing any of the "extra ROM" features does not work
 
*** [vice] Attaching V4.1 IDE64 ROM image fails in WinVICE
 
Tracker: https://sourceforge.net/tracker/?func=detail&aid=2466527&group_id=223021&atid=1057617
(TESTCASE NEEDED)
*** [vice] Digimax driver improperly combines samples to mono
 
Tracker: https://sourceforge.net/tracker/?func=detail&aid=2483496&group_id=223021&atid=1057617
(TESTCASE NEEDED)
 
*** [vice] JAM at $9243 Stationfall + REU (file attached at tracker)
 
Tracker: https://sourceforge.net/tracker/?func=detail&aid=2828706&group_id=223021&atid=1057617
 
nojoopa: JAMs with 2.2.1ish but not with current trunk. Must have been that DMA
        -to-REU-regs thing.
 
*** [vice 2.2] ISEPIC
 
- switch does not work as expected
 
GPZ: partially fixed in trunk. still something wrong it seems :(
 
-------------------------------------------------------------------------------
NTSC related
-------------------------------------------------------------------------------
 
*** [vice 1.21] Borders have wrong dimensions in NTSC mode
 
should be ? lines in top- and ? lines in bottom border
 
(NEED INFO)
 
"NTSC should have at LEAST 8 more lines visible in bottom border, and about 6
or 7 in the top"
 
"Here on my real ntsc c64 the right border has 8 more pixels to display raster
colours and siderborder sprites.
 
PAL Vice emulation displays 384 pixels width.
So, correct NTSC vice emulation would be 392 pixels width.
 
The reason for the extra 8 pixels is ntsc being 65 cycles ?
 
-------------------------------------------------------------------------------
things that aren't actual bugs that you should be aware of:
-------------------------------------------------------------------------------
 
*** [css, hoxs] missing feature: lightpen emulation (yes not a bug)
 
nojoopa: Added in 2.2, but currently (r22442) disabled for x64sc
nojoopa: recently added to x64sc as well.
 
*** [vice] emulator system state is always the same when starting
 
various methods of randomizing data will fail on vice (ie, always give the same
result) when using the autostart feature.
 
*** [ccs] strange problematic patched kernal (?)
 
"I've been made aware of a significant CCS64 flaw. Namely it comes packaged
with Kernal Revision 2. However iAN CooG claimed to have checked "Leftovers/
Shadi Software" with Kernal Rev2 in CCS64 and wrote here that the intro part
was all black, while it's blue with the Kernal that CCS64 comes with. Could it
be that there are different Rev2 Kernals around?"
 
"CCS always has a PATCHED rev2, which load $0286 instead of $d021 during jsr
$e544. An ugly hybrid I never understood why not simply replace it with a rev3.
I tried with a real rev2, I have something like 40 different kernal roms in
CCS\ROMS\ dir to make tests with ;)"
 
 
Audio:
-------------------------------------------------------------------------------
 
*** [vice 2.1] audio/video timing problems due to audio buffering
 
- 15 Years Oxyron Party - Invitation  http://noname.c64.org/csdb/release/?id=45690
"Audio buffering is a requirement for any software based audio playback. The
option is there to set the buffer to a lower value for those with fast
machines, which makes the problem less apparent. Impossible to work around."
 
"still there is no option to set it below 100msec. And that's still quite a
lot! why not allow 50msec? or 20msec (== 1 frame). My pc wouldn't be bothered
by it."
 
"For windows there are ASIO or WDM drivers for many soundcards that will allow
near realtime audio (a couple of milliseconds or less in latency).
A selectable buffered video to match the lag of the audio could be useful for
watching timed demos."
 
"Simply delay the video update to be in sync with the audio..."
 
A: this has drastically improved in 2.2, much smaller buffers (and thus less
  latency) can be used now.
 
Video:
-------------------------------------------------------------------------------
 
*** [vice,ccs] palette has "wrong colors"
 
this is often complained about, but it is _not_ a bug. read peptos research
page to understand how vic colour generation works
(http://www.pepto.de/projects/colorvic/)
 
the essence is, that there are infinite "correct" palettes. whether the palette
matches what you know from your c64 depends on many factors, like your c64,
your monitor, the operating system you use on your pc, and your pc monitor.
 
what you have to do to get the most "accurate" colours is enabling "exact pal
emulation" in the emulator, and then tweak the various parameters until you are
satisfied with the result. this is basically the same as tweaking the various
knobs at your monitor of your C64.
 
(Works if "PAL emulation" or equivalent colour generation is active)
 
*** [vice 1.21] PAL Emulation does not emulate horizontal Chroma "bleeding" correctly
 
- Vandalism News #36 Dialogue 3  http://noname.c64.org/csdb/release/?id=46312
"...Another piece of evidence of the malfunctioning Vice emulator. Here two
different shades of purple colour appear differentiated (different in general)
on a real C64/c128 connected to a typical television generating a nice Gaussian
blur to the picture (built in CRT feature??)
 
Now why is it that people seem to have forgot to implement that? (Not the
Gaussian thing), but what the different colors look like if they are started on
a different y-position and with this type of pattern drawn??"
 
(Works in VICE v2.2+)
 
- Play With Colors 1/Wrath Designs  http://noname.c64.org/csdb/release/?id=50555
"The reason why I never liked the emulators was (and unfortunately up to this
date) still is the fact that the colours are not 100% emulated. When drawing a
field 121212 and 212121 made a great difference on a normal television and
computer-monitor. On the emulator with the PAL-emulation activated there is
still no difference which is a shame. Fix it!"
 
A: much improved since the new exact PAL emulation.
 
(Works in VICE v2.2+)
 
*** [vice, ccs]  "missing thing in the emulation, is CRT phosphor emulation also"
 
*** [vice] missing feature: NTSC emulation
 
Tracker: https://sourceforge.net/tracker/?func=detail&aid=2911887&group_id=223021&atid=1057617
 
A: proper NTSC emulation is in the making, see the link below.
 
*** [vice] "wrong picture size/dimensions"
 
- [vice] Darwin/The Dreams  http://noname.c64.org/csdb/release/?id=12732
 
"Where CCS fails Vice goes like a charm, and the digi part works fine. :)
The only pitiful thing is that Vice renders only 272 pixels on Y axis (instead
of 282 rendered by CCS) so on the last part the lower border scroller seems
going too far under the screen."
 
nojoopa: VICE "Full" border mode shows 293 lines, showing the scroller (almost)
        completely.
 
There is an ongoing effort to improve the video output much further, have a
peek at http://hitmen.c02.at/temp/palstuff/
 
==============================================================================
1541 Emulation Issues
==============================================================================
 
*** [vice 1.21] gcr stream wraparound bug
 
drive emulation can not handle a sync mark that is located on the track
wraparound (ie starts at the end of a track and continues at the beginning)
 
*** [vice,ccs] unidentified problems with protected disks
 
- DarkStar BBS V3.1  http://noname.c64.org/csdb/release/?id=47911
 
The protection (STAGGER TRAX 64) is imagable by mnib but vice or ccs64 won't
run it.
 
*** [vice 2.1] JAM with protected games
 
- Grand Monster Slam
- Turrican 2
  Tracker: https://sourceforge.net/tracker/?func=detail&aid=2789689&group_id=223021&atid=1057617
 
(TESTCASES NEEDED!)
 
- [vice 2.0] "The Toy Shop" by Broderbund
  Tracker: https://sourceforge.net/tracker/?func=detail&aid=2371598&group_id=223021&atid=1057617
 
"Trying to start an original The Toy Shop-Copy from a G64 freezes the emulator.
When I try to print, WinVICE quits (with a segfault) and tells me:
An unexpected error occurred. Received signal 11()."
 
(TESTCASE NEEDED!)
 
*** [vice] serial timing latency is not implemented. (1 cycle per foot of cable or so).
 
(NEED INFO)
 
*** [vice] "1571 has extra delay on on reading sync inside the drive,
 
"you cannot use BVC in 2mhz mode!"
 
(NEED INFO)
 
*** [vice] "clk has one cycle extra delay or so also in 1541 when data also changes... (or something)"
 
(NEED INFO)
 
*** [vice 1.21] Exos V3 loader doesn't work in C64 emulation + 1541 in Vice-1.21
 
Confirmed, Exosv3 works only with 1541-II
 
GPZ: works fine in VICE 2.2 (even with 1541)
 
==============================================================================
VICE GUI Issues
==============================================================================
 
The following are not "emulation bugs" per se, but the remaining few things
from the official buglist that did not fit into any of the sections above.
 
from BUGS:
----------
 
- Xaw UI context popup menu for drive attach is broken if more than
  two drives are active.
 
- Screenshots with activated PAL emulation do not deliver the expected
  (blurry) result.
 
- When a key which is shifted on the real machine but unshifted on the
  PC or Unix keyboard you are using is pressed, the virtual shift is
  pressed together (i.e. at the same clock cycle) with the main key;
  this could not work with some keyboard routines.  If you have to
  use the function keys, press the (real) shift key manually (e.g. F2
  = Shift + F1, F4 = Shift + F3 and so on); this also works with other
  keys.
 
- Using X11 XAW it is not possible to enter the disk name in the
  create empty disc image dialogue.
 
- In the win32 port keyboard input can be garbled after issuing a
  reset on CPU JAM.
 
- Commandline `-logfile SOME/FILE.log' fails to record logs to
  `SOME/FILE.log' when resources are loaded via menu (load settings).
 
other:
------
 
-  "Also in WinVICE, "always on top" doesn't work when switched on at boot.
  Frankly, I'm amazed that this isn't the 'known bugs' list already"
 
##############################################################################
==============================================================================
---------------------- CUT HERE, REST IS OLD STUFF ---------------------------
------------------------------------------------------------------------------
 
------------------------------------------------------------------------------
==============================================================================
Appendix
==============================================================================
------------------------------------------------------------------------------
 
==============================================================================
NON WORKING PROGRAMS - NOT EMULATOR ISSUES
==============================================================================
 
i just collect those here to post them somewhere else later so the entries in
csdb can get fixed:
 
- Zamzara/RSI  http://noname.c64.org/csdb/release/?id=19658
 
A: It shows the same behaviour on a real thing, so it's not a bug in the emulator.
 
  ... now fixed in csdb!
 
- [vice] Lifeboat/Dover Dodge http://noname.c64.org/csdb/release/?id=42776
 
"crashes on both VICE/CCS after pressing the key..."
 
A: Corrupt, it doesn't work on a real C64 either.
 
- [vice] Violator +4/X-Ray http://noname.c64.org/csdb/release/?id=42716
 
"Not working in VICE, No option now to test it on real c64"
 
A: The same behaviour on a real thing.
 
- [vice] Coop/Spench, The Sixth Sense  http://noname.c64.org/csdb/release/?id=41267
 
"Not working in VICE or CCS64"
crashes shortly after run in vice 1.20
 
A: Doesn't work on a real thing either.
 
- [vice] Compressor V1/AFL  http://noname.c64.org/csdb/release/?id=31542
 
crashes after intro (syntax error?)
 
A: The same error on a real thing - not an emulator issue.
 
- [vice 1.20] The Movie Writer V1.2  http://noname.c64.org/csdb/release/index.php?id=33771
 
"directory routine doesn't seem to work in vice1.20"
 
A: Neither does it on a real C64.
 
*** [Vice, CCS, HOXS] Die Donnernde Kataun/Abyss  http://noname.c64.org/csdb/release/?id=2396
 
"irq does not trigger correctly.
Patching it like this will do:
 
0873  20 D4 08  JSR $08D4
 
08D4  8D 1A D0  STA $D01A
08D7  8D 19 D0  STA $D019
08DA  A9 1B    LDA #$1B
08DC  8D 11 D0  STA $D011
08DF  60        RTS"
 
"A: It fails on the real thing, too."
 
unpatched version works in vice1.22
 
- [vice] Nobby the Aardvark +6/RSI  http://noname.c64.org/csdb/release/?id=48068
 
"Loader crashes on VICE 1.21, both with 1541 and 1541-II."
 
"A: Doesn't load on the real thing (1541-II), either."
 
- [vice] A New Type/Alloy Graphic Design  http://noname.c64.org/csdb/release/index.php?id=23182
 
"does not seem to work in either vice or ccs (pressing space in the first part does nothing)"
 
"A: And it does nothing on the real C64, for that matter."
 
- [vice] Sailing/Popeye  http://noname.c64.org/csdb/release/?id=21902
 
"Messed up graphics after the intro (atleast in vice), bad file?"
 
"A: The same garbage rendered by the real VIC."
 
- [vice 1.20] Mad Springs +2/The Ruling Company+The Blasters Incorporated  http://noname.c64.org/csdb/release/?id=38408
 
graphic in the crack intro is messed up
 
"A: Not an emulator fault, it's the same on the real thing."
 
- [vice] The Plague  http://noname.c64.org/csdb/release/?id=9524
 
crashes after some parts
 
"Collision Pt: Really nice picture (FLI) of a red car. The highlite of the demo. 1x1 hires dycp and tune
_Loader Pt: Picture, No Music
 
Pt: The parts failed to work on Vice :(
 
Pt: 0F (Load direct from Dir).
Hires sprite dycp over Bitmap logo in upper screen area. Large char scroller in lower screen area
_Loader Pt: Good picture of Judge Dread.
Pt: Good looking swinging logo, 3 1x1 DYCP and a really nice tune :)
_Loader Pt: Picture, better than Loader pt 4 picture
Pt: Flashing hires image of 2 people, followed by the real Pt
 
Restire FAILED TO WORK TO EXIT PT (on Vice) -?-
 
(Load part 0H direct from Dir)
Part 0H - Last Pt: Good logo with some rasters inside it."
 
"It is possible to load the parts separately. The part after the "Really nice picture (FLI) of a
red car" won't work if you start the demo from the very beginning, or "0A", or "0B". It will work,
however, provided you start the demo from the "0C" file (which is the part preceding the troublesome
one) or load the part directly ("0D"). The same quirk occurs on the real thing.
 
As for the "Restire" key failing to work in the part 0H, it does work if you press any other key beforehand.
For instance, press space and "Page Up" (Restore) subsequently to exit the part. This is how it works on
the real thing too - the problem lies in the code, not in the emulation."
 
- [vice] Beyond Dark Castle
        http://noname.c64.org/csdb/release/?id=51001
        http://noname.c64.org/csdb/release/?id=51002
Rubi: Crashes on real C64 and even in Hoxs-1.0.4.24 and CCS3.3 if you select "normal" load.
       
"I got problems running these 2 versions of Beyond Dark Castle. After
typing in the doc-check (FBR in the FBR version or just Enter in the
NEC version) it loads a bit and then just writes ready on the
commodore screen.
 
It works perfect in CCS. Tried it both on 1.20 and 1.21."
 
==============================================================================
BUGGY PROGRAMS - NOT EMULATION ISSUES
==============================================================================
 
- Comic Art 9/Mayhem  http://noname.c64.org/csdb/release/?id=38695
 
Main file crashes in Vice 1.19/1.20, works in CCS64 V3.0 Beta 1.7
 
"A: As a matter of fact, it's CCS64 that's inaccurate in this case - the collection crashes
on a real C64 in the same way as in VICE and Hoxs64."
 
"Actually not an emu issue but it's only a fault on the cruncher used, which expects all
the mem filled with zeroes(!!)
Fill the memory with zeroes yourself, or set the memory fill pattern to all zeroes and it
will work everywhere. Easy to patch :)
 
In CCS works because the mem fill pattern is REVERSED (00 instead of ff and viceversa).
Fill the mem with ff's and you'll see it failing on ccs too."
 
- Leftovers/Shadi Software  http://noname.c64.org/csdb/release/?id=22677
 
"The intro part has light blue background where it should be black. (atleast in VICE)"
 
"A: It's light blue in Hoxs64, CCS64, and on the real thing. Looks to me like a bug in the
code or a bad visual taste."
 
"This is probably a kernal revision issue. One of the things that differ is the color in
colorram after printing a #147 (CLR).
 
IIRC the different behaviours are:
- colorram set to 1 (white)
- colorram set to the contents of $d021
- colorram set to the contents of 646 (i.e cursor color)
 
A lot of older demos relied on the two last of these."
 
"Confirmed, kernal rev 2 in all 3 emulators and the part is in black"
 
- [vice] Alternate Reality/Mr. Zeropage  http://noname.c64.org/csdb/release/?id=26135
 
hangs after the character selection/randomizing
 
"A: There's only 1 disk side to download, where are the others? Fails on the real thing too."
 
"No wonder it doesn't work, file "AA" has a bad sector with illegal link to 13/77 (as stated by 64copy)"
 
- [CCS] Rick Dangerous/Myth  http://noname.c64.org/csdb/release/?id=20577 (does NOT work on real c64)
 
"Nope, it's not a bank switching issue. Looking at the code (as you've obviously done),
you can see that every memory configuration works, as long as I/O mem is switched on.
The bug is caused by the program switching off timer interrupts (lda #$7f sta $dc0d)
without acknowledging any pending timer interrupts (by doing e.g. lda $dc0d). Sometimes,
a timer interrupt has been triggered before they're switched off, and hence, as soon as
the interrupt flag is cleared, a timer interrupt occurs, which is never acknowledged."
 
"A: It doesn't work on the real thing, which was confirmed by j0x in the comments ("I did this because
I was curious why it didn't always work under Vice - or on the real thing, for that matter"). Again,
the fact it does work flawlessly in CCS64 suggests that an inaccuracy exists in this emulator."
 
"I found out that "Rick Dangerous/Myth" fails in CCS64 v3.3 with Kernal copied from Hoxs64, which suggests
that it's merely a Kernal revision issue. It should be noted that the game works solely with Kernal Rev2
and will fail in any emulator using Kernal Rev3."
 
- Brutal Blue/Orbs  http://noname.c64.org/csdb/release/?id=41886
 
"Had some problems with the loader. I remember this working on an older version of Vice though."
 
"A: Doesn't work on the real thing, which indicates there was a problem with an older version of VICE."
 
"I just tested it, works in every emu only if you use exos v3, would be nice if someone can test it on
the real thing with that kernal rom."
 
"Definately bugged, the author must have coded and tested this under exos only(?)
This is the proof, it always fail to load the "Z.*" turboloader at $cd00
C248  A9 01    LDA #$01
C24A  A8        TAY
C24B  A2 08    LDX #$08
C24D  20 BA FF  JSR $FFBA
C250  A9 03    LDA #$03
C252  A2 80    LDX #$80
C254  A0 C2    LDY #$C2
C256  20 BD FF  JSR $FFBD
C259  20 D5 FF  JSR $FFD5  << a=3 here, so does NOT load but verify
C25C  A9 41    LDA #$41      apparently exos always loads, which is weird
C25E  8D FD 9F  STA $9FFD
C261  A9 2E    LDA #$2E
C263  8D FE 9F  STA $9FFE
C266  A9 2A    LDA #$2A
C268  8D FF 9F  STA $9FFF
C26B  4C 00 CD  JMP $CD00  << and here executes "random" code
 
lda #$00 before the jsr $ffd5 is enough (and mandatory)"
 
 
- [vice] Defcom/Jazzcat  http://noname.c64.org/csdb/release/?id=29387
 
"Another one for the collection of weirdness. This one crash on Vice,
but works fine in CCS."
 
"Works in CCS and on the real thing but not in Vice."
 
"Almost the same issue as in Comic Art #9/Mayhem, decruncher relies on memory
contents and most probably filesize ($ae/$af contents after loading).
Patch the main file adding 16 zeroes at end and it always works.
Actually both this and Comic Art 9 will run unpatched if you reset after the
crash and reload them."
 
- never ending  http://noname.c64.org/csdb/release/?id=36312
 
"I am not able to find any code that would load next part... are we sure that is meant to load the next part pressing space?
Plus I noticed this
7600  A9 0F    LDA #$0F
7602  8D 18 D4  STA $D418
7605  78        SEI
7606  A9 35    LDA #$35
7608  85 01    STA $01
760A  20 10 E8  JSR $E810 ; play music
760D  A9 37    LDA #$37
760F  85 01    STA $01
7611  58        CLI
7612  A2 00    LDX #$00  ;some delay loop
7614  A0 F4    LDY #$F4
7616  C8        INY
7617  D0 FD    BNE $7616
7619  E8        INX
761A  D0 F8    BNE $7614
761C  60        RTS      ; never reaches here, irq happens during
                          ; previous loop
 
7630  20 00 76  JSR $7600 ; calls previous routine but
7633  4C 81 EA  JMP $EA81 ; never reaches here, too
 
someting strange is happening here."
 
"(C:$7616) m 100
>C:0100  32 76 fc 88  37 a0 16 76  32 76 f7 88  37 a0 17 76  2v..7..v2v..7..v
>C:0110  32 76 f8 88  37 a0 16 76  32 76 f5 88  37 a1 17 76  2v..7..v2v..7..v
>C:0120  32 76 fb 89  37 a1 17 76  32 76 fe 82  37 a1 17 76  2v..7..v2v..7..v
>C:0130  32 76 f6 8a  37 a1 17 76  32 76 f5 8b  37 a1 17 76  2v..7..v2v..7..v
>C:0140  7d ea fc 3f  37 a1 17 76  32 76 f7 87  37 a0 16 76  }..?7..v2v..7..v
>C:0150  32 76 fb 89  37 a0 16 76  32 76 f5 88  37 a0 16 76  2v..7..v2v..7..v
>C:0160  32 76 ff 89  37 a0 17 76  32 76 fe 83  37 a0 17 76  2v..7..v2v..7..v
>C:0170  32 76 f5 8b  37 a0 17 76  32 76 fe 8b  37 a0 17 76  2v..7..v2v..7..v
>C:0180  32 76 fb 87  37 a0 17 76  32 76 f7 8c  37 a0 17 76  2v..7..v2v..7..v
>C:0190  32 76 f8 8e  37 a0 17 76  32 76 00 8f  37 a0 1a 76  2v..7..v2v..7..v
>C:01a0  32 76 00 8f  37 22 17 76  32 76 f6 8e  37 a0 17 76  2v..7".v2v..7..v
>C:01b0  32 76 f7 90  37 a0 16 76  32 76 fb 8f  37 a0 17 76  2v..7..v2v..7..v
>C:01c0  32 76 f7 90  37 a0 16 76  32 76 fa 8e  37 a0 16 76  2v..7..v2v..7..v
>C:01d0  32 76 f8 8e  37 a0 17 76  32 76 fb 8c  37 a0 17 76  2v..7..v2v..7..v
>C:01e0  32 76 fc 8c  37 a0 16 76  32 76 fa 7f  37 a0 16 76  2v..7..v2v..7..v
>C:01f0  32 76 f7 8a  37 a0 16 76  32 76 00 89  37 a0 1a 76  2v..7..v2v..7..v
 
\o/ ahrahr
Demo title makes some sense now :)"
 
- [vice] Invest-TRC&Blasters  http://noname.c64.org/csdb/release/?id=50335
Rubi: A. reports that it doesn't work on real C64. So why is this in the emulator issue section?
 
For the list of bugreports for emulators. Invest works perfect on the
real c64 without any problems.
 
A: Doesn't work on the real thing nor in any emulator. I suspect a disk error,
as the drive head rattles before the program exits to BASIC.
 
- [vice] Quadra-Lazer  http://noname.c64.org/csdb/release/?id=51005
Rubi: Needs special RAM init pattern. Choose "First byte: 255" to make it work in VICE.
 
"Just found this one which crashes on Vice, but works fine in CCS"
 
- [vice,ccs] Skull & Crossbones/Faces  http://noname.c64.org/csdb/release/?id=51007
Rubi: Freezes on my real C64 too.
 
"the game freeze after the trainer screen on Vice
(or doesnt get that far in CCS). When running this on my real C64 then
it starts loading after the trainerscreen, but it doesnt do on Vice."
 
- [vice] Hollywood Poker Pro [pal/ntsc]/Hotline + International Network of Chaos http://noname.c64.org/csdb/release/?id=43460
Rubi: This is only reproducable if you have virtual device traps enabled and use Autostart feature.
The intro is buggy and would probably show the same beahviour on the real machine if you enter RUN in
the wrong moment (raster line 191). Rule of thumb: switch virtual device traps off would help.
 
"Although this game works on both PAL and NTSC computers, VICE has problems when in PAL
mode getting past the HTL/INC intro (which is PAL compatible and works okay in CCS64).
NTSC mode will get you farther in Vice. Due to the loading routine, this game may also
give some emulators problems."
 
- [CCS64] FlyingSharkPreview+-Ikari&FAC  http://noname.c64.org/csdb/release/?id=21889
Rubi: Needs special RAM init pattern. Choose "First byte: 255" to make it work in VICE.
 
"Another one here... When running it in Vice it goes into grey screen
and gives cpu jam. If I run it on the real c64 and on ccs it works
fine."
 
A: It crashes on my C64C, just like in Hoxs64 and VICE. This suggests an inaccuracy
exists in CCS64 because it SHOULDN'T work.
 
- [vice 1.21] Relax #03  http://noname.c64.org/csdb/release/?id=20394
 
"Switch off true drive emulation in order to have it working in Vice."
 
Relax #3 often crashes, but randomly works.
I don't understand why it should work, and actually it should NEVER work IMHO.
The irq init is completely f**ked up, and prone to lock-ups or crashes.
081E  00        BRK        ;here some stuff is missing:
081F  00        BRK        ;SEI? DCOD/D012 setup?
0820  A9 08    LDA #$08  ;
0822  8D 86 02  STA $0286  ;
0825  20 60 0E  JSR $0E60  ;Only does LDA #$93 JSR $FFD2 RTS
0828  A2 00    LDX #$00  ;
082A  8E 14 03  STX $0314  ;WHY THE F**K ONE WANTS TO DO IT THIS WAY?
082D  8E FF 38  STX $38FF  ;(setting only the lower byte while irq are active
0830  8E FB 09  STX $09FB  ; is plain stupid, is like seeking for crashes)
0833  8E 1A D0  STX $D01A  ;Set to 0 and will be never set to 1 (=no irq?)
 
Even in Hoxs64 1.0.4.24 sometimes locks up.
Works on Vice without TDE active, or simply loading the .prg alone.
I think this is a side effect of inaccurate emulation when TDE is off.
Here's a quick fix, there is enough room for a (almost) correct init.
0805  78        SEI
0806  A9 7F    LDA #$7F
0808  8D 0D DC  STA $DC0D
080B  AD 0D DC  LDA $DC0D
080E  A9 37    LDA #$37
0810  8D 12 D0  STA $D012
0813  A9 1B    LDA #$1B
0815  8D 11 D0  STA $D011
0818  A9 01    LDA #$01
081A  8D 19 D0  STA $D019
081D  8D 1A D0  STA $D01A
 
0825  20 44 E5  JSR $E544
 
0833  2C 1A D0  BIT $D01A
 
unpatched version works in vice1.22
 
- [vice] Dylan Dog/X-factor  http://noname.c64.org/csdb/release/?id=51003
 
"This one crash after the intro in Vice, but no in CCS."
 
A: It crashes on my C64C, just like in Hoxs64 and VICE. This suggests an
inaccuracy exists in CCS64 because it SHOULDN'T work.
 
Rubi: Cannot reproduce. Works perfectly in 1.22. Is this bad as it should fail
just like on a C64C?
 
GPZ: on my c64 it hangs randomly, either right at the beginning, or after
    pressing space in the crack intro, or after the trainer screen
 
nojoopa: Got it to hang (after pressing space) by loading manually. Seems like
        a case of "autostart has lucky timing".
 
"Here's what I found debugging DylanDog/X-Factor.
IRQs are not properly stopped when intro starts, and while calling music init
at $E000 an irq triggers using vector at $FFFE (which points at $F000, hence
the crash)
 
to fix, before running:
 
break 2800
x
 
and then the usual missing one:
 
> dc0d 7f
x
 
and intro starts.
Too bad that even the end sequence loading will lead to a crash.
It should do a jsr $1031 to set $01 and other stuff before but doesn't.
 
fix:
 
break 1029
x
 
now press 4 keys N-I-C-O together, release and press LeftShift+Q
 
> 01 36
x
 
to make it load."
 
 
==============================================================================
WORKING PROGRAMS - EMULATOR ISSUES THAT HAVE BEEN FIXED
==============================================================================
listed here to prevent duplicated reports, and to document what issues have been
fixed in which emulator versions
 
- [vice] Skate Crazy/Shining 8  http://noname.c64.org/csdb/release/?id=37001
 
"Heres another weird one where part 2 crashes, but if I run it on CCS
then it works fine. I havnt tested on the real c64 yet, but I guess
they work there without problems."
 
"It randomly works in VICE v1.21, the problem is due to an incorrectly initialized IRQ."
 
second part crashes in vice, works in ccs
 
A: It's already fixed, works in VICE v1.21.
 
"I noticed that *randomly works* on all 3 emulators, just wait some seconds before
running and it will eventually work. It's a problem of this release only, a simple
lda #$7f sta $dc0d, that SHOULD be there to properly init the irq, will fix it.
 
load but don't run, enter monitor
break 819
x
then after run:
> dc0d 7f
x
will work.
 
Part one properly sets $dc0d in the intro and seems enough."
 
"Ah now I see that it randomly refuses to work, also in Hoxs64. "
 
- [CCS] Darwin/The Dreams  http://noname.c64.org/csdb/release/?id=12732
 
"This demo won't run with CCS as it cannot handle DreamLoad's ShutUp-Feature. Then, I don't
think any emu up to now can play the digi-part in original quality."
 
"A: The demo works in CCS64 v3.3, so it must have been fixed at some point."
 
Hoxs64 v1.0.4.24 has been released, it can now handle the following titles:
 
-Aurora 90% ($01 fading corrected, passes the emu check, there's no need to press run/stop
to proceed at the beginning anymore)
-Locomotion/Hitmen (IRQ timing adjusted, works now)
-Demo IV (it doesn't crash anymore and flickers in the same manner my C64C does)
 
*** [vice] Latch X and Y ($d013 and $d014) are not emulated properly
Rubi: fixed in 1.22.2
 
"I tested this by repeatedly printing their read values on the screen by every frame,
alongside the values stored in $dc00 and $dc01 - as I wanted to test this after seeing
a very nice raster stable routine in an old Crest demo.
 
On Vice, when you press and hold the space bar or any of the keys in the bottom row,
the values in $d013 and $d014 only change once, where as on CCS64 and a REAL c64,
they change every frame - which is of course what they SHOULD be doing on Vice.
 
The stable routine by the way, was found in the mega split-raster part in Blow Job 5/Crest,
i'm not too sure if it was either Crossbow or Vision who coded the routine.
 
loop:
 
LDA $DC00  ; Keyboard write/Joyport 1
STA $0400  ;
 
LDA $DC01  ; Keyboard read/Joyport 2
STA $0401  ;
 
LDA $D013  ; Latch X
STA $0403  ;
 
LDA $D014  ; Latch Y
STA $0404
 
JMP loop
 
Doesn't matter how IRQ is setup etc. The effect relies on when you press various bottom row
keys or hit fire button in Joyport 1. Try it on Vice and then the real machine and you'll
see the difference."
 
*** [Vice 1.20+] Elven warrior: during game does not display in PAL. Works in NTSC mode.
Rubi:Fixed in 1.22.2
 
"It's one of the bugs I noticed in Hoxs64 too, and David fixed it promply few days after,
like every bug reports I sent him from version 1.0.4.16 :)"
 
Elven Warrior + by Doughnut Cracking Service  http://noname.c64.org/csdb/release/?id=30269
Elven Warrior +6 by Ikari, Talent  http://noname.c64.org/csdb/release/?id=17184
Any will do, even the original tape  http://tapes.c64.no/tapes/ElvenWarrior.zip
 
"Bug confirmed (related to DEN bit handling), not yet fixed, more investigation will follow"
 
*** [vice 1.21] sprite fetches in border (9th sprite on a line) is not emulated
Rubi:Fixed in 1.22
 
Krestage 3 - More Weird Stuff/Crest  http://noname.c64.org/csdb/release/?id=48577
 
"Will work in 1.22 (25/50 pixel sprites and "9 sprites on a row" are emulated now)"
 
*** [vice 1.21] 50 pixel wide sprites not emulated
Rubi:Fixed in 1.22
 
Krestage 3 - More Weird Stuff/Crest  http://noname.c64.org/csdb/release/?id=48577
 
"Will work in 1.22 (25/50 pixel sprites and "9 sprites on a row" are emulated now)"
 
*** [vice] at a JAM instruction the emulator halts immediatly and does not update the screen properly
Rubi: WinVice-1.22.3 offers an option to continue without resetting the machine
or entering the monitor.
 
-  Info Everybody  http://noname.c64.org/csdb/release/?id=51177
 
- [vice 1.22] Borderless/The Dreams http://noname.c64.org/csdb/release/?id=16121
Rubi: Both fixed in 1.22.3
 
Works in earlier version and all the others. In 1.22 only a light blue screen.
Changing VIC-II settings/border doesn't produce differences.
The notefile works in normal and full borders mode, not in debug mode.
 
- [vice 1.22] Demode/Chorus http://noname.c64.org/csdb/release/?id=15101
Rubi: Fixed in 1.22.3
 
"4th part, works only with normal borders.
With full borders you read "HE POP inside", few pixels only instead of letter T
With debug borders you read "POP inside", few pixels only instead of THE"
 
- [vice] bubble tale/crest  http://noname.c64.org/csdb/release/?id=3098
Rubi: Fixed in 1.22.3 (both the border size issue and the bug in the "stretch routine")
 
"When I watched the part "undulation" (can be accessed via the shortcut and press fire,
and then load undulation from the good old Crest demo, the Bubble Tale
 
I noticed that with the Vic II border set to Debug. It looks like crap. the sprites
are bouncing of the rasterbar and everything is fucked.
 
with the Vic Ii border set to full, it is a bit more close to the original but there
is a bug in the stretch routine which was not even there in vice 1.21 or displayed
in c64."
 
"abo: The new VICII border modes were introduced by Krill but he oversaw that the borderwidth
variable is used for some essetial calculation which needs to be fixed."
 
- [Vice 1.22] +H2K/Plush http://noname.c64.org/csdb/release/?id=11755
Rubi: Fixed in 1.22.2. The 1541-II ROM is needed to be used to avoid the "endscroller crash".
 
"Choose "Chessboard spin" in part requester, the anticlockwise wipe effect shows some dirty lines.
 
I have to add that the endscroller crashes just after the last japanese text. In Hoxs64 continues correctly."
 
- [vice 1.20,CCS] Aurora 90%/Level64  http://noname.c64.org/csdb/release/?id=41457
Rubi: Fixed in 1.22.2
 
"On emus, there will appear a strangely-patterned screen. Get yourself the real
thing or expect major vic-bugs after pressing run/stop."
 
"btw, aurora80% displays same on emu then on realthing, i just did that emucheck
for the fun of it, its temperature measuring via unused bits in $01"
 
"A: This one's interesting. First of all, in both the 85% and the 90% versions,
I've spotted no VIC bugs - neither in VICE nor in Hoxs64. Secondly, that strangely
patterned screen is visible on a C64 as well, but it disappears after a while. In
emus, a user interaction is required to proceed, and this seems to be the only
difference. This affects CCS64, VICE"
 
(Works in Hoxs64 v1.0.4.24+)
 
- [vice] Camel Park/Camelot http://noname.c64.org/csdb/release/?id=11652
Rubi: Fixed in 1.22.2.
 
"Not really a goof but the FLI picture by Rob'93 part flickers in VICE."
 
- [vice 1.22] So-phisticated/I.C.E. Squad  http://noname.c64.org/csdb/release/?id=930
Rubi: Fixed in 1.22.6
"in vice 1.21 it wont work properly, but hurray, CCS provides the needed c64 bugs to view these pictures."
 
"Bug confirmed (related to CIA timer handling and maybe more...), many more investigation needed..."
 
- [vice,hoxs] Tsunami/Booze Designs  http://noname.c64.org/csdb/release/?id=17913
Rubi: Fixed in 1.22.3
 
"The interlaced girl in the demo Tsunami features 8 bad pixels on her nose when running on
VICE (as HCL stated in the note IIRC)"
 
"Well spotted, the glitch is visible in Hoxs64 too. CCS64 v3.3 isn't affected by this."
 
"abo: Problem is identified, patch needs further investigation"
 
*** [vice 1.21] Sprites in left border are positioned wrong in NTSC mode
Rubi: Fixed in 1.22.6
 
examples:
Nostalgia Intro  http://cosine.org.uk/n0s/games/183_ArcticFox_1986_EOA.d64.zip
 
"One more thing : The $d010 emulation in vice ntsc mode bugs.
 
Try watching my intros in vice ntsc mode:
 
http://intros.c64.org/inc_download.php?iid=2803
http://intros.c64.org/inc_download.php?iid=2047
http://noname.c64.org/csdb/release/download.php?id=56326
 
Left side siderborder sprites are off 8 pixels
They work fine on a real ntsc .."
 
- TRC+TBI Intro: Fixed in 1.22.3
- Trilight: Graphic glitch fixed in 1.22.5
- Volume slider problem: Fixed in 1.22.5
 
*** [vice 1.21] truedrive emulation auto toggle problems (fixed in vice 2.2)
 
- truedrive emulation is switched off/on automatically when the emulator auto-
runs d64s, this causes problems (drivecode not beeing initialised properly
for example) sometimes.
- some plain .prg files do not run when autostarted with the emulator. they DO
run however if you put them into a d64 first.
- t64 files seem to have similar problems as prg
 
- [vice] Enforcer+4M-Enigma  http://noname.c64.org/csdb/release/?id=51004
Rubi: Confirmed.
nojoopa: Works on x64 & x64sc 2.2.1-ish, maybe on 2.2 already.
 
"Found another one that doesnt work. When you press fire at the intro
and it loads level 1 then it crash. It doesnt even scan in CCS, but
works perfect on the real C64."
 
loading endsequence works
 
A: It works on the real thing, in Hoxs64, and contrary to the statement above,
CCS64. Crashes on loading the first level in VICE.
 
- [vice 1.20] Locomotion +2/Hitmen  http://noname.c64.org/csdb/release/?id=23897
 
"Simple bug in the code: change the code at $4d33 from jmp $8000 to jmp $7fe0
while showing the trainer screen. It does work on the real machine, but it is a
bug (changing irq settings with irq enabled, thus firing a raster irq that is never
acknowledged). The proper init code is there, it's just not executed."
 
"A: works on the C64 (at least all of the attempts to run the game were successful)."
 
(Works in Hoxs64 v1.0.4.24+)
 
nojoopa: Works on x64 & x64sc 2.2.1-ish, maybe on 2.2 already.
 
==============================================================================
WORKING PROGRAMS - FALSE ALARM! SOMEONE FUCKED IT UP! =)
==============================================================================
 
- [vice, ccs] Crazy News Preview  http://noname.c64.org/csdb/release/index.php?id=23799
 
crashes/hangs after selecting something in the main menu of the game (start loading, drive
hangs at track 25)
 
"does not work on CCS nor Vice - works on the real thing"
 
"I can only wonder how it was verified to work on the real thing. In order to make it work
in CCS/VICE, make use of the hint in the directory, which says: "rest on side two". Amazingly,
the rest is on the side B on the real thing too. ;D"
 
*** [vice 1.21] strange issues with $01
 
seems that switching $01 quickly makes VICE make mistakes in thinking what is RAM and what is ROM...
Interestingly, this one fucks up in WinVICE v1.20 at max. speed and warp mode, but not @ 100% speed.
Brings up (a seemingly long-time known bug) that toggling RAM/ROM quickly (init tune at $E000) confuses VICE.
 
Zax-Ripp #006/Hurricane  http://noname.c64.org/csdb/release/?id=44749
 
"A: I cannot reproduce it. The warp mode is turned on, the maximum speed is there, it just doesn't
fuck up - neither in the interpolating SID sampling mode (at 800% speed), nor in the fast sampling one (3200%)."
 
- [vice] Non Plus Ultra 64%/Singular http://noname.c64.org/csdb/release/?id=32442
 
"A: Rule of thumb #3: "switch virtual device traps off"."
 
- [vice, ccs] Brave/Laxity  http://noname.c64.org/csdb/release/?id=51006
Rubi: Tested with 1.22. Work for me too.
 
"when Im running this in Vice (and it got the same problem in
CCS) then I get to the game intro and press fire - nothing happends.
When I run it on my real C64 then it works perfectly. It might be
something about the way they fade out the sound - Im not sure just a
wild guess."
 
mmmh works for me in vice 1.20
 
- [vice] Lethal Bombs/Vision  http://noname.c64.org/csdb/release/?id=30118
Rubi: Tested with 1.22. Work for me too.
 
"when Im running this in Vice it gives CPU jam. when I
got through trainerscreens and intros - then it loads and gives CPU
JAM. If I run it on my real C64 it got no problems and my friend tried
it in Vice 1.15 and it works. I tried that too, but no luck."
 
mmmh works for me in vice 1.20
 
- [vice] Paradox [NTSC]/Shade  http://noname.c64.org/csdb/release/?id=35918
 
"Horribly broken in Vice unless you load the pages manually"
can't press space in first part
 
nojoopa: confirmed, Space still doesn't work.
rubi: it does not work in ccs64 either
 
gpz: the code implies that "press space" was intentionally disabled. (maybe
this is a half finished release, or they didnt make it in time, or who knows =P)
 
putting a watchpoint on dc01 reveals that the code to detect space has been
NOPed out:
 
first part:
.C:5108  AD 01 DC  LDA $DC01
.C:510b  C9 EF      CMP #$EF
.C:510d  EA        NOP
.C:510e  EA        NOP
 
second part:
.C:5201  AD 01 DC  LDA $DC01
.C:5204  C9 EF      CMP #$EF
.C:5206  EA        NOP
.C:5207  EA        NOP
.C:5208  EA        NOP
.C:5209  EA        NOP
.C:520a  EA        NOP
 
third part:
.C:5115  AD 01 DC  LDA $DC01
.C:5118  C9 EF      CMP #$EF
.C:511a  EA        NOP
.C:511b  EA        NOP
</pre>

Latest revision as of 02:31, 3 July 2012

Rendering

  • check and maybe also make chip specific: "AspectRatio", "TrueAspectRatio", "KeepAspectRatio"

call tree

normal rendering call sequence:

  • video/video-canvas.c:video_canvas_render
    • video/video-render.c:video_render_main (renderer main)

YUV rendering call sequence:

  • video/video-render.c:render_yuv_image (yuv renderer main)

switching from/to fullscreen (alt-d):

  • video/video-resources:set_fullscreen_enabled
    • video_chip_cap->fullscreen.enable (arch/unix/x11/fullscreen.c:fullscreen_enable)
      • arch/unix/x11/xrandr.c:xrandr_enable
        • set_xrandr
          • FIXME: grab/ungrab mouse pointer
        • arch/unix/x11/gnome/x11ui.c:x11ui_fullscreen
    • video_chip_cap->fullscreen.statusbar (arch/unix/x11/fullscreen.c:fullscreen_statusbar)

setup: video_chip_cap set in:

  • arch/unix/x11/fullscreen.c:fullscreen_capability