marty@wuphys.wustl.edu (Marty Olevitch) (02/22/91)
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). Please send replies to me at one of the addresses below or post to the net. Thanks very much for any help. Marty Olevitch Internet: marty@wuphys.wustl.edu Washington University UUCP: uunet!wugate!wuphys!marty Physics Department, Campus Box 1105 Bitnet: marty@wuphys.WUSTL St Louis MO 63130 USA Tel: (314) 889-6285
jgd@Dixie.Com (John G. DeArmond) (02/23/91)
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
jstone@world.std.com (Jeffrey R Stone) (02/23/91)
josephc@nntp-server.caltech.edu (Simplelogic) writes: > ... A quick call to Borland >did, however, reveal a name of a company that might help: Paradigm Systems >(1-800-582-0864, or 1-800-537-5043 to order) in New York. >According to the fax I received from them, their product, Paradigm LOCATE will >allow you to take standard .EXE files and burn it into ROM. There is, with the >product, a run-time library and floating point support - and from having talked >with a technician there, it's basically as simple as processing your .EXE >through their product (with one "Configuration File" that details your target >environment's memory layout). I have used Paradigm Locate and TDREM in product development, and I reccomend them highly. The locater works so well that I can't even tell you much about it. I copied their sample locate instructcions into my makefile (with suitable adjustments for my target memory map) and I've never had to look at it again. TDREM is THE way to go for debugging on a target system if its CPU is an 8086-family processor. It gives you the ability to debug your program with (your own copy of) Turbo Debugger. I wish all of my development tools were as professionally done as this pair of products. BTW, if you do decide to use TDREM, perhaps I can save you some grief by pointing out some known Turbo Debugger bugs (I haven't found ANY in any Paradigm product). Borland will confirm them once you've torn out your hair looking for them in your own code, but they won't warn you up front, even if you ask. Mail me if you're interested (I'll post if I get several requests). -jeff- PS.: No connection with Paradigm, just a very satisfied customer.
andy@bluemoon.uucp (Andy Vaught) (02/24/91)
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? There was an article in a recent Dr. Dobb's Journal. Basically, what you did was create and debug the program with MSC, then when you were ready to ROM the code, you put the EXE file through what amounted to a loader that resolved DOS fixups to the place you wanted to ROM the code at, and save the binary image. "Recent" is within two years-- they do tend to pile up.
jstone@world.std.com (Jeffrey R Stone) (02/26/91)
In an earlier posting I offered to describe some bugs I had found in Turbo Debugger. Since I've had several requests, I am posting the list here. None of them is so serious as to make TD unuseable, but one of them (the block-write bug) quietly causes bad data to be written to a file. I feel that Borland ought to have fixed this one immediately and should have all notified registered users of its existence. This is not a diatribe against the company or its products. I use TD personally and professionally and highly recommend it. In spite of these bugs, it is still my personal and professional opinion that it is the best debugger available for software development targeted to 8086- family processors. I am offering this information to other users of Turbo Debugger who may benefit by not having to waste the time I did looking for non-existent bugs. I would be appreciate hearing about other bugs and work arounds to them. -jeff- The list: 1. Block I/O in remote mode writes bad data. When using TD in remote mode, block I/O from between target memory and a local file happens in 120-byte packets. Unfortunately, the memory pointer seems to be advanced only 110 bytes each time. On output, this causes the last 10 bytes of the first packet to be repeated as the first 10 bytes of the second, and so on. My remedy was to write enough more data than I really wanted to make up for the bytes wasted to repetition, then post-process the output files to remove the repeated bytes. 2. Two-valued dialog boxes fail after using the assembler. Some dialog boxes request two inputs, such as starting address and byte count for block writes, or port-address and data for output to a port. Once you have assembled instructions into memory using the internal assembler, these dialog will fail with the message "Extra input after expression". The remedy is to patch in hexadecimal (Yuck!) in a data window if you will want to to use any features that use two-valued dialog boxes later in the session. 3. Block I/O buffers aren't flushed when shelling out. While the buffers are managed OK at exit, I often wanted to shell out to graph some data captured from the remote system, and then resume my interupted program where it left off. Requiring me to exit first loses the states of the target program and the debugger. 4. TD won't inspect the value of functions written in assembler. It can inspect the value of C functions, so why not assembler functions? Not exactly a bug, but it seems an unnecessary and useless restriction. The follwing was supplied to me one of the respondents, for which I am grateful. I have not tested it. If a breakpoint condition is too long, the popup window that tries to tell you about it will crash the whole machine. It doesn't try to wrap the expression.
traub@rtf.bt.co.uk (Michael Traub) (02/27/91)
In article <1991Feb22.155750.1404@wuphys.wustl.edu> marty@wuphys.UUCP (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). Try Systems and Software link and locate products, their product contains everything necessary for generating ROMable code. It is fashioned on the old MDS-ISIS products and thus allows complete control over code/data placement. It also generates Intel Hex files for downloading to your EPROM blower. I don't think it is possible to generate ROMable code without a product like this. I know for certain that MS-Link is not up to the job. Also if at all possible change C compilers! Microsoft C has stack checking embedded in many of its library routines, which ain't much use in a stand alone system. I have used Turbo C and Turbo C++ and they work very well. If you insist on staying with Microsoft C I suggest forking out for the library sources, they will save you money in the long run. Michael Traub BT Customer Systems, Brighton Systems Centre. traub@rtf.bt.co.uk
shaunc@gold.gvg.tek.com (Shaun Case) (02/28/91)
In article <1991Feb22.211530.4528@nntp-server.caltech.edu> josephc@nntp-server.caltech.edu (Simplelogic) writes: >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 have had a similar wish using Borland's products, and I have found that >there was no way to directly produce rommable code. A quick call to Borland >did, however, reveal a name of a company that might help: Paradigm Systems >(1-800-582-0864, or 1-800-537-5043 to order) in New York. > When I had to design and build a single board 8088 machine with a monitor in ROM for an engineering class, I used a utility called ROMIZE that turned turbo C object code into rommable code. However, it needed either TASM or MASM, along with exe2bin to make the code. The utility was horked off Compu$erv by a classmate, and is PD as far as I know. I used it with great success. The only restrictions were: 1) You had to compile to .obj code using the right memory model (small, I think, it's been a while) 2) You couldn't use any library routines that called BIOS services or did PC dependent stuff. Thus, you couldn't use floating point, printf(), file io, console io, etc, but you could use things like isalpha(), casts, arrays, etc. I wasn't really sure in some cases what used BIOS calls and what didn't, so I ended up writing a lot of small functions like str_to_hex(), itoa(), etc. It was pretty easy, and a lot of fun, and now I have a nice library of (probably inefficient) routines for bonehead compilers that don't support things like strstr(). The utility had its own c0 startup code, which was assembly, with source. You could change it if you wanted to -- I think I had to make a small patch to it. Anyhow, I still have the package, and would be willing to mail it to a few people, if you are interested. I'd really like it if someone could find an FTP site for it, or could put it on Simtel. It's pretty short. Shaun. -- Shaun Case: shaunc@gold.gvg.tek.com or atman%ecst.csuchico.edu@RELAY.CS.NET or Shaun Case of 1:119/666.0 (Fidonet) or 1@9651 (WWIVnet) --- A bullet in the Bush is worth two in the hand.
tom@syssoft.com (Rodentia) (02/28/91)
Another solution is to use one of Systems and Software's products
(I am affiliated in no way other than an employee ;-{) ).
We have products for ROMing both Microsoft and Borland produced EXE
files, as well as a more sophisticated linker for Microsoft if the
EXE wasn't properly ROMable. Send me mail if you want to be
pestered by our sales force (try tom@syssoft.com if the Reply-To:
address bounces). Or you could call...
-Tom
--
Thomas Roden | tom@syssoft.com
Systems and Software, Inc. | Voice: (714) 833-1700 x454
"If the Beagle had sailed here, Darwin would have | FAX: (714) 833-1900
come up with a different theory altogether." - me |