Date   
Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

John
 

Hi All,

Earlier I wrote "and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted."

I was wrong (forgotten already!) The left-most switch was used to pull the active-low chip select high, it was nothing to do with write enable. While running the chip select was held low, then I took it high for power down. I've disconnected the switch now and so far I haven't had a problem with memory loss. 

I've made a new back apron for Mar1e today, with a 9-way D socket for serial and a 25-way D socket for parallel and analog interfaces, none of which I've added yet. I'm eyeing-up the remaining space on the board for a 74HCT373, a MAX232 (no 1488/1489 for me as I don't want to have to add two more power rails) and whatever else I can fit. I think the two D sockets might be too close together, depending on the with of the covers. I've found a Psion Organiser XP (two line display) and two comms links, both with 25-way D connectors. Somewhere I have one where I swapped the connector for 9-way, but I haven't found it. Somewhere, too, I have a Psion LZ64 and an original LZ which I made into a 64 by adding more memory. Four lines would be good.

John

On Thu, 11 Apr 2019 at 17:52, David Madole <david@...> wrote:
John wrote:
> I fancy building an AFSK oscillator too, 1275/1445Hz, so it can talk
> acoustically to an RTTY app on my Android tablet at 50bps. I love that
> warbling sound!

Try just putting a speaker on Q and doing the tones in software.

David




RCA Studio II

chris@...
 

Hi there,

I just stumbled across a listing for an RCA Studio II on Goodwill's auction site. So far it's going for $16 (although they want a lot for shipping).

I figured I'd pass along the link in case someone here is looking for one: https://www.shopgoodwill.com/Item/66096969

Thanks,
Chris

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

David Madole
 

John wrote:
I fancy building an AFSK oscillator too, 1275/1445Hz, so it can talk
acoustically to an RTTY app on my Android tablet at 50bps. I love that
warbling sound!
Try just putting a speaker on Q and doing the tones in software.

David

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

Lee Hart
 

John wrote:
Not much of my Elf is "period correct", having a 6116 and laser-cut and
engraved panels, but the general layout started like that of the
original (and quickly changed). I might one day build an unexpanded
original with authentic parts but that's not a priority.
The original PE Elf wasn't a commercial product; it was hand-wired on perfboard. As you look through the series of articles, it keeps changing as Weisbecker added features. So there is no "right" way to build it.

The 2114 and 6116 both existed in the 1970's. They were just more expensive than the 2101's in the original Elf. Still, it cost about $80 for all the parts. That was a lot in 1976!

Having fun with it is the priority to justify the time I'm spending
on it.
That's the name-of-the-game for all of us! :-)

I fancy building an AFSK oscillator too, 1275/1445Hz, so it can talk
acoustically to an RTTY app on my Android tablet at 50bps. I love that
warbling sound!
The terminal for my first Elf was a Baudot teletype! I wrote my own driver to get it to work with a monitor and then Tiny BASIC.

--
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: Frugal Keypad #Electronics

Timothy Stoddard
 

I've also done that in other projects, but that requires software overhead to use and would not be a good solution for a DMA input into the COSMAC.
--
Tim Stoddard
"Life with technology: It's a roller coaster ride!"

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

John
 

Hello Paul,

The wiper of the switch does go to the active low write enable pin(s) on the RAM in both the original PE diagram and Paul's diagram. The poles are connected to +5v (write protect) and pin 35 on the 1802 (active low memory write).

Not much of my Elf is "period correct", having a 6116 and laser-cut and engraved panels, but the general layout started like that of the original (and quickly changed). I might one day build an unexpanded original with authentic parts but that's not a priority. Having fun with it is the priority to justify the time I'm spending on it. An alphanumeric LCD is a probable addition, and a hex keypad. I fancy building an AFSK oscillator too, 1275/1445Hz, so it can talk acoustically to an RTTY app on my Android tablet at 50bps. I love that warbling sound!

John

On Wed, 10 Apr 2019 at 22:20, David Madole <david@...> wrote:
The 22K shouldn't go to the wiper, if it's wired like Paul's diagram. It should go to the terminal that connects to the RAM.

Maybe your circuit is a little different though.

The MAX232 is not "period correct"... don't do it! Just kidding. Kind of. 

David

On April 10, 2019 5:08:23 PM John <easydogxray@...> wrote:

Thanks again for all the help. I can confirm;

There is no difference between the original circuit diagram and the one I called "Paul's design" 
The DIP switch I added does exactly the same as leaving the MP switch in the active condition (why didn't I spot that?)
Adding the 22k pull-up between the switch wiper and +5v has fixed the problem. I can now flick the MP switch up and down without any unwanted writes to RAM.

Adding the address LEDs was worthwhile too. I can see where I am. I will sleep well tonight.

Next job is to wire the other DIP switches to A8, 9 and 10, make the new back apron with D connector cut-outs (maybe tomorrow), add the MAX232 and some ports.

I love this machine, and I only found out about it by chance while planning a SC/MP-based project. 

John,

Nottingham

On Wed, 10 Apr 2019 at 20:47, David Madole <david@...> wrote:

Ah ok, I was just replying to what John called it. I took a quick look at the schematic but I really didn’t read the history or other documentation with it to understand that.

 

It’s been 40 years since I’ve seen the magazine article so I have no idea any more what the original design looked like :)

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of Paul Schmidt
Sent: Wednesday, April 10, 2019 3:36 PM
To: cosmacelf@groups.io; cosmacelf@groups.io
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

 

For what it is worth (and I am gratified that folks are using the ELF documentation I prepared), there is no "Paul's Design" in regard to the ELF schematic. What I show is just the same as the magazine article schematic, merely cleaned up and made neater, with more descriptive comments and such. I did not change anything that I can recall in regard to the way "MP" works.....

 

Paul

-----Original Message-----
From: David Madole
Sent: Apr 10, 2019 2:15 PM
To: "cosmacelf@groups.io"
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs


Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

 

Paul Schmidt
ocleide@...

 


Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

Lee Hart
 

Paul Schmidt wrote:
there is no "Paul's Design" in regard to the ELF schematic. What I show is just
the same as the magazine article schematic, merely cleaned up and made neater,
with more descriptive comments and such. I did not change anything that I can recall in regard
to the way "MP" works.
That's correct. Paul's schematic is the same as the original PE Elf article. Both leave the RAM's /WE pin "floating" during the time the switch transitions between WriteEnable and WriteProtect.

The 1802 Membership Card includes a pullup resistor on RAM /WE, and I've never had a problem with phantom writes. Perhaps adding one will fix your problem? It's an easy thing to try!

--
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: Mar1e gets (some) address LEDs #Electronics #Homebrew

David Madole
 

The 22K shouldn't go to the wiper, if it's wired like Paul's diagram. It should go to the terminal that connects to the RAM.

Maybe your circuit is a little different though.

The MAX232 is not "period correct"... don't do it! Just kidding. Kind of. 

David

On April 10, 2019 5:08:23 PM John <easydogxray@...> wrote:

Thanks again for all the help. I can confirm;

There is no difference between the original circuit diagram and the one I called "Paul's design" 
The DIP switch I added does exactly the same as leaving the MP switch in the active condition (why didn't I spot that?)
Adding the 22k pull-up between the switch wiper and +5v has fixed the problem. I can now flick the MP switch up and down without any unwanted writes to RAM.

Adding the address LEDs was worthwhile too. I can see where I am. I will sleep well tonight.

Next job is to wire the other DIP switches to A8, 9 and 10, make the new back apron with D connector cut-outs (maybe tomorrow), add the MAX232 and some ports.

I love this machine, and I only found out about it by chance while planning a SC/MP-based project. 

John,

Nottingham

On Wed, 10 Apr 2019 at 20:47, David Madole <david@...> wrote:

Ah ok, I was just replying to what John called it. I took a quick look at the schematic but I really didn’t read the history or other documentation with it to understand that.

 

It’s been 40 years since I’ve seen the magazine article so I have no idea any more what the original design looked like :)

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of Paul Schmidt
Sent: Wednesday, April 10, 2019 3:36 PM
To: cosmacelf@groups.io; cosmacelf@groups.io
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

 

For what it is worth (and I am gratified that folks are using the ELF documentation I prepared), there is no "Paul's Design" in regard to the ELF schematic. What I show is just the same as the magazine article schematic, merely cleaned up and made neater, with more descriptive comments and such. I did not change anything that I can recall in regard to the way "MP" works.....

 

Paul

-----Original Message-----
From: David Madole
Sent: Apr 10, 2019 2:15 PM
To: "cosmacelf@groups.io"
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs


Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

 

Paul Schmidt
ocleide@...

 


Re: Thai CDP 1802 #Wichit

gregory simmons
 

Hello Chuck,

On my computer, on the right side of the screen when I log onto groups.io, there are a few hyperlinks labelled "VIEW ALL".  If you click any one of them, then the menu bar on the far left side expands, and "Files" is the 3rd item from the bottom.  If you're computer acts the same way mine does, there ya go!  (PS -- I don't know whether it matters, but I'm using Chrome on Windows).

Best wishes,
greg/ab8im



From: svodyssey <chuck@...>
To: "cosmacelf@groups.io" <cosmacelf@groups.io>
Sent: Wednesday, April 10, 2019 5:01 PM
Subject: Re: [cosmacelf] Thai CDP 1802

I've been poking around on the Groups.io site and I can't find the files area. Can someone point me in the right direction?

Thanks,
Chuck

From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of the-eagle@... via Groups.Io <The-Eagle@...>
Sent: Wednesday, April 10, 2019 12:14 PM
To: cosmacelf@groups.io
Subject: Re: [cosmacelf] Thai CDP 1802
 
 
For all interested, I have posted in my file section an A18 assembler listing that will demonstrate on how to initialize a HD44780 LCD display for use on the CDP1802 Microprocessor Kit. I personally use a 16 by 2 lines display on my kit.
 
Regards,
Chuck Yakym
 


Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

John
 

Thanks again for all the help. I can confirm;

There is no difference between the original circuit diagram and the one I called "Paul's design" 
The DIP switch I added does exactly the same as leaving the MP switch in the active condition (why didn't I spot that?)
Adding the 22k pull-up between the switch wiper and +5v has fixed the problem. I can now flick the MP switch up and down without any unwanted writes to RAM.

Adding the address LEDs was worthwhile too. I can see where I am. I will sleep well tonight.

Next job is to wire the other DIP switches to A8, 9 and 10, make the new back apron with D connector cut-outs (maybe tomorrow), add the MAX232 and some ports.

I love this machine, and I only found out about it by chance while planning a SC/MP-based project. 

John,

Nottingham

On Wed, 10 Apr 2019 at 20:47, David Madole <david@...> wrote:

Ah ok, I was just replying to what John called it. I took a quick look at the schematic but I really didn’t read the history or other documentation with it to understand that.

 

It’s been 40 years since I’ve seen the magazine article so I have no idea any more what the original design looked like :)

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of Paul Schmidt
Sent: Wednesday, April 10, 2019 3:36 PM
To: cosmacelf@groups.io; cosmacelf@groups.io
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

 

For what it is worth (and I am gratified that folks are using the ELF documentation I prepared), there is no "Paul's Design" in regard to the ELF schematic. What I show is just the same as the magazine article schematic, merely cleaned up and made neater, with more descriptive comments and such. I did not change anything that I can recall in regard to the way "MP" works.....

 

Paul

-----Original Message-----
From: David Madole
Sent: Apr 10, 2019 2:15 PM
To: "cosmacelf@groups.io"
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs


Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

 

Paul Schmidt
ocleide@...

 

Re: Thai CDP 1802 #Wichit

Chuck
 

I've been poking around on the Groups.io site and I can't find the files area. Can someone point me in the right direction?

Thanks,
Chuck


From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of the-eagle@... via Groups.Io <The-Eagle@...>
Sent: Wednesday, April 10, 2019 12:14 PM
To: cosmacelf@groups.io
Subject: Re: [cosmacelf] Thai CDP 1802
 

 

For all interested, I have posted in my file section an A18 assembler listing that will demonstrate on how to initialize a HD44780 LCD display for use on the CDP1802 Microprocessor Kit. I personally use a 16 by 2 lines display on my kit.

 

Regards,

Chuck Yakym

 

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

David Madole
 

Ah ok, I was just replying to what John called it. I took a quick look at the schematic but I really didn’t read the history or other documentation with it to understand that.

 

It’s been 40 years since I’ve seen the magazine article so I have no idea any more what the original design looked like :)

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of Paul Schmidt
Sent: Wednesday, April 10, 2019 3:36 PM
To: cosmacelf@groups.io; cosmacelf@groups.io
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

 

For what it is worth (and I am gratified that folks are using the ELF documentation I prepared), there is no "Paul's Design" in regard to the ELF schematic. What I show is just the same as the magazine article schematic, merely cleaned up and made neater, with more descriptive comments and such. I did not change anything that I can recall in regard to the way "MP" works.....

 

Paul

-----Original Message-----
From: David Madole
Sent: Apr 10, 2019 2:15 PM
To: "cosmacelf@groups.io"
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs


Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

 

Paul Schmidt
ocleide@...

 

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

Paul Schmidt
 

For what it is worth (and I am gratified that folks are using the ELF documentation I prepared), there is no "Paul's Design" in regard to the ELF schematic. What I show is just the same as the magazine article schematic, merely cleaned up and made neater, with more descriptive comments and such. I did not change anything that I can recall in regard to the way "MP" works.....

Paul

-----Original Message-----
From: David Madole
Sent: Apr 10, 2019 2:15 PM
To: "cosmacelf@groups.io"
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John


Paul Schmidt
ocleide@...


Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

David Madole
 

John,

 

Another thought that came to me… why do you need a DIP switch to hold /WE high when that is exactly what the MP switch appears to do?

 

It seems like you could have just flipped MP to power off?

 

There may be more going on here than meets the eye and a schematic may be useful if further discussion is needed.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of David Madole
Sent: Wednesday, April 10, 2019 3:15 PM
To: cosmacelf@groups.io
Subject: Re: [cosmacelf] Mar1e gets (some) address LEDs

 

Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

David Madole
 

Paul’s design looks like it lets the /WE input on the RAM float during the short time that the MP switch is between breaking one side of the throw and making the other. I suppose this is fine if the /WE input on the RAM floats high but that’s probably not a good assumption, especially if you are not using the same RAM he did.

 

For the simplest fix, I would suggest tying /WE of the RAM high through a pull-up resistor (22K should be fine) to avoid this. Once you do that, you don’t really need a double-pole switch for MP either, but it won’t hurt.

 

David

 

 

From: cosmacelf@groups.io <cosmacelf@groups.io> On Behalf Of John
Sent: Wednesday, April 10, 2019 1:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

 

Hi Lee and the group,

 

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

 

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

 

The black wire exiting stage left is for the 'scope's earth clip.

 

Any ideas, anyone?

Thanks,

 

John

_._,_._,_

 

Re: Mass storage for Wichit Sirichote 1802 kit #Wichit

ajparent1/kb1gmx
 

Bill,

First assume the pc is like any other computer, it can be programmed to address anything.

Also current PCs if there is a limitation its due to the OS not any specific file system.  An example
of that is Win10 does NTFS or FAT but does not have a user utility to read or write a sector.
Linux has dd that does that as part of the distribution but its a dangerous tool as you can corrupt
the system disk very easily.  In both cases its possible to have tools that are both smart and not
tied to the native file system and can address a non-system (typically not drive C: and D: in
windows parlance) device like a USB disk, USB memory dongle, a CF or SD/uSD in
an adaptor.

So:
Yes you can, and no sorta.  The first is any tag and bag file system its easy to read the catalog
and see where a specific file is.  Due to its simple nature it also does not allow for fragmented
files as they are by default sequential.   The basic structure is a file starts at block nnnn and
continues for nnnn blocks.  Everything you need to find the file is in the catalog/directory.

File systems like NTFS, HPFS, FAT, CP/M, ELFOS all allow for fragmented files as its efficient
use of space.  All of those directory systems are more complex but finding a specific file and
the blocks it uses can be done, with greater overhead.  To find a file and its pieces is harder
as the directory entry requires you to access several tables on the disk to assemble the
needed information.

The bottom line is a low overhead file system for a simple (bounded) computer like
ELF, SCAMP, or whatever is a handy thing if mass storage is needed.  While it is
possible to have a more sophisticated file system one often needs more ram and
EE/Eprom to support it.

While none of this talks about how to actually interface or do it we have the Arduino and
it interfaces to SD via SPI (it has that) and also has serial.  With its 30 some K of flash
its possible to put a Fat file system (there is a library for that) in the Arduino as is
commonly done and be able to access files on a PC using an USB to SD adaptor.
Then the ELF can use a serial IO to talk to the Arduino and read/write/delete a file
by name and conduct transfer to the SD.  This makes for simple things that can
send data to the PC or get data or programs from the PC.  That lowers overhead
but the expense(DC power, added code) is also a lot of MPU (arduino) doing the
heavy lifting.  While that works its kinda upside down, the powerful system [PC]
with all the IO should put stuff on the portable devices (SD) in a form that the
ELF can use directly and any filesystem work is placed on the PC.

Just me, but I see it as a way to have fun and apply stuff I've learned over the
last 50 or so years.

Allison

Re: Mar1e gets (some) address LEDs #Electronics #Homebrew

Paul Schmidt
 

John, when I built the first of my two identical 'original configuration' ELFs (I have the original and my duplicate is (I think) still on display at Bletchley Park, both I (with mine) and the Bletchley volunteers (with theirs) noticed a slight glitchiness when making changes to memory. I my case, I initially attributed it to just clumsiness on my part, or brain fatigue during tedious program entry. When multiple guys at Bletchley contacted me about experiencing the same issue, I played around and found an alternate sequence of toggle switch movements that seemed to completely cure the problem. I think my online-published ELF documentation still shows the original sequence:

- MP up
- Press IN repeatedly until the byte immediately before the desired byte is displayed
- Set 8 toggles for correct byte contents
- MP down
- Press IN once
- MP up

In my correspondence with Bletchley, I have a record of the improved sequence, but offhand I don't recall what it is. My computer's boot drive took a dump over this last weekend, and although all normal data was automatically backed up, my OUTLOOK emails were not (oops!), so at the moment I cannot check to see what I told them. A data recovery service is working to recover those stored emails, but it might be a couple weeks before I (hopefully) have access to them again.

Maybe somebody else on this forum has the answer in the meantime.

Paul Schmidt

-----Original Message-----
From: John
Sent: Apr 10, 2019 12:30 PM
To: cosmacelf@groups.io
Subject: [cosmacelf] Mar1e gets (some) address LEDs

Hi Lee and the group,

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

The black wire exiting stage left is for the 'scope's earth clip.

Any ideas, anyone?

Thanks,

John


Paul Schmidt
ocleide@...


Mar1e gets (some) address LEDs #Electronics #Homebrew

John
 

Hi Lee and the group,

I've made a board with eight LED and eight 3k3 resistors which plugs into the second 6116 socket to show the lower eight bits of the address bus. It confirms my fears that, when I step through a program with MP active in order to edit a location, switching MP off writes the byte from the switches to the current location. Pressing IN (as I'm supposed to) then writes the byte from the switches to the next location (as it's supposed to). My circuit closely follow's Paul Schmidt's design. 

I don't yet know whether this happens every time or just sometimes. I'll try it repeatedly later tonight. I think I can get away with it by setting the current byte for the current location on the switches (as shown by the TIL311s), switching MP off, setting the next byte on the switches and pressing IN. I don't think this should be necessary though. Something is wrong.

I'll attach a new photo of Mar1e. The 2114 sockets are gone, the 6116 sockets are on the right and I've added a 4-way DIP switch. The left-most switch holds the active-low MW pin of the battery-backed RAM chip high for switching off and on, that way the RAM contents don't get corrupted. The other three switches will be used on the 6116's A8, 9 and 10 inputs, giving me effectively eight blocks of 256 bytes of RAM which will be maintained when the power is off. I've also relocated the 1MHz can oscillator to give me more space at the top. I'll make a new back apron with holes for a 9-way D connector (RS-232 via a MAX232) and a 25-way one (for parallel interface). 

The black wire exiting stage left is for the 'scope's earth clip.

Any ideas, anyone?

Thanks,

John

Re: New Elf called Mar1e - dumb question, before I start modding #Homebrew #Electronics

John
 

Thanks very much for this Lee. I have some blue LEDs in black holders which are quite bright at 0.5mA. I have a second 24 pin socket wired for a 6116 but not in use yet. I might make a plug-in board with eight LEDs to fit that. All the signals and ground are there.

Best regards,

John

On Tue, 9 Apr 2019 at 22:05, Lee Hart <leeahart@...> wrote:
John wrote:
> I really want to display the current address when I'm loading a program...
> If I want to latch the lowest 8 bits of the address bus and show them on
> LEDs, can I use a 74HCT373 octal latch with its strobe input connected
> directly to TPB?  ... I expect it's not that simple...

In the case of the 1802, it really *is* simple. :-)

To display the low 8 bytes of the address, all you need are 8
high-efficiency LEDs and a resistor network with 8 (or more) resistors.
Individual resistors can also be used. The 1802 can drive them directly
as long as the LED current isn't more than about 1 ma. I suggest
resistor values in the range of 2.2k to 4.7k.

Connect the common pin of the resistor network to GND.
Connect each resistor pin to each LED cathode.
Connect each LED anode to the 1802 MA0-MA7 pins.
The LEDs will light for any MA0-7 bit that is "high".

In LOAD mode, the address bus continuously outputs the low byte of the
address. TPA pulses and the high address byte are not present, except
during the actual DMA-IN cycle. So, you don't need a latch. :-)

If you also want to see the high byte, you need a 74HC373 latch as you
desscribed (connected to TPA), and 8 more LEDs and resistors connected
to the outputs of this latch as described above.

Lots of modern LEDs are efficient enough to be bright at 1ma. If your
DMM has a "diode test" range, this usually applies about 1ma as its test
current. Connect your LED to it to read the LED's forward voltage drop
at 1ma.

The red LEDs I supply with the 1802 Membership Card are highly visible
at 1ma, and they are just garden-variety parts. The "best" LEDs are
likely to be green or blue, which can be highly visible even at 0.25ma.

--
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: Mass storage for Wichit Sirichote 1802 kit #Wichit

ajparent1/kb1gmx
 

yes.

What one to use is far more complex as my system here is linux and I don't think the natic file system is 
simple.

The thought should be a PC can address anything its only a programming problem.
Think of the file systems that the various simulators can and do use.

Allison