[Coco] Coco 3 Memory Map Questions

[L. Curtis Boyle]

This sounds a lot like the clock doubler circuit that John Kowalski did years back (in his case, halving the time of “dead cycles” when memory was  not being accessed). Ironically, the 6309 didn’t get anywheres near as much of a speed up doing the same thing, as in native mode it eliminated a lot of the dead cycles itself.

L. Curtis Boyle
curtisboyle at sasktel.net



> On Feb 8, 2016, at 8:37 AM, Dave Philipsen <dave at davebiz.com> wrote:
> 
> No, I wasn't expecting 2x but I would take 1.3x or 1.5x!  I realize there would be problems with data alignment but you could also create an optimizing assembler and a knowledgeable programmer could perhaps pull some tricks.  It's just an idea.  Not likely to ever come to fruition because it would be hard to justify the amount of time it would take to implement this.  And, given the fact that there is such a small pool of 6809 FPGA users... And, for most practical purposes for which one would use a 6809 the performance at 25 MHz is way more than enough.
> 
> Dave
> 
> 
> On 2/8/2016 7:00 AM, Neal Crook wrote:
>>>>  It is in the realm of possibility to speed up the 6809 even more and
>> still retain full object code compatibility. Right now the 6809 core with
>> 8-bit data bus really smokes at 25 MHz.
>> 
>> Let's say that the best-case improvement from switching the data bus from
>> 8-bit to 16-bit is 2x. The 6809 spends its time doing (i) nothing (internal
>> cycle, VMA=0), (i) op-code fetches and (iii) data read/write.
>> 
>> 16-bit bus obviously does nothing for (i) (worse than nothing: you are now
>> wasting 2x the bandwidth)
>> If you have 2 opcodes to fetch (with no internal cycles) and the first is
>> at an odd address, you get a potential speedup
>> If you have 8-bit data to fetch, no speedup
>> If you have 16-bit data to fetch, potential speed up.. but ONLY if your
>> data is at a 16-bit aligned address.
>> Given the processing power and tools available, you could run traces and
>> assess the impact of this change, but I suspect it would not be anything
>> like 2x.
>> 
>> Neal.
>> 
>> On 8 February 2016 at 06:49, Dave Philipsen <dave at davebiz.com> wrote:
>> 
>>> Yes, even though the 6809 has internal 16-bit registers it still has to
>>> make two accesses through an 8-bit bus to get it the data for them.  The
>>> 16-bit access would only help if the 6809 had a 16-bit data bus.  That also
>>> brings up an interesting question:  For the 6809 implemented in FPGA by
>>> John Kent, I wonder what kind of average speed increase could be had if
>>> your FPGA had 16-bit memory (which the DE1 does) and you designed some
>>> pipelining and a 16-bit data bus for the 6809.  It is in the realm of
>>> possibility to speed up the 6809 even more and still retain full object
>>> code compatibility. Right now the 6809 core with 8-bit data bus really
>>> smokes at 25 MHz.  Imagine what might be possible if a 16-bit data bus
>>> could be designed.
>>> 
>>> Dave
>>> 
>>> 
>>> On 2/7/2016 4:25 PM, L. Curtis Boyle wrote:
>>> 
>>>> Isn't the 16 bit access to memory more for the GIME, for accessing
>>>> graphics memory to send to the screen?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Feb 7, 2016, at 3:59 PM, RETRO Innovations <go4retro at go4retro.com>
>>>>> wrote:
>>>>> 
>>>>> On 2/7/2016 12:57 PM, Robert Gault wrote:
>>>>>> RETRO Innovations wrote:
>>>>>> 
>>>>>> I'll try to answer these questions although I'm not sure I know just
>>>>>> what you meant by some of them. If you don't already have a copy, get the
>>>>>> Tandy Coco3 service manual, #26-3334. There are .pdf copies.
>>>>>> 
>>>>> Looked over my copy before posting, and yes, it is a fine resource.
>>>>> 
>>>>>> Since the cpu has 16-bit registers, it make sense for memory to be
>>>>>> accessed at that width.
>>>>>> 
>>>>> That doesn't make sense to me.  The 6809 data path is 8 bits wide,
>>>>> regardless of the width of internal registers.  Just like the 68008 used an
>>>>> 8 bit data path even though the registers were 16 and 32 bits wide.
>>>>> 
>>>>> 
>>>>> --
>>>>> Coco mailing list
>>>>> Coco at maltedmedia.com
>>>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>>> 
>>>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>