Atari 2600 BASIC compiler is here!

[vdub_bobby]

Here's a rewritten kernel that has both players, both missiles, the ball, and the asymmetrical playfield (PF1 & PF2 only); everything at 2-line resolution:

KernelLoopa           ;     54
  nop
  nop                 ;+4   58
KernelLoopb           ;     58

  cpy Player0Top      ;+3   61
  beq SwitchDraw0     ;+2   63
  bpl SkipDraw0       ;+2   65
  lda (player0ptr),Y  ;+5   70
  sta.w GRP0          ;+4   74   outside playfield area


  cpy Player1Top      ;+3    1
  beq SwitchDraw1     ;+2    3
  bpl SkipDraw1       ;+2    5
  lda (player1ptr),Y  ;+5   10
  sta GRP1            ;+3   13   outside playfield area


  lda playfield,X
  sta PF1             ;+7   20

  lda playfield+1,X
  sta PF2             ;+7   27

  lda BallHeight      ;+3   30
  dcp BallTemp        ;+5   35
  sbc BallAdjuster    ;+3   38
  sta ENABL           ;+3   41   <-- VDEL the ball - won't show up until next line!

  lda playfield+2,X
  sta PF2             ;+7   48   this timing cannot be changed
  lda playfield+3,X
  sta PF1             ;+7   55

  nop                 ;+2   57   for timing

  lda M0Height        ;+3   60
  dcp M0Temp          ;+5   65
  sbc M0Adjuster      ;+3   68
  sta ENAM0           ;+3   71   outside playfield area

  lda M1Height        ;+3   74
  dcp M1Temp          ;+5    3
  sbc M1Adjuster      ;+3    6
  sta ENAM1           ;+3    9   outside playfield area

  lda playfield,X
  sta PF1             ;+7   16
  lda playfield+1,X
  sta PF2             ;+7   23


  lda NewLineChange,X
  sta LineChange      ;+7   30

  SLEEP 4             ;+4   34

  dey                 ;+2   36

  lda playfield+3,X
  sta PF1             ;+7   41

  lda playfield+2,X
  sta PF2             ;+7   48   this timing cannot be changed

  cpy LineChange      ;+3   51
  bne KernelLoopa     ;+2   53
  dex                 ;+2   55
  bne KernelLoopb     ;+3   58


;--------------------
  
NewLineChange
  .byte 0,9,18,27,36,45,54,63,72,81,90,99,etc.

A few notes:

This is untested - so it may not work. I think it should, though.

 

It is more RAM-heavy than the current kernel. It uses 4 bytes of RAM for each player (two for SwitchDraw and 2 for a graphic pointer) and 3 bytes of RAM for each missile/ball. It also uses 1 more byte (the variable LineChange) to handle the loop maintenance. So a total of 18 bytes, counting pointers and not counting the RAM used for the playfield.

 

The players are drawn on the same line, so VDELing them will not have much in the way of a good effect. They are lined up with the playfield, as is the ball. The missiles, on the other hand, are off by one scanline from the playfield and player lines. If you know what I mean. Also, you cannot draw the ball on the first 2-lines of this kernel unless you write to ENABL before the kernel begins.

 

There are a few free cycles left in there, though they are a bit scattered. You could pretty easily get six together, though (move the 'dey' somewhere else), for example.

 

Anyway, I hope this is helpful; if not, well, it was fun writing it!

[kisrael]

Tonight I will try to update the page.

 

It might be helpful if everyone generating content (esp Batari and Potatohead) could email me updates, just incase I'm lagging in keeping up with the forums, and to make sure I have the very latest.

 

Batari, I just gotta say I'm struck by the cleverness of how you handle the playfield. It's one of those things that wouldn't have occured to me, because my brain was kind of stuck on playfields being hardcoded in ROM, and I thought of memory-mapped playfields as being undoable given the RAM limitations. But your pragmatic, oldschool-BASIC-influenced approach has really busted open the possibilities. (In fact, some of these games are gonna look more Atari-ish than Atari games, because they fit the stereotype of GIANT PIXELS that so many people have in their minds.)

 

And of course, overall, you really shut people up who said it couldn't be done, and I think produced a thougtful silence or "hmmmmm" for people who thought maybe it shouldn't be done--and I mighta been one of those people, at least sometimes. So Kudos to you, and I'll try to be a better supporter as time permits.

[Thomas Jentzsch]

Why do you need LineChange? Why not directly comparing Y with NewLineChange?

  tya
 cmp NewLineChange,x

[potatohead]

Know what would be awesome?! Once you get this program more polished?!

 

Let's have some source code for a complete game and get one of the classic magazines to put it in their magazine. Sort of like the old Compute! magazines where you typed in C64 games. The article would list what programs you need, where to get them, and have a full source code with documentation.

 

That's not a bad idea! I'm sure a lot of us miss those.

 

That Ooze game has some errors too.. one would be when the ooze gets to the bottom most spot it can goto you cannot shoot it away, yet you can shoot the parts behind it. Pretty cool game. Spice it up a little with some sort of increased difficulty.. or maybe the ooze moving back and fourth or something. Maybe different levels. Slap on an intro screen and slap it into a cartridge and I'll buy one heh.

 

Aw man, now you have my hopes up

 

Well now that I know I've only used 1/3 of the code space avaliable to me, good things can happen. The tough part is getting the order and timing of things right.

 

The problem, you wrote about, happens when a bullet collides with the ooze and the ooze grows at the same time. A left over pixel gets drawn and that stops the bullet from hitting the real ooze pixels higher up on the screen. If you let the ooze come all the way down, you can then knock it back a high percentage of the time. --Things work so *fast*. I'm quickly remembering just why I spent so much time hacking on the old A800.

 

Still working on that one. That's part of why the ooze does not get to the bottom right now.

 

One variation I want to try is the paddle. We are not there yet (I think.) but probably will be. At that point, the ooze can move really fast and in wicked ways, really stressing the player control of the paddle.

 

More ooze is needed too. 5 rows is not enough. That one I know I can fix.

 

Addressing the "it could not be done comments above". Yeah, I was one of those naysayers when I saw this announed on /. My first thought was not enough code space, too few options to make games, slow, buggy, etc...

 

I hopped on here thinking the worst, but decided to give it a try. At first I said, "ok, this is a cool tech demo". But then after futzing around with it for a bit, the real power began to shine. Interestingly, everything I tried worked! The only real downside are the graphical limitations, but those can be powered through with creativitiy, IMHO. I am being honest when I say the issues really are my own. Programming with this is simple, but subtle --just like the 2600, only nicely abstracted.

 

The lack of dual comparisons and case, on goto statements makes some things tough, on the other hand, the compiled code is frugal enough to keep things possible. All in all, it's a lot of fun.

 

Re: updates, where do I send them to? (Use the forum e-mail address?)

Edited July 12, 2005 by potatohead

[Cybergoth]

Hi there!

 

And of course, overall, you really shut people up who said it couldn't be done

 

I don't think anyone ever said that it's impossible. In fact the idea existed for years, like for example http://www.biglist.com/lists/stella/archiv...1/msg00266.html

 

Just no one ever sat down and did it - and most said it'd be very limited, being like a "Combat Basic" best case - which, no matter how you put it, is still simply the truth.

 

Greetings,

Manuel

[vdub_bobby]

Why do you need LineChange? Why not directly comparing Y with NewLineChange?

  tya
 cmp NewLineChange,x

890356[/snapback]

Because:

   tya
  cmp NewLineChange,X

takes 6 cycles and

   cpy LineChange

takes 3.

 

More seriously, it isn't hard to fit everything in 152 cycles. There is plenty of time left over. The problem is that I wanted both players written on the first line, and between the last PF2 write on the 2nd line (ending at cycle 48) and when the PF writes begin again on the first line (cycle 13) I only have 41 cycles. I need 15 for each player, so that only leaves me 11 to update X, if needed, and loop back.

This:

   tya
  cmp NewLineChange,X
  bne KernelLoopa
  dex
  bne KernelLoopb

takes 13 cycles at the longest - two cycles too many. But if I use:

   cpy LineChange
  bne KernelLoopa
  dex
  bne KernelLoopb

that only takes 10 cycles.

 

There is probably a better way to do this but this is my second iteration - I don't have time right now for another rewrite - I haven't even had time to test the ones I've written so far!

 

Maybe tonight I'll try another rewrite. Or somebody else...

[Thomas Jentzsch]

There is probably a better way to do this but this is my second iteration - I don't have time right now for another rewrite - I haven't even had time to test the ones I've written so far! 

VDEL one player! Then you can update that one whereever you want to.

 

BTW:

When you update X every 8th line then you can do:

  tya
 and #$07

Edited July 12, 2005 by Thomas Jentzsch

[potatohead]

Just bumped into something this morning.

 

Does the compiler allow for more than one drawscreen command?

 

Worked up a quickie title screen and it compiles but assembler has unresolved symbols...

 

Here is a code chunk that illustrates the problem. If I need to, I'll post the whole thing.

 

8 rem jump to title screen!!  Start game with goto 10
9 goto 4000

aa (Normal game stuff here.)

xx drawscreen

bb (more normal game stuff)

yy goto aa

4000 pfhline 7 1 5 on : pfvline 10 1 5 on
4030 pfvline 15 6 5 on : pfhline 15 8 5 on : pfvline 19 8 3 on
4040 pfvline 23 0 5 on : pfhline 23 0 5 on : pfhline 23 3 3 on : pfhline 23 4 5 on
4040 COLUPF = 23
(I did try putting various things here, player defs, etc...)
4050 drawscreen
6000 if INPT4 < 15 then goto 10
6010 goto 4040

 

Here is the DASM output:

 

[dougd@feona atari_basic]$ ./run
2600 Basic compilation complete.

DASM V2.20.09, Macro Assembler (C)1988-2003
Warning: Unable to open 'vcs.h'
Warning: Unable to open 'macro.h'
Warning: Unable to open '2600basic.h'
test.asm (1435): error: Label mismatch...
--> 0.4040 f70c
Unrecoverable error(s) in pass, aborting assembly!
Complete.

 

Re: combat basic. --I think this is fair. However the bitmapped playfield really allows for a lot of game play possibilities. Won't look so nice graphically, but very good game play is possible. As this matures, different kernels might help this, but will each be limited in their own way.

 

I think a 7800 kernel would rock. End result would be something between the two, with a lot of flexibility for the programmer --and speed!

 

Think 8 bit atari basic, with a few more sprites and a multi-colored playfield. Lots of great stuff could be done in that environment. --Just to be clear, that's a forward looking statement. What we have now is not even close to being done yet and I don't want to diminish Batari's hard work.

 

However, I must point out this thing is easy to grok. It's a lot harder to actually get things timed right and in the right order, but that's the fun part, IMHO. Anyway, where I'm headed is the older 8-bit basics were easy to access, which made the learning fun.

 

The downside then was the lack of speed. That meant slowly getting into assembly language code to shore up the basic. (Still have my MAC/65 cart!) Anyway, this thing has lots of speed but will eventually need the assembler to apply spit 'n polish, depending on the game and the authors standards and expectations. The point being gameplay is possible without having to deal with a lot of complex details, like API's, assembler, etc...

 

If, for example the 7800 thing became a reality and emulators were created for the growing number of portable devices we are seeing these days, there might be a lot of interest for this kind of thing because it just does not exist today in a form that is accessable to nearly anyone interested in getting their computer do do something they want it to do. --Again, that's future stuff, but I wanted to clarify what I was thinking and why, beyond "ooh it would rock on platform x".

 

The actual learning potential is much higher than the old basics because the speed is there to make things happen. The language itself will probably remain fairly simple. Bataris approach to mapping functions to common assembly language constructs is a great choice in this regard.

 

Sorry to ramble, but I just know there is a point in all of that somewhere.

 

People, who may not be ace programmers (and I'm one of them), are often daunted by large API's and detail. This thing does not have that, leaving the real fun of programming right there in front, easy to access and learn from. --That's what interests me at this moment. I spend my days doing sysadmin and consulting. (MCAD systems Unix, win32). It's big nasty complicated stuff. Writing the code for this system is pure fun by comparison. All the complexity gone, leaving me a thin layer between an idea and the computer.

Edited July 12, 2005 by potatohead

[vdub_bobby]

There is probably a better way to do this but this is my second iteration - I don't have time right now for another rewrite - I haven't even had time to test the ones I've written so far! 

VDEL one player! Then you can update that one whereever you want to.

Yeah, I know. But that isn't quite as clean, because then if you want both players drawn on the very first line you have to write to the VDELed player before the kernel loop begins. Which isn't such a big deal, really, but it wasn't as clean. If I have time I'll rewrite again tonight.

BTW:

When you update X every 8th line then you can do:

  tya
 and #$07

890376[/snapback]

I wanted to keep this as generic as possible, for now, though that is certainly a good option for 8-line tall blocks.

[Thomas Jentzsch]

Which isn't such a big deal, really, but it isn't as clean. 

Good kernels are rarely "clean".

[vdub_bobby]

Which isn't such a big deal, really, but it isn't as clean. 

Good kernels are rarely "clean".

890423[/snapback]

 

I like to start clean, anyway. Then things don't work, I realize that I can't write to that TIA register then, I forgot that I need to save collision registers mid-kernel...they always end up dirty.

Edited July 12, 2005 by vdub_bobby

[+batari]

Does the compiler allow for more than one drawscreen command?

8 rem jump to title screen!!  Start game with goto 10

4040 pfvline 23 0 5 on : pfhline 23 0 5 on : pfhline 23 3 3 on : pfhline 23 4 5 on

4040 COLUPF = 23

[right][snapback]890377[/snapback][/right]

You can call drawscreen as often as you like. The problem is you have two line 4040's.

[+batari]

Which isn't such a big deal, really, but it isn't as clean. 

Good kernels are rarely "clean".

890423[/snapback]

 

I like to start clean, anyway. Then things don't work, I realize that I can't write to that TIA register then, I forgot that I need to save collision registers mid-kernel...they always end up dirty.

890444[/snapback]

Thanks Bob and Thomas for the suggestions with the kernel - I'm still not very good at writing them. I'll see if I can implement your suggestions in an upcoming release - maybe not the next one, but hopefully the next one after that.

[+batari]

Tonight I will try to update the page.

 

It might be helpful if everyone generating content (esp Batari and Potatohead) could email me updates, just incase I'm lagging in keeping up with the forums, and to make sure I have the very latest.

890352[/snapback]

I think for now, I'd like to see potatohead's latest game and attendo's IDE on the web page.

And of course, overall, you really shut people up who said it couldn't be done, and I think produced a thougtful silence or "hmmmmm" for people who thought maybe it shouldn't be done--and I mighta been one of those people, at least sometimes. So Kudos to you, and I'll try to be a better supporter as time permits.

890352[/snapback]

I was definitely one of the dissenters. But my main beef was with the idea of a game maker where you can make an entire game with just mouse clicks without actually having to write any code. I was also opposed to the idea of a simplified language at first but I thought about it and my issue was not with the language but with a compiler that would produce binaries directly. I think that such a thing would not be conducive to moving on to assembly.

 

Since Batari Basic produces assemblies, I think it's much more likely to encourage tinkering and eventually learning how to program assembly, which most seem to view as a good thing.

[potatohead]

Does the compiler allow for more than one drawscreen command?

8 rem jump to title screen!!  Start game with goto 10
4040 pfvline 23 0 5 on : pfhline 23 0 5 on : pfhline 23 3 3 on : pfhline 23 4 5 on
4040 COLUPF = 23
[right][snapback]890377[/snapback][/right]
[/quote]
You can call drawscreen as often as you like.  The problem is you have two line 4040's.
[right][snapback]890461[/snapback][/right]
[/quote]

Gotta hate that!   :x 

Anyway, found another thing others might want to know.  It appears we have a line length limit.  It looks like 80 chars, but I didn't count.  Here's the line in question:

[CODE]4040 pfvline 22 1 6 on : pfpixel 23 1 on : pfpixel 24 1 on : pfpixel 25 1 on : pfpixel 26 1 on : pfpixel 27 1 on 

 

Also, it seems the pfhline does not always draw the lines you ask for. The vline function seems to work just fine, but some horizontal lines simply do not appear, or are truncated. In my last code snippet (the one with the two 4040 lines), those few line commands are supposed to spell letters, but don't. Trying different line values, yields lines sometimes, other times not.

 

The pixel commands work great.

 

4000 pfhline 4 1 8 on : pfvline 6 1 5 on
4030 pfvline 12 6 5 on : pfhline 12 8 19 on : pfvline 19 6 5 on
4040 pfvline 22 1 4 on : pfhline 23 1 8 on : pfhline 23 3 4 on : pfhline 23 5 8 on

 

Edit: forgot the actual code.

 

The drawscreen stuff works just fine too, making different game levels and title screens fairly easy to get done. ---and that's where I ran into the line problem...

 

Looking forward to next release and command reference. BTW, if you want to offload that, I'm happy to help in that area. I've got tonight, then need to go radio silent for a few days. (damn work.) Let me know.

 

Maybe it's my emulator?

 

Can somebody try this binary on another platform / emulator to check? (I'm linux + stella) If things are working as they should, the horizontal lines on the "e" should be longer than they appear in the attached screenie.

 

ooze_title_bug.zip

Edited July 12, 2005 by potatohead

[Dan Iacovelli]

came up the same way for me on pcaewin

[+batari]

Anyway, found another thing others might want to know.  It appears we have a line length limit.  It looks like 80 chars, but I didn't count.  Here's the line in question:

 

4040 pfvline 22 1 6 on : pfpixel 23 1 on : pfpixel 24 1 on : pfpixel 25 1 on : pfpixel 26 1 on : pfpixel 27 1 on 

Yes, there is a line limit, unfortunately, 80 chars sounds about right. It's a relic of an early version I wrote that didn't allow colons - I thought 80 chars would be plenty in this case, but forgot to change it when I added support for colons. I'm changing it to 500 so this won't likely come up again.

Also, it seems the pfhline does not always draw the lines you ask for.  The vline function seems to work just fine, but some horizontal lines simply do not appear, or are truncated.  In my last code snippet (the one with the two 4040 lines), those few line commands are supposed to spell letters, but don't.  Trying different line values, yields lines sometimes, other times not. 

possibly a bug ... I'll look into it.

BTW, if you want to offload that, I'm happy to help in that area.  I've got tonight, then need to go radio silent for a few days.  (damn work.)  Let me know.

890495[/snapback]

If you want to start on something, that would be great - I'm doing coding today and won't have time to start writing docs until tomorrow or maybe the next day. I think a good template (one I liked anyway) is the one for MS-DOS Qbasic. TO get an idea of what the QBasic help screen is line, go here and get qbasic.exe and qbasic.hlp. They will run under DOSBox so you can use them in Linux.

 

Basically (no pun) what I'd like to see is something like the command reference in Qbasic except have it in a .html file that could be included in the package (and put up on Kirk's webpage too) so people can see all the commands at a glance, and click on each one to see the syntax, usage, limits, and sample code containing the command. I always thought that this feature in Qbasic was pretty nifty.

 

Don't worry about making html just yet - for now we'll just make a big .rtf file and convert it later.

[retrocon]

Potatohead, could you post the ooze game as a bin?

 

I'd like to try it, but I don't want to mess with the basic stuff.

[kisrael]

All:

anything sent to @ alienbill.com should get to me, no problem.

 

Feel free to use Batari in the subject line...

 

Ugh, can't promise tonight, but will swear by tomorrow...

[potatohead]

Potatohead, could you post the ooze game as a bin?

 

I'd like to try it, but I don't want to mess with the basic stuff.

890554[/snapback]

 

 

Goto post #135. That one is the most playable one so far.

[retrocon]

Potatohead, could you post the ooze game as a bin?

 

I'd like to try it, but I don't want to mess with the basic stuff.

890554[/snapback]

 

 

Goto post #135. That one is the most playable one so far.

890570[/snapback]

 

Thanks, fun game. Shows a lot of promise. Also shows a lot of promise for this basic. I do hope this batari basic is used as a means to gain expertise into advanced 2600 programming, rather than an end to itself. If it angers the 2600 gods they may move on to something more challenging like cobol or channel f or something.

Edited July 13, 2005 by retrocon

[potatohead]

Thanks, fun game. Shows a lot of promise. Also shows a lot of promise for this basic. I do hope this batari basic is used as a means to gain expertise into advanced 2600 programming, rather than an end to itself.  If it angers the 2600 gods they may move on to something more challenging like cobol or channel f or something.

890636[/snapback]

 

Glad you liked it! The kids played it for a while this morning. They don't like the gaps between the ooze. I thought about moving it back and forth, but that might end up too coarse. (Have not really toyed with the scrolling too much yet.) I'm working on widening the falling ooze to take more of the screen and trying to nail the pesky left over pixel bug that ruins the experience right now. Widening things up, will increase the challenge.

 

Kicking around an accuracy factor too in order to make the gaps an integral part of the game. Miss the ooze and your score goes down. How to finish the game is still an open issue as well. letting the ooze come all the way down might work, but that might make for a lot of quick games. Ideas on these things welcome!

 

(Have to let the ooze come all the way down to the pixel before it can be eliminated, BTW.)

 

The promise is what I was getting at a few posts back. Graphically, the hardcore 2600 developers are going to have the advantage, but as far as I can see, gameplay is dead even. That's the part that attracts me. Long ago, on the 8-bitters, gameplay was very difficult to get to the immersive hand-eye level because the speed just was not there.

 

This little project has that, and that's just cool, IMHO.

 

Honestly, the 7800 is there waiting and has plenty of the tricky technical challenges that makes the 2600 great.

 

(Shaking in horror at the idea of doing anything with a channel F. Astrocade, if anything

 

The only downside is the small number of them. Maybe someday, given some interest, we might see 7800 on a chip solutions like the 2600 today.

 

Either way, there is room for all, IMHO.

 

As for advanced programming, I think it's about as good as it gets really. At some point, the graphical limitations are going to become an incentive for assembly. There are three stages that I see. I'm at stage one. Getting a complete game done in the basic environment is possible and that's what I'm working on. (Not sure this one will be it though --maybe) Stage two will be 90 percent basic, with assembly helpers. Get the game running in basic, then use that assembly code as a kick start for the final spit and polish. (colors, sounds, etc...) Stage three will come with enough hacking, assembly should become obvious enough to warrant a full project, if the person is willing. At that stage, the basic is still handy for working out game logic, etc... With larger memory spaces, some cut 'n paste for tough to code and debug logic sequences ought to blend nicely with other graphical elements.

 

Take that for what it's worth. It's what I see happening. Truth is we will just have to wait and see.

[kisrael]

Ok, the Batari BASIC homepage has been updated:

 

* replaced working_game with ooze (at some point I'll probably stop including so much source inline)

* addeded 2600IDE and description

* added link to this forum

* added Potatohead's Batari User's Guide, plus an HTML port ofit

[potatohead]

Ok, the Batari BASIC homepage has been updated:

 

* replaced working_game with ooze (at some point I'll probably stop including so much source inline)

* addeded 2600IDE and description

* added link to this forum

* added Potatohead's Batari User's Guide, plus an HTML port ofit

890753[/snapback]

 

Doug "Potatohead" Dingus. Hehe, guess I asked for that! I've used potatohead all over the place because it's almost never taken. Not to worry, I think it's funny! Once 'Dingus' becomes a factor, the name mangling can easily get far worse !! Nice update. If people come wandering by, it looks a lot more like something realistic than it did at first. --thanks!

 

I just got up and am healing from a rather nasty dentist trip. I might work on docs tonight, might just program a little too. The latter is more likely at this stage as it will be my last effort for the week...

 

Was thinking about inline assembly and math. So far, the two most cumbersome things in this language, for me, are:

 

Inability to index variables, causing way too many cut 'n paste statements to be written.

 

Lack of multiple comparisons, also resulting in a lot of statements.

 

(Loops and gosub are next on the list, but those are being addressed, so they are off the table until the next release.)

 

So, I thought I might deviate from my goal a bit and try the assembler function to process multiple variables at one time, potentially using the tempx storage locations to pass values, or by just operating on the variables themselves, whichever.

 

The idea being the variables are very likely located sequentially in RAM. Batari has done everything else in a logical way, so without a trip into the source for this compiler (which I've avoided to see what the learning process really is like) it's a guess. Hard to imagine them being random, so they are either up in RAM or down in RAM from a.

 

My first effort was to do something simple, like mask off the upper nibble of a variable. (Thinking of packing two ooze stacks into one byte to get more overall ooze onto the screen.)

 

that looked like this and it worked!

 

100 asm
lda a
sta temp1; These are tempoary storage places good for one vblank only.  One loop...
and #$0f
sta a
end

 

Nice. It did exactly what I wanted. Which was to unset the upper nibble of the byte pointed to by the variable a.

 

The basic statements are:

 

100 temp1 = a
110 a = a & $0f

 

I'm liking this actually. The shared mnemonics make using bits of asm very, very easy compared to how I'm used to seeing this kind of thing. I happen to remember enough 6502 to know what to do, but a quick look through test.asm would reveal plenty to carry on either way.

 

So, next step to build a little loop and replace this:

 

1400 if a > 8 then a = 8
1410 if b > 8 then b = 8
1420 if c > 8 then c = 8
1430 if d > 8 then d = 8
1440 if e > 8 then e = 8

...with:

 

1390 asm
.loop
ldx #$00
lda a, x
cmp #$08
bmi .nextvar
beq .nextvar
lda #$08
sta a, x
nextvar
inx
cpx #$05
bne .loop
end

 

Assembly is a lot harder. 3 edits to this and I'm still not sure it's right. Is there one branch that will equal: 'if a > 8 then ...." (Wishing for 6809 branches & indexing...)

 

My goal being to begin to mix the assembly with the basic now so that when I really, really need it, it's going to be there. Still want to complete a solid game with the language only. I think this can be done, particularly on the next release. This one could get there, but it's going to go with some pain. So, maybe tinker a bit and generate material for the docs.

 

Well this failed. I can't seem to use lables with the inline assembly. Either I am not using them properly (is the dot required or not? --tried both.), or something else is getting in the way. Without these, one cannot do loops, so that's a bug, IMHO. (If I'm doing the right kinds of things, that is.)

 

Any thoughts?

 

Here is the DASM output:

 

[dougd@feona atari_basic]$ ./run
2600 Basic compilation complete.

DASM V2.20.09, Macro Assembler (C)1988-2003
Warning: Unable to open 'vcs.h'
Warning: Unable to open 'macro.h'
Warning: Unable to open '2600basic.h'
test.asm (1092): error: Unknown Mnemonic '.loop'.
test.asm (1106): error: Unknown Mnemonic 'nextvar'.
Unrecoverable error(s) in pass, aborting assembly!
Complete.

Edited July 13, 2005 by potatohead

[+batari]

Inability to index variables, causing way too many cut 'n paste statements to be written.

 

Lack of multiple comparisons, also resulting in a lot of statements.

I could implement some sort of indexing - maybe a good idea would be to use [brackets] like in C. so:

 

10 a[5]=20 would actually access f.

 

Also working on multiple comparisons.

 

Well this failed.  I can't seem to use lables with the inline assembly.  Either I am not using them properly (is the dot required or not?  --tried both.), or something else is getting in the way.  Without these, one cannot do loops, so that's a bug, IMHO.  (If I'm doing the right kinds of things, that is.)

890771[/snapback]

Yep, another bug. The solution is to require indenting of the opcodes instead of having the compiler indent them for you (since it will indent the labels too, thus making them not labels anymore...) Just fixed it.