Jump to content
IGNORED

Error codes? Where do I find these?


Gorf

Recommended Posts

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 by Gorf
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...
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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

 

:D

Link to comment
Share on other sites

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!

 

:D

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

Link to comment
Share on other sites

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!

 

:D

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.

Link to comment
Share on other sites

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!

 

:D

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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'?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...