Topics

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


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.

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

taf123
 

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

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)

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.



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

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/

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

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

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

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

taf123
 

Hi ELF-ish Fans -

If you recall from my version of the VIS, one can either use Character Generator mode, by running with the 2 * CDM6116 2k x 8-bit SRAMs, or can use bit-map mode, by running with the single CDM6264 8k x 8-bit SRAM.  But you had to make that decision up front.

Wouldn't it be nice to be able to switch between the modes using software control?  Note that the VIS board is already very full, so not much could be added.

I decided to add a 4013 D flip-flop to be used as a 1-bit output port, with the Q output controlling the !CS for the CDM6116's and the !Q output controlling the !CS for the CDM6264.  I used a spare 4016 transmission gate together with a decoded N=2 line from the CDP1853 that was added earlier for the keyboard, to select the FF.

Also, note that the PCB input of the CDP1870/1876 is useless in bit-map mode needs to be tied high when the CDM6264 is enabled.  I used another spare 4016 transmission gate and a pull-up resister to cause this to happen automatically when the CDM6264 is selected.

Here's the relevant changes:








And here's the new 4013 (original RCA type) installed in the lower left of the VIS board.



With this change, I can have both sets of memory installed at the same time.



With a slight update to the program to select the 6116 SRAMs, the Character Generator demo works as expected.



Changing the output OUT 2 byte from 0 to 1, selects the 6264 and thus bit-map mode.



It doesn't do anything more exciting than that as I haven't written a program to do anything interesting in bit-map mode yet, but at least it's functioning.

One of the keys is that we now have two independent pages and modes.  You can be in Character mode, switch to bit-map mode and do stuff, and then switch back to Character mode and the display will not have changed.

Cheers,
Todd