Chronogamer

The Odyssey2 keyboard is certainly a huge advantage, but were it not for that I would think the 2600's cart would be in many regards superior. There are a few annoyances with Basic Programming, such as the fact that trying to print when the output buffer is full simply stops the program rather than ditching some text from the output buffer, but being able to watch the program execution on screen should count for a lot.

The Odyssey2 keyboard is certainly a huge advantage, but were it not for that I would think the 2600's cart would be in many regards superior. There are a few annoyances with Basic Programming, such as the fact that trying to print when the output buffer is full simply stops the program rather than ditching some text from the output buffer, but being able to watch the program execution on screen should count for a lot.

 

I'll grant that the ability to watch the program execution does count for a lot, not only as a technical feat but as a learning tool. What counted so much for me with CompIntro was the feeling I was learning an actual transferable form of assembler (whether true or not), while with BasicProg I felt like I was learning some adapted diluted version of BASIC that would only work for the 10 lines I could write on the Atari. As a beginner, it just feels like I could do more interesting things with CompIntro than I could with BasicProg.

 

Would it have been easier for Atari to have produced a learning tool to teach Assembler? Could the Odyssey^2 have been considered "cheating" by dropping the need for a BASIC compiler, which I would imagine take up more resources?

 

Again, while BASIC Programing may have been more of a technical achievement (i.e. harder to do) it just doesn't seem as useful as a learning tool. Perhaps my bias is that I have more knowledge of BASIC than I do of Assembler, or maybe I just appreciated the CompIntro manual more than Atari's.

It won't balance your checkbook or do your income tax or plot the course of a spaceship to Mars. But it will give you some idea of how those computers do their work."

 

Damn! I was hoping to plot a course to Mars with it!

 

Actually those were akin to the ambitions I had when I first learned to program on the Altair and, later, the Atari 400. Never got around to doing something ambitous like that but I still learned a lot. In fact, two of my friends had the chance to do something along those lines in their senior year of high school. They got the chance to work under the school districts planetarium director and wrote some FORTRAN programs to plot the course of our planets. Not the same as plotting the course of a spaceship, but cool nevertheless. If they had access to an Odyssey or and Atari (this project was in 1977) I think they might have been able to plot the courses on the TV screen instead of a clunky line printer. (Sorry for the babbling here, but I got a little excited).

 

If you, like me, are someone who wishes they had learned how to program at an early age, but didn't have access to a computer until it was comparatively too late...

 

What age would you consider too late? I didn't know how to program until I was 16 and I think I did OK by it. When I went to college in the late 70's and early 80's, many of my classmates programmed or the first time in their freshman year in school. I don't think any time is too late as long as you have a good book or teacher handy.

If you're doing it just for fun, it's never too late

 

I learned programming when I was 7 or 8 on a ZX81, which had a first class manual for their BASIC. In a way it was just like BASIC programming on the VCS though: Within the 1K of RAM available, your programms couldn't get much longer than what fit on a single screen

 

Thank heavens, instead of a RAM expansion I got a C64 then!

 

Only the C64 kinda stopped all my programming efforts for several years, since I was only playing games first.

(I think I only started programming the ZX81 because that was all you could do with it )

If you, like me, are someone who wishes they had learned how to program at an early age, but didn't have access to a computer until it was comparatively too late...

 

What age would you consider too late? I didn't know how to program until I was 16 and I think I did OK by it. When I went to college in the late 70's and early 80's, many of my classmates programmed or the first time in their freshman year in school. I don't think any time is too late as long as you have a good book or teacher handy.

 

"Too late" is when one becomes more interested in things other than learning to program. In my case, it was when I became more interested in girls and playing the piano. When I figured out some girls really liked piano players, even videogames hit the backburner.

 

(More recently, I have been learning to program in Flash, but now I'd rather play and write about games than program them.)

"Too late" is when one becomes more interested in things other than learning to program.

 

GASP!!!! There is NOTHING better than programming!!! Sacrilege!! Blasphemer!!!

 

Sure you can be distracted by girls or rock music or other things, but you always go back to programming. It's the very essence of logicial thinking and the meaning of life!!! What. Is. Wrong. With. You????

 

(More recently, I have been learning to program in Flash, but now I'd rather play and write about games than program them.)

I've been learning Flash off and on for the past 10 months (in fact, the Circles program I mentioned in my Blog was done with Flash). Actionscript is the bomb baby! There is no need to drop everything to learn Flash. Just do some reading or playing around on the thing when you get the chance. (At the risk of TMI, I keep a copy of the Actionscript for Flash 8 near my bathroom whenever I need to pay an extended visit. It's amazing how much reading you can get done in just a few minutes a day).

Here's where I learned to program. http://users.telenet.be/kim1-6502/6502/usrman.html. It was daunting as a child, and I felt like giving up at times, this Oddysey manual/cart looks a lot easier to tame.

What counted so much for me with CompIntro was the feeling I was learning an actual transferable form of assembler (whether true or not), while with BasicProg I felt like I was learning some adapted diluted version of BASIC that would only work for the 10 lines I could write on the Atari. As a beginner, it just feels like I could do more interesting things with CompIntro than I could with BasicProg.

 

There are some annoying quirks with Basic Programming, to be sure, but the language it implements is far more sophisticated than the so-called "assembler" of the O2 Basic Programming. I wonder how well one could have implemented a PIC emulator on the 2600, and whether that would have offered any interesting possibilities? I would think it might have offered some very nice ones. One can't do a whole lot in 32-64 PIC instructions, but it might not have been totally hopeless, especially if there were some useful pseudo-registers.

 

For example, if each keypad had a byte which indicated in 3 bits which column was pressed (if any) and in 4 bits which row, then something like a "Tennis" game could have been implemented something like:

; Assumes all registers start out zeroed; also assume user registers start at 0; system registers are at top.
; Regiser 0 is x velocity and 1 is y velocity
00 movlw $02
01 movwf R0
02 movlw $01
03 movwf R1
04 movlw $40
05 movwf Xball
06 movf $00,w
07 addwf xball
08 movlw $A0
09 subwf xball,w
0A btfsc status,0 ; Skip if carry clear, i.e. don't skip if X>=160
0B goto 00
0C movf R1,w
0D addwf yball
0E btfss yball,7 ; Skip the goto if >128
0F goto 13
10 subwf yball
11 clrf R1   ; Zero Y velocity
12 subwf R1 ; And subtract old Y velocity from it
13 movlw 4 ; Velocity for paddles
14 btfss leftpad,0
15 incf ypl0
16 btfss leftpad,1
17 decf ypl0
18 btfss rightpad,0
19 incf ypl0
1A btfss rightpad,1
1B decf ypl0
1C movf yp0,w
1D btfsc collis,0
1E goto 22
1F movf yp1,w
20 btfss collis,1
21 goto 2B
22 subwf yball,w
23 movlw $01
24 btfss status,carry
25 movlw $FF
26 movwf R1
27 movlw $02
28 btfsc xball,7
29 movlw $FE
2A movwf R0
2B movwf WAIT
2C goto $06

Hmm... 43 instructions for a pretty feeble tennis game. Actually 45 since I forgot to set the player 1 X position. There's no bounds checking on the paddle Y positions; they'll simply wrap. Bounds checking would probably be another two instructions each.

 

It's hard to know what sort of 'computer intro' cartridge would have been best. Warren Robinnet's was certainly ambitious. Not sure which is more practical.

 

After all, I didn't see a whole lot of possibilities for the Computer Intro cartridge. What could it do that Basic Programming couldn't, beyond its slightly larger memory capacity?

Slight addendum: the PIC instruction set actually existed on a real microcontroller in 1980. It has the advantage that--unlike the instruction set used in the "Computer Intro" cartridge--all instructions are the same length. Something like an adapted version of the Transputer instruction set might have been better still, but that hadn't been invented yet. Whereas all PIC instructions are 1.5 bytes long, the Transputer's instructions are all one byte. One of the instructions is used to handle extended values; thus an opcode of "$15" might mean "load the accumulator with the value 5", while "$F9 $15" might mean "load the accumulator with the value $95". Code would probably require a few more instructions with a set like that than with the PIC's, but the instructions would only use 2/3 as much space.

 

Another alternative would be to use two-byte instructions. Assuming a 16-register pseudo-machine, a nice instruction format might be:

• $qdnn -- (With q <= $0D) Perform operation q between register 'd' and constant 'nn'.
  
• $Eqds -- (With q <= $0D) Perform operation q between register 'd' and register 's'
  
• $EEds -- Swap registers 'd' and 's'.
  
• $EFqs -- Perform alternate-set instruction 'q' on register 's'
  
• $F000-$FFFF -- Other instructions
  

For the primary instruction set, I'd might go with fourteen instructions:

[*]MOV -- Dest <- Source
[*]IOR -- Dest <- Dest or Source
[*]EOR -- Dest <- Dest xor Source
[*]AND -- Dest <- Dest and Source
[*]ADD -- Dest <- Dest+Source
[*]SUB -- Dest <- Dest-Source
[*]ADC -- Dest <- Dest+Source+Carry
[*]SBB -- Dest <- Dest-Source-Carry
[*]XBS -- If (Dest and Source)!=0 execute next instruction (else skip)
[*]XBC -- If (Dest and Source)=0 execute next instruction (else skip)
[*]XEQ -- If (Dest == Source) execute next instruction (else skip)
[*]XNE -- If (Dest != Source) execute next instruction (else skip)
[*]XGT -- If (Dest > Source) execute next instruction (else skip)
[*]XLE -- If (Dest <= Source) execute next instruction (else skip)

The secondary instruction set would include bit shifts/rotates, one's complement, two's complement, etc. Jumps would be accomplished by loading register 14. Accesses to register 15 would access the register pointed to by register 13. Subroutine calls would be accomplished by putting the subroutine address into the register that will hold the return address, and then swapping that register with register 14.

 

Something like that instruction set might make a tennis game pretty workable. Interesting to ponder.

After all, I didn't see a whole lot of possibilities for the Computer Intro cartridge. What could it do that Basic Programming couldn't, beyond its slightly larger memory capacity?

I'm not being sarcastic when I say that, given your level of expertise, I'm pretty certain that you're in a far better position to see the posibilities of the Computer Intro cartridge than I am. If you don't see them, then I'm convinced that they're probably not there. Maybe the larger memory capacity and the layout of a real keyboard are the only things that elevate CI to a level of teaching effectiveness above BP's.

 

To draw an analogy to, well, drawing, if I gave a beginner (a kid, say) a notepad and a pencil, and gave another a good sized sketch pad with a box of 64 crayons, who'd be more excited about learning to draw? Yes, a pencil is a more precise instrument that can produce an infinite amount of shades and textures, but most would be beyond a beginner's ability to pull off. Also, 64 crayons and a big sheet of paper would probably go to waste on a beginner as they might not know what to do with all the space and all the colors. However, if given a choice between the two tool sets, most kids are going to pick the one with all the crayons because the pencil just isn't exciting enough. Will they necessarily learn to draw better with the crayons? Probably not, but it might keep them interested long enough so that they might decide to advance into more subtle mediums. I guess what I'm trying to say is that part of teaching is informing and part of it is inspiring someone to learn the information. On that playing field, that's what Computer Intro does that Basic Programming doesn't.

 

To another point, though, any eager enough student could learn in either environment, while any disinterested student would fail. It's the students who *might* get into it, if the environment can keep them interested long enough, that I think CI has the better potential of capturing, even if it's only because CI lets you use the built-in sprites.

 

On a technical level, though, I'm in no position to argue with you! You can take a technical discussion to a depth that makes my head swim.

Such a nice discussion for us geeks! I have to agree with Mezrabad, particularly after his excellent analogy above. Both carts are technically sound, but having more memory, a real keyboard, and a good manual must make all the difference. I didn't try these carts, though, but I'm merely talking from a user's perspective and ignoring my programming background.

 

When I say "better than," I'm saying something very similar, in spirit, to "kicks the ass of," "wipes the floor with," or "is not fit to tie the shoestrings of."

 

Hahaha