Oddity with an External Font File brought in with "file" in the Propeller Tool
JRetSapDoog
Posts: 954
I'm having a small quirk using an external data (font) file in the Propeller Tool. If the file (.fnt) with the font data is open in the editor tabs, then, on a VGA screen connected to the P2, I get garbage (lots of seemingly meaningless dot patterns in place of sensical-looking characters (letters, etc.)) after hitting F10 to upload to the P2. But if I close that .fnt tab in the editor, and then upload, the characters displayed on the VGA screen are fine. That is, I get no love if the .fnt file is open in the editor tabs upon hitting F10. I haven't checked to see if anything weird happens with data files that don't contain font data (i.e., a different file extension). FWIW, in my case, the font file is referenced in an object one down from the top (haven't tried other possibilities). Also, I've only tried this on the P2, not the P1.
Anyway, the workaround is simple, just don't open a tab for the .fnt file (Patient: Doctor, it hurts when I raise my arm. Doctor: Don't raise your arm). Or if I double click the top-level file to open all files automatically at once, then I just need to close the tab for that font file.
Initially, I was having this quirk in the Propeller Tool 2.5.1. And in that I've been meaning to upgrade to 2.5.3 to try playing with the enhanced debug features, I went ahead and upgraded to the latest-and-greatest (2.5.3), but the quirk persisted. The only difference is that in 2.5.1, I generally got some kind of access violation (I think) warning dialog on clicking on (bringing forward) the file for the font. Whereas, in 2.5.3, I just get a blank white screen (which is fine as I'm not trying to mess with the font file in the Prop Tool (I've used HxD Hex Editor for that purpose for minor changes)). Incidentally, I never ran into this quirk back when I was using a 2.4.X version).
When I first encountered this quirk, I thought that my font file was corrupted. So I replaced it (multiple times) but the pesky quirk kept coming back to haunt me. And after fiddling with things for about an hour, I was able to reproduce the problem and the workaround without fail. So I'm reasonably sure that somehow the font data that gets included into the P2 binary gets corrupted if the .fnt file is open in the editor tabs. Everything else works fine when the quirk is in effect, meaning that the text (in garbled glyphs) appears in the correct position on the screen and in the right foreground and background colors, but it's just a bunch of weird dots. Even the space character has dots in it. On quick inspection, I believe that the same character appears in the same garbled form everywhere on the screen that it is used (which is what you would expect). But as for what is really happening, I haven't looked into that and don't really know how. Perhaps there's some kind of offset problem when the .fnt file is open in the editor tabs. Or perhaps more likely no real font data is being incorporated and what I'm seeing as font data is just the data for code in the HUB. Not sure if the characters always appear the same or not, as the dot patterns are really small and hard to make out.
I don't think this will matter but for what it's worth, the font that I'm using is Eric Smith's (Total Spectrum Software) version of the built-in P1 font that is deinterlaced and arranged such that the first pixel line of all 256 characters comes first (2 bytes per char x 256 = 512 bytes per pixel line), followed by the second pixel line and so on and so forth. But I really doubt that the particular font has anything to do with the quirk and I'd expect the quirk to happen with any font and perhaps other kinds of data that are brought in. However, it's quite possible that this quirk only applies to .fnt files (because if it affected other data files, then I'd imagine that it would have come up earlier). Anyway, that's about all I know (or think that I know) about the quirk. My apologies if I erred in explaining this or my conclusion is wrong; I just got things working again within the hour (and I've been away from the P2 for a few weeks). --Jim
Comments
Known bug in Propeller Tool wherein it'll try open included binary files as text and just insert garbage into the compiled output. If you're really lucky it'll even crash PropTool.
Thanks for the reply/info, Wuerfel. That's good (for me) to know. Hmm, that would seem like one of those bugs that would be fairly straightforward to stomp out. Maybe someday. Anyway, working around it is easy. Thanks again.