Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
169 user(s) are online (82 user(s) are browsing Forums)

Members: 3
Guests: 166

imagodespira, afxgroup, FlynnTheAvatar, more...

Headlines

Forum Index


Board index » All Posts (msteed)




Re: osdepot certificate not updated?
Just popping in
Just popping in


Quote:
Put everything behind cloudflare...

Definitely don't do that- it would make it inaccessible to Odyssey (and presumably IBrowse, too).

Go to top


Re: Updater tool: latest releases and updates
Just popping in
Just popping in


@kas1e

Quote:
The one you include in the Enhancer are 1.53 (03/06/2022)

While the version tag date is 03/06/2022, the file date on the one in Enhancer seems to be 03/06/1980- I'm not sure what happened there.

Go to top


Re: Get/Set Kernel DebugLevel (and KDEBUG command question)
Just popping in
Just popping in


@rjd324

Quote:
...or there was a screen in some GUI tool...

Ranger can display all the firmware environment variables in its Hardware->Firmware tab.

Go to top


Re: AmiFTP 1.953
Just popping in
Just popping in


@khayoz

OS 4 version 1.943 also crashes on exit if "sort by date" has been used.

Go to top


Re: The RAD (And logging serial output techniques)
Just popping in
Just popping in


@rjd324

Quote:
To me it just seems more preferable and convenient to capture the serial to a file without the need to have another machine turned on...

You could always get a Sentinel X-Logger!

Go to top


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


@kas1e

Quote:
For you it just pure keyboard+mouse ?

Yes, that's right.

Go to top


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



TopTop
« 1 2 3 (4) 5 6 7 8 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project