This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Looking For Inspiration

Looking For Inspiration
by on (#63901)
OK, to cut a long introduction short, I'm embarking on another NES tracker. I know, I know. :)

I've been busy (on and off) rewriting an audio engine from scratch that runs at (so far) 240hz and you can layer up the effects for some pretty weird-sounding stuff.

Anyway, all that is going well. However, because of the CPU intensiveness of updating the engine 4 times per frame, I'm trying to create an interface that minimises screen updates and data decoding. I think I've got this fairly sussed but one thing I'm struggling with is the design of the music data.

NTRQ used "fixed" length patterns and while it meant memory handling wasn't necessary, it was also very wasteful (2 bytes per pattern step, even if that step was empty).

This time I'm wanting to have 2 FX columns plus the note column but I'm going to take a leaf out of LSDJ's book and limit the pattern length to 16 steps so that I don't have to have "scrolling" data.

This would mean that one pattern, done like NTRQ, would take 80 bytes (1 byte for note, 2 bytes for FX1, 2 bytes for FX2 multiplied by 16 steps = 80)

My rough memory map allows me 4096 bytes for pattern data (again using 8KB battery RAM) which would only allow me about 50 patterns and that's just not enough.

So.....(there's a point, yes :))

I've been trying to figure out a dynamic memory method to make more efficient use of the battery RAM. Instead of having fixed patterns, in memory they will be tokenised so that, for example, 9 blank steps is represented by one byte, $89, instead of 45 bytes (9 x 5 bytes per step as explained above).

My idea so far would be to have a edit buffer in main RAM that you decode the pattern to when editing. As you enter editing mode;

1) Decode the pattern from SRAM to main RAM.
2) Shuffle all the pattern data from the address of the pattern being edited upwards to close the gap (the size of the encoded pattern in SRAM).
3) All edits are performed in the edit buffer in main RAM.
4) If you change patterns or exit edit mode, the pattern in the edit buffer is encoded to SRAM but at the end of existing patterns and it's pointer address is updated accordingly.

The obvious gotcha is going to be when the limit of the 4096 bytes of pattern RAM are being reached and you're editing patterns low down in the memory - there'll be a lot of data to shuffle upwards before editing can begin.

Just looking for some advice, optimisation, tips, alternatives etc.

:)

by on (#63903)
I would like to see some kind of an implementation of meta-effects, effects that one could program to "command" other effects and thus create complex sounds with more ease. For example, the user could pre-define a certain single effect letter to abbreviate for a long and thoroughly complex guitar-like-pitch-bending, volume-changing and arpeggio-abusing effect pattern with only a single effect.

Of course, getting such a feature to run 240 times a second on an old 6502 is most likely not that easy. Perhaps possible for a single, maybe even two, channels, but, I dare say, certainly not possible for every single one.
Then again, as an experienced musician, you most likely already have a brilliant strategy to combat the adversity of having to write down long, repeating sequences.

To address the matter of limited space, have you considered bankswitched SRAM?

by on (#63960)
I advise using a bigger SRAM. I've mentioned on other threads before that if you make new boards later, 32kB SRAMs are cheaper than 8kB ones (so pretty much anyone would build with 32kB and have most of it go to waste).

What emulator are you testing with? I've learned C recently so maybe I could hack a usable mapper into one of them. I know the game Genghis Khan uses 16kB SRAM, so hopefully an emu that supports that, as a start.

A copy of NESten I have will work with 32kB already. Kind of an older emulator though.

by on (#63961)
Yeah, the bigger SRAM would be nice. A sticking point at the moment is that as far as I know, only MMC5 supports it and PowerPak doesn't support MMC5 (properly?) therefore I'd be cutting off the possibility of using it on PowerPak.

I've no doubt that a dedicated cart could be built but there are a lot of people using NTRQ on PowerPak and I wouldn't like to alienate those users (as they're probably my whole "market" :))

by on (#63963)
Oh, I'm using Nestopia (Mac) and also FCEUX (via Parallels). I'm pretty sure Nestopia can use 32k SRAM, not sure about FCEUX.

by on (#63964)
There are other boards, too, that support more than 8k of SRAM.
Two variants of MMC1, at least:
SOROM 16k
SXROM 32k

by on (#63966)
I would hope that PowerPak has 32kB of RAM, and it's just the case that no one is using it. I can open up the case on mine later, unless someone else has a definitive answer first.

That's actually something I've been interested in for some Verilog practice, a PowerPak mapper, so I'll be a little disappointed if there's not 32kB there. That'll be later though. But I'll take a look at Nestopia's source this weekend. This kind of mapper would be helpful for others too, I believe.

by on (#63971)
I have never saved games when running them on my PowerPak, but I remember 32KB save files being discussed back when it was released.

EDIT:
www.retrousb.com wrote:
Technical Info:
Inside the PowerPak is a Xilinx FPGA, 512KB prg space, 32KB battery ram space, 512KB chr space, boot rom, and glue logic. The FPGA has extra graphics ram for four screen games and MMC5 exram. No processors are used; the NES 6502 controls everything.
Re: Looking For Inspiration
by on (#63972)
neilbaldwin wrote:
I've been busy (on and off) rewriting an audio engine from scratch that runs at (so far) 240hz and you can layer up the effects for some pretty weird-sounding stuff.

Ooh, a 4x player, has anyone done multi-speed replayers on the NES before? I know it's very commonplace on the C64, where I've seen 8x, 12x, and I think even more.
Re: Looking For Inspiration
by on (#63977)
LocalH wrote:
neilbaldwin wrote:
I've been busy (on and off) rewriting an audio engine from scratch that runs at (so far) 240hz and you can layer up the effects for some pretty weird-sounding stuff.

Ooh, a 4x player, has anyone done multi-speed replayers on the NES before? I know it's very commonplace on the C64, where I've seen 8x, 12x, and I think even more.


As far as I know, no. :)

Yeah, it's much more common on C64, probably due to the fact that you have timed IRQs and can set them multiple times per frame.

by on (#63978)
InvalidComponent wrote:
There are other boards, too, that support more than 8k of SRAM.
Two variants of MMC1, at least:
SOROM 16k
SXROM 32k


From reading I'm still pretty sure only MMC5 supports 32Kb of battery-backed RAM (which is what I need). SXROM seems to only have 32kb of volatile RAM which, while handy, is not much use for this application.

by on (#63980)
wiki on SXROM wrote:
and that inverter is also battery backed just like the SRAM

by on (#63982)
tokumaru wrote:
wiki on SXROM wrote:
and that inverter is also battery backed just like the SRAM


Doh! I was just running back to this thread after properly reading the SXROM page to correct my error.

:)

Having said that, I've also been reading MMC5 specs. Man, that's a sexy mapper - the nametable stuff, timed IRQs and hardware multiplication sounds like a dream-come-true! :D

by on (#63983)
All board that have batteries are optional - that is they can be made to be build together with either volatile SRAM or battery backed SRAM.

There is a couple of boards with SRAM and no slot for a battery (TSROM, JSROM) but that's a minority. They probably made TSROM because it was commonly used enough so that they save board space by removing the TKROM battery slot. Because SMB3 was one of the first MMC3 games, and it was produced in insane quantities, Nintendo made that decision.

Quote:
Man, that's a sexy mapper - the nametable stuff, timed IRQs and hardware multiplication sounds like a dream-come-true!

Agreed !

by on (#63986)
Not having much luck trying to get Nestopia (Mac) or FCEUX (Win) to create a 32kb .sav file. From reading, you put MMC1 into 8K chr mode then use bits 2-3 of MMC1 register 1 (CHR Bank 0 @ $A000-$BFFF) to select the WRAM bank.

I'm just trying to flood the WRAM with incrementing bytes. It creates an 8K .sav file OK.

Here's the code;

Code:
   jsr resetMMC1
      
   lda #%00001100      ;Set bank layout, H&V mirror, 16kb ROM at $C000. 8KB CHR
   jsr setMMC1r0
   lda #%00000000
   jsr setMMC1r2
   
   lda #%00000000      ;WRAM bank 0?
   jsr setMMC1r1
   jsr clearWRAM
   
   lda #%00000100      ;WRAM bank 1?
   jsr setMMC1r1
   jsr clearWRAM

;--------------------------

clearWRAM:
   lda #<$6000
   sta tmp0
   lda #>$6000
   sta tmp1
   ldx #$20
   ldy #$00
@clearWram:
   tya
   sta (tmp0),y
   iny
   bne @clearWram
   inc tmp1
   dex
   bne @clearWram
   rts

resetMMC1:
   ldx #$80
   stx $8000
   rts

setPRGBank:
   sta $E000
   lsr a
   sta $E000
   lsr a
   sta $E000
   lsr a
   sta $E000
   lsr a
   sta $E000
   rts
   
setMMC1r0:
   sta $9fff
   lsr a
   sta $9fff
   lsr a
   sta $9fff
   lsr a
   sta $9fff
   lsr a
   sta $9fff
   rts

setMMC1r1:
   sta $Bfff
   lsr a
   sta $Bfff
   lsr a
   sta $Bfff
   lsr a
   sta $Bfff
   lsr a
   sta $Bfff
   rts

setMMC1r2:
   sta $Dfff
   lsr a
   sta $Dfff
   lsr a
   sta $Dfff
   lsr a
   sta $Dfff
   lsr a
   sta $Dfff
   rts

by on (#63994)
InvalidComponent wrote:

"this board has no 72-pin "NES-SXROM" counterpart." Good luck making repros of a game using this.

by on (#64000)
tepples wrote:
InvalidComponent wrote:

"this board has no 72-pin "NES-SXROM" counterpart." Good luck making repros of a game using this.


Gah.....doomed!

:)

by on (#64003)
tepples wrote:
"this board has no 72-pin "NES-SXROM" counterpart." Good luck making repros of a game using this.

Still easier than using the MMC5, since at least the mapper chip has been successfully cloned. And I'm pretty sure that other MMC1 boards (even the ReproPak sold by RetroZone, although it doesn't seem to have space for a battery) can be converted with some rewiring.

But I believe that the main focus is the PowerPak, since managing the saves in other ways is not as simple.

by on (#64004)
neilbaldwin wrote:
Not having much luck trying to get Nestopia (Mac) or FCEUX (Win) to create a 32kb .sav file.

Maybe it's because the old iNES format doesn't have a way to specify the size of he SRAM, so the few games that use that much are detected using checksums I think... Maybe these emulators already support iNES 2.0?

by on (#64021)
neilbaldwin wrote:
tepples wrote:
InvalidComponent wrote:

"this board has no 72-pin "NES-SXROM" counterpart." Good luck making repros of a game using this.


Gah.....doomed!

:)



Well doesn't this support SXROM?

http://www.retrousb.com/product_info.ph ... ucts_id=43


I think in the PDF it says SXROM :wink:

by on (#64022)
tokumaru wrote:
neilbaldwin wrote:
Not having much luck trying to get Nestopia (Mac) or FCEUX (Win) to create a 32kb .sav file.

Maybe it's because the old iNES format doesn't have a way to specify the size of he SRAM, so the few games that use that much are detected using checksums I think... Maybe these emulators already support iNES 2.0?


Hmmmm. Is there much support for iNES 2 at all? I can find very little about it apart from the discussion (and subsequent wiki entry) on here?

by on (#64023)
At least Nestopia supports iNES2 but since I don't think any ROM use it yet not a lot of emulators will implement this. However a major release that requires iNES2 to work might be the only way to force people to accept the format.

by on (#64026)
Bregalad wrote:
At least Nestopia supports iNES2 but since I don't think any ROM use it yet not a lot of emulators will implement this. However a major release that requires iNES2 to work might be the only way to force people to accept the format.


From reading, the amount of battery-backed PRG RAM is specified in byte 10 of the header in the upper nibble. I took it to mean the number of 8kb blocks?

In any case, it doesn't matter what value I put in byte 10 of the header, only an 8k .sav file is generated.

:(

by on (#64027)
neilbaldwin wrote:
In any case, it doesn't matter what value I put in byte 10 of the header, only an 8k .sav file is generated.

:(

Maybe you should create the 32k SAV file manually and see if it loads it correctly.

by on (#64028)
thefox wrote:
neilbaldwin wrote:
In any case, it doesn't matter what value I put in byte 10 of the header, only an 8k .sav file is generated.

:(

Maybe you should create the 32k SAV file manually and see if it loads it correctly.


Great idea but I just tried it and Nestopia overwrites it with an 8k one :(

by on (#64038)
I guess you should specify in the header somewhere a flag that tells it that it's effectively a iNES2 header. If you don't - it will be considered a normal iNES header - and the emulators default to 8kb and emulate more based on CRC checks.
I'm not sure, but it was made so that the typical "DiskDude" (incorrectly) present in some iNES headered ROMs would NOT set the iNES2 flags. Your best bet is to use Nestopia's "edit iNES header" feature - and then save the result to re-use it at compile time.

by on (#64062)
Bregalad wrote:
I guess you should specify in the header somewhere a flag that tells it that it's effectively a iNES2 header. If you don't - it will be considered a normal iNES header - and the emulators default to 8kb and emulate more based on CRC checks.
I'm not sure, but it was made so that the typical "DiskDude" (incorrectly) present in some iNES headered ROMs would NOT set the iNES2 flags. Your best bet is to use Nestopia's "edit iNES header" feature - and then save the result to re-use it at compile time.


Ah, see, I never knew how different Nestopia was on OSX compared to Windows. There's quite a lot missing from the OSX version.

Anyway, your idea was a good one. Edited the header in Nestopia (Win) and then used the resulting header in my code. Nestopia now recognises that the ROM is supposed to have 32kb NVRAM but it still doesn't want to save a .sav file bigger than 8kb.

Does anyone have a definitive answer on how to bank-switch NVRAM/WRAM? At the moment I don't know if I'm doing it incorrectly or the feature is not supported. :S

by on (#64064)
I don't know about other carts, but I know for the game Genghis Khan with it's 16kB, only 8kB of it is battery-backed (it's 2 separate RAM chips).

by on (#64089)
Memblers wrote:
I don't know about other carts, but I know for the game Genghis Khan with it's 16kB, only 8kB of it is battery-backed (it's 2 separate RAM chips).


Hmmmm. So how does that game bank-switch the RAM?

by on (#64092)
Copied from 'advanced nerdy nights #2' here

Quote:
SOROM
This board is used by Genghis Khan, Nobunaga, and a few other games. The same idea of stealing unused CHR bits is used to expand the WRAM to 16KB. This time the fourth bit of the CHR Bank register (D3) becomes the WRAM bank select. Clear the bit to select the lower 8KB of WRAM for the $6000-7FFF range, and set the bit to select the upper 8KB. The board uses two physically separate chips and only one is battery backed, so only one of the 8KB banks is battery backed.

Like with SUROM when using 4KB mode you need to set D3 the same in both CHR registers.


Quote:

SXROM
This board is only used in a couple Japanese games like Final Fantasy 1+2. It is a combination of SUROM and SOROM to expand both PRG ROM and WRAM. Makes sense when they pack two games on one cart that each need half those specs! Unlike SOROM there is only one physical WRAM chip so all 16KB is battery backed.

D4 still picks upper or lower 256KB PRG, and D3 still picks upper or lower 8KB WRAM.


by on (#64094)
neilbaldwin wrote:
So how does that game bank-switch the RAM?

The CHR switching is used for the SRAM instead, since it would be pointless in a CHR-RAM cart.

by on (#64108)
tokumaru wrote:
The CHR switching [...] would be pointless in a CHR-RAM cart.

Not always. Sometimes the player needs the extra RAM in the only game that uses CPROM to draw the various forms of CP.


Sometimes thinking about the exceptions to a rule helps people understand the rationale behind the rule. It certainly helps me like that.

by on (#64117)
But that game has more CHR memory than what the NES can address, so bankswitching is needed. I admit that even with only 8KB of CHR bankswitching can sometimes be useful (not with the 4KB banks of the MMC1, since you can use $2000 to simulate that kind of bankswitching, but with 1KB banks it could be), but hardly practical for most types of games.

Is Videomation the prequel to Art Alive? And what does CP have to do with anything?

by on (#64164)
I only found one emulator, Nintendulator, that's explicitly supposed to support SXROM.

However, yet again, it seems impossible to create a .sav file larger than the standard 8kb.

I'm desperate now, is there anyone who knows how to get an emulator to save a 16kb .sav file?

My current project is pretty much dead in the water if I can't find a solution :(

by on (#64176)
I guess no one emulates SXROM because the only cart using it (AFAIK) already exists as 2 separate games (Final Fantasy 1 and 2).

Well I finally tried messing with Nestopia source and unfortunately it's a VC++ setup and I have no idea how to deal with that. Since VC++ Express 10.0 is the only version I could find to download, it has to "convert" it which results it craploads of warnings and failure to build. I guess I'm stuck without having the exactly right version.. (Seriously, what the hell kind of software/version scheme goes up to v10.0?)

I'll have to try again with another emu that works with gcc/mingw maybe, but won't be able to try it for another week or so. Does anyone want to help out adding by mapper #124 (Squeedo mapper number) with extra RAM to any emulator?

by on (#64178)
There is another game that use 32k of ram, the best play baseball special but it came out in japan only. Maybe this game support 32k properly or the game is not emulated completely, good question.

As for the squeedo mapper, now that I have a netbook I could always check how to implement it but my time is quite limited. VS is not an issue for me but I don't know how long it would take to understand how the emulator works and how to implement it after. I cannot promise anything.

by on (#64183)
Quote:
but it came out in japan only

In fact FF1&2 also come out in japan only. Only FF1 standalone made it to america (if you don't count the FF2 prototype).

Neil, I don't think you could get a 16kb sav file, but a 32kb. SOROM has 16kb RAM, but only 8k can be battery-ied.

I guess I have found the problem. Nestopia only accepts to do a 32kb file if you have a iNES2 header, and if your PRG-ROM is at least 128kb. You probably tried with a smaller PRG-ROM, and that's why it still made you a 8kb file. I don't know WHY, it's probably a bug/error in Nestopia, but anyway it's there. The SOROM/SXROM boards effectively only accepts 128-256kb (and 512kb for SXROM obviously) so that might be the reason - although iNES was made to make ALL possibilities of boards, not only the ones commercial games used so I think Nestopia should honnor this but oh well.


Your header should look like this (for 128kb PRG-ROM) :
$4e, $45, $53, $1a, $08, $00, $12, $08, $00, $00, $90, $07

However, I think all other emus will ignore it and Nestopia have no debugger so good luck... the only other option is to have your ROM have the same CRC-32 as Final Fantasy 1+2 or that obscure Basball game.... insane I know. It might work surprisingly well though.

by on (#64184)
Bregalad wrote:
Quote:
but it came out in japan only

In fact FF1&2 also come out in japan only. Only FF1 standalone made it to america (if you don't count the FF2 prototype).

Neil, I don't think you could get a 16kb sav file, but a 32kb. SOROM has 16kb RAM, but only 8k can be battery-ied.

I guess I have found the problem. Nestopia only accepts to do a 32kb file if you have a iNES2 header, and if your PRG-ROM is at least 128kb. You probably tried with a smaller PRG-ROM, and that's why it still made you a 8kb file. I don't know WHY, it's probably a bug/error in Nestopia, but anyway it's there. The SOROM/SXROM boards effectively only accepts 128-256kb (and 512kb for SXROM obviously) so that might be the reason - although iNES was made to make ALL possibilities of boards, not only the ones commercial games used so I think Nestopia should honnor this but oh well.


Your header should look like this (for 128kb PRG-ROM) :
$4e, $45, $53, $1a, $08, $00, $12, $08, $00, $00, $90, $07

However, I think all other emus will ignore it and Nestopia have no debugger so good luck... the only other option is to have your ROM have the same CRC-32 as Final Fantasy 1+2 or that obscure Basball game.... insane I know. It might work surprisingly well though.


Thank you so much Bregalad :D

Seriously, this is the kind of answer I was needing and couldn't get to myself. Really appreciate the effort.

The CRC trick sounds interesting - how does one go about finding that and where does it go in the ROM (that's probably a daft question :))?

by on (#64191)
Cyclic Redundancy Check is a hash function built around a polynomial counter. If you read the description on Wikipedia and find it strangely familiar from having hacked ROMs, consider that a lot of games use things like CRC as a pseudorandom number generator.

Unlike later secure hash functions such as MD5 and the SHA series, CRC is intended only to detect noise in transmission channels. It's straightforward to "forge a CRC", or find a message with a given CRC value that differs from your original message by fewer than 32 bits.

by on (#64192)
Quote:
It's straightforward to "forge a CRC", or find a message with a given CRC value that differs from your original message by fewer than 32 bits.

Then it might be possible to have a program that "hacks" a few unused bytes at the end of your ROM so that it has the same CRC as a SXROM commercial ROM, and include it in the compilation process and emulator will be tricked by thinking it's the other game. I have no idea if this would work and how much it would slow down the compilation.

by on (#64193)
As for the SXROM/32KB setup - works like a charm. :) Apart from the slight issue that I now have no text on screen - is that SXROM configuration for CHR RAM? I'm probably not setting it up right, just hacked it together to make the .sav file work.

But, as you suggested, only in Nestopia (so far from the ones I've tested). :(

Really need to try it on my PowerPak when I get home as that's probably the most important test for me right now.

Does anyone know the authors of FCEUX enough to convince them to support this stuff? That would be brilliant if it could happen.

by on (#64194)
SUROM, SOROM, and SXROM all extend SNROM, a CHR RAM board. They pretty much have to use 8 KiB CHR RAM (or 8 KiB CHR ROM) because they repurpose the CHR ROM bank bits to switch PRG ROM and PRG RAM.

by on (#64195)
tepples wrote:
SUROM, SOROM, and SXROM all extend SNROM, a CHR RAM board. They pretty much have to use 8 KiB CHR RAM (or 8 KiB CHR ROM) because they repurpose the CHR ROM bank bits to switch PRG ROM and PRG RAM.


Of course, thanks tepples.

*wanders off to read about CHR RAM*

by on (#64202)
neilbaldwin wrote:
*wanders off to read about CHR RAM*

There is no mystery here. The difference is that with CHR-ROM the tiles are "magically" in place for you to use, but with CHR-RAM you have to populate the pattern tables yourself (using $2006 and $2007, like with other kinds of VRAM updates) before using the tiles.

Also, since there is no bankswitching, if you need to change tiles you have to manually rewrite them byte by byte, something that obviously takes longer than bankswitching.

by on (#64219)
tokumaru wrote:
neilbaldwin wrote:
*wanders off to read about CHR RAM*

There is no mystery here. The difference is that with CHR-ROM the tiles are "magically" in place for you to use, but with CHR-RAM you have to populate the pattern tables yourself (using $2006 and $2007, like with other kinds of VRAM updates) before using the tiles.

Also, since there is no bankswitching, if you need to change tiles you have to manually rewrite them byte by byte, something that obviously takes longer than bankswitching.


Yep, got it :)

Works fine. Need to test on PowerPak now.

by on (#64221)
:(

Doesn't seem to work on PowerPak. Only the first 8kb of the .sav file is written to.

by on (#64240)
May educated guess is that the powerpak "mappers" doesn't support it properly yet. Since it's emulates the mapper in hardware, that would be the most plausible reason.

by on (#64248)
Maybe the PowerPak doesn't read iNES 2.0 yet. How does it use more than 8KB of WRAM then?

by on (#64249)
That's what is strange. PowerPak comes with "blank" .sav files, one 8K and one 32K so there is obvious intention for it to work, somehow.

When I load up the ROM and point it at the save file it doesn't complain about the size (32K) but then again you might be able to point it at anything, I don't know how much validation PowerPak uses.

Something I noticed last night is that contrary to what Bregalad said, I managed to get it working with a 128K ROM size, as opposed to the 256K that he said was required. I'll try making a 256K ROM and retest on PowerPak, just in case.

But yes, at the end of the day, it could just be that iNES 2.0 is not supported.

by on (#64251)
I said 128k was required, but it don't work with lower sizes.

About the power pak I don't know. Maybe the 32k sav file is for SNES games (even though most SNES games still use 8k, some are 32k I think).

by on (#64253)
Bregalad wrote:
I said 128k was required, but it don't work with lower sizes.


Sorry, I was doing that from some (evidently) false memory without actually referring back to the thread. :(

by on (#64258)
I actually had a similar problem when I was developing the save state mappers but I don't remember at all how I solved it. :? Sorry. It might have been a change I made to the actual mapper.

But for now, one thing you could try is playing a game like Final Fantasy I & II which uses 32K SRAM and see if PowerPak saves the full 32K when playing it (fill the SAV file with some markers before playing & saving).