• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

So if I'm reading that right, it increments both the horizontal and vertical position; and you reset the one you're not advancing in order to either keep printing to the right, or do a CRLF kind of thing?
 
SpaceHobo said:
So if I'm reading that right, it increments both the horizontal and vertical position; and you reset the one you're not advancing in order to either keep printing to the right, or do a CRLF kind of thing?
Click to expand...
To my eye it seems dumber than that. It looks like X advances sensibly. Y, however, is jam-cleared to a multiple of the line height, then advanced by the character height. So you can leave that value in AC, and draw more characters advancing to the right. The low 4 or 5 bits would keep getting cleared, then set to the new value again. Meanwhile, of course, clogging up AC with gunk so you'd have to CLA to get anything else done.

When you finish a row, it seems to me that you'd typically want to move *down*, not up a row. To advance Y, you still have to add/subtract something to get to the next multiple of the line height. What value you have to add mostly doesn't affect efficiency. Which means that having DSC advance it part of the (wrong) way is silly. It would be more efficient to just clear AC.

I suspect it is down to maintaining compatibility with the original LINC design. Would love to understand why the LINC designers thought advancing Y was a good idea. Maybe they envisioned using DSC for line graphics or something?? But then, forcing text-line alignment seems dumb.
 
It could just be a side-effect, like "We did some work and didn't clean up after ourselves. Some of this is probably useful to you, so we'll just leave that state laying about." It was probably the cheapest solution the LINC could do with the unprecedented budget they'd given themselves.

Incidentally, so much of the LINC side reminds me of the really grubby techniques that purpose-built serial CPUs used to do. So much shifting of individual bits around the register chain!
 
Maybe we are looking at it with our "young whippersnapper" eyes, and (as you suggest) it is just that AC got fiddled with in the process of drawing the half-character, and it wasn't important enough to add gating to change it.
 
Tried spcwr3. The PDP-12 build doesn't quite run on the SIMH out of the box. It exhibits the classic "no clock" symptom where the screen is only updated when a key is struck (causing an interrupt).

Rebuilding it to use the 8/E clock but the VC12 display works as expected. The interactive switch register kludge isn't there, so there's no controlling the ships, and they just fall into Z Polaris. The keyboard commands to change the ship types and other options do work as expected.

Anyone want to write clock and LINCtape support for SIMH?
 
vrs42 said:
Tried spcwr3. The PDP-12 build doesn't quite run on the SIMH out of the box. It exhibits the classic "no clock" symptom where the screen is only updated when a key is struck (causing an interrupt).

Rebuilding it to use the 8/E clock but the VC12 display works as expected. The interactive switch register kludge isn't there, so there's no controlling the ships, and they just fall into Z Polaris. The keyboard commands to change the ship types and other options do work as expected.
Click to expand...
Cool!

vrs42 said:
Anyone want to write clock and LINCtape support for SIMH?
Click to expand...
I so wish I had a student up to and interested in this challenge... or that I had a sabbatical.
 
pahp said:
I so wish I had a student up to and interested in this challenge... or that I had a sabbatical.
Click to expand...
Meanwhile, I wish an institution around here would let me do this as work toward a graduate degree!

Like, no joke: I would do this toward a masters or beyond at a London university!
 
vrs42 said:
Maybe we are looking at it with our "young whippersnapper" eyes, and (as you suggest) it is just that AC got fiddled with in the process of drawing the half-character, and it wasn't important enough to add gating to change it.
Click to expand...
I was thinking about this while trying to brush up on LINC ASM a little. It seems like the LDA instructions and such make "noise" in AC less of an impediment than they do on the "TAD-only" 8.
 
This is objectively the best comment to that video:

1c01a9ba2264d74b.png
 
I just realized I was out of the loop for this thread. I can't seem to find how to get email alerts when there are new postings. HELP;
I haven't dug into SIMH yet, but I'd be interested in working on the LINCtape emulation. I might need some hand-holding at first.
 
MauryP said:
I just realized I was out of the loop for this thread. I can't seem to find how to get email alerts when there are new postings. HELP;
Click to expand...
Up toward the top-right of the page should be a box containing the text "watch", or possibly "unwatch". That's the button to watch/unwatch the thread.

One minor annoyance is that even if you watch the thread, you have to revisit it *every time* they send you an email notification. Otherwise I guess they think you've at least temporarily lost interest and don't send you another.
MauryP said:
I haven't dug into SIMH yet, but I'd be interested in working on the LINCtape emulation. I might need some hand-holding at first.
Click to expand...
The code is in https://svn.so-much-stuff.com/svn/trunk/pdp8/simh/. The PDP8 and PDP12 sub-directories should be more or less the same. There's example DECtape code there, but it's a little hard to comprehend it at first. You can write me with questions or for more info.
 
You must log in or register to reply here.
Back
Top