It is currently Sun Nov 19, 2017 3:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Wed Aug 16, 2017 6:04 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
krzysiobal wrote:
I've just added mapper63 definition to FCEUX in the way I described it and all games works, so maybe your mapper 63 in nestopia is invalid.
Image Image Image Image

BTW. It's first time I add mapper in FCEUX and I am not familiar with this SDK, for example I don't know how to add CHR-RAM protection.

Quote:
Krzysiobal: I suspect that this cart uses A0 in the reset detection circuit...


I just think that the diode is to make quick discharge of capacitor after power switch.



I think refactoring mapper 63(nestopia),thank you !


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 6:13 pm 
Offline

Joined: Tue Aug 15, 2017 1:07 pm
Posts: 16
lidnariq wrote:
krzysiobal wrote:
Maybe LS series (74LS174) does not have clamp diodes or maybe not to risk high current flow over internal chip protecting diodes (it's electrolite cap so it can store quite lot of energy).
Well, then, why is it electrolytic? There's no need for the >1ms time constant if it's just to make sure that the pin is low on first power-up.

... Actually, though, the right answer is to just ask flaviocaste whether the multicart goes back to the menu when he hits the reset button.


Unfortunately I do not have the console, as I remember, at 25 years ago the reset returned in the selection menu, so I understand I need a new mapper to run all the games?

Ps. If you are interested, in the end I can send the cartridge so that they can test it.

Thanks.


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 6:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
Well, if you'd rather, you could just check for continuity on the other pins. I strongly suspect A0 connects to one side of the diode.

But I think I'm comfortable with "memory of going back to the menu on reset AND presence of diode-capacitor AND no connection to M2 implies reset detection circuit on A0"


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 7:02 pm 
Offline

Joined: Tue Aug 15, 2017 1:07 pm
Posts: 16
lidnariq wrote:
Well, if you'd rather, you could just check for continuity on the other pins. I strongly suspect A0 connects to one side of the diode.

But I think I'm comfortable with "memory of going back to the menu on reset AND presence of diode-capacitor AND no connection to M2 implies reset detection circuit on A0"


The only points that have connection to the diode are the two small ICs (red dots)

Attachment:
IMG-20170816-WA0044.jpg
IMG-20170816-WA0044.jpg [ 114.42 KiB | Viewed 577 times ]


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 7:13 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
merge code,now mapper 63,working two pcb.
todo test;


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 8:09 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
flaviocaste wrote:
The only points that have connection to the diode are the two small ICs (red dots)
Uh.
What.
Not to any of the large ICs?

What does the other side of the diode connect to?


Top
 Profile  
 
PostPosted: Thu Aug 17, 2017 12:56 am 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
Mapper is very similar, but different

1.PRG logic same.
2.mirr logic different.(hardware runing Some games mirr are not correct)
3.menu logic different.
4.prg mask different.(0x7F or 0xFF)

Can be combined into a MAPPER, of course, if some precision, is defined as MAPPER 63.1


Top
 Profile  
 
PostPosted: Thu Aug 17, 2017 9:19 am 
Offline

Joined: Tue Aug 15, 2017 1:07 pm
Posts: 16
lidnariq wrote:
flaviocaste wrote:
The only points that have connection to the diode are the two small ICs (red dots)
Uh.
What.
Not to any of the large ICs?

What does the other side of the diode connect to?


Yes, I tested the connection with all the pins on the board


Top
 Profile  
 
PostPosted: Thu Aug 17, 2017 1:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
Anyway, the correct place to put this code in FCEUX is as part of addrlatch.cpp. Perhaps:
Code:
//-------------- NCN-82 -----------------------

static void NCN82Sync(void) {
        setchr8(0);
        if (latche & 2) {
                setprg32(0x8000, latche >> 3);
        } else {
                setprg16(0x8000, latche >> 2);
                setprg16(0xC000, latche >> 2);
        }
        setmirror((latche & 1) ^ 1);
}

void Mapper63_Init(CartInfo *info) {
        Latch_Init(info, NCN82Sync, NULL,
                   0x0000, // initial value of latch
                   0x8000, 0xFFFF, // range of latch
                   0); // whether prg-ram provided
}
Plus a little help in ines.cpp.

FCEUX has no implementations of submappers yet; it looks like the Whatever_Init routine has to inspect the CartInfo structure to decide how to initialize the board.

FCEUX also doesn't seem to have any way to write-protect CHR-RAM either; the best it has is the PPUCHRRAM 8-bit bitmask which specifies whether any given 1024 B CHR bank is writeable or not. It's not directly addressable; instead the setchr8r(r,A,V) function consults the CHRram array to determine whether any given IC is always RAM (and writeable) or always ROM. If this matters, we'll either have to add new "setchrNx" functions to support the abstraction or break the abstraction with something like this:
Code:
        if (CHRram[r] && (latche & 0x200)==0)
                PPUCHRRAM = 255;
        else
                PPUCHRRAM = 0;




I see now that the $F01A and $F01B banking writes are slightly trollish. "04 SUPER MARIO" and "74 FANCY MARIO" are the same PRG and CHR, just with different nametable layout. I don't suppose flaviocaste remembers whether the last nine games on the cart were "real"?


Top
 Profile  
 
PostPosted: Thu Aug 17, 2017 2:09 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
Quote:
Anyway, the correct place to put this code in FCEUX is as part of addrlatch.cpp. Perhaps:

and the `addrlatch` with 0x1FF to clear the CHR-write protection bit.

Quote:
FCEUX has no implementations of submappers yet; it looks like the Whatever_Init routine has to inspect the CartInfo structure to decide how to initialize the board.

Maybe that's how it was supposed to work. Anyway, don't forget to set amount of CHRRAM in ines 2.0 header, otherwise FCEUX crashes during quitting.


Top
 Profile  
 
PostPosted: Thu Aug 17, 2017 3:08 pm 
Offline

Joined: Tue Aug 15, 2017 1:07 pm
Posts: 16
lidnariq wrote:
Anyway, the correct place to put this code in FCEUX is as part of addrlatch.cpp. Perhaps:
Code:
//-------------- NCN-82 -----------------------

static void NCN82Sync(void) {
        setchr8(0);
        if (latche & 2) {
                setprg32(0x8000, latche >> 3);
        } else {
                setprg16(0x8000, latche >> 2);
                setprg16(0xC000, latche >> 2);
        }
        setmirror((latche & 1) ^ 1);
}

void Mapper63_Init(CartInfo *info) {
        Latch_Init(info, NCN82Sync, NULL,
                   0x0000, // initial value of latch
                   0x8000, 0xFFFF, // range of latch
                   0); // whether prg-ram provided
}
Plus a little help in ines.cpp.

FCEUX has no implementations of submappers yet; it looks like the Whatever_Init routine has to inspect the CartInfo structure to decide how to initialize the board.

FCEUX also doesn't seem to have any way to write-protect CHR-RAM either; the best it has is the PPUCHRRAM 8-bit bitmask which specifies whether any given 1024 B CHR bank is writeable or not. It's not directly addressable; instead the setchr8r(r,A,V) function consults the CHRram array to determine whether any given IC is always RAM (and writeable) or always ROM. If this matters, we'll either have to add new "setchrNx" functions to support the abstraction or break the abstraction with something like this:
Code:
        if (CHRram[r] && (latche & 0x200)==0)
                PPUCHRRAM = 255;
        else
                PPUCHRRAM = 0;




I see now that the $F01A and $F01B banking writes are slightly trollish. "04 SUPER MARIO" and "74 FANCY MARIO" are the same PRG and CHR, just with different nametable layout. I don't suppose flaviocaste remembers whether the last nine games on the cart were "real"?


I really do not remember this detail, about the above information, I do not understand the technical terms, do I need to do something else to run it well or just wait for a new version of FCEUX? Today I tested the rom in the Recalbox for raspberryPI3 and it did not work, there appeared a white screen, I changed the emulation core and run most games, except those that were reported here.

Attachment:
1503008523124959132552.jpg
1503008523124959132552.jpg [ 3.07 MiB | Viewed 449 times ]



Thanks.


Top
 Profile  
 
PostPosted: Fri Aug 18, 2017 1:04 am 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
nestopia working this rom! and other pcb rom.


Top
 Profile  
 
PostPosted: Fri Aug 18, 2017 6:55 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
For reference, what is the filename of the other Mapper 63 cart?


Top
 Profile  
 
PostPosted: Fri Aug 18, 2017 7:38 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
lidnariq wrote:
For reference, what is the filename of the other Mapper 63 cart?

255-in-1 (as)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Tomy and 8 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