• Please review our updated Terms and Rules here

Build your own PDP 8I, Part 4..

Marty

Veteran Member
Joined
Jul 26, 2009
Messages
3,141
Location
Boulder , Colorado USA
Hi All;

I've decided to start a new thread, as the last one was long enough..

http://www.vintage-computer.com/vcforum/showthread.php?49355-Build-your-own-PDP-8I-Part-3

http://www.vintage-computer.com/vcforum/showthread.php?49355-Build-your-own-PDP-8I-Part-3/page40


Here is a copy of some of the last posting in part 3..

I am going to try Dave's alternate program, and report what it shows..

0000 6044
0001 6032
0002 7200
0003 7402
0004 6034
0005 7402
0006 5000..

After I run it, that is after putting in a 0101 in the Accumulator, It shows an 'A' on the screen..
Then after the next continue, after the 6034 at address 0004..
It shows a '0001..
I even slowed it down, to my regular fast clock.. Same thing.. I even tried putting in a 'B'.. Same output, '0001..
What I don't know is 'if' the '0001 is correct or if it should show what I originally entered into the Accumulator..

"" Have you also tried my ECHO program from post #377 (PC to PDP-8 UART, loopback internally via PDP-8 software back to UART and back to PC)? Type a character on the PC - it should echo back on the PC. ""

Yes, that is the one that fails, still loops at address '0001 and '0002..

"" When you say you have tried the interrupt program - do you mean the one in post #382? ""
Yes..

"" I can give you a few things to look at in the short-term (I will be out for most of the day today). No problem, I will be gone from about 11:00 till 2:00..

When you press a key on your PC - and the character is received by the UART - Pin 19 of the UART should go from '0' to '1'.

"" should go from '0' to '1'. ""

It stays at '0'..

"" and the character is received by the UART ""

YES.. pin 20 on the UART..

E12 pin 8 (PINT) should go from '0' to '1' at the same time (this gate merges the interrupts from the UART Tx and Rx). Just check that pins 9 and 10 of E12 (inputs on figure 1 of the TTY interface schematics) are both '1' before you start (signifying no interrupts are pending).

E12 pin 8 (PINT) should be wired to schematic LD21 E5 pin 12. This pin should also go from a '0' to a '1' when you enter a key on your PC.

Assuming interrupts have been enabled by an ION instruction (6001) pin 13 of E5 should already be a '1'.

An incoming interrupt from the Rx half of the UART should, therefore, drive pin 11 of E5 low (/I.IE) - which (in turn) is wired to our favourite place - pin 8 of J7 on schematic LD11 (the F/A state machine). ""

I am going to make another change to the Board, I am going to monitor with Led's the error status pins..

I Just found something interesting, from my Status Led's, which monitor pins 13, 14, 15, 19, 20 and 24..
And when monitoring pin 19, it goes up and down when running Dave's reverse echo program,
But, stays the same when running the Interrupt program, which means the Interrupt is not getting thru to the computer..
As pin 19, doesn't go high..

I tried the RIM Loader, and I think it fails for the same reason, that Echo fails..


THANK YOU Marty
 
Last edited:
Marty,

I am a little bit confused (it won't be the first time and it won't be the last time)...

You said back in part 3 post #394 that my 'reverse ECHO' program was working (the one posted in #391).

For this program to work - characters have to be transmitted from the -8 to the PC and looped back to be received by the UART again. So, the receive half of the UART must be working. In order for the -8 to 'sense' that a received character is available, pin 19 of the UART ***HAS*** to have gone high.

I really want to see this pin go high - it has to...

Can you re-enter my reverse echo program again (included below as we have now started a new part); install the RS232 loopback and just make sure things work as expected (i.e. <NUL>, ..., A, B, C, ... is displayed on the terminal emulator of your PC).

0000 7200 CLA ; Start off with an ASCII <NUL> to transmit.
0001 6032 KCC ; Keyboard clear received character flag.
0002 6046 TLS ; Teleprinter clear transmitter flag and print character in AC.
0003 6041 TSF ; Teleprinter skip on flag.
0004 5003 JMP 3 ; Teleprinter flag not set so wait for the character to be transmitted.
0005 6031 KSF ; Keyboard skip if flag set.
0006 5005 JMP 5 ; Keyboard flag not set so wait for the character to be received.
0007 7200 CLA ; Clear accumulator (don't get confused by the character already being in the accumulator).
0010 6036 KRB ; Keyboard read character and clear flag.
0011 7001 IAC ; Increment accumulator (move on to the next ASCII character. The UART will ignore the more significant bits when we exceed 8 bits).
0012 5002 JMP 2 ; Repeat the process indefinitely with the next character to be transmitted.

STOP the program running.

Deposit 0005 with 7402 ; HLT

Set AC=0101 (ASCII A).

Re-run the program from location PC=0001 (Note location 0001 not 0000 - i.e. don't clear AC).

The -8 should halt.

If all has gone according to plan UART pin 19 should be a '1'...

Remove the RS232 loopback link.

Set AC=0101 and re-run the program from PC=0001.

UART pin 19 should be a '0'.

Reinstall the RS232 loopback link.

Set AC=0101 and re-run the program from PC=0001.

UART pin 19 should be a '1'.

Dave
 
Hi All;

Dave, Thank You for your Questions and Concerns..

On a side Note, On the last page of the TTY Interface notes, there is a long program, at least for us..
And as far as I can tell it is running fine.. I don't know what it does, but it is running..

"" I am a little bit confused (it won't be the first time and it won't be the last time)...

I know I've been there myself..

You said back in part 3 post #394 that my 'reverse ECHO program was working (the one posted in #391).

For this program to work - characters have to be transmitted from the -8 to the PC and looped back to be received by the UART again. So, the receive half of the UART must be working. In order for the -8 to 'sense' that a received character is available, pin 19 of the UART ***HAS*** to have gone high.

I really want to see this pin go high - it has to...

I had this pin Monitored with my scope, for Various programs, and I will re-enter and run both that program and do the modifications to the program that You are asking for me to do..

Can you re-enter my reverse echo program again (included below as we have now started a new part); install the RS232 loopback and just make sure things work as expected (i.e. NUUL>, ..., A, B, C, ... is displayed on the terminal emulator of your PC.

0000 7200 CLA ; Start off with an ASCII <NUL> to transmit.
0001 6032 KCC ; Keyboard clear received character flag.
0002 6046 TLS ; Teleprinter clear transmitter flag and print character in AC.
0003 6041 TSF ; Teleprinter skip on flag.
0004 5003 JMP 3 ; Teleprinter flag not set so wait for the character to be transmitted.
0005 6031 KSF ; Keyboard skip if flag set.
0006 5005 JMP 5 ; Keyboard flag not set so wait for the character to be received.
0007 7200 CLA ; Clear accumulator (don't get confused by the character already being in the accumulator).
0010 6036 KRB ; Keyboard read character and clear flag.
0011 7001 IAC ; Increment accumulator (move on to the next ASCII character. The UART will ignore the more significant bits when we exceed 8 bits).
0012 5002 JMP 2 ; Repeat the process indefinitely with the next character to be transmitted.

STOP the program running.

Deposit 0005 with 7402 ; HLT

Set AC=0101 (ASCII A).

Re-run the program from location PC=0001 (Note location 0001 not 0000 - i.e. don't clear AC).

The -8 should halt.

YES..

If all has gone according to plan UART pin 19 should be a '1'...

Remove the RS232 loopback link.

Set AC=0101 and re-run the program from PC=0001.

UART pin 19 should be a '0'.

YES..

Reinstall the RS232 loopback link.

Set AC=0101 and re-run the program from PC=0001.

UART pin 19 should be a '1'. ""

YES !!!!

Here are some pictures of it Running the Reverse Echo program..
I am sorry about the Scope Picture, as it initially was in Focus, But, I must have moved it when I pressed the Button to take the picture..

001.jpg


002.jpg 003.jpg


THANK YOU Marty
 
Last edited:
If you have a scope then just run my 'reverse ECHO' program with the RS232 loopback in place and have a look at UART pin 19 with the scope probe. It should be going high briefly then low. That would be much easier than playing with the HLT...

Dave
 
Excellent (as Monty Burns would say)...

So we now know that UART pin 19 is working correctly.

So, we can transmit characters from the -8 to the PC OK. We can loopback the characters to the -8 and receive them OK.

Next little test...

Enter the following little program and run it from PC=0000. It will just loop - but what it should do is to continuously read the UART received data register and store what it finds into AC.

0000 6034 ; KRS - Keyboard Read Static.
0001 5000 ; JMP 0 - Repeat forever.

Connect your PC transmit serial port up the the -8's receive serial port.

See if there are continuous low-going pulses on UART pin 4 with your scope (Receive Data Enable). These come from my test program.

Type a letter 'A' on your PC keyboard (within Terra Term).

What 'value' do you see in AC?

Is it possible that there is a serial port communications mismatch between your PC's serial port parameters and the -8's (especially in the area of number of data bits, number of stop bits or parity).

Can you post your PC Serial Port configuration and the wire-wrapping strapping for your COM 2502 UART and check that the two are the same?

I just want to try and get your actual configuration straight in my head so we can work out why the data transfer from the PC to the -8 isn't working correctly.

"On a side Note, On the last page of the TTY Interface notes, there is a long program, at least for us..
And as far as I can tell it is running fine.. I don't know what it does, but it is running.."

Interestingly, this program doesn't contain any '6xxx' instructions so it can't have anything to do with the TTY interface!

Cheers,

Dave
 
Hi All;

Dave, Thank You for the Next test..

"" Next little test...

Enter the following little program and run it from PC=0000. It will just loop - but what it should do is to continuously read the UART received data register and store what it finds into AC.

0000 6034 ; KRS - Keyboard Read Static.
0001 5000 ; JMP 0 - Repeat forever.

Connect your PC transmit serial port up the the -8's receive serial port.

See if there are continuous low-going pulses on UART pin 4 with your scope (Receive Data Enable). These come from my test program.

YES..

Type a letter 'A' on your PC keyboard (within Terra Term).

What 'value' do you see in AC?

'0000 ....

Is it possible that there is a serial port communications mismatch between your PC's serial port parameters and the -8's (especially in the area of number of data bits, number of stop bits or parity).

Can you post your PC Serial Port configuration and the wire-wrapping strapping for your COM 2502 UART and check that the two are the same?

Sure..
On Tera-Term, Com3, 300 Baud, 8 data bits, No Parity, one stop, and No flow control..

On the Com 2502, Pin 34, CS, a '1' will enter the control bits into the holding register, It is tied to Vcc..
Pin 35, NP, No Parity, A Logical '1' will eliminate the Parity bit from both the Transmit and Receive character.. It is tied to Vcc..
Pin 36, TSB, The number of stop Bits, a '0' Selects one Stop bit, I have it tied to Ground..
Pin 37 and 38.. NB2, NB1, Number of Bits, Both tied to Vcc, so 8 Bits is Selected..

Pin 16, (bar)SWE, Tied to Ground
Pin 21, MR, Master Reset, Tied to Ground..

Pin 39, POE, left floating..

I just want to try and get your actual configuration straight in my head so we can work out why the data transfer from the PC to the -8 isn't working correctly.

That is exactly what I figured, as well..

"On a side Note, On the last page of the TTY Interface notes, there is a long program, at least for us..
And as far as I can tell it is running fine.. I don't know what it does, but it is running.."

Interestingly, this program doesn't contain any '6xxx' instructions so it can't have anything to do with the TTY interface! ""

I noticed, as I was entering it..

Dave, I found what circuitry would be used to make the Instruction 6034 work..
Let's make sure that we are talking Oranges and Oranges, and not Oranges and Apples..
And, I have ohmed it out, and it seems fine to me..
There is not as much as I originally thought to the circuit..
I am going to check G19, pins 3,4,5, and 6 with the scope.. Especially pin 4 (RDE)..
I traced the signal (RDE) into the AC(L) circuit and then into the RAL and RAR circuit where it gets eliminated..
The S0 and S1 pins on the 74194's have it on them, a mostly Low signal with a high pulse in between the lows..

I have a Theory, as to what may be the problem..
Nothing is wrong with either the I/O/UART circuitry, or the Computer itself..
But, that because the Computer is running at a very slow pace, compared to a real PDP 8i, and even though I am going at a slow 300 Baud on the Uart..
So, that the computer is too slow to get the correct information from the UART..
What is slowing the machine down, is mainly not the IC, circuitry itself..But the Write Pulse to the Memories..
In the Original Memory Upgrade, it uses 2102's and a 9602 to determine the Pulse width to the Memories themselves..
That no matter how fast or how slow the computer was actually running the Write pulse to the Memories was always the same..
And I could not get the 9602's to work here, as well as near as I could tell the paper, nor either book gives the Resistor/Capacitor value, nor the amount of time needed to set the 9602 for length of time..
And so, I used some 7404 gates to drive the signals high or low depending on which Q or (bar) Q the output signal went to..
Which seemed to work, unless I upped the computer frequency too much, then the Memories would not be reliable..
And so that is what (at present) determines my top operating speed.. And to a degree, my wire mess..
So, one of the things, that I think would be good for me to do, is get the 9602 working and set to a correct length of time for the write pulse..


THANK YOU Marty
 
Last edited:
I don't think your speed is the problem yet...

By sending one single character from the PC to the UART receive side it should have been buffered within the UART itself and (a) never overwritten and (b) always available to be read.

Can you repeat the above and (whenever pin 4 of the UART goes low) check the receive data lines (pins 5-12). They should go from tristate (when UART pin 4 is high) to whatever character was in the receive buffer (when UART pin 4 is low).

If this doesn't work - we still have a problem with the UART receive side itself. If this is the case, we must investigate further. I will check the link settings with my data sheet but (from what you have documented and I remember) things seem fine...

I would be much happier if (when you enter an 'A' on Tera Term) we see 0100_0001 being received in the UARTs receive data register.

I am still of the opinion that the fact that the -8 can both transmit and receive from/to itself indicates to me that the problem is not with the -8 itself - but the interface between the PC and the -8 still.

We may have a problem 'down the line' with the speed of the -8 - but doesn't Tera term have a DelayPerChar setting so we can 'slug' data transmission from the PC to the -8 to suit your -8 speed in the short term.

One thing I did think of is MR (Master Reset UART pin 21) being tied low. With the -8 all of the flip-flops and counters (those devices with 'state') power up to 'rubbish' - but pressing the STOP and CLEAR buttons seems to sort the 'mess' out. The UART is quite a complex beast and not resetting it is a crime! Can I suggest disconnecting UART pin 21 (MR) from 0V and connecting it to CLEAR.H? That way, when you press CLEAR on the -8 it will reset the UART to a known state. The UART could be powering up in a 'random' state every time and it is this fact that may be confusing it and us!

"There is not as much as I originally thought to the circuit..". I agree, that's what is getting me confused. There is s*d all here to make the UART receive circuit work - so why is it taking us so long to get it working?! We are missing something obvious...

Dave
 
Last edited:
Thinking a bit more out of the box...

Remove IC E19 from the board. Connect E19 pin 8 (/RDA to UART) to '1', E19 pin 6 (/DS to UART) to '1' and E19 pin 11 (/RDE to UART) to '0'. This modification will permanently enable the receiver data buffer onto IORD4-11. Without any software at all running in the -8 (i.e. depress STOP and CLEAR) you should now be able to hit an 'A' under TeraTerm and (literally) the data should appear correctly on IORD4-11.

If not, there is definitely something wrong with the PC to UART interface or timing etc. (since the -8 is taking no part in this transaction anymore at all).

Dave
 
Hi All;

Dave, Thank You for Your thoughts..

"" One thing I did think of is MR (Master Reset UART pin 21) being tied low. With the -8 all of the flip-flops and counters (those devices with 'state') power up to 'rubbish' - but pressing the STOP and CLEAR buttons seems to sort the 'mess' out. The UART is quite a complex beast and not resetting it is a crime! Can I suggest disconnecting UART pin 21 (MR) from 0V and connecting it to CLEAR.H? That way, when you press CLEAR on the -8 it will reset the UART to a known state. The UART could be powering up in a 'random' state every time and it is this fact that may be confusing it and us! ""

I agree that I thought it was kind of funny, that they didn't have some kind of Reset set up.. I had thought about setting one up with a switch, But, I like Your Idea a whole lot Better !!

"" Remove IC E19 from the board. Connect E19 pin 8 (/RDA to UART) to '1', E19 pin 6 (/DS to UART) to '1' and E19 pin 11 (/RDE to UART) to '0'. This modification will permanently enable the receiver data buffer onto IORD4-11. Without any software at all running in the -8 (i.e. depress STOP and CLEAR) you should now be able to hit an 'A' under TeraTerm and (literally) the data should appear correctly on IORD4-11.

If not, there is definitely something wrong with the PC to UART interface or timing etc. (since the -8 is taking no part in this transaction anymore at all). ""

I will do and let You know the results..

I have wired in the MR Reset, and it shows it working on the scope, when I press the Button, a high pulse is issued, otherwise it is Low..
I have pulled E19, and have wired the appropriate pins on the UART via a chip-clip..

I have tried this and It shows all '0000's, I have taken the scope and looked at pin 20, and when I press an 'A' it shows Data coming into the Serial connection on the UART..
I have checked pins 5 thru 12 with the scope..
I have gone back to the very basic, I have Switched OFF my interface to the -8 and tied pins 2 and 3 together via a wire on the Personal Computer side, and so I should get Exactly what I have typed in and I am Not getting that.. I sometimes get am 'A', but most of the time its garbage.. So my USB to Serial converter may be Bad on one side.. I will do further checking..

I have Found the Problem, my USB to Serial Converter will Only work correctly at 110 Baud !!!!! And not at 300 Baud or any other speed.. I am going to see IF I have a Serial Card that will work in my Computer (PC)..
No go, I am going to (for now) get another PC Computer with a working Serial Port, and work on it getting to function with that..

001.jpg


The above picture should say it all !!!!


THANK YOU Marty
 
Last edited:
I thought there was something else astray somewhere other than your -8!!!

So, RIM loader and "hello world" next is it???

Load the RIM loader into the -8 using the deposit keys - and make sure you have loaded it correctly using the examine keys.

Start the RIM loader running at PC=7756.

Send my hw.rim file to the -8 from tera term.

When the file has been transferred to the -8 it doesn't halt or anything. Press STOP on the -8.

Use the hw.lst file and examine the memory contents to make sure the file has loaded down correctly (it starts at address 0200).

Start "hello world" running at PC=0200.

Dave
 
Hi All;

Dave, Thanks for the Encouragement..

I have tried the RIM Loader once, I saw alot of activity, but no Hello World..
But, I am clearing all of Memory to '0000..
And then I will try again.. And do as You say compare the Listing with the -8..

"" Use the hw.lst file and examine the memory contents to make sure the file has loaded down correctly (it starts at address 0200). ""
Nothing there !!!

I upped the Speed of the Computer, and I GOT "HELLO WORLD" to display on the screen !!!!!!!!!!!!!

002.jpg


Where do I get either the BIN Loader for the 8i
OR, a RIM loadable BIN Loader ??
I'LL have a look in BitSavers..

I have found a RIM Loadable BIN Loader and it seems to work fine, as near as I can tell..
http://so-much-stuff.com/pdp8/tapes/digital.html
I have run, d01b, d01c and d02b..

THANK YOU Marty
 
Last edited:
Way to go Marty!!!!!!!!!!!!!!!!!!!

A simple "Hello World" message doesn't capture all of the "blood, sweat and tears" to get to that point does it?!

Just to confirm that d01b is actually running correctly...

Did you get the HALT right at the beginning with AC equal to 0000?

D01b should keep running without halting after that assuming everything is OK.

After 128 iterations of the test - you should get a BELL on Tera Term - this indicates that it is really running...

If your -8 is running slower than a real -8 - you can decrease the time taken for the BELL to occur by patching memory locations 4351 and 4352 (both with the same value) before starting the test. The initial value should be 7600. If you change this to something like 7776 - you should get a BELL on every two loops around the program rather than every 128 (i.e. subtract the number of iterations you want to report from from 10000 OCTAL).

Incidentally, you can also run d01b to force an error to be reported - again, just to make sure things are running properly. You are told to set SR=7777 before running the program. Set it to something other than 7777 for devilment... The test should HALT at 0501/0502 (OSR TEST 1 if you look it up in the PDF listing). The text by the test says "OSR did not set AC to 7777" - which is correct (because we did not put 7777 in the switch register like we were told to do). I like testing out the tests...

d01c is just another minor revision to d01b.

d02b should also produce a BELL after 40 iterations.

You should then try d11a (memory test). This comes in two 'flavours' - one runs in low memory and the other runs in high memory. You want to run them both.

d04b (Random JMP).

d05b (Random JMP and JMS).

d07b (Random ISZ).

After that - time for Chess! I have a version of CHEKMO (in RIM format) that I assembled from source.

By the way, have you downloaded the PDP-8 cross assembler for your PC? (I use a version - supplied with 'C' language source code - from Doug Jones).

Good work...

Dave

PS: I also realise that we still haven't fully completed the interrupt testing have we yet? This was the program from earlier to test the receiver interrupts out:

0000 0000 - This is where the return address would be stored.
0001 6032 - Keyboard clear flag.
0002 7020 CML - Toggle the LINK register every time we get an interrupt.
0003 5400 JMP I 0 - Return from interrupt handler.
0004 6001 ION - Enable interrupts.
0005 7001 IAC - Increment the accumulator as a background task...
0006 5005 JMP 5 - Keep looping forever...

Start the program running from PC=0004.

The accumulator should increment. Whenever you press a key on the keyboard, the LINK flag should toggle in response.

Now you have fixed your PC->8 serial link, this should now work (baring errors in my program of course).

Dave
 
Last edited:
MAINDEC-08-D02B sends a null character out the serial port to generate an interrupt. If the interrupts are not working, or the serial port does not generate an interrupt this test will not work.
 
Hi All;

Thank You, Dave and M-Thompson, for Your response and Information..

"" Just to confirm that d01b is actually running correctly...

Did you get the HALT right at the beginning with AC equal to 0000?

I don't remember for sure, I was looking at everything else, But, I am going to Run Everything again..

I am also going to make another change.. At present it is running a 4.7K (4700) HZ, so I am going to wire it to the same IC that does my divide down from the Crystal on the I/O Board.. It will go thru a Jumper, so if needed I can go back to the 555..

D01b should keep running without halting after that assuming everything is OK.

After 128 iterations of the test - you should get a BELL on Tera Term - this indicates that it is really running...

If your -8 is running slower than a real -8 - you can decrease the time taken for the BELL to occur by patching memory locations 4351 and 4352 (both with the same value) before starting the test. The initial value should be 7600. If you change this to something like 7776 - you should get a BELL on every two loops around the program rather than every 128 (i.e. subtract the number of iterations you want to report from from 10000 OCTAL).

Incidentally, you can also run d01b to force an error to be reported - again, just to make sure things are running properly. You are told to set SR=7777 before running the program. Set it to something other than 7777 for devilment... The test should HALT at 0501/0502 (OSR TEST 1 if you look it up in the PDF listing). The text by the test says "OSR did not set AC to 7777" - which is correct (because we did not put 7777 in the switch register like we were told to do). I like testing out the tests...

d01c is just another minor revision to d01b.

d02b should also produce a BELL after 40 iterations.

You should then try d11a (memory test). This comes in two 'flavours' - one runs in low memory and the other runs in high memory. You want to run them both.

d04b (Random JMP).

d05b (Random JMP and JMS).

d07b (Random ISZ).

Yes, I plan on Running all the Tests I can find, just to be sure..
I even thought I would see if I can find a 4K Basic, just to see if it will run and show something on the screen..

After that - time for Chess! I have a version of CHEKMO (in RIM format) that I assembled from source.

By the way, have you downloaded the PDP-8 cross assembler for your PC? (I use a version - supplied with 'C' language source code - from Doug Jones).
NO, Do you have the Link ??

Good work... ""

"" PS: I also realise that we still haven't fully completed the interrupt testing have we yet? This was the program from earlier to test the receiver interrupts out:

0000 0000 - This is where the return address would be stored.
0001 6032 - Keyboard clear flag.
0002 7020 CML - Toggle the LINK register every time we get an interrupt.
0003 5400 JMP I 0 - Return from interrupt handler.
0004 6001 ION - Enable interrupts.
0005 7001 IAC - Increment the accumulator as a background task...
0006 5005 JMP 5 - Keep looping forever...

Start the program running from PC=0004.

The accumulator should increment. Whenever you press a key on the keyboard, the LINK flag should toggle in response.

Now you have fixed your PC->8 serial link, this should now work (baring errors in my program of course). ""

THANK YOU Marty
 
Last edited:
D02B transmits characters - so will test the transmit half of the UART - but doesn't test the receive side. My test program tests the receive side interrupts so we get full coverage. Chess also uses receive interrupts.

There isn't a 4K BASIC - there is a 4K FOCAL though.

There are quit a lot of languages and the PDP-8 cross-assembler here http://www.gc-net.jp/omiokone/cpldp8/. Don't worry about the Japanese character that you can't understand (!) Download and UNZIP cpld833.zip.

The cross-assembler is in the 'utility' directory.

Dave
 
Hi All;

Dave,

"" If your -8 is running slower than a real -8 - you can decrease the time taken for the BELL to occur by patching memory locations 4351 and 4352 (both with the same value) before starting the test. The initial value should be 7600. If you change this to something like 7776 - you should get a BELL on every two loops around the program rather than every 128 (i.e. subtract the number of iterations you want to report from from 10000 OCTAL). ""

I am not seeing these values at these addresses..

At 4351 I see, 3647..
And at 4352 I see, 1374..

Does SomeOne have "Hello World" in BIN format for the PDP 8 ???

That would be a good way for me to test whether I have Loaded the BIN Loader Correctly..


"" There are quit a lot of languages and the PDP-8 cross-assembler here http://www.gc-net.jp/omiokone/cpldp8/. Don't worry about the Japanese character that you can't understand (!) Download and UNZIP cpld833.zip. ""

I have downloaded it, but I have not looked at it..

THANK YOU Marty
 
Last edited:
You're probably using a different revision to me. I am using d01b-d.

If you look through the source code for d01b (printed in the PDF file) you should be able to identify the memory locations for BLCNT and BLCON. These should be close to the end of the program itself - round about some text like / RING BELL).

This is always the problem patching something that's not designed to be patched - and there are multiple copies out in the wild...

Dave
 
Hi All;

Thank You, Dave..

"" You're probably using a different revision to me. I am using d01b-d. ""

I have the same text, I guess, I would need to actually look at the various addresses and see whether or if, at or after a certain address it has some problem(s)..

I have Loaded and Run a RIM Loaded Memory Test.. So, I am fairly confident that my code for the RIM Loader is correct..
What I don't know for sure is IF my BIN Loader is correct..
Somewhere I have seen a source for it, I just don't where..

THANK YOU Marty
 
This one by any chance?

http://www.pdp8.net/pdp8cgi/query_docs/tifftopdf.pl/pdp8docs/dec-08-lbaa-d.pdf

Note that after the BIN loader has stopped - the accumulator should equal 0000 (otherwise an error has occurred).

The BIN loader contains a checksum - so it should know itself if the load has been successful or not...

I can only see one "maindec-8i-d01b-d.pdf" on this website http://so-much-stuff.com/pdp8/software/maindec.php. I guess it is possible that the BIN image doesn't correspond with the PDF of course - but there is an OCTAL DUMP file with it and the last words I can see are the magic numbers we need to patch (so they are there somewhere).

Dave
 
Last edited:
Back
Top