- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
How to Start hardware of 8085up......??
- Thread starter RITESH
- Start date
DOS lives on!!
Veteran Member
Please be patient. Some of us are in different time zones and may still be in bed.
Chuck(G)
25k Member
BlackCow
New Member
Well RITESH emailed me after finding out I have been working on an 8085 project (probably from my website).
I actually haven't finished my 8085 project to the point that I want to make a blog post about it. When it's done I
plan to post my final schematic and my operating system's source code. So far I can hook it up to a terminal and
type commands, have it recognise them, and execute code based on given commands. Next I want to wire up a
floppy drive to my 8255 GPIO and load programs into RAM through floppys :D
He linked me to this thread, and I think I found a new favourite forum to frequent
I am posting my final email response to him here in hopes that the links and brief explanations will help someone else
reading this thread and point them in the right direction.
I actually haven't finished my 8085 project to the point that I want to make a blog post about it. When it's done I
plan to post my final schematic and my operating system's source code. So far I can hook it up to a terminal and
type commands, have it recognise them, and execute code based on given commands. Next I want to wire up a
floppy drive to my 8255 GPIO and load programs into RAM through floppys :D
He linked me to this thread, and I think I found a new favourite forum to frequent
I am posting my final email response to him here in hopes that the links and brief explanations will help someone else
reading this thread and point them in the right direction.
BlackCow
New Member
Ok so you're ROM and RAM chip will have chip enable pins, this is what tells the chip to turn on or off.
Remember they all share the same data bus and you do not want two chips trying to use
the data bus at the same time. This is called bus contention and will damage your chips!
So we map memory locations, with logic gates, to turn on the CE (chip enable pin) on our chips
for certain memory ranges.
The 8085 is an 8 bit computer with a 16 bit address bus, so it can address 2^16 power memory locations
(at each location is an 8 bit chunk of data).
Or that's 65,536 memory locations.
Or that's 1111 1111 1111 1111 memory locations.
Or thats 0xFFFF memory locations.
It's much easier to represent this with hexadecimal values so I will be using that for now on.
So the 8085 can address memory between 0x0000 all the way up to 0xFFFF (or 0000 0000 0000 0000 up to 1111 1111 1111 1111)
So all you have to decode 8 kilobytes of ROM and 8 kilobytes of RAM.
So you could give your ROM the location 0x0000 (starting instruction) up to 0x2000
And then RAM could have 0x4000 up to 0x6000.
Yes there is a lot of wasted space between 0x2001 up to 0x3FFF but if you only need 8KB of each then it doesn't matter.
My memory IO decoder is more complex because I didn't want to waste as much space because I have bigger ROM and RAM
chips as well as a serial UART and an IO chip to address.
For you, simply an OR gate on address line 14 (remember I am counting from 0 to 15) would turn your ROM enable on
and at 0x4000 address 14 would be logic high so then it would switch the OR gate to your RAM to be enabled.
Quite simple in your case! (Also keep in mind that chip enables are often enabled at logic low not logic high, check your data sheet).
However I am wondering how you plan to communicate to any devices besides ROM or RAM with your 8085 to make it actually do things!
You need some sort of input/output chip to control things. For testing purposes you could write a program to output data (like 10101010)
to your SOD pin (using the SIM instruction) and look at the output on an oscilloscope or a logic probe (because it would be too fast to see with an LED).
But that wouldn't help you do anything useful except prove it works!
You really need some sort of IO chip (like an 8255 for parallel data or a serial UART) to make it do things!
And of course any IO chips need address space as well (think of them as memory locations that control things!)
So you will have to add more logic to give it spaces as well and then write software to drive them.
Good luck
Remember they all share the same data bus and you do not want two chips trying to use
the data bus at the same time. This is called bus contention and will damage your chips!
So we map memory locations, with logic gates, to turn on the CE (chip enable pin) on our chips
for certain memory ranges.
The 8085 is an 8 bit computer with a 16 bit address bus, so it can address 2^16 power memory locations
(at each location is an 8 bit chunk of data).
Or that's 65,536 memory locations.
Or that's 1111 1111 1111 1111 memory locations.
Or thats 0xFFFF memory locations.
It's much easier to represent this with hexadecimal values so I will be using that for now on.
So the 8085 can address memory between 0x0000 all the way up to 0xFFFF (or 0000 0000 0000 0000 up to 1111 1111 1111 1111)
So all you have to decode 8 kilobytes of ROM and 8 kilobytes of RAM.
So you could give your ROM the location 0x0000 (starting instruction) up to 0x2000
And then RAM could have 0x4000 up to 0x6000.
Yes there is a lot of wasted space between 0x2001 up to 0x3FFF but if you only need 8KB of each then it doesn't matter.
My memory IO decoder is more complex because I didn't want to waste as much space because I have bigger ROM and RAM
chips as well as a serial UART and an IO chip to address.
For you, simply an OR gate on address line 14 (remember I am counting from 0 to 15) would turn your ROM enable on
and at 0x4000 address 14 would be logic high so then it would switch the OR gate to your RAM to be enabled.
Quite simple in your case! (Also keep in mind that chip enables are often enabled at logic low not logic high, check your data sheet).
However I am wondering how you plan to communicate to any devices besides ROM or RAM with your 8085 to make it actually do things!
You need some sort of input/output chip to control things. For testing purposes you could write a program to output data (like 10101010)
to your SOD pin (using the SIM instruction) and look at the output on an oscilloscope or a logic probe (because it would be too fast to see with an LED).
But that wouldn't help you do anything useful except prove it works!
You really need some sort of IO chip (like an 8255 for parallel data or a serial UART) to make it do things!
And of course any IO chips need address space as well (think of them as memory locations that control things!)
So you will have to add more logic to give it spaces as well and then write software to drive them.
Good luck
Eudimorphodon
Veteran Member
Uhm, why do you say it should be eight kilobits? The address scheme BlackCow laid out refers to numbers of *BYTES*.
It's really simple, and it's astounding how many times in this thread this has been explained to you: The 8085 is an 8 bit CPU with a 16 bit address bus. Address circuitry decodes the ADDRESS BUS, and 16 bits gives you 65,536, aka, 64k possible address locations at which the CPU could read or write an 8 bit data word. (If you want to be pedantic I suppose that makes the 8085's total addressable memory 512 kilobits, but it's broken into 8 bit chunks and memory fetches operate on those byte-size pieces.) BlackCow's memory layout was essentially to wire an 8 kilobyte EPROM chip and an 8 kilobyte SRAM in parallel. (Each of which would have 13 address pins, A0 through A12 for 8K 8-bit bytes of ROM and RAM, respectively. And yes, they'd also have eight data pins so each would be a 64 kilobit part. The number of bits will probably be reflected in their part numbers; the 2764 was a common 8 kilobyte parallel EPROM and the 6264 is a common 8 kilobyte SRAM; but what's important for this application is how many BYTES that number of bits works out to.) Then his suggestion is to use the fifteenth address line, which would be A14 on the schematic to select which is active.
If you understand binary (which I'm not entirely sure you do), you'd understand how this works. A14 (which again, is the 15th address line) would act as an ON/OFF switch which is toggled on and off at every 16K boundary in the 64k address space. IE:
0 to 16383 == 0x0000 to 0x3FFF == 0000 0000 0000 0000 to 0011 1111 1111 1111 == A14 is off
16384 to 32767 == 0x4000 to 0x7FFF == 0100 0000 0000 0000 to 0111 1111 1111 1111 == A14 is on
32768 to 49151 == 0x8000 to 0xBFFF == 1000 0000 0000 0000 to 1011 1111 1111 1111 == A14 is off
49152 to 65535 to 0xC000 to 0xFFFF == 1100 0000 0000 0000 to 1111 1111 1111 1111 == A14 is on
(The third column is the binary representation, and the second 0 from the left represents A14.) ROM is enabled whenever A14 is off, RAM enabled whenever it is on. With addressing circuitry this simple you'll see the following:
A: If you're using 8K parts each will appear twice inside each 16K window. IE, the contents of your 8K ROM will appear where you want them at location 0000, and then appear again at 2000. The reason for this is there's no decoding of A13 the 14th address line, the one that marks off 8K boundaries) and the chip only uses address lines up to A12 (13 of them.) The state of the lower 13 address lines counts up the same whether or not the 14th is on, the chip will be enabled for the whole time up until the 15th address line comes on, so it'll just spit out the same contents whether A13 is on or off. If you were to use even smaller parts you'd see even more repeated copies, IE, 4 copies for a 4k part, 8 copies for a 2k part. If instead you used a 16k part it'd fill the window perfectly. But:
B: There are four 16K windows in the address range, so each set (off/on) will also be repeated twice. (IE, the same memory that lives at the 0k mark will also appear at the 32k mark, and ditto the 16k and 48k windows.)
If you're stuck on 8k parts and having a gap between ROM and RAM bothers you decode A13 instead of A14 instead. Then RAM starts at 0x2000, right after ROM. But now you'll have a copy of ROM at the 16k mark, RAM at the 24k mark, ROM at the 32k mark... etc, etc, so it wastes the same amount of address space, just in a different pattern. Heck, if you really think that "8 kilobits" is the right number decode A10 to use a one kilobyte (which is eight kilobits arranged into eight-bit bytes, as explained earlier) EPROM at 0x0000 and a one kilobyte SRAM at 0x0400. Then you'll have a copy of your entire memory map repeated every 2k boundary. If you don't want these shadow copies then you need to more fully decode the address spaces by adding more logic gates. And as BlackCow also noted you'll need to add some decoding hardware if you want to add any I/O chips to make this thing useful at all, unless just bit-banging the single I/O pin on the CPU is your idea of a good time.
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.
I think this was asked way back, but have you considered assembling a kit or playing with a well-documented microcontroller development board? Perhaps you could stand to work on your fundamentals a little more before building a machine like this from scratch.
Last edited:
BlackCow
New Member
I lol'ed
Also I agree, he does seem to lack some of the fundamentals but this is one hell of a way to learn them.
I am curious, why did you choose to build with the 8085 and not a more modern or popular CPU?
I thought I was the only kid messing around with this thing :D
Last edited:
glitch
Veteran Member
The consensus seems to be that it was chosen because it's part of his coursework!
Naturally, the reason it was chosen for coursework in the past and is still used as a learning tool today is because it's a clean, easy-to-understand CISC processor. That's why I decided to use it in my single-board computer design (http://www.glitchwrks.com/8085projects ) -- that, and I didn't want to build /another/ Z80 SBC!
I use the SOD Flash Test as a simple "is the circuit alive?" test, but the SOD pin isn't too useful for real I/O. That listing of my code that RITESH keeps copypasta'ing will of course only work if the memory map is the same as mine, if it's left unmodified. The modification is trivial, but if you're not to that level yet, do a halt test first. You can check the two 8085 status pins to see if the processor has halted.
Chuck(G)
25k Member
If you like the Z80 instruction set, but prefer the 8085 bus structure and clocking, there's always the NSC800.
If you like late CP/M style applications, a Z80 is a definite plus. I've been frustrated with my 8085 gear with not being able to run some programs.
When Bill Godbout/Compupro had their 8088-8085 CPU board, one of the early modifications was to fit it with the NSC800.
If you like late CP/M style applications, a Z80 is a definite plus. I've been frustrated with my 8085 gear with not being able to run some programs.
When Bill Godbout/Compupro had their 8088-8085 CPU board, one of the early modifications was to fit it with the NSC800.
Eudimorphodon
Veteran Member
When I took the first "hard" computer science course in college a painfully clear pattern emerged:
A: Approximately 20-30% of the class nailed every assignment without breaking a sweat. Straight As.
B: Maybe another 10-20% sort of squeaked by. Maybe they were as smart as the "A" group but lazy/slow/unfocused, or perhaps they weren't quite as smart but were able to make up for it with sheer hard work. And:
C: The remaining 50% COMPLETELY didn't get it. Not at all. They weren't bad people, they weren't even dumb people, but beyond a certain depth they just couldn't follow an algorithm or concept anymore. I tried to help some of those people (without just doing their work for them) a few times and just never found a way to do it effectively.
It gives me too much of a headache to read back through this thread to really know if a "Category C:" in a formal EE course is what we're dealing with here, but the one thing I'd say *if* that's what's going on is this: Sure, copying stuff off the Internet *might* get you past an assignment assuming you're not caught (Remember, professors and TA's are able to use Google too.) but it's not going get you past the final.
It seems like the OP is at least somewhat familiar with electronics in a vacuum but is really weak at computer concepts. A good low-level programming course (or book) might really be helpful for remedial work.
Chuck(G)
25k Member
I dropped into this thread against my better judgement and regretted it.
I have a policy of not doing someone's homework for them.
One of these days, I'll learn... :sigh:
I have a policy of not doing someone's homework for them.
One of these days, I'll learn... :sigh:
MikeS
Veteran Member
I'm surprised you hung in as long as you did...
Even allowing for language/culture differences, "What the hell are you waiting for............?? just tell me direction rest of my hard work" isn't really going to make folks eager to help.
The Internet seems to have brought a real sense of entitlement to this sort of thing; instead of reading and Googling some of the many, many useful books and other info out there, some people seem to think that these forums are places where you find unpaid consultants/teachers whose job it is to do even your basic research and work for you.
Being polite, saying thank you, or even just acknowledging a response whether it was helpful or not does not seem to be relevant in this context to some people...
