• Please review our updated Terms and Rules here

T11 clock running Forth

Pete,

I should probably be figuring this out on my own, but can you provide definitions of words that can write a stack value to the general purpose output pins and read a value from the general purpose input pins to the stack?

Lou (working on teaching myself Forth [old dog new tricks....])
 
Pete,
I should probably be figuring this out on my own, but can you provide definitions of words that can write a stack value to the general purpose output pins and read a value from the general purpose input pins to the stack?
Lou (working on teaching myself Forth [old dog new tricks....])

Sure, no problem. Here's the process:
In the schematic, the GPO chip select is "-OUT1CS".
OUT1CS is the 2nd 1K block of the upper 8K block.
So, the GPO is at address 162000(octal), which is 58368(10).
The Forth system defaults to base-10, unless you change it.
Similarly, the GPI address is 164000(octal) or 59392(10).

To read the input bits, you can do this:
59392 C@
To print the value immediately, add a period:
59392 C@ .
To write the output bits, do this:
<data> 58368 C!
If your desired data is already on top-of-stack, just this:
58368 C!
To do a read-then-write in one statement:
59392 C@ 58368 C!
The above line would basically copy the current state of the inputs to the outputs, as a byte-sized value.
To make a "word" of that, do this:
: INTOOUT 59392 C@ 58368 C! ; ////// note spaces at beginning and end!
Now, just typing INTOOUT will execute the statement.
Now try this:
: MAIN BEGIN INTOOUT AGAIN ; ////// endless loop
MAIN // execute MAIN
Now, the output bits will continuously reflect the state of the input bits. If you have the LED on bit 0, then diddling the bit-0 input will diddle the LED to match.
Since MAIN is an endless loop, you'll have to reset to get out of it.

Pete
 
From message #55:
Everything works, except for some weirdness related to the UART, but we found a workaround for that.

Not sure what the issue was, but it seems to me that connecting the 6850 'E' signal to COUT is tricky in combination with ANDing in /CAS in the address selection.
- According to the 6850 datasheet /CS must be low at least 80ns before the rising edge of E; E is what triggers data transfers inside the 6850
- The phase of COUT relative to /CAS is unpredictable, and may fall foul of timing constraints (or even have 2 rising edges with a single /CS)
Wouldn't using PI as the E signal be more safe/predictable?
 
We are making good progress on the clock, the hardware at least. I'm going to build it all on the breadboard first.

Here are the breadboard photos:
http://www.vintage-computer.com/vcforum/album.php?albumid=300&attachmentid=27064
http://www.vintage-computer.com/vcforum/album.php?albumid=300&attachmentid=27065

I have the six general purpose output bits going two places. For status indication, they go to a 74240 acting as a buffer driver for eight LEDs. AM/PM each have their own LEDs, but are driven by one bit and are mutually exclusive. Similarly I have date/time each with their own LED from one bit, also mutually exclusive. The others indicate a "setup" mode, alarm 1 active, alarm 2 active, and the last bit will eventually drive an alarm beeper, but is on an LED now.

The second place the six output bits go is to a 74125 binary to BCD. One 74125 can yield 7 bits of BCD. The low 4 bits drive one 7447, and the high three a second 7447. The low and high 7447s each drive all three high digits and low digits of two digit seven segment displays. The cathodes of each pair of displays can be strobed to make that pair active through a 2N3906. Obviously there is a pair of digits for hours(month), minutes(day), and seconds(year). Thank goodness there are six bits, so that we can count to at least 59 minutes, or 63 years. (Yes, this clock will have a problem in the year 2064. The six bits will only allow the years counter to count to [20]63. I will worry about this problem then, if I'm still alive.)

As Pete suggested, the IO3CS through IO6CS lines on J5 are used as strobes. One each for the status LEDs on the 74240 through the enable, and the pairs of digits through their 2N3906s. The IOxCS lines drive clock inputs of 7473s that are setup to toggle the Q or not Q outputs as approriate. Addressing 166000, 170000, 172000, or 174000 by doing a write generates a pulse on the associated IOxCS line, causing the associated JK flop to toggle and either light or extinguish that digit pair or the status LEDs.

So at any given time, the six general purpose output bits either have status info, or have the hour/month/minute/day/seconds/year value. I expect to be able to use persistence of vision to strobe fast enough so that a viewer can't tell that only one pair of digits or the status LEDs are truly lit at any instant in time.

For clock setting input, I have three pushbuttons debounced with 7414 schmitt trigger inverters to three of the four general purpose input bits. The fourth bit will be the 1 Hz signal from the RED60, which I have not installed yet, but it is next.

All of the above works properly. I have exercised it extensively in the immeadiate mode of the Forth interpreter.

I measured the current of all this stuff so far at 580mA. For the permanent power supply, I plan to use a small 6.3V center tapped transformer with two diodes, a 7805, and approriate input and output filtering. The RED60 will take the unrectified AC from the transformer secondary as input. The RED60 1Hz output will feed the fourth general purpose input bit. *** 10/9/15 edit - this is all now installed and tested : http://www.vintage-computer.com/vcforum/album.php?albumid=300&attachmentid=27082

The software should be simple, but it will be my first "practical" work in Forth. More to come.....

Lou

PS. a little trick I found to connect male breadboard jumper wires to male header pins was to use header jumper plugs. One port of the jumper plug goes on the header pin while the other port receives the breadboard jumper wire.
 
Last edited:
Very nice! I need to decide what to do with the last T11 board from the PCB build...
One thought is to make a tiny "switches and lights" panel for it. I guess the logic to support that might be more complex than the CPU board.

Pete
 
Pete,

I have another Forth question, perhaps specific to the implementation on your board. I have been studying the little bit of code that was much earlier in the thread for the simple version of the clock on your desk at work. I noticed that you used locations (octal) 378 through 388 as the ram area to store your working variables. In my implementation I will probably need a few more variables. My question is, what are the upper and lower boundaries of this memory space for variables? (I would not want to overwrite any of the rest of the Forth implementation.)

Thanks,
Lou
 
I noticed that you used locations (octal) 378 through 388 as the ram area to store your working variables. In my implementation I will probably need a few more variables. Lou
Hi,
The locations I used are 378 thru 388 DECIMAL, which is 572 to 604 OCTAL (note that this Forth defaults to decimal).
Starting at location 378 decimal, there are 34 contiguous words that can be used for anything.
In the LST listing, it is this:
96 000572 .BLKW 34.

Pete
 
Pete,

Excellent. That's lots of space.

Yes, I must look like an idiot typing 378 (octal). I do (usually) know better but must have been distracted, or as Dr. Charles pointed out to me in a PM, it could have been a lack of coffee (he is a doctor, he should know!) I will not however, default to my usual excuse of being a mechanical engineer. That wouldn't be enough in this case. ;)

Lou
 
Last edited:
I may have an idea for a project using the last T11 board:
- Another clock (of course), so that there is an excuse for running it 24/7.
- Add HW similar to a "switches and lights" panel, but probably just lights (no switches). Lights to show address and data bus, and a couple of control signals.
- Implement a clock display, with basic LED displays and such.
- Run the T11 clock super-slow, so that the lights are visibly changing as it runs code. Generate the clock from a 555 timer, and include a pot so that the speed can be changed on the fly.
- The accurate time base would be 1 Hz, using some appropriately weird and quirky technology.
- The Forth code could be the same as I already have, except for driving the displays.
- Maybe build everything on a proto board, similar to Lou's recent clock prototype.

What do we think?
Pete
 
- Run the T11 clock super-slow, so that the lights are visibly changing as it runs code. Generate the clock from a 555 timer, and include a pot so that the speed can be changed on the fly.

Interesting. I've always assumed that the T11 implementation wasn't fully static, and perhaps it isn't but just needs a minimum clock rate? How lo can it go ....
 
I think it's fully static. I did an experiment on my development system with a 555 running the clock at just a few Hz. It seems to work fine. But since the startup code needs to copy the entire EEPROM to RAM, it took many minutes to boot up.
So, maybe an idea is run from a fast clock on power-up, and then let the code toggle a GPIO to switch to the super-slow clock.
Pete
 
Interesting. I've always assumed that the T11 implementation wasn't fully static, and perhaps it isn't but just needs a minimum clock rate? How lo can it go ....

This is what the EK-DCT11-UG-003 manual says:

5.4.2 TTL Oscillator-Based Clock
Period T > 133 ns
Rise time tR < 80 ns
Fall time tF < 80 ns
Low time tL > 60 ns
High time tH > 60 ns

Refer to Figure 5-6. The XTL1 signal may be gated to stop operation of the DCT11-AA as long as the signal at the XTL1 pin meets or exceeds the above criteria. XTL1 may be left high or low indefinitely.


Figure 5-6 shows the TTL oscillator input to XTL1 being gated through an AND gate as a simple example of how the clock could be stopped by an external signal.
 
Hi, I haven't got around to do anything with the PCB and part kit that I bought from Pete. If anyone in UK would like to buy it the cost will be £30 including postage. That is what I paid Pete.
I will be selling most of my PDP stuff in the coming months as I don't have time to use/play with it.
I'll post on here before I put it up for sale.
Thanks, Paul.
 
I just breadboarded up a T11 system very similar to the T11 FORTH project discussed in this thread. I'm running into a problem - it doesn't seem to want to run. I have good Vcc, good clock signal going into the T11, but...nothing's happening. No clock on COUT, RAS and CAS aren't changing, and none of the lines are changing. I'e swapped out all the chips - no change. No doubt I've done something wrong.... I'm doing my usual trooubleshooting - reading the manual, checking connections, and pulling out my hair. Do you have any troubleshooting suggestions specific to the T11 that you learned designing the T11 FORTH clock?
 
Found the problem - a bad connection to ground on the T-11. No doubt along with causing lots of other problems, it kept PUP from being able to reach the right voltages to start the initialization sequence, so none of the post init signals were present.
 
Back
Top