🚀 go-pugleaf

marty@wuphys.wustl.edu (Marty Olevitch) writes:

>We have an application that runs on a PC from ROM. Up until now, we have
>been using Aztec C to create the romable code, but now we are thinking of
>switching to Microsoft C for a number of reasons. Looking over the
>documentation, there is nothing on creating romable code with MSC. Can it be
>done?  Is it necessary to buy a separate linker or "locater", or can the MS
>link program be used?

>I am specifically looking for either some kind of instructions on creating
>romable code using the standard MSC tools, or a pointer to some literature
>on that topic. If a commercial linker/locater is the way to go, does anyone
>have recommendations for particular products (good experiences, stuff to
>avoid, etc).

You might want to clarify what you're doing a bit, as it will determine 
which tools you need.  I'll describe a couple that we use.

If you are doing a truely embedded application that does not need DOS,
I recommend C_Thru_ROM from Datalite.  This is a linking-locator and a
turbo-c-style remote debugger.  It will use the output of either MSC or
Turbo C, though Turbo-C code output must be run though a symbol table
generator.  The debugger is really nice.  Full screen, source level,
and fast.  It talks to your embedded application via a small kernel.
The debugger on the development PC talks to its interface via a device
driver.  ONe is supplied for standard ASY ports.  The beauty of this
scheme is that you can write a device driver - a skeleton is provided - 
for just about anything.  Thus if you wanted to talk to your target 
via ethernet, all you gotta do is provide the code on the PC and in
the target kernel for the ether chipsets.

Datalite also has a Mini-Dos kit for the occasion where your embedded 
application needs file services.  I've not tried this product but I
hear good reports.

If you want to take a DOS application and ROM it and the application needs
DOS, you might want to look at Annabook's PromKit.  This package takes a
bootable floppy with your application on it, reads it absolutely sector
by sector and builds an image that can be placed in ROM.  It also
outputs a driver that is discoverable by the POST rom-scan that installs
the ROM image as a pseudo-drive.  Thus, your application thinks it's
running from disk but the computer boots and executes DOS from the ROM.
His kit can handle a variety of ROMs and/or RAM (for read/write disks)
including the new paged mode ROM (27011 for example.)   He has 
the schematics in the book for very simple ROM board consisting of 
2 27011 (16k pages) and a single decode PAL.  Or you can buy ROM boards
commercially.  I'm using one from Sealevel Systems that will also accept
RAM for R/W drive emulation.

For our Printer Nidget (TM) (a little box to make any old printer speak
ethernet/ TCP/IP and turn into network printers), I am using a Sealevel
Systems board with 128k of static RAM. My code does not need any DOS
services once loaded.  DOS 2.2 and my application code fit well in this
space.  When I'm ready to load a new revision, I  simply transfer a new
.exe file over via the applications's ftp service and tell the
application to commit suicide by pinging a designated port. It exits and
the endless loop autoexec.bat also on the RAM disk reloads the new code. 
if all else fails, I just  stick a floppy in and copy the fixed binary
onto the RAM drive.

I have the system configured so that the RAM board occupies C0000 thru
Dffff.  The driver ROM goes in the ROM BASIC socket and is found at
f800:0.  You can also have the driver as part of the first data ROM too
if you have sufficient free address space.  My motherboard uses 1 mb
RAM so I could not chop it down to 512k or something more reasonable.

John Foster at Annabooks is a real nice guy and a consumate hacker.
He follows what I consider to be the model for commercial software
sales.  He gives away via his BBS and soon, by mail server from
this system (dixie.com), executables of his code.  He considers
his product to be his documentation and source code.  NOT shareware.
No beg or guilt messages anywhere.  If you can get along with only
the binary, fine.  The BBS is at 619 749 2741.

Along with PromKit you get the XT-AT handbook which is a shirtpocket
book that contains about all you'd ever need to know about the PC
and the 80xxx family.  This is worth the price of the kit.

Annabooks' other claim to fame is his C BIOSs for ATs and XTs.  he has
many variants including one for the Faraday single chip XT (nice
for embedded systems.)  Annabooks is at 800 462 1042 or 619 271 9526.

Disclaimer:  I have no connection with Annabooks or Datalite other
	than I'm impressed enough with Annabooks' products to give them
	a point of presence on the net via dixie.com.

John

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it