Previous Thread
Next Thread
Print Thread
Page 125 of 528 1 2 123 124 125 126 127 527 528
Re: SVN builds - new driver flood [Re: Anna Wu] #59182 02/17/10 08:33 AM
Joined: Aug 2004
Posts: 1,383
Robbbert Offline
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,383
same with kayproii, i suspect it is to do with the new pio code, as its the only thing that has changed recently. I haven't had time to investigate though.

edit: Micko fixed the crash, and I've fixed the pio interface, but it still doesn't boot. Looks very much like a bug in the new pio. Still investigating...

Last edited by robbbert; 02/17/10 11:07 AM.
Re: SVN builds - new driver flood [Re: Robbbert] #59188 02/17/10 11:56 AM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
This is probably the reason, disk drive motor not emulated.

static WRITE8_DEVICE_HANDLER( pio_system_w )
{
/* d7 bank select
d6 disk drive motors - not emulated (0=on)

Re: SVN builds - new driver flood [Re: Curt Coder] #59189 02/17/10 12:12 PM
Joined: Aug 2004
Posts: 1,383
Robbbert Offline
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,383
The issue is that the system rom needs to be selected by having the system pio port A bit 7 high to enable the bios. The bios uses port A as a 1-byte register and just flips or adjust whatever bits need to be changed. However this new implementation sets the bits low (port->output = 0), disabling the bios.

I can enable the bios in the machine reset, but this doesn't set the port->output variable. So, at some stage the bios reads the port, gets 0, does what it needs to do, and outputs the modified value. So, the bios is now disabled causing an instant crash in the emulated machine.

edit: added the motor emulation is case it is needed

edit 2: the initial state of the machine is determined by pullup resistors on port A. Perhaps the initial value in the pio register is determined by this. Whatever, i don't believe there is anything more i can do unless i change the pio code.

Last edited by robbbert; 02/17/10 12:28 PM.
Re: SVN builds - new driver flood [Re: Anna Wu] #59190 02/17/10 01:37 PM
Joined: Jul 2007
Posts: 4,625
A
Anna Wu Offline OP
Very Senior Member
OP Offline
Very Senior Member
A
Joined: Jul 2007
Posts: 4,625
Yes, the crash is now fixed. smile
Only the solution to boot disks is missing at moment.

Re: SVN builds - new driver flood [Re: Anna Wu] #59192 02/17/10 01:42 PM
Joined: May 2004
Posts: 1,592
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,592
maybe you could clarify what the megatouch games are/were doing wrong?

sweeping statements like the one made about the megatouch use of the PIO don't actually help anybody fix the driver, for what reason are you sure it's a bug in the driver, and not a bug in your new code? 'because this is what the documentation says' doesn't mean there can't be subtle undocumented behaviors.

I'm not trying to be difficult, it's a genuine question, I'm just not a fan of people breaking drivers, making no attempt to fix the drivers, or help others fix them, and simply saying the drivers were always broken without giving sound reasoning. Obviously the changes made help some cases here, but are you just swapping one set of problems for another? How much research into what Megatouch needs, and why your new code breaks it did you do? I'd hate to see a case arise where we end up flip-flopping between two sets of code based on what needs fixing in any given week, or worse, having two implementations because things weren't fully researched.

Re: SVN builds - new driver flood [Re: Haze] #59195 02/17/10 01:58 PM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
I suspect Megatouch is broken because the V9938 video chip signals an interrupt on each scanline instead of at vblank when it should. This comment can be found at line 601 in emu/video/v9938.c:

/*
** Somehow the IRQ request is going down without cpu_irq_line () being
** called; because of this Mr. Ghost, Xevious and SD Snatcher don't
** run. As a patch it's called every scanline
*/

I debugged this to death the last time I rewrote the Z80-PIO, and could not come up with a working solution. The V9938 code makes my eyes bleed every time I look at it.

Re: SVN builds - new driver flood [Re: Curt Coder] #59196 02/17/10 02:21 PM
Joined: May 2004
Posts: 1,592
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,592
Originally Posted By Curt Coder
I suspect Megatouch is broken because the V9938 video chip signals an interrupt on each scanline instead of at vblank when it should. This comment can be found at line 601 in emu/video/v9938.c:

/*
** Somehow the IRQ request is going down without cpu_irq_line () being
** called; because of this Mr. Ghost, Xevious and SD Snatcher don't
** run. As a patch it's called every scanline
*/

I debugged this to death the last time I rewrote the Z80-PIO, and could not come up with a working solution. The V9938 code makes my eyes bleed every time I look at it.


Ok.. What are they actually using the PIO stuff for on the system?

Clearly that check_int code gets called every time either the irq related flags change, and for whatever reason, every scanline, and thus can potentially cause a pio write called due to the callback under certain conditions. I'm guessing you think it's spamming the pio with unwanted data due to the excessive calling?

Obviously checking the interrupt state and adjusting it if the register change is correct (although there could be a slight delay between write and effect) I really don't get the scanline kludge tho, I would have thought that it would only have to be rechecked if something related to the interrupt flags, or irq ack happened / the irq was taken.

It's the MSX VDP iirc, and I already question what's going on in the mode7 code that sexyboom etc. use, so I'd be curious to see which MSX games actually work. I wouldn't really want to change any code in there without a comprehensive test suite, hopefully again this is something the fixed software lists can bring. This is of interest to me because I was trying to get to the bottom of the 'missing black card symbols' issue with the mixing of the 2 VDPs, although I imagine that's going to be like Sega System E where the issue isn't obvious unless you have 2 vdps and have to handle transparency in a special way. Anyway that's got nothing to do with this issue, but it does make me question the quality of the vdp code.

It's possible the whole callback hookup with the PIO write in the actual driver is wrong too I guess...

Re: SVN builds - new driver flood [Re: Curt Coder] #59197 02/17/10 02:27 PM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
Ok, I fixed Kaypro II/4 booting.

Problem was that PIO output register can apparently be written even when in input mode.

Another problem was that Kaypro II and 4 have disk side selection polarities switched.

Re: SVN builds - new driver flood [Re: Haze] #59203 02/17/10 04:40 PM
Joined: Feb 2005
Posts: 449
C
Curt Coder Offline
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
Originally Posted By Haze
Ok.. What are they actually using the PIO stuff for on the system?


It is used as an interrupt controller receiving the INT pins from both V9938s. I added logging to demonstrate how fucked up the V9938 interrupt callbacks are:

VINT2 1 y 136 frame 5
VINT2 0 y 155 frame 5
VINT2 1 y 454 frame 5
VINT2 0 y 268 frame 130
VINT2 1 y 454 frame 130
VINT2 0 y 382 frame 255
VINT2 1 y 454 frame 255
VINT2 0 y 16 frame 381
VINT2 1 y 454 frame 381
VINT2 0 y 126 frame 506
VINT2 1 y 454 frame 506
VINT2 0 y 237 frame 631
VINT2 1 y 454 frame 631
VINT2 0 y 347 frame 756
VINT2 1 y 454 frame 756
VINT2 0 y 468 frame 881
VINT2 1 y 454 frame 882

If the Z80 code is expecting a 60 Hz interrupt, this might throw it off a bit.

Re: SVN builds - new driver flood [Re: Curt Coder] #59207 02/17/10 05:56 PM
Joined: Aug 2009
Posts: 8
M
mariuszw Offline
Member
Offline
Member
M
Joined: Aug 2009
Posts: 8
Originally Posted By Curt Coder
Originally Posted By Haze
Ok.. What are they actually using the PIO stuff for on the system?


It is used as an interrupt controller receiving the INT pins from both V9938s. I added logging to demonstrate how fucked up the V9938 interrupt callbacks are:

VINT2 1 y 136 frame 5
VINT2 0 y 155 frame 5
VINT2 1 y 454 frame 5
VINT2 0 y 268 frame 130
...


But this doesn't explain why Megatouch games break with new PIO, V9938 didn't change afterall.

The code in meritm.c was calling PIO port write only when interrupt line has actually changed (line state was cached) and only when it changed to 1 (interrupt active). I don't remember at the moment why I had to put it that way. Maybe just try to remove one of these kludges at a time to see if it fixes anything?

Mariusz.

Page 125 of 528 1 2 123 124 125 126 127 527 528

Who's Online Now
1 registered members (belegdol), 82 guests, and 1 spider.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,682
Posts114,002
Members4,863
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3