Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
208 user(s) are online (134 user(s) are browsing Forums)

Members: 0
Guests: 208

more...

Headlines

Forum Index


Board index » All Posts (salass00)




Re: getcwd() issue or bad usage ?
Just can't stay away
Just can't stay away


@kas1e

AFAICT there should be no upper limit on the buffer size for getcwd() in clib2 (I looked at the code both for Olaf Barthel's and afxgroup's clib2).

What is errno set to after getcwd() has returned?

Go to top


Re: A new editor for AmigaOS 4 is in the works
Just can't stay away
Just can't stay away


@trgswe

A more verbose method that should produce the same result:
struct Locale *locale;
ULONG charset 0;

locale ILocale->OpenLocale(NULL); /* Get default locale */
if (locale != NULL)
{
    
charset locale->loc_CodeSet;

    
ILocale->CloseLocale(locale);
}

/* Locale autodoc says to treat zero as ISO-8859-1 */
if (charset == 0)
{
    
charset 4;
}


BTW the warning note in the GetDiskFontCtrl() autodoc is mainly for the tag pairs like DFCTRL_XDPI/DFCTRL_YDPI or DFCTRL_XDOTP/DFCTRL_YDOTP where you might get a new value for the X and an old value Y if you read them while they are being modified.

Go to top


Re: A new editor for AmigaOS 4 is in the works
Just can't stay away
Just can't stay away


@LiveForIt

Quote:

it crashes on PowerPC "BLR" opcode, its like the 680x0 "RTS", so my guess is corrupted stack, maybe it has run out of stack.


If that was the case it would be an ISI and not an alert.

In this case what seems to have happened is that the newlib.library dlmalloc allocator has detected an error and posted the alert 0x81000009 (AT_DeadEnd|AN_FreeTwice).

It could be that a bad memory pointer was passed to free() or maybe the memory was already freed before as suggested by the alert code. It is also possible that the magic field in the memory chunk header has been overwritten by a buffer overflow or random memory trashing.

Go to top


Re: A new editor for AmigaOS 4 is in the works
Just can't stay away
Just can't stay away


@walkero

You don't need unlibdev or other external dependencies to convert between local charset and unicode.

Just use IDiskfont->GetDiskFontCtrl(DFCTRL_CHARSET) to get the IANA number and you can then use IDiskfont->ObtainCharsetInfo() to request a mapping table.

ULONG charset;
const 
ULONG *maptable;

charset IDiskfont->GetDiskFontCtrl(DFCTRL_CHARSET);
maptable = (const ULONG *)IDiskfont->ObtainCharsetInfo(DFCS_NUMBERcharsetDFCS_MAPTABLE);


The mapping table is an array of 256 ULONGs that are the unicode (UCS4) equivalents to each character in the local (8-bit) charset.

You can then use this to convert to unicode just like so:
IKeymap->MapRawKey(ie, &vanilla1NULL);
if (
== 1)
{
    
ucs4 maptable[(UBYTE)vanilla];
}


I use this method in SSHTerm as libtsm (the terminal emulation layer I am using) works exclusively with unicode as well (see src/term-gc.c).

Go to top


Re: SSHTerm "Authentication password failed"
Just can't stay away
Just can't stay away


@rjd324

Try specifying the password from the command line.

If it works that way then you are encountering one of the race condition bugs that exists in the latest public version of string.gadget, but should be fixed in the latest beta version.

Go to top


Re: No std::to_string(float) in GCC 11
Just can't stay away
Just can't stay away


The latest beta version of the AmigaOS 4 newlib port has about 160 added functions compared to the version 53.61 that was released with 4.1 FE update 2. The majority of these are floating point/complex math functions (the complex.h header also exists now) and wide char support functions that are needed for better C++ support in gcc.

Go to top


Re: Is there a simple why to find the motherboard name?
Just can't stay away
Just can't stay away


@LiveForIt

The IExpansion->GetMachineInfoTags() function with GMIT_MachineString tag should work to get the machine model as a string.

Go to top


Re: Getting Red Mars to run on AmigaOS 4.1
Just can't stay away
Just can't stay away


@jap

Looks like a random number generator to me, with vposr being used not for timing but to get some extra entropy.

Go to top


Re: Fading effect on 24bit ARGB screens
Just can't stay away
Just can't stay away


@flash

Quote:

Here is complete C function, it works ok when I use "Win->Width * 4" inside Read/WritePixelArray api calls, but fails if I use Win->RPort->Bitmap->BytesPerRow value.


The BytesPerRow argument is for your own buffer and not for the rastport.

Go to top


Re: Exodus The Last War patching : work in progress
Just can't stay away
Just can't stay away


@kas1e

Quote:

MOVEA.L 14(A3),A2
BEQ.W LAB_0758
TST.B (A2)
BEQ.W LAB_0758


It looks like maybe the first two instructions were meant to be a NULL pointer check but the programmer did not take into account that moves with an address register as destination do not set condition flags.

On 68020+ I think you can do:
MOVEA.L 14(A3),A2
TST.L A2
BEQ.W LAB_0758

But on 68000 CPU you will have to find a free data register and do something like:
MOVE.L 14(A3),D0
MOVEA.L D0,A2
BEQ.W LAB_0758

Go to top


Re: Odyssey 1.23 progress: r5 RC2
Just can't stay away
Just can't stay away


@kas1e

Quote:

For me, it reports 210713c, ~35MB.


Only if you use SI units where 1 MB = 1000000 bytes.

Using binary units it is ~33.028 MiB where 1 MiB = 1048576 bytes.

Go to top


Re: Odyssey 1.23 progress: r5 RC2
Just can't stay away
Just can't stay away


@kas1e

Quote:

@tonyw
Quote:

The binary for Odyssey is huge - some 36 MB. Because it is >32 MB, its PPC FP op-codes can't be translated into SPE op-codes and it will have to run under emulation on the A1222.

36? It is 60 when unstripped, and almost 50 when stripped.


What matters for whether LTE can be used or not isn't executable size but how big the code segment is (".text" section in ELF files).

Running "ppc-amigaos-readelf -e" on the Odyssey exe it reports that the .text section is just a little over 33 MiB.

Go to top


Re: gcc 9 and 10
Just can't stay away
Just can't stay away


@flash

AFAIK the last gcc to support SPE code generation when using the regular ppc target is gcc 7. For later versions the only way to build SPE code is using a special ppc_spe-<OS>-gcc cross-compiler.

The latest gcc with SPE support that can be built from adtools is gcc 6.4.0.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@alfkil

Quote:

Here is another one : What is the Amiga equivalent of CLOCK_BOOTTIME ?


In AmigaOS 4 there is GetUpTime() for this.

Go to top


Re: Cmake and adtools
Just can't stay away
Just can't stay away


@alfkil

Are you using the libstdc++.so that is built along with gcc 11, or are you using the one the one that is supplied with the OS (in SOBJS:)? If it's the latter then that is likely the reason for your problem.

IIRC the newer libstdc++.so is not backwards compatible so the best solution ATM is to bundle it with your program or not use shared objects if possible.

You may also need to update other compiler shared object files like libgcc.so. I'm not sure as I don't use shared objects much anymore.

Go to top


Re: MutexAttemptWithSignal
Just can't stay away
Just can't stay away


@sTix

To be honest I'm not really sure what the purpose of non-recursive mutices is (as they do not save memory or CPU time AFAIK) and what exactly the correct behavior should be for your code.

What happens however for your code is that after returning from Wait(SIGF_SINGLE|sigmask) MutexAttemptWithSignal() checks if it is now the owner of the mutex in question and if it is it always returns zero indicating that the mutex was successfully obtained.

Go to top


Re: MutexAttemptWithSignal
Just can't stay away
Just can't stay away


@sTix

The SIGF_SINGLE signal is used internally by the semaphore/mutex functions to signal when a semaphore/mutex has become free so it can't be used in the way that you are using it.

Go to top


Re: Enhancer Software v2.0 Released
Just can't stay away
Just can't stay away


@Amigo1

Quote:

- Archiver: does not offer the option to assign a default destination dir where the archive should be unarchived to. e.g. UnArc tooltypes (DESTINATION=)


Archiver already supports the ARCHIVE and DESTINATION tooltypes same as UnArc.

The ARCHIVE tooltype can be used to either set an archive that is always opened initially when the program is run or just to set a default path for the ASL requester used for opening archives.

The DESTINATION tooltype sets the initial destination path (default is RAM: if the tooltype is not set).

Quote:

- Archiver: A tooltypes option for Archiver to open at certain coordinates and Window Size would be very handy (See UnArc tooltypes)


You should be able to snapshot/unsnapshot the window from the dropdown menu in the window title bar.

Quote:

- Archiver: IMHO the keyboard shortcuts are a little unconventional; e.g. "l" for "select all"? Why does it not stay close to system style and use "a"?


IIRC "l" is used there because "A" was at some point used for "Extract All". This will be changed in the next version.

Quote:

- Archiver: IMHO, the GUI needs an overhaul. The "Open" button is mispositioned.


Where would you put it then? If it's on a separate row it wastes too much space IMO.

Go to top


Re: How to print text in RGB colour?
Just can't stay away
Just can't stay away


@Deniil

Just use RPTAG_APenColor tag with IGraphics->SetRPAttrs(). Format is 0xAARRGGBB.

Go to top


Re: GDB
Just can't stay away
Just can't stay away


@afxgroup

Quote:

Unlucky fseeko64 is not working correctly on newlib. Don't know if something has broken from your tests but i've tried your p7zip with an 8GB file and it fail. I've tested it with my clib2 version i'm using now and it is working.
So something has changed in newlib code (most probably)


As a test I just used p7zip on my beta installation to create a 6.5GiB archive file from ~11GiB worth of music files and it worked without problems, though it took about 14 hours to finish.

I then ran "7za t" on the archive on both AmigaOS and Ubuntu and both reported that the archive was okay and with no errors.

Then I extracted the archive on AmigaOS using the p7zip port again and this also worked fine with no errors (I also compared md5sums on a couple of the extracted files and they do match the originals).

What file system are you using? JXFS has broken relative seeking as well as other bugs that will never be fixed because it is no longer developed and should not be used anymore. For the tests above I used SFS\2 partitions (ssh2-handler was used to transfer the archive to my Ubuntu system for the test there).

Go to top



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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project