Search found 1547 matches

by Near
Fri Jun 09, 2006 1:21 pm
Forum: NESdev
Topic: reading controller status when strobe bit is set
Replies: 9
Views: 6165

o.O news to me. Ok, so when $4016.d0 is set, the read position is reset to 0 (status of A), and all reads from $4016 at this point return the status of A, at the time of reading $4016 , as if having the strobe bit set means the NES is constantly polling the joypad in realtime, and acts basically lik...
by Near
Thu Jun 08, 2006 1:26 pm
Forum: NESemdev
Topic: Lega issues: June 2006
Replies: 28
Views: 8926

The law doesn't have to be logical And rarely is. I won't drag a political argument here, but I can name at least five areas of law that were created solely through racism, bigotry and corporate lobbying that have absolutely no positive value to society whatsoever. Why should laws based around gree...
by Near
Fri Jun 02, 2006 11:35 pm
Forum: NESemdev
Topic: dd routines interface
Replies: 12
Views: 5582

If your filter is 32bpp-only, eg HQ2x, then you rewrite it to be 16-bit :D Ask blargg, he has a really highly optimized c++ version of the HQ2x filter that outputs at 16bpp. Or get it from bsnes/src/snes/video/filter_hq2x.cpp. Anyway, I don't think templates will do what I want. I know I can't inser...
by Near
Fri Jun 02, 2006 3:47 pm
Forum: NESemdev
Topic: dd routines interface
Replies: 12
Views: 5582

Well, with DD and D3D, along with every video card made in the past eight years or so, they support automatic conversion of bit depths, so even if the user is running at 16bpp or 32bpp, you can blit a 16bpp buffer to the screen. Why does this matter? You halve the video data being transferred from t...
by Near
Fri Jun 02, 2006 12:48 pm
Forum: NESemdev
Topic: dd routines interface
Replies: 12
Views: 5582

You're just getting lucky that ignoring the pitch is working for you. The reason is because most video cards use the pitch to round textures (surfaces) up to powers of two, and 256 just happens to be 2^8. It's just a minor video card alignment optimization. Still, you should account for it anyway be...
by Near
Wed May 24, 2006 4:23 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

Another way to look at it: In the quote above you seem to be implying a scenario where many cothreads need to synchronize at once (i.e. "have to" stop for each other) in a way that prevents you from getting them all to a "want to" point. But even if it was possible for that to happen for short peri...
by Near
Wed May 24, 2006 12:58 am
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

If we define a stable state as the main CPU and sound CPU both having just completed instructions, this might not even be possible. I imagine that the only stable states that could be reliably gotten to would constrain the implementation enough that it would come to resemble the previous design tha...
by Near
Mon May 22, 2006 3:52 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

The problem with byuu's system (ignoring that it's for the SNES) is a limitation of the emulator implementation. Some of the system state is represented in the host machine's internal state of several threads (program counter, stack contents, stack pointer). This can't be easily converted to an emu...
by Near
Mon May 22, 2006 8:29 am
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

You'd made it sound like it wouldn't be possible to avoid savestate versioning issues.. but since the NES is static, it's more a matter of how practical it is. This isn't related to the NES. The reason you can't use savestates with cooperative multithreading is because you can't save the stack + co...
by Near
Sun May 21, 2006 10:15 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

augnober wrote:Confucius says.. Platforms and emulators may come and go, but the NES will never change 8)
Uhh... what?
by Near
Thu May 11, 2006 2:26 pm
Forum: NESemdev
Topic: Down to the cycle
Replies: 26
Views: 9238

The model I have in my mind is that the 6502 latches the IRQ/NMI status at the beginning of the last clock of each instruction. This means that it effectively looks at the IRQ/NMI input just before that time, i.e. what its status was on the next-to-last clock. This would account for most of the lat...
by Near
Thu May 11, 2006 11:00 am
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

Alright, figured I'd post about this here as well since we were discussing cooperative multithreading, etc previously in this thread. Basically, what I've found out about cooperative multithreading is that there is an implementation in Win95/NT3.51+ called Windows Fibers. On my Athlon 3500+, it is g...
by Near
Wed Mar 29, 2006 3:57 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

It sounds like you aren't interested in giving the catch-up method a fair chance, but I'll try to discuss this anyway. I don't mind giving it a fair chance, it obviously works for you guys. But I'm not interested in using it myself, having tried for the better part of three months to get those issu...
by Near
Tue Mar 28, 2006 7:31 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

Oh well, I was hoping for actual problem cases for the catch-up method. I cited many in my first post. To repeat one example, how would you complete a DMA transfer that activates in the middle of an opcode if your CPU emulator can't break out until the opcode is completed? To get the timing right, ...
by Near
Tue Mar 28, 2006 6:07 pm
Forum: NESemdev
Topic: cycle for cycle stuff
Replies: 99
Views: 53491

I take strong issue with your claims that the catch-up design is a hack. Sorry, it's just my personal opinion. If it works, it works. I try and code things as a reference implementation, which is obviously terrible for performance. There's no need to separate PPU synchronization from CPU memory acc...