> Thanks so much Paul!
> So the 3036 controllers ran at least 15x slower than my IBM friend imagined from
> hallway rumors 3 decades ago. That makes it quite a bit less interesting to me.
>
> From the diagram on page 5, it looks to me like the 3036 main memory was 10 bits wide plus parity, and the whole
> 10 bits were used when fetching and executing instructions. Data path is 5 bits, with 4 ad hoc registers. IC
> and Link are 16 bits. 256w x 10 bits of ROS code for startup. Interrupts nested 6 levels deep. 64 bytes of
> scratchpad. 64w x 8 bits of control store for sequencing or gate control within single instructions.
>
> The controller is integrated with DMA circuits for driving a raster-scan CRT, with character
> lookups and font lookups from the main memory. Characters do NOT use a 5-bit code.
>
>

Yeah, nothing special. Just enough power to do it's job(s); 3033 power sequencing and control, 3033 control storage load, trace, metering, management. Wish I still had the complete set of ALDs for the 3033 and the latest 3036 diskettes with the 3033 control store load - although the docs had the complete control storage micro-program laid out in an automated ALD-like flowchart. Cool machine for its time. Last machine you could actually scope. If I can find the ALDs (paper or fische) I want to reproduce the machine in FPG(s) - minus the directors.

Nice analysis of the 3036.

Thing I always hated about IBM was naming the bits from left to right instead of by the bit-weight. You never know what any particular bit contributes unless you know the bus/reg/etc width. There was a frame 33 feature to take the machine to 24MB (don't remember ever seeing a machine with this feature). But when you have a 24-bit address bus labeled 0 thru 23, how do you add that next address bit to the left? Naturally it was not contiguous but schmoozed via some DAT crap. You can see frame 33 and 14 for the 16-24MB upgrade in Selected pages from the installation planning guide