[Coco] Device module for (O)VCC continues. How to do DMA?

Gene Heskett gheskett at shentel.net
Mon Jun 3 07:15:27 EDT 2019


On Monday 03 June 2019 01:02:51 am Walter Zambotti wrote:

> Thanks Gene.
>
> You're supposed to break it to me GENTLY!
>
> So it simply isn't possible to design a hardware pak with DMA
> regardless of whether it is to the 64k or the 512k memory map!
>
> I suppose the DMA PAC feature in VCC (& OVCC) is an extension to the
> CoCo design.
>
> Walter
>
AIUI, the 6809 has a VMA pin, which could be used to notify a separate 
DMA controller to halt the 6809 while it was doing its thing. But what I 
read at the time said it was a kludge at best, so I never followed up, 
not even in my drifting off to sleep thoughts. The VMA piin tells the 
outside world that this cycle is the last valid memory address of this 
machine cycle, and that when its done the 6809 can be halted for a bit 
to give the dma controller full access to the memory.

Having at that point, already completed a production helper for the 
commercial making folks at KRCR-TV in Redding CA, that used a cosmac 
Super Elf board, which had an RCA 1802 microcontroller that did have 
builtin DMA, which I used to drive the video display, a thing I cobbled 
up out of a 74154 and a bag of 1n914 diodes as all it had to do was a 
new digital academy countdown in huge characters 103 lines tall in a 8.8 
pattern. 6 bytes of dma per vertical scan cycle. 4k of static ram 
supplemented the 256 bytes of the main board and the kit on an S-100 
board only cost $400 back then. Bag of parts and the boards with 
connectors I had to build. That was in 1978. Then I went on down the 
road, looking for more green. When I flew out to see  my oldest aunt in 
1994 with my then fairly new wife, I called that tv station and talked 
to the Chief, who told me that it was still handy and was still in use 5 
to 10x a day. It prepped the commercial on u-matic tape for their 
automatic station break machine, laying down the triggering tones on 
audio channel 2, while laying a new frame accurate academy leader in the 
video leader. And it did it to the finished tape without having to dub 
the tape to a copy of a master tape, saving a generation of quality 
loss, which was considerable in u-matic days. That improvement in image 
quality gained us 2 points in the Neilson book, and that directly 
translates to more sheckels in the bank.

I still have a freezer bag on the top shelf, with 2 audio carts of that 
software and a paper copy I typed up an a borrowed typewriter. Just in 
case I ever had to build another. Never happened.

The 1802 is an interesting micro-controller, fully 16 bits wide. Builtin 
dma, 16 16 bit registers. Any one of which could become the program 
counter in a one byte command. Had no subroutine or return call, so two 
of the registers were preset at boot time to point at the first byte of 
a short call, or return, each of which was maybe 20 bytes, and when it 
had done its thing jumped back to one byte before its resting address 
where the next instruction made the regular program counter the 
operative program counter again. All cmos.  Great little controller. But 
the 6809 was about 4 or 5x faster. But it got the job done that it had 
to do for every frame of video by line 21 of the frame, so it was way 
more than fast enough to do the job.

Using my wet ram for a wayback machine... 

> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Gene
> Heskett Sent: Sunday, 2 June 2019 3:30 PM
> To: coco at maltedmedia.com
> Subject: Re: [Coco] Device module for (O)VCC continues. How to do DMA?
>
> On Sunday 02 June 2019 12:17:24 am Walter wrote:
> > Ok
> >
> >
> >
> > So I have my MPU pak module (PFU & GPU) successfully performing
> > floating point operations and drawing under OS9.
> >
> >
> >
> > However it only works in synchronous mode.  In async mode it
> > corrupts task memory and after several hours of debugging I now know
> > why but I'm unsure how to fix the issue.
> >
> >
> >
> > The problem turns out to be the GPU can only DMA into the same 64k
> > address that the process is running in.
> >
> >
> >
> > If OS9 switches the MMU memory map the GPU is completely unaware and
> > continues drawing into wrong memory.
> >
> >
> >
> > The GPU has no way of knowing the MMU has pulled the memory rug from
> > under its feet!
> >
> >
> >
> > So my question is:
> >
> >
> >
> > How does a physical pak device accomplish DMA given this limitation?
> >
> >
> >
> > Can a PAK device see (and DMA) into the full (512k/1M/2M) ?
>
> No. There is no "dma" anyplace in the coco's design.
>
> > If yes, how?
> >
> >
> >
> > If no, what is the work around?
> >
> >
> >
> > Walter
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>



More information about the Coco mailing list