Hi,
I'm new to understanding processors.
I've worked on micro controllers of 8051 architecture and I'm fairly familiar with it.

I'm unclear as to how exactly the AMD 188 processor will work with an external EEPROM (that has the code) and RAM.
Does only the EEPROM have the code? Or do we need to program the processor as well to point to the starting address of EEPROM? Also, do we need to make a program in processor to read from the EEPROM as well? I never really understood how exactly the code will be written in the EEPROM and executed by processor. 

I'm looking for some clarity on the same.

Generally, the AMD 188 processors, the Am188ER and Am188ES, have two chip select outputs, nUMCS and nLMCS, which split the 1MB address space in half on reset and power up.

In my projects  with this processor, I used an external CPLD to split the upper memory chip select address range into additional memory device selects, with one of those derived chip selects typically connected to my Flash or other non-volatile memory.

On reset, the Am188 and other '188 processors begin fetching instructions from location 0xFFFF0, which is 16 bytes short of the end of the upper memory chip select. In those 16 bytes the processor should be redirected to some other location within the boot Flash or other non-volatile memory. If not, the processor program counter will roll over and continue execution at address 0x00000.

Thank you so much for your reply.

I'm probably stuck at a much lower level. 

Do we have to burn any program/bootloader in AMD 188 for it to interface with a flash /EEPROM? 

When you say "processor program counter", does this actually refer to the memory location on the interfaced Flash/EEPROM?

Unless they've come out with newer versions, the AMD 188 has no internal memory -- you have to add everything externally.  So you don't have to program the processor to have it read from the EEPROM.  Instead, you need to wire up the EEPROM in such a manner that the processor starts running out of it from boot.

A typical development process would be to have socketed EEPROM or flash, and a EEPROM burner to program the read-only memory.  You'd do "burn and turn" development, meaning taking the memory chip out of its socket, erasing it and burning new code, and repeat.  (When I started in the late 80's, the process was to take your EPROM out, stick it in a UV eraser, program it, and repeat).

One you learn how to do that reliably, you switch to a flash memory that has protectable blocks.  Program the block the processor starts out of with boot code and protect it from errant writes, and download application code.

Just remember that the bare chip does nothing without memory attached.

Thank you Mr Tim. That clears a lot of my doubts.

Could you please also suggest what compiler I can use for AMD188?

Is there any way I could write my code in C language?

Also, is there any other processor you could recommend with similar specs? This has a 70ns memory access time. I'm trying to interface an E1 transceiver to AMD188. Hence probably this access time is of importance. Please correct me if I'm wrong.

The AMD188 is an obsolete processor, and not supported by modern tools.

If you really need to use this processor, Paradigm Software provides
C/C++ tools for AMD186/188 based on Borland, and Paradigm
also provides a bootloader and a locater that you will need.

Thank you so much!

Is there also any compiler you could suggest for assembly code? 

Why do you want to use a processor that's been out of production for years on what appears to be a new project?  There are so many superlative fast and modern processors out there to choose from, why scratch around for parts and tools and then struggle on with little or no support?

Is this E1 as in telephony at a bit rate of 2048Mbps?  Can you post a data sheet of the E1 transceiver?  If it's just getting the raw E1 bits into a processor, I'm thinking you might want to do the E1 part in an FPGA or CPLD, sent to something with an ARM core inside, using SPI.  SPI at more than 2048Mbps is easy-peasy these days, and if you don't want to mess with that there's plenty of microprocessors with memory interfaces that'll do clock speeds in the GHz range.

If you're just determined to stick with the 188 (or if you're upgrading an old product and haven't told us), I think that the gnu compiler set will work with it.  I know that the Borland compiler can be made to work perfectly well with it, because about 25 years ago I was writing C++ code for the 188 using the Borland compiler.  But you'd have to find an old copy of Borland, and if you don't want to do burn-and-turn a Paradigm debugger, and all the associated stuff that most people will have thrown out by now.

It looks like the Borland compiler at least may still be available, and for free: http://www.compilers.net/dir/free/compilers/ccpp.h.... 

I'm going to be pedantic here and highly dis-recommend the approach you're taking, again.  Unless you really are trying to wedge One Last Feature into an existing product there's no sense in it.  By the time you've figured out how to collect all the pieces you could be done with development using a modern ARM Cortex part with gnu tools and the OpenOCD debugger.

Thanks!

I'm trying to understand one of our old projects that we never completed and I'm trying to re-design it and hopefully get it working.

The transceiver used is PM4351 by Comet (Microsemi now). I'm unable to attach the datasheet as the size is higher than the allowed limit here. Yes, it's for telephony (PRI).

Do you still suggest an ARM controller with a high clock speed? Or are there any other options I can consider? I'm unclear as to what is the minimum clock speed I'll need in the processor to interface it with PM4351.

Also, I have an old code written in Assembly for AMD 188. I'm having trouble to find the right compiler for that too. Please suggest. 

Ordinarily I'd suggest a link to the data sheet, but it looks like Microsemi wants a sign-in.  I hate that.  So I'm going to assume details, and it'll be up to you to decide if I've got my head on straight.

I'd go looking for an ARM Cortex part that has a parallel memory interface.  This one does, but I am by no means pushing that particular one -- it's just the first one that popped up in a casual search, and it's by ST whose parts I currently prefer.  In a head-head race, the ARM Cortex-M cores will have won before the 188 has completed a lap, AND there are lots of inexpensive options.

Assembly code gets assembled, C code gets compiled.  You need an assembler that matches the assembly syntax.  If you can find out what the original used as a tool chain, try and use that.

You simply do not want to foist some old design that's chock full of obsolete parts upon your manufacturing organization.  I'm a design engineer, and even I would vote to call the subsequent actions by manufacturing personnel justifiable homicide.  You want to take the specifications of the original product and design anew -- particularly if the old product was abandoned for some good technical reason (as, for instance, that the 188 couldn't quite keep up, which is indicated by swaths of assembly, unless there was just someone on the project who considered himself an Assembly God).