[Coco] VCC and my code tinkering.

[James Ross]

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