It is currently Fri Jan 19, 2018 10:32 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 191 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 13  Next
Author Message
 Post subject:
PostPosted: Sat May 26, 2012 11:42 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
MottZilla, yes.

Bregalad, it was discussed in this thread on few pages - because it is way easier to ignore 2048 bytes with discrete logic (just a single IC) than $17 bytes. Of course, a CPLD or the flag ROM approach may be used to get these extra 2K, but this out of the 'simple stuff' category. And it is generally better to have a single standart than few variants, for compatibility reasons.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 11:53 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
3gengames wrote:
Yeah, the NBASIC made by that college guy and then his class (attempted) game programming with it. Bob Ross rings a bell, probably sounded something like that.

VERY close:
Bob Rost - this is the NES college course teaching guy
Bob Ross - this guy painted happy little trees


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 11:55 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Shiru wrote:
MottZilla, yes.

Bregalad, it was discussed in this thread on few pages - because it is way easier to ignore 2048 bytes with discrete logic (just a single IC) than $17 bytes. Of course, a CPLD or the flag ROM approach may be used to get these extra 2K, but this out of the 'simple stuff' category. And it is generally better to have a single standart than few variants, for compatibility reasons.

Wouldn't it be just as easy to ignore...say...$20 bytes as it is $800?


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 12:15 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Ignoring $20 is more difficult, because it means A15-A5 involved in the decoding rather than A15-A11. 10 lines vs just 5.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 12:52 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7350
Location: Chexbres, VD, Switzerland
This is not a valid argument, as then you can just go with ignoring A0...A12 and use only A13 and A14 to decode $6000-$FFFF. This will be even simpler - 2 lines vs 5

But as long as you expand the memory in a crazy way you'd probably want to expand it as fully as possible, and the very fullest possible is $4018-$FFFF.

I don't like to repeat myself but this is decodable with a single PAL/GAL chip which are cheap and common, just like the 74xxx series. There is NO need for a CPLD or something that complex.
However, it's true you have to program the PAL/GAL chip and this can be a problem for someone with limited acess to material. This doesn't preven them to use less bytes and use another chip - but at least making the "standard" (that will prbably never ever be used anyways) would be to have up to $4018-$FFFF available.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 2:03 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
I compiled a simple test (one of my C examples) with CC65 for the NROM-368 layout, and made a FCEUX modification that runs it. Download.

The test does not test whole address space, but since the code is located in $4800 and vectors are in the top bank, it'll show if this works. A better test could be made easily now, if it will be needed.

Next step is to test the hardware designs, and if they work, make something more serious, to have a reason to put the support into official FCEUX and other emulators.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 2:27 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Shiru wrote:
to have a reason to put the support into official FCEUX and other emulators.


Thanks Shiru. Your example works in my modified NESICIDE...I'll commit the changes and make a Windows build available.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 3:02 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1946
Location: WhereverIparkIt, USA
I've got to fix by bug before I can get your test running Shiru.

For what it's worth Lidnariq's test is more along the lines of what I would suggest for your next rom. It actually shows you what addresses aren't being read properly and verifies that the ROM isn't enabled below $4800 per the current format. It's nice to have easy to interpret feeback on the actual problem vice crashing because you've got some issue and have no idea what it is.

I'm not sure but it also appears to verify the data so I imagine that if you did the decoding improperly but still enabled the ROM at the right address range it'll point out the failure.

EDIT: linariq, is my previous statement actually correct? Does your rom have unique chunks of data that it's verifing at each address? Because if so the problem I'm having is a bit more complex. It would suggest that I'm having a timing issue or something when PRG A12 is the ONLY signal that is activating my address decoder. Because when I implement it improperly with the ROM active from $4000 and above I do get proper data at $5000. I can't think of what would cause this besides a timing issue...

EDIT 2: That last question got me thinking. Normally PRG /CE is an inversion of M2 (phi2) from $8000 to $FFFF. However in my previous code I enabled PRG ROM /CE solely based on the fact that the address was >= $4800, so the result was that the ROM's /CE wouldn't toggle like it's used to as an inversion of m2. It would STAY active anytime PRG A11-15 was high. I need some clarification on how linariq's test actually works, BUT it appears due to timing issues decoding $5000-5800 may not be as simple as one would hope. I decided to change my implementation to the below and I passed linariq's AND shiru's tests with flying colors.

Code:
begin//NROM368
               prg_addr_hi[14] = b_prg_addr[14];
               prg_addr_hi[15] = b_m2 & ~b_prg_ce;
               w_ce = 1'b1;      //wram forbidden
               
               if ( {prg_addr_hi[15], b_prg_addr[14:13], eb_prg_addr[12:11]} >= 5'b01001 )   //PRG address >= $4800
                  //prg /CE enabled
                  p_ce = ~b_m2;  //  broke-> 1'b0;   
               else
                  p_ce = 1'b1;   //prg /CE disabled
            end


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 3:40 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
I can make a better test if you explain what it should do. Honestly I don't really have an idea how you could test that a particular address of ROM is read or not read properly. Like, I can put certain values into existing ROM addresses, but what I have to compare them against? And how can I decide that a value that reads back below $4800 is not from ROM?


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 4:01 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1946
Location: WhereverIparkIt, USA
Well linariq's solution seemed good to me. I'm guessing he incremented the data in ROM or something so that you could compare it to a counter or some sequence of operations.

Atleast now I've got it working in hardware and I'm not searching for the non-existent bug in my hardware. I didn't look heavily over the logic behind the discrete design but based on what I learned it appears you need to ensure that the ROM /CE signal is an inversion of M2 when active. It's possible that other designs would have more delays that would self correct this problem, however I'd be careful about relying on inherent delay in a mapper design...

I think linariq's test is already checking for this but one option you could try is putting more text or something on the screen. Then there wouldn't need to be a comparison in your code. The verification would be on screen.

The other thing would be to verify that the sound and controller registers are properly blocked by the mapper. Linariq seems to be checking/sensing High-Z at those addresses.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 4:21 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
I can actually easily recompile one of my games that were written in C to this layout. This will make use for all the console resources, with large part of code and data located in the $4800-$8000 range.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 4:55 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Shiru wrote:
I can actually easily recompile one of my games that were written in C to this layout. This will make use for all the console resources, with large part of code and data located in the $4800-$8000 range.

I modified the linker config for Alter Ego and it works fine running down at $4800.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 5:10 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
cpow, upload the file, please, so it would be available for hardware tests.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 5:28 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Shiru wrote:
cpow, upload the file, please, so it would be available for hardware tests.

Ok, it's here. If you want the linker config too I'll upload an updated project archive.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 5:43 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Strange, it does not work properly on my FCEUX mod - messed up palette and sound, and it hangs after pressing start.

Since smaller tests works well, I guess there is a problem with the middle bank ($8000-$dfff) in my mod.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 191 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 13  Next

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