I have autostart working some of the time.  I am using OS8 boot, if works but not all the time.  The simulation works fine.  I think it is that the power supply for the switches does not come up as fast as the FPGA comes up.  I have added a delay in the code, it has not yet been tested.  I have also added as a build time chioce as Console Serial Device (CSD) boot.

The timing chnages are now inplace and tested on the HX8 FPGA,  I have started building the Max10 platform.  The usual struggles with new, different tools.  Two big items with the Altera build are failure to build the RK8E,it claims that spiRXD has no driver.  Both the simulator and yosys have no problems with it.  

The second problem is ram.  The Max10 has far more ram than the HX8.  It should support 32 k words.  When I specified that it infers ram, but only uses one half of the bits of storage that it should have allocated.

 Some progress, but still a long time.  Life gets in the way!

I have concluded that minicom is unable to deal with the serial stream from the PDP8e.  If I start the focal interpreter, I get decent results.  Minicom is usable with FOCAL at 115200 baud.  However when I boot OS8, minicom displays garbage.  None of the commands that I have tried produce sane results.  At the end of the display I get the "." prompt of OS8 so OS8 is still running correctly.  Doug Ingram's csd works fine.  I will not try to figure out why minicom does not work properly.

I no longer am getting random jumps and halts!  The "disk" remains ready!

I have re-written the tx and rx parts of the serial package.  This was because  I was having OS8 miss characters and sit there waiting on a character.

I have discovered that I have an Altera Max10 FPGA board. I tried re-targetting my code to the Max10 with Altera's tools.  They don't like some of the verilog system tasks that make calculating register bit widths easy.  I will have to hand calculate and then hard code the constants.  I have taken the bulk of the timing related calculations and put them in the same directory as the top level file for the FPGA.  I have that file for the ICE40 HX8K.  I will now try to do the same thing for the max10. 

 

 Well a short time since I last posted.  Much progress but still not finished.  

I believe that the sd card writing problem is solved.  I used Bob Doyle's VHDL code from his (any) PDP8.  His approach to using the sd card for storage was to completely stop the execution of PDP8 instructions while the mass storage operation was in process.  My translation and integration into my PDP8e took the approach that I would use the data break operation (DMA) like the original PDP8.  The net result was that reading worked OK, but writing did not have the word from memory before the first word was sent to the sd card, resulting in an octal 0000 as the first word, then every other word was shifted up one address.  Several changes were made in the sd.sv file to change the state machine to pre-fetch the first word so it was available before the first write to the sd card.

The next problem I categorized as random jumps, executing off in the weeds,  or crashes.  This address where this was happening was 76xx.  When I poked this into a google search, the IA came back with that this was likely because the disk was not ready.  I had hi-jacked an LED in the state display to indicate when the "disk" was ready.  When I looked at it when one of these occurrences happened, the "disk" was not ready!  I have not tracked this problem down yet.

The third problem was communication between the PDP8e and OS8.  Both minicom and picocom don't work properly with OS8.  I have a set of utility programs written by David Gesswein on my computer.  They are part of the dumprest package.  It has a dumb terminal program in it.  When I tried to compile the "dumbterm" program in that package it failed for a number of reasons.  The programs appear to have the last changes made in 2001.  My compiler is gcc  15.2   There have been numerous upgrades to C and to the standard libraries in the past 25 years!  I modified the source until I got clean compiles, and it almost works correctly.  Then I remembered Doug Ingram's console serial device.  It includes a terminal program, when I tried it, it works properly.  I am now torn as to fix the dumb terminal bug or try again with code from the console serial device.!

Again it has been a long time since I have posted!  However I do have progress to report.  I now have OS8 booting from micro SD card!

This is not without problems though.  There are currently three problems that I know of, first writing to SD cards is not correct, I will turn to simulation to see if I can find the problem there.

The second problem is random crashes, halts or loops.  Currently I can think of three possible reasons, a timing problem, I will slow the clock down and see if that clears the problem.  Secondly I may still have an instruction bug that diagnostics don't catch.  It is possible that there is a bug in OS8 that makes it go off into the weeds with user input.

The third problem is that DEC used essentially a six bit "ASCII" code.  This was before the ASCII code was approved.  I had been using Minicom as my terminal, it does not cope with this well.  I am now using picocom, it is doing better, but still not correct.  When playing with this I suspect OS8 is getting bombarded with crap!

I have modified the state machine and the operations in the states to improve the timing of the device.  I hope to be able to have the basic PDP8e, with 10 K words of memory, the EAE and the RK8E disk controller in one build.  This will push the logic usage up past 50%, it gets harder and harder to meet timing as the logic usage goes up.

I am now using OS8 Combined Kit (ock) release of OS8.  This is essentially that last release of OS8 for standard PDP8's.  There may have been further releases for the DecMates...  The ock image files were generated with  tools from the PiDP8I project:  https://tangentsoft.com/pidp8i/.  Many thanks...

Well when I went to retest the PDP8e before pushing to it github I decided to re-run the diagnostics.  Much to my surprise two failed!  The first was the adder test, the second was the extended memory.  It turns out that both of these diagnostics test to see which pages are valid and which are not!  So even though I told the program it had two fields, it checked to see if there were more!  It needs full fields to run these two diagnostics!

So another modification,  parameters.v contains two lines that define the memory size.  ram.v uses it to define the implementation.  So we now have a choice of 8K or 10K.  If one is going to run the diagnostics one must us the 8K version.

 I have upgraded the memory on this PDP8e.  It is now 10k words.  This takes 30 of the 32 block rams of the FPGA.  I had wanted it to be split into two pieces.  The bottom 8k as it was and the remaining 2k  in the high half of field 7.  However I was unable to convince yosys to do that.  So it is now 10 k continuous.   I could have written a mapper in verilog to remap the 10 k as I described but that would have increased the decoding delay.   The last block rams are unlikely to be able to be used. 

So my plan going forward is to put the binary loader at the upper end of the 2 K section.  This will entail disassembling the binary loader.  Making sure it reassembles to the identical object and then modifying it to reside in field 2 at 37xx - 3777.  At which point I can put it into the FPGA build.  Once there I can use the hardware diagnostics without regard to which ones trash the last page of field 0.  I also want to make the default serial device as the console device.

Going forward from that I should be able to add other bootloaders that can be selected via the switch register for other things like the console serial disk...

I have updated the state diagram, below.  When I started out on this project I had in mind a goal of operating this machine with a 100 MHz clock.  I soon discover that it was not something that was easily accomplished, so I dialed the clock down.  Originally I had 4 states in a machine cycle and each of the machine cycles were identical to that on an original PDP8e.  Once I had thae machine running I realized that the slowest path was reading from memory.  This was caused by the multiplexer at the output of the ram blocks used to select the proper word for reading.  So I added some pipeline  and sped the clock up.  The clock is now running at 73.5 MHz.  If you look at the state diagram you will note there are branches off of state F1, this was added when EAE was added.  Immediate operands for EAE ops are fetched in states F1 and F2(A or B). effectively shortening those operation.  As well when a deferred operation occurs which is not indexed the deferred cycle is only 3 clocks long.   There are other possible changes to the state machine that will increase the speed.