@Ami603Quote:
Oh, cool - that's a new addition for OS4. It would be most helpful in OS3.

@jabiruloQuote:
:) Whenever I have some time. I'm pretty busy at the moment but I'll get back to it soon...

@kas1eQuote:
I agree. I just couldn't find another way to access that information.

Quote:
Yeah, it's a sanity check, just in case the Intuition current window and ARexx current window somehow aren't the same window.

There's no way that I know of using the standard API. I used the ARexx interface to get the name of the currently active window, and then checked to make sure the dimensions matched the window struct of the current window from Intuition so I could be reasonably sure it was the same window. This isn't bullet-proof of course...

Ordinarily, waiting for IDCMP_NEWSIZE would be the "safe" way to know the resize has been completed and the new size values present in the window struct. I'm not sure if that's easy to detect though when you don't own the window yourself.

Since I never got that far, I can't be sure... But is it possible that that tag is only set *after* the window is opened?

For DrawerGenie, I had planned to use SetFunction() to detect all windows opening with the WFLG_WBENCHWINDOW and open a toolbar for each, but I couldn't get it to work properly in Blitz so I left it out. To get the patch to work, I might just write the patch itself in C and run it from the Blitz parent program to get it going.

Integrating fully into the actual fabric of the Workbench window (as opposed to window border buttons) would be a massive patch, and I've tried to avoid that wherever possible. Instead, it remembers the struct of each relevant window and polls them to check if they've moved. It's not ideal, but it works reasonably well, and while it lags the windows, it's fast enough for classic use. It also respects window border widths so as to align neatly with the border.

I haven't had the time to do any debugging on OS4 yet, but from the description I suspect it's simply a problem with the GTGZZ positioning flag that means the gadgets end up beyond the visible window borders. Odd that it happens like that, but I can detect OS4 and compensate easily.

Heh, thanks guys. Backdrops are of course down to personal taste, but I kinda like that one when using the bright coloured GlowIcons of 3.9.

There shouldn't be a major reason it doesn't work on OS4, so I'll check that out when I get a chance. The OS4 Workbench API is almost the same as 3.9's, but if it's opening a blank toolbar then the issue is more likely the image loading or gadget creation. The deadline for the Tool Jam is today though so last night's upload will be the main release for a little while. I wasn't too pushed about OS4 compatibility since Lister already exists and has much better navigation functions.

It uses the Workbench API introduced in OS 3.5, which was inherited then by every Workbench version after, including 4.x and 3.2. It does also use ARexx as some functions are only available through the ARexx interface, and some functions appear to be buggy and ARexx is used to work around them.

The plans for the future do include user-provided toolbar imagery, AISS support etc., and patching Intuition so that it can be opened automatically when Workbench opens a window.

Indeed. A.org was the first of the main ones to go downhill - I stopped hanging out there many years ago. AW.net followed a while later, and it's probably years since I've logged in there too. EAB has been pretty decent, though recently a few "characters" have shown up (including Vox), who were either sent away from other places or got bored with the declining troll fodder on those sites.

This sounds familiar, and I think it's down to a slight incompatibility between protocols. I can't remember the details, but I do think it's a known issue with smbfs. There are newer versions of smbfs floating around, but they might introduce other issues as they're a work in progress. Development was paused I believe while Olsen was working on OS 3.1.4 / 3.2 updates, so maybe we'll see it getting picked up again soon...

The monitor is just fine, and the EDID information is correctly read. The custom modes I'm looking for aren't anything special, e.g. 1920x1080 & 1280x800, and they're selected from the options available in the Monitors tab of Screenmodes. It looks like an issue with the driver trying to reinitialise the graphics card and failing, as it doesn't even get to the point of attempting to use the new resolution; no resolution switch is detected by the display.

A difference that may be relevant between this card and my previous one is that the old one was a 256MB card, whereas the new one is 128MB. I can't see that being an issue however - OS4 correctly detects the amount of available RAM, and the issue also happens when switching to smaller screenmodes.

Thanks for the reply. There is a database of available screenmodes kept by Amiga OS, I'm just not sure whether it's generated on the fly at boot or whether it's persistent somewhere and needs to be wiped.

I've already ruled out any interference from software at startup, and yeah, I'm pretty sure it's a software thing - it doesn't happen with the old card.

Interestingly, it worked for a short while when I restored the settings to automatically detect settings and used a different monitor to force it to show different choices, then switched back to my normal monitor. But the automatic detection doesn't show all the modes I want to use, and switching back to the tooltype method causes the freezes again. At that point, switching back to automatic detection does not resolve the issue, so it could just have been a coincidence.

Recently my Radeon 9250 started having weird glitches and corruption, so I swapped it out for another Radeon 9250. Glitches are gone and it seems to work fine, however when I change screenmodes in Screenmode preferences, the system locks up, with an almost completely blank grey screen but for the frozen mouse pointer and a few corrupted lines from the Workbench screen. I don't think this is a hardware issue because testing the screenmode works just fine, and other software opening different screenmodes also works just fine. This only happens when saving or using the screenmode for Workbench. If I save the mode and reboot, the saved mode works just fine too.

Any ideas? Is there possibly some confusion between the old display modes and the new perhaps, given that both cards have the same name but are physically different models? Is there a way to flush the screenmodes database? Renaming screenmodes.prefs resulted in a black screen after the splashscreen, so I needed to boot from the 4.1FE CD to restore the file.

@trgswe

There's nothing wrong with the current scheme - it combines the best of both worlds. I assumed there was a setting that I'd inadvertently modified since it replicated the behaviour of AsimCDFS or whatever, but it turned out to be a hardware quirk of some sort.

Do you have a specific use case that you have found where you need to use these qualifiers?

Yeah, I know it had the CD audio tracks as files, but for me at least, they were presented alongside the data files on mixed CDs. Good information on the shortcuts, thanks! My problem however was the data portion being suppressed, even though no keys were being held. Interestingly, by switching my drive settings from UDMA to best PIO (using an sii0680 board), the problem went away. I'll put this down as one of those A1-XE quirks for now I guess.

Thanks :)

I've just noticed that audio CDs are showing up as a volume with tracks presented as audio files that I can access from Workbench. This is a feature that I remember from one of the CD filesystems back in the day, but I don't remember when this what introduced on OS4. It's a nice feature... but it appears to be preventing the data portion of CDs from being mounted, meaning I can no longer see any data files on any CDs.

Where do I go to revert this setting? I don't use CDs all that much so I can't tell when this started happening, but other than Enhancer 1.5 and any official updates, this is a very plain OS4.1FE setup.

Cool, guess I'll give the latest build a try so :)

I don't suppose anyone's gone ahead and built a version of YAM without the timeout, no?

SimpleMail works with GMail if you set GMail to use less secure authentication. However, both the OS3 and OS4 versions crash for me while syncing the inbox for the first time. It's potentially a size-related thing, or maybe a particular mail is malformed, but it's essentially unusable for me. Worth trying though in case it works better with your mail setup.

@Steady
Quote:
Just to clear up: the RAM needed by FFS in this fashion is only needed for partition validation, and is not consumed when validation is not happening. Validation is only required as part of the formatting procedure, or when a volume bitmap becomes invalid, e.g. after an interrupted write operation like turning off power while saving.

The RAM required for validation is directly related to the number of blocks, not the partition size, so increasing the block size (which decreases the number of blocks in a given partition) reduces the RAM requirement.

@jPV
Quote:
Indeed, the main memory usage comes from the buffers. With a larger blocksize, the number of buffers can be reduced without significantly impacting performance since ultimately the same amount of data is cached, but regardless of the size, you get to an area of diminishing returns between 100-200 buffers; adding more buffers beyond that produces a more or less undetectable difference in performance, so is essentially a waste of RAM.

Quote:
As you point out, PFS and SFS both recommend (or even enforce) a 512-byte block size, but FFS does have good reasons for using a larger block size.

Quote:
I actually have the opposite experience, and conducted extensive testing a few years back on many different combinations. Everyday use cases (boot time, copying large directories containing mixtures of large and small sized files, unarchiving and archiving mixed files, seeking large files) showed dramatic improvements in speed with block size increases. These improvements started levelling out around 8192 bytes, with some improvements seen going to 16384, and no significant improvement going to 32768. With all block sizes, the difference made by buffers was less noticeable once you reached a number equivalent to around 100 512-byte buffers (around 50kB of RAM), and practically no difference at all at around 100kB of RAM.

An additional advantage of larger blocksizes comes down to the use of modern flash-based drives, which have an internal block size of 4kB. While they still support 512-byte operations for compatibility, writing in particular can be significantly sped up when a 4kB block size is used.

Yeah, I tend to use PPaint for working on lots of images that are smaller than the screenmode - it's a bit clumsy to cut the image as a brush to save it, but it works well for game graphics work. Other options that are more colour-orientated and less indexed palette-orientated are TVPaint and ArtEffect, both of which work well on OS4 and allow an arbitrary canvas size.