If you don't want to be exposed to sloppy code stop reading...
Ok, this is the problem: I validate the set_gfx_mode and it returns a proper 0.
But there is a problem.
If it wasn't for a hilarious typing mistake I wouldn't have noticed it.
(The program doesn't work properly if I remove it either, that's why I started checking all the values and there seems to be no error after that.)
If I compile with mingw I don't get any error message, just a blank-out like nothing happened.

But if I compile with DJGPP it says (or something):
Error in line: 220
Not a Mode-X colordepth

This shouldn't happen. I've compiled dozens of times with DJGPP on that computer and never had that problem. It shouldn't be reverting to mode-x.(I run it under windows 95). Also the line where I check SET_GFX_MODE never returns a non-zero.
It doesn't seem to load my image either, but that's no surprise.

Here's the startup:

And if I make everything so it does work in mode-x I get a traceback of 1 line(!)
which says something about a DJGPP wrapper (or something).
And as it doesn't work with mingw either, I probably made some obvious noobish misstake...
Noobish source attached.
(I use allegro 4.2.1 with DJGPP and 4.2.0 with mingw)
I'll be very grateful to any non-noob willing to waste his (or less likely her) time on this.

Hmmm... quick thought:

if((main_field != 0) || (status_field != 0))my_error(__LINE__);

I'm not very good with operator precedence, but your original statement may or may not evaluate to:

if((main_field != (0 || status_field)) != 0)my_error(__LINE__);

which is equivalent to

if((main_field != status_field) != 0)my_error(__LINE__);

which in turn can be boiled down to

if(main_field != status_field)my_error(__LINE__);

...which is very likely to be true.

Not sure though, I might have operator precedence wrong.
The safest check would be:

if(main_field || status_field)my_error(__LINE__);

...but even this doesn't make too much sense; it means that if the creation of any of the 2 sub-bitmaps was successful, you throw an error. I think you mean the opposite:

if(!main_field || !status_field)my_error(__LINE__);

Try this and see if it fixes the error.

That was the hilarious typing misstake I was talking about...
As for all the other consequenses, read my first post. Besides, there shouldn't be an allegro_error at this point if everything worked properly.
[MAGIC EDIT looking into future]
Allegro_error is initialized at this point otherwise the output would have been different (i.e. just "error in line 220"). And it is a relevant message, because Mode-x only supports 8bpp and I (only) tried 16. Please read my post more carefully.
Oh, there's one thing I forgot to mention: in one version I just changed set_color_depth(8). Which results in another error namely: Not a proper mode-X resolution. And it still it only catches this in line 220... Bizarre!

If there has been no error, then allegro_error is undefined (i.e. cannot be trusted to tell you anything meaningful). Inspecting allegro_error makes sense only if an allegro function call has failed.

Not related to the error, but...

(main_field != 0) || (status_field != 0)
// Equivalent
main_field != 0 || status_field != 0

// Furthermore
(main_field != (0 || status_field)) != 0
// NOT Equivalent
(main_field != status_field) != 0

// Correct reduction
main_field != (bool) status_field

weapon_S: Just print out the value of your driver name:

textprintf_ex(screen, font, 2, 2, -1, 0, "I am using graphics driver %s", gfx_driver->name);
readkey();

Thought I might be wrong...

I fixed it (I think).
I had a function definition at the end of main. I think it confused END_OF_MAIN.
Whatever it was it's working (kind of) properly now.

As with many mathematic deductions it's not the same, because if they're both true I get true. Which isn't the case with the original expression,... I think.

Just for your information, that wasn't the problem.