It is currently Sat Nov 18, 2017 8:20 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Benico (Asder 20-in-1)
PostPosted: Sat Nov 04, 2017 3:32 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Game number 14 on the Asder 20-in-1 multicart is "Benico", a game that has not been discovered so far in single-cartridge form. While gameplay is emulated fine, during the self-running demo, the game performs a number of writes in the $F000-$F0FF range that throw most emulators off, causing graphical corruption. I can mask them off by excluding the F000-F07E area from the bankswitching emulation code without problems, but I'm wondering: what is the game doing there that it's not doing during actual gameplay?


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 12:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
I would not necessarily assume that the game works correctly on the original multicart hardware...

The mapper hardware (since this isn't documented on the wiki) seems to be:
A~[1PPP PMCC Sp.. .CCC]
P - PRG A18,17,16,15
C - CHR A17,16,15,14,13
M - 1:VRAM A10 = PPU A11 ; 0:=A10
S - 1:PRG A14=p ; 0:=CPU A14

In fact, given this description, I don't see a way that that could work correctly on the original multicart.


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 12:28 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
If that description is correct, that is. I don't know that it is based from actual hardware analysis, as opposed to just figuring out how to make emulation of the ROM image work.

The only YouTube video of the original hardware that I could find unfortunately does not show the game's attract mode.

I still cannot make any sense of what the game is trying to accomplish with those writes.


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 12:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
More or less the only possibilities are:
* Some bits are required to be 1 or 0 for a write to succeed
* Some bits, after having been written to with a 1 or 0, disallow any further writes to all or part of the register

But, seriously, don't overestimate the amount of testing that went into any pirate multicart.


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 12:46 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
It's not a pirate multicart, but a multicart by the original makers of the games. (That NTDEC/Asder pirated other companies' games on other occasions does not make this one a pirate multicart.)


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 12:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
I'm really not certain what you think your point is.

A company that released pirate multicarts releases a multicart of in-house games. Do you think this somehow magically means their testing will have improved?


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 1:04 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Yes, in fact I would think that.

But that was not my original question. My original question was that regardless of whether that individual game works correctly on the multicart hardware or not, the programmers of that individual game intended those F000-F0FF writes made during attract mode to do something, and I cannot figure out what that would be, and that someone might have an idea of what that could be.


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 1:07 pm 
Offline

Joined: Tue Feb 14, 2017 9:50 am
Posts: 38
Maybe krzysiobal has an idea?


Top
 Profile  
 
PostPosted: Sat Nov 04, 2017 2:17 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
The routine that writes to $F000,Y reads from a pointer that usually points to somewhere in $E000. The value that is written is the simulated joypad input during attract mode.

I strongly suspect that the way attract mode was created was they put the game on a RAM cart, and wrote the sequence of button inputs into $F000,Y. For final manufacture, these 128 byte sequences were then moved to other locations in ROM, and the code that read from the controllers was replaced with a playback loop reading from the pointer instead. Since the original game was released as NROM, there was no need to remove the side-effect-less writes to the PRG ROM addresses.


Top
 Profile  
 
PostPosted: Sun Nov 05, 2017 6:39 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Thank-you, that makes sense. Together with krzysiobal's confirmation that the graphic errors occur on real hardware as well, we now know that the previous description of the mapper hardware does not need to be amended.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group