Which compiler should I use?
adric22
the VGA card (mostly using text mode and maybe mode 13 graphics)
I used to write stuff for DOS years ago using Borland Pascal and C++.
The only half-way modern tool I can find now is DJGPP and I've
installed it but I'm baffled on how to use it being that it uses
DPMI. I need to be able to read/write directly to video memory.
Am I better off just getting an old version of Borland C++ ??
Rugxulo
On Sep 3, 3:51 pm, adric22 <adri...@yahoo.com> wrote:
>
> I want to write a program for MS-DOS that will be writing directly to
> the VGA card (mostly using text mode and maybe mode 13 graphics)
>
> I used to write stuff for DOS years ago using Borland Pascal and C++.
> The only half-way modern tool I can find now is DJGPP and I've
> installed it but I'm baffled on how to use it being that it uses
> DPMI.
Modern as in C++ features? Yes, it's much better than Borland.
The .EXEs aren't as small, but a lot of that is due to extra
functionality (LFNs, symlinks, POSIX). Besides, UPX is your
friend. ;-)
> I need to be able to read/write directly to video memory.
See one of the DJGPP Doom clones or Quake, e.g. nearptr. You can
indeed write directly to memory, but it disables protection (I think).
And that doesn't work at all under WinNT and derivatives (e.g. WinXP).
Also see the FAQ and news://comp.os.msdos.djgpp (and sys/farptr.h, sys/
nearptr.h, sys/movedata.h).
http://www.delorie.com/djgpp/v2faq/
http://eternity.mancubus.net/ee-old/ (Eternity, uses Allegro
and nearptr)
http://www.doomworld.com/idgames/index.php?id=12508 (CDoom, no
Allegro, only one that worked on XP for me)
http://free.doomers.org/
http://www.nongnu.org/freedoom/
> Am I better off just getting an old version of Borland C++ ??
Seriously, that's possible and entirely reasonable although personally
I think OpenWatcom (see news://openwatcom.users.c_cpp) might be a
better choice (while I still think DJGPP is worth using). It really
depends on what features you want/need and how much memory you'll use.
P.S. Allegro is very useful but seems to have regressed a bit since
4.0, and DOS support was dropped completely after 4.2.2. I think 3.12
might be "good enough" (or even explicitly required for most old Doom
ports), but honestly that situation just plain sucks. :-/
adric22
of sorts. I want to essentially clone the original Commodore 64 BASIC
interpreter and kernel/screen editor to run on X86 platform. At
first, I want to create a DOS executable that will actually run in DOS
with all direct hardware writes. Over time the goal is to make it
actually work from the boot sector of a hard drive.
The trouble I'm running into is that most of these new compilers that
say they work for DOS actually create WIN32 executables that will not
work under DOS, or they want to use DPMI, nor will they allow direct
memory writes (such as writing to the screen). The problem with the
older compilers seems to be that they do not come with an integrated
IDE for some reason and don't seem to be well supported or documented
on the web. So I need the executable to me small and efficient, as
well as work in a pure DOS environment.
Also an IDE that actually works in DOS too would be nice because I run
a Mac and I'll be using DOSBox as my experimental platform and it
would be easier just to do all the coding, compiling, and testing
inside DOSBox.
Rugxulo
On Sep 3, 9:42 pm, adric22 <adri...@yahoo.com> wrote:
>
> Let me clarify a bit. I am planning to write a new operating system
> of sorts. I want to essentially clone the original Commodore 64 BASIC
> interpreter and kernel/screen editor to run on X86 platform.
VICE for DOS compiles with DJGPP. Heck, even Frotz (Z machine
interpreter) has a DJGPP port. And Ardi's Executor was an old Mac
68000 emulator (now open sourced on Github) also using DJGPP. Similar
with Atari800, etc. So DJGPP is indeed possible for these sorts of
things.
> At first, I want to create a DOS executable that will actually run in DOS
> with all direct hardware writes. Over time the goal is to make it
> actually work from the boot sector of a hard drive.
Well that's a whole other thing entirely. Not saying it can't be done
(Rod P. can probably point you to some tips for COFF booting), but
it's a lot harder, to say the least! (One guy even got Turbo C to
compile for Linux/ELKS, so anything's possible.)
> The trouble I'm running into is that most of these new compilers that
> say they work for DOS actually create WIN32 executables that will not
> work under DOS, or they want to use DPMI, nor will they allow direct
> memory writes (such as writing to the screen).
I can't think of any compiler that claims "DOS" but really means
Win32. Perhaps you mean the "[MS-]DOS console" misnomer.
DPMI is just an API for protected mode on top of DOS, mainly so that
multiple apps (or just running DOS apps atop Windows or OS/2) can work
together peacefully. There really is no alternative under Windows for
32-bit protected mode DOS programs, esp. since VCPI (via EMM386, e.g.
Desqview) is way more deprecated than DPMI (e.g. DR-DOS, Win 3.0 and
newer, etc).
> The problem with the
> older compilers seems to be that they do not come with an integrated
> IDE for some reason and don't seem to be well supported or documented
> on the web. So I need the executable to me small and efficient, as
> well as work in a pure DOS environment.
Turbo C 2.01 and Turbo C++ 1.01 are freeware and both come with IDEs
(and the latter is much better, IMHO). OpenWatcom has a vi clone for
DOS too, but it's not quite an IDE. (There is a third-party tool
called PVIDE that may work well for you.) RHIDE is deprecated but
works well for most DJGPP people (and includes a built-in debugger
which DJGPP's Emacs lacks).
ftp://ftp.simtel.net/pub/simtelnet/msdos/pgmutl/pvide50.zip
ftp://ftp.simtel.net/pub/simtelnet/msdos/pgmutl/pvidesrc.zip
Actually, CC386 has Infopad, which isn't quite an IDE but good enough.
Maybe you'll approve of that. Probably easier to use in some ways
(although it basically uses NASM and the same extenders as
OpenWatcom).
http://ladsoft.tripod.com/cc386.htm
> Also an IDE that actually works in DOS too would be nice because I run
> a Mac and I'll be using DOSBox as my experimental platform and it
> would be easier just to do all the coding, compiling, and testing
> inside DOSBox.
Argh. Here's the problem: DOSBox is slow and buggy and only meant
for games. And some IDEs use Ctrl-F9 (which obviously doesn't work
well in DOSBox). A better, faster solution is probably VirtualBox,
which is fast and works pretty well (mostly), but it might be more
difficult to get a DOS install set up properly with a lot of tedious
file copying.
EDIT: Here's the most likely solution (which I almost forgot about):
FreePascal. You mentioned Borland Pascal, and FPC is heavily
compatible with it. FPC is portable to a ton of OSes, even DOS, and
the DOS IDE has a debugger built-in. In fact, it's heavily maintained
(hi, marcov!), and the FreeBSD guy (hi, marcov!) often browses DOS
forums (e.g. BTTR or FreeBASIC) as well as the obvious Pascal
newsgroups. It should do pretty much everything you want. I forget
exactly, but there are several OSes written (or being written) in
FreePascal. I'm sure you could even cross-compile for DOS via Mac OS X
if you really wanted.
Good luck! :-)
adric22
night and got it to work under DOSBox on my Mac. I like virtualbox,
but the trouble is my machines at home are PowerPC and so DosBox is
about the only choice I have. And I'll be doing a lot of the coding
at work in my spare time, but at work I use Windows XP. So I sort of
need a platform that is portable between the two, and I'd like to have
the same tools available when coding at work and home. So that is
sort of why I figure DosBox would be the best solution.
I used to be a wizard in Pascal but that was like 15 years ago. I
barely remember how to use it (I'm sure a quick refresher wouldn't
take long) but I really didn't give it much thought because I thought
the world had moved on from Pascal in the same way it had moved on
from things like Cobol. I figured if there was any chance of anyone
adding to my work, it should at least be in C. Actually, what I
used to do years ago when I wanted to write really good code in Pascal
is I would write the main portions of the program in Pascal, then I
would go to each subroutine and convert it to ASM since the compiler I
used could also take inline assembly for subroutines. Eventually I'd
have the whole thing converted to ASM and then I could recompile with
TASM and get a very small, efficient file without having the headache
of trying to design and test the whole program in ASM. I was sort
of thinking of trying the same thing with C, only I haven't tried yet
to see if Turbo C supports inline assembly.
As for the compilers writing windows code.. I'm not sure, but when I
try to compile using Borland C 55, if I try to run the program in
Virtualbox is gives me the usual message "this program cannot be run
in DOS mode" or something to that effect. But it runs fine under the
Windows command prompt as long as I don't use any direct memory
writes. Of course if I do include any direct screen writes, then the
whole thing crashes and I get the little window pop up telling me the
program has encountered an error and asks if I'd like to send or not
send the crash report. So for what I'm trying to accomplish, the
command-prompt under windows will probably not work. The thing I
don't understand, though, is that older programs that do have direct
screen writes seem to run under windows command prompt. But somehow
Windows seems to know and provide some kind of emulation. And I
suppose I could always use BIOS calls for my screen writes, but that
will be too slow in the long run.
Peter Schepers
adric22 <adr...@yahoo.com> wrote:
>
>The trouble I'm running into is that most of these new compilers that
>say they work for DOS actually create WIN32 executables that will not
>work under DOS, or they want to use DPMI, nor will they allow direct
>memory writes (such as writing to the screen). The problem with the
>older compilers seems to be that they do not come with an integrated
>IDE for some reason and don't seem to be well supported or documented
>on the web. So I need the executable to me small and efficient, as
>well as work in a pure DOS environment.
I have always used the Watcom compiler (http://www.openwatcom.org). It can
produce DOS-only executables, DPMI is optional. It has no IDE for DOS, but
I used to use Semware's QEdit 3 for DOS. Now I always use my own 64Copy as
my IDE with some BAT files to compile parts of or the whole project I'm
working on.
I did use Borland Turbo C when I first got into coding, but Watcom
produced much smaller and faster executables. Watcom just takes some
getting used to.
---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://www.64copy.com
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 36347 | on this planet. Too bad!
Rugxulo
On Sep 4, 7:12 am, adric22 <adri...@yahoo.com> wrote:
>
> Thank you for all of your help. I actually played with Turbo C last
> night and got it to work under DOSBox on my Mac. I like virtualbox,
> but the trouble is my machines at home are PowerPC and so DosBox is
> about the only choice I have. And I'll be doing a lot of the coding
> at work in my spare time, but at work I use Windows XP. So I sort of
> need a platform that is portable between the two, and I'd like to have
> the same tools available when coding at work and home. So that is
> sort of why I figure DosBox would be the best solution.
Well, I suspect you could also try QEMU as it's portable. I'm not sure
how fast it would be, but I'd doubt it'd be slower than DOSBox (which
at present needs a very fast machine just to emulate a 486).
> I used to be a wizard in Pascal but that was like 15 years ago. I
> barely remember how to use it (I'm sure a quick refresher wouldn't
> take long) but I really didn't give it much thought because I thought
> the world had moved on from Pascal in the same way it had moved on
> from things like Cobol.
Far from true as there are many Pascal programmers today, but they use
Delphi / Object Pascal mostly. FreePascal 2.2.2 and GNU Pascal 3.4.4
(needs GCC) both exist, but Virtual Pascal is still available too
(even if no longer developed). FPC has the best Borland support, I
think.
> I figured if there was any chance of anyone
> adding to my work, it should at least be in C. Actually, what I
> used to do years ago when I wanted to write really good code in Pascal
> is I would write the main portions of the program in Pascal, then I
> would go to each subroutine and convert it to ASM since the compiler I
> used could also take inline assembly for subroutines. Eventually I'd
> have the whole thing converted to ASM and then I could recompile with
> TASM and get a very small, efficient file without having the headache
> of trying to design and test the whole program in ASM. I was sort
> of thinking of trying the same thing with C, only I haven't tried yet
> to see if Turbo C supports inline assembly.
The freeware versions of TC do support inline asm, but you have to
have a separate assembler program. The default is TASM, which isn't
included, but you can use the Arrowsoft Assembler if you use "-
Easm.exe" on the commandline. OpenWatcom also supports inline asm, and
it has both an internal assembler built into the compiler and external
(and supports more than just 286 opcodes). OW also has better C++
support, if that matters to you.
> As for the compilers writing windows code.. I'm not sure, but when I
> try to compile using Borland C 55, if I try to run the program in
> Virtualbox is gives me the usual message "this program cannot be run
> in DOS mode" or something to that effect. But it runs fine under the
> Windows command prompt as long as I don't use any direct memory
> writes.
I haven't tried it, but it's true that 5.5 is Win32 only. Technically,
there are ways to get it and its output to work in DOS (WDOSX or HX),
but that's probably not the compiler for you.
Kevin G. Rhoads
>at work in my spare time, but at work I use Windows XP.
If the processor is a dual-core, Microsoft VM will run well
and you can boot DOS 2.0-6.22 from a virtual floppy. Boot
floppy images can be gotten from several places, or I
could e-mail you one (I do NOT recommend anything lower
than v5 for serious dev work)
As for tools, OpenWatcom or the offerings from the Borland
Community Museum would be my choice for DOS dev if I didn't
still have all my other 16 bit dev tools.
Sincerely
Kevin
Kevin G. Rhoads
>try to compile using Borland C 55
The last Borland C/C++ product was BC 5.02, anything that says CBuilder
or has a number higher than 5.02 is 32 bit only.
For 16 bit dev with Borland C or C/C++, and of the TurboC, TurboC++ 1 or 2,
BorlandC 3.x, 4.x or 5.0/5.01/5.02 -- with the caveat that overlay support
was broken in BC 5 (a TLINK bug IIRC)
TC 2.0 and TCPP 1.0 (which is later than TC 2) are available from the Borland
Community Museum, BC 4.x and BC 5.x can be found on eBay.
adric22
DOS Box and Turbo C. I may eventually move to virtualbox and use
Virtual-PC on my mac. but for the moment DosBox is working fine. I
don't need a lot of speed for what I'm doing.
So far this morning I have created several hundred lines of code and I
have a working screen-editor to some extent. It took me forever to
figure out how to get Turbo C to write directly to the screen
memory.
The problem I'm having now is reading the keyboard. None of the
commands I've found so far will allow me to detrmine if SHIFT or
Control are being held down. I haven't found a way to scan the
keyboard hardware directly.
Another problem I've run into is the inline assembly. turbo C won't
allow it inside the IDE, but supposively it works from the command
prompt. Trouble is, that is very inconvenient to do everything from
the command prompt, that is why I wanted an IDE.
The reason the inline assembly is a problem at the moment is that I
can't find documentation on how to achieve certain things without
using BIOS calls, and those usually require inline assembly. For
example, I need to move the cursor around on the screen. Well, I have
figured out how to do that by writing directly to the VGA card. But I
haven't figured out how to change to graphics mode or other text modes
yet.
Rugxulo
On Sep 4, 11:23 am, adric22 <adri...@yahoo.com> wrote:
>
> The problem I'm having now is reading the keyboard. None of the
> commands I've found so far will allow me to detrmine if SHIFT or
> Control are being held down. I haven't found a way to scan the
> keyboard hardware directly.
I'm sure it's trivial, but I don't know offhand.
> Another problem I've run into is the inline assembly. turbo C won't
> allow it inside the IDE, but supposively it works from the command
> prompt. Trouble is, that is very inconvenient to do everything from
> the command prompt, that is why I wanted an IDE.
Like I said, it expects TASM, but you can substitute Arrowsoft ASM.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/arrow/arrow20c.zip
Just rename "asm.exe" to "tasm.exe", and it will then work from the
IDE too.
--------------------------------------------------
#include <stdio.h>
#include <conio.h>
int main() {
clrscr();
asm { xor ax,ax
int 16h
}
return 0;
}
--------------------------------------------------
Tested and works.
> The reason the inline assembly is a problem at the moment is that I
> can't find documentation on how to achieve certain things without
> using BIOS calls, and those usually require inline assembly.
No, you can also use int86() instead. See the online help (Shift+F1).
(example given in help):
------------------------------
#include <stdio.h>
#include <conio.h>
#include <dos.h>
#define VIDEO 0x10
void movetoxy(int x, int y)
{
union REGS regs;
regs.h.ah = 2; /* set cursor position */
regs.h.dh = y;
regs.h.dl = x;
regs.h.bh = 0; /* video page 0 */
int86(VIDEO, ®s, ®s);
}
int main(void)
{
clrscr();
movetoxy(35, 10);
printf("Hello\n");
return 0;
}
------------------------------
Alex Russell
> I appreciate all the help. At the moment I sort of settled on using
> DOS Box and Turbo C. I may eventually move to virtualbox and use
> Virtual-PC on my mac. but for the moment DosBox is working fine. I
> don't need a lot of speed for what I'm doing.
>
> So far this morning I have created several hundred lines of code and I
> have a working screen-editor to some extent. It took me forever to
> figure out how to get Turbo C to write directly to the screen
> memory.
some code for this in common.zip, below
>
> The problem I'm having now is reading the keyboard. None of the
> commands I've found so far will allow me to detrmine if SHIFT or
> Control are being held down. I haven't found a way to scan the
> keyboard hardware directly.
There are bios calls to read the last scan code, and the bios keeps the
last key pressed in memory, and the bios maintains flags for some key
states:
Ralf Brown's Interrupt list will have more info.
BIOS memory areas, at 0400h:
417h keyboard status
bits
0 right shift key is down
1 left shift key is down
2 ctrl is down
3 alt is down
4 scroll lock status
5 num lock status
6 caps lock status
7 insert status
418h has more flags
41ah / 41bh word pointing to start of keyboard circular buffer buffer
(where in the buffer the head is)
41ch / 41dh end if the buffer
41e / 43d the keyboard buffer. the previous two words point into this buffer
>
> Another problem I've run into is the inline assembly. turbo C won't
> allow it inside the IDE, but supposively it works from the command
> prompt. Trouble is, that is very inconvenient to do everything from
> the command prompt, that is why I wanted an IDE.
>
batch files and make will streamline the process.
> The reason the inline assembly is a problem at the moment is that I
> can't find documentation on how to achieve certain things without
> using BIOS calls, and those usually require inline assembly. For
> example, I need to move the cursor around on the screen. Well, I have
> figured out how to do that by writing directly to the VGA card. But I
> haven't figured out how to change to graphics mode or other text modes
> yet.
int86() and other similar TC functions will let you make bios and dos calls.
TC/BC code
/* ----------------------- move_cursor() ---------------- January 13,1991 */
void move_cursor(int x, int y)
{
union REGS inregs, outregs;
inregs.h.ah=0x02;
inregs.h.dh=(char)y;
inregs.h.dl=(char)x;
inregs.h.bh=(char)0; /* page number */
int86(0x10, &inregs, &outregs);
}
http://www3.telus.net/alexander_russell/
look for common.zip
has examples of
reading/writing directly to the screen in c and asm dtext.c dtextc.c
puttext.c - reading and writing rectangular patches of the text screen
keyboard code: key.c - read raw scan codes
keyboard - stuffngo.c - how to put text into the BIOS keyboard buffer
without using bios
pr2.c - read/write to an MDA text only video card.
Alex R
Dr J R Stockton
9...@r39g2000yqm.googlegroups.com>, Thu, 3 Sep 2009 13:51:25, adric22
<adr...@yahoo.com> posted:
Borland Pascal should do nicely. It can be used at the Command Prompts
of Win98 & WinXP, as well as in pure DOS.
Long ago, I wrote a partial LSI-11 emulator with Turbo Pascal, perhaps
versions 4 or 5, using a PPC640 computer with 640K RAM and 2 1.44 MB
FDDs. It implemented that part of the instruction set used by a
particular program, with substituted I/O.
If the CRT unit is used, the DELAY routine needs to be fixed. I use
Pedt Scragg's fix, or, on an extant EXE, Andreas Bauer's patch - see
<URL:http://www.merlyn.demon.co.uk/pas-r200.htm> .
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
mike
with Turbo C style IDE. Don't get hooked on the Turbo C/C++/Pascal
syntax - this is about learning some techniques that you can possibly
apply in the future (and with other compilers too!) isn't it?
If your want to maximize your speed and executable's size, you'll
eventually need an assembler like 'nasm' (16-bit DOS version) or
'fasm' .
Set AH=00 , AL=13h , call INT 10, 0 to set video mode (mode 13h,
320x200, 256 color).
Go here for Pacific C Compiler:
http://staticchaos.co.nr/pacific.html
I actually wrote a long detail message for this thread but my browser
crashed - what're ya gonna do?