AL39 fig 8-1 Qs and emulator progress

[doo...@gmail.com]

All,

After initial coding the flowchart in Fig 8-1 for implementing the Appending unit in my simulator it quickly became apparent that Fig 8-1 alone is quite insufficient for reverse engineering the APU. While it seems to give a good flow for effective segment generation and operation of the ring mechanism it doesn't give a comprehensive cycle-by-cycle breakdown of what happens and, sometimes, when -- surprise, surprise. No problem as I *think* I can intuit what is missing (he was heard to hope.)

My question for all you multicians out there is "In Fig 8-1, why does the previous (last) cycle seem to be important for many operations?" What about the current cycle? And wrt Fig 8-1 where does that transition occur?


As aside for those who may be interested in my progress in simulating this beast. Here's what I have so far. The simulator, as a whole, functions quite well in absolute mode. Most instructions have been implemented (sans most EIS and floating point)- although not yet extensively tested. Address modifications seem to be more-or-less complete and functional (incl the special ITS/ITP & PR stuff), APU partially implemented. SDWAM, PTWAM implemented. I can, in a limping-along fashion, do inter segment (non paged) transfers and loads with appropriate ACVs thrown when appropriate to do so. My short-term goal is to get all the non-paged segment operations working correctly before I get into the paging stuff. (Not that paging seems much harder to implement, but in order to test it I need to set up more infrastructure in my simulator to handle page faults & instruction restarts, etc.) I've also started up a new project on SourceForge - http://sourceforge.net/projects/dps8m/

I'm hoping that the SF project can/will be used for a kinda' "simulator clearing-house" for any past/present/future h6180/dps8m simulator writers where we can share code, experience and horror-stories, etc.

Regards,
Harry Reed

[Peter Flass]

Could you refresh my memory or, better yet, post some details on SF?
What source language? What's the targeted host system?

--
Pete

[doo...@gmail.com]

Pete,

I'll post more info on my SF dps8m wiki as time permits. Source language is C. I'm building it under the simh framework. I am developing it under Mac OS/X w/ XCode(clang) &/| Eclipse CDT (gcc). Targets are any 64-bit UNIX/Linux systems. (Anything with native 64-bit integers should work fine.)

Currently I have >75% of the instruction set implemented. No FP or EIS just yet. All address modifications seem to work as well as most of the appending unit - so intersegment non-paged operations via PRn/ITS/ITP seem to work as documented. No interrupts or faults handled yet.

If you're interested in the code it's available via SF dps8m SVN.

Harry

[Daiyu Hurst]

On Nov 20, 7:26 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> On 11/20/2012 11:16 AM, doon...@gmail.com wrote:
>
> Could you refresh my memory or, better yet, post some details on SF?
> What source language?  What's the targeted host system?

SF==SourceForge

Source language is C.

Currently requires x86_64 CPUs, but once he cranks out some routines
to do 128-bit integer math on a 32-bit machine, it should enjoy more
universal hosting.

-daiyu

[rfm]

On Tuesday, November 20, 2012 11:16:06 AM UTC-5, doo...@gmail.com wrote:
> After initial coding the flowchart in Fig 8-1 for implementing the Appending unit in my simulator it quickly became apparent that Fig 8-1 alone is quite insufficient for reverse engineering the APU. While it seems to give a good flow for effective segment generation and operation of the ring mechanism it doesn't give a comprehensive cycle-by-cycle breakdown of what happens and, sometimes, when -- surprise, surprise.

I suspect this is derived from the Cambridge copy of a spec used to design the
645F->H6180->DPS8. The Phoenix copy probably had a lot of annotations from
verbal communications to clarify the terse conditional boxes. Flowcharts make
sequential what probably happens simultaneously (in combinatorial logic) so
the only observable states would be at traps taken or final success.

The first page is thoroughly muddled. It is trying to say that instruction
bit A29 is applied once per instruction, before any other operation, and even
if the MMU will not be invoked (as for the EA* instructions). (It's
too late now to verify, but I suspect A29 even applied to RPT and DU.)
Instruction fetch is mentioned because it also has to initialize the TPR.
RTCD shouldn't even be mentioned on this page.

Elsewhere references to last cycle being RTCD operand fetch should just say
RTCD is now fetching the first instruction (or pair) of the destination, as
all transfers do. (This is a programmer-friendly feature since jumps to
invalid addresses will show where you jumped from. It may also have
simplified the hardware since sequential fetch doesn't have to handle the
case of an odd address.)

I noticed several plain old bugs:
In case B, both reads and writes check TRR against SDW.R2; writes should be
limited to R1, as the text explains just a few pages back.

The instruction fetch path winds through case L, where it tests OPCODE;
that should only apply in the transfer path.

I didn't see TPR.CA get set anywhere.

In case K it appears that RTCD always sets the ring number of each pointer
register to TRR. This would be a serious bug if a pointer had a higher
ring number (because it originated in an outer ring) but luckily :) the
compiler and standard calling sequence make sure no register survives a
call :(

[Harry Reed]

Yeah, we've discovered the hard way that Fig 8-1 from AL39 leaves mush
to be desired. Despite that, still making good progress.

--

Harry W. Reed
Sr. Programmer/Analyst

Forestry Inventory & Analysis
Department of Geoscience
University of Nevada Las Vegas
4505 S. Maryland Parkway
Box 454010
Las Vegas NV 89154-4010

Tel. (702) 895-5846
email: doo...@gmail.com
Harry...@unlv.edu
ree...@unlv.nevada.edu
hwr...@fs.fed.us