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



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

taf123
 

Although things were working there were some issues.  The cheap scan convertor had no shielding, so the EMI coming from the ELF-ish would cause the screen to jump and flicker whenever I did anything with it.

So, I ordered a better one, which came in a nice shielded chassis, with a shielded, multi-core cable.  I put a Molex connector on it and we were ready to run.




No more flicker/jumping/etc - very nice.

Also, I finished entering the demo program.  Here is a shot of the screen full of random characters from my typing and using the cursor controls and scroll features.




But, it doesn't look like a made a video of the full demo - one will be coming shortly.

I then tested out the bit-map operation.  First step, remove the two CDM6116's and install the CDM6264




Here's a couple video's demonstrating the very basics of bit-map mode, just to show that it is working.

(ignore the hi-res pixels at the bottom of the screen on the first one - that was just having the scan converter size set incorrectly so it was displaying some uninitialized pixels)

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

taf123
 

I entered a bit more of the demo program and then made this little video, enjoy.

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

taf123
 
Edited

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

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

taf123
 

So, on to the VIS build.  There are many options to choose from when designing a VIS.  I decided I didn't want to decide and included everything:

  • A CDM6116 2k x 8-bit for Page Memory so it can support the full 24 x 40 on-screen and a full page off-screen
  • A CDM6116 2k x 8-bit for Character Memory to support the full 256
  • Jumpers to select between different memory options
    • CDP1869, pin 25 can either be cma3, for 6x16 characters or pma10 for the off-screen page
    • Bit 7 from the Page Memory can either be used for color information (PCB), can extend cmem from 128 chars to 256 chars
    • NTSC or PAL output
    • The !PREDISPLAY can either go to an !EFx, for polled use, or an !IRx line for interrupt use.
  • The option to install a CDM6264 8k x 8-bit SRAM instead to try the bit-map operation.
Although I did manage to source a CDP1871 Keyboard Encoder, I I didn't want to build a custom keyboard for it.

Instead, I decided to again borrow from the ELF2k, this time using 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 could be used for the necessary hand-shaking.

The VIS data sheet requires the use of one pair of CDP1856 bus buffers/separators between the pmem and the CPU data bus.  But since I am using buffering for memory-mapped I/O and I/O-mapped I/O as well, I'll have to include additional buffers of both types.  Plus, I need to interface to the two-level I/O system.

Phew - better get to it.

Similar to the 12k memory expansion board, I used two 74HC244 octal buffers for the address bus and signals.  Additionally, I used another 74HC07 HEX open drain buffer for the !EFx and !IRx lines.



I decided to use I/O level IO1 (where the latched bit 1 is set) for the VIS.  Since the CDP1869 decodes the N-lines itself, I use a 4016 quad bilateral switch, controlled by the IO1 line, to limit its access to the N-lines, with pull-down resistors to present 000 when a different I/O level is latched.

Since I planned on doing this a few more times, I went ahead and wired up a few of these lines to the CDP1875 used as a latch back on the expansion chassis.



The IO1 went to the 4016 control lines.

I'll just show here the combined N-line 4016, CDP1869, the two CDM6116 2k x 8-bit pmem and cmem SRAMs, and the CDP1856 pair acting as bus separators for the pmem.



The CDP1876 connects to the cmem bus, the "internal" CDP1869 to CP1876 lines, and the PCB.

The CDP1876 has two requirements for its data bus connection - it presents the cmem access as memory-mapped I/O, but also presents its control register as I/O-mapped I/O, using the CDP1869 decoded !N=3 line.

For my bidirectional buffering, this requires both a pair of CDP1857's, for I/O-mapped use, and a 74HC245 bidirectional buffer for the memory-mapped use.  I could have used another pair of CDP1856's instead, but I was running low and the pair takes up more board space.

Finally, the CDM6264 8k x 8-bit memory is wired in to both the PMA and CMA lines, for addressing, and the cmem bus.

Here's what all of that looks like:


The CDP1857's will also be used to buffer I/O-mapped devices in I/O level's 2 & 3, later, so that combined IO23_EN line is diode/resistor OR-ed with the N=3 line for a combined VIO_EN (VIS I/O ENable) line.

Finally, the DOT clock.  The data sheet calls for a 5.67Mhz crystal for NTSC use - but I can't find one.  If anyone knows where to source one, please let me know.

Since I couldn't find the required crystal, I looked around for alternates, which could get close enough.  I found some crystals and oscillators which, when /2 or /4, would get close.

So I wired in for all three options.  For the separate crystal controlled oscillator, I copied the 74HC04 based oscillator I used with the RTC, since a 74HC04 is fast enough for this.

Then for the division, I used both halves of a 74HC74, with jumpers to select between /2 or /4.

I figured between all of this, I should be able to find a good enough clock.


ICAN-6953 includes a full assembly listing of a VIS demo program which uses the UT4 sub-routines for character input, so I could start building at this point and come back to the PS/2 keyboard interface once all of this was working.

Ta-da! Phew!





I started with an 11.2896Mhz oscillator: /2 = 5.6448Mhz, which is close to the specified 5.67Mhz.




It's nice when a plan works out.

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

Lee Hart
 

taf123 wrote:
Back in the day, RCA offered several CDP1802-based development
platforms... their Microboard line...
The good news is that the board was still basically functional...
The bad news - two of the chips were DOA.
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.

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

--
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: IDIOT UART Patch #Serial #Assembler

taf123
 

Excellent Chuck - thanks a lot!

Once I get my ELF-ish story caught up to the current state of build, I'll make these updates and let y'all know how it goes.

Best regards,
Todd

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

taf123
 

The blank space to the left of the memory expansion boards in the 16k RAM version of the ELF-ish is just screaming out to be filled with something.



So let's go for something big!

But first, I was getting a little concerned about the additive effects of propagation delays as the system continues to sprawl.  So I exchanged the pair of 4050 address bus and signal buffers of the expansion chassis with CD74HC4050 chips.  These are pin- and functional-compatible but use High-speed CMOS (hence the HC), so their propagation delay is an order of magnitude better than the originals (~6ns vs ~60ns).



Now on to filling that space.

Although us ELF fans love our CDP1861-based PIXIE graphics, it leaves a lot to be desired not only in resolution, but in the demands it places on the CPU and thus the entire system.

RCA released what they called the Video Interface System, or VIS.  This was a two-chip set, both big 40.6 guys; the CDP1869 and CDP1870.

The VIS is geared toward text use, so uses a character generator method.  This method stores the character code in "page" memory, or pmem, which is then used to address the character 6x8 bit-maps (6x9 for PAL) in "character" memory, or cmem.  The output of cmem is the row of dots which then get shifted out to the display.

The set could support a maximum resolution of 24 rows x 40 characters, for 960 characters on display, and a maximum of 256 unique characters.  Using the character generator method, this required only 1k for pmem, and up to 2k for cmem, for a total of 3k - less if you didn't need all of the possible characters.  The equivalent resolution in a fully bit-map display would have required 8k, which was still spendy at the time.

It also had some rudimentary color capability as well as the ability to hold an additional page of characters off-screen, with built-in scrolling features.  And, just for fun, it could also make sounds.

The CDP1870 provided lum, chrom, and comp-sync, which could be combined into a composite graphics signal and fed to a TV via an RF-modulator, or to a video monitor.  RCA also provided the CDP1876 version, which instead presented separate RGB and comp-sync outputs, for driving a video monitor.

I went with the CDP1876 option as my scan converter wants the RGBS lines.

Some of the advantages of the VIS over other similar contemporary systems were:

  • The VIS controlled pmem and cmem directly - the CPU is not involved in screen refresh at all!
  • The VIS maps these memory spaces back into memory-mapped I/O space during non-refresh times so the CPU can update the display
  • The VIS clock is completely independent of the CPU clock and operates asynchronously from it.
Although the memory is mapped into the memory-mapped I/O space, the control registers are accessed by CDP1802 N-lines.  The CDP1869 directly decodes these, and uses N=3 through N=7, so two-level I/O is a must if you want to do anything else.  Fortunately, the ELF-ish is already configured for two-level I/O, so we're good to go.

The data sheet does mention that it also supports the bit-map operation, if you would rather stick in an 8k memory system, although you'll need to map between the character oriented address and pixel (X,Y) positions through your software.

The data sheet shows this all tied together as a system including the CDP1871 keyboard encoder.

There are many features and options available, so you'll have to consult the documentation if you're interested in the details.

In addition to the data sheets, there's an article about the VIS starting on page 79 of the "Design Ideas Book for the CDP1802", which includes the schematic of the RCA VIS demo board.

Additional very good resources are the two application notes, ICAN-6953 "An Introduction to the Video Interface System (VIS) Devices-CDP1869 and CDP1870" and ICAN-7032 "CDP1800-Based Video Terminal Using the RCA Video Interface System VIS".

These, along with a number of other very good application notes can be found in the 1982 RCA publication, SSD-280 "RCA LSI Products - Applications".

I found a copy at bitsavers, http://bitsavers.trailing-edge.com/components/rca/cosmac/SSD-280_RCA_LSI_Products_Applications_Jan82.pdf


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

Terry Gray
 

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

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

taf123
 

I wanted to bring the ELF-ish up to 16k of RAM, but didn't want to keep playing around in such small increments, so I decided to go with the RCA CDM6116 2k x 8-bit CMOS SRAM.

Putting 6 of these on an expansion board would add 12k, to bring the total up to 16k.

This time, I used a pair of 74HC244 octal buffers for the address bus and signals since I had a couple more signals involved.  Again, I used a CDP1875 output port as the upper address latch.


I also included two more 26-way memory expansion connectors.  Memory3 was intended for ROM expansion, so the !R4K0 line was buffered and passed through to it.

The Memory4 port was intended to let me expand the RAM further, so I could eventually fill the lower memory to a full 32k of RAM.  Of course, now that I own an RCA 8k Microboard, it will go here instead, assuming I can fix it.

To supply the required !CS lines I used a 74HC138, 3-to-8 line decoder, inverting.

I used A14 and A15 as !CS for the '138, placing this in the lower 16k of memory space.  Of course, the decoder will also generate the !CS lines for the lower two 2k blocks already decoded on the main board.  But by gating these together, I generate the !4K0 line.  If either of these lines are LO, then the !4K0 remains LO.  But if both are HI, the !4K0 line goes HI, disabling the lower 4k of RAM.  The other six !CS lines go to the six CDM6116's.

Of course I'm addicted to battery backup, so I had to include it here as well. By using a different mode setting, the DS1321 just passes the !CS lines through to the RAMs, rather than doing further decoding as was done with the CDP1822's in the first 1k of memory.

Each DS1321 can only handle four !CS lines, so I used two, both supplied by the same battery.



For the data bus buffering, I again used a 74HC245 bidirectional octal buffer.  The enable of this was made by again gating the A14 and A15 together to make sure we're in the lower 16k.  But of course, we don't want to enable this buffer if the lower 4k of RAM on the main board is active, so we gate this with the !4K0 line.

Finally, I was getting concerned about the length of the un-buffered side of the data bus, so I decided I would present the buffered data bus to the Memory3 and Memory4 expansion ports.  I included a !MEM3_EN and !MEM4_EN, which those expansion boards would assert when they are selected, to enable the buffer.  This was all OR-ed together using diode/resistor logic.



One final little detail.  The signal that the 8k Microboard asserts when it is selected is active HI, but I was intending to use active LO for the !MEM3_EN and !MEM4_EN lines, so I included a little jumper and gate to select wether to use the !MEM4_EN line directly, for one of my expansion boards, or to invert it for the RCA board.


And here are the connections for those future expansion boards.


Phew!  All of that fits nicely on one of the matrix boards I've been using.





And wired up for testing.



And, of course, it works.

Welcome to the 16k version of the ELF-ish.

IDIOT UART Patch #Serial #Assembler

cmdrcosmac
 

Hi Todd,

Here are my UART patches for IDIOT. UT4 should be similar.

First, initialize the UART.

0000 ;               0075          ORG =     #0000        .. RJ for Membersip Card
0000 71;             0076  RESET:    DIS            ..  DISABLE INTERRUPTS
0001 00;             0077          ,#00
0002 63;             0078               OUT 3                   .. Init UART
0003 13;             0079               ,#13                    .. 7 Data, 1 Stop, Even Parity.
0004 F8FF;           0080  FINDRAM:    LDI     #FF        ..  FIND RAM, STARTING AT FFFF

I realize you don't have a FINDRAM: but the idea here was to put the init at the beginning. It can go anywhere
before 1st use of the UART. Just DEC the stack if needed.

.........................................................................................................

Here's the input routine:

0143 F880;           0323  READ2:        LDI    #80        ..  SET #BITS IN CARACTER=7
0145 BF;             0324          PHI    ASCII        ..  (TAKES 7 SHIFTS TO CHANGE '80' INTO '01')
0146 E3;             0325          SEX    3
0147 8F;             0326          GLO    ASCII        ..  GET ENTRY FLAG
0148 C6;             0327          LSNZ            ..  IF TTYRED,
0149 67;             0328          OUT    7        ..     TURN READER ON
014A 80;             0329          ,#80
014B ;               0330  ..
014B ;               0331  ..   UART SERIAL
014B ;               0332  ..
014B E2;             0333          SEX SP
014C 6B;             0334  KEY1:   INP 3       .. GET DA BIT FROM
014D F6;             0335          SHR         .. UART STATUS BYTE
014E 3B4C;           0336          BNF KEY1    .. WAIT 'TILL DATA AVAIL.
0150 ;               0337  ..    
0150 12;             0338          INC SP
0151 6A;             0339          INP 2       .. GET DATA
0152 52;             0340          STR SP
0153 62;             0341          OUT 2       .. echo
0154 22;             0342          DEC SP
0155 BF;             0343          PHI ASCII
0156 ;               0344       .. ANI #7F     .. STRIP PARITY BIT
0156 22;             0345          DEC SP
0157 ;               0346  ..
0157 ;               0347  .. Original code continues.
0157 ;               0348  ..
0157 3243;           0349                  BZ    READ2        ..  REPEAT IF 00=NULL
0159 8F;             0350          GLO    ASCII        ..  IF READ OR TTYRED,
015A FE;             0351          SHL            ..     THEN GO TO EXIT
015B 3B39;           0352          BNF    REXIT        ..     ELSE IS READAH:
015D 9F;             0353          GHI    ASCII        ..  IF CHARACTER < "A",
015E FF41;           0354          SMI    #41        ..     TEN GO CECK FOR A NUMBER (0-9)
0160 3B2F;           0355          BNF    CKDEC
0162 FF06;           0356          SMI    #06        ..     ELSE CECK FOR LETTERS A-F
0164 3337;           0357          BDF    NFND
0166 FE;             0358  FND:        SHL            ..  CHARACTER IS HEX:

 I deleted the stuff between ..   UART SERIAL and .. Original code continues.
The surrounding stuff just illustrates how the patch sits within the original.

........................................................................................

Here's the output routine:

01BE F80B;           0439  TY2:        LDI    #0B        ..    ELSE SET CODE=BYTE, 11 BITS
01C0 AF;             0440  TY3:        PLO    ASCII        ..     SAVE CODE BYTE
01C1 ;               0441 
01C1 ;               0442  ..
01C1 ;               0443  ..  BEGIN UART SERIAL OUTPUT.
01C1 ;               0444  ..
01C1 E2;             0445           SEX SP
01C2 6B;             0446  BEGIN:   INP 3
01C3 FE;             0447           SHL
01C4 3BC2;           0448           BNF BEGIN
01C6 ;               0449  ..
01C6 12;             0450  OUTPUT:  INC SP
01C7 8D;             0451           GLO D
01C8 52;             0452           STR SP
01C9 62;             0453           OUT 2            .. Send character from stack.
01CA 22;             0454           DEC SP
01CB 22;             0455           DEC SP
01CC 8F;             0456           GLO ASCII
01CD FF0B;           0457           SMI #0B
01CF AF;             0458           PLO ASCII
01D0 ;               0459  ..   
01D0 ;               0460  ..   Original code continues.
01D0 ;               0461  ..
01D0 8F;             0462          GLO    ASCII       
01D1 FA0F;           0463          ANI    #0F
01D3 ;               0464               .. NOP
01D3 ;               0465               .. NOP
01D3 8F;             0466  NXCHAR:    GLO    ASCII        ..  GET CODE BYTE;

Again, delete all the original code between the notations, and insert the patch.

 The DELAY: and TIMALC: routines were deleted. This means you don't need to hit CR at startup.
IDIOT now unconditionally echoes. Since DELAY: is gone, this probably won't work with a TeleType
machine. Since DELAY: and TIMALC: are gone you may have to fix long and short branches.

Best,
-Chuck