Who's Online |
51 user(s) are online ( 36 user(s) are browsing Forums)
Members: 1
Guests: 50
flash,
more...
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/6/2 15:10
#121
|
Not too shy to talk 
|
@Anyone Guys, please, obviously something is wrong with the recovery drive. Everything I read about it, where it is produced by AmigaKit, says it includes latest drivers. Clearly this is not the case. Although it can boot it cannot detect any SFS partitions. Can someone just grab an image of a proper up to date recovery image send it across to Mame? PM is your friend guys. 
|
|
|
|
|
|
Re: FTP Between OS3 and OS4
|
Posted on: 2024/6/2 14:36
#122
|
Not too shy to talk
|
@MartinW Quote: The workaround is simply to LHA the disk images before transferring them to the OS4 machine. When I un-LHA them at the other end the file comments are intact. It's an extra step but it's not the end of the world. That's also what I do as well. Since years. Takes time and RAM or HDD space but works for me. Unfortunately, for some reason, not all Amiga users are aware of this. I have no idea why. I've seen Amiga people copy Amiga files to USB stick or even unpack on Windows for some reason then transfer to Amiga using some other generic medium and wonder why they have problems later. I didn't think I was too smart for my own good, but I don't know why they do this. I mean, does anyone unpack Windows or Linux files on their Amiga, copy from an Amiga file system to Windows or Linux, the complain the executables are faulty? If not, why do the opposite?! Lol.  Where I have seen problems is where a basic CDFS turns all files into upper case and strips bits. I've seen this happen a lot when transferring or installing OS3.9 in UAE. For some reason all my UAE Workbenches suffer from this glitch. 
|
|
|
|
|
|
Re: FTP Between OS3 and OS4
|
Posted on: 2024/6/2 14:25
#123
|
Not too shy to talk
|
@jPV Quote: It could be that server gives the outer IP address instead of local IP address to establish a passive data connection and that might mess things up if you don't have port forwardings properly set for outside connections. So it could very well be the issue still. Passive is better for outside connecitons, but active may work better on LAN. I haven't known about that catch in a LAN. I didn't expect it to pass out outer IP addresses. I have been caught with active and passive before when remotely connecting to a server with MS FTP command. I needed to change this script to use passive. Maybe it has an esoteric use but for the most used OS in the world I was surprised to find it wouldn't work easily. But later found out it can be forced to work after editing a hex key (as I call it). In the end I just gave up and downloaded another ftp program to use. Perhaps it's common to outsource. I mean, if you can download Python now, would anyone bother sticking with 80's MSDOS batch scripting? Even AmigaDOS scripts look superior in use and handling Quote: As told, comments aren't stored in actual files or their headers. Files just aren't touched in any way and their size doesn't change when you modify comments. It's a filesystem specific feature and filesystem stores it somewhere where it stores other metadata about files. It would end up with horrible mess if comments would be stored in the actual files. Well, I would call it a file header, where name size and other attributes are stored. So apparently it's called a FileListEntry where the comment is called. In a file list of a directory. Quote: FTP only sends binary data of the file, no dates or any other info, and client asks for a file by its filename. The FTP protocol really isn't designed to be used with automated (graphical) clients. It's up to client to parse a human readable text based directory listing to get whatever info is provided in that. Practically all FTP servers (including Amiga servers) send the directory listing in UNIX standard listing format nowadays, which is the same as you get with the "ls -l" command in *nix systems. So, what clients are able to parse about the list is *nix protection bits (not Amiga), user and group (not much use in Amiga), file size, date, and filename. It's up to client what information of these it uses, filename is the only one really needed to retrieve files. I mostly use FTP with a GUI client. Usually FileZilla which has "Opus" file listers. But I do find it lacks obvious features like changing dir on both local and remote when there is a matching folder name. I found out about the Unix underpinnings of FTP when setting up RC-FTPd on my A1200. I don't recall what happened with Amiga protection bits. I used to transmit files over FTP to other machines like Mac. And mostly, to decrease transfer size and keep bits intact, would LhA it first. Quote: Nothing stops writing an FTP client and server that would support Amiga's file attributes, but they would only work between themselves and no other client or server would understand them. There have been tens of different listing formats in the past and it's been a mess.. luckily there's kind of de-facto standard nowadays. Most if not all OS or file systems would have attributes and comments. The Amiga has GUI/UID but it's an optional extra. I'd say FTP could be expanded to include bits and comments but if it's not there already too late to append the standard.
|
|
|
|
|
|
Re: FTP Between OS3 and OS4
|
Posted on: 2024/5/30 16:53
#124
|
Not too shy to talk
|
@MartinW
The comment would be stored in the file header somewhere. But it wouldn't be in the binary data transfer just as the file name or attributes are also not sent inside the transfer. Unless it specially sends them across. I'm not aware of any other information being sent or checked apart from dates. And nothing relevant turned up for FTP transferring this information after a search. If it's part of the protocol then it's up to the client and server to support it if so.
Given ARP maps IP addresses to MAC addresses it seems like a reasonable idea. But I do wonder if being static or dynamic affects it? One thing does come to mind now I think of it. In the past it was common to use static IP or configure the router to assign a specific IP to a machine using DHCP. I don't recall how it was specified apart the physical interface it used. But I do recall that host names were set. Did you assign host names to any machines?
Was that the A-ftp on OS4Depot? Not much experience with RNOXfer. There is also PFTP for OS4 that I used years ago.
I used RC-FTPd on my A1200. And I also used it on OS4 years ago with success. But that was before OS4.1 came about.
I also know of some other Amiga cross platform file sharing software. I'm not sure of the name. I looked up RNOXfer but that didn't stand out as being the one.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/5/29 15:59
#125
|
Not too shy to talk
|
@MamePPCA1
I take it you have no space for another partition? If your HDD had any empty space you could at least create another volume to install too. Then at least you'd have a working WB to boot off before reinstalling.
In any case one final way to locate SmartFilesystem is to boot off pendrive, show all files, then open up Kickstart drawer. Sometimes it can be inside System if it follows a CD installer. Order by name and it should be there. If there get Info on file and press Version button. That should be easier.
A shame the dealer can't offer to send a replacement pendrive, even at cost, or a USB image to update it with.
|
|
|
|
|
|
Re: FTP Between OS3 and OS4
|
Posted on: 2024/5/29 12:27
#126
|
Not too shy to talk
|
@MartinW
Apparently this is more of a common misconception than I knew of. You can edit the file comments in the Info window of the icon. But the comments are stored with the file itself and not the icon.
I thought something more had to be going on with the FTP. Remotely I could see issues. But on the local network there should be no issues.
I could only think of passive and active FTP but again locally there shouldn't be blocked ports unless it was intentional. I hadn't heard of this ARP caching so that's rather specific. Good to be aware of it.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/5/28 15:23
#127
|
Not too shy to talk
|
@MamePPCA1
That's usually the beauty of it. You usually don't need to do a thing. As it can be picked up.
It may be because the boot priority of the pendrive is too low or on default 0. It really should be on 5 or higher like for floppy. You could change it but you can work around it.
In that case just boot off HDD until it's loading Kickstart. Then hold down both mouse buttons for boot menu. Best to leave pendrive in so it's detected before menu displays.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/5/27 3:31
#128
|
Not too shy to talk
|
@MamePPCA1 Also I have an idea. Before you re-install. Boot Kickstart off the HDD. When it is ready to boot Workbench insert your pen drive so it boots off that! Yes, Kickstart loaded off HD, Workbench loaded off USB. It may even be as easy as plugging your pendrive in then restarting the X5000. So it loads off HDD then when AmigaDOS launches it detects and boots off USB.
|
|
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 2024/5/26 16:10
#129
|
Not too shy to talk
|
@joerg Quote: Only works because on m68k the AmigaOS library calls are replaced with inline functions, macros or #pragma, depending on the compiler, which replace the standard stack based m68k ABI with register arguments, and a hidden A6 library base argument, for those functions . Then that's what was needed. Regarding SDI, looks like it was a bit too late for the 80's, being dated from this century. But what does SDI mean? I read through that project years ago and unless I missed the obvious it doesn't say what it is. I think an acronym is rather pointless if it isn't explained on the first line of the readme.
|
|
|
|
|
|
Reply timeout bug?
|
Posted on: 2024/5/24 14:33
#131
|
Not too shy to talk
|
Hi. So I was just casually making a short reply before. Pressed Submit and it gives me a time out error. Tried again, time out error. Reload. Try again. Same error. Reload front page. Go to same forum. Same error! So I logged out. Logged in. Reply. Works! At this point a time out error can be ruled out. It was under five minutes of typing and after reloading it kept doing it. Is this known as I don't recall getting so many time out errors in such a short time. 
|
|
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 2024/5/24 14:27
#132
|
Not too shy to talk
|
@joerg Quote: I don't know what it's based on but I meant the Amiga 68K ABI which is fully register based. For API calls. Including the A6 offset jump. Quote: It would have been compiler specific if I'd have used something like That's still too complicated. Given a library call is like this without needing to think about it. So it certainly could have been programmed in.
int32 hookFunc(struct Hook *hook, APTR object, APTR message)
|
|
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 2024/5/24 4:47
#133
|
Not too shy to talk
|
@joerg Quote: On PPC nobody is using an asm stub in h_Entry and a C function in h_SubEntry. It's not required because on PPC all 3 arguments are passed in registers (r3, r4 and r5) in C code anyway. Yes, obviously the ABI convention helps here in SYSV, which C compilers follow. The 68K ABI convention is also the same way as the native ABI also uses registers in API calls, however, C compilers don't follow it for internal functions calls and use the common stacking standard. Quote: On m68k an asm stub in h_Entry can be used which pushes the 3 registers A0, A2 and A1 on the stack and calls a C function in h_SubEntry. On m68k C functions don't use registers but only the stack for the arguments. And that's where the mess begins. It would have needed a specific keyword like APICALL in GCC does, but I imagine that C compilers could have used registers automatically, if they could be told to call it like an API function. Of course there would be no library base so perhaps it wouldn't have been easy to tell the C compiler to put parameters in registers like a normal library call. Quote: But even on m68k most people didn't use that anymore but something like Except in that case but it can be compiler specific. Where as a library call using the same register method is just an include file away for the causal coder. Quote: The EmulateTags() call works in any case, no matter if there is a m68k asm stub in h_Entry which calls a h_SubEntry function with stack arguments, or if h_Entry is the C function using register arguments with the REG() macro. Transparency is good and expected. Quote: It's the same for PPC native code, just in case someone uses useless code like Ha. 
|
|
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 2024/5/23 2:07
#134
|
Not too shy to talk
|
@joerg
An issue with that is it's using h_Entry as the HLL entry point. According to convention, h_Entry is for asm stub and h_Subentry is the HLL function. Mind you, it's pointing to some code, but that's not the point. It's designed so that h_Entry is an asm stub that calls h_Subentry. Perhaps naming it as h_Start and h_Main or h_Function would be less confusing but I suppose in any case h_Entry can be treated as a generic entry point.
|
|
|
|
|
|
Re: developing amiga 68000 clone
|
Posted on: 2024/5/22 14:57
#135
|
Not too shy to talk
|
@kerravon Quote: By "passing it around" you mean - my mini-clone passes it to any executable it runs? Yes. It does provide a means of portability I can see. Quote: Yes, it already exists on the Amiga - but I don't want it in this case - otherwise my apps will invoke real AmigaDOS, not my mini-clone. And if you want that to happen, there's no point running my mini-clone at all. Technically they would be accessing the Exec kernel before even getting to DOS. But I can understand. Quote: That is an entire toolchain (gcc etc) - not just for the Amiga, but also targeting other environments. gcc 3.2.3 itself is 400,000 lines of C code. I consider that to be "much". Yes that would be much. But the little I mean is what you need from Exec and DOS which isn't a huge amount compared to the total amount of functions. For GCC I would have expected it to be efficient by now and only compile in what functions are used. I mean, as a rule, C compilers like to optimise away unused code and strings so leaving in vestigial code linked in shouldn't happen. Quote: The Amiga C90-compliant programs that I am trying to run (all using PDPCLIB as the C library), have this code (from pdpclib/start.c): For a clone this would be fine but on the Amiga this is bad. In an Amiga context, not only isn't it thread safe, it's very thread unsafe. You are walking through a system list without any locking which could bomb at any time. When you find what you want, a library, you simply pull it out. Without any opening of the library nor any version checks. Unless you want your code to randomly crash it should do like this which is less work:
// SysBase is set
DOSBase = OpenLibrary("dos.library", 33L);
if (DOSBase != NULL)
{
//continue
}
else
{
// fail
return RETURN_FAIL;
}
The return code is just convention back to the CLI. 33 above is OS1.2, 34 is OS1.3, etc. Quote: My mini-clone prepares that environment with this (from generic/amiextra.asm): If you generate your own copies, and fill them in with your own relevant functions, then when rewriting that DOSBase open code I've wasted my time. Quote: Building the array isn't an issue - I already do that with the data in d0. But I need the program name - not included in d0 (as far as I can see) - if I am to put it in argv[0]. So there may be an Exec/Dos call to get that, but I haven't tried to find it, because it hasn't been priority to do that bit of work. Okay so for that you will need to grab the Process structure. From a FindTask(NULL) call. It returns a struct Task so you will need to cast it or use &Process->pr_Task to get Task from Process. From the Process you need to extract the struct CommandLineInterface from the pr_CLI BPTR. So will need BADDR macro for that. It's ba-ba-bad to the bone lol. From there you find a BSTR at cli_CommandName. And there is your command name. Simple! Like a lot of DOS operations it's a little complicated and only in OS2 could it be retrieved more directly. The CLI arguments are in the pr_Arguments field of the Process but only in OS2+. And you have the simpler GetProgramName() but only in v36 DOS. Though that's unclear as that's not calling it a CommandName. Quote: BTW - I actually changed my priorities - I still haven't gotten back to the ARM32 work, and also I've taken an interest in the Atari after all (one thing led to another and I got interested). I never know where I will be the next day! Ha. Well I took a brief look at the ARM asm code. About the only asm I'm not familiar with. Well, with common asm that is, since I've really only written some 6502, been proficient in 68000, didn't understand x86, done some brief coding in PPC and looked at ARM sources.
|
|
|
|
|
|
Re: developing amiga 68000 clone
|
Posted on: 2024/5/21 3:49
#136
|
Not too shy to talk
|
@kerravon Quote: I'm not 100% sure I understand the question - but if I am, the answer is "yes" - I am not interested in the Atari or Mac - I'm only interested in the Amiga - but I want to be able to run my Amiga software on those other platforms (Mac, Atari, Linux) - if that's all I have access to. Furthermore - I'm mainly interested in Linux being installed on the Mac/Atari hardware, such that the only thing I need to do is make sure that my "mini Amiga clone" runs under Linux 68000, with Linux being treated as a glorified BIOS. Okay. It was just the ExecBase pointer at $4 was particular to AmigaOS. It in fact uses 68K reset vector. But not for resetting in the usual way. Since it points to Exec library and not a reset routine. The ROM being mapped in for CPU reset. Quote: I'm not familiar with that and I don't understand that. What I meant was that with PowerPC machines software was made for Mac. For example a PPC Linux CD was designed to boot on a Mac. Mac was the most common PPC desktop and it used OpenFirmware. So most bootable CDs, though not auto bootable, were made to work on Mac OpenFirmware. But OpenFirmware was used on most other PPC hardware in the CHRP standard. The AmigaOne PPC boards being an exception. Quote: I'm not sure if you're misunderstanding because I'm not quite understanding the question. So let me just restate how things work. It's likely because of the stacking of ExecBase on Amiga when it always exists. And depending on that. If you are only interested in Amiga 68K it's fine but looks redundant passing it around if the PDOS lib can just grab it itself. Quote: That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone). That isn't too much. It does give you the chance to implement resource tracking above that as well. Quote: That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone). For a clone it would have an ExecBase jump table with lots of empty items. But you also need DOSBase. Where is that opened from? Because if you only pass ExecBase then a mini clone will need to locate DOSBase. Which usually is a call to OpenLibrary(). Not such a problem on Amiga but something else will need a mechanism when it looks for DOS. Quote: So you can see that an Amiga C program (which would normally use fwrite()) calls Write() and then my mini-clone (it's not really an emulator I think), simply turns around and calls fwrite again. Yes I can see that, thanks for the example. Quote: Yes, but I don't know how to retrieve that on an Amiga, so my Amiga executables in the startup code just set it to "UNKNOWN" - only the bit after the executable is passed in d0/a0 I believe. The simple answer is you can't because it doesn't exist. As per previous discussion all you have is a simple string and length of the whole command line passed in A0/D0. And some other place in the CLI object. If you want a nice array of vectors pointing to each argument and your program binary you have to build it yourself. I didn't know this was a standard thing for other OS. I just know AmigaDOS doesn't do that. And with ReadArgs() in OS2+ no one really needs iterate through any argv vectors unless they really want too. A standard C lib does it so no one really thinks about it unless they are doing their own startup code.
|
|
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 2024/5/20 7:15
#137
|
Not too shy to talk
|
@kas1e
Just quickly I always knew the "A" postfixed to function names as being for Attribute. But it's confused again by "Tags" or "TagList" functions where that's postfixed on names as well. Like OpenWindowTagList and OpenWindowTags. Suppose the "A" team of functions is mainly for BOOPSI.
|
|
|
|
|
|
Re: developing amiga 68000 clone
|
Posted on: 2024/5/19 16:24
#138
|
Not too shy to talk
|
@kerravon Quote: No, I can't do that, because absolute address 4 may not be available for me to use on an Atari etc etc. Well, no it wouldn't, because Atari uses TOS. Quote: When run on Atari, or Linux, I am "rewriting core kernel" - there is no alternative - the Amiga doesn't exist at all. Are you using the Amiga and Exec as an m68k base standard? Kinda like how Mac became the PowerPC de facto standard for PowerPC? With OpenFirmware. That's one way about it. I thought that may make it hard though. You have to take every Exec function and then DOS as it happens I expect and write an Amiga Exec wrapper to Atari, or Mac, or any other 68K platform. Or am I misunderstanding here? Quote: Anyway, here is the current state: I thought arg[0] was usually the binary filename? Quote: The standard - or indeed - definition - of PDOS-generic is that it takes a pointer on the stack to a list of functions such as printf. And that has been working for something like 6-12 months (can't remember - but could look it up) and those executables are available from pdos.org but until now I had no ability to personally test them. For a function like printf() stack makes sense. Since it can have variable arguments. And C like to stack! Indeed, when I compiled from C to ASM by hand, even though I was rewriting it myself in ASM I did it the "proper" C way and stacked all the function parameters. Quote: If there was a reason to there could be an alternate interface, but that's what I use on all environments (e.g. 80386). For x86 it makes sense since it's pretty much a stack based architecture. The base 68000 has more GPRs to play with but x86 did catch up. If your code is mainly C this makes sense. Since C likes to use stack in its ABI.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/5/19 16:02
#139
|
Not too shy to talk
|
@MamePPCA1 Might be easier to just use a Workbench program. Do you have Ranger on the pendrive? If not download here and you can copy it across to you X5000 over another USB stick as one option. Then run Ranger and look for the Kickstart modules tab. See if SmartFilesytem is listed as Kickstart module. Or just look in pendrive Kickstart drawer. http://os4depot.net/?function=showfil ... e=utility/misc/ranger.lha
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 2024/5/19 15:56
#140
|
Not too shy to talk
|
@smf Quote: The format has not changed, it's just that the "old" sfs does not support new machines like tabor and X5000 so for you it will be safe. Ah, I see. Another one of those version checks in any software with Joerg written on it. Now this is the X5000 inside information that's needed here. Quote: But it's sure a little bit complicated for X5000 customers atm as they need to know how to prepare their own emergency boot pendrive if they want to run a better filesystem than what was offered when the latest os4.1 iso was shipped in case they run into problems. That would go for everyone. To my knowledge this was a dealer setup recovery drive so easier for the user. Unfortunately not fully tested it seems to actually be useful as a recovery tool. But at least X5000 users can boot off USB. Even if there is not yet a program to build a recovery volume like in OS3.9. On my X1000 there's no USB boot support at current. Quote: A-eon has created a great emergency boot iso for the tabor, they should do it for the X5000 too. I expect in due course it will be. So an ISO image that can be burnt to CDR or USB?
|
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
