Who's Online |
86 user(s) are online ( 41 user(s) are browsing Forums)
Members: 2
Guests: 84
afxgroup, Rob,
more...
|
|
|
|
|
Re: Lame intuition/reaction based questions
|
Posted on: 11/24 15:38
#1
|
Just can't stay away 
|
@kas1e Quote: Through found some moment : when one window opens on top of the previous ones, and the mouse cursors are over both of them, then i have empty string returned. While i were expected to get it from the active window.. But maybe there another flag for ? If you pass the pointer of the active window instead of NULL, and change the mouse x/y to be relative to the top/left of that window instead of the screen, you should get what you want.
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
|
Just can't stay away
|
@Hans Some addition to your comment: My AmigaOS 4.x port of OWB might have even been more expensive per user as IBrowse is. While I never asked anything for it there was a bounty for another browser which, after the original project was cancelled, was divided among the AmigaOS 4.x developers of OWB (me) and NetSurf (Chris Young) instead.
|
|
|
|
|
|
Re: Lame intuition/reaction based questions
|
|
Just can't stay away
|
@kas1e
A lot of intuition, not only BOOPSI gadgets/images/etc., is done asynchronously, not directly executing the code in the task calling some intuition functions but sending messages to it's input.device task which (later) does the actual work.
Simple functions like IIntuition->GetWindowAttr() may be executed immediately in the task using them, but functions doing more complex things like changing the size of a window with IIntuition->SetWindowAttr() may be forwarded to the input.device task.
|
|
|
|
|
|
Re: Max. partition size in AmigaOS4.1 (SFS2 handler)
|
Posted on: 11/20 19:45
#4
|
Just can't stay away
|
|
|
|
|
|
|
Re: Max. partition size in AmigaOS4.1 (SFS2 handler)
|
Posted on: 11/20 18:52
#5
|
Just can't stay away
|
@geennaam Quote: I'll stop looking into it further because I cannot fix SFS2 itself. Did you test it with and without diskcache.library? If diskcache.library.kmod is installed SFS doesn't do the device I/O itself but just calls the diskache.library functions. If diskcache.library.kmod is not installed the device I/O is done by SFS. Would be very strange if the 64 bit device I/O code in SFS, which was implemented by John Hendrikx, has the same bugs for drives larger than 2 TB as the independent 64 bit device I/O code I implemented in diskcache.library.
|
|
|
|
|
|
Re: Max. partition size in AmigaOS4.1 (SFS2 handler)
|
Posted on: 11/20 10:10
#6
|
Just can't stay away
|
@geennaam Quote: That is not enrtirely correct. I do see filesystems sending the TD_GETGEOMETRY. I wrote that the file systems don't use the results from it, not that they don't send the TD_GETGEOMETRY command. It's used once on startup, but the results aren't used - unless LowCyl is 0. Only in this case the results from TD_GETGEOMETRY are used instead of the data from the file system startup message and additionally the TD_ADDCHANGEINT command is used to get information from the disk driver when a disk is removed from or inserted into the drive. On each disk change TD_GETGEOMETRY is used again to check if there is a disk in the drive or not and if yes use the data from TD_GETGEOMETRY result for the current disk. For example when replacing a DD floppy disk with a HD one in an Amiga floppy drive Sectors/Track changes from 11 to 22 and C*H*S * sector size from 880 KB to 1760 KB. If LowCyl isn't 0, as it's the case on all partitioned drives, nothing from the TD_GETGEOMETRY result nor TD_ADDCHANGEINT is used but the CHS, etc. values from the file system startup message, the data from the RDB.
|
|
|
|
|
|
Re: Max. partition size in AmigaOS4.1 (SFS2 handler)
|
Posted on: 11/19 20:47
#7
|
Just can't stay away
|
@geennaam Quote: I've bought a 4TB NVMe drive which arrived today. Unfortunately, I've ran into the same problem as @Raziel. The disk capacity is shown correctly in MediaToolbox. I can define partitions of > 2TB. But they cannot be formatted. With SFS2, I get a disk is full. With NGFS, I get an uninitialised disk. I don't understand why you even tried that, I wrote several times already, and of course it's mentioned in the SFS readmes as well, that SFS uses 32 bit block numbers resulting in a max. theoretical partition size of 2 TB with 512 bytes/block Quote: There's also a TD_GETGEOMETRY64 with a struct DriveGeometry64 defined for the mounter library. Struct DriveGeometry64 doesn't work with CHS but with a 64bit dg_TotalSectors. So I've added support for this command and it's indeed used by the mounter library. But not by MediaToolbox or any filesystem. TD_GETGEOMETRY64 didn't exist yet when I did the last updates of SFS, but filesystems don't use any values from TD_GETGEOMETRY anyway, unless LowCyl is 0 like on floppy disks for example, to support both DD (880 KB) and HD (1760 KB) floppies with a single DOSDriver. On HDs, and anything similar like USB massstorage and NVMe with a RDB, the filesystems only use the values they get in their startup message from dos.library, which are the same CHS values as in the RDB created by MediaToolBox/HDToolBox/HDInstTool/etc. Quote: When I increase the blocksize to 4096 bytes, I can format the drive but the result is only a 1.86TB partition. How did you check the wrong 1.86TB size? The functions and data structures used by C:Info, the WorkBench, etc. are 32 bit as well and can't display anything > 2 TB correctly. Quote: EDIT2:
SFS2 partitions do not work reliable. Executing something will result in a GR. Not even if I split my 3.7TB into e.g. 3x 1.2TB. NGF\01 works fine in any case.
So it looks that SFS2 will not work with >2TB drives Using several partitions <= 2 TB (with 512 bytes/block) should work, but since I never had a HD > 500 GB, and the largest HD the original author of SFS had was only 10 or 20 GB, it could never be tested by a SFS developer. Please test if it works if you disable diskcache.library in the kicklayout, maybe it's not SFS itself but diskcache.library not working correctly on drives > 2 TB. @all The last version of JXFS was intentionally read-only, to let users who used it copy their data to a partition with a working filesystem, without the risk of a JXFS version with write support destroying their data. In case of JXFS it wasn't a license problem, Hyperion never had any. Beta versions of JXFS were just included as free contributions in some AmigaOS 4.x distributions. It had too much bugs, and the bugs weren't just implementation bugs, but unfixable design bugs, and since Tony already started working on his better NGFS it didn't make sense to create a 3rd implementation of my JXFS.
Edited by joerg on 2023/11/19 21:12:38
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 11/18 20:58
#8
|
Just can't stay away
|
I don't know anything about QEmu, but unless there is a default file name for CD images in Quote: -drive if=none,id=cd \
-device ide-cd,drive=cd,bus=ide.1 \ the file name of the CD image may be missing? @balaton My AmiDVD tools supports creating AmigaOne SE/XE/µA1/SAM4x0 bootable CD/DVD image files (burning them to CDs and DVDs as well, but that's useless for QEmu), incl. adding the required slb_v2 to it.
Edited by joerg on 2023/11/18 21:16:28
|
|
|
|
|
|
Re: Running my OS4 games on QEmu
|
Posted on: 11/15 18:38
#9
|
Just can't stay away
|
@TheMagicSN Quote: EDIT: tried it compiling the renderer with softfloat
breaks the game completely. You can't mix hardfloat (default) with softfloat (-msoft-float compiled) code. Either everything has to be compiled with the default hardfloat, for example using FPU registers for float/double function arguments and results, or everything has to be compiled with -msoft-float using integer registers for float/double function argument and results instead, incl. any libraries you may be using in your games.
|
|
|
|
|
|
Re: DrawerGenie for AOS4?
|
Posted on: 11/15 15:36
#10
|
Just can't stay away
|
@kas1e Quote: Can anyone spot some obvious mistake in this simple test case ? Current software usually doesn't use the ancient AmigaOS 1.x struct NewWindow, incl. NewWindow->Flags, but since AmigaOS 2.0 already tags instead. NewWindow may even be NULL in OpenWindowTag(s|List)() making your code crash. Search in the Taglist for WA_WBenchWindow, TRUE, for example using IUtility->FindTagItem(WA_WBenchWindow, Taglist). Additionally your program should crash since it exits, is unloaded and the newFunc() code no longer exists. Add IExec->Wait(0) after IExec->Permit() to make sure it wont exit and it's code isn't unloaded.
Edited by joerg on 2023/11/15 16:01:43
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/13 19:33
#11
|
Just can't stay away
|
@MigthyMax Quote: BTW can foo.library use sjobs ? Yes, but I don't know if that was ever used. Except for me, and maybe @Futaura, just testing if it's working. At least I never publicly released such a foo.library using sobjs, and even it was used in a publicly available foo.library it's probably a very rare case you can ignore.
|
|
|
|
|
|
Re: qemu emualtion of AmigaONE XE
|
Posted on: 11/13 17:40
#12
|
Just can't stay away
|
@Maijestro Quote: Qemu does not emulate Classic PPC hardware where custom chips also have to be emulated QEmu doesn't but WinUAE does, and the PPC emulation part of WinUAE is based on an old, IIRC 5.x, version of QEmu.
|
|
|
|
|
|
Re: Running my OS4 games on QEmu
|
Posted on: 11/13 17:34
#13
|
Just can't stay away
|
@TheMagicSN
You don't need to change any sources to disable FPU usage, simply recompile everything with CFLAGS += -msoft-float.
Of course the result will be unusable slow on any real AmigaOS 4.x PPC hardware, and I don't know if using guest softfloat is faster, or even slower than QEmu's host softfloat.
Additionally the softfloat functions in both clib2 and newlib are just approximations, not exact results, which may cause problems. Maybe clib4 has better softfloat support.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/13 16:11
#14
|
Just can't stay away
|
@MigthyMax Another reason .rodata should be separated from .text (and .plt) is the way (non-)execuable memory is allocated in AmigaOS 4.x. At least on some CPUs you can't change it after allocation from executable to non-executable, or the other way round. While it doesn't cause problems directly in PPC-only code, without m68k cross calls/EmuTraps, having executable .rodata (const data, strings, etc.), which would be the result of loading the complete section with .text, .plt and .rodata at once, would be a bad idea. Quote: * m68k Hook function: Theoretically possible, but why should I setup an m68k hook, if I currently developing for ppc. Maybe only used in a bizarre scenario If you are developing a PPC library (AmigaOS foobar.library, not libfoobar.a or libfoobar.so) which also exists in a AmigaOS 3.x/m68k version and uses Hooks you will get m68k Hook functions from AmigaOS 3.x/m68k executables using the PPC version of the library on AmigaOS 4.x. The same is theoretically possible for m68k interrupts as well, but unlikely to be used.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/11 19:11
#15
|
Just can't stay away
|
@Georg
The cross calls are generated by the "ftdrans" tool. The results are IIRC assembler, but in any case just .(ro)data with the bytes of the to be emulated m68k code, without any symbols or anything else which could be used to identify it in an ELF executable.
The m68k cross calls/EmuTraps are used in the, for OS4 native code obsolete and unused, m68k jump table of OS4 libraries for example. Only old, emulated OS 3.x/m68k code calling library function via the jump table uses it, and the "EmuTrap" code in it just copies the emulated m68k registers to the corresponding PPC ones, calls the PPC native version of the OS4 library function and on return to the emulated m68k code copies the PPC register results of the function to the emulated m68k ones (D0 (+D1 for 64 bit) for integer, A0 for pointer results, etc.).
Emulated m68k code like those cross calls/EmuTraps can only work if it's in (for the PPC CPU) non-execuable memory, if it would be allocated in PPC executable memory instead it would be executed as PPC native code, resulting in ISI crashes, instead of being emulated with one of the 2 m68k emulators of OS4.
|
|
|
|
|
|
Re: Tetris Queen
|
Posted on: 11/11 18:38
#16
|
Just can't stay away
|
@Maijestro Quote: The game wants "liballegro.so" where can I get this library ? Best source for OS4 software is usually os4depot.net, the 2nd result searching for "allegro" on it is http://os4depot.net/?function=showfil ... ment/game/allegro_sdk.lha which includes the file "Local/newlib/lib/liballegro.so", which you'll have to copy into SOBJS:. I din't test it and don't know if there may be other, incompatible versions of liballegro.so somewhere else, but worth a try.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/11 17:57
#17
|
Just can't stay away
|
@kas1e Quote: Hmm.... but if .rodata has something to do with 68k cross calls, then shouldn't it be matters in all cases, not only for dynamically linked executables ? Why only for dynamic, then ? Because statically linked executables don't have a .plt. The problem is a combination of the 3 sections .text, .plt and .rodata: - .text and .plt have to be loaded into contiguous memory to make 24 bit (+/- 8 MB) relative calls work as Frank wrote. That's done by elf.library if .text and .plt are in the same segement, but .rodata is in a different one. That's a bug in vlink (putting .text and .plt into different segments), or more likely just in it's linker scripts, which needs to be fixed. It may work by accident even without doing it correctly, like in your example, but it's not guaranteed to work. - elf.library can't load .text, .plt and .rodata into the same memory space at once because of the m68k cross calls in .rodata with have to be loaded into non-executable memory but .text (and .plt?) has to be loaded into executable memory instead. If a section contains .rodata all of the segments in it (.text, .rodata and for dynamically linked executables additionally .plt) are loaded separately instead, to make .text executable but .rodata non-executable, which may result in .text and .plt to be more than +/- 8 MB (24 bit) apart from each other. Is it GCC specific? Maybe. GCC, or rather fdtrans, puts the m68k cross calls (EmuTraps) into .rodata. If the VBCC equivalent of fdtrans uses .data instead of .rodata it doesn't have the m68k code in PPC executable .rodata problem. But that doesn't change anything, elf.library can't know if an executable was linked with ld (binutils) and .rodata has to be loaded separately, or if it was linked with vlink instead and separate .rodata loading may not be required. (I may have mixed "segment" and "section" above, but you should still get what I meant.)
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/9 18:16
#18
|
Just can't stay away
|
@Futaura Quote: Not much to be done about this, I guess. In theory, you could load the entire .text/.rodata/.plt segment in one block of memory and then change the memory attributes for the .rodata section, but I don't think it can be guaranteed that there is suitable padding/alignment either side of .rodata, particularly with the older binutils. That said, this could be checked and handled differently if alignment is correct, but perhaps not worth the effort. I don't know anything about how the ExecNG kernel works on the newer CPUs (X1000, X5000, A1222), but on the older ones changing memory attributes may work at most on 440/460 CPUs which are using the TLB cache for it, but not on G2/G3/G4 CPUs. On G2/G3/G4 CPUs the MMU memory attributes, incl. the executable bit, aren't used by the kernel IExec->IsNative() function, and similar code in the m68k emulator, at all. At least not in the kernel versions for which I still had access to the sources. It just checked if the address of the code is in the 256 MB executable segment address space, IIRC 0x70000000-0x7FFFFFFF.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 11/9 16:04
#19
|
Just can't stay away
|
@Futaura Quote: The logic is that any segment containing .rodata is treated differently by elf.library - each section is loaded individually, rather than the entire segment. The reason: something to do with not breaking 68k cross calls, which is the only clue given in the comments (I haven't figured out exactly why this is, only that the OS crashes if I remove this behaviour). If at all possible, I'd like to change this, but until I understand it, I can't touch it. The m68k cross calls probably depend on IExec->IsNative() returning FALSE for the m68k code, just like it's required for utility.library hook functions for example checking if the hook function is PPC native or m68k code. If .rodata is in the same segment as .text .rodata with the m68k code may be put into executable memory (segment registers on G2/G3/G4 CPUs) making it fail by IExec->IsNative() returning TRUE for m68k cross call code.
|
|
|
|
|
|
Re: SDL1 open issues
|
Posted on: 11/8 17:28
#20
|
Just can't stay away
|
@balaton Quote: or firmware (but the firmware is not really involved in graphics either so not likely to have a role in it either) The firmware is executing the x86 BIOS ROM of gfx cards. If the (emulated) SM502 has a x86 BIOS ROM it could be that it's BIOS code changes some endian mode and only works correctly with the SciTech x86emu used by U-Boot, but not with the x86 emulator of the Pegasos2 SmartFirmware?
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
