Mr SQL

Wow - that was a fantastic review keithbk! The combination of fast upbeat presentation and the way you described the racing games was dynamite I've added you to my favourites under retro reviews, right next to Metal Jesus I've just checked out several of your other VCS reviews - they are good but it's much more enjoyable to hear you talk about the games like you did here

Good one BassGuitari Tried this last night to check out the gray scale but I'll have to wait until my next retro party to really play - wish it had AI!

Spice, to clear this up for RT or add to the confusion consider that a mnemonic is an opcode mnemonic by definition in context, just as a an opcode is equally a mnemonic opcode; it just depends on which side of the table you approach since they are both symbols that stand directly for each other. In practice if we plug in the opcodes directly we may be (at least until we memorise them) using a paper lookup table of the mnenomic opcodes, scanning through the mnemonics in the table to find the associated opcodes we need to use. Conversely once memorised, the developer can look at the opcodes directly like Neo in the Matrix and do a reverse mental lookup to determine the opcode mnemonics. At some point the line blurs (millions and millions of lines of code later) and the opcode itself becomes a mnemonic device for the underlying operation and we then of course have a mnemonic context switch since the developer is associating the opcode directly with the target operation and we've tossed out the other mnemonic completely. There's no confusion of course with the operands as the mnemonic operands and opcode operands are always one and the same. We're just playing with semantics though; Andrew, Johnny and Tjoppen are right on OK I got tounge tied doing that and had to edit it twice!

What's scary about this is that programmers who use a lookup table for the mnemonics eventually end up memorising the opcodes

Tjoppen is right on! Johnny agrees and he's the next action figure coming up in chapter 6

Thanks wood_jl I agree; if IBM had allowed Microchannel to be an open standard it would have been the standard. Yes, Warp was a much better OS and initially gained a foothold in the business world - there was interoperability where it could run the new business Windows (Windows NT 3.5, Windows NT 4.0) software, but Windows NT could not really support the Warp software. I think if IBM gave those development kits away free instead of charging developers and, if they didn't charge users so much for the Warp OS they could have taken market share with it!

Very cool Tremoloman! I am definitely trying Indy 500 in B&W tonight Really like those screenshots of the B&W arcade versions you posted!

Thanks jaybird3rd, glad to inspire you! Circus Atari is awesome in B&W and already one of my favourite games - I had no idea it could do B&W but I played last night and it's equally awesome with a totally different feel I agree on the B&W signal being sharper, I think it is also sharper on a colour set (tube TV only) than colour but it may indeed be sharper on a BW set (I started out with a BW set too and also want to pick out up - they are hard to find compared to colour sets!)

wood_jl, I was fairly impressed by IBM's Microchannel architecture; you could double up the send and receive lines in burst mode for 64-bit throughput; the 32-bit PCI standard that came out years later paled in comparison. Ditto for OS2/Warp - awesome OS compared to Windows but IBM did mess up again and for similar reasons here; they wanted to charge developers something like $500 for their Warp dev kit at expo - I wasn't buying given that multiple Microsoft reps had shoved no less than 3 free copies of their kit and docs in my hands before I could get out the door. Seemed neither was anyone else

Loon, Great post, I needed some time to properly respond The Genesis is a fantastic machine but IMO it doesn't feel retro; the Motorola 68000 series CPU was dubbed mainframe on a chip with good reason - Sega downplayed it hard for the timeframe stenciling "16-bit" on the first rendition and I can think of no other reason as it's a 32-bit chip! IMO your observation that it feels like an Amiga without the keyboard is right on. But the VCS is an iconoclastic retro machine that charges the imagination like no console before or after could do; not IPF's aptly named Imagination Machine, not the Genesis, not even the PS2. It's got switches on the console and one of them is a BW switch; it's got a huge colour palette and an impressive grayscale pallette too - thrown that special switch and you're not plunged into the world of the RCA Studio II. Instead you're greeted with a pleasing array, of shades of gray But I have observed my Jr detracts from the experience somewhat in contrast to my Vader model; it's got Nintendoesque buttons and sliders instead - that's too bad because throwing switches on a console is an inherrently cool experience in and of itself. That being said I'll have to take apart my Vader (and I'm loathe to do that) since the BW switch is jamming and I have to pull it up and wiggle a bit it to get it to engage - does anyone know a good trick to resolve this without opening it up and cleaning the contacts??

Awesome 90's retro review MetalJesus! It's still hard for me to think of the 90's as retro but I realise the times they are a changin' I'd love to see you do a follow-up with earlier gaming mags from the 80's like Compute, Antic and Rainbow! Point about the Jag .... it's really got 64 bit CPU's and also a 32-bit 68000 series CPU (I see a lot of confusion about that last one in many reviews).

Excellent points SvOlli, both models have their advantages and I would definitely switch to yours with a large number of calls when hitting space constraints! You've got rolls in your code while I have action figures, but I'm surprised none of the advanced coders rolled their eyes at my previous chapters where I first avoid bitwise operations and then neatly dispose of Hexadecimal notation by submerging it in a bath of liquid Helium

SvOlli, I just added the chapter, you should read it just for fun - I guarantee you'll get a kick out of it http://atariage.com/forums/topic/210550-learn-assembly-in-8-hours-with-bb-and-the-asdk/?do=findComment&comment=2746526

Lesson 5: Advanced Assembly – Bank Switching with JCVD Topics: JCVD JCVD’s Roundhouse Kick Senator McComb - Same Matter can’t Occupy Same Space Now let’s implement JCVD Here’s JCVD in the Science-Fiction Block Buster, TimeCop; he’s going to teach us how to bankswitch: JCVD’s Roundhouse Kick Here’s JCVD’s Roundhouse Kick; it’s pretty good Senator McComb - Same Matter can’t Occupy Same Space Here’s Senator McComb’s current and future self starting to self destruct after JCVD purposely violates the one and only rule of Bank Switching with a Roundhouse Kick; same matter, can’t occupy same space: Now Let’s implement it (the JCVD Bank Switching Model) If you peruse the JCVD bankswitching model at top of BANK0 and BANK1 in the ASDK Framework you will see nearly identical blocks for every subroutine; it’s commented to show you which of the mirrored instructions will never execute – rest assured they cannot because the same matter cannot occupy the same space. Therefore, they simply become placeholders. The commands LDA $FFF8 and LDA $FFF9 switch between bank 0 and bank 1, but you end up in exactly the same spot you were at in the previous bank hence the comments as to which instructions do and do not execute; since we’ve used all the same instructions and kept everything at the top we now have nothing to calculate and nothing to count! Note that we’ve simply jumped around our bankswitching block in both banks at startup since we don’t need to actually call the routines, until we need to actually call the routines. Chapter Review Same matter can’t occupy same space, so don’t do the Roundhouse unless you want your code to self destruct; that’s it

SvOlli, you might like the backswitching model I've implemented in my ASDK Framework; it's incredibly simple, all proxy stub so there are no cycles to count. I'll be teaching the method presently on my Learn Assembly thread but you'll get it just by looking at it

I like this retro cast! Awesome Microvision opening

toptenmaterial, all good points on this thread! Here's my perspective: I agree many of the home computers of the 80's beat the PC's by leaps and bounds. And for that reason, PC's of the 80's have largely fallen by the wayside while collectors avidly enjoy all of those other machines! PC's haven't actually endured at all: PC's ushered in an era of disposable architecture (the incremental X86) wherein the underpowered machine quickly became useless while silmutaneously precipitating a need for the end user to buy the next better faster version (ditto for the expansion cards) and emulation (virtual PC) has now grown powerful enough to finally put an end to this model as well. I've got an IBM "portable" 8086 suitcase computer from the 80's and one of the first 80286 laptops (from late in the game, 1992) but not too much you can do with either and they pale compared to a 1979 Atari 800, a 1980 CoCo or a 1982 C64 despite up to 13 years of advancement.

ComputerSpaceFan, Thank you, I'm glad you like the game Great question! I've thought about paddle implementations, but the issue is just as you've stated - how to keep the player in control of the camera at the same time? Two paddles would work but I agree with you that would be kind of awkward and difficult to control compared to one joystick. There have been a few variations between the initial demo version and this one. With the demo version a paddle would work fine since the camera is under control by the CPU and follows first the paddle and then the ball - one problem both my pong champion friends and the children in my test group noted was that the combination of vertical and horizontal scrolling was too much and just not fun so it had to go, just side scrolling was more fun. Then putting the side scrolling under player control made it actually part of the game and increased the fun; I could put that back under CPU control to allow single paddle play but I think it just doesn't match the fun of being able to sometimes follow the ball, sometimes look ahead and sometimes just listen to it bounce around the distant plane of the table.

Thanks jeffgamer!

Lesson 4: Advanced Assembly - Binary and BITwise operations Topics: Introduction to Advanced Assembly Language programming Converting numbers to Binary and back again Implied BITwise operations - leveraging the binary flags and commands Direct BITwise operations – AND OR EOR BIT Marshalling operations – ROL ASL ROR LSR Hexadecimal (optional) Binary operations beyond 8-bit (optional*) How to tabulate game scores beyond 250,000 with just 12 bits* Introduction to Advanced Assembly Language programming You already know enough Assembly to code loops and game logic, but we’ve purposely glossed over using the binary condition codes while still leveraging some of them for game logic; we will now explore how the branch operations you’ve used actually run based on the processor’s condition code flags that are automatically set via different Assembly commands. In this scene from the Walt Disney movie Tron, Sark interfaces with the Master Control Program to check the condition codes on the MPU (a retro term for CPU) to determine if Flynn should be given a LightCycle and sent to the GameGrid. Converting Numbers to Binary and Back Again With this exercise we must deviate from abstract thinking to go low level; here it is (and again you’ll find you already know the answers): Binary numbers are just base 2 instead of our normal base 10 just as you learned in school. And like base 10, the most significant digits are on the left. Refresher - with base 10, each digit increases by the power of 10 so if we look at the number 100 we’ve got a 1 in the 100’s column, and zero’s in the 10’s and 1’s column. For 112 we also have a 1 and a 2 in the 10’s and 1’s columns respectively. We know this intuitively so we don’t really have to think about it. With base 2 each column represents a power of 2 instead of a power of 10 but the rest is just the same: So 100 becomes 1100100 in base 2; here’s the breakdown for the math: 0 in the 1’s column, 0 in the 2’s column, 1 in the 4’s column, 0 in the 8’s column, 0 in the 16’s column, 1 in the 32’s column and 1 in the 64’s column or: 64+32+0+0+4+0+0 = 100! Notice we’re only using 7 bits in the example above; an 8-bit CPU like the 6502 can work with numbers up to 255 directly: 11111111 = 128+64+32+16+8+4+2+1 (255). We get around this limitation by using additional bits with various constructs that we create; for a conceptual example of this, each is a row of pixels in the large virtual world is 92 pixel bits: We could therefore store a number in each 92-bit row greater than what even a 64-bit CPU is capable of working with directly. A simpler construct is most often built with two bytes (8-bit’s each) for storing 16-bit values up to 65,535 (1111111111111111). Implied BITwise operations - leveraging the binary flags and commands The various instructions (commands) of the 6502 change the value of the flag bits in the condition code register. This is a special construct where we don’t care what the number adds up to but only what the individual bits are since each of the bits are used as single binary variables. That’s right: We can use this construct in our own code too (and everyone does, we’ll cover that next) when we want to turn a single byte into 8 binary variables. It’s important to Do The Hustle here because memory was expensive in the 70’s and we’ve only got 128 bytes of system RAM on the Atari! Here is a list of the bit variables (also know as flag variables) in the condition code register that can get set and cleared from the different Assembly instructions: BIT Variable: Description: Z Zero Flag (bit 1) C Carry Flag (bit 0) V Overflow Flag (bit 6) N Negative Flag (bit 7) (There are three more but these aren’t needed; one just flags decimal mode which is odd and the other two deal with Interrupts and are superfluous; code runs in a loop so we don’t actually need a special interrupt to interrupt). We worked with the branch instructions BEQ (branch if equal) and BNE (branch if not equal); these operations work off of the zero flag bit variable, which gets set via many Assembly instructions: LDA #5 CMP #5 BEQ dothisroutine In the straightforward example above we are loading the Accumulator with the number 5 and then comparing it to 5 – you can bet the code will always branch to “dothisroutine” because when you issue a CMP compare, the zero flag variable is set when it matches. You may also recall that the CMP is curiously optional when comparing to zero: LDA #0 ;CMP #0 – commented out because it’s already been done! BEQ dothisroutine That’s because the zero flag is automatically set or cleared when the accumulator is loaded depending upon weather the value in the accumulator is zero or not. Many other instructions such as INC (increment a variable [memory location]) and DEX (decrement the X register) will likewise automatically set or clear the zero flag depending upon the value in the target register or memory location. See the 6502 Reference Guide online for a complete list of the 6502 instructions and how they affect the flag/bit variables in the condition code register; knowing how and when these are set is invaluable for advanced Assembly programming – for example it’s OK to issue a STA, STY or STX command to store a register to a variable (memory location) before checking for a condition code flag that was previously set because those instructions don’t change any of the cc flags but you most often will need to examine the flag bits before issuing additional instructions or they will be lost. Before we make the transition to direct BITwise operations, here’s one that’s a little bit of both: BIT myvar This instruction copies bits 6 and 7 of the target variable/memory location directly to bits 6 and 7 of the the cc register; it also set’s the zero flag like an AND mask which we’ll cover next, but unlike AND it drops the result in the bit bucket behind the CPU rather than updating the Accumulator. We can then run our conditional branch logic right off of the bit 6 and 7 binary variables with: BVS, BVC, BMI and BPL depending upon how these bits were set: BVS – branch if bit variable 6 is set BVC – branch if bit variable 6 is clear BMI – branch if bit variable 7 is set BPL – branch if bit variable 7 is clear These branch commands can have other connotations, but performed after issuing BIT myvar as in our example, this is precisely what they mean. Note on BMI and BPL: These always work off of the 8th or most significant bit (bit 7) and it is possible to create a negative number construct by reducing our otherwise 8-bit values from 255 to (–)127 through (+)127 as follows: 11111111 = -127 01111111 = +127 Can you see what we did here? We’ve created an obtuse construct where the fist bit holds the sign. If you start thinking about these get back on your LightCycle; vague and esoteric concepts like negative numbers have no place on the GameGrid: Flynn didn’t care about negative numbers and he didn’t use them to write all those Tank programs; neither should you. Note: a slight variation on this concept is used to jump backwards and forwards in your code every time you issue a branch instruction but this is also a meaningless construct you shouldn’t waste your time with; no one ever counts forwards or backwards 127/128 positions in memory to see if their branch commands will work – we just change them to the long branch equivalent whenever the DASM Assembler tells us “branch out of range on line xxx”. Actually you can’t do that either because the 6502 has no long branch instructions! What you do is instead is test for the opposite condition and branch just around a JMP instruction which has the power to get wherever you were trying to go (or anywhere in memory for that matter). For example: LDA #5 CMP #5 BEQ yourroutine Has to be changed to this type of format if the Assembler complains that the branch to “yourroutine” is out of range: LDA #5 CMP #5 BNE jumparoundbecausethebranchwastoofaraway JMP yourroutine Jumparoundbecausethebranchwastoofaraway Direct BITwise operations AND OR EOR These are powerful and most often applied with a bit mask using the % binary indicator. Here’s a quick refresher on DASM specific indicators: LDA 255; no indicators at all so we load the Accumulator with whatever value is located in memory location “255”. LDA #255; we’ve indicated we want to use a number instead of a memory location, so we load the Accumulator with the number 255. LDA #$FF; this is the same as the above but we want to use a hexadecimal format so we load the Accumulator with the number FF (255 decimal, we’ll optionally cover hex later; it’s not required at all). LDA #%01101000; again this is the same, but we want to use a binary format so we load the Accumulator with the number 01101000 (100 decimal like we explored earlier); this is the way we will apply a bit mask to set check or flip any of the specific bits in a byte: LDA myvar AND #%00000001 ; is the first bit set? BEQ firstbitclear JSR firstbitset firstbitclear Here’s what’s happening: We’ve loaded A with the variable/memory location myvar, and And’d it with a bit mask of just bit 0 “#%00000001” Suppose myvar (now in the Accumulator) contained the number 100, or #%01101000 in binary: 00000001 (our bit mask) AND 01101000 (value in the Accumulator) 00000000 (revised value in the Accumulator) This is so because AND only sets the target bits if both the source bit AND the corresponding bit from the bit mask are set (quite intuitive). Our next instruction branches to “firstbitclear” because the first bit was clear, but what if the value in the Accumulator was 101 (01101001) instead of 100? 00000001 (our bit mask) AND 01101001 (value in the Accumulator) 00000001 (revised value in the Accumulator) As you guessed, the code would instead jump to the subroutine “firstbitset”; that’s all there is to bit masking – you can use an AND bitmask to check for each of the bits in a byte individually (such as when you’d like to create a group of bit variables out of a single byte). To set a target bit in a byte we can use OR: LDA myvar ORA #%00000001; set first bit Suppose myvar (now in the Accumulator) contained the number 100 (01101000 in binary): 00000001 (our bit mask) OR 01101000 (value in the Accumulator) 01101001 (revised value in the Accumulator) As you can see, OR sets the target bits if either bit is set; our OR bit mask here specifies that bit 1 must be set but we could set more than one bit at a time if we like: 10001011 (our bit mask) OR 01101000 (value in the Accumulator) 11101011 (revised value in the Accumulator) As you can see a bit set in either expression will become set in the OR result. To flip a target bit in a byte, we use an exclusive OR, EOR: LDA myvar EOR %11111111 Suppose myvar (now in the Accumulator) contains zero (00000000): 11111111 (our bit mask) EOR 00000000 (value in the Accumulator) 11111111 (revised value in the Accumulator) Now suppose myvar contains 255 (11111111): 11111111 (our bit mask) EOR 11111111 (value in the Accumulator) 00000000 (revised value in the Accumulator) An exclusive or flips the target bits because it literally means either or, but not both (again quite intuitive). BIT Marshalling operations – ROL ASL ROR LSR The bit marshalling operations are quite powerful; ASL and LSR will shift the bits left and right respectively: ASL can also be used to multiply by two in one step (the 6502 has no MUL instruction) 000000010 (2) becomes 00000100 (4). LSR can be used to divide by two in one step: 00000100 (4) becomes 00000010 (2). If a bit falls off the end the carry flag bit variable is set, and ROL and ROR are similar variations except they push the carry flag bit variable into the binary expression instead of an empty bit; this is great for working with multiple bytes. Hexadecimal (Optional) Nevermind; all you need to know for advanced Assembly programming is binary because the DASM Assembler will translate it for you anyway (you produce a Binary when Assembling, not a Hexagonal and the internal operations are all binary). But fine if you want to know it it’s simple - it’s just base 16 and for added fun you can go on to learn base 8, base 24 and then build a Tetrahedron so that you can shower in cool quantum fluids like Liquid Helium. There is a valid reason for using Hexadecimal though; if you typed in a BASIC listing in the 70’s or 80’s you probably saw data statements like “DATA FF, FE, FD” which saved magasine space over “DATA 255, 254, 253” – that’s 3 bytes per byte vs. 4 or a 25% saving (3 pages of code for you to type in vs. 4). This author wrote a shifting algorithm 30 years ago that saved even more magasine space to the tune of 1.2 bytes per byte vs. 3 for Hexadecimal notation. That translates to about a page of code to type in vs. 3 or 4 for the Hexadecimal and Decimal variations - with programming there’s always another way. So here it is, we can translate binary into hexadecimal quite easily as follows: 11111111 =F F See how it works? The first four bits are the first letter/digit, 0-F and then the next four bits are then second letter/digit. Now build a Tetrahedron Binary Operations Beyond 8-bit You don’t need these to build Tank programs; let’s move on to the only place you’ll really need them - for the game score (and even there we can do a better job if we just think what would Neo do? and change the rules a bit). Neo changing the rules of the Matrix. How to tabulate game scores beyond 250,000 with just 12 bits We already covered how two bytes can be used to represent a 16-bit number up to 65,535 but this still isn’t really big enough for the score unless you want to award the player a paltry point or 10 at a time and that’s simply not so much fun; players like to score 100 points at a time or more – chances are you’re a player too so you know exactly what I’m talking about. Here’s the concept we’ll ignore because memory’s expensive anyway and this score doesn’t go high enough: Byte Byte 11111111 11111111 (or 65,535) (bits in order of most significant to least significant). Instead we’ll award players at least 100 points at a time with a byte and ½ (4 bits are also known as a Nybble by the way): Byte Nybble 11111111 0000 (or 255,000) Here’s how it works: the first byte represents thousands and we increment it everytime the Nybble reaches 10 (and clear the Nybble). For each increment of the Nybble before 10 we add 100’s. It’s that simple: Byte Nybble 11111110 0011 (or 254,300) Note that the maximum value of the score becomes 255,900 before the player flips it (an admirable goal). This is more than large enough for any Tank program. Here’s a variation if you want players to receive score increments as small as 50 points instead of 100 – use a phat Nybble (5 bits) and add 50 for each increment of the Nybble up until it reaches 20 whereupon it is cleared and we increment the byte representing 1,000’s. Chapter Review: Congradulations! There was alot to absorb in this lesson but it was easy because you already knew the concepts and more importantly you were already writing games in Assembly. Take a break and have some coffee, then get back on your LightCycle; the remaining chapters on Bankswitching and Memory management are just semantics - all we have left is to dot the i's and cross the t's.

Very cool FujiSkunk! I also started gaming on a B&W Television (and programming on a Teletype) chuckwalla, I gave River Raid a try in B&W; nice to find another grayscale GEM amongst the classics!

Good one AtarianGuy Barnstorming is awesome in B&W - I never played this game until last night! rmaerz, I tried sky diver again in B&W but I still can't figure out the controls; I can only open the parachute by accident. Looks like I need to RTM...

Serious, I first noticed this about 10 years ago on a friends Plasma screen via the movie disclaimers; the glow is more intense than phosphor and green seems to glow the best - you don't notice it as much with other colours. Additional circuitry has been added to the plasma panels since then but the VCS signal really seems to enhance the luminosity and makes the panel glow like the early plasma displays used to do. Here's an explanation: http://www.funtrivia.com/askft/Question110209.html You'd need a plasma display to experience this effect though!

Games that Glow in Plasma I have a second VCS setup in my living room, a Vader hooked up to a large Plasma display (the Jr just isn't as iconic looking so it's in the basement with the antique Televisions). The luminosity of the VCS is unique and it turbocharges a plama display like no other retro console can; a plethora of colours that show up a bit dull on a tube Television undergo a startling transformation on Plasma, particularly shades of Green. Games like Popeye and Enduro literally come alive with vibrant colour. What are your favourite Plasma games? As a related subtopic, I've noticed many composite mods tend to flatten the outstanding luminosity of the VCS's colour output; I prefer the off spec signal

The Black and White console switch; what are you favourite games to play in grey scale? I've seen a few related threads but there are none I can find ranging the aspect of the Black and White switch I'm contemplating: The colour palette of the VCS is tremendous but it's grey scale compliment is also impressive and has a retro feel and ambiance all it's own - some of my favourite games to play in greyscale are: 1. Defender - even more fun than in colour. 2. Breakout - enough said 3. Pacman - has to be level six as well and it becomes an awesome game; more retro than any other pac version. 4. Space Invaders 5. Combat 6. Video Pinball 7. Chopper Command 8. Alien 9. Frogger 10. Boxing 11. Computer Chess 12. Pitfall There are some others that aren't implemented right like Mr Do (though it's great in colour) and some I'm not particularly inclined to play but playing these classics in greyscale makes me wish more of the greats had the BW palette option - I'm glad black and white Televisions were popular in the 70's