Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
57 user(s) are online (34 user(s) are browsing Forums)

Members: 0
Guests: 57

more...

Headlines

Forum Index


Board index » All Posts (Daedalus)




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


Re: need help my A4000 won't start with new A4000 ATX PSU adapter
Not too shy to talk
Not too shy to talk


Ripple on the 12V rail is of no real concern to an Amiga, and certainly won't stop the PSU turning on. All the Amiga's logic runs off the 5V rail, which is where you want the low ripple.

As for the original issue from a year ago, those adaptors are pretty simple - there's not a lot that can go wrong with them. If it's turning on the PSU without being connected to the A4000, then it's doing its limited job correctly. The issue is between the PSU and the A4000 then, and as pointed out above, ATX PSUs aren't particularly well suited to Amiga use. The most common issue is that it doesn't draw enough current to regulate properly, in which case it should immediately shut down (though some poor quality units will continue to output out-of-spec power). But that's not the case if the PSU turns on with no load. In this case it's probably more likely to be an imbalance in the load, where the output of the PSU isn't connected how it expects. Perhaps some of the ground or power rail lines aren't connected to the rest, confusing it, or perhaps it requires the 12V load to be similar to or greater than the 5V load. This could be the "sense" issue mentioned.

Go to top


Re: Problems with AmigaInputAnywhere
Not too shy to talk
Not too shy to talk


@LiveForIt

Awesome, thanks very much for that! I'll check it out at some point when I have time.

Go to top


Re: Problems with AmigaInputAnywhere
Not too shy to talk
Not too shy to talk


@LiveForIt

Quote:
Amiga Input anywhere is reading events it does not poke the device memory, so there is no rick here.

Fair enough, in which case it would appear that AmigaInput itself is misaligning the struct contents. That would mean the risk is still there of course, just not directly from your code. In that case, perhaps polling it once per frame (the old-fashioned Amiga way of doing things) would be a better option all round? At least supported controllers would be properly recognised.

Quote:
But it wont be atomic, the user might unplug it between checkng if its connected and AIN_GetEvent,

player can also unplug it while program is event loop, reading the queue

Yes, that's true, but the time between the check and the event fetch should be very small compared to the rest of the game loop, which minimises the risk. As for the event list, you can check for connection before each read of the event, or copy the event struct contents to a dummy struct so that each check in the event loop isn't reading the event again.

Quote:
Amiga Input is broken but I agree I can make my code safer maybe.

Yep, it is broken, but a lot can be done to avoid the issues or greatly reduce the risk of them occurring, rather than just shrugging them off.

Go to top


Re: Problems with AmigaInputAnywhere
Not too shy to talk
Not too shy to talk


@LiveForIt

Quote:
Looked at the code, I do not query offsets, for buttons etc.

You *must* query for offsets for every controller. The struct that contains the data from all the controller's inputs varies in size depending on the number of axes, hats and buttons it has. Without querying it, you're assuming a certain layout, which is probably why your buttons are getting swapped and why I have buttons that correspond to axes on my controller. It's additionally risky if the controller is simpler, because then you could be accessing data beyond the end of the struct.

Quote:
I was always going rewrite it from scratch if where do more on AmigaInputAnywhere.

That would be nice, but I've started work on my own fixed alternative anyway that's implemented as a commodity.

Quote:
There is no disconnected event type or device event type or anything like that in my SDK.

True, it's not an event you're looking for. But to read an event, you need a valid context, so you need to be sure your device is connected before you use GetEvent()

Quote:
I can query the device by intervals, using AIN_Query() this command takes the context, so if the context is deleted, it will crash...

True, but you don't query a device if you don't have context so that should never happen. Once you find out that the device is disconnected (while you still have context), you drop the context and don't carry out any more reading of the device. Instead, you start from scratch with a new context, repeating if necessary until a suitable device is found.

Quote:
Well i obtained the device, my program owns the device, until my program release the device.

Which is fine in theory, but in reality your program doesn't own the device, the user does. And the user can take away that device no matter what your program thinks.

Quote:
I created the context, its my job delete the context.
the context might not be valid,
but it should safe to use it.

I agree, any accesses when the context is no longer valid should return an error code to that effect so that you know it's no longer valid (and out-of-context queries should not be forwarded to the USB stack), but unfortunately this isn't the case. As with obtaining the device, the context is at the mercy of the user, not just your program. If the user changes the context, it can't be valid any longer and must be refreshed.

Quote:
I'm not checking the signal before AIN_GetEvent(...)
this might be the major mistake in the code.

I guess this is becouse its not using GetMsg( MsgPort )..

This might be a good idea, though it shouldn't be necessary. What might also be a good thing to do, is to query if the controller is connected before AIN_GetEvent().

Go to top


Re: Problems with AmigaInputAnyware
Not too shy to talk
Not too shy to talk


Okay, this evening I've done a little feasibility work for writing my own version of an AmigaInputAnyware-type-program. From what I've done so far, I can tell you that:

- It looks like AmigaInputAnyware is reading the button offsets incorrectly for some controllers, meaning button 4 corresponds to button 1, buttons 1-3 correspond to various hat/axis offsets, and everything else seems to be shifted by the same amount. Possibly some sort of alignment bug in the struct, or assumptions made about the number of hats/axes? Anyway, I can read the controller inputs without issues so it's not the controller or AmigaInput itself. This explains why my mappings would never work in AmigaInputAnyware with that controller but did with a previous one.

- AmigaInput will tell you if a controller is disconnected, but will crash if you try to read a disconnected controller after reconnecting it, since the context is no longer valid. Therefore, you can avoid the crashes if you immediately dump the context as soon as the controller is disconnected and re-initialise it from scratch when the controller is reconnected. Once you do that, you can disconnect and reconnect the controller as much as you like and still read it without issues. The additional problem is that if you're polling the device instead of using signals, you need to check the device is connected before any attempted read of it.

Go to top


Re: Problems with AmigaInputAnyware
Not too shy to talk
Not too shy to talk


Or, if you don't have the time or means to fix AmigaInputAnyware, how about sharing the source for it so that I or someone else might be able to fix it for you? I don't have a lot of time for Amiga-related projects, so it would save me having to write my own alternative from scratch...

Go to top


Re: Problems with AmigaInputAnyware
Not too shy to talk
Not too shy to talk


Yes, I'm aware of that issue, but if you read my posts, you'll see that that's not the issue I'm talking about. The issue I'm talking about here is specifically to do with AmigaInputAnyware not mapping inputs properly.

Go to top


Re: Problems with AmigaInputAnyware
Not too shy to talk
Not too shy to talk


So what's the exact nature of the bug then? I don't understand how AmigaInput can prevent AmigaInputAnyware from remapping keys, when it works fine with default keys...

Go to top



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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project