developing amiga 68000 clone

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2)

kerravon

Re: developing amiga 68000 clone

Posted on: 5/21 9:03 #21

Just popping in

@joergQuote:

joerg wrote:@kerravon
Quote:
int c_Write(void *handle, void *buf, int len)
{
int rc;
rc = fwrite(buf, 1, len, handle);
return (rc);
}
That's wrong and wont work in all cases.
dos.library Write() is an unbuffered I/O function, while C library fwrite() is buffered.
If you want to use C fwrite() for dos Write() you'd have to use
int c_Write(void *handle, void *buf, int len) { int rc; rc = fwrite(buf, 1, len, handle); fflush(handle); return rc; }
instead.

You are correct - but during normal operation (ie the scope I am trying to achieve - running toolchains) - it is not something that anyone can notice.

I might notice it when I start running microemacs, and then that will serve as my testcase.

Quote:

Additionally dos.library file handles can't be the same as a C library FILE handle, it's a different abstraction layer.
dos.library BPTR file pointers are more similar to the POSIX int filedes.

That is not correct. Yes it is true it is the equivalent of the int filedefs. And indeed, it is exactly treated that way. The application program will do an fopen using its own C library, and get a pointer to a distinct location in memory. And part of that fopen process is to get a handle from the OS - and I simply do my own fopen, and get a pointer to another distinct area of memory. There is no clash. And that pointer is basically treated as the equivalent of the POSIX int. And since everything is 32-bit there is no issue.

So two FILE * are allocated in that process - one suitable for the Amiga, and one suitable for Linux (ie it really does have an int in it).

Or if I was running my Amiga mini-clone on the Amiga itself - once again I would have two distinct FILE *, and both of them are suitable for the Amiga. And only one of them (ie the clone) will have a real int-like BCPL thing in it (obtained from real AmigaDOS). The other (an ordinary C90 app) is just a link to the other (clone's FILE *).

Very neat IMO. And very small objectively - around 51k for a clone that is sufficient for what I want to do.

Hypex

Re: developing amiga 68000 clone

Posted on: 5/22 15:57 #22

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.

Register To Post	« 1 (2)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )