tokumaru wrote:
Except that sometimes the VBlank flag goes undetected, if you happen to read it while it's being set by the PPU. If this happens in this case, you'll probably get a bad result. I'd use NMIs. Polling $2002 should never be done when timing is important. If you absolutelly *need* to wait for VBlank the old way, have the NMI set a flag and have the waiting code check this flag instead.
My bad, I had no idea this was the case (and for once its even mentioned in the wiki!). Bloody hardware bugs.
Oh well, time to go back and fix some code..
Quote:
doynax wrote:
Also what's up with the tabs in code boxes? I don't know what they're doing but they sure as hell don't line things up..
Well, each editor uses a different number of spaces to represent TABs (Notepad's for example is ridiculously large), so if this board (or your browser, I don't know which one is converting TABs into spaces) uses something different than the editor where you wrote the code, it will look wrong.
It's not the number of spaces (it seems to use three), which I can live with. The problem is that rather then moving to the next tab stop (the next column evenly divisible three) it simply jumps three characters ahead regardless of the current position, which is amazingly fucked up.
Just look at these examples, where a single tab precedes the comments:
Code:
;0
a ;1
ab ;2
abc ;3
abcd ;4
Quote:
That's kinda why I mostly gave up TABbed comments (although that seems to be some kind of standard in assembly)... They look pretty weird accross different editors, and some times I do use different editors. You know, those times when you have an urge to code and all that's available is Notepad! :D
I tend to use 8-character tabs for assembler code so its not really an issue as every editor known to man supports it (based on some old ancient VT terminal I suppose), and any sane code editor ought to be customizable for each file type.
The only reason I can see to use a shorter tab size would be for indentation. And while I've tried in assembly code occasionally it has never really worked out. Perhaps if someone wrote an assembler with a excellent set of scoped flow control macros. But with every such system I've tested to date I've just ended up with a bunch of regular labels and branches intermixed with the high-level macros, making the scopes useless as visual cues for the program flow.