2 Apr
2006
2 Apr
'06
6:41 p.m.
Although I've written several CP/M CBIOSes, I've never had to write one on
a system that used the Trap vector (0066h) for something essential.
Just curious--has anyone had to deal with servicing the Trap interrupt in
CP/M? How does one keep CP/M from clobbering the vector, since it's in the
FCB2 area?
Cheers,
Chuck
2 Apr
2 Apr
7:52 p.m.
Chuck Guzis wrote:
Although I've written several CP/M CBIOSes,
I've never had to write one on
a system that used the Trap vector (0066h) for something essential.
Just curious--has anyone had to deal with servicing the Trap interrupt in
CP/M? How does one keep CP/M from clobbering the vector, since it's in the
FCB2 area?
Chuck, I have no answer for you, but it reminds me of a point I've
always wondered about. The CP/M service call to 0005 takes three bytes
-- why didn't they move it three bytes forward so that the one byte "RST
1" call could have been used instead?
8:03 p.m.
On 4/2/2006 at 6:52 PM Jim Battle wrote:
Chuck, I have no answer for you, but it reminds me of a
point I've
always wondered about. The CP/M service call to 0005 takes three bytes
-- why didn't they move it three bytes forward so that the one byte "RST
1" call could have been used instead?
That answer would lie in the mind of the late Gary Kildall, I'm afraid.
AFAIK, only RST 7 is used in all of CP/M--and that's as a breakpoint patch
in DDT.
Cheers,
Chuck
8:12 p.m.
On Sunday 02 April 2006 07:52 pm, Jim Battle wrote:
Chuck Guzis wrote:
I've always wondered about that one myself...
And why it was necessary to stuff parameters into registers, when it's easy
enough to put 'em on the stack, among other things.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Although I've written several CP/M CBIOSes,
I've never had to write one
on a system that used the Trap vector (0066h) for something essential.
Just curious--has anyone had to deal with servicing the Trap interrupt in
CP/M? How does one keep CP/M from clobbering the vector, since it's in
the FCB2 area?
Chuck, I have no answer for you, but it reminds me of a point I've
always wondered about. The CP/M service call to 0005 takes three bytes
-- why didn't they move it three bytes forward so that the one byte "RST
1" call could have been used instead?
3 Apr
3 Apr
12:30 a.m.
On 4/2/2006 at 7:12 PM Roy J. Tellason wrote:
And why it was necessary to stuff parameters into
registers, when it's
easy enough to put 'em on the stack, among other things.
Well, memory fetches are slower than register references for one. It
requires stack space, for another. And the 8080 code to access the
arguments, while not awful, is somewhat clumsy:
lxi h, 2
dad sp
mov c,m
inx h
mov b,m
....or something like that to grab a word off the stack into BC.
Cheers,
Chuck
12:57 a.m.
Chuck Guzis wrote:
On 4/2/2006 at 7:12 PM Roy J. Tellason wrote:
I think the real reason (?) goes to a difference in cultures between
register rich and register poor machines IN THAT TIMEFRAME.
E.g., if you are writing code for a 68xx, you have little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Moving to something like a 99000 can be terribly distressing
for the register rich crowd to become accustomed to! ;)
--don
And why it was necessary to stuff parameters into
registers, when it's
easy enough to put 'em on the stack, among other things.
Well, memory fetches are slower than register references for one. It
requires stack space, for another. And the 8080 code to access the
arguments, while not awful, is somewhat clumsy:
lxi h, 2
dad sp
mov c,m
inx h
mov b,m
....or something like that to grab a word off the stack into BC.
1:25 a.m.
On 4/2/2006 at 9:57 PM Don Y wrote:
Moving to something like a 99000 can be terribly
distressing
for the register rich crowd to become accustomed to! ;)
I think the hardest machines to program for are the ones with "not quite
enough" registers. Programming an IBM 1620 is easy--there are no
accumulators, so there isn't much choice. Even a single accumulator calls
out a certain programming style. But, say 3 or 4 registers gets you taking
time to think about how to best use them. On the other hand, with the CDC
Cyber 200, you had 256 64 bit registers, so you could keep just about
everything in registers--no tough thought there. But on the 808x, there
are just few enough and they're orthogonal enough to make you think.
Cheers,
Chuck
2:33 a.m.
Chuck Guzis wrote:
I think the hardest machines to program for are the
ones with "not quite
enough" registers. Programming an IBM 1620 is easy--there are no
accumulators, so there isn't much choice. Even a single accumulator calls
out a certain programming style. But, say 3 or 4 registers gets you taking
time to think about how to best use them. On the other hand, with the CDC
Cyber 200, you had 256 64 bit registers, so you could keep just about
everything in registers--no tough thought there. But on the 808x, there
are just few enough and they're orthogonal enough to make you think.
I would say un-orthogonal myself. Other than the 8080,6800 & 6502
I can't think of any other architecture styles for 8 bit cpu's.
Hindsight has proven that they are smallest practical computer systems
with 16k for the OS and 48k for user space programs.
Offhand two index registers, a stack frame pointer, base data
pointer and three accumulators seem to be about right. Add a program
counter and that brings you to 7 registers. More than that you are
moving data around to use 'free' registers.
Cheers,
Chuck
2:38 a.m.
woodelf wrote:
Chuck Guzis wrote:
The 8051 family offers a different approach (CODE + DATA).
Many of the PICs have seriously perverse ideas of what
a processor should look like :-/
And, 8x300 probably sets the standard for a "RISC 8" machine.
I liked the 2650 (?) but it was short-lived.
I think the hardest machines to program for are
the ones with "not quite
enough" registers. Programming an IBM 1620 is easy--there are no
accumulators, so there isn't much choice. Even a single accumulator
calls
out a certain programming style. But, say 3 or 4 registers gets you
taking
time to think about how to best use them. On the other hand, with the
CDC
Cyber 200, you had 256 64 bit registers, so you could keep just about
everything in registers--no tough thought there. But on the 808x, there
are just few enough and they're orthogonal enough to make you think.
I would say un-orthogonal myself. Other than the 8080,6800 & 6502
I can't think of any other architecture styles for 8 bit cpu's.
Hindsight has proven that they are smallest practical computer systems
with 16k for the OS and 48k for user space programs.
Offhand two index registers, a stack frame pointer, base data
pointer and three accumulators seem to be about right. Add a program
counter and that brings you to 7 registers. More than that you are
moving data around to use 'free' registers. 
9:48 a.m.
From: Don Y <dgy at dakotacom.net>
----snip---
The 8051 family offers a different approach (CODE + DATA).
Many of the PICs have seriously perverse ideas of what
a processor should look like :-/
And, 8x300 probably sets the standard for a "RISC 8" machine.
I liked the 2650 (?) but it was short-lived.
Hi
F8
Dwight
5:25 a.m.
On 4/3/06, woodelf <bfranchuk at jetnet.ab.ca> wrote:
Other than the 8080,6800 & 6502 I can't think
of any
other architecture styles for 8 bit cpu's.
1802 - 8-bit accumulator, 16 16-bit registers, any one of
which can be an index register, a stack pointer or the
program counter. Register-to-register transfers are
8-bits at a time, through the accumulator.
-ethan
6:23 p.m.
On Monday 03 April 2006 12:57 am, Don Y wrote:
Chuck Guzis wrote:
I think you're probably right...
On 4/2/2006 at 7:12 PM Roy J. Tellason wrote:
I think the real reason (?) goes to a difference in cultures between
register rich and register poor machines IN THAT TIMEFRAME. And why it was necessary to stuff parameters into
registers, when it's
easy enough to put 'em on the stack, among other things.
Well, memory fetches are slower than register references for one. It
requires stack space, for another. And the 8080 code to access the
arguments, while not awful, is somewhat clumsy:
lxi h, 2
dad sp
mov c,m
inx h
mov b,m
....or something like that to grab a word off the stack into BC. E.g., if you are writing code for a 68xx, you have
little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Yeah. Though XTHL was another one...
Moving to something like a 99000 can be terribly
distressing
for the register rich crowd to become accustomed to! ;)
I found, though, when I was doing some z80 stuff a while back that most of
the time I'd use one pair for an address pointer and maybe one other besides
the accumulator and that was it, over 90% of the time.
Oh, and the little monitor program that I was playing with didn't push a
parameter on to the stack, it put it inline, right after the call to some
subroutine -- the called code would pick it up and use it and adjust the
stack pointer to just past it for the return. :-)
I have to dig out that code, anyhow, there were a few little tricks in there
that I think I want to use again. Like funneling everything through a
dispatch table, so that un-programmed EPROM showing up as "FFFF" in some
entries would be handled automatically ("CRASH!" :-), ferinstance.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4 Apr
4 Apr
9:08 a.m.
Roy J. Tellason wrote:
Z80 is a different beast from the 808[05]. You write code
differently for it because it has a much richer instruction
set. But, if you are doing things like adding an 8 digit
BCD number to another 8 digit BCD number, you quickly
discover that you need a lot of registers (two pointers
for the two arguments -- assuming the destination is one
of these as well, a "digit counter", the accumulator and,
of course, the carry).
On Monday 03 April 2006 12:57 am, Don Y wrote:
As was PCHL. But, XCHG was lots of bang for the buck (4 clocks?)
because it moved a lot of data in a little time. By contrast,
XTHL (ex sp,(hl) for z80 folks) moved the same amount of data
but, since it went to TOS, there were a lot more clocks involved
(19 or 20, IIRC).
I think the real reason (?) goes to a difference
in cultures between
register rich and register poor machines IN THAT TIMEFRAME.
I think you're probably right...
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Yeah. Though XTHL was another one... Moving to
something like a 99000 can be terribly distressing
for the register rich crowd to become accustomed to! ;)
I found, though, when I was doing some z80 stuff a while back that most of
the time I'd use one pair for an address pointer and maybe one other besides
the accumulator and that was it, over 90% of the time. Oh, and the little monitor program that I was playing
with didn't push a
parameter on to the stack, it put it inline, right after the call to some
subroutine -- the called code would pick it up and use it and adjust the
stack pointer to just past it for the return. :-)
Yes, a favorite trick for "printing" strings, etc.
CALL OUTPUT
DB 'Hello, World!'
<insert next instruction here>
I have to dig out that code, anyhow, there were a
few little tricks in there
that I think I want to use again. Like funneling everything through a
dispatch table, so that un-programmed EPROM showing up as "FFFF" in some
entries would be handled automatically ("CRASH!" :-), ferinstance.
Or, using INR M to 'test' flags.
--don
3:26 p.m.
On Tuesday 04 April 2006 09:08 am, Don Y wrote:
Z80 is a different beast from the 808[05]. You write code differently for
it because it has a much richer instruction set.
But I never used most of that stuff. Never got around to doing anything with
the index registers, the alternate set, or a lot of those "specials" that
were added. I kinda liked relative jumps, though, since it made it way
easier to do relocatable code and plus they were a byte smaller. :-)
Just so.
Yep!
Sometimes I like the absolutely minimalist approach to things, too. One of
these days I'm gonna dig that code out, burn it, and see how small a z80
box I can build that'll still prove useful for all sorts of things. I sure
have enough of those parts on hand here...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Roy J. Tellason wrote:
Yes. And I often wished that they'd had one that would work with BC, as
well... :-)
On Monday 03 April 2006 12:57 am, Don Y wrote:
As was PCHL. But, XCHG was lots of bang for the buck (4 clocks?) I think the real reason (?) goes to a difference
in cultures between
register rich and register poor machines IN THAT TIMEFRAME.
I think you're probably right...
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Yeah. Though XTHL was another one... because it moved a lot of data in a little time. By
contrast,
XTHL (ex sp,(hl) for z80 folks) moved the same amount of data
but, since it went to TOS, there were a lot more clocks involved
(19 or 20, IIRC).
Yup.
Moving to something like a 99000 can be terribly
distressing
for the register rich crowd to become accustomed to! ;)
I found, though, when I was doing some z80 stuff a while back that most
of the time I'd use one pair for an address pointer and maybe one other
besides the accumulator and that was it, over 90% of the time. But, if you are doing things like adding an 8 digit
BCD number to another 8
digit BCD number, you quickly discover that you need a lot of registers (two
pointers for the two arguments -- assuming the destination is one
of these as well, a "digit counter", the accumulator and, of course, the
carry).
I suppose. I guess it all depends on what you want to do...
Oh, and the
little monitor program that I was playing with didn't push a
parameter on to the stack, it put it inline, right after the call to
some subroutine -- the called code would pick it up and use it and adjust
the stack pointer to just past it for the return. :-)
Yes, a favorite trick for "printing" strings, etc.
CALL OUTPUT
DB 'Hello, World!'
<insert next instruction here> I have to dig
out that code, anyhow, there were a few little tricks in
there that I think I want to use again. Like funneling everything
through a dispatch table, so that un-programmed EPROM showing up as
"FFFF" in some entries would be handled automatically ("CRASH!" :-),
ferinstance.
Or, using INR M to 'test' flags. 
7:09 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
E.g., if you are writing code for a 68xx, you have
little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;;
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. -------------
7:30 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
On Tuesday 04 April 2006 07:09 pm, Cameron Kaiser wrote:
OTOH on one of those *I* don't know what to do with all of those addressing
modes... :-)
Or, I guess, you could conceivably look at that page zero stuff as
"registers". Is there any standardization for how those are used at all?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
E.g., if you
are writing code for a 68xx, you have little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;;
8:15 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
E.g., if you are writing code for a 68xx, you have
little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;;
7:35 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
Cameron Kaiser wrote:
Or a 6502. I don't know what to *do* with all the
other registers on
other architectures. ^_^;;
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :)
8:04 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
Or a 6502. I
don't know what to *do* with all the other registers on
other architectures. ^_^;;
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :) 
5 Apr
5 Apr
11:45 a.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
From: "Cameron Kaiser" <spectre at floodgap.com>
Since you brought it up :) what OSes can you run on a
4K PDP-8?
There are a bunch of stand-alone programs, and a 4K Disk Management
System that lets you load and save programs from disk. Depends on
how you define OS, I guess. (The resident part of the OS is pretty
much just a bootstrap to get the command language interpreter back
into memory.)
More OSes run in an 8K PDP-8 :-).
Vince
12:57 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
woodelf wrote:
Cameron Kaiser wrote:
And NO stack. Might as well mention the intresting missing items too.
Or a 6502. I don't know what to *do* with all
the other registers on
other architectures. ^_^;;
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :)
1:35 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
Kevin Handy schrieb:
woodelf wrote:
And the really weird ideas... like storing the return address in the
first word of a subroutine.
Sebastian
Cameron Kaiser wrote:
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :)
And NO stack. Might as well mention the intresting missing items too.
1:47 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
From: "Sebastian Br?ckner" <sb at thebackend.de>
Kevin Handy schrieb:
Gotta store it somewhere; there's no stack, and it's a single address
machine :-).
Vince
woodelf wrote:
And the really weird ideas... like storing the return address in the
first word of a subroutine. Cameron Kaiser wrote:
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :)
And NO stack. Might as well mention the intresting missing items too.
1:50 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
On 4/5/2006 at 7:35 PM Sebastian Br?ckner wrote:
And the really weird ideas... like storing the return
address in the
first word of a subroutine.
That one goes way back before the PDP-8. Even before CALL instructions,
one of the standard ways was to store the return address in a jump
instruction at the front of the subroutine being called.
Here's an example for the CDC 160A:
http://www.cs.uiowa.edu/~jones/cdc160/man/jump.html
So it was pretty natural that machines would eventually implement the
sequence in hardware. The CDC 6000/7000 PPU, which is the direct descended
of the 160A did just that.
Who needs all of those fancy instructions, anyway?
Cheers,
Chuck
1:36 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
On 4/5/2006 at 10:57 AM Kevin Handy wrote:
My first "Hands on" was an IBM 1620. No accumulator or stack. Decimal
arithmetic--and you had to load the addition and mulitplication tables
yourself. Variable word and record length, so you could easily clear
memory several ways using a single instruction...sometimes when you
actually intended to do it.
Lotsa blinkenlights, though!
Cheers,
Chuck
The first
computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :)
And NO stack. Might as well mention the intresting missing items too. 
1:46 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
I don't call it "register-impoverished", that's too negative a term.
I'd
prefer to call it "extraneous register-free" :)
I've always loved the simplicity of the 6502, 6809, HP2100... expressly
because there was just one or two accumulators, and just one or two more
registers for indexing or scratch. Early RISC ;) I always loathed the more
complex x86 type architectures that sported lots more (comparatively)
registers. They felt very "calculator-like" to me.
Jay
2:57 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
Jay West wrote:
I don't call it "register-impoverished",
that's too negative a term. I'd
prefer to call it "extraneous register-free" :)
I've always loved the simplicity of the 6502, 6809, HP2100... expressly
because there was just one or two accumulators, and just one or two more
registers for indexing or scratch. Early RISC ;) I always loathed the
more complex x86 type architectures that sported lots more
(comparatively) registers. They felt very "calculator-like" to me.
Register-rich *orthogonal* instruction set -- not intel's
bastardization of a bastardization of a bastardization... :-(
4:15 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
On Wednesday 05 April 2006 12:57 pm, Kevin Handy wrote:
woodelf wrote:
Yeah, that really put me off a bit...
I had a PDP8, sitting in storage. Sold it to a guy a while back, after
storing it for a few years and finally coming to the realization that I
wasn't ever gonna do anything with it.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Cameron Kaiser wrote:
And NO stack. Might as well mention the intresting missing items too. Or a 6502. I don't know what to *do* with all
the other registers on
other architectures. ^_^;;
The first computer I got to use was a PDP-8. You get a Program Counter
and a Accumulator. :) 
4 Apr
4 Apr
7:44 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
Cameron Kaiser wrote:
if there are enough of them, you should be able to use them as memory.
on the Microdata 1600, when it was first put out, one of the criticisms
of the design
was that the design had an 8 x 32 static ram that was used as, god
forbid, a register
file, with a 4 bit selector, for 30 registers. This was up from the
800's design which
had only 1 file bank, of 15 registers. one of the complaints was that
the 0 register
was special, and did not use the file's location 0 (or 16).
now days it is nothing to throw away an entire register to emit a 0 or 1
constant, but
then it was scandalous waste of hardware. (69- 71)
Jim
E.g., if you
are writing code for a 68xx, you have little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;;
5 Apr
5 Apr
7:18 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;; 
11:48 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
In article <m1FRHGq-000IxtC at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
The AMD 29050 has 192 general-purpose registers each 32-bits wide :-).
Trivia: The AMD 29050 was the vertex processor in the Evans &
Sutherland Freedom series graphics accelerators for IBM RS/6000, Sun
SBus and HP 9000 series workstations.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
Or a 6502. I
don't know what to *do* with all the other registers on
other architectures. ^_^;;
For the exact opposite, look at the PERQ 1a at the microcode level. 256
general-purpose registers (each 20 bits wide). [...] 
7 Apr
7 Apr
7:47 p.m.
New subject: register-impoverished childhoods was Re: Z80 TRAP and CP/M
On Thu, 2006-04-06 at 00:18 +0100, Tony Duell wrote:
For the exact opposite, look at the PERQ 1a at the microcode level. 256
general-purpose registers (each 20 bits wide). There's even an 8 bit
register which can be used to select a particular register -- that is
you have a sort of indirect addressing to the registers. The NORD-10 had 160 - ten
levels of 16 each.
I've described the machine on a wikipedia page, here:
http://en.wikipedia.org/wiki/NORD-10
I hope to create more articles, including the NORD-1, and the NORD-500
series.
-toresbe :)
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing.
Or a 6502. I don't know what to *do* with all the other registers on
other architectures. ^_^;;
4 Apr
4 Apr
10:23 p.m.
Roy J. Tellason wrote:
Z80 is a different
beast from the 808[05]. You write code differently for
it because it has a much richer instruction set.
But I never used most of that stuff. Never got around to doing anything with
the index registers, the alternate set, or a lot of those "specials" that
Alternate register set was ideal for interrupt service (assuming
IRQs aren't nested *or* you restrict the alt registers for use by
a single IRQ that can never interrupt itself). Consider the
cost of saving all of that state and restoring it before RETI
and you can see how quickly you can save a lot of time!
Just so.
We would often develop our own interpreters to make some of this
stuff more efficient to code. This would get coded in-line
with appropriate macros. For example:
STATE IDLE
ON '0' THRU '9' GOTO IDLE EXECUTING Accumulate_Digit
ON BARCODE GOTO TEST EXECUTING Clear_and_Read_then_Test
ON CLEAR GOTO IDLE EXECUTING Clear_Accumlator
ON ENTER GOTO TEST EXECUTING Test_Value
ENDSTATE
STATE TEST
ON GOODVALUE GOTO ACCEPT EXECUTING Process_Value
ON BADVALUE GOTO REJECT EXECUTING Signal_Error
ENDSTATE
So, with ~25 bytes, I can code a numeric data entry routine
(trivial example) in a way that actually is reasonably easy
to read.
Yep!
THogh this caused all sorts of problems when I got my first
ICE! :-( (think about it :> )
On Tuesday 04 April 2006 09:08 am, Don Y wrote:
The typical usage was HL & DE for source/destination pointers
and BC as length/byte count. So, you could
LXI H,...
LXI D,...
...
DAD B ;HL points to something
XCHG ;save HL in DE, get at contents of DE
DAD B ;DE points to similar "thing"
...
Roy J. Tellason wrote:
Yes. And I often wished that they'd had one that would work with BC, as
well... :-) On Monday 03 April 2006 12:57 am, Don Y wrote:
As was PCHL. But,
XCHG was lots of bang for the buck (4 clocks?) I think the real reason (?) goes to a difference
in cultures between
register rich and register poor machines IN THAT TIMEFRAME.
I think you're
probably right...
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Yeah. Though XTHL was another one... Moving to
something like a 99000 can be terribly distressing
for the register rich crowd to become accustomed to! ;)
I found, though, when I
was doing some z80 stuff a while back that most
of the time I'd use one pair for an address pointer and maybe one other
besides the accumulator and that was it, over 90% of the time. were added. I kinda liked relative jumps, though,
since it made it way
easier to do relocatable code and plus they were a byte smaller. :-)
A favorite trick was to finish a product. Then grep for all
CALLs. Sort this list to come up with the N most common CALLs,
and then assign those to the "unused" RST's. You could often
save 500 bytes of code with that 10 minute exercise...
But, if you
are doing things like adding an 8 digit BCD number to another 8
digit BCD number, you quickly discover that you need a lot of registers (two
pointers for the two arguments -- assuming the destination is one
of these as well, a "digit counter", the accumulator and, of course, the
carry).
I suppose. I guess it all depends on what you want to do...
Oh, and
the little monitor program that I was playing with didn't push a
parameter on to the stack, it put it inline, right after the call to
some subroutine -- the called code would pick it up and use it and adjust
the stack pointer to just past it for the return. :-)
Yes, a favorite trick for
"printing" strings, etc.
CALL OUTPUT
DB 'Hello, World!'
<insert next instruction here> I have to dig out that code, anyhow, there were a
few little tricks in
there that I think I want to use again. Like funneling everything
through a dispatch table, so that un-programmed EPROM showing up as
"FFFF" in some entries would be handled automatically ("CRASH!" :-),
ferinstance.
Or, using INR M to 'test' flags. Sometimes I like the absolutely minimalist approach to
things, too. One of
these days I'm gonna dig that code out, burn it, and see how small a z80
box I can build that'll still prove useful for all sorts of things. I sure
have enough of those parts on hand here...
I have a tiny multitasking executive that runs in a handful of
bytes. Slick as snot -- if you adopt its coding style.
11:12 p.m.
On Tuesday 04 April 2006 10:23 pm, Don Y wrote:
Yes. And I often wished that they'd had one that would work with BC, as
well... :-)
The typical usage was HL & DE for source/destination pointers and BC as
length/byte count.
Yup! I just like orthagonality, I guess...
Blame that H-11 that was my first hand-on exposure to a computer for spoiling
my expectations in that regard. :-)
<...>
That's what Osborne thought when they used it for _the keyboard interrupt_ (if
I'm remembering right) and then along came Turbo Pascal and Mix C and you had
to run a patch program or upgrade to a 1.21 rom (in the executive) to get 'em
to work at all.
Makes sense to me. My fiddling monitor program used a couple of those, I
think, but not most of them.
<...>
We would often develop our own interpreters to make some of this
stuff more efficient to code. This would get coded in-line
with appropriate macros. For example:
STATE IDLE
ON '0' THRU '9' GOTO IDLE EXECUTING Accumulate_Digit
ON BARCODE GOTO TEST EXECUTING Clear_and_Read_then_Test
ON CLEAR GOTO IDLE EXECUTING Clear_Accumlator
ON ENTER GOTO TEST EXECUTING Test_Value
ENDSTATE
STATE TEST
ON GOODVALUE GOTO ACCEPT EXECUTING Process_Value
ON BADVALUE GOTO REJECT EXECUTING Signal_Error
ENDSTATE
So, with ~25 bytes, I can code a numeric data entry routine
(trivial example) in a way that actually is reasonably easy
to read.
Macros were one thing I never really got going on, although one of the books
I have on hand here that deals with this stuff (I forget which one it is now,
and if it's z80-specific or cp/m-specific) was so heavily awash with them
that I had trouble wrapping my head around it. I should probably dig that
book out of whatever box it's in and have another look one of these days.
<...>
THogh this caused all sorts of problems when I got my first
ICE! :-( (think about it :> )
Never used one, so I'm not sure how you mean here.
For the z80? I'd sure like to see that if so.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Yeah. Though
XTHL was another one...
As was PCHL. But, XCHG was lots of bang for the buck (4 clocks?) But I never
used most of that stuff. Never got around to doing anything
with the index registers, the alternate set, or a lot of those
"specials" that
Alternate register set was ideal for interrupt service (assuming
IRQs aren't nested *or* you restrict the alt registers for use by
a single IRQ that can never interrupt itself). Consider the
cost of saving all of that state and restoring it before RETI
and you can see how quickly you can save a lot of time! were added. I
kinda liked relative jumps, though, since it made it way
easier to do relocatable code and plus they were a byte smaller. :-)
A favorite trick was to finish a product. Then grep for all
CALLs. Sort this list to come up with the N most common CALLs,
and then assign those to the "unused" RST's. You could often
save 500 bytes of code with that 10 minute exercise... DB 'Hello, World!'
<insert next instruction here>
Just so. Or, using INR M to 'test' flags.
Yep! Sometimes I
like the absolutely minimalist approach to things, too. One
of these days I'm gonna dig that code out, burn it, and see how small a
z80 box I can build that'll still prove useful for all sorts of things.
I sure have enough of those parts on hand here...
I have a tiny multitasking executive that runs in a handful of
bytes. Slick as snot -- if you adopt its coding style.
5 Apr
5 Apr
12:49 a.m.
Roy J. Tellason wrote:
For the z80? I'd sure like to see that if so.
I'll dig up the paper I wrote on it and send it off list.
On Tuesday 04 April 2006 10:23 pm, Don Y wrote:
THogh this caused all sorts of problems when I got my first
ICE! :-( (think about it :> )
Never used one, so I'm not sure how you mean here.
With an emulator, the code often resides in *RAM*.
If you don't configure the emulator to treat the
RAM *as if* it was *ROM* (ie. write protect it),
then INR M doesn't work! (well, actually, it works
the *first* time you use it, but not thereafter! :>)
Or, using INR M to 'test' flags.
Yep!
Sometimes I like the absolutely minimalist approach to
things, too. One
of these days I'm gonna dig that code out, burn it, and see how small a
z80 box I can build that'll still prove useful for all sorts of things.
I sure have enough of those parts on hand here...
I have a tiny multitasking
executive that runs in a handful of
bytes. Slick as snot -- if you adopt its coding style.
1:50 a.m.
On 4/4/2006 at 10:12 PM Roy J. Tellason wrote:
Yup! I just like orthagonality, I guess...
Blame that H-11 that was my first hand-on exposure to a computer for
spoiling my expectations in that regard. :-)
It's funny that the GI CP1600 never caught on--8 16-bit registers, R7 being
PC and R6 being the stack pointer, R4 and R5 being auto-increment and R0-R3
being general purpose. Very clean and easy to program. As far as I know,
the Activision game boxes were the only consumer products to use it.
Cheers,
Chuck
3:59 p.m.
On Wednesday 05 April 2006 01:50 am, Chuck Guzis wrote:
On 4/4/2006 at 10:12 PM Roy J. Tellason wrote:
Sounds nifty. But like a lot of other stuff in this industry, probably too
much affected by marketing considerations and not enough by technical merit.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Yup! I just like orthagonality, I guess...
Blame that H-11 that was my first hand-on exposure to a computer for
spoiling my expectations in that regard. :-)
It's funny that the GI CP1600 never caught on--8 16-bit registers, R7 being
PC and R6 being the stack pointer, R4 and R5 being auto-increment and R0-R3
being general purpose. Very clean and easy to program. As far as I know,
the Activision game boxes were the only consumer products to use it. 
3 Apr
3 Apr
11:57 p.m.
On Sun, 2006-04-02 at 15:41 -0700, Chuck Guzis wrote:
Although I've written several CP/M CBIOSes,
I've never had to write one on
a system that used the Trap vector (0066h) for something essential.
Just curious--has anyone had to deal with servicing the Trap interrupt in
CP/M? How does one keep CP/M from clobbering the vector, since it's in the
FCB2 area?
Sounds awfully familar... I think this problem exists when running ZCN
on the Amstrad NC100/200. ZCN deals as best it can. The problem comes
for applications that access the fcb directly without going through the
OS, I think.
Check the documentation for ZCN.
http://www.ibiblio.org/zcn/zcn13.zip
look under the doc/ directory for a file named zcn.txt . It mentions
some of the hacks needed. Plus there is full source code.
-- John.
4 Apr
4 Apr
1:51 a.m.
On 4/3/2006 at 8:57 PM John R. Hogerhuis wrote:
http://www.ibiblio.org/zcn/zcn13.zip
look under the doc/ directory for a file named zcn.txt . It mentions
some of the hacks needed. Plus there is full source code.
Ick, that's ugly--and it won't work for my application where TRAP is
triggered on a bus error, such as an invalid I/O address or memory page or
parity error. I think I'll connect the TRAP line to RST 4.5 and deal with
it that way--I'll figure out a way to handle double TRAP incidents--most
likely, ignore them.
Thanks,
Chuck
8:28 a.m.
Chuck Guzis wrote:
On 4/3/2006 at 8:57 PM John R. Hogerhuis wrote:
If you have control over the hardware, you can just jam whatever
vector you want onto the bus.
And, there's a trick I used once to free up RST 0 (!) for use
as well (differentiating it from RESET). But, it's too early
in the morning for me to recall what it was. :-(
--don
http://www.ibiblio.org/zcn/zcn13.zip
look under the doc/ directory for a file named zcn.txt . It mentions
some of the hacks needed. Plus there is full source code.
Ick, that's ugly--and it won't work for my application where TRAP is
triggered on a bus error, such as an invalid I/O address or memory page or
parity error. I think I'll connect the TRAP line to RST 4.5 and deal with
it that way--I'll figure out a way to handle double TRAP incidents--most
likely, ignore them.
10:23 a.m.
On 4/4/2006 at 5:28 AM Don Y wrote:
If you have control over the hardware, you can just jam
whatever
vector you want onto the bus.
There's already an 8259 for handling device interrupts, so I need something
that's higher priority than that. That leaves the RST 5.5, 6.5 and 7.5
pins. Given that only one of them (7.5) is edge triggered and not
level-triggered, I'll use that one.
Right about now you're probably asking yourself--Z80 TRAP, 8259 PIC, RST
7.5 pin?!? What the heck has this guy been smoking? Everyone knows that
Z80 timings are wrong for an 8259. And where is this RST 7.5 pin he's
talking about?
Well, this isn't a Z80--it's an NSC800--sort of a CMOS Z80 with 8085
timings and a multiplexed data/address bus like the 8085. I'm retrofitting
one into an 8085 box--there are a number of Z80-only programs that I'd like
to use and the National chip appears to be the most straightforward way to
do this. The pinout is substantially different from an 8085 and there are
a couple of signals that need to be inverted, but the timing charts look
good--and my particular application doesn't have the CPU making use of SID
or SOD or the undocumented 8085 instructions. The hardest part was finding
a supply of the NSC parts.
Cheers,
Chuck
1:07 p.m.
Chuck Guzis wrote:
On 4/4/2006 at 5:28 AM Don Y wrote:
I probably have a tube of them somewhere in the garage. I've
"explored" most of the 8085/Z80 variants over the years in
different designs (I recall a 3870?) -- though I haven't touched
one in probably a decade or more...
--don
If you have control over the hardware, you can
just jam whatever
vector you want onto the bus.
There's already an 8259 for handling device interrupts, so I need something
that's higher priority than that. That leaves the RST 5.5, 6.5 and 7.5
pins. Given that only one of them (7.5) is edge triggered and not
level-triggered, I'll use that one.
Right about now you're probably asking yourself--Z80 TRAP, 8259 PIC, RST
7.5 pin?!? What the heck has this guy been smoking? Everyone knows that
Z80 timings are wrong for an 8259. And where is this RST 7.5 pin he's
talking about?
Well, this isn't a Z80--it's an NSC800--sort of a CMOS Z80 with 8085
timings and a multiplexed data/address bus like the 8085. I'm retrofitting
one into an 8085 box--there are a number of Z80-only programs that I'd like
to use and the National chip appears to be the most straightforward way to
do this. The pinout is substantially different from an 8085 and there are
a couple of signals that need to be inverted, but the timing charts look
good--and my particular application doesn't have the CPU making use of SID
or SOD or the undocumented 8085 instructions. The hardest part was finding
a supply of the NSC parts.
3 p.m.
On 4/4/2006 at 10:07 AM Don Y wrote:
I probably have a tube of them somewhere in the garage.
I've
"explored" most of the 8085/Z80 variants over the years in
different designs (I recall a 3870?) -- though I haven't touched
one in probably a decade or more...
Hmmm--I've got a couple of the 3870s and I don't believe they're of the
same 8080/Z80 family. IIRC, the original F8 (the 3850) was not a complete
microprocess and required one of several support chips that provided, among
other things, the program counter and memory control logic. (3851, 3852,
3853?) Fairchild later introduced the 3859, which combined the two
simplest chips (3850, 3851), but Mostek did them one better and combined
the 3850 and one of the more complex support chips--I forget which one; it
may have been the 3856. Again, IIRC (I had only peripheral experience with
the things), the big advantage of the 3870 wasn't the level of integration,
but the steeply lower ROM mask charge over the Fairchild parts. I believe
that Fairchild, knowing a good thing when they saw it, licensed the 3870
from Mostek.
I've got a bunch of the 2.5 MHz NSC800's--I'd love to get my hands on a 4
MHz part. NSC's part suffix numbering system is a bit bizarre and probably
points to a story of a missed objective. The -1 is a 1 MHz part, but the
-3 is 2.5 MHz; the -35 is 3.5 MHz and the -4 is 4 MHz.
Cheers,
Chuck
9:46 p.m.
Chuck Guzis wrote:
On 4/4/2006 at 10:07 AM Don Y wrote:
I don't think they are the same beasts. But, I think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
I probably have a tube of them somewhere in the
garage. I've
"explored" most of the 8085/Z80 variants over the years in
different designs (I recall a 3870?) -- though I haven't touched
one in probably a decade or more...
Hmmm--I've got a couple of the 3870s and I don't believe they're of the
same 8080/Z80 family. IIRC, the original F8 (the
3850) was not a complete
microprocess and required one of several support chips that provided, among
other things, the program counter and memory control logic. (3851, 3852,
But, that's similar to the 8080, 4004, etc. lineage... I can recall
being excited when the 8085 came out with ONBOARD XTAL DRIVER!
Woo-hoo!! :>
3853?) Fairchild later introduced the 3859, which
combined the two
simplest chips (3850, 3851), but Mostek did them one better and combined
the 3850 and one of the more complex support chips--I forget which one; it
may have been the 3856. Again, IIRC (I had only peripheral experience with
the things), the big advantage of the 3870 wasn't the level of integration,
but the steeply lower ROM mask charge over the Fairchild parts. I believe
that Fairchild, knowing a good thing when they saw it, licensed the 3870
from Mostek.
I've got a bunch of the 2.5 MHz NSC800's--I'd love to get my hands on a 4
MHz part. NSC's part suffix numbering system is a bit bizarre and probably
points to a story of a missed objective. The -1 is a 1 MHz part, but the
-3 is 2.5 MHz; the -35 is 3.5 MHz and the -4 is 4 MHz.
5 Apr
5 Apr
1:25 a.m.
On 4/4/2006 at 6:46 PM Don Y wrote:
I don't think they are the same beasts. But, I
think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
Maybe you're thinking of the Zilog "official" part numbers. The 8400 was
the CPU, the 8430, the CTC; the 8470, the DART, etc.
Cheers,
Chuck
2:12 a.m.
Chuck Guzis wrote:
On 4/4/2006 at 6:46 PM Don Y wrote:
No, this was a 3xxx part number. And I am pretty sure it
was a Mostek part. I know it wasn';t a "Z80" but it was
something that grabbed our interest at the time (we were
having problems getting certain Zilog peripherals...)
I don't think they are the same beasts. But,
I think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
Maybe you're thinking of the Zilog "official" part numbers. The 8400 was
the CPU, the 8430, the CTC; the 8470, the DART, etc. 
4:17 a.m.
Don Y wrote:
Chuck Guzis wrote:
Mostek's #s for the Z80 family were MK388x:
MK3880 : Z80 CPU
MK3881 : PIO
MK3882 : CTC
etc.
(ref: IC Master 1982)
Presumably chosen by Mostek to be as close as possible to the MK385x, MK387x
F8 family numbers just to make the probability of confusing everyone as high
as possible.
On 4/4/2006 at 6:46 PM Don Y wrote:
No, this was a 3xxx part number. And I am pretty sure it
was a Mostek part. I know it wasn';t a "Z80" but it was
something that grabbed our interest at the time (we were
having problems getting certain Zilog peripherals...) I don't think they are the same beasts. But,
I think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
Maybe you're thinking of the Zilog "official" part numbers. The 8400 was
the CPU, the 8430, the CTC; the 8470, the DART, etc.
10:28 a.m.
Brent Hilpert wrote:
Don Y wrote:
Ah, OK. But, IIRC, there is a very subtle difference between
the Zilog parts and the Mostek's. But, I'm sure it was in some
really obscure aspect of the device, not the obvious characteristics
(the firm I was with at the time was fond of pushing the
envelope on designs... undoc'd opcodes, subtle timing hacks
in the hardware, etc.).
<shrug> Dunno. I just remember *needing* an alternate, looking
at their (Mostek) part and deciding it wasn't quite right... :<
Chuck Guzis wrote:
Mostek's #s for the Z80 family were MK388x:
MK3880 : Z80 CPU
MK3881 : PIO
MK3882 : CTC
etc. On 4/4/2006 at 6:46 PM Don Y wrote:
No, this was a 3xxx part
number. And I am pretty sure it
was a Mostek part. I know it wasn';t a "Z80" but it was
something that grabbed our interest at the time (we were
having problems getting certain Zilog peripherals...) I don't think they are the same beasts. But,
I think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
Maybe you're thinking of the
Zilog "official" part numbers. The 8400 was
the CPU, the 8430, the CTC; the 8470, the DART, etc. (ref: IC Master 1982)
Presumably chosen by Mostek to be as close as possible to the MK385x, MK387x
F8 family numbers just to make the probability of confusing everyone as high
as possible.
No, *that* distinction goes to the bozos at TI with their
non-2732, 2732 (IIRC). So, if you wanted what the rest of
the world called a 2732, you had to order a 2532! (IIRC, 3
power supplies on their 2732..?)
12:27 p.m.
On 4/5/2006 at 7:28 AM Don Y wrote:
No, *that* distinction goes to the bozos at TI with
their
non-2732, 2732 (IIRC). So, if you wanted what the rest of
the world called a 2732, you had to order a 2532! (IIRC, 3
power supplies on their 2732..?)
We shouldn't also forget the NEC 8080A that didn't run quite the same as
the Intel part; the "74L" low power TTL logic series that had different
pinouts from the standard line, or the 24-vs-28 pin EPROMs with the same
number, or the wildiy different programmig conventions for same-numbered
parts from different vendors. All just part of the job...
Cheers,
Chuck
7:47 p.m.
Ah, OK. But, IIRC, there is a very subtle difference
between
the Zilog parts and the Mostek's. But, I'm sure it was in some
There's also a subtle (?) difference between 2 of the Japanese clones of
the Z80 (Toshiba and ???). The Epson PX8 (and I think the PX4) has a link
that you set one way for a Toshiba CPU and the other way for the other
brand. I'll have to check just what that link does.
No, *that* distinction goes to the bozos at TI with their
non-2732, 2732 (IIRC). So, if you wanted what the rest of
the world called a 2732, you had to order a 2532! (IIRC, 3
power supplies on their 2732..?)
You're thinking of the 2516. TI's 2716 was a 3-rail (+5V, +12V, -5V)
part, everybody else's was single rail. TI then made a single-rail 2K
EPROM and called it the 2516, it was much the same as everybody else's
2716...
AFAIK there never was a 3-rail 4K EPROM (2732-ish). The 2532 had
different pinouts fromthe 2732.
-tony
3:58 p.m.
On Wednesday 05 April 2006 01:25 am, Chuck Guzis wrote:
On 4/4/2006 at 6:46 PM Don Y wrote:
I think I have some parts around that has some other company (SGS?) using that
sort of numbering as well. Though they did put "Z80-(whatver) on the package
as well.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
I don't think they are the same beasts. But,
I think they (or
something with a P/N similar to that) sticks in my mind as a
viable alternative to Z80's at one time...
Maybe you're thinking of the Zilog "official" part numbers. The 8400 was
the CPU, the 8430, the CTC; the 8470, the DART, etc.
4 Apr
4 Apr
3:30 p.m.
On Tuesday 04 April 2006 10:23 am, Chuck Guzis wrote:
Everyone knows that Z80 timings are wrong for an 8259.
They are?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:09 p.m.
On 4/4/2006 at 2:30 PM Roy J. Tellason wrote:
On Tuesday 04 April 2006 10:23 am, Chuck Guzis wrote:
If you want to use the 3-byte CD xx xx vectored output of the 8259 they
are. AFAIK, the Z80 doesn't output 3 INTA pulses in response to an INTR-CD
sequence, although with enough glue, I suppose anything's possible.
Cheers,
Chuck
Everyone knows that Z80 timings are wrong for an
8259.
They are?
6:17 p.m.
On Tuesday 04 April 2006 04:09 pm, Chuck Guzis wrote:
On 4/4/2006 at 2:30 PM Roy J. Tellason wrote:
Ah, I'd forgotten about that...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On Tuesday 04 April 2006 10:23 am, Chuck Guzis
wrote:
If you want to use the 3-byte CD xx xx vectored output of the 8259 they
are. AFAIK, the Z80 doesn't output 3 INTA pulses in response to an INTR-CD
sequence, although with enough glue, I suppose anything's possible. Everyone knows that Z80 timings are wrong for an
8259.
They are?
3:26 p.m.
On Tuesday 04 April 2006 08:28 am, Don Y wrote:
And, there's a trick I used once to free up RST 0
(!) for use
as well (differentiating it from RESET). But, it's too early
in the morning for me to recall what it was. :-(
Do tell!
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
10:25 p.m.
Roy J. Tellason wrote:
On Tuesday 04 April 2006 08:28 am, Don Y wrote:
If it is important, I'll have to look for that design
to see what I did. But, that's a LONG time ago (and
the neurons tend to wear out after a while... :> )
And, there's a trick I used once to free up
RST 0 (!) for use
as well (differentiating it from RESET). But, it's too early
in the morning for me to recall what it was. :-(
Do tell!
6682
days inactive
6687
days old
55 comments
18 participants
participants (18)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
dgy＠DakotaCom.Net -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
frustum＠pacbell.net -
hilpert＠cs.ubc.ca -
jhoger＠pobox.com -
jwest＠classiccmp.org -
jwstephens＠msm.umr.edu -
kth＠srv.net -
legalize＠xmission.com -
rtellason＠blazenet.net -
sb＠thebackend.de -
spectre＠floodgap.com -
toresbe＠ifi.uio.no -
vrs＠msn.com