Looking for AMD 29K User's Manual

"Bart T." wrote

Do you mean FPGA Core emulation, or SW emulation, or even code-morphing on a P4 ?

If you draw a blank on that, you could try using a 29xxx Assembler and the test files, such as

as also search to see what's been done on FPGA Cores around the 29xxx. It would seem that the latest FPGA iterations would suit a 29xxx core. What's the tool-chain status for 29xxx devices ?

-jg

Isn't the 29000 a 4 bit ALU slice from about 1970, and in no way a computer. Or am I confusing things?

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

I should have a complete set of documentation here *someplace*. Of course, figuring out *which* place is the *trick*! :-/ Undoubtedly, stashed with my copy of Mick & Brick (wherever *that* went...)

I'll try to dig through the various boxes that it *may* be in sometime over the holidays -- but don't get your hopes up...

--don

N.B. Incoming mail is not accepted at this email address.

Software emulation. I'm looking at a very old system which uses a 29K as a math co-processor.

Thanks. I'll be taking a look at this, it should be handy for testing. I grabbed the GNU binutils sources which include a 29K disassembler, so I now know the opcodes, but having the actual programming manual would still be very useful.

I'm not sure if the GNU tools are actively supporting it anymore. It's not a problem for me since I'm not planning on writing any new 29K code.

"CBFalconer"

The 2900/2901/2903 are the Bit Slice models. Of course, someone COULD want to emulate that, in eg a student project :)

The 29000 was rather different ( more of a jump than the add-a-digt 8086 ->

80186 :) It was widely used in laser printers, for a while.

This from a web summary The AMD 29000 family is a 32-bit RISC architecture introduced in 1988. Notable characteristics include: 192 registers divided into 64 global registers (gr64-gr127) and 128 local registers (gr128-gr255) local registers form the top of a register stack that is backed by a larger stack in memory access to local registers is relative to a register stack pointer (rsp = gr1) and is calculated modulo 128 a separate memory stack is provided for parameters beyond 16 words and for parameters and local variables that must be memory allocated (i.e., for which addresses are needed) procedure conventions for entry and exit includes register stack pointer adjustment and software checks for underflow and overflow using assert instructions that conditionally cause traps input parameters are passed in overlapped local registers, return values are passed in global registers a trace-back tag convention was defined for debuggers

-jg

That family was used in some 1984ish coin-op arcade games like Pole Position II for graphics scaling. (Driving games got expensive parts because they could earn back the cost in a relatively short time.) The sound of over a dozen PP-IIs burning in at a time in attract mode will haunt me almost as long as Tapper. (Only one, but we spent some time figuring out how they got such good sound out of their AY-3-8910s. Those tunes over and over...)

--
Ron Sharp.

Great, thanks! Email me if you do manage to find it. I'll probably get started on it soon even without the user's manual. What I have now should be enough to get a good deal of it done, but probably not all of it.

"Android Cat" writes:

Atari started using the 2901 long before that. Battlezone used four of them on the "math box" board back in 1980. They were house-marked with an Atari part number, and the schematics and service manual called them out as "transistor arrays" (which is, of course, technically correct), but when I first looked at the board it was immediately apparent that they were bit slice chips, and most likely the 2901. A quick look at the pinout confirmed it.

Essentially the same "math box" was used for the games Red Baron and Tempest. In 1991 I wrote a disassembler for the math box firmware:

This let to a math box simulator for the vector game simulator Hedley Rannie and I wrote: These days, vecsim is of only historical interest (mainly for the crude attempt at binary translation), but the math box simulation code lives on in MAME.

On the original topic, Bob Henig and I ported the Telebit Netblazer dialup router code from the 386 to the 29000 back in 1992. I worked on the OS kernel and device drivers. It was interesting because the

29K normally uses TWO stacks for C code.

The 29K has a typical three-address RISC instruction set. The register addresses are eight bits each. There are a few special registers numbered in the 0x00-0x3f range, 64 global registers in the 0x40-0x7f range, and

128 local registers in the 0x80-0xff range. However, any time a local register is referenced, seven bits of one of the special registers are added to the local register number as an offset (with wraparound). This is used to make the local registers act as a stack frame cache.

A stack frame cannot be larger than 128 registers total (including return address, etc.). When a non-leaf function is called, the function prologue code determines whether there is enough space available in the stack frame cache for the new stack frame, using an assert instruction. If the assert fails, the exception handler spills out one or more stack frames to memory to make room.

Similarly, the function epilogue code checks whether the caller's stack frame is entirely present in the stack frame cache using an assert instruction. If this assert fails, the exception handler fills the frame in from memory.

The second stack arises because if a function needs more than 124 words of local variables, it has to put the excess on an auxilliary stack. It's not possible to push extra words onto the main stack because it would interfere with the spill/fill mechanism.

This makes context switching expensive. And interrupt handling is fairly complicated if you want to write your handler in C, because the interrupt may have occurred during a function prologue or epilogue, in which case the stack frame cache is in an inconsistent state. AMD published applicaitions information on how to fix this, but I used a different technique involving switching to an interrupt stack and setting the registers to make it look like the entire set of 128 local registers are a single large stack frame.

Of course, it would be entirely possible for a compiler to treat the 29K registers as a more conventional fixed arrangement simply by never setting the offset.