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.
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:
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.
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)..
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.
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.
I have been thinking more about this, plus there has been a development. I now have "Windows for 68000", and the thread here:
explains how that works - and should work under the Amiga too.
I am still trying to get the Amiga 1000/500 to compete with the PC XT.
Including the box-drawing, and including covering Vietnamese.
The end of the above thread covers a potential solution to these issues - by enabling graphics mode on the Amiga for Win68k to operate under, instead of what would currently happen, which is to make use of an Amiga console window.
Again - I'm not interested in UTF. I'm interested in a modified VISCII.
joerg wrote:@kerravon Main problem is that there is next to no AmigaOS software running in a shell, nearly all uses a GUI.
Of course there are a few exceptions like the VIM editor, originally developed on AmigaOS, or S-Lang and ncurses based ports, for example the slrn usenet newsreader, mutt e-mail client and the w3m web browser, some of which I ported to AmigaOS 20-30 years ago, but there is no advantage using an AmigaOS port of any of them compared to the versions on other OSes.
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.
It was just pointed out to me that there is no "text mode" on the Amiga anyway. So what's wrong with simply switching the Amiga to code page 437 (one way or another) and using the box-drawing characters?
And assuming that is not an issue, any idea whether the speed of the Amiga in rendering an 80 * 25 screen is as fast as an XT doing a direct write to 0xb8000? Or not so much "as fast" as - is the user likely to detect it?
It was just pointed out to me that there is no "text mode" on the Amiga anyway. So what's wrong with simply switching the Amiga to code page 437 (one way or another) and using the box-drawing characters?
The Amiga has no CP/M, MS-DOS, VMS, VC20/C64, BBC Micro, MSX, CGA/EGA/VGA, etc. like text mode (some 40x20 to 80x50 buffer with just the char codes in it), everything is bitmap based graphics, incl. font rendering, and the lowest usable resolution was 320x200 pixels (= 40x25 chars with a 8x8 pixel font), but it's shell heavily depends on the 0x80-0x9F control chars, especially the CSI (0x9B) sequences. AmigaOS depends on 8 bit chars, incl. all of the 64 (0x00-0x19 and 0x80-0x9F) control chars, like for example VMS on the VAX did as well. Not only for output but for input as well, for example the cursor, F1-F30 (F1-F10 physical keys only, not 12 like on most PC, but with shift and control extended to 30), HELP, etc. keys are sent to the shell as 8 bit CSI input sequences. Just one more reason why something like CCSID 437 or 850 are impossible on Amigas... Most (or even all?) Unix systems used 7 bit workarounds instead, for example "ESC[" (0x1B[) as "CSI" (0x9B) replacement.
Quote:
And assuming that is not an issue, any idea whether the speed of the Amiga in rendering an 80 * 25 screen is as fast as an XT doing a direct write to 0xb8000? Or not so much "as fast" as - is the user likely to detect it?
The Amiga had several co-processors (agnus, blitter, copper, denise were gfx related, paula for audio and floppy, etc.) additionally to the, rather slow, 68000 (motherboard) and 6500/1 or 6570/6571 (in the keyboard) CPUs. But of course even with them running in parallel of the CPU rendering text even with the small default font (topaz/8, 8x8 pixels = 8 bytes) is slower than only writing a single byte into a text mode screen buffer.
It was just pointed out to me that there is no "text mode" on the Amiga anyway. So what's wrong with simply switching the Amiga to code page 437 (one way or another) and using the box-drawing characters?
The Amiga has no CP/M, MS-DOS, VMS, VC20/C64, BBC Micro, MSX, CGA/EGA/VGA, etc. like text mode (some 40x20 to 80x50 buffer with just the char codes in it), everything is bitmap based graphics, incl. font rendering, and the lowest usable resolution was 320x200 pixels (= 40x25 chars with a 8x8 pixel font),
Sorry? The Amiga can do 80 * 25 with an appropriate (1084S) monitor, right?
I'm trying to get the Amiga to match the PC. If that means using a monitor (as the PC did) instead of the TV - that's fine. This is meant to be for corporate use anyway (like the Apple Mac Silicon processor is managing to do to some extent).
Quote:
but it's shell heavily depends on the 0x80-0x9F control chars, especially the CSI (0x9B) sequences.
I may need to replace the shell as a solution to this problem, but let's see.
Quote:
AmigaOS depends on 8 bit chars, incl. all of the 64 (0x00-0x19 and 0x80-0x9F) control chars, like for example VMS on the VAX did as well. Not only for output but for input as well, for example the cursor, F1-F30 (F1-F10 physical keys only, not 12 like on most PC, but with shift and control extended to 30), HELP, etc. keys are sent to the shell as 8 bit CSI input sequences.
That's OK - I can translate those characters on input, in my C library (PDPCLIB).
Something like Vietnamese input is still done using a normal QWERTY keyboard. There will be keys to provide "accents" such that the next (ASCII) character produces the appropriate Vietnamese code (VISCII-like).
Quote:
Just one more reason why something like CCSID 437 or 850 are impossible on Amigas...
The box-drawing characters can be alternate fonts on the Amiga. I believe you can already do that.
Quote:
Most (or even all?) Unix systems used 7 bit workarounds instead, for example "ESC[" (0x1B[) as "CSI" (0x9B) replacement.
My C library will provide this sequence to the application.
Quote:
Quote:
And assuming that is not an issue, any idea whether the speed of the Amiga in rendering an 80 * 25 screen is as fast as an XT doing a direct write to 0xb8000? Or not so much "as fast" as - is the user likely to detect it?
The Amiga had several co-processors (agnus, blitter, copper, denise were gfx related, paula for audio and floppy, etc.) additionally to the, rather slow, 68000 (motherboard) and 6500/1 or 6570/6571 (in the keyboard) CPUs. But of course even with them running in parallel of the CPU rendering text even with the small default font (topaz/8, 8x8 pixels = 8 bytes) is slower than only writing a single byte into a text mode screen buffer.
Slower - yes, technically correct. But DETECTABLE by a user? Could a user detect that a "text mode" box that just popped up, popped up slower on the Amiga compared to an XT? Or are we talking about a 1 millisecond difference that is undetectable?
Sorry? The Amiga can do 80 * 25 with an appropriate (1084S) monitor, right?
The 1084(S) monitor is basically just a TV, depending on the region it was sold for with PAL (640x256, 640x512 interlaced) or NTSC (640x200, 640x400 interlaced) resolutions, just without the TV signal receiving units. With overscan IIRC up to 720x640 (PAL). There were several additional screen modes up to 1024x800 (A2024 monitor required), 1408x688 ("Euro 36", multiscan monitor like the Arcon AKF50, which I had at that time, required), DblPAL, DblNTSC, etc., but some of them require "newer" Amigas with the ESC or AGA chip set and don't work with the initial (A1000, A500, A2000, A1500, etc.) OCS chip set.
But the Amiga never had any text mode (except for the U-Boot, CFE, etc. firmware on the PPC Amigas maybe), everything in AmigaOS is bitmap gfx and rendering a single char needs writing at least 8 bytes, with a 8x8 bitmap font, to the slow gfx memory.
Quote:
Slower - yes, technically correct. But DETECTABLE by a user?
Yes, at least 8 times slower than a text mode. With anti aliasing, LCD monitor sub-pixel rendering, alpha blending, etc., as used by the current AmigaOS versions, several 100 times slower than a simple CGA/MDA/EGA/VGA text mode.
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
