DMA transfer
DMA transfer
Are there examples of use and documentation? nothing was found
Re: DMA transfer
Which DMA transfer?
Re: DMA transfer
If I remember correctly (it was at least 10 years ago), in addition to a faster chip (from Toshiba), the content of the GAL is also modified (perhaps the same as for +3). But results were not so revolutionary and limited to a 64KB space only, the Z80-DMA took too much time to initialize each transfer, to set its registers. I didn't follow later development then, I stopped being interested in it, the SAM became a collector's item, instead of saving old software to preserve it for future, people started buying copy-rights and some individuals made a retro-business out of it.
I think there is an experimental version of the X128 that could perhaps include extra circuitry for the SAM, such as Z80-DMA and SID(?) It was also able to emulate Quazar Surround (the great soundcard in a huge box), but the author of this hardware banned the distrubution of such an expanded emulator.
From these times, I also remember another expansion, which could speed up SAM's graphics. A small board with a CPLD, which would be connected between the main memory and the SuperULA (ASIC) and replace every written byte with entire blocks of data, "tiles". This would bring interesting possibilities, still in a style of the SAM as an enhanced ZX Spectrum machine - let us imagine placing a block of 16x16 points in 16 colors using a single-byte-POKE, e.g. in Laser Squad. As far as I know, there was a timing problem (read or write states?), Velesoft did not complete the development.
@g0blinish
I can send you Data-Gear boards and GALs for testing.
I think there is an experimental version of the X128 that could perhaps include extra circuitry for the SAM, such as Z80-DMA and SID(?) It was also able to emulate Quazar Surround (the great soundcard in a huge box), but the author of this hardware banned the distrubution of such an expanded emulator.
From these times, I also remember another expansion, which could speed up SAM's graphics. A small board with a CPLD, which would be connected between the main memory and the SuperULA (ASIC) and replace every written byte with entire blocks of data, "tiles". This would bring interesting possibilities, still in a style of the SAM as an enhanced ZX Spectrum machine - let us imagine placing a block of 16x16 points in 16 colors using a single-byte-POKE, e.g. in Laser Squad. As far as I know, there was a timing problem (read or write states?), Velesoft did not complete the development.
@g0blinish
I can send you Data-Gear boards and GALs for testing.
Re: DMA transfer
Thank you! But do I need them?
Re: DMA transfer
It depends... You should be ready to modify a motherboard of your SAM. A CPU socket on the SAM motherboard is needed.
Other suggested internal expansions: ATOM Lite+ with RTC, Centronics (+ Covox), 1-4 MB fast MegRAM (and more, Mouse IF, Kempston IF)
I supplied Antony/DTA with his first SAM, but I guess I didn't send him the DMA interface. I don't see anyone experimenting with the SAM-DMA software today.
Re: DMA transfer
Unfortunately, I am not a user of this computer. As I understand the SimCoupe emulator does not support DMASamC wrote: ↑Mon Aug 28, 2023 11:08 am It depends... You should be ready to modify a motherboard of your SAM. A CPU socket on the SAM motherboard is needed.
Other suggested internal expansions: ATOM Lite+ with RTC, Centronics (+ Covox), 1-4 MB fast MegRAM (and more, Mouse IF, Kempston IF)
I supplied Antony/DTA with his first SAM, but I guess I didn't send him the DMA interface. I don't see anyone experimenting with the SAM-DMA software today.
Re: DMA transfer
DMA (direct memory access) on Z80 computers is usually a standard 1970s Zilog chip (Z8410), so it's a known thing whether you have a Sam Coupe, a DataGear board, or a Z80 FPGA system that supports it, or not. While we know the speccy as a very minimal design, there were a bunch of other support chips that Zilog expected most system designers to include - as well as DMA there was CTC (hardware timers and interrupts), parallel I/O and serial I/O.
You can read about Zilog DMA on page 33 onwards of the Zilog manual: http://www.z80.info/zip/um0081.pdf
About the only thing that really changes is which Z80 I/O port (IN/OUT etc) particular boards assign to it. For DataGear, MB02, MB03+, ZX eLeMeNt ZX, Shama ZX and SAM Coupe, it's either port $6B or port $0B, but probably not both.
The DataGear board used a Soviet clone instead of the real Zilog chip, and this had some differences, including off-by-one errors when specifying the count of bytes to copy or output. Out of lack of familiarity with the Zilog chip, some other FPGA systems copied the DataGear functionality and preserved the errors. Next legacy DMA mode uses port $6B and preserves the errors, which, Next native mode uses port $6B, fixes the errors and adds some other functionality, like repurposing the "burst" mode to output one byte every fixed amount of time (ideal for playing back PCM samples).
I believe the ZX-UNO/DOS/TRES family of FPGA computers also has DMA, but it may not be following the Zilog standard. Or perhaps it is the standard, but mapped to multiple uno registers instead of a single I/O port.
DMA transfers are not that hard to get your head round. You send a multibyte program to the DMA chip telling it what you want it to do. Each bit in each program byte means something, and if set, often indicates that another byte follows afterwards. In this way it's a little like how microcode works in other CPUs. Once you start the DMA program running it will stop the CPU (there are /BUSREQ and /BUSACK lines on the Z80 to allow this communication to happen cooperatively) so that the DMA chip has full access to the bus, RAM, etc. When it finishes control is returned to the CPU. Different modes (byte, burst, continuous) allow different levels of interruption back to the program code before it is finished. It may not seem like stopping the CPU is worth it, but a DMA block copy is usually much faster than an equivalent LDIR-style code copy.
Of course as you noted, you can't use DMA on a Speccy or SAM Coupe unless you have some external hardware which includes the chip. Or an emulator which emulates the chip.
You can read about Zilog DMA on page 33 onwards of the Zilog manual: http://www.z80.info/zip/um0081.pdf
About the only thing that really changes is which Z80 I/O port (IN/OUT etc) particular boards assign to it. For DataGear, MB02, MB03+, ZX eLeMeNt ZX, Shama ZX and SAM Coupe, it's either port $6B or port $0B, but probably not both.
The DataGear board used a Soviet clone instead of the real Zilog chip, and this had some differences, including off-by-one errors when specifying the count of bytes to copy or output. Out of lack of familiarity with the Zilog chip, some other FPGA systems copied the DataGear functionality and preserved the errors. Next legacy DMA mode uses port $6B and preserves the errors, which, Next native mode uses port $6B, fixes the errors and adds some other functionality, like repurposing the "burst" mode to output one byte every fixed amount of time (ideal for playing back PCM samples).
I believe the ZX-UNO/DOS/TRES family of FPGA computers also has DMA, but it may not be following the Zilog standard. Or perhaps it is the standard, but mapped to multiple uno registers instead of a single I/O port.
DMA transfers are not that hard to get your head round. You send a multibyte program to the DMA chip telling it what you want it to do. Each bit in each program byte means something, and if set, often indicates that another byte follows afterwards. In this way it's a little like how microcode works in other CPUs. Once you start the DMA program running it will stop the CPU (there are /BUSREQ and /BUSACK lines on the Z80 to allow this communication to happen cooperatively) so that the DMA chip has full access to the bus, RAM, etc. When it finishes control is returned to the CPU. Different modes (byte, burst, continuous) allow different levels of interruption back to the program code before it is finished. It may not seem like stopping the CPU is worth it, but a DMA block copy is usually much faster than an equivalent LDIR-style code copy.
Of course as you noted, you can't use DMA on a Speccy or SAM Coupe unless you have some external hardware which includes the chip. Or an emulator which emulates the chip.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: DMA transfer
This is a wrong. The DataGear works with both originals and clones, was tested with a wide range of various clones (and speeds), including the clone from East Germany (DDR, not a soviet clone!).
Can you describe details about "DataGear errors", please?
It seems the very original Z80-DMA has some isssues. At least one type of transfers in DMA chips of Zilog, Mostek and Texas instrument do not work properly, do not match with an original documentation. The clone from DDR has this bug repaired. Details of this issue can explain Busy, LMN128, maybe Velesoft, Zilog(ator) and others from CZ/SK scene...
Maybe the DDR clone, UA858D, has some other issues and differences. However, for the DataGear in the SAM Coupe, this chip is slow. You do not need a faster version from another producer, at least at 6 MHz.