Xref: utzoo comp.os.msdos.programmer:3550 comp.sys.ibm.pc.hardware:5846 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!emory!rsiatl!jgd From: jgd@Dixie.Com (John G. DeArmond) Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.hardware Subject: Re: Romable code with Microsoft C? Message-ID: <7199@rsiatl.Dixie.Com> Date: 23 Feb 91 04:16:53 GMT References: <1991Feb22.155750.1404@wuphys.wustl.edu> Followup-To: comp.sys.ibm.pc.programmer Organization: Rapid Deployment Systems (making go-fast things and things that-go fast) Lines: 93 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