RE: Short, short questions
Ok, i haven't read all the posts on this, but why not stick the code in
LMPR and use IM1 - saves having the table of vectors.
Adrian
** UIP Sam Port 4100+ lines of z80 and climbing
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Brant
Sent: 21 May 2008 06:46
To: sam-users@nvg.ntnu.no
Subject: Re: Short, short questions
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/ ---
--
APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock,
Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number: 4942193.
V.A.T. No: 826 0005 70
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system
RE: Short, short questions
I have to admit I was wondering the same. IM2 was necessary on the speccy
because 0x38 was in ROM and couldn't be paged out but I see no reason not
to use IM1 on the Sam. I'm quite happy to be told otherwise, of course :)
Geoff
On Wed, 21 May 2008 13:50:14 +0100, Adrian Brown
[EMAIL PROTECTED] wrote:
Ok, i haven't read all the posts on this, but why not stick the code in
LMPR and use IM1 - saves having the table of vectors.
Adrian
** UIP Sam Port 4100+ lines of z80 and climbing
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Brant
Sent: 21 May 2008 06:46
To: sam-users@nvg.ntnu.no
Subject: Re: Short, short questions
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/ ---
--
APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock,
Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number:
4942193. V.A.T. No: 826 0005 70
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email
Re: Short, short questions
Adrian Brown wrote: Ok, i haven't read all the posts on this, but why not stick the code in LMPR and use IM1 - saves having the table of vectors. That's my favoured approach too. ** UIP Sam Port 4100+ lines of z80 and climbing Woo! It's so tantilisingly close! David Brant wrote: But then again is there any hardware for the SAM that uses them? As far as I'm aware there's nothing. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
RE: Short, short questions
Has to be said the first thing my code does is page itself into LMPR addr 0 and
sit there :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Winkless
Sent: 21 May 2008 14:46
To: Adrian
Subject: RE: Short, short questions
I have to admit I was wondering the same. IM2 was necessary on the speccy
because 0x38 was in ROM and couldn't be paged out but I see no reason not
to use IM1 on the Sam. I'm quite happy to be told otherwise, of course :)
Geoff
On Wed, 21 May 2008 13:50:14 +0100, Adrian Brown
[EMAIL PROTECTED] wrote:
Ok, i haven't read all the posts on this, but why not stick the code in
LMPR and use IM1 - saves having the table of vectors.
Adrian
** UIP Sam Port 4100+ lines of z80 and climbing
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Brant
Sent: 21 May 2008 06:46
To: sam-users@nvg.ntnu.no
Subject: Re: Short, short questions
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/ ---
--
APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock,
Congdons Shop
Re: Short, short questions
Hi, I'm using IM2 in ... um, a current project ... in which I have more spite drawing code than will fit in 32k. Thus I need to keep the screen in one half of memory while the other half is a moveable window into other pages. If I used IM1 this would require that either, a) the screen goes in sections A and B, and the interrupt routine is actuially visible in pixels - or b) the moveable window goes in sections A and B, and I have to duplicate the interrupt routine in nearly every page of memory. So I'm using IM2 instead, and the interrupt routine can slot into the last 8k following the screen. Cheers, Andrew On Wed, May 21, 2008 at 02:08:51PM +0100, Geoff Winkless wrote: I have to admit I was wondering the same. IM2 was necessary on the speccy because 0x38 was in ROM and couldn't be paged out but I see no reason not to use IM1 on the Sam. I'm quite happy to be told otherwise, of course :) Geoff On Wed, 21 May 2008 13:50:14 +0100, Adrian Brown [EMAIL PROTECTED] wrote: Ok, i haven't read all the posts on this, but why not stick the code in LMPR and use IM1 - saves having the table of vectors. Adrian ** UIP Sam Port 4100+ lines of z80 and climbing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brant Sent: 21 May 2008 06:46 To: sam-users@nvg.ntnu.no Subject: Re: Short, short questions 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
Re: Short, short questions
If you interrupt routine is small, could you not also just switch off the first one or two scanlines of your display, and even grab a few extra cycles out as a result? Or can you not enable and disable the display per scanline? And, yes, I know I'm missing the point with this question, I'm just curious. On Wed, May 21, 2008 at 3:12 PM, Andrew Collier [EMAIL PROTECTED] wrote: Hi, I'm using IM2 in ... um, a current project ... in which I have more spite drawing code than will fit in 32k. Thus I need to keep the screen in one half of memory while the other half is a moveable window into other pages. If I used IM1 this would require that either, a) the screen goes in sections A and B, and the interrupt routine is actuially visible in pixels - or b) the moveable window goes in sections A and B, and I have to duplicate the interrupt routine in nearly every page of memory. So I'm using IM2 instead, and the interrupt routine can slot into the last 8k following the screen. Cheers, Andrew On Wed, May 21, 2008 at 02:08:51PM +0100, Geoff Winkless wrote: I have to admit I was wondering the same. IM2 was necessary on the speccy because 0x38 was in ROM and couldn't be paged out but I see no reason not to use IM1 on the Sam. I'm quite happy to be told otherwise, of course :) Geoff On Wed, 21 May 2008 13:50:14 +0100, Adrian Brown [EMAIL PROTECTED] wrote: Ok, i haven't read all the posts on this, but why not stick the code in LMPR and use IM1 - saves having the table of vectors. Adrian ** UIP Sam Port 4100+ lines of z80 and climbing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brant Sent: 21 May 2008 06:46 To: sam-users@nvg.ntnu.no Subject: Re: Short, short questions 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
Re: Short, short questions
Really it was related to my first question - I was considering the plausability of moving my data table to be positioned around address zero when I wrote the post. And obviously a table that reaches 2kb in either direction from address 0 covers address 0x0038. Tests last night with an older, slower version of multiply, suggest that I'm now using around 4,000 cycles to transform a point in world space (9 multiplies, 6 adds) and another 5,000ish to project it to the screen (2 divides, 2 adds, some hard-coded-with-shifts multiplying by 128 and 96). Moving the multiply table so that it is centred around 0 should cut about 1/4 from the transformation time, so 1/9 from the time I spend on points. Which I think is worth it. But obviously I need to do something about my divides. On Wed, May 21, 2008 at 2:29 PM, Colin Piggot [EMAIL PROTECTED] wrote: Adrian Brown wrote: Ok, i haven't read all the posts on this, but why not stick the code in LMPR and use IM1 - saves having the table of vectors. That's my favoured approach too. ** UIP Sam Port 4100+ lines of z80 and climbing Woo! It's so tantilisingly close! David Brant wrote: But then again is there any hardware for the SAM that uses them? As far as I'm aware there's nothing. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Short, short questions
Andrew Collier wrote: If I used IM1 this would require that either, a) the screen goes in sections A and B, and the interrupt routine is actuially visible in pixels - or b) the moveable window goes in sections A and B, and I have to duplicate the interrupt routine in nearly every page of memory. That's the approach I was taking years ago for Chrome, I'd have a couple K dedicated to the main core of the code and interrupt routines at the start of many 32K chunks of code and sprite data, so AB pages could be shifted around keeping the screen in CD - with the 8K above the screen holding other data. Thomas Harte wrote: If you interrupt routine is small, could you not also just switch off the first one or two scanlines of your display, and even grab a few extra cycles out as a result? Or can you not enable and disable the display per scanline? That could be done using line interrupts, perhaps use the Frame Interrupt to switch the screen off, then just a single line interrupt to trigger an interrupt at a certain scan line and re-enable the screen. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Short, short questions
On Wed, 21 May 2008 15:29:28 +0100, Colin Piggot [EMAIL PROTECTED] wrote: Andrew Collier wrote: If I used IM1 this would require that either, a) the screen goes in sections A and B, and the interrupt routine is actuially visible in pixels - or b) the moveable window goes in sections A and B, and I have to duplicate the interrupt routine in nearly every page of memory. That's the approach I was taking years ago for Chrome, I'd have a couple K dedicated to the main core of the code and interrupt routines at the start of many 32K chunks of code and sprite data, so AB pages could be shifted around keeping the screen in CD - with the 8K above the screen holding other data. You'd only need 3 bytes in each page to jump to 57344 (or 57400, maybe). So that's 96 bytes taken rather than 256, although they're spread out through memory which could cause problems... You're right, though, Andrew - your example hadn't occurred to me. I did say I was happy to be wrong :) Geoff
Re: Short, short questions
On Wed, May 21, 2008 at 03:16:07PM +0100, Thomas Harte wrote: If you interrupt routine is small, could you not also just switch off the first one or two scanlines of your display, and even grab a few extra cycles out as a result? Or can you not enable and disable the display per scanline? Hi, You could, yes. You can alter pretty much anything about the screen on a line-by-line basis - and if you're very careful, during those lines in the screen area itself! For example, MMENOdemo 1 part 2 (on Fred 60) changes the screen page during the raster; repeatedly switching between foreground and background screens to draw lit and unlit rectabgles - which togehter form a scrolling message. Various other programs switch between mode 4 and mode 3, to get high resolution in a certain area of the screen - Edwin Blink's menu on Blitz (issue 6, was it?) and David Laundon's Fred menu come to mind. Anyway - in this particular case I wanted to display the whole screen; and in the case of one or two scanlines, it probably takes longer to set up the line interrupt handling, than you save by having the screen turned off. Cheers, 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
Literally anything? On many of the machines I have written emulators for, most things are usually completely changeable but some things are loaded internally — especially on any machine that has a variable screen start address. Also, one further question: am I right to think that the Sam has no means of producing interlaced video? On Wed, May 21, 2008 at 3:58 PM, Andrew Collier [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 03:16:07PM +0100, Thomas Harte wrote: If you interrupt routine is small, could you not also just switch off the first one or two scanlines of your display, and even grab a few extra cycles out as a result? Or can you not enable and disable the display per scanline? Hi, You could, yes. You can alter pretty much anything about the screen on a line-by-line basis - and if you're very careful, during those lines in the screen area itself! For example, MMENOdemo 1 part 2 (on Fred 60) changes the screen page during the raster; repeatedly switching between foreground and background screens to draw lit and unlit rectabgles - which togehter form a scrolling message. Various other programs switch between mode 4 and mode 3, to get high resolution in a certain area of the screen - Edwin Blink's menu on Blitz (issue 6, was it?) and David Laundon's Fred menu come to mind. Anyway - in this particular case I wanted to display the whole screen; and in the case of one or two scanlines, it probably takes longer to set up the line interrupt handling, than you save by having the screen turned off. Cheers, 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
Thomas Harte wrote: Literally anything? On many of the machines I have written emulators for, most things are usually completely changeable but some things are loaded internally — especially on any machine that has a variable screen start address. Not literally anything, you can change the screen page, or screen mode by changing VMPR and you'll have to come up with line interrupt routine to carry out the changes, either say at the start of the scan line, or wait till a certain way along the screen using NOPs as padding etc. Also, one further question: am I right to think that the Sam has no means of producing interlaced video? Correct, the SAM only produces a non-interlaced PAL output. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Short, short questions
Hi,
Well - at least, any of the things you can ever change, yes! screen on/off,
border colour, palette, screen mode, ram page, etc.
Early versions of SimCoupe didn't support these changes better than once per
line. I remember Allan (or was it Simon?) telling me he had never realised
that the E-Tunes player from Fred 63 and on, even had a scrolly message -
because at the time, SimCoupe wasn't able to display it.
Also, one further question: am I right to think that the Sam has no
means of producing interlaced video?
Correct. Always non-interlaced (despite various examples on Fred of flickery
pictures which purported otherwise).
Andrew
On Wed, May 21, 2008 at 04:36:34PM +0100, Thomas Harte wrote:
Literally anything? On many of the machines I have written emulators
for, most things are usually completely changeable but some things are
loaded internally — especially on any machine that has a variable
screen start address.
Also, one further question: am I right to think that the Sam has no
means of producing interlaced video?
On Wed, May 21, 2008 at 3:58 PM, Andrew Collier [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 03:16:07PM +0100, Thomas Harte wrote:
If you interrupt routine is small, could you not also just switch off
the first one or two scanlines of your display, and even grab a few
extra cycles out as a result? Or can you not enable and disable the
display per scanline?
Hi,
You could, yes. You can alter pretty much anything about the screen on a
line-by-line basis - and if you're very careful, during those lines in the
screen area itself! For example, MMENOdemo 1 part 2 (on Fred 60) changes the
screen page during the raster; repeatedly switching between foreground and
background screens to draw lit and unlit rectabgles - which togehter form a
scrolling message.
Various other programs switch between mode 4 and mode 3, to get high
resolution in a certain area of the screen - Edwin Blink's menu on Blitz
(issue 6, was it?) and David Laundon's Fred menu come to mind.
Anyway - in this particular case I wanted to display the whole screen; and
in
the case of one or two scanlines, it probably takes longer to set up the
line
interrupt handling, than you save by having the screen turned off.
Cheers,
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
--
--- 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
On Wed, 21 May 2008 17:09:32 +0100, Andrew Collier [EMAIL PROTECTED] wrote: Correct. Always non-interlaced (despite various examples on Fred of flickery pictures which purported otherwise). While (on a TV with 576 visible lines) you won't be able to get a 192 line output device to output alternate lines on a TV display by switching between two screens (since the pixels will take up more than one scan line), you should be able to get a weird kind of subpixel colouring which (ISTR) was what they were trying to do in the 16-bit colour demo on the Crash tape, IIRC. Geoff
Re: Short, short questions
But Sim Coupe duplicates all known characteristics of the real
hardware now, right?
I was actually involved in writing emualtors as early as 1998, and
most of the early ones were horrible. Pretty much anything by Marat
Fayzulin or derived from his source still is — they're usually run
the CPU for exactly this many cycles (usually one scanline of
display), then give all the support chips a chance to update their
state. Which is obviously just a cop out by unimaginative programmers
and in most cases are trivially incorrect.
Anyway, I think I've confused myself somewhere else, is Mode 2 no
faster than Modes 3 and 4, or is it a little faster but not as much
faster as having half the bytes to fetch should imply?
On Wed, May 21, 2008 at 5:09 PM, Andrew Collier [EMAIL PROTECTED] wrote:
Hi,
Well - at least, any of the things you can ever change, yes! screen on/off,
border colour, palette, screen mode, ram page, etc.
Early versions of SimCoupe didn't support these changes better than once per
line. I remember Allan (or was it Simon?) telling me he had never realised
that the E-Tunes player from Fred 63 and on, even had a scrolly message -
because at the time, SimCoupe wasn't able to display it.
Also, one further question: am I right to think that the Sam has no
means of producing interlaced video?
Correct. Always non-interlaced (despite various examples on Fred of flickery
pictures which purported otherwise).
Andrew
On Wed, May 21, 2008 at 04:36:34PM +0100, Thomas Harte wrote:
Literally anything? On many of the machines I have written emulators
for, most things are usually completely changeable but some things are
loaded internally — especially on any machine that has a variable
screen start address.
Also, one further question: am I right to think that the Sam has no
means of producing interlaced video?
On Wed, May 21, 2008 at 3:58 PM, Andrew Collier [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 03:16:07PM +0100, Thomas Harte wrote:
If you interrupt routine is small, could you not also just switch off
the first one or two scanlines of your display, and even grab a few
extra cycles out as a result? Or can you not enable and disable the
display per scanline?
Hi,
You could, yes. You can alter pretty much anything about the screen on a
line-by-line basis - and if you're very careful, during those lines in the
screen area itself! For example, MMENOdemo 1 part 2 (on Fred 60) changes
the
screen page during the raster; repeatedly switching between foreground and
background screens to draw lit and unlit rectabgles - which togehter form a
scrolling message.
Various other programs switch between mode 4 and mode 3, to get high
resolution in a certain area of the screen - Edwin Blink's menu on Blitz
(issue 6, was it?) and David Laundon's Fred menu come to mind.
Anyway - in this particular case I wanted to display the whole screen; and
in
the case of one or two scanlines, it probably takes longer to set up the
line
interrupt handling, than you save by having the screen turned off.
Cheers,
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
--
--- 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
On Wed, May 21, 2008 at 05:28:58PM +0100, Thomas Harte wrote: But Sim Coupe duplicates all known characteristics of the real hardware now, right? All the ones that I know about, certainly. Even the little ASIC quirks like single-pixel vertical lines in the border (this is something Simon Cooke pointed out to me and I used at the very very bottom of the screen in Fred 65 menu - it's fun but of little practical value...) Anyway, I think I've confused myself somewhere else, is Mode 2 no faster than Modes 3 and 4, or is it a little faster but not as much faster as having half the bytes to fetch should imply? The number of available t-states per second is the same in mode 2, 3 and 4. Cheers, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/ --- --
