Date   
Schematics for Todd's ELF-ish uploaded to the files area #ELF #Homebrew

taf123
 

Hi -

I've been asked to make the full schematics for Todd's ELF-ish available, so I have.

I've uploaded the PDFs to the new folder "Todd's ELF-ish Schematics", https://groups.io/g/cosmacelf/files/Todd%27s%20ELF-ish%20Schematics

I'll upload any updates as this project is still a Work in Progress.

Cheers,
Todd

Todd's ELF-ish gets some more more I/O #Homebrew #ELF

taf123
 

Hi 1800 fans -

This week, I finished adding the CDP1851 Programmable I/O Interface and the CDP1878 Dual Counter-Timer to the VIS board.  These have nothing to do with the Video Interface System, but there happened to be enough space for them on that board.

Both of these I put in I/O-mapped space.  Since each uses multiple N-line decodes, I used a dedicated I/O level for each, IO2 and IO3, respectively. These are used as CS and also control a 4016 to allow them access to the N-lines, as was done with the CDP1869 VIS.  If any of the N-lines are asserted while the 4016 is enabled, the CDP1857 I/O bus buffer shared with the VIS is activated.





The CDP1851 uses 2 of the N-lines together with the I/O level as CS.  Either Port A or Port B can generate an interrupt.  I tied them together and use a jumper to select either interrupt or !EFx polling.  Reading of the status register can determine which port issued the interrupt.

I present each port to a separate connector.  Since the default mode is input, I tied all of the lines to pull-up resistors.


The CDP1878 decodes all three N-lines, and I use the I/O level as CS.  The chip can generate an interrupt when either timer/counter expires, and again I use a jumper to select between interrupt and !EFx polling operation.

Each timer can use a separate clock input.  For Timer A, I use the CLK_OUT line from the CDP1879 Real-Time Clock, which can be programmed for one of 15 periods related to real-time.  For Timer B, I added a dedicated 1Mhz oscillator to allow it to time shorter duration events. (this is the maximum clock input frequency for the CDP1878).

Each clock can be controlled by an external gating signal or controlled by software.  Also, each timer can generate an output, and an inverted output.  These I bring to a 10-pin connector, together with the RTC CLK_OUT signal.



Here's they are all wired up.



The I/O pins on the CDP1851 are on the wrong side of the chip considering where I have the port connectors, so I mounted it upside down compared to the other chips.
It does mean that Port B is the top port, instead of Port A as one would normally want. But, it made wiring a lot easier, so there


And top view.  The VIS board is now completely populated.



Ready for testing - I'm going to have to get a bigger house soon...



For testing the CDP1851 Programmable I/O, I used the same test bed as I previously used for the Byte I/O CDP1852 ports on the expansion chassis.  Since the CDP1851 is programmable, I set Port B to be input and Port A to be output, to support the same test.  I just had to modify the code to properly initialize the CDP1851 and to use the correct two-level I/O codes to access these ports.

This pictures shows that the test was successful. You'll have to take my word for it that I had just pressed the 9 button.



Or, you can watch the exciting video, attached.

Of course the CDP1851 supports more complicated configurations, but tests for those will have to wait.

For testing the CDP1878 Dual-Timer, I modified the above test by adding a 10 second delay between when the button is pressed and when the display is updated. Instead of using a delay loop, this is using the Timer A from the CDP1878 Dual 16-bit timer. In this demo, Timer A is driven by the programmable clock out from the CDP1879 Real-Time Clock, which I've set for a period on 500ms.

My not very scientific timing showed the delay was not quite 10 seconds, so I have some further investigations. But this test verified to basic functionality.

Video also attached.

Socket - Grrrr!

John
 

For some time I've been seeing strange behaviour in Mar1e. Quite often a program would crash. I'd look through the contents of the lithium-backed RAM and it would have changed, but then it would change back again. As the chip is 25 years old I thought maybe this was to be expected.

I checked the wiring side under a microscope. I stroked every pin with my fingers. I couldn't provoke bad behaviour. Then last night I tried tapping the boards, and the problem appeared. I lifted and re-seated every chip. I finally traced the problem to the RAM chip socket. One or more of the pins wasn't making proper contact. After bending all the pins of the chip inward slightly the problem disappeared.

I don't know what kind of ill-treatment the socket might have suffered in the past; maybe it was used for something with thicker pins. Anyway, for now Mar1e is behaving herself and I can get back to learning to speak her language.

John, Nottingham

Re: Standard cassette interface for the Elf?

John
 

Thanks Chuck,

I'm hoping to have some "quiet time" this weekend so I'll browse through as many of the Ipso Factos as I can. 

I'll also have a look at free sound recording software (because I'm a miser). 

John, Nottingham

On Thu, 16 May 2019 at 19:11, cmdrcosmac <cmdrcosmac@...> wrote:
John,
There are many articles in Ipso Facto describing hardware and software for the Kansas City
scheme. Also note that you don't need a cassette recorder. You can use the PC's sound I/O.
Some audio recording programs have a "scope display" you can use to set the levels with.
-Chuck

Re: Standard cassette interface for the Elf?

cmdrcosmac
 

John,
There are many articles in Ipso Facto describing hardware and software for the Kansas City
scheme. Also note that you don't need a cassette recorder. You can use the PC's sound I/O.
Some audio recording programs have a "scope display" you can use to set the levels with.
-Chuck

Re: Standard cassette interface for the Elf?

John
 

Thanks to all for the replies. Maybe I don't want to use cassettes when I can have a terminal program like Tera Term (or Termite or PuTTY) to do the saving and loading, but there's something nice and nostalgic about that warble, however it's generated and modulated. I still have cassette deck for audio, and old computer cassette deck from the early 80s and a couple of Walkmans (Walkmen?) one of which was quite fluttery last time I tried it.

I've heard of the Kansas City standard, and I'll probably try that first. 

Thanks again,

John (and Mar1e)

On Wed, 15 May 2019 at 04:29, cmdrcosmac <cmdrcosmac@...> wrote:
John,

I went thru this dilemma when I designed my system. I run the IDIOT monitor, which is very similar to UT4.
I use Tera Term, a terminal emulator that can save a session to a file, and can send a text file "naked"
that is, with no protocol like XMODEM. You will want a feature that allows you to set a delay between characters.
 You use the menu to send file..., select a text file, and TeraTerm sends it. There are other term programs
like this. So I use the ?M command for the RAM area to save, and  save the session. Then I edit the save file
to keep only the RAM dump. To Load, I give IDIOT the !M, then tell TeraTerm to send the file.
Works perfectly. This is how RCA intended UT4 to save files, except that the terminal would punch a tape.
-Chuck   

Re: Mar1e the Elf now has an EPROM!

taf123
 

Looking good!

Cheers,
Todd

Re: Mar1e the Elf now has an EPROM!

John
 

Hi Todd and the group,

I made progress last night, some of it being backwards!

I still couldn't find a 74HC32 but I did find a 4071 which does the same job. I wired the second part of the 74HC139 to select one or other of the DL1414s so they now appear as a block of write-only RAM at 4000 to 4007. I made several changes before testing and it didn't work at first, so I reversed the mods and added them one at a time. Then it worked. I can write eight ASCII characters to the display. The 4071 gates are to AND the active low select outputs from the 139 with the active low write output from the 1802.

I'll attach a picture of Mar1e's greeting to Todd. The grey tinted window should be a bit wider as there are reflections from the edges. I have some red tinted acrylic somewhere, which would be better.

Best regards,

John

On Tue, 14 May 2019 at 19:31, taf123 <todd.ferguson@...> wrote:
Hi John -

Nothing better than that feeling of having started from just an idea, to design, implementation and having it work as intended.

Congrats.  When you get moment, some pics or a quick vid would be cool.

Cheers,
Todd

Re: Standard cassette interface for the Elf?

cmdrcosmac
 

John,

I went thru this dilemma when I designed my system. I run the IDIOT monitor, which is very similar to UT4.
I use Tera Term, a terminal emulator that can save a session to a file, and can send a text file "naked"
that is, with no protocol like XMODEM. You will want a feature that allows you to set a delay between characters.
 You use the menu to send file..., select a text file, and TeraTerm sends it. There are other term programs
like this. So I use the ?M command for the RAM area to save, and  save the session. Then I edit the save file
to keep only the RAM dump. To Load, I give IDIOT the !M, then tell TeraTerm to send the file.
Works perfectly. This is how RCA intended UT4 to save files, except that the terminal would punch a tape.
-Chuck   

Re: Standard cassette interface for the Elf?

taf123
 

Hi -

That's right - it used 1 cycle of 2000 Hz for a 0 and 1 cycle of 800 Hz for a 1.  I remember it worked well for back in the day, but I didn't exchange VIP tapes with other users at the time, so I don't know how robust the solution was for tape machine variations.

RCA published an application note on this as ICAN-6934, "Cassette Tape I/O For COSMAC Microprocessor Systems".

It includes a hex dump of the I/O routines for a system using their UT4 serial utility.  I've not tried this, but since I built one of these little boards for the VIP mode of Todd's ELF-ish, I'll have to give this a whirl.

See attached.

Re: Standard cassette interface for the Elf?

Raymond Sills
 

HI John:

In addition to the Kansas City format, there is the VIP format.  IIRC, the VIP used frequencies of 2000 Hz and 800 Hz.   As you would expect, the Q line and one of the EF lines were used for output and input, with encoding and decoding done in software.  The VIP had only a 512 byte "operating system", so the routines for encode and decode had to have been fairly compact.   When you would save or load data, you also would tell the OS how many 256 byte "pages" to save or load.

It was a fairly robust format, and tolerant of cassette machine wow and flutter.

73 de Ray



-----Original Message-----
From: John <easydogxray@...>
To: cosmacelf <cosmacelf@groups.io>
Sent: Tue, May 14, 2019 10:34 am
Subject: [cosmacelf] Standard cassette interface for the Elf?

Hi All,

No doubt many different cassette interfaces have been tried over the decades. Is there one particular recording format and circuit that's floated to the top and become most widely used? I want to add a cassette interface to Mar1e before long, time is precious and I don't want to waste any of it going down wrong routes. I'm not after great speed, just a reliable way of storing programs.

Thanks in anticipation,

John, Nottingham

Re: Mar1e the Elf now has an EPROM!

taf123
 

Hi John -

Nothing better than that feeling of having started from just an idea, to design, implementation and having it work as intended.

Congrats.  When you get moment, some pics or a quick vid would be cool.

Cheers,
Todd

Re: Standard cassette interface for the Elf?

ajparent1/kb1gmx
 

The most common format was one called Kansas city which was redundant FM
(8cycles of 2400 and 4cycles of 1200, memory test) at a bit rate of 300 baud.

Cosmacs used several different formats, most were similar using the
Q and an EF-line for the encode and decode.  Most of the work was done
in software and the cassette recorder to ELF or similar was fairly trivial.   
Some included a IO port to control the cassette machines motor and there
were cases where one was used for Play only and the other for Record
only, so work could be done to say assemble an input file and record the
output file.

check the files section for monitors that used tape formats.

Allison

Standard cassette interface for the Elf?

John
 

Hi All,

No doubt many different cassette interfaces have been tried over the decades. Is there one particular recording format and circuit that's floated to the top and become most widely used? I want to add a cassette interface to Mar1e before long, time is precious and I don't want to waste any of it going down wrong routes. I'm not after great speed, just a reliable way of storing programs.

Thanks in anticipation,

John, Nottingham

Re: Mar1e the Elf now has an EPROM!

John
 

Hi Todd,

11:08 PM and I'm about to call it a night. I have two DL1414s connected now giving me eight equi-spaced characters. They have "bubble" lenses like the old LED calculator displays, but instead of being 7 segment they are 16 segment, sometimes called starburst or even "English flag" (should be British flag) so they can display all the characters from ASCII 20 to ASCII 5F. I have some HP DLR1414s somewhere (only one within reach) and they have a 5x7 dot matrix rather than line segments. They can display 256 characters including lower case, letters with accents and a few more punctuation marks.

I couldn't find an HC32 to allow me to AND the block select from the 139 and the !MWR from the 1802 to generate a !WR for the display so I've used 2/3 of a 4025. The address lines A0 and A1 (I buffered them unnecessarily) go to both DL1414s for digit select within the devices. One appears at 4000 to 4003 and the other will appear at C000 to C003 when I can find a '32. For now I've wired my !WR signal to both displays so one duplicates the other. I wrote some code to display J, O, H, N, each letter appearing after pressing IN. One more press clears the display and the whole thing repeats. 

I go to bed feeling very happy, despite losing an Ebay auction this evening for an OK Hobby battery wire wrap tool. I put in a bid of £12 in the last few seconds. It sold for £12.50. Back to my trusty wire-wrap pencil!

John, Nottingham

On Mon, 13 May 2019 at 21:49, taf123 <todd.ferguson@...> wrote:
Hi John -

Thanks!

You're doing some interesting and original stuff here, so keep at it!

Those DL1414's look cool.  From the data sheet, they are CMOS, so you should be able to connect directly to the address and data bus without any problems.

Looking forward to seeing them in operation.

Cheers,
Todd

Re: Mar1e the Elf now has an EPROM!

taf123
 

Hi John -

Thanks!

You're doing some interesting and original stuff here, so keep at it!

Those DL1414's look cool.  From the data sheet, they are CMOS, so you should be able to connect directly to the address and data bus without any problems.

Looking forward to seeing them in operation.

Cheers,
Todd

Re: Todd's ELF-ish gets some more Memory #Homebrew #ELF

taf123
 

Hi Terry -

On Sat, May 11, 2019 at 09:49 PM, Terry Gray wrote:
It would appear that at the rate you are adding functionality and the fact that you aren's stacking the boards that you may have to add a room to your house just for your Elf! 
It'll soon be a problem, I'm sure ;-)

Way back in the 70's I used to wirewrap like that...found it very cathartic.  Need to see if I still have the patience.

My previous wire-wrap was at uni back in the late '80s.  I'll never know how I managed to use one of those pencil tools back then, but this project was almost a non-starter when I began with one of those.

Finding that used electric wrapping gun on eBay is at least 75% responsible for the sprawl - can't imagine having got this far otherwise.

Cheers,
Todd

Re: Todd's ELF-ish gets gets a Video Interface System (VIS) #ELF #Homebrew

taf123
 

Yep, I'm putting this down as "good enough, all things considered".

Besides, the wire-wrap approach sort of wipes out "good layout practices" one would expect to see on a PCB - who knows what's going on with strays.

So long as the scan converter is happy with what the VIS spits out, the Todd is happy.

Thanks for all of the explanation and advice on this black-magic subject.

Cheers,
Todd

Re: Todd's ELF-ish gets gets a Video Interface System (VIS) #ELF #Homebrew

Lee Hart
 

taf123 wrote:
Hi Lee -

Thanks for the right up about crystal oscillators. I don't know very
much (anything?) about this topic, so I looked around for application
notes, etc, to help me out here...

Intel's AP-155, "Oscillators for Microcontrollers" has a big discussion
about the built-in oscillators in their MCS-48 and MCS-51 MCU families.
"Logic gates tend to have a fairly low output resistance,
which destabilizes the oscillator. For that reason a resistor
Rx is often added to the feedback network... At higher frequencies a
20 or 30 pF capacitor is sometimes used in the Rx position, to compensate
for some of the internal propagation delay...
I think that's good advice; but old. The internal inverters weren't all that fast back then. I suspect they needed the capacitor in the Rx position because the inverter was barely fast enough, and needed help.

But today's 74HC is an order of magnitude faster. A 74HC04 has a propagation delay of only 7-8 nsec, or about 75 MHz. 11 MHz is "slow" in comparison. :-)

I know this is a "just try it and see approach" which would make my old
engineering professors turn to drink, but seems to be okay.
All you need is for *one* to work. And, you don't care if the oscillator is pulled somewhat off frequency by a less-than-ideal design. So go for it! :-)

--
Fools ignore complexity. Pragmatists suffer it. The wise avoid it.
Geniuses remove it. -- Alan Perlis, "Epigrams on Programming"
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Mar1e the Elf now has an EPROM!

John
 

I hardly dare post my humble efforts in the same forum as Todd's, but here goes...

I've typed UT4 into a 2732 and wired Mar1e's second 24 pin socket for the EPROM. A 74HC139 selects the 6116 at 0000 and the 2732 at 8000. The other outputs for 4000 and C000 aren't used yet (but see below).

I've written a simple program to point R4 at 8000, make R4 the data pointer and wait for IN to be pressed and released, then output the contents pointed to by the DP to the hex display, go back and wait for the next press. I watched almost with disbelief as the bytes of UT4 came up one after another. 

Next job is to reinstate the serial port (disconnected during the mods) and see if it will talk to the Psion Organiser. 

I haven't fitted, or even wired the sockets for, the DL1414 displays yet. I'm thinking of memory-mapping these; one chip select going to each of the 4000 and C000 select outputs of the 74HC139 and the two address lines going to the address bus. Allocating a whole 16k block to a device with four memory locations, one for each character, might be a bit wasteful but if it works I'll be happy. I don't know yet whether the address bus can drive the inputs so I might wire them all low and just use one character to prove the rest of the circuit, that being the 139 to !CE and the buffered data bus to the data inputs. 

Todd, I am in awe. 

John, Nottingham