SKROM how to?

[mutecity]

Hello everyone.

I have been trying to make a hardware copy of NTRQ.

It's MMC1 with CHR and PRG with save RAM,
So It must be a SKROM.

I find a post here saying that the wiring is the same as on SLROM.
I used UCON64 to pad both the PRG and CHR to 128k.

But I can't get it to work.
anyone know where im going wrong?

[MottZilla]

What's NTRQ? And you shouldn't have to pad the PRG or CHR roms. That might be why it doesn't work.

[tepples]

NTRQ is here.

[mutecity]

What's NTRQ? And you shouldn't have to pad the PRG or CHR roms. That might be why it doesn't work.

well all I had was 27c010 EPROMs

well If the files are not paded there are 64k for the PRG and 16k for the CHR,
How would I wire that?

[Memblers]

Do you need a way to save/load the music data? I'm wanting to work on a way to do that, I have several different solutions actually.

[Memblers]

Oh, I thought of another thing too. NTRQ appears to come with a "blank" SRAM file. I'm assuming if that's needed then NTRQ doesn't do a full sanity check / initialization on the SRAM and so it could perhaps crash if it assumes that something is initialized when it isn't. If that was true, you would need something like the CopyNES hardware to write the SRAM. Or another EPROM that does it before you put NTRQ in.

[mutecity]

Do you need a way to save/load the music data? I'm wanting to work on a way to do that, I have several different solutions actually.

That would be great!

hold on... do you mean save and load data to PC or on the cart?

If it's on the cart you should have a chat to neil about it.

[tepples]

NTRQ appears to come with a "blank" SRAM file.

It could just be there because PowerPak's file system code can't create files, and not everyone has Python to run make_sram.

[Memblers]

Do you need a way to save/load the music data? I'm wanting to work on a way to do that, I have several different solutions actually.

That would be great!

hold on... do you mean save and load data to PC or on the cart?

It can be done either way, but the cart I've designed will be able to do both since it will have FlashROM and a USB or RS232 connection.

You can't save to FlashROM with MMC1 because the address space is used by the mapper for writing, but what you can do is build a TTL-to-RS232 converter (or TTL-USB) and plug it into the NES controller port. I freely released my part of the source code (the NES-side of things), the XMODEM part was written by another 6502 guy, Daryl Rictor, and is free to use with credit given. That works with Hyperterminal, which cames with practically every version of windows (vista and win7 I have no idea though). For the USB cable you just install some drivers (so it uses it like a serial COM port).

The cartridge I've designed (Squeedo) puts the mapper registers at $5xxx, so the PRG-ROM can be written to freely. There's 32kB instead of 8kB of SRAM (not battery backed though - you save it to flash). The next revision will have USB onboard, the "current" version was made in 2004 and I'm just now bringing it back to life to get the basic functionality up and running again, and into the hands of a few developers and testers. The cart also has some extra sound functions, whenever NTRQ's source is available I definitely want to look into replacing (ideally, adding in), the sound channels with the ones my synth generates.

[MottZilla]

What's NTRQ? And you shouldn't have to pad the PRG or CHR roms. That might be why it doesn't work.

well all I had was 27c010 EPROMs

well If the files are not paded there are 64k for the PRG and 16k for the CHR,
How would I wire that?

Ok, so your problem is that you padded it up to size which is a big no-no. Instead you need to mirror it up to size. Basically you take the PRGROM file, and copy it to itself until it is to size. Example at the command line:

copy /b PRG.ROM + PRG.ROM BIGPRG.ROM

For the CHR that you say is 16K, you'll have to copy it onto itself alot more to get it up to 128K, the eprom size you have.

But you can just go like this:

copy /b chr.rom + chr.rom bigchr.rom

Now it's 32K. Delete the CHR.ROM file and rename bigchr.rom to chr.rom and do the command again and it will double in size to 64k. Do the same renaming again and execute the command one more time and you'll have 128K.

[tepples]

The cartridge I've designed (Squeedo) puts the mapper registers at $5xxx, so the PRG-ROM can be written to freely. There's 32kB instead of 8kB of SRAM (not battery backed though - you save it to flash).

Flash at what page size? People don't want to have to read-modify-write an area larger than the NES's RAM to change one byte.

[Memblers]

The cartridge I've designed (Squeedo) puts the mapper registers at $5xxx, so the PRG-ROM can be written to freely. There's 32kB instead of 8kB of SRAM (not battery backed though - you save it to flash).

Flash at what page size? People don't want to have to read-modify-write an area larger than the NES's RAM to change one byte.

Page size is 64kB. When I redo the board it will have at least 128kB of RAM, but the workaround for the old Squeedo was the plan to use 2 sectors since this requires no RAM. When one sector is full, the alternate one is erased, this is the only time it erases any old files. So depending on how full your save memory is, and yeah if you keep changing a single byte in a large file, you'll see a delay more or less often while saving. Just a simple wear-leveling type file system. I had not coded it, but it always seemed simple enough.

The user/programmer won't have to do much, you would JSR to a routine in the BIOS. This is pretty much necessary so multiple programs can co-exist with eachother's save files, and also because the hardware will change or be reconfigured to save to other locations.

[neilbaldwin]

Oh, I thought of another thing too. NTRQ appears to come with a "blank" SRAM file. I'm assuming if that's needed then NTRQ doesn't do a full sanity check / initialization on the SRAM and so it could perhaps crash if it assumes that something is initialized when it isn't. If that was true, you would need something like the CopyNES hardware to write the SRAM. Or another EPROM that does it before you put NTRQ in.

NTRQ checks for a signature in the SRAM file. If not found it "formats" the SRAM file so that it doesn't get upset.

I only included that blank file as a fall-back in case something did go wrong. You don't actually need it.

[arfink]

I seem to recall seeing a post from a while ago where Memblers said to to an SKROM by using the SLROM rewiring instructions for the CHR chip and UNROM rewiring for the PRG chip. This doesn't seem to make sense to me, is it true?

See here for reference: http://nesdev.com/bbs/viewtopic.php?t=2 ... 88b8ea274a

[Bregalad]

The instructions shouldn't depend on the board name but on size of the chips. In that regard, all SLROM, SKROM, TLROM, TKROM, etc... boards will have the exact same instructions, and it makes perfect sense. SGROM, SNROM, etc... board will have the same instructions for the PRG chips, and nothing for the CHR obviously.

Smaller size chips have standard pinouts so no rewiring needed if the board is the good one (but you will need some rewiring for size changes, for example to convert from NROM-128 to NROM-256).