• Please review our updated Terms and Rules here

How to Start hardware of 8085up......??

Hi again,

I have a new easy memory decoder schematic:-

Note:- Reply to thread, please don't leave blank forum we very near to our goal.12233.jpg
 
;Flash a LED on SOD
;Top of RAM @ 0x4000

START: LXI H, 4000h
SPHL
Click to expand...

what the need of RAM in this program using SOD ??

and if we will prog. EEPROM by this code where to write PROM add.??
 
RITESH said:
what the need of RAM in this program using SOD ??

and if we will prog. EEPROM by this code where to write PROM add.??
Click to expand...
Your questions were answered in post # 151:
And just for the record, no, I can tell you your test code is wrong even without knowing 8085 assembly simply because you're originating it at 0x4000. If you're mapping your EPROM at 0x0000 that's where you should ORG it in your assembler unless your design includes some sort of front panel, bootloader, or copy routine to load your test code into RAM and execute it from there. Someone else might be able to tell you if your delay loop is long enough to actually make the blinking of the LED visible to the human eye.
Click to expand...
 
It's also not /his/ code, it's /my/ code, copied from my personal website (http://www.glitchwrks.com/8085projects/ ). That's why it looks like a fragment -- it was posted to help those looking to get into 8085 projects with a simple test without allowing it to be directly plagarized for someone's coursework.

Read the article I wrote, it clearly explains why RAM is needed and where the program should be loaded. If you don't understand that, you need to read more about the 8085. If you have specific questions about what you don't understand, people on this forum (including me) will be happy to answer them. Right now, 99% of the questions you've asked can be answered from the 8085 datasheet.
 
glitch said:
Read the article I wrote, it clearly explains why RAM is needed and where the program should be loaded. If you don't understand that, you need to read more about the 8085.
Click to expand...
Maybe now I am asking a dumb question, but why is RAM needed if all you're going to do is pulse SOD?

BTW, most data sheets do not list the extended (aka 'undocumented') 8085 instructions and flags; look for the Tundra version for a full list.
 
Last edited:
Hi again,

I have programmed EEPROM with Glitch code SOD one......
I have changed RAM addr at 3000H and and delay in accumulator at 10H from FFH.
Now i have to just decode the addr of 8085 by 74154 ( 4 bit To 16 bits) and connect it lower addr i.e. 0000H to PROM and Ram to 3000H,etc...

is this OK, Know?
 
MikeS said:
Maybe now I am asking a dumb question, but why is RAM needed if all you're going to do is pulse SOD?
Click to expand...

It's not required, and the original version was a ROM-only test using just the processor's registers so that RAM didn't have to be hooked up/working (important when it's all point-to-point!). The version listed is for testing RAM/stack functionality as well. It's a quick way to put something in ROM and test general functionality/address decode/RAM without having to attach anything non-permanent to the 8085 (you can just monitor the SOD pin with a logic probe).

Ritesh, yes, you can decode memory like that and it'll work fine. You would be better off with a 74LS138 1-of-8 decoder though, since it will split memory into 8K chunks and you're using 8K memory devices. The delay listed in my example will provide an approximate 2 or 1 second delay with an 8085 running at 1 or 2 MHz (2 or 4 MHz crystal respectively). If you're not sure if your memory decode is working, then program the ROM to just toggle the SOD pin on and halt and check the SOD pin. That will allow you to get ROM decode working without worrying about RAM.
 
Glitch, even though I mentioned the 138 many posts back, why not simply split the memory space into two 32K chunks, one for RAM and one for ROM. That scarcely needs more than an inverter.

If all you're going to do is blink an LED, you don't need RAM. But if you eventually want to add a peripheral or two, such as a UART for debugging and communication with the 8085, RAM is necessary.

When I'm starting out with an unfamiliar architecture, one of the very first things that I write is a debugger for it. This indicates to me that I have at least a rudimentary understanding of the instruction set and a few peripheral interfaces.
 
Chuck(G) said:
Glitch, even though I mentioned the 138 many posts back, why not simply split the memory space into two 32K chunks, one for RAM and one for ROM. That scarcely needs more than an inverter.
Click to expand...

Well, that's true if you ignore the IO//M line or if your memories have enough chip selects to account for it. The 138 has three selects (two active low, one active high) which conveniently handles splitting memory space /and/ the IO//M qualification. That's why I chose to go with the 138 for my initial design with 8K devices.

If all you're going to do is blink an LED, you don't need RAM. But if you eventually want to add a peripheral or two, such as a UART for debugging and communication with the 8085, RAM is necessary.
Click to expand...

Exactly, which is why my SOD blinking program used RAM. I knew I wanted to add RAM anyway, and it was a convenient test.
 
Heh, I seem to recall that the MCS85 manual has not one, but two examples that illustrate using SID and SOD for "bit bang" serial I/O, including formulas for bit rate calculation, so you could get by with just ROM and RAM and no I/O space. I suppose you could put an LED on SOD... :)
 
Yep, a lot of embedded applications used the bit-bang serial method over SID and SOD. I'd rather have a full UART, but one could see where it would be nice to save an appreciable amount of board space by using SID/SOD. In any case, it's built in and it's got instructions for manipulating it, so it's a convenient test to see if your 8085 is fetching and executing instructions from memory! And SOD will definitely drive a LED through a 330R resistor as a simple 1-bit output...you can also poll SID as a 1-bit input.
 
Chuck(G) said:
...If all you're going to do is blink an LED, you don't need RAM. But if you eventually want to add a peripheral or two, such as a UART for debugging and communication with the 8085, RAM is necessary.
Click to expand...
Well of course, if you're going to do anything useful you'll need RAM, but Ritesh had asked, "what the need of RAM in this program using SOD ??" and I thought Glitch's reply, "it (his article) clearly explains why RAM is needed" was a little misleading.

@Ritesh, re your question in that other thread: Tundra is a Canadian semiconductor company who makes an 80C85 and whose datasheet is one of the few that officially documents the 10 extended instructions. Google 'tundra 8085'.
 
MikeS said:
Well of course, if you're going to do anything useful you'll need RAM, but Ritesh had asked, "what the need of RAM in this program using SOD ??" and I thought Glitch's reply, "it (his article) clearly explains why RAM is needed" was a little misleading.

@Ritesh, re your question in that other thread: Tundra is a Canadian semiconductor company who makes an 80C85 and whose datasheet is one of the few that officially documents the 10 extended instructions. Google 'tundra 8085'.
Click to expand...

I understand. If I were a tyro at 8085 design, though, I'd want to play around without burning a new PROM image every time I changed the code; i.e. run things out of RAM. An PROM emulator might accomplish almost the same thing.

Sadly, Tundra is no more--it was swallowed up a couple of years ago by IDT. I suspect there's nobody at IDT who knows about the Tundra 8085. Still it was neat marketing trick; document the instructions that everyone knew were there and refer to them as "enhancements" to the basic 8085.
 
OK, I will use '138 then i have to connect A15 in such a way that when A15 is low then only memory decoder circuit will work. I am right??
Is it compulsory that the PROM addr should start at 0000H as it reset vector addr is at 0000h, so, can we change the PROM starting addr.???

and I think without RAM the program will not run as we need to store Stact, etc....
 
Chuck(G) said:
I understand. If I were a tyro at 8085 design, though, I'd want to play around without burning a new PROM image every time I changed the code; i.e. run things out of RAM. An PROM emulator might accomplish almost the same thing.
Click to expand...
Well, without a monitor to put things into RAM and edit it, his EEPROM is probably the most practical.
Sadly, Tundra is no more--it was swallowed up a couple of years ago by IDT. I suspect there's nobody at IDT who knows about the Tundra 8085. Still it was neat marketing trick; document the instructions that everyone knew were there and refer to them as "enhancements" to the basic 8085.
Click to expand...
I also thought they'd faded from the scene a few years back, but when I Googled Tundra Semiconductor it brought up quite a few current listings, valid phone no.s etc; I doubt that they're still big on 8085s though...

I'll have to ask a buddy of mine in Ottawa who's had dealings with them in the past what the story is.
 
You must log in or register to reply here.
Back
Top