Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
36 user(s) are online (31 user(s) are browsing Forums)

Members: 0
Guests: 36

more...

Support us!

Headlines

Forum Index


Board index » All Posts (Daedalus)




Re: Lame intuition/reaction based questions
Not too shy to talk
Not too shy to talk


@Ami603Quote:
Ami603 wrote:@kas1e:

have a look at workbench.library/WhichWorkbenchObject
with the tag WBOBJA_DrawerPath

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

@jabiruloQuote:
jabirulo wrote:@Daedalus

<offtopic>
BTW when do you plan another codign stream?
</offtopic>

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

Go to top


Re: Lame intuition/reaction based questions
Not too shy to talk
Not too shy to talk


@kas1eQuote:
kas1e wrote:
As one more idea .. but not very "system" ones imho :) Anwyay, thanks for idea..

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

Quote:
But why you need to check dimensions ? Just for sake of double-checking ?

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

Go to top


Re: Lame intuition/reaction based questions
Not too shy to talk
Not too shy to talk


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...

Go to top


Re: Lame intuition/reaction based questions
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: DrawerGenie for AOS4?
Not too shy to talk
Not too shy to talk


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?

Go to top


Re: DrawerGenie for AOS4?
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: DrawerGenie for AOS4?
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: Amigaworld.net what is going on over there?
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: SMBFS / SMBMOUNTER Bug
Not too shy to talk
Not too shy to talk


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...

Go to top


Re: Lockup When Changing Screenmodes
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: Lockup When Changing Screenmodes
Not too shy to talk
Not too shy to talk


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.

Go to top


Lockup When Changing Screenmodes
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: CD Audio Tracks as Files
Not too shy to talk
Not too shy to talk


@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?

Go to top


Re: CD Audio Tracks as Files
Not too shy to talk
Not too shy to talk


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 :)

Go to top


CD Audio Tracks as Files
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: Please someone remove YAM's time contraint
Not too shy to talk
Not too shy to talk


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

Go to top


Re: Please someone remove YAM's time contraint
Not too shy to talk
Not too shy to talk


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

Go to top


Re: eMail app
Not too shy to talk
Not too shy to talk


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.

Go to top


Re: AmigaOS 3.2 for all Classic Amigas released and available
Not too shy to talk
Not too shy to talk


@Steady
Quote:
As to your memory issue, a FFS partition using 512 byte blocks (usual set up) requires about 1MB of memory per GB from my understanding. If you have a 2GB partition then that explains about 2MB or RAM being chewed up. Try 2KB or even 4KB blocks and see what that does for you ... but read the FAQ to verify and catch anything I may have forgotten or misremembered here!

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:
Isn't it mostly Buffers * Blocksize in this case? On NG machines people might use buffers as hundreds or even thousands, because memory isn't an issue there, but on classics I'd stay somewhere like 128 or so.

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:
And keep blocksize as 512 if there isn't a good reason and memory to make it bigger.

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:
In my opinion buffers have actually bigger impact on speed with many real world operations (like when deleting/scanning files) than the blocksize. So if you don't have that much memory, I would use small blocksize, but at least moderate amount of buffers. IIRC HDToolbox on 3.x had default value of 60 or 80, or something like that under 100, for buffers. IIRC SFS documentation recommended to use 128 buffers or so, and I've felt that it's quite good to have it over 100 or couple hundreds on classics. On NG I personally have raised buffers to 4096 on partitions I have lots of small files and I need to delete large amounts of files regularly, and 2048 on other partitions. It really shows in speed when you delete, for example, a system backup directory.

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.

Go to top


Re: Personal Paint on X5000 need 256x192 but No Such Option
Not too shy to talk
Not too shy to talk


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.

Go to top



TopTop
(1) 2 3 4 ... 15 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project