Hi, the only demo of that serie that does not work is TRC+TBI Intro 10:
TRC+TBI Intro 10 - https://csdb.dk/release/index.php?id=54242

About this issue I have read this on the web:
_strange... remove the music (jsr$1003) and it works... seems to be a $d011&$80 problem... Seems waiting for the rasterline happens with bit 7 set on the emulator... and that line has been already passed by the music..._
VIC fixes. TRC-TBI intro demo displays. Fixed the VIC LP IRQ response to the keyboard.
...from Hoxs64 History
Is this the solution for the issue ?
strange... remove the music (jsr$1003) and it works... seems to be a $d011&$80 problem... Seems waiting for the rasterline happens with bit 7 set on the emulator... and that line has been already passed by the music...
This is from here I guess:
https://www.lemon64.com/forum/viewtopic.php?t=26100
As far as I know, the CCS source code is not available.
VIC fixes. TRC-TBI intro demo displays.
This is from the Hoxs64 1.0.5.0 release notes. Fortunately, the Hoxs64 source code is on Github. If we knew which exact check-in fixed the issue, we could pretty much narrow it down.
@davidhorrocks ...help please...!
Although a little bit off topic: I've updated the website today: http://www.dirkwhoffmann.de/software/index.html
This demo does not work for me too
@dirkwhoffmann
I cannot recall which specific issue I had to fix as it was before I moved to a source control repo. It might be worth checking these points below.
1) The VIC raster comparison (rasterIrqLine) and current raster line / yCounter are both 9 bits values. The raster IRQ comparison should be an 9 bit comparison. Writes to bit 7 of $D011 will write to bit 8 of rasterIrqLine. Reads of bit 7 of $D011 will read bit 8 of yCounter. The sprite Y match should remain as an 8 bit comparison with the lower 8 bits of yCounter.
2) If a write to D012 or bit 7 of D011 changes the rasterIrqLine value then edge trigger a raster match IRQ is allowed with a 1 clock lag. The reason for the 1 clock delay could be because the CPU writes very late in the 02 phase and the VIC makes its raster comparison check early in the 02 phase, but I am not sure. For example, a write in cycle 63 of PAL line 2 will affect raster IRQ matching at the start of cycle 1 of line 3. You cannot abort a yCounter match that was due to happen at the start of cycle 1 of line 2 by writing to rasterIrqLine in cycle 1 of line 2. Keep in mind that line 0, cycle 1 is special because yCounter will still be the max line value (0x137 for PAL).
3) About CPU IRQs generally: One curious effect not needed by TRC-TBI is that when an IRQ condition is cleared by write to VIC D019 or a read from CIA Dx0D it is as though IRQ line takes one extra clock to float high than it would take to force CPU IRQ line low by a CPU to chip r/w access.
@davidhorrocks
David, thanks a lot for your hints! It's been a while since I worked on VirtualC64, so I'm not familiar with all the details anymore. But the second point might be a smoking gun. At the moment I'm busy finishing up my new Amiga emulator, so it will take a while before I can address these bugs in detail. But when the time comes, your hints will be of great value to me.
Hoxs64 is great by the way. It has excellent compatibility and the source code is much more readable than VICE鈥檚. I have been looking very closely at the CIA implementation some time ago and was able to fix many bugs in VirtualC64 by reviewing what your emulator does in certain situations.
Hi, any news ?
Hi, any news ?
@Haroldo64 No, sorry, nothing new so far. Priority number 1 is releasing vAmiga 1.0. Priority number 2 is to add test automation support to VirtualC64 (which is long overdue).
Good news. Runs fine in (yet unreleased) v4.1. Most likely a duplicate of #547.
v4.1 is now online.
Most helpful comment
Although a little bit off topic: I've updated the website today: http://www.dirkwhoffmann.de/software/index.html