mch@GALAHAD.CAMELOT.CS.CMU.EDU (Mark Hahn) (02/17/88)
Use minix - see "Operating Systems - design and implementation,"
Tannenbaum. Mostly compatable with version 7 unix. Clean, well documented.
The architecture-dependent code is small and well compartmentalized.
The copyright provides for limited, non-commercial redistribution
(of sources).
I think the board itself should be a simple design - emphasizing a powerful
cpu, and minimizing io stuff. Just cpu, mmu, sockets for tons of memory,
perhaps a scsi (dma) interface, maybe a couple of serial ports. Certainly
no slots, no disk controllers.
--
ARPA: mch@a.gp.cs.cmu.edu
UUCP: {harvard | ucbvax | seismo}!a.gp.cs.cmu.edu!mch
This does not represent the opinion or policy of my employer.johnw@astroatc.UUCP (John F. Wardale) (02/18/88)
In article <880@PT.CS.CMU.EDU> mch@cs.cmu.edu (Mark Hahn) writes: >and minimizing io stuff. Just cpu, mmu, sockets for tons of memory, >perhaps a scsi (dma) interface, maybe a couple of serial ports. Certainly >no slots, no disk controllers. Whoa, Nellie!!!!! 1: memory (never enuf) 2: serial lines on a kit are a necessity. I vote for 4, but 2 is tolerable 3: slots, scsi, or disk controller: you *MUST* have one of these Either have a case with n <XXX-BUS> slots, or a *SINGLE* mother board that does it all. With scsi this is possible. -- John Wardale ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw To err is human, to really foul up world news requires the net!
eao@anumb.UUCP (e.a.olson) (02/19/88)
In article <880@PT.CS.CMU.EDU> mch@cs.cmu.edu (Mark Hahn) writes: >Use minix - see "Operating Systems - design and implementation," >Tannenbaum. Mostly compatable with version 7 unix. Clean, well documented. >The architecture-dependent code is small and well compartmentalized. >The copyright provides for limited, non-commercial redistribution >(of sources). why not use Genix? NSC has already written flavors for both BSD4.3 & sVr3. these include a compiler that NSC has spent a lot of time and energy on; i doubt it could be easily duplicated. >I think the board itself should be a simple design - emphasizing a powerful >cpu, and minimizing io stuff. Just cpu, mmu, sockets for tons of memory, >perhaps a scsi (dma) interface, maybe a couple of serial ports. Certainly >no slots, no disk controllers. you propose to run a un*x system without disks? and what about video? my preference would be something like this: 1 a memory controller. one of the chips that will drive up to 4X32 256Ks/1Ms. i'd use ZIPs for space/availability reasons. 2 a high-power video controller. i can't decide if it should be one of the at/xt superset chips, or something really exotic which can emulate at/xt modes. should it have it's own memory? 3 SA450 controller. there are at least half a dozen streaming tapes with floppy interfaces; also (i think) some cd-roms. the driver should be able to handle any mix. 4 HD controller. if this board is to fit an AT chassis, it should handle the AT drives which are ST506/412s; otherwise AT owners who want to upgrade (this IS an upgrade, isn't it? ;^>) will be SOL. and why not put plugs on the board for 4 drives? the WD1010-family chips can handle that many. 5 slots. likewise. you'd also be missing out on the vast wealth of plugins already developed for the AT. drivers are another question, though. 6 in this same vein, it might be useful to include a ms-dos simulator (doshell?) or recompiler. dma & vm go without question. it doesn't have to be 532-based; i'd even be willing to accept an 032-based machine with the above attributes. andy hay +-----------------------------------------------+ | Don't try to out-wierd ME, three-eyes! | ihnp4!mvuxq!adh +-----------------------------------------------+
ken@cs.rochester.edu (Ken Yap) (02/20/88)
Hey NSC, Don't ignore hardware hackers. They can be your one of your best sources of testimonials when it comes to designing chips in. Guess how many people out there cut their teeth on 8 bitters. I still remember the 6809 fondly, it has, in my opinion, a great instruction set for an 8 bit micro. Some of this goodwill carried over to the 68k chips. Think how many U* hackers met and wooed U* at college. I wish there was a decent U* box for around 2k. I dread the idea of buying a PC motherboard but that looks like the only economically viable path now. Ken
rrr@naucse.UUCP (Bob Rose ) (02/21/88)
In article <177@anumb.UUCP>, eao@anumb.UUCP (e.a.olson) writes: > In article <880@PT.CS.CMU.EDU> mch@cs.cmu.edu (Mark Hahn) writes: > >Use minix - see "Operating Systems - design and implementation," > > why not use Genix? I called National Sem, they what $45000 to use Genix, that is why were not even looking at using it. AT&T, Mt XINU and all the rest want about the same, then many of them want royalties in the range $100 to $1000 for _each_ machine sold. You can't make a small inexpensive machine when your giving out royalties left and right. We are currently looking into minix, Prentice-Hall has a copyright on it but the royalties shouldn't be that bad. We hope to `enhance' it to a small BSD by adding job control, sigvec, and a few other small things. (Enough to get most of the BSD software up but not all.) [wish list] > 1 a memory controller. > 2 a high-power video controller. > 3 SA450 controller. > 4 HD controller. > 5 slots. > it doesn't have to be 532-based; i'd even be willing to accept > an 032-based machine with the above attributes. Well how about this: 1) 1 to 8 meg of ram 2) HD and floppy controller on motherboard 3) 4 or 8 serial ports 4) 4 slots, IBM AT hardware compatible (that way you can add anything you want if your willing take the time to write a driver) 5) 32032 based, 32532 is just too expensive to make a small machine that John Doe Hacker will buy. (Looking at 32332.) 6) And the most important is price, hopefully well under $2000. (Small machines with little disk and mem would be under ?$1000?) Notice no video, you gotta get a terminal (all in the spirit of unix and to keep the price cheap.) Yes all this is in the planning stage but it always must start somewhere. -bob Robert R. Rose Rose Research 1515 S. Yale Bldg 23A Flagstaff, AZ 86001 .....!ihnp4!arizona!naucse!rrr
cwwj@ur-tut.UUCP (Clarence Wilkerson) (02/21/88)
I've read with interest recent postings on the 32000. Could I ask for a short list of "hacker" oriented products? Clarence Wilkerson, Dept. Math. Cornell University
cyrus@hi.unm.edu (Tait Cyrus) (02/23/88)
I have read with interest the comments about a 32xxx box. Well, here
at the University of New Mexico, in conjunction with Los Alamos
National Labs, we are building a hypercube using the 32xxx. Specifically,
each node of the cube consists of:
I/O engine
-32016 plus MMU, ICU, FPA
-local PROM(128k)
-local RAM (128k)
-2 RS232 ports
-1 SMD (maybe even HSMD) disk interface; we
are using the NS8466 Disk Data Controller chip
-1 ethernet interface; we are using the AMD 7990 LANCE
-6 high speed links (hypercube links) using the DMA
controller.
-8 Megs of shared memory (shared with the compute engine)
Compute engine:
-32032 plus MMU, ICU, FPA
-local PROM(128k)
-local RAM (128k)
-1 RS232 port (debugging)
-8 Megs of shared memory (shared with the I/O engine)
We are currently porting GENIX to our hardware.
To those of you who have suggested using GENIX, I would say DO NOT
USE IT. Namely, the GENIX C compiler, along with GENIX itself,
uses external procedures (i.e. cxp, rxp, lxp, etc) which is VERY
VERY VERY VERY............ SLOW. It is my understand that the NS
SYSV, though, does NOT use the external procedure stuff which will
make it a lot faster than GENIX.
Unfortunately only two people are working on the hardware and one on
the software. We are still working out some minor bugs with the
disk controller as well as some intermittent ethernet problems (each
of our boards are wire wrapped with a total of about 4,000 wires
and I wonder why we have intermittent problems :-) Our current
design is on a full size VME card (SUN sized).
I wish I could offer our board, but since it is not stable yet, and
probably won't be for a couple more months, I can't. I will, though,
offer my services and expertise (if you can call it that) with any
hardware design questions that might come up.
We would like to go to the 32532 in our next iteration of our design
for both our I/O and compute engines so I would be interested in
in any 32532 designs.
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of Electircal & Computer Engineering
@__|_______@ | Parallel Processing Research Group (PPRG)
| | | | UNM/LANL Hypercube Project
| | hc | | Albuquerque, New Mexico 87131
| @.......|..@
| / | / e-mail:
@/_________@/ cyrus@hc.dspo.govsnoopy@doghouse.gwd.tek.com (Snoopy) (02/24/88)
In article <880@PT.CS.CMU.EDU> mch@cs.cmu.edu (Mark Hahn) writes: >I think the board itself should be a simple design - emphasizing a powerful >cpu, and minimizing io stuff. Just cpu, mmu, sockets for tons of memory, >perhaps a scsi (dma) interface, maybe a couple of serial ports. Certainly >no slots, no disk controllers. No slots, and *maybe* a couple of serial ports? Okay, how are you going to talk to the thing? Do they make SCSI terminals now? What if you need to hookup a parallel printer? Simple yes. But expandable! Snoopy Lord, won't ya buy me a '532 ? tektronix!doghouse.gwd!snoopy My friends all have Sun-4s, snoopy@doghouse.gwd.tek.com I must go fast too.
johnw@astroatc.UUCP (John F. Wardale) (02/24/88)
In article <23506@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: > >To those of you who have suggested using GENIX, I would say DO NOT >USE IT. Namely, the GENIX C compiler, along with GENIX itself, >uses external procedures (i.e. cxp, rxp, lxp, etc) which is VERY >VERY VERY VERY............ SLOW. --------------------------------- Please do *NOT* confuse a SYSTEM with a COMPILER !!!!!!!! Symetrics has a Genix port with there own complier/linker/etc. that does *NOT* use cxp-et.al. I don't have hard timings, but I have a good feel that the difference is only about 10 or 15% There *IS* a Green-Hill's compiler for the National, but it's not cheap. It's code should be 15-25% faster than the symetics's. -- John Wardale ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw To err is human, to really foul up world news requires the net!
mike@hoover.UUCP (mike gehl) (02/25/88)
in article <23506@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) says: > > > We are currently porting GENIX to our hardware. > To those of you who have suggested using GENIX, I would say DO NOT > USE IT. Namely, the GENIX C compiler, along with GENIX itself, > We would like to go to the 32532 in our next iteration of our design > for both our I/O and compute engines so I would be interested in > in any 32532 designs. > Tait, a couple of points: 1) You seem to have a rather interesting project on your hands; by "porting GENIX" to your hypercube implementation, do you mean Unix? (4.1,4.2,5.2,5.3) If so, this has staggering implications as far as the kernel is concerned. If I assume you mean the GNX language tools, you will find that at current(GNXR2 externals are not supported, and the optimizer is what we consider to be "state of the art"..i.e. somewhat more sophisticated than the Greenhills "garden variety" supercompilers that Mot and Intel tout. I've seen typically a 25-40% improvement in performance over what i suspect you've got. 2) there are now, I believe, 3 532 implementations on the market: a) the vme532 from NSC b) a 532 VME board from Heurikon, announced this week, and c) a 532 AT coprocessor from Aeon Technologies, of Denver, CO. They all, to the best of my knowledge, feature at least the 532, 381 FPU, and 4MB of RAM. Other features differ, of course. The NSC and Aeon have 5.3, the Heurikon I'm not sure (a Real-timer at least). And they all basically blow away any 68k, 80x86, or Clipper units in terms of performance (this IS posted to the 32k group, isn't it?), and I haven't seen anything close to advertised performance for the SPARC (remember the Clipper's 33 Million NOP's per second? A register add and a store aren't two whole instructions in my book!). Basically, these boards constitute the most poop for the buck at this time. Good Luck, Mike Gehl, National Semiconductor denver. * i THINK that the preceding message is the opinion of my company. If it isn't, we're in deep .........
amos@nsc.nsc.com (Amos Shapir NSTA) (02/25/88)
In article <23506@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: >We are currently porting GENIX to our hardware. >To those of you who have suggested using GENIX, I would say DO NOT >USE IT. Namely, the GENIX C compiler, along with GENIX itself, >uses external procedures (i.e. cxp, rxp, lxp, etc) which is VERY >VERY VERY VERY............ SLOW. It is my understand that the NS >SYSV, though, does NOT use the external procedure stuff which will >make it a lot faster than GENIX. The GENIX you refer to is National's port of BSD 4.1 unix. All new unix ports by National use jsr/bsr rather than cxp; but to make things more confusing, they are also called GENIX... Check our software products catalog for details as to which is which. -- Amos Shapir My other CPU is a NS32532 National Semiconductor 7C/266 1135 Kern st. Sunnyvale (408) 721-8161 amos@nsc.com till March 1, 88; Then back to amos%taux01@nsc.com
pekka@amnesix.liu.se (Pekka Akselin [The Mad Midnight Hacker]) (02/26/88)
In article <585@naucse.UUCP> rrr@naucse.UUCP (Bob Rose ) writes: >Well how about this: > 1) 1 to 8 meg of ram > 2) HD and floppy controller on motherboard How about a tapestreamer too?! It's surely more useful for backups, dumps etc than a floppy. The tapestreamer and HD could go on a SCSI-bus. There is a cheap SCSI-controler from Western Digital (WD33C93 I think). A floppy is good when you need to transport "small" amounts of soft to a another machine. [...] >Notice no video, you gotta get a terminal (all in the spirit of unix and >to keep the price cheap.) A computerboard with video on board is a PC! A real computer has none (except for SUNs - the exception that confirms the rule 8-) No flames! This is my opinion and nobody, I repeat, nobody can take it away from me. /pekka [...The Mad Midnight Hacker Strikes Again...] ______________________________________________________________________________ pak@ida.liu.se ...!uunet!enea!liuida!ida!pak Pekka Akselin, Univ. of Linkoping, Sweden (The Land Of The Midnight Hacker 8-) Bus error (core dumped)
eao@anumb.UUCP (e.a.olson) (02/26/88)
how about using the CMU Mach kernel?
i believe it's PD, thus cheap/free.
also fast; they essentially re-implemented *n*x (BSD flavor).
i can't peg it, but i recall a speedup of more than 3 times described.
it has networking hooks, too.
one thing i've always wanted to try --
instead of just hanging a uart off the bus to implement a serial port,
why not imbed the tty driver in a single-chip micro with embedded uart?
single-chippers are almost as cheap as a separate uart.
buffer i/o with a byte-wide ram dual-ported by cycle-stealing.
i favor (if there's enough room) of putting as much as possible
on the motherboard. a lot of us are going to want disk
controllers, color graphics ability, etc.
you others, you don't have to install chips just because the
etch is there!
speaking of graphics, i've just seen the sega 3d game box.
this has 2 frame buffers which display alternately (30hz*2),
and lcd glasses which switch to let each eye see only one frame.
imagine if you had a pc which could do this......
3d flight simulator? 3d omega-moria-hack-? yow!
andy hay +-----------------------------------------------+
| "Boom boom boom boom" -- J. L. Hooker |
ihnp4!mvuxq!adh +-----------------------------------------------+johnw@astroatc.UUCP (John F. Wardale) (03/01/88)
In a recnet ncs.32k discussion: In article <183@anumb.UUCP> mvuxq!adh@anumb.UUCP (a.d.hay) writes: >one thing i've always wanted to try -- >instead of just hanging a uart off the bus to implement a serial port, >why not imbed the tty driver in a single-chip micro with embedded uart? >single-chippers are almost as cheap as a separate uart. >buffer i/o with a byte-wide ram dual-ported by cycle-stealing. In 4.2/4.3 the the tty drivers all call the line-disipline routines, which do the "real" tty stuff. There are several line-disciplines (LDs): The old v7 one (OTTYDISC), the new (Berkeley) one (NTTYDISC), the Berkely-tty-net one (NETDISC) usefull with block-transter terminals (i.e. *NOT* a vi-editing environ.) And new with 4.3: SLIPDISC for running Serial Internet Protocal on a serial medium! If we had the 4.2 driver in your single-chiper, and got 4.3 and WANTED SLIPDISC, we'd be S.O.L. !!! (Ok, so you could probably hack around it, but it'd be UGLY!) Also, ptys need to use this code too (script, rlogind, et.al.) so imbeding it does NOT let you remove it! (Or did you want to copy in into *ALL* the network drivers too? or maybe have all the network drivers talk to it??) It's a hard problem, but there are many cases (like here) where centralization is *GOOD*. -------------------------------------- Things that DO work: tty OUTPUT is generally 50 to 200 times more common than input. (cat foo, ^F in vi, etc. etc.) What you really need/want is to process all the output, buffer it, THEN let some semi-inteligent <hunk-of-HW> spit the characters at the terminal one-at-a-time. For input, you frequently have to send *EACH* character to the host: *remost-hosts* always send each. *VI* must send each, or imbed editor support into the controller-or-whatever. What I'm contemplating is setting up my controller (8 ports, 19.2k, 9600 baud max, one 68000) with a loadable character-indexed "what-to-do" table. For "normal" operations, normal letters would echo them selves, Control-characters could echo ^<letter> if set up to... Given sufficient ambition, the "actions" could involve things like "redisplay screen-buffer" This (of course) means that vi, emacs, jove, et-al. would have to be hacked (alot ??) to take advantage of such things. -- John Wardale ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw To err is human, to really foul up world news requires the net!
eao@anumb.UUCP (e.a.olson) (03/03/88)
In article <726@amnesix.liu.se> pekka@amnesix.liu.se (Pekka Akselin [The Mad Midnight Hacker]) writes: >In article <585@naucse.UUCP> rrr@naucse.UUCP (Bob Rose ) writes: >> >> LINES DELETED >> >>Notice no video, you gotta get a terminal (all in the spirit of unix and >>to keep the price cheap.) >A computerboard with video on board is a PC! >A real computer has none (except for SUNs - the exception that confirms >the rule 8-) my only objection to omitting onboard video is that the only way you can get adequate bandwidth for high-res graphics is on the bus. okay, maybe it doesn't have to be on the mother.... but there should be a place for it inside the box. andy hay +-----------------------------------------------+ | "Something wonderful will happen!" | ihnp4!mvuxq!adh +-----------------------------------------------+
orr@taux01.UUCP (Orr Michael ) (03/30/88)
In article <23506@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: > >We are currently porting GENIX to our hardware. >To those of you who have suggested using GENIX, I would say DO NOT >USE IT. Namely, the GENIX C compiler, along with GENIX itself, >uses external procedures (i.e. cxp, rxp, lxp, etc) which is VERY >VERY VERY VERY............ SLOW. It is my understand that the NS >SYSV, though, does NOT use the external procedure stuff which will >make it a lot faster than GENIX. > This is partly right. The CTP compilers of NS only use the external call mechanism as a special option. True enough, these calls are slow , BUT, they provide a unique capability. The way this works is that you can generate code that is totally free from relocateable addresses. All references to entities visible across modules is done utilizing "link tables". This makes it possible to change one module, with out making it necessary to re-compile all other modules. In ROM based application (for example) this makes it less expensive, as you have to replace fewer ROM chips. Normally, however you are right - only JSR (actually most of the time BSR) and RET are used. (I should know - I am currently responsible for the code generator of the CTP compilers) > >We would like to go to the 32532 in our next iteration of our design >for both our I/O and compute engines so I would be interested in >in any 32532 designs. > I think that NS and/or several other companies have announced 32532 VME SBC's. orr@nsc.NSC.COM IBM's motto: Machines should work, {amdhal,decwrl,hplabs,pyramid,sun}!nsc!orr People should think. Orr's remark: Neither do. Disclaimer: Opinions, come home. All is forgiven. Papa. -- orr%@nsc.NSC.COM IBM's motto: Machines should work, {amdhal,decwrl,hplabs,pyramid,sun}!nsc!orr People should think. Orr's remark: Neither do. Disclaimer: Opinions, come home. All is forgiven. Papa.
orr@taux01.UUCP (Orr Michael ) (03/30/88)
In article <862@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes: >In article <23506@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: >> >>To those of you who have suggested using GENIX, I would say DO NOT >>USE IT. Namely, the GENIX C compiler, along with GENIX itself, >>uses external procedures (i.e. cxp, rxp, lxp, etc) which is VERY >>VERY VERY VERY............ SLOW. >--------------------------------- > >Please do *NOT* confuse a SYSTEM with a COMPILER !!!!!!!! > Hear! Hear ! >Symetrics has a Genix port with there own complier/linker/etc. >that does *NOT* use cxp-et.al. I don't have hard timings, but I >have a good feel that the difference is only about 10 or 15% > >There *IS* a Green-Hill's compiler for the National, but it's not >cheap. It's code should be 15-25% faster than the symetics's. > As I mentioned before, NS has a full set of compilers, called CTP (Compiler Technology Project), which include 4 front-ends, (pascal,Modula2, C and Fortran77), a common global optimizer, and a common code generator (which I am currently responsible for). The compiler is part of the "GNX" language tools package, which, in turn, runs on (among other environments) a "GENIX" system, which is a port of SysV . I have no idea of the cost of any of these packages, as I am not involved in sales/marketing, but your (hopefully) local NS rep will be able to find out for you. I may (8-]) be biased, but I think CTP is worth looking into if you use the 32K chips. > John Wardale >... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw > -- orr@nsc.NSC.COM IBM's motto: Machines should work, {amdhal,decwrl,hplabs,pyramid,sun}!nsc!orr People should think. Orr's remark: Neither do. Disclaimer: Opinions, come home. All is forgiven. Papa. -- orr@nsc.NSC.COM IBM's motto: Machines should work, {amdhal,decwrl,hplabs,pyramid,sun}!nsc!orr People should think. Orr's remark: Neither do. Disclaimer: Opinions, come home. All is forgiven. Papa.
johnw@astroatc.UUCP (John F. Wardale) (03/31/88)
In article <537@taux01.UUCP> orr@taux01.UUCP (Orr Michael ) writes: >In article <23506@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: >> >> ... External Call stuff is *SLOW* > are slow , BUT, they provide a unique capability. The way this works > is that you can generate code that is totally free from relocateable > addresses. All references to entities visible across modules is done > utilizing "link tables". This makes it possible to change one module, > with out making it necessary to re-compile all other modules. In ROM > based application (for example) this makes it less expensive, as you > have to replace fewer ROM chips. Close, but *NO* cigar! The "CXP" insturction requires an "External Procedure Descriptor" (see below). Each module has a "link table" wich is a list of EPDs used by that module. Now if you change ONE routine in ONE module, you will shift *MANY* routines in that module. For each routine that's moved, you must: change its EPD in *EACH and EVERY* module that calls it. --> Bassically, "relink" the world! E.P.D = (the 16-bit address of the callED's MOD-table , the 16-bit offset of the called proceucure entry) - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Having a "link table" for each module is DEFINATLY a lossage for "ROM-ability" and the rest is just TOO slow! There are better alternatives, but ONLY if you can change the architecture. 1: make a "user-service-call" instruction that takes a *NUMBER* like an "SVC" instruction. (or a mod#, function# pair) ....maybe add a "Call-Look aside-Buffers" (cache) for speed. 2: Indirect procedure calls (see the Mac stuff) 3: RISC arguments: Do you even NEED normal "call" insturctions? (Personally I like the MIPS stuff) -- John Wardale ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw To err is human, to really foul up world news requires the net!
devoz@encore.UUCP (Joe Devincentis) (04/01/88)
[eat at joes] I had to respond to this, we have been ROMMING NS code since 1984....... >From: johnw@astroatc.UUCP (John F. Wardale) >Having a "link table" for each module is DEFINATLY a lossage for >"ROM-ability" and the rest is just TOO slow! > John Wardale >... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw Both the National guy, (with the Change one rom but not the rest story) and johnw are out of wack here. The cxp stuff and external procedure descriptors are only a pain for interrupt stuff (if you can get your compilers to generate bsr/jsr instead of cxp rxp). The interrupt vectors have to be "procedure descriptors", so you have to have a module table (at least one mod descriptor large). Since you only have a 16 bit mod table register, it has to be in the first 64K of memory (virtual, but for diags you run physical most of the time), so you often find that you have to have your rom image mapped over your first 64K of address space longer than you would like to, etc. It depends on the particular application, but it is not fatal. In the 532 you can have 32 bit addresses instead of procedure descriptors on the interrupt table, so all of these problems go away. Closing Editorial comments: You can ROM cxp rxp. It is a pain having module tables mainly because they have to sit in a limited address space. Interrupts with procedure descriptors suck. The 532 doesn't have any of these problems. National reps on the net tend to say the same caffeine crazed things that the rest of us say, which means they are human too! (This is just a rumor though :-)). Move to bsr and jsr and most of your rom problems go away (except the interrupt procedure descriptors). devoz@encore Joe DeVincentis