I have tried to write down a way to get a free (in terms of memory
cycles) and easy to implement DMA channel on the Apple II.
It has to do with the "6502 trashed memory cycles".
Would you (more hardware-oriented guys) like to read and comment about
it ?
<http://homepage.mac.com/jorgechamorro/a2things/a2gratisDMA/
index.html>
Regards,
Jorge.
Jorge,
I am not sure I understand your question. It looks like what you want
to reduce wasted 6502 CPU cycles by removing un-needed trash cycles per 6502
instruction, but it will refresh RAM incorrectly. You can go to use DMA
without depending on 6502 CPU. To do this. Set high on Phase 1 signal to
control RAM directly by using DMA. You may be able to trace how data is
retreived or stored from / into RAM each ONE cycle out of 1 MHz. It might
screw video processor because it uses DMA at phase 1 signal.
You can try to disable 6502 CPU and use your own secondary CPU according
to your design to do DMA at phase 0 siginal while video processor runs at
phase 1 signal. It might give you the big difference.
Bryan Parkoff
Bryan,
The idea is that
-You can steal *regular 6502 memory cycles* during phase 0 therefore,
not phase 1.
-As there's no need to halt the 6502 during these DMA cycles, the 6502
will continue to run at 100% full speed.
-That's, I think, a magic, free, 100% transparent, unknown DMA channel
that exists but nobody never ever has used, afaik.
You could be writing to the disk II or saving to a cassete, and at the
same time transferring tens of KBytes of data in/out of the Apple II
transparently and it won't affect disk/cassete write operation at all,
to name a very time-critical operation. That's because it regains for
use these unneded, wasted, innecesary, interleaved in-between 6502's
opcode execution memory access cycles that are happening all the time.
No, it doesn't affect RAM refresh, because RAM refresh happens during
phase 1.
This channel is available during phase 0 and then only for the cycles
that the FREE/BUSY signal marks as free (FREE/BUSY==1).
Jorge.
> I have tried to write down a way to get a free (in terms of memory
> cycles) and easy to implement DMA channel on the Apple II.
> It has to do with the "6502 trashed memory cycles".
> Would you (more hardware-oriented guys) like to read and comment about
> it ?
Hi Jorge,
It's a cool idea. A way to handle asynchronous I/O on the Apple II.
I guess what's missing is the lack of a good use-case. I've run over a
couple in my mind, but the main issue is that in order to take
advantage of asynchronous I/O, you need appropriate software.
One example might be say, a serial interface card that used this
technique for data transfer. In theory, such a card could use your
technique to fill/empty FIFO buffers during normal execution. This
might turn out to be advantagous in say a terminal emulator, where the
software can simply update the screen and read from the keyboard, and
I/O happens transparently.
The question you have to ask though, is would this technique provide
sufficient bandwidth as to allow the Apple II to do serial comms at a
faster speed than if this process was done synchronously? My guess
would be yes on an unaccelerated II, no on an accelerated II (where
the technique would be useless anyway)
Perhaps a more compelling example would an operating system that
supported pre-emptive multitasking. The big win here would be using
the technique on a storage controller, which could potentially do it's
transfers asynchronously and interrupt the OS when it was finished.
This would allow much greater utilisation of the 6502 for actual
computing tasks, but again, being compatible with existing
accelerators is, I think, an unsurmountable challenge.
Like any new hardware design or technique, you're reliant on the
'killer app' to make it worthwhile, so I guess the challenge is now on
for all of us to come up with a way to do so :-)
Cheers,
Matt
http://forum.6502.org/viewtopic.php?t=771
Just another interesing 6502 hack...
Rich
This would have served as a great debugging aid. You could read/set
softswitches, vectors, page 0 locs, monitor a certain mem loc,
whatever, 100% transparently. You could interface a button to switch
the video modes, to step the disk II heads, to beep the speaker, to
mod the reset vector, the interrupt vector... to hack it all around
without the 6502 even noticing...!
I'd like to discover what the real achievable bandwidth would have
been.
A counter connected to this FREE/BUSY signal reseted every second
would tell... (i.e. a freq. counter)
And, yes, a zipchip would render it completely useless.. 8-(
Jorge.
Indeed, although I can't imagine wanting to to those things without
pausing the 6502, so there's easier ways.
> I'd like to discover what the real achievable bandwidth would have
> been.
> A counter connected to this FREE/BUSY signal reseted every second
> would tell... (i.e. a freq. counter)
Why not simply augment an existing emulator to provide such a counter?
Matt
Yes. Multiple zero pages...
I wonder, wouldn't you prefer to have them layered one on top of the
other,
instead of disseminated all around the memory map ?
BTW, surfing around I came across this nice and very detailed block
diagram of the 6502:
<http://homepage.mac.com/jorgechamorro/a2things/6502.jpg>
(so nice that it has become the background of my a2 entry web page...
8-)
Jorge.
Wouldn't you like, for example, to switch video modes through a
keystroke ?
Transparently ?
Without writing a single byte of code ?
Without the 6502 nor the software even noticing ?
Jorge.
Apparently some feel the need to do this enough to devise hardware
to make it possible. The DMAcontroller described by Sather is an
example.
I've never found it to be a problem that I couldn't solve another
way.
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
> > Wouldn't you like, for example, to switch video modes through a
> > keystroke ?
> > Transparently ?
> > Without writing a single byte of code ?
> > Without the 6502 nor the software even noticing ?
>
> Apparently some feel the need to do this enough to devise hardware
> to make it possible. The DMAcontroller described by Sather is an
> example.
>
> I've never found it to be a problem that I couldn't solve another
> way.
I installed a 'programmers switch' in my machine which allows me to
manually fire NMI and IRQ, which I found handy when doing esoteric
things with RAMWorks style memory.
As far as debugging goes, I've always found more traditional
approaches adequate, and have been a long fan of the assertion
approach.
Never much cared for symbolic debuggers - somehow the granular
stepping approach removes the spatial element of code and actually
obscures the problem from view, IMHO
Of course, as this thread indicates there are many differing yet valid
views on the topic.
Matt