[Coco] 6309 microprocessor project 01-16-2004

[Gene Heskett]

On Friday 16 January 2004 14:54, John Collyer wrote:
>Again,
>
>Since this version of the emulator will require a 586
>preferably a Pentium I am assuming these block
>moves of 8k will require very little time, but I can
>see how this might effect NitrOS-9 or OS-9
>Level 2 though.  How much time does NitrOS-9
>or OS-9 Level 2 kernel spend switching MMU
>pages as opposed to getting or putting bytes
>without the MMU page being changed.
>change.
>
>John Collyer

IIRC, and this may not be correct for Nitros9 today (Boisy?), the os9 
kernel, when redoing the memory mapping, updates the whole 16 byte 
wide gime register set, including its ghost image in the direct page.  
Thats redoing 16 bytes each in 2 seperate memory areas. A bit slower 
than we'ed like.  

Once in a while, this isn't much of a problem, however doing it just 
to read a byte or int there, and then switch maps and put it "here", 
will slow it down some.  I didn't find it had an appreciable effect 
when I did "myram", megaread times averaged in the 11.5 second area 
in either case as long as the mapping was for the whole 8k block at a 
time.  The 1.79 Mhz clock was the limiting factor, and IIRC my 
version of megaread was using the 6309's register Q for the gets and 
puts.  Reverting megaread to ldd, std in the copying brought it up to 
around 13 seconds if my memory is correct.

>----- Original Message -----
From: "John Collyer" <johncollyer at zoominternet.net>
>To: <coco at maltedmedia.com>
>Sent: Friday, January 16, 2004 2:26 PM
>Subject: [Coco] 6309 microprocessor project 01-16-2004
>
>> 6309 microprocessor project.
>>
>> Hello,
>>
>> I decided for the memory functions I would use a dedicated 64K
>> memory extent.  I tried the other way, which used pointers to 8k
>> memory regions.  This allowed for singlebank and fixbanks to only
>> change the memory pointers when needed, but increased getbyte
>> and putbyte's complexity.
>>
>> Since getbyte and putbyte are constantly being used as opposed to
>> singlebank or fixbanks it was a easy decision.  This was the most
>> convincing argument for the choice.
>>
>> Also with using the pointer method the special opcodes $11FD
>> and $11FF were confined to 8k memory boundaries.  With the
>> dedicated 64k memory extent using these special opcodes can
>> exist anywhere in the 16MB physical memory space because
>> singlebank and fixbanks not only calculate everything but also
>> blast the 8k banks to the 64k address space so the 64k memory
>> extent always contains the right banks, and getbyte and putbyte
>> are then greatly simplified.
>>
>> This goes against the grain, so to speak.  Usually you'd want to
>> change pointers instead of moving memory chunks around, but
>> not in this case.
>>
>> I was still wondering what the emulator lacks in making the
>> Sockmaster demos work?  Any insights will be appreciated.
>>
>> John Collyer
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.