[N8VEM: 16157] EPROM vs EEPROM

[Todd Rossi]

I've got a really dumb question that's probably got a simple answer. I've
tried searching for information here regarding the topic, but I can't find
anyone else posing the question. So please forgive me if it's been answered
or obvious to everyone else:

Why does the N8VEM need to use an EPROM, are there no suitable EEPROMS?

It just seems like the convienience of using an EEPROM would be worth the
extra effort. But I could be flat out wrong in my assumption.

In my research it's obvious that there doesn't seem to be a pin-compatible
EEPROM that could replace the N8VEM's 32-pin 1M x 8 EPROM DIP. Availability
or the existance of a 1M x 8 EEPROM seems the only obvious answer I've been
able to piece together.
I've also considered that there may be a cost concern. If that's the case
are we talking the difference between a ~$9 EPROM vs a $20 EEPROM? Maybe
it's more like a $50 EEPROM replacement? Then I could also see this being a
decent reason.

Anyway, it just seemed like a question that hasn't been so publicly
discussed. I'd like to see if the community has pondered this as well.

[vk5dg]

Hello Todd,

EEPROMs are quite suitable for the N8VEM range but there are a couple of
things to consider.

The ROM must be able to hold the firmware image. The 27080 has 1M which is
plenty. I've used 512k 27040
EPROM as that is what I have on hand (salvaged from old equipment). The
Zeta uses a 512k FLASH ROM.
I have tried 128k and 256k chips at various times without major problems.

Pinouts are different between the various chip types. Usually there are
only a couple of pins that have different
functions between the ROM types - check pins 1, 30 and 31 for different
address and write lines. The SBC has
jumpers to cater for various types. I made up an adaptor socket so I could
use a 512k FLASH ROM in the place of
a 27080.

EPROMs can't be erased and programmed in-situ. This avoids accidents but
has little flexibility. FLASH ROMs
can be programmed in-situ which makes upgrades possible without needing an
external programmer as long as you're careful.
I haven't looked at whether EEPROMs can also be programmed in-situ without
hardware modification as I don't have any on hand.

By all means give it a try and let us know if you find any that are
suitable.

David

Post by Todd Rossi
I've got a really dumb question that's probably got a simple answer. I've
tried searching for information here regarding the topic, but I can't find
anyone else posing the question. So please forgive me if it's been answered
Why does the N8VEM need to use an EPROM, are there no suitable EEPROMS?
It just seems like the convienience of using an EEPROM would be worth the
extra effort. But I could be flat out wrong in my assumption.
In my research it's obvious that there doesn't seem to be a pin-compatible
EEPROM that could replace the N8VEM's 32-pin 1M x 8 EPROM DIP. Availability
or the existance of a 1M x 8 EEPROM seems the only obvious answer I've been
able to piece together.
I've also considered that there may be a cost concern. If that's the case
are we talking the difference between a ~$9 EPROM vs a $20 EEPROM? Maybe
it's more like a $50 EEPROM replacement? Then I could also see this being a
decent reason.
Anyway, it just seemed like a question that hasn't been so publicly
discussed. I'd like to see if the community has pondered this as well.

[Andrew Lynch]

Hi
I think the SBC V2 can also use the 29F040 Flash memory instead of the 27C080 CMOS EPROM. The original design used EPROM for reliability purposes (100% gaurantee of no overwritten memory) but since then builders have been using Flash. In this context, Flash memory is essential the same as EEPROM. I think smaller EPROM and EEPROMs can also be used depending on the jumper settings.

Thanks and have a nice day!

Andrew Lynch


--------------------------------------------
On Thu, 9/19/13, vk5dg <vk5dg-CkBdp7X+***@public.gmane.org> wrote:

Subject: [N8VEM: 16159] Re: EPROM vs EEPROM
To: n8vem-/***@public.gmane.org
Date: Thursday, September 19, 2013, 8:32 PM

Hello Todd,

EEPROMs are quite suitable for the N8VEM range but there are
a couple of things to consider.

The ROM must be able to hold the firmware image.  The
27080 has 1M which is plenty. I've used 512k 27040
EPROM as that is what I have on hand (salvaged from old
equipment).  The Zeta uses a 512k FLASH ROM.
I have tried 128k and 256k chips at various times without
major problems.

Pinouts are different between the various chip types. 
Usually there are only a couple of pins that have different

functions between the ROM types - check pins 1, 30 and 31
for different address and write lines.  The SBC has
jumpers to cater for various types.  I made up an
adaptor socket so I could use a 512k FLASH ROM in the place
of
a 27080.

EPROMs can't be erased and programmed in-situ. 
This avoids accidents but has little flexibility. 
FLASH ROMs
can be programmed in-situ which makes upgrades possible
without needing an external programmer as long as you're
careful.
I haven't looked at whether EEPROMs can also be
programmed in-situ without hardware modification as I
don't have any on hand.

By all means give it a try and let us know if you find any
that are suitable.

David


On Thursday, September 19, 2013 2:39:52 PM UTC+9:30, Todd
Rossi wrote:I've got a
really dumb question that's probably got a simple
answer. I've tried searching for information here
regarding the topic, but I can't find anyone else posing
the question. So please forgive me if it's been answered
or obvious to everyone else:

Why does the N8VEM need to use an EPROM, are there no
suitable EEPROMS?

It just seems like the convienience of using an
EEPROM would be worth the extra effort. But I could be flat
out wrong in my assumption.
In my research it's obvious that there
doesn't seem to be a pin-compatible EEPROM that could
replace the N8VEM's 32-pin 1M x 8 EPROM DIP.
Availability or the existance of a 1M x 8 EEPROM seems the
only obvious answer I've been able to piece
together.I've also considered that there may
be a cost concern. If that's the case are we talking the
difference between a ~$9 EPROM vs a $20 EEPROM? Maybe
it's more like a $50 EEPROM replacement? Then I could
also see this being a decent reason.
Anyway, it just seemed like a question that
hasn't been so publicly discussed. I'd like to see
if the community has pondered this as
well.



--

You received this message because you are subscribed to the
Google Groups "N8VEM" group.

To unsubscribe from this group and stop receiving emails
from it, send an email to
n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

To post to this group, send email to
n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

Visit this group at http://groups.google.com/group/n8vem.

For more options, visit https://groups.google.com/groups/opt_out.

[Douglas Goodall]

Todd,

I highly recommend the flash solution as there are major benefits. While new releases don 't come out that often, it is common to make changes to your build configuration, and reprogramming the chip in place is the most excellent method. No matter how careful you are, it is hard to avoid eventually bending or breaking a pin. There is a very clever program that reprograms the chip "in-situ" and you will be happy very quickly. Now and then you need to pull the chip and put it I'm the burner, but not often if you are careful. :-)

Douglas


Sent from my iPhone

Post by Todd Rossi
Why does the N8VEM need to use an EPROM, are there no suitable EEPROMS?
It just seems like the convienience of using an EEPROM would be worth the extra effort. But I could be flat out wrong in my assumption.
In my research it's obvious that there doesn't seem to be a pin-compatible EEPROM that could replace the N8VEM's 32-pin 1M x 8 EPROM DIP. Availability or the existance of a 1M x 8 EEPROM seems the only obvious answer I've been able to piece together.
I've also considered that there may be a cost concern. If that's the case are we talking the difference between a ~$9 EPROM vs a $20 EEPROM? Maybe it's more like a $50 EEPROM replacement? Then I could also see this being a decent reason.
Anyway, it just seemed like a question that hasn't been so publicly discussed. I'd like to see if the community has pondered this as well.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Sergey]

As Andrew mentioned N8VEM SBC V2 (but not V1, at least not without PCB
modification) will work with 29F040 Flash ROM.
This chip is 512 KiB (vs. 1 MiB for 27C080), so you'll need to find or to
build a 512 KiB firmware.
Flash ROM is very handy, as it can be re-programmed in the system without
using a programmer and UV eraser (you'll still need a programmer to program
it the first time).

There are no 1 MiB flash chips in DIP-32 packages, because this package
doesn't have enough pins. 1 MiB flash would need 8 pins for data + 20 pins
for address + 3 pins for control signals: /RD, /WR, and /CS + 2 pins for
power (VCC/GND), that is 33 pins...

There is a difference between EEPROM and Flash. In EEPROMs each byte can be
independently reprogrammed (erased and programmed), while in Flash ROM only
whole pages can be erased (page size depends on the part used but normally
from 4 KiB to 64 KiB). EEPROMs have smaller capacity and much more
expensive ($8.5 for 32KiB) compared to Flash ROMs ($3 for 512 KiB). The
EEPROM price (as the price of other ICs) will depend on specifications and
testing that was done.

Because EEPROMs are byte-programmable they are normally used to store
configuration in various equipment (e.g. network equipment, medical
equipment, industrial applications) while Flash ROMs are used for firmware,
which is mostly read-only, but sometimes it might need to be updated.

[Frank Vanderydt]

I think he has a point here we need a solution if we want our projects
going, 27080 and 29F080 are in EOL at the suppliers point.
I can only find 3V3 types in plcc..

[James Moxham (Dr_Acula)]

I have been wondering if we can leave the eprom out? It would save the cost
of the eprom, and the cost of a programmer.

Ok, please bear with me as this is a bit crazy! Let's consider you need an
add-on board - maybe it is a picaxe or propeller or some other board that
does the display and keyboard and talks to an SD card and can talk to a
touchscreen etc.The extra cost of adding some sort of bootstrap facility is
one extra chip. It could be an 82C55 or it could be a MCP23017 and there
are several other options - it just needs enough pins to talk to the ram
chip and at a minimum, maybe that is 8 data pins, 4-6 control pins and as
few as 5 address pins (bootstrap programs don't need to be big). I've been
studying the v2 schematic and I think it is possible to bootstrap the board
externally. I think you need access to all the pins on the ECB bus, and in
addition, I think you need to be able to control the /reset line, and the
v2 board brings out the reset to a 2 pin header so that should be easy.

I think all the 245 chips on the ECB bus interface all will work from the
ECB bus to the Z80 if the Z80 is issued a BUSRQ, so it should be possible
to load in a bootstrap program into the sram chip.

However, I am not entirely sure how a reset sequence works on a Z80. The
problem is with the ROM extended addressing latch. This controls whether
the board is talking to ram or rom, and the reset pin on that chip is tied
to the board reset. So whenever you issue a reset to the board, it goes
back to reading rom. I need to study the Z80 timing a bit more, but what I
am hoping is if BUSRQ is low and then you issue a RESET, the reset
overrides the BUSRQ. I think reset needs to be low for 3 clock cycles. Keep
BUSRQ low and make reset high, and I am hoping that the first thing the Z80
does is then acknowledge the busrq and make all the pins tristate. I hope
it does this before it tries to read anything from the eprom.

If that doesn't work, another option would be to add 8 weak pulldowns on
the data lines so the first thing the board does after a reset is to try to
read the eprom (which doesn't exist) and instead reads instruction 00 which
is a NOP and then a bit later the external board does a BUSRQ.

The other concept which might work is in situ programming of a flash chip.
The v2 board has provision 29xxx series flash chips and I think there is
sufficient control of all the ram/rom enable pins to be able to program
these chips from an external board.

Of course, there are many solutions if you redesign boards etc. The
challenge (and I like a challenge!) is to poke in a bootstrap program into
the ram chip from an external board, and hence not need any eeprom.

Cheers, James Moxham

Post by Todd Rossi
I've got a really dumb question that's probably got a simple answer. I've
tried searching for information here regarding the topic, but I can't find
anyone else posing the question. So please forgive me if it's been answered
Why does the N8VEM need to use an EPROM, are there no suitable EEPROMS?
It just seems like the convienience of using an EEPROM would be worth the
extra effort. But I could be flat out wrong in my assumption.
In my research it's obvious that there doesn't seem to be a pin-compatible
EEPROM that could replace the N8VEM's 32-pin 1M x 8 EPROM DIP. Availability
or the existance of a 1M x 8 EEPROM seems the only obvious answer I've been
able to piece together.
I've also considered that there may be a cost concern. If that's the case
are we talking the difference between a ~$9 EPROM vs a $20 EEPROM? Maybe
it's more like a $50 EEPROM replacement? Then I could also see this being a
decent reason.
Anyway, it just seemed like a question that hasn't been so publicly
discussed. I'd like to see if the community has pondered this as well.

[James Moxham (Dr_Acula)]

Well this thread has sent me off to Doctor Acula's Laboratory, and after a
month I have some designs.
I started with the idea that maybe we can do away with the EPROM
altogether. At a minimal level, all you need is to poke a small program
into RAM sufficient to get a Z80 talking and that should be possible with
32 bytes or even less. So I started with the MCP23017 I2C expander chip as
that has 16 I/O lines that can be set to be high, low or HiZ. So once the
bootstrap program is loaded, the pins can all go HiZ and this chip doesn't
do anything more. A MCP23017 is smaller and cheaper than an eprom, and you
don't need a programmer. But... it needs an I2C bus.
So the next thing to add is a Propeller chip which has an I2C bus. So the
project became a hybrid between a standard Z80 motherboard and the PropIO
board.
Initially I tried fitting everything on one board but too many things ended
up being left out. It might still be possible though to merge these two
boards together as the standard Z80 board has routing a lot denser than I
can get with the Eagle autorouter.
So - I ended up using a propeller board I have used for lots of projects
which has the following specs:
10x10cm board, SD card, Keyboard, Serial port, Keyboard, VGA display, TV
display, Stereo sound, Onboard regulators, Analog I/O and an expander chip.
This board brings out all the propeller pins plus the expander chip pins to
a 50 pin header, so at the simplest level, one has a 50 pin header with
lots of digital I/O pins.
Next issue is level translation. The PropI/O board uses resistors to do the
3V to 5V level translation and this works well and I have used this too for
D0-D7 and 4 control pins. But there is another way to do level translation
and that is to feed 3V logic signals into and out of the I2C bus on a
MCP23017 expander, and to run the expander chip on 5V. This is not as fast
but for bootstapping, speed is not so important.
Then it was a matter of seeing what could fit on the board. Most things fit
except the real time clock, and this can always be added to the propeller
I2C bus as tiny RTC boards for the I2C bus are very cheap on ebay.
I made a couple of design changes compared with the Z80 v2. I wanted to do
this with 74HC logic and the 7406 does not appear in the HC family. I think
an HC125 can do the same job though. There were a few less chips so there
are some spare gates. The serial port is now on the propeller board, so I
borrowed the UART address on the 139 and used this for the propeller board
instead.
I'll post the schematics first. I can post the boards as well if anyone
wants to see these.
Comments etc would be most appreciated.