Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

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

Members: 1
Guests: 38

Lio, more...

Headlines

Forum Index


Board index » All Posts (msteed)




Re: Different AmigaOS4 machines boot times: X1000,X5000,Sam460 and Peg2
Just popping in
Just popping in


@kas1e

Quote:
Those of you who have x1000 instead of x5000, can meassure the full loading from power on to working workbench as well as meassuer just a time between white screen (when amigaboot starting load modules) and the working system ?

On my X1000 I get 49 seconds from power on to working system, which includes a five second timeout for the CFE boot menu. It takes 32 seconds from power on to where the progress bar first appears as amigaboot.of starts loading modules (including that five second menu timeout), and another 17 seconds from there to a full working system. That's with the standard (not debug) kernel and a mechanical HDD formatted with SFS2.

Go to top


Re: x1000 documentation and other x1000 related questions
Just popping in
Just popping in


@kas1e

Quote:
Are you saying that you never-ever have this "[HELO][DRAM]" stop booting after reset of x1000 ? I just have this issue, and Raziel too, and it sounds like everyone have it ?

I vaguely remember seeing that at some point in the past (perhaps when I was having boot problems due to a depleted backup battery), but in normal use I never have that problem.

Go to top


Re: SDK 54.16
Just popping in
Just popping in


@walkero

Quote:
Now, you mentioned that it is not documented anywhere, and you are right about it.

That's not entirely true. If you look at adtools.lha on OS4Depot, which contains GCC 8.3.0, you'll find in the share/info directory the file gcc.info, which has been edited to document the Amiga-specific alterations to GCC, including -athread. This information apparently never made it to any of the PDF versions of the GCC documentation.

Go to top


Re: libjpeg.so problem
Just popping in
Just popping in


@kas1e

I got a crash as well, a DSI. The redzone was not damaged, but the stack pointer was out of bounds. Looks like an infinite recursion leading to a stack overflow, with the stack full of two alternating addresses in elf.library.

My libjpeg.so is the same size as yours, and I got the same crash even if I used the FILE switch.

So no, it's not just you.

Go to top


Re: Old AmigaOS 4 versions and new software
Just popping in
Just popping in


@walkero

As a user, I don't always immediately upgrade to the latest version of something, as for every bug it fixes and new feature it adds, it also may break something or add new bugs. For example, I stayed with OS 4.1.6 for some time after FE was released, because the initial incarnation of FE was rather buggy. It was only after Update 1 came out that I switched to FE.

As a developer, I try to keep users like me in mind when writing software, and generally make some attempt at supporting older versions of the OS/libraries/MUI/whatever. I try to avoid using conditional code to add backwards compatibility, as it makes the code hard to read and maintain. But if I can use a DOS function that only supports 32-bit file sizes, for example, when I know that my application will never generate files large enough for that to be a problem, then why not? Likewise, does that gee-whiz new feature really add value to the user, or would the program be just as useful -- though maybe less sparkly -- without it?

If there's a compelling reason to use the latest version of something (for example, it fixed a bug that my application can't reasonably work around, or it adds a useful new feature that it's not practical to reproduce some other way) then I'll certainly do so. But I'll also at least look at whether I can work around the bug, or if I really need that new feature.

Balanced against all that is the stark reality that there are far more Amiga programs that need to be written than there are developers to write them, so whatever makes it most efficient (and enjoyable, since most of us are not in it for the money) to work on Amiga software is the way to go. If for any given programmer that means only using/testing with the very latest version of everything, then so be it. But please do publicize the requirements so no one will be caught by surprise, and have the program display a helpful error message and safely quit if it encounters an outdated version of something, rather than crashing or not working properly.

Go to top


Re: New Sam460cr boards will hit the road soon!
Just popping in
Just popping in


@kas1e

Quote:
If cpu is hot, then any thermo-glue may be fluid after a while and the fan slides.

That sounds like heatsink compound, not thermal glue. Heatsink compound is a silicone paste that helps heat transfer between the CPU and the heatsink by filling any tiny gaps between the two. It intentionally gets softer when it's hot. It's not intended to hold anything in place, and is only used when you have some other means of securing the heatsink.

If you do end up with a stick-on or glue-on heatsink you'll want to remove the heatsink compound first, as nothing is going to stick to it.

Go to top


Re: Amigaworld.net what is going on over there?
Just popping in
Just popping in


@trixie

Quote:
There's no use posting there any more, or reading it for that matter.

The 'reading' part is not entirely true. There's an occasional worthwhile posting (like Robert Bernardo's Amiwest videos), so I do find myself checking in from time to time, just in case.

Go to top


Re: Newbie questions, SAS/C OS3 code to OS4 gcc conversion
Just popping in
Just popping in


@Mlehto

Quote:
#define __USE_SYSBASE 1 is brobably SAS/C-only. Wjhat it does and what it needs on new gcc env?

That tells the SAS/C code to get the address of ExecBase from a global variable called SysBase, instead of getting it by reading address 4. GCC always uses SysBase, so this definition is not needed (but it does no harm if present).

Quote:
setpri.c:98:26: error: 'struct Library' has no member named 'TaskWait'
tasklist[0] = &SysBase->TaskWait;
^~

By default the OS4 includes define SysBase as a generic pointer to struct Library, rather than what it actually is, a pointer to struct ExecBase. That allows calls like OpenLibrary() and CloseLibrary() to work without needing to cast to and from a pointer to whatever that library's base is called.

But of course struct Library has no TaskWait and TaskReady fields, so you get errors. One way to fix this is to cast SysBase to a pointer to ExecBase before referencing those fields. Another way is to add the definition

#define __USE_BASETYPE__

before including anything; that causes SysBase to be defined as pointing to struct ExecBase, which will let the code reference ExecBase fields like TaskWait and TaskReady without a cast.

Note that those two fields of ExecBase are marked as obsolete, so they may not do anything useful even after you get the code to compile. There are enough differences between OS4 and OS3 that OS3 code that pokes around in ExecBase is unlikely to work properly under OS4.

Quote:
Reading general c-manual is bit like eat dry wood or something.

Some people feel that same way about writing code.

Go to top


Re: Porting to AmigaOS4 thread
Just popping in
Just popping in


@Capehill

Quote:
It seems to me that you need to cast TimerBase like:

ITimer = (struct TimerIFace *)GetInterface((struct Library *)TimerBase, "main", 1, NULL);

Better to make TimerBase a library pointer, instead of a device pointer; that way no casting is required. It's also cleaner that way, since the purpose of obtaining the TimerBase from the device is to be able to treat it like a library.


Edited by msteed on 2022/9/29 3:44:48
Go to top


Re: Porting to AmigaOS4 thread
Just popping in
Just popping in


@Raziel

Quote:
> In your case, you have to migrate the code to use the now official method to create an IORequest

argh, ok, so nothing i could do...thank you for checking

If you want to get rid of all the warnings, just use "-Wno-deprecated-declarations".

Go to top


Re: AmigaKIT/AEON AmiSphereServer is crashing...
Just popping in
Just popping in


@LiveForIt

For what it's worth, Updater runs fine on my X1000 with the latest newlib. The first time I tried it it took a long time to fetch the update data (a couple of minutes), but every try since then has only taken a short time, as normal. So most likely just an Internet/server glitch the first time.

Go to top


Re: What
Just popping in
Just popping in


@nbache

Quote:
As for SYS:Documentation/ReleaseInfo, it is obsolete. It used to be a directory where AmiUpdate put some short descriptions, but that idea was (AFAIK) abandoned. But this dir has never been the place for proper ReleaseNotes files.

Good to know-- thanks! Since I install manually I never picked that up, and have continued to put release notes in ReleaseInfo. I'll just rename that directory to ReleaseNotes and I should be good.

Update: Since I've renamed SYS:Documentation/ReleaseInfo to SYS:Documentation/ReleaseNotes I notice that the WB Help tool now allows the release notes to be displayed, in addition to the help documentation. Another feature I didn't know existed, though it's somewhat documented on the wiki (which mentions release notes, but doesn't say where it looks for them).


Edited by msteed on 2022/10/4 7:21:51
Go to top


Re: What
Just popping in
Just popping in


@rjd324

Quote:
I got my update using the AmiSphere... thing.

Same here, using AmiUpdate.

Quote:
There was also zero release notes, which would have been nice.

There actually are release notes. Try looking in SYS:Documentation/ReleaseNotes, which is where the installer puts them. If you don't have a directory by that name then the release notes are not installed. I think the standard location for release notes is SYS:Documentation/ReleaseInfo, so maybe that's the problem.

Quote:
Only the shared library was updated.

In addition to the new linker libraries (which yes, are there), there are a bunch of updated newlib include files in the update as well (you should see some includes with 2021 dates). I'm wondering if something went wrong with your install (assuming you used the auto-install option), and your SDK didn't get updated properly or at all.

The SDK won't be updated if you don't have an SDK: assign, but I assume you do have that. I'm not sure what else could have gone wrong. This is the relevant portion of the AutoInstall script:

C:Assign >NILSDKEXISTS
IF NOT WARN
   C
:Delete SDK:newlib ALL QUIET
   C
:Copy BUFFER 0 CLONE SDK/#? SDK: ALL QUIET
   
SDK:C/sh makelinks
ENDIF

(makelinks is a shell script that re-establishes the softlinks that were deleted by Delete ALL.)

I always install everything manually, because I never trust install scripts to do the proper thing across all the different system setups out there. If you've still got the update archive try looking at it with LHA or UnArc and see if some of the things you're missing aren't in there.

Go to top


Re: Endianes, again
Just popping in
Just popping in


@kas1e

Quote:
Hi,can you show how's MAKE_IRR_ID() defined?

I'm with jabirulo-- I suspect that MAKE_IRR_ID() is designed for a little-endian system, and so swaps the order of the arguments compared to something like MAKE_ID() that's designed for a big-endian system.

Quote:
Should be MAKE_IRR_ID be reversed instead, like:
#ifdef __amigaos4__
    u32    sigCheck = MAKE_IRR_ID('b','r','r','i');
#else
    u32    sigCheck = MAKE_IRR_ID('i','r','r','b');
#endif

That would be a quick way of confirming that we're on the right track. But if we are, I think that conditionally defining MAKE_IRR_ID() would be a better way to deal with the problem.

Go to top


Re: OS4.1 native find-tool
Just popping in
Just popping in


@nbache

I've seen it work both ways, as walkero described, and as you described. A bit of experimentation worked out what is going on.

The way it seems to work is that if you click on one of the buttons next to a volume name, then that name becomes selected (it's highlighted). At that point, the space bar toggles just that selected name, and does not affect any of the other names.

The up and down arrow keys change which name is selected, and the space bar toggles that name. Pressing the down arrow key when no names are selected selects the top name in the list (and pressing escape deselects the Pattern gadget, allowing the space bar to work on the list of names instead of entering a space). Basic keyboard control.

However, if you click on the name itself and not on the button, then the name is not selected (no highlight), and the space bar then toggles all of the names.

So I guess the simplest way to do what you want is to click the top name (not button) in the list to turn it off while leaving all the names unselected, and then press space to toggle all the names. Or just save the settings as pjs suggested.


Edited by msteed on 2022/9/21 5:18:46
Go to top


Re: What
Just popping in
Just popping in


@rjd324

Quote:
If the libc is just forwarding calls to newlib.library, why is the libc in newlib so large?

I think that's a result of inefficiency in the object module format. In order to allow only those functions that are used to be linked into a program, every single function in the library has to be in its own object module.

While the actual glue code to turn a newlib call into a newlib.library call is likely not very big, there is a good deal of other overhead in the object module. Multiply that by the rather large number of functions in the library, and all that overhead adds up. (Also, I'm guessing that since libm.a is empty, the math functions are actually in libc.a as well, making it even bigger.)

Look at libauto.a. It's quite large too, and all it does is open and close libraries. But it handles a lot of different libraries, each of which requires its own object module. So again, all the overhead adds up.

Go to top


Re: What
Just popping in
Just popping in


@rjd324

Quote:
...but there is no updated to the libc linker library.

Isn't there? The libc.a in the SDK is 553,018 bytes and is dated 01-Jan-21, while the one in the latest newlib update is 684,962 bytes and is dated 10-Mar-22. Besides the later date, being significantly larger is consistent with having more functions.

Go to top


Re: OS4.1 native find-tool
Just popping in
Just popping in


@pjs

Quote:
I wasn't able to find any docs on the AmigaOS Find program either...

There is some documentation on the OS4 Documentation Wiki, though it's minimal and not entirely accurate. It does list the tooltypes (though some that it says are unused clearly are in fact used) and the command line options.

Quote:
I think I have a solution for your goal to deselect all your drives by default.

Thanks for the tip on saving the settings-- it wasn't clear what settings would be saved, so I never even tried that. It works great, removing the most annoying thing about using Find.

Note that saving the settings also saves the current location and size of Find's window, instead of the default of always centering the window on the screen and setting the size automatically. If you want to restore the default behavior, just set the MAIN_LEFT and MAIN_TOP tooltypes to CENTER, and the MAIN_WIDTH and MAIN_HEIGHT tooltypes to AUTO (or just delete those four tooltypes).

Go to top


Re: ASL file requester bug?
Just popping in
Just popping in


Quote:
If you guys check the AmiUpdate a new version of string.gadget is available...

And a new version of newlib, too-- nice!

Go to top


Re: x5000 benchmarks / speed up
Just popping in
Just popping in


@Raziel

Quote:
Apart from the last one it wipes the floor with your X5040...huh?

As noted earlier in this thread (post 36), the X1000 seems to be much faster than the X5000 at accessing memory, at least according to RageMem. Geennaam speculated (post 37) why this might be. And the author of RageMem has noted that it was designed for earlier, lower-spec NG Amigas, and may not be that accurate for X1/X5-class machines.

Go to top



TopTop
(1) 2 3 4 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project