nakada@husc4.HARVARD.EDU (Paul Nakada) (04/07/89)
From what I gather, Sweet 16 is some instruction set for a 16 bit
P-Code machine... I have Merlin Pro, which allows for assembly of sweet
16 opcodes, but I have never seen or heard of any documentation for the
sweet 16 interpreter not have i seen the actual interpreter...
Where is sweet 16? how does one get it and its documentation?
thanks for your help..
-paul nakada
__
| Paul Nakada '89 #8-) |
North House | nakada@husc4.HARVARD.EDU
Harvard College | seismo>!harvard!husc4!nakada.UUCP
Cambridge, MA 02138 | rutgers/ nakada@husc4.BITNET
617/498-6255 || 6264 | __|smw@cbnewsl.ATT.COM (scott.wincklhofer) (04/07/89)
In article <1568@husc6.harvard.edu>, nakada@husc4.HARVARD.EDU (Paul Nakada) writes: > > From what I gather, Sweet 16 is some instruction set for a 16 bit > P-Code machine... I have Merlin Pro, which allows for assembly of sweet > 16 opcodes, but I have never seen or heard of any documentation for the > sweet 16 interpreter not have i seen the actual interpreter... > > Where is sweet 16? how does one get it and its documentation? > thanks for your help.. > -paul nakada > __ > | Paul Nakada '89 #8-) | > North House | nakada@husc4.HARVARD.EDU > Harvard College | seismo>!harvard!husc4!nakada.UUCP > Cambridge, MA 02138 | rutgers/ nakada@husc4.BITNET > 617/498-6255 || 6264 | __| Sweet 16 is a meta processor, that is it is an immaginary 16 bit processor which was invented by Woz. As a sixteen bit processor it is fairly flexible, featuring 16 16 bit registers 12 of which are general purpose. The instruction set is about as extensive as that of the 6502 if maybe even a little less so. So what is the catch? How can you use this processor? Why have you not heard about it before? The swweet 16 was implemented as an interpreter, that is you would write 6502 code to jump to this interpreter, after which it was expected that sweet 16 code would follow the subroutine call. Thus sweet 16 code runs about half as fast as 6502 code. The final catch to using sweet 16, and this is why not many people have heard about it is that the interpreter was located in the integer basic ROMs that came with the original apple II's. So the only way for anyone without integer basic to use sweet 16 is for the programmer to include the interpreter in his program. I think that I have a disassembled listing of this interpreter somewhere but I'm not sure if I should post it knowing how touchy Apple can be with its software copyrights. If anyone can advise me on this I would appreciate it. Sorry this went on so long, but I've been writing a paper for the past two weeks and its hard to stop being verbose when I'm not writing it. Hope this helps Scott Wincklhofer ------------------------------------------------------------------------------- Scott Wincklhofer AT&T Bell Laboratories Whippany NJ whuts!smw
ALBRO@NIEHS.BITNET (04/08/89)
Paul Nakada asks "What is Sweet 16?" Sweet 16 is Woz's assembly language machine in the AppleII and /or II+ to allow floating point arithmetic. In a sense, it's the ultimate precursor of the SANE routine.
dseah@wpi.wpi.edu (David I Seah) (04/08/89)
In article <1568@husc6.harvard.edu> nakada@husc4.UUCP (Paul Nakada) writes: >Where is sweet 16? how does one get it and its documentation? >thanks for your help.. I've never actually used it for anything, but Sweet-16 was a set of subroutines in the ancient Integer Basic ROM of the Apple II. Sweet 16 code was an "ideal" 16 bit machine language that was interpreted by the firmware. It got squeezed out in the new Autostart ROMs. There used to be single step & trace, a mini-assembler and a floating point arithmetic package too. I can't seem to find any documentation on it either. Lost in time...perhaps some Really Old hacker other there could clarify. :) Dave Seah (dseah@wpi.wpi.edu, dseah@wpi.bitnet); "The world can be saved by steam!"
mw22+@andrew.cmu.edu (Michael Alan Wertheim) (04/08/89)
Sweet 16 has nothing to do with P-code. It is a sort-of-16-bit assembly language interpreter. The Sweet-16 language is pretty low level, giving the user 16 16-bit "registers" and a few instructions to manipulate them. It is fairly easy to intersperse 6502 code with Sweet-16 code, and vice versa. Sweet-16 was written way back in 1978 or so (by Wozniak, I think). It *might* be included in the 50-sector file "INTBASIC" on the DOS 3.3 System Master disk. (There are two verisons of INTBASIC. The 43-sector version contains the language Integer Basic. The 50-sector version contains Integer Basic plus some nifty utilities, including hi-res routines, chromatic-scale-based sound routines, and an assembly language program relocator. I can't recall if the Sweet-16 interpreter is included in the 50-sector version of INTBASIC or not.) Anyway, I know I have some info on Sweet 16 back at home. I'll look into it.... Michael Wertheim Carnegie Mellon University Pittsburgh, PA Arpa: mw22@andrew.cmu.edu Bitnet: mw22%andrew@cmccvb =========================== "I wish I was in / Tijuana / eating barbe- / cued iguana." -- Wall of Voodoo
brianw@microsoft.UUCP (Brian Willoughby) (04/11/89)
In article <8904071330.aa29809@SMOKE.BRL.MIL>, ALBRO@NIEHS.BITNET writes: > Paul Nakada asks "What is Sweet 16?" > > Sweet 16 is Woz's assembly language machine in the AppleII and /or II+ to > allow floating point arithmetic. In a sense, it's the ultimate precursor > of the SANE routine. I hate to break it to you, but the Sweet 16 routines do not include floating point arithmetic by any means! There is a fully descriptive article in an ancient Byte magazine article which I think was written by the Woz. For those of you with complete libraries nearby, I'll go home tonight and find the issue. From memory, the Woz had a thought that BASIC would be much easier to write with a 16-bit processor, so he simulated one with the instructions he needed and wrote INTEGER BASIC. The genius of The Woz (in both hardware and software) never ceases to amaze me! The Sweet 16 routines are available to anyone who has 64K and the system disk file INTEGER (or an original II, ed.). Regarding another post, the 50 sector INTEGER is larger because it includes the Monitor code. It is basically a BSAVE of $D000.FFFF on an Apple II. After Apple designed the 16K card with the AutoStart ROM on it, they didn't want the easily frightened nouveau crowd of II users to have the AutoStart disabled by loading the contents of the old Monitor ROM in the Language Card. Therefore, the 42 sector INTEGER file is only addresses $D000.F7FF. This is where LOADER.OBJ0 was born. This code (with the proper Basic calling program) copies whatever data is in the motherboard ROM at $F800.FFFF into the RAM bank at the same address. THEN it loads $D000.F7FF with INTEGER Basic. The smaller INTEGER has all the features (i.e. Sweet 16, Mini-Assembler, HiRes Routines and Basic) but it lacks the features of the original Monitor ROM (i.e. 6502 Single-Step and Tracing). An interesting note, it seems like Apple really wanted to push the AutoStart ROM. The 16K RAM card with the 24-pin ROM on it permanently disabled whatever ROM was at $F800.FFFF, and they also tried to prevent it from being overwritten in the RAM bank. I guess this was a combination of keeping software writers happy, because they could almost be guaranteed RESET protection, and making it harder for the hackers to get deep into the guts of the Apple II. In some ways I feel that this early move started the trend of fewer knowledgable hackers, and paved the way for the "new generation" of Apple users who learned BASIC instead of Assembly. Alluding to an earlier post, I can say that my current software engineering career was built on the struggle I went through with my Apple II. Before the Plus and AutoStart, you booted into the Monitor without the fancy "Apple II" title, and I eventually was forced into learning what all those funny 3-letter mnemonics meant. I can't complain too much now, because I like the convenience of restarting with RESET. But I still keep the original non-AutoStart ROM available by a flip of a switch (2732 4K ROMs) for avoiding the dreaded power-off method of cold-start which wreaks havoc on digital circuits. Brian Willoughby microsoft!brianw@uunet.UU.NET or uw-beaver!microsoft!brianw or just microsoft!brianw
jearls@polyslo.CalPoly.EDU (Johnson Michael Earls) (04/12/89)
The source listings for Sweet-16, as well as for the original Monitor ROM,
floating point routines, and mini-assembler, are all in the original
"red book" Apple ][ manual.
P.S. -- Anyone out there know where you can buy a copy of this manual? Ours is
falling apart, and I would really like to get another copy...
___________________________________________________________
(~~~~) / \
( 0 0 ) | Johnson Earls - jearls@polyslo.CalPoly.EDU |
(| > |) ___/ - jearls@polyslo.UUCP |
( \__/ ) <___ - ..!ucbvax!voder!polyslo!jearls |
(____) \_____________________________________________________________/kucharsk@uts.amdahl.com (William Kucharski) (04/12/89)
In article <10183@polyslo.CalPoly.EDU> jearls@polyslo.CalPoly.EDU (Johnson Michael Earls) writes: >The source listings for Sweet-16, as well as for the original Monitor ROM, >floating point routines, and mini-assembler, are all in the original >"red book" Apple ][ manual. > > >P.S. -- Anyone out there know where you can buy a copy of this manual? Ours is >falling apart, and I would really like to get another copy... Well, considering I saw an ad (I think it was APDA) about the close-out of DOS 3.3 Manuals (Get yours now - what a collector's item), I believe the only way to get another Red Book would be to photocopy it and have it rebound. Either that, or perhaps some Apple dealer in Podunk County USA has one in the back room somewhere (next to the piles of Integer Basic, Applesoft Tutorial and Graphics Tablet manuals). Ah, the red book. I was beginning to wonder if I had just dreamed the manual... -- William Kucharski ARPA: kucharsk@uts.amdahl.com UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk Disclaimer: The opinions expressed above are my own, and may not agree with those of any other sentient being, not to mention those of my employer. So there.
mw22+@andrew.cmu.edu (Michael Alan Wertheim) (04/12/89)
The following is based on an assembly listing of a Sweet-16 program. I have
attempted to decipher the instruction set from the listing....
Unfortunately, I did all this at home and forgot to write down the entry point
to Sweet-16. (It begins with $F6....) Also, there seem to be two different
entry points to Sweet-16, and I'm not sure about the difference between the two.
First of all, Sweet-16 was written by Woz in 1977. It is included in the
50-sector INTBASIC file.
Sweet-16 is a 16-bit pseudo assembly language. Sweet-16 instructions can be
written in-line with 6502 instructions. Sweet-16 gives you 16 16-bit registers,
numbered 0 through 15. Register 0 is also Sweet-16's accumulator. Sweet-16
also maintains its own condition codes. I think Sweet-16 preserves the values
of the A, X, and Y registers on entry and restores them on exit.
For most Sweet-16 instructions: Each instruction is encoded in one byte. The
first nibble of the byte specifies the instruction. The second nibble specifies
which register is to be used.
I have constructed the follwong table based on the Sweet-16 assembly that I
have. Unfortunately, the Sweet-16 program that I am looking at (Woz's renumber
utility for Integer Basic) only uses about 80% of the Sweet-16 instruction set,
so the table is incomplete.
Value of Example Encoding for What this
first nibble instruction this example example does
========================================================================
1 SET 3 $1234 13 12 34 Stores the value $1234
in reg 3
2 LD 3 23 Loads accumulator with
value stored in reg 3
3 ST 7 37 Stores accumulator
value into reg 7
4 LD @1 41 Loads accumulator with
contents of memory
word whose address
is stored in reg 1
5 ST @2 52 Stores accumulator
value into the memory
word whose address
is stored in reg 2
6 LDD @9 69 ?
7 STD @7 77 ?
8 Not used in the program I have
9 Not used in the program I have
A ADD 8 A8 Adds value of reg 8 to
accumulator and stores
sum in accumulator
B SUB 5 B5 Subtracts value of reg 5
from accumulator and
stores difference in
accumulator
C POPD @3 C3 ? -- Woz's program has a
few POPD instructions but
no "PUSHD" instructions.
D CPR 8 D8 Compares accumulator
value with value in reg 8
E INR 9 E9 Increments reg 9
F DCR 9 F9 Decrements reg 9
If the first nibble of the instruction byte is 0, then the instruction is a
branch instruction, which is sometimes a 2-byte instruction. The second nibble
determines the type of branch. If needed, the an 8-bit signed offset is stored
in the second byte of the instruction.
Value of Example Encoding for What this
second nibble instruction this example example does
========================================================================
0 RTN 00 Signifies that the
next instructions are
6502 instructions
1 Not used in the program I have
2 BNC label 02 10 Branches to label if
carry bit is clear
3 BC label 03 10 Branches to label if
carry bit is set
4 Not used in the program I have
5 BM label 05 10 ?
6 BZ label 06 10 Branches to label if
zero bit is set
7 BNZ label 07 10 Branches to label if
zero bit is clear
8 BMI label 08 10 Branches to label if
minus bit is set
9 BNMI label 09 10 Branches to label if
minus bit is clear
A-F Not used in the program I have
Example program:
SW16 EQU $F6?? ; Sweet-16 entry point
CROUT EQU $FDED ; Character out routine
LDA #7 ; Load 7 (ascii bell value) into A
JSR CROUT ; Ring the bell
JSR SW16 ; Execute the following instructions
; as Sweet-16 instructions
SET 1 1000 ; Load reg 1 with 1000
loop DCR 1 ; Decrement reg 1
BNZ loop ; If reg 1 isn't 0, loop back
RTN ; Execute the following instructions
; as 6502 instructions
JSR CROUT ; Ring the bell again (A is still 7)
RTSlar@usl-pc.usl.edu (Robert Lane A.) (04/17/89)
In article <gYEpcsy00W0N0Aulw6@andrew.cmu.edu> mw22+@andrew.cmu.edu (Michael Alan Wertheim) writes: >The following is based on an assembly listing of a Sweet-16 program. I have >attempted to decipher the instruction set from the listing.... > >Unfortunately, I did all this at home and forgot to write down the entry point >to Sweet-16. (It begins with $F6....) Also, there seem to be two different >entry points to Sweet-16, and I'm not sure about the difference between the two. > One is $F689, don't know the other. [...] >Value of Example Encoding for What this >first nibble instruction this example example does >======================================================================== [...] > 4 LD @1 41 Loads accumulator with > contents of memory > word whose address > is stored in reg 1 > > 5 ST @2 52 Stores accumulator > value into the memory > word whose address > is stored in reg 2 > The above instructions load or store the low byte of the accumulator with the value of the BYTE pointed to by the contents of the memory word stored in register 'n'. Also increment register 'n' by 1. > 6 LDD @9 69 ? > > 7 STD @7 77 ? Same as instructions 4 & 5, except they load/store an entire 16-bit word into/from the accumulator. Also increment reg. 'n' by 2. > 8 Not used in the program I have POP @R8 88 Decrement R8 by 1, then load acc from R8 indirect. > 9 Not used in the program I have STP @R9 99 Decrement R9 by 1, then store acc from R9 indirect. [...] > C POPD @3 C3 ? -- Woz's program has a > few POPD instructions but > no "PUSHD" instructions. > Decrement R3 by 2, then load acc from R3 indirect. Also, there is no "PUSHD" instruction. [...] >If the first nibble of the instruction byte is 0, then the instruction is a >branch instruction, which is sometimes a 2-byte instruction. The second nibble >determines the type of branch. If needed, the an 8-bit signed offset is stored >in the second byte of the instruction. Actually, instructions with first nibble 0 are called nonregister ops, most of which are branches. >Value of Example Encoding for What this >second nibble instruction this example example does >======================================================================== > 0 RTN 00 Signifies that the > next instructions are > 6502 instructions > > 1 Not used in the program I have BR label 01 10 Branch always to label [...] > 4 Not used in the program I have BP label 04 10 Branch on plus result > 5 BM label 05 10 ? Branch on minus result > A-F Not used in the program I have A BK label 0A 10 Cause a 6502 BRK B RS 0B Return from a Sweet-16 subroutine C BS label 0C 10 Branch to a Sweet-16 subroutine Opcodes D-F are unassigned. My information comes from the book "Apple Programmer's Handbook" by Paul Irwin, published by Howard W. Sams & Co. Lane ------------------------------------------------------------------------ Lane Robert lar@usl.usl.edu ...!{killer, uunet!dalsqnt}!usl!lar University of Southwestern Louisiana Computing Center Lafayette, LA