Previous Thread
Next Thread
Print Thread
Page 510 of 529 1 2 508 509 510 511 512 528 529
Re: SVN builds - new driver flood [Re: Anna Wu] #113264 04/27/18 08:18 PM
Joined: May 2007
Posts: 548
M
mizapf Offline
Senior Member
Offline
Senior Member
M
Joined: May 2007
Posts: 548
Which release?

Re: SVN builds - new driver flood [Re: mizapf] #113266 04/27/18 09:32 PM
Joined: Apr 2006
Posts: 712
Tafoid Offline
Senior Member
Offline
Senior Member
Joined: Apr 2006
Posts: 712
Did some checking - breaks shortly after 0.172 release
Examining the daily builds, I narrowed it down to TMS9995 changes, very likely this commit on March 30, 2016:
https://github.com/mamedev/mame/commit/a444e30e281eee5a4e0d7c19ec17f7e963442276

Testing is a simple as mounting the cassette then typing "LOAD" then hit F2 to start the tape to load (Anna links example above)
In cases where it doesn't work, the name "BARS" doesn't show up and the load results in an "ERR 18"

Re: SVN builds - new driver flood [Re: Anna Wu] #113268 04/27/18 10:34 PM
Joined: May 2007
Posts: 548
M
mizapf Offline
Senior Member
Offline
Senior Member
M
Joined: May 2007
Posts: 548
I think I fixed it. Try the latest commit.

Re: SVN builds - new driver flood [Re: mizapf] #113269 04/27/18 10:45 PM
Joined: Apr 2006
Posts: 712
Tafoid Offline
Senior Member
Offline
Senior Member
Joined: Apr 2006
Posts: 712
Seems to work now on my end. However, just that change caused the driver to slow down pretty dramatically in testing. Any way to avoid this, even if you aren't using the cassette?

Speeds from my i5-4570 3.2ghz

Today's Binary
[MINGW64] c:\mamegit\mame>mame64 tutor -str 30 -nothrottle -video none
Average speed: 1062.80% (29 seconds)

Driver only compile to test change:
[MINGW64] c:\mamegit\mame>tutor64 tutor -str 30 -nothrottle -video none
Average speed: 834.60% (29 seconds)




Re: SVN builds - new driver flood [Re: Anna Wu] #113270 04/27/18 11:07 PM
Joined: May 2007
Posts: 548
M
mizapf Offline
Senior Member
Offline
Senior Member
M
Joined: May 2007
Posts: 548
What I did was to turn off the auto wait state creation. This means that the CPU is now executing more cycles, so the higher CPU load is an immediate consequence.

I don't have details on the Tutor, so I don't know whether the auto wait states are really deactivated. The issue with the cassette seems to suggest it.

Re: SVN builds - new driver flood [Re: Anna Wu] #113271 04/27/18 11:21 PM
Joined: Mar 2001
Posts: 16,377
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,377
The emulated CPU is doing substantially more work, so that slowdown is expected.

Re: SVN builds - new driver flood [Re: Anna Wu] #113272 04/27/18 11:21 PM
Joined: May 2010
Posts: 82
R
r09 Offline
Member
Offline
Member
R
Joined: May 2010
Posts: 82
I've noticed a regression in the FM Towns driver that has probably been there for a while. I think it was introduced with the RTC58321 implementation (https://github.com/mamedev/mame/com...98#diff-d538be56a05896eacb098d604abb3831) and it seems to be related to the RTC BUSY signal. It basically causes the mouse cursor to have very jerky movement in old versions of TownsOS (1.1 L10 particularly) and in some games (mainly Sierra stuff, King's Quest V for example), to the point of being almost unusable.

If I do this in drivers/fmtowns.cpp so the machine always sees the RTC as ready:

Code
READ8_MEMBER(towns_state::towns_rtc_r)
{
	return 0x80 | m_rtc_d;
}


It seems to fix it, but it feels wrong and it's probably breaking something else, so I thought reporting it on the forums in case someone has a better solution would be more sensible that submitting that.

Re: SVN builds - new driver flood [Re: Anna Wu] #113273 04/28/18 12:14 AM
Joined: Dec 2015
Posts: 106
A
AJR Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2015
Posts: 106
The MSM58321 emulation gives the active-low busy output a 50% duty cycle, which is incredibly inaccurate as its actual duty cycle is about .0427%. I'm fixing that now.

Re: SVN builds - new driver flood [Re: AJR] #113277 04/28/18 10:04 AM
Joined: May 2010
Posts: 82
R
r09 Offline
Member
Offline
Member
R
Joined: May 2010
Posts: 82
Originally Posted by AJR
The MSM58321 emulation gives the active-low busy output a 50% duty cycle, which is incredibly inaccurate as its actual duty cycle is about .0427%. I'm fixing that now.


Thanks for looking into it, but I think that made it even worse, haha. You can easily see it by running "mame fmtowns tss1110", the mouse is even more uncontrollable now.

I'm not really too knowledgeable about this stuff so feel free to call me an idiot, but if the "busy" state is 0 to the RTC... isn't this (in mame/drivers/fmtowns.cpp) actually interpreting it the opposite way? (bit 7 in port 0x70 is supposed to be 1 when the RTC is *not* busy)

Code
WRITE_LINE_MEMBER(towns_state::rtc_busy_w)
{
	m_rtc_busy = state == ASSERT_LINE ? true : false;
}


Code
READ8_MEMBER(towns_state::towns_rtc_r)
{
	return (m_rtc_busy ? 0 : 0x80) | m_rtc_d;
}

Re: SVN builds - new driver flood [Re: r09] #113282 04/28/18 03:13 PM
Joined: Dec 2015
Posts: 106
A
AJR Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2015
Posts: 106
All right, so I've done away with the ASSERT_LINE nonsense as well.

Page 510 of 529 1 2 508 509 510 511 512 528 529

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