[Coco] 6309 microprocessor project - 10-24-2003
john donaldson
jadonaldson at charter.net
Fri Oct 24 14:24:00 EDT 2003
John,
I thought there was a MAX size that a program could be
under OS9. Are you saying that now we can have a multi
100K
program running at the same time. I always was told that
64K was the max size a program could be.
John Donaldson
On Fri, 24 Oct 2003 09:55:02 -0400
"John Collyer" <johncollyer at zoominternet.net> wrote:
>The extra memory can be used for whatever you'd like,
>as far as I know there aren't any current applications
>using this memory except for VIDEOTEST and
>MEMTEST by Robert Gault.
>
>----- Original Message -----
>From: "john donaldson" <jadonaldson at charter.net>
>To: <coco at maltedmedia.com>; "John Collyer"
><johncollyer at zoominternet.net>
>Sent: Friday, October 24, 2003 9:34 AM
>Subject: Re: [Coco] 6309 microprocessor project -
>10-24-2003
>
>
>> John,
>> This may sound like a silly question, but what will
>> one
>> be able to do with the extra memory. Can it be used for
>> large programs, or is it only useful for graphics
>>screens
>> and mabey a RAM Disk?/
>>
>> John Donaldson
>>
>>
>>
>> On Fri, 24 Oct 2003 08:48:53 -0400
>> "John Collyer" <johncollyer at zoominternet.net> wrote:
>> >6309 microprocessor project.
>> >
>> >Hello,
>> >
>> >The special opcode $11FD (win32 functions) let you
>> >manipulate files
>> >on the host system directly from your emulated coco
>> >programs. The
>> >data areas that you defined and initialize according
>> to
>> >the win32 api
>> >documentation will be converted from Big Endian to
>>Little
>> >Endian byte
>> >order for you automatically, naturally. This allows
>>you
>> >to manipulate
>> >the win32 data structures in a natural way.
>> >
>> >The special opcode $11FF will let you run win32 code,
>>but
>> >I suspect this
>> >opcode will generally not be used heavily by anyone,
>> >mostly because it's
>> >hard to use and awkward.
>> >
>> >I am starting on the memory portion of the emulator
>> >today. The emulator's
>> >memory will be designated as read/write/execute, this
>>is
>> >to support the
>> >special opcode $11FF. Below see my vision of coco's
>> >emulated memory.
>> >
>> >; FF9B Reserved. | 2^11 = 1000000h = 16777216 = 2048
>>MMU
>> >blocks
>> >; | for a total memory of 2024 * 8192 =
>> >16,580,608 (16Meg).
>> >;
>> >; 1MB and 2MB bits, Write only.
>> >; Bit 7 - 16MB Video Bit NoCan3 bits
>>for
>> >16MB.
>> >; Bit 6 - 16MB Memory Bit NoCan3 bits
>>for
>> >16MB.
>> >; Bit 5 - 8MB Memory Bit NoCan3 bits
>>for
>> >8MB.
>> >; Bit 4 - 4MB Memory Bit NoCan3 bits
>>for
>> >8MB.
>> >; Bit 3 - 8MB Video Bit NoCan3 bits
>>for
>> >8MB.
>> >; Bit 2 - 4MB Video Bit NoCan3 bits
>>for
>> >8MB.
>> >; Bit 1 - 2MB Video Bit Disto & NoCan2/3 bits
>> >for 2MB.
>> >; Bit 0 - 1MB Video Bit Disto & NoCan2/3 bits
>> >for 1MB.
>> >
>> >The memory bits (vmmmvvvv) at $FF9B have no effect
>>until
>> >a value is sent
>> >to an MMU register, $FFA0-$FFAF. When a value is sent
>>to
>> >an MMU register,
>> >the memory bits at $FF9B combine with the MMU register
>>to
>> >create a pseudo
>> >11 bit register. This enables access to 2048 (2^11) MMU
>> >blocks for a total
>> >memory of 2024 * 8192 = 16,580,608 (16Meg).
>> >
>> >I've decided to use the Nocan3 memory model, which
>>gives
>> >us access to
>> >16 Megs of ram plus the 32K internal rom. With this
>>model
>> >there is no
>> >need for the jv coco3 emulator's use of the MMU
>>extension
>> >registers at
>> >$FF70 - $FF7F. That will leave these memory locations
>> >free as they should
>> >be. If anyone would like to comment on my vision of
>> >memory for the jc emulator,
>> >please do! The topic is open and I'd like to read all
>> >your responses.
>> >
>> >
>> >More later
>> >
>> >John Collyer.
>>
>> <TEXTAREA NAME="Signature" ROWS="4" COLS="60">
>>
>_______________________________________________
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
<TEXTAREA NAME="Signature" ROWS="4" COLS="60">
More information about the Coco
mailing list