nesdev.org

rainwarrior wrote:That one day could be any day you choose, even today.

But I have to learn first, and that could take a while.

rainwarrior wrote:Why don't you give it a shot?

orlaisadog wrote:I don't have enough experience yet- I know a lot about how the NES works in theory from browsing the forums but can't do much assembly. I could do it myself one day, probably.

Is anyone considering making this?

lidnariq wrote:Oh, gosh. That's certainly clever, but given that OAM isn't readable on older PPUs (2C02A,B,C,D,E, most Famicoms) and OAM can only be accessed sequentially on the 2C02G (writes to OAMADDR cause corruption), I doubt it's practical.

Oh, OK.

lidnariq wrote:Well, that's why you wouldn't use the OAM shadow, but why do you need OAM at all?

Also, you can store the OAM shadow in ROM, although that's wasteful and constrains what you can show.

I mean the OAM itself as extra RAM. We can do forced blanking during game logic.

I've just realised that OAM memory will decay if forced blanking is used. Could sprites be turned on occasionally during emulation to keep it refreshed or would there not be enough time? What would you be using OAM for here? The CHIP-8 "sprites" seem to be more accurately called a bitblit...

Most likely something T9-inspired since keyboards aren't an option. 35 opcodes would be no match for a d-pad hexnumpad + action button. What about an assembler with the attached layout (I haven't made anything properly yet)? The categories come from https://en.wikipedia.org/wiki/CHIP-8 and the name...

I thought it would be like PocketNES, maybe with a GUI with options on graphics (affects CHR ROM data so cannot be changed at runtime). However, an IDE would be interesting. It would probably need the Family BASIC keyboard though. Oh, I didn't read your post properly.

I've just realised that OAM memory will decay if forced blanking is used. Could sprites be turned on occasionally during emulation to keep it refreshed or would there not be enough time?
Edit: Offtopic but I just read that the decay is affected by temperature. Could there be a NES thermometer?

1000 would be too much for the NES to handle, because even though many of the operations are simple, you still have to fetch the instruction, decode it, update the VM state, and so on, for every instruction. Also, drawing sprites is a fairly slow process, since it involves bit shifting, bitwise ope...

bazza wrote:http://wiki.nesdev.com/w/index.php/APU_Noise

For the channel noise uses this?

Yes... The APU noise... uses APU noise??? What?

I've been reading about the CHIP-8 and it does seem like games can run at fairly slow speeds... This is an emulator that lets you select the number of cycles per frame, starting at 7 and going all the way up to 1000. That seems very doable on the NES, which could probably even handle an SCHIP imple...

That page wrote:a function we can tick at 500Hz

So it is 500Hz?

In this page someone mentions using a clock speed between 500Hz and 1MHz, which doesn't sound right, so maybe they actually mean KHz rather than Hz? If that's really the case, then we might be in trouble... 9000 instructions per frame really wouldn't be possible. CHIP-8 was designed for old compute...

Yeah, I've seen the number being mentioned, but I'm not sure what it means. It definitely isn't CPU cycles as we're used to measuring on the NES, because 540 instructions per second (assuming each instruction is one cycle) isn't nearly enough to make a game with any sort of real time interaction. T...