Date   
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

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

taf123
 

The ELF-ish so far has 4k of RAM, partially decoded on the main board using a CDP1859 to decode the four 1k blocks, with the first 1k further decoded to four 256 byte pages.

The CDP1859 !EN is enabled by gating together !MA15, to ensure we're in the lower 32k reserved for RAM, and the so-called !4K0 (the enable like for the first 4k block).



The !4K0 line is simply tied LO using a pull-down resister connected to the !4K0 line on the memory second expansion port.  The idea is that any expanded memory board plugged into the port would more fully decode the address space, and raise this line HI for addressing memory above the 0000 - 0FFF range.  There's a matching !R4K0 line which does the same function for the ROM area above 8000, which we've seen connected to the decode for the memory-mapped I/O space in upper memory.


My plans were to build a memory expansion board at this time.  But, before I did this, I managed to get a hold of something special, which I had to try first.

Back in the day, RCA offered several CDP1802-based development platforms.  These were modular, using what they called their Microboard line, all connected together through a 44-pin motherboard.

The manual for the complete line can be found on-line - I found it on bitsavers at http://www.textfiles.com/bitsavers/pdf/rca/cosmac/1982_RCA_Microboards.pdf

Well, one day while looking around eBay, I spotted a CDP18S623 8k Microboard for sale at only $54.98, so I snapped it up.

And this is what arrived.



It uses a pair of 4050's to buffer the Address lines and signals, and a pair of CDP1856 bus buffers for the data bus - just like I did on the expansion chassis.

The DIP switches allow the board to be put in any of the available eight 8k blocks within the 64k CDP1802 memory space,

With four CDP1866 chips doing address latching and decoding to provide the various !CS lines.

Then the rest is a matrix of 32 RCA 89052 512 x 4-bit chips, which are predecessors to the MWS5114 1k x 4-bit chips.

 Because of differences in the motherboards between some of the RCA development platforms, they provided a jumper area to change come of pin uses.

This was convenient for the ELF-ish.  Remember, the expansion memory is responsible for de-asserting !4K0 to disable the low 4k RAM.  By adding a small jumper-wire here, I was able to present the board's enable line back to an unused pin on the 44-pin edge connector.  This I used to disable the main board RAM.



I then just needed to wire up a 44-pin card edge connector to a 26-way IDC cable and I was ready for testing.



The good news is that the board was still basically functional - it was correctly selected in the 8k block I had set in the dip switches, and I could read and write to various memory locations.

Yay.  So I did a simple write/read test to all 16 of the 512-byte pages of the 8k board.

The bad news - two of the chips were DOA.  The worse news - one of these was in the first 512-byte page, so there would be hole in the memory if I tried to use this board as-is.

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 hope to attempt a repair of this board in the near future - updates to this forum when that happens.

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

cmdrcosmac
 

Hi Todd,

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

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

 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.

 I like the labels on the underside of the chip sockets. How are these done??

>>  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??
Please tell us more about the Logic Analyzer!

Best,
Chuck

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

Lee Hart
 

taf123 wrote:
This next device is a departure both from the CDP1800 series and from
the CMOS technology I've been leaning towards so far.

It's an AM9511A-1DC Arithmetics Processing Unit, or APU, by AMD. The
original AM9511 was from 1978, and my AM9511A-1DC is (c)1979, so it's
period.
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.

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.

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!

--
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 I/O #ELF #Homebrew

taf123
 

This next device is a departure both from the CDP1800 series and from the CMOS technology I've been leaning towards so far.

It's an AM9511A-1DC Arithmetics Processing Unit, or APU, by AMD.  The original AM9511 was from 1978, and my AM9511A-1DC is (c)1979, so it's period.

The device handles signed 16- or 32-bit fixed point and 32-bit floating point add, subtract,  multiply and divide.  Plus it has 11 "derived" functions, such as square root, trig functions like sine, log and exp, and power.

There are also some data manipulation functions, such as converting from fixed to floating, or vice versa.

And all of this in a 24.6 package.

The device is stack oriented.  First, you have to use two or four 8-bit pushes to load one operand, then another two or four to load the other operand.  The command is then issued and the APU processes.  When it finishes, it asserts the !END line and the answer can be popped off the top of stack.  Or, another operand can be pushed and another operation begun.

Depending upon the operation, it may take anywhere from 10 - 20 cycles, to several thousand for some of the derived functions.

The APU also has a !PAUSE line to make the CPU wait if it is not ready for access.

It all looks straight forward to add to the ELF-ish in memory-mapped I/O space.  I placed it at CC00.  Only two addresses are needed; CC00 for the data and CC01 for the command and status register.

One little gotchya is that it's an older style NMOS, requiring both +5V and +12V supplies.  So I decided to feed the ELF-ish 5V regulator with a 12V supply instead of the original 9V, and then patch over the 12V supply directly to the APU.

It needs a clock, with the AM9511-1DC version supporting up to 3Mhz, so I use a buffered version of the 2.4576Mhz CPU clock.


I can't remember why I added the pull-up resisters to the buffered memory bus, except perhaps since the data sheet says that VOH was a minimum of 3.7V.  Although that looks like under TTL load conditions, so it probably should have been just fine driving CMOS.



There it is in the upper right, with the connector for the +12V feed.



So, did it work? Again, since it's memory-mapped, I can access it directly from UT4 using memory read and write commands.

With my first attempt to access it, the ELF-ish just locked up and needed to be reset.

Time to break out the logic analyzer and see what's going down in groove town.






This was a simple attempt to read the status register at CC01.

What we see here is standard CDP1802 execute of a memory read.  The !CS, which is decoded from the high addresses, occurs near the end of timing pulse TPA, with !MRD being asserted near the middle of TPA.

MA0 only takes on the value for the lower byte, the 01, after TPA.  So what we have here is a timing problem.  At the time that !CS and !MRD are asserted, A0 = 0, so the device thinks this is a data read (POP from the stack), which it is slow at due to the internal stack access time, so it asserts the !PAUSE line to make the CPU wait.  The CPU !WAIT line asserts a moment later due to the propagation delay in the control gating.

But, the APU never de-asserts !PAUSE, so we're waiting forever.  The timing diagram in the data sheet does show that !CS should occur at least 25ns before !MRD is asserted, which we have clearly violated here since !MRD is coming before !CS.

The data sheet doesn't say what happens if this is violated, but a separately available manual says this will cause the AM9511 to malfunction - which I guess we could say we're seeing here.

So I need to delay the !MRD signal.  If I gate it with the !CS signal, that solves the malfunction issue, but the !MRD would still be occurring before the A0 has taken on its value from the lower byte of the address, so an access to the Data register may occur when we wanted an access to the Control or Status register.

In other words, I need to gate !MRD with a sufficiently delayed version of the !CS signal.

I know there are better ways to do this, but I'm out of space on the board for any more chips, so I just used the some of the spare gates sitting around to compound propagation delays.  This ugly hack is what I ended up with.



Here's the signals with this change in place.



The key is that !MRD is now happening well after !CS, at the same time as A0 is asserting high.  According to the timing in the data sheet, the minium hold time between C/!D (which A0 is connected to) and !MRD is 0ns, so it's okay for these to happen together.

There is still a brief assertion of the !PAUSE line - the AM9511 pauses for every access, even if just briefly as in this case.

But then the read occurs and everything proceeds.

Here's a screen shot of the UT4 basic APU test.



The plan is to do a 16-bit fixed point add of 0x1234 with 0x5678, which should equal 0x68AC.

The first four lines push the operands onto the internal stack, at CC01, LSB first.

I then issue the add command by writing 6C to the command register at CC01.

I then pop the two byte result off the stack, MSB first.

Looks like success to me!  Yay!

One more signal trace for all of the nerds in the audience.  This is captured between issuing the 6C add command, and the APU asserting the !END line.



Issuing a command is a write cycle.  The CDP1802 asserts the !MWR much later in the execute cycle, so there wasn't any timing issues here.  The APU starts executing the command when !MWR de-asserts, as shown by the blue line.

Then, a couple machine cycles later, the APU finishes and pulses the !END line.  If that was tied to !INTERRUPT (or one of the !IRx lines of the CDP1877 PIC), an ISR could process the results.

I'm happy with these results.  If you're interested in this APU, or floating point maths in general, and all kinds of AM9511 and AM9512 gory details, check out the extended manual.

I found a copy at http://ep.homeserver.hu/PDF/AM9511A-9512.pdf.