Short, short questions

2008-05-20 Thread Thomas Harte
I'm about to finish my lunch break, sorry if I sound slightly short...

1) is there any pattern or logic to the values placed on the bus
during interrupts? I guess an equivalent question is: what realistic
options do I have on the Sam for catching and processing interrupts?

2) are there any non-obvious tricks for fast access to a table
containing 16bit words, indexed by an 11bit (signed) integer? At the
minute I'm essentially doing:

[stuff to work out offset into table in hl]
ld bc, address of middle of table - which is aligned to a two-byte boundary
add hl, hl
add hl, bc
ld e, (hl)
inc l
ld d, (hl)


Re: Short, short questions

2008-05-20 Thread Andrew Collier
On Tue, May 20, 2008 at 02:03:57PM +0100, Thomas Harte wrote:
 I'm about to finish my lunch break, sorry if I sound slightly short...
 
 1) is there any pattern or logic to the values placed on the bus
 during interrupts? I guess an equivalent question is: what realistic
 options do I have on the Sam for catching and processing interrupts?

I don't think the bus value is ever constructed in a useful way.

The usual strategies are to use mode 1, or to use mode 2 with a 257-byte table 
all 
containing the same byte.

 2) are there any non-obvious tricks for fast access to a table
 containing 16bit words, indexed by an 11bit (signed) integer? At the
 minute I'm essentially doing:
 
 [stuff to work out offset into table in hl]
 ld bc, address of middle of table - which is aligned to a two-byte boundary
 add hl, hl
 add hl, bc
 ld e, (hl)
 inc l
 ld d, (hl)

If you can align your table onto a 256 byte boundary, you can save a few cycles 
by adding 
only the top byte of the table offset. You can also double a number more 
quickly if you 
have an excuse to put some of it in the A register:

ld a,h 4
sla h  8
rla4
add table/256  8
ld h,a 4
   = 28
instead of

ld bc, table 12
add hl, hl 16
add hl, bc 16
   = 44

HTH,
Andrew

-- 
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --
r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4


Re: Short, short questions

2008-05-20 Thread Andrew Collier
On Tue, May 20, 2008 at 03:22:54PM +0100, Andrew Collier wrote:

correction:

 ld a,h 4
  sla l  8
 rla4
 add table/256  8
 ld h,a 4
= 28

You can also shave a little more time if you're willing to rearrange the table:

Instead of word pairs (low byte, high byte, low byte, high byte) you could have 
alternating lines of 256 low bytes, 256 high bytes. To use that, double the 
high byte of 
the address but don't change the low byte (in other words, don't run the 'sla 
l' at all 
saving 8 t-states) and then, when reading DE from the table, increment H 
instead of 
incrementing L to get the high byte corresponding to the selected low byte.

HTH,
Andrew

-- 
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --
r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4


Re: Short, short questions

2008-05-20 Thread Thomas Harte
While thinking about it during the afternoon, I have decided that  
since this table is absolutely fundamental to my program (it's part of  
the table based 2.8x2.8 multiply), I'm just going to centre it on  
address 0. Then I can cut the ld bc and the add hl, bc. I'm happy to  
rearrange my table, so I guess the comparison is between:


add hl, hl
ld e, (hl)
inc l
ld d, (hl)

and:

sla h
ld e, (hl)
inc h
ld d, (hl)

Obviously the second is faster — but I'm curious about your cycle  
counts. All the z80 documentation I have lists add hl, ss as 11 t- 
states. Why have you turned that into 16? It looks from your other  
calculations that you're just rounding to the next multiple of 4  
(which may be a good rule of thumb for the Sam, I don't know, I've  
just been letting Sim Coupe work it out), so why isn't it 12?


Anyway, with moving the table to 0 and rearranging it I have a  
reasonably accurate 2.8 x 2.8 multiply that operates in just 109 paper  
cycles, or between 152 and 268 Sim Coupe cycles. Annoyingly I  
currently have the screen in the low 32kb and my program in the high  
32kb so there's a whole bunch of things to change before I can  
actually see what overall effect that has on my framerate versus my  
current 200 to 304 Sim Coupe cycles...


On 20 May 2008, at 17:28, Andrew Collier wrote:


On Tue, May 20, 2008 at 03:22:54PM +0100, Andrew Collier wrote:

correction:


ld a,h 4

 sla l  8

rla4
add table/256  8
ld h,a 4
  = 28


You can also shave a little more time if you're willing to rearrange  
the table:


Instead of word pairs (low byte, high byte, low byte, high byte) you  
could have
alternating lines of 256 low bytes, 256 high bytes. To use that,  
double the high byte of
the address but don't change the low byte (in other words, don't run  
the 'sla l' at all
saving 8 t-states) and then, when reading DE from the table,  
increment H instead of
incrementing L to get the high byte corresponding to the selected  
low byte.


HTH,
Andrew

--
---   Andrew Collier 
  http://www.intensity.org.uk/ ---
 --
r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+  
(Cantab) 1.1.4




Re: Short, short questions

2008-05-20 Thread Andrew Collier
On Tue, May 20, 2008 at 07:20:48PM +0100, Thomas Harte wrote:

 Obviously the second is faster — but I'm curious about your cycle  
 counts. All the z80 documentation I have lists add hl, ss as 11 t- 
 states. Why have you turned that into 16? 

By mistake :)

I'm working from google, and misread a table. You're right, it should be 12. 
(Whn I get 
home I'll check there aren't any other details I missed).


There's a very comprehensive article in Based On An Idea about Sam timings; 
in almost 
all cases you can consider the real timing to be the Z80 timings rounded up to 
multiples 
of 4 (and then doubled if you're in the screen area - because there's little 
way top avoid 
this effect, I find it simpler to think of timings in terms of a t-state whose 
length 
changes).

Then as the second layer of approximation, there are some instructions which 
don't access 
memory so much, and take less than double time in the screen area. In effect 
you recover 4 
of the variable t-states if you happen to be in the screen. The article lists 
there with 
a * for each 4 t-states you can save.

INC rr is one (there are more, I can't remember right now) which takes 8* 
t-states.

Andrew

-- 
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --
r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4


Re: Short, short questions

2008-05-20 Thread Edwin Blink

1)

Normally the value is FF and it looks pretty stable too considering PRO-DOS 
uses IM 2 without a vector table. So your choices are IM 0/IM 1 both do a 
RST 38H or IM 2 which 'calls' the adress found at the address pointed by I 
register (MSB) and the value on the databus (LSB). Like the speccy there may 
be some hardware connected that changes the default value on the databus so 
a 257 byte vector table is recomended.



2)

If choose to put all the LSB at 32768 followed by the MSB then you could use 
the following:


set 7,h
lde,(hl)
set 3,h
ldd,(hl)

Other usefull addresses for the table would be 16384 (use SET 6,H), 8192 
(SET 5,H), 4096 (SET 4,H) or 0  (you don't need  the first SET instruction 
at all)


Edwin


- Original Message - 
From: Thomas Harte [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:03 PM
Subject: Short, short questions



I'm about to finish my lunch break, sorry if I sound slightly short...

1) is there any pattern or logic to the values placed on the bus
during interrupts? I guess an equivalent question is: what realistic
options do I have on the Sam for catching and processing interrupts?

2) are there any non-obvious tricks for fast access to a table
containing 16bit words, indexed by an 11bit (signed) integer? At the
minute I'm essentially doing:

[stuff to work out offset into table in hl]
ld bc, address of middle of table - which is aligned to a two-byte 
boundary

add hl, hl
add hl, bc
ld e, (hl)
inc l
ld d, (hl) 




Re: Short, short questions

2008-05-20 Thread David Brant
Mode 2 uses a table with 128 word address but as byte high,byte low not the 
normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

   DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
   di
   pushaf
   ina,(status.int)
  .
  .
   ei
   ret



- Original Message - 
From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257-byte 
table all

containing the same byte.





Re: Short, short questions

2008-05-20 Thread Thomas Harte
Surely set would only work if I had an unsigned offset from the  
beginning of a table? I'm using a signed offset from the middle of a  
table.


On 20 May 2008, at 19:48, Edwin Blink wrote:


1)

Normally the value is FF and it looks pretty stable too considering  
PRO-DOS uses IM 2 without a vector table. So your choices are IM 0/ 
IM 1 both do a RST 38H or IM 2 which 'calls' the adress found at the  
address pointed by I register (MSB) and the value on the databus  
(LSB). Like the speccy there may be some hardware connected that  
changes the default value on the databus so a 257 byte vector table  
is recomended.



2)

If choose to put all the LSB at 32768 followed by the MSB then you  
could use the following:


set 7,h
lde,(hl)
set 3,h
ldd,(hl)

Other usefull addresses for the table would be 16384 (use SET 6,H),  
8192 (SET 5,H), 4096 (SET 4,H) or 0  (you don't need  the first SET  
instruction at all)


Edwin


- Original Message - From: Thomas Harte [EMAIL PROTECTED] 


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:03 PM
Subject: Short, short questions


I'm about to finish my lunch break, sorry if I sound slightly  
short...


1) is there any pattern or logic to the values placed on the bus
during interrupts? I guess an equivalent question is: what realistic
options do I have on the Sam for catching and processing interrupts?

2) are there any non-obvious tricks for fast access to a table
containing 16bit words, indexed by an 11bit (signed) integer? At the
minute I'm essentially doing:

[stuff to work out offset into table in hl]
ld bc, address of middle of table - which is aligned to a two-byte  
boundary

add hl, hl
add hl, bc
ld e, (hl)
inc l
ld d, (hl)






Re: Short, short questions

2008-05-20 Thread Edwin Blink

From: Thomas Harte

Surely set would only work if I had an unsigned offset from the  beginning 
of a table? I'm using a signed offset from the middle of a  table.


it works the same as ADD HL,HL ADD HL,BC the difference is
you store the table entries LSB,MSB so you need the ADD HL,HL
First you get the LSB from the table then INC L points to MSB

When you store LSB,LSB... for all table enties first and then  MSB,MSB...
you don't need to do the add as HL already points to table entries LSB to 
get the MSB

you add 2K to get to MSB

Or am I getting something wrong ?

Because you have your table at address 0 the following would do :

LD E,(HL)
set 3,H;Add 2K to point to MSB
LD D,(HL)

takes 24Ts :-)

Edwin 



Re: Short, short questions

2008-05-20 Thread Edwin Blink

Boy Do I feel silly  I  missed that ADD HL,BC.

Edwin



- Original Message - 
From: Thomas Harte [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:53 PM
Subject: Re: Short, short questions


Surely set would only work if I had an unsigned offset from the  beginning 
of a table? I'm using a signed offset from the middle of a  table.


On 20 May 2008, at 19:48, Edwin Blink wrote:


1)

Normally the value is FF and it looks pretty stable too considering 
PRO-DOS uses IM 2 without a vector table. So your choices are IM 0/ IM 1 
both do a RST 38H or IM 2 which 'calls' the adress found at the  address 
pointed by I register (MSB) and the value on the databus  (LSB). Like the 
speccy there may be some hardware connected that  changes the default 
value on the databus so a 257 byte vector table  is recomended.



2)

If choose to put all the LSB at 32768 followed by the MSB then you  could 
use the following:


set 7,h
lde,(hl)
set 3,h
ldd,(hl)

Other usefull addresses for the table would be 16384 (use SET 6,H),  8192 
(SET 5,H), 4096 (SET 4,H) or 0  (you don't need  the first SET 
instruction at all)


Edwin


- Original Message - From: Thomas Harte 
[EMAIL PROTECTED]


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:03 PM
Subject: Short, short questions



I'm about to finish my lunch break, sorry if I sound slightly  short...

1) is there any pattern or logic to the values placed on the bus
during interrupts? I guess an equivalent question is: what realistic
options do I have on the Sam for catching and processing interrupts?

2) are there any non-obvious tricks for fast access to a table
containing 16bit words, indexed by an 11bit (signed) integer? At the
minute I'm essentially doing:

[stuff to work out offset into table in hl]
ld bc, address of middle of table - which is aligned to a two-byte 
boundary

add hl, hl
add hl, bc
ld e, (hl)
inc l
ld d, (hl)








Re: Short, short questions

2008-05-20 Thread Andrew Collier

Hi,

I'm sceptical about this claim. I've never heard anybody say that the  
vector formed is big-endian - it's just you don't know the byte offset  
from which the interrupt vector will be fetched. (As Edwin says, it is  
usually 255 - which is odd so your 1-aligned table will usually work -  
but I don't know that Sam's hardware guarantees this).


So the high byte comes from I, the low byte from the data bus; this  
forms a 16 bit address which will be incremented once (which is why  
the table needs 257 bytes, not 256). You could, at least in theory,  
read the vector address from even or odd overlapping entries, which is  
why the usual strategy is to pick a vector address whose low and high  
bytes are the same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE:   equ $
IM2BYTE:equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET:  equ 257*IM2TARGETBYTE
ds IM2TARGET-$

EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte low  
not the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

  DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
  di
  pushaf
  ina,(status.int)
 .
 .
  ei
  ret



- Original Message - From: Andrew Collier [EMAIL PROTECTED] 


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257- 
byte table all

containing the same byte.





--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --




Re: Short, short questions

2008-05-20 Thread David Brant
This was based on info from a book called z-80 Workshop manual by E.A Parr. 
The I register gives the high part of the table and the hardware gives the 
low part to the table then takes that word for the service routine. So if 
you start from one byte before the table and use the same address for all 
entries and over run it by one it will work. My demo of a full scrolling 
football pitch used this system, which I believe you saw many years a go.


Dave

- Original Message - 
From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:50 PM
Subject: Re: Short, short questions



Hi,

I'm sceptical about this claim. I've never heard anybody say that the 
vector formed is big-endian - it's just you don't know the byte offset 
from which the interrupt vector will be fetched. (As Edwin says, it is 
usually 255 - which is odd so your 1-aligned table will usually work - 
but I don't know that Sam's hardware guarantees this).


So the high byte comes from I, the low byte from the data bus; this  forms 
a 16 bit address which will be incremented once (which is why  the table 
needs 257 bytes, not 256). You could, at least in theory,  read the vector 
address from even or odd overlapping entries, which is  why the usual 
strategy is to pick a vector address whose low and high  bytes are the 
same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE: equ $
IM2BYTE: equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET: equ 257*IM2TARGETBYTE
ds IM2TARGET-$

EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte low  not 
the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

  DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
  di
  pushaf
  ina,(status.int)
 .
 .
  ei
  ret



- Original Message - From: Andrew Collier 
[EMAIL PROTECTED]


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257- 
byte table all

containing the same byte.





--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --






Re: Short, short questions

2008-05-20 Thread David Brant
I've just been looking at my books. Although I can't find the bit that said 
about swapping to high,low but I'm sure that I did read it somewhere. It 
does say that the device only gives the bits 1-7 and bit 0 is always 0 
giving 128 possible addresses.


Dave

- Original Message - 
From: David Brant [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 10:49 PM
Subject: Re: Short, short questions


This was based on info from a book called z-80 Workshop manual by E.A 
Parr. The I register gives the high part of the table and the hardware 
gives the low part to the table then takes that word for the service 
routine. So if you start from one byte before the table and use the same 
address for all entries and over run it by one it will work. My demo of a 
full scrolling football pitch used this system, which I believe you saw 
many years a go.


Dave

- Original Message - 
From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:50 PM
Subject: Re: Short, short questions



Hi,

I'm sceptical about this claim. I've never heard anybody say that the 
vector formed is big-endian - it's just you don't know the byte offset 
from which the interrupt vector will be fetched. (As Edwin says, it is 
usually 255 - which is odd so your 1-aligned table will usually work - 
but I don't know that Sam's hardware guarantees this).


So the high byte comes from I, the low byte from the data bus; this 
forms a 16 bit address which will be incremented once (which is why  the 
table needs 257 bytes, not 256). You could, at least in theory,  read the 
vector address from even or odd overlapping entries, which is  why the 
usual strategy is to pick a vector address whose low and high  bytes are 
the same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE: equ $
IM2BYTE: equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET: equ 257*IM2TARGETBYTE
ds IM2TARGET-$

EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte low  not 
the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

  DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
  di
  pushaf
  ina,(status.int)
 .
 .
  ei
  ret



- Original Message - From: Andrew Collier 
[EMAIL PROTECTED]


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257- 
byte table all

containing the same byte.





--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --








Re: Short, short questions

2008-05-20 Thread Andrew Collier

Hi,

In a spirit of scientific enquiry, let us perform an experiment by  
running the code below.


On SimCoupe, at least, the border turns bright yellow, meaning it ran  
the interrupt vector at 0x9a92 (that is, the 256th and 257th bytes of  
the table). Anybody got real hardware handy?


Cheers,
Andrew


org 32768
dump 32768

di
ld a,TABLEADDR/256
ld i,a
im 2
ei
@:  halt
jr @


TABLEADDR: equ 8100
ds TABLEADDR - $
for 254, DB 82
DB 8a, 92, 9a

BORDER: EQU 254

ds 8282 - $
ld a,0
out (BORDER),a
reti

ds 828a - $
ld a,1
out (BORDER),a
reti

ds 8292 - $
ld a,2
out (BORDER),a
reti

ds 829a - $
ld a,3
out (BORDER),a
reti

ds 8a82 - $
ld a,4
out (BORDER),a
reti

ds 8a8a - $
ld a,5
out (BORDER),a
reti

ds 8a92 - $
ld a,17
out (BORDER),a
reti

ds 8a9a - $
ld a,7
out (BORDER),a
reti

ds 9282 - $
ld a,32
out (BORDER),a
reti

ds 928a - $
ld a,33
out (BORDER),a
reti

ds 9292 - $
ld a,34
out (BORDER),a
reti

ds 929a - $
ld a,35
out (BORDER),a
reti

ds 9a82 - $
ld a,36
out (BORDER),a
reti

ds 9a8a - $
ld a,37
out (BORDER),a
reti

ds 9a92 - $
ld a,38
out (BORDER),a
reti

ds 9a9a - $
ld a,39
out (BORDER),a
reti





On 21 May 2008, at 00:02, David Brant wrote:

I've just been looking at my books. Although I can't find the bit  
that said about swapping to high,low but I'm sure that I did read it  
somewhere. It does say that the device only gives the bits 1-7 and  
bit 0 is always 0 giving 128 possible addresses.


Dave

- Original Message - From: David Brant [EMAIL PROTECTED] 


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 10:49 PM
Subject: Re: Short, short questions


This was based on info from a book called z-80 Workshop manual by  
E.A Parr. The I register gives the high part of the table and the  
hardware gives the low part to the table then takes that word for  
the service routine. So if you start from one byte before the table  
and use the same address for all entries and over run it by one it  
will work. My demo of a full scrolling football pitch used this  
system, which I believe you saw many years a go.


Dave

- Original Message - From: Andrew Collier [EMAIL PROTECTED] 


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:50 PM
Subject: Re: Short, short questions



Hi,

I'm sceptical about this claim. I've never heard anybody say that  
the vector formed is big-endian - it's just you don't know the  
byte offset from which the interrupt vector will be fetched. (As  
Edwin says, it is usually 255 - which is odd so your 1-aligned  
table will usually work - but I don't know that Sam's hardware  
guarantees this).


So the high byte comes from I, the low byte from the data bus;  
this forms a 16 bit address which will be incremented once (which  
is why  the table needs 257 bytes, not 256). You could, at least  
in theory,  read the vector address from even or odd overlapping  
entries, which is  why the usual strategy is to pick a vector  
address whose low and high  bytes are the same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE: equ $
IM2BYTE: equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET: equ 257*IM2TARGETBYTE
ds IM2TARGET-$

   EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte  
low  not the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

 DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
 di
 pushaf
 ina,(status.int)
.
.
 ei
 ret



- Original Message - From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a  
257- byte table all

containing the same byte.





--
---   Andrew Collier 
  http://www.intensity.org.uk/ ---
 --






--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --




Re: Short, short questions

2008-05-20 Thread Edwin Blink
All 8 bits are used for LSB of the vector. The part where bit 0 always is 
zero is when one of the Z80's IO chips is connected (PIO,SIO,CTC etc) is 
connected.


Edwin

- Original Message - 
From: David Brant [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Wednesday, May 21, 2008 1:02 AM
Subject: Re: Short, short questions


I've just been looking at my books. Although I can't find the bit that 
said about swapping to high,low but I'm sure that I did read it somewhere. 
It does say that the device only gives the bits 1-7 and bit 0 is always 0 
giving 128 possible addresses.


Dave

- Original Message - 
From: David Brant [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 10:49 PM
Subject: Re: Short, short questions


This was based on info from a book called z-80 Workshop manual by E.A 
Parr. The I register gives the high part of the table and the hardware 
gives the low part to the table then takes that word for the service 
routine. So if you start from one byte before the table and use the same 
address for all entries and over run it by one it will work. My demo of a 
full scrolling football pitch used this system, which I believe you saw 
many years a go.


Dave

- Original Message - 
From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:50 PM
Subject: Re: Short, short questions



Hi,

I'm sceptical about this claim. I've never heard anybody say that the 
vector formed is big-endian - it's just you don't know the byte offset 
from which the interrupt vector will be fetched. (As Edwin says, it is 
usually 255 - which is odd so your 1-aligned table will usually work - 
but I don't know that Sam's hardware guarantees this).


So the high byte comes from I, the low byte from the data bus; this 
forms a 16 bit address which will be incremented once (which is why  the 
table needs 257 bytes, not 256). You could, at least in theory,  read 
the vector address from even or odd overlapping entries, which is  why 
the usual strategy is to pick a vector address whose low and high  bytes 
are the same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE: equ $
IM2BYTE: equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET: equ 257*IM2TARGETBYTE
ds IM2TARGET-$

EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte low 
not the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

  DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
  di
  pushaf
  ina,(status.int)
 .
 .
  ei
  ret



- Original Message - From: Andrew Collier 
[EMAIL PROTECTED]


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257- 
byte table all

containing the same byte.





--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --










Re: Short, short questions

2008-05-20 Thread David Brant
I thought the idea of mode2 was you could have different vectors for 
different devices connected well this throws a spanner in the works. But 
then again is there any hardware for the SAM that uses them? I think it must 
have been an old spectrum book that said this about swapping high,low bytes. 
After a little test and using old brain this is wrong.


Dave

- Original Message - 
From: Edwin Blink [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Wednesday, May 21, 2008 5:34 AM
Subject: Re: Short, short questions


All 8 bits are used for LSB of the vector. The part where bit 0 always is 
zero is when one of the Z80's IO chips is connected (PIO,SIO,CTC etc) is 
connected.


Edwin

- Original Message - 
From: David Brant [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Wednesday, May 21, 2008 1:02 AM
Subject: Re: Short, short questions


I've just been looking at my books. Although I can't find the bit that 
said about swapping to high,low but I'm sure that I did read it 
somewhere. It does say that the device only gives the bits 1-7 and bit 0 
is always 0 giving 128 possible addresses.


Dave

- Original Message - 
From: David Brant [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 10:49 PM
Subject: Re: Short, short questions


This was based on info from a book called z-80 Workshop manual by E.A 
Parr. The I register gives the high part of the table and the hardware 
gives the low part to the table then takes that word for the service 
routine. So if you start from one byte before the table and use the same 
address for all entries and over run it by one it will work. My demo of 
a full scrolling football pitch used this system, which I believe you 
saw many years a go.


Dave

- Original Message - 
From: Andrew Collier [EMAIL PROTECTED]

To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 9:50 PM
Subject: Re: Short, short questions



Hi,

I'm sceptical about this claim. I've never heard anybody say that the 
vector formed is big-endian - it's just you don't know the byte offset 
from which the interrupt vector will be fetched. (As Edwin says, it is 
usually 255 - which is odd so your 1-aligned table will usually work - 
but I don't know that Sam's hardware guarantees this).


So the high byte comes from I, the low byte from the data bus; this 
forms a 16 bit address which will be incremented once (which is why 
the table needs 257 bytes, not 256). You could, at least in theory, 
read the vector address from even or odd overlapping entries, which is 
why the usual strategy is to pick a vector address whose low and high 
bytes are the same.


The last IM2 interrupt routine I wrote looked something like this:

ds ALIGN 256
IM2TABLE: equ $
IM2BYTE: equ im2table/256

IM2TARGETBYTE:  equ IM2BYTE+1
for 257, DB IM2TARGETBYTE

IM2TARGET: equ 257*IM2TARGETBYTE
ds IM2TARGET-$

EX   AF,AF'
...

Andrew


On 20 May 2008, at 21:16, David Brant wrote:

Mode 2 uses a table with 128 word address but as byte high,byte low 
not the normal low, high bytes


So if you set your org/dump address to ??FF (i.e. ??00-1)

and then do

  DEFWmode2.i,mode2.i

so you have 129 words.

mode2.i:
  di
  pushaf
  ina,(status.int)
 .
 .
  ei
  ret



- Original Message - From: Andrew Collier 
[EMAIL PROTECTED]


To: sam-users@nvg.ntnu.no
Sent: Tuesday, May 20, 2008 3:22 PM
Subject: Re: Short, short questions




The usual strategies are to use mode 1, or to use mode 2 with a 257- 
byte table all

containing the same byte.





--
 ---   Andrew Collier 
   http://www.intensity.org.uk/ ---
  --