Date   
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

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

taf123
 

Now that we're oscillating, and working in both Character Generator and Bit-Map modes, it's time to turn our attention to the keyboard input.

I do have a couple of the CDP1971 Keyboard Encoders that the original VIS design uses, but I don't really feel like building a custom keyboard at this time - although that may be an interesting side project some time.

So I looked over the shoulder of the student next to me, and stole their approach ;-)

In this case, I "borrowed" the AT89C2051 MCU based PS/2 keyboard to byte-parallel ASCII used on their GPIO board.  But instead of using their PLD-based interface circuit, I decided to just go with a CDP1852 byte-I/O in input mode - the built-in CLOCK / !SR action being used for the necessary hand-shaking.

ICAN-7032 shows connecting a parallel encoded keyboard to the VIS using a CDP1852, using the CDP1869 decoded !N=3 line, inverted, as the CDP1852 CS2.  The VIS Demo Board illustrated in the Design Ideas Book also uses this approach.

Sounds likes a good way forward. Note that the signal from the MCU to indicate data ready, what the ELF2k GPIO schematic calls SET_KEY_DATA_RDY_L, and I call !KB_STB, is active LO, but the CDP1852 requires a HI clock pulse, so I just invert this.

Here's the schematic.



Again I included a jumper to select between !EFx polling and interrupt operation.

Here's the completed wiring, with the '2051 as U15 in the upper middle with support components, and the CDP1852 below that as U16, and a 4-pin Molex connector for the PS/2 keyboard connector.



My Wellon VP598 programmer supports the AT89C2051 MCU's, plus a host of others.  It was a good purchase - would recommend one if you need a universal programmer.



Thanks again to the STG people for supplying the Intel HEX dump so I could flash my own.

I also added the 4-pin Molex connector for the '2051 UART debug output, although the supplied HEX dump didn't have debug enabled.



And ready for testing.



Although I forgot to take a pic of connecting the 16-channel logic analyzer to the AT89C2051 MCU, and matching CDP1852 byte-input port, I did save the data.

This shot verifies that I have the PS/2 keyboard connector wired correctly.

No photo description available.

According to the standard, after the keyboard powers on, it does a BAT (Basic Assurance Test).

When it finishes, it signals success by sending 0xAA.

Channel 1 is the clock from the keyboard, channel 2 is the serial data. Reading at each clock low, you have 1 start, 8 data bits, parity, and 1 stop bit.

Result = 0xAA, successful BAT.

This shot shows the MCU actions just as it comes out of RESET.

No photo description available.


Channel 5 looks like the RESET line (active HI).

Channel 4 is the active LO strobe line which the '2051 uses to signal to the input port that data is ready.

Channel 3 is '2051 pin 9, which lights the LED when there is data waiting (active LO)

And channels 8-15 are the data lines.  According to the provided source code, the '2051 outputs three bytes right out of RESET as part of the initialization.

PUBLIC void ConvertKeys (void){
  BYTE bKey;  BOOL fRelease;
  m_bKeyFlags = 0;
  SendHost('K' | 0x80);  SendHost ('B');  SendHost(VERSION);
  DBGOUT(("ConvertKeys() initialized ...\n"));
    ...

The data lines decode to 0xCB, which is ('K' | 0x80), so it's working.  Cool!

Here's a quick and dirty test of the PS/2 keyboard interface, using the UT4 serial interface for output.



After downloading the code (the first 2 lines), the "$P00" runs it.

Of the three bytes the '2051 sent after coming out of reset, only the 'B' is printed - the version is an unprintable character so only a space shows, but what happened to the ('K' | 0x80)?  I would expect that at least a space would have been printed before the 'B'.  Something for further investigation...

After that, the program reads any data from the input port (PS/2 keys mapped to ASCII) and prints to the serial port.

I typed "Hello World!!!!", which was correctly displayed.

Yay.

After further investigation, I found the missing K.

The CDP1852 data sheet warns about using the same N decode for a CDP1852 in input while it is also used with an output device:

"In a CDP1800 series microprocessor-based system where
!MRD is used to distinguish between INP and OUT
instructions, an lNP instruction is assumed to occur at the
beginning of every I/O cycle because !MRD starts high.
Therefore, at the start of an OUT instruction, which uses the
same 3-bit N code as that used for selection of an input port,
the input device is selected for a short time (see Figure 8).



This condition forces SR low and sets the internal SR latch.
In a small system with unique N codes for
inputs and outputs, this situation does not arise. Using the
CDP1853 N-bit decoder or equivalent logic to decode the N
lines after TPA prevents dual selection in larger systems."

This is why I normally use the CDP1853 for my N-line decoding.

The CDP1869 decodes the N-lines internally, and has access to TPA and TPB, so I had assumed they would have taken this into account.  Of course, the CDP1869 and 1870/76 only use OUT instructions, so they must have left this out.

That little code snippet for my PS/2 test also included the basic VIS initialization, including the OUT 3 required to configure the CDP1876.

When the OUT 3 happens, the CDP1852 sees this spurious "read" condition and resets it's SR line.  This signals to the '2051 that the character has been read, so it sends the next one, the 'B', which overwrites the 'K', so my code never sees it.

Just being a little pedantic about the potential for losing a character if the code ever changes the format of the VIS using an OUT 3, plus wanting to match for the '2051 start up characters in my code to verify that it has initialized correctly, I decided to fix this by adding a CDP1853 to decode the N=3 for the CDP1852.

Since I had to do some rewiring anyways, I started a little side project to recompile the '2051 code so the strobe to the CDP1852 would be active HI and I could remove the inverter.  Plus, I wanted to support a UK keyboard layout.

That little side project is detailed in the thread "Recompiling the ELF 2000 PS/2 AT89C2051 SW", https://groups.io/g/cosmacelf/topic/recompiling_the_elf_2000_ps_2/31262983, which was my first posting to this forum.

See that thread for details.

Here's the updated schematic



Fortunately, the board layout has a space open right in the upper middle where I could insert the CDP1853.



And this all worked as planned.  So now I can reliably read the initialization codes from the '2051, I saved an inverter, and my UK keyboard is properly supported.

I just need to modify the VIS demo to use the PS/2 keyboard instead of the UT4 serial interface.

Now we are caught up with the current state of the ELF-ish build.

Further updates as the project progresses.


Hope you have enjoyed it so far.  More to come.

Todd

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

taf123
 

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.

There is the Harris AN6565.1 "Design of Clock Generators for Use with COSMAC Microprocessor CDP1802", but it's discussion of external oscillators is limited to low frequency (<500kHz) using RC timing.

I then found Intel's AP-155, "Oscillators for Microcontrollers" which has a big discussion about the built-in oscillators in their MCS-48 and MCS-51 MCU families.  A very interesting read actually.

It has a small blurb about the type of the external oscillator we're looking at here.


But all it has to say on the subject is:

"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, as
shown in Figure 11 A and B. 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.
Reference 1 contains an excellent discussion of gate
oscillators, and a number of design examples."

The reference is "Crystal Oscillator Design and Temperature Compensation" by Marvin E. Frerking.

A quick web search found a PDF of the book.  It is filled with the kind of mathematics I haven't looked at in several decades.  Phew.

But section 7.6 covers Gate Oscillators, which starts out with basically the same picture:




He gives the design work for a 200kHz oscillator.  I remember that I used to know this kind of maths, but anyways...

He then says:

"At higher frequencies, above approximately 1MHz, the circuit of Fig 7-23 is not entirely satisfactory because of lagging phase shift in the gate, and it is necessary to replace resistor R2 with a capacitor C3, as shown in Fig 7-25"



He wrote this back in '78, so didn't have access to the 74HC series, so he says, "For frequencies higher than a few MHz, it is necessary to use TTL gates for satisfactory operation".  And shows the following 20Mhz oscillator design.




I figured I could use the CMOS design with the higher speed 74HC04 gates at the 11.3 Mhz, rather than going to the TTL design, which is why I simply changed that R out with the C33 of 39pF in my updated circuit.

And it seems to work.

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.

I'll let you know if I end up with any stability issues with this over time.  I can always go back to the can oscillator which was "close enough" if I need to.

Cheers,
Todd

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

taf123
 


Incidentally Todd, how'd you manage all of that with a bored domestic
beside you? (Think of Hobbes and you're there.)
I too am flabbergasted at how fast Todd's project is progressing. My
spouse would never let me get away with that!
Just to be clear, the stuff I've been posting over the past few days covers pictures I've taken of my build project over at least 1.5 years.  Someone asked to see pictures and the flood gates opened ;-)

We're almost caught up to the current build state.

But yes, spot the single guy ;-)

Cheers,
Todd

Re: Todd's ELF-ish #ELF

taf123
 

Hi -

I noticed that the schematic snippet of how I wired the data switches didn't come out in me previous post, so here it is.  The key is that the switches aren't wired to +5, instead they float when switched to the 1 position, relying upon the data bus pull-up resisters to bring the lines HI.

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

bill rowe
 

Todd: Your brilliant build keeps reminding me of my 40 year old homebrew elf - just the form factor and sprawl, not the design or execution!



From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of taf123 <todd.ferguson@...>
Sent: May 11, 2019 7:48 PM
To: cosmacelf@groups.io
Subject: Re: [cosmacelf] Todd's ELF-ish gets gets a Video Interface System (VIS) #ELF #Homebrew
 

[Edited Message Follows]

Now that the VIS is built and it has a decent clock (hopefully close enough), it's time to test.



The VIS isn't tied to the system !CLEAR, so it comes up in a random state. In this case, in the low-res 12 x 20 display.  But since both pmem and cmem are implemented in RAM, the screen was just random garbage.



But random garbage showing that the VIS was working!

Who's the Happy Todd?!?

My first test program simply tells the VIS to switch to its hi-res mode of 24 rows of 40 characters each.

It's still random garbage, but now it's hi-res random garbage.



Yay!!!

I then started loading the demo program from the ICAN.  Here's another quick test.



Things are getting exciting!!!

--
Bill Rowe
Olduino - an arduino for the first of us
https://olduino.wordpress.com/about-2/about/

Re: 30 AWG wire wrap stripper

 

A bit late to reply, but just to chime in, Ideal makes some nice wire strippers.  I like the Reflex T-stripper.  Mine goes from 22-32 Ga.  This one goes from 20-30 Ga.  For lengths longer than an  inch or so, I like the Stripmaster, but for 30 Ga, ususally reach for the Reflex T-stripper.

BTW, when I was a kid I did plenty of point-to-point projects with 30 Ga wire wrap wire, and my go-to stripping tool for 30 Ga wire-wrap wire was a fingernail clipper.  I created a little nick in the cutting surfaces by clamping down on a needle to approximate a 30 Ga diameter.  Cheap, worked great, and also handy as a flush cutter.  In a pinch, teeth work pretty well also.

Dave

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

Lee Hart
 

Gregg Levine wrote:
In my case, I happen to like the entire site.
And I actually bumped into someone wearing a 6502 badge at this years
VCF East show.
Hey, that's pretty cool! BTW, we're working on a new 6502 Badge for this year's VCFMW in Sept 2019. There is a preview of it at <http://sunrise-ev.com/6502.htm> near the bottom of the page. :-)

However,,, IMHO Lee I believe you are right regarding homebuilt EV
designs and this country.
Sad; but true. The problem of "nobody wants to build anything" is common in many parts of the hobby world. It's so darn easy to just buy it all...

Incidentally Todd, how'd you manage all of that with a bored domestic
beside you? (Think of Hobbes and you're there.)
I too am flabbergasted at how fast Todd's project is progressing. My spouse would never let me get away with that!

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

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

Lee Hart
 

taf123 wrote:
In the mean-time, the much awaited 11.3258Mhz crystal arrived.

Anyways, this oscillator didn't work. I copied it from the RTC circuit,
which only used a 32kHz crystal. Turns out, this same design can be
used at higher frequencies, but the load 220k load resister (the blue
one tucked next to the crystal) actually needs to be a capacitor to
compensate for the phase shift of the inverter at speed.

Updated it to 39pF and it oscillated just fine.
Hi Todd,

Here's the deal on the oscillator: Crystals are mechanical resonators, like a bell or guitar string. A mechanical resonator has more than one resonant frequency; its fundamental (X1), and all the odd harmonics (X3, X5, X7...)

The 32 KHz crystal will therefore happily oscillate at 32x3=96 KHz, 160 KHz, 224 KHz etc.

The inverter obviously has lots of gain at these frequencies, too. If the oscillator "starts on the wrong foot", it can lock in on one of these harmonics -- not what is desired! This can happen if there is a noise glitch on the input, or the power supply voltage rises too sharply, or some physical bump makes the crystal "ring", etc.

So, the 220K resistor (at location C33) was added. The 220K and 39pF (at location C30) form an RC filter that rolls off the inverter's gain at higher frequencies. 220k x 39pf = 8.5 usec = 116 KHz. That way, it only has enough gain to oscillate at the fundamental; 32 KHz.

Now replace the 32 KHz crystal with your 11.3 MHz. There's no gain at that frequency, so it won't oscillate! You have to substantially reduce the value of that 220k to roll off the frequency above the 3rd harmonic. That would be 11.3 x 3 = 33.9 MHz. With the 39pf, the resistor has to be 2.2k.

In fact, the gain of a 74HC04 inverter is falling off anyway at this frequency. And, it already has several hundred ohms of internal resistance in its output. So an even lower value will work (like 1k or 1.5k).

What will a capacitor at C33 do? It will actually *increase* the high-frequency gain of the inverter. That's not what you want; it increases the chance of oscillating at some harmonic. Then the only thing stopping it would be if the inverter itself does not have enough gain to oscillate at 33.9 MHz or more.

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

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

Gregg Levine
 

Hello!
In my case, I happen to like the entire site.
And I actually bumped into someone wearing a 6502 badge at this years
VCF East show.

However,,, IMHO Lee I believe you are right regarding homebuilt EV
designs and this country.

Incidentally Todd, how'd you manage all of that with a bored domestic
beside you? (Think of Hobbes and you're there.)
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Sat, May 11, 2019 at 9:31 PM taf123 <todd.ferguson@...> wrote:

On Sat, May 11, 2019 at 03:35 PM, Lee Hart wrote:

www.sunrise-ev.com

P.S. - I love the VIP2k from your website...

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

taf123
 

On Sat, May 11, 2019 at 03:35 PM, Lee Hart wrote:
www.sunrise-ev.com
P.S. - I love the VIP2k from your website...

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

taf123
 

On Sat, May 11, 2019 at 03:35 PM, Lee Hart wrote:
taf123 wrote:
Although I've never seen RCA 89052 anywhere, the RCA manual for this
Microboard says that the replacement part is the MWS5114. Looking at
the supplied schematic, the chips are pin-compatible. The 5114
obviously has one more address-line, but that pin is tied LO on this
board, so the 5114 would just function like a 512 x 4-bit memory.
I suspect that the 89052's were MW5114's that had a bad bit. Rather than
throw them out (RAMs were expensive back then!), they used them as
512-byte RAMs.
That makes a lot of sense - I wouldn't be at all surprised.

I hope to attempt a repair of this board in the near future - updates to
this forum when that happens.
I have a tube of RCA MW5114's if you (or others) need any. I also have a
couple tubes of 5101's (some RCA, some NEC). :-)
Thanks for the offer, but as I wrote that up, I did an eBay search for some more MWS5114's and already placed an order.

Bad timing ;-)  Sometimes, this Internet thing can be too efficient.

Best regards,
Todd

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

taf123
 

Hi again Chuck -

On Sat, May 11, 2019 at 11:58 AM, cmdrcosmac wrote:
>> It's one of the reasons I put battery backup on all of the memory - so I don't have to reload the programs.

Note that a common bug when programming is a runaway stack, wherein the INC STACK and DEC STACK's aren't balanced.
This causes a stack crawl and may overwrite the program. Time to reload. I have an EEPROM to save stuff in.
The Elf and IDIOT's !M load routine is slow enough that the chip's byte write mode works just like RAM. I then
disable write with a jumper and block-move the code into RAM.
That's a great idea - will work that into the sprawl.

>> And it should not be hard to patch UT4 to use the UART.
 Since you have the UART, that's probably the easiest. But keep the Q/EF wiring in place as most 1802 software uses
bit-banged serial I/O.
Good point.  There's no reason for me to remove any of that.

 As for Monitors, most folks appear to be using UT4, IDIOT, Chuck Yakym's MCSMP, or ELF2K. The first 3 have similar
functions. ELF2K supports a disk operating system that can run on CF card "disks". MCSMP loads and saves I8hex files.
IDIOT and UT4 use RCA's !M format. MCSMP will run 9600 Baud at a CPU clock of 1.8 MHz. I use IDIOT, and an assembler that
creates RCA-compatible list files that IDIOT (or UT4) can load. IDIOT is run-time relocatable, and will find RAM to
save the registers. UT4 needs to be assembled with a RAM location coded in. UT4 supports JAM_8000 RUN_U, IDIOT does not.
 I am redesigning my Elf expander to locate IDIOT at F800, an EEPROM at 8000 or C000, and the rest RAM. RUN_U will use
the scheme in Ipso Facto.
Thanks for the monitor comparison.  I need to spend some quality time looking over the options.  I'll probably borrow from everything and cobble something together.

I really want to be able to load the Intel HEX dump fromat from the assembler directly, rather than having to use the UT4 !M interface for that.

 I like the labels on the underside of the chip sockets. How are these done??
I'm using the plastic Wrap-ID's where I could get them.  But they are expensive nowadays, so I won't be buying more.



The paper ones are just done up in Inkscape, and then stuck in place with a piece of two-sided tape - I have a roll of very narrow tape for this.

This is just a by-product of my layouts.  I design a full detail layout in Inkscape, and then also flip it over (reversing all of the text again) so I have both a TOP and a BOTTOM view.

For example, from the VIS build:





Printing an extra copy of the bottom view gives me the labels to cut out.


>>  My design approach has been to use as many of the CDP1800 series as I could source
>> - and I managed to get just about the complete set.

Where did you get the 1863 frequency divider??
Just did a search on eBay and it popped up from someone in China.  He seems to still have some available.  They are used though, but mine worked fine.

Please tell us more about the Logic Analyzer!
Just like you can get very cheap scan converters today, you can get very check logic analyzers.  They are built using a little MCU development board, but with Logic Analyzer FW added.

This one I found on amazon.co.uk (I'm in the UK) from Hobby Components Ltd for about £16 (~ $20). 

https://www.amazon.co.uk/dp/B06Y2C3XVH/ref=pe_3187911_189395841_TE_3p_dp_1

The board is basically just and interface card - all of the processing happens on the laptop using the open source package sigrok.

https://sigrok.org/

Nothing fancy, but get's the job done and cheaply.

Cheers,
Todd

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

taf123
 

Hi Lee -

On Sat, May 11, 2019 at 11:12 AM, Lee Hart wrote:
That's a pretty powerful chip; both in calculating and in power
consumption. :-) It will take some work to adapt something like BASIC or
FORTH to use it for its math routines.
Yep, I'll have to figure out how to interact with it properly.  I'm slower at looking into the SW compared to the ever expanding HW.

There is a CMOS alternative. RCA made the CDP1855 multiply/divide unit.
It's less powerful than the 9511, but CMOS and part of the 1802 family.
They are hard to get, but I have one somewhere.
I also have some CDP1855's, which I'll probably add in here somewhere eventually.  I was originally going to use these when I stumbled over the AM9511.

In case I haven't mentioned it before, I'm mightily impressed by your
ELF-is computer. You have also spent as much time documenting it as
building it!
Thanks.  Hope you've enjoyed it as much as I have.

Regards,
Todd

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

taf123
 

In the mean-time, the much awaited 11.3258Mhz crystal arrived.

This, together with a couple resistors and capacitors, and 2 inverters from the 74HC04 chip, will form an oscillator for the VIS. This /2 = 5.6629Mhz, which is pretty damned close to the VIS specified 5.67Mhz.





Of course I had to re-populate all of those sockets before I could test, but I don't have the picture.

Anyways, this oscillator didn't work.  I copied it from the RTC circuit, which only used a 32kHz crystal.  Turns out, this same design can be used at higher frequencies, but the load 220k load resister (the blue one tucked next to the crystal) actually needs to be a capacitor to compensate for the phase shift of the inverter at speed.

Updated it to 39pF and it oscillated just fine.






And that's perddy darned close to 5.67Mhz



That's all the time we have for VIS tonight. 

In the next installment, the PS/2 keyboard interface.