• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

DougIngraham said:
The early 8/i's had a 1.6us memory cycle time due to issues with the core memory. The 12 is an 8/i with a LINC. I suspect only the very early 12's would have been the 1.6us cycle time. There are no other instruction differences. My guess is the 2.9 score was using an EAE. An FPP12 should give better numbers than that so probably they were using an EAE. What does the /N option do? There is also the possibility of using the 36 bit or 48 bit floating point. It has been so long since I played with Fortran.
Click to expand...
Ahh. All of the documentation I've seen for the 8/I has indicated a 1.5us timing and all for the 12 has indicated a 1.6us timing (+/- 20% in both cases). Is all of the 12 documentation just outdated then?

DougIngraham said:
How do the Fortran time functions keep track of time? It sort of implies a real time clock which steals some processor time with interrupts. The next question would be how accurate is the clock? Is the RTC running at the frequency that Fortran thinks it is? If the RTC is doing 100hz and Fortran expects 60 hz that almost seems right. It would give you slow numbers by about 60%. Check the frequency of the RTC.

I sort of remember looking at the memory timing on Vince's 12 but I never thought about looking to see if it was doing a 1.5 or 1.6 microsecond timing. And I never looked at the RTC or it was even equipped with one. Was the RTC standard on the 12? Seems like it might have been a standard feature. Certainly not standard on any of the other 8 models. That may not be strictly true. The 8/a with option boards would have an RTC standard. And most of them had the option boards.
Click to expand...
There's a built in clock (KW12-A), which FORTRAN uses, yeah. It seems decently accurate compared to manually recorded times I've taken (within a second or so for a four minute test). Removing all timing-related code and related prints helps a little, but only by around 2%.

----------

vrs42 said:
I'm curious about /Q, which I gather is supposed to generate tighter code by assuming statements don't have non-obvious side effects.
Click to expand...
The impression I've gotten is that it would be unsafe w/ Whetstone. I think I've tried it in the past and it made some difference though(?)

vrs42 said:
In my attempts to run this on SIMH, WHET just hangs in the ISR, seemingly because of the clock interrupt.
Click to expand...
If you're using our Whetstone, the WHETNT version has the timing code stripped out, but of course it also won't give timing results.

vrs42 said:
My first thoughts were about EAE and FPP hardware being present. Does anyone have a working FPP on an 8/I or a 12?
Click to expand...
Roy also has a Whetstone result for a PDP-12 with an FPP of 35.4KWIPS, which is much higher than his 8/I result and our standard 12 result, so I don't think it's that.
EAE, maybe? All/Most 12s have EAE from what I've seen (ours definitely does, anyway) and I assume it's the same as the 8/I's EAE. But it doesn't appear to be used at all in our version of FORTRAN IV (MQ lights never come on) and looking at the source material for it, it appears to only support the 8/E's/KE8-E EAE. Is it possible to use a KE8-E on an 8/I? Or is it possible that an older version for FORTRAN IV supported the 8/I EAE and support for it was removed at some point? Fwiw, Roy also has an 8/E EAE result of 5.1KWIPS.
 
ZachyCatGames said:
The impression I've gotten is that it would be unsafe w/ Whetstone. I think I've tried it in the past and it made some difference though(?)
Click to expand...
realizes Whetstone prints out the values of each relevant variable after each module
Oh, yeah, `/Q` messes with things when used globally on Whetstone.
Without `/Q`:
Code: 
BENCHMARK #2 -- WHETSTONE (A001)
      -0.50       -0.50       0      0      0  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
       0.85        1.35      60     70     60  0.0000E-01  0.0000E-01  0.0000E-01  0.0000E-01
      11.75       10.90      70     60     60  0.0000E-01  0.0000E-01  0.0000E-01  0.0000E-01
      21.15        9.40    1725      0      0  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
      40.35       19.20    1050      1      2  6.0000E+00  6.0000E+00  0.0000E-01  0.0000E-01
      93.70       53.35     160      1      2  5.6820E+01  5.6820E+01  6.2702E+01  6.2702E+01
     160.30       66.60    4495      1      2  1.0000E+00  1.0000E+00  1.9140E+02  1.9140E+02
     189.85       29.55    3080      1      2  3.0000E+00  2.0000E+00  3.0000E+00  0.0000E-01
     190.05        0.20       0      2      3  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
     226.30       36.25     465      2      3  7.9602E-01  7.9602E-01  7.9602E-01  7.9602E-01
SINGLE WHETSTONE KIPS         2.20
With `/Q` on all source files:
Code: 
BENCHMARK #2 -- WHETSTONE (A001)
      -0.50       -0.50       0      0      0  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
       0.50        1.00      60     70     60  0.0000E-01  0.0000E-01  0.0000E-01  0.0000E-01
       7.90        7.40      70     60     60  0.0000E-01  0.0000E-01  0.0000E-01  0.0000E-01
      17.35        9.45    1725      0      0  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
      36.50       19.15    1050      1      2  6.0000E+00  6.0000E+00  0.0000E-01  0.0000E-01
      89.55       53.05     160      1      2  5.5337E+01  5.5337E+01 -5.3709E+01 -5.3709E+01
     155.80       66.25    4495      1      2  1.0000E+00  1.0000E+00  1.8310E+02  1.8310E+02
     182.20       26.40    3080      1      2  3.0000E+00  2.0000E+00  3.0000E+00  0.0000E-01
     182.40        0.20       0      2      3  1.0000E+00 -1.0000E+00 -1.0000E+00 -1.0000E+00
     218.65       36.25     465      2      3  7.9602E-01  7.9602E-01  7.9602E-01  7.9602E-01
SINGLE WHETSTONE KIPS         2.28
 
Using the EAE is not an automatic thing. You probably have to tell Fortran to use it somehow. Link a different library, something like that. You can't use the EAE hardware from the E, but as far as I know they didn't use the extra stuff in the 8/e EAE for compatibility reasons. The Straight 8 EAE has the same instructions as the 8/i EAE (and the 12) and the 8/e would run the EAE code for the earlier CPU's without any issues. Could you write a floating point package that would work only on the 8/e EAE, yes you could but it would not get you enough additional performance to be worth it. You already get additional performance because the EAE is faster. I could certainly be wrong and they dedicated some people to writing the F4 floating point library specifically for the 8/e EAE.
 
I have what might be a dumb question... what controls the main cycle time of the machine? Could we just be running below spec?

Given that some of the cycle time docs say things like +/- 20%, is that just randomness, variability, or is it a setting on a particular machine? I ask because if there's a pot (or whatever) that controls #435's memory cycle time, and everything else depends on that clock, then it occurred to me that our machine could just be running 20% slow... sort of the equivalent of being underclocked. We never had a reason or a method to compare our machine to any other machine, and we really focused on the machine functioning correctly. It's only Zach's Whetstone that has us wondering why our machine is slower than an 8/I.
 
If I remember correctly there were two methods used to control the memory timing. One utilized delay lines where taps pick off the signal at appropriate timing points. The other uses timers with adjustable pulse lengths. I believe they originally used the delay line method and probably changed to the other one for cost savings and the ability to change the timing if necessary. Vince's 32k expansion originally used delay lines but he also made a timing generator that uses one shots. The CPU waits for the memory to signal done which makes this somewhat asynchronous.

It is not yet clear to me that your machine is running slow. You don't have the exact executable that was originally run. I would continue to experiment with compilation settings. You know that it is not using the EAE because of the lack of activity in the MQ. The EAE will speed up floating point operations. I am not sure by how much. Maybe double or triple speed for some of the floating point operations. Integer multiply and divide would be a lot faster. But it won't change the speed of a lot of other stuff that takes place.

The PDP-12 is also a weird beast in that you can run it in a mode where you have a knob that you can use to change the execution speed. When in that mode nothing says that turning that knob all the way to the fastest setting is running at full speed. It probably is but it is the kind of thing you have to watch out for.
 
DougIngraham said:
The PDP-12 is also a weird beast in that you can run it in a mode where you have a knob that you can use to change the execution speed. When in that mode nothing says that turning that knob all the way to the fastest setting is running at full speed. It probably is but it is the kind of thing you have to watch out for.
Click to expand...
Having messed with that before, I can say full speed on the auto restart function is not as fast as simply running.
 
Why not characterize the speed by generating a sequence of 1000 identical instructions, followed by toggling an output pin, followed by a jump back to the beginning? Use a 'scope on the output. Of course, you could always just look at the timing directly with a 'scope.
 
Hi @DougIngraham and @antiquekid3 -- thanks for the info.

To be clear, I wasn't suggesting that I think our machine is running slow, just wondering how easily that might happen based on the design and the lack of official maintenance.

I agree with @antiquekid3 that "full throttle" on the auto-restart is still slower than "unthrottled".

I definitely suspect that it's a combination of software and/or compilation... It is a fun mystery but also one that could eat up a lot of time. 😂

I am pretty sure our machine uses at least some delay lines but I'm not sure if it's in the memory cycle or not. Scoping the memory cycle is a great idea but definitely a "Summer" kind of project. Running some instructions with a known duration and timing them is a great idea -- thanks, @antiquekid3 !
 
My understanding of 8/i and PDP-12 memory timing is that it is comtrolled by the memory implementation:

1. The CPU sends MEM_START to the memory, and waits for STROBE. STROBE indicates that the read is complete, and triggers the memory data to be latched and execution to continue.

2) After execution continues TP2 signals the beginning of the write-back. Data will be held stable (so the memory can write it) until the memory asserts MEM_DONE. After MEM_DONE, execution will proceed (to begin the next memory cycle, unless RUN has been cleared).

3) There's a non-existent memory detection scheme, which basically consists of "I give up" timers, which actuate eventually to generate fake memory completion signals. Otherwise, execution would freeze forever when non-existant memory is referenced.

Tapped delay lines are used in the DEC memory implementations to delay the MEM_START and BTP2 pulses until the core memory has had time to do it's thing, at which point they become STROBE and MEM_DONE. These timings are probably somewhat tuneable, but I've not looked up how to go about it.

The PDP-12 "slow execution" mode, as I understand it, is basically a way of doing single step, but with a variable clock attached to "continue". So I'd think it has to be slower than not starting and stopping the machine and just letting it run.

Vince
 
antiquekid3 said:
There's also a G718 in slot H08 that you can turn upside-down (perhaps the only Flip-Chip that can do so without harm? Quite a clever design when you look at it!) to change the system timing. You can shave 150 ns off a cycle.
Click to expand...
@antiquekid3 this is absolutely the coolest and most mind-blowing thing I read yesterday. Thank you. Does anyone know more about this feature? Did it exist in other machines, like the PDP-8?

We will likely scope the timing signal after finals.

In the meantime, @ZachyCatGames has been working on a little timing benchmark that should allow us to time and compute the effective cycle time and compare that to a theoretically derived runtime. I'll let him speak more about that once he's ready.
 
pahp said:
@antiquekid3 this is absolutely the coolest and most mind-blowing thing I read yesterday. Thank you. Does anyone know more about this feature? Did it exist in other machines, like the PDP-8?
Click to expand...
Not on any of the 8 CPU's. There is a jumper on the 8/e cpu that makes all memory cycles 1.4us instead of most of them being 1.2us.

pahp said:
In the meantime, @ZachyCatGames has been working on a little timing benchmark that should allow us to time and compute the effective cycle time and compare that to a theoretically derived runtime. I'll let him speak more about that once he's ready.
Click to expand...
I have such a piece of code I wrote a long time ago. If you want I can try to dig up a copy. The purpose was to verify that instruction timing worked the way I thought it did for my Straight 8 sim. I wrote my sim before simh was an idea.
 
DougIngraham said:
Not on any of the 8 CPU's. There is a jumper on the 8/e cpu that makes all memory cycles 1.4us instead of most of them being 1.2us.
Click to expand...

Thanks -- fascinating.
DougIngraham said:
I have such a piece of code I wrote a long time ago. If you want I can try to dig up a copy. The purpose was to verify that instruction timing worked the way I thought it did for my Straight 8 sim. I wrote my sim before simh was an idea.
Click to expand...
Hi @DougIngraham -- thanks! That would be great, if you can find it without too much trouble. @ZachyCatGames wrote one, but a second opinion would always be helpful -- again, if it is not hard to find. It would be interesting to compare the results. Thanks!
 
Found a copy. I was testing TSF on an 8/e to see execution time as part of the Console Serial Disk project.

Code: 
/ PROGRAM TO TEST INSTRUCTION TIMINGS.
/
/ RUN AND TIME THIS PIECE OF CODE WITH NO INSTRUCTION ON THE LINE AFTER THE
/ LABEL "NEXT" TO GET A BASELINE TIME FOR THE EXECUTION.  THEN INSERT THE
/ INSTRUCTION TO BE TESTED ON THE LINE AFTER THE LABEL "NEXT" AND ASSEMBLE,
/ RUN, AND TIME IT.  THE EXECUTION TIME FOR ONE INSTRUCTION WILL BE THE
/ DIFFERENCE IN THE EXECUTION TIMES DIVIDED BY 10000000.  THIS COUNT WAS
/ CHOSEN BECAUSE IT IS LONG ENOUGH TO HAND TIME AND OBTAIN REASONABLY ACCURATE
/ NUMBERS.  ALSO YOU CAN TAKE THE DIFFERENCE IN THE EXECUTION TIMES AND DIVIDE
/ BY 10 AND YOU HAVE THE EXECUTION TIME OF A SINGLE INSTRUCTION SCALED TO
/ MICROSECONDS.
/
/ THE BASE INNER TIMING LOOP TAKES 4.5 MICROSECONDS ON A STRAIGHT 8 SO THE
/ TOTAL TIME TO EXECUTE THE EMPTY LOOP IS A LITTLE OVER 45 SECONDS.  ON A
/ KK8-E CPU IT SHOULD EXECUTE IN A LITTLE OVER 38 SECONDS.  A 1.5 MICROSECOND
/ INSTRUCTION WILL ADD 15 SECONDS TO THE EXECUTION.  A 1.2 MICROSECOND
/ INSTRUCTION ADDS 12 SECONDS.  GOING TO A COUNT OF 100000000 WOULD RESULT
/ IN MORE ACCURACY WITH THE TEST TAKING 10 TIMES LONGER.  I INCLUDED THE
/ INITIALIZER CONSTANT FOR 100000000 AT THE END IF YOU CHOOSE TO USE IT.
/
/ ACTUAL TIME ON KK8E CPU IS 38.35 SECONDS
/
/ YOU HAVE TO BE CAREFUL WHEN TIMING INSTRUCTIONS THAT TRANSFER CONTROL.
/ HERE ARE EXAMPLES OF HOW TO TIME THEM.
/
/ TO TEST A JMP YOU CODE IT AS
/ NEXT,
/        JMP .+1
/
/ AND TO TEST A JMS CODE IT AS
/ NEXT,
/        JMS .+1
/        0000
/
/ AND TO TEST TIMING ON SKIP USE THE UNCONDITIONAL FORM AND A FILLER
/ INSTRUCTION (IN THIS CASE A HLT WORKS WELL)
/
/ NEXT,
/        SKP
/        HLT                   / THIS SHOULD NEVER GET EXECUTED
/
/ IF YOU WANT TO TIME AN INDIRECT TO OBTAIN DEFER YOU CAN DO THAT BY FIRST
/ TIMING A NON-DEFER VERSION OF THE INSTRUCTION AND THEN ADDING THE
/ INDIRECTION.  READS ARE ALWAYS SAFE BUT INDIRECT WRITES NEED A SAFE
/ DESTINATION.  YOU MIGHT WANT TO USE THE FOLLOWING TO TEST AN AUTOINCREMENT
/ INDIRECT WRITE.  THE FIRST TWO INSTRUCTIONS SHOULD BE IN THE BASE LOOP
/ TIMING.
/
/ NEXT,
/        CLA                   / FORCE THE INDIRECTION LOCATION TO ZERO
/        DCA Z IND10
/        DCA I Z IND10         / THIS WILL ALWAYS WRITE TO ADDRESS 0001
/
*0007
IND07,  0000            / NOT AUTOINCREMENTING WHEN USED INDIRECTLY
IND10,  0000            / AUTOINCREMENTING WHEN USED INDIRECTLY
*0175
LOW,    0000            / LOW 12 BITS OF A 36 BIT COUNTER
MID,    0000            / MIDDLE 12 BITS
HI,     0000            / HIGH 12 BITS

*0200
START,  CLA
        TAD INLOW       / INITIALIZE THE COUNTER
        DCA Z LOW
        TAD INMID
        DCA Z MID
        TAD INHI
        DCA Z HI
/ PUT ANY SETUP FOR THE INSTRUCTION HERE
    TCF        / CLEAR THE TELEPRINTER FLAG
/ END OF SPECIAL SETUP FOR THE INSTRUCTION
NEXT,                   / PLACE THE INSTRUCTION TO BE TESTED NEXT
        TSF        / TEST TSF
            / PLACE THE INSTRUCTION TO BE TESTED BEFORE THIS
        ISZ Z LOW       / THIS IS A 36 BIT ISZ
        JMP NEXT
        ISZ Z MID
        JMP NEXT
        ISZ Z HI
        JMP NEXT
        HLT             / HLT WHEN DONE
        JMP START       / HIT CONT TO RUN AGAIN

INHI,   7777            / -10000000 AS A 36 BIT NUMBER
INMID,  3166
INLOW,  4600
/INHI,   7772            / -100000000 AS A 36 BIT NUMBER
/INMID,  0241
/INLOW,  7400
$
 
DougIngraham said:
Found a copy. I was testing TSF on an 8/e to see execution time as part of the Console Serial Disk project.

Code: 
/ PROGRAM TO TEST INSTRUCTION TIMINGS.
/
/ RUN AND TIME THIS PIECE OF CODE WITH NO INSTRUCTION ON THE LINE AFTER THE
/ LABEL "NEXT" TO GET A BASELINE TIME FOR THE EXECUTION.  THEN INSERT THE
/ INSTRUCTION TO BE TESTED ON THE LINE AFTER THE LABEL "NEXT" AND ASSEMBLE,
/ RUN, AND TIME IT.  THE EXECUTION TIME FOR ONE INSTRUCTION WILL BE THE
/ DIFFERENCE IN THE EXECUTION TIMES DIVIDED BY 10000000.  THIS COUNT WAS
/ CHOSEN BECAUSE IT IS LONG ENOUGH TO HAND TIME AND OBTAIN REASONABLY ACCURATE
/ NUMBERS.  ALSO YOU CAN TAKE THE DIFFERENCE IN THE EXECUTION TIMES AND DIVIDE
/ BY 10 AND YOU HAVE THE EXECUTION TIME OF A SINGLE INSTRUCTION SCALED TO
/ MICROSECONDS.
/
/ THE BASE INNER TIMING LOOP TAKES 4.5 MICROSECONDS ON A STRAIGHT 8 SO THE
/ TOTAL TIME TO EXECUTE THE EMPTY LOOP IS A LITTLE OVER 45 SECONDS.  ON A
/ KK8-E CPU IT SHOULD EXECUTE IN A LITTLE OVER 38 SECONDS.  A 1.5 MICROSECOND
/ INSTRUCTION WILL ADD 15 SECONDS TO THE EXECUTION.  A 1.2 MICROSECOND
/ INSTRUCTION ADDS 12 SECONDS.  GOING TO A COUNT OF 100000000 WOULD RESULT
/ IN MORE ACCURACY WITH THE TEST TAKING 10 TIMES LONGER.  I INCLUDED THE
/ INITIALIZER CONSTANT FOR 100000000 AT THE END IF YOU CHOOSE TO USE IT.
/
/ ACTUAL TIME ON KK8E CPU IS 38.35 SECONDS
/
/ YOU HAVE TO BE CAREFUL WHEN TIMING INSTRUCTIONS THAT TRANSFER CONTROL.
/ HERE ARE EXAMPLES OF HOW TO TIME THEM.
/
/ TO TEST A JMP YOU CODE IT AS
/ NEXT,
/        JMP .+1
/
/ AND TO TEST A JMS CODE IT AS
/ NEXT,
/        JMS .+1
/        0000
/
/ AND TO TEST TIMING ON SKIP USE THE UNCONDITIONAL FORM AND A FILLER
/ INSTRUCTION (IN THIS CASE A HLT WORKS WELL)
/
/ NEXT,
/        SKP
/        HLT                   / THIS SHOULD NEVER GET EXECUTED
/
/ IF YOU WANT TO TIME AN INDIRECT TO OBTAIN DEFER YOU CAN DO THAT BY FIRST
/ TIMING A NON-DEFER VERSION OF THE INSTRUCTION AND THEN ADDING THE
/ INDIRECTION.  READS ARE ALWAYS SAFE BUT INDIRECT WRITES NEED A SAFE
/ DESTINATION.  YOU MIGHT WANT TO USE THE FOLLOWING TO TEST AN AUTOINCREMENT
/ INDIRECT WRITE.  THE FIRST TWO INSTRUCTIONS SHOULD BE IN THE BASE LOOP
/ TIMING.
/
/ NEXT,
/        CLA                   / FORCE THE INDIRECTION LOCATION TO ZERO
/        DCA Z IND10
/        DCA I Z IND10         / THIS WILL ALWAYS WRITE TO ADDRESS 0001
/
*0007
IND07,  0000            / NOT AUTOINCREMENTING WHEN USED INDIRECTLY
IND10,  0000            / AUTOINCREMENTING WHEN USED INDIRECTLY
*0175
LOW,    0000            / LOW 12 BITS OF A 36 BIT COUNTER
MID,    0000            / MIDDLE 12 BITS
HI,     0000            / HIGH 12 BITS

*0200
START,  CLA
        TAD INLOW       / INITIALIZE THE COUNTER
        DCA Z LOW
        TAD INMID
        DCA Z MID
        TAD INHI
        DCA Z HI
/ PUT ANY SETUP FOR THE INSTRUCTION HERE
    TCF        / CLEAR THE TELEPRINTER FLAG
/ END OF SPECIAL SETUP FOR THE INSTRUCTION
NEXT,                   / PLACE THE INSTRUCTION TO BE TESTED NEXT
        TSF        / TEST TSF
            / PLACE THE INSTRUCTION TO BE TESTED BEFORE THIS
        ISZ Z LOW       / THIS IS A 36 BIT ISZ
        JMP NEXT
        ISZ Z MID
        JMP NEXT
        ISZ Z HI
        JMP NEXT
        HLT             / HLT WHEN DONE
        JMP START       / HIT CONT TO RUN AGAIN

INHI,   7777            / -10000000 AS A 36 BIT NUMBER
INMID,  3166
INLOW,  4600
/INHI,   7772            / -100000000 AS A 36 BIT NUMBER
/INMID,  0241
/INLOW,  7400
$
Click to expand...
ok yeah this is much cleaner than what I was trying to do, heh.

Running this with the TSF removed (just the basic loop; I also added a HLT before the loop) yielded a run time of about 54 seconds. Here are my exact recorded times:
Code: 
54.43
54.41
54.44
54.42
54.41

Adding a `TAD Z IND07` after `NEXT` brought the run time up to about 90 seconds; this is a 36 second increase and indicates TAD is taking 3.6 microseconds to execute.
Code: 
1:30.51
1:30.42
1:30.41
1:30.47
1:30.51

`DCA Z IND07` gave the exact same result as TAD:
Code: 
1:30.52
1:30.60
1:30.49

Using `IAC` yielded a run time of 72 seconds; this is a 18 second increase and indicates IAC is taking 1.8 microseconds to execute.
Code: 
1:12.40
1:12.42
1:12.49

So it seems like our CPU/MEM cycle time is 1.8 microseconds? It would be interested to see this run on another '12. I also plan to try running this on our other memory fields to see if they behave/perform any differently.
 
I have returned with more numbers :)
I ran all of the same tests on our field 1 (which is using another original core memory module), and our field 2 and field 7 (which are using @vrs42's memory expansion module).

Field 1 performed slightly faster than field 0, but not significantly so. DCA added ~36 seconds when the test was run on field 0, while ~35.5 seconds were added when field 1 was tested; this indicates our field 1 has a ~1.775us mem cycle.

@vrs42's memory expansion performed significantly better than both of our original cores, with DCA only adding 32-33 seconds; this indicates a 1.6us mem cycle. Does this sound right?

I've attached txt files with all of my recorded times:
base.txt: Times recorded using the base test w/ no added instructions.
dca.txt: Times recorded with "DCA Z IND07" added to the loop.
tad.txt: Time recorded with "TAD Z IND07" added to the loop and IND07 set to 0001 (I wanted a nice light show to watch while waiting).
iac.txt: Times recorded with "IAC" added to the loop.
 

Attachments

ZachyCatGames said:
Field 1 performed slightly faster than field 0, but not significantly so. DCA added ~36 seconds when the test was run on field 0, while ~35.5 seconds were added when field 1 was tested; this indicates our field 1 has a ~1.775us mem cycle.

@vrs42's memory expansion performed significantly better than both of our original cores, with DCA only adding 32-33 seconds; this indicates a 1.6us mem cycle. Does this sound right?
Click to expand...
Seems plausible to me! (Running these on my PDP-12 is yet another thing I don't quite have time for today.)

Does it go faster with the speed jumper card turned over?
 
I am enjoying that you are running a little piece of code I wrote sometime back in the early to mid 1990's.

I remember that when I originally ran it I considered the first run to be a discard because you didn't know when it was supposed to finish and you invariably were slow hitting the stop button on the stopwatch.

I thought that your 12 had 8k in it and you added Vince's expansion to bring it up to 32k. It doesn't make sense to me that there would be any timing difference between field 2 and field 7 since they are both using Vince's timing chain. Or am I confused again? There really isn't much difference.
 
DougIngraham said:
I am enjoying that you are running a little piece of code I wrote sometime back in the early to mid 1990's.
Click to expand...
Thanks for the code! It's been super helpful. Running something 30 years old does feel pretty sweet.

DougIngraham said:
I remember that when I originally ran it I considered the first run to be a discard because you didn't know when it was supposed to finish and you invariably were slow hitting the stop button on the stopwatch.
Click to expand...
A good policy.

DougIngraham said:
I thought that your 12 had 8k in it and you added Vince's expansion to bring it up to 32k. It doesn't make sense to me that there would be any timing difference between field 2 and field 7 since they are both using Vince's timing chain. Or am I confused again? There really isn't much difference.
Click to expand...
I think that @ZachyCatGames meant fields 0, 1, and 7, not 1, 2 and 7.

0 and 1 (our two 4k cores) are close to each other (in the 1.8us ballpark), and field 7 is in @vrs42 's
expansion and gets ~1.6us.

Is there anything configurable about the core units themselves in terms of timing? Or are some cores just faster than others?

We haven't scoped the MEM_START yet (nor flipped the turbo chip) -- the former is something for after finals but maybe we could do the latter this week. It's a busy time.

@vrs42 - if/when you have time we would love to hear how your machine does with @DougIngraham 's code.

And thanks @ZachyCatGames for all the hard work!
 
You must log in or register to reply here.
Back
Top