05948: c64, c64p and clones: Severe graphic issues/wrong sync with raster effects

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05948	Graphics	Major	Always	Jun 1, 2015, 14:24	Aug 20, 2015, 11:02

Tester	Mamesick	View Status	Public	Platform	MESS (Official Binary)
Assigned To		Resolution	Open	OS	Windows Vista/7/8 (64-bit)
Status [?]	Confirmed			Driver	commodore/c64.cpp
Version	0.162	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	05948: c64, c64p and clones: Severe graphic issues/wrong sync with raster effects
Description	There are big graphics issues caused probably by wrong timings and syncronizations between 6510 and VIC-II. It's easy noticeable in a lot of crack intros where raster interrupt effect are abused. Just look at the 3532/TRIANGLE intro in MAME and in VICE emulator.
Steps To Reproduce	Load the attached .D64 image and then LOAD"*",8,1. Wait a while and have a look.
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	c64, c64p and clones

Attached Files	0001.png (1,810 bytes) Jun 1, 2015, 14:24 Uploaded by Mamesick C64 PAL MESS
	53583.png (1,256 bytes) Jun 1, 2015, 14:24 Uploaded by Mamesick C64 PAL VICE
	Creatures.zip (150,370 bytes) Jun 1, 2015, 14:51 Uploaded by Mamesick Unzip it first

No.11710 Mamesick Senior Tester Jun 3, 2015, 13:06	I think after a quick look at MOS6566.C file, that the problem lies in line 1436 and 2005 where the following condition is never reached: if ((cpu_cycles == vic_cycles) && (m_rdy_cycles > 0)) It's never reached because MOS6510 CPU CYCLES are 64, VIC-II CYCLES (MOS6566, 6569 etc.) are 63.
No.11979 robiza Developer Aug 20, 2015, 11:02 edited on: Aug 20, 2015, 11:40	The problema is 6502 emulation. It's necessary to implement RDY signal in the core. RDY stop every read operation from the bus. When RDY will be present, the vic ii implementation could be modified to handle the RDY signal. Frodo source: // Set BA low #define SetBALow \ if (!the_cpu->BALow) { \ first_ba_cycle = the_c64->CycleCounter; \ the_cpu->BALow = true; \ <------------------------------------------ send RDY signal to CPU } Mess source: inline void mos6566_device::set_ba(int state) { if (m_ba != state) { m_ba = state; <------------------------------------------ don't send RDY signal to CPU if (m_ba) { m_aec_delay = 0xff; } } }

No.11710

Mamesick

Senior Tester

Jun 3, 2015, 13:06

I think after a quick look at MOS6566.C file, that the problem lies in line 1436 and 2005 where the following condition is never reached:

if ((cpu_cycles == vic_cycles) && (m_rdy_cycles > 0))

It's never reached because MOS6510 CPU CYCLES are 64, VIC-II CYCLES (MOS6566, 6569 etc.) are 63.

No.11979

robiza

Developer

Aug 20, 2015, 11:02

edited on: Aug 20, 2015, 11:40

The problema is 6502 emulation. It's necessary to implement RDY signal in the core. RDY stop every read operation from the bus.

When RDY will be present, the vic ii implementation could be modified to handle the RDY signal.

Frodo source:
// Set BA low
#define SetBALow \
if (!the_cpu->BALow) { \
first_ba_cycle = the_c64->CycleCounter; \
the_cpu->BALow = true; \ <------------------------------------------ send RDY signal to CPU
}

Mess source:
inline void mos6566_device::set_ba(int state)
{
if (m_ba != state)
{
m_ba = state; <------------------------------------------ don't send RDY signal to CPU

if (m_ba)
{
m_aec_delay = 0xff;
}
}
}