Failed Ooze Build

[potatohead]

Here is the output from the message window.

 

DASM V2.20.07, Macro Assembler ©1988-2003

bytes of ROM space left

-13 bytes of ROM space left

-13 bytes of ROM space left

segment: ff9c vs current org: ffa9

Ooze--085.bas.asm (5667): error: Origin Reverse-indexed.

Aborting assembly

2600 Basic compilation Failed!

 

And it's Ooze 0085, the last one posted here. It can be found in my blog.

 

Suspect this is due to kernel size changes....

[SeaGtGruff]

-13 bytes of ROM space left

Yes, probably due to some kernel changes. But if it's just 13 bytes over, you might want to take a look at the assembly listing to see if there's a way for you to rearrange anything to reclaim some space. I'm referring to the way the player and playfield graphics are positioned in memory, which sometimes requires aligning to the next page. If you see that there are any aligns that waste space, you might be able to alter the order in which the graphics are defined in your program, which would shuffle the graphics data around a bit and maybe require less wasted space. Or there might be an include file that you don't really need in your program.

 

Michael

[potatohead]

Yep. That was it.

 

I pulled some code and it built just fine. Now to go and see if I can find the latest source. Thought it was archived here, but...

[SeaGtGruff]

Yep. That was it.

 

I pulled some code and it built just fine. Now to go and see if I can find the latest source. Thought it was archived here, but...

I grabbed 0.85 from your blog and compiled it with the same results, -13 bytes free. I didn't see any extra aligns, just the two in the kernel, but I saw where you could optimize a little bit by rearranging the way some variables were initialized. So I rearranged a few things, and remmed out a line that seemed superfluous (s = 0, followed immediately by s = 3), and it compiled with 3 bytes free. But it looks like you need to adjust for the changes in the player/missile x positions, because the ship's fire knocks out the playfield pixels that are a column or two to the left of the ship. I forget what player0x value used to give you player0 at the leftmost position on the screen, but now it's player0x = 1.

 

Michael

 

Edit: The optimizing I referred to involves placing initializations on the same line if they set several variables to the same value-- like putting several "= 0" initializations together on a line, with no other values in the middle of them. That lets you save a few bytes by not having to load the accumulator with a new value, e.g.:

 

   a = 0 : c = 0 : e = 0 : b = 2 : d = 4
  rem compiles to
  rem LDA #0
  rem STA a
  rem STA c
  rem STA e
  rem LDA #2
  rem STA b
  rem LDA #4
  rem STA d

  rem versus

  a = 0 : b = 2 : c = 0 : d = 4 : e = 0
  rem compiles to
  rem LDA #0
  rem STA a
  rem LDA #2
  rem STA b
  rem LDA #0
  rem STA c
  rem LDA #4
  rem STA d
  rem LDA #0
  rem STA e

Edited May 30, 2009 by SeaGtGruff

[+batari]

Yep. That was it.

 

I pulled some code and it built just fine. Now to go and see if I can find the latest source. Thought it was archived here, but...

You can usually recover some space by compiling with the -O option. The compiler can produce redundant assembly code, and the optimizer acts on the completed assembly file, finds this code and comments it out. It will almost always find something.

 

E.g., the compiler might produce an assembly file with a load from a variable it has just stored to. The optimizer will remove the redundant load, provided the load is not a branch target. The compiler also sometimes produces CMP #0 which is always redundant if bB produces it.

 

The optimizer isn't enabled by default because there is an infinitesimal chance it will cause a program to fail by removing a CMP #0. If bB produced the CMP #0, there's no problem, but if your inline assembly contains this (and you actually need it for something, which would be exceedingly rare) then it might cause your program to fail.

 

I have used the optimizer for years without a single failure, FWIW.

[jwierer]

You can usually recover some space by compiling with the -O option. The compiler can produce redundant assembly code, and the optimizer acts on the completed assembly file, finds this code and comments it out. It will almost always find something.

 

E.g., the compiler might produce an assembly file with a load from a variable it has just stored to. The optimizer will remove the redundant load, provided the load is not a branch target. The compiler also sometimes produces CMP #0 which is always redundant if bB produces it.

 

The optimizer isn't enabled by default because there is an infinitesimal chance it will cause a program to fail by removing a CMP #0. If bB produced the CMP #0, there's no problem, but if your inline assembly contains this (and you actually need it for something, which would be exceedingly rare) then it might cause your program to fail.

 

I have used the optimizer for years without a single failure, FWIW.

BTW for any Visual bB users there is an "Enable peephole optimizer -O" option in the settings tab so you can turn this on/off.

 

-Jeff

[SeaGtGruff]

You can usually recover some space by compiling with the -O option.

I tried the -O option on the Ooze 0.85 code after I'd gotten it down to 3 bytes free by reorganizing some initializations, and it jumped up to 22 bytes free!

 

Michael

[potatohead]

I ran it too. Worked just fine.

 

Now to find if 0.9 or 0.95 still exists...