Error codes? Where do I find these?

[Gorf]

I did not see much in the way of error codes in the batari manual(of course I may have

missed it or looked in the wrong spot.) but I came across this trying to compile a multisprite

version of gorf vertically

 

M:\Atari2600\bB>2600bas gorfv.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler (C)1988-2003
  bytes of ROM space left
--> cycle74_HMCLR f07b

M:\ATARI2~1\bB>

 

I guess Im stufing to many cycles in the loop?

Edited April 20, 2007 by Gorf

[Dan Iacovelli]

I did not see much in the way of error codes in the batari manual(of course I may have

missed it or looked in the wrong spot.) but I came across this trying to compile a multisprite

version of gorf vertically

 

M:\Atari2600\bB>2600bas gorfv.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler (C)1988-2003
  bytes of ROM space left
--> cycle74_HMCLR f07b

M:\ATARI2~1\bB>

 

I guess Im stufing to many cycles in the loop?

sometimes thats not error because the game still works(unless when you ran it it crashed)

[SeaGtGruff]

I did not see much in the way of error codes in the batari manual(of course I may have missed it or looked in the wrong spot.) but I came acroos this trying to comile something

 

M:\Atari2600\bB>2600bas gorfv.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler (C)1988-2003
  bytes of ROM space left
--> cycle74_HMCLR f07b

M:\ATARI2~1\bB>

 

I guess Im stufing to many cycles in the loop?

Chances are, that's not an error, but simply a warning message. If your program is the correct size (2K, 4K, 8K, 16K, or 32K, whichever size you specified), and if it runs okay, then that isn't an error.

 

DASM is a multi-pass assembler, and during the first pass it will assign addresses to all the program labels. But the batari Basic kernel and includes routines can contain a lot of compiler directives that tell DASM to use different sections of assembly code depending on things like which kernel options have been specified. And for other possible reasons as well, sometimes DASM can start out thinking that a particular label will correspond to a particular address-- but by the time DASM has made as many passes as it needs to in order to resolve all the label references and plug them into the code, it may turn out that some of the labels correspond to different addresses than originally expected.

 

So what you're seeing is a message telling you that the label "cycle74_HMCLR" turned out to have a different address than expected. The batari Basic compile batch actually suppresses all these types of messages, except for the first one encountered-- so if you were to modify the compile batch to remove that suppression, you'd see a *lot* more messages of this type.

 

Michael

[Gorf]

Is that a bug in batari or DASM or just bad coding on my part?

[Gorf]

Im really anal about such messages. I seem to get tham from time to time, even though like you

all said the code still works.

[SeaGtGruff]

Im really anal about such messages. I seem to get tham from time to time, even though like you

all said the code still works.

I don't think there's anything you can do about them. It isn't a bB bug-- if anything, I'd say it's an issue with DASM. And the funny thing is, you can compile the program and get the message, then add a little bit more code to your program and the message is gone, then add more code and it's back again, etc.

 

Michael

[+batari]

Im really anal about such messages. I seem to get tham from time to time, even though like you

all said the code still works.

I don't think there's anything you can do about them. It isn't a bB bug-- if anything, I'd say it's an issue with DASM. And the funny thing is, you can compile the program and get the message, then add a little bit more code to your program and the message is gone, then add more code and it's back again, etc.

 

Michael

For the next release of bB, I am including a customized version of DASM. Aside from other things, this version will automatically suppresses most of the bogus error messages and minor annoyances.

 

This was necessary because with some really large bB source files, DASM started to choke on them and not assemble at all. The problem was that DASM would sometimes abort when it thought that a branch was out of range. If DASM had just given it another pass, the branch would have resolved within range. I fixed this problem by making DASM try a few more passes before giving up on branches.

[Gorf]

For the next release of bB, I am including a customized version of DASM. Aside from other things,

 

 

As long as it still works and is not a problem I can live with it. I'd much rather see

you spend the time on something like defines.....I'd be right there helping with this

stuff if I were not such a novice on this machine. ...on that note, if you guys think

I may be able to help you with batari's improvements, by all means ask.

 

I dont know if it is possible or not with the 'dim' statement but if not, can you add

#defines so I can use defines for a bit in a variable?

 

like

 

#define GAMEOVER = a{x}

 

if GAMEOVER then goto gameover

 

Now that would be shuga sweet!

 

[+batari]

For the next release of bB, I am including a customized version of DASM. Aside from other things,

 

 

As long as it still works and is not a problem I can live with it. I'd much rather see

you spend the time on something like defines.....I'd be right there helping with this

stuff if I were not such a novice on this machine. ...on that note, if you guys think

I may be able to help you with batari's improvements, by all means ask.

 

I dont know if it is possible or not with the 'dim' statement but if not, can you add

#defines so I can use defines for a bit in a variable?

 

like

 

#define GAMEOVER = a{x}

 

if GAMEOVER then goto gameover

 

Now that would be shuga sweet!

 

That's a good idea, as things can get a little vague with all the bit twiddling.

[Gorf]

For the next release of bB, I am including a customized version of DASM. Aside from other things,

 

 

As long as it still works and is not a problem I can live with it. I'd much rather see

you spend the time on something like defines.....I'd be right there helping with this

stuff if I were not such a novice on this machine. ...on that note, if you guys think

I may be able to help you with batari's improvements, by all means ask.

 

I dont know if it is possible or not with the 'dim' statement but if not, can you add

#defines so I can use defines for a bit in a variable?

 

like

 

#define GAMEOVER = a{x}

 

if GAMEOVER then goto gameover

 

Now that would be shuga sweet!

 

That's a good idea, as things can get a little vague with all the bit twiddling.

 

 

 

Well I guess you can do something like, 'dim' a name like say...'gamestats'

but 'gamestats{x}' is not as readable as 'gamestats{GAMEOVER}' would be.

 

 

Again, if I was not so busy with contract work right now, I'd be all over helping

you guys with this. I would LOVE to make a version a batari for the Jaguar. Now

that we can run code from main RAM off the RISC's in the Jaguar, it would be a

more practical way to do things.

[SeaGtGruff]

I dont know if it is possible or not with the 'dim' statement but if not, can you add

#defines so I can use defines for a bit in a variable?

 

like

 

#define GAMEOVER = a{x}

 

if GAMEOVER then goto gameover

 

Now that would be shuga sweet!

 

That's a good idea, as things can get a little vague with all the bit twiddling.

 

 

 

Well I guess you can do something like, 'dim' a name like say...'gamestats'

but 'gamestats{x}' is not as readable as 'gamestats{GAMEOVER}' would be.

You should be able to do "gamestats{GAMEOVER}" right now, as follows:

   dim gamestats = a

  const GAMEOVER=0
  rem *** or whichever bit you're using to mean GAMEOVER

  rem *** a bunch of code, then...

  if gamestats{GAMEOVER} then goto restart_game

Michael

[SeaGtGruff]

You should be able to do "gamestats{GAMEOVER}" right now, as follows:

   dim gamestats = a

  const GAMEOVER=0
  rem *** or whichever bit you're using to mean GAMEOVER

  rem *** a bunch of code, then...

  if gamestats{GAMEOVER} then goto restart_game

Michael

Never mind, the batari Basic compiler views that as trying to use a variable with bit access, and won't let you do it. I thought it would realize that "GAMEOVER" is a *constant*, and use "0."

 

Michael

[Gorf]

You should be able to do "gamestats{GAMEOVER}" right now, as follows:

   dim gamestats = a

  const GAMEOVER=0
  rem *** or whichever bit you're using to mean GAMEOVER

  rem *** a bunch of code, then...

  if gamestats{GAMEOVER} then goto restart_game

Michael

Never mind, the batari Basic compiler views that as trying to use a variable with bit access, and won't let you do it. I thought it would realize that "GAMEOVER" is a *constant*, and use "0."

 

Michael

 

 

It would really rock to have defines for anything. this stuff is loads of fun, nonetheless.

[+batari]

It would really rock to have defines for anything. this stuff is loads of fun, nonetheless.

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

[Gorf]

It would really rock to have defines for anything. this stuff is loads of fun, nonetheless.

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

 

 

That would be fantastic! It can only make stuff much more readable.

[CurtisP]

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

 

I think the syntx in this cse should be def foo = bar

[Gorf]

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

 

I think the syntx in this cse should be def foo = bar

 

 

I would dig the #define like in C but I could live with 'def' as well.

[+batari]

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

 

I think the syntx in this cse should be def foo = bar

 

 

I would dig the #define like in C but I could live with 'def' as well.

I'm gonna go with def foo=bar, as it's consistent with other bB syntax.

 

Actually, I added the feature last night. It operates as just a simple replacement, and I've already started using it for redefining bits (def BOSSLEVEL=level{7} was the first test, and it worked!)

 

This brought up another idea. In C, #define can also take arguments, e.g. #define foo(a)=(bar+a)/2. It's kind of like a macro but limited to a single line. So I'd say to keep define for simple replacements and also add a macro command that can use arguments and multiple lines, e.g.:

  macro foo(bar, baz)
 if bar=baz then baz=baz+1
 if bar<baz then baz=bar
end

 

This will be a little harder and likely won't get done in a single evening...

[Gorf]

I think that defines could be done in the general case and not just for bits. I could modify bB's preprocessor to remember the defines and swap in the replacement text before the compiler sees them.

 

I think the syntx in this cse should be def foo = bar

 

 

I would dig the #define like in C but I could live with 'def' as well.

I'm gonna go with def foo=bar, as it's consistent with other bB syntax.

 

Actually, I added the feature last night. It operates as just a simple replacement, and I've already started using it for redefining bits (def BOSSLEVEL=level{7} was the first test, and it worked!)

 

This brought up another idea. In C, #define can also take arguments, e.g. #define foo(a)=(bar+a)/2. It's kind of like a macro but limited to a single line. So I'd say to keep define for simple replacements and also add a macro command that can use arguments and multiple lines, e.g.:

  macro foo(bar, baz)
 if bar=baz then baz=baz+1
 if bar<baz then baz=bar
end

 

This will be a little harder and likely won't get done in a single evening...

 

 

 

 

Im quite fine with 'def'...it is probably more closer to basic syntax anyway.

 

BTW,

Also, 'on goto' is absoluty perfect and well beyond anything I expected

efficiency wise. I saved at least a bank and a half.

 

How hard would it be to implement 'on gosub'?

[+batari]

Im quite fine with 'def'...it is probably more closer to basic syntax anyway.

 

BTW,

Also, 'on goto' is absoluty perfect and well beyond anything I expected

efficiency wise. I saved at least a bank and a half.

 

How hard would it be to implement 'on gosub'?

Shouldn't be too hard. I just haven't got around to adding it.

[SeaGtGruff]

How hard would it be to implement 'on gosub'?

I was going to say that it probably wouldn't be a good idea, but then I saw how "on...goto" is being implemented, and I think it should be easy to do, as follows (in assembly):

 

.L00  ; on n gosub line1 line2 line3 line4
  LDX n
  LDA #>(.L01-1)
  PHA
  LDA #<(.L01-1)
  PHA
  LDA .L00jumptablehi,x
  PHA
  LDA .L00jumptablelo,x
  PHA
  RTS
.L00jumptablehi
  BYTE >(.line1-1)
  BYTE >(.line2-1)
  BYTE >(.line3-1)
  BYTE >(.line4-1)
.L00jumptablelo
  BYTE <(.line1-1)
  BYTE <(.line2-1)
  BYTE <(.line3-1)
  BYTE <(.line4-1)
.L01  ; rem * continue here after returning
  NOP; etc. etc.
.line1
  NOP; etc. etc.
  RTS
.line2
  NOP; etc. etc.
  RTS
.line3
  NOP; etc. etc.
  RTS
.line4
  NOP; etc. etc.
  RTS

Michael

[+batari]

How hard would it be to implement 'on gosub'?

I was going to say that it probably wouldn't be a good idea, but then I saw how "on...goto" is being implemented, and I think it should be easy to do, as follows (in assembly):

Hmm... it's easier than I thought. I'll just expand the on...goto handling to add a few extra lines of code if gosub is used.

[Gorf]

How hard would it be to implement 'on gosub'?

I was going to say that it probably wouldn't be a good idea, but then I saw how "on...goto" is being implemented, and I think it should be easy to do, as follows (in assembly):

Hmm... it's easier than I thought. I'll just expand the on...goto handling to add a few extra lines of code if gosub is used.

 

 

Yeah, having an on gosub would eliminate the need to gosub after the on goto.