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.

kerravon

Re: developing amiga 68000 clone

Posted on: 7/27 6:16 #23

Just popping in

@joergQuote:

joerg wrote:@kerravon
One of the "problems" compared to MS-DOS is that AmigaOS uses ISO-8859 charsets (ISO-8859-1 on AmigaOS <= 3.9, default on AmigaOS 4.x is ISO-8859-15).
With the code page 437 charset used on MS-DOS it's much easier to create text/shell only software since you can "draw" lines/boxes/etc. with the chars 0xB0-0xDF creating a "GUI" in text-only mode, for example like the MS-DOS version of Norton Commander did.
With the ISO-8859 charsets used on AmigaOS that's not possible.

I was thinking about this problem again.

Those box-drawing characters are output-only. I assume those ISO code pages don't have pictures assigned to the control characters.

As such, it would be possible to assign the box drawing characters to control characters.

And perhaps C90 or ASCII needed to be extended in some manner prior to people writing MSDOS software to explain that any use of box-drawing characters needed to go through a translation process, in preparation for being run on another platform, specifically the Amiga.

Some people create static "screens" including the box-drawing characters. So those would need to be typed in, and on some systems would appear as European characters instead of box-drawing characters - but that would be corrected on output.

That would only cover English static screens though.

Note that the Vietnamese alphabet (not DBCS) uses so many characters that VISCII (I want a slight variation of this that doesn't interfere with microemacs keystrokes) has to reassign 6 control characters. This can factor into the box-drawing mechanism.

I'm not interested in either UTF-8 or Unicode. I'm after efficient code pages. I'm also not interested in DBCS (the Chinese, Japanese and Koreans all have alphabets - their refusal to use them is not something I wish to be involved in)..

Any suggestions?

Thanks. Paul.

LiveForIt

Re: developing amiga 68000 clone

Posted on: 7/27 13:10 #24

Home away from home

@kerravon

Quote:

That would only cover English static screens though.

Yes.. without codepage support your stuck at 7bit ascii,
with codepage support you can use all European languages.

Quote:

Note that the Vietnamese alphabet (not DBCS) uses so many characters that VISCII (I want a slight variation of this that doesn't interfere with microemacs keystrokes) has to reassign 6 control characters.

That’s 100% not support in AmigaOS, no program uses that, and with library infrastructure it takes advantage of its, unknown.

Quote:

This can factor into the box-drawing mechanism.

You will need to crop it, or find closest looking match.
see codeset library.

Quote:

Im not interested in either UTF-8 or Unicode.

AmigaDOS does not support UTF8, it can’t display it.

Quote:

I'm after efficient code pages.

That’s not efficient, the content of the codepage has the same glyph code as UTF8/16/32 is storing, so actually code pages is extra layer, with an extra lookup, so that absolutely not efficient. Considering it can result cache misses.

Naturally UTF32 is fastest (no encoding/no decoding), UTF16 is slower, and UTF8 is the slowest, if you consider the amount of code, and checks, of course that depends on the text you’re displaying as well.

The size of text, will of course, depend on values stored, 32bit guaranties large use, while worst case utf8 can be larger then 32bit per glyph in worst case, but in the best case is only one byte, UTF16 is halfway point.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

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

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