What's new

Nes

hap

New member
I'm looking at gbsound3.pdf..

Start with duty and frequency of the square wave channels. For sound channel 1, duty is $ff11.6,7 and frequency is $ff13 and $ff14.0,1,2

The duty is basically an 8 bit buffer, where 0 is no sound output (volume=0) and 1 is sound output (volume=insertvalue). There's a timer that's obtained from the 11 bit frequency like this ($ff13 OR $ff14(012)<<8)*4. The timer is decremented each cpu cycle. Whenever the timer reaches zero, it is re obtained, and the current sample is the next bit from the duty (keep a duty counter that goes from 0 to 7, to 0 again). Create a function with a loop, that writes 1 sample per cpu cycle to a buffer big enough for 1 frame (4mhz/idunnotheframerate). Call this function whenever there's a write to any of the relating sound registers, and at the end of the frame.

In pseudocode:

Code:
const int duty[][]={
	{0,0,1,0,0,0,0,0},
	{0,1,1,0,0,0,0,0},
	{0,1,1,1,1,0,0,0},
	{1,0,0,1,1,1,1,1}
};

channel1_update {
	(cpu_getcycles: i'm assuming you have a cpu cycle downcounter per frame)
	
	for (int cpu_cycles=cpu_getcycles();c1_cycles>cpu_cycles;c1_cycles--) {
		c1_timer--;
		if (c1_timer<=0) {
			c1_duty_counter++;
			c1_duty_counter&=7;
			c1_sample=duty[$ff11.67][c1_duty_counter];
			obtain_timer_from_frequency();
		}
		c1_buffer[c1_buffer_counter]=c1_sample*volume;
		c1_buffer_counter++;
	}
}
At the end of the frame, downsample and do actual sound output.
 

ShizZy

Emulator Developer
Makes a little more sense, huge thanks. Going to need to read this over and over again until I digest it :p
 

|\/|-a-\/

Uli Hecht
i know what the problems are: the palette is written not correctly, if i change the values in debugging mode, the screen looks perfectly!
I think it's an emulation error and the problem is not caused by the ppu.

i started to implement the background scroll register and became confused strongly. Each doc discribes it a very differt way.
I also read $2005 is called PPU Address 2, but i thought that ppu address reg does something else and has nothing to do with bgscroll reg. Emulators handle this different ways and i don't understand what they do when drawing scrolled screen and when writes to $2005 occur...

I hope you have an answer that i understand because i didn't find any documentation which describes it the way i understand it...
 

hap

New member
Read loopy's 'the skinny on nes scrolling' (attachment).. a hundred times :p

small example to describe his logic:
t:0000110000000000=d:00000011
t = (t AND %1111001111111111) OR ((d AND %00000011) << 10), where d is the data you write to that register


and there's 1 typo in it: '(if background and sprites are enabled)' should be '(if background and/or sprites are enabled)'
 

hap

New member
It seems that old ISP account has been deleted, I can't log into my homepage anymore to update it :( So I'll post the new release of my emulator here...
 

hap

New member
blargg's been busy making an NTSC emulator for NES emulators. Some minor issues aside, it looks and feels very much like playing NES games on a real NES connected to a tv..
 

hap

New member
Looks like this thread is Sega Li-only ;) ... anyway.. a new version, which I'll upload here, since I haven't got a homepage yet still

Code:
- drugs wore off, it was a joke anyway
- mappers: support for extended mapper information, thus removing CRC32 checks
  from the mapper source, where it doesn't belong. added correct support for
  Low G Man, and the European SMB+Tetris+World Cup cartridge
- mappers: added iNES mapper 78
- mappers: added some duplicates: 48=33, 100=4, 101=86, 140=66, 158=118,
  184=122
- mappers source: changed mirroring for mappers 70 and 152
- mappers: moved Namco 109 to MMC3, and added Namco 118 (mappers 88, 154)
- fixed detection of uneven prg/chr banks
- mappers: added support for Ai Senshi Nicol in mapper 42
- mappers: added FFE emulation (mappers 6, 8, 17)
- mappers: added Taito X types (mappers 80, 82, 207)
- mappers source: added a lot of shortcuts for commonly used functions
- mappers: added Konami VRC types (mappers 21, 22, 23, 24, 25, 26, 73, 75, 85),
  including emulation of the custom soundchip used in the Japanese version of
  Castlevania 3, Esper Dream 2, Mouryou Senki Madara, and the YM2413 clone used
  in Lagrange Point
- mappers: added iNES mapper 18 (Jaleco)
- mappers: fixed MMC3 IRQ edge timing, that caused screen shaking problems in
  Downtown Special - Kunio-kun no Jidaigeki Dayo Zenin Shuugou!
- fixed a very stupid boundary check bug in the CPU memorymap, causing bad
  sound in mappers 40 and 42 (<=0x4020 instead of <0x4020)
- mappers: added iNES mapper 50
- APU: fixed a bug in the frame sequencer reset timing, introduced in the
  previous version
- debug: tracelogging is cleaner to the eyes now
- CPU: fixed CLI->RTI behaviour (hmm, I thought I fixed that already in version
  1.3), this fixes Paris-Dakar Rally Special, and The Triathron (Engrish
  indeed)
- APU: fixed frame IRQ timing: it was off by only a fraction of a cycle! in
  turn, this fixed Mezase Pachi Pro - Pachio Kun
- CPU: fixed PAL reset timing (the European version of Pac-Man needed a bit
  different timing)
- mappers: mapper 232 Aladdin games are a bit different than the standard
- PPU: added behaviour where the sprite address specifies the location of
  sprites 0 and 1 during evaluation, fixing Tatakai no Banka
- mappers: fixed a small memory leak when closing a game in mapper 69
- PPU: rendering is a bit faster
- changing the open dialog filetype now correctly refreshes the file list
- input: completely rewrote the input module, adding support for multiple
  keyboards, joysticks, and mice, which can be remapped using simple rules,
  also added support for mouse cursor hiding. emulation specific input was
  moved to a separate cont.c module
- source: renamed standard typedefs, to prevent conflicts with the Windows API
- debug: added a simple profiler
- several small speedups
- the loaded game title is shown in the titlebar now
- draw: added auto detection for using DDraw video/system memory, and made it
  optional
- settings: rewrote the settings module, it now saves the emulator's settings
  to a file, that can manually be edited
- sound: added an option to prevent the emulator from sleeping while waiting
  for the play cursor's, and made the secondary buffer resizable
- added a new splash screen
- the currently loaded game is not closed anymore when an error occurs while
  loading a new game
- palette: emphasis colours are more accurate
- better detection on whether the window is in the foreground/background
- sound: less pops and clicks when starting the emulator, or when opening a new
  game (it was writing an unsigned zero, which caused maximum volume)
- file: CRC32 calculation was very slow, not anymore
- file: paths can be changed in the settings file, it also doesn't
  automatically create many new folders on startup anymore, also added support
  for multiple filetypes in one zip file (eg. ROM, palette, IPS patch)
- draw: added true NTSC emulation, though it's not enabled in the default
  build... a fast CPU with support for SSE is needed for this, it looks very
  cool though!

feedback would be nice :D


*edit* removed the files, this is an outdated version, you may get the current version from my homepage (see profile)..
 
Last edited:

smcd

Active member
Is there any way to get/save the palette from the NTSC version? It's playing pretty solid - while the blurring and stuff is original and interesting I still like to play most games looking a bit more crisp than that so I'll probably stick to the normal version of it even though I like the colors better in the NTSC one. Overall it's a good emulator, it even has sound yay! Keep up the good work!
 

hap

New member
Thanks.

blargg's NTSC emulator, or better said simulator since no microprocessors are involved, is not using the commonly used hardcoded 64 colour palette, so its colours can't be saved as a .pal file. Actually the colours should be the same as normal, except for slight differences in brightness, since I'm converting the YUV normal palette to YIQ and feed it to the ntsc emu.. there's probably a bug somewhere in the conversion ;p
 

smcd

Active member
I like the color scheme (when playing super mario brothers for example) the colors look about right for a change instead of having either overly vivid bright colors or washed out purple-looking sky. Oh well, keep up the good work anyhow :)
 

Agozer

16-bit Corpse | Moderator
If you want to see great colors, why don't you give AspiringSquire's palette a try and tell him what you think? I find his palette very accurate.
 

ShizZy

Emulator Developer
Four hours in, and here's what I have to show. I've surprised myself, took me weeks to get this far when I first did my GB emu. :)
 

GbaGuy

New member
How many 'discussions' have there been about which is harder to emulate GB vs. NES?

My vote is for GB being more difficult. The NES mappers aren't really that bad.
 

aprentice

Moderator
GbaGuy said:
How many 'discussions' have there been about which is harder to emulate GB vs. NES?

My vote is for GB being more difficult. The NES mappers aren't really that bad.

i think both consoles have their share of difficulties just in different areas, ive emulated both and thats what i felt
 

hap

New member
Don't rush yourself ShizZy, you'll end up writing crappy code. Though I like seeing a new NES emulator in the works, especially in this thread.

As for NES vs GB difficulty: Aside from about 5 mappers and a few sound chips, mappers indeed aren't difficult to emulate, it's just that there are so many, taking a lot of time if the emulator's a one-man's job.

Lots of NES games are picky about timing, requiring near-perfect emulation. Writing an accurate NES emulator would probably be as hard as writing an accurate GB emulator. But if you're just going for good results (eg. 99% compatibility), a not-so-accurate GB emulator would do the job, while a NES emulator having that same accuracy wouldn't. -- (not that I've had experience writing a GB emulator; just using them, and seeing an inaccurate one run almost all games flawlessly)
 

ShizZy

Emulator Developer
Aye. In my opinion, the 6502 is a much simpler cpu than the Z80 (and inferior to it). GB on the other hand has much simpler hardware, a lot of things are simplified, and it doesn't so much rely on true accuracy, as hap stated.
 

huarifaifa

New member
Aye. In my opinion, the 6502 is a much simpler cpu than the Z80 (and inferior to it). GB on the other hand has much simpler hardware, a lot of things are simplified, and it doesn't so much rely on true accuracy, as hap stated.

Really? I have had a really hard time with timing, interrupts, etc. in my GB emulator to be able to run some games, but its just my first emulation project, so maybe it's the programmer not the GB complexity the problem :)
 

ShizZy

Emulator Developer
GB timing is really easy. Just do cycles+=3; each instruction, and then if(cycles == 114){vblank();}. That should be enough timing to run some simple demos ;)
 

djudz

New member
hi, sorry to ask such dummy question, but i have trouble understanding how ines format works. i really don´t know where the video data is on the .nes file. i think (for mapper 1 at least) first 0x4000 are the prg-rom data, and the following 0x2000 the video data, but i´m not sure of this. maybe is these 0x2000 are the pattern tables. so in that case i don´t know where to find the table names and attributes. can you help me understand that?

note: my english really sucks =]
 

GbaGuy

New member
For mapper 0 (called an NROM board), there's either 16KB or 32KB of
program code followed by 16KB of graphics (the tiles themselves). The program
will create maps, palettes, and attribute tables, etc when it runs.
 

Top