Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    135,961

BASIC Programming

Sign in to follow this  
Guest

544 views

A little spot of nostalgia as I haven't done anything on PoP in the past week:I enjoy reading the posts on the recently formed Atari 2600 Basic Programming Forum. A lot of the issues that are raised, and the problems faced remind me of my own experiences with BASIC programming many years ago. I think it is a shame that modern computers do not come with a built-in BASIC interpreter as it is a great tool for teaching programming to beginners without the complexities of pointers or objects (provided that we are not talking about Visual BASIC :)).I started with BASIC programming when I was around 7 years old, back in the early 1980s. Through various experiments on the school computer (described in a previous entry), I figured out the essentials, assisted by type-in magazine listings and library books. As a result of these experiments, most of which were simple games, my ambitions quickly turned to becoming a real games programmer. At that time there were frequent stories in the newspapers about wizz-kid programmers who made millions, though I'm not convinced they were actually true! I used to fill books with game ideas, waiting for the time when my programming skills would be good enough to create all of the wonderful games that I could imagine!post-4830-1097635853_thumb.jpgIt didn't take long before the limitations of the BASIC interpreter became very apparent to me. There was precious little memory, and even simple programs took an age to run. I knew that if I was to become a real games programmer then I would have to learn assembly language. But, compared to BASIC, it appeared to be a horribly complex and cryptic method of programming. Nonetheless, I had come this far, and I wasn't about to give up! I learned about binary numbers, and memorised the 6502 mnemonics from a book. I figured out how to use the accumulator and the stack, and I could write simple math operations. However, despite my best efforts at the time, I just couldn't figure out how to put it all together to make a game. For some reason, the complexity of writing a complete program was just too great, and I couldn't make the necessary leap. As a result, I stuck with BASIC for many years, moving to STOS BASIC for game creation when I later purchased an Atari ST. It wasn't until I reached university that the mysteries of assembly language became suddenly clear, and now I just can't figure out why I had so much difficulty.Looking back, it is clear why most machines of the time were bundled with BASIC. Despite the syntactic differences, there are many similarities between BASIC and 8-bit assembly language. The core compiler in batari BASIC is very straightforward as many of the BASIC operations can be directly mapped into assembly. Nonetheless, I can see that many people are struggling with the same issues that I faced. Despite the power of the tool, the limitations of BASIC programing remain, and it will be necessary for them to make the leap to assembly at some point. However, there is something about assembly language that remains mysterious and frightening to even the most accomplished of BASIC programmers. I hope some of them will be able to make the leap that eluded me all those years ago. Chris

Sign in to follow this  


13 Comments


Recommended Comments

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.

Share this comment


Link to comment
- 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.

Share this comment


Link to comment

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.

Share this comment


Link to comment

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.

Share this comment


Link to comment
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

Share this comment


Link to comment
- 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.

Share this comment


Link to comment
- 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.

Share this comment


Link to comment
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

Share this comment


Link to comment
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

Share this comment


Link to comment
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.

Share this comment


Link to comment
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.

Share this comment


Link to comment
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...

Share this comment


Link to comment
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

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...