Verilog and the Powerpak

[never-obsolete]

I've been reading up on Verilog and modified one of loopy's mappers, but I have 2 questions:

1. what software would I use to synthesize the code?

2. how likely am I to damage the powerpak with ill formed logic?

[lidnariq]

Writing new fusemaps for the PowerPak requires a copy of and key for an old version of Xilinx ISE—ISE 10 was the last one to support the Spartan 2.

As long as you get your pin directions correct, you shouldn't be able to damage anything. The synthesis tool should prevent anything problematic.

However, do make sure to test your fusemaps in simulation before you actually use them on hardware.

[never-obsolete]

So I got a key for and installed ISE 10.1, but have a few more questions.

I decided to take a step back, and first get a known to be good example working. I created a new project targeting XC2S30 -5 TQ144. Then added powerpak.ucf, powerpak.v, and map45.v from Loopy's mappers to the project. Built it using Process > Implement Top Module, which spit out powerpak.bit with some warnings but no errors.

1. From your previous post, what are fusemaps?
2. Is powerpak.bit the output file I want?
3. Page 16 of this quick start quide walks through creating a Test Bench WaveForm. Would I adapt that process and create my own to test the fusemaps?

[thefox]

2. Is powerpak.bit the output file I want?

Yes. However, you need to prepend a short loader (1024 bytes) to produce a .MAP file. This is just 6502 code that is executed to configure the FPGA from the bitstream that comes after the loader. You can copy it from an existing official mapper, unless you want to make some customizations. The .bit file should be 42169 bytes, if I'm not mistaken.

[lidnariq]

1. "fusemap" is an accurate term for the result of synthesis targetting a CPLD, PAL, or some nonvolatile programmable logic. It's a bit of a misnomer for FPGAs where the entire state is in RAM, but.

3. Yes.

[NovaSquirrel]

which spit out powerpak.bit with some warnings but no errors.

And I think there's always going to be warnings, because it's complaining about the fact that the CHR output address isn't continuous.

For making the mapper file out of the powerpak.bit, I ended up just taking the first 1024 bytes from an official .MAP and putting it in stub.map then I made a batch file with copy/b stub.map+powerpak.bit MAP6F.MAP to let me combine them with a few clicks.

[Bananmos]

I've tried to do some mapper development this weekend, making a mapper30 implementation. (based on Loopy's mapper sources)

But I seem to have fall into an unexpected pitfall: My mapper30 *only* works with TheFox's pc2nes software. When I put the .MAP file on the cartridge and try to load any ROMs from the powerpak OS, I just get a garbage screen.

Current state of the mapper30 implementation can be found here:
https://drive.google.com/open?id=1ifLP6 ... -kRehJg7Fz

As mentioned, it works with the pc2nes tool, but does not support 4-screen/singlescreen mirroring with that tool, due to iNES byte 6 being ANDed with 1 when written to the mirroring configuration register. So there's already a bit of a difference between the pc2nes software/Powerpak OS. Though that difference doesn't really explain it not working at all.

Or it could just be my Verilog that is FUBAR. But would anyone know about any specific differences between pc2nes and the Powerpak OS NES ROM loading and configuration?

The pc2nes program has source to study, but the Powerpak OS does not. And as I'm going on a long holiday from in 24 hours from now I won't have much ability to debug. It's one of those times where I've started a project on a tight deadline and wish I could turn the almost-working to actually-working, just to have it off my mind for the next few weeks. So any last-minute tips would be much appreciated...

EDIT: Just realised there ARE sources for the Powerpak. So at least it should make debugging this easier when I'm back...

[thefox]

Where did you take your mapper loader (the first $400 bytes of the .MAP file) from? It looks like it isn't the same as the one used in, e.g., loopy's mappers.

That could explain the difference since pc2nes completely ignores the loader.

[Bananmos]

Where did you take your mapper loader (the first $400 bytes of the .MAP file) from? It looks like it isn't the same as the one used in, e.g., loopy's mappers.

That could explain the difference since pc2nes completely ignores the loader.

Thank you!! After using the first 1024 bytes from Loopy's mappers, it works perfectly.

Here's the new version: https://drive.google.com/file/d/1dreb8f ... YuQvu/view

I think the header I got was from the official .MAP files from Bunnyboy, but not sure (will double-check when I'm back). And I'm still a bit confused as to why the loaders are different. I also noticed that different .MAP files do have different sizes. (the Loopy ones are 43193, including the 1024 bytes header) But nevermind... just happy to have this wrapped up for now!

[never-obsolete]

Is the PowerPak able to see the values for PPU A0..A13?

I'm trying to watch for name table reads. I believe A13..12 would be %10. Then, if A9..A6 == %1111, attributes are being accessed. This is the table I came up with:

Code: Select all

	1111
	32109876543210
	nn  aaaa
	00000000000000		= 0000
	‭01000000000000‬		= 1000
	
	‭10000000000000‬		= 2000
	‭10001100000000‬		= 2300
	‭10001110111111‬		= 23BF
	‭10001111000000‬		= 23C0
	‭10001111111111‬		= 23FF
	10010000000000		= 2400
	
	‭10011111000000‬		= 27C0
	‭10101111000000‬		= 2BC0
	‭10111111000000‬		= 2FC0
	
	‭11000000000000‬		= 3000

[lidnariq]

Yes, the powerpak has access to all of the CPU & PPU pins on the card edge.

If you find the "reference powerpak CNROM source" it contains "map03.pcf" which specifies what each of the pins are connected to. But I'll recap here:

BOOT_ENABLE — whether the boot ROM is enabled
All the NES_ pins are from/to the cart connector:
NES_CHR_A0 through NES_CHR_A13
NES_CHR_D0 through NES_CHR_D7
NES_CHR_RD and _WR
NES_CIRAM_CE
NES_CLK - the 21.5 or 26.6MHz clock
NES_IRQ
NES_M2
NES_PRG_A0 through NES_PRG_A14
NES_PRG_CE
NES_PRG_D0 through NES_PRG_D7
NES_PRG_RW
All of the RAM_ pins are to the two 512 KiB SRAMs on the cart:
RAM_CHR_A0 through RAM_CHR_A2 - for MMC5 left-and-right split support
RAM_CHR_A10 through RAM_CHR_A18
RAM_CHR_CE
RAM_PRG_A13 through RAM_PRG_A18
RAM_PRG_D0 through RAM_PRG_D7
RAM_PRG_RD
RAM_PRG_WR
And these two are to the 32 KiB SRAM on the cart:
WRAM_PRG_RD
WRAM_PRG_WR

[never-obsolete]

I've been trying to figure out how to put data into PPU D0.D7 but haven't had any luck. I started out by filling the attribute tables with palette 0 in software, and trying to force them all to palette 2 in hardware.

For bus control I have:

Code: Select all

assign neschr_oe=neschr_rd & ({chrain[13:12],chrain[9:6]}==6'b101111);

I'm not sure if it should be !neschr_rd since the wiki says PPU /RD will be low when data can be placed on the bus.

The logic is:

Code: Select all

	always@* begin
		if ({chrain[13:12],chrain[9:6]}==6'b101111)
			neschrdout=8'b10101010;
		else
			neschrdout=8'bx;
	end

I've also tried this on negedge and posedge of neschr_rd.

[lidnariq]

I assume you're also keeping the NES's internal RAM off the bus?

Otherwise, check polarity. Active-low signals (such as the enable signals from the PPU and to the various RAMs) might have been pre-inverted for your convenience... or may not.

[never-obsolete]

I assume you're also keeping the NES's internal RAM off the bus?

Turns out this was it. After adding some logic to control ciram_ce, everything started working. Thanks!