Printable View
I doesn't work like that. The VDP just draws whatever's in the VRAM/CRAM. It shows the change as soon as it reaches the place where you made it... if that makes sense.
That's also why you can mess things up, if you write to the VRAM during active display.
Vram only goes to #$3fff (16k).Quote:
Originally Posted by KillerBean2
Whatever changes you made to the VDP, remain static until you make further changes. So no, you don't need to keep re-updating the same data every screen - unless they be changes.Quote:
But I gotta know for tomorrow, does the SMS update the screen automatically? or do you gotta call some "re-paint" function?
Loading sprite cells or sprite SAT entries? If you didn't change reg #6 or didn't write new cells to the sprite cell area designated by current reg 6 value (pattern block 2), then the SAT entry won't show a sprite object onscreen (because vram was cleared and all pixels in the pattern block 2 are transparent).Quote:
Well not sure if I corrected that or not, but I seem to be loading sprites fine now.
SAT entries.
So the Master System only has two shades of grey, so I can't get my ship my desired colour.
But I'm satisfied with what I got, yet no sprites are final.
Anyone wanna take a look?:
https://docs.google.com/file/d/0B8yy...it?usp=sharing
After this, I'm gonna take a break from sprites, to figure out how the SMS updates and so on.
True, I'm babbling. Had the patterns and SAT mixed up (ironically). The sprite table goes to $3F00 (always!), but in the "Hello World" tutorial the sprites use the tiles at $2000 in stead of the ones at $0000, right?Quote:
Originally Posted by tomaitheous
The VDP redraws the screen 60 or 50 (NTSC/PAL) times per second. If you have the frame interrupt enabled (bit 5 of register $01), one will be triggered each time the VDP has finished drawing a frame, and you'll have the time span of the vertical blanking to make changes to registers, VRAM and CRAM. The frame interrupt is very useful.Quote:
Originally Posted by azonicrider
The SMSpower tutorial talks about interrupts I think.
So this is how you do "if statements" in Z80, looks pretty simple:
http://www.andreadrian.de/oldcpu/Z80...mozTocId370017
god, looking at that C code is so refreshing. Its like seeing daylight, after 5 years of being stuck in a bomb shelter.
That's only because you don't have enough time spent with assembly (any processor). 'IF' statements are just made up of compare logic. Sometimes there are short cuts (such as loading an initial value into register that yields ZERO, can set a flag), and other times you just have to write multiple compare steps. It's all about the status FLAGs. Comparing, subtracting, adding, shifting, logic operations, etc all yield results in the status FLAG register. You just have to pay attention as to what instructions effect this flag (it can be different on other processors). Some processors have quite a few flags, and multiple flags can be set depending on an action. For other processors, they are more limited and thus you have to write 'fall though' test code to check something multiple times (case logic).Quote:
Originally Posted by azonicrider
Compare instructions are usually the same as subtraction opcodes, except nothing is changed or updated other than the status flag. This is desirable because you might want to compare one register or value against quite a few different values; Is A>1, is A=0, is A<45, is A>88, etc. I often write short hand notes as C code, next to my assembly. It's faster than writing out english or language comments and it's faster to read and understand as well.
I've done sooo much 65x, that my z80 is rusty (z80 was my first 8bit processor that I learned assembly one, after learning x86 assembly). It won't seem so convoluted and/or complex, once you get the hang of it. And once you get good enough, you can write high level macros for non essential code (usually non speed sensitive areas).
Also, don't forget this one aspect: while you only have vblank to update the VDP - you have the whole frame to do in game logic. Don't try to fit every thing into vblank area. You'll run out of cpu resource real quick. Instead, do the game logic after vblank necessary code. Just buffer whatever changes you need, to fall on the next vblank. That way you maximize the full potential of the CPU. Yes, you'll have a 1 frame delay. But it's such a small interval and a lot of old systems did this; no one complained.
There's also a dirty little trick you can do to double the speed of your processor... per se. Almost all retro games on such consoles ran at 60/50 fps (home computers did half frame rate because the cpu or blitter need to do more heavy lifting in comparison). It's possible to run game logic at half frame rate, but movement and animation at full frame rate. This doesn't exactly give you double cpu resource as you still need to do frame updates on every frame, but game logic usually takes much cpu resource, so it does free up more than usually. Probably somewhere half way in between.
This project is frozen. Not dead, frozen.
I just don't think I'm ready for this low-level stuff. I'm gonna return to it in a couple months.
So I'm moving this project over to PlayStation Vita, the object-oriented C# is just mouth watering.
Then after its done, I'll try hard to port it to the SMS.
Remember I still have interest in SMS homebrewing. The 4-bit tiles and FM sound, make the SMS the obvious choice for 8-bit homebrew.
I think learning more high-level game development, could somewhat help me understand low-level game logic a bit more.
the high level stuff will only help you with things like game logic and management, however it will not help a single bit with stuff you are stuck with right now :P