That's the signal which tells the world that the Z-80 is starting a new
instruction cycle and is currently fetching the opcode. It is also the
cycle during which the refresh occurs. The Z-80 asserts IOREQ* and M1*
concurrently in order to signal a vectored interrupt acknowledge is in
progress and that the peripheral should drive its interrupt vector address
onto the bus. Aside from this last functon, I've never seen any particular
need for a processor to let me in on the fact its opcode fetch cycle was in
progress. It is helpful, I guess, if you're hand-toggling a program into
the processor as it executes them, though that's not how it's usually done.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, March 31, 1999 7:36 AM
Subject: Z-80 M1?
>I have never really understood the purpose of the M1 pin or cycle. Can
>anyone in simple terms explain it's purpose?
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
Remember a while back I mumbled something about finding some documentation
for a NorthStar Dimension computer which I suspected was PC compatible?
Well, I found a short review of it in the 1985-86 Edition of _The Peter
McWilliams Personal Computer Buying Guide_. This is the book that has all
those keen Victorian-style illustrations throughout the book. They turn
up regularly at thrift stores and the like.
The NorthStar Dimension is reviewed on page 78. 8088, 256K, MS-DOS,
multi-user system. The system was modular. You would buy a CPU, and
could hook up to 12 terminals(dubbed "work stations") to a single CPU.
The "work stations" could apparently run MS-DOS apps.
Sellam Alternate e-mail: dastar(a)siconic.com
------------------------------------------------------------------------------
Don't rub the lamp if you don't want the genie to come out.
Coming in 1999: Vintage Computer Festival 3.0
See http://www.vintage.org/vcf for details!
[Last web site update: 02/15/99]
Well, now that I've gotten to where, if I smoked, I'd go have a cigarette
while waiting for a 450MHz processor do to something, I'm almost ready to
wire up a 4.5" x 6" card with a Z80-H and a couple of hard disks of that
generation and fire up CP/M just to see how slow it seems now. I haven't
fiddled with one of these old timers in years.
Years ago, I said that computers wouldn't be fast enough for me until
everything I typed for it to do was done by the time my finger left the
return key. Well, we're there now, and they're still a mite sluggish to me
. . .
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 4:47 PM
Subject: Re: followup
><I guess it's fortunate there was only one DMA process going on at the time
><else it might have been real sticky figuring out what had been overwritten
><already.. If you were doing a read in order to do a write, using DMA, you
><might actually get tangled up. Fortunately that showed up while the vendo
><was debugging his code, so I didn't have to deal with that.
>
>Multiple DMA streams are doable too though hard to apply usefully.
>
><That's quite so. Fortunately one wasn't required to load data at the
><granule size, but rather at the sector size, so you could get by with a
rea
><of a 1K sector. Of course you had to read it before you could write it, s
><you had to wait for the next revolution of the disk. All this went by so
><fast, and, since I didn't run big databases requiring sorts to and from
><disk, I didn't perceive much delay, as it only takes a few revolutions to
><load up a program. So each drive had six logical drives on it.
>
>I have. Running a pair of drives and using ramdisk and my own smartdisk
>system. That was the speed order as well, the smartdisk system was fasest
>as it hard its own CPU and DMA channel to processor ram using hidden cycle
>stealing plus caching to 4x physical track size. That and a 6MHz z80 and
>dust flew.
>
><This all sounds like it could be fun if, for example, you're running it al
><on classic and unmodified hardware. I'm not sure I'd want to try to earn
m
><living that way, though.
>
>it's more fun on current hardware like 33mhz Z180s and it's still in use
>in odd pockets here and there. I don't (never did) make a living off it.
>
>Allison
>
That sort of thing was common. I never figured out why they didn't just
load the code into RAM from the ROM, then make the ROM go away. Eventually,
that was the method of choice.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 5:05 PM
Subject: Re: Rebirth of IMSAI
><I said 'ROM' because on a number of machines, it was just a few TTL chips
><that gated C3, lobyte, hibyte onto the data bus on the first 3 fetches
><after reset.
>
>Most used a mux and jumpers to fake a 3byte rom with the first byte
>hardwired as C3h (jmp in 8080/8085/z80) and it was jammed on the bus for
>boot and only then. another approach was to on power up map rom to loc 000
>and also F800h and then disable the mapping after the code was running up
>high. Plenty of tricks to fake that.
>
>Allison
>
<> I was thinking that the important part of all this is just to get
<> SOMETHING started. Don't worry about all the costs of going all out to
<> create a computer museum type organization. Just start out with what yo
<> can to begin with. Even if that means a garage party every month among
<> local collectors then that's a good start. From there, people will get
>Therein lies the essence of getting going. Inspired comment.
>Right now Megan and I seem to be the most voluminous collectors on the
>eastern MA area and we are close to each other. To get something going
>needs critical mass greater than two.
Hmmm... does anyone remember 'progressive dinner parties'? You'd get
a group of friends interested in dinner, and you'd go from one house
where you'd have one part of the meal, to another where you would have
the next part, and so on...
What about something like that for viewing collections... It would
have to be a limited number of people at any one time, obviously...
I'd definitely have to clean up... :-)
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 5:05 PM
Subject: Re: Rebirth of IMSAI
><It was always somewhat of a nuissance dealing with the Z-80 because of the
><way it presented its interrupt acknowledge, which was a combined I/O and M
><cycle, as long as the I/O cycle, but with M1. That meant, in my case, tha
>
>All instuction fetch cycles were short, INTA cycle had an extry cycle added
>for interrupt resolution in the supporting chips.
>
>To get around the short M1 cycles I'd use a tiny bit of logit to stutter
>the clock to the chip (slip a cycle) for M1 only. This results it running
>generally faster and still using slower memory.
This would require a variable length or variable preset counter sourcing the
clock. The problem was knowing when it was going the generate an M1 cycle
in advance, since the instructions were, generally of different clock cycle
counts. Either that or you'd have to look for the clock edge after the
appearance of the M1 strobe and KNOW it wasn't part of the interrupt
acknowledge. Neither was thrifty with logic, nor was it fun.
I've done lots of clock fiddling with various processors, and I admit from
the get-go, that the Z-80 was the least fun in this respect. It had so many
timing requirements that, once you varied from the beaten path, you were
going to use too many parts. Why would one want to replicate the bus timing
state machine just to improve it a bit? The reason for using a Z-80 was
that you could use CP/M for your development environment. I even had a
scheme wherein I took my target system and connected its processor to my CPU
socket via a cable or other arrangement, just so I could use CP/M. If it
hadn't been for that one, I'd never have put a Z-80 in anything. 6801's had
more features and required less hardware, and their clock was symmetrical so
you could share memory if that was desirable. It's a real pain with the
Z-80. That's true of the 8085 as well. I always preferred the 6502 and
68xx parts for useful work. Unfortunately they didn't have the support of
really useful OS. (well, . . . maybe on the Apple, but I never got much use
out of them until I put in a Z-80 card.)
><This same protocol made it unwise to try to use memory mapped I/O, since
the
><cycle length of an I/O cycle differed from that of a memory cycle.
>
>I used to do it all the time and like I posted earlier the NS* disk system
used MM-IO very effectively.
>
I had one friend whose NorthStar convinced me every time I saw it, that I
didn't want one. We were using CP/M, and you really didn't have even one
byte to spare in your measly 64K. His NorthStar only had 48K of memory
space, for some reason. Maybe it was because they'd mapped that region for
I/O.
>
>Allison
>
>
>Thanks for the info on the "Toaster", I'll fit a fuse into it and see if I
>can fire it up, it looks fairly clean so it should be ok. I might go back
>and see if the rest of the VSV11 is still around, there was a lot of DEC
>gear hanging around, mainly terminals.
>
It is a 3 board set(sometimes 4 if it has the optional second memory). I am
on the road right now so I don't have the # offhand but they have a ribbon
(40 pin I think) between them. They are quad wide Qbus boards but are also
used in Unibus machines with a Unibus to Qbus converter. If you think they
might still have the rest of it I will look up the board # and backplane #
when I get back. I have 1 I use routinely along with several for supporting
customers. Be sure to get the Cab Kit and the Joystick.
Dan
please see imbedded comments below.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 4:31 PM
Subject: Re: Computer busses....
>> >>You've hit most of the important signals. One I'd add, however, is a
data
>> >>bus disable, and perhaps an address bus disable as well. This would
allow
>> a
>> >>front panel or other bus mastering device to steal cycles under certain
>> >>circumstances.
>> >
>> >Why wouldn't BUS REQUEST work?
>> >
>> It would only work if BUS REQUEST were not a request for negotiation. If
>> you do have a bus negotiation handshake, then it might not work simply to
>> asser BUS REQUEST because you may want to "jam" data in to certain
locations
>> while the processor is doing most of the work. CPU places addresses on
the
>> bus, you, by means of your front panel, want to put different data there.
>> You float his data bus, and drive it yourself while he creates the
strobes
>> in his normal timing. Likewise, you might want to redirect his data
flow,
>> hence you float his address bus, driving it yourself, while the CPU
>> generates normally timed transaction control signals. It's an obscure
point
>> but I've seen it done for whatever reason on several occasions.
>
>I see what you're saying, but it's not that common to want to do that (if
>the CPU doesn't have access to the main memory, it'll execute NOPs or
>RST38's depending on how the bus is pulled, for example, which might not
>be that useful). Admittedly the PERQ rasterop machine did something
>similar (got the CPU to generate addresses and start memory cycles while
>the rasterop hardware took over the data bus), but the microcode on that
>machine was designed specificially to do that. The Z80 microcode isn't.
If you then drive the bus, it will execute whatever you feed it, provided
you do that during an instruction fetch cycle.
>A front panel can certainly be made that takes over the entire bus and
>generates address/data/control lines.
>
>> >
>> >>What would you do with the HALT signal, and how would you implement it?
>Remember on the Z80 (which is what I assume you're using based on the
>signal names), Halt is an _output_ from the CPU to indicate that the CPU
>has executed a halt instruction and is waiting for a reset/interrupt.
>
Of course! I'd forgotten that it raises that flag when it's halted. My
steel-trap memory is gradually becoming a colander . . . <sigh>
I don't believe I ever used that function on an S-100 . . .
>-tony
>
Thanks for the info on the "Toaster", I'll fit a fuse into it and see if I
can fire it up, it looks fairly clean so it should be ok. I might go back
and see if the rest of the VSV11 is still around, there was a lot of DEC
gear hanging around, mainly terminals.
Another odd device I picked up this week is a "Sharp Portable Computer
PC-2500", with a plotter-printer, it fires up, and gives me a menu of
options for "Business Software", "Telephone Book" and "Basic", it has a
16k Ram card and what appears to be a serial port with an odd connector. I
have searched high and low on the net for info on this but haven't been
able to find much!!
Cheers
Karl
------------------------------------------------------------------------------
Karl Maftoum
Computer Engineering student at the University of Canberra, Australia
Email: k.maftoum(a)student.canberra.edu.au
