Adrian Brown
Wed, 21 May 2008 07:11:46 -0700
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] [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] [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 >>>>>> >>>>>> DEFW mode2.i,mode2.i >>>>>> >>>>>> so you have 129 words. >>>>>> >>>>>> mode2.i: >>>>>> di >>>>>> push af >>>>>> in a,(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. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. 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. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.