noworol@eecg.toronto.edu (Mark Noworolski) (01/04/89)
Well- for those of you who have been following my saga here's the next piece For those of you who have helped me along- I'm forever grateful. How to ROM code (absolutely ugly brute force method- works only for .com files- sort of). Final result: your program executes from the basica rom slot on bootup. Instructions: 1. Make sure your rom bios jumps to the basic rom location (at f600 or so) Some phoenix bios's just jump to a message 'Faulty boot disk'. You'll need to get a technical hardware reference manual to do this- but it's pretty easy (modify the vector table for int 18h- @ 1f13 in the rom). 2. Make sure your rom (when you plug it in) actually starts where you think it does. ie. program it with something like 00 01 02 03 04 05 06 and then do a search for these bytes in debug (f f000:0 l0 00 01 02 03 04 05 ...) 3. Write a little loader program (in assembly) to move everything after it into low ram and then jump to that ram location (this is actually a bit of a pain- you have to be very careful about where you ORG this code when assembling it). Run this through exe2bin to get a binary (.com) file. If you org this thing at f600 for example exe2bin wont COMify it- I then loaded the exe file into debug and saved the appropriate length from the approporiate starting location. Maybe there's an easier way to do this? 4. Compile your Turbo C program in tiny model. The trick here is not to use ANY library functions (or floating point I think- since fp is not supported in the tiny memory model (?)). Also you need to link your program WITHOUT the nasty C start up code c0x.obj since this seems to do a lot of stupid dos calls (and since you don't have dos when this rom runs - usually- you don't want these). The way I do this is to use the assembly output option and then assemble and link that using an assembler (like MASM). Is there a cleaner way? There should be a way to link in library functions and avoid the startup scum dos code- but I sure haven't found it (anybody volunteer for this one?). 5. Merge your loader code with your .com file: copy loader.bin+tccode.com romcode.bin 6. Program your ROM with the result. Hope this helps some of you and once again thanks to all those who helped. mark -- There's a really fine line between stupid and clever. Nigel - Lead Guitar, Spinal Tap noworol@ecf.toronto.edu
hollen@spot.megatek.uucp (Dion Hollenbeck) (01/06/89)
From article <89Jan4.141140est.2375@godzilla.eecg.toronto.edu>, by noworol@eecg.toronto.edu (Mark Noworolski): > Well- for those of you who have been following my saga here's the next piece > For those of you who have helped me along- I'm forever grateful. > > How to ROM code (absolutely ugly brute force method- works only for .com > files- sort of). > [...lots of helpful advice deleted...] I develop ROMable code daily from Lattice C and assembly or Microsoft C and assembly and the critical step that is being left out is a few $$. Go out and purchase an embedded system development kit which contains a special LINK program which creates output for a LOCATE program. The LOCATE program takes the link output (not .EXE or .COM) and turns into absolutely located code, you first having told it at what address to locate the code. Yes, you can use the TINY model, but with a LOCATOR, you can locate any segment at any address you desire, put the segments in any order you wish. A good source for such a suite of programs is: Systems Software, Inc. 3303 Harbor Blvd. C11 Costa Mesa, Ca. 92626 (714) 241-8650 If you deal with them, DO NOT BUT LATTICE C!!! They are merely a dealer and Lattice is not very responsive to fixing problems. All the software which SSI makes is very high quality and they are very responsive to user problems. I realize that this might not be the solution for most people since it will cost several hundred $$, but if you are REALLY SERIOUS about producing ROMable code, this is the ONLY way to go and be efficient. If any of you need any more hints, please EMAIL me directly and we will chat electronically. (sometimes, I try to mail back and somebody's (*%%$^%$ mailer thinks it is smarter than the path I gave it, so include a phone number for me to use if the mail response bounces back to me). Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 seismo!s3sun!megatek!hollen ames!scubed/
hundt@paul.rutgers.edu (Hundt) (01/06/89)
> Final result: your program executes from the basica rom slot on bootup. --------- See next comment. > Instructions: > 1. Make sure your rom bios jumps to the basic rom location (at f600 or so) > Some phoenix bios's just jump to a message 'Faulty boot disk'. You'll need Of course this is for machines sans disk. > when assembling it). Run this through exe2bin to get a binary (.com) file. > If you org this thing at f600 for example exe2bin wont COMify it- I then > loaded the exe file into debug and saved the appropriate length from the > approporiate starting location. Maybe there's an easier way to do this? I'd get the source to exe2com off simtel20 and hack that --- remove the restriction on ORGs, etc. > you need to link your program WITHOUT the nasty C start up code c0x.obj > is to use the assembly output option and then assemble and link that using > an assembler (like MASM). Is there a cleaner way? There should be a way to > link in library functions and avoid the startup scum dos code- but I sure > haven't found it (anybody volunteer for this one?). How about getting the source to c0x (c0x.asm) and hacking that a bit? I had it when I was working on the ka9q (NET) package, I think I got it from Russ Nelson (nelson@clutx.clarkson.edu) in his "porting kit". I don't remember what the terms of this were, however. Is it supplied with TC 2.0? > 6. Program your ROM with the result. Oh, what ROM burner board do you use? Mine is from JDR Microdevices (their old version, about 2 years old?) and conflicts with EGA ports. Bummer. Anybody want to trade? :-) hundt@occlusal.rutgers.edu:Thomas M. Hundt:201/247-6723(H),932-5843(Lab) -- RRRRRR Thomas M. Hundt RR RR Gradual Student --- Electrical & Computer Engineering RR RR Rutgers University RRRRR New Brunswick NJ RR RR hundt@occlusal.rutgers.edu RRR RRR Famous last words: "The virus ate it."
john@data.UUCP (John Mantey) (01/11/89)
Maybe I'm wrong, but doesn't Borland describe how to generate your own c0x.lib files? (I believe I saw something about this in my copy of 2.0) johnm