nesdev.com

As I remember, my sharpness is just 2D (scanline) edge enhancement. In its more basic form, you exaggerate differences between pixels, but correct before/after to keep the absolute level the same. So 10, 10, 90, 90 becomes 10, 0, 100, 90 if you're enhancing, and 10, 20, 80, 90 if you're softening.

You shouldn't get exactly 800 samples every frame since NES frames are not exactly 1/60 second long. Can your sound code handle just getting 798/799 samples per frame rather than needing exactly 800? This probably touches on the issue of audio and video running at the same rate. If you want to get a...

In your original code most of the time you'll be getting zero samples available. Does your buffering code work properly if you call SoundOut.WriteBuffer() with zero samples? You don't seem to be adding deltas, rather the absolute sample values. You must keep track of the current amplitude and add th...

It looked broken and I was about to be amazed at such a basic bug I missed, but I think I made sense of it. There is a pipeline in effect so V1 processes some things from the *previous* voice. V1 sets t_dir_addr based on t_dir and t_srcn. t_srcn is the value from the *previous* execution of V1, so t...

I'm reading the code as, "If the 5 sample KON delay has passed then use the Source Loop Start Address (LSA) instead of the Source Start Address (SA). Yeah. If a KON isn't happening, then the only address it will need is the loop for when it reaches the end. It only reads one of the two sample addre...

I figured I'd try changing the define to use 57600 bps instead of 115200. And it got me halfway to a "SENDING PRG" message... soon thereafter I figured out the program was ignoring the define in the later transfers, and after fixing that it looks like I can finally enjoy eprom emulator development ...

Jarhmander wrote:

Code: Select all

cl65 --target none --start-addr $(printf %d 0xBF80) disasm.s -o test.nsf

A little more concise is double parens instead of printf, and you can use expressions:

The macro RTSADDR x, y, z, ... would emit .WORD x, y, z, ... in SPC700 mode or .WORD (x)-1, (y)-1, (z)-1, ... in 6502 mode. [*]The macro PLAS ("pull A and set flags") would emit PLA AND #$FF in SPC700 mode or PLA in 6502. The name is inspired by ARM's S suffix on ALU operations that affect the flag...

I have no desire to lead. If people can't decide on something, oh well. In discussions my goal is simply clarity of everything and honest about goals and tradeoffs. With a clear picture, people can understand each others' wants (they need no justification; if you want something due to aesthetics, fi...

"I have little interest in trying to make custom 6502-like mnemonics for SPC-700 instructions" "I just looked at some of your SPC-700 instructions in 6502 clothing and I'm wondering what the benefit is" If you like the idea, I'd love your participation. If you don't, then I wouldn't want you to dre...

I took a while to survey the topic. To avoid sunk-cost bias from wrecking things, I'm going to ignore my ca65 macro packs and byuu's bass. We start with the 65xx and SPC-700 architectures. Those have official assembly syntaxes and are supported by multiple assemblers. All good. But there are improve...

See demo_fixed.c, which uses the highest-possible clock rate (for maximum time resolution). So the period of your 440-Hz square wave would be clock_rate/440. To make a square wave you add positive and negative deltas at that period, spaced by half the period (floating-point just for clarity; you'd n...

Avoid Blip_Buffer and prefer blip_buf. blip_buf has a more refined interface and better timing accuracy.

* POP A, POP X, and POP Y don't affect the flags. * RET doesn't increment the return address by one as on the 65C02, and likewise CALL pushes the address of the opcode of the next instruction. * The N, V, Z, and C flags are set the same for all supported instructions, including in the same bit posit...

byuu, your messages to me here and in the other thread have been hurtful and I dread them. I'd really appreciate if you could stick to the technical arguments. You keep lamenting about how things can't happen, and these negative predictions are detrimental to me even participating at this point. I'm...