RetroBSD

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

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

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:

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:

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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: https://www.techtravels.org/ks10-fpga-2/

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..

_________________
Pukao Hats Cleaning Services Ltd.

On-chip Logic Analyser
20ns/div resolution.

_________________
Pukao Hats Cleaning Services Ltd.

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!

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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 -

https://www.youtube.com/watch?v=7GP78j6VhWs
https://www.youtube.com/watch?v=H98gfQJHZLUin

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..

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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:


What are the instructions there??



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..

_________________
Pukao Hats Cleaning Services Ltd.

@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

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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:

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:

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

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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..

The recommended reading - a short history of CPUs, great retro stuff in there
http://www.cpushack.com/CPU/cpu.html#tableofcontents

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

A second board has arrived:

_________________
Pukao Hats Cleaning Services Ltd.

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.

Wiz

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.
https://en.wikipedia.org/wiki/MicroBlaze

_________________
Pukao Hats Cleaning Services Ltd.

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 .

Wiz

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

_________________
Pukao Hats Cleaning Services Ltd.