Date   

Re: Fake Harris 1802 chip confirmation #rca1802 #History

P Todd Decker
 

Yes, Intersil made the 1802 and did so fairly recently (perhaps they still even do).  Here is their data sheet:  https://www.renesas.com/jp/ja/www/doc/datasheet/cdp1802ac-3.pdf

---
P. Todd Decker
913-284-8814

On Sep 11, 2020, at 3:04 PM, Ham Radio <bernard.murphy@...> wrote:

Thanks Dave

The marking  on the back look like
6FVBQ
Y7739

?FVBQ
?7733

6FVYQ
W676

6FVXD
J6116

Anybody know if those above are RCA markings? Did Intersil make 1802 chips under license?
--
Regards,
Bernie Murphy


Re: 1861 Replacement

Lee Hart
 

cmdrcosmac wrote:
The design I'm building id Chuck Yakym's Rev E, not the STG design.
Since Chuck Yakym's file area on the Group is under construction I've
attached
the files. The REV E is the video board.
I designed the original using just 4 chips; a 4040, EPROM, and a couple gates. It worked, but the 4040 is a ripple counter, so there were glitches as it advanced to the next state. The EPROM would momentarily look up the wrong address, so there were glitches in the outputs.

Chuck and I worked on improving the circuit. A 74HC4040 is faster, and reduced (but didn't eliminate) the glitches. Chuck used three 74HC163 synchronous counters in his rev.E version; they eliminated the glitches going into the EPROM addresses; but the EPROM itself still has small glitches in its outputs as the addresses change.

I improved it still further in my VIP2K design. I kept the 4040, but added an octal latch on the EPROM outputs, which eliminates the glitches entirely. But the VIP2K board is so tight on space that I couldn't latch all the EPROM outputs (I needed two sections of the octal latch for a /4 counter).

Back to the original question: Yes, this circuit can be configured to do other video formats (other resolutions, separate sync and video, PAL, VGA, etc.) It's basically a state machine, so the clock frequency and EPROM program can be changed for just about any format.

Lee
--
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com


Re: Fake Harris 1802 chip confirmation #rca1802 #History

Ham Radio
 

Thanks Dave

The marking  on the back look like
6FVBQ
Y7739

?FVBQ
?7733

6FVYQ
W676

6FVXD
J6116

Anybody know if those above are RCA markings? Did Intersil make 1802 chips under license?
--
Regards,
Bernie Murphy


Re: 1861 Replacement

the-eagle@att.net
 
Edited

Chuck, I have attached the Rev. D which is the last one I personally built and tested. I have also included the EPROM - U7 hex file that is needed.

Cheers,
Chuck Yakym


Re: 1861 Replacement

Mark Graybill
 

Sorry I misunderstood. Thanks for the files.


On Fri, Sep 11, 2020 at 11:35 AM cmdrcosmac <cmeyer@...> wrote:
The design I'm building id Chuck Yakym's Rev E, not the STG design.
Since Chuck Yakym's file area on the Group is under construction I've attached
the files. The REV E is the video board, The autorun is an 1802 system made to test the video board
-Chuck


Re: RC1802 Revision F - issues #rca1802

 

Nice!
Glad to see you got it going. :-) 

JohnS_AZ


Re: RC1802 Revision F - issues #rca1802

John Kennedy
 

Well everything is now working! In total I made four (big) mistakes:

1. Used the wrong type of switch for IN.
2. Didn’t use IC sockets (because hubris / impatience / I’m a HERO) and either broke or used a broken 4013 Flipflop.
3. Used a slightly different Static RAM chip, not noticing that an OE signal in the circuit was where A13 was on the chip
4. Used an EEPROM and couldn’t get any data from it - not realizing that again, A13 was always low as it was OE on this board, and so it was reading from part of the EEPROM that I hadn’t put data in, making me think the CPU wasn’t able to read it ‘cos it was all FFs.

Thanks to Josh I was able to confirm the CPU was still alive, and the switch circuitry was working as expected (once I fixed the flipflop which meant unsoldering it and this time using a socket).

Then, once I pulled A13 high on the OE the RAM chip started working. And once I programming the ROM starting at 4000h it started working too!

So now I’m ready to being exploring what this little marvel can do!



Re: 1861 Replacement

 

  FWIW, all the files for the STG1861 are in the STG Elf2K files area of this group...

Bob


Re: 1861 Replacement

cmdrcosmac
 

The design I'm building id Chuck Yakym's Rev E, not the STG design.
Since Chuck Yakym's file area on the Group is under construction I've attached
the files. The REV E is the video board, The autorun is an 1802 system made to test the video board
-Chuck


Re: 1861 Replacement

Mark Graybill
 

On Fri, Sep 11, 2020 at 2:56 AM Rizal Acob <racob@...> wrote:
Curious...any link where Chuck’s 1861 replacement circuit might be. Thanks








Re: Fake Harris 1802 chip confirmation #rca1802 #History

David G Williams
 


Hi Bernie,
 
                That is the Intersil symbol on the top - not Harris.
 
David Williams

----- Original Message -----
From: Ham Radio
Sent: Friday, September 11, 2020 12:08 AM
Subject: [cosmacelf] Fake Harris 1802 chip confirmation #rca1802 #History

I need help confirming that an 1802 chip is a fake.  

The eBay seller claims the chip is using a new “Harris” logo.

The date code on the back may be RCA?  Looks fake to me.

Comments please.  Thank you.


--
Regards,
Bernie Murphy


Re: 1861 Replacement

Rizal Acob
 

Curious...any link where Chuck’s 1861 replacement circuit might be. Thanks


1861 Replacement

cmdrcosmac
 

Hi all,

 I'm planning to build Chuck Yakym's 1861 replacement circuit and would like
to hear the Group's experience and advice.
 
 Would using 74HC rather than LS logic work?

 I would like to use a 28C256 EEPROM for the timing ROM as I can program these
on the Elf. There was apparently  some issue with different types of EPROMS in
this circuit. Has this been explained or resolved?

 Has anyone tried to re-do the timing to generate VGA timing rather than NTSC?

Thanks for your help.
-Chuck

 


Re: COSMAC VIP OS can now be operated with a smartphone #Homebrew #VIP

Kazuhiro Ouchi
 

Hi Gaston,

It is good. If you use the ESP-32 as a front panel, everyone will enjoy it with a web browser.
I will try it when the project I am working on is over.

Thanks,
Kazu


Re: RC1802 Revision F - issues #rca1802

John Kennedy
 

Thanks so much Josh!

Secretly I love it when things don’t work, as that is when I learn how they are supposed to work!

I’ve checked all those pins, and so it seems possible that the RAM chip is to blame. I’ll see if I can track down another :-)

Thanks again,

John

On Sep 10, 2020, at 11:48 AM, joshbensadon <jbensadon@...> wrote:


John,  Have a look at U2, with pin 7 so close to pin 8 ground... could there be a short there? 





From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Thursday, September 10, 2020 12:14 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC1802 Revision F - issues #rca1802
 

Thanks Josh!

As I puzzle over it, some data:

MRD - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down

LOAD_N2 - follows LOAD switch

TPB - pulses when LOAD is up

STROBE - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down (pulses are inverse of MRD)

DMA_IN - High until LOAD up and IN pressed then high again. 

—-

What is supposed to bring MRD low again?


On Sep 10, 2020, at 3:20 AM, joshbensadon <jbensadon@...> wrote:


Hi John,

You are correct, the LED should not follow the switches until you press the IN button.
Verify STROBE isn't shorted low anywhere and scope the signals around U4C.  

<image.png>


STROBE should only pulse low on TPB pulses during the load (DMA-IN) cycle.

PS. I find this design peculiar since it uses some 74LSxx chips.

Cheers,
Josh





From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Wednesday, September 9, 2020 10:48 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: [cosmacelf] RC1802 Revision F - issues #rca1802
 
Hello everyone!

I’m new to the group, as I’ve only recently tried to get a 1802 Elf system working.

I am using the RC1802 Revision F boards from https://github.com/tebl/RC1802-Cosmac-ELF

I’m having the devil’s own time trying to get things working, so I’d welcome debugging suggestions and any success stories from anyone who has used the rev F board.
At the moment it appears that the data I enter is not being stored, or read back. An EPROM doesn’t display anything either, when set to Low or High.

I know the CPU is working because I can observe the various SC0, SC1, TPA, TPB, address bus signals doing what I expect.
I can enter 76 and run it, and the Q LED comes on. I can’t seem to enter more than that byte though,

So I am looking for clues as to what might be the problem. For example:

* When powered on and LOAD set to UP, and MP set OFF, I can press IN and (perhaps) enter a byte. The LEDs change anyway.
* After this first byte, without changing LOAD or MP, or pressing IN, the data toggles update the LED displays in real-time. Is that normal?

I ask as the online emulators I’ve seen do not update the display until IN is pressed. I’m wondering if this is something that could help me diagnose my project.

thanks!

-john


Re: RC1802 Revision F - issues #rca1802

joshbensadon
 

John,  Have a look at U2, with pin 7 so close to pin 8 ground... could there be a short there? 





From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Thursday, September 10, 2020 12:14 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC1802 Revision F - issues #rca1802
 

Thanks Josh!

As I puzzle over it, some data:

MRD - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down

LOAD_N2 - follows LOAD switch

TPB - pulses when LOAD is up

STROBE - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down (pulses are inverse of MRD)

DMA_IN - High until LOAD up and IN pressed then high again. 

—-

What is supposed to bring MRD low again?


On Sep 10, 2020, at 3:20 AM, joshbensadon <jbensadon@...> wrote:


Hi John,

You are correct, the LED should not follow the switches until you press the IN button.
Verify STROBE isn't shorted low anywhere and scope the signals around U4C.  

<image.png>


STROBE should only pulse low on TPB pulses during the load (DMA-IN) cycle.

PS. I find this design peculiar since it uses some 74LSxx chips.

Cheers,
Josh





From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Wednesday, September 9, 2020 10:48 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: [cosmacelf] RC1802 Revision F - issues #rca1802
 
Hello everyone!

I’m new to the group, as I’ve only recently tried to get a 1802 Elf system working.

I am using the RC1802 Revision F boards from https://github.com/tebl/RC1802-Cosmac-ELF

I’m having the devil’s own time trying to get things working, so I’d welcome debugging suggestions and any success stories from anyone who has used the rev F board.
At the moment it appears that the data I enter is not being stored, or read back. An EPROM doesn’t display anything either, when set to Low or High.

I know the CPU is working because I can observe the various SC0, SC1, TPA, TPB, address bus signals doing what I expect.
I can enter 76 and run it, and the Q LED comes on. I can’t seem to enter more than that byte though,

So I am looking for clues as to what might be the problem. For example:

* When powered on and LOAD set to UP, and MP set OFF, I can press IN and (perhaps) enter a byte. The LEDs change anyway.
* After this first byte, without changing LOAD or MP, or pressing IN, the data toggles update the LED displays in real-time. Is that normal?

I ask as the online emulators I’ve seen do not update the display until IN is pressed. I’m wondering if this is something that could help me diagnose my project.

thanks!

-john


Re: RC1802 Revision F - issues #rca1802

joshbensadon
 

Hi John,

Sorry, I made a mistake.  I looked at the data sheet and tested my ELF, indeed, TPB and MRD pulse as normal during LOAD mode.
LOAD mode just forces the CPU to continuously execute an IDLE instruction without incrementing the PC.
Then with each IN press, a DMA-IN request occurs, which pulses the MWrite.  

So, during LOAD, the MRD continuously reads the RAM and with LOAD_N2 high, TPB strobes the value of RAM into the display.
When MRD is inactive (high), the switches are continuously read onto the bus but doesn't go anywhere until a write cycle deposits it to the RAM.
If you pull the RAM chip, the display just follows the switches (probably due to capacitance on the data lines).

I think the problem is with your RAM chip not being written to or read from.  Check the RAM and scope the CS, OE and WE.

Also check that the READ input (pins 1 & 19) to U6 (switch tristate buffer) is not grounded.  If it's shorting to ground, then you will also have the problem described.

Cheers,
Josh




From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Thursday, September 10, 2020 12:14 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: Re: [cosmacelf] RC1802 Revision F - issues #rca1802
 

Thanks Josh!

As I puzzle over it, some data:

MRD - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down

LOAD_N2 - follows LOAD switch

TPB - pulses when LOAD is up

STROBE - low until LOAD is up, IN pressed then pulses and doesn’t stop until LOAD is down (pulses are inverse of MRD)

DMA_IN - High until LOAD up and IN pressed then high again. 

—-

What is supposed to bring MRD low again?


On Sep 10, 2020, at 3:20 AM, joshbensadon <jbensadon@...> wrote:


Hi John,

You are correct, the LED should not follow the switches until you press the IN button.
Verify STROBE isn't shorted low anywhere and scope the signals around U4C.  

<image.png>


STROBE should only pulse low on TPB pulses during the load (DMA-IN) cycle.

PS. I find this design peculiar since it uses some 74LSxx chips.

Cheers,
Josh





From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of John Kennedy <johntkennedy@...>
Sent: Wednesday, September 9, 2020 10:48 PM
To: cosmacelf@groups.io <cosmacelf@groups.io>
Subject: [cosmacelf] RC1802 Revision F - issues #rca1802
 
Hello everyone!

I’m new to the group, as I’ve only recently tried to get a 1802 Elf system working.

I am using the RC1802 Revision F boards from https://github.com/tebl/RC1802-Cosmac-ELF

I’m having the devil’s own time trying to get things working, so I’d welcome debugging suggestions and any success stories from anyone who has used the rev F board.
At the moment it appears that the data I enter is not being stored, or read back. An EPROM doesn’t display anything either, when set to Low or High.

I know the CPU is working because I can observe the various SC0, SC1, TPA, TPB, address bus signals doing what I expect.
I can enter 76 and run it, and the Q LED comes on. I can’t seem to enter more than that byte though,

So I am looking for clues as to what might be the problem. For example:

* When powered on and LOAD set to UP, and MP set OFF, I can press IN and (perhaps) enter a byte. The LEDs change anyway.
* After this first byte, without changing LOAD or MP, or pressing IN, the data toggles update the LED displays in real-time. Is that normal?

I ask as the online emulators I’ve seen do not update the display until IN is pressed. I’m wondering if this is something that could help me diagnose my project.

thanks!

-john


Re: #MembershipCard #MembershipCard

Lee Hart
 

Matt wrote:
After it was all said and done, it wasn't my FTDI cables. When I cut
the U2/U8 traces, I nicked a via just enough to cause interference. One
jumper wire later, and things were talking on the serial line and not
floating. Onward and upward. Thanks for the help!
Congratulations! You found it! Finding a bug like that can really make your day. :-)

There needs to be something kind of prize for technicians that solve particularly nasty problems. How about the "Auntie Murphy" award?

Lee Hart

--
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com


Re: RC1802 Boards #rca1802 #Homebrew

P Todd Decker
 

All three of my extra board sets have been spoken for.  Thank you!

---
P. Todd Decker
913-284-8814

On Sep 10, 2020, at 11:51 AM, P Todd Decker via groups.io <ptdecker@...> wrote:

I have ordered a set of five of each of the RC1802 boards (processor, UI, and backplane).  I only need two.  So, if you're in the U.S. and want a set once they arrive, just private message me and I'll send you a set for the cost of postage plus $5 to help me recoup the postage on the order (the postage from PCBWay was almost more than the boards).

P. Todd


RC1802 Boards #rca1802 #Homebrew

P Todd Decker
 

I have ordered a set of five of each of the RC1802 boards (processor, UI, and backplane).  I only need two.  So, if you're in the U.S. and want a set once they arrive, just private message me and I'll send you a set for the cost of postage plus $5 to help me recoup the postage on the order (the postage from PCBWay was almost more than the boards).

P. Todd

2681 - 2700 of 30121