Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
49 user(s) are online (40 user(s) are browsing Forums)

Members: 0
Guests: 49

more...

Headlines

 
  Register To Post  

developing amiga 68000 clone
Just popping in
Just popping in


See User information
Hello.

I bought an Amiga 500 around 1988, and did some development on it using SAS/C.

I was expecting people to migrate from MSDOS to the Amiga, since it was the superior machine. That didn't happen. And I wanted to know why. After all, if everyone followed the C90 standard, everything should port.

So I have spent 3 decades working on PDOS/386 (see pdos.org) and then, inspired by the number 4 (ExecBase) on the Amiga, I created PDOS-generic - which is an extremely portable operating system written in C, just dependent on a suitable BIOS. And Linux (or any other operating system) are effectively a suitable BIOS. So is UEFI. And one day I will hopefully write a layer on top of the IBM PC BIOS to make it "suitable".

Anyway, this then led to me realizing that I could support executables from other OSes if they in turn were "suitable". Meaning that they call DLLs/shared libraries rather than doing interrupts/TRAPs. So I could support OS/2 for example.

The Amiga has a similar but different mechanism, and I want to prove that it is possible and see what it looks like.

So currently I am creating a "bios layer" for Linux 68000 that I can run using qemu-m68k which will then support running (perfectly valid) Amiga executables that follow the "D7 standard", and I will support two flavors - ones that access dos.library and ones that access a new msvcrt.library (inspired by Windows msvcrt.dll and mingw).

If anyone wants to get involved, please let me know. There is a linker, pdld, which has been updated to take Amiga Hunk object as input, and produce 68000 ELF as output, but it's still in development and qemu-m68k doesn't like the output currently (because it is LSB instead of MSB). Hopefully that will be resolved in a matter of hours (author is in Slovakia).

Go to top
Re: developing amiga 68000 clone
Home away from home
Home away from home


See User information
@kerravon

This is what the JIT compiler and stubs do on AmigaOS4.1.

there is also a project called VAMOS that allows you run simple programs on Windows/Linux.

as your probably already know older stuff from 80’s requires chipset emulation, so VAMOS is limited to simple commands. Even stuff from 90’s need chipset emulation as well, late 90’s you get more system friendly programs, but fewer, with often bugs do lack of MMU on many 68K systems they were developed on. unless you have source code to 68K programs your not going to get anywhere sadly.

If you want to help out, ask around for source code, and start replacing Puala routines, with AHI Routines and fix the bugs in the software.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@LiveForItQuote:
This is what the JIT compiler and stubs do on AmigaOS4.1.

Apologies - I failed to clarify some of the goals.

Yes - I'm sure there are other solutions out there. But they're likely all copyrighted. I'm creating a public domain rival to them.

Quote:

unless you have source code to 68K programs your not going to get anywhere sadly.

And this was only implied by my original. I mentioned C90-compliant programs that used the "D7 standard" as seen here:

https://sourceforge.net/p/pdos/gitcode ... tree/pdpclib/amistart.asm

That defacto, but not de jure, requires you to have the source code and to recompile with PDPCLIB.

I am not expecting or attempting to run existing software. I am attempting to bring C90-compliant software (I have a whole toolchain, editor etc that are C90-compliant) across to the Amiga in such a manner that it still runs on a lightweight clone (like a 100k ELF executable).

I can't see a reason for it to not work, but I haven't definitively proven that this new scenario works. It's not the same as running OS/2 programs where I just satisfy functions in a DLL. I need to provide some Amiga structures and functions with different ABI for (valid) Amiga programs to see. I already have Motorola syntax assembler stubs for calling Write(), for example, but I will need the reverse of that now.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravon

I was a little confused when I read the title. I thought you were developing an Amiga hardware clone with CPU. Or at least some clone of what may be an A500. But then you talk some OS called PDOS. And how AmigaDOS/TripOS didn't take over the world. Well MSDOS sucks but unfortunately being a bootstrap for Windows made it more popular.

So PDOS generic is like a hosted PDOS. Any reason D7 was chosen? And not an address register? Amiga DOS was peculiar as the API put all addresses into data registers. I suppose D7 would continue that trend.

It's strange your linker produces LSB ELFs. That might cause problems unless it's just a container. Does it produce MSB ELF now? So it converts hunks now. Can 68K PDOS code be compiled to ELF directly or still in the works?

Go to top
Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
So PDOS generic is like a hosted PDOS.

It can be, yes. But e.g. I have a version already that uses UEFI for x64 - is that considered to be hosted? Even when my executable is called bootx64.efi and the EFI shell is not used.

Quote:

Any reason D7 was chosen? And not an address register?


I was advised that D5 and above were "free":

https://eab.abime.net/showthread.php?p ... ight=execbase#post1469898

Quote:

It's strange your linker produces LSB ELFs. That might cause problems unless it's just a container. Does it produce MSB ELF now?

Yes, it has been updated.

However, my ELF is not executing on qemu-m68k. Is there a "note segment" required for Linux?

Quote:

So it converts hunks now. Can 68K PDOS code be compiled to ELF directly or still in the works?

gccami is used to produce assembler. asami is used to convert that to Amiga hunk object code (no other choice I think). ldami will convert that into a hunk executable (only choice I think - maybe a.out too?). Or now, pdld will convert the Hunk object code into ELF (the only choice currently, but Hunk output is expected to be added in due course).

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@joergQuote:
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.

Yeah - I'm not looking for an advantage. I'm just looking to take my tools with me wherever I go. I spent an awful lot of time getting an (emulated) EBCDIC ANSI X3.64 terminal to work on a mainframe so that I could run microemacs. Spanning decades.

Quote:

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.

Oh - thanks for that insight! Maybe there needs to be ANSI escapes to draw such characters, and the terminal is required to put a "*" there if it doesn't support a particular box character.

It would be interesting to know if THIS was the show-stopper.

I don't do such box-drawing myself so didn't realize this could be an issue. I only do C90 plus ANSI X3.64 for microemacs, which doesn't draw boxes.

Go to top
Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


See User information
@kerravon
Quote:
Oh - thanks for that insight! Maybe there needs to be ANSI escapes to draw such characters, and the terminal is required to put a "*" there if it doesn't support a particular box character.

It would be interesting to know if THIS was the show-stopper.

I don't do such box-drawing myself so didn't realize this could be an issue. I only do C90 plus ANSI X3.64 for microemacs, which doesn't draw boxes.
AmigaOS doesn't even use 7-bit workarounds like <ESC>[ (0x1B 0x5B) for escape sequences (IIRC it's supported for output as well, but not for key input) but the 8 bit <CSI> (0x9B) sequences instead, for example for the cursor up/down/left/right keys for input, for output moving the cursor, changing foreground and background colours, etc.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@kerravon
Quote:
However, my ELF is not executing on qemu-m68k.

The technical issues in pdld have now been resolved, so my ELF works, and I am now in a position (I believe) to port PDPCLIB (my C library) to Linux 68000, and when that is working, create a mini Amiga clone that satisfies my desire to be able to develop C90 applications on an Amiga. The other tools (gcc/binutils/microemacs/etc) should all theoretically be able to be built already, to comply with the "D7 standard", so that it would be a self-hosting (under Linux 68k) ecosystem.

There is still some 68k assembler to be fleshed out too, such as setjmp/longjmp, but those will be easier to get operational once I have the above infrastructure in place to test them.

Go to top
Re: developing amiga 68000 clone
Quite a regular
Quite a regular


See User information
@kerravon
A simple explanation to your question "I was expecting people to migrate from MSDOS to the Amiga, since it was the superior machine."
Diskcopy A: B: this was the reason in Spain the success of MS-DOS, when the people can to have programs and games "free" from their schools, institutes, work and friends.
In Amiga there was "pirate paying" while in MS-DOS was "pirate free" nearby.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravon

Quote:
It can be, yes. But e.g. I have a version already that uses UEFI for x64 - is that considered to be hosted? Even when my executable is called bootx64.efi and the EFI shell is not used.


Well I suppose it could be considered hosted if it relies on UEFI for its work and not for bootstrapping.

Quote:
I was advised that D5 and above were "free":


Okay I see, because of old BCPL ABI. Well that's only relevant if you're reliant on it being compatible with OS1.3 and below. Code can easily be backwards and forwards compatible. Assembler programs relied on A0/D0 containing the CLI arguments. As did C startup code populating argv/argc. This changed with DOS ReadArgs() as it didn't use A0/D0 as a source but they were stored elsewhere. However the convention was for them to be in both places in OS2 and above. That thread has lots of discussion.

Early OS commands used the BCPL interface. But it isn't needed for any code. Although it provided a direct interface to DOS in a quirky BCPL way any code can just open dos.library and call functions the normal way. However, I did find that functions like ReadArgs() made public in OS2, were actually existent in early forms and callable in BCPL but it wasn't publicly known.

In any case, if PDOS is an OS, this shouldn't matter. Except for PDOS bootstrapping itself under AmigaOS. But, will there be a PDOS, that simply uses DOS to bootstrap and then takes over? Like Linux would do. Or, will PDOS rely on the OS as a BIOS of sorts, so run hosted and need AmigaDOS underneath?

Quote:
However, my ELF is not executing on qemu-m68k. Is there a "note segment" required for Linux?


Not that I'm aware of. But, I haven't used m68k Linux either.

Quote:
gccami is used to produce assembler. asami is used to convert that to Amiga hunk object code (no other choice I think). ldami will convert that into a hunk executable (only choice I think - maybe a.out too?). Or now, pdld will convert the Hunk object code into ELF (the only choice currently, but Hunk output is expected to be added in due course).


That's a few layers there! Hopefully you can simplify that down the line. But, compiling was always assembling parts, generating object code, then linking them all together into a final binary. Common object files were not stored as common HUNK but as a related format. And lots of libs were an archive of object files. So a final linker generating ELF is not unreasonable.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
Hypex wrote:@kerravon

Quote:
It can be, yes. But e.g. I have a version already that uses UEFI for x64 - is that considered to be hosted? Even when my executable is called bootx64.efi and the EFI shell is not used.


Well I suppose it could be considered hosted if it relies on UEFI for its work and not for bootstrapping.

Ok, and what about an OS (e.g. PDOS/386 and MSDOS) that relies on the IBM PC BIOS to do its work? And what about an OS (e.g. z/PDOS) that relies on intelligent hardware (ie mainframe hardware) such that there isn't a lot of work to do to create a CCW to obtain data from a device?

Regardless of your answer to that, if you think using UEFI is "cheating", then there is no issue replacing the pseudo-bios layer that PDOS-generic relies on with direct access to hardware - ie partially (and pointlessly?) duplicating UEFI. I just haven't had a reason to do that (apparently?) pointless work. It hasn't been a priority. Right now my priority is to have a mini Amiga clone so that at long last I can actually test my Amiga executables without having to ask someone else to test them for me.

Quote:

Quote:
I was advised that D5 and above were "free":


Okay I see, because of old BCPL ABI. Well that's only relevant if you're reliant on it being compatible with OS1.3 and below. Code can easily be backwards and forwards compatible. Assembler programs relied on A0/D0 containing the CLI arguments. As did C startup code populating argv/argc. This changed with DOS ReadArgs() as it didn't use A0/D0 as a source but they were stored elsewhere. However the convention was for them to be in both places in OS2 and above. That thread has lots of discussion.

Early OS commands used the BCPL interface. But it isn't needed for any code. Although it provided a direct interface to DOS in a quirky BCPL way any code can just open dos.library and call functions the normal way. However, I did find that functions like ReadArgs() made public in OS2, were actually existent in early forms and callable in BCPL but it wasn't publicly known.

Ok, I was excited about this, as I don't like having to rely on registers at startup. However, I realized (incorrectly?) that in my case it doesn't matter. I need to get the number 4 (ExecBase) from somewhere (noting that the number will no longer be 4 when run under qemu-m68k Linux or Atari or whatever, so I can't see anything to be gained by switching to using ReadArgs. Note that I'm doing something similar for Linux itself - I don't get argc and argv from the stack - at least not as a first preference. I try /proc/pid/cmdline first instead - which normally always exists. That allows PDOS/386 to run certain Linux programs without needing to construct the odd stack.

I could put the (alternative to) the number 4 on the stack, which would allow standard C code to read it, but I would still need a flag of some sort to indicate that an alternative ExecBase has been provided. So the high bit in D0 seems to be as good as anything else, and I'm stuck with needing assembler code. Or does AmigaOS already put something on the stack that I could rely on and detect? Or any other technique?

Quote:

In any case, if PDOS is an OS, this shouldn't matter. Except for PDOS bootstrapping itself under AmigaOS. But, will there be a PDOS, that simply uses DOS to bootstrap and then takes over? Like Linux would do. Or, will PDOS rely on the OS as a BIOS of sorts, so run hosted and need AmigaDOS underneath?

All those scenarios are possible depending on what user requirements are. However, the one that I am more likely to code personally is the one that uses AmigaDOS as a glorified BIOS. Because I may not be able to access the hard disks from PDOS otherwise, because the hard disks may require device drivers that are no longer supported and that there is no source code for. Replacing that for every bit of hardware is not really something I wish to do. Perhaps if there was a user requirement and a user willing to pay for development of that. But for me as a hobbyist - unlikely.

Quote:

Quote:
However, my ELF is not executing on qemu-m68k. Is there a "note segment" required for Linux?


Not that I'm aware of. But, I haven't used m68k Linux either.

I can confirm that it is NOT required - the technical issues were resolved. One of the header sizes was being set to an incorrect value.

Quote:

Quote:
gccami is used to produce assembler. asami is used to convert that to Amiga hunk object code (no other choice I think). ldami will convert that into a hunk executable (only choice I think - maybe a.out too?). Or now, pdld will convert the Hunk object code into ELF (the only choice currently, but Hunk output is expected to be added in due course).


That's a few layers there! Hopefully you can simplify that down the line.

In one aspect, that IS simplified. Restricting each program to reading text or binaries files and writing text or binary files means that each program can be C90-compliant, as reading/writing files is something within the scope of C90.

Quote:

But, compiling was always assembling parts, generating object code, then linking them all together into a final binary. Common object files were not stored as common HUNK but as a related format. And lots of libs were an archive of object files. So a final linker generating ELF is not unreasonable.

Yep, proven technology now.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravonQuote:


Ok, and what about an OS (e.g. PDOS/386 and MSDOS) that relies on the IBM PC BIOS to do its work? And what about an OS (e.g. z/PDOS) that relies on intelligent hardware (ie mainframe hardware) such that there isn't a lot of work to do to create a CCW to obtain data from a device?


Generally that wouldn't be considered hosted as the OS would need to interface with any firmware. Unless there was a boot loader in between. But even then that usually acts as a middle man.

Quote:
Regardless of your answer to that, if you think using UEFI is "cheating", then there is no issue replacing the pseudo-bios layer that PDOS-generic relies on with direct access to hardware - ie partially (and pointlessly?) duplicating UEFI. I just haven't had a reason to do that (apparently?) pointless work. It hasn't been a priority. Right now my priority is to have a mini Amiga clone so that at long last I can actually test my Amiga executables without having to ask someone else to test them for me.


I wouldn't say that's cheating. I would interpret hosted as running on a full OS and usually loaded by hand. But unless you have driver sources for all drivers you need you cannot be expected to fully take over the hardware.

Modern UEFI is similar to Amiga ROM2.0+. With mouse and GUI. But in many ways surpassed a basic early startup menu.

You can make use of WinUAE or any UAE to emulate an Amiga so you don't need a physical machine all the time.

I can see what you mean by duplicating unnecessary work. A few years back I wrote a Linux chain loader for the newer AmigaOS4 machines that use a boot loader (called AmigaBoot) for menu between firmware and AmigaOS. Now I could have written a full boot loader that also presented submenus to chose from. But I would have need to write a ton more code and handle file loading myself as well the user needing to manually add it to the firmware menu as an option. I decided to make use of the existing menu loader, adding menu entries with a dedicated boot partition, and letting the boot loader load all the files in for me. I just needed to iterate through a list of files and it gave me freedom to support other compression formats.

Quote:
Ok, I was excited about this, as I don't like having to rely on registers at startup. However, I realized (incorrectly?) that in my case it doesn't matter. I need to get the number 4 (ExecBase) from somewhere (noting that the number will no longer be 4 when run under qemu-m68k Linux or Atari or whatever, so I can't see anything to be gained by switching to using ReadArgs. Note that I'm doing something similar for Linux itself - I don't get argc and argv from the stack - at least not as a first preference. I try /proc/pid/cmdline first instead - which normally always exists. That allows PDOS/386 to run certain Linux programs without needing to construct the odd stack.


Ok so $4 is also known as ABSEXECBASE. It's the only consistent address in the whole Amiga OS. What I don't know iss why the OS just didn't pass it in a register and avoid using a 68000 vector. But the OS does use it on reboot. So you just need to read the pointer at $4 and store it as ExecBase.

For arguments A0/D0 can be saved as well. But keep in mind it's just a string. Address and length. The C lib would read it and split it into an array of arg vectors. I've written ASM macros in the past that did this.

You could also access it from the process CLI structure. That would avoid relying on registers. But again it's just a string that needs splitting. Unlike what I read about /proc/pid/cmdline containing null bytes. That looked like a bad idea when I read it at first. Using a null terminator as delimiter in a string.

Quote:
I could put the (alternative to) the number 4 on the stack, which would allow standard C code to read it, but I would still need a flag of some sort to indicate that an alternative ExecBase has been provided. So the high bit in D0 seems to be as good as anything else, and I'm stuck with needing assembler code. Or does AmigaOS already put something on the stack that I could rely on and detect? Or any other technique?


Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel. You could save it or stack but it's always the same. Good idea to cache it as $4 is in chip RAM and incurs a slight penalty.

So, AmigaOS or the AmigaDOS startup code doesn't stack anything for you. The AmigaOS ABI doesn't work that way. All OS functions take parameters in registers. In this respect it's somewhat like a RISC ABI. The 68000 provides 8 data and almost 8 address registers for use. The OS uses them. The only main exception is Intuition hooks where message data for lists is pushed to stack. And some other esoteric functions. Plus most C compilers would use stack based calling conventions.

Quote:
All those scenarios are possible depending on what user requirements are. However, the one that I am more likely to code personally is the one that uses AmigaDOS as a glorified BIOS. Because I may not be able to access the hard disks from PDOS otherwise, because the hard disks may require device drivers that are no longer supported and that there is no source code for. Replacing that for every bit of hardware is not really something I wish to do. Perhaps if there was a user requirement and a user willing to pay for development of that. But for me as a hobbyist - unlikely.


Okay I can understand that. Well, the kernel is there to provide all that, so you might as well use it. So you have two basic ways about it. You could create a boot disk that has boot code to boot strap PDOS. That allows you to take over instantly. But also be able to use OS to read in disk blocks. From your own file system. Of course, though nice for testing, not very practical relying on floppy.

The other way is for PDOS to be a shell. It simply runs as a command on startup and can take over that way. Cover disk menus also did this. The user can exit back DOS. Or run it independently. This would make use of Amiga filesystem and could be installed to a bootable partition at will. Either way this would be hosted but making use of core OS components. It is called PDOS and in this case AmigaPDOS so obviously a DOS interface and not entire OS replacement. It can customise a console to run inside a PDOS window.

So drivers. This would be the easy bit. Device drivers for most hardware are added by the OS from the Zorro card ROMs. Plug and play so to speak. You just need to know the device driver name. There is Exec name and DOS name. Reverse name look ups from DOS name to Exec name are convoluted for some reason. Unless you need to write directly to disk blocks you don't need it. DOS is enough to read files from and SYS: is always assigned as boot volume. The only concern is 68040 and up need CPU libraries or it can crash.

At this point, since you are still working on it, is how a PDOS binary will interface with PDOS. You could provide a PDOS library that all PDOS binaries open on startup. Standard Amiga binaries could be tested that way. But, the intention is for ELF binaries, so obviously this needs to executed by a PDOS shell. In that case you have full control over how PDOS passes itself. You will need an ELF loader as well. And I imagine a pass through for standard hunk binaries if that is supported. The user may be confused if running an Amiga binary doesn't work. But same user would be aware they are running in PDOS.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
So you just need to read the pointer at $4 and store it as ExecBase.

No, I can't do that, because absolute address 4 may not be available for me to use on an Atari etc etc.

Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel.
[/quote]
When run on Atari, or Linux, I am "rewriting core kernel" - there is no alternative - the Amiga doesn't exist at all.

Anyway, here is the current state:

[kerravon@paul-pinebook xxx]$ qemu-m68k ./bios.exe pdptest.exe "abc def"

bios starting
about to execute program with entry point C080202C
welcome to pdptest
main function is at C0802200
allocating 10 bytes
in callocmem
m1 is C0CC7008
allocating 20 bytes
in callocmem
m2 is C0CC8008
stack is around C07FFE70
printing arguments
argc = 4
arg 0 is <UNKNOWN>
arg 1 is <pdptest.exe>
arg 2 is <abc>
arg 3 is <def>
Segmentation fault (core dumped)
[kerravon@paul-pinebook xxx]$

I'll investigate the remaining things "tomorrow". Source is in sourceforge and those two executables are available as an attachment on the other forum I mentioned previously.

So that's the Amiga emulator.

Now on to PDOS-generic for the 68000 which could run under Amigados as an example ...

Quote:

At this point, since you are still working on it, is how a PDOS binary will interface with PDOS. You could provide a PDOS library that all PDOS binaries open on startup.

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.

If there was a reason to there could be an alternate interface, but that's what I use on all environments (e.g. 80386).

Go to top

  Register To Post

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project