Why can't I open the Topaz-font in a boot block?
 

Trying to open the resident Topaz size 8, but OpenFont fails. Code works perfectly fine outside the boot block. Any ideas?

Resident fonts are case sensitive. If you tried to open "Topaz.font" it will fail, because it's called "topaz.font".

Anyway, topaz 8 ist the default font. You shouldn't need to open it. If you call InitRastPort() your RastPort will be set to topaz 8 already.

Thanks for the hints. I am of course opening "topaz.font" - the code works and prints text just like it should when I run it from CLI or Workbench.

What I'm after is the pointer to the actual bitmap data for the Topaz 8, and again this works fine outside the boot block. I tried calling InitRastPort and picking the TextFont pointer from there, and then the tf_CharData, but I see from the results that the TextFont doesn't get properly initialized.

Any other ideas how I can obtain the pointer to the font bitmap?

I think (not sure though) that OpenFont() doesn't work in the bootblock because it needs initialized intuition.library which isn't available at boot. But this is just a guess.

You could look for the first "8x8" font you find in the gb_TextFonts structure in gfxbase. Something like:

should do the trick.

Thanks. You forgot to compensate for the node size in your code, but even then I can't find a single font with a width or height of 8 in the TextFonts list. I also tried picking the font via DefaultFont in the graphics base, but that gives the same random letters as when I pick the font from a freshly initialized RastPort.

What I want to get hold of is the monospaced bitmap of the Topaz 8, where the characters come in ASCII order and are 8 bytes per character, which is exactly what you get when you call OpenFont.

This is what the alphabet in Topaz 8 looks like when I grab it via the graphics base or a RastPort:

The code is perfectly fine!

Not sure what is wrong with your code but I can find the Topaz font with the code I posted.

Really? My docs say that TextFonts is at offset 140 in the graphics base, and this is a List of size 14, and at offset 0 in there is the pointer to the first Node, which has a size of 14, and the actual data, a TextFont structure, comes right after. You must've looked at some other code, because I don't see how you can traverse a list from just a TextFont structure. I can't make head nor tail of this (get it?).

Let's get on the English Amiga Board Internet Relay Chat Server (TM) and solve this, or do it later if you're at work.

If anyone else knows a safe way to get to the intact Topaz 8 bitmap in a boot block, please post!

Theres plenty of bootblocks that use resident fonts, especially stuff like Interferon. The X-Copy bootblock uses a resident font doesn't it?

I have hacked a small example which shows that my code is perfectly fine! I have attached it here. I really don't know why you didn't just use the code I posted. And as for your question:

lea gb_TextFonts(a6),a0


Anyway, here's the main part of my example code:

and it'll print one line with the font.

The struct TextFont *contains* the stuct Node at the beginning, it does not come after it. So the tf_#? offsets already include the 14 bytes of the Node.

Thanks, I've sorted the confusion now. The docs are a bit messy, the TextFont contains a Message structure which in turn contains a Node and some other data, but with no mention that fonts are effectively linked together through the Message structure, so instead I start at the graphics base and see a List which points to a Node which has a diagram depicting attached data at the end of the node, and I end up with wrong offsets.

In any case Stingray's first suggestion to iterate through the font list works fine now that I've corrected my offsets.

Thanks!

I seem to remember I needed no search algo to nick topaz 8 in the bootblock. But that was on kick 1.2-2.0. This is what I used way back when, probably the same way Leffman does it?

Comments included as bonus, the last one is probably for some .library reuse or other packing.

It feels very strange to me that OpenFont would start failing on higher kicks without any mention in docs, but perhaps the last revision of those bibles was exactly in the kick 2.0 times.

Maybe the font organization in memory or font struct changed at some point, and that's why some methods work/fail?

You're right that OpenFont DOES work in a boot block, and looking at your code I just realized that OpenFont failed because I had set the pointer to the font name directly in the TextAttr structure, and ignored it when I made the rest of the code PC-relative. Funny how you always look for the error in the wrong place.