I was digging around in my garage and ran across an old 65832 datasheet which I had thought I lost:
http://www.flickr.com/photos/tm314159/9 ... /lightbox/
http://www.flickr.com/photos/tm314159/9 ... /lightbox/
If someone has a scanner and is interested in scanning them, let me know.
Toshi
65832 datasheet
-
GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: 65832 datasheet
I didn't realize we didn't have it on this site. I have it too, in perfect condition, so I could scan it, but it'll have to wait in line. My work slowed down so I got some time to work on the stacks primer, although I doubt I'll be able to finish it before the next flood of work hits. [Edit: It's up, at http://wilsonminesco.com/stacks/ .]
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: 65832 datasheet
Thanks Toshi. Searching on phrases therein I found this scan online - 53 pages, clean but not OCRed.
http://pdf.datasheetarchive.com/datashe ... 032005.pdf
It seems the Terbium was to be an odd mix of 8, 16, 24 and 32 bit capabilities. Most visibly, the standalone CPU has the same 24 bit address bus as the 65816, and even in an integrated chip program addresses are just 24 bits and still based on a 16 bit PC and an 8 bit Program Bank. Data addresses can be constructed up to 32 bits.
Cheers
Ed
http://pdf.datasheetarchive.com/datashe ... 032005.pdf
It seems the Terbium was to be an odd mix of 8, 16, 24 and 32 bit capabilities. Most visibly, the standalone CPU has the same 24 bit address bus as the 65816, and even in an integrated chip program addresses are just 24 bits and still based on a 16 bit PC and an 8 bit Program Bank. Data addresses can be constructed up to 32 bits.
Cheers
Ed
Re: 65832 datasheet
I found yet another scan of the 65832 datasheet here:
http://www.downloads.reactivemicro.com/ ... 20v2.0.pdf
The cover letter on this one is pretty funny:
"WDC told me on several occasions in our many telcons: "We have no such manual our
self now -- only made a dozen or so and mailed all of them out to clients many years
ago." I've never found anybody else that has one either.
Mine may well be the only one left in existence now (???). That's why I digitized it
*cover to cover* and put it online to share the info with the world."
So out of the dozen or so, two of them are owed by 6502.org members.
It looks like there's minor difference between the different 65832 datasheets:
reactivemicro.com: March 1990 version, 51 pages
datasheetarchive.com: March 1990 version, 51 pages + ICE page + publications page = 53 pages
Me: March 1990 version, 51 pages + extra pinout diagram page (March 1991) + disclaimer page = 53 pages
Garth: ? version
It looks like the 51 page versions have the PLCC pinout on page 10, so they seem to be the same.
Toshi
http://www.downloads.reactivemicro.com/ ... 20v2.0.pdf
The cover letter on this one is pretty funny:
"WDC told me on several occasions in our many telcons: "We have no such manual our
self now -- only made a dozen or so and mailed all of them out to clients many years
ago." I've never found anybody else that has one either.
Mine may well be the only one left in existence now (???). That's why I digitized it
*cover to cover* and put it online to share the info with the world."
So out of the dozen or so, two of them are owed by 6502.org members.
It looks like there's minor difference between the different 65832 datasheets:
reactivemicro.com: March 1990 version, 51 pages
datasheetarchive.com: March 1990 version, 51 pages + ICE page + publications page = 53 pages
Me: March 1990 version, 51 pages + extra pinout diagram page (March 1991) + disclaimer page = 53 pages
Garth: ? version
It looks like the 51 page versions have the PLCC pinout on page 10, so they seem to be the same.
Toshi
Re: 65832 datasheet
Any guesses as to how XFE was to be fitted in? There's no hint that they were thinking of using COP or WDM to help. Would it be too backward-incompatible to reuse XCE when in 16 bit mode? If overflow flag V is generally clear, then it would usually pop into 32 bit mode, which would make it rather incompatible.
-
GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: 65832 datasheet
Quote:
Garth: ? version
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: 65832 datasheet
BigEd wrote:
Any guesses as to how XFE was to be fitted in? There's no hint that they were thinking of using COP or WDM to help. Would it be too backward-incompatible to reuse XCE when in 16 bit mode? If overflow flag V is generally clear, then it would usually pop into 32 bit mode, which would make it rather incompatible.
http://mirrors.apple2.org.za/ground.ica ... n/cpu65832
Contents of webpage (in case it disappears):
David Empson <dempson@actrix.gen.nz> wrote:
> Bryan Parkoff <BParkoff@satx.rr.com> wrote:
>
> > 65832 Manual Is Found!
> >
> > Go to http://www.apple2.org.za/gswv/A2.LOST.N ... CPU.65832/
>
> Thanks for the pointer.
>
> It is in a rather awful format (separate GIF document for each page,
> with no HTML index), so it will take me a little while to absorb its
> contents.
Well that was a non-event.
If this document is accurate, then the only differences between the
65832 and 65816 would have been:
- Three layers of emulation mode (65832 native, 65816 emulation and
65C02 emulation). The existing 'E' flag bit is renamed 'E8' and a
second 'E16' flag is added. The new XFE instruction toggles the E16 and
E8 flags with the V and C flags respectively.
- 32-bit A, X and Y registers available in 65832 native mode. X and Y
can be either 32-bit or 8-bit (controlled by 'X' flag). A can be
32-bit, 16-bit or 8-bit (controlled by 'M' and 'E8' flags).
- Yet another set of interrupt vectors in 00FFD0-00FFDF for use in
32-bit native mode.
That's it. No new instructions (apart from XFE) or addressing modes.
No improvements to the placement of the stack or direct page.
It theoretically supports a 32-bit address space, but there is no way to
access more than 16 MB outside of the chip. The rest of the 4 GB
address space would only be available in an ASIC which incorporated the
65832 as a CPU module, and appears to have very limited addressing
options.
The second half of the document is basically identical to the 65816 data
sheet.
I couldn't see any evidence that an opcode had been allocated for the
new XFE instruction. Since the 65816 uses all but one of the possible
opcodes, and the last one was reserved as a pre-byte, the XFE would
require a two byte opcode, probably WDM (0x42) followed by an
unspecified second byte (with the XCE opcode being a likely candidate).
--
David Empson
dempson@actrix.gen.nz
Re: 65832 datasheet
The 65832 would provide a 32 bit accumulator operations but doesn't really support a 32 bit address space very well. The program space is limited to 24 bits. It's just the I/O and data space that could be 32 bits. The problem with it is support for backwards compatibility, which is very important. This could be overcome using more pages of opcodes, or an address control register somewhere in the memory map.
The 65816 uses the M bit to choose between byte and 16 bit word accesses. Most other cpu's use separate instructions.
It would be nice if indirect long addressing and absolute long addressing supported a 32 bit length. It would make it easier than manipulating a 24 bit address value.
As Garth mentioned elsewhere, it would be nice if the bank registers were simply 32 bit. With 32 bit bank registers they would really operate like segment base registers.
Along with an increased address space it might be nice to have a DRAM controller onboard, it could cut down on the pincount as well. One could use a 1Mx4 DRAM for instance to get 512kB of memory. (4 bits wide memory). With an onboard instruction cache, a nybble wide memory probably wouldn't impact performance that much.
The 65816 uses the M bit to choose between byte and 16 bit word accesses. Most other cpu's use separate instructions.
It would be nice if indirect long addressing and absolute long addressing supported a 32 bit length. It would make it easier than manipulating a 24 bit address value.
As Garth mentioned elsewhere, it would be nice if the bank registers were simply 32 bit. With 32 bit bank registers they would really operate like segment base registers.
Along with an increased address space it might be nice to have a DRAM controller onboard, it could cut down on the pincount as well. One could use a 1Mx4 DRAM for instance to get 512kB of memory. (4 bits wide memory). With an onboard instruction cache, a nybble wide memory probably wouldn't impact performance that much.
Re: 65832 datasheet
.....huff, huff, (back in there creature!!)...huff, huff...
Necromancy is tiring.
_______________________________________________________________________________________________
I have looked briefly at a few of the 65x+32 projects out there. I have read through the 65832 datasheet and around this board 'some'.
Because this topic is kinda hot and this is as good a place as any to jump in, I want to discuss a few things I think are crucial to a 32-bit 65xx series chip.
Full 32 bit addressing as Rob Finch mentions above. Just make is have 8/16, 16/24, and 32/64 (or 32/32) addressing on it's registers and emulation modes.
Additional Registers:
Z-Index.
the Z register is exactly the same as the X and Y registers. this will facilitate a lot of 3d math for graphics, physics and geometry.
T/time (or J/jump).
this is basically a second accumulator, or 'accumulator junior'. this is halfway between an accumulator and an index register, with some operations/address modes from each. It may need a status bit to change modes. In 'T' mode, or T-ops, it is an index register that that can be used for tracking time in simulations, functions, formulas etc. it would have a set of increments and update operations, to update X, Y and Z registers with an offset, or sequential offset, like in a 1d, 2d or 3d array. It would facilitate things like that. In 'J' mode or J-ops, the register can act as a secondary accumulator for common operations to be done simultaneously, or it can do basic branch prediction, so on say a BNE, when the Accumulator is performing its comparison, the J-register already has the next instruction from the BNE address ready to go because if the comparison is equal, it will just get whatever is next anyway. So the Acc and J/T register would have opcodes that did simultaneous actions, or one register could access memory during cycles the Acc was busy.
Opcodes to support better Scalar capability, or potentially Super-Scaler pipelining.
Opcodes to use the new registers, loading, comparisons etc.
Opcodes for a lot of 3d matrix ops on x, y and z, and 4d ops using J/T as well.
Moving the stack onto the chip as an L1 cache.
__________________________________________________________________________
beyond this, not a lot of things I would change really. an FPU maybe. DMA controller or similar?
Necromancy is tiring.
_______________________________________________________________________________________________
I have looked briefly at a few of the 65x+32 projects out there. I have read through the 65832 datasheet and around this board 'some'.
Because this topic is kinda hot and this is as good a place as any to jump in, I want to discuss a few things I think are crucial to a 32-bit 65xx series chip.
Full 32 bit addressing as Rob Finch mentions above. Just make is have 8/16, 16/24, and 32/64 (or 32/32) addressing on it's registers and emulation modes.
Additional Registers:
Z-Index.
the Z register is exactly the same as the X and Y registers. this will facilitate a lot of 3d math for graphics, physics and geometry.
T/time (or J/jump).
this is basically a second accumulator, or 'accumulator junior'. this is halfway between an accumulator and an index register, with some operations/address modes from each. It may need a status bit to change modes. In 'T' mode, or T-ops, it is an index register that that can be used for tracking time in simulations, functions, formulas etc. it would have a set of increments and update operations, to update X, Y and Z registers with an offset, or sequential offset, like in a 1d, 2d or 3d array. It would facilitate things like that. In 'J' mode or J-ops, the register can act as a secondary accumulator for common operations to be done simultaneously, or it can do basic branch prediction, so on say a BNE, when the Accumulator is performing its comparison, the J-register already has the next instruction from the BNE address ready to go because if the comparison is equal, it will just get whatever is next anyway. So the Acc and J/T register would have opcodes that did simultaneous actions, or one register could access memory during cycles the Acc was busy.
Opcodes to support better Scalar capability, or potentially Super-Scaler pipelining.
Opcodes to use the new registers, loading, comparisons etc.
Opcodes for a lot of 3d matrix ops on x, y and z, and 4d ops using J/T as well.
Moving the stack onto the chip as an L1 cache.
__________________________________________________________________________
beyond this, not a lot of things I would change really. an FPU maybe. DMA controller or similar?
Re: 65832 datasheet
ahhh the dreams of a 32-bit 6502 CPU. i have been working every now and then on a draft for my own flavor of 32-bitness.
re-reading the 65k project pages, i can see some similarities here and there. but i think my design is distinct enough to not be called a copy...
for example my design does have a Z Index Register and all related instructions (LDZ, STZ, CPZ, INZ, DEZ, TAZ, TZA, PHZ, PLZ).
It also has a full 32-bit Stack Pointer, Directpage Pointer, and 4 Abs. Base Registers (used for Absolute addressing modes) of which only 1 can be active at a time.
the Prefixes also work a bit differently. for example you cannot stack them, so an instruction can only ever have 1 prefix at most.
but i never thought about having instructions for directly dealing with multi dimensional arrays. personally i would have some external co-processor to deal with stuff like that (like a DMA/Math CoProcessor combo chip). built-in complex operations like that don't really fit the KISS principle IMO...
for example simply converting a set of 3D coordinates to a 1D index into an array would probably take around 90 clock cycles (assuming 32-bit multiplication takes 32 cycles). doing that in hardware is expensive, bloats your CPU's logic footprint, and likely lowers the maximum operating frequency. meanwhile you could just have hardware MUL/DIV instructions and do the rest in software, which is obviously slower and takes up more program space... but makes the underlying hardware simplier.
i wrote this little mockup of how a 3D coordinate to 1D index function would look like on my system, though obviously i cannot test it right now. the math should be correct though.
anyways i won't go into too much detail about my design, in fear of bringing the thread too off topic.
re-reading the 65k project pages, i can see some similarities here and there. but i think my design is distinct enough to not be called a copy...
for example my design does have a Z Index Register and all related instructions (LDZ, STZ, CPZ, INZ, DEZ, TAZ, TZA, PHZ, PLZ).
It also has a full 32-bit Stack Pointer, Directpage Pointer, and 4 Abs. Base Registers (used for Absolute addressing modes) of which only 1 can be active at a time.
the Prefixes also work a bit differently. for example you cannot stack them, so an instruction can only ever have 1 prefix at most.
but i never thought about having instructions for directly dealing with multi dimensional arrays. personally i would have some external co-processor to deal with stuff like that (like a DMA/Math CoProcessor combo chip). built-in complex operations like that don't really fit the KISS principle IMO...
for example simply converting a set of 3D coordinates to a 1D index into an array would probably take around 90 clock cycles (assuming 32-bit multiplication takes 32 cycles). doing that in hardware is expensive, bloats your CPU's logic footprint, and likely lowers the maximum operating frequency. meanwhile you could just have hardware MUL/DIV instructions and do the rest in software, which is obviously slower and takes up more program space... but makes the underlying hardware simplier.
i wrote this little mockup of how a 3D coordinate to 1D index function would look like on my system, though obviously i cannot test it right now. the math should be correct though.
Code: Select all
WIDTH = ???
HEIGHT = ???
SIZE = HEIGHT * WIDTH
; Converts a set of 3D Coordinates to a 1D Index (32-bit)
; Inputs: X, Y, and Z (Index Registers)
; Output: A (Accumulator)
3d_to_1d:
PHX.L ; Save X to the Stack
TYA.L ; Move Y into A
LDX.L #WIDTH ; Load the Width of the Array into X
MUL.L ; Y * WIDTH
CLC
ADC.L 1,S ; X + (Y * WIDTH)
STA.L 1,S ; Put the Result back onto the Stack
TZA.L ; Move Z into A
LDX.L #SIZE ; Load the 2D Size of the Array into X
MUL.L ; SIZE * Z
CLC
ADC.L 1,S ; (SIZE * Z) + X + (Y * WIDTH)
PLX.L ; Dummy Pull to restore the Stack
RTS
; Note that MUL multiplies the values in A and X, and stores the result into A (lower half) and X (upper half)
; Hand Assembled:
; Opcode
; Prefix | Operands
; | | ______|______
; v v / \
PHX.L ; $2F $DA
TYA.L ; $2F $98
LDX.L #WIDTH ; $2F $A2 $xx $xx $xx $xx
MUL.L ; $2F $44
CLC ; $18
ADC.L 1,S ; $AF $65 $01 $00
STA.L 1,S ; $AF $85 $01 $00
TZA.L ; $2F $EB
LDX.L #SIZE ; $2F $A2 $xx $xx $xx $xx
MUL.L ; $2F $44
CLC ; $18
ADC.L 1,S ; $AF $65 $01 $00
PLX.L ; $2F $FA
RTS ; $60
; 39 Bytes and maybe like 120-140 Cycles Total