25 Sep
2014
25 Sep
'14
11:33 a.m.
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors
on the lineair powersupply and testing it with dummyloads. there is a
8kword and a 16kword corepack in the machine. we would like to dump the
contents of the core to serial to preserve the original contents for
later examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
25 Sep
25 Sep
11:43 a.m.
On Sep 25, 2014, at 2:33 PM, Simon Claessen <simski at dds.nl> wrote:
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors on the lineair
powersupply and testing it with dummyloads. there is a 8kword and a 16kword corepack in
the machine. we would like to dump the contents of the core to serial to preserve the
original contents for later examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as the CHM PDP-1
team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load that in a small
bit of memory that you have previously saved by hand (from the console switches/lights).
I don?t speak PDP-8 assembler, but I imagine such a program wouldn?t be more than 30-50
instructions total.
paul
noon
On Thu, Sep 25, 2014 at 11:43 AM, Paul Koning <paulkoning at comcast.net>
wrote:
On Sep 25, 2014, at 2:33 PM, Simon Claessen <simski at dds.nl> wrote:
Or a logic analyzer with enough trace memory; hook it up to the front panel
memory address and contents display. Step through memory with the console
switches, recording the data in the logic analyzer, dump the analyzer
traces to a computer, reformat....
-- Charles
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors
on the
lineair powersupply and testing it with dummyloads. there is a
8kword and a 16kword corepack in the machine. we would like to dump the
contents of the core to serial to preserve the original contents for later
examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as
the CHM PDP-1 team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load
that in a small bit of memory that you have previously saved by hand (from
the console switches/lights). I don?t speak PDP-8 assembler, but I imagine
such a program wouldn?t be more than 30-50 instructions total.
paul
12:20 p.m.
On 9/25/2014 1:00 PM, Charles Anthony wrote:
On Thu, Sep 25, 2014 at 11:43 AM, Paul Koning
<paulkoning at comcast.net>
wrote:
Try Paper and pencil. Can the octal debugger handle separate code and
data pages?
On Sep 25, 2014, at 2:33 PM, Simon Claessen <simski at dds.nl> wrote:
Or a logic analyzer with enough trace memory; hook it up to the front panel
memory address and contents display. Step through memory with the console
switches, recording the data in the logic analyzer, dump the analyzer
traces to a computer, reformat....
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors
on the
lineair powersupply and testing it with dummyloads. there is a
8kword and a 16kword corepack in the machine. we would like to dump the
contents of the core to serial to preserve the original contents for later
examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as
the CHM PDP-1 team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load
that in a small bit of memory that you have previously saved by hand (from
the console switches/lights). I don?t speak PDP-8 assembler, but I imagine
such a program wouldn?t be more than 30-50 instructions total.
paul
-- Charles
Ben.
1 p.m.
It is fairly easy these days to pull binary data out of a video image. So I
would consider building a small device which pressed 'examine next' and
then turned on an LED, then turned off the LED. Have it repeat at about 10
Hz. Even at 30p progressive scan recorder, you get 3 frames in 100mS the
lights on (we will assume the lights all work) with a 60p framerate that is
6 frames. Take the video and post process to remove the values of memory.
No serial port required. You use the blinks of the LED on the switch pusher
as an index mark, capture frames between the time that LED is on.
--Chuck
On Thu, Sep 25, 2014 at 12:20 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 9/25/2014 1:00 PM, Charles Anthony wrote:
On Thu, Sep 25, 2014 at 11:43 AM, Paul Koning
<paulkoning at comcast.net>
wrote:
Try Paper and pencil. Can the octal debugger handle separate code and
data pages?
-- Charles
On Sep 25, 2014, at 2:33 PM, Simon Claessen
<simski at dds.nl> wrote:
Hello all,
panel
memory address and contents display. Step through memory with the console
switches, recording the data in the logic analyzer, dump the analyzer
traces to a computer, reformat....
The pdp8/f we got last week is working now, after forming the capacitors
on the lineair powersupply and testing it with dummyloads. there is a
8kword and a 16kword corepack in the machine. we would like to dump the
contents of the core to serial to preserve the original contents for
later
examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650
uart?
One way would be to wiggle the console switches under program control, as
the CHM PDP-1 team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and
load
that in a small bit of memory that you have previously saved by hand
(from
the console switches/lights). I don?t speak PDP-8 assembler, but I
imagine
such a program wouldn?t be more than 30-50 instructions total.
paul
Or a logic analyzer with enough trace memory; hook it up to the front
Ben.
12:03 p.m.
> we would like to dump the contents of [a
PDP-8/f's] core to serial
> to preserve the original contents for later examination while we can
> to tests with the machine.
> is there a way to do this, using a empty part of
memory and a M8650
> uart?
There is.
One way would be to wiggle the console switches under
program control, as th$
That would require additional hardware. That may be acceptable, but
the original post doesn't say anything about it, so it also may not be.
Another would be to find, or write, a simple memory
dump program, and load t$
It wouldn't. It's been too long since I played with a PDP-8 for me to
write such a thing extemporaneously, but I do remember that much.
However, I would strongly recommend using another -8/f, or an emulator,
to make sure you get the program right. It would be very easy to
accidentally destroy the data you're trying to save with a coding
mistake.
Alternatively, single-step the program by hand long enough to be
confident it's working correctly.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:44 p.m.
Actually with an ASR33 it would be trivial to write a program to dump
memory to paper tape.
On Thu, Sep 25, 2014 at 12:03 PM, Mouse <mouse at rodents-montreal.org> wrote:
> we would
like to dump the contents of [a PDP-8/f's] core to serial
> to preserve the original contents for later examination while we can
> to tests with the machine.
> is there a way to do this, using a empty part
of memory and a M8650
> uart?
There is.
One way would be to wiggle the console switches
under program control,
as th$
That would require additional hardware. That may be acceptable, but
the original post doesn't say anything about it, so it also may not be.
Another would be to find, or write, a simple
memory dump program, and
load t$
It wouldn't. It's been too long since I played with a PDP-8 for me to
write such a thing extemporaneously, but I do remember that much.
However, I would strongly recommend using another -8/f, or an emulator,
to make sure you get the program right. It would be very easy to
accidentally destroy the data you're trying to save with a coding
mistake.
Alternatively, single-step the program by hand long enough to be
confident it's working correctly.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:40 p.m.
On 2014-Sep-25, at 11:43 AM, Paul Koning wrote:
On Sep 25, 2014, at 2:33 PM, Simon Claessen <simski
at dds.nl> wrote:
I can only encourage the latter approach, I did something similar for my HP 2116C 10 years
ago when I received it. Once I had a monitor written and loaded I was able to recover the
remaining contents of core. It was enough to show the last thing the machine had been
doing was running a BASIC game, apparently in July of 1983.
http://www.cs.ubc.ca/~hilpert/e/HP21xx/HP2116CSys/index.html#recovery
Due to a hardware fault in the core memory, I (had) had only one opportunity to get a full
dump, which I had missed due to checking memory from the front panel and not knowing about
the fault, so I didn't get the entire contents. In my case hindsight is great, but
it's something to keep in mind if recovering the contents is of some concern.
If it's a suitable program in memory it might be possible to restart it after some
analysis and ident.
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors on the lineair
powersupply and testing it with dummyloads. there is a 8kword and a 16kword corepack in
the machine. we would like to dump the contents of the core to serial to preserve the
original contents for later examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as the CHM PDP-1
team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load that in a
small bit of memory that you have previously saved by hand (from the console
switches/lights). I don?t speak PDP-8 assembler, but I imagine such a program wouldn?t be
more than 30-50 instructions total.
2:28 p.m.
On Sep 25, 2014, at 4:40 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Sep-25, at 11:43 AM, Paul Koning wrote:
That?s a good point. If the restore machinery is not working, you can only read once,
after that you?ll see zeroes. A quick check would be to pick some location and read it
several times. If that works, the restore logic is at least somewhat functional.
Still, safest would be to hook to the console. A BeagleBone Black has enough I/O lines to
do that, I think, so it sounds like just some level shifters and a modest amount of
software.
paul
On Sep 25, 2014, at 2:33 PM, Simon Claessen
<simski at dds.nl> wrote:
I can only encourage the latter approach, I did something similar for my HP 2116C 10
years ago when I received it. Once I had a monitor written and loaded I was able to
recover the remaining contents of core. It was enough to show the last thing the machine
had been doing was running a BASIC game, apparently in July of 1983.
http://www.cs.ubc.ca/~hilpert/e/HP21xx/HP2116CSys/index.html#recovery
Due to a hardware fault in the core memory, I (had) had only one opportunity to get a
full dump, which I had missed due to checking memory from the front panel and not knowing
about the fault, so I didn't get the entire contents. In my case hindsight is great,
but it's something to keep in mind if recovering the contents is of some concern.
Hello all,
The pdp8/f we got last week is working now, after forming the capacitors on the lineair
powersupply and testing it with dummyloads. there is a 8kword and a 16kword corepack in
the machine. we would like to dump the contents of the core to serial to preserve the
original contents for later examination while we can to tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as the CHM PDP-1
team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load that in a
small bit of memory that you have previously saved by hand (from the console
switches/lights). I don?t speak PDP-8 assembler, but I imagine such a program wouldn?t be
more than 30-50 instructions total.
3:31 p.m.
On 2014-Sep-25, at 2:28 PM, Paul Koning wrote:
On Sep 25, 2014, at 4:40 PM, Brent Hilpert <hilpert
at cs.ubc.ca> wrote:
Although, if by restore machinery you mean the state-machine/sequencing-logic that does
the (re)-write, it can still be more subtle than that.
In my case it was just one bad address-wire driver transistor, such that the failure was
for only one direction of current flow - the 'write' or 'set' direction.
It failed as you suggest - could read once but failed to rewrite - but did not affect the
entire core array, just a sub-set of 64-word blocks.
On 2014-Sep-25, at 11:43 AM, Paul Koning wrote:
That?s a good point. If the restore machinery is not working, you can only read once,
after that you?ll see zeroes. A quick check would be to pick some location and read it
several times. If that works, the restore logic is at least somewhat functional. On Sep 25, 2014, at 2:33 PM, Simon Claessen
<simski at dds.nl> wrote:
I can only encourage the latter approach, I did something similar for my HP 2116C 10
years ago when I received it. Once I had a monitor written and loaded I was able to
recover the remaining contents of core. It was enough to show the last thing the machine
had been doing was running a BASIC game, apparently in July of 1983.
http://www.cs.ubc.ca/~hilpert/e/HP21xx/HP2116CSys/index.html#recovery
Due to a hardware fault in the core memory, I (had) had only one opportunity to get a
full dump, which I had missed due to checking memory from the front panel and not knowing
about the fault, so I didn't get the entire contents. In my case hindsight is great,
but it's something to keep in mind if recovering the contents is of some concern.
The pdp8/f we got last week is working now, after
forming the capacitors on the lineair powersupply and testing it with dummyloads. there is
a 8kword and a 16kword corepack in the machine. we would like to dump the contents of the
core to serial to preserve the original contents for later examination while we can to
tests with the machine.
is there a way to do this, using a empty part of memory and a M8650 uart?
One way would be to wiggle the console switches under program control, as the CHM PDP-1
team did according to an article from a few years ago.
Another would be to find, or write, a simple memory dump program, and load that in a
small bit of memory that you have previously saved by hand (from the console
switches/lights). I don?t speak PDP-8 assembler, but I imagine such a program wouldn?t be
more than 30-50 instructions total. Still, safest would be to hook to the console. A
BeagleBone Black has enough I/O lines to do that, I think, so it sounds like just some
level shifters and a modest amount of software.
paul
4:25 p.m.
this is the advice I was looking for. we already found a bad zero
address. hacking into the console is not a bad idea. I will look into
the schematic for that. right now we wrote a very small program
outputting all ascii characters to a serial vt220. that works and is
only 5 instructions:
0003 7001 increment ac +1
0004 6446 output ac to serial and set flag
0005 6441 skip if flag is 1
0006 5005 goto 5
0007 5003 goto 3
it really is just a start, but something formatting the address and
contents of addresses in octeds and some formatting of the output string
is feasable. fortunately this machine has 24Kword core, so there is
still some empty space. (or is it gone because of a faulty rewrite... we
have to test that)
simon
Although, if by restore machinery you mean the state-machine/sequencing-logic that does
the (re)-write, it can still be more subtle than that.
In my case it was just one bad address-wire driver transistor, such that the failure was
for only one direction of current flow - the 'write' or 'set' direction.
It failed as you suggest - could read once but failed to rewrite - but did not affect the
entire core array, just a sub-set of 64-word blocks.
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
Due to a hardware fault in the core memory, I (had)
had only one opportunity to get a full dump, which I had missed due to checking memory
from the front panel and not knowing about the fault, so I didn't get the entire
contents. In my case hindsight is great, but it's something to keep in mind if
recovering the contents is of some concern.
That?s a good point. If the restore machinery is not working, you can only read once,
after that you?ll see zeroes. A quick check would be to pick some location and read it
several times. If that works, the restore logic is at least somewhat functional. Still, safest would be to hook to the console. A
BeagleBone Black has enough I/O lines to do that, I think, so it sounds like just some
level shifters and a modest amount of software.
paul
26 Sep
26 Sep
6:24 a.m.
well,
Another member of hack42.nl (bugblue at hack42.nl) came up with this code.
hopefully tonight we can check it. (depends on me being able to attend)
any thoughts on this?
*200 /LOCATE PROGRAM STARTING AT ADDR 200
CLA CLL /CLEAR ACCUMULATOR
/CLEAR AC LINK
DCA TMP1 /STORE THAT (0) IN TMP1
MAIN, NOP
TAD TMP1 // load TMP1
JMS PRINTNUM // print dit nummer
CLA CLL
TAD SPACE
JMS TTYO // output to tty0
TAD I TMP1 // indirect loading of TMP1
JMS PRINTNUM // print this number
TAD TMP1 // load TMP1
IAC // INCREMENT 1
DCA TMP1
CLA CLL
TAD CR
JMS TTYO // output to tty0
CLA CLL
TAD LF
JMS TTYO // output to tty0
JMP MAIN // tada.wav
PRINTNUM, NOP
DCA TMP3 // store this in tmp3
CLA CLL // clear AC
TAD TMP3 // load TMP3
RAR
RTR // 3 bitwise shift
JMS XOR // xor met 0070
JMS MIN // substract 0010
JMS TTYO // output to tty0
CLA CLL // clear AC
TAD TMP3 // load TMP3
JMS XOR // xor with 0070
JMS MIN // substract 0010
JMS TTYO // output to tty0
CLA CLL // clear AC
TAD TMP3 // load TMP3
RAL
RTL // 3 bitwise shift
JMS XOR // xor met 0070
JMS MIN // substract 0010
JMS TTYO // output to tty0
CLA CLL // clear AC
TAD TMP3 // load TMP3
RTL
RTL
RTL // 6 bitwise shift
JMS XOR // xor met 0070
JMS MIN // substract 0010
JMS TTYO // output to tty0
MIN, NOP
CMA IAC / 2's complement accumulator
TAD MIN10 / add operand from memory
JMP I MIN
XOR, NOP
DCA XORTMP
TAD XORTMP
AND XORDO
CMA IAC
CLL RAL
TAD XORTMP
TAD XORDO
JMP I XOR
TTYO, NOP /TTY OUTPUT ROUTINE. THE FIRST WORD OF
/A SUBROUTINE MUST BE EMPTY (0) BECAUSE
/THE JMS INSTRUCTION INSERTS THE RETURN
/ADDR IN THIS WORD.
6446 /WRITE AC TO THE OUTPUT DEVICE (TTY)
6441 /IF TTY IS READY, SKIP NEXT INSTRUCTION.
JMP .-1 /TTY IS NOT READY, SO CHECK AGAIN
CLA /CLEAR AC
JMP I TTYO /RETURN TO CALLER
MIN10, 10
XORDO, 70
TMP1, 0
TMP3, 0
XORTMP, 0
SPACE, 40
LF, 12
CR, 15
$
On 26-09-14 01:25, Simon Claessen wrote:
this is the advice I was looking for. we already found
a bad zero
address. hacking into the console is not a bad idea. I will look into
the schematic for that. right now we wrote a very small program
outputting all ascii characters to a serial vt220. that works and is
only 5 instructions:
0003 7001 increment ac +1
0004 6446 output ac to serial and set flag
0005 6441 skip if flag is 1
0006 5005 goto 5
0007 5003 goto 3
it really is just a start, but something formatting the address and
contents of addresses in octeds and some formatting of the output string
is feasable. fortunately this machine has 24Kword core, so there is
still some empty space. (or is it gone because of a faulty rewrite... we
have to test that)
simon
Although, if by restore machinery you mean the
state-machine/sequencing-logic that does the (re)-write, it can still
be more subtle than that.
In my case it was just one bad address-wire driver transistor, such
that the failure was for only one direction of current flow - the
'write' or 'set' direction.
It failed as you suggest - could read once but failed to rewrite - but
did not affect the entire core array, just a sub-set of 64-word blocks.
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
Due to a hardware fault in the core memory, I (had)
had only one
opportunity to get a full dump, which I had missed due to checking
memory from the front panel and not knowing about the fault, so I
didn't get the entire contents. In my case hindsight is great, but
it's something to keep in mind if recovering the contents is of some
concern.
That?s a good point. If the restore machinery is not working, you
can only read once, after that you?ll see zeroes. A quick check
would be to pick some location and read it several times. If that
works, the restore logic is at least somewhat functional. Still, safest would be to hook to the console. A
BeagleBone Black
has enough I/O lines to do that, I think, so it sounds like just some
level shifters and a modest amount of software.
paul
9:30 p.m.
When we restored the PDP-1 at CHM, we were worried that there might be
something useful in the memory that we would lose. We dumped the
first dozen or two locations manually, then toggled in a short program
I wrote to dump the remaining locations out serially via two of the
flags (one as a clock and one as data), and connected the flags via a
USB device (FTDI FT245, IIRC) to a laptop.
27 Sep
27 Sep
1:28 a.m.
we take the same approach now and identified some bad memory locations
in page 0. I suspect more bad locations on page 1 as it is on the same
8k board assembly. we have not touched the extra 16kword board yet.
the problem is that bad locations read 0000: clear the ac... not handy.
we program around that by jumping a lot...
for now we outputted the data to a la120 at hand, as the serial console
board we use is configures for 110baud and we dont want to change that
for now.
Fortunately one of our members has a pdp8 emulator on his macbook pro,
so testing is kinda easy.
simon
On 27-09-14 06:30, Eric Smith wrote:
When we restored the PDP-1 at CHM, we were worried
that there might be
something useful in the memory that we would lose. We dumped the
first dozen or two locations manually, then toggled in a short program
I wrote to dump the remaining locations out serially via two of the
flags (one as a clock and one as data), and connected the flags via a
USB device (FTDI FT245, IIRC) to a laptop.
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
8:13 a.m.
On Sep 27, 2014, at 4:28 AM, Simon Claessen <simski at dds.nl> wrote:
we take the same approach now and identified some bad
memory locations in page 0. I suspect more bad locations on page 1 as it is on the same 8k
board assembly. we have not touched the extra 16kword board yet.
the problem is that bad locations read 0000: clear the ac... not handy. we program around
that by jumping a lot?
Have you found bad words that have some bits stuck at zero but not others? Having a whole
word zero is peculiar. I was going to blame the write circuitry but it seems strange for
that to mess up a whole word since each bit is separate circuitry. On the other hand,
marginal select circuits might break whole words.
paul
4056
days inactive
4058
days old
14 comments
8 participants
participants (8)
-
bfranchuk＠jetnet.ab.ca -
charles.unix.pro＠gmail.com -
chuck.mcmanis＠gmail.com -
hilpert＠cs.ubc.ca -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
simski＠dds.nl -
spacewar＠gmail.com