startbjl.cof + Weird code in skunkboard BIOS

[+cubanismo]

Largely a question for @Tursi, but thought I'd ask publicly in case it helps others or others have ideas.

 

I was trying to debug a flaky board I built last night, and figured I'd use startbjl.cof (Claims to boot a skunkboard over BJL rather than from the flash.  Basically just the board BIOS code in BJL form).  However, it doesn't work.  Just throws an exception and dumps me right back in the BJL boot screen.  I tried dropping some breadcrumbs in d7, but they don't seem to persist as well as I'd hoped back in the BJL register dumps at the bottom of the boot screen (Got non-sensible results with that after the first few tries).  I had updated the code a bit to merge in my pending changes and sync it with 3.0.2 before that, but even reverting back to the binary on https://github.com/tursilion/skunk_bios, I was still seeing the same failure.  BJL claims PC only got to 0x141C, a few instructions in, but I don't know if I can rely on it (That address isn't even on an instruction boundary, but I don't know how the 68k reports PC in exceptions).

 

If I adjust the startup address (E.g., $1400->$100000) and send it to a working skunk using JCP, which I'd been doing to test my BIOS changes, it works fine, but that's kind of cheating because the on-flash BIOS has already initialized things and this should just be the equivalent of a soft reset.  Also not useful for my intended purpose here, but it's a data point none the less. @Tursi, can you confirm startbjl.cof in your BIOS repo works for you or worked as-is in the past?

 

Second thing: While trying to debug by inspection, I noticed this code:

calc_vals:
                move.w  d0,320
                move.w  d4,200

Now this just looks wrong.  It's looks like it's a search/replace gone bad from the standard Atari startup.s initialization code, which does this:

calc_vals:
                move.w  d0,width
                move.w  d4,height

width/height being words in BSS, so obviously not the same thing.  Further, I don't see any reads from these locations, so it looks like best case it does nothing.

 

However, it's been in the skunk bios boot code (BJL and on-flash version) forever and doesn't *seem* to be causing any problems (Nothing important at #200 and #320 in RAM at this point?), so I'm wondering if I'm just missing something and it's actually intended to stash these values there for some reason.

 

[Zerosquare]

Address 200: trap #0 interrupt vector

Address 320: reserved interrupt vector

 

I don't think anything on the Jaguar uses these vectors or rely on their value. So the mistake is probably harmless.

 

[Tursi]

I'm not entirely sure I remember. I haven't touched any of those tools since... looks like 2012?

 

I have definitely run the Skunkboard BIOS from BJL, though... in theory it's not that hard. The Skunkboard copies the BIOS from flash to RAM for normal operation anyway, so it always runs from RAM.

 

calc_vals does look wrong to me, too, hehe.  I'd say your instinct is probably correct.

 

The code contains absolute jumps, so if you are loading it at a different address and it's working, I assume you're changing the build address. I mean, you should find it's pretty much the same code that is actually loaded into the flash chip when programming the Skunkboard, so I guess you could try comparing against that -- or just extracting the working code and throwing this version away.  I can't say what this was used for, might have just been a one-time test.

 

What was the exception? 0x141c should still be in the initial moves... is one of the labels there mis-defined in your jaguar.inc?

[+cubanismo]

6 hours ago, Tursi said:

I mean, you should find it's pretty much the same code that is actually loaded into the flash chip when programming the Skunkboard, so I guess you could try comparing against that -- or just extracting the working code and throwing this version away.

Yeah, the first version I tried is actually after I'd re-synced startup.s and startbjl.s: Only difference is the jump addresses aren't calculated relative to RAMLOAD in the BJL version.  That's why it's so puzzling.

 

6 hours ago, Tursi said:

What was the exception? 0x141c should still be in the initial moves... is one of the labels there mis-defined in your jaguar.inc?

I'll have to try again, don't remember the exception. And yeah, it seemed to be the endian set move to the GPU IIRC.  Built against the same header as the working on-flash BIOS and it works when I build with a different start address and load via JCP, so I doubt the header is wrong.  I must be doing something wrong here.  I'll keep messing with it.

[+cubanismo]

Well, that was annoying.

 

Took a look at this again, and the exception codes were always either 0x2 or 0xA (illegal instruction, unimplemented instruction). This didn't make any sense. I rebuilt the code to load at 0x1ff000 like I'd done when loading it via JCP, and it worked fine. Then, figuring it was the only possible difference between what you would have run and what I was running, I BJL'd over the old 1997 loader at 0x1ff000 (Recall I decided the 1997 loader wasn't good enough and made myself a BJL BIOS that uses the mysterious 2005 loader code of unknown origin), and loaded startbjl.cof built at 0x1400 with that, and it works fine. I tried BJL'ing the 2005 loader over at the same address for the same experiment, and it failed. Something in the 2005 BJL loader is clobbering the data I upload to 0x1400. I tried again with startbjl.cof compiled to load at 0x1500 on the 2005 loader, and that works fine.

 

Comparing the source for the 1997 loader with the disassembled 2005 loader, I can see they both put the screen bitmap object at 0x1000, and it's a 1-bit image. The 1997 loader displays 3 lines of text, resulting in a (320 >> 3) x 24 = 0x3c0 byte bitmap, so it ends at 0x13c0. We're safe. The 2005 loader displays 4 lines of text, resulting in a (320 >> 3) x 32 = 0x500 byte bitmap, which ends right at 0x1500 (good guess, right?). The last line is constantly updated, displaying the last uploaded dword. BJL was drawing its text over the first 0x100 bytes of uploaded data, corrupting my BIOS instructions.

[Tursi]

42 minutes ago, cubanismo said:

Comparing the source for the 1997 loader with the disassembled 2005 loader, I can see they both put the screen bitmap object at 0x1000, and it's a 1-bit image. The 1997 loader displays 3 lines of text, resulting in a (320 >> 3) x 24 = 0x3c0 byte bitmap, so it ends at 0x13c0. We're safe. The 2005 loader displays 4 lines of text, resulting in a (320 >> 3) x 32 = 0x500 byte bitmap, which ends right at 0x1500 (good guess, right?). The last line is constantly updated, displaying the last uploaded dword. BJL was drawing its text over the first 0x100 bytes of uploaded data, corrupting my BIOS instructions.

Ah ha... a case of battling bioses

 

[Zerosquare]

Yes, in hindsight it's obvious: RAM below $4000 was reserved for use by the Alpine debugger, and BJL uses the same area (hence why standard programs start at this address).

[+cubanismo]

For the sake of completeness, the BJL loader appears to use $1000-$1500 (4-lines-on-screen versions) and $2000+ (Didn't measure exactly how much) for variables and stack.  Even with my additions, the skunk BIOS is only ~2500 bytes, fitting well between the regions BJL occupies if placed correctly.

 

For my testing purpose, I've just written a script that loads the older BJL loader and immediately uses that to load the skunk BIOS. Seems better than running from a different start address than the real BIOS or tweaking the real BIOS load address too at this point.