[Coco] 6309 microprocessor project - 10-24-2003
John Collyer
johncollyer at zoominternet.net
Fri Oct 24 08:52:00 EDT 2003
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://five.pairlist.net/pipermail/coco/attachments/20031024/43fce3f1/attachment.html>
More information about the Coco
mailing list