16 bit console I/O functions

[allynm]

Hello everyone,

I am searching for a 16 bit console I/O library that would perform pretty basic console reading and writing functions.  The C library is wonderfully robust but is rather larger than I need for many applications. 

I have scanned the web for about a week now and tried a view possiblities (IRVINE.lib, UCR Stdlib) but found them unsatisfactory for various reasons.

Any suggestions?

Thanks,
Mark Allyn

[jj2007]

Ralf has some suggestions.

[dedndave]

if i were in your shoes, i'd probably write my own
the source code for Irvine16 and UCR16 are both available
they may be used as a "how to perform this function" reference
then, make a library of your own that satisfies your needs

when you think about it, not that many functions are required to get started
a half-dozen console output functions
a few console input functions
a handfull of file i/o functions
maybe a few macros to save some typing

once you have the basics, you can add some math stuff, like random number generator, etc

[FORTRANS]

Hi,

   MS-DOS has character and string I/O.  The BIOS has character
I/O, cursor movement, supports character attributes (color),
string output, and scrolling.  You might look at those and write
some standard wrapper code (either macros or subroutines)
to ease their usage.  You can add DOSKEY functions for
cursor movement to edit strings.  That leaves the formatted
numeric output for you to create.

Regards,

Steve N.

[allynm]

Hi everyone,

I thought about 'Dave's suggestion as it would be a good learning experience to have to develop my own I/O.  I'm kinda lazy, of course.  As he says, there aren't a lot that are the real workhorses:  in C lingo they would be printf, gets, scanf, ftets, fscanf, fprintf, atoi, atof, and of course the non-extent (in C) itoa, and itof.  So, I don't really have an excuse.

Int 21h lets you do string I/O pretty easily, but not conversions like atoi or atof.  I'm already doing a couple of wrappers on the strings.  But, then you hit the conversion problem and with signed numbers it gets rather messy and you wind up saying "what the heck",  why not just revert to UCR or IRVINE or the C library.  I was trying to avoid this.

Regards,
Mark

[allynm]

Hello everyone,

I looked at JJ's link.  I forgot about Ralf Brown.  Very helpful.  Made me think that actually for a "lite library" all I really need is the conversion functions--  ATOF, ATOI, ITOA, and ITOF and hex equivalents.    The rest of what I'm lookiing for is basically captured by int 21h.  So, maybe the way to go is what 'Dave and Steve N. suggest:  put the int21h stuff into wrappers and roll my own conversion functions.

Regards,

Mark

[jj2007]

...and roll my own conversion functions.

There are several threads here in the forum doing conversions in 32 bit. If speed is not the ultimate goal, there are fairly simple options around.

[dedndave]

the floating point conversion functions are the only tough ones
all the others are easy

[allynm]

Hi folks,

'Dave, yes the signed and floating points are the difficult cases.  But, there are some 32 bit procs in the MASM32 library that are good models, I think.

JJ- Thanks for the link.  I'll look at it.  I was trying to do this all in 16-bit code, just for fun.  I was also trying to avoid linking to a bunch of functions that I don't need so as to be "light/bare-bones".
 
Regards,
Mark

[FORTRANS]

Hi,

   Floating point formatting is the hard one.  But it is also a good
way to start learning how to use the FPU.  Signed integers is not
too bad.  The way I saw it implemented was to test the high bit
and if negative, print a minus sign, do a twos complement of the
number, and call the unsigned number routine.

Regards,

Steve N.

[dedndave]

that is a down and dirty method
just test for overflow after you take the NEG, as 80000000h will look like a positive value   :P

[jj2007]

...as 80000000h will look like a positive value   :P

More like an illegal one, Dave :wink

cmp ax, 80000000h fails miserably

[dedndave]

oops
:lol

although - you can use 32-bit regs in 16-bit code   :P

[jj2007]

oops
:lol

although - you can use 32-bit regs in 16-bit code   :P

Yes, but it requires one line more than the standard setting:

.Model small
.Stack 512
.386


(I just found out playing around - 16-bit code is not my strong point because I started in 1986 with a Motorola 68000 :green)

[FORTRANS]

that is a down and dirty method
just test for overflow after you take the NEG, as 80000000h will look like a positive value   :P

Hi,

   But I said to then treat it as an unsigned value.  It will
be the proper value then, even if the negation overflowed.
But almost a nice catch.

Cheers,

Steve N.