Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
65 user(s) are online (39 user(s) are browsing Forums)

Members: 0
Guests: 65

more...

Headlines
Recent files - OS4Depot - Your one stop for AmigaOS4 files

Forum Index

Board index » All Posts (Daedalus)


(1) 2 3 4 ... 14 »


Daedalus
Re: Amigaworld.net what is going on over there?
Posted on: 2022/11/17 14:21    #1
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
Topic | Forum


Daedalus
Re: SMBFS / SMBMOUNTER Bug
Posted on: 2022/2/24 12:06    #2
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
Topic | Forum


Daedalus
Re: Lockup When Changing Screenmodes
Posted on: 2022/2/18 15:30    #3
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
Topic | Forum


Daedalus
Re: Lockup When Changing Screenmodes
Posted on: 2022/2/18 13:32    #4
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
Topic | Forum


Daedalus
Lockup When Changing Screenmodes
Posted on: 2022/2/18 12:38    #5
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
Topic | Forum


Daedalus
Re: CD Audio Tracks as Files
Posted on: 2022/2/12 22:09    #6
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
Topic | Forum


Daedalus
Re: CD Audio Tracks as Files
Posted on: 2022/2/10 10:13    #7
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
Topic | Forum


Daedalus
CD Audio Tracks as Files
Posted on: 2022/2/9 13:47    #8
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
Topic | Forum


Daedalus
Re: Please someone remove YAM's time contraint
Posted on: 2021/10/26 22:02    #9
Not too shy to talk
Not too shy to talk
Cool, guess I'll give the latest build a try so :)
Go to top
Topic | Forum


Daedalus
Re: Please someone remove YAM's time contraint
Posted on: 2021/10/26 11:33    #10
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
Topic | Forum


Daedalus
Re: eMail app
Posted on: 2021/6/28 19:16    #11
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
Topic | Forum


Daedalus
Re: AmigaOS 3.2 for all Classic Amigas released and available
Posted on: 2021/6/17 12:26    #12
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
Topic | Forum


Daedalus
Re: Personal Paint on X5000 need 256x192 but No Such Option
Posted on: 2021/2/23 10:21    #13
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
Topic | Forum


Daedalus
Re: need help my A4000 won't start with new A4000 ATX PSU adapter
Posted on: 2020/7/29 14:45    #14
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnywhere
Posted on: 2020/2/18 11:13    #15
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnywhere
Posted on: 2020/2/15 20:06    #16
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnywhere
Posted on: 2020/2/15 14:29    #17
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnyware
Posted on: 2020/2/13 23:21    #18
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnyware
Posted on: 2020/2/11 15:01    #19
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
Topic | Forum


Daedalus
Re: Problems with AmigaInputAnyware
Posted on: 2020/2/2 14:08    #20
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
Topic | Forum



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



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project