FPGA Based Videogame System

[nitro322]

 

Some cartridge have hardwired horizontal or vertical mirroring and cannot be changed. For the games on these cartridges, having the right mirroring set is essential. Other cartridges can control the mapping via the chips inside them or use a board where the mirroring is always set to a certain method. For those games, it doesn't matter which mirroring mode is set because they can switch it on the fly.

 

NES Mappers 0, 2, 3, 11, 34, 66, 71, 79, 144, 206, 232 and 234 all have hardwired mirroring. The other common NES Mappers have the mirroring, 1, 4, 5, 7, 9, 13, 47, 64, 69, 118, 119, 168, 228 under hardware control or only use one type of mirroring.

 

Thanks for the reply. What you describe makes sense. Just to confirm I'm understanding you, it sounds like you're saying the mirroring setting is inconsequential here as far as playback is concerned because the mapper will control it regardless.

 

However, from an accuracy/preservation perspective, shouldn't the mirroring be set to the mode that's actually used, rather than specifying the "wrong" mode in the header and letting the mapper just correct that upon playback? If the dumper is going to set the mirroring bit in the header, but it sets the incorrect mode, wouldn't that be considered a bug?

 

Obviously this is a minor issue in the grand scheme of things, just trying to learn more about this and, if appropriate, get any bugs fixed for anyone else using this functionality.

[Great Hierophant]

 

Thanks for the reply. What you describe makes sense. Just to confirm I'm understanding you, it sounds like you're saying the mirroring setting is inconsequential here as far as playback is concerned because the mapper will control it regardless.

 

However, from an accuracy/preservation perspective, shouldn't the mirroring be set to the mode that's actually used, rather than specifying the "wrong" mode in the header and letting the mapper just correct that upon playback? If the dumper is going to set the mirroring bit in the header, but it sets the incorrect mode, wouldn't that be considered a bug?

 

Obviously this is a minor issue in the grand scheme of things, just trying to learn more about this and, if appropriate, get any bugs fixed for anyone else using this functionality.

 

On mappers with hardwired mirroring, there will almost always be a pair of pads on the PCB for H and V. On the pad next to the H or the V, but never both, there will be a blob of solder. That solder blob tells the NES whether the game will use Horizontal or Vertical mirroring.

 

See here for Super Mario Bros., a game which only uses Vertical Mirroring :

 

http://bootgod.dyndns.org:7777/image.php?ImageID=3250

 

and here for Wrecking Crew, a game which only uses Horizontal Mirroring :

 

http://bootgod.dyndns.org:7777/image.php?ImageID=3274

 

As you probably know, Super Mario Bros. only scrolls horizontally and Wrecking Crew only scrolls vertically. But a game that can scroll horizontally or vertically, like Metroid or Super Mario Bros. 3 don't have pads for a solder blob. Mirroring is handled within a special chip on the board, which allows the mirroring to be changed on the fly.

 

http://bootgod.dyndns.org:7777/image.php?ImageID=1838

 

http://bootgod.dyndns.org:7777/image.php?ImageID=13097

 

So, for the games that rely on the mapping hardware, the initial state of the mirroring is set by the hardware on bootup.

[Reaperman]

Has anybody had any luck with the master system micro machines game?

I unsuccessfully tried a bunch of different core settings, and am digging up various copies of it now.

[phoenixdownita]

Has anybody had any luck with the master system micro machines game?

I unsuccessfully tried a bunch of different core settings, and am digging up various copies of it now.

That's a Codemaster game that requires the special VDP2 available to PAL machines only from SMS2 onward (and same very rare PAL SMS1 with VDP2).

In NTSC land (on real SMS) it plays weird (haven't tried on PAL SMS with VDP1 to see how it behaves)... there's a part of the screen that's messed up making playing less than ideal to say the least, I don't think I really got past the first race, the garbled gfx really hits you (a little bit like playing Xenon 2 at 60Hz, you just die touching the "garbled" sides, not so at 50Hz).

So told kevtris said his core supports that special mode but I am not sure if it would work correctly at 60Hz and afaik his cores (aside NES) do not support PAL yet.

Now given the VDP2 was PAL only I have not had the chance to try the game on a 60Hz modded PAL SMS2 (I have one in the house just never thought of seeing if that video mode would work in PAL60 or if it would trip the VBLANK with too much computation, and YES I bought that PAL SMS2 specifically because of the VDP2, I was sooooo curious .... meh).

 

This is the "short" list of games with that same requirement:

http://www.smspower.org/Tags/Extra-Height

 

and:

http://www.smspower.org/Development/SMS1SMS2VDPs

 

more technical:

http://www.smspower.org/Development/VDPRegisters

 

and something only for VDP1:

http://www.smspower.org/Development/TilemapMirroring

 

EDIT: so told it is possible that the VDP2 made his appearance on NTSC SMS2, I just never checked.

[Andromeda Stardust]

 

Pretty sure Kevin said save states were not going to happen unfortunately.

It could likely be done with a "twice as big" FPGA, or at least enough RAM to dump the state of every CPU register as well as bankswitch data and SRAM for currently loaded ROM. If the Z3k has enough horsepower to implement SNES, then it might be able to pull off a state saver core, at least for a few of the 8-bit systems. Basically another addon FPGA core would run in tandem to the classic console core, with 2x memory required to dump everything to SD card. So if the NES core needed X LEs and Y RAM, then the NES save state core might need 2*X LEs and 2*Y RAM. And it wouldn't work on carts. And attempted loading of a save state from a previous firmware version may or may not crash the system.

 

BTW, save stating in PC / mobile NES emulators is extremely easy when the core emulator only takes up less than 1% of system RAM. Doubling the resources to 2% is nothing.

[Andromeda Stardust]

I tried the Raphnet adapter with the Famicom Network Controller and it works fine as an NES controller but the number buttons don't register in the Colecovision core. They buttons work just fine when plugged into the accessory port of course.

 

Would be nice if compatibility with the number buttons were possible through the front port.

How many wires does the Famicom Network controller actually use? You could open up the controller with a screwdriver without damage.

 

My original theory was that the Famicom Network Controller simply streamed more than 8-bits of serial data, but said bits may not have the same logical order starting with bit 9 (counting the first logical bit as 1), due to the fact that SFC/SNES controllers must supply 4 additional button inputs plus 4 key bits.

 

If the Famicom Network Controller has more than five wires inside the cable, then it is highly likely sending data to other pins besides D1; in this case, a simple D15 to NES adapter would be out of the question for anything besides the standard 8 buttons.

[Andromeda Stardust]

 

On mappers with hardwired mirroring, there will almost always be a pair of pads on the PCB for H and V. On the pad next to the H or the V, but never both, there will be a blob of solder. That solder blob tells the NES whether the game will use Horizontal or Vertical mirroring.

 

See here for Super Mario Bros., a game which only uses Vertical Mirroring :

 

http://bootgod.dyndns.org:7777/image.php?ImageID=3250

 

and here for Wrecking Crew, a game which only uses Horizontal Mirroring :

 

http://bootgod.dyndns.org:7777/image.php?ImageID=3274

 

As you probably know, Super Mario Bros. only scrolls horizontally and Wrecking Crew only scrolls vertically. But a game that can scroll horizontally or vertically, like Metroid or Super Mario Bros. 3 don't have pads for a solder blob. Mirroring is handled within a special chip on the board, which allows the mirroring to be changed on the fly.

 

http://bootgod.dyndns.org:7777/image.php?ImageID=1838

 

http://bootgod.dyndns.org:7777/image.php?ImageID=13097

 

So, for the games that rely on the mapping hardware, the initial state of the mirroring is set by the hardware on bootup.

Mirror bits 01, 10 normally designate horizontal or vertical.

 

AA

BB

 

or

 

AB

AB

 

Then there's 11 for 4-way mirroring (requires on cart PPU-RAM - used in Micro Machines and certain other titles, as well as Memblers homebrew GT-ROM, which don't play nice with NOAC clones)

 

AB

CD

 

And 00 for mirroring disabled (rarely used)

 

AA

AA

 

or mapper defined mirroring, where IIRC the mirror bits are basically ignored in header.

 

Then some other obscure stuff like "diagonal" mirroring

 

AB

BA

 

which can allow for both horizontal and vertical scrolling but never both at the same time (no diagonals).

[Reaperman]

That's a Codemaster game that requires the special VDP2 available to PAL machines only from SMS2 onward (and same very rare PAL SMS1 with VDP2).

 

 

Thanks for the info--I won't hold my breath on oddballs like that. GG version also appears to have issues.

I was just doing more of my odd new habit of comparing different versions of the same game across cores.

Edited April 15, 2017 by Reaperman

[phoenixdownita]

 

Thanks for the info--I won't hold my breath on oddballs like that. GG version also appears to have issues.

I was just doing more of my odd new habit of comparing different versions of the same game across cores.

Some of the GG versions of SMS games were actually using the SMS mode of the GG (literally the GG runs the game as an SMS game and does scaling at the display level only), if this is one of those I am not surprised it has issues either way or maybe kevtris core for the GG does not implement SMS mode as it has an SMS core after all (like he did for 7800 core, no 2600 mode).

 

Again the VDP2 may have made it to NTSC land in SMS2 form but not sure if the 60Hz would allow it to run fine in that config (as mentioned if MicroMachines behaves like Xenon 2 it only kind of works but not really), we'll let kevtris chime in.

[Great Hierophant]

Mirror bits 01, 10 normally designate horizontal or vertical.

 

AA

BB

 

or

 

AB

AB

 

Then there's 11 for 4-way mirroring (requires on cart PPU-RAM - used in Micro Machines and certain other titles, as well as Memblers homebrew GT-ROM, which don't play nice with NOAC clones)

 

AB

CD

 

And 00 for mirroring disabled (rarely used)

 

AA

AA

 

or mapper defined mirroring, where IIRC the mirror bits are basically ignored in header.

 

Then some other obscure stuff like "diagonal" mirroring

 

AB

BA

 

which can allow for both horizontal and vertical scrolling but never both at the same time (no diagonals).

 

This isn't quite correct. The bits work like this :

 

3210

0..0 = Horizontal Mirroring

0..1 = Vertical Mirroring

1..x = 4-screen Mirroring (x = don't care)

 

Note that the bits are not adjacent to each other in the NES header. If the mapper number indicates that the mirroring is under mapper control, then lower bit is ignored. The upper bit is not ignored, because a mapper like the MMC3 cannot do 4-screen mirroring on its own. I am not aware of any hardware that allows for diagonal mirroring, but it could be done.

 

This describes mirroring in better detail : http://wiki.nesdev.com/w/index.php/Mirroring

[Great Hierophant]

Also, Micro Machines for the NES does not use 4-Screen Mirroring. All Codemasters games use vertical mirroring with the exception of Fire Hawk, which does single screen mirroring.

Edited April 15, 2017 by Great Hierophant

[retrorgb]

A little more seriously, if it had been possible to support the Game Boy Advance with currently "affordable" FPGAs, I would have envisioned the possibility of you starting a new project with Analogue to create a sequel to the Analogue NT Mini, one that would have featured a Game Boy cartridge port instead of Famicom/NES cartridge ports. It could have supported GB, GBC and GBA games, and it could sport the same NES controller ports (although the GBA shoulder buttons would be a slight problem, now that I think about it...). Anyway, a nice little console to play GB/GBC/GBA carts on the living room HDMI TV.

 

Just daydreamin'...

 

What you're asking for is already in the works and will use a SNES controller: http://shmups.system11.org/viewtopic.php?f=6&t=56870

[Andromeda Stardust]

This isn't quite correct. The bits work like this :

 

3210

0..0 = Horizontal Mirroring

0..1 = Vertical Mirroring

1..x = 4-screen Mirroring (x = don't care)

 

Note that the bits are not adjacent to each other in the NES header. If the mapper number indicates that the mirroring is under mapper control, then lower bit is ignored. The upper bit is not ignored, because a mapper like the MMC3 cannot do 4-screen mirroring on its own. I am not aware of any hardware that allows for diagonal mirroring, but it could be done.

 

This describes mirroring in better detail : http://wiki.nesdev.com/w/index.php/Mirroring

 

Also, Micro Machines for the NES does not use 4-Screen Mirroring. All Codemasters games use vertical mirroring with the exception of Fire Hawk, which does single screen mirroring.

Thank you for correcting me. It's been a while since I read the online docs and my recollection is less than perfect.

[genfuyung]

Sad this thread had slowed to a crawl without Kevtris' updates.

[Keatah]

Glad that it has because it supposed to be about the next upcoming system from him. And the last 80 or so pages don't really discuss that.

[+eebuckeye]

If that is the case then we should have a thread just about the NT Mini. Kevtris mentioned other cores and that he would work on bugs but it would be slower. I'm sure he will be back.

[cacophony]

All of the work on the Nt Mini cores will directly benefit the Z3K, so it seemed pretty relevant to this thread.

Edited April 19, 2017 by cacophony

[Wolf_]

Just because Kev is busy with other work doesn't mean he won't be back. Besides we have been getting the pre-made cores Kev spent ages on with the weekly updates so once we get to systems he hasn't experimented with yet the updates will slow down anyways. Just be patient. (We don't want him to get sick of working on it either.)

[Andromeda Stardust]

If that is the case then we should have a thread just about the NT Mini.

There is. See also "Analog NT Mini Hardware":

http://atariage.com/forums/topic/263325-analogue-nt-mini-hardware/

 

But NT Mini discussion continued in both threads rather than migrate to the other one. Maybe since Kevtris kept posting updates here. It is his brainchild, after all...

[atmn]

Got a design question I've been wondering about.

 

Whats the benefit to place a square shaped IC such as the FPGA.s at a 45 degree angle on the PCB?

[Keatah]

Imagine you are a tiny guy with a survey camera standing on the left side of a rectangular board. And the chip is mounted in the middle. With the chip at right angles, you will only see one of four sides side of the chip. But if you skew the chip's rotation by 45 degrees, now your survey camera can see two sides of the chip! It will see 2x more pins.

 

It's basically for routing purposes, it enables 2x the amount of traces to go in any of the 4 cardinal directions. There's also the issue the wave soldering (which isn't done much anymore). An offset angle will prevent shorts.

 

Practically, any part and be placed at any angle these days. And any one given orientation may save a lot of extra routing and vias if done one way as opposed to another.

Edited April 19, 2017 by Keatah

[ApolloBoy]

Again the VDP2 may have made it to NTSC land in SMS2 form

It did, actually.

[Andromeda Stardust]

Got a design question I've been wondering about.

 

Whats the benefit to place a square shaped IC such as the FPGA.s at a 45 degree angle on the PCB?

I think the IC should be hexagon and tilted 30 degrees, like a snowflake. But what do I know?

 

I think Keatah is right. It may have to do with PCB trace routing or component placement making it easier. Accelerometers/Gyros should definitely be positioned correctly. Same with photodiodes and sensors. Everything else, really doesn't effing matter. You could have the little SMT pins wire wrapped with 40awg wire if you wanted, but it would be neither robust nor cost effective, and "rats nest" wiring don't play nice with HF signals. Imagine wire wrapping a BGA, the nest of wires exploding out!

[atmn]

Imagine you are a tiny guy with a survey camera standing on the left side of a rectangular board. And the chip is mounted in the middle. With the chip at right angles, you will only see one of four sides side of the chip. But if you skew the chip's rotation by 45 degrees, now your survey camera can see two sides of the chip! It will see 2x more pins.

 

It's basically for routing purposes, it enables 2x the amount of traces to go in any of the 4 cardinal directions. There's also the issue the wave soldering (which isn't done much anymore). An offset angle will prevent shorts.

 

Practically, any part and be placed at any angle these days. And any one given orientation may save a lot of extra routing and vias if done one way as opposed to another.

Sounds very reasonable. Makes sense.

Also, it looks cool.

[Keatah]

Modern placement machines have no preference for orientation. Early ones absolutely did.

 

Additionally I believe (but cannot confirm) it was early layout software that liked right angles, 0, 90, 180, 270, 360. Anything in between simply wasn't available. And of course there is aesthetic influence of the engineer doing it up.

 

People also tend to work in grids. Look at most city layouts, there's a regular grid. Like boards. Like microchips. Wonder when we'll see complex chips like uP have non-linear curved wiring? If ever. I know they do it in micro gas-chromatographs and other chemical analyzers. RF too, RF hates right angles - too many radiating points. That's why you see USB data lines curved on a board full of straight traces.