This is perhaps a pretty pointless post, but anyway..
Let's imagine a NES console with a modern CPU, something like a 2-3GHz CPU but with the same graphics capabilites as the real NES.
Assuming this was possible, how do you think NES games / homebrew would look? Would it even be fun to code on a 2GHz NES?
I'd say they'd be the same, unless you removed the 8 sprites/scanline limit. If that weren't there, and you could put nearly as many as you wanted per scanline......stuff would get crazy I think!
What Zepper said + big explosion at the end.
Actually, this makes sense if you want to make very authentic looking NES-style retro game or demake for PC or other modern system - emulate PPU and APU, with game code in the system's native code.
using the original ppu would bottleneck you pretty good when it comes to making games so not particularly different.
I seem to remember someone making a PCI (or was it ISA?) card with a NES PPU on it, and put that on a modern (at the time) computer. It was a 133MHz Pentium I think, which is nowhere near 2GHz but is a lot faster than the regular NES CPU. I believe he successfully controlled the PPU with PC code, doing essentially what is suggested in this thread.
http://web.archive.org/web/200505041514 ... esvidcard/ (insanely slow)
I think it's pointless project (as would be a PC game using NES constraints) but I would like to see what someone could do with it nonetheless. I'd rather see someone use emulator PPU/APU code than repurpose real game hardware.
A fast CPU (and fast memory and no PPU bottleneck) would allow you to:
-update nametables, attributes and CHR-RAM per rendered BG tile
-update the palette during Hblank
-use a really complex sound engine, with steaming PCM etc
-use intensity bits on a pixel basis?
- Perhaps a dumb question, but how would you control the PPU refresh rate, of ~60hz?
Zepper wrote:
- Perhaps a dumb question, but how would you control the PPU refresh rate, of ~60hz?
I think you don't really have to do anything... it's still clocked at the same frequency as in the NES, so it will generate frames at the same rate...
tokumaru wrote:
Zepper wrote:
- Perhaps a dumb question, but how would you control the PPU refresh rate, of ~60hz?
I think you don't really have to do anything... it's still clocked at the same frequency as in the NES, so it will generate frames at the same rate...
- I didn't get the idea. If it's a 1ghz CPU, I suppose the "new" NES would run at such speed; by clocking at ~1mhz, seems to lose the "essence" of more speed... ?
Graphics would look at least PlayStation 1 quality, if a bit grainier.
Imagine a TV tuner cartridge for the NES. An ASIC on the cartridge reads a 256x240 pixel frame buffer, determines the best of four palettes for each 8x1 pixel sliver, and then dithers the pixels down to the NES's 2bpp and feeds them to the PPU. It also collects statistics on the color distribution to choose the palettes for the next frame. Now imagine a typical smartphone system-on-chip, with a 1 GHz ARM CPU and integrated PowerVR GPU, rendering to this frame buffer.
kyuusaku wrote:
I think it's pointless project (as would be a PC game using NES constraints)
You appear to claim that a
retraux art style in a video game is pointless. The developers of Eversion, La-Mulana, Mega Man 9, and I Wanna Be the Guy disagree.
Zepper wrote:
- I didn't get the idea. If it's a 1ghz CPU, I suppose the "new" NES would run at such speed; by clocking at ~1mhz, seems to lose the "essence" of more speed...
In this thought experiment, the CPU is clocked orders of magnitude faster, but the PPU is clocked at the same rate as the NES PPU.
This leads me to wonder just how far the PPU can be overclocked, before it starts to fail. o_O
Either way, maybe you could keep the NES cpu as a sound co-processor, kinda like what the SPC-700 is to the SNES.
tepples wrote:
Graphics would look at least PlayStation 1 quality, if a bit grainier.
Imagine a TV tuner cartridge for the NES. An ASIC on the cartridge reads a 256x240 pixel frame buffer, determines the best of four palettes for each 8x1 pixel sliver, and then dithers the pixels down to the NES's 2bpp and feeds them to the PPU. It also collects statistics on the color distribution to choose the palettes for the next frame.
Not unlike Trixter's
text-mode video for the CGA or the
Text-Mode Demo Competion. "Collecting statistics" is as easy as temporal Floyd-Steinberg dithering. The hardest part is figuring out which four three-color palettes you're going to be stuck with each field.
lidnariq wrote:
The hardest part is figuring out which four three-color palettes you're going to be stuck with each field.
Yes, the
cluster analysis is complicated by the 0123, 0567, 09AB, 0DEF structure of the palette.
Drag wrote:
maybe you could keep the NES cpu as a sound co-processor, kinda like what the SPC-700 is to the SNES.
Yeah, you'd still need it to feed the mixed audio to $4011, to read the controllers, and possibly to stuff the palette depending on how the PPU is connected. It'd become an IOP, like the MC68000 on the Jaguar, or the PS1 MIPS on the PS2, or the ARM7 on the DS, or the "Starlet" ARM9 on the Wii.
I thought about this before. Was going to put the PPU on an ISA card, and put it in the fastest cpu/motherboard I could find with ISA.
Timing might be an issue, unless you clock the CPU at some multiple that the PPU has to run at. (Correct me if I'm wrong about that).
I think even the NES 6502 is good enough for maxing out what the PPU can do, I think you'd need to add more sprites without a scanline limit to need a better CPU to take advantage of anything. Anyone up for making some 2GHZ 6502's with some new 256-sprite no-limit sprites? That'd be amazing, the world needs an epic easy-to-progam 2D PPU, haha.
The easy-to-program 2D PPU is the SDL graphics API. Because it uses a pair of frame buffers, there's no sprite limit apart from fill rate.
That is interesting, because then you could also do bitmapped graphics with an SDL-like NES PPU without limits of sprites, would be awesome. One bad thing is that software would have to put "sprites" on the screen from it, unless it has the bitmapped layer over/under it. Oh well what's it matter, that's too much. >.< And maybe we could also add image-loading already optimized. Haha, that part of SDL sucks ever since I worked through the tutorial. >.>
This is the same kind of "what-if" question that got me started on the Squeedo project. I estimated the PIC18 I used was 5 times faster than the NES CPU. The PIC I will use on the redesign might be be 50 times faster, I'm not sure exactly.
I've been wanting to make the ultimate memory controller sometime too, that could be used with this and allow movements of obscene amounts of data on the PRG and CHR buses.
If there was much interest in something like this, it could be helpful to the project. I can make the hardware and stuff, but it pretty interesting if I'm not the only person to write software for it. The newer one could be programmed in C and/or MIPS32 assembly (kinda amusing that it's related to the N64's CPU). Seems like it would be easy to run a 6502 emulator on there. Maybe one could have it use the PPU and sound registers to "emulate" the NES, running the code in a virtual machine.
3gengames wrote:
MMC7? I'm in.
Membler's
Master
Controller, version
7. Awesome.
Seriously, Let's design a mapper that we want, get it into a few emulators for testing, port our games to it and make stuff.
My mapper wish list:
- prog-rom: $e000-$ffff = fixed
- prog-rom: ROM from $8000 to $dfff swappable in 8K banks (8K alignment).
- Up to 256K char-rom or char-ram, swappable in 16-sprite banks.
- 8K bram (but I can see making this larger and swappable in banks too).
- 2 IRQ scan-line counters. **
My idea for how IRQ scanline - counting would work is as follows:
- Game writes the desired scan-line (or scan-line minus one) to a pair of mapper registers, 0xf0 - 0xff to disable (just like a sprite Y coord).
- In game's NMI handler, FIRST instruction after NMI is to "bit" another mapper register. This triggers the countdown circuit inside the mapper. (Basically, any read to this address triggers the countdown to start. Can be abused mid-frame to get more than 2 IRQs per scan-line I guess)
- IRQ automatically fires approximately during hblank at the end of the line before the desired scan-line.
If we do this, I'd want 64K SRAM switching with 512KB CHR-RAM/ROM and 512KB PRG space. Agreed on PRG-bank being fixed being the last one, but I'd prefer 8KB chunks....or even adjustable size?
Hope we don't end up causing someone to do a ton of work, but if anyone wants to make their own mapper for shits and gigs, this'd be nice to tinker with.
I'm sure even more homebrew start out like this... "I wanna make an NES game, hahah....how funny.....I guess I'll look into it."
Maybe I was confusing. prog-ram from $8000 to $dfff would be divided into 3x 8K banks, each individually swappable with any 8K aligned, 8K chunk of the entire prog-rom, upto the max prog-rom size.
I would engineer a large game to use the CPU's address space as follows:
$8000 to $9fff = map data
$a000 to $bfff = sound data
$c000 to $dfff = swappable game logic
$e000 to $ffff = kernel and "library" routines, NMI handlers, main control code.
I assume that 8K chunks are easier, but in reality, I'd think that 8K is a bit over-kill or swapping sound data. 2K or 4K sized banks would probably be all that is needed for swapping sound data (2K per song set?) However, I've never designed a mapper, so I have no idea how feasible it is to have different sized banks.
Maybe just have 8x 4K banks, with the last one fixed. Bank switching should be accomplished by a simple memory register write (not like MMC1 - takes way too many clock cycles).
Why put PRG-RAM expansion on top of ROM? I hope you mean $6000-$7FFF. Makes it alot easier then putting it over ROM I think. Especially when you need to read ROM and RAM, I don't think it works like that on the NES?
3gengames wrote:
Why put PRG-RAM expansion on top of ROM? I hope you mean $6000-$7FFF. Makes it alot easier then putting it over ROM I think. Especially when you need to read ROM and RAM, I don't think it works like that on the NES?
Yes, I mistyped. I meant prog-rom.
MMC7, that's funny.
I guess it would be the first cart without PRG-ROM. Of course the 2A03 still has to boot into something, but it's only 1 byte of ROM. Program code/data would be stored in a serial Flash memory, the mapper would allow the PIC to copy (hopefully DMA) it into RAM whenever requested, even while the NES CPU and PPU are both using the memory. The RAM isn't huge (and I don't think SDRAM will be fast enough), but it's plenty for use with bankswitching.
This would be very different from any other mapper. Instead of WRAM, maybe you'd want to map some CHR tiles or nametables into $6000-$7FFF and write to CHR anytime. Maybe instead of CHR banking, something like MMC5's EXRAM could be used. Just some options.
Sounds a little over-complex to me, haha.
Whatever you decide on though?
I have something kind of related. I wanted a way to upgrade some NES emulation projects that I had going. But all the approaches I looked at always involved breaking some sort of compatibility and/or writing to a lower level system hardware (though through NES cpu code) and also a tons of hacking of the original routines. So I looked at the OAM format. Found some unused bits and added addition graphic support. Extended PPU functionality:
Code:
NES OAM attribyte byte:
76543210
||||||||
||||||++- Palette (4 to 7) of sprite
|||+++--- Extended
||+------ Priority (0: in front of background; 1: behind background)
|+------- Flip sprite horizontally
+-------- Flip sprite vertically
Extended:
D2 = High palette bit
D4-D3: Sprite size
00b = 8x8 NES flipping based on 8x8
00b = 16x16 Native flipping (if upper palette bit set)
01b = 32x16 Native flipping
10b = 16x32 Native flipping
11b = 32x32 Native flipping
Now I can have both original sprite support and extended sprite support. The colors are extended to 4bpp too, but I need to add some DMA commands that will write to the additional bit planes on vram. They're zero'd out normally, so normal NES tiles show as normal.
tomaitheous wrote:
I have something kind of related. I wanted a way to upgrade some NES emulation projects that I had going. But all the approaches I looked at always involved breaking some sort of compatibility and/or writing to a lower level system hardware (though through NES cpu code) and also a tons of hacking of the original routines. So I looked at the OAM format. Found some unused bits and added addition graphic support. Extended PPU functionality:
Code:
NES OAM attribyte byte:
76543210
||||||||
||||||++- Palette (4 to 7) of sprite
|||+++--- Extended
||+------ Priority (0: in front of background; 1: behind background)
|+------- Flip sprite horizontally
+-------- Flip sprite vertically
Extended:
D2 = High palette bit
D4-D3: Sprite size
00b = 8x8 NES flipping based on 8x8
00b = 16x16 Native flipping (if upper palette bit set)
01b = 32x16 Native flipping
10b = 16x32 Native flipping
11b = 32x32 Native flipping
Now I can have both original sprite support and extended sprite support. The colors are extended to 4bpp too, but I need to add some DMA commands that will write to the additional bit planes on vram. They're zero'd out normally, so normal NES tiles show as normal.
I was doing something like that, but I had two things: lack of coding and still using 8x16, not to mention it is a failure for any NESDev compatibility hardware-wise
There was the VR Technologies VT03/VT02/Onebus, but it's documents were machine translated from chinese. and anyone who tried to redocument it left it for dead because of no more interest.
CaH4e3 of FCEUMM and Russian Romhacking Fame decoded the Onebus Famiclone series part-way, but at 2011 there was no more news so far, But he still works at BMF and Xkeeper's ''The Cutting Room Floor'' Wiki
EDIT:
Code:
NES OAM attribyte byte (specefication v0.2 alpha/discussion mode):
Original by Tomaitheous of PCEDEV (PC-ENGINE Dev forums)
76543210
||||||||
||||||++- Palette (4 to 7) of sprite**
|||+++--- Extended/Enhanced NES Sprite support
||+------ Priority (0: in front of background; 1: behind background)
|+------- Flip sprite horizontally
+-------- Flip sprite vertically
if it is Extended, original NES/Fami 8x16 mode must be
disabled and must choose a extended Size specified below!
Extended: 000b = 8x8 2bpp NES - Original format
001b = 8x16 2bpp NES - Original format
010b = 16x16 2bpp NES - Extended format
011b = 8x8 4bpp SNES - Extended format
101b = 8x16 4bpp SNES - Extended format
110b = 16x16 4bpp SNES - Extended format
111b = 32x32 4bpp SNES - Extended format
** = Palette: 2bpp = Same as original - $3f00-$3f10
4bpp = Extended palette - $3f00-$3fff
$3f00-3f0f for four 2bpp BG palette RAM
$3F10-3f4f for four 4bpp Sprite/OAM Palette RAM
$3F50-3fff Scratch RAM