6

What are some examples of devices that would use the Z80's bus request input?

From the technical manual re. BUSRQ:

Input, active low. The bus request signal is used to request the CPU address bus, data bus and tri-state output control signals to go to a high impedance state so that other devices can control these buses. When BUSRQ is activated, the CPU will set these buses to a high impedance state as soon as the current CPU machine cycle is terminated.

I'm assuming this rules out memory as whatever address is present on the address bus would disappear when the CPU enters high impedance (w/ regards to the bus).

Improve this question
4
  • 4
    I suspect it's for DMA controllers; would need to check that before stating it confidently though.
    – Tommy
    Commented Feb 14, 2018 at 22:43
  • Video cards frequently used DMA so that the CPU did not interrupt them during large memory block read/write. Early computers sometimes had problems with monitor "flicker" because the CPU would interrupt the video controller. BUSRQ prevented this from happening.
    – jwzumwalt
    Commented Feb 23, 2018 at 21:10
  • It's worth noting that the BUSRQ/ACK protocol used by the Z80 was inherited from the Intel 8080 (where the signals are called HOLD and HOLDA but have the same function), and also persisted into other Intel processors, including the 8088 and 8086. This means that there is a degree of hardware compatibility between these systems, and DMA hardware and/or bus designs from one system can be used with the others (e.g. using 8088 or 8086 processors on S100 bus machines).
    – Jules
    Commented May 30, 2018 at 14:17
  • "whatever address is present on the address bus would disappear" - in practice, they often DON'T. That is why trying to dump non-existent memory gives you ASCII tables with some systems.
    – rackandboneman
    Commented Jun 6, 2018 at 23:07

4 Answers 4

Reset to default
11

That would be any device that likes to take over the bus. Usually that would be some DMA controller handling an interface like a serial or parallel one. But it also can be anything you want - like another CPU.

Its function is that another device (not the CPU) pulls /BUSREQ whenever it needs control of the system. When the CPU is ready to release the BUS it answers with /BUSACK, which in turn allows the other device to go ahead. The Z80 Peripherals User Manual describes the handling in great detail, including why and how other family members use this feature.

Using this mechanism a DMA controller can for example feed a parallel port a new byte whenever the last one has been transferred, so a background print queue requires no CPU attention at all - well, until the buffer is emptied of course. Similarly with a serial printer or a modem connection.

Of course there might be situations where a 'polite' bus takeover, as with this protocol, might not work out. For example with a screen buffer in main memory, access for the graphics unit by asking nicely via DMA protocol, would require additional buffers to compensate for the time it may have to wait for the bus. So simple graphics systems instead disable the CPU by manipulating things like clock timing. This does result in a lower overall performance, but also in a way lower chip count, thus enabling cheap systems.

Improve this answer
14
  • Is it used for device to device communication? On high impedance, no component of the CPU is accessible (for instance writing a value to one of its registers). If so, why bother using the CPU buses, instead of just physical wiring directly between the two devices?
    – Jet Blue
    Commented Feb 15, 2018 at 2:39
  • Does the parallel port you mention belong to another device? Are you able to flesh out the printer example? Why would a printer benefit from DMA? Thanks!
    – Jet Blue
    Commented Feb 15, 2018 at 2:40
  • 1
    No, it is used for other masters to access the bus. For example like a DMA controler. Without a DMA controller a CPU programm has to handle all bytes transferd to a port. This means either the CPU loops around outputing - and waits thus most of the time, while the User can't do anything but also wait, or, when interrupt driven, each byte will take several dozend instructions and maybe 100 or more cycles. With DMA it takes exactly 2 clock cycles to output a byte, leaving the CPU almost untouched working for whatever is done in foreground - like text editing.
    – Raffzahn
    Commented Feb 15, 2018 at 8:21
  • These signals were typically used by the Z80 DMA controller, which in turn was often used for floppy disk or hard disk read/writes because the transfer rates made it hard or impossible to read or write the bytes on time using a CPU loop.
    – Ralf Kleberhoff
    Commented Feb 15, 2018 at 11:46
  • 1
    @supercat Ofc, stoping the clock in the midst of a cycle isn't a good idea. And yes, one could build a system using additional counters and FIFOs and so on. That's exactly why a graphics solution using /BUSREQ is more expensive than manipulating the CPU clock. In a price sensitive market like several additional TTL are a hefty toll, and designers took caution to avoide it. Just check how a Spectrum did it. I'd trust their decison as well thought thru.
    – Raffzahn
    Commented Feb 16, 2018 at 23:21
6

for example Z8410 DMA chips are using BUSRQ so any peripherial based on them will use it too. For example this:

Which is used as form of GPU. For more info see:

BUSRQ is meant to share buses of the system so it is intended also for multi (C)PU systems. But not all shared BUS devices use it. For example ZX spectrum CPU+ULA share buses but ULA stops Z80 clock instead of using BUSRQ.

You're right Memories are using different mechanisms. Each memory chip has its own CS chip select signal which is activated by system address decoder usually tied to the address buss (not always). For example peripherials on ZX Spectrum use /ROMCS signal on the bus which deactivates the internal ROM and the peripherial can place its own memory there When needed. For example FDC Didaktik D40/D80 works this way

D40/D80

IIRC When you call rst0(reset) it swap ROMs and run its own BIOS it detects the reason of "interrupt/reset". As BASIC triggers this on syntax error it places new syntax into BASIC extending it to operate with FDD. for example:

LOAD "file.P"

loads from tape but

LOAD * "file.P"

loads from floppy ...

Improve this answer
2
  • I believe the ERROR routine is at RST 8.
    – user3570736
    Commented May 31, 2018 at 7:01
  • @user3570736 might be but rst 0 is also generated in some cases. Do not remember the details anymore but I did use it in the past to make unresetable program (after pressing HW Reset the program continues ...) exploiting the swapping ROM of D40/80. It might have something to do with its content
    – Spektre
    Commented May 31, 2018 at 7:04
3

Here is an example of ZX Spectrum-related thing: http://nedopc.com/gs/neogs_c_front.jpg This is a sound card for russian clones of ZX Spectrum (those that have ZX-Bus slots, ZX-Bus is an improved version of 'rubber ZX' bus, allowing multiple cards). It is called 'NeoGS' and based over the older one, 'GS' (stands for "General Sound"), that played 4 channels of digital 8-bit sound using on-board Z80.

The improved NeoGS is FPGA-based and also has SDcard slot and mp3 decoder. DMA via BUSRQ/BUSACK for its on-board Z80 is used for fast access from host ZX to card's memory, thus making it also suitable for co-processor actions like 3D precalc etc. On-board Z80 runs at frequencies up to 24 MHz (slightly overclocked, also 20 MHz mode is supported).

Improve this answer
1

Well, here's an example, IMHO, of how NOT to do it.

This is a segment of the TRS-80 Model 1 schematic. (it's stitched together from two pages from here).

If you find the BUSRQ pin in the upper left, it's tied to a TEST input.

Follow the line around, and you'll find that it's connected to a set of Tri-State buffer chips.

As soon as you send the BUSRQ low, it tri-states out the entirety of the Address and Data bus. Immediately. It doesn't wait for the BUSAK, it doesn't wait for the CPU to finish, it just cuts the CPU completely off mid-anything and everything.

Obviously, this is labeled TEST, so they used it for testing purposes in an (ostensibly) controlled situation. My father discovered this when he wanted to do some expansion to the TRS-80, and perhaps some DMA, but found this little bit making the BUSRQ mostly unsuitable for actual expansion. Things like this went in to his "They did WHAT?" file.

It's not kind to the CPU to just up and yank it away from its whole world on a whim.

TRS Schematic

Improve this answer
1
  • The purpose was probably to allow an external controller to probe the memory bus of a system that might have problems that would make normal code execution impossible (e.g. a shorted or open data line). Back in the days when non-working boards would be repaired rather than junked, an ability to have a program running on another machine examine the memory of a device under test without interference from that device's CPU would be very useful. I'm not sure that BUSRQ was necessarily more useful for that purpose than RESET, but it avoided the need to add extra logic on the reset line.
    – supercat
    Commented May 30, 2018 at 22:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .