The Southsider

I also hope some are able to make the transition from batari Basic to assembly well enough to write a game. Perhaps the reason you didn't back in the early 80's was simply because you were so young and hadn't quite developed the reasoning skills needed to understand 6502 at a deep level. I mean, 7 is really young to understand any sort of programming, much less asm.

 

My story is a little different, probably because my age was in the double-digits all throughout the 80's. I did study asm on the Apple II back then, with some success. That's not to say I understood it fully, however. Some things didn't quite get through.

 

I did not fully understand how the carry bit worked, only that you had to do a CLC before an ADC. I had a minimal understanding of LSR/ROR/ASL/ROL but I couldn't conceive of a practical use for them.

 

And some things were a complete mystery:

 

- The V bit (actually, I'm still not entirely sure of this one.)

 

- The stack, and the instructions PHA, PLA, PLP, PHP, TSX and TXS. All I really knew is the stack lived at $100-$1FF, and putting stuff there caused strange things to happen.

 

- Cycles. I remember seeing that certain instructions took a certain number of cycles, but I didn't understand what a cycle was.

 

- The BIT instruction.

 

- SEI/RTI/BRK.

 

- Indexed indirect addressing, e.g. LDA ($00,x). Though in retrospect, it probably doesn't matter that I didn't get this addressing mode, as it's almost completely useless.

 

Given my relative ignorance, one would think that you couldn't write a game in asm without knowing the stuff above, but I did. I can't remember what I called it. It wasn't much of a game - it was essentially Space Invaders with no shields and only a single alien. It wasn't very exciting - My Basic games were much better. But the fact that it was in asm gave it more value to me.

 

If there is a point to any of this, if a pimply-faced 13-year-old can transition from Basic to asm enough to write a game, albeit a crappy one, I remain hopeful that some of the 30-somethings that use bB today will eventually do great things in asm.

- The V bit (actually, I'm still not entirely sure of this one.)

The overflow flag is set when a signed addition/subtraction overflows. I.e., when the result is a signed number that cannot be represented in a twos-complement byte.

 

So, 120+120 = 240, overflow flag set.

100+20 = 120, overflow flag clear.

-20 - (-120) = -140 [or 116] overflow flag set.

20 - 100 = -80 [or 176] overflow flag clear.

 

That make sense? It is useful sometimes. I've used it a whole bunch implementing fractional positioning.

Games are really a form of pseudo-multitasking. You have to do a lot of tasks fast enough to look as if they are all happening at once.

 

The reason writing games in BASIC is so tough is that there is no notion of timing. Stuff happens "as soon as it can" as opposed to every frame. The more logic you put into the main loop, the more sluggish the game becomes. (This is the first problem solved by bAtari Basic, by the way).

 

This really puts a damper on your enthusiasm, or a motivation to learn assembly. But that's the holy grail, to figure out how to position your code in such a way that the game updates on every frame.

 

I learned pretty quickly that I was not going to write my Star Raiders clone in AtariBASIC, though, and switched to writing AD&D character creator software instead.

 

And as for basic on modern machines, VBSCRIPT is part of windows. The problem with interpreted languages on modern machines is that there is no easy way to do sound and graphics. You are awash in the sea of Windows objects, most of which are not easily consumed by loosely typed languages like VBSCRIPT.

I wonder if QBASIC is still hidden on the Windows XP CD somewhere. I still use it for a variety of different things and on modern PCs it's amazingly fast.

 

I also cut my programming teeth on BASIC, starting with AppleSoft on the Apple ][+. My first ASM was 6809 on the CoCo; and when I tried to later learn 6502 I couldn't understand how to live without a 16 bit index register and dropped it until I got into 2600 programming.

 

Oh, and you're right batari. Indexed indirect is almost completely useless. I can't imagine many cases where it would be worth the ZP space to store an array of address pointers to single bytes. Better to store the array in main memory, copy the address pointer to ZP using ABS,X then access it with (ZP),Y. At least then your pointers can be to multi-byte objects.

If there is a point to any of this, if a pimply-faced 13-year-old can transition from Basic to asm enough to write a game, albeit a crappy one, I remain hopeful that some of the 30-somethings that use bB today will eventually do great things in asm.

 

Thanks for the story - I am always interested to hear how other people got into ASM programming. I think I was just a bit too young at the time to grasp all of the necessary the concepts. Also, I think that a big part of the problem for me was the difficulty in debugging assembly code. With BASIC, I could just add a few PRINT statements to find out what was happening, and buggy code wouldn't normally crash the machine. However, with assembly you had to use a machine monitor, and you could easily lock up the machine. This was particularly painful when working from casette tapes! However, with tools like the Emulators and the Stella debugger, this shouldn't be such an issue now.

 

- The V bit (actually, I'm still not entirely sure of this one.)

- SEI/RTI/BRK.

- Indexed indirect addressing, e.g. LDA ($00,x).  Though in retrospect, it probably doesn't matter that I didn't get this addressing mode, as it's almost completely useless.

 

I am still not entirely sure about these I only use the V bit with the BIT instruction, and I have never used indexed indirect mode, though it doesn't seem very useful. I think I understand the BRK instruction, but I haven't used it in any of my code yet.

 

Chris

- The V bit (actually, I'm still not entirely sure of this one.)

- SEI/RTI/BRK.

- Indexed indirect addressing, e.g. LDA ($00,x).  Though in retrospect, it probably doesn't matter that I didn't get this addressing mode, as it's almost completely useless.

 

I am still not entirely sure about these I only use the V bit with the BIT instruction, and I have never used indexed indirect mode, though it doesn't seem very useful. I think I understand the BRK instruction, but I haven't used it in any of my code yet.

Well, (ZP,X) does have a few uses. Notably, the BRK subroutine trick uses both the BRK opcode and the lda ($00,X) instruction.

 

BRK is also useful for debugging.

- The V bit (actually, I'm still not entirely sure of this one.)

- SEI/RTI/BRK.

- Indexed indirect addressing, e.g. LDA ($00,x).  Though in retrospect, it probably doesn't matter that I didn't get this addressing mode, as it's almost completely useless.

 

I am still not entirely sure about these I only use the V bit with the BIT instruction, and I have never used indexed indirect mode, though it doesn't seem very useful. I think I understand the BRK instruction, but I haven't used it in any of my code yet.

Well, (ZP,X) does have a few uses. Notably, the BRK subroutine trick uses both the BRK opcode and the lda ($00,X) instruction.

 

BRK is also useful for debugging.

That makes sense. But this trick only works on the 2600, not other 6502 systems. The stack normally lives at $100-$1FF, but on the 2600, it just happens to be mirrored into zero page.

 

Also, thanks for the info about the V bit - I think there was some code I was struggling with in a bB module that would actually benefit from this.

Games are really a form of pseudo-multitasking.  You have to do a lot of tasks fast enough to look as if they are all happening at once.  The reason writing games in BASIC is so tough is that there is no notion of timing.  Stuff happens "as soon as it can" as opposed to every frame.  The more logic you put into the main loop, the more sluggish the game becomes.  (This is the first problem solved by bAtari Basic, by the way).

 

Yes, as I'm sure you are aware this issue is particularly true on the 2600 as the display is directly controlled from the code. On other machines, you get slowdown if you exceed the time limits, but on the 2600 you have to make sure that even the slowest path in the code is within the limits, or the dreaded screen-roll will occur. I am not sure what you mean by this problem is solved in batari basic? The memory-mapped screen means that you don't have to update on every frame, but you still have a very limited number of cycles to do everything.

 

And as for basic on modern machines, VBSCRIPT is part of windows.  The problem with interpreted languages on modern machines is that there is no easy way to do sound and graphics.  You are awash in the sea of Windows objects, most of which are not easily consumed by loosely typed languages like VBSCRIPT.

 

Absolutely true. I doubt I would have been able to start programming at age 7 on a modern machine. There are just too many concepts to grasp before even the simplest tasks can be achieved. Just printing "Hello World" in a window from Java (and probably VBSCRIPT) can require pages of code!

 

Chris

I wonder if QBASIC is still hidden on the Windows XP CD somewhere.  I still use it for a variety of different things and on modern PCs it's amazingly fast.

 

I suspect that Qbasic will run on XP even if it is no longer supplied. I think PHP is the modern equivalent of BASIC - a very simple interpreted language that lets you do great things with web pages in only a handfull of lines without worrying about types or object.

 

Chris

I suspect that Qbasic will run on XP even if it is no longer supplied.  I think PHP is the modern equivalent of BASIC - a very simple interpreted language that lets you do great things with web pages in only a handfull of lines without worrying about types or object.

 

Chris

 

It definitely will I did this back when I had a Windows machine. I learned programming at the age of eight or so from my grandfather, who used to hack FORTRAN-IV on IBM mainframes in the 1960's. He's been a nerd as long as there have been nerds, and has passed all of his BASIC and Fortran knowlege to me. I'm still struggling with understanding the ins and outs of 6502, but I'm getting there.

 

I still love writing test code in BASIC though, it's good to see if things will actually work before translating them into the somewhat-less-familiar 6502.

Games are really a form of pseudo-multitasking.  You have to do a lot of tasks fast enough to look as if they are all happening at once.  The reason writing games in BASIC is so tough is that there is no notion of timing.  Stuff happens "as soon as it can" as opposed to every frame.  The more logic you put into the main loop, the more sluggish the game becomes.  (This is the first problem solved by bAtari Basic, by the way).

I am not sure what you mean by this problem is solved in batari basic? The memory-mapped screen means that you don't have to update on every frame, but you still have a very limited number of cycles to do everything.

I think the point here is that adding additional code into your bB game doesn't necessarily slow it down. The main loop should always run 60 times a second as long as the extra code doesn't exceed the number of cycles alloted to overscan. Other Basics will always slow down with additional code (unless you've got something funky like timed interrupts controlling the game's speed.)

 

This "feature" of bB is a double-edged sword, of course, because you really don't have much time for game logic, and the compiler does no checking to see if you have exceeded this time limit per frame.

This "feature" of bB is a double-edged sword, of course, because you really don't have much time for game logic, and the compiler does no checking to see if you have exceeded this time limit per frame.

 

 

Ok, so do the emulators? Just wondering because my game has gotten fairly complex. Never thought about this. I figured it would crash, or distort in an obvious way...

Ok, so do the emulators?  Just wondering because my game has gotten fairly complex.  Never thought about this.  I figured it would crash, or distort in an obvious way...

 

The z26 emulator has a -n flag to show how many scanlines the game is using. This should register at a steady 262lines/60Hz for an NTSC cart. If you exceed the limit, then it should be fairly obvious as the screen will flicker. The problem is that there can be paths on the code which are only reached occasionally, so a game can appear fine and then suddenly flicker at one point. I think the only way around this is lots of testing!

 

Chris