SynthModules

Dave,

See syncable.bas in the file section under Code 
Fragments/Mbasic for how to talk to registers and enable and 
disable interupts. At least as far as we have figured out yet. That 
particular segment uses timer W, but the serial port should be 
similar.

Important notes:

1. All Peeks and Pokes are offset by $F780. The memory map is 
inverted from the Motorola model with flash at the bottom and 
RAM at the top. Poke 0 actually pokes to $F780, the start of RAM. 
None of this is documented except in the forums.

2. All the registers are protected keywords and are used directly. 
That is LET SSR = %00000000 or LET TEMP = TDR works. 
According to Nathan, DO NOT use pokes or peeks and do not 
define the registers or register addresses (it's automagic).

3. The interupt commands are compiler directives, not keywords. 
For example, disable the interupt right before the interupt handler 
name label, not inside the interupt handler routine itself.

Via Con Dios,

Grant

More notes:

4. Forget about using debug with interupt routines. They only 
work in real time.

5. Version 7.2 implements HSERIN and HSEROUT which are 
code blocks that use the hardware UART. In theory, they should 
take care of interupt processing for us. But direct register use 
may still needed for byte by byte message parsing, the HSERIN 
routine may add enough overhead so it can't handle MIDI data 
rates.

6. To use HSERIN you also have to enable it and use the 
SERSETUP command to initialize the UART.

--- In SynthModules@yahoogroups.com, "grantrichter2001" 
<grichter@a...> wrote:
> Dave,
> 
> See syncable.bas in the file section under Code 
> Fragments/Mbasic for how to talk to registers and enable and 
> disable interupts. At least as far as we have figured out yet. 
That 
> particular segment uses timer W, but the serial port should be 
> similar.
> 
> Important notes:
> 
> 1. All Peeks and Pokes are offset by $F780. The memory map 
is 
> inverted from the Motorola model with flash at the bottom and 
> RAM at the top. Poke 0 actually pokes to $F780, the start of 
RAM. 
> None of this is documented except in the forums.
> 
> 2. All the registers are protected keywords and are used 
directly. 
> That is LET SSR = %00000000 or LET TEMP = TDR works. 
> According to Nathan, DO NOT use pokes or peeks and do not 
> define the registers or register addresses (it's automagic).
> 
> 3. The interupt commands are compiler directives, not 
keywords. 
> For example, disable the interupt right before the interupt 
handler 

> name label, not inside the interupt handler routine itself.
> 
> Via Con Dios,
> 
> Grant

--- In SynthModules@yahoogroups.com, "grantrichter2001"
<grichter@a...> wrote:
> Dave,
>
> All the registers are protected keywords and are used directly. 
> That is LET SSR = %00000000 or LET TEMP = TDR works. 
> According to Nathan, DO NOT use pokes or peeks and do not 
> define the registers or register addresses (it's automagic).

Wow.  Who would have thought.  I changed all the peeks and pokes as
you described.  They all worked as your example EXCEPT for the PMR1. 
I still had to do that as a poke to enable the outputs.
 
> 3. The interupt commands are compiler directives, not keywords. 
> For example, disable the interupt right before the interupt handler 
> name label, not inside the interupt handler routine itself.

I'll have to try this.  I did use the HSERIN command along with all
the setup and compiler directives but could never generate an
interrupt.  More to try tomorrow.

Thanks

Dave

I also note that the new compiler has a C/C++ options with the ASM 
keyword :)  If BASIC isn't fast enough, this will do...

--- In SynthModules@yahoogroups.com, "grantrichter2001" 
<grichter@a...> wrote:

> More notes:
> 
> 4. Forget about using debug with interupt routines. They only 
> work in real time.
> 
> 5. Version 7.2 implements HSERIN and HSEROUT which are 
> code blocks that use the hardware UART. In theory, they should 
> take care of interupt processing for us. But direct register use 
> may still needed for byte by byte message parsing, the HSERIN 
> routine may add enough overhead so it can't handle MIDI data 
> rates.
> 
> 6. To use HSERIN you also have to enable it and use the 
> SERSETUP command to initialize the UART.
> 
> --- In SynthModules@yahoogroups.com, "grantrichter2001" 
> <grichter@a...> wrote:
> > Dave,
> > 
> > See syncable.bas in the file section under Code 
> > Fragments/Mbasic for how to talk to registers and enable and 
> > disable interupts. At least as far as we have figured out yet. 
> That 
> > particular segment uses timer W, but the serial port should be 
> > similar.
> > 
> > Important notes:
> > 
> > 1. All Peeks and Pokes are offset by $F780. The memory map 
> is 
> > inverted from the Motorola model with flash at the bottom and 
> > RAM at the top. Poke 0 actually pokes to $F780, the start of 
> RAM. 
> > None of this is documented except in the forums.
> > 
> > 2. All the registers are protected keywords and are used 
> directly. 
> > That is LET SSR = %00000000 or LET TEMP = TDR works. 
> > According to Nathan, DO NOT use pokes or peeks and do not 
> > define the registers or register addresses (it's automagic).
> > 
> > 3. The interupt commands are compiler directives, not 
> keywords. 
> > For example, disable the interupt right before the interupt 
> handler 
> > name label, not inside the interupt handler routine itself.
> > 
> > Via Con Dios,
> > 
> > Grant

> > 3. The interupt commands are compiler directives, not 
keywords. 
> > For example, disable the interupt right before the interupt 
handler 
> > name label, not inside the interupt handler routine itself.
> 
> I'll have to try this.  I did use the HSERIN command along with 
all
> the setup and compiler directives but could never generate an
> interrupt.  More to try tomorrow.

As I understand it, HSERIN is an interupt service routine built into 
BASIC. So you should either write your own ISR in BASIC and 
handle it on the register level OR use HSERIN and all BASIC, but 
not both, because HSERIN grabs the interupt for it's own use.

From the bleeding edge of technology...

--- In SynthModules@yahoogroups.com, "grantrichter2001"
<grichter@a...> wrote:
> Version 7.2 implements HSERIN and HSEROUT which are 
> code blocks that use the hardware UART. In theory, they should 
> take care of interupt processing for us. But direct register use 
> may still needed for byte by byte message parsing, the HSERIN 
> routine may add enough overhead so it can't handle MIDI data 
> rates.
> 
> To use HSERIN you also have to enable it and use the 
> SERSETUP command to initialize the UART.
> Grant

I did finally get the PMR1 to work without a poke.  Must have been a
late night moment.

I've played around with the HSERIN this morning.  When I do an
ENABLEHSERIAL and the SETHSERIAL command, the RE (receiver enable)
bit in SCR3 is set to 0.  I can't even turn it back on with a
SCR3=%11110000 command.  I'm suspecting that it might be enabled
within the HSERIN command.  As such, I don't know how to use this
with interrupts since I don't seem to be able to enable the receiver.

Dave

--- In SynthModules@yahoogroups.com, "grantrichter2001"
<grichter@a...> wrote:
> Dave,
> 
> See syncable.bas in the file section under Code 
> Fragments/Mbasic for how to talk to registers and enable and 
> disable interupts. At least as far as we have figured out yet. That 
> particular segment uses timer W, but the serial port should be 
> similar.
> 
> The interupt commands are compiler directives, not keywords. 
> For example, disable the interupt right before the interupt handler 
> name label, not inside the interupt handler routine itself.
> Grant

This is getting more weird.  I followed your lead and re-wrote the
interrupt routine.  In debug mode I can follow the code and see it
execute through the ISR and then exit.  This is significant progress
as before I could never exit the ISR.  However, none of the code
after executing the ISR seems to work correctly.  I traced it down to
all the variables I set within the ISR always are returned as 0.  I
wrote the following simple code:

	DISABLE SCI3INT_RDRF
MIDI_IN_ISR:
		MIDIDATA=RDR	'Read Receiver Data Register
		ctr=10
		debug [dec ctr,"=ctr "]
		end

When sent a MIDI command, it enters the ISR, prints in the debug
console, and halts.  However, the data written to the debug window
is:  0=ctr

No matter what variable or flag I put in the ISR, everthing reads
back as 0.  This is the same effect I saw in trying to read the SSR
register inside the ISR.  They also read as all 0's.

Your code clearly passes back MSEX.  I don't understand the
difference.

Dave

You have to use "resume" at the end of ISRs and not "end".

I'm guessing "resume" clears the interupt flag and passes 
variables back through the stack? Dpoe this thing even have a 
stack?

--- In SynthModules@yahoogroups.com, "djbrow54" 
<davebr@e...> wrote:
> --- In SynthModules@yahoogroups.com, "grantrichter2001"
> <grichter@a...> wrote:
> > Dave,
> > 
> > See syncable.bas in the file section under Code 
> > Fragments/Mbasic for how to talk to registers and enable 
and 
> > disable interupts. At least as far as we have figured out yet. 
That 
> > particular segment uses timer W, but the serial port should 
be 
> > similar.
> > 
> > The interupt commands are compiler directives, not 
keywords. 
> > For example, disable the interupt right before the interupt 
handler 
> > name label, not inside the interupt handler routine itself.
> > Grant
> 
> This is getting more weird.  I followed your lead and re-wrote 
the
> interrupt routine.  In debug mode I can follow the code and see 
it
> execute through the ISR and then exit.  This is significant 
progress
> as before I could never exit the ISR.  However, none of the code
> after executing the ISR seems to work correctly.  I traced it 
down to
> all the variables I set within the ISR always are returned as 0.  I
> wrote the following simple code:
> 
> 	DISABLE SCI3INT_RDRF
> MIDI_IN_ISR:
> 		MIDIDATA=RDR	'Read Receiver Data Register
> 		ctr=10
> 		debug [dec ctr,"=ctr "]
> 		end
> 
> When sent a MIDI command, it enters the ISR, prints in the 
debug
> console, and halts.  However, the data written to the debug 
window
> is:  0=ctr
> 
> No matter what variable or flag I put in the ISR, everthing reads
> back as 0.  This is the same effect I saw in trying to read the 
SSR

> register inside the ISR.  They also read as all 0's.
> 
> Your code clearly passes back MSEX.  I don't understand the
> difference.
> 
> Dave

--- In SynthModules@yahoogroups.com, "grantrichter2001" <grichter@a...> wrote:
> You have to use "resume" at the end of ISRs and not "end".
> 
> I'm guessing "resume" clears the interupt flag and passes 
> variables back through the stack? Dpoe this thing even have a 
> stack?
> 

I thought of that.  The reason I used the end code was that the code following the ISR never seemed to work right.  When I went to debug it I found that all the variables that I created during the ISR were always 0.  So I started using the debug routine in the ISR.  It always prints the variables as 0.  Then I started using the end statement to really prove that I was in the ISR.  Then I thought that perhaps there was some other mechanism that prevented the proper 'debug' within an ISR.  So my final test was to set a variable in the ISR and then perform conditional IF statements followed by END.  The program always terminates with a path that indicates the variables are 0.  There's got to be something else going on here but I sure don't know what.

Dave

--- In SynthModules@yahoogroups.com, "grantrichter2001"
<grichter@a...> wrote:
> Forget about using debug with interupt routines. They only 
> work in real time.
> Grant

I downloaded syncable.bas and tried to look at the variables in the
interrupt service routine.  I had assumed 'debug' above meant the
debug statement but soon figured out that it's really debug mode.

None of the variable commands (variable=variable+1) executed in
your interrupt service routine when using debug mode even with no debug
statements.

That means I'll have to debug the program by just trial and error in
program mode.

Hi Dave,
   this'll have to be fast... sorry
   i'm really under the gun at work right now but-

--- In SynthModules@yahoogroups.com, "djbrow54" <davebr@e...> wrote:
> 
> That means I'll have to debug the program by just trial and error in
> program mode.

that is correct. It appears to me that ISR's on the AtomPro can only be tested in 'program' (or runtime/realtime) mode. i will confirm that it is a pain in the ass, especially if you are used to more luxurious development environments. Syncable.bas took me several days of trial & error to debug. Oh well- C'est La AtomPro
It looks like you got your code running nonetheless - congrats

gotta go,
-doc