My new toy - a complete PDP-8 on an XC6SLX9
Page 4 of 5

Author:  Pito [ Thu Nov 17, 2016 10:46 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

It works!!
As Wiz said I was too close !!!



ABSLDR.SV   5 06/01/93  LIBSET.SV   5 07/05/93  PMD   .PB  30 02/15/92
TDCOPY.SV   7 07/05/93  P     .SV 122 02/15/92  PANEW .PA 361 11/17/92
TECO  .SV  22           PASCAL.PB 161 02/15/92  PNEW1 .PA 361 11/17/92
FORT  .SV  25 07/05/93  PASCAL.TX  15 02/15/92  PNEW1 .BN  61 11/17/96
LIB8  .RL  29 07/05/93



The file PNEW1.BN (PASCAL.BN) has been created as of today :)
It took 15 seconds here. Intensive work with disk.
The original 8/E did it in 75secs. Thus is seems our disk subsystem is set slow :)

What was the problem: PAL8 does not like Linux line endings in the source, it must be Windows like CRLF :geek:

Update: attached you may find the listing from PAL8 assembler - 12450 lines, I cannot imagine how long would it take to print out all the pages on a teletype :)
The listing itself takes 960 blocks of disk, therefore you have to do it on an a freshly zeroed disk.

Still not sure what this mean:

My current understanding is it is a kind of information - 162 links have been created. When reading the 499 pages long DEC OS/8 Handbook, one can deduct it is not an error condition or warning. In the listing I cannot find any error messages there.

What are the LINKS:

In addition to handling symbolic addressing on the current page of memory,
PAL8 automatically "links" for off-page references.
In the listing, the octal code for the instruction will be followed by
a single quote (') to indicate that a link was generated..
NOTE: The option /E makes link generation a condition that produces the LG (Link Generated) error message..

So I think it says the switch /E forces to print out such links "as an error message". When I run PAL8 with /E switch it prints out a list of 162 by LG marked instructions.
On the other hand, many places on the web with PAL8 list the "LG" among the errors.. :?
For example in below listing chunk are the links visible:
02502  7100          CLL
02503  4771'         JMS MUL10
02504  1032          TAD BCD
02505  3053          DCA OP3
02506  3052          DCA OP2
02507  3051          DCA OP1
02510  4770'         JMS BADD
02511  2046          ISZ DC

Attachments: [87.76 KiB]
Downloaded 307 times

Author:  wiz [ Fri Nov 18, 2016 10:55 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

I think it may refer to the need to make a backwards link during compilation and how much memory was needed to store those links since memory was small.

Also, if the number of links changed for no apparent reason with a working program, something was not right.

Just a vague memory for me. But I think it was something like that.

Lots of fun :).


Author:  Pito [ Fri Nov 18, 2016 11:53 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

The page size is afaik 128bytes with PDP-8 (..The top 5 bits of the 12 bit program counter give the current page..).
That means - when you want access something off the current page, the PAL8 creates "a bridge" by inserting some new JMPxx instructions at the borders of the pages such it could work like in a continuous memory.
PAL8 informs that the links have been created, as the programmer may find a lot of new instructions there he/she never programmed them to be there..

PS: I've found this interesting:

KS-10 a lite version of DEC PDP-10 Mainframe.
A good intro what everything needs a creator of FPGA based mainframes :)
The author is the same as the design we talk here..

Author:  Pito [ Sat Nov 19, 2016 3:13 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

On-chip Logic Analyser :)
20ns/div resolution.
ChipScope6.JPG [ 249.76 KiB | Viewed 28231 times ]

Author:  Pito [ Sat Nov 19, 2016 9:57 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

The beginner's luck is over, it seems :)
The binary has been generated by PAL8 out of the asm source, but creating a working exe file is not easy.
The recommended process (40y old btw) is as follows:

The absolute loader loads the binary into the core, and the subsequent SAVE saves it on disk as the resulting PASCAL.SV - that is the exe you normally run.
When running SA it saves .SV file on the filesystem, but the resulting .SV is defunct (but the size is ok). Moreover, the SAVE crashes, it does not land in dot.
Under SIMH with the same disk image and Pascal source it works.

As I do not have the Front Panel with Switches and LEDs, I've started to mess with the LA.
Currently looking for a good signal to tap in order to trigger in LA when the issue occurs :?:

An interesting pattern when pdp crunches numbers (pascal benchmark). I like it :)
The AC is the 12bit Data and MA/XMA is the 12+3bit Address..

Below picture is not a simulation, but reality.
LA runs on-the-chip, takes about 100slices and uses 2kSamples of internal bram for samples (could be enlarged based on available bram up to 131kSamples).
You may have up to 16 LAs, each LA with up to 256 probes. Each LA with up to 16 triggers, and up to 16 trigger sequence levels.
The LAs communicate and the data are uploaded via jtag. Great!
ChipScope7.JPG [ 373.55 KiB | Viewed 28222 times ]

Author:  wiz [ Sat Nov 19, 2016 11:35 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

Beginner's luck over. I would not be so sure :).

It seems to me that the next questions might be along the line of getting back to what was DEC trying to do.

IMHO - Dec was trying to make an box that users could easily modify for their particular use. The instruction set makes small interpreters easy to create for example.

And there were tools at each stage to observe and verify that each stage was working correctly. All the way from boot to running code.

There was, at least in some models, a backup button that copied the CPU state and all RAM to disk memory so it could be examined in detail.

And it was easy to figure out with only that dump what did what, save a particular image portion to disk and have it as a stand alone image.

So again, you must be VERY close.

Each step had tools to easily figure out what was not right. I never got into it at that level, but was told it was do big deal for someone who understood whatever tool.

Contrast this to the latest dump of iphone memory on hackaday and all that has been done to make really figuring out what is happening difficult.

Like you, I think RetroBSD on MZ might be a very useful piece of work. And to entertain Matt, loadable modules make the size of the kernel MUCH smaller and make adding to the system and debugging your work much easier.

And with the DEC tools once you had something working, you could just save whatever portion of main memory to disk, massage it a little and have a loadable program or module.

Lots of fun :).


Author:  Pito [ Sat Nov 19, 2016 12:15 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

DEC liked the ferrite core memories a lot. Not only they did huge profit on selling them, but they were none-volatile. So like today's FRAMs and MRAMs. Btw, the cores were 0.02in (0.51mm) in diameter -

in the latest core mem PDP-8 models.
So we may use the FRAMs or MRAMs with the external 128kW ram to mimic the cores.

Btw, I've seen the handbook of the mem expansion KT-8A module which is needed in order to run >32kW (128kW max).
As they started small in 1965, ..thinking something similar Intel and BG were thinking at later time too.. :), the memory expansion was a nightmare for the PDP-8 designers, sure.
For example there is about XX TTLs just doing remapping of a few of highest bits in several possible modi, thus it could stay somehow compatible with existing OS and hw types. I counted 131 TTLs on that module board. And we talking 2 additional address bits only.. :shock:

Author:  wiz [ Sun Nov 20, 2016 2:31 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

The woven memories certainly were in a class by themselves. Did you ever run into the mercury delay line memories. Yet another attempt.

I wonder if the flash memories have really helped? They are so easy to change that it is assumed that the software can be fixed later. And then there is the problem of them being hacked or just changing themselves. I have a PIC with one bit that doesn't remember very well.

I think a micro fully in RAM, with no flash would be very useful. An RAM based FPGA is pretty much like that. Why not a PIC or 8051?

My conclusion is that the need for reliable stuff is now bigger than ever. And I think that is what DEC really delivered. Easy to get running, easy to verify all was OK, easy to troubleshoot, easy to build a new design on top of an older one, easy to figure out what was wrong when something didn't work right.

Most stuff has become so complex that no one really understands what is going on. I think of my troubles with my mips debugger. I used 'exit' as a symbol. This lead to a cryptic error condition. The fix was discovered by accident. Not at all what one would like to see!!

So I wonder where your PDP-8 and the other PDP recreation projects will lead? I think they could be quite significant?

There was a real benefit in designing the CPU from the ground up. Its proper operation could be well understood and tested for despite the huge number of chips and other parts that were used.

I am having trouble convincing myself that PIC32 is simple enough to make it? Can it every really be tested? Or is it just too complex?

Hard questions....

I have one unrelated point you might like to ponder? The cheap cell phone of today, $30USD with many peripherals and a really powerful radio has yet as far as I know to be hacked into being a simple ham radio transceiver. It could be a simple walkie-talkie or even better some sort of data radio maybe even communicating with some of the ham satellites already in orbit. Why hasn't this already been done? It can't really be that hard can it?

We were looking for winter projects!!

Lots of fun :).


Author:  Pito [ Sun Nov 20, 2016 3:30 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

With the on-chip LA I see following after the SAVE crash - the ADDR loops between o7672 and o7673, while AC=0.
After running SAVE in SIMH I see following code in the memory locations around above addresses:

7666:   1353
7667:   6746
7670:   1350
7671:   6743
7672:   6741      <----
7673:   5272      ----> Here it loops with a period of aprox 13 clocks
7674:   6745
7675:   7104
7676:   7640
7677:   5317
7700:   7410

What are the instructions there??

7672:   6741      <---- LOOP
7673:   5272      ----> JMP  to address 72 on this page
7674:   6745

So in my PDP-8 it loops, in SIMH does not.. :?

Update: the 67xx are the IOT opcodes for RX01 floppy. No idea why it wants to work with floppy disk when doing SAVE SYS or SAVE RKA0: ..

UPDATE: the 674x op codes comes from RK8 disk controller..

Author:  Pito [ Sun Nov 20, 2016 6:12 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

So I wonder where your PDP-8 and the other PDP recreation projects will lead? I think they could be quite significant?

@Wiz: this short off-topic is aimed towards young talented makers, my intention is not to become a PDP-8 guru.. Programming micro-controllers and building arduinos today is not too much exiting business it was 35y back as we did with help of a single wet XEROX A4 cpu instruction sheet and 2-3 other XEROX A4 sheets with DIL socket layouts of our lovely cpus and memories :)
The real EE work today is with FPGAs, ASICs, SoCs "mixed signal designs" - the pic32 and others are just helpers for blinking the front panel leds..
So assembling Pascal and Fortran from sources would be the pinnacle here :)

Author:  wiz [ Sun Nov 20, 2016 11:06 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

Could be a delay hack. When doing serial i/o I often wish for a delay of 1/2 bit time. There is no simple way to get this from the serial chip without having any other effects especially when the baud rate changes.

But some 'common' [always present] peripheral may be doing this sort of thing as a documented or undocumented 'feature'.

Some of the brightest DEC programmers got 'stuck' writing drivers where size was crucial and tricks were often used.

Some of the comments in the drivers were very creative and often quite amusing.

I remember being told that bugs were OK provided they were well documented and their was an otherwise good reason for them. Greatly reduced size or it seems to work everywhere already so lets not change things and discover other problems.

This was especially true when you were trying to get some other manufacturer's stuff to work with your new DEC driver. The only documentation was that it was working in another system that you could look at.

Real EE work is certainly an interesting comment. Does figuring out how to use some manufacturer's stuff count as real EE work?

And how should this sort of thing be documented?

These still are some very important and hard to answer questions.

Isn't real i/o where the rubber meets the road!!

I have always felt that easily understood reverse assembly and compilation are a required feature to create a long term reliable system. You can easily tell exactly what is or should be happening regardless of what created the code you are looking at.

Lots of fun :).


Author:  Pito [ Tue Nov 22, 2016 1:11 am ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

As the issue with SAVE command seems to be hw related, I tried with another Pascal called P4 (today P5) in the meantime.
P4 is a compiler, which creates P-code (.PB), the P-code is run then by the P4 itself.
First thing I tried - to compile P4 by itself, as the source is available. Interestingly P4 loaded the P4 source (245kB large Pascal) and worked hard with it (based on SDcard led activity) for 45minutes long, finally ended with:

P10F  .PS 638


P8RTS V1-0-F E
P8COM V1-0-F F

*** Error: Ran out of memory during program or segment load


That is OK as the experts say it cannot be compiled on PDP-8 but on a bigger machine (which one??). That same in SIMH ended the same way, but did much faster :)

Therefore I took the P10FDE, which is a 28kB large Pascal source (it prints out the .PB P-pseudo-assembly code listing), and compiled it with P4. It worked, after ~1.5 minutes I got the P10FDE.PB P-code.
And when run the P-code, which lists the P-code of itself, I got 4870 lines of:
 P8RTS V1-0-F E
 PASCODE 1-0-F-2

 PFL COUNT:              41
 SEGMENT COUNT:           2
 MAX WORK SPACE:     377777
 NO-PMD FLAG:      False
 -     :      .PB
 - IO  :      .LS
 PFL 0:  SEG 1, OFFSET 16065

016065 15002114     ISP 2114
016067 0000         LSC 0
016070 51400002     STG I 2
016072 17001327     SLN 1327
016074 70402014     LDA 1 2014
016076 10000001     DUP 1
016100 16416107     LCA 16107
016102 0100            '@'
016135 10020031     CIP MFTRT
016137 0713         INS 14
016140 31400002     LDG I 2
016142 51402114     STG I 2114
016144 70402056     LDA 1 2056
015532 10000000     DUP 0
015534 16415556     LCA 15556
015536 0040            ' '
015537 0104            'D'
015540 0105            'E'
015541 0106            'F'
015542 0111            'I'
015543 0116            'N'
015544 0105            'E'
015545 0104            'D'
015546 0040            ' '
015547 0111            'I'
015550 0116            'N'
015551 0040            ' '
015552 0120            'P'
015553 0106            'F'
015554 0114            'L'
015555 0040            ' '
015556 0020         LSC 20
015557 0020         LSC 20
015560 10020006     CIP WRSRT
015562 10000000     DUP 0
015564 20000013     LDL U 13
015566 0001         LSC 1
015567 10020010     CIP WRIRT
015571 0460         POP
015572 0437         ILN
015573 12000007     CAP 7
015575 17001304     SLN 1304
015577 12000007     CAP 7
015601 0433         RET



Great how this tiny system mastered such volumes ;)
Can we do something similar with retrobsd/lite? :)

Author:  wiz [ Wed Nov 23, 2016 1:33 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

I am on the road right now.

I think you have hit the nail on the head.

Is this or some of this PDP stuff useful with Retro/Lite?

My answer is a BIG yes !!

Now how do we proceed?

What would be most useful to have working?

Lots of fun :).


Author:  Pito [ Wed Nov 23, 2016 2:18 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Is this or some of this PDP stuff useful with Retro/Lite?

Hmm, I do not think it is useful directly.. Unless you port SIMH's pdp8 to retro/lite :)

The key LL here is: there is a tiny cpu (almost nil) with tiny 32kW of RAM and NO ROM, and you have got an OS with a filesystem, commands which are useful, with several high level languages (with single to ~double precision fp), assemblers, tools.. It can compile large sources, and when clocked >=50MHz the responsiveness and look and feel is as with today's stuff.. 8-)

The recommended reading - a short history of CPUs, great retro stuff in there :)

Author:  wiz [ Thu Nov 24, 2016 7:21 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

I suppose in some senses java/javascript is a sort of universal language.

It seems to me that it is effectively not open in the sense that you can easily tell exactly what it is doing?

Also, hacking the underlying interpreter to have secondary effects would be pretty hard to detect or understand.

All that said, PDP-8 code is simple and pretty easy to understand even when no sources are available.

Maybe that is a worthwhile spec?

The code can be understood and modified with no sources available?

Kind of a hard problem from where I find myself today.

But I think well worth some careful additional thought?

Maybe the reverse assembly and compilation tools are the next place to study.

Lots of fun :).


Author:  Pito [ Mon Nov 28, 2016 8:23 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

A second board has arrived:
cluster.JPG [ 152.2 KiB | Viewed 27969 times ]

Author:  wiz [ Tue Nov 29, 2016 1:44 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

Nice looking board.

PDP cluster in the beginning :).

Board just needs DDR.

I bet you could do a ttl version of 10base2 pretty easily between multiple boards? Especially doing just UDP packets.

Does it have enough RAM to run Retro?

Adding SD should also be easy especially if driven from software.


Author:  Pito [ Tue Nov 29, 2016 1:54 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

You may put microblaze cpu with mmu in it, and xx MB of dram, it could fit inside the fpga. And you may run retrobsd or linux.. The microblaze is almost identical to pic32 cpu. Microblaze is highly configurable and supported by Linux kernel and GCC.

Author:  wiz [ Tue Nov 29, 2016 3:45 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

Hi Pito,

So I guess the question is whether we should implement Retro in it at all?

Assuming Linux is already available?

Maybe this is a good test for how portable Retro really is?

And is MicroBlaze really open source. Can we run it and our stuff too on another FPGA just to be sure?

Maybe it is time for a "This is how I got Retro/Linux running on my XXX FPGA board?"

At one point in time there were 7 different manufacturers making 6502s. We really need multiple sources that work here also.

From where I look, we need MUCH simpler stuff. Small kernels. Ease of adding custom stuff to our basic micro kernel.

Lots of fun :).


Author:  Pito [ Tue Nov 29, 2016 5:25 pm ]
Post subject:  Re: My new toy - a complete PDP-8 on an XC6SLX9

And is MicroBlaze really open source. Can we run it and our stuff too on another FPGA just to be sure?

Can we run retrobsd on an another chip than the pic32MX?

Page 4 of 5 All times are UTC
Powered by phpBB® Forum Software © phpBB Group