It is currently Sun Dec 16, 2018 10:59 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 54 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Tue Jun 25, 2013 3:52 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7832
Location: Seattle
zzo38 wrote:
for extra audio you could use a AY-3-8910 (similar to how the Sunsoft 5B does), but connect it to the PPU address bus (you might be updating the music during vblank, and with no extra decoding logic you can map it to $3xxx (cartridge already provides A13 inverted, and A12 can be used uninverted) in the PPU address space)
Useful if you want expansion audio on a minimal discrete-logic game, but I expect the cost of a 74'20 or whatever to map it to CPU space is more convenient. The biggest improvement would probably be not dividing M2 by 2 so that the envelope register can be used for two octaves of tones instead of one. (A frequency doubler, if connected to a YM part, would be even better)

Also, if you do use an '8910, keeping the GPIO pins hidden behind the PPU is unkind: it prevents midscreen banking.

Quote:
to use one [audio channel] for IRQ.
The voltages that come out of at least the YM2149 are inappropriate for driving logic.

Quote:
You could connect the CHR RAM enable and CIRAM enable to CHR A12 instead of A13 (and CHR A13 to CHR RAM A12), which provides four screens but less graphics are available for sprites.
You could have a latch enabled by CHR A13 in order to make CHR ROM bankswitching according to which nametable is selected, and even individual 16x16 attribute areas if that is wanted.
I already mentioned both of these.

Quote:
To make up mappers in a emulator, it would be useful to support a C API plugin interface that supports NES 2.0 (therefore, you can use 12-bit mappers numbers and have submapper numbers and other things available too) and some other features.
Modifying nestopia's NstBoard.[ch]pp is pretty easy.


Top
 Profile  
 
PostPosted: Tue Jun 25, 2013 4:23 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
lidnariq wrote:
Useful if you want expansion audio on a minimal discrete-logic game...
Yes this is precisely my point.

Quote:
Also, if you do use an '8910, keeping the GPIO pins hidden behind the PPU is unkind: it prevents midscreen banking.
Of course you wouldn't do this if you need midscreen banking.

Quote:
The voltages that come out of at least the YM2149 are inappropriate for driving logic.
I thought this might be the case (although I was unsure).

Quote:
Modifying nestopia's NstBoard.[ch]pp is pretty easy.
I would rather not have to recompile the entire emulator if I can just add a DLL; however, if recompiling that is just to add a feature and that the mapper can be added using a DLL then that should be good enough. I will look at those things; thanks. However, it won't work if the emulator cannot be compiled using MinGW or Cygwin, since that is what I have.

_________________
.


Top
 Profile  
 
PostPosted: Tue Jun 25, 2013 5:04 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7832
Location: Seattle
zzo38 wrote:
I would rather not have to recompile the entire emulator if I can just add a DLL; however, if recompiling that is just to add a feature and that the mapper can be added using a DLL then that should be good enough. I will look at those things; thanks.
Are you familiar with the concept of incremental builds? A well-written makefile (and equivalents) only compile the specific source files that changed (or depend on things that changed) and then links.


Top
 Profile  
 
PostPosted: Tue Jun 25, 2013 5:34 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
lidnariq wrote:
zzo38 wrote:
I would rather not have to recompile the entire emulator if I can just add a DLL; however, if recompiling that is just to add a feature and that the mapper can be added using a DLL then that should be good enough. I will look at those things; thanks.
Are you familiar with the concept of incremental builds? A well-written makefile (and equivalents) only compile the specific source files that changed (or depend on things that changed) and then links.
Yes, I am familiar, but I want to write a plugin code so that it can be used in another emulator too possibly. Also, that doesn't answer my question about MinGW.

_________________
.


Top
 Profile  
 
PostPosted: Tue Jun 25, 2013 5:58 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7832
Location: Seattle
There's definitely nothing resembling a cross-emulator mapper syntax. Such a thing would imply any kind of standardization across emulators.

As far as MinGW/Cygwin, I don't know, I use linux.


Top
 Profile  
 
PostPosted: Wed Jun 26, 2013 12:52 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
I wonder what kind of things you could make with a seven-segment decoder? Each segment is effectively some logic on the inputs.

_________________
.


Top
 Profile  
 
PostPosted: Wed Jul 10, 2013 6:53 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7832
Location: Seattle
zzo38 wrote:
I wonder what kind of things you could make with a seven-segment decoder? Each segment is effectively some logic on the inputs.
Having sat down and thought about this on and off for the past several weeks, for the life of me I cannot figure what one would do with this.
The 74'4511 (the only still-manufactured BCD decoder) is basically a 16-by-7-bit ROM with an obtuse table, both a force-high and force-low pin, and a transparent latch.
Individual output pins could be used for complex decoding logic, but the part where values A-F force blank doesn't help matters, and I see very few useful relations between multiple outputs.
The combined function is something like:
Code:
Qa = (Q1+Q2+nQ3)·(Q1+nQ2+nQ3)·nblank·(nQ1+Q2+Q3+Q4)
Qb = (nQ1+Q2+nQ3)·(Q1+nQ2+nQ3)·nblank
Qc = (Q1+nQ2+Q3)·nblank
Qd = (nQ1+Q2+Q3)·(Q1+Q2+nQ3)·(nQ1+nQ2+nQ3)·nblank
Qe = nQ1·(Q1+Q2+nQ3)·nblank
Qf = (nQ2+Q3)·(nQ1+nQ2+nQ3)·nblank·(nQ1+Q2+Q3+Q4)
Qg = (Q1+Q2+Q3+Q4)·(nQ1+nQ2+nQ3)·nblank·(nQ1+Q2+Q3+Q4)
Where nblank is all the reasons the output might be blanked (/BL input low, or Q0..Q3 denoting hexadecimal A-F)


Top
 Profile  
 
PostPosted: Fri Mar 21, 2014 12:59 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7832
Location: Seattle
In this thread, OneCrudeDude asked whether it would be possible to get a hardware-based parallax assist.

So what would theoretical hardware-assisted parallax look like, if it weren't fine-grained banking?

Horizontal parallax, even though it's the kind we'd want, will be more complicated due to the way the NES draws its output. But vertical parallax ... we can probably do something clever here. After all, the MMC5 supports different vertical fine scroll values when in Left-and-Right split screen.

I think the addition of an 8-bit latch and an 8-bit adder should get us most of the way there. To make only one section of CHR scroll, we would use something (maybe 1 or 2 OR gates) to select which section of CHR would scroll, and a tristateable latch with pull-down resistors would let us add 0 instead of the latch's contents for tiles where we didn't want a scroll offset.

The adders would take the latched value, and add it to PPU A8..A4, A2..A0 (skipping A3, because that's color plane information). This means we could vertically rotate any number of sets of 32 contiguous tiles.

Unlike MMC5, this doesn't let us change the size of attribute zones, and it also imposes strict requirements on the CHR's layout.

This is just a little bit of a stretch for a discrete-logic solution, especially as it's more useful in the context of an ASIC mapper that already provides separate CHR banking:
4 ICs: 74'573 (three-state octal latch), 2x 74'283 (four bit full adder), 74'32 (quad OR gate). Hook the latch up in lieu of the MMC3's RAM, or something.
Doing 74573./OE ← PPUA10 OR PPUA11 OR PPUA12 would let us scroll only the 64 tiles from $0000 to $03ff.
The 74HC283 is fast enough (propagation times of 40ns at 5V) that modern 100ns ROMs or RAMs will have plenty of breathing room.


Top
 Profile  
 
PostPosted: Fri Mar 21, 2014 10:18 am 
Offline
User avatar

Joined: Fri Aug 23, 2013 2:14 am
Posts: 274
I'm so honored to have been mentioned in a post! Anyway, regarding my parallax theory, I was thinking this could be used to add a much needed depth in NES games. Granted the hardware wasn't natively capable of doing it, instead relying on bankswitching techniques or scanline split techniques. The below image (from Panic Restaurant, which I believe has the best artistic direction of all NES games) will be used for my example.

Image

You see the floor, buildings, the sign, and the distant skyscrapers, right? My theoretical "parallax" mapper would make the skyscrapers move as the player does. Of course, this is basic parallax for NES games, but I was thinking about doing a more thorough attempt. The following example would be another example.

Image

Again, the distant blue buildings will "scroll" "behind" the game game scenery, which is in reality just rewriting the graphics at those particular locations. Unfortunately, most of my theories have been already executed by commercial NES games, and what I'm suggesting seems like very intensive; all the "background" of the stage will be rewritten based on how far the player has moved, while the "foreground" stays the same.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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