Beware for I have some noob questions
I've always wanted to make a homebrew z80 computer but have no idea where to start. I've dealt with micros but never dealt with a processor before and every homebrew project I've seen went way above my head.
I've found a site that has the CM\M ASM files for the Z80
http://www.cpm.z80.de/source.htmlAs well as the processor its self
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=269-3895-NDI know some basics like the address lines are used to address ram and ROM and the data lines are bidirectional it has a 16-bit address bus and an 8-bit data bus
My first question is: Does the processor address the first address in RAM on boot like the 8088\86 processor. and if so is the CPU responsible for transferring the firmware from ROM to RAM or does that have to be done with external circuitry.
My 2c. I began my microprocessor world with the 6800 and the Z80, then later the 8080. This was a long time ago.
I recall with some aged confusion, one of these 3 addressed memory from top to bottom, so the boot code had to reside within a fixed location likely 0000, since on power up, it would begin reading from 0000 and work up. I don't recall if electronics did the transfer from ROM to RAM, I think the ROM must occupy the boot memory addresses the CPU will read on start up and thus, all the initializations must be there.
THey still make the microprofessor and clones of it, so you can purchase the hardware since writing software for it in hex, is fairly time consuming.
http://en.wikipedia.org/wiki/Micro-Professor_MPF-Ihttp://flite.co.uk/microprofessor-mpf-1b-z80-training-system.htm
The "classic" Z80 that you plan to use has a single memory address space from 0 to 64KB. It doesn't distinguish between ROM and RAM, it just asserts the address, rd/wr and mreq signals whenever memory access is needed.
The reset vector is 0x0000. You would normally map some kind of a ROM memory here that contain your application/firmware and map some RAM elsewhere.
Please have a look at the ZX Spectrum machines:
http://en.wikipedia.org/wiki/Sinclair_ZX_Spectrumhttp://www.worldofspectrum.org/documentation.html#manualsThose are the most widely know Z80 computers. The implementation uses 16KB ROM (EPROM) chips from 0 to 16KB and the rest is RAM. Some versions include memory bank switching for multiplying the available address space.
Also, if you go for a ZX-Spectrum clone, you can instantly use a wide library of software, including CP/M.
Wow, a Z-80 project today.
Rodney Zaks' book was the bible on the Z-80.
Mine became very dog eared as I read it on the train many times going to/from RMIT.
I even have a Microprofessor I was given many years after I had finished RMIT, we used these at uni at the time and they had a nice fluorescent 14 segment display.
Never been fired up though by myself!
And yeah the Z-80 sets the program counter to 0000 upon reset and starts reading opcodes from there.
Other processors used vector tables and other techniques, but a simple lets start reading from 0 was the Z-80's approach.
One unique feature the Z-80 had at the time was shadow registers to avoid wasting time doing context switches in interrupts, very handy.
The "classic" Z80 that you plan to use has a single memory address space from 0 to 64KB. It doesn't distinguish between ROM and RAM, it just asserts the address, rd/wr and mreq signals whenever memory access is needed.
The reset vector is 0x0000. You would normally map some kind of a ROM memory here that contain your application/firmware and map some RAM elsewhere.
Please have a look at the ZX Spectrum machines:
http://en.wikipedia.org/wiki/Sinclair_ZX_Spectrum
http://www.worldofspectrum.org/documentation.html#manuals
Those are the most widely know Z80 computers. The implementation uses 16KB ROM (EPROM) chips from 0 to 16KB and the rest is RAM. Some versions include memory bank switching for multiplying the available address space.
Also, if you go for a ZX-Spectrum clone, you can instantly use a wide library of software, including CP/M.
Thanks, do I need any other Zilog branded chips to make this work or do I just need the CPU, Parallel ram that has 16 bit addressing and 8 bit databus, and similar ROM.
I'll check those links out when I get home from school.
AFAIK the absolute minimum is a Z80, a clock, RAM, and something for i/o, at minimum 8+ LEDs. For input you'll need to make 8+ electronic switches that are debounced. This type of base computer will be machine language programmed in binary and output is in binary.
For rapid testing, you can use a function generator in lieu of a clock, so you can ramp up the clock speed in case timing issues make operating erratic at the rated speed.
The "classic" Z80 that you plan to use has a single memory address space from 0 to 64KB. It doesn't distinguish between ROM and RAM, it just asserts the address, rd/wr and mreq signals whenever memory access is needed.
The reset vector is 0x0000. You would normally map some kind of a ROM memory here that contain your application/firmware and map some RAM elsewhere.
Please have a look at the ZX Spectrum machines:
http://en.wikipedia.org/wiki/Sinclair_ZX_Spectrum
http://www.worldofspectrum.org/documentation.html#manuals
Those are the most widely know Z80 computers. The implementation uses 16KB ROM (EPROM) chips from 0 to 16KB and the rest is RAM. Some versions include memory bank switching for multiplying the available address space.
Also, if you go for a ZX-Spectrum clone, you can instantly use a wide library of software, including CP/M.
Thanks, do I need any other Zilog branded chips to make this work or do I just need the CPU, Parallel ram that has 16 bit addressing and 8 bit databus, and similar ROM.
I'll check those links out when I get home from school.
Wow, a Z-80 project today.
Rodney Zaks' book was the bible on the Z-80.
Mine became very dog eared as I read it on the train many times going to/from RMIT.
I even have a Microprofessor I was given many years after I had finished RMIT, we used these at uni at the time and they had a nice fluorescent 14 segment display.
Never been fired up though by myself!
And yeah the Z-80 sets the program counter to 0000 upon reset and starts reading opcodes from there.
Other processors used vector tables and other techniques, but a simple lets start reading from 0 was the Z-80's approach.
One unique feature the Z-80 had at the time was shadow registers to avoid wasting time doing context switches in interrupts, very handy.
Haaa! The Z80 and the ZX80 (wipes tear from eye!). I don't think people will ever again get that same buzz as you got from playing with one of these.Rodney Zaks has given permission for distribution of his book Programming the Z80 and it can be downloaded here
http://www.z80.info/zaks.html If you really want to get geeky search for the unsupported codes then try to find an assembler and disassembler the support them
. The one I used was written by a lady Called Toni Baker in her short lived but much loved fanzine, but there were others.
Edit> Fixed link
If you really want to get geeky search for the unsupported codes then try to find an assembler and disassembler the support them . The one I used was written by a lady Called Toni Baker in her short lived but much loved fanzine, but there were others.
Edit> Fixed link
Thinking back to my RMIT days, I probably should have submitted the Z-80 cross assembler I wrote that ran on a 6809!
It never really crossed my mind as the task was to build a piece of Z-80 hardware.
As for the undoc'd instructions, they actually make perfect sense when you look at the binary patterns of the opcodes, and the "holes" in the instruction tables.
Yes, this was all part of understanding the real opcodes to build the cross assembler.
[/quote]
Thinking back to my RMIT days, I probably should have submitted the Z-80 cross assembler I wrote that ran on a 6809!
It never really crossed my mind as the task was to build a piece of Z-80 hardware.
As for the undoc'd instructions, they actually make perfect sense when you look at the binary patterns of the opcodes, and the "holes" in the instruction tables.
Yes, this was all part of understanding the real opcodes to build the cross assembler.
[/quote]
Yes the undocumented opcodes do make perfect sense when you look at the binary pattern ,but unfortunately they do not perform as expected (corruption of the flag reg I seem to remember) which is why they were left out of the official listing, I think the standard workaround was to push and pop the flag reg before and after there use if the flag status was needed to be preserved.
If you are feeling up to it, you can implement a bank-switched page in the memory space which can be used as a
fast external memory outside the 64K to contain the BDOS image when you are using CP/M. That way the infamous
BDOS load error can be avoided during warm boots. It also chews up the FCB table a lot less, if you are using flash
memory for the filesystem.
J.R.