Who's Online |
54 user(s) are online ( 49 user(s) are browsing Forums)
Members: 0
Guests: 54
more...
|
|
|
|
Re: Bootarguments for Qemu AmigaOne install on Mac M1
|
Posted on: 6/26 11:50
#81
|
Just popping in 
|
@balaton Thank you for replying  Correction. It looks like internet access works afterall. Accessed a timeserver and that fetched the time. Apparantly I had made an error trying to do that until now. Is there a boot argument to mount the ISO without having the system boot from it? I need to install some extras like a browser, ftp-client etc.? Also need to get a new version of AmiUpdate. The one on the system is way to old to be able to update anything. Filesharingwise I am primarily just unsure what to do. I have tried this argument to add USB: -device usb-storage,drive=ufat but I get this error: qemu-system-ppc: -device usb-storage,drive=ufat: Property 'usb-storage.drive' can't find value 'ufat' Is there a way to add a folder or something?
Edited by johnfante on 2025/6/26 12:15:31 Edited by johnfante on 2025/6/26 12:58:56
|
|
|
|
Re: Bootarguments for Qemu AmigaOne install on Mac M1
|
Posted on: 6/26 11:38
#82
|
Quite a regular 
|
@johnfante What error do you get? What network settings you use in AmigaOS? With -netdev user you should leave it using DHCP and ping may not work but should still be able to connect to services (like from behind a router doing NAT).
|
|
|
|
Bootarguments for Qemu AmigaOne install on Mac M1
|
|
Just popping in 
|
Sorry if this has been discussed before or if this is nooblike. Following this guide I have a working AmigaOne install running on my M1 Mac. However, I can not get it to go online or share files with th Mac side, so I can not really get any further with it. I use the bootarguments below and have set up and RTL8139 connection on the Amiga side but I can not get it to online. Sharing files I simply do not know how to. Have tried setting up a USB storage solution but it errors out. Any recommandations?
qemu-system-ppc -machine amigaone -rtc base=localtime -serial stdio -vga none -device sm501 -drive media=disk,format=raw,file=amigahd.img -device rtl8139,addr=0x09,netdev=nic -netdev user,hostname=amigaone-os4,hostfwd=tcp::22220-:22,id=nic -rtc base=localtime -device loader,cpu-num=0,file=bboot -device loader,addr=0x600000,file=Kickstart.zip
|
|
|
|
Re: G-Wars
|
Posted on: 6/25 21:57
#84
|
Not too shy to talk 
|
@LiveForIt
The only tooltypes relating relating to vsync in the monitor driver are for setting the minimum and max. Both are set at 60 on my system.
If a game uses vsynch it it should just lock the frame rate in relation to the refresh rate of the monitor. It more about maintaning a consistent frame rate than limiting the speed at which the game itself runs.
If you compare my video to NovaCoder's own video you can see there are issue beyond the speed at which the game runs. The game scrolls or jumps beyond the boundaries of the gamneplay area and object are also drawn beyond that boundary.
Black listing the game so it runs using interpreted 68k emulation makes no difference, well maybe a few more seconds before the game over message is displayed.
MorphOS user have reported it to be running fine on their systems although one did have a problem with the player ship not being drawn correctly.
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
Posted on: 6/25 17:47
#85
|
Home away from home 
|
@msteed Quote: A good deal of caution should be employed when displaying a string parameter. Since one of the uses of the program is debugging, you have to consider that in some cases string pointers may not be valid (illegal values other than NULL or -1), Using a IExec->TypeOfMem() check could partially help: If it returns 0 it's not a virtual address mapped by the kernel, and accessing it will very likely cause a DSI exception. Quote: or may not point at a real NUL-terminated string. Checking that isn't that easy, but possible as well. Requires using such checks for each MMU page, if it's mapped or not. On most, or maybe all, OS4 systems the MMU page size is 4KB.
|
|
|
|
Re: Tracing of callhookpkt()/callhook() and varargs
|
Posted on: 6/25 15:05
#86
|
Home away from home 
|
@kas1e Quote: Btw, what about Printf(), DebugPrintF(), etc ? IIRC DebugPrintF() has everything internal and doesn't use other functions, the rest probably still ends in using IExec->RawDoFmt(), or once loaded the locale.library replacement of RawDoFmt() (with the additional features supported by ILocale->FormatString(): argument positioning, localized number formats, etc.).
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
|
Just popping in 
|
@kas1e Sounds like a cool tool (love the name!). I like that you can decide which parameters of each function to snoop on, rather than having to see them all, whether you're interested in them or not. Quote: Please share your ideas, findings, and suggestions. ... What features should be added?
It would be nice to be able to see the return value from the patched calls, though that will be a bit more complex as you need to report twice, once before the call and once after. It would also be nice if it showed the name of the program making the call like OS4 Snoopy does, so you can see which calls are made by the program being debugged (and once you can do that, the option to snoop only on a specified program would help filter out clutter from other programs). A good deal of caution should be employed when displaying a string parameter. Since one of the uses of the program is debugging, you have to consider that in some cases string pointers may not be valid (illegal values other than NULL or -1), or may not point at a real NUL-terminated string. Somewhere down the road a standalone GUI tool -- something like MPlayer-GUI -- could be created to build the script files and send them to Snork for processing. But that can wait until all the basics are working. Quote: Which libraries should come next? (I'm thinking about exec.library, utility.library, and graphics.library.)
Those would be my choices.
|
|
|
|
Re: Introducing Profyler
|
|
Just popping in 
|
Quote: The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.
I re-read this thread after it accidentally got bumped, and it started me thinking- since the A1222 seems to have newer versions of many system components than other editions of OS4, what version of exec.library does it have?
|
|
|
|
Re: Tracing of callhookpkt()/callhook() and varargs
|
|
Home away from home 
|
@joerg Quote: The varargs functions simply call the non-varargs ones, not only in dos but in all OS4 libraries.
Looks so indeed. That what happens when i patch all 3 : CreateNewProc(), CreateNewProcTagList() and CreateNewProcTags(...) and simple call CreateNewProcTags with 5 tags:
IDOS->CreateNewProcTags(...)
NP_Entry = 0x7FFB2500
NP_Name = amiga1200
NP_FreeSeglist = 0
NP_CloseOutput = 1
NP_Child = 1
IDOS->CreateNewProcTagList(tags=0x5FDADCC8)
IDOS->CreateNewProc(tags=0x5FDADCC8)
CreateNewProcTagList() is the one i called from patched CreateNewProcTags, and CreateNewProc() seems the one called from TagList one. Because if i simple replace in varargs one to call at end CreateNewProc() one instead of TagList one, then output is:
IDOS->CreateNewProcTags(...)
NP_Entry = 0x7FFB2500
NP_Name = amiga1200
NP_FreeSeglist = 0
NP_CloseOutput = 1
NP_Child = 1
IDOS->CreateNewProc(tags=0x5FD9CCC8)
Btw, what about Printf(), DebugPrintF(), etc ? They all call VSNPrintf() in end ? But then, user want to know exactly what he call imho, even if after it go over other function (so maybe it need to be patched, logged, and giving control to the one which called for real after) ? Because seeing in log bunch of VSPirntf() while you call for example pure Printf() or DebugPrintF() will make it looks wrong imho.
Edited by kas1e on 2025/6/25 6:48:42
|
|
|
|
Re: Updating system
|
Posted on: 6/24 22:05
#90
|
Just can't stay away 
|
@SteffJay Quote: I have now received the Serial / Data cable, however i am not sure what or how to use it. It's all explained in the guide I linked to above. You just set up the serial link with a terminal program running on the computer at the other end (using the right parameters, see guide). Then when you turn on your machine, there will be useful diagnostics output in the terminal (hopefully). No need for Linux on the Amiga. Best regards, Niels
|
|
|
|
Re: NULL, 0xFFFFFFFF and Exec: Real vs QEMU
|
Posted on: 6/24 17:21
#91
|
Home away from home 
|
@broadblues Quote: It's not uncommon for a few special values for strings, we mainly get away with this due to the signed 32 bit memory space, so 0xFFFFFFFF will "never" be a valid pointer to a string. That's not the case for AmigaOS 4.x anymore, it has an unsigned 32 bit, 4 GB address space. I guess you are referring to the very strange, but on AmigaOS 4.x obsolete and no longer used, exec AllocEntry() function which did set bit 31 of the address on errors. But even on AmigaOS 4.x a pointer to 0xFFFFFFFF (-1) or 0xFFFFFFFE (-2) can never be valid, even if something is mapped there (the A1 SE/XE/µA1 might have had something U-Boot related there), because accessing odd, and on some PPC CPUs even only 2 byte aligned, addresses for 4 byte/32 bit accesses are invalid and cause a CPU exception. Of course wrap arounds like the 0xFFFFFFF[EF]->0x0000000[0-2] one cause a CPU exception as well.
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
Posted on: 6/24 16:39
#92
|
Just can't stay away 
|
Just test it a bit and working fine on SAM460ex.
Just when you CTRL+C Snork just show a simple "Snork ended" on Shell/CLI (and maybe to serial outoput too).
|
|
|
|
Re: Tracing of callhookpkt()/callhook() and varargs
|
Posted on: 6/24 15:39
#93
|
Home away from home 
|
@kas1e Simply only patch the non-varargs versions of the functions instead, in this case CreateNewProc()/CreateNewProcTagList() (not sure why there are 2 names for it, it may be the same?) The varargs functions simply call the non-varargs ones, not only in dos but in all OS4 libraries.
In AmigaOS 1.x-3.x the varargs versions of the functions weren't included in the libraries yet, but in the compiler includes, as macro, inline asm, #pragma, etc. instead
|
|
|
|
Re: ScummVM and AmigaOS4.1 F.E.
|
Posted on: 6/24 15:14
#94
|
Just popping in 
|
@Raziel
Do you do the 68K port for Amiga OS 3 as well?
|
|
|
|
Re: AmigaOS port of libsmb2
|
Posted on: 6/24 14:15
#95
|
Quite a regular 
|
@Tuvok I think the main problem is, that I don't know much about Windows  I thought, that I could use the login data from the desktop. This uses my full name with a space in it. But it didn't work even with two Windows machines. I solved this problem by creating a new Windows user (thanks youtube). I had to launch this command in a terminal: net user <username> <password> \add Maybe there is an other way to make this, but finally it worked for me. Thanks for your help!
|
X-5000 PPC 5020/2 GHZ, Fractal Define XL R2-Tower, OS 4.1 final update 2, 4 GB, Radeon HD 7770, ESI Juli@ XTe A1222, OS 4.1 SAM 460ex/1,15 GHZ, OS 4.1 final, 2 GB, Radeon HD 6450 Amiga 4000D/040 25 Mhz, OS 3.9 BB2, 272 MB, X-Surf, 250 MB ZIP
|
|
|
Re: Updating system
|
Posted on: 6/24 11:52
#96
|
Just popping in 
|
@nbache Thank you and yes it is.
|
|
|
|
Re: Updating system
|
Posted on: 6/24 11:51
#97
|
Just popping in 
|
@rjd324 Thanks for the reply. I have now received the Serial / Data cable, however i am not sure what or how to use it. I have tried booting from a Linux CD ROM but the Amiga does not boot from it.
|
|
|
|
Re: Tracing of callhookpkt()/callhook() and varargs
|
Posted on: 6/24 11:31
#98
|
Home away from home 
|
@all Can anyone bring some ideas how to patch/trace varargs based functions (such as Tags(...), format strings ones, and those specific rare cases where varargs used but not fits in first 2 categries) ? I tried to patch for test CreateNewProcTags(...), and can't make it work as it, because it takes (...), i then reparce them via va_* functions, and then i need to call original version, which didn't take (...) anymore but args => crash. I.e:
// Wrapper function for patching CreateNewProcTags
static void VARARGS68K Patched_CreateNewProcTags(struct DOSIFace *Self, ...) {
va_list args;
va_startlinear(args, Self);
struct TagItem *tags = va_getlinearva(args, struct TagItem *);
Original_CreateNewProcTags(Self, tags); // ! Can't! Expected (...)
va_end(args);
}
That one crashes of course.. I can replace of course call to original by CreateNewProcTagList(tags), and it then works, but then it isn't much "tracer", but "replacer" :) All i need is to simple grab the (...), parce all tags from till TAG_DONE/TAG_END found, print, and return all of them back to original, but of course i can't via a way i do it. But maybe there some other ways how i can do so ? Like some varargs forwarding or so ?
Edited by kas1e on 2025/6/24 11:59:07
|
|
|
|
Re: NULL, 0xFFFFFFFF and Exec: Real vs QEMU
|
Posted on: 6/24 10:03
#99
|
Home away from home 
|
@kas1e Quote: You can specify a value of -1 (i.e. (STRPTR) ~0) for either of the title pointers. This designates that you want Intuition to leave the current setting of that particular title alone, and modify only the other one. Of course, you could set both to -1.
I see jabirulo got there first.... Quote: Yeah, read it all yesterday already. Is it only SetWindowTitles allowing -1 or there are more ? I see NULL is acceptable offten, but -1 ?
It's not uncommon for a few special values for strings, we mainly get away with this due to the signed 32 bit memory space, so 0xFFFFFFFF will "never" be a valid pointer to a string. But check with the autodocs of each function / tag, some places bad things will happen
|
|
|
|
Re: NULL, 0xFFFFFFFF and Exec: Real vs QEMU
|
Posted on: 6/24 8:29
#100
|
Home away from home 
|
@jabirulo Quote: It's on the autodoc for such "strange" values.
Yeah, read it all yesterday already. Is it only SetWindowTitles allowing -1 or there are more ? I see NULL is acceptable offten, but -1 ?
|
|
|
|