I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to get the file 8080.c compiled to work with MS-DOS, and was wondering if someone here can compile it for me ( also explain the steps ).

8080.c located here at MSN OneDrive
https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I

Thanks and
Merry Christmas
-- William Gallant

On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:

> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
> get the file 8080.c compiled to work with MS-DOS, and was wondering if
> someone here can compile it for me ( also explain the steps ).

Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
to the compiler's modern response to K&R style code, but the source code
compiles OK.

What sort of problems are you having compiling this code?
--
Lew Pitcher
"In Skills, We Trust"

On Monday, December 20, 2021 at 5:46:35 PM UTC-5, Lew Pitcher wrote:
> On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:
>
> > I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
> > get the file 8080.c compiled to work with MS-DOS, and was wondering if
> > someone here can compile it for me ( also explain the steps ).
> Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
> Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
> to the compiler's modern response to K&R style code, but the source code
> compiles OK.
>
> What sort of problems are you having compiling this code?
> --
> Lew Pitcher
> "In Skills, We Trust"

The only error is
line 135 - cannot cast int() ro void *(int)

when i use tcc ( tiny c compiler ) on Windows 11 under PowerShell.
I don't have a linux machine. If i were to use gcc i could use mingw
but i don't have that and would rather somehow have an executable
i can run under DOSBox.
How to compile under DOSBox or powershell?

William Gallant <sigma.research@gmail.com> writes:
> On Monday, December 20, 2021 at 5:46:35 PM UTC-5, Lew Pitcher wrote:
>> On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:
>>
>> > I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
>> > get the file 8080.c compiled to work with MS-DOS, and was wondering if
>> > someone here can compile it for me ( also explain the steps ).
>> Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
>> Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
>> to the compiler's modern response to K&R style code, but the source code
>> compiles OK.
>>
>> What sort of problems are you having compiling this code?
>
> The only error is
> line 135 - cannot cast int() ro void *(int)
>
> when i use tcc ( tiny c compiler ) on Windows 11 under PowerShell.
> I don't have a linux machine. If i were to use gcc i could use mingw
> but i don't have that and would rather somehow have an executable
> i can run under DOSBox.
> How to compile under DOSBox or powershell?

Can you show us the *exact* (copy-and-pasted) error message? There's at
least one typo in what you showed us. Other descrepancies might be critical.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

William Gallant <sigma.research@gmail.com> writes:
> On Monday, December 20, 2021 at 5:46:35 PM UTC-5, Lew Pitcher wrote:
>> On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:
>>
>> > I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
>> > get the file 8080.c compiled to work with MS-DOS, and was wondering if
>> > someone here can compile it for me ( also explain the steps ).
>> Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
>> Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
>> to the compiler's modern response to K&R style code, but the source code
>> compiles OK.
>>
>> What sort of problems are you having compiling this code?
>
> The only error is
> line 135 - cannot cast int() ro void *(int)
>
> when i use tcc ( tiny c compiler ) on Windows 11 under PowerShell.
> I don't have a linux machine. If i were to use gcc i could use mingw
> but i don't have that and would rather somehow have an executable
> i can run under DOSBox.
> How to compile under DOSBox or powershell?

Line 135 is:

signal(SIGTERM, exit);

Since the code doesn't #include <stdlib.h>, the compiler (following old
rules) makes assumptions about how the exit function is declared.

The code has a lot of constructs that are syntax errors or constraint
violations in modern C (1999 or later). Most of them trigger non-fatal
warnings in gcc, which is designed to tolerate old-style code by
default, but some compilers might be more picky. There's no particular
reason to expect that tcc won't treat something as a fatal error if gcc
lets it go with a non-fatal warning.

If I wanted to build and use this, I'd start by adding any required
#include directives (particularly for <stdlib.h>), specifying return
types for all functions, and converting old-style function definitions
to use prototypes.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 20/12/2021 22:36, William Gallant wrote:
> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to get the file 8080.c compiled to work with MS-DOS, and was wondering if someone here can compile it for me ( also explain the steps ).
>
> 8080.c located here at MSN OneDrive
> https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I

This is appalling code. Clearly people weren't fans of declarations when
it was written, and didn't care whether functions returned values or not.

I've done some fixes so that it compiles with gcc and tiny c:

https://github.com/sal55/langs/blob/master/8080b.c

But there are some either some includes missing, or declarations:

getopt

I've added an assumed declaration for getopt(). (Also for gets(),
because one of the three compilers I tested didn't know it; you can
comment that out.)

There is also SIGTERM etc from line 144; I just commented these out.

With SIGTERM etc commented out:

Tcc compiles it but getopt, opterr, optarg are undefined when linking.

Somehow, gcc manages to compile and link it. When I run it, it says:

8080: program halted at 0000

I suspect that it assume that 'long' is wide enough for a pointer; I
suggest compiling with -m32 just in case.

For the exact cut and paste error after
trying compilation with tcc under Windows 11 ---

8080.c:135: cannot cast 'int()' to 'void *(int)'

A few years ago i also tried to experiment with "blotting out"
the calls to signal() SIGTERM, SIGQUIT, SIGHUP, SIGINT
and substituting some makeshifts but i gave up.

Bart <bc@freeuk.com> writes:
> On 20/12/2021 22:36, William Gallant wrote:
>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01
>> to get the file 8080.c compiled to work with MS-DOS, and was
>> wondering if someone here can compile it for me ( also explain the
>> steps ).
>> 8080.c located here at MSN OneDrive
>> https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I
>
> This is appalling code. Clearly people weren't fans of declarations
> when it was written, and didn't care whether functions returned values
> or not.

The code was written in 1990, when ANSI C compilers were not widely
available. The author couldn't assume that either the void type or
function prototypes were available. Given those limitations, it's not
too bad.

> I've done some fixes so that it compiles with gcc and tiny c:
>
> https://github.com/sal55/langs/blob/master/8080b.c
>
> But there are some either some includes missing, or declarations:
>
> getopt

getopt is declared in <unistd.h>, and is specified by POSIX.
The code apparently isn't intended for non-POSIX systems (or, when it
was written, non-Unix-like systems).

> I've added an assumed declaration for getopt(). (Also for gets(),
> because one of the three compilers I tested didn't know it; you can
> comment that out.)

Just replace the gets() call with a call to fgets(). It only looks at
the first charater entered, so the differing treament of newline
characters doesn't matter. Even before it was removed from the
language, gets() was dangerous.

> There is also SIGTERM etc from line 144; I just commented these out.

SIGTERM is defined in <signal.h>, and is specified by the C standard.
Does your implementation not have it?

> With SIGTERM etc commented out:
>
> Tcc compiles it but getopt, opterr, optarg are undefined when linking.
>
> Somehow, gcc manages to compile and link it. When I run it, it says:
>
> 8080: program halted at 0000
>
> I suspect that it assume that 'long' is wide enough for a pointer; I
> suggest compiling with -m32 just in case.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:

> On 20/12/2021 22:36, William Gallant wrote:
>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01
>> to get the file 8080.c compiled to work with MS-DOS, and was
>> wondering if someone here can compile it for me ( also explain the
>> steps ).
>> 8080.c located here at MSN OneDrive
>> https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I
>
> This is appalling code. Clearly people weren't fans of declarations
> when it was written, and didn't care whether functions returned values
> or not.

This is C as it was -- K&R C. There was no void. No function
prototypes. No return type (in fact any declaration with not type)
defaulted to int.

It's not the oldest K&R C -- there are unsigned types, typdefs and
compound assignments which are the modern way round (+= rather than
=+) -- but without a bang up to date compiler, this is what you used.

Mind you, ANSI C (later ISO C90), kept a lot of that for backwards
comparability, so one could say it is written in "old" C90.

> I've done some fixes so that it compiles with gcc and tiny c:
>
> https://github.com/sal55/langs/blob/master/8080b.c

It compiles with no changes on my Linx laptop. But I suspect there is
trouble ahead...

--
Ben.

Compiling the "8080b.c" using tcc
with signals() commented out and fgets replacing gets
on Windows 11 machine gives this error:

8080b.c:133: incompatible types for redefinition of 'fgets'

I set up Ubunto 20.04.3 under Oracle VM and tried gcc using the
same 8080b.c and the reply was:

wfg@wfg-VirtualBox:~/empl$ gcc 8080b.c
8080b.c:133:7: error: conflicting types for ‘fgets’
133 | char* fgets(char*);
| ^~~~~
In file included from 8080b.c:16:
/usr/include/stdio.h:564:14: note: previous declaration of ‘fgets’ was here
564 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
| ^~~~~
8080b.c: In function ‘load_file’:
8080b.c:248:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
248 | fprintf(stderr, "8080: error reading file, cnt = %d\n",
| ~^
| |
| int
| %ld
249 | cnt);
| ~~~
| |
| long int
wfg@wfg-VirtualBox:~/empl$

I seem to understand what's going on, i just don't have the knowledge
in my head to figure the solution in a short time. Might take me quite some time.
-- William

William Gallant <sigma.research@gmail.com> writes:

> Compiling the "8080b.c" using tcc
> with signals() commented out and fgets replacing gets

There's no need to do that. Include <stdlib.h> and change

interr()

to

void interr();

(Later, you can add int to the ()s, but the above is the minimum change
that will remove the type error.)

> on Windows 11 machine gives this error:
>
> 8080b.c:133: incompatible types for redefinition of 'fgets'

Don't do that! You can't swap function about unless you know hat they
do and how. gets is bad, but leave it in until you know how to fix
problem.

> I set up Ubunto 20.04.3 under Oracle VM and tried gcc using the
> same 8080b.c and the reply was:
>
> wfg@wfg-VirtualBox:~/empl$ gcc 8080b.c
> 8080b.c:133:7: error: conflicting types for ‘fgets’
> 133 | char* fgets(char*);
> | ^~~~~
> In file included from 8080b.c:16:
> /usr/include/stdio.h:564:14: note: previous declaration of ‘fgets’ was here
> 564 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
> | ^~~~~
> 8080b.c: In function ‘load_file’:
> 8080b.c:248:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
> 248 | fprintf(stderr, "8080: error reading file, cnt = %d\n",
> | ~^
> | |
> | int
> | %ld
> 249 | cnt);
> | ~~~
> | |
> | long int

Yes, just change the %d to %ld.

> wfg@wfg-VirtualBox:~/empl$
>
> I seem to understand what's going on, i just don't have the knowledge
> in my head to figure the solution in a short time. Might take me quite some time.

Getting it to compile is one thing, but with "old C" there are often a
lot of assumptions being made, and it's also easy for the code to do
things that work on one system but break badly on another.

--
Ben.

On 21/12/2021 01:56, William Gallant wrote:
> Compiling the "8080b.c" using tcc
> with signals() commented out and fgets replacing gets
> on Windows 11 machine gives this error:
>
> 8080b.c:133: incompatible types for redefinition of 'fgets'
>
> I set up Ubunto 20.04.3 under Oracle VM and tried gcc using the
> same 8080b.c and the reply was:
>
> wfg@wfg-VirtualBox:~/empl$ gcc 8080b.c
> 8080b.c:133:7: error: conflicting types for ‘fgets’
> 133 | char* fgets(char*);
> | ^~~~~

You need remove that declaration of fgets() (which you changed from
gets()). I shouldn't have put it in (the 3rd compiler I used needed it).

However, changing gets to fgets elsewhere won't work; fgets uses
entirely different arguments from those used here for gets.

gets is not ideal, but just leave it; gcc and tcc should still have it.

> In file included from 8080b.c:16:
> /usr/include/stdio.h:564:14: note: previous declaration of ‘fgets’ was here
> 564 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
> | ^~~~~
> 8080b.c: In function ‘load_file’:
> 8080b.c:248:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
> 248 | fprintf(stderr, "8080: error reading file, cnt = %d\n",
> | ~^
> | |
> | int
> | %ld

I wouldn't worry about this one; on Windows both int and long are the
same size anyway. Or just change the format to "%ld".

tcc on windows now only gives:

tcc: undefined symbol 'opterr' --- Line 157
tcc: undefined symbol 'getopt' --- Line 132
tcc: undefined symbol 'optarg' --- Line 158

They seem to be defined ???

--- William

Bart <bc@freeuk.com> writes:
> On 21/12/2021 01:56, William Gallant wrote:
>> Compiling the "8080b.c" using tcc
>> with signals() commented out and fgets replacing gets
>> on Windows 11 machine gives this error:
>> 8080b.c:133: incompatible types for redefinition of 'fgets'
>> I set up Ubunto 20.04.3 under Oracle VM and tried gcc using the
>> same 8080b.c and the reply was:
>> wfg@wfg-VirtualBox:~/empl$ gcc 8080b.c
>> 8080b.c:133:7: error: conflicting types for ‘fgets’
>> 133 | char* fgets(char*);
>> | ^~~~~
>
> You need remove that declaration of fgets() (which you changed from
> gets()). I shouldn't have put it in (the 3rd compiler I used needed
> it).
>
> However, changing gets to fgets elsewhere won't work; fgets uses
> entirely different arguments from those used here for gets.
>
> gets is not ideal, but just leave it; gcc and tcc should still have it.

No, change this line:
if (gets(buf) == NULL) exit(0);
to this:
if (fgets(buf, sizeof buf, stdin) == NULL) exit(0);
The code after that only refers to the buf[0], so fgets's different
behavior with respect to '\n' is irrelevant. (The buffer is 256 bytes
presumably to make it less likely for gets() to write past the end.)

If I were going to maintain the code I probably wouldn't use either gets
or fgets, but fgets is unambiguously better than gets. Don't teach bad
habits.

>> In file included from 8080b.c:16:
>> /usr/include/stdio.h:564:14: note: previous declaration of ‘fgets’ was here
>> 564 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
>> | ^~~~~
>> 8080b.c: In function ‘load_file’:
>> 8080b.c:248:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
>> 248 | fprintf(stderr, "8080: error reading file, cnt = %d\n",
>> | ~^
>> | |
>> | int
>> | %ld
>
> I wouldn't worry about this one; on Windows both int and long are the
> same size anyway. Or just change the format to "%ld".

No, just change the format to "%ld", which it should have been in the
first place. There's no reason to do it wrong. Don't teach bad habits.

On Windows you likely don't have getopt. This is not Windows code. (It
could probably be adapted to work on windows; there are numerous ports
of getopt.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

William Gallant <sigma.research@gmail.com> writes:
> tcc on windows now only gives:
>
> tcc: undefined symbol 'opterr' --- Line 157
> tcc: undefined symbol 'getopt' --- Line 132
> tcc: undefined symbol 'optarg' --- Line 158
>
> They seem to be defined ???

getopt and friends are declared in <unistd.h>, which is specified by
POSIX. Windows does not support this by default.

8080.c is not entirely portable code, and apparently was never intended
to be used under Windows.

It could probably be adapted without too much difficulty. If nothing
else, you could write your own code that iterates over the argv array,
or you could use any of several Unix-like emulation layers that run on
Windows.

One possible issue: If you give it an explicit file name, it opens it in
binary mode, but otherwise it reads from stdin, which is in text mode.
Binary and text modes work the same way on Unix/POSIX/Linux, but not on
Windows. I don't know enough about how it works to say what effect that
might have.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 21/12/2021 00:12, William Gallant wrote:
> On Monday, December 20, 2021 at 5:46:35 PM UTC-5, Lew Pitcher wrote:
>> On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:
>>
>>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
>>> get the file 8080.c compiled to work with MS-DOS, and was wondering if
>>> someone here can compile it for me ( also explain the steps ).
>> Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
>> Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
>> to the compiler's modern response to K&R style code, but the source code
>> compiles OK.
>>
>> What sort of problems are you having compiling this code?
>> --
>> Lew Pitcher
>> "In Skills, We Trust"
>
> The only error is
> line 135 - cannot cast int() ro void *(int)
>
> when i use tcc ( tiny c compiler ) on Windows 11 under PowerShell.
> I don't have a linux machine. If i were to use gcc i could use mingw
> but i don't have that and would rather somehow have an executable
> i can run under DOSBox.
> How to compile under DOSBox or powershell?
>

If you want to compile code for DOS, the best source of information that
I know of is the FreeDOS website, <https://www.freedos.org>.

If you want to try compiling a single piece of code in different ways,
with different compilers and/or different flags, then an extremely
useful resource is the online compiler at <https://godbolt.org>. It is
an online compiler, supporting a large number of tools (including tcc,
dozens of gcc versions, clang, MSVC, and others). You can paste your
code into it, then work on it (perhaps starting with Keith's suggestion
of using the correct include files) to improve it. And if you have
specific questions, you can copy-and-paste the errors and warnings, or
even make shareable links to snapshots of the page (including code,
compiler choices, etc.).

On 21/12/2021 03:25, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> gets is not ideal, but just leave it; gcc and tcc should still have it.
>
> No, change this line:
> if (gets(buf) == NULL) exit(0);
> to this:
> if (fgets(buf, sizeof buf, stdin) == NULL) exit(0);
> The code after that only refers to the buf[0], so fgets's different
> behavior with respect to '\n' is irrelevant. (The buffer is 256 bytes
> presumably to make it less likely for gets() to write past the end.)
>
> If I were going to maintain the code I probably wouldn't use either gets
> or fgets, but fgets is unambiguously better than gets. Don't teach bad
> habits.

The file is full of bad habits! But we're just trying to get the thing
compiled before starting to rewrite it and likely introduce extra bugs.

> No, just change the format to "%ld", which it should have been in the
> first place. There's no reason to do it wrong. Don't teach bad habits.
>
> On Windows you likely don't have getopt. This is not Windows code.

Evidently not. But there is nothing OS-specific about an application
like this. An 8080 will work the same way whatever OS the emulator runs
under.

> (It
> could probably be adapted to work on windows; there are numerous ports
> of getopt.)
>

gcc/tdm apparently can link with getopt. My version works; I just don't
have a suitable 8080 program for it.

David Brown schrieb am Dienstag, 21. Dezember 2021 um 09:13:17 UTC+1:
> On 21/12/2021 00:12, William Gallant wrote:
> > On Monday, December 20, 2021 at 5:46:35 PM UTC-5, Lew Pitcher wrote:
> >> On Mon, 20 Dec 2021 14:36:14 -0800, William Gallant wrote:
> >>
> >>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to
> >>> get the file 8080.c compiled to work with MS-DOS, and was wondering if
> >>> someone here can compile it for me ( also explain the steps ).
> >> Funny, it compiles and links well enough with gcc (GCC) 5.5.0 under 64bit
> >> Slackware Linux 14.2 (kernel 4.4.276). There's a ton of warnings relating
> >> to the compiler's modern response to K&R style code, but the source code
> >> compiles OK.
> >>
> >> What sort of problems are you having compiling this code?
> >> --
> >> Lew Pitcher
> >> "In Skills, We Trust"
> >
> > The only error is
> > line 135 - cannot cast int() ro void *(int)
> >
> > when i use tcc ( tiny c compiler ) on Windows 11 under PowerShell.
> > I don't have a linux machine. If i were to use gcc i could use mingw
> > but i don't have that and would rather somehow have an executable
> > i can run under DOSBox.
> > How to compile under DOSBox or powershell?
> >
> If you want to compile code for DOS, the best source of information that
> I know of is the FreeDOS website, <https://www.freedos.org>.
>

FreeDOS recommends crosscompilation to DOS through OpenWatcom.
Were I working on DOS, I'd probably use djgcc or even rewrite it for Turbo Pascal.

Bart <bc@freeuk.com> writes:
> On 21/12/2021 03:25, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> gets is not ideal, but just leave it; gcc and tcc should still have it.
>> No, change this line:
>> if (gets(buf) == NULL) exit(0);
>> to this:
>> if (fgets(buf, sizeof buf, stdin) == NULL) exit(0);
>> The code after that only refers to the buf[0], so fgets's different
>> behavior with respect to '\n' is irrelevant. (The buffer is 256 bytes
>> presumably to make it less likely for gets() to write past the end.)
>> If I were going to maintain the code I probably wouldn't use either
>> gets
>> or fgets, but fgets is unambiguously better than gets. Don't teach bad
>> habits.
>
> The file is full of bad habits! But we're just trying to get the thing
> compiled before starting to rewrite it and likely introduce extra
> bugs.

If you look at the way the buffer is used, there's no reason not to
replace gets() by fgets().

>> No, just change the format to "%ld", which it should have been in the
>> first place. There's no reason to do it wrong. Don't teach bad habits.
>> On Windows you likely don't have getopt. This is not Windows code.
>
> Evidently not. But there is nothing OS-specific about an application
> like this. An 8080 will work the same way whatever OS the emulator
> runs under.

That has nothing to do with using the correct format string.

>> (It
>> could probably be adapted to work on windows; there are numerous ports
>> of getopt.)
>
> gcc/tdm apparently can link with getopt. My version works; I just
> don't have a suitable 8080 program for it.

Or you could probably grab a source code implementation of getopt.
There shouldn't need be anything OS-specific in its implementation.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

If you install djgpp in DOS, the program compiles okay with no source
changes.
I

Le 20/12/2021 à 23:36, William Gallant a écrit :
> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to get the file 8080.c compiled to work with MS-DOS, and was wondering if someone here can compile it for me ( also explain the steps ).
>
> 8080.c located here at MSN OneDrive
> https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I
>
> Thanks and
> Merry Christmas
> -- William Gallant

There are quite a few 8080 emulators these days, written in more modern
and portable C. I'd really suggest looking elsewhere.

You can try that, for instance: https://github.com/richardt94/8080_emulator

On Tuesday, December 21, 2021 at 1:02:05 PM UTC-5, Guillaume wrote:
> Le 20/12/2021 à 23:36, William Gallant a écrit :
> > I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to get the file 8080.c compiled to work with MS-DOS, and was wondering if someone here can compile it for me ( also explain the steps ).
> >
> > 8080.c located here at MSN OneDrive
> > https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I
> >
> > Thanks and
> > Merry Christmas
> > -- William Gallant
> There are quite a few 8080 emulators these days, written in more modern
> and portable C. I'd really suggest looking elsewhere.
>
> You can try that, for instance: https://github.com/richardt94/8080_emulator

The particular 8080 emulator 8080.c is used to run "EMPL",
a vector only APL written by Erik Mueller.
The following archived webpage describes the entire package.

https://web.archive.org/web/20070220140130/http://www.signiform.com/erik/programs/empl/empl.htm

-- William

On 2021-12-20, William Gallant <sigma.research@gmail.com> wrote:
> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01
> to get the file 8080.c compiled to work with MS-DOS, and was wondering
> if someone here can compile it for me ( also explain the steps ).

Maybe you should find another way to run 8080 code than some .c
file from 1990.

On Github, when we enter the search query "8080 emulator", there are
467 repository hits.

Chances seem good that at least one thing in there is useful.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>On 2021-12-20, William Gallant <sigma.research@gmail.com> wrote:
>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01
>> to get the file 8080.c compiled to work with MS-DOS, and was wondering
>> if someone here can compile it for me ( also explain the steps ).
>
>Maybe you should find another way to run 8080 code than some .c
>file from 1990.
>
>On Github, when we enter the search query "8080 emulator", there are
>467 repository hits.
>
>Chances seem good that at least one thing in there is useful.

Indeed, there is one in the simh distribution:

/work/opensource/simh-master/Intel-Systems/common/i8080.c

On 21/12/2021 18:51, William Gallant wrote:
> On Tuesday, December 21, 2021 at 1:02:05 PM UTC-5, Guillaume wrote:
>> Le 20/12/2021 à 23:36, William Gallant a écrit :
>>> I don't know "C" well, and have tried Tiny C and the old Turbo C 2.01 to get the file 8080.c compiled to work with MS-DOS, and was wondering if someone here can compile it for me ( also explain the steps ).
>>>
>>> 8080.c located here at MSN OneDrive
>>> https://1drv.ms/u/s!Ak_7nwQxFkS7iHfKQT0cp9uDLt1I
>>>
>>> Thanks and
>>> Merry Christmas
>>> -- William Gallant
>> There are quite a few 8080 emulators these days, written in more modern
>> and portable C. I'd really suggest looking elsewhere.
>>
>> You can try that, for instance: https://github.com/richardt94/8080_emulator
>
> The particular 8080 emulator 8080.c is used to run "EMPL",
> a vector only APL written by Erik Mueller.
> The following archived webpage describes the entire package.
>
> https://web.archive.org/web/20070220140130/http://www.signiform.com/erik/programs/empl/empl.htm

I managed to get that working using these two modifications of those
programs:

https://github.com/sal55/langs/blob/master/8080b.c
https://github.com/sal55/langs/blob/master/load.c

But they will only compile and build with gcc:

gcc 8080b.c -o8080.exe
gcc load.c -oload.exe

load.exe converts empl.hex from your link to empl.bin:

C:\c>load <empl.hex
5845 bytes (range of 5808) from 0H to 16afH

C:\c>8080 -l empl.bin
EMPL 1.0
CLEAR WS
\10
\10
1 2 3 4 5 6 7 8 9 10
+%\10
+%\10
55

(gcc/TDM on Windows 10 64-bit.)