@joerg

A great little utility- thanks!

@all

It's obvious what most of the displayed numbers represent, but there are some whose meaning is not apparent. Does anyone know what the F:xxxxx, D:xxxxx, and S:xxxxx figures at the top of the display mean? (See Capehill's screenshot for reference.)

@trixie

I always enjoy reading your blog entries. You write very well, particularly for someone who is (I presume) not a native English speaker.

Quote:
Indeed it did. And while in retrospect, once you learn that AllocBitMap() and AllocBitMapTags/TagList() work differently from each other you can reason out why that is, I agree with FlynnTheAvatar that based on reading the autodocs that's not what you'd expect to happen.

It would be nice if the autodoc for AllocBitMap() could be updated to add a note that due to the need for backwards compatibility, you might not get an optimal BitMap for an RTG display even if you pass an RTG friend BitMap. Otherwise this is sure to catch someone else by surprise someday.

@FlynnTheAvatar

Quote:
I don't have any inside knowledge of how graphics.library works, so I can only make educated guesses as to what might be going on, based on the results you're seeing.

I suspect that as an OS 3.0 function, AllocBitMap() has to be backwards compatible in order to allow old OS3 programs to run, even when passed a friend BitMap. While as an OS 4.1 function, AllocBitMapTags/TagList() is free to assume a more modern program is calling it, on a more modern machine. So even when passing the same parameters, you might be getting a different BitMap depending on which function you call.

I imagine you're running the example program on a 32-bit truecolor Workbench screen, which means your friend BitMap is also 32-bit truecolor. But the backBuffer BitMap you're allocating has a depth of only one bit. So the question is, what happens when you ask for a one-bit color-mapped BitMap, but pass a 32-bit truecolor friend BitMap?

Back in the OS 3.1 days even graphics cards typically supported planar displays when the depth was less than eight. So for compatibility with programs from that era, you may well be getting a one-plane planar BitMap from AllocBitMap(). Of course that's going to require planar to chunky conversion when blitted to a 32-bit BitMap, which is going to be slow.

When calling AllocBitMapTags/TagList() I wonder if you're not getting something like an 8-bit color-mapped BitMap instead. It would use eight times as much memory (not as big an issue on an OS4 system), but would be much faster to blit to a truecolor BitMap.

As Capehill suggested, it might be instructive to query the BitMaps returned by the two different functions using GetBitMapAttr() to see how they compare.

BTW: I don't think it makes any difference with this issue, but the backBuffer BitMap doesn't really need to be BMF_DISPLAYABLE, since it is never displayed directly, but is always blitted to a displayable BitMap for display.

@afxgroup

Quote:
What about https://www.researchgate.net/publicati ... ith_compiler_optimization? The other two sites work with IBrowse too, while this one doesn't.

@afxgroup

Quote:
I don't think it's an SSL problem- that's not the kind of security issue that Cloudflare is looking for. They're looking for automated web bots that are probing or potentially attacking a web site. Simply checking SSL certificates and looking at user agents isn't good enough, as robots also use SSL, and know how to spoof as being an actual web browser.

I'm sure the details of how they attempt to discriminate between bots and real users are proprietary, but it seems to involve running some Javascript (no doubt heavily obfuscated) on the browser, and if they're still not sure, putting up a CAPTCHA.

Quote:
No, it's an Odyssey problem. Most likely the Javascript makes use of some Javascript or browser functionality that Odyssey doesn't support, so the test fails or doesn't even run. It never gets as far as putting up the CAPTCHA, though in the past when the CAPTCHA did appear it didn't help- though the CAPTCHA itself seemed to work, clicking 'Verify' at the end just brought up another CAPTCHA, and you still couldn't access the site or page.

Regardless of the cause, the effect is the same- Cloudflare threat protection on a site means you can't access it with Odyssey. The situation with IBrowse seems a little more complex.

@Futaura

Quote:
This link that LiveForIt posted over on the RadeonHD V.5 driver thread is an example of a web page that is not accessible to Odyssey because of Cloudflare's threat protection:

https://www.researchgate.net/publicati ... ith_compiler_optimization

There's no CAPTCHA with this page, so either there are different versions of the threat detection code, or the code has changed and no longer gets far enough to even bring up the CAPTCHA.

When I try to follow the link with Odyssey, I get a page with a "Checking if the site connection is secure" message, followed by a high CPU load as a lot of Javascript runs. After a bit the message "This check is taking longer than expected" pops up. After a bit more the page reloads, and the whole thing repeats.

Every now and then, for whatever reason, I instead get a "Verify you are human" button in addition to the "This check is taking longer than expected" message. With other sites in the past clicking on such a button has brought up the CAPTCHA, but here it has no effect, and eventually the page reloads again.

When I try this same link with IBrowse I get the same "Checking if the site connection is secure" page, but there doesn't seem to be any Javascript executing, and nothing further happens (no "taking longer" message or page reloading).

Here's another link that doesn't work with Odyssey due to Cloudflare:

www.bhphotovideo.com

When I try it with Odyssey, I get the same result as with the link above. But curiously, when I try it with IBrowse it works fine (or as well as it can, with no CSS support).

@Futaura

I was thinking more of the threat protection aspect of Cloudflare- almost every time I encounter a website that wants me to prove I'm not a robot and then won't let me in no matter how many times I complete the CAPTCHA, it turns out to be Cloudflare. So I've come to associate Cloudflare with "can't go there with Odyssey." I imagine IBrowse also has this problem, though I've never actually tried it.

If that part of Cloudflare can be separated from the SSL/certificates part, then of course I have no objection to that.

Quote:
Definitely don't do that- it would make it inaccessible to Odyssey (and presumably IBrowse, too).

@kas1e

Quote:
While the version tag date is 03/06/2022, the file date on the one in Enhancer seems to be 03/06/1980- I'm not sure what happened there.

@rjd324

Quote:
Ranger can display all the firmware environment variables in its Hardware->Firmware tab.

@khayoz

OS 4 version 1.943 also crashes on exit if "sort by date" has been used.

@rjd324

Quote:
You could always get a Sentinel X-Logger!

@kas1e

Quote:
Yes, that's right.

@kas1e

Quote:
On my X1000 I get 49 seconds from power on to working system, which includes a five second timeout for the CFE boot menu. It takes 32 seconds from power on to where the progress bar first appears as amigaboot.of starts loading modules (including that five second menu timeout), and another 17 seconds from there to a full working system. That's with the standard (not debug) kernel and a mechanical HDD formatted with SFS2.

@kas1e

Quote:
I vaguely remember seeing that at some point in the past (perhaps when I was having boot problems due to a depleted backup battery), but in normal use I never have that problem.

@walkero

Quote:
That's not entirely true. If you look at adtools.lha on OS4Depot, which contains GCC 8.3.0, you'll find in the share/info directory the file gcc.info, which has been edited to document the Amiga-specific alterations to GCC, including -athread. This information apparently never made it to any of the PDF versions of the GCC documentation.

@kas1e

I got a crash as well, a DSI. The redzone was not damaged, but the stack pointer was out of bounds. Looks like an infinite recursion leading to a stack overflow, with the stack full of two alternating addresses in elf.library.

My libjpeg.so is the same size as yours, and I got the same crash even if I used the FILE switch.

So no, it's not just you.

@walkero

As a user, I don't always immediately upgrade to the latest version of something, as for every bug it fixes and new feature it adds, it also may break something or add new bugs. For example, I stayed with OS 4.1.6 for some time after FE was released, because the initial incarnation of FE was rather buggy. It was only after Update 1 came out that I switched to FE.

As a developer, I try to keep users like me in mind when writing software, and generally make some attempt at supporting older versions of the OS/libraries/MUI/whatever. I try to avoid using conditional code to add backwards compatibility, as it makes the code hard to read and maintain. But if I can use a DOS function that only supports 32-bit file sizes, for example, when I know that my application will never generate files large enough for that to be a problem, then why not? Likewise, does that gee-whiz new feature really add value to the user, or would the program be just as useful -- though maybe less sparkly -- without it?

If there's a compelling reason to use the latest version of something (for example, it fixed a bug that my application can't reasonably work around, or it adds a useful new feature that it's not practical to reproduce some other way) then I'll certainly do so. But I'll also at least look at whether I can work around the bug, or if I really need that new feature.

Balanced against all that is the stark reality that there are far more Amiga programs that need to be written than there are developers to write them, so whatever makes it most efficient (and enjoyable, since most of us are not in it for the money) to work on Amiga software is the way to go. If for any given programmer that means only using/testing with the very latest version of everything, then so be it. But please do publicize the requirements so no one will be caught by surprise, and have the program display a helpful error message and safely quit if it encounters an outdated version of something, rather than crashing or not working properly.

@kas1e

Quote:
That sounds like heatsink compound, not thermal glue. Heatsink compound is a silicone paste that helps heat transfer between the CPU and the heatsink by filling any tiny gaps between the two. It intentionally gets softer when it's hot. It's not intended to hold anything in place, and is only used when you have some other means of securing the heatsink.

If you do end up with a stick-on or glue-on heatsink you'll want to remove the heatsink compound first, as nothing is going to stick to it.