Previous Thread
Next Thread
Print Thread
Page 6 of 15 1 2 4 5 6 7 8 14 15
Re: what? no NES support??!??! [Re: Heretical_One] #51340 07/02/09 11:10 AM
Joined: Apr 2004
Posts: 1,554
J
judge Online Content
Very Senior Member
Online Content
Very Senior Member
J
Joined: Apr 2004
Posts: 1,554
Nice

Re: what? no NES support??!??! [Re: judge] #51342 07/02/09 12:14 PM
Joined: Jan 2006
Posts: 3,687
etabeta78 Offline
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
ditto smile

Re: what? no NES support??!??! [Re: etabeta78] #51388 07/03/09 06:45 AM
Joined: Dec 2005
Posts: 443
Heretical_One Offline
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
You know, I think this all makes sense suddenly.

A somewhat hack-ish solution even has presented itself!

(But I've got stuff that HAS to be done before I wake up on the 4th, so I don't expect to *TRY* it before then)

Here it goes:

1. I think the PPU always handled the banking. I have an old 2081 revision nes_mmc where this occurs. It's actually nothing new.
2. The problem is that whether the PPU has ROM or RAM or neither is decided before the mapper is set.
3. Since removing and reinserting a PPU is clearly stupid, we can't do that.
4. But we could make a mapper reset call a new function limited to the YUV PPU that the NES uses (arcade PPUs are RGB) that would reset the internal PPU state to one that reflects the mapper?

That could get us working again while we await the ability to put the mappers truly in the driver's seat...

Feel free to shoot me down/debate alternatives, but I think I can even extend the concept slightly to fix some long-standing weirdness to the MMC interfaces we have.

Re: what? no NES support??!??! [Re: Heretical_One] #51391 07/03/09 07:11 AM
Joined: Jan 2006
Posts: 3,687
etabeta78 Offline
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
I actually tried to implement something like that, but I had no success (I agree that 4 is the only viable temp solution)

but maybe I was using the wrong PPU functions (my understanding of graphics in MESS is still partial), so if you can make it work be my guest, no matter if tomorrow or in a month. smile

Re: what? no NES support??!??! [Re: etabeta78] #51398 07/03/09 10:57 AM
Joined: Dec 2005
Posts: 443
Heretical_One Offline
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
Well, there's option 5: figure out how to make the current implementation NOT hardwire itself to a memory region on device creation.

E1:
That's the real issue here: MESS has to create the PPU before it does the mapper configuration. AFTER the PPU is created, attempting a rebinding = CRASH.

Does anyone have examples of devices that do major on-the-fly configuration changes?

E2:
Hmmm...

Can someone explain some code (purpose, not function-wise) to me?

function: ppu2c0x_set_videorom_bank
block starting with:
int vram_start = start_page * 0x400;

I can successfully map gfx1 region to the PPU if I comment the whole block out, and I don't *seem* to notice any ill effects in limited testing.

Last edited by Heretical_One; 07/03/09 11:20 AM. Reason: I'm a lyre!
Re: what? no NES support??!??! [Re: Heretical_One] #51405 07/03/09 12:22 PM
Joined: Apr 2004
Posts: 1,554
J
judge Online Content
Very Senior Member
Online Content
Very Senior Member
J
Joined: Apr 2004
Posts: 1,554
I've been wanting to do a rewrite of the ppu moving all the banking out of the ppu code; however I really need to first finish a large 6845 update I'm currently working on.

Re: what? no NES support??!??! [Re: judge] #51413 07/03/09 04:06 PM
Joined: Dec 2005
Posts: 443
Heretical_One Offline
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
Before anyone rewrites the PPU, we should get a sense of whether device-based memory maps are coming smile

It would dramatically cut back the weirdness that would result from trying it now, I think.



That said, it might be necessary to rewrite immediately. I'm just trying to be as minimally invasive as possible for now. Like I said, I've got that block of code that's stopping me from having a "workable" solution for the moment, because I don't know if anything depends on it (but it looks like something that was meant for the scrap heap and never made it to me).


Also, I found some slight errors on one of the mapper fixes already pending, so that it yields a fully working result. (Actually, I just used a second source of information to verify the initial state of the mapper)

Last edited by Heretical_One; 07/03/09 04:42 PM.
Re: what? no NES support??!??! [Re: Heretical_One] #51414 07/03/09 05:06 PM
Joined: Apr 2004
Posts: 1,554
J
judge Online Content
Very Senior Member
Online Content
Very Senior Member
J
Joined: Apr 2004
Posts: 1,554
Well, for device based memory maps you'd still move the mapping behavior out of the ppu to the machine/driver level.

Device-based memory maps won't be added soon it seems.

Re: what? no NES support??!??! [Re: judge] #51422 07/04/09 07:19 AM
Joined: Dec 2005
Posts: 443
Heretical_One Offline
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
If we have to wait for them, then I think we should at least try to get the driver working for now. LIke I've said, I have a brutal hack running locally that restores a large degree of functionality.

Essentially, it comments out one chunk of the PPU banking code (I still can't discern what it might do that the prior blocks don't already do) and recreates most aspects of the device initialization code regarding the PPU chip implementation, while essentially ignoring the fixed "ppu2c0x_interface" (which is a const*)

Hardly ideal, but short of finding a way to eliminate the has_videorom and RAM equivalents, it's about all we have available.

As long as I can reset a bunch of attributes the ppu chip structure uses, everything works, but it's NOT pretty (although I only call the function once in the mapper code)

A better solution long-term is to figure out what code depends on the attributes I reset and fix that code where possible.

THEN we can worry about banking wink

Re: what? no NES support??!??! [Re: Heretical_One] #51609 07/11/09 06:06 AM
Joined: Dec 2005
Posts: 443
Heretical_One Offline
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
Of course, the best solution is if Aaron gives us device memory maps... which he just did smile

To-do list:

1. Move palettes out of nametable RAM. (DONE!)
2. move palette access to memory map (DONE!)
3. get the memory map working (DONE!)
4. move nametables to memory map (DONE!)
5. convert drawing code to use map (DONE!)
6. move pattern tables to memory map (DONE!)
7. convert drawing code to use map
8. move pattern tables to machine-side
9. remove banking code from PPU
10. move nametables to start of PPU RAM
11. right-size PPU RAM
12. move sprite DMA code
13. work with PPU mirroring code (4-screen)
14. fix $4015 to return all bits correctly.

Priorities may not stay in this order. Items 6 through 9 are the "big ones", but without fixing the other stuff, I'll never FIND what I need to make that happen. #12 and #14 are stuff that "could be done" at any time. The PPU need not work for either of those.

Last edited by Heretical_One; 07/11/09 08:59 AM. Reason: update3
Page 6 of 15 1 2 4 5 6 7 8 14 15

Who's Online Now
1 registered members (Carbon), 278 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,734
Posts114,829
Members4,879
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3