Who's Online |
23 user(s) are online ( 13 user(s) are browsing Forums)
Members: 0
Guests: 23
more...
|
|
|
|
|
Re: Replace file with different suffix
|
|
Just popping in 
|
@orgin
I notice that if I click "Show content" for either of those files I get the error message "No content viewer is available for this file type at this time." Is that something that can be fixed?
|
|
|
|
|
|
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
|
|
Just popping in
|
@pjs Quote: I just don't recall if there was anything like the OS4
requestchoice/requeststring/requestfile commands in the end
on OS3. Both RequestChoice and RequestFile are documented in the printed OS 3.1 DOS manual, so those two go back at least that far. No RequestString, though.
|
|
|
|
|
|
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
|
|
Just popping in
|
@FlynnTheAvatar
Checking for a value less than zero will reject any address where the MSb is set, and not just -1. Strictly speaking, only the value -1 is reserved; other values with the MSb set might be legitimate addresses.
In practice, I think OS4 reserves addresses in the upper 2 GB range for uses other than general purpose RAM, so pr_WindowPtr will never actually point there. Still, while checking for a value less than zero is fine for a patch to an existing binary, if you're modifying the source why not do it right and only reject NULL and -1? That way you're not depending on something that might change some day.
|
|
|
|
|
|
Re: Strange crash with ARexx and RexxReqTools on Amiga OS4
|
|
Just popping in
|
@FlynnTheAvatar Quote: Anybody has any idea why the pragma call is causing issues? PRAGMA('W','N') would appear to set the pr_WindowPtr field in the Process struct for ARexx to -1, which is how you tell DOS to not put up any requesters for your program. pr_WindowPtr normally points to a window whose screen DOS should open its requesters on, or is NULL if it should use the Workbench screen. It looks like something in either reqtools.library or rexxreqtools.library doesn't check for a pr_WindowPtr of -1 and attempts to use it as the address of a window, which of course causes a crash. Perhaps reqtools is trying to open the requester on the same screen that DOS would use, and doesn't check for the special "don't open any requesters" value.
|
|
|
|
|
|
Re: How to made from shell commands some directory to be a default one while being in the other one ?
|
Posted on: 2024/11/5 7:11
#5
|
Just popping in
|
@nbache Quote: I'm not sure if this is the solution you want, but in S:Shell there is a small script called PCD which makes a CD, but remembers the dir you leave so you can get back to it afterwards. PCD is kind of a holdover from OS3. OS4 also has the built-in PushCD and PopCD commands which do the same thing, but probably more elegantly.
|
|
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 2024/9/27 4:34
#6
|
Just popping in
|
Quote: Maybe use Snoopy to see what files are actually being accessed? If there's a path problem of some sort, that might provide some clues.
|
|
|
|
|
|
Re: Creating an AmigaOS4 library
|
Posted on: 2024/9/21 3:29
#7
|
Just popping in
|
Quote: The idltool writes dummy _manager_Obtain and _manager_Release function which contains embedded assembler.
That's interesting. Every example library source I've looked at, including the skeleton library that comes with the clib2 source, the library code generated by Enhancer's LDCK, and apparently even older versions of IDLTool, generate this code (or something essentially the same) for _manager_Obtain():
STATIC uint32 _manager_Obtain(struct LibraryManagerInterface *Self)
{
return ++Self->Data.RefCount;
}
That's not atomic, though the window of vulnerability is very small (just a few instructions). To get it to malfunction you'd have to have two different programs manipulating the interface at exactly the same time, and then have a task switch occur during those few instructions. That would be very difficult to arrange even if you were trying, let alone having it happen by chance. Which is fortunate, as there would appear to be a lot of libraries out there that use this code.
|
|
|
|
|
|
Re: 2024-Aug/Sept-Gaming Competition- Shmupacabra
|
Posted on: 2024/8/7 4:17
#8
|
Just popping in
|
@Hypex Quote: For some reason, with some images you have to right-click on the thumbnail and then select "Open Image in New Tab" to see the full-size image. If you just click on the thumbnail you get the home page, not the page with the image.
|
|
|
|
|
|
Re: A1222 Freezes when writing to the RAM DISK
|
Posted on: 2024/6/11 7:09
#9
|
Just popping in
|
@dfstudios Quote: Given that the copy function works okay in the Shell (ignoring the ran out of space freezing issue) and not with the Workbench to me points to an issue with the Workbench's copy function.
You're probably using AsyncWB, since that seems to be the default for OS4. Just for kicks, you might try disabling it and trying the Workbench copy again.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2024/4/29 7:23
#10
|
Just popping in
|
@kas1e Quote:
ok# 16 config-l@
ok# config-l@
ok# .
646011AB
ok#
I think you should only execute config-l@ once, not twice. When you execute it the second time it takes the value that the first execution left on the stack (the result you're trying to see) as the address to report on, which is not what you want (and may be why you're getting strange results). You should just do:
16 config-l@ .
Quote: (Also realised where did you get 16 for BAR address. Forth is hex by default do dec# 16 is wriiten as 10 in Forth.) Good point. Forth itself is decimal by default, but OpenFirmware may not be. The value '646011AB' is clearly in hex, so the number '16' is probably taken as hex as well. You could try something like:
20 1 - .
If you get 13 (the value 19 in hex) then the numbers are being interpreted as decimal. If you get 1F then they're being interpreted as hex.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2024/4/28 3:09
#11
|
Just popping in
|
@kas1e I don't know anything about OpenFirmware, but I did program the Amiga in Multi-Forth for a time way back when, and still remember some things about Forth. Quote: I mean, what "config-addr -- data" mean...? "(config-addr -- data)" is a Forth stack use diagram. It means that the word 'config-l@' expects to see 'config-addr' on the top of the stack when it is executed, and it leaves behind 'data' on the top of the stack when it has finished executing. Typing a number alone adds that number to the top of the stack. So the correct sequence would be "16 config-l@", which puts the value 16 (the "config-addr") on the stack, then executes config-l@. In Forth you would then type a single period ('.') to print the top value on the stack, which would be whatever config-l@ left there (the "data"). But maybe that's not required in OpenFirmware.
|
|
|
|
|
|
Re: Sam460le - new user experience
|
Posted on: 2024/1/14 6:51
#12
|
Just popping in
|
Quote: Once the snow is put back in storage the site gets a lot lighter CPU-wise . Now that snow season is over, opening two Amigans tabs with Odyssey shows 5 - 15% CPU use, according to CPUInfo. Tequila shows less than 5%, and almost all of that is stuff other than Odyssey.
|
|
|
|
|
|
Re: Sam460le - new user experience
|
Posted on: 2024/1/11 7:19
#13
|
Just popping in
|
@nbache Quote: ...when I then click in the displayed graph, it falls down to where it should be. Hmm, you're right- I never noticed that before. Though it seems like CPUInfo gets less accurate when you click on it, not more. Tequila reports that Odyssey itself uses around 40 - 45% CPU when displaying two Amigans tabs with falling snow. Add in the other tasks running, and the total CPU usage is around 45 - 55%, which is the same as what CPUInfo reports before I click on it. After clicking on the CPUInfo graph it shows the total CPU use dropping to around 5 - 15%, while Tequila shows no change. The effect is so pronounced it's got to be intentional, but I've no idea what it's supposed to be doing (the docs that come with it say nothing about this). Whatever it is, it doesn't seem to accurately reflect total CPU use anymore. And strangely, if I open a third tab in Odyssey CPUInfo goes back to displaying the correct CPU usage, and it remains correct even if I close the third tab again. I'm getting off topic here, so I'll just note in closing that it seems best to avoid clicking the CPUInfo docky. And indeed, the falling snow does represent a significant CPU load.
|
|
|
|
|
|
Re: Sam460le - new user experience
|
Posted on: 2024/1/9 3:07
#14
|
Just popping in
|
@amiganuts Quote: Using Odyessy on my SAM the CPU is pegged at 98-100% constantly and on my X5040 it 70-100% constantly. The falling snow decoration that's active around Christmas is a real CPU-sucker. I get 45 - 55% CPU use with Odyssey on my X1000 (using CPUInfo). Once the snow is put back in storage the site gets a lot lighter CPU-wise.
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/14 8:05
#15
|
Just popping in
|
@kas1e Quote: And can't those "titles" be changed by GUI/workbench prefs by the way ?
You can change the Workbench screen title, but I don't think you can change the window titles. Quote: -- added check on "Amiga+e" window (AsynWB - texinput process)
Remember that AsyncWB is optional, so some users may not be using it. Quote: Imho we can keep filler for: 1)dbl-click 2). "Open Volumes" 3). "Open". But for 3 others like "amiga+e / wbrun" , "shell/wbrun" and "filler's open wb folder" - original WB window.
That seems reasonable to me. "Amiga+e/wbrun" and "shell/wbrun" are kind of hardcore and are likely only used by those who have a specific need for a Workbench window and who could just as easily run Filer if that's what they really wanted, and the whole point of Filer's "Workbench folder" is to open a Workbench window in addition to the Filer. The first three are more for day-to-day use and are the ones that someone who runs a utility like WB2Filer would expect to be patched. BTW, ContextMenus also has "Execute command" and "Open a drawer" options, as well as "Open" for both disks and drawers. Some quick testing with WB2Filer_07 shows that ContextMenus (including "Execute command" with wbrun) works like double-clicking; disks get a Filer, while drawers get a Workbench window. Just noticed: When WB2Filer is running, switching the Workbench background from a backdrop window to a regular window and then back again causes a crash (a DSI in the OpenWindowTagList() patch). Perhaps because there's no window title?
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/13 7:29
#16
|
Just popping in
|
@nbache Quote: is that a problem you guys haven't considered yet?
I don't think it will be a problem. We're looking for a task called "Workbench", not a window title or a disk name, so there shouldn't be any confusion.
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/13 7:09
#17
|
Just popping in
|
@joerg Quote: That's no problem since drawers only have the drawer name as window title but disks additionally "x% full, y GB free, z GB in use".
That occurred to me as well shortly after I posted that reply. If the window title doesn't have the extra verbiage then it's a drawer, so just pass it on to Original_OpenWindowTagList() to become a Workbench window. If it does have the extra verbiage then extract the name, append a colon, and pass it to Filer. That's it. No need for the selected icon list or which_icon. The devil is in the details though, and as you noted it won't be simple to reliably extract the name from the window title in all cases. And it's moot if Workbench doesn't use WA_Title to set the initial window title. So I guess it's over to @kas1e to test that.
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/13 3:01
#18
|
Just popping in
|
@kas1e Quote: Btw, if we can find how Workbench checking on "if disk already opened on screen", we can then just avoid re-run of filer, and making it active instead.
I imagine Workbench has internal data that it uses to keep track of what windows it's opened, so if you try to open the same window again it just activates the existng window. We don't have access to that data, so there's no easy way for us to duplicate that functionality. Of course, if we open a Filer instead and pass NULL back to Workbench then it thinks there is no window open for that disk, so it will try to open it again if you ask it to.
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/13 2:51
#19
|
Just popping in
|
@kas1e Quote: So, firstly good thing: this "UserPort->mp_SigTask" for sure good one!
Yes, it looks like we can pretty reliably detect whether we want to hijack the OpenWindowTagList() call and open a Filer instead, or whether we want to let the window open normally. The problem is still in knowing which disk we want Filer to open. We still have to assume that the window is being opened for one of the selected icons, and we know that's not always the case. What we really need is a way to know what disk or drawer Workbench is trying to open the window for, and we don't have any good way to learn that. Some clues might come from the WA_Title tag of the window to be opened, if Workbench sets the title that way and doesn't wait until the window is already open to set the title. But even if the tag is present, the window's title has a number of obstructions to easy use: - There's bunch of other stuff in the title besides the name - The trailing colon is removed from the name, so we can't readily tell disks apart from drawers (someone could have a drawer named "Work") - If it is a disk, the name is that of the volume and not the device ("RAM Disk" and not "RAM:"), and the volume name can be set to anything by the user - The path is stripped from the name; you could have more than one drawer with the same name that differ only in the path, and we can't tell them apart The last one wouldn't matter if we could reliably tell disks apart from drawers, since we don't want to hijack drawer windows. But it's certainly possible that someone could have a drawer named "RAM Disk" somewhere, and based on the window title we couldn't tell that apart from the actual RAM disk.
|
|
|
|
|
|
Re: wb2filer v0.6
|
Posted on: 2023/12/12 7:07
#20
|
Just popping in
|
@joerg Quote: Additional things you could check in Scout and if it's usable add the check(s) to wb2filer:
Thanks for the ideas. The title of the Workbench backdrop window is unset, so no joy there. However, the window's UserPort's mp_SigTask is indeed the Workbench task. So perhaps that's the way to go- if the active window's UserPort->mp_SigTask is the Workbench task (ln_Name is "Workbench") then the new Workbench window is likely being opened due to some user interaction with Workbench, and not because of some other program asking Workbench to open the window. That doesn't solve all the problems -- we're still assuming that the window being opened is for one of the currently selected icons, and that's not always the case -- but it's one more thing that can be checked in an attempt to determine what's going on.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
