Re: RFC : Apple II DMA for free.

["mdj" <mdj.mdj@gmail.com>]

On Mar 27, 6:09 am, "biel...@terra.es" <biel...@terra.es> wrote:
> On Mar 26, 3:08 am, "mdj" <mdj....@gmail.com> wrote:
>
>
>
> > 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
>
> 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...!

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