Search the Community

One of my big questions I have is how I would have an algorithm to figure out where it is on the scanline and then know how many scanlines it has written. I would have to do an increment after every single instruction, and that would waste many precious CPU cycles and ROM space. I guess I could have a register for the X-Position, one for the Y-Position, and one for where in the Scanline, and one for how many scanlines it's written. But wait, I will not only not have enough registers to use them for anything other then that, but I'll also be using more registers then there are inside the CPU.

Hey everyone, I'm very new to programming with assembly. Anyways, from the tutorial in this section of the forums I played around with the first kernel that is presented in Session 8. I made the lines alternate their colors with it. I ran it with SECAM60 after being satisfied, and wow is it an eyesore. I attached an image of the screen when I ran it. Challenge: look at the SECAM60 screenshot for 30 seconds and then turn away. pantomchap_test_game_5-17-2017-2.27PM.bin

Forth: The Cart Before the Horse (#5) This is one is going to be brief. If you've read any of the Forth primers, or any of the Forth proclamations that I and others make here on Atariage from time-to-time, you'll no doubt have read about how versatile and configurable the language is. We're going to have a very brief look at that today. But it won't be the War And Peace tome that I wrote yesterday. Brian Fox recently wrote some fascinating code for Camel99 that gives the language a more Basic-like syntax. As you probably know, in Forth, arguments and parameters to words (functions) come *before* the word/function that you want to call. This is because words/functions take their data, and put their data on the stack, so the stack has to be loaded before the word is called: TI BASIC: CALL HCHAR(ROW,COLUMN,CHAR,REPEATS) Forth: ROW COLUMN CHAR REPEATS HCHAR This tends to put people off when they look at Forth. It just looks like gobbledy-gook; at least until you understand that ROW and COLUMN etc are going on the stack, and HCHAR removes them. However, Forth is supposedly "the most flexible language of them all", "ultra malleable, "if you don't like it you can change it" blah blah blah. So, why don't we put our money where our mouth is and prove it? Well alrighty then! Inspired by Brian's look at HCHAR and VCHAR I thought it might be fun to demonstrate how the language can be changed to suit your preferences. There are some restrictions, sure, but I think you'll be impressed. We're going to change Forth's HCHAR and VCHAR into TI BASIC's HCHAR and VCHAR, where the arguments come after the word. So, again, let's recap: TI BASIC: CALL HCHAR(ROW,COLUMN,CHAR,REPEATS) Forth: ROW COLUMN CHAR REPEATS HCHAR We're going to end up with: CALL HCHAR( ROW COLUMN CHAR REPEATS ) Furthermore, we want it to be sophisticated enough such that the parameters can be numbers (called literals in Forth parlance) or calls to other words, or complex Forth expressions that compute a value etc. What might shock you is how much code is NOT required to do this. I give you: : CALL ( -- ) ; IMMEDIATE \ do absolutely nothing : HCHAR( ASCII ) WORD EVALUATE STATE @ IF COMPILE HCHAR ELSE HCHAR THEN ; IMMEDIATE : VCHAR( ASCII ) WORD EVALUATE STATE @ IF COMPILE VCHAR ELSE VCHAR THEN ; IMMEDIATE Now, you can type this directly on the command line: PAGE CALL HCHAR( 10 10 42 10 ) CALL VCHAR( 10 10 42 10 ) And behold the awesomeness. Note the spaces: The space between the open parenthesis of HCHAR( and VCHAR( is essential. The spaces between the parameters are just normal for Forth (and actually looks much nicer than using commas). The space before the final closing parenthesis is also required. You just changed Forth to be more like BASIC. You don't have to have numbers in the parameter list. They can be words or expressions: 10 CONSTANT TEN 42 CONSTANT FORTY-TWO CALL HCHAR( TEN TEN FORTY-TWO TEN TEN + ) (That last phrase: TEN TEN + puts 10 on the stack, then another 10 on the stack, then + ("add") removes them and replaces them with their sum, thus leaving the repeat count for HCHAR) So how does it work? Let's look at CALL first. CALL does nothing. It's only job is to be there to make those more familiar with BASIC happy. It has no code in it; it's empty. Furthermore, it's what is known as an IMMEDIATE word, meaning that it executes DURING COMPILATION, not during execution. An example: : FRED ( -- ) CR ." I AM FRED" CR ; Type that in. Nothing much happens. The word FRED gets stored in the dictionary ready to be used. Now type FRED and press enter. FRED executes. No big deal. Now, type this: : BOB ( -- ) CR ." BOO! BOB WAS HERE!" CR ; IMMEDIATE Okay, you typed it in. Nothing much happened. Now execute it: type BOB and press enter. Again, no big surprises. Now, try this: : TOM ( -- ) BOB CR ." HELLO! I AM TOM!" CR ; Did you see what happened? While *TOM* was being compiled, BOB got in on the act and ran, rather rudely announcing his presence. So what happens if we run TOM (type TOM and press enter)? HELLO! I AM TOM! Where's BOB? Should BOB not also say BOO!? No. And the reason why is very clever and is the secret sauce that makes Forth so very powerful. Here it is: "Immediate words execute at compile time." That is, immediate words execute when a word is being compiled, *not* when the compiled word is executed! That's possibly a brain-hurting statement. Consider this TI BASIC code: 10 CALL HCHAR(10,10,42,10) Now, when you press enter, the TI BASIC compiler switches on and compiles your code into some internal magic code that will do what you want it to do when you later RUN it. Okay. All normal stuff. But consider this: When the TI BASIC compiler is compiling that line of code, it does so entirely privately. No have no control over what compiler does. Mind your own business, it's nothing to do with you. The compiler privately compiles that code (or doesn't if there's an error), and you are just a bystander. That's not the case in Forth. In Forth, you can use "immediate" words that run when the compiler is compiling. And because they run when the compiler is compiling, you can "hijack" the compiling process, and do something: make a fart sound; say something on the speech synth; load a file; anything you want. You can even compile your own code. Think about that. Code that compiles code. And THAT is what makes Forth so powerful. So, lets get back to TOM and examine what happened. In Forth, the compiler is switched on by : (colon) and switched off by ; (semi-colon): : SOME-WORD <CODE GOES HERE> ; The compiler just walks along the line of text, and when it sees a word it looks for it in its dictionary and if it finds it, it compiles a call (like a GOSUB) to it. Now you can see why spaces are so critical in Forth. They are what separate the words so that they can be found in the dictionary. However, when the compiler is looking for a word, if it finds it, it checks to see if it is immediate or not. If it is not, it just compiles a call/GOSUB to the word. However, if it *is* immediate, it *executes* it, and does not compile it. That means you can put a reference to an immediate word in your definition, and at that point in the compilation process it will call your immediate word, and *you* can do something to the word that is *currently* being compiled, like add some more code to it. When the immediate word ends, the compiler just carries on compiling, totally oblivious to anything you may or may not have done to the word currently being compiled. It's none of its business. It's your business. You are in total control. Thus when TOM was being *compiled* the compiler saw the reference to the word BOB and saw that it was "an immediate word" and so it executed BOB, and BOB did it's thing (in this case, writing a cheeky message to the screen) and then carried on with the compiling. Now you understand why, when TOM was *executed*, there was no message from BOB. BOB did it's thing while TOM was being *compiled*. Yes. In Forth, there are two distinct excecution phases: Run-time: When a word is just plain excecuting, doing its thang; Compile time: When a word is being compiled. And you can do whatever the hell you want in either phase. You might want to go for a little lie down at this point! Now, lets look at HCHAR( and see what it does: : HCHAR( ASCII ) WORD EVALUATE STATE @ IF COMPILE HCHAR ELSE HCHAR THEN ; IMMEDIATE When the compiler sees HCHAR( it sees that it is immediate and so it executes it. The first thing is does is place the ASCII code for a ) (closed parenthesis) on the stack. Then WORD executes. WORD reads the line of text and will stop when it sees the ) character. So, if you typed CALL HCHAR( 1 2 42 4 ) WORD would capture 1 2 42 4 The output of WORD is two numbers: The address and length of the text that it found. This is fed into EVALUATE that simply evaluates the string as if it were a line of code entered at the keyboard. In this case, 1 2 42 4, or TEN TEN 42 TEN etc. are all valid code, so it executes it according to the rules of Forth: If we're compiling (i.e. the compiler was switched on with : (so we're building a word) then it will compile what it sees; If we're not compiling, it will just execute what it sees there and then, just like in BASIC when you enter something without a line number. So, we're using EVALUATE to evaluate the parameters for us between the HCHAR( word and the closing ) character. Note the cheeky use of the open parenthesis in HCHAR( which makes it look like some part of the the syntax of the word, but it isn't: It's just part of the name! And note also the closing parenthesis which again looks like syntax but is in fact nothing more than a marker for WORD to look for to isolate the parameters so that it can feed them into EVALUATE. The magic of Forth. The last bit of HCHAR( is very simple indeed. It just looks to see if we're in compile mode (the variable STATE will be 0 if we're not compiling, and >0 if we are compiling). If we ARE compiling, we compile a call to HCHAR (the original version of HCHAR built into the TurboForth EPROM). See? We're "injecting" code into the definition that is being compiled. However, if we're NOT compiling, we just execute HCHAR right there and then, which uses the parameters that EVALUATE evaluated for us. Thus we can do: CALL HCHAR( 1 2 42 99 ) (i.e. not in a definition, so it will execute immediately, like BASIC code with no line number) Or : LINE ( -- ) CALL HCHAR( 1 2 42 10 ) ; And both will work fine and do what they're supposed/expected to do. So, again, here's what happens when that LINE defintion above is compiled: The compilier sees that CALL is an immediate word, so it runs it. CALL actually does precisely nothing, it compiles nothing and runs nothing. It has 0 impact on run-time speed. It's purely "syntactic sugar" to sweeten things up for BASIC lovers. It's a total sham. You don't need to use it at all. The compiler sees that HCHAR( is immediate so it runs it. HCHAR( temporarily takes over, and reads the input up to the closing parenthesis and evaluates them. Since we're building a definition (LINE) the compiler is ON, so EVALUATE will compile them (by calling a new instance of the compiler and saying "HEY! Compile this! Thanks man!" (How's that for a mind f**k!?). HCHAR( then exits, it's done it's thing. Control now goes back to the compiler. The compiler only sees ; (semi-colon) because the parameters were consumed by WORD and EVALUATE so it completes the definition and we're done. If you were to disassemble the definition of LINE what you would see is this: 1 2 42 10 HCHAR In other words, HCHAR( re-arranged the code so that the parameters went first, then called a reference to the internal (in the EPROM) HCHAR which expects the parameters to be on the stack. The whole HCHAR( definition is nothing more than a trick which allows us to put the parameters *after* HCHAR( but internally it compiles HCHAR after the parameters. And that is the power of Forth. If you don't like: ROW COLUMN CHAR REPEATS HCHAR You can make your own word to give you: CALL HCHAR( ROW COLUMN CHAR REPEATS ) Or any other combination. And there endeth the lesson. This is without a doubt a bit of mind melter when you are new to Forth, so don't worry if you don't understand it all. I just wanted to give you an appreciation of the power and flexibility of Forth. It's not essential to understand this stuff right now. And now a quick demo using our new words. We haven't covered a lot of the code below yet. For now, just sit back and enjoy. : FWD-BOX ( -- ) 30 0 DO 12 0 DO CALL VCHAR( I I I 33 + J + 24 I 2* - ) CALL VCHAR( I 31 I - I 33 + J + 24 I 2* - ) CALL HCHAR( I I I 33 + J + 32 I 2* - ) CALL HCHAR( 23 I - I I 33 + J + 32 I 2* - ) LOOP LOOP ; : REV-BOX ( -- ) 0 29 DO 12 0 DO CALL VCHAR( I I I 33 + J + 24 I 2* - ) CALL VCHAR( I 31 I - I 33 + J + 24 I 2* - ) CALL HCHAR( I I I 33 + J + 32 I 2* - ) CALL HCHAR( 23 I - I I 33 + J + 32 I 2* - ) LOOP -1 +LOOP ; : BOXES ( -- ) \ top-level - run me 1 GMODE 5 0 DO FWD-BOX REV-BOX LOOP 0 GMODE ." Thanks for watching!" CR ; Note the additional spaces in the paremeters so that it's easier to identify each paremeter. References: HCHAR - http://turboforth.net/lang_ref/view_word.asp?ID=220 VCHAR - http://turboforth.net/lang_ref/view_word.asp?ID=232 IMMEDIATE - http://turboforth.net/lang_ref/view_word.asp?ID=163 ASCII - http://turboforth.net/lang_ref/view_word.asp?ID=210 STATE - http://turboforth.net/lang_ref/view_word.asp?ID=189 COMPILE - http://turboforth.net/lang_ref/view_word.asp?ID=156 IF - http://turboforth.net/lang_ref/view_word.asp?ID=81 THEN - http://turboforth.net/lang_ref/view_word.asp?ID=88 ELSE - http://turboforth.net/lang_ref/view_word.asp?id=76 CONSTANT - http://turboforth.net/lang_ref/view_word.asp?ID=157 CR - http://turboforth.net/lang_ref/view_word.asp?ID=129 ." - http://turboforth.net/lang_ref/view_word.asp?ID=206 DO - http://turboforth.net/lang_ref/view_word.asp?ID=75 LOOP - http://turboforth.net/lang_ref/view_word.asp?id=84 +LOOP - http://turboforth.net/lang_ref/view_word.asp?id=69 I - http://turboforth.net/lang_ref/view_word.asp?ID=80 J - http://turboforth.net/lang_ref/view_word.asp?ID=82

Forth: Bouncing some ideas around (#3) In this short tutorial we'll start with something really simple: We'll get a bouncing ball moving around on the screen. As we develop our words, we'll test them as we go, rather than run the whole program in one go only to find that it doesn't work and wonder where the bugs could possibly be. When we've got the ball moving around, we'll add a bat that we can use to hit the ball. Think old style breakout. We're going to restrict ourself to characters in 32 column mode. We'll look at sprites in a future lesson; I'll just say this: Sprites are in some respects simpler than characters when it comes to moving them around, because you don't need to erase them, so there's great difficulty coming down the line regarding sprites. If your curiosity cannot be contained however, have a look at the sprite tutorial here: http://turboforth.net/tutorials/graphics.html#95 So, here's a program that bounces a ball (a zero character, actually, at the moment I'm into a rather odd "less is more" period when it comes to graphics, and am particularly fascinated with ASCII graphics; check out some of those old ZX81 games and you'll see what I mean) around the screen, inside a frame, just to keep things tidy. First in TI BASIC so that we have something as a reference: 10 CALL CLEAR 20 REM DRAW FRAME AROUND SCREEN 30 CALL HCHAR(1,2,ASC("-"),30) 40 CALL HCHAR(24,2,ASC("-"),30) 50 CALL VCHAR(2,1,ASC("|"),22) 60 CALL VCHAR(2,32,ASC("|"),22) 70 CALL HCHAR(1,1,ASC("+")) 80 CALL HCHAR(1,32,ASC("+")) 90 CALL HCHAR(24,1,ASC("+")) 100 CALL HCHAR(24,32,ASC("+")) 110 REM DEFINE BALL VARIABLES 120 BALL_COL=2+INT(RND*29) 130 BALL_ROW=2+INT(RND*21) 140 XDIR=1 150 YDIR=1 160 REM ERASE BALL 170 CALL HCHAR(BALL_ROW,BALL_COL,32) 180 REM CALCULATE NEW BALL POSITION 190 BALL_COL=BALL_COL+XDIR 200 BALL_ROW=BALL_ROW+YDIR 210 CALL HCHAR(BALL_ROW,BALL_COL,ASC("0")) 220 REM CHECK FOR EDGE OF SCREEN 230 IF (BALL_COL<3)+(BALL_COL>30)THEN 260 240 IF (BALL_ROW<3)+(BALL_ROW>22)THEN 290 250 GOTO 170 260 REM REVERSE X DIRECTION 270 XDIR=-XDIR 280 GOTO 170 290 REM REVERSE Y DIRECTION 300 YDIR=-YDIR 310 GOTO 170 We'll now look at how we could re-create this program in Forth. Note how I have separated the code above into distinct sections (using blank lines here for clarity). We'll divide (or "factor") the Forth version into pretty much the same sections, testing them as we go. Drawing the Frame Around The Screen Okay, in the program above, we need to clear the screen and then draw some lines and characters. Note that I've used the ASC function to make the code a little more "self-describing" who wants to waste time looking up ASCII codes, right? In Forth, there's an extra step, as we first need to tell the system to go into 32 column mode (TurboForth and fbForth default to 40 or 80 column text modes). The (TurboForth) command to change graphics modes is GMODE. Mode 0=40 column text mode 1=32 column graphics mode 2=80 column text mode So, lets create a word called FRAME which sets up the screen and draws the frame. : FRAME ( -- ) \ set up screen and draw frame 1 GMODE \ 32 column text mode 0 1 ASCII - 30 HCHAR 23 1 ASCII - 30 HCHAR 1 0 ASCII | 22 VCHAR 1 31 ASCII | 22 VCHAR 0 0 ASCII + 1 HCHAR 0 31 ASCII + 1 HCHAR 23 0 ASCII + 1 HCHAR 23 31 ASCII + 1 HCHAR ; Things to note in the above code: : FRAME - this part says "hey, here's a new word called FRAME; ( -- ) this is comment that tells us that word has no effect on the stack - it takes nothing from the stack and puts nothing on the stack; The \ (backslash) is a comment. When TurboForth see this is treats eveything following it as a comment; Screen coordinates are zero-based, whereas in BASIC they are one-based Read the code from left to right, top to bottom. You can have multiple instructions on the same line; The "arguments" to the function/word (in this case HCHAR and VCHAR) come BEFORE the word itself. Why? Because the words/functions take them from the stack, so they need to be on the stack BEFORE the word itself executes; The command ASCII looks at the character in front of it and pushes the appropriate ASCII value to the stack. So ASCII * is like ASC("*") in TI BASIC; Spaces are ESSENTIAL in Forth. One or more spaces MUST separate words and numbers from each other. Forth cannot recognise 99STARS if you really mean 99 STARS; The semi colon at the end says "Okay, I'm done defining my FRAME word, thank you very much, add it to the dictionary" (where all the Forth words and their code are stored). At this point, you've added a new word to the language called FRAME. Now that it exists, any other word that you create can use it. So how do we use it? We "name" it. I.e. we type its name. Forth will do the rest. If we type FRAME on the command line (i.e. when the cursor is sitting there blinking at you) then it will immediately execute it. This is the same as typing something in TI BASIC without a line number in front of it. TI BASIC will just execute it (or try to); If we type FRAME inside another definition, then it will be compiled for execution later. This is the same as putting a line number in front of something in TI BASIC. TI BASIC will store it and run it later. So, assuming you have typed the above in (the best way is to use Classic99 and just copy the text above and paste it into TurboForth) you can just type FRAME (or frame - TurboForth is not case sensitive by default (you can turn it off)) and press enter and the code will run. So, hopefully, you have a neat frame around the screen and TurboForth is saying OK at you and furiously flashing its cursor at you. We can now move on to the next bit. Note that TurboForth is still in 32 column mode. You can leave it in 32 column mode if you like, but you might be more comfortable in 40 column mode on a real TI, or, if you have an F18A or you are using classic99, 80 column mode. Type either 0 GMODE and press enter, or 2 GMODE and press enter. The screen will clear and the mode will be changed. Let's move on. We've tested FRAME, it does just one thing and has no variant behaviour, so it either works or it doesn't. The Value of VALUEs The next step of the program sets up the initial ball and row and column variables, let's remind ourselves: 110 REM DEFINE BALL VARIABLES 120 BALL_COL=2+INT(RND*29) 130 BALL_ROW=2+INT(RND*21) 140 XDIR=1 150 YDIR=1 In TI BASIC, you can go ahead and just use a variable name. Forth is not like that. In Forth everything must be created first and stored in the dictionary, then you can reference it. So, we first need to declare our variables. However, in this tutorial, as it's very early days, I'm going to suggest that we use VALUES as they work more like variables in BASIC (i.e. they work with values; whereas variables in Forth work with addresses - that's for another day!) 1 VALUE BALL_COL 1 VALUE BALL_ROW 1 VALUE XDIR 1 VALUE YDIR So, this bit of code creates some VALUEs called BALL_COL, BALL_ROW, XDIR and YDIR respectively. The number is the initial value. Here's how 0 VALUE BALL_COL is evaluated: 0 is pushed onto the stack; The word VALUE (a built-in TurboForth word) executes. VALUE is programmed to *read ahead* of itself and use the word it finds there as the *name* of the value to create, so in this case, it creates a VALUE in the dictionary called BALL_COL. The initial value (0) that is on the stack is removed, and is used to initialise BALL_COL. If we had typed 99 VALUE BALL_COL then it would be initialised with 99. Declaration of VALUES/VARIABLES should NOT be done inside a definition. They should be by themselves. Some words are special in Forth and can only be used on the command line, just like (for example) NEW in TI BASIC, which can only be used on the command line. So, that's the declaration of the VALUEs done. You can test them by simply typing their name and pressing enter: BALL_COL <enter> Note that TurboForth responds with OK:1 meaning that 1 number is on the stack. What happened? You just "executed" a VALUE. Sounds strange doesn't it? I mean, you can't execute, say, variables in BASIC. What does it mean to execute a VALUE or a variable? Well, in the case of VALUEs in Forth, they are pre-programmed (once you have created them) to push their current value to the stack when you execute them. It's as simple as that. If you're used to OOP, think of VALUE as a class, and BALL_COL as an instance of class VALUE which took 0 as the constructor. Now, type YDIR <enter> TurboForth says OK:2 meaning that 2 numbers are on the stack. Let's look at them. There are two ways: The word .S will display what's on the stack, and leave them there for us (non-destructive) The word . (a dot/period) will take what's on the top of the stack and display it, removing it from the stack as it does so. Type .S <enter> TurboForth should display: 1 1 <--TOP OK:2 So, it's told you that 1 (YDIR) is on the top of the stack, and 1 (BALL_COL) is underneath it. Now, type XDIR .S <enter> TurboForth says 1 1 1 <--TOP OK:3 As an experiment, let's change the value of XDIR. Type: -1 TO XDIR See? That wasn't so hard was it? Pretty simple. Let's display the stack again: .S<enter> 1 1 1 <--TOP OK:3 Hang on. We changed XDIR to -1. Why does it still show 1 on the top of the stack? Surely it should display -1, right? No. The stack is a separate entity all by itself. It simply stores what you push on it. If you then change the value of something, good for you. You won't see it until you push it again. So, type XDIR again. TurboForth says OK:4 Now type .S and we get 1 1 1 -1 <--TOP OK:4 Okay, let's continue, but before we do, how do we clear those four numbers off the stack? There's a number of ways: type DROP DROP DROP DROP to drop (discard) them; type . . . . (four dots, separated by spaces) to display them (they get removed as they are displayed); Or, my favourite: type some random gibberish which causes TurboForth to empty its stack and display an error message: JFKDFDJKFJ ERROR: NOT FOUND OK:0 See? 0 items on the stack! Initialisation Right, now we need to initialise random starting row and columns for BALL_ROW and BALL_COL. So, let's make a word called SET_RC ("set row and column") that does just that: Type in or paste in the following: : SET_RC ( -- ) \ set row and column 30 RND 1+ TO BALL_COL 22 RND 1+ TO BALL_ROW ; That's it. How does this work? Well, this is a new word called SET_RC so when it is executed it will: Push 30 to the stack; Call RND which takes the 30 off the stack and uses it to generate a random number between 0 and 29. We need a random number between 1 and 30, so we call 1+ ("one plus") which simply adds 1 to the number on top of the stack. The phrase "TO BALL_COL" removes whatever is on the top of the stack and stores it in our VALUE which is called BALL_COL. The exact same technique applies for BALL_ROW, but using a different random number range. Let's test it. Make sure the stack is clear by typing some gibberish. Now type: SET_RC <enter> TurboForth says OK:0 - nothing was pushed to the stack. Let's see what was stored in BALL_COL and BALL_ROW: Type BALL_COL . BALL_ROW . <enter> (note the spaces between the dots) TurboForth will respond will respond with something like 13 9 OK:0, depending on what random numbers it chose. Let's look again, but this time using .S to show us the stack: BALL_COL BALL_ROW .S 13 9 <--TOP OK:2 This time, we executed the values directly, so they were pushed to the stack. Note how it's possible to put multiple commands on the same line separated by spaces. It's not necessary to enter them one at a time on separate lines, like this: BALL_COL BALL_ROW But you could if you wanted to. Placing commands/words together on the same line is a bit like using :: in Extended Basic to separate statements, only in Forth we just use spaces because there is hardly any syntax in Forth, you're in total control. Next, we need a word to erase the ball: Erasing The Ball : ERASE_BALL ( -- ) BALL_ROW BALL_COL 32 1 HCHAR ; There's not a lot of code there - it's hardly worth making a word just for this, *however* the advantage is that it means we can test it separately from the rest of our code. Let's test it: First, fill the screen with a character, using HCHAR like this: PAGE 0 0 ASCII * 960 HCHAR ERASE_BALL PAGE clears the screen (which resets the cursor position to the top of the screen) then we fill the screen (assuming you're in 40 column mode) with asterisks using HCHAR. You should see a hole somewhere where ERASE_BALL erased an asterisk. Good. So, how does it work? Well, during execution of ERASE_BALL, BALL_COL will push its value to the stack, BALL_ROW will push its value to the stack, we then push 32 to the stack (the ASCII code for a space character), and then we push 1 to the stack (the number of repeats - this is an optional parameter in HCHAR/VCHAR in BASIC, but NOT so in Forth). HCHAR then gobbles all those values up and uses them to draw a space at the correct place on the screen. Calculate New Ball Position Next, we need to re-create the calculation of the new ball position, and display of the ball. We're going to re-create this TI BASIC code: 180 REM CALCULATE NEW BALL POSITION 190 BALL_COL=BALL_COL+XDIR 200 BALL_ROW=BALL_ROW+YDIR 210 CALL HCHAR(BALL_ROW,BALL_COL,ASC("0")) : MOVE_BALL ( -- ) XDIR +TO BALL_COL YDIR +TO BALL_ROW BALL_ROW BALL_COL ASCII 0 1 HCHAR ; And voila. We have a new word, MOVE_BALL. Let's test it. We'll first make sure that the row, columns etc. are set to realistic values: 10 TO BALL_COL 10 TO BALL_ROW 1 TO XDIR 1 TO YDIR Note how I typed all that on one line. I could have typed: 10 TO BALL_COL 10 TO BALL_ROW 1 TO XDIR 1 TO YDIR But I'm lazy and impatient. Okay, so type in PAGE MOVE_BALL <enter> The ball should be displayed. Now type MOVE_BALL again. Now type MOVE_BALL MOVE_BALL MOVE_BALL MOVE_BALL <enter>. It should leave a trail of balls (ooer!). So how does it work? Here's the breakdown: XDIR pushes its value to the stack; The word +TO removes it and *adds* it to whatever is stored in BALL_COL; YDIR pushes its value to the stack; The word +TO removes it and *adds* it to whatever is stored in BALL_ROW; We then push the values of BALL_COL, BALL_ROW, the ASCII code for 0, and the number 1 (the number of repeats) to the stack; HCHAR removes them and does it's thing. Edge Detection Okay, we're nearly there! Next, we need to check if the ball is on a screen edge, and if it is then we reverse the direction of the ball in either the X or the Y direction. TI BASIC is rather terrible at this, because IF can only target a line number, so you're forced to separate the IF from the code that should run when IF is true. Just awful. In Forth we can do much better, however, the syntax may hurt your head a little bit. Not to worry, I'll break it all down. This is the TI BASIC code that we want to re-create: 220 REM CHECK FOR EDGE OF SCREEN 230 IF (BALL_COL<3)+(BALL_COL>30)THEN 260 240 IF (BALL_ROW<3)+(BALL_ROW>22)THEN 290 250 GOTO 170 260 REM REVERSE X DIRECTION 270 XDIR=-XDIR 280 GOTO 170 290 REM REVERSE Y DIRECTION 300 YDIR=-YDIR 310 GOTO 170 I'm going to create four new words: HIT_NS? (Hit north or south?) HIT_EW? (Hit east or west?) REV_XDIR (Reverse X direction) REV_YDIR (Reverse Y direction) Now, to be clear, we could write all of the above as one word. In fact, we could write the entire program as one word, but you'd have a terrible job trying to debug it! That's the advantage of breaking our code down ("factoring it") into small chunks. We can test them, and then just string them together at the end. So, here we go: HIT_NS? first: : HIT_NS? ( -- flag ) \ check hit on top or bottom of screen BALL_ROW 2 < BALL_ROW 21 > OR ; Whoa! That is some WEIRD looking code!! What on earth does it mean? Let me break it down step by step. There's only seven instructions, so it's not difficult to understand. It just LOOKS weird (most Forth looks weird, to be honest!) First, you need to be aware of the stack signature of this word: ( -- flag ) That means that this word takes nothing from the stack, but it does *leave* something on the stack. It leaves a flag (something that is either true or false). It's also very important to realise that the stack signature is a COMMENT. It's not a function parameter declaration like in C or Java. It's a comment that tells us *humans* what this word expects and leaves on the stack. Forth itself doesn't actually *know* what the word expects or leaves on the stack. It just dumbly tears through the code, obeying what it sees, and the results are the results. If the results are NOT what you expected, well, then YOU made a mistake somewhere! So, here we go: BALL_ROW pushes its value to the stack; We push the value 2 to the stack We execute the word < which means "is less than?" Is Less Than The word < or "is less than?" takes two values off the stack and compares them. If the first value is less than the second value, it pushes a -1 (true). If the first value is NOT less than the second value it pushes a 0 (false). It's as simple as that. So... at run time, BALL_ROW will be compared to 2, and if BALL_ROW *is* less than 2, the word "<" will push a -1 to the stack, otherwise it'll push a 0. We then do the same thing but using the word ">" is "is greater than?". Here, we compare BALL_ROW to 29, and if it *is* greater than 29, ">" will give us a -1, otherwise it'll give us a 0 on the stack. So, after the execution of these two lines of code, we'll end up with *two* values on the stack. The result of the < comparison, and the result of the > comparison. Next, we execute the word OR. OR takes two values off the stack and if the first value, or the second value, or both values are true, it pushes a -1 (true) to the stack. If both values are 0, it pushes a 0 (false) to the stack. So OR pushes the flag to the stack that we refer to in the stack signature for our word. We can prove that this will work at the command line, using numbers: -1 0 OR . (result is -1 (true) because one of the inputs to OR was true 0 0 OR . (result is 0 (false) because both inputs to OR were false). Let's have a quick look at the stack comments for these words: The word < has the stack comment ( a b -- flag ) which means flag will be true if a < b. A and b are removed from the stack. The word > has the stack comment ( a b -- flag ) which means flag will be true if a > b. A and b are removed from the stack. The word OR has the stack comment ( a b -- flag ) which means flag will be true if a or b are true. A and b are removed from the stack. All quite simple and logical. Okay, I'll rattle through the next one, it uses the exact same principle. It's just check East and West (left and right) screen edges. : HIT_EW? \ Hit east or west? BALL_COL 2 < BALL_COL 29 > OR ; I'll refrain from breaking this down as the principle is identical. I will however make a VERY brief detour and discuss paragraphs: Paragraphs: When we write in C or Java or assembly language we're used to leaving blank lines between lines of code. These are paragraphs, and they separate code up into logical blobs of code. Because Forth coded horizontally, we often use multiple spaces (two or three) on a line of code to break our code up into paragraphs. Consider HIT_EW? written in a horizontal style: : HIT_EW? \ Hit east or west? BALL_COL 2 < BALL_COL 29 > OR ; It reads okay (to someone that is used to Forth) but a better way to write it is like this: : HIT_EW? \ Hit east or west? BALL_COL 2 < BALL_COL 29 > OR ; That is probably a lot more readable to you. It certainly is to me. It's now much clearer that "BALL_COL 2 <" is a separate blob of code from "BALL_COL 29 >" because we separated them using paragraphs. It also takes up less screen space, and block space if you are using blocks. REV_XDIR (Reverse X direction) and REV_YDIR (Reverse Y direction) Okay, we're nearly finished. If you're having trouble reading all this stuff, spare a thought for the guy that had to write it! Let's finish up with REV_XDIR and REV_YDIR which will reverse the direction of the ball in the horizontal and vertical directions: : REV_XDIR ( -- ) \ reverse x direction XDIR NEGATE TO XDIR ; : REV_YDIR ( -- ) \ reverse y direction YDIR NEGATE TO YDIR ; You can probably see what these do. For XDIR, XDIR goes to the stack, NEGATE then negates whatever is on the stack (1 becomes -1 and -1 becomes 1 etc.) and then TO writes it back into XDIR. Same principle for YDIR. Let's test them: -1 TO XDIR REV_XDIR XDIR . TurboForth should display 1. I'll leave you to test REV_YDIR. Now we're going to write a word to roll these four words up. We'll call it CHECK_DIR for Check Direction. : CHECK_DIR ( -- ) HIT_EW? IF REV_XDIR THEN HIT_NS? IF REV_YDIR THEN ; I reckon right about now your head just exploded. I hope you're not sat on a bus as you read this. Just what in the name of Satan's Holy Trousers is that THEN doing at the END of a line? This doesn't make sense at all! Or does it? Well, actually it does. Here's a quick detour into how IF...THEN works in Forth. First, some BASIC to compare it to: 10 INPUT A 20 IF A < 10 THEN 50 ELSE 70 30 PRINT "FINISHED!" 40 END 50 PRINT "LESS THAN 10" 60 GOTO 30 70 PRINT "NOT LESS THAN 10" 80 GOTO 30 This absolutely vile, abominable code which forces you to go searching down the code for the appropriate line numbers (what if there was 100 lines of other code between them? Just vile) can be beautifully expressed in Forth thus: : CHECK ( n -- ) 10 < IF ." LESS THAN 10" ELSE ." NOT LESS THAN 10" THEN CR ." FINISHED" CR ; Go ahead and type that in. Note the stack signature. It needs a value passed into it from the stack: 9 CHECK 11 CHECK 10 CHECK You understand how this works now: We put 9 on the stack, then call CHECK which uses the 9 we just we put there, and so on. Let's break this CHECK word down: It puts 10 on the stack. Then "less than?" executes which will compare whatever we put on the stack to 10 and leave a true or false on the stack. IF then consumes whatever "less than?" left on the stack. If it was a TRUE then the code after the IF will execute, ELSE the code after the ELSE will execute, THEN normal execution will continue to the end of the word. The following should illustrate how this works, and it's important to realise that THIS IS VALID FORTH CODE (assuming the following words existed): SUNNY? IF GET-SHADES ELSE GET-JACKET THEN GO-OUTSIDE If you read that out loud, it reads like English. And well crafted Forth code, if factored nicely (which takes experience) will often read very close to English. It's clear from the above that the THEN denotes the continuation of the rest of the code. It's an "ENDIF" in other languages. Alright, so what do the other words do? Well, the word ." just prints a string. It needs a space between it and the string, and a closing " to indicate the end of the string. The word CR means "carriage return" and moves the cursor/current print position to the next line, scrolling the screen upwards if necessary. Putting It All Together Let's review all the code we have so far: : FRAME ( -- ) \ set up screen and draw frame 1 GMODE \ 32 column text mode 0 1 ASCII - 30 HCHAR 23 1 ASCII - 30 HCHAR 1 0 ASCII | 22 VCHAR 1 31 ASCII | 22 VCHAR 0 0 ASCII + 1 HCHAR 0 31 ASCII + 1 HCHAR 23 0 ASCII + 1 HCHAR 23 31 ASCII + 1 HCHAR ; 1 VALUE BALL_COL 1 VALUE BALL_ROW 1 VALUE XDIR 1 VALUE YDIR : SET_RC ( -- ) \ set row and column 30 RND 1+ TO BALL_COL 22 RND 1+ TO BALL_ROW ; : ERASE_BALL ( -- ) BALL_ROW BALL_COL 32 1 HCHAR ; : MOVE_BALL ( -- ) XDIR +TO BALL_COL YDIR +TO BALL_ROW BALL_ROW BALL_COL ASCII 0 1 HCHAR ; : HIT_NS? ( -- flag ) \ check hit on top or bottom of screen BALL_ROW 2 < BALL_ROW 21 > OR ; : HIT_EW? \ Hit east or west? BALL_COL 2 < BALL_COL 29 > OR ; : REV_XDIR ( -- ) \ reverse x direction XDIR NEGATE TO XDIR ; : REV_YDIR ( -- ) \ reverse y direction YDIR NEGATE TO YDIR ; : CHECK_DIR ( -- ) HIT_EW? IF REV_XDIR THEN HIT_NS? IF REV_YDIR THEN ; So far, you can probably see that we don't yet have a "program" as such. We just have a collection of words that each do something, but we need to glue them together. So, let's break out the glue: : BOUNCE ( -- ) FRAME SET_RC BEGIN ERASE_BALL MOVE_BALL CHECK_DIR AGAIN ; So, BOUNCE calls FRAME which draws the screen, and then SET_RC which sets our row and column values. Then, we BEGIN a loop. The word BEGIN marks the start of the loop. Then, we call ERASE_BALL, MOVE_BALL and CHECK_DIR. Notice how at this high level the code is quite generic. It's almost like English. It's just words strung together in a sentence: "erase ball, move ball, check direction" Then, we execute AGAIN which runs everything again from the word BEGIN (in reality, it jumps back to ERASE_BALL; BEGIN is just a marker to show where it jumps back to). So we have this in our main loop: "erase ball, move ball, check direction, do it again". It's English. Well factored code at the high-level will read like English. Sure, it's not so nice at the low level with all the stack management and stuff going on, but (and this is a big one) you tested all those words "on the way up". You know they work. No need to re-visit them. Your higher level words use the lower level words, and you can keep building your code up in this way. Words stand on the shoulders of other words. It's a LOT more sophisticated than line numbers, so it takes more practice, but once you've got it you won't want to do line numbers again. If you type the complete program in as shown and type BOUNCE you will see the program run. However, there are two problems: It's too fast. You can't really see anything; There's no way to exit. Let's fix that: : DELAY ( n -- ) 0 DO LOOP ; : BOUNCE ( -- ) \ top-level code FRAME SET_RC BEGIN ERASE_BALL MOVE_BALL CHECK_DIR 100 DELAY 0 JOYST 1 = UNTIL ; So, we've introduced a delay word which uses an empty loop just to spin the wheels for a while (more on DO...LOOP in a further article - hopefully someone else will write it! - it's generic; not specific to TurboForth) and we've changed BOUNCE as follows: We now read the first joystick (unit number 0). JOYST pushes a value on the stack according to what the joystick is doing. The only value we're currently interested in is 1, which means the fire button has been pressed. So: We push 0 onto the stack. JOYST uses it to read joystick 0 and pushes the result; We push the number 1 onto the stack; The word = ("equal?") tests the value that JOYST pushed against the 1 that we pushed. If they are equal then "=" will push a true else it will push a false; UNTIL consumes the number that "=" pushed. If it is TRUE then execution is allowed to continue past the UNTIL word, otherwise it loops back to begin. So, our code will loop back to the associated BEGIN word UNTIL the fire button is pressed. There's no code after the UNTIL so everything just stops. You can see that the program is not really a program until we get to the word BOUNCE. That's where a bunch of related, but unconnected words come together to make a program, yet BOUNCE is just another word that we've added to the system. This is how programs are grown in Forth. Of course, it's possible to be more sophisticated (where words leave values on the stack for other words to consume). We haven't done that much here. There is a bit of that going on in CHECK_DIR though. Well, this turned out to be a LOT longer than I was planning. If you stuck with me to the end then I'm grateful. The whole program, in it's finished form which you can cut and paste into Classic99: : FRAME ( -- ) \ set up screen and draw frame 1 GMODE \ 32 column text mode 0 1 ASCII - 30 HCHAR 23 1 ASCII - 30 HCHAR 1 0 ASCII | 22 VCHAR 1 31 ASCII | 22 VCHAR 0 0 ASCII + 1 HCHAR 0 31 ASCII + 1 HCHAR 23 0 ASCII + 1 HCHAR 23 31 ASCII + 1 HCHAR ; 1 VALUE BALL_COL 1 VALUE BALL_ROW 1 VALUE XDIR 1 VALUE YDIR : SET_RC ( -- ) \ set row and column 30 RND 1+ TO BALL_COL 22 RND 1+ TO BALL_ROW ; : ERASE_BALL ( -- ) \ erase ball from screen BALL_ROW BALL_COL 32 1 HCHAR ; : MOVE_BALL ( -- ) \ update ball position and draw it XDIR +TO BALL_COL YDIR +TO BALL_ROW BALL_ROW BALL_COL ASCII 0 1 HCHAR ; : HIT_NS? ( -- flag ) \ hit top or bottom of screen? BALL_ROW 2 < BALL_ROW 21 > OR ; : HIT_EW? \ Hit east or west? BALL_COL 2 < BALL_COL 29 > OR ; : REV_XDIR ( -- ) \ reverse x direction XDIR NEGATE TO XDIR ; : REV_YDIR ( -- ) \ reverse y direction YDIR NEGATE TO YDIR ; : CHECK_DIR ( -- ) \ reverse direction if hit screen edge HIT_EW? IF REV_XDIR THEN HIT_NS? IF REV_YDIR THEN ; : DELAY ( n -- ) 0 DO LOOP ; : BOUNCE ( -- ) \ top-level word FRAME SET_RC BEGIN ERASE_BALL MOVE_BALL CHECK_DIR 100 DELAY 0 JOYST 1 = UNTIL ; References: HCHAR - http://turboforth.net/lang_ref/view_word.asp?ID=220 VCHAR - http://turboforth.net/lang_ref/view_word.asp?id=232 < - http://turboforth.net/lang_ref/view_word.asp?ID=50 > - http://turboforth.net/lang_ref/view_word.asp?ID=54 = - http://turboforth.net/lang_ref/view_word.asp?ID=53 BEGIN - http://turboforth.net/lang_ref/view_word.asp?ID=72 AGAIN - http://turboforth.net/lang_ref/view_word.asp?ID=71 UNTIL - http://turboforth.net/lang_ref/view_word.asp?ID=89 OR - http://turboforth.net/lang_ref/view_word.asp?ID=95 ASCII - http://turboforth.net/lang_ref/view_word.asp?ID=210 VALUE - http://turboforth.net/lang_ref/view_word.asp?ID=168 TO - http://turboforth.net/lang_ref/view_word.asp?id=167 +TO - http://turboforth.net/lang_ref/view_word.asp?id=152 I hope you enjoyed learning some Forth.

I am re-listening to Intellivisionaries Episode 4, featuring Christmas Carol. James was talking about the bug he experienced at CGE. It got me thinking "what if there is a production bug in the next thing I make, how can I get some information about it?" So... Would it be possible for a running game to somehow catch a crash/Exception and write the ROM/RAM/STIC contents to a JLP "save slot"? I was thinking that if all of that was collected into a file that could be read later, it would be A Good Thing . I don't know if that means running the game within a kind of "container" or if there is some kind of hook that can be added to in the as1600 build process, or what. I think a JLP board would have enough storage to hold the largest Inty games several times over, definitely enough to store the entire state of a crashed environment. If the crash happens in emulation, the file could be parsed by some tooling, if it happens on a cart, I'm not sure how to physically get the data out... What do you think?

So hey there^^ I've decided to pick up and start learning bB and using the visual tool recently. To be honest,I've got more of a background in art, I've never programmed a day in my life before recently. Unfortunately, all of the information I've found so far seems really disorganized and I haven't found any sort of hub or directory that shows examples of code and explaining how the information actually works. I've had a few problems so far, but I know how to do part of what I want. If anyone could point me in the right directions when it comes to specific tutorials/ part of guides and such, that would be great. The project itself is called "Magnificent Heist" it's a top-down, Zelda-style, stealth based dungeon crawler where you play as a thief and have to evade lasers, spotlights, and security guards as you go deeper through a building to burgle treasure. Things I can do/ know I can do: - Create and place sprites (multiple copies of one as well) on a playfield - sprite animation multicolor sprite/pfcolor kernels (also the no_blank_line) - missile creation (I won't it for this project, however) - programming lives/ how to lose them - sound effects - items (temporarily invisibility cloaking device) Things I've struggled with: - creating working controls for the player - proper playfield dimensions/structure (how to form a "good" screen that's big and isn't cut off when emulated, how to design a level for the 2600) - Keeping Code Organized ( as the project gets bigger, I'm wondering how I'm going to keep everything straight/in their own sections) Things I'll need to figure out/learn eventually for this project - Title Screen - moving from one screen to another - applying a transition animation to that screen change (similar to the Zelda transition when you move screens) - Enemy logic (A spotlight/ guard chasing you if you get to close to a guard or touch a spotlight it and lose health/ a life to it once) - multiple "floors" with a few rooms on each floor, possibly the need to search the rooms for a key to get to the next floor - progressive difficulty with each floor - end goal that sends back to title screen So yeah, if anyone could give me some advice or point me in the right direction that would be great. As of posting this, my current issue is the inability to get the player character to move. I'm at work on my phone, so I'll have to wait until later to share the file/code, but If anyone has more advice, thoughts, scathing criticism, etc. I'd love to hear that as well ^^

MEMOIRS OF A NOVELTY ACCOUNT VOL. II, ISSUE IV Good evening. I am... Dracula. Ah ah ah. For me, this Monday was truly imperial. I was stuck at a certain part of my CS210 lexer assignment, and showed it to my instructor, saying "I feel like if I just get past this problem, I could finish this in two hours." He said he severely doubted my ability to do that. Guess what? I got past the problem and finished the assignment in two hours. And I even did it in less than 300 lines! In fact, I'm so freaking proud of this that I'll share it with the community. Here you go: /*-------------------------------------------------------------- Lexer Assignment CS 210 Rhindle the Dragon 2-27-2017 to 3-6-2017 Deep as a river, wide as the sea Changin' the ways of a captain and me--------------------------------------------------------------*/#include <stdio.h>#include <string.h>#include "keys.h"#define MAXSIZE 1048576#define WORKSIZE 256int iskeyword(char []);int isoperator(char []);int main(int argc, char *argv[]){ if (argc == 1) { printf("\nYou MUST specify the name of a file to read.\n\n"); return 0; } FILE *fp = fopen(argv[1], "r"); if (!fp) { printf("\nError opening file!\n\n"); return 1; } char a, master[MAXSIZE], working[WORKSIZE]; int i, j; /* This loop feeds the entire file into an array. */ for (i = 0; (a = fgetc(fp)) != EOF; i++) master[i] = a; fclose(fp); printf("\n"); /* The parsing portion begins here. */ for (i = 0; master[i] != '\0'; i++) { /* This section skips white space. */ if (master[i] == ' ' || master[i] == '\n' || master[i] == '\t') continue; /* This section checks for comments. */ else if (master[i] == '/' && master[i + 1] == '*') { printf("%c", master[i]); while (1) { if (master[i + 2] == '*' && master[i + 3] == '/') break; i++; printf("%c", master[i]); } printf("%c%c%c (comment)\n", master[i + 1], master[i + 2], master[i + 3]); i += 4; } /* This section checks for string literals. */ else if (master[i] == '\"') { j = 0; working[j] = master[i]; i++; j++; while (master[i] != '\"') { working[j] = master[i]; i++; j++; } working[j] = master[i]; working[j + 1] = '\0'; printf("%s (string)\n", working); } /* This section checks for character literals. */ else if (master[i] == '\'') { for (j = 0; j < 3; j++) { working[j] = master[i]; i++; } working[j] = '\0'; i--; printf("%s (character literal)\n", working); } /* This section checks for numeric literals. */ else if (master[i] > 0x2F && master[i] < 0x3A) { j = 0; while ((master[i] > 0x2F && master[i] < 0x3A) || (master[i] > 0x40 && master[i] < 0x47) || (master[i] > 0x60 && master[i] < 0x67) || master[i] == 0x23 || master[i] == 0x2E || master[i] == 0x5F) { working[j] = master[i]; i++; j++; } i--; working[j] = '\0'; printf("%s (numeric literal)\n", working); } /* This section checks for identifiers and possible keywords. */ else if ((master[i] > 0x60 && master[i] < 0x7B) || (master[i] > 0x40 && master[i] < 0x5B)) { j = 0; while ((master[i] > 0x60 && master[i] < 0x7B) || (master[i] > 0x40 && master[i] < 0x5B) || (master[i] > 0x2F && master[i] < 0x3A) || (master[i] == 0x5F)) { working[j] = master[i]; /* Feed lexeme into array */ i++; j++; } i--; working[j] = '\0'; if (iskeyword(working) == 0) /* Check if keyword */ printf("%s (keyword)\n", working); else printf("%s (identifier)\n", working); } /* This section checks for operators. */ else if ((master[i] > 0x27 && master[i] < 0x30) || (master[i] > 0x39 && master[i] < 0x3F) || master[i] == 0x21 || master[i] == 0x26 || master[i] == 0x5B || master[i] == 0x5D || master[i] == 0x7C) { j = 0; working[j] = master[i]; i++; j++; if (master[i] == '=' || master[i] == '.' || master[i] == '<' || master[i] == '>' || master[i] == '*') { working[j] = master[i]; j++; } else i--; working[j] = '\0'; if (isoperator(working) == 0) printf("%s (operator)\n", working); else { printf("ILLEGAL OPERATOR\n"); return 0; } } /* This is the default condition. */ else { printf("UNK\n"); return 0; } } printf("\n"); return 0;}int iskeyword(char working[]){ int k; int flag1 = 0; for (k = 0; k < MONKEY; k++) { if (strcmp(keys[k], working) == 0) { flag1 = 1; break; } } if (flag1 == 1) return 0; else return 1;}int isoperator(char working[]){ int k; int flag1 = 0; for (k = 0; k < BROADWAY; k++) { if (strcmp(opers[k], working) == 0) { flag1 = 1; break; } } if (flag1 == 1) return 0; else return 1;} And here's the header: /*++++++++++++++++++++++++++++++++++++++++ Lexeme List Header Rhindle the Dragon 2-27-2017 to 3-6-2017++++++++++++++++++++++++++++++++++++++++*/#define MONKEY 34#define BROADWAY 27const char *keys[MONKEY] ={ "accessor", "and", "array", "begin", "bool", "case", "else", "elsif", "end", "exit", "function", "if", "in", "integer", "interface", "is", "loop", "module", "mutator", "natural", "null", "of", "or", "others", "out", "positive", "procedure", "return", "struct", "subtype", "then", "type", "when", "while"};const char *opers[BROADWAY] ={ ".", "<", ">", "(", ")", "+", "-", "*", "/", "|", "&", ";", ",", ":", "[", "]", "=", ":=", "..", "<<", ">>", "<>", "<=", ">=", "**", "!=", "=>"}; Featured Photograph: 1882 Elgin pocket watch I bought with the refund money.

MEMOIRS OF A NOVELTY ACCOUNT VOL. II, ISSUE I As you may know, my blog Memoirs of a Novelty Account has not seen an entry for almost a month, and I apologize. Posting twice a week was difficult, even on winter break, but now that I'm back in college, schoolwork has caught up to me. However, I do wish to remain active on this site, so I am restarting Memoirs and will post an entry every Monday as long as I am able. This new series with its reorganized schedule shall be known as "Imperial Mondays". Again, all photographs on this blog were taken by me unless otherwise noted. The "Imperial Mondays" banner is a compilation of images from the Wikimedia Commons. Let's move on to the topic of the day. As I write this, I am sitting in CS 270: System Software. I really should be paying attention. Lately I have been designing a new programming language, which is sort of a cross between BASIC and FORTRAN. I won't share its name or logo here, as I have not trademarked them yet. Building a programming language is an integral part of the computer science curriculum. The next step is designing an interpreter for it, then a compiler. Ultimately we will be working with operating system kernels and lower-level, nitty-gritty crap. I plan on pursuing a career in this low-level area, because believe it or not, it has become my favorite part of computer science. Go figure. I hope this new series will do well. Not posting as often should give me a chance to bring more robust content to the table. Here's to "Memoirs of a Novelty Account, vol. II: Imperial Mondays".

I thought some members on this forum might not know about this and find it interesting. Zachtronics (creator of many super interesting PC puzzle games) has just released a new puzzle game called "TIS-100", which is all about solving puzzles through ASM programming on a made-up 80's computer system. As you play through the game you learn about the computer and who build it (and why). Here's the trailer for the game: https://www.youtube.com/watch?v=ZkUHGvy2pNU here's how they describe the game: It even comes with a 14-page PDF manual that you're meant to print out and use as reference while you code your solutions to the puzzles

I just finished programming a music program into my Commodore 64 in BASIC. I ran it before saving, and it worked fine. I saved it and turned the computer off, then back on and loaded it, then typed 'list' to make sure all the lines of the program were there. They were. So I ran it. All that I could hear was (the best way I can describe it) a clicking sound rather than the musical melody that was there before saving and loading. The program ran for it's regular cycle and exited like it was supposed to, but the sound was messed up. I tried this a few times with the same results. Thinking that perhaps my sound chip was burned out, I loaded games on both cartridge and floppy disk. They worked fine. So my next step was to type the program again, save it under a different name and on a different disk, and run it. Same results.The last thing I did was turn the computer off and back on, then type the program into it again. I ran it without saving and it worked fine. Bad drive maybe? It's just weird that I can load it and the program shows all the lines, but it won't work right. And only after loading it from a 5.25 floppy. Any ideas or thoughts? Just so you know, I am doing this on original hardware. I am using an actual breadbox C64 with a 1541 disk drive and disks that were brand new in the packages(DD Fujifilm). They formatted just fine too. Any advice you can give would be appreciated. Thanks guys!

I have some rudimentary programs I wrote (hey, I was 9 at the time ) as well as some other books on TI Basic and would like to start dabbling again. I haven't picked up a program recorder yet, nor have I made the investment in a PEB (yet!). Should I look to just start out with a program recorder? Since I've seen different hardware development over time, perhaps that's just "old fashioned" and there's a better way. (e.g. storage peripheral that uses SD cards?) I didn't see any though, just the units for the PEB I think. Any advice is appreciated, thanks.

I am looking for a simple example of: a) A MADS based program. b) ... which will use an AtariMax 1mb or 8mb cartridge when written to it. c) ... which then can switch in any bank from the cartridge. I'd also like some clarification of: - If a 2 megabit file is added to the 8mb cartridge, when you're addressing bank 0, is that bank 0 of the file that is being addressed or bank 0 of the cartridge as a whole? I guess the latter.

I am by nature a tinkerer with a wide range of interests, and every year I come up with a variety of projects, whether in hardware or software, most of which nowadays end up on YouTube. Unfortunately, I have rarely documented my thought processes with each project, nor any mistakes I made along the way to completion. So I figured going forward I would start keeping such a blog, if nothing else for my own records, although I suspect that some readers might be interested in some aspects of it. So here it goes...

Admittedly I don't know very much about Atari or programming in general...but here's the story: My girlfriend is a big fan of the Crystal Castles arcade game because her dad used to play it all the time in their basement. After he passed away about 10 years ago, they had to sell the machine, but I know this game holds a lot of meaning for her because it brings back fond memories. I'm hoping to propose in the next couple of months and was trying to think of creative ways to do it...which leads me here: Is it at all possible to take the Atari 2600 cartridge version of Crystal Castles and program a message into it? For example, after she completed Level 3, it would trigger a message scrolling across the screen. I certainly don't have the ability to make this happen, so I was hoping someone here might have a suggestion (or just tell me that this is a pipe dream). I'm even willing to pay a programmer for their services if this is a possibility. Please let me know and we can discuss further. Thanks!

Using the SIO2PC, is it possible to save BASIC programs from my Atari 800XL to PC? I can send ATR images from PC to Atari, but can it go other way round? Do I need DOS or something? Thanks, sorry if this seems like a silly question

Intellivision IntyBASIC Programming Contest 2015 Welcome to the first IntyBASIC game programming contest held on AtariAge (thanks Albert!). The contest is open to all IntyBASIC programmers and is sponsored by GroovyBee, nonner242, nanochess, CollectorVision and Albert. Further prizes are being offered by revolutionika and cmart604, and awards will be given to entries that place 1st, 2nd and 3rd respectively. Drop us a PM if you'd also like to help out with some more prizes! THE RULES So you can get started, the basic rules are laid out below: The competition starts today (Wednesday 1st of July 2015) and the deadline for submissions is 00:00 GMT on the 1st of January 2016 (midnight on the 31st of December) - this gives you around 6 months of development time. There will be no competition unless a minimum of six entries are submitted by the deadline. Your game(s) must be developed in IntyBASIC and use the default prologue/epilogue files. The only assembly language statement allowed within your game is the ORG statement so that you can develop a larger game. However, bank switching is not permitted. All submitted games must meet the entry criteria to be valid. The games submitted do not necessarily need to be new, but must be your own work, not sold commercially or released in cartridge format previously. NTSC must be supported, with additional PAL support optional (but encouraged). The maximum number of single entries from a person or group is set at three. If more entries are made, the applicant has the opportunity to replace a previous entry with a new one. The 1st prize winning game may be published by CollectorVision (should it's developer enter into an agreement to do so). This matter will be discussed privately with the parties concerned and if an agreement is reached a public announcement will be made later. There will be a panel of judges (announced in full over the coming weeks), and entries will be scored on a points basis across several criteria. The decision of the panel is final. All game ROMs below 1st prize (2nd, 3rd etc.) will be published after judging has been completed. However, if the 1st prize game is to be published by CollectorVision its ROM will be distributed after game sales have completed. All entries must be submitted via email to contest@intybasic.com by the closing date. The judges will declare the results of the contest by 12:00 GMT on the 31st of January 2016. GAME ENTRY Each entry into the contest must consist of the following items to be valid :- Game image in *.rom or *.bin+*.cfg. Brief instructions on how to play the game. IntyBASIC source code (and any data files). Instructions on how to build the IntyBASIC source code (this must also include IntyBASIC compiler version number). As part of the validation process, each entry's source code will be built using its instructions and the final binary produced must match the submitted binary image 100%. Any entry that fails this criteria will not be judged. It is not necessary for any contestant to publish the source code to their entry. However, if they wish to do so before the contest closes, they will be awarded an extra 5 points. Competition contestants are free to discuss their game's progress, provide source code and WIP ROMs and to also help other contestants should they wish to do so. Your entry must be submitted via email to contest@intybasic.com by the competition's closing date. THE JUDGING PANEL The panel of judges is as follows :- Albert Yarusso (Albert) Mark Ball (GroovyBee) nonner242 Oscar Toledo G. (nanochess) J-F (retroillucid) Judges are not permitted to enter the contest themselves. However, they are permitted to answer technical questions and provide assistance to applicants publicly when required. DZ-Jay will validate the entries. His role is to ensure that only the permitted assembly language is used in the game and that an exact game binary can be produced. SCORING SYSTEM The criteria that each game will be evaluated on are: Originality (1 ro 10) - Is the game based on a new idea or a twist on an established design? Concept (1 to 10) - Quality of game design. Execution (1 to 10) - Execution of design, taking into account controls, NTSC/PAL compatibility. Graphics (1 to 10) - Quality of graphics and animation. Sound (1 to 10) - Quality of music and sound effects. Presentation (1 to 10) - Overall presentation. Game play (1 to 10) - A measure of how enjoyable the game is to play. Lasting Appeal (1 to 10) - Replay value, addictiveness. Source code (5) - These points are awarded to any coder that publishes his/her game's source code publicly. When the panel has scored each game accordingly, the totals for each criteria will be added together for each game to give it a final score. PRIZES First prize: Game on Bee3 cartridge (1 copy only). End label and a box designed by nonner242 (1 copy only). Hive Multi-cart Deluxe Edition. 2 blank Bee3s. 1 Bee3 programmer adapter (donated by DZ-Jay). Optional: CIB publication with CollectorVision. CIB Copter Command Deluxe (donated by revolutionika). One console from CIB Intellivision I, CIB Intellivision II or CIB Sears (donated by cmart604). 30 pack of CIB common games (donated by cmart604). Choice of D1K or D2K (donated by cmart604). Second prize: Game on Bee3 cartridge (1 copy only). End label by nonner242 (1 copy only). Hive Multi-cart Standard Edition. CIB Copter Command (donated by revolutionika). One console from the remaining choice of CIB Intellivision I, CIB Intellivision II or CIB Sears after the 1st prize winner has picked theirs (donated by cmart604). 20 pack of CIB common games (donated by cmart604). Third prize: Game on Bee3 cartridge (1 copy only). A simple end label by nonner242 (1 copy only). CIB Space Raid (donated by nanochess). CIB Copter Command (donated by revolutionika). The remaining CIB Intellivision/Sears console after 1st and 2nd prize winners have picked theirs (donated by cmart604). 10 pack of CIB common games (donated by cmart604). Note: These rules are based on RGCD's Programming Contest 2014 rules and are used with permission. DEVELOPMENT The development tools and emulators needed to create and play your games can be found here.

Hello AtariAge! I am making my first game, and all I really need to add is sound effects, and possibly music. I understand how setting AUDV0/1, AUDC0/1, and AUDF0/1 change the pitch, but I am stuck on even how to begin to write music or sound effects for it. Is there some sort of engine I can use in my game to play an arbitrary song or sound? The one engine I can find (right here) loops the music (which isn't what I want, except for perhaps a music track during the game), and doesn't work when I put it in my code.

Hey folks, I'm trying to self-teach how to program the Commodore 64, and a lot of folks have already recommended to me a bunch of books. But I thought I would also start a thread to post more specific questions as they arise, and tap into the community of knowledge here. My first question is pretty basic (har har). I just wanted confirmation that the DEF FN command (in Commodore 64 BASIC) can only create single-variate functions of a floating point variable. I find this very limiting and would very much like to know if there's any way to define multivariate functions, and also on arrays or strings or integers etc. I don't think there is, and I have tried stuff but nothing works, and the books I have read so far are not 100% clear on explaining this function. Thanks in advance for any help and advice. I hope that other people interested in C64 programming can join in and we can build up this forum.

Hey Everyone. First off, I do love forums. I don't want to detract from Atari Age in any way whatsoever with this. Forums are awesome for long discussions, seeking opinons, and getting help from others when trying to solve problems. The only problem is that it can be really hard to find the solution to an issue when you have to dig through pages of posts, filtering out in your head all the other stuff like huge signatures and the like. Chances are good that everyone here has used a StackExchange site at some point, and if you have you'll know how effective they are. I've created a proposal for a Retro Computing site—I really think it'd be awesome to have a cross-community resource that covers all aspects of the computers we love. Any backing for the proposal here would be hugely appreciated! http://area51.stackexchange.com/proposals/94441/retro-computing

Hey all. I have a long string of numbers in a text file. I am looking for a program or technique to convert all of the values to hex equivalents in Windows, changing them in the text file. Before I go off in the weeds and code something, I thought I would ask what the gurus are using. The values are used in IntyBASIC. It's kind of academic since Decimal values work, but it is inconsistent where the rest of my programs use Hex. Thanks. 604 , 570 , 570 , 570 , 570 , 570 , 538 , 538 , 508 , 339 , 339 , 339 , 339 , 320 , 339 , 339 , 339 , 320 , 320 , 320 , 452 , 508 , 538 , 570 , 320 , 359 , 538 , 427 , 452 , 427 , 427 , 403 , 403 , 403 , 718 , 718 , 761 , 761 , 339 , 678 , 678 , 761 , 427 , 452 , 508 , 640 , 640 , 761 , 761 , 761 , 678 , 678 , 678 , 678 , 678 , 604 , 604 , 604 , 854 , 854 , 905 , 905 , 678 , 905 , 854 , 761 , 854 , 807 , 718 , 678 , 678 , 678 , 678 , 678 , 678 , 678 , 718 , 718 , 718 , 761 , 761 , 807 , 807 , 807 , 807 , 807 , 807 , 807 , 807 , 807 , 718 , 678 , 678 , 678 , 678 , 678 , 640 , 640 , 640 , 640 , 640 , 640 , 640 , 640 , 320 , 320 , 320 , 427 , 427 , 427 , 403 , 403 , 380 , 302 , 302 , 285 , 285 , 285 , 285 , 285

Another work in progress. Mode 0 , 0,0,0,0 Wait Print At 0 Color 7 , "Greensleeves (1)" Print At 80 Color 4 , "Press top side" Print At 100 Color 4 , "button to" Print At 120 Color 4 , "restart music." Print At 160 Color 1 , "Press bottom side " Print At 180 Color 1 , "button to exit." Wait Play Full Wait Play mymusic Wait Goto PlayLoop PlayLoop: Wait If Cont.B0 Then Wait : Play Off : Wait : Play mymusic If Cont.B1 Then Goto ExitThis If Cont.B2 Then Goto ExitThis Wait Goto PlayLoop ExitThis: Wait Print At 235 Color (Rand and 7) , "Bye." For spinWait = 0 to 5 Wait Next Play Off mymusic: Data 5 Music - , - Music - , - Music A4Y , - Music - , - Music A4Y , - Music - , - Music A4 , - Music S , A4Y Music C5 , S Music S , C5 Music S , S Music S , S Music D5 , S Music S , D5 Music E5 , S Music S , E5 Music E5 , S Music F5 , E5 Music E5 , F5 Music S , E5 Music D5 , S Music S , D5 Music S , S Music S , S Music B4 , S Music S , B4 Music G4 , S Music S , G4 Music G4 , S Music A4 , G4 Music B4 , A4 Music S , B4 Music C5 , S Music S , C5 Music S , S Music S , S Music A4 , S Music S , A4 Music A4 , S Music S , A4 Music A4 , S Music G4 , A4 Music A4 , G4 Music S , A4 Music B4 , S Music S , B4 Music S , S Music S , S Music G4 , S Music S , G4 Music E4 , S Music S , E4 Music S , S Music S , S Music A4 , S Music S , A4 Music C5 , S Music S , C5 Music S , S Music S , S Music D5 , S Music S , D5 Music E5 , S Music S , E5 Music E5 , S Music F5 , E5 Music E5 , F5 Music S , E5 Music D5 , S Music S , D5 Music S , S Music S , S Music B4 , S Music S , B4 Music G4 , S Music S , G4 Music G4 , S Music A4 , G4 Music B4 , A4 Music S , B4 Music C5 , S Music S , C5 Music S , S Music S , S Music B4 , S Music A4 , B4 Music S , A4 Music G4# , S Music S , G4# Music G4# , S Music F4# , G4# Music G4# , F4# Music S , G4# Music A4 , S Music S , A4 Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music A4 , S Music S , A4 Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music A3 , S Music S , A3 Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music A2 , S Music S , A2 Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music S , S Music Stop

Ok, it's not much, but I am trying to make an IntyBasic game. Sort of a Stunt Cycle game. Thanks to all for the great tips, posts of code and suggestions and the tools. I have learned a lot looking at all the examples and have stolen code from just about everyone. At this point I have a lot of things that I haven't figured out but I will start with the two or three that are really killing me. What is the best way to know that I have left the screen and need to change direction? Starting from left to right I change when the sprite X position is more than 170. Not sure that's good but it seems to work. Going right to left I am checking for the X position to be less than 5. This works if I am going pretty slow (Right arrow key pressed) but if I am going faster (down arrow) it doesn't work and I continue moving right to left. Collisions. I haven't messed with it a lot. How do I check if sprite 0 has had a collision with a background pixel? The manual says “bit 8 means collision against background pixel (pixel set)” What does “(pixel set) mean?” I have “if level = 3 and COL0=HIT_BACKGROUND then gosub jump” If any one has examples or advice on either or both of these I would appreciate it and that alone will probably keep me busy for a while. But I think I also would like to know more about Fractional Movement. It seems to make sense to me conceptually but as I try to accomplish using 16 bit variables for calculating the move but then using just the lower 8 bits for the actual movement (if that is even close to right). If there is a short example I would appreciate it. what I have so Far IntyKnInty.bas

Recently, Willy's artist created a nice box design for Paddle Party, which included a cool "Paddle Party" logo. I wanted to try and put the same logo on the title screen, in spite of my general lack of artistic ability. I decided to try and do it using a free Windows program called "tile studio". First, I took the box image: and cut out the logo part. (Using windows paint, which is not the greatest graphics program on earth, but it is free…) The cut out logo was 458 pixels wide. The Intellivision screen is only 160 pixels wide (20 characters * 8 pixels per character). I decided that 14 characters * 8 = 112 pixels wide would be a good size for the logo. This would leave me 24 pixels of border on each side. 24 pixels border + 112 pixels logo + 24 pixels border = 160 pixels So, how much do I scale the logo to get it down to 112? 112/458 = 0.24454148, which is not a very round number. After some figuring I found that 112/466 = 0.24 exactly. So, I expanded the logo bitmap in paint to make it 466 pixels wide. Then, I selected the whole image, and scaled it down to 24 percent. Here is the result. It is blocky, but that's Intellivision for you. Then I saved it as a monochrome bmp file. This reduced everything to only 2 colors. This made it even uglier: After some hand tweaking of the bits, I ended up with this version. Then, I started up tile studio. I selected the "import tile option", and chose my file to import from. I specified the tile size as 8 by 8 (the default is 32 by 32). After importing, 42 tiles had been created. (14 * 3). The I selected "create new map". I created a map of size 14 by 3. Then I painted my characters onto the map. This was pretty easy because the characters were in sequence. Luckily, the dividing line of the characters fell between "paddle" and "party", so I would be able to make them different colors on the Intellivision... Here is what the map looked like in tile studio: Once the map was created, I hit the menu option to remove duplicates in the tiles. This reduced the number of tiles to 31 (including a blank, which I didn't need because the Intellivision character set has a blank built in.) Under "code generation" I selected the GBA option (if I did this a lot, I guess I would want to make my own option). I told it to generate code, and it generated a data file (containing the character patterns) and a map file (containing the numbers of the characters needed to display the logo). After massaging these files and integrating them into my program, I ended up with this: It looked pretty good, but it was kind of flat. I wanted the character outlines (like in the original), or a the least some kind of shadow behind the characters. But the Intellivision display only allows 2 colors per character. So, the only resource left is the motion objects. There are 8 motion objects. If I put them together, side by side, they would be 8 * 8 = 64 pixels wide. But the logo is 112 bits wide! Hmmm. But, the motion objects have a double wide mode, where each bit is 2 pixels wide. If I put the objects in that mode, then 7 objects would be 7 * 8 * 2 = 112 pixels wide, but horizontally blocky. What would that look like? Only way to find out is to try it. So I took my 112 pixel wide logo image and reduced it in half vertically. Here it is (after some pixel tweaks:) Here it is stretched out vertically (and with different colors): It looked pretty bad, but maybe it would work as a shadow. So I ran this image through tile studio, and created new character data and maps for it. Then I set up the motion objects to use this data in the program. I set the priority bit to make the objects appear behind the characters. I offset the image 1 pixel down and 1 pixel to the right of the original image. This was the result: I wasn't to happy with it. It didn't look clean. It looked like the idea wasn't going to work. But just for fun, I tried an offset of 2 pixels down and 2 pixels to the right. This worked much better: If you look closely, you can see the flaws in the shadow, but at a glance I think it looks pretty good. I also tried this offset: Then we experimented with a variety of colors: We finally decided on this version…. And now I have one motion object left for special effects.... I was pretty happy with Tile Studio. What do you think? Questions? Comments? Catsfolly

I would like to give folks a try at my new game before the finishing touches are added. If you like my game please consider buying it when it comes out!! This was programmed from scratch, by me!! Here are the instructions.. Joystick = moves the character Hold action = Jump (in Jump let go of action to attack) Left + action = attack Right + action = attack Down + action = special attack Hold up + action = Use magic (uses power) In easy hold action on the Game Over screen to continue In Hard hold action to begin at an earlier point in the game (usually), or choose a different character On the title screen hold a direction to listen to one of the music tracks, five in total! (I made all the music, too) This game is one of my most loved creations and I hope you all enjoy it and consider purchasing it when/if it comes out at AtariAge Please don't take my code or modify it in any way!! I present.. Titan Axe Beta TitanAxeBeta.bin

Like the topic says.... is there a way to use PLOT and DRAWTO to quickly drawn lines with the line drawing characters? Here's what I understand so far after some research: You can use PLOT and DRAWTO in a text mode. The COLOR statement is used to determine what character is output. The COLOR statement is ranged 0-255 (8 bits), but the 1st two bits are said to control color of character, and the last 6 to identify which character. Six bits only allows for 64 possible characters (out of 128 + another 128 inverse). When I wanted to plot an ATASCII 17 (upper left corner drawing character), I instead neded up with a Q, ATASCII 81 (in the next set of 64 chars). So, how do I plot box corner characters and "draw" box side characters between them? Also I'm pondering... normally the COLOR statement determined which color register will be used for subsequent plots. There are 5 color registers (0 - 4). When doing graphics, the least sigificant bits given to the COLOR statement determine which register, Why is it that the same COLOR statement, when using for text mode, has the two most significant bits deal with color? Also, since it is just two bits, it could only refer to teh 1st four color registers and not the 5th one. That's okay I suppose, but do they even refer to color registers at all? Any of you gurus able to help clear this up?