Home built Z80 computers
Bob Yates
http://www.hanssummers.com/
About a quarter of the way down the page is his Z80 computer projects
ziggy
Bob Yates <bob...@centurytel.net> wrote:
Perhaps a group sponsored Z80 project might be fun? I know there is the
P112, but I'm thinking of something 'traditional'.
Bill Gunshannon
I still have an un-populated Xerox-820 board up in my attic somewhere.
Maybe I should just put it up on Ebay? Wouldn't that be about as
traditional as you can get?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Jeff Jonas
Do you remember where you bought it?
I too bought an unpopulated bigboard but it came with the ROMS
and very complete information including schematic.
I just gave away my 3 complete running Xerox bigboards
because I just can't get around to using them,
particularly since I'm focusing on single board systems
such as PIC and eZ80.
--
-- mejeep deMeep ferret!
Bill Gunshannon
je...@panix.com (Jeff Jonas) writes:
>> I still have an un-populated Xerox-820 board up in my attic somewhere.
>
> Do you remember where you bought it?
Hamfest in Middletown, NY. I was really into Packet Radio in
those days and planned to set up a BBS. But I ended out
concentrating on the transport side of things.
> I too bought an unpopulated bigboard but it came with the ROMS
> and very complete information including schematic.
>
> I just gave away my 3 complete running Xerox bigboards
> because I just can't get around to using them,
> particularly since I'm focusing on single board systems
> such as PIC and eZ80.
Obviously, for various reasons, Inever got around to it either. :-)
Lee Hart
> Perhaps a group sponsored Z80 project might be fun? I know there is the
> P112, but I'm thinking of something 'traditional'.
I'd be happy to share the desing for my Databug. It's a 6.5" x 2.5" PC
board with a Z80, two bytewide memory sockets for up to 1meg of memory,
bank switching logic, two serial ports (on RS-232, one special), a
3-channel A/D converter, and switchmode power supply. It was designed
for a data logger, but could run CP/M using the memory above 64k as its
disk. Not exactly traditional, but very cheap (all the parts cost under
$20).
Another thought I've had is to make boards to reproduce the Heathkit H8
computer. It's a very simple, generic design, easy to build and modify;
and it easily runs CP/M.
--
Ring the bells that still can ring
Forget the perfect offering
There is a crack in everything
That's how the light gets in -- Leonard Cohen
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net
pbetti
(at least) i'm interested.
BTW it's never a good thing to loose this kind of projects / schematics.
Tarkin
Hans' site isn't the only good one; there's about a
half-dozen or so that I rate from 'good' to 'excellent',
Hans' being the gold standard- his inclusion of
schematics, and the walk-through of the logic behind
his VD circuits are simply a joy to read. I'm too darn
tired to think of the other sites, but Google Dincer Aydin
and coprolite software, to get ya started. I remember
before signing up for this site tracking down many a page
form google searches like "z80 home homebrew built made"
and others. A case of virtual R/C cola goes to the person who
can two pix of robots built with the z80! If only ever found two,
at least that were billed as such.
I'll be lurking to see what becomes of this thread.
Nighty-nite,
Tarkin
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> I'll be lurking to see what becomes of this thread.
>
Steve Ciarcia, Byte Books, McGraw-Hill, 1981. I know that the
power supply part can be disregarded...one can always use a
"canned" PC supply. I am *not* sure about the availability of
the other parts used in the design in this book.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Don
This is just a bunch of random ramblings on my part but I was thinking
of system loosly based on the Xerox 820-1. All of the schematics for
this system are available and so is the source code for the ROMS. I
would drop the video circuits and use one of the serial ports for
communication with a terminal emulator. All those DRAMS could be
replaced with a single byte wide SRAM chip. I also have the Plus-2 ROMS
but don't have the source. I also have the circuit for the double
density controller adaptor which the Pluse-2 ROM supports. All of the
Z80 family chips are still available. Anyway, just thinking outloud.
Don
Tarkin
to restate a question I had Gaby put up on the
Z80 site she manages (under 'software sites'):
Does anyone have a good, well-rounded tute
on serial-port programming for the Z80 family
SIO/SCC chips? I have 1 or 2 of the Z085300
SCC's, however, I am under under the impression
that the chip is signal/code compatable with the
early SIO's...much like the Z80 is compatable
w/ the 8080. The SCC is very feature-laden...
to the point that the documentation becomes a
slow read for someone as impatient as myself.
I am familiar w/ the basics of serial communications;
I just don't want to have to re-invent the wheel.
Some nice example code which demonstrates
initializing the registers, interrupt vs. non-interrupt
implementations, and external circuitry do's and
don'ts are what I am looking for.
>I also have the Plus-2 ROMS but don't have the source
If you have an older-ish pc, dos or win98, the free
Hitec C compiler, some skills, some components,
and the the inclination, you can hack together a
parallel-port ROM reader. I made a four-chip
EEPROM programmer with the above list.
The command sequences for writing and block
erase, and the latch firmware were the hardest
parts to code (oh, and the UI, but that's 'cos I
am a horrible C programmer). The project was
a blast, and I learned *a lot* about firmware
and such. For free, and it's age, the Hitec C
compiler is purty darn nice, IMO.
Well, now I am just rambling.
Cheers,
Tarkin
Jeff Jonas
>on serial-port programming for the Z80 family
>SIO/SCC chips?
*oy* I cannot find the source to the
SDLC driver I wrote years ago.
I remember
- preferring the AMD databook to the Zilog
for the chip descriptions and register programming
- initializing the registers is NOT just from 0-15
but in a specific sequence, depending on the chip's mode.
Therefore the initialization code is specific to each port's mode:
sync or async, clock source, full SDLC or partial, etc.
- I used interrupt mode and the most important thing to remember is
keeping the driver's state machine in sync with the chip's internal state
for each port. Not every state change causes an interrupt
(ex: writing a character to the XMT buffer clears the xmt status bit),
so my driver kept a copy of the PREVIOUS state
and XOR-ed that with the current state register
to ascertain what change caused the interrupt.
ziggy
"Don" <micr...@att.net> wrote:
Oddly enough i just ran across that book in my garage this last weekend.
From what it looks like from first glance, its still doable, and could
reduce the parts count greatly by using a small/cheap pla/cpld/fpga.
Though that might make it less 'real' in the process.
Tarkin
registers initializtion being specific to operating
parameters and port mode, but it's gotchas
like keeping a copy of the xmt status that I
suspected would cause hours of r&d and
forensic debugging.
I am off to hunt down the AMD spec/docs.
To birng us back on track, what's the consensus
on a z80-based homebrew? Book? Databug?
Shameless eastern-bloc rip-off of the p112?
Xerox-clone[1] (snicker)?
Thanx,
Tarkin
[1] I am old enough to remeber when mimeographs
were replaced, the new process was called
"Xeroxing".
Don
I remember "using" mimeograph machines. Xerox didn't exist at that
time. :-)
My reason for suggesting the 820-1, or bigboard for that matter, is
that it is a fairly stable starting point. I have know idea of the
skills of the readers of this list so thought a known starting point
would be good. I had an 820-1 many years ago. It reminded me of two
aircraft carriers parked side by side. :-) That puppy was big!
Anyway, the design could be simplified and then expanded on. My 820 was
hacked to the max. I had doubled the speed from 2.5 to 5 MHz, added the
double density adaptor, hard drive interface, 68000 co-processor and
changed the video timing to use a hercules monitor. It looked more like
a high rise apartment complex than a computer board. :-)
Don
j...@cimmeri.com
I have a complete, functional 820-1 w/ 8" floppy drives, diskettes, and
manuals that I reconditioned. Thinking of selling soon.
But what would be the point in another homebrew z80 w/ serial port?
Much easier to assemble an S-100 w/ Z80 cpu.. something else I have
done recently. IMSAI chassis, Cromemco ZPU, CompuPro Ram17
64k+Disk1+Interfacer1. CP/M 2.2 so far, is booting and running from
ROM. I plan on making a graphics + voice syn board too.
One cool idea might be to make a Z80 SBC with the above features,
including the graphics (TMS9928) and voice (SPL0256). THen see if we
can make any graphics games that will run under CPM, and share them.
~ J
Dave Griffith
> Thanks for the tip. I realized the bit about the
> registers initializtion being specific to operating
> parameters and port mode, but it's gotchas
> like keeping a copy of the xmt status that I
> suspected would cause hours of r&d and
> forensic debugging.
> I am off to hunt down the AMD spec/docs.
> To birng us back on track, what's the consensus
> on a z80-based homebrew? Book? Databug?
> Shameless eastern-bloc rip-off of the p112?
> Xerox-clone[1] (snicker)?
If you want to do something like the P112, that is, be entirely
compatible with it, you'll have to do some rather delicate surface-mount
soldering. Those two surface-mount chips aren't available in
through-hole packages.
If it's a Bigboard clone, then you'll probably have loads of "fun"
tracking down currently-available parts and an increasingly rare naked
CRT. Old serial terminals are easily and cheaply available.
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Terry Gulczynski
"Tarkin" <Tark...@gmail.com> wrote in message
news:1144892003.2...@t31g2000cwb.googlegroups.com...
> Shameless eastern-bloc rip-off of the p112?
Why do a rip-off? The P112 is available now; it works well, runs
fast, and carries the 'standard' CP/M I/O compliment, ie, 2 x Serial,
Parallel, and 1.44MB Floppy ports. It runs at 16MHz, has been tested
at 18.432MHz, can carry up to 1MB RAM, and has some expansion
capability. It comes with ZSDOS and a fully-implemented Z-System.
[Shameless plug] And there is a P112-specific GIDE adapter kit (IDE
HD interface) available, too - also available now. It comes with Hal
Bower's B/P BIOS, tailored to the P112, and adds a banked ZSDOS,
RamDisk, and multiple IDE partitions with up to 512MB of HDD storage.
Included is the ability to use the P112-GIDE to read CDROM disks and
copy files to the P112 HD.
So again, why do a rip-off?
Terry Gulczynski
P112 info here:
http://www.cs.csubak.edu/~dgriffi/proj/p112/
P112-GIDE info here: http://home.cfl.rr.com/tgcons/
Tarkin
>P112, but I'm thinking of something 'traditional'.
This was suggested by ziggy.
>I'd be happy to share the desing for my Databug <snip>
>Another thought I've had is to make boards to reproduce the Heathkit H8
>computer. It's a very simple, generic design, easy to build and modify;
>and it easily runs CP/M.
Sayeth Lee H.
And den:
>Sounds like a very nice design. If you could really share the project
>(at least) i'm interested. (pbetti)
>How about taking a look at _Build Your Own Z80 Computer_, by
>Steve Ciarcia, Byte Books, McGraw-Hill, 1981. (Charles R)
>This is just a bunch of random ramblings on my part but I was thinking
>of system loosly based on the Xerox 820-1.
Up to this point, I thought simplicity and 80's-ish parts were the
order of the day.
>reduce the parts count greatly by using a small/cheap pla/cpld/fpga.
>Though that might make it less 'real' in the process. (ziggy)
Which kinda (IMO) wandered away from the 'point'; thus the bit about
'less real' (I think! I don't presume to speak for ziggy!)
My quip about the P112 was meant as kind of a joke...I am very
aware of the availability of kits, and the plans + schem's + source
(kudos, BTW; an excellent endeavor, all the way 'round!). I also felt
that the P112 was kinda too high-tech for what I felt was the 'point'.
The Eastern-Bloc bit was a reference to all the field-expedient cloning
of computers that went on days gone by. Spectrum clones, for example.
There are some Bilingual Polish,Czech, and Russian enthusiasts out
there
who are doing laudable work on documenting these fascinating machines,
and the joke was not meant to offend in any way, either to our
bit-brothers
in the East, or any of the fine developers of the P112.
Besides, after reading about some of the struggles you (the P112 folks)
had
during serial comm's debugging, I thought that that experience would be
much
less harrowing and far more enjoyable if working on a hombrew project,
and
not under a shipping or release constraint.
As far as the grafix vs. tty debate, I thought that there might be a
middle ground
between two extremes I've read about:
1) The PIC vcr-pong game. If you haven't heard about this, check it out
here:
http://dt.prohosting.com/pic/pong.html
Anywho, this has got to be graphics output at it's most basic. I was
wondering
if it wouldn't be feasible to adapt the concept to an output for a
homebrew
Z80-based comp, with text at first and graphics later.
2)Hans' work. I consider Hans' work the other end of the Spectrum
(snicker).
While brilliant, it seems complex. Of course, on challenging days, a
baked potato
seems complex to me...
But I am also entirely for doing the user I/O as a tty: I have a
Toshiba T1200 and
an Apple p.b. 145, as well as various win and linux boxes that beg to
be put
to use as terminals.
Dambit, I am rambling again. I blame the potatos.
TTFN,
Tarkin
ziggy
dgr...@cs.csbuak.edu (Dave Griffith) wrote:
Personally i dont think 'cloning' anything is the right idea, it should
be something unique, designed from scratch.
I also agree that we will have to make some concessions for the loss of
'classic' components over the years, but i would think we should get by
with a bare minimum of 'modern' parts in this thing.
Lee Hart
> I'd be happy to share the design for my Databug. It was designed for
> a data logger, but could run CP/M using the memory above 64k as its
> disk. Not exactly traditional, but very cheap (all the parts cost
> under $20).
> - Z80
> - 2 bytewide memory sockets, up to 1meg memory, bank switching logic
> - two serial ports (one RS-232, one special)
> - 3-channel A/D converter
> - switchmode power supply.
pbetti wrote:
> Sounds like a very nice design. If you could really share the project
> (at least) i'm interested.
I don't have a website, but would be happy to post the schematic or
board layout. Anyone have any suggestions on where to put them?
But the Databug is a specialized solution, intended for another purpose,
but that can be "pressed into service" for CP/M. There are of course
hundreds of Z80 systems already for which the same could be said. People
will always pick the one they already happen to know, or have, or can
get cheap.
I think if the goal is to home build your own computer, then the design
has to be *suitable* to be home built. That means it should avoid parts
that are expensive or hard to get. It should avoid assembly difficulties
like surface mount or tight spacings. It should be well documented. And
lots of people should have "passed that way before", so you can follow
in their footsteps, rather than have to re-invent everything yourself.
I've been thinking about doing this for a long time, and have discussed
some ideas on this newsgroup. I thought about recreating the Altair
8800, but it has too many parts and is basically not a very good design.
I looked at the IMSAI 8080, which is a better design; but there are
still lots of expensive parts (100-pin edge connectors, expensive
switches). Plus, it's already being done.
So, my current thought is to recreate something like the Heathkit H8. It
was designed to be built as a kit, and so is particularly easy to build.
It came with the legendary Heath quality manuals, written so *anyone*
could build it. In its basic form, you got a 2 MHz 8080 CPU card with 1k
monitor ROM, 8k RAM card, and front panel card with keypad and 7-segment
LEDs. The cards were large; 6"x12", with all chips socketed and very
large spacings and pads for easy soldering. The cards use pin-and-socket
connectors (Molex KK series; 0.025" square pins on 0.1" centers) to plug
into a 10-slot motherboard with a 50-pin bus.
There were *lots* of accessory cards to add the Z80 CPU, memory, serial
and parallel ports, cassette and disk controllers, color/graphics,
sound, etc. Being home built, and since Heath provided full schematics,
board layouts, source code listings, etc. lots of people built their own
boards.
Several disk operating systems were used; CP/M (several versions), HDOS
(Heath Disk Operating System), FORTH, UCSD Pascal P-System, etc. The H8
was highly compatible with the Heath H89 and Z-100 (running on the
8085); most software worked the same on all of them.
The H8 cabinet was much simpler than most S-100 boxes, and can easily be
built with flat aluminum sheets and simple tools. It had a linear power
supply and no fan (convection cooled).
I think we could build a "clone" of the H8 that is fully compatible
software-wise, but uses more modern parts to simplify construction and
reduce cost. Modern 74HC chips reduce power and noise, and it takes
fewer of them to perform the same functions (octals instead of quads,
etc.) The entire 64k memory is now a single CMOS bytewide chip, rather
than dozens of 4k chips.
The greatly reduced chip count would allow smaller boards -- this gets
the price down considerably. The "motherboard" could be just a ribbon
cable with the desired number of IDC connectors crimped onto it.
Rather than the now-rare Molex KK bus connectors, use 25-pin D
connectors for the bus; they are common, reliable, and mechanically
rugged.
I'm not sure what to do about the disk controllers, though. The Heath
designs used Western Digital chips, which are now hard to get and not
very sensible for a new design. But if something else is used, (765?),
then all the hardware has to be redesigned and all the software
rewritten.
Any thoughts?
Lee Hart
> Personally i dont think 'cloning' anything is the right idea, it should
> be something unique, designed from scratch.
If you start from scratch, then it's a lot more work to ever reach even
a modest level of functionality. It would be likely to become a project
that never gets finished.
> I also agree that we will have to make some concessions for the loss of
> 'classic' components over the years, but i would think we should get by
> with a bare minimum of 'modern' parts in this thing.
I agree. Though it is tempting to use "new improved" parts, in may cases
they are also single-sourced and availability is poor. Probably 9 out of
10 new ICs won't survive; their manufacturers will soon give up and drop
them.
I tend to stick with generic multiple-sourced parts that have been
around for 10 years or so. Once they have a broad user base, they tend
to *stay* around much longer. So the odds are good that I will still be
able to get a replacment part 10 years in the future.
Tarkin
>board layout. Anyone have any suggestions on where to put them?
I can offer either/both my yahoo and comcast personal websites.
yahoo :
pros: that site has been around for awhile, and will likely remain
that way.
cons : heavy advertising.
comcast :
pros: Less advertising, the site is (for the moment) 'cleaner'
(as in less cluttered), easy file management (for me!)
cons: It's dependant on my Dad's comcast account. If he
gets a twist in his shorts and cancels his subscription, I
lose my sub-account.
My thoughts about the project in general:
While I would love to dive into an ASIC project, I also
love simplicity, commonality, and ease-of-replacement:
If I release the magic smoke on an ASIC, I'm gonna
be pretty mad. If I smoke a Z80 or '138, I can get over it
much easier and faster.
A lot of machines were built without an ASIC- Kaypros,
the H8, and many others. Lot's of homebrewers out there
manage quite nicely without them as well.
I'm all for using a pre-existing design for a starting point;
but I don't wan't to shy away from rewriting
(maybe even large) portions of the code, if it will serve
our purposes- such as the idea of upgrading the H8's
1701 (? WD) in favor of the 765. As an aside, I have a
765A, and was wondering when I'd get around to using it.
I propose setting some 'baselines' - issues we can agree
on now - to get the ball rolling.
proposals -
Z80 @ 4MHz : is there a reason to be slower or faster?
Disk Controller: 765A (cuz I have one ;o) )
True I/O : as opposed to memory-mapped. [1]
Rsvd Ports : for options like color/grafix/sound [2]
CP/M : (was there ever any doubt?) 2.2 for simplicity?
Drives: 3.5" cuz they're thick in these parts.
[1] This is a wonderful feature of the Z80, that requires
only two to four gates to implement. And I am a byte
hog; the thought of sacrificing RAM addy's for hardware
just makes me itch.
[2] In this way I am kind of signaling that I am leaning
towards a tty design. But I like the thought of leaving
'room' for people to extend the base design in their own
way- implement their own customized peripherals and
the code to use them.
After writing all of this, I just realized the H8 was an 8080
based design. Which actually doesn't affect much as far as
my proposals are concerned, I don't think. The 8080 only has
512 I/O ports, which is still probably more than I'll *ever* use,
but the Z80 did some cool things with diffferent out(~~) instr's.
I guess the both biphase clock and the bivoltage supply of the 8080
scare me.
Lemme know whatcha think.
-Tarkin
wild bill
>serve
>our purposes- such as the idea of upgrading the H8's
>1701 (? WD) in favor of the 765
Upgrading? Who (or what) are you people, anyway?
Bill
who:
1-bought one of first Xerox 820s ever sold (1981)
2-discovered its many many limitations
3-found designer, called him, learned about Bigboards
4-built two BB IIs, one for friend, one for myself (1982)
5-used BB II extensively for several years
There is no better Z-80 implementation anywhere
than the BB II. It has all the support chips: the CTC chip;
the DMA chip; the PIO chip; the full blown SIO chip,
and is the classic 'everything in the Intel databook
implementation' with the addition of a SASI interface
and the ability to program it's own BIOS ROMs.
You need either a keyboard and a monitor OR a
serial terminal (or a computer that looks like one)
And, of course, what ever kind of storage you can
wire up - drives, tape, paper tape, whatever.
It has an extensive built-in monitor that does
almost everything but write programs for you.
Which includes, INing and OUTing whatever
bits it takes to get all your I/O working right.
You don't even need an operating system to
save and get bits from your storage device(s).
Meaning: you can start from SCRATCH and
work up your boot interface, then paste it
onto ANY Z-80 operating system image, from
any device you can read from, and then
save it out to ANY storage device you have.
If you don't have ANY, then burn yourself
a ROM of the thing. It's even got extra
sockets to stash hardprogrammed code.
They didn't leave anything out. Period.
Because of it's hardware interface capabilities
there is NO WAY you can do it all with ANY
emulator. The BB II is/was uniquely versatile.
Call it the pinnacle of Z-80 development systems.
(and, it is impossible to emulate the 1791/3 type
disk controller with a 765. IT CAN NOT BE DONE.)
IBM and the others chose the 765 at least in part
because of it's 'ability' to protect THEM and their
precious softwares from unauthorized copying.
Which included, making safety backups yourself.
With the 1793 you can copy ANYTHING, with the
only exception being those little laser holes. For
some reason they forgot to give it a turn-on-the-
laser output port. Probably so you wouldn't
accidentally burn up your disks. Anyway, not too
many disk drives came with them (hole burners).
And, maybe 'weak' bits. Not too sure about them.
wild bill
wrote:
>
>There is no better Z-80 implementation anywhere
>than the BB II. It has all the support chips: the CTC chip;
>the DMA chip; the PIO chip; the full blown SIO chip,
>and is the classic 'everything in the Intel databook
>implementation' with the addition of a SASI interface
>and the ability to program it's own BIOS ROMs.
>
Well, okay, so try Zilog Databook.
Ever since, it's been Intel On My Mind.
With an occasional AMD breeze.....
Bill
ziggy
"Tarkin" <Tark...@gmail.com> wrote:
> >I don't have a website, but would be happy to post the schematic or
> >board layout. Anyone have any suggestions on where to put them?
>
> I can offer either/both my yahoo and comcast personal websites.
>
> yahoo :
> pros: that site has been around for awhile, and will likely remain
> that way.
> cons : heavy advertising.
>
> comcast :
> pros: Less advertising, the site is (for the moment) 'cleaner'
> (as in less cluttered), easy file management (for me!)
> cons: It's dependant on my Dad's comcast account. If he
> gets a twist in his shorts and cancels his subscription, I
> lose my sub-account.
>
> My thoughts about the project in general:
>
> While I would love to dive into an ASIC project, I also
> love simplicity, commonality, and ease-of-replacement:
> If I release the magic smoke on an ASIC, I'm gonna
> be pretty mad. If I smoke a Z80 or '138, I can get over it
> much easier and faster.
>
A fpga is really tempting me as well, for about 150 bucks and i have
plenty of hardware to do most any z80 project ( or 6502, etc ) i want,
and if i is crew it up, just erase it and start over.
But, that sort of takes away from the whole retro idea and wouldnt be as
much fun..
Tarkin
>idea and wouldnt be as much fun.
I wholeheartedly agree. I was tempted, as
well, after looking at the Spartan3 dev
board from http://digilent.com .
I have a decent machine running CRUX linux
2.0 (eveolution), w/ gcc 3.4, and all sorts o'
libxxx's; I also have the J2SE sdks for win
and linux; but I get my kicks from writing
'Hello world!' using cp/m, MAC, and ED.
(My main box, the one I usually compose
my thoughts to the groups on, is a WinXP box)
I am not entirely against the idea of using the BBII
as starting point, either; I've heard good things
about it before.
I am also totally for using modern equivalents
of some of the componenets from yesteryear:
one of the prev. posters mentioned octal vs.
quad latches (registers? something), and his
point about the lower power consumption of
the HC devices is spot on; I don't believe
that these enhancements will violate the
spirit of the OP's project idea.
I guess the idea of using an fpga suggests
(to me) using a more robust fpga, and
implementing all of it on a single chip, or
use an fpga + 2/3 support chips, and do
it all surface mount on a credit-card sized
card.
My interpretation of the OP's intent for the
proj was something that would use cheap,
readily-available components, easily assembled,
and that the design would be something a
reasonably bright 10-12 year-old could
assemble, grabbing an elder for assistance
w/ the programming & firmware.
TTFN,
Tarkin
Don
Tarkin wrote:
> >But, that sort of takes away from the whole retro
> >idea and wouldnt be as much fun.
>
> I wholeheartedly agree. I was tempted, as
> well, after looking at the Spartan3 dev
> board from http://digilent.com .
>
>
> TTFN,
> Tarkin
This is just another bunch of random ramblings on my part so take what
you want and leave what you don't want. :-)
I was thinking of sticking to the standard Z80 and its support chips,
WD279x FDC and the GIDE interface. All of the "glue logic" would be
implemented in a couple of CPLD (Atmel or Xilinx). The parts are not
that expensive, $6 to $12 each, and don't require any special
programming hardware. The parts are in system programmable through the
JTAG port. The development tools are free.
Don
ziggy
"Don" <micr...@att.net> wrote:
How about a modular approach?
Sort of like a PC102 concept. We design seperate boards with some sort
of 'universal' bus, and people choose what features they want, beyond
the basic cpu board.
One board for video, another for IDE..
Of course everything will need to be done with CPM in mind, but i would
think a modular approach would make it fit most anyones needs.
( spending this weekend myself digging for z80 books in my garage, and
see what chips i have left .. its been a while but i think this might be
just the excuse to dust off all my old equipment, and braincells, and
actually do something with real hardware again. Going thru life as a
software guy is hard for an old EE like me :) )
Or am i way off base here in this day and age and should just be content
with my z80 card in my IIGS?
Tarkin
I am having fun with the C128. I RTFM for
once, and realized you CAN use cp/m
in the 40-col tv mode. So I knocked around
with Mac and Ed. Fun stuff!!
(*Thank You ETG!!!!*)
I have a couple of proposals for a middle
ground on this.
If the CPLD's are that low, I am guessing
that their gate count is as well.. So design
the glue logic in such a manner as to allow
implementation as a single CPLD or a handful
of 74-series logic devices. Combined with
the idea of either reserved ports or addy's,
this would leave a design that is consistent
(from a software point of view), but gives
a lot of room for the indiviual implementor.
Leftover gates could be connected to the
reserved ports/addy's to provide custom
peripherals- like ISP or video or audio
or cassette controls. The core chips-
uP, disk controller, ram, rom, sio,
ctc, pio, etc all need their specific pins
tended to. It will simply be left to the
individual to choose which 'black box'
he sticks between those chips.
Don - got any links to specific vendor's
pages on CPLD's in that range, and/or
the tools? I'm going to google up on
JTAG & connectors for same. I guess
I should come out of the 80's.
"Take, on, meeeeee......."
(take on me)
"Taaaake meee onnn...."
(take on me)
"I'lll beeee gooooneeeeee......'
-Tarkin
pbetti
for you or just for the project itself, as you like.
Simply let me know if you're interested in this space.
This also is giving me the idea that ALL of the works of this thread
can be hosted on my server if the people here likes the idea.
It would be nice to create a dedicated forum on the site too....
pbetti
response to Lee Hart:
> I don't have a website, but would be happy to post the schematic or
> board layout. Anyone have any suggestions on where to put them?
Sorry.
-Piergiorgio
ziggy
"Tarkin" <Tark...@gmail.com> wrote:
I have a C128 as well :) And an osborne 1 ( though the keyboard is
acting up and isnt reconized at all... )
Xilinx has inexpensive CPLDs and FPGAs. Plus their design tools are free
for home use.
Don
Tarkin wrote:
> Darn your socks!! Is it fun (the IIgs + card)?
>
A modular approach would be an excellent idea. Take the video circuit
like that on the bigboard or xerox as an example. All those counters
and glue logic to generate the sync and video signals could be drawn as
a single sub-circuit using your favorite TTL logic. That same circuit
could also be run through a logic compiler to produce the data file
needed to program a single CPLD. Now you have two ways to go to get to
the same result.
The GIDE is another perfect example. The 74xx646 is getting hard to
find and the design uses two of them plus a 16V8 and 20V8 GAL. The
whole thing would fit in a single CPLD.
All of the memory and I/O decoder logic is another place that a CPLD
could be used to good advantage.
I will start another discussion and share what I know about CPLD's.
Don
P.S. Please excuse my spelling and bad grammer. Not to bother anybody
with my problems but I have dyslexia which makes my spelling bad and my
ability to express myself in words next to impossible.
Jonathan Graham Harston
"Don" <micr...@att.net> wrote:
> > [1] I am old enough to remeber when mimeographs
> > were replaced, the new process was called
> > "Xeroxing".
>
> I remember "using" mimeograph machines. Xerox didn't exist at that
> time. :-)
fluid....
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
Jet Set Willy Resources - http://mdfs.net/Software/JSW
Tarkin
ziggy: I have two Kaypros that I am hoping
to Frankenstein into one working beasty.
The keyboard issue on your Osb is probly
due to either corrosion or connector
mechanical failure, IIRC some of the
previous discussions from this very board.
A dis-assembly and inspection of the kb and
connectors may well be in order.
(>>for an old EE like me <snip> oops!
why am I giving you advice on hardware?
<recovering from dumb attack>)
CPLD's in the 6-12 $ range....how sharp is the
learning curve on VHDL? (or what's that other
whiz-bang language?). You guys are tempting
me w/ the dark side....
While trying to read up on the BB, one site
quoted someone as saying the Kaypro was so
similar (to the BB) that it was considered by
some to be an unlicensed copy. If that's the
case, or if the video systems are even vaguely
similar, then I am for tty. The Kaypro's video
section makes my heard spin when I try to
comprehend it. Video is one place I'd
definitely go in for using a CPLD or
even a microcontroller (a la VCR Pong),
so as to keep it's headaches separate from
the rest of the system. Divide and conquer,
I say.
In any event, I feel that either a tty, a manual-
entry (switches/keypad)+lcd, or both should
be in place as a development bootstrap and
emergency system saver. As a not-quite-
expert linux user who likes to run as root,
I usually keep a small partition on my linux
machines w/ a 'stock' distro like slackware 8
or mandrake 7.2 or RH 6 in case I screw up a
script and lock myself out of my (main) system.
I also keep bootable cd toolkits (linuxcare BBT)
and flopppies (tomsrtbt). I may not use those
failsafes regularly, but they darn sure are handy
when the unexpected happens.
TTFN,
Tarkin
p.s before I get flamed by 'professional'
linux users, the machines that I run as root
on are *not* production servers or mission-
critical; I have no sensitive data on them.
Running as a separate user and having to su
everytime I wanna clip my toenails just
irritates me.
Dave Griffith
> A modular approach would be an excellent idea. Take the video circuit
> like that on the bigboard or xerox as an example. All those counters
> and glue logic to generate the sync and video signals could be drawn as
> a single sub-circuit using your favorite TTL logic. That same circuit
> could also be run through a logic compiler to produce the data file
> needed to program a single CPLD. Now you have two ways to go to get to
> the same result.
> The GIDE is another perfect example. The 74xx646 is getting hard to
> find and the design uses two of them plus a 16V8 and 20V8 GAL. The
> whole thing would fit in a single CPLD.
What's the deal with the 74x646? Fairchild is currently making them.
You can get them from Mouser, but not Jameco.
Terry Gulczynski
"Dave Griffith" <dgr...@cs.csbuak.edu> wrote in message
news:3Yj1g.12385$4L1....@newssvr11.news.prodigy.com...
> What's the deal with the 74x646? Fairchild is currently making
> them.
> You can get them from Mouser, but not Jameco.
Jameco carries the 74ABT646 version - I've purchased 40-50 of them.
I've used 646 chips from the F, ALS, HC, and ABT families - all work
as intended in the GIDE.
Terry
Holger Petersen
>A modular approach would be an excellent idea. Take the video circuit
>The GIDE is another perfect example. The 74xx646 is getting hard to
>find and the design uses two of them plus a 16V8 and 20V8 GAL.
>All of the memory and I/O decoder logic is another place that a CPLD
>could be used to good advantage.
How about the Floppy-Controller?
It might be difficult to get a real 40-pin Chip these days; even
a version for the IBM-PC with some other IO may be hard to get...
Would it be possible to do a 765 like AND a WD-like controller
into one CPLD with the possibility to dynamically re-program that
chip 'on the fly'? I preferred th WD chip in those old days. And
I once had to read a Floppy with 128 Bytes in DD, which would
have been impossible on the 765.
Just asking, Holger
Don
Terry and Dave. I stand corrected on the 74xx646. I typically look for
the LS, HC & HCT parts which I didn't find until I looked at the
B.G.Micro catalog. I did find the parts previously mentioned in the
DIGI-KEY and Jameco catalogs. While Mouser is a good source of parts I
have never used them so didn't look there.
The one thing I like about these groups is that while one person my not
have all the answers or may have incomplete information, collectively I
think we have all the bases covered.
Don
Don
Doing an FDC chip in a CPLD might be pushing it a little. The bigest
part that will fit in a socket is an Atmel ATF1508 with 128 registers.
I'm not sure the circuit would fit in that part. B.G.Micro has a fairly
complete line of 17xx and 27xx series FDC chips as well as the 765 and
the 9216 data seperator chip.
Don
Tarkin
1.29 USD, in stock and available in 40 pin. Not
uncoincidentally, they have it in their 'IC/Z80 &
Support' section. And in *40 pin* (gasp!). I do
not work for them; I am a satisfied customer.
They were my one-stop shopping source when
I got bit by the Z80 bug. They have IMHO a
pretty decent selection of microprocessors
from yesteryear, and while the prices aren't
bargain-basement, I do like their IC section's
organization. Well, enough lip-service.
>I once had to read a Floppy with 128 Bytes in DD,
>which would have been impossible on the 765.
I am confuzzled. The spec line on the 765 from
JDR lists it as an 8MHz SS/DD FDC. Re-reading
my doc's on the specific chip I have, it seems like
it will read 128-byte sectors, but only in FM mode.
I'm no expert on the subject, so please feel free to
edumacate me. If using the 765 is going to cramp
our style in any way, then I am for using the WD
chip, esp. in light of Don's revelation of their ]
availability from BG Micro (I've done business w/
them, too, and was pleased).
As I stated, I'm no expert on FDC's- in fact,
part of my motivation for this project is to
learn about such things from the very basest
level- and frmware just doesn't get much more
basic. I say let the debate begin- 765 vs WD17xxx
(what is 27xxx? upgrade/advanced features?).
Pro's and Con's of each.I'm off to research the WD
device(s).
TTFN,
Tarkin
wild bill
>than the BB II. It has all the support chips: the CTC chip;
>the DMA chip; the PIO chip; the full blown SIO chip,
>and is the classic 'everything in the Intel databook
>implementation' with the addition of a SASI interface
>and the ability to program it's own BIOS ROMs.
>
I think I'm confusing it with a Bonneville stock market
data receiver/decoder I took apart some time ago.
If it matters, I just hauled out one, and I don't see a
PIO chip anywhere. And, there are TWO of the CTCs.
Ferguson used TTL for the assorted parallel I/Os.
And, there is a 6845 video controller, which might
be of interest to some ...
Oh, and Allison - I think we were talking Z-80, not 8080.
S-100? gimme a break! A proper Z-80 would be all
on one board, because the BUS was not designed
to allow spreading the support chips across it.
The interrupt support in S-100 is little more than
putting a garage door opener on a commode.
The Z-80 support chips were DESIGNED to allow
interrupt driven, higher performance operation.
Not that many people ever WROTE anything that way.
If all you want is a cheap Z-80, get a Timex Sinclair.
Bill
Tarkin
I don't feel like I can get at it's guts and do
some real I/O without knackering it right
proper.
CP/M, striclty speaking, was an 8080 OS,
the 68000, Z8000, and 8086 vs's notwithsatanding.
The various 'aftermarket' CCP's and such all
leveraged some aspect or other of the Z80
beyond what features the traditional 8080
CP/M offered.
I think that there is a real possiblity here of
creating a project that will offer a wide range
of challenge possiblities- from the
'ho-hum another Z80 board w/ CP/M' to
a complex, CPLD-boosted microcomputer
leveraging the full power of the Z80.
My personal desire is to is help to contribute
to a design which is flexible enough to encompass
that broad spectrum.
I really do like the P112's design; it's simply
out of my budget at the moment. I do have
a bunch of Z80 and related parts, though;
so I'd like to make something and contribute
to it's design. Er, that is, I am/was planning
on build ing a Z-80/CP/M beastie anyway;
why not collude with others who are doing
the same thing?
And please, do tell me more about that 6845
VC chip......
p.s. Did anyone have anything to contribute
on the FDC issue??
TTFN,
Tarkin
Tarkin
I know. I read a thread a while back, before 'subscribing'
to this group, where you talked about programming for
both co-processing and shared-memory access w/
8-bit(IIRC) processors. Compelling stuff!
>Thats both good and bad as the directions you can go are
>oppsites!
True enough. I like to think of it as sort of like
Monster Garage; taking bits, peeling them back
to bare iron, and then modding it to your heart's
desire.
I'll say this again: I believe that if the design is
both simple and elegant, with specific I/O
ports and/or mem. addy's reserved for specific
functions, the 'black-box' approach should
work for the glue logic. If you're a poor hick
like me, you use TTL chips harvested from
the junk-o-copia and spares bin (and R*dio
Sh*ck, that 7-11 for your component needs,
they're unloading all sorts of IC's for a
comparative bargain). If you're an EE type,
or whiz-bang college student, or a have
a bigger hobby budget(not just $$, but Tau,
which in some equations = $$), you do it
in a CPLD, and use the rest of the macro-cells/
gates/whatever for your own purpose, for
example cascading to another device for video.
>Memory lapse? What FDC issue <snip>
>>As I stated, I'm no expert on FDC's- in fact,
>>part of my motivation for this project is to
>>learn about such things from the very basest
>>level- and frmware just doesn't get much more
<ed v v v v v v v v v v v v vv v v v v v v v v v v v v >
>>basic. I say let the debate begin- 765 vs WD17xxx
<ed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >
>>(what is 27xxx? upgrade/advanced features?).
>>Pro's and Con's of each.I'm off to research the WD
>>device(s).
My main beefs w/ the 765 is this nugget from the
NEC 765A spec sheet (the chip I have):
"The µPD765B does not require synchronisation
between the CLK and WCLK inputs."
The CLK I've used successfully (on another project,
not floppy-related) was a 3.59xxxMHz
jobby, most likely intended for TV use. I was wondering
how in blazes I was going to sync it w/ a 250KHz or
500KHz!! Or is it as simple as just gettting a new integral
(i.e. 4.00MHz) CLK.
>Booting is handeled with big (32kb or larger) EEproms
That's what I did on the my other project- a 256-KB
multi-sector FLASH jobbie scavenged from a dead
mobo- worked great. Tied the upper unused bits
lo for testing, eventually planned for some latching[1]
scheme to use it as a sort of flash-ram-disk.
>A CF card is cheaper and easier to implement
>once your past the socket.
I've considered that. I also have a 32 or 64 MB
disk-on-chip, and wondered if it didn't beg to
be used on this sort of project. Would like
to see some more data on the CF idea.
I rigged my nano-system to boot from
the FEEPROM; it copied the relevant
code+data into the upper 32KB of RAM,
which included copy-down code, jumped
to the upper 32K, did the I/O voodoo to swap
in the lower 32K of ram, and the copy-down
code copied the actual intended executable
code+data back down to 0000h, RST 0,
and voila! Sticking with that cumbersome model
has but one advantage: it doens't matter
what's providding the data in the lower 32K (
or whatever size rams one uses) on boot;
just copy high, bank in the ram, copy low,
RST 0, and presto!
[1]:which was how I programmed it- using 3 latches,
a 2-to-4 line decoder, and some inverters, and a
PC parallel port. Not the simplest design, but
it worked, and could program every bit. I learned
a lot from that project.
>Opinion:
>If you have atleast one system that satisfies the floppy needs
>then just wite or find some serial file transfer code. And forget
>a floppy.
I'll take that opinion and use it to make my case for
tty/SIO/SCC as a necessity. Floppy seems like
ars gratia ars, or just a plain ol' pain in the ars.
> <snip> but mounting and programming
>are issues most people will not want to tackle.
Which also has prevented me from working
w/ surface mount.
Thanks for you're input Allison!!
TTFN,
Tarkin
Dave Griffith
> I always thought the P112 was cool but in some repects
> it was a closed system where adding IO was going to be
> harder.
Closed? Last time I checked, everything about it is freely
redistributable. The OS (ZSDOS) is GPLed. I don't know how design
files can be GPLed, but Dave Brooks told me he wants them distributed in
a similar spirit.
craigm
> On Thu, 27 Apr 2006 03:55:01 GMT, dgr...@cs.csbuak.edu (Dave
> Griffith) wrote:
>
>>Alliso...@nouce.bellatlantic.net wrote:
>>
>>> I always thought the P112 was cool but in some repects
>>> it was a closed system where adding IO was going to be
>>> harder.
>>
>>Closed? Last time I checked, everything about it is freely
>>redistributable. The OS (ZSDOS) is GPLed. I don't know how design
>>files can be GPLed, but Dave Brooks told me he wants them distributed in
>>a similar spirit.
>
> You misunderstood. Closed as in single board most signals not
> available at edge connectors and internal configuration is as is.
>
> I know the idea of closed usually means software and prints
> unavailable. However a small board like that is not as hardware
> hackable.
>
> Allison
Aren't most, if not all, of those internal signals on the expansion
connector? The board layout isn't fixed either, it was changed to support a
different battery.
Full documentation is available.
I wouldn't consider it a closed system.
craigm
Don
Tarkin wrote:
> 765A's can be had from JDR MicroDevices for
> 1.29 USD, in stock and available in 40 pin.
>
>
> As I stated, I'm no expert on FDC's- in fact,
> part of my motivation for this project is to
> learn about such things from the very basest
> level- and frmware just doesn't get much more
> basic. I say let the debate begin- 765 vs WD17xxx
> (what is 27xxx? upgrade/advanced features?).
> Pro's and Con's of each.I'm off to research the WD
> device(s).
>
> TTFN,
> Tarkin
Sorry for the long delay in answering the quaestion about the WD279x
series parts.
The WD 1770/1772 were the first generation SD/DD FDC chips by Western
Digital (WD). The WD1771 was a SD FDC chip. The next family of parts
was the WD179x second generation of SD/DD FDC chips. These chips
required an external data seperator when working at the higher data
rates. The last and final series was the WD279x series of parts. These
parts have a built in data seperator as well as a few other
enhancments. If you want to use WD parts then the 279x series is what
you want.
As pointed out the 765 is also available. B.G.Micro is a good source of
the these and several of the WD parts. B.G.Micro also carries the 9216
data seperator chip in an 8-pin dip. If you use the 765 or WD179x
series parts you will also need the 9216.
I've looked for some of the other FDC chips mentioned (National 8473
and SMC 37C665) but can't find any place that has them in stock.
One final note on standard Z80 parts. Again, B.G.Micro seems to have a
very good selection of 2.5, 4 and 6MHz parts.
One note about B.G.Micro. They are a good place to do business with but
they seem to be at the bottom of the components "food chain". In other
words, when places like DIGI-KEY, Jameco & JDR stop carrying an old
part. B.G.Micro starts picking them up. So their your last chance to
get an old part. Word to the wise, If you buy from B.G.Micro, buy a
lot!
Don
j...@cimmeri.com
I'd like to make a proposal as well.
Goals:
This project needs to be easy to build AND finish, so that more people
will actually do so... something we can mount on a wooden base to get
started with, wire by hand, find parts to, and see fast results from.
Project also needs to be a little different than everything else thus
more interesting to see end results. I argue that doing yet another
Z80 project is just too predictable in outcome. So here's what I would
like to do.
- single board with expansion room (no bus is needed if we have the
main features from the outset)
- 6809 CPU (this will take us into lesser known territory)
- 2 x serial port -- one for terminal, one for data transfers.
- separate graphics output (TMS9928 is simple chip to design around)
please no IBM 6845 vid chip.
- no floppy chip (circuitry too complicated! I want to actually have
time to finish this project!)
- CF storage
Our tasks would then be to translate CPM -> 6809 unless it exists
already, or use a new operating system altogether. Allison already has
a lot of experience in this area.
Now, I know you all are talking Z80 project, but I thought this would
be a fun, new direction to go and maybe some of us can do something
like this, and others can go the Z80 route. But instead of
endlessly debating which is the typical outcome of "committee driven"
projects, some of us who are serious can quickly choose the components
that make sense, keep the project SIMPLE yet COOL, and get our asses in
gear towards having fun.
~ J
Don
I can't wait to see where this goes. :-)
Don
Charles Richmond
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Dave Dunfield
>I'll let Dave comment if he notices.
Ah another chance to post a plug for CUBIX !
(Hey Allison, hows your system coming?)
I have published a small 6809 design to run my CUBIX OS - this has been
getting a bit of interest lately and there are a few other people currently in
the process of building up systems.
Here is a bit more information:
In the mid 80's I designed a little 6809 based computer system, including the
hardware and all software. The operating system is called CUBIX, and may be
of interest to anyone who wants to build up small homebrew computer. Here is
some information to consider:
- The system is designed to give high functionality with minimal hardware - you
can build a completely operational CUBIX system with a fairly small handful of
parts. (I have built working CUBIX systems in a single afternoon).
- CUBIX is designed to be very portable - it can handle pretty much any I/O
devices and disk geometry, and you can even change to new devices or
redefine the disk geometry "on the fly". The system is so portable, that many
system ports can be done from nothing more than the ROM image (I provide
a detailed porting document).
- CUBIX itself occupies the better part of an 8K ROM, and provides a nice file
system, a command line "shell" (including a good selection of built in
commands and "script/batch" files), and over 100 system calls/services.
- There are a few dozen applications and utilities, which include
- All the standard file and system maintenance utilities
- Several editors, including a fairly decent one which operates line-
by line or full-screen visual.
(The system includes a TTY specification subsystem which allows you
to taylor the screen oriented programs to pretty much any terminal.)
- HELP : A vax/vms like help command, which provides interactive
documentation to all commands, applications and utlities.
- ASM : 6809 assembler, and RAID : a fairly powerful 6809 debugger.
- BASIC
- C A complete implementation of my Micro-C compiler (in fact the
6809 was the first target for the compiler).
- FORTH : A very fast FORTH which compiles to directly executable 6809
machine code instead of threaded lists.
- MAPL : A little APL system.
- SIM80 : An 8080 simulator - allowed me to run most of the code I had
written for my Altair on CUBIX
(I included on the disk as examples, an 8080 BASIC
interpreter, and an 8080 CHESS program)
- Lots more...
- The system is quite mature/stable - I used it as my main computer for several
years, and there has been a small base of other users. (At one time I sold
the software as a commercial product).
- The system is very well documented. The main documents are:
- CUBIX system users guide
- CUBIX system programming manual
- CUBIX porting guide
- Separate documents for all of the major applications.
- The distribution "documents" diskette, as a 360k 5.25" disk which contains
nothing but documentation, and it is completely full - not a single free
sector.
- All source code, documentation and bnaries are now freely available.
(Excluding the C compiler which my commercial compilers are still based
on).
- I have provided schematics for a simple CUBIX system using a serial console,
and matching sample drivers.
- I have done a PC based simulator for my original D6809 portable computer,
which allows you to try the system out by running it (full functionality) on
your PC. I also have a command to import/export individual files to/from the
simuilator disk images, and you can use my ImageDisk program to transfer
disk images back and forth between the simulator image files and physical
CUBIX compatible diskettes.
Although it would be considered a "toy system" by modern 32/64 bit standards, a
CUBIX system gives you a pretty powerful computer with minimal hardware, and can
be a very rewarding small project (as a number of people have told me over the
years). It also gives you a very unique system that you won't experience
anywhere else.
I invite/encourage anyone who wants to experiencing building a small/useful
computer "from the ground up" to check out the CUBIX system - Most of the
material mentioned above can be found on my web site (See URL in sig) - go
to the the "Dunfield 6809" computer under "Homebuilts".
>>I thought that the MC6809 was a *difficult* part to obtain...
>FYI: there is also the Hitachi HD6309 so there are more of them than
>most think and they will be found embedded in stuff. Apparently they
>are not so scarce.
6809s can still be found ... and yes, the 6309 is a very good substitute
(get the 63C09 - it runs at 3Mhz - bus speed - equivalent to 12Mhz or so
by other vendors numbers).
Btw -a floppy controller doesn't have to be all that hard ... the one I
include in my design is 765 based (easy to find), and IIRC it's about
10 ICs.
Regards,
Dave
--
dave06a@ Collector of classic pre-PC computer systems.
dunfield. If you have an old 8/16 bit non-PC system in need of a good
com home, please contact me at email address on the left, or
via contact link of this web site:
http://www.parse.com/~ddunfield/museum/index.html
j...@cimmeri.com
As a follow up -- if the 6809 idea would present too many obstacles..
ie. in CPU availability, or in having any software tools for it, then
as a second choice, the Intel 8051 or 8052 would be another odd way to
go. I've never used one of these so am not sure if the instruction
set is 8080, but compilers already exist for it, and decent core speeds
are available. If you're not familiar with this CPU, read the descrip
below -- sounds like a fun chip.
http://en.wikipedia.org/wiki/Intel_8051
Allison -- what is available for the 6809 in terms of monitors and
software dev tools? Would we be stuck at ground zero, or are there
some interesting things to get started with?
Don
Alliso...@nouce.bellatlantic.net wrote:
> On 1 May 2006 09:08:40 -0700, "j...@cimmeri.com" <j...@cimmeri.com> wrote:
>
> >
> >As a follow up -- if the 6809 idea would present too many obstacles..
> >ie. in CPU availability, or in having any software tools for it, then
> >as a second choice, the Intel 8051 or 8052 would be another odd way to
> >go. I've never used one of these so am not sure if the instruction
> >set is 8080, but compilers already exist for it, and decent core speeds
> >are available. If you're not familiar with this CPU, read the descrip
> >below -- sounds like a fun chip.
>
> http://www.parse.com/~ddunfield/museum/index.html
>
>
> > http://en.wikipedia.org/wiki/Intel_8051
>
> Know the part, used them . Not a suitable machine for an OS as it's
> targeted as a embedded processor.
>
> >Allison -- what is available for the 6809 in terms of monitors and
> >software dev tools? Would we be stuck at ground zero, or are there
> >some interesting things to get started with?
>
> there is a whole world of difference in design and programming.
>
>
> Allison
Dave Dunfield's little CUBIX system is a clean and simple design to
implement. I have had it on my stack of things I want to do for a long
time now. Just can't find that "round tuit" yet. :-)
As Allison pointed out, the 8051/8052 just isn't suited as the core of
an OS. If you want an embedded controller it's very good.
Back to the 6809 and porting CP/M to it. This is just my openion but it
would be like cutting down an oak tree with a butter knife. :-) You
might get it done someday but what would you have?
If you really want to get into the 6809 there are a few other DOS's
available. One is called FLEX and was produced by Technical Systems
Consultants (TSC) back in the late 70's. Most, if not all, of the
software is now in GPL and freely available on the web. Versions for
the 6800 and 6809 were produced. As a side note, the 6800 version will
run on the 68HC11 family of processors. Another 6809 DOS is SK*DOS.
This is a FLEX compatable OS and versions for the 6809 and 68000 are
available under GPL. Getting back to TSC. If you really feel brave you
can tackle a system using TSC's UniFLEX DOS for the 6809. This beast is
a unix work alike and ran on a 6809 with a minimum 256K of RAM. Some
systems were in use with 1Meg of RAM. It's not for the faint of hart.
I've done a lot with FLEX. I have two 6809 systems and an HC11 system
all running it. I added an IDE hard drive to all of them and I have
access to a maximum of 128 partitions of 16 megabytes each, or just
over 2 Gigabytes.
Anyway, enough ranting about the 6809. This is supposed to be a Z80
project to run some version of CP/M or one of its replacements.
Don
Roger Ivie
> One comment on CP/M and non 8080 based cpus. Yes, you can port it to
> most anything and there are sources in C (CP/M-68K) to make it easier.
> However what you end up with really fails the "so what" test badly as
> all you do get is a OS like CP/M that has a compatable filesystem and
> NONE of the 8080/8085/NSC800/z80 base of software will run on it.
Bear in mind that it's possible to extend the CP/M-68K program loaders.
You could very well make a system that, when it sees a .COM file, fires
up a Z80 interpreter to run it.
Of course, this wouldn't work too well on a 6809...
--
roger ivie
ri...@ridgenet.net
Dave Dunfield
>Bear in mind that it's possible to extend the CP/M-68K program loaders.
>You could very well make a system that, when it sees a .COM file, fires
>up a Z80 interpreter to run it.
>Of course, this wouldn't work too well on a 6809...
Why not?
I did exactly this under CUBIX - When I first built the system,
I still had a pile of code (mostly my own) on my Altair - I
write an 8080 emulator for the 6809 which allowed me to use
most of that code with very little changes - the 8080 engine
is still included in CUBIX - IIRC it's about 3k of 09 code.
It might even be possible to put together an OS emulation
package which would run some CP/M software under
CUBIX - but the OS itself is quite different from CP/M,
especially in the file structure on disk, so anything which
relied even a little on disk structure (common in CP/M)
would have a problem.
Having said that - if you want a Z80 CP/M system ---
then by all means build a Z80 CP/M system. I think the
6809 suggestion was made in the spirit of learning about
something different.
Regards,
Dave
--
Dunfield Development Services http://www.dunfield.com
Low cost software development tools for embedded systems
Software/firmware development services Fax:613-256-5821
Tarkin
>P112, but I'm thinking of something 'traditional'.
(Ziggy^^)
>Anyway, enough ranting about the 6809. This is supposed to be a Z80
>project to run some version of CP/M or one of its replacements.
>Having said that - if you want a Z80 CP/M system ---
>then by all means build a Z80 CP/M system
I do respect all of the posters- even though it appears
that Wild Bill has one too many Ginger Ale's before
posting- however, those three lines above sum up
how I feel about the topic at this point. Furthermore:
CUBIX is not CP/M. Please do not take this personally,
Dave. I just feel this topic has gone a bit wobbly, and I
would like to see it re-centered. Dave has been anything
but selfish in sharing his wisdom and experience with the
'net, as well as the group. 'Nuff said.
To refocus : system base proposal
CPU : Z80 ***
Code that is in the base (BIOS,BDOS,
and CCP) must not be MHz-dependant.
Optional modules - MHz-dependant code
would be, well, optional.
Memory Model : 2 X 32KB SRAM
With the price of SRAM these days,
a debate on the merits of DRAM is not,
IMHO, warranted.
Boot xROM : Phantom .5 - 32 KB
Phantom as in : upon cold boot
or h/w reset, 0000h points to the
boot device. Choice of device is
left to the implementor (imp).
Could be PRAM, EEPROM,
CFLASH, or OTP-ROM; imp's
choice. The only hard and fast
rule is it should 'disappear' after
copying 'stub' code to the upper
32K.
(This does not, however, preclude
the device from reappearing as
a ramdisk,etc -ED)
I further propose reserving
I/O port 0001h for this task.
After the lower 32K ram is swapped
in, 'stub' code is copied back down
to 0000h, which then loads the
BIOS from wherever- disk, tty,
or the xROM; imp's choice again.
It may be desirable to have this
optional functionality as a h/w option-
I propose I/O port 0002h be reserved
as such.
Console Services Priority:
The console- tty, keyp&lcd,
or blinkenlights&toggles,
should be of primary importance.
I strongly propose the implementation
Status LED's, perhaps controlled by
a latch mechanism. I further propose
reserving I/O port 0004h for writing
(& reading?) the h/w Status.
>I've been playing in the realm
>of LCD display and small keyboard with a
>PAD style input (up/down/left/right and select buttons)
>and menues. The idea is to develop a user interface
>that is still text based but one traverses menues
>(pull downs?) to do routine tasks rather than
>entering commands. Something to think about?
I bought a 25-key pad from B.G. Micro a while ago, and
they have it in stock again: http://tinyurl.com/fm52u
Note in particular the function keys, F0-F3 ;
I'm thinking DIR & PIP should be hard-coded
to F0 & F1.
The Shift key doubles the # of functions to 8.
Left & right could be Shifted for Up & Down.
And the hex characters speak for themselves.
For those who are exceptionally patient, a
key sequence (Shift <pause> Shift <pause> +)
followed by a function key could 'shift' the alpha-
bet down - ie Sh+Sh+F1 maps A-F keys to
G-L, and Sh+Sh+Sh+DEL = Z.
The HD44780-based lcd modules are fairly
prevalent, and damn easy to work with.
Line-based code could be worked out
to deal w/ disparate-lined modules.
(An IOBYTE thing, maybe??)
Well, I think that's enough for tonite.
Thanks all,
Tarkin
Roger Ivie
>
>>Of course, this wouldn't work too well on a 6809...
>
> Why not?
My concerns about emulating a Z80 on a 6809 are two-fold:
- Performance
- Available memory
I've not done much with a 6809 since I gave my little sister my trusty
CoCo III many many years ago, so I'm not entirely certain of the
performance. However, I doubt a Z80 interpreter on a 6809 would be very
peppy.
As for memory, well, the 6809 is starting out with less memory than a
Z80 to begin with (memory-mapped I/O; although you should be able to
bank switch it out), and the interpreter itself will need some memory
space.
Yeah, I've used a 2MHz Z80 with 32K RAM; it's possible, but not fun...
--
roger ivie
ri...@ridgenet.net
Roger Ivie
> On Tue, 02 May 2006 04:53:46 GMT, Roger Ivie <ri...@ridgenet.net>
> wrote:
>
>>On 2006-05-02, Dave Dunfield <Dave.D...@use.techsupport.link.on.my.website> wrote:
>>>
>>>>Of course, this wouldn't work too well on a 6809...
>>>
>>> Why not?
>>
>>My concerns about emulating a Z80 on a 6809 are two-fold:
>>
>>- Performance
>>- Available memory
>
> I've wire wrapped z80s that ran at 8mhz and had dynamic ram
> with no problems, Tim Olmstead wrote the book on how to do
> that and have it work well. For thouse unfamiliar it's on Gaby's
> site.
I was projecting the sort of performance you might expect from a Z80
emulated by a 6809. I suspect 2 MHz would be quite a bit faster than a
6809 can interpret Z80 code; I was getting much less performance from 16
MHz 386s back in the day when they were fast.
The 6809 is also limited to 64K of RAM, some of which would be required
to hold the emulator and (possibly) I/O space.
I was certainly NOT advocating building a 2MHz Z80 32K RAM system. Just
saying that interpreting Z80 code on a 6809 would NOT be fun.
--
roger ivie
ri...@ridgenet.net
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> As Allison pointed out, the 8051/8052 just isn't suited as the core of
> an OS. If you want an embedded controller it's very good.
>
> Back to the 6809 and porting CP/M to it. This is just my openion but it
> would be like cutting down an oak tree with a butter knife. :-) You
> might get it done someday but what would you have?
>
PL/M. If one could port a PL/M compiler to the 6809, then you would
be 80% there...right???
>
> If you really want to get into the 6809 there are a few other DOS's
> available. One is called FLEX and was produced by Technical Systems
> Consultants (TSC) back in the late 70's. Most, if not all, of the
> software is now in GPL and freely available on the web. Versions for
> the 6800 and 6809 were produced. As a side note, the 6800 version will
> run on the 68HC11 family of processors. Another 6809 DOS is SK*DOS.
> This is a FLEX compatable OS and versions for the 6809 and 68000 are
> available under GPL. Getting back to TSC. If you really feel brave you
> can tackle a system using TSC's UniFLEX DOS for the 6809. This beast is
> a unix work alike and ran on a 6809 with a minimum 256K of RAM. Some
> systems were in use with 1Meg of RAM. It's not for the faint of hart.
>
Shack Color Computer folks use this OS if they want something sort of
heavy duty.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> The emulator would manage IOspace and since 8080 only addresses
> 256 ports thats a trivial space. Also emulating 8080 is a far smaller
> and easier task that z80. CP/M does not require Z80.
>
I have little emulator experience myself. I know that the Z80 has
*more* instructions that the 8080. I understand that CP/M only
requires an 8080.
However, the 6809 seems well suited to the additional instructions
of the Z80. Both processors support PC relative branching and both
have two index registers. So how much harder could it be to add
the Z80-only instructions???
Charles Richmond
>
> As a follow up -- if the 6809 idea would present too many obstacles..
> ie. in CPU availability, or in having any software tools for it, then
> as a second choice, the Intel 8051 or 8052 would be another odd way to
> go. I've never used one of these so am not sure if the instruction
> set is 8080, but compilers already exist for it, and decent core speeds
> are available. If you're not familiar with this CPU, read the descrip
> below -- sounds like a fun chip.
>
back when. There *are* development tools on the web for them also.
ziggy
"Tarkin" <Tark...@gmail.com> wrote:
Looks good to me, just dont forget the port for the console :) I know my
direction would be a tty based 'main module' with all other cool I/O
like keypads and LCD on expansion modules.
I also agree that SRAM is cheap enough not to even consider DRAM.
Not being up on current day Zilog chips, do they have any MCU type chips
with a Z80 core that has all the ports built in? ( both SIO and PIO
mainly ). That could save on the parts count a bit.
Sort of like a 8051 having 90% of what we need on board ( not bringing
up the 8051 debate again, just a comparison of level integration )
j...@cimmeri.com
Yes, in the suggestion of doing something different. Seems some here
just want to reinvent the wheel... so that the wheel can roll just like
other wheels do. I guess that's got some interest value if you don't
already have a Z80.
The idea of translating CP/M to 6809 is not supposed to make sense...
but is a "do it because it's not been done" thing. Cubix sounds
great, but also a lot more complicated than CPM. I can wrap my small
brain around CPM .. can I do so with over-100-calls- Cubix? Don't
know.
It would also be interesting to see what a bunch of moderns could do
code-wise these days.. given 20-30 years of hindsite.. in recreating
CPM + utils + a few languages all anew.
Course, Dave's 6809 platform sounds like a great place to start too.
Even as a dev platform for the CPM idea.. assuming CPM would even hold
any interest after seein Cubix close up.
~ J
Tarkin
After the first four bits of the lower 8 of the addy bus,
dedicating the remaining four or using combos makes
for tough decisions, ones which I sidestepped using
2-4 line decoders + latches. The plan was to step up
to 3-8 line decoders at some point.
I agree a h/w console, while darn near necessary,
should be an acessory module, and not a set-in-
stone core requirement.
Having done some research, while there are
such devices (84C15 was my focus), the
packaging relegates these devices to the
'exotic' category, IMHO. QFP-100 is the
pack for the 84C15, which has the SIO,PIO,
CTC, and a Clock generator. 10-MHz in
single quantity from digikey for ~$17.
There is a nice mount available from:
http://www.engineeringlab.com/circuitboards.html#schmartmodules
(scroll down for the QFP mod's.)
So, this would shape up to be ~45$ for the
core- but has the advantage of not having to
decouple the 4 individual chips.
The grainy-arsed spec pdf is here:
http://www.zilog.com/docs/z80/dc2992.pdf
Actually, the more I look at it, the more I like it.
Research on some of the other popular IC makers
turned up nad, except for their own 8-bit MCU
offerings, w/ 20-50 different ways to skin the kitty,
and not one z80-based solution.
Actually, the more I look at it (84C15), the more I like it.
The layout is nice and logical, and looks like it will
lend itself well to routing the glue, memory, and I/O.
Looks like the core board would weigh in @ ~100$.
Well, now is the time for the sleepy.
TTFN,
Tarkin
wild bill
>It would also be interesting to see what a bunch of moderns could do
>code-wise these days.. given 20-30 years of hindsite.. in recreating
>CPM + utils + a few languages all anew.
You gotta be joking.
In the sixties, most ''programmers'' actually took courses intended to
teach us HOW to write programs. You didn't actually code anything
until you'd defined IN ADVANCE what you thought you were doing.
CP/M was crafted by a teacher of computer science. He engaged
in the academic excercise of inquiry during it's evolution. It's a
paradigm that doesn't exist any more. Screw your hindsight.
Just a couple examples:
I haven't seen anybody do a (new/current) flow chart in years.
There used to be something called 'specifications'. Until somebody
figured out you could be sued if you claimed your program actually
did something, and then a user could show it didn't, or it crashed.
Look at microsoft - biggest code house around. Still run by a bunch
of untutored hackers. Still producing bug filled crash prone garbage.
(I appreciate having the Linux alternative, but trying to remember
all that non-intuitive naming and syntax makes my head hurt)
Bill
Roger Ivie
>
> I haven't seen anybody do a (new/current) flow chart in years.
I do 'em all the time. But, then, I've been programming for 25 years...
--
roger ivie
ri...@ridgenet.net
Jeff Jonas
>with a Z80 core that has all the ports built in? ( both SIO and PIO
>mainly ). That could save on the parts count a bit.
I'm sorrowed to say that my eZ80 development kit
is still waiting for my schedule to open up :-(
Some resources:
http://circuitcellar.com/
Circuit Cellar Magazine had a contest for the ez80 developer's kit
and published the winners and related articles
http://www.dscinet.com/eZ80/
an ez80 BBS (and there's a Yahoo group for the ez80 too)
http://www.bamafolks.com/~randy/students/embedded/Z80_intro.html\
A nice z80 manual with schematics for a small system
used for the embedded programming course.
http://www.zilog.com/products/family.asp?fam=218
citing Zilog's web site for the ez80:
The next generation eZ80 is revolutionizing the high-performance MPU market
for today's 8-bit embedded applications. The eZ80 executes Z80 code
four times faster than traditional Z80s at the same clock speed,
and can operate at speeds up to 50MHz. Unlike most 8-bit MPUs,
which can only address 64KB, the eZ80 can address 16MB
without a Memory Management Unit.
The eZ80 also supports demanding TCP/IP networking applications,
featuring an Embedded Internet protocol stack
that enables the transmission of HTML form data
and the dynamic generation of web pages,
and supports additional higher-level networking functions
such as email and SNMP
The developer's kit has infra-red transceivers and 10/100-base-t built in.
--
-- mejeep deMeep ferret!
glen herrmannsfeldt
(snip)
> The older 8049 is subset of 8051. It is a Harvard archtecture
> meaning data storage and program storage are seperate. The
> 8049 only addresses 4K or program memory and 128 bytes of
> internal ram or 256bytes of external ram or IO. It's intended for
> embedded control.
There is one instruction for reading data from code space.
I don't think you can write code space, though, especially if it
is in ROM. (You could always add external logic if you use external
code.)
I don't remember if the Harvard architecture definition says anything
about reading code space (in addition to immediate data).
-- glen
Tarkin
<snip>
>This would make for a both
>compact and lowpower (even using
>Nmos parts) core that is easily expanded.
Which is, admittedly, one of the aims of
the project, AFAIK.
However, does the 8085 offer any
significant software enhancements over
the 8080? And the doubled clock
necessity seems kinda strange.
I want to clear on this issue: I love
the Z80 the way Ricky loves Lucy,
the way Beast loves Beauty, the way
Romeo loves Juliet. 65,535 I/O ports.
Shadow registers. Index registers.
Block search & move instructions.
A cpo[le of things did, however
intrigue me about the 8085
from Intels spec sheet:
* Binary, Decimal, and Double
Precision Arithmetic(<??)
* Non-Maskable TRAP
(Good for debugging??)
At the end of the sheet, I see the
two 'new 8085' instructions:
SIM & RIM, set & read interrupt
mask.
Also, what you save in terms of
simplicity is made up for by the
need for additonal glue logic, at
first glance.
I briefly thought that HOLD might
make for an interesting multi-proc
machine, using the 84C15 w/ slave
Z80's seems much more interesting.
Don't get me wrong, here folks;
at some point, I'd like to flirt w/ other
chips. But right now, I'm hot for
the Z80.
Wanna know what turned me off
to 68xx(x) uP's? The Apple
Powerbook 145b. While exceptionally
easy to use, trying to prgram for it
is a nightmare; old-school Macs of the
'90's vintage are an absolute pain
in the arse (IMO) to program for,
w/ out a dedicated separate (desktop)
box w/ MPW. And MPW is the bastard
child of a tryst between sh, Pascal,
and C. To this date, I have not
been able to code or assemble two
bits of 68030 code. I have assembled
bootsectors for Bochs, programmed
goofy little programs for linux,
made a custom 'C' program to access
my parport programmer under DOS,
and have used the SLR(Z80ASM) and
MAC assemblers. Apple remains
impenetrable to me. I'm not goind to drop
$2K to find out what OS/X is like.
</Apple Rant>
Anywho, I'd like to hear opinions
on schematic software and file formats.
I use TinyCAD, myself; I'm about to load
geda/gaf (a comprehensive linux collection
of related electronics s/w tools) for
review on my main box
(which is a dual-boot XP/Crux Linux
PI...@1.1GHz, 256MB [1]).
Toodles,
Tarkin
[1] I'm not trying to boast about my box;
it's obsolescent, but does quite a lot for
me!!
j...@cimmeri.com
Re: 8085.
By that token, why not the Z8671 (if available)?
There's two approaches being talked about here, and I don't want to
derail Tarkin's desires with the 8080/Z80 CPM machine idea. Someone
had mentioned recreating the H8, for instance. This would be really
nice, especially if a replica kit could be had. Although Heathkits
had problems (such as some of their kits looking like ancient relics
from the 1950's), the LACK of heathkits today is really depriving
modern generations of a wonderful and educational pasttime. And the
country wonders why we are weak in science and math (or whatever it
is).. it's not just the lack of Heathkits, but the whole attitude of
the masses that led to Heathkit's demise (among many other kit and
science type products). Seems the prevalent attitude today is to just
buy the car and go, rather than know how it works and service it too.
My computer idea is a parallel idea to Tarkin's - not a replacement.
Some might want to go the traditional route, but for others, it would
be more interesting to go off in a novel direction.. thus the 6809 or
some other unusual chip -- with whatever OS... but with some sort of
tie back to CPM, or at least to the *simplicity* of CPM so this can be
a homebrew project that can actually be accomplished in a reasonable
amount of time.
-
Re emulating 8080 on 6809 topic: is it possible, for instance, using a
6809 macro assembler, to write a macro for each one of the 8080
instructions, and then run 8080 code through the assembler to get a
working 6809 program?
~ J
Jeff Jonas
>65,535 I/O ports
>Shadow registers. Index registers.
>Block search & move instructions.
Ummm, the IN and OUT instructions used only 8 bits addressing,
unless you pre-loaded some register for the upper 8 address bits.
Even then, the Zilog native devices (PIO, SIO, CTC, DMA, etc.)
usually used 2 addresses per port (data, control).
Even the interrupt vector was a limitation:
7 bits vector (LSB was always 0),
but with devices using 2-3 vector bits for status,
that's only 4 vector bits left, meaning only 16 peripheral chips.
Unless you use the large STD bus card cage with lotsa I/O chips
directly to the CPU, it's rare to hit that limit.
I think the largest Z80 system I touches was a
16 port terminal server using 8: SIO chips and maybe a CTC.
I wanted so much to make a Z80 system maxed out with DMA, SIO and PIO chips
so I could just attach stuff, but I learned that I'd have to worry about
clock skew, clock buffering, interrupt ack look-ahead and such.
Happily, that was all in the Zilog Z80 manuals for the peripheral chips,
but not all in one place.
Tarkin
>using the C register, the C register is on the low address and the
>B register in on the high address. The result is for that
>instruction the addressing range for IO is 64k.
Listen to the pretty lady. 8^)
>meaning only 16 peripheral chips.
>16 port terminal server using 8: SIO chips and maybe a CTC.
Allison's clear elocution of the data from the
Zilog doc's reveals what it is I love about the
16-bit I/O space; it's not so much that I *ever*
think I'll even attach 16, or even 9 devices to the
z80's bus; the point is one can get clever w/
bit combos for demuxing/decoding et al.
I found this particularly useful in writing the
s/w routines to control a HD44780 and that
25-key pad I mentioned earlier in the thread.
Those upper bits came in handy for the
odd-sized keypad; 5x5 made for 5 rows+
5 columns, needing ten bits...it was easy
(ish) w/ a 16-bit bus.
Also, w/ the way I think we'd like to keep
this thing expandable, modular, and optional,
the I/O port cornucopia allows for modules
to be developed without fear of I/O port
collision.
I am almost swayed by the 8085, were it
not for my handy supply of 4 (&6)MHz
z80 parts. sssh! Don't tell ziggy that
if one choses to do things the hard way,
one can replace that QFP-100 84C15
w/ the handful of chips it replaces....the
84C15 merely puts all the silicon on one
chip....you still have to interconnect
them (correct me if I am wrong on this one;
the links for datasheets on the chip were
links to the regular old z80 cpu + periph'l
manuals). I could make a discrete,
multi-chip version and he'd never even know
it!! bwahahahahahahah!!
But seriously.....
Here's a question: iss a TV freq
crystal (3.59xxxxxMHz) not good
for baud rate? Is it unsuitable?
TFTTT[1],
Tarkin
[1] Too Friggin Tired To Think
ziggy
"Tarkin" <Tark...@gmail.com> wrote:
Hey, reduction of parts count is always good.. ( thats one reason FPGAs
appeal to me.. but that would be cheating :) )
I not opposed to a 8085... I just also has a supply of z80 items at
hand.
Don
Alliso...@nouce.bellatlantic.net wrote:
> On 4 May 2006 21:45:09 -0400, je...@panix.com (Jeff Jonas) wrote:
>
> >>I want to clear on this issue: I love the Z80 ...
> >>65,535 I/O ports
> >>Shadow registers. Index registers.
> >>Block search & move instructions.
> >
> >Ummm, the IN and OUT instructions used only 8 bits addressing,
> >unless you pre-loaded some register for the upper 8 address bits.
> >Even then, the Zilog native devices (PIO, SIO, CTC, DMA, etc.)
> >usually used 2 addresses per port (data, control).
>
> using the C register, the C register is on the low address and the
> B register in on the high address. The result is for that
> instruction the addressing range for IO is 64k.
At this point I'm a little bit confuzzeled (not uncommen at my age).
:-) I just read my copy of the Zilog Z-80 CPU technical manual and on
page 7 under pin description it clearly states the the Z-80 has 256
input or output ports. Depending on the addressing mode the top half or
the bottom half of the address bus can be used but it is only an 8-bit
wide address. If I'm wrong, and I could be, I would really like to see
some programming examples that illustrate how to access port numbers
above 255. For example, port 1024 or port 32768.
>
> <snipped>
>
> Allison
Don
Never mind...., I see whats going on. Very trickey! It's amazing what
you don't read in some tech manuals.
Don