Hi BrianIts a bit confusing to read but as I understand it you have two eproms and you are latching the address bus which is then fed to both of them in parallel. That means whatever address you select and latch will be common to both eproms but you want to access them at different addresses. I think what you are asking for is to read the high 8-bits and low 8-bits at adjacent addresses. If I'm right, you need to use A0 to select one of two data latches, not address latches. Basically selecting the data from one or the other eprom at alternating addresses.
Brian.
Hi,
Please show a schematic. Hand drawn is O.K.
Klaus
Hi KlausHi,
Please show a schematic. Hand drawn is O.K.
Klaus
Thanks so much for your reply. Yes I did consult the 8086 manual but found it confusingYou are missing basic information of x86 bus operation. They are answered in 8086 user manual and circuit examples.
For 8-bit read-only devices, you simply connect bus A[16..1] to memory A[15..0]. x86 16 bit data bus is expecting the respective data at D[15..8] respectively D[7..0], independent of A0 state. 8 bit writes need to process A0 additionally.
That's wrong. One EPROM must hold high byte and other low byte of 16 bit data. EPROM programmers have functions to split 16 bit data file into two 8 bit images.Both EPROMs have identical code
This can´t replace a schematic. There is so much information missing.Attached is the connection of eprom
I´v never used 8086. I did a serach on "8086 16 bit memory schematic" and found good information on the first hit.So can I just invert the a0 address connection to eprom 2 ?
Hi,
Please show a schematic. Hand drawn is O.K.
Klaus
Thanks so much Klaus,Hi,
This can´t replace a schematic. There is so much information missing.
I´v never used 8086. I did a serach on "8086 16 bit memory schematic" and found good information on the first hit.
You could do the same. Or do like the other posters recommended.
To your question: No. A0 can´t be used for this. It is done via BLE and BHE.
*****
But: Why using a 45 years old microcontroller, outdated, slow, complicated to wire, high power consumption, with bad availability at all?
Every modern 16 bit microcontroller (indeed most 8 bit modern microcontrollers) will beat this guy in every manner.
Usually they have built in RAM, ROM, address decoder - so no external wiring needed for this. Are in system programmable (don´t need high quality EEPROM sockets and don´t need an eternity to delete/reprogram the EEPROM). Have a lot of built in periferals.
Klaus
Thanks FvMThat's wrong. One EPROM must hold high byte and other low byte of 16 bit data. EPROM programmers have functions to split 16 bit data file into two 8 bit images.
thats What I thoughtHere's the ROM connection scheme from Intel 80186 user manual. It's also expected that 16 bit data are split into odd and even address data and programmed to both EPROMs respectively.
View attachment 185191
OkA0 is not connected to the EPROMs, so the addresses 0xfff0 and 0xfff1 will be 0x7ff8 locally to both of them. The 8086 uses A0 internally to select the low or high byte (only necessary for 8-bit transfers).
Two 27512 can hold 128 kB of data if you have A16 available in your bus. Reset address ist actually 0xFFFF0 in 1 MB memory map. Code EPROM base address depends on how you decode upper address lines.
If don't use A16 and cut code memory to 64 kB, EPROM A15 has to be connected either to L or H level, reset address will be 0x7ff0 or 0xfff0 either.
This is however very basic x86 system design stuff and discussed in many documents.
so as an example the mov ax, 93hex machine code is, in little endian
B8 93 00
So do I put at location FFF0 in low byte eprom B9 and at FFF1 00
and in eprom 2 the high byte I put at FFF0 address in the eprom 00 ?
Ah . I get it - thank youB8 must be at address 0x7ff8 in the low byte EPROM, and 93 must be at address 0x7ff8 in the high-byte EPROM. When the 8086 goes to address 0xfff2 (and 0xfff3) the EPROMs will see address 0x7ff9.
Remember, A1 from the 8086 is connected to A0 of the EPROMs. A0 from the 8086 is not connected.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?