apm279l@vaxc.cc.monash.edu.au (11/21/90)
Hi, I am working on (and have almost finished) a saturn -> C converter which
should make it simple to debug saturn code. If it is of interest I'll place
it in the public domain (that's the sweetener!) Now: I have a few questions
re the Saturn processor (I could find out for myself by experiment, but to
save me some time as I'm very snowed under at the moment...)
(1) According to the now biblical processor notes (thanks Alonzo!)
the branch instructions affect the carry. I need to know *how*
it is affected. I *guess* that (for example) brgt.f a,c,label
does a subtraction, but is it "a-c" or "c-a"?? what about
breq, brge, brle, brlt etc. What about brz and brnz??
(2) What about neg.f X - how is carry alterred? It could either take
a two's complement by inverting and THEN incrementing, or by
decrementing, THEN inverting.
(3) gosub, gosubvl, gosubl also affect carry - is this because the processor
takes PC.a+OFFSET.a ?
(4) How do the IN and OUT registers get used? (I know they are used somehow
for I/O - but what happens, for example when you put something in OUT,
how does IN receive input? and from where? - I though the keyboard was
bufferred in memory (#F.... something)
(5) What's known about the BUS commands? (BUSCB, BUSCC, BUSCD - do these put
the contents of B,C or D on the bus? if so, what field is put?)
CON/UNCONFIG, MOVE.A ID,C, SREQ, RESET. - I have the brief descriptions
of these from Alonzo's notes, but what are the chips in question? What
are the ID's, what happens when you config/unconfig/reset the chip?
I know there is a lot here, and I may not implement all these command in my
first release (depending on complexity) - but I'd like to make the converter
as realistic as I can. I have not seen any details on this stuff in c.s.h
and I imagine there'd be quite a few users out there with the same questions.
Thanx in adv, Peterbson@rice-chex.ai.mit.edu (Jan Brittenson) (11/22/90)
In article <72330.274a4cb2@vaxc.cc.monash.edu.au> apm279l@vaxc.cc.monash.edu.au writes: >(1) According to the now biblical processor notes (thanks Alonzo!) > the branch instructions affect the carry. I need to know *how* > it is affected. I *guess* that (for example) brgt.f a,c,label > does a subtraction, but is it "a-c" or "c-a"?? what about > breq, brge, brle, brlt etc. What about brz and brnz?? The carry flag is set whenever a branch is taken, and cleared when not taken. >(3) gosub, gosubvl, gosubl also affect carry - is this because the processor > takes PC.a+OFFSET.a ? Where did you find your processor notes?! My says nothing about "gosub" instructions and branches affecting the carry. >(4) How do the IN and OUT registers get used? (I know they are used somehow > for I/O - but what happens, for example when you put something in OUT, > how does IN receive input? and from where? - I though the keyboard was > bufferred in memory (#F.... something) Various bits go to different places. The keyboard is scanned by software. OUT bit 10 turns the speaker off, 11 turns it on, and the bits 0-4 are used to output the keyboard column when scanning. Bit 0 is the right-most column. Scanning is performed by putting the column mask in the OUT register and reading the row pattern with IN. Bit 0 is the bottom row, and bit 8 the top (menu) row. I'd love to know how the remaining bits are used!
alonzo@microsoft.UUCP (Alonzo GARIEPY) (12/02/90)
Here are the answers to your questions, with some help from a higher authority (HA). Please repost to comp.sys.handhelds and save me the effort. Alonzo In article <72330.274a4cb2@vaxc.cc.monash.edu.au> apm279l@vaxc.cc.monash.edu.au writes: | (1) According to the now biblical processor notes (thanks Alonzo!) | the branch instructions affect the carry. I need to know *how* | it is affected. I *guess* that (for example) brgt.f a,c,label | does a subtraction, but is it "a-c" or "c-a"?? what about | breq, brge, brle, brlt etc. What about brz and brnz?? If the branch is taken (i.e., the test is true) the carry bit is set. | (2) What about neg.f X - how is carry altered? It could either take | a two's complement by inverting and THEN incrementing, or by | decrementing, THEN inverting. Seems to me that the NEG instruction will set carry according to whether the result is 0. This is the only case where decrementing before inversion or incrementing after inversion will cause overflow. The order of operations is therefore irrelevant. Try it and see. This command performs a 2's complement, or 9's complement, depending on the DEC/BIN mokde. The NOT instruction performs a 1's complement, or 10's complement, depending on the DEC/BIN mode. It clears the carry bit. | (3) gosub, gosubvl, gosubl also affect carry - is this because the processor | takes PC.a+OFFSET.a ? I am told that this is absolutely untrue. They do not affect carry. | (4) How do the IN and OUT registers get used? (I know they are used somehow | for I/O - but what happens, for example when you put something in OUT, | how does IN receive input? and from where? - I though the keyboard was | bufferred in memory (#F.... something) It's a cool idea to add stuff to the bus and do IO, but I'm not a hardware junkie. The instructions OUT=C and OUT=CS send the X or least significant nibble of C. The instructions A=IN copies IN into nibbles 0 through 3 of A, and C=IN does likewise to C. --HA | (5) What's known about the BUS commands? (BUSCB, BUSCC, BUSCD - do these put | the contents of B,C or D on the bus? if so, what field is put?) | CON/UNCONFIG, MOVE.A ID,C, SREQ, RESET. - I have the brief descriptions | of these from Alonzo's notes, but what are the chips in question? What | are the ID's, what happens when you config/unconfig/reset the chip? The bus commands issue a sequence that is intrepreted by the chips on the bus - they do not send register contents. Unless you are adding Saturn chips to the bus that are smart enough to interpret bus commands and not torch the 48's configuration, there's no reason to support these instructions. They were most useful on the 71, but since the 48's address space is spoken for, they're just PLA wasters now. --HA Alonzo Gariepy alonzo@microsoft