rat@madnix.UUCP (David Douthitt) (02/20/89)
In article <8902152259.AA04690@wpi> GREYELF@WPI.BITNET writes: | | I made a 65c02 handheld computer about 1 year ago, with a seiko 4x20lcd | | screen. .... [stuff deleted] | | .... The problem I am having..is that All my code is | | assembly..(I really dont have the time to create each program by hand in | | assembly)..even though functions such as clock on interupt must still be | | in assembly.. | | | Since the code must be ROMable...uses ROM for program, I was wondering if | | anyone knows of any higher level language that is compact, no libraries or | | anything like that needed, and will allow me to create a ROMable program. | | | Thanks for any replys... | | Scott Hutinger | | (Where did all the time go?) | | Scott, why not use a normal assembler and the macro routines of | any standard assembler. | | Microsparc puts out an assembler that translates code almost exactly | like basic to pure object code, no libraries. If you want to use a higher level ROMable language, I would recommend either Forth or C. Both have many versions which are good and offer ROMable code. Right off the top of my head, Aztec C comes to mind. However, Aztec C tends to be expensive and slow. I don't know if there are any Apple Forths that are ROMable (I'm sure there must be). Perhaps you could try MicroMotion Forth or Isys Forth.. although Isys is IIgs specific and oriented towards scientific applications (I think). I wouldn't recommend a macro assembler unless you intend to USE assembly.. Personally for an Apple assembler, Merlin 8/16, ORCA/M, and possibly the S-C Assembler are the ones I would consider. I hope this helps.... [david] PS: Watch the followups for cross-posting... feel FREE to change the subject when this thread goes off-topic. TX. -- ======== David Douthitt :::: Madison, WI :::: The Stainless Steel Rat ======== FidoNet: 1:121/1 or 1:121/2 {decvax|att}! UseNet: ...{rutgers|ucbvax|harvard}!uwvax!astroatc!nicmad!madnix!rat ArpaNet: madnix!rat@cs.wisc.edu {uunet|ncoast}!marque!
merkel@shuxd.UUCP (Thomas Merkel) (02/21/89)
In article <500@madnix.UUCP> rat@madnix.UUCP (David Douthitt) writes: >In article <8902152259.AA04690@wpi> GREYELF@WPI.BITNET writes: >| | I made a 65c02 handheld computer about 1 year ago, with a seiko 4x20lcd >| | screen. > .... [stuff deleted] >| | Since the code must be ROMable...uses ROM for program, I was wondering if >| | anyone knows of any higher level language that is compact...... >| | Scott Hutinger >| >| Scott, why not use a normal assembler and the macro routines of >| any standard assembler. > >If you want to use a higher level ROMable language, I would recommend either >Forth or C. Both have many versions which are good and offer ROMable code. >======== David Douthitt :::: Madison, WI :::: The Stainless Steel Rat ======== A few years ago I used a C compiler that generated ROMable code for a 6809. I was able to squeeze fairly complicated code ( photocopier mechanism control ) into a 2764 and 1K RAM with room to spare. The compiler was from a company named Introl, I think they were in Madison, Wisconsin. I don't know if they did a 6502 version, but the 6809 version worked well. It came with a lot of source code for the runtime support, so you could scrounge for what you needed. It was real good with interrupts. I also experimented with FORTH for the 6502. The version I had was from Rockwell, used with the AIM-65. It wasn't perfect, but it let you get at the hardware, was compact and efficient, and could be squeezed into ROMs. The manuals claimed there was a way to pick just what you needed and put it into a ROM for standalone use, but I never tried it. From what I could see FORTH had a lot of potential, but I couldn't sell anyone else on it. Hope this helps. Tom -- Tom Merkel | merkel@shuxd.att.com Hard work never hurt anyone, | att!shuxd!merkel but why take chances. | merkel%shuxd@att.arpa
aash@ms.uky.edu (aash) (02/22/89)
In article <500@madnix.UUCP> rat@madnix.UUCP (David Douthitt) writes: > >I wouldn't recommend a macro assembler unless you intend to USE assembly.. >Personally for an Apple assembler, Merlin 8/16, ORCA/M, and possibly >the S-C Assembler are the ones I would consider. > Are there any PD or Shareware assemblers out there? hehe should I write one? aash -- aash aash@ms.uky.edu (archive at 128.163.128.6) {backbone site|rutgers|uunet}!ukma!aash "So aash, want some filet mignon?" "Nah, I was gonna have a hot dog."
hansell@poppy.cis.ohio-state.edu (Timothy Hansell) (03/11/89)
>In article <8902152259.AA04690@wpi> GREYELF@WPI.BITNET writes: >| | I made a 65c02 handheld computer about 1 year ago, with a seiko 4x20lcd >| | screen. > .... [stuff deleted] > I just wanted to post a note about how easy I found C to rom. I created a boot program for a 68000 based system. The initial routine that got called upon power on was in assembler, but after I set up enough of a stack enviroment I jumped to C. I generated all of the binaries using the Sun C compiler, and linker, ( linking in my own rommable version of the libc routines that I used ) and was able to take this binary, burn it in the prom directly and have it work. This is not so much of an praise for the Sun c compiler, which you would not be able to use, but a comment that it only took about a week to create my prommed versions of the libc routines ( there were a whole lot more simple than the Unix versions ). I just provided the capability I needed to use, and ignored unecessary fluff. If a C compiler is available for the CPU you are using, try it. Or another option is to Port the Small-C compiler ( which generates Mneumnic assembly code ) to generate the assembler for the chip you are using. You code write your routines in Small-C, and tweak the assemle output if you want. Currently the Small-C comes in two flavor's 8080 and 8086. But it is possible that someone has generated a version for the 6502. I am biased for C ( if you can get it ) -tim
hankd@pur-ee.UUCP (Hank Dietz) (03/14/89)
As an optimizing/parallelizing compiler researcher, I have designed and
written many small prototype compilers, and I think the level of Ron Cain's
Small C (as it appeared long ago in Dr. Dobbs) is very useful both for
checking-out nasty experimental compiler analysis/transformations and for
generating ROMable code for the many wimpy microprocessors/microcontrollers
used in embedded systems. In general, I am talking about "C programs
without printf, etc." -- C code for a bare machine.
Small C is not a large subset of C, but it is quite workable and the compiler
is completely self-contained (even self-compiling) and easy to understand
(hence easy to modify, although the implementation is somewhat kludgey).
The code it generates is dumb, but not grossly inefficient; the way it
manages locals and the stack happens to work really well, except for the
fact that it allocates stack space one variable at a time (easy to fix).
The stack allocation of temporaries makes it very easy to make Small C
handle a machine with general registers by simply treating the registers as
a "stack cache" -- a lousy way to allocate registers, but it does work.
I guess I've now got about 20 different mutations of Small C for various
different machines ranging from processors for a few proposed parallel
supercomputers all the way down to lowly TI7000 series machines. Given a
working assembler and reasonable understanding of the machine, mean time to
target for a new machine is about 2 days. I also have an assembler I wrote
long ago specifically as a target for such "toy" C compilers, ASA (the
ASsembler Adaptable), which takes a mean of about 1 week to target for a new
machine.
Some of you might ask "why not use Gnu CC?" However, Gnu CC is *BIG*. The
time taken for a person to learn the internal structure of Gnu CC seems to be
on the order of a couple of months and even then the program is too large and
complex to be ported quickly... especially to small machines. The ideal is
to have a reasonable subset language compiler that is small, self-contained,
and can be subsetted or extended easily.... Gnu CC ain't it, there may be a
better choice soon, but for now, Small C is probably the best bet.
-hankd@ee.ecn.purdue.edu
PS: An interesting side note is that one could fairly easily bootstrap GCC
by making a version of GCC generate Small C code.... Efficient? Heck
no, but easy... and it can be incrementally improved.