nesdev.parodius.com

Celius · Posted: Sun Jul 31, 2005 6:26 pm Post subject:

Okay, so if the hi bit is on, it would equal 8 in binary, which is why you have 85 for list something 5 times! yay. I figured something out. So when you define the bytes like you did in the compression thing above, you just have to decompress it? you don't have to write a compression code?

tepples · Posted: Sun Jul 31, 2005 8:14 pm Post subject:

You have to compress the data within the map editor, or if your map editor doesn't compress, you have to compress the data with some external tool.

At least one popular RLE compression format uses signed numbers: 0 through 127 for a string of 1 to 128 literal bytes, or -1 through -127 for a run of 2 through 128 copies of the following byte. This format, introduced by Apple Computer with the MacPaint file format, is called PackBits. I've written a PackBits compressor (in C) and a decompressor (in 6502 assembly language) as part of Pin Eight NES Tools.

Celius · Posted: Mon Aug 01, 2005 11:54 am Post subject:

Okay, this is really dumb, but how do you pull a byte from a .db line?

Disch · Joined: 10 Nov 2004 Posts: 1587

Celius · Posted: Mon Aug 01, 2005 12:25 pm Post subject:

Oh, I didn't know that when you loaded A with the data, it would equal the first byte of the data. If that didn't make any sense, I didn't know that what you just said was true. Smile

Well, I've decided upon which RLE decompression method I'm going to use, and that's the one Disch displayed, because it makes alot of sense. I need to think of a good code. Because I'm not sure how I would tell it to do this:

Celius · Posted: Mon Aug 01, 2005 2:27 pm Post subject:

I'm assuming that you'd have to have all of that information present, so that's why I used a,x, and y. Smile

Disch · Joined: 10 Nov 2004 Posts: 1587

You will probably need Y for indirection (odds are you will need to use Indirect.Y addressing mode). X will probably need to be used as a counter to count down the run length. A will probably need to be used for memory movement and other things. Which means you'll need areas in RAM for other information (like current source and dest positions, remaining bytes to be decompressed, etc)

But I'm kinda just blowing smoke at you.

I'm kind of in agreement with blargg on this one. It looks like you're trying to move too far too fast. Before you start doing things like compression you should really get more familiar with the basics.

Celius · Posted: Mon Aug 01, 2005 3:01 pm Post subject:

Well, I just want to find a way to load a background with out an emulator going phsyco or displaying Name Table 1.5. If what you mean by basics is Sprite moving, Sprite DMA, joypad handling, vblank, etc., I pretty much have that all down. I'm thinking loading a background is pretty basic. Maybe I'll just start making one screen backgrounds with NSA. It's just that it always screws up on emulators, and shows name table 1.5. But no one else seems to have this problem, so maybe it's just my code. Any one know a decent way to load a .nam file?

blargg · Joined: 27 Sep 2004 Posts: 2557

I think a .nam file is in the native PPU format for loading; just copy it to the current nametable memory (along with the proper pattern table) and it's displayed.

I'll figure out how to do this this evening and e-mail you demo code in our ongoing tutorial.

Celius · Posted: Mon Aug 01, 2005 3:45 pm Post subject:

Yeah, the only problem is it doesn't work on most emulators. It is displayed incorrectly, and looks like the camera scrolled down to Name table 1.5 and stopped.

Quietust · Joined: 19 Sep 2004 Posts: 1028

Memblers · Posted: Mon Aug 01, 2005 6:55 pm Post subject:

And don't forget the all-important NMI routine, to be enabled once you've got your full nametable loaded. You'll want to at least write zeros to $2005 and $2006 in there, otherwise I think the screen would get stuck at whatever point you turned it on.

That could be why it looks like it scrolled (it didn't scroll, but rather started it's display at the wrong origin). I used to see that all the time in my programs, but it was temporary (since NMI would fix it on the next frame). Now I get around that by waiting for a vblank before enabling the screen.

Celius · Posted: Mon Oct 17, 2005 2:31 pm Post subject:

Okay, are you not able to incbin more than 7 nam files, or what? Because I was putting together a quick demo, and I tried to take the high and low bytes of the adress that the 8th nam file was at, and it completely screwed up, and the name table was all messed up. But in my routine, I changed it from taking the high and low bytes of the 8th nam file, to taking the high and low bytes of the 7th nam file, and it worked just fine. If you switch the nam files around, it will always load the last one improperly. I'm thinking it has something to do with memory space. Any clue?

tokumaru · Posted: Tue Oct 18, 2005 5:57 am Post subject:

I don't see a reason for that problem unless you are going over the limit the PRG bank can store. How big are your nam files? How big is your code?

Celius · Posted: Fri Oct 28, 2005 7:29 pm Post subject:

Sorry for a late reply, my nam files are 1K each, and I think that is going way over the prg limit. And my PRG banks are 16K, actually, now that I think about it, I don't know how I could be going over the limit. But just a rough idea, not really an educated guess, it may have something to do with memory mirroring like in RAM, but I have my nam files in PRG. I hope that's not a problem. Oh, and if I put my nam files right by the .org $8000 part, it says "Bank overflow! <$1FFF!" And when I put them back on bottom, it doesn't say that. But, I don't have any segments where I org it at any different location, or change banks, so what's the deal? I don't get it.