• Please review our updated Terms and Rules here

Build your own PDP 8I, Part 3..

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
You caught my post in half-edit mode again (you are just too quick off the mark)!

I have updated my previous post with a few more tests for you.

It's Sunday here as well (!) but the rest of the family are watching cricket on the TV (England vs South Africa) which doesn't interest me in the least... So a bit of Vintage Computer time for me today - but what?

Dave
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
This is what I think is a noddy program to test keyboard interrupts (it may contain the odd bug itself of course):

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.

You could replace instruction 0005 (7001 IAC) with a NOP (7000) if you like and instruction 0001 with 6036 (Keyboard read and begin next read). In this case, the accumulator won't be incremented as a background task - but the PC will continue to loop around instructions 0005 and 0006. When a keyboard interrupt occurs, the LINK register should be toggled and the accumulator should be loaded with the binary pattern of the character that was received.

The only thing in the back of my mind here is what will happen to the printer side of things (as the interrupt is enabled for both the printer and keyboard).

Dave
 

Marty

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

Dave, Thank You for the latest Program..

We have a Problem, corrected the wire up on G17, pin 12, and Now it runs Continuously, when I press a button, and only clear will stop it..
And what button, I have pressed doesn't work either..
I am going to unwire it, and see if that makes any difference..

I didn't need to unwire it, I turned off my Lamp, and saw one one my clips for an IC on the table with an Ic still in it.. Put the Ic back after straightening the Legs.. The light from the Lamp had blinded my seeing the missing IC..

And ALL works Fine Now..

"" The only one I disagree with is instruction 6031 - which should give you a high-going pulse on G17 pin 13 during CP0 (which should be wired to either E21 pin 5 or E31 pin 5 - I can't quite read the writing). You seem to have identified 6033 gives this pulse - which is incorrect. Incidentally, the test program for this should be:

0000 6031 KSF - Keyboard skip on flag set.
0001 5000 JMP 0
0002 5000 JMP 0 ""

This NOW Passes..

"" This was my test ECHO program (input character from keyboard is echoed back to printer):

0000 6032 KCC - Keyboard clear and read character.
0001 6031 KSF - Keyboard skip if flag set.
0002 5001 JMP 1 - Flag clear therefore keep looping.
0003 6034 KPC - Keyboard flag was set - so something to process. Keyboard read static to AC.
0004 6046 TLS - Teleprinter load and start (clear flag and print character).
0005 6041 TSF - Teleprinter skip if flag set.
0006 5005 JMP 5 - Flag clear therefore keep looping.
0007 5000 JMP 0 - Repeat forever...

Still Doesn't work, it still won't get past 0001 6031 Keyboard Skip..

""
Set up AC with the character to be transmitted (and what we expect to be received due to the loopback).

0000 6044 TPC - Teleprinter print character.
0001 6032 KCC - Keyboard clear and initiate read of the next character (this should also clear the accumulator).
0002 7200 CLA - Clear accumulator (trash the character to be transmitted - so we don't get confused).
0003 7402 HLT - Halt - to allow time for the character to be transmitted and received via the loopback connector.
0004 6034 KRS - Keyboard read static.
0005 7402 HLT - With received character in the accumulator for inspection. Option to change accumulator value for a different character here.
0006 5000 JMP 0 - Repeat the process again...

Note that instruction 0001 needs to have been completed before the character is transmitted and received - so there is a timing constraint here (i.e. this is a noddy test program and, therefore, may have a few quirks).

Note that I am not sure if this is working.. I did change to a faster clock, But the Accumulator always shows 0000, after the 6034 static read..

If you setup AC with (say) an 'A' character and run the program from location 0000 - you should see the 'A' transmitted and (when the character has been received by the UART) pin 19 on the UART should go from '0' to '1'.

No, it remains at '0..
Now it could be a Bad UART, but until we prove this, I can't/won't say for sure..

The PDP-8 should HALT. Allow a few milliseconds (for the Tx and Rx!) and hit CONT.

The PDP-8 should halt again with the accumulator showing the same binary pattern as the character you transmitted. If this is the case - this tests the receive data path and we can then concentrate on the receive flag and SKIP. ""

The Accumulator has '5260 in it..

THANK YOU Marty
 
Last edited:

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
So I am going to state the obvious here...

With my ECHO program running:

0000 6032 KCC - Keyboard clear and read character.
0001 6031 KSF - Keyboard skip if flag set.
0002 5001 JMP 1 - Flag clear therefore keep looping.
0003 6034 KPC - Keyboard flag was set - so something to process. Keyboard read static to AC.
0004 6046 TLS - Teleprinter load and start (clear flag and print character).
0005 6041 TSF - Teleprinter skip if flag set.
0006 5005 JMP 5 - Flag clear therefore keep looping.
0007 5000 JMP 0 - Repeat forever...

And it sitting at address 0001/0002 waiting for a character - you are sending a valid character to the UART aren't you? When you send a character - pin 19 of the UART should go from '0' to '1'. This pin (19) is a function of the UART not your PDP-8 implementation. As soon as the UART receives a character - pin 19 should go from '0' to '1'. It will stay a '1' until you issue a low-going pulse on pin 18 (a 6032 instruction) which should clear it.

Note that UART pin 19 may not go from a '0' to a '1' if the UART receives an invalid character. You should be able to check this by monitoring the error outputs from the UART (e.g. FE - Framing Error, OE - Overrun Error and PE - Parity Error). These error pins should normally be '0'. An error is indicated by a '1' level. It may be that your UART clock is accurate enough for your transmitter (i.e. whatever you are connecting your UART transmitter to is able to lock onto the serial signal) but not accurate enough for your receiver.

What I am thinking is to turn my ECHO program around so that the PDP-8 sends a character to the UART, the UART transmits the character, the transmitted character is echoed back to the UART receiver (by a loopback connector between Tx and Rx), the character will (hopefully) be received by the UART and then seen by the ECHO program. The ECHO program should add 1 to the accumulator value (thus moving on to the next ASCII character in the sequence) and loop around to retransmit the new character.

This will avoid any incompatibilities in the serial format between machines as the PDP-8 UART should be using the same clock and serial parameters (i.e. it is self-consistent).

I have something else to do at the moment - so I will get back to this after tea.

I was waiting for the printer - so I came up with this test program.

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.

Link the UART's RS232 transit line back to the receive line and also connect the transmit line to your PC.

Start the program at PC=0000.

The UART should transmit the ASCII <NUL> character (0x00) followed by 0x01, 0x02, ... up to 0xFF and then wrap-around to 0x00 again.

The process will stop if the character fails to be transmitted or a character is not received via the RS232 loopback connection.

This is a pretty good test to leave running for a while.

I can modify the test a little later (when it is running of course) to really thrash your PDP-8 / UART! With the UART being buffered - you can get different characters being transmitted and received at the same time...

Dave
 
Last edited:

Marty

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

Dave, Thank You for the New program..

I will try it in a minute, something came up, and so I have been busy..

"" What I am thinking is to turn my ECHO program around so that the PDP-8 sends a character to the UART, the UART transmits the character, the transmitted character is echoed back to the UART receiver (by a loopback connector between Tx and Rx), the character will (hopefully) be received by the UART and then seen by the ECHO program. The ECHO program should add 1 to the accumulator value (thus moving on to the next ASCII character in the sequence) and loop around to retransmit the new character.

This will avoid any incompatibilities in the serial format between machines as the PDP-8 UART should be using the same clock and serial parameters (i.e. it is self-consistent).

I have something else to do at the moment - so I will get back to this after tea.

I was waiting for the printer - so I came up with this test program.

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.

Link the UART's RS232 transit line back to the receive line and also connect the transmit line to your PC.

Start the program at PC=0000.

The UART should transmit the ASCII <NUL> character (0x00) followed by 0x01, 0x02, ... up to 0xFF and then wrap-around to 0x00 again.

It's almost working, but it is slightly strange..
I had to Load the Accumulator to get something useful, in it.. (0101)
But, it Might be the speed of my 8, as to why, for when I single step it, it changes slightly, in that it increments,
But, when running it goes through the correct sequence (I think), yet it goes from (in the Accumulator) 4101, to 4041, to 4100, 4101, to 4041, to 4100 and keep on repeating, If I single step it then the 4101 will become a 4102.. But, if I run it, it reverts back to the previous flow 4101, to 4041, to 4100..
It is putting out to the Terminal (PC) A!A! Etc..

The process will stop if the character fails to be transmitted or a character is not received via the RS232 loopback connection.
It is not stopping..

This is a pretty good test to leave running for a while.

I can modify the test a little later (when it is running of course) to really thrash your PDP-8 / UART! With the UART being buffered - you can get different characters being transmitted and received at the same time... ""

THANK YOU Marty
 
Last edited:

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
There's something not right there - but it will have to wait until tomorrow for me to have a look at it.

The accumulator shouldn't have any of the high bits set - as when we clear the keyboard flag (6036 KRB) - we should also clear the accumulator at the same time (RDA from figure 3 to additional logic driving CLA on figure 5).

The UART should only drive the least significant 8 data bits of AC - but what is the state of the other data bits driving AC I wonder? Floating?

Dave
 

Marty

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

Dave, Thank You for Your feedback..

"" There's something not right there - but it will have to wait until tomorrow for me to have a look at it.

The accumulator shouldn't have any of the high bits set - as when we clear the keyboard flag (6036 KRB) - we should also clear the accumulator at the same time (RDA from figure 3 to additional logic driving CLA on figure 5).

I think it is doing something like a Rotate.. Or Dancing between bit 0 and bit 11..

The UART should only drive the least significant 8 data bits of AC - but what is the state of the other data bits driving AC I wonder? Floating? ""
No, they are tied to Ground.. I just checked.. Bits 8-11.. O do I have them at the Wrong end, and they should be 0-3, tied to Ground ??

Also, I got in the 20 pin wire-wrap sockets and my 14 pin ID Wrap for the Microcoded 8..
 
Last edited:

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
Can you just try a simple program for me.

0000 6032 - Clear keyboard flag (should also clear the accumulator).
0001 7402 - Halt.

STOP CLEAR
AC=1234
PC=0000
CONT.

When the machine halts, the accumulator should have been cleared. This proves that resetting the keyboard flag also clears the accumulator.

Can you run this test at full speed please.

Dave
 

Marty

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

Dave, Thanks for the test..

"" Can you just try a simple program for me.

0000 6032 - Clear keyboard flag (should also clear the accumulator).
0001 7402 - Halt.

STOP CLEAR
AC=1234
PC=0000
CONT.

When the machine halts, the accumulator should have been cleared. This proves that resetting the keyboard flag also clears the accumulator.

Can you run this test at full speed please. ""

YES, it works as expected !!!! It clears the Accumulator..

THANK YOU Marty
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
That's good.

I just noticed you had updated a previous post...

UART transmit data is from AC11 (least significant bit) up to AC4 (most significant bit). Don't forget that D0 on the UART is the least significant bit = AC11!!!

UART receive data is similar - D0 on the UART is wired to AC11 and so forth to D7 on the UART is wired to AC4. AC0-3 should be '0'. For 'AC' here I really mean the I/O input of the MUX of course...

By the sounds of what you said - you have the UART receive bits wired to the wrong bits of the I/O input of the MUX. That may account for the fault you have found - the UART receive data is being read into the wrong bits of AC.

Dave
 

Marty

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

Dave, Thank You for the explanation, that IS exactly what I needed to know..

"" I just noticed you had updated a previous post...

UART transmit data is from AC11 (least significant bit) up to AC4 (most significant bit). Don't forget that D0 on the UART is the least significant bit = AC11!!!

I think I get confused on this..

UART receive data is similar - D0 on the UART is wired to AC11 and so forth to D7 on the UART is wired to AC4. AC0-3 should be '0'. For 'AC' here I really mean the I/O input of the MUX of course...

I think also this may be wired Wrong..

By the sounds of what you said - you have the UART receive bits wired to the wrong bits of the I/O input of the MUX. That may account for the fault you have found - the UART receive data is being read into the wrong bits of AC. ""

Exactly !!

I will check Both sides from the UART..

Yep, they were wired on the wrong end and wrong direction..

I was waiting for the printer - so I came up with this test program.

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.


The Program now runs, correctly..

THANK YOU Marty
 
Last edited:

MarsMan2020

Experienced Member
Joined
Dec 19, 2013
Messages
188
Location
Hawthorne, CA
Hi All;

Dave, Thank You for the explanation, that IS exactly what I needed to know..

"" I just noticed you had updated a previous post...

UART transmit data is from AC11 (least significant bit) up to AC4 (most significant bit). Don't forget that D0 on the UART is the least significant bit = AC11!!!

I think I get confused on this..

UART receive data is similar - D0 on the UART is wired to AC11 and so forth to D7 on the UART is wired to AC4. AC0-3 should be '0'. For 'AC' here I really mean the I/O input of the MUX of course...

I think also this may be wired Wrong..

By the sounds of what you said - you have the UART receive bits wired to the wrong bits of the I/O input of the MUX. That may account for the fault you have found - the UART receive data is being read into the wrong bits of AC. ""

Exactly !!

I will check Both sides from the UART..

THANK YOU Marty

I've been watching all of these threads with great interest - I just have one question.

When all this is said and done and debugged, is there a way to document it so that we could maybe create PCBs for people who are interested in building one?
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
Marty,

From re-reading post #385 I think you may have wired the transmitter half of the UART up correctly and the receiver half of the UART up incorrectly.

Setting AC to 0101 (octal) is the same as binary 000_001_000_001. Converting this into binary groups of 4 bits = 0000_0100_0001 = 0x041 which is the HEX code for a capital 'A' ASCII character.

By transmitting this character, looping back Tx to Rx and wiring up the receiver UART incorrectly I can vaguely see how you get the other values in the AC.

MarsMan2020,

Marty has a pretty good notebook he is keeping so I hope that will describe the heartache we are going through for the benefit of everyone else following in our footsteps... Thanks for your interest in our ramblings!

Dave
 

Marty

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

Dave and all, I am Glad to report it Now works ..

001.jpg

I have tried the Interrupt program, and it doesn't seem to work, so tomorrow I will look into that..

THANK YOU Marty
 
Last edited:

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
Thanks Jack - and a Happy New Year to everyone on VCF.

Marty,

Great news once again. More bugs squashed - but the odd one or two still lurking yet...

Still, if we can get to the point of getting the MAINDEC diagnostics to run we have a good chance of squashing them all!

So my loopback test program works OK (output from PDP-8, through an RS232 loopback connector and back to the PDP-8).

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.

STOP the PDP-8 from running - no more characters should echo on the PC when typed. CONTinue the PDP-8 program. Characters should echo on the PC when typed on the keyboard once again.

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

I can give you a few things to look at in the short-term (I will be out for most of the day today).

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

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

Dave
 
Last edited:

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,090
Location
UK - Worcester
Just a thought...

The early parts of the MAINDEC diagnostics don't use interrupts - so I would like to suggest that we try and get the RIM and BIN loaders to load maindec-8i-d01b (found at http://so-much-stuff.com/pdp8/software/maindec.php) from your PC. There is a PDF write-up of the test (including the assembler source) and the binary image.

First, however, I suggest you load the RIM loader and try and load a very simple PDP-8 program in RIM format from your PC. Let me try and locate one that is suitable.

Found one - hw.rim is a "Hello World" for the PDP-8...

The assembler source and list files are also included.

Start the program running by setting PC=0200.

The RIM loader (slow speed) can be found here http://homepage.cs.uiowa.edu/~jones/pdp8/refcard/74.html about half way down the page. This should (!) be compatible with your PDP-8 serial port. Deposit this program by hand into the PDP-8 memory and then start it running at PC=7756. The RIM loader is also described in Appendix 6 of "F-85_PDP-8_Users_Handbook_May66.pdf" along with how to load and operate it plus the RIM format for paper tapes (=the binary stored in your RIM files on the PC).

Dave
 

Attachments

  • hw.zip
    2.1 KB · Views: 2
Last edited:

Marty

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

Dave, Thank You for the next Installment..

I had made an earlier post, but somehow I lost it..

Dave, as per Your statement, I have put in a Temporary crystal for my Frequency to the UART and it is at a steady 4.80005 Khz..
I will wire it in later..

001.jpg

But, all of a sudden the Reverse Echo program fails..

I am going to look into things.. possible a stray wire or something like that..

I found the problem, I had forgotten to hook up the Loop-back connection..

It has at present a faster clock, and I will retry the echo program again, just in case..
No, it still fails, same place..

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

Here is a picture of the I/O Board, with all of it's latest gadgets..

002.jpg

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

I am starting a new posting.. Part 4...

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

THANK YOU Marty
 
Last edited:
Top