"Canada, one of the treaty's first signatories, has no clear plan for reaching its target emission cuts. Far from cutting back, its emissions have increased by 20% since 1990." (Read article)
If you're unfamilliar, that means we have 20% to cut back in 7 years. Beauty. And Japan is unsure about their ability to cut back 6%? Well, at least we've got no clear plan!
Mapquest has let be down too many times in the last month:
Unlisted addresses/roads.
Telling Jerusha to turn into on coming traffic on a one way road.
And now this little gem: You searched for "[3-25] Buckhorn Pl, Mississauga, ON L4W 5N9", MapQuest did not find this exact address, but found one very similar: "[3-25] Buckhorn Pl, Mississauga, ON L4W 5N9"
All done. I reimplemented the substring decompression routine to another location (when each byte is read from the buffer) and now it works like a charm, allowing 1 byte of text to represent substrings up to 256 characters long. The best part is, the routine is incredibly more simplistic than before.
So the old, bloated, and time consuming substring modifications below have been thrown out, but at least I've become more comfortable with 6502 assembler and NES hardware.
In the screenshot, the strings retrieved from the substring table are represented by an arrow and the index number for now.
Alright, thanks to Zooka and joat of #nesdev on EFnet, I've learned that my routine has to be small enough to fit into a VBlank period, which it doesn't even come close to doing right now. Time to figure out how many CPU cycles I have to waste, then try to see if I can cut the buffer size in half in order to gain some more.
Updated: So apparently vertical blank time is "precious" and should pretty much only be used to communicate with the PPU, which for some reason is where the original text loading routine is. Anyways, the lesson is that this is not the place to implement my decompression scheme, and instead I'll have to implement it somewhere else. At least we're getting closer to some closure here.
And still, my relationship with the NES is slowly growing up. :)
Apparently the jittering that occurs between when the buffer is filled and the text is printed has to do with the now arbitary amount of time my buffering routine runs for, verse the original fixed "one byte read, one byte written" code. I don't know very much, but based on what I'm reading in Jeremy Chadwick's Nintendo Entertainment System Documentation, I'm thinking maybe I need to keep track of VBlank status to make sure I'm only reading from (writing to?) $2007 during a VBlank. This document is great.
I decided to implement substring compression in addition to DTE for the dialogue text routines. Quite a bit more complex than the last one, but I'm getting more comfortable with the 6502 processor. One outstanding issue I haven't sorted out yet is that my routine seems to cause the screen to jitter sometime between after it fills the buffer and when another routine starts printing the buffer. It's a small effect, but a bug nonetheless.
So I had some spare time at work and an itch to hack on some Nintendo ROMs, so I implemented a DTE routine in SD Gundam Knight Story 3. This one is for menu text, and seems to work pretty nicely everywhere I've run into it. Those who care know who they are, and only care if there are screenshots. ;)
Before:
After:
Current Music: Five Iron Frenzy - The Phantom Mullet
The Yellow Dog Linux 4.0 ISOs have finally started popping up on mirrors and such, although I haven't seen any sort of announcement about it. I found my copy on this mirror. I've got the 4 binary ISOs downloaded, and I just started the install on my iBook G3.