I was also wondering, is it possible for CPC to support DMA. I don't mean ASIC like "DMA" but DMA via some external DMA controller (like intels one).
I'm expecting the CPC timings would fall apart and the display would break???
It appears the Aleste can do it and it's CPC like...
Quote from: arnoldemu on 20:02, 26 August 15
I was also wondering, is it possible for CPC to support DMA. I don't mean ASIC like "DMA" but DMA via some external DMA controller (like intels one).
I'm expecting the CPC timings would fall apart and the display would break???
It appears the Aleste can do it and it's CPC like...
The CPC could support DMA, using the BUSREQ/BUSACK signal on the extension port. But there are some drawback :
- You steal the bus to the Z80, so your code will be stopped during the DMA
- The DMA controller must be GA friendly and watch for the WAITn signal and do not attempt more than one access between to WAITn
I've got some plan playing with this, but only plan yet ;)
You can connect a DMA to the CPC, but it best to use the Zilog DMA (if you can get them). If you any other make is used then special circuitry may be required, since the Zilog version was designed to work in tandem with the Z80.
The DMA itself MUST use the WAIT line to pause the DMA chip when it is asserted so as to not cause issue with memory access.
The other issue with DMA usage is the use of interrupts, since these will most likely interfere with the GA which make its more difficult to implement a DMA.
rpalmer
Also, I have the Z80 DMA PDF and Applications Manuals (Volumes 1 and 2) for Zilog Devices which includes example logic diagrams for connecting a DMA to the Z80.
rpalmer
Quote from: arnoldemu on 20:02, 26 August 15
I was also wondering, is it possible for CPC to support DMA. I don't mean ASIC like "DMA" but DMA via some external DMA controller (like intels one).
I'm expecting the CPC timings would fall apart and the display would break???
It appears the Aleste can do it and it's CPC like...
The CPC can not use the Z80 DMA, because the expansion port does not provide the needed signals. You can put a DMA into the CPC with the Z80 moved to a daughter board though.
I think the question is more: Why using a DMA on CPC?
If an external device have to access the memory without using the Z80, it can use a dedicated RAM.
There's lots of uses for DMA on the CPC, but it's rather complicated to implement because it needs access to many points within the CPC.
Bryce.
Thanks all. Interesting.
I was asking why... I wasn't expecting anything to be implemented to use it.
Quote from: TFM on 01:26, 27 August 15
The CPC can not use the Z80 DMA, because the expansion port does not provide the needed signals. You can put a DMA into the CPC with the Z80 moved to a daughter board though.
Can you elaborate ?
Quote from: rpalmer on 21:35, 26 August 15
Also, I have the Z80 DMA PDF and Applications Manuals (Volumes 1 and 2) for Zilog Devices which includes example logic diagrams for connecting a DMA to the Z80.
Are those Applications Manuals available in pdf form ?
sadly the manuals are in paper form.
There's also the issue of the CRTC already "stealing" memory cycles from the Z80 and blowing up memory accesses to multiples of 4 cycles -any DMA controller would have to deal/cooperate with the CRTC and of course have direct access to the RAM, perhaps through a priority mechanism that would avoid collisions, and also bypass the Z80 for DMA access through the expansion ports, floppy controller, etc.
In other words, a CPC thus redesigned would be more like an 8-bit Amiga or a C64 ;)
Interestingly, the CRTC is the only hardware on the CPC motherboard (on the classic models, at least) which has "DMA" and can do its own memory accesses (too bad that it's not dual-channel with the Z80, heh).
Not all 8-bit computers drove their display "automagically" in that way: e.g. the Z80-based Galaksija (https://en.wikipedia.org/wiki/Galaksija_(computer)#Video_generation) had the Z80 drive the video output directly, and it would disable video output completely for intensive processing.
Quote from: Velktron on 12:14, 27 August 15
There's also the issue of the CRTC already "stealing" memory cycles from the Z80 and blowing up memory accesses to multiples of 4 cycles -any DMA controller would have to deal/cooperate with the CRTC and of course have direct access to the RAM, perhaps through a priority mechanism that would avoid collisions, and also bypass the Z80 for DMA access through the expansion ports, floppy controller, etc.
In other words, a CPC thus redesigned would be more like an 8-bit Amiga or a C64 ;)
Interestingly, the CRTC is the only hardware on the CPC motherboard (on the classic models, at least) which has "DMA" and can do its own memory accesses (too bad that it's not dual-channel with the Z80, heh).
Not all 8-bit computers drove their display "automagically" in that way: e.g. the Z80-based Galaksija (https://en.wikipedia.org/wiki/Galaksija_(computer)#Video_generation) had the Z80 drive the video output directly, and it would disable video output completely for intensive processing.
The CRTC does not have DMA access. The CRTC is only a programmable address generator tailored for screen display.
The only "DMA" on the CPC is the Gate array which statically shares the access to the base memory. One time slice for the screen, using CRTC generated address, one time slice for the Z80.
The Gate array is also managing the DRAM row and column addressing.
The WAITn signal on the Z80, driven by the GA is clearly indicating when a memory cycle is available for the Z80 bus.
I stand corrected. Still, besides the Z80, the only device able to access memory more or less directly is the GA, at least on the classic CPC models. It's like a sort of "forced DMA", so any additional memory access mechanism would have to be able to "coexist" with it as well.
Quote from: Velktron on 12:41, 27 August 15
I stand corrected. Still, besides the Z80, the only device able to access memory more or less directly is the GA, at least on the classic CPC models. It's like a sort of "forced DMA", so any additional memory access mechanism would have to be able to "coexist" with it as well.
In fact, you can see the DRAM/CRTC/GA as a frame buffer, and the Z80 as a guest ;D
And since the Z80 can be inhibited by setting the BUSREQ signal, nothing prevent an other guest to access the DRAM as long as it follow the GA rules.
Well, on the CPC motherboard, there's the problem of physically giving another "guest" access to the memory lines -I think the mobo is designed only for PIO, so everything has to go through the Z80. It would require a lot of soldering and of course, as you said, playing by the GA's rules. Every new DMA-capable device would have its own address generator, iterator etc. but it would have to stall if the GA said so -plus there would need to be some sort of controller which would resolve conflicts between the GA and multiple DMA devices, allowing/disallowing specific ones, and of course letting the GA trump them all, as the big bad booty daddy that it is. ;)
In addition, the Z80 would now be disabled not only by the GA, but by every other DMA device present (by ORING the GA and the controller's "busy" signal). Talk about establishing a pecking order ;D
GA >> DMA devices >> Z80
Should be better to use the EXP RAM instead of the VGA RAM for DMA usages.
This is becoming a very theoretical and academic conversation.
The whole thing falls apart as soon as you can't guarantee that the Z80 is handed over control at exactly the right moment for the interrupt routines. Otherwise for example there's no reading the keyboard or handling sound, at least not in a predictable way (and wouldn't you hate typing something and not knowing if the system recognises your input?) The system would be pretty useless then.
And every piece of Z80 code that needs exact timing (i.e. FDC controller- or tape-routines) means the DMA devices need to hand over control to the Z80 beforehand (!) and for the duration of the routine as well.
It's either that or replace the above problems by daisy-chaining the keyboard, sound, disc, tape, etc. peripherals into the same DMA system.
Good bye compatibility and good bye CPC (because you're talking about a completely new Z80 system by then).
Yup, the presence of such a disruptive DMA controlling scheme would throw software compatibility out of the window. It might work for code specifically written to account for its presence, possibly only by running under a controlled OS/monitor environment with a well-defined API and driver architecture, but as you said, then that wouldn't be a CPC anymore.
E.g. you couldn't just replace the basic PIO-based disk I/O access routines with a ROM containing a set of "smarter" DMA-based ones, and soldering a new DMA-expansion board somewhere between the Z80, the FDC controller and main RAM, and expect it to have no side-effects whatsoever to timing-sensitive software (bye-bye, games) or even quite "vanilla" software if it decides to hog the memory bus at the wrong time.
It'd be quite risky to run software NOT designed to account for its presence, so such a peripheral (if you could still call it that) would need to be disabled easily at will so the user can switch between "normal CPC" and "super-duper enhanced CPC with DMA" ;D
Quote from: gerald on 08:53, 27 August 15
Can you elaborate ?
In brief, a DMA at the expansion port can't access DRAM on the PCB properly (ignoring timing of GA access here).
A solution could be a DMA for an external memory expansion, ok that's easy. But it wont help to access V-RAM quick.
Would love to see that you prove me wrong! :) :) :)
Quote from: TFM on 16:18, 27 August 15A solution could be a DMA for an external memory expansion, ok that's easy. But it wont help to access V-RAM quick.
Easy...and pointless. An external device can be as complex and free of the CPC's vagaries as we please, so for all we know it could be running a modified ZX Spectrum with an Amiga DMA controller, 5 SCSI hard disks, 10 external DD-I drives and 20 SID chips strapped on it, and of course it could move data from and to its own RAM as fast and with any access method it pleased, as long as it had a CPC expansion interface somewhere, of course. ::)
But the PC would still have to interface using good old PIO with it, so what's the point? :P
Quote from: Velktron on 16:56, 27 August 15
Easy...and pointless. An external device can be as complex and free of the CPC's vagaries as we please, so for all we know it could be running a modified ZX Spectrum with an Amiga DMA controller, 5 SCSI hard disks, 10 external DD-I drives and 20 SID chips strapped on it, and of course it could move data from and to its own RAM as fast and with any access method it pleased, as long as it had a CPC expansion interface somewhere, of course. ::)
But the PC would still have to interface using good old PIO with it, so what's the point? :P
That's exactly what I pointed out in my posts. Just less rude, but more efficient! :P 8) :laugh:
Quote from: TotO on 13:31, 27 August 15
Should be better to use the EXP RAM instead of the VGA RAM for DMA usages.
Yes, except most of the obviously good uses of DMA, like a blitter, aren't much use without access to video memory.
Well, one idea could be to fill the E-RAM quick from mass media... ok, ok, I know what are you going to say now... it won't be a CPC any longer.... (as if we would built something like this anyway).
Quote from: TFM on 19:02, 27 August 15
it won't be a CPC any longer....
Yes. That's why it's pointless worrying about compatibility with games etc.
However we can imagine an expansion device for the CPC that uses DMA for some specialized task such as playing video, enhanced graphics or a second processor. It would be designed to maintain compatibility with existing CPC software and hardware when not active, and only use 'incompatible' DMA for its own purposes. Such a device was never produced during the CPC's commercial lifetime, but that doesn't mean it
couldn't have been.
Rather than trying to do it through the expansion port I would look at removing the Z80 and putting it on a daughter board. Then the DMA device (which might even be a different CPU) can get complete control of the bus. Even with the limitations imposed by the gate array, the DMA device could access memory much faster than the Z80. For example LDIR takes 6 cycles to copy one byte, when it could be done in 2 cycles by a device with no instruction overhead.
A daughter board could also have peripherals attached such as an SD card, which can be accessed without using
any CPC RAM cycles. Data could be written from it to CPC RAM at a blistering 1 Megabyte per second. Imagine movies or 3D games running at 50fps with time to spare!
But...... It's not a CPC anymore. If you want to do that surely a pc or Mac is your tool?
Yep, removing the Z80 is what's left at the end, like I pointed out in my first post. Guess generations of CPC hard core uses thought about the topic DMA before. It come up once in a while. But as you say, it was never made.
Quote from: CraigsBar on 20:46, 27 August 15
But...... It's not a CPC anymore. If you want to do that surely a pc or Mac is your tool?
The old argument, I did know it will come up! :laugh: So where do / can / shall we draw the line? Because with a B-drive in 3.5" and 700 KB it's not a CPC anymore either. [nb]That is btw. a rethoric question. This was discussed many times in the wiki. Since then people talk .... and talk... maybe it helps ;)
[size=78%][/nb][/size]
Quote from: TFM on 21:08, 27 August 15
The old argument, I did know it will come up! [emoji23] So where do / can / shall we draw the line? Because with a B-drive in 3.5" and 700 KB it's not a CPC anymore either. [nb]That is btw. a rethoric question. This was discussed many times in the wiki. Since then people talk .... and talk... maybe it helps ;) [size=78%][/nb][/size]
Well for meth line is at the point that existing software and hardware is not gonna work anymore without disabling or removing the expansion.
But before a plus hater says the plus machines are therefore not cpcs anymore, they are the exception. The keyboard problems in the plus were an error and anyone can make those! what is being discussed here will knowingly break all old hard and software, therefore it's no longer a CPC if it cannot run CPC games etc.....
Quote from: CraigsBar on 23:22, 27 August 15
Well for meth line is at the point that existing software ... is not gonna work anymore without disabling or removing the expansion.
Games (originals!) usually do not like expansions. They won't run from a B drive, so the B drives is already over the border. :o
But I know what you try to tell, and mostly agree with it. :)
Quote from: TFM on 01:15, 28 August 15
Games (originals!) usually do not like expansions. They won't run from a B drive, so the B drives is already over the border. :o
But I know what you try to tell, and mostly agree with it. :)
Not running from B drive isn't an incompatibility. The hardware didn't "break" the game. The programmers just didn't bother including this support.
Bryce.
And they were also too lazy to look specifically for a multiface 2 so failed to run with anything on the expansion port. Again software issue not hardware.
AFAIK, the only major PC/home computer manufacturer that dared to change hardware architecture (including the CPU family) regularly, ditching all direct hardware backwards compatibility, was Apple. First they went 680x0 -> PowerPC, and then PowerPC -> Intel, bridging the gaps with software emulators. At some point they even ditched their old OS (MacOS Classic) for the newfangled UNIX-based OS X (Darwin).
Then there's also the case of Amigas getting "upgraded" with incompatible PowerPC-based accelerator boards, or graphics cards which were not usable with "classic" games. IMO, in those cases it was highly questionable whether the "upgraded" platform was still an Amiga or a Mac. Especially in the case of Amigas, it was just a second computer piggybacking on the first one. IMO there's something inherently wrong when an "expansion" is more powerful than the host system ::)
Quote from: CraigsBar on 23:22, 27 August 15
But before a plus hater says the plus machines are therefore not cpcs anymore, they are the exception. The keyboard problems in the plus were an error and anyone can make those! what is being discussed here will knowingly break all old hard and software, therefore it's no longer a CPC if it cannot run CPC games etc.....
Strictly speaking the design is within spec and code that breaks on the Plus machines was never guaranteed to work on original CPCs. It always did, but more by luck than judgement.
Quote from: Bryce on 08:37, 28 August 15
Not running from B drive isn't an incompatibility. The hardware didn't "break" the game. The programmers just didn't bother including this support.
Bryce.
Ah, so it's all the programmers fault?
Ok, I can live with that. Everything supported by FutureOS does thereby NOT make the CPC an non-CPC. And you know i like to provide support for any kind of hardware :-)
BTW: Happy birthday CPC 6128 - I put out some birthday presents today.