Sizecoding reaches Jaggy

[42bs]

256byte pure 68k fire:
https://www.pouet.net/prod.php?which=91150

 

Does _not_ run on any emulator so far!

Edited February 28, 2022 by 42bs

[Zerosquare]

Nice!

 

It works fine here, but only in 50 Hz mode (black screen in 60 Hz mode, both with the normal boot ROM and with the BJL ROM).

[42bs]

Yes, the video setting is fixed. I need to build a NTSC version. No space to hold both. I need to find the video setup in the BIOS to call it.

[Zerosquare]

Remember, there are at least two versions of the official boot ROM, not including the BJL ones

[Cyprian]

finally Jag on the board.

nice fx.

I guess it wasn't so easy to fit in 256 bytes all that startup stuff

[42bs]

One of the things I found out is, that a lot of stuff is not really needed.

For example setting big ending mode or stopping the OP. This is all done by the (stock) ROM. 

 

[42bs]

Added NTSC versions and .COF files to github

https://github.com/42Bastian/new_bjl/tree/main/exp/fire256

[42bs]

And here a version with GPU. One .j64 for PAL or NTSC:

 

https://github.com/42Bastian/new_bjl/tree/main/exp/gpufire256

 

Slightly quicker as the 68k version as it runs from ROM and not internal RAM (need to reduce the 68k part some more bytes for the copy loop).

[+cubanismo]

Can't get the GPU one to run from .cof or .j64 on a Skunkboard. Tried 50Hz and 60Hz. The .j64 works fine on a Gamedrive (I.e., a regular full BIOS boot), but the .cof does not (Gamedrive just hangs on menu screen, presumably after loading the tiny file and trying  to run it).

 

How are you testing these? BJL?

[42bs]

1 minute ago, cubanismo said:

Can't get the GPU one to run from .cof or .j64 on a Skunkboard. Tried 50Hz and 60Hz. The .j64 works fine on a Gamedrive (I.e., a regular full BIOS boot), but the .cof does not (Gamedrive just hangs on menu screen, presumably after loading the tiny file and trying  to run it).

 

How are you testing these? BJL?

This code relies on the BIOS setting up the video, therefore it does not run from SKUNK and likely not BJL.

Updated it, now it runs fullspeed in internal RAM.

[+cubanismo]

Looks very smooth now ? FWIW, the 68k version does work on my Skunkboard.

[42bs]

2 minutes ago, cubanismo said:

Looks very smooth now ? FWIW, the 68k version does work on my Skunkboard.

Yes, the 68k version does setup the video. But I needed the code-space for the copy routine.

[42bs]

For those w/o Gamedrive:

 

[SlidellMan]

Wow, that is an excellent use of the Jaguar's particle capabilities.

[42bs]

3 minutes ago, SlidellMan said:

Wow, that is an excellent use of the Jaguar's particle capabilities.

I am not sure what you mean, but this is pure old-school frame buffer manipulation:
 

for all x,y do
  plot x,y, MIX(color(x+1,y+1)+color(x,y+1))

 

[42bs]

Prototype in Processing:

int [][] frame = new int[103][160];
int [] r = new int[256];
int [] g = new int[256];
int [] b = new int[256];


void plot(int x, int y, int col)
{
  int _r,_g,_b; 
  _r = r[col];
  _g = g[col];
  _b = b[col];
  _r*=6;
  _g*=6;
  _b*=6;
  fill(_r,_g,_b);
  stroke(_r,_g,_b);
  rect(x*4,y*4,4,4);
}


void setup() {
  size(640,408);
  noSmooth();
  rectMode(CORNER);
  surface.setLocation(1800,100);        
  frameRate(60);

  for(int y = 0; y < 102; ++y){
    for(int x = 0; x < 160; ++x){
      frame[y][x] = 0;
    }
  }
  int _r = 0;
  int _g = 0;
  int _b = 0;
  for(int col = 0; col < 256; ++col){
    r[col] = _r;
    g[col] = _g;
    b[col] = _b;
    if ( col < 16 ) {
      _b = col;
    } else {
      _b = 0;
    }
    if ( (col & 32) == 0 ){
      ++_r;
    } else {
      ++_g;
    } 
  }
}

void draw()
{
  int x,y,s;
  s = 0;
  for(y = 0; y < 102; ++y){
    for(x = 0; x < 160; ++x) {
      int rp;
      int lp;
      
      if ( x < 159 )
        rp = frame[y+1][x+1];
      else
        rp = frame[y+1][0];
      lp = frame[y+1][x];  
       
      s = (rp + lp) & 255;
      s = (s + lp) & 255;
      s ^= lp;
      s = (s+frame[y][x]) & 255;
      s ^= frame[y][x];
      s /= 4;
      frame[y][x] = s & 255;
      plot(x,y,s);
    }
  }
  for(x = 0; x < 160; x+=2){
    s = s+int(random(65536));
    frame[102][x] = s & 255;
    frame[102][x+1] = (s >> 8)& 255;
  }
}

 

[42bs]

Some evolution.

Now 32 bits read/writes and scaled bitmap.

I guess a quicker fire is only possible using blitter to move lines in and out.

 

https://github.com/42Bastian/new_bjl/tree/main/exp/quickfire256

[42bs]

MONA ported:
https://github.com/42Bastian/new_bjl/tree/main/exp/jagmona

 

https://www.pouet.net/prod.php?which=91157

Edited March 4, 2022 by 42bs

[ggn]

1 hour ago, 42bs said:

MONA ported:
https://github.com/42Bastian/new_bjl/tree/main/exp/jagmona

 

https://www.pouet.net/prod.php?which=91157

Nicely done!

 

In line 56 with a bit of re-jigging you should be able to move the 7ec8 part of the constant right before "brush" and load both high and low parts using a move.l (a1)+,d7. Then move that "move.w (a1)+,d7" below the inner loop so you can consume the next part of the seed then. This should save you a whopping 2 bytes . More info about this madness (and more!) here http://beyondbrown.mooo.com/post/mona/

[42bs]

1 minute ago, ggn said:

Nicely done!

 

In line 56 with a bit of re-jigging you should be able to move the 7ec8 part of the constant right before "brush" and load both high and low parts using a move.l (a1)+,d7. Then move that "move.w (a1)+,d7" below the inner loop so you can consume the next part of the seed then. This should save you a whopping 2 bytes . More info about this madness (and more!) here http://beyondbrown.mooo.com/post/mona/

Cool! Thanks. But I fear, the 256byte goal is still unreachable.

 

[42bs]

I was think about SMC, but I wanted the code to run from ROM, so no way.

[42bs]

6 minutes ago, ggn said:

Nicely done!

 

In line 56 with a bit of re-jigging you should be able to move the 7ec8 part of the constant right before "brush" and load both high and low parts using a move.l (a1)+,d7. Then move that "move.w (a1)+,d7" below the inner loop so you can consume the next part of the seed then. This should save you a whopping 2 bytes . More info about this madness (and more!) here http://beyondbrown.mooo.com/post/mona/

Not sure, as I do

move.b (a1),d1

for the Y. But I need to think ...

[ggn]

Yes, the two implementations have structured the code a bit differently. So it's quite possible that it's not feasible in your case - after all I just took a quick look. And sure, SMC is completely out of the question, I did notice that :).

 

I see from the .rom file that the binary size is 304 bytes. So who knows, maybe 256 is reachable with lots of rewrites and exploits, maybe not! But at least my -2 bytes is a start

[42bs]

1 hour ago, ggn said:

Yes, the two implementations have structured the code a bit differently. So it's quite possible that it's not feasible in your case - after all I just took a quick look. And sure, SMC is completely out of the question, I did notice that :).

 

I see from the .rom file that the binary size is 304 bytes. So who knows, maybe 256 is reachable with lots of rewrites and exploits, maybe not! But at least my -2 bytes is a start

Actually it is 314 bytes. But I am already doing a lot of dirty stuff. Tried the trick, but adding the "lsr.w #8" will eat up the gain.

I have to try to get rid of the VBL interrupt and rather check the HBL counter to for the OBL reload.

*hmp* rmac/rln seem to align the output to 16bytes

Ok, found it: -rw => Word alignment.

Edited March 4, 2022 by 42bs

[42bs]

Down to 306 bytes ... 50  304 bytes ... 48 to go

Edited March 4, 2022 by 42bs