[Coco] VCC and my code tinkering.

[Walter Zambotti]

James wrote:

>The real slowdown would more likely be the rendering of the screen... where 60 x per second it has >to read the bytes from the RAM and convert them to bits on the screen.  That is probably where >most of the time is spent in VCC.

In fact that is one of the optimisations I want to look at.  It shouldn't be too hard to place the renderer in a thread of its own so that it doesn't affect the speed of the cpu emulation (on a multicore CPU).

But then theirs is theory and the practice.

Walter

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of James Ross
Sent: Wednesday, 26 July 2017 2:55 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] VCC and my code tinkering.

That is very interesting Walter!  Since we have two Walters, perhaps I should call you Zambotti? It's a cool last name btw!

Very interesting what you tried. I recall you're first post on this subject and I meant to respond back then.  I seriously doubt that the RAM byte access  that you pointed out in that post 

Byte = Memory[MMUBanks[Mode][Address>>13]][Address&0x1FFF];

is the big slowdown in the VCC emulator.  It would be interesting to see the x86 assembly language that statement gets translated to, I'd guess somewhere around 20 to 30 instructions?  (no clue really)

The real slowdown would more likely be the rendering of the screen... where 60 x per second it has to read the bytes from the RAM and convert them to bits on the screen.  That is probably where most of the time is spent in VCC. 

My work on VCC is currently stalled, due to real work, but I still plan on getting back to it soon. Btw, if you would like to take it over, be my guest!! :)  On the other hand if you don’t want to do that, but have some improvements – let me know, I’ll integrate them into my fork of VCC. 

James

________________________________________
From: Coco <coco-bounces at maltedmedia.com> on behalf of Walter Zambotti <zambotti at iinet.net.au>
Sent: Tuesday, July 25, 2017 6:35 AM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: [Coco] VCC and my code tinkering.

For anyone interested.



I have just finished integrating Windows Address Windowing Extensions with VCC.



Window AWE allows the user to control which pages of physical memory are mapped into virtual memory.



Or in other words it is a memory paging management device similar to the CoCo MMU unit.



My goal was to determine if using hardware memory management would speed up the VCC emulator (which currently only uses software) for Windows users only.



The bottom line is I got it going but it slows down the emulator by about 50%. (So half the speed)



The primary reason is because the CoCo MMU allows the same page of memory to be mapped into different memory  banks multiple times simultaneously and AWE does not allow this.



I managed to overcome this limitation in AWE by allowing memory access violations to occur and used exception traps to remap the banks in real time to where they were needed.



This is fine if accesses to multiply mapped pages are scarce.  But as I found out they can occur on every single instruction (millions of times per second).

This results in page trashing.



The second problem related to the first is because AWE does not allow the same page to be mapped multiple times the CPU will have one map of memory (64K) but at the same time the GPU in the GIME needs to access the same pages in its own memory map.  This results in pages being swapped everytime the GIME and the CPU wants to share memory (and they do all the time).



The only positive thing was I gained a better understanding of how the CoCo hardware works and how VCC emulates it!


--
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