[Coco] CoCo3 accelerator add-on

[L. Curtis Boyle]

Ah... when we were in chat, I had thought that you had said that the screen output was the bottleneck. 
Also, would it speed your example up slightly if used TFR instead of the PSHS/PULS? (this is off the top of my head here... not looking up instructions):
So, the _add8 routine would be:
_add8 sta <A
andb #~(SF|ZF|HF|PF|NF|CF)
tfr cc,a
bita #%00100000
etc.

(I was thinking of using LSRA instead of BITA for your last 4 checks, too... but, if I remember right, it's a byte smaller but the same amount of CPU cycles. Might be faster on a 6309, though).

L. Curtis Boyle
curtisboyle at sasktel.net



On Apr 27, 2013, at 10:04 PM, Luis Antoniosi (CoCoDemus) wrote:

> i made some experiments and it didn't make much difference at all.my
> bottleneck is that I need to load each instruction, dispatch a jmp table
> for each instruction and perform each instruction in 6809.
> 
> add, sub, cmps have all 6809 similars but not for the flags. It spends a
> considerable amount of time translating the 6809 flags to 8080/z-80, and
> also, the 6809 doesnt perform half carries in subtractions, etc. so
> basically i have one instruction to perform the code and dozen to set the
> proper 8080 flags.
> 
> for example, the ADD instruction:
> 
> _add8 pshs cc
> sta <A
> andb #~(SF|ZF|HF|PF|NF|CF)
> puls a
> bita #%00100000
> beq @nHF
> orb #HF
> @nHF bita #%00001000
> beq @nSF
> orb #SF
> @nSF bita #%00000100
> beq @nZF
> orb #ZF
> @nZF bita #%00000010
> beq @nPF
> orb #PF
> @nPF bita #%00000001
> beq @nCF
> orb #CF
> @nCF stb <F
> rts
> _ADD8 MACRO
> ldd <AF
> adda \1
> lbsr _add8
> ENDM
> 
> ADDAA _ADD8 <A
> _FETCH
> ADDAB _ADD8 <B
> _FETCH
> ADDAC _ADD8 <C
> _FETCH
> ADDAD _ADD8 <D
> _FETCH
> ADDAE _ADD8 <E
> _FETCH
> ADDAH _ADD8 <H
> _FETCH
> ADDAL _ADD8 <L
> _FETCH
> 
> 
> maybe later i will add some queue as it adds some bugs to the vt-52
> emulation.
> 
> 
> On Sat, Apr 27, 2013 at 11:31 PM, L. Curtis Boyle
> <curtisboyle at sasktel.net>wrote:
> 
>> Don't forget to try buffering your characters so that you can do a larger
>> (and less often) I$Write calls... it will make a big difference. :)
>> 
>> L. Curtis Boyle
>> curtisboyle at sasktel.net
>> 
>> 
>> 
>> On Apr 27, 2013, at 9:25 PM, Luis Antoniosi (CoCoDemus) wrote:
>> 
>>> my cp/m emulator would run faster too :)
>>> 
>>> 
>>> On Sat, Apr 27, 2013 at 11:04 PM, Nick Marentes <nickma at optusnet.com.au
>>> wrote:
>>> 
>>>> Here's an idea I've been tossing around for awhile and wonder if it is
>>>> possible/feasible.
>>>> 
>>>> The GIME chip is so tied down to the speed of the 6809 in order to keep
>>>> video syncronised for output to a monitor.
>>>> 
>>>> As we've seen in the past, clocking up the 6809 just makes the GIME lose
>>>> video sync.
>>>> 
>>>> What if a replacement 6809 could be created using an FPGA with adaption
>> to
>>>> fit the standard 6809 socket?
>>>> 
>>>> The FPGA would ensure that the signals to the GIME remain what it
>> expects
>>>> but internally, it can process much faster.
>>>> 
>>>> This will be similar to Sock Master 4Mhz mod which made the 6809 slow
>> down
>>>> when being accessed by the GIME (or vice versa) but number crunching can
>>>> run at a higher rate.
>>>> 
>>>> A faster CoCo3 opens the doors to more complex programs such as a Wolf3D
>>>> game (graphics still at old speed but number crunching for the math much
>>>> faster).
>>>> 
>>>> Possible? Another pipe dream?
>>>> 
>>>> Nick
>>>> 
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/**mailman/listinfo/coco<
>> http://five.pairlist.net/mailman/listinfo/coco>
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Long live the CoCo
>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>> 
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> 
> 
> -- 
> Long live the CoCo
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>