Re: Addressing 2GS slots with Orca Pascal?

[dempson@actrix.gen.nz (David Empson)]

Yves McDonald <""yves.mcdonald\"@NO SPAM sympatico.ca> wrote:

> Ok, the situation so far is:
> a) i/o address is located in first 64 kb memory segment in GS memory map

They are also in the $01Cxxx, $E0xxxx and $E1xxxx areas, but $00Cxxx is
the easiest area to deal with it because the numbers will be the same as
the (unsigned version of the) Applesoft BASIC PEEK and POKE addresses.

> b) a byte pointer could be used to access I/O address, thanks to ORCA
> Pascal pointer arithmetics.

This assumes that accessing memory through a byte pointer will actually
perform an 8-bit memory access.  ORCA/Pascal might be taking a shortcut
and using 16-bit mode even for a nominal 8-bit read operation, and
discarding the high order byte of the result (this avoids two CPU mode
switches).  It must switch to 8-bit mode for writing via a byte pointer.

I haven't use ORCA/Pascal for this sort of low level operation, but
probably tried it using ORCA/C, which has similar low-level code, but
don't recall whether I ever did direct access to I/O locations.

I'd be inclined to use inline assembly language (or a separately
assembled source file which is linked into the main program) to ensure
that the access is performed using the expected mode.

> Depending on i/o hardware restriction (pseudo-slotting) and PASCAL 
> pointer implementation, it may or may not work.

You may run into problems if you need to access the IOSTROBE space
($C800-$CFFF) because other drivers might cause a different slot to be
selected.  (Interrupt code is supposed to avoid this sort of thing, as
long as the appropriate value is stored in $07F8.  How do I remember
this stuff?)

I can't see any issues with accessing the $C0nX and $CnXX spaces,
assuming the slot is set to "your card".  (If it is set to the internal
peripheral, you will have to do rather a lot more trickery to access the
card in the slot, preferably involving locking out interrupts, and a
fair amount of assembly code.)

> To write a GS/OS device driver for TI chip, I will have to go deep into GS
> system programming.

What does this chip do?  I see you mentioned "sprite card" in the
original posting, but some more information would be helpful.

> The first test I will try is to tick the speaker at $C050 in a delay 
> loop to see if it actually works.

You won't get very far if you access $C050 - it will turn on graphics
mode (assuming you are initially in text mode).  Try $C030 instead.  :-)

-- 
David Empson
dempson@actrix.gen.nz