+Andrew Davie Posted May 27, 2003 Share Posted May 27, 2003 Even our language treats "color" differently - here in Oz we write "colour" and in the USA they write "color". Likewise, '2600 units in different countries don't quite speak the same language when it comes to colour. We have already seen why there are 3 variants of '2600 units - these variations (PAL, NTSC, SECAM) exist because of the differences in TV standards in various countries. Specifically, the colour information is encoded in different ways into the analogue TV signal for each system, and the '2600 hardware is responsible for inserting that colour information in the data sent to the TV. Not only do these different '2600 systems write the colour information in different ways, they also write totally different colours! What is one colour on a NTSC system is probably NOT the same colour on PAL, and almost certainly not the same colour on SECAM! Here's some wonderful colour charts from B. Watson to show the colours used by each of the systems... http://www.urchlay.com/stelladoc/v2/tia_co...colorchart.html Colours are represented on the '2600 by numbers. How else could it be? The colour to number correspondence is essentially an arbitrary association - so, for example on a NTSC machine the value $1A is yellowish, on PAL the same colour is grey, and on SECAM it is aqua (!). If the same colour values were used on a game converted between a NTSC and PAL system, then everything would look very weird indeed! To read the colour charts on the above URL, form a 2-digit hex number from the hue and the lum values (ie: hue 2, lum 5 -> $25 value -> brown(ish) on NTSC and as it happens a very similar brown(ish) on PAL. We've already played with colours in our first kernel! In the picture section (the 192 scanlines) we had the following code... ; 192 scanlines of picture... ldx #0 REPEAT 192; scanlines inx stx COLUBK sta WSYNC REPEND We should know by now what that "sta WSYNC" does - and now it's time to understand the rest of it. Remember the picture that the kernal shows? A very pretty rainbow effect, with colour stripes across the screen. It's the TIA producing those colours, but it's our kernal telling the TIA what colour to show on each line. And it's done with the "stx COLUBK" line. Remember how the TIA maps to memory in locations 0 - $7F, and that WSYNC is a label representing the memory location of the TIA register (which happens, of course, to be called WSYNC). In similar fashion, COLUBK is a label which corresponds to the TIA register of the same name. This particular register allows us to set the colour of the background that the TIA sends to the TV! A quick peek at the symbol table shows... COLUBK 0009 (R ) In fact, the very best place to look is in the Stella Programmer's guide - for here you will be able to see the exact location and usage of this TIA register. This is a pretty simple one, though - all we do is write a number representing the colour we want (selected from the colour charts linked to, above) and the TIA will display this colour as the background. Don't forget that it also depends on what system we're running on! If we're doing a PAL kernel, then we will see a different colour than if we're doing a NTSC or SECAM kernel. The bizarre consequence of this is that if we change the number of scanlines our kernel generates, the COLOURS of everything also change. That's because (if we are running on an emulator or plug a ROM into a console) we are essentially switching between PAL/NTSC/SECAM systems, and as noted these systems send different colour information to the TV! It's weird, but the bottom line is that when you choose colours, you choose them for the particular TV standard you are writing your ROM to run on. If you change to a different TV system, then you will also need to rework all the colours of all the objects in your game. Let's go back to our kernel and have a bit of a look at what it's doing to achieve that rainbow effect. There's remarkably little code in there for such a pretty effect. As we've learned, the 6502 has just three "registers". These are named A, X and Y - and allow us to shift bytes to and from memory - and perform some simple modifications to these bytes. In particular, the X and Y registers are known as "index registers", and these have very little capability (they can be loaded, saved, incremented and decremented). The accumulator (A) is our workhorse register, and it is this register used to do just about all the grunt-work like addition, subtraction, and bit manipulation. Our simple kernel, though, uses the X register to step a colour value from 0 (at the start), writing the colour value to the TIA background colour register (COLUBK), incrementing X by one each scanline. First (outside the repeat) we have "ldx #0". This instruction moves the numeric value 0 into the X register. ld is an abbreviation for "load", and we have lda, ldx, ldy. st is the similar abbreviation for store, and we have stx sty sta. Inside our repeat structure, we have "stx COLUBK". As noted, this will copy the current contents of the x register into the memory location 9 (which is, of course, the TIA register COLUBK). The TIA will then *immediately* use the value we wrote as the background colour sent to the TV. Next we have an instruction "inx". This increments the current value of the X register by one. Likewise, we have an "iny" instruction, which increments the y register. But, alas, we don't have an "ina" instruction to increment the accumulator (!). We are also able to decrement (by 1) the x and y registers with "dex" and "dey". The operation of our kernel should be pretty obvious, now. The X register is initialised with 0, and every scanline it is written to the background colour register, and incremented. So the background colour shows, scanline by scanline, the colour range that the '2600 is capable of. In actual fact, you could throw another "inx" in there and see what happens. Or even change the "inx" to "dex" - what do you think will happen? As an aside, it was actually possible to blow up one early home computer by playing around with registers like this (I kid you not!) - but you can't possibly damage your '2600 (or emulator!) doing this. Have fun, experiment. Since we're only doing 192 lines, the X register will increment from 0 to 192 by the time we get to the end of our block of code. But what if we'd put two "inx" lines in? We'd have incremented the X register by 192 x 2 = 384 times. What would its value be? 384? No - because the X register is only an 8-bit register, and you would need 9 bits to hold 384 (binary %110000000). When any register overflows - or is incremented or decremented past its maximum capability, it simply "wraps around". For example, if our register had %11111111 in it (255, the maximum 8-bit number) and it was incremented, then it would simply become %00000000 (which is the low 8-bits of %100000000). Likewise, decrementing from 0 would leave %11111111 in the register. This may seem a bit confusing right now, but when we get used to binary arithmetic, it will seem quite natural. Hang in there, I'll avoid throwing the need to know this sort of stuff at you for a while. Now you've had a little introduction to the COLUBK register, I'd just like to touch briefly on the difference apparent between the WSYNC register and the COLUBK register. The former (WSYNC) was a strobe - you could simply "touch" it (by writing any value) and it would instantly halt the 6502. Didn't matter what value you wrote, the effect was the same. The latter register (COLUBK) was used to send an actual VALUE to the TIA (in this case, the value for the colour for the background) - and the value written was very much important. In fact, this value is stored internally by the TIA and it keeps using the value it has internally as the background colour until it changes. If you think about the consequences of this, then, the TIA has at least one internal memory location which is in an uknown (at least by us) state when the machine first powers on. We'd probably see black - which happens to be value 0 on all machines), but you never know. I believe it is wise to initialise the TIA registers to known-states when your kernel first starts - so there are no surprises on weird machines or emulators. We have done nothing, so far, to initialise the TIA - or the 6502, for that matter - and I think we'll probably have a brief look at system startup code in a session real-soon-now. Until then, have a play with the picture-drawing section, and see what happens when you write different values to the COLUBK register. You might even like to change it several times in succession and see what happens. Here's somtehing to try (with a bit of headscratching, you should be able to figure all this out by now)... ; 192 scanlines of picture... ldx #0 ldy #0 REPEAT 192; scanlines inx stx COLUBK nop nop nop dey sty COLUBK sta WSYNC REPEND Try inserting more "nop" lines (what does nop do, again?) - can you see how the timing of the 6502 and where you do changes to the TIA is reflected directly onscreen because of the synchronisation between the 6052 and the TIA which is drawing the lines on-the-fly? Have a good play with this, because once you've cottoned-on to what's happening here, you will have no problems programming anything on the '2600. See you next time! 1 Quote Link to comment Share on other sites More sharing options...
Happy_Dude Posted May 27, 2003 Share Posted May 27, 2003 Alright then NOP = waste 1 cycle 1 6502 cycle = 3 TIA clocks Is 160 cycles resolution the 6502 time or TIA time? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 27, 2003 Author Share Posted May 27, 2003 Alright then NOP = waste 1 cycle1 6502 cycle = 3 TIA clocks Is 160 cycles resolution the 6502 time or TIA time? Almost. NOP = waste 2 cycles. 160 is the number of clocks of visible pixels. That's TIA clocks, one clock per pixel. But on each scanline there's 228 clocks. Divide by 3 to get the number of 6502 clocks per scanline = 76. We covered this earlier, so time for a bit of revision I think Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 27, 2003 Author Share Posted May 27, 2003 Until then, have a play with the picture-drawing section, and see what happens when you write different values to the COLUBK register. You might even like to change it several times in succession and see what happens. Here's somtehing to try (with a bit of headscratching, you should be able to figure all this out by now)... ; 192 scanlines of picture... ldx #0 ldy #0 REPEAT 192; scanlines inx stx COLUBK nop nop nop dey sty COLUBK sta WSYNC REPEND Try inserting more "nop" lines (what does nop do, again?) - can you see how the timing of the 6502 and where you do changes to the TIA is reflected directly onscreen because of the synchronisation between the 6052 and the TIA which is drawing the lines on-the-fly? Have a good play with this, because once you've cottoned-on to what's happening here, you will have no problems programming anything on the '2600. See you next time! The above may not have been so obvious, because ALL of the code inside our REPEAT... REPEND section is happening in the first 68 colour-clocks of the line, when the TV is doing its horizontal retrace. If you replace the code with the following (with more NOPs inserted) the effect I was trying to show will become WAY more apparent! The sample image shows what we're looking at. ; 192 scanlines of picture... ldx #0 ldy #0 REPEAT 192; scanlines nop nop nop nop nop nop nop nop nop nop inx stx COLUBK nop nop nop dey sty COLUBK sta WSYNC REPEND One caution: as the above code is wrapped inside a repeat structure which creates 192 copies of the enclosed code, we're actually running short of ROM space! With the above code installed, there's only 10 bytes free in our entire ROM! Clearly, using REPEAT in this sort of situation is wasteful, and the code should be written as a loop. We covered looping for scanline draw early on - but because both X and Y registers are in use at the moment, it's a bit more tricky. So for now, we'll just have to accept that we can't add any more code - but at least you can see what effect adding/removing cycles can have on the existing code. The bold changes above were corrections made 27/6/2003 - AD kernel11.zip Quote Link to comment Share on other sites More sharing options...
Happy_Dude Posted May 27, 2003 Share Posted May 27, 2003 I just used the Sleep macro to kill some cycles How many cycles does the "bit VSYNC" used in macro.h waste ? Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted May 27, 2003 Share Posted May 27, 2003 Hi there! I just used the Sleep macro to kill some cycles How many cycles does the "bit VSYNC" used in macro.h waste ? Actually it's supposed to work just the other way round. You say Sleep X And then it wastes X cycles. No need to worry what the macro does... But to still answer your question: 3 cycles. Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 27, 2003 Author Share Posted May 27, 2003 I just used the Sleep macro to kill some cycles How many cycles does the "bit VSYNC" used in macro.h waste ? It uses 3. There are various ways of 'efficiently' wasting time (ie: the most cycles used for the least number of bytes of ROM spent doing it). We'll cover that in a later tutorial. Quote Link to comment Share on other sites More sharing options...
Happy_Dude Posted May 27, 2003 Share Posted May 27, 2003 just curious .....'efficiently' wasting time? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 27, 2003 Author Share Posted May 27, 2003 just curious .....'efficiently' wasting time? If you *have* to waste time, then do it in as few bytes as possible. The following contrived code snippets all waste the same amount of time - but the cost of the 2nd (in ROM bytes used) is double. jsr _rts ; 12 cycles, 3 bytes nop nop nop nop nop nop ; 12 cycles, 6 bytes We will see in later tutorials where, even if you DO have lots of ROM space, it is often necessary to keep code size to a minimum - because of constraints on how far the 6502 can "see" to get to other bits of code. We'll cover all of this in future sessions. Quote Link to comment Share on other sites More sharing options...
NE146 Posted May 28, 2003 Share Posted May 28, 2003 I gotta say.. you are a writing machine to do this every day. Looking forward to the next one Quote Link to comment Share on other sites More sharing options...
Contieri Posted May 28, 2003 Share Posted May 28, 2003 Hi! Anyone has this code commented?? I've messed up mine and I'd like to get a copy of it with the up to date lesson. Mine has got creepy since I've messed it a lot... Cheers, Ricardo Quote Link to comment Share on other sites More sharing options...
Serguei2 Posted October 19, 2003 Share Posted October 19, 2003 Hi I got segment: fffa vs current org: 10063 test2.asm (142): error: Origin Reverse-indexed. Aborting assembly when trying a new code: processor 6502 include "vcs.h" include "macro.h" SEG ORG $F000 Reset StartOfFrame ; Start of vertical blank processing lda #0 sta VBLANK lda #2 sta VSYNC ; 3 scanlines of VSYNCH signal... sta WSYNC sta WSYNC sta WSYNC lda #0 sta VSYNC ; 37 scanlines of vertical blank... sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC ; 192 scanlines of picture... ldx #0 ldy #0 REPEAT 192 ; scanlines nop nop nop nop nop nop nop nop nop nop inx stx COLUBK nop nop nop dey sty COLUBK sta WSYNC REPEND lda #%01000010 sta VBLANK ; end of screen - enter blanking ; 30 scanlines of overscan... sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC sta WSYNC jmp StartOfFrame ORG $FFFA .word Reset ; NMI .word Reset ; RESET .word Reset ; IRQ END Another thing. Do I need how the C++ works when using DASM? Serguei Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 19, 2003 Share Posted October 19, 2003 Your code is too large to fit inside 4K. Instead of repeating the same code over and over (192 * 21 bytes = 4032 bytes!) you should use a loop. Quote Link to comment Share on other sites More sharing options...
Serguei2 Posted October 19, 2003 Share Posted October 19, 2003 I used Andrew Davie's code with the code from lesson 8 to get the screenshot see above by myself. Andrew's code: ; 192 scanlines of picture... ldx #0 ldy #0 REPEAT 192 ; scanlines nop nop nop nop nop nop nop nop nop nop inx stx COLUBK nop nop nop dey sty COLUBK sta WSYNC REPEND So. How do I use a loop to make this thing to work? Serguei Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 19, 2003 Share Posted October 19, 2003 Do something like this: ldx #0 ldy #192; scanlines .loop: nop ... inx stx COLUBK nop ... dey sty COLUBK sta WSYNC bne .loop; loop until Y == 0 Quote Link to comment Share on other sites More sharing options...
+xucaen Posted January 7, 2005 Share Posted January 7, 2005 Hi, I'm not sure if any follows this thread anymore, but I figured I'd give it a shot. I'm using dasm V2.20.09 compiled for linux, and I have z26 (2.13) -- May 23, 2004 also compiled for linux. When I load kernel1.bin included in kernel1.zip from session 8 http://www.atariage.com/forums/viewtopic.php?t=27194 and it doesn't look like the screen shot included in that article. I get a solid green bar across the top and a solid black bar at the bottom. I made the changes outlined in session 11 above and still get these. I tried to fix it but I couldn't. Are these examples written for PAL or NTSC? I'm including my modified source file as well as my screen shots. ;first kernel processor 6502 include "vcs.h" include "macro.h" SEG ORG $F000 Reset StartOfFrame ; Start of vertical blank processing lda #0 sta VBLANK lda #2 sta VSYNC ; 3 scanlines of VSYNCH signal... sta WSYNC sta WSYNC sta WSYNC lda #0 sta VSYNC ldx #37 vblankloop ; 37 scanlines of vertical blank... sta WSYNC dex bne vblankloop endvblankloop lda #2 ldx #192 ldy #0 drawpictureloop ; 192 scanlines of picture... iny sty COLUBK sleep 20 stx COLUBK sleep 10 sty COLUBK sleep 10 sta WSYNC dex bne drawpictureloop enddrawpictureloop lda #%01000010 sta VBLANK ; end of screen - enter blanking ldx 30 overscanloop ; 30 scanlines of overscan... sta WSYNC dex bne overscanloop ebdoverscanloop jmp StartOfFrame ORG $FFFA .word Reset ; NMI .word Reset ; RESET .word Reset ; IRQ END thanks! Jim Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted January 7, 2005 Share Posted January 7, 2005 Hi there! There's been numerous little flaws with the code, so first I fixed all of them (including the formatting...): ;first kernel processor 6502 include "vcs.h" include "macro.h" SEG ORG $F000 Reset StartOfFrame ; Start of vertical blank processing VERTICAL_SYNC ldx #37 ; 37 scanlines of vertical blank... vblankloop sta WSYNC dex bne vblankloop ldx #192 ; 192 scanlines of picture... ldy #0 STY COLUBK STY VBLANK drawpictureloop sta WSYNC iny sty COLUBK sleep 20 stx COLUBK sleep 10 sty COLUBK sleep 10 dex BNE drawpictureloop enddrawpictureloop lda #%01000010 sta VBLANK ; end of screen - enter blanking ldx 30 ; 30 scanlines of overscan... overscanloop sta WSYNC dex bne overscanloop jmp StartOfFrame ORG $FFFA .word Reset ; NMI .word Reset ; RESET .word Reset ; IRQ END Well, the major points were - you disabled VBLANK too early It should be the last thing to do before your display code starts. It was already enabled before the VBLANK period was even started. - VERTICAL_SYNC should happen before the VBLANK period - Your drawing loop should start with a write to WSYNC, so all lines get the same timing. - The last color your loop sets is 192, so you should set COLUBK to 0 again, before disabling VBLANK, or you'll get to see 192 again. Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 8, 2005 Share Posted January 8, 2005 just curious .....'efficiently' wasting time? If you *have* to waste time, then do it in as few bytes as possible. The following contrived code snippets all waste the same amount of time - but the cost of the 2nd (in ROM bytes used) is double. jsr _rts ; 12 cycles, 3 bytes nop nop nop nop nop nop ; 12 cycles, 6 bytes Actually, the cost of the first example would be half the amount of rom...but in addition to 2 bytes of ram (taken to store the return address...right?). At least it would be if the rest of the program has no need of JSR'ing or stack manipulation. With only 128 bytes of user ram, it could be an advantage doing it the long way instead. Hackers take note: that's how you get water from an empty well in some cases Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted January 8, 2005 Share Posted January 8, 2005 Hi there! Actually, the cost of the first example would be half the amount of rom... That's what Andrew said You sound like you didn't understand it fully. Maybe this is better: JSR AnyROMLocationWithAnRTS ... ... Other Code ... SUBROUTINE BLA ... ... Other Code ... AnyROMLocationWithAnRTS RTS [code] See? No RAM required at all. And it's only 3 bytes for "JSR abs", as an RTS is _somewhere_ in your code. Even if you're not using subroutines at all, there should be a byte containing $60 somewhere, maybe in the data Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 8, 2005 Share Posted January 8, 2005 Isn't the stack in ram? Seems that once I eliminated all subroutine JSR's and stack instructions like PHA from a program, the upper ram locations were no longer corrupted...leaving all 128 bytes $80-$FF free to be assigned as variables. Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted January 8, 2005 Share Posted January 8, 2005 Hi there! Isn't the stack in ram? Seems that once I eliminated all subroutine JSR's and stack instructions like PHA from a program, the upper ram locations were no longer corrupted...leaving all 128 bytes $80-$FF free to be assigned as variables. Uihjah! Didn't think someone would get so desperate to need those last two bytes as well. Subroutines are such a nice thing to have. Though I usually avoid nesting them on the VCS Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted January 8, 2005 Share Posted January 8, 2005 Hi there! Subroutines are such a nice thing to have. Though I usually avoid nesting them on the VCS My SFX driver for Seawolf will start any of 11 sound effects any time just with LDY #EFFECT JSR DoSFX for example :-) Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
+xucaen Posted January 9, 2005 Share Posted January 9, 2005 - you disabled VBLANK too early It should be the last thing to do before your display code starts. It was already enabled before the VBLANK period was even started. - VERTICAL_SYNC should happen before the VBLANK period - Your drawing loop should start with a write to WSYNC, so all lines get the same timing. - The last color your loop sets is 192, so you should set COLUBK to 0 again, before disabling VBLANK, or you'll get to see 192 again. Greetings, Manuel Hi Manuel, thanks for the code review. I noticed Andrew's example begins with vertical sync, but yours begins with vertical blank. I've seen other examples that begin with overscan. That's enough to confuse me. So my biggest misunderstanding at the moment is... how do I know where to begin? Do I control the tv or do I try to keep up with it? For instance, if I move #2 into VSYNC in the middle of drawing the playfield, does the electron beam return to the top of the screen? I just did a test and that's what it looks like is happening. And is it the same for VBLANK and RSYNC as well? Jim Quote Link to comment Share on other sites More sharing options...
+xucaen Posted January 9, 2005 Share Posted January 9, 2005 p.s. I don't see a vsync anywhere in your example.. yet it compiles and runs! just when I thought I was beginning to grasp things... So, when is vsync not needed? jim Quote Link to comment Share on other sites More sharing options...
+xucaen Posted January 9, 2005 Share Posted January 9, 2005 p.p.s. never mind. I found where you're setting vsync.. in macro.h. jim Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.