SynthModules

Continuing my thinking out loud on the MIDI input.

How would one handle a buffer in this BASIC?

It does not support STR$ command or some of the other 16K 
BASIC features for string handling.

It seems you would have to use an array variable and brute force 
move all bytes for a first in last out string.

Any suggestions?

(Observe as the MIDI-ignoramus climbs out onto a limb...)

Grant,
Why do we have to use string functions? The MIDI data is numeric.
--
john


----- Original Message ----- 

From: "grantrichter2001" <grichter@asapnet.net>


> Continuing my thinking out loud on the MIDI input.
> 
> How would one handle a buffer in this BASIC?
> 
> It does not support STR$ command or some of the other 16K 
> BASIC features for string handling.
> 
> It seems you would have to use an array variable and brute force 
> move all bytes for a first in last out string.
> 
> Any suggestions?

Hi Mark
 Ipromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthis

--- In SynthModules@yahoogroups.com, Mark Pulver <mark@m...> wrote:
> bunch of questions...
> 
> - I trust that there's ISR handling of some sort in the language 
> implementation?
>
yes, take a look at syncable.bas in the code fragments folder of the files section. it's not beautiful or very intuitive but it does appear to work
 
> - Is the PIC mapped such that you can control it? Either port or memory?
> 
don't know yet

> - Can the UART be setup to be memory mapped so that it dumps a byte 
> straight to memory, or is it port mapped?
>
don't know yet
 
> - Have you done any timings on reading from a port, moving a byte/word of 
> memory?
> 
the jury is still out...
so far...i get inconsistent results using TIMERW - One barrier appears to be that 31.25Kbaud has to be implemented as a custom baud rate it's not one of the 'standard' selections

> - Does this BASIC allow for PEEK and POKE? 
yes, 
but again i'm getting some erratic results, ie: not always PEEKing back what i POKEd to a static location
but i'm just getting my feet wet in this though so it's a bit early for me to make a call about how reliably PEEK & POKE work

>Can you get the address of a 
> variable? 
don't know - haven't tried
 
>The thought behind this is that PEEK/POKE would be faster than:
> 
>    CommBuffer[CommIndex] = $UARTIn
>    CommIndex = CommIndex + 1;
> 
definitely!
that's my instinct too. the big boogeyman with this micro-environment is the dire threat of the buffer spilling over with pitch-bend data or the like..

Ipromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthis
-doc

grantrichter2001 (08:37 AM 4/8/2004) wrote:

 >Continuing my thinking out loud on the MIDI input.
 >
 >How would one handle a buffer in this BASIC?
 >
 >It does not support STR$ command or some of the other 16K
 >BASIC features for string handling.
 >
 >It seems you would have to use an array variable and brute force
 >move all bytes for a first in last out string.
 >
 >Any suggestions?

This is where I was going with my questioning about how the PSIM program 
memory is organized... I wanted to get some background before I started 
babbling about the issues of BASIC as an ISR for a comm buffer.

Trying to do a FIFO buffer in a minimal BASIC will be most interesting. A 
bunch of questions...

- I trust that there's ISR handling of some sort in the language 
implementation?

- Is the PIC mapped such that you can control it? Either port or memory?

- Can the UART be setup to be memory mapped so that it dumps a byte 
straight to memory, or is it port mapped?

- Have you done any timings on reading from a port, moving a byte/word of 
memory?

- Does this BASIC allow for PEEK and POKE? Can you get the address of a 
variable? The thought behind this is that PEEK/POKE would be faster than:

   CommBuffer[CommIndex] = $UARTIn
   CommIndex = CommIndex + 1;


Just some random questions...

Mark

Mark,

It's not PIC based.  It has a Hitachi H8/3664 on it.  Read the datasheet in
the files section of the Group's site.  Yes, you can PEEK and POKE but there
may be easier ways to handle it.  I'm looking into this as well.

- Brice

"It's easy to play any musical instrument: all you have to do is touch the
right key at the right time and the instrument will play itself."
- J.S. Bach

----- Original Message ----- 

From: "Mark Pulver" <mark@midiwall.com>
To: <SynthModules@yahoogroups.com>
Sent: Thursday, April 08, 2004 11:48 AM
Subject: Re: [SynthModules] More on MIDI handler


> grantrichter2001 (08:37 AM 4/8/2004) wrote:
>
>  >Continuing my thinking out loud on the MIDI input.
>  >
>  >How would one handle a buffer in this BASIC?
>  >
>  >It does not support STR$ command or some of the other 16K
>  >BASIC features for string handling.
>  >
>  >It seems you would have to use an array variable and brute force
>  >move all bytes for a first in last out string.
>  >
>  >Any suggestions?
>
> This is where I was going with my questioning about how the PSIM program
> memory is organized... I wanted to get some background before I started
> babbling about the issues of BASIC as an ISR for a comm buffer.
>
> Trying to do a FIFO buffer in a minimal BASIC will be most interesting. A
> bunch of questions...
>
> - I trust that there's ISR handling of some sort in the language
> implementation?
>
> - Is the PIC mapped such that you can control it? Either port or memory?
>
> - Can the UART be setup to be memory mapped so that it dumps a byte
> straight to memory, or is it port mapped?
>
> - Have you done any timings on reading from a port, moving a byte/word of
> memory?
>
> - Does this BASIC allow for PEEK and POKE? Can you get the address of a
> variable? The thought behind this is that PEEK/POKE would be faster than:
>
>    CommBuffer[CommIndex] = $UARTIn
>    CommIndex = CommIndex + 1;
>
>
> Just some random questions...
>
> Mark
>
>
>
>
> Be sure to check out the primary Web site at:
> http://www.SynthModules.com
>
> Yahoo! Groups Links
>
>
>
>
>

(OK, so i'm not going about this in the most organized fashion!)

--- In SynthModules@yahoogroups.com, "grantrichter2001" <grichter@a...> wrote:
> Continuing my thinking out loud on the MIDI input.
> 
> How would one handle a buffer in this BASIC?
>
if you use PEEK/POKE there is a 2K 'buffer' available. This is just an educated guess but i'd say that's enough to handle a couple of channels of note-on + velocity (or equivalent) but not a whole lot more. There would need to be a serious 'bouncer' at the input, rejecting everything but the supported MIDI bytes. It wouldn't be luxurious but it's still looks do-able so far

Ipromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthis,

-doc

drmabuce (11:37 AM 4/8/2004) wrote:

 >Hi Mark
 > Ipromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyse
 >lfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutof
 >this

tee-hee. :)


 >--- In SynthModules@yahoogroups.com, Mark Pulver <mark@m...> wrote:
 >> bunch of questions...
 >>
 >> - I trust that there's ISR handling of some sort in the language
 >> implementation?
 >>
 >yes, take a look at syncable.bas in the code fragments folder of the files
 >section. it's not beautiful or very intuitive but it does appear to work

'k

{insert looking time...}
{gauging level of appropriate reaction...}
{issuing reaction...}

"eek".


 >> - Have you done any timings on reading from a port, moving a byte/word of
 >> memory?
 >>
 >the jury is still out...
 >so far...i get inconsistent results using TIMERW - One barrier appears to be
 >that 31.25Kbaud has to be implemented as a custom baud rate it's not one of
 >the 'standard' selections

Yeah... I was wondering how this was gonna work. The Magic Baud Rate has 
always been an issue in working with UARTs.


 >> - Does this BASIC allow for PEEK and POKE?
 >yes,
 >but again i'm getting some erratic results, ie: not always PEEKing
 >back what i POKEd to a static location but i'm just getting my feet
 >wet in this though so it's a bit early for me to make a call about
 >how reliably PEEK & POKE work

'k. What you may be seeing is that you've picked an address which is 
actually a memory mapped port, so the data at the "address" would change.

How did you pick the memory address to poke at?


 >>The thought behind this is that PEEK/POKE would be faster than:
 >>
 >>    CommBuffer[CommIndex] = $UARTIn
 >>    CommIndex = CommIndex + 1;
 >>
 >definitely!
 >that's my instinct too. the big boogeyman with this micro-environment
 >is the dire threat of the buffer spilling over with pitch-bend data or
 >the like..

Right... Which kinda' circles back to how fast you can move memory; how 
deep the INT buffer is on the H8; what the inherent overhead of an ISR is 
(in relation to moving data fast enough to keep up with pitch tracking); etc.


 >Ipromisedmyselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromised
 >myselfi'dstayoutofthisIpromisedmyselfi'dstayoutofthisIpromisedmyselfi'd
 >stayoutofthis

heh... All of my free time would be gone if I had my PSIM...

...in fact, I'd be tempted to bring it to work and create "free time" here 
to play with it. :)

Brice,
Producing the SpeakJet add-on *first* looks more sensible with each post.
;-)
--
john

What about assembly language code for the ISR?  The processor is 
fast, but probably not fast enough to keep up with servicing the 
buffer and staying sync'd to some other program, me thinks.  So 
MIDI<->CV only?

--- In SynthModules@yahoogroups.com, "Brice D. Hornback" 
<synthmodules@s...> wrote:
> Mark,
> 
> It's not PIC based.  It has a Hitachi H8/3664 on it.  Read the 
datasheet in
> the files section of the Group's site.  Yes, you can PEEK and POKE 
but there
> may be easier ways to handle it.  I'm looking into this as well.
> 
> - Brice
> 
> "It's easy to play any musical instrument: all you have to do is 
touch the
> right key at the right time and the instrument will play itself."
> - J.S. Bach
> 
> ----- Original Message ----- 
> From: "Mark Pulver" <mark@m...>
> To: <SynthModules@yahoogroups.com>
> Sent: Thursday, April 08, 2004 11:48 AM
> Subject: Re: [SynthModules] More on MIDI handler
> 
> 
> > grantrichter2001 (08:37 AM 4/8/2004) wrote:
> >
> >  >Continuing my thinking out loud on the MIDI input.
> >  >
> >  >How would one handle a buffer in this BASIC?
> >  >
> >  >It does not support STR$ command or some of the other 16K
> >  >BASIC features for string handling.
> >  >
> >  >It seems you would have to use an array variable and brute 
force
> >  >move all bytes for a first in last out string.
> >  >
> >  >Any suggestions?
> >
> > This is where I was going with my questioning about how the PSIM 
program
> > memory is organized... I wanted to get some background before I 
started
> > babbling about the issues of BASIC as an ISR for a comm buffer.
> >
> > Trying to do a FIFO buffer in a minimal BASIC will be most 
interesting. A
> > bunch of questions...
> >
> > - I trust that there's ISR handling of some sort in the language
> > implementation?
> >
> > - Is the PIC mapped such that you can control it? Either port or 
memory?
> >
> > - Can the UART be setup to be memory mapped so that it dumps a 
byte
> > straight to memory, or is it port mapped?
> >
> > - Have you done any timings on reading from a port, moving a 
byte/word of
> > memory?
> >
> > - Does this BASIC allow for PEEK and POKE? Can you get the 
address of a
> > variable? The thought behind this is that PEEK/POKE would be 
faster than:

> >
> >    CommBuffer[CommIndex] = $UARTIn
> >    CommIndex = CommIndex + 1;
> >
> >
> > Just some random questions...
> >
> > Mark
> >
> >
> >
> >
> > Be sure to check out the primary Web site at:
> > http://www.SynthModules.com
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >

Hi Mark
 BTW while i'm thinking about it, THANX for all the terrific content you've put on the web over the years. You are truly one of the guys who made the internet-era analog renaissance fun for all...Kudos!


--- In SynthModules@yahoogroups.com, Mark Pulver <mark@m...> wrote:

>  >how reliably PEEK & POKE work
> 
> 'k. What you may be seeing is that you've picked an address which is 
> actually a memory mapped port, so the data at the "address" would change.
> 
> How did you pick the memory address to poke at?

I don't know if you saw my reply to Grant, but I was mistook!
PEEK & POKE work fine - they default to 8b Bytes. (I had my variable typed incorrectly) But you have only 2k of memory to work with (f780 to FFFF) 

> 
> Right... Which kinda' circles back to how fast you can move memory; how 
> deep the INT buffer is on the H8; what the inherent overhead of an ISR is 
> (in relation to moving data fast enough to keep up with pitch tracking); etc.
> 
>
Plus... assembler support is still pretty vaporous....
besides
I have Kenton boxes that do a ripping job of MIDI->CV !
and thus insufficient motivation to climb this glass hill (again) I did one commercial MIDI-imp in the 80's and swore to gouge out my own eyes if I ever even THOUGHT of doing it again! 
I like the PSIM for the unique things it does. IMHO a dedicated MIDI-CV box yields much more bang/buck - and that frees up the PSIM to do envelope generation with time ranges measured in HOURS or LFO's based on fractal curves (which the Kenton doesn't do very well...) 
;'> 

> 
> heh... All of my free time would be gone if I had my PSIM...
> 
> ...in fact, I'd be tempted to bring it to work and create "free time" here 
> to play with it. :)

hmmmmmmmmmm,
just mount it in a discarded zip drive housing.....
THANX!

best-
-doc

I'm guessing about a 20 microsecond execution time for an 
equate. Each MIDI byte takes 320 microseconds. You could 
execute about 8 - 16 simple BASIC commands in each byte time.

Something as simple as:

TEMP = RDR 'read recieve data register
POKE INDEX, TEMP ' store byte in RAM buffer
INDEX = INDEX + 1 'increment index pointer
IF INDEX > 256 THEN ERROR 'buffer over run
RESUME 'reset interupt flag

Just off the top of my head that should take about 150 
microseconds. That uses less than 50% compute time even 
with a constant MIDI stream, assuming the mainline program 
can process the buffer fast enough to keep INDEX from going 
over 256 bytes.

--- In SynthModules@yahoogroups.com, "Mike Marsh" 
<mmarsh@w...> wrote:
> What about assembly language code for the ISR?  The 
processor is 
> fast, but probably not fast enough to keep up with servicing the 
> buffer and staying sync'd to some other program, me thinks.  
So 
> MIDI<->CV only?
> 
> --- In SynthModules@yahoogroups.com, "Brice D. Hornback" 
> <synthmodules@s...> wrote:
> > Mark,
> > 
> > It's not PIC based.  It has a Hitachi H8/3664 on it.  Read the 
> datasheet in
> > the files section of the Group's site.  Yes, you can PEEK and 
POKE 
> but there
> > may be easier ways to handle it.  I'm looking into this as well.
> > 
> > - Brice
> > 
> > "It's easy to play any musical instrument: all you have to do is 
> touch the
> > right key at the right time and the instrument will play itself."
> > - J.S. Bach
> > 
> > ----- Original Message ----- 
> > From: "Mark Pulver" <mark@m...>
> > To: <SynthModules@yahoogroups.com>
> > Sent: Thursday, April 08, 2004 11:48 AM
> > Subject: Re: [SynthModules] More on MIDI handler
> > 
> > 
> > > grantrichter2001 (08:37 AM 4/8/2004) wrote:
> > >
> > >  >Continuing my thinking out loud on the MIDI input.
> > >  >
> > >  >How would one handle a buffer in this BASIC?
> > >  >
> > >  >It does not support STR$ command or some of the other 
16K
> > >  >BASIC features for string handling.
> > >  >
> > >  >It seems you would have to use an array variable and 
brute 
> force
> > >  >move all bytes for a first in last out string.
> > >  >
> > >  >Any suggestions?
> > >
> > > This is where I was going with my questioning about how 
the PSIM 
> program
> > > memory is organized... I wanted to get some background 
before I 
> started
> > > babbling about the issues of BASIC as an ISR for a comm 
buffer.
> > >
> > > Trying to do a FIFO buffer in a minimal BASIC will be most 
> interesting. A
> > > bunch of questions...
> > >
> > > - I trust that there's ISR handling of some sort in the 
language
> > > implementation?
> > >
> > > - Is the PIC mapped such that you can control it? Either port 
or 
> memory?
> > >
> > > - Can the UART be setup to be memory mapped so that it 
dumps a 
> byte
> > > straight to memory, or is it port mapped?
> > >
> > > - Have you done any timings on reading from a port, 
moving a 
> byte/word of
> > > memory?
> > >
> > > - Does this BASIC allow for PEEK and POKE? Can you get 
the 
> address of a
> > > variable? The thought behind this is that PEEK/POKE 
would be 

> faster than:
> > >
> > >    CommBuffer[CommIndex] = $UARTIn
> > >    CommIndex = CommIndex + 1;
> > >
> > >
> > > Just some random questions...
> > >
> > > Mark
> > >
> > >
> > >
> > >
> > > Be sure to check out the primary Web site at:
> > > http://www.SynthModules.com
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >

john mahoney (01:46 PM 4/8/2004) wrote:

 >Brice,
 >Producing the SpeakJet add-on *first* looks more sensible with each post.
 >;-)

:)

Although I dunno if I'd use the SpeakJet module (though I will buy one!), I 
agree.


Mark

Here here!

--- In SynthModules@yahoogroups.com, "drmabuce" <drmabuce@y...> wrote:
> Hi Mark
>  BTW while i'm thinking about it, THANX for all the terrific 
content you've put on the web over the years. You are truly one of 
the guys who made the internet-era analog renaissance fun for 
all...Kudos!
> 
> 
> --- In SynthModules@yahoogroups.com, Mark Pulver <mark@m...> wrote:
> 
> >  >how reliably PEEK & POKE work
> > 
> > 'k. What you may be seeing is that you've picked an address which 
is 
> > actually a memory mapped port, so the data at the "address" would 
change.
> > 
> > How did you pick the memory address to poke at?
> 
> I don't know if you saw my reply to Grant, but I was mistook!
> PEEK & POKE work fine - they default to 8b Bytes. (I had my 
variable typed incorrectly) But you have only 2k of memory to work 
with (f780 to FFFF) 
> 
> > 
> > Right... Which kinda' circles back to how fast you can move 
memory; how 
> > deep the INT buffer is on the H8; what the inherent overhead of 
an ISR is 
> > (in relation to moving data fast enough to keep up with pitch 
tracking); etc.
> > 
> >
> Plus... assembler support is still pretty vaporous....
> besides
> I have Kenton boxes that do a ripping job of MIDI->CV !
> and thus insufficient motivation to climb this glass hill (again) I 
did one commercial MIDI-imp in the 80's and swore to gouge out my own 
eyes if I ever even THOUGHT of doing it again! 
> I like the PSIM for the unique things it does. IMHO a dedicated 
MIDI-CV box yields much more bang/buck - and that frees up the PSIM 
to do envelope generation with time ranges measured in HOURS or LFO's 
based on fractal curves (which the Kenton doesn't do very well...) 
> ;'> 
> 
> > 
> > heh... All of my free time would be gone if I had my PSIM...
> > 
> > ...in fact, I'd be tempted to bring it to work and create "free 
time" here 

> > to play with it. :)
> 
> hmmmmmmmmmm,
> just mount it in a discarded zip drive housing.....
> THANX!
> 
> best-
> -doc

My primary interest if to store high resolution data on a MIDI 
recorder. Pitch bend is a 14 bit data type. If you store 4 channels 
of pitch bend data, and can decode 4 channels of pitch bend 
data, you have a high resolution 4 channel control voltage 
recorder which can be edited graphically with unlimited lenght 
sequences.

Could be useful...

--- In SynthModules@yahoogroups.com, "Mike Marsh" 
<mmarsh@w...> wrote:
> Here here!
> 
> --- In SynthModules@yahoogroups.com, "drmabuce" 
<drmabuce@y...> wrote:
> > Hi Mark
> >  BTW while i'm thinking about it, THANX for all the terrific 
> content you've put on the web over the years. You are truly one 
of 
> the guys who made the internet-era analog renaissance fun for 
> all...Kudos!
> > 
> > 
> > --- In SynthModules@yahoogroups.com, Mark Pulver 
<mark@m...> wrote:
> > 
> > >  >how reliably PEEK & POKE work
> > > 
> > > 'k. What you may be seeing is that you've picked an 
address which 
> is 
> > > actually a memory mapped port, so the data at the 
"address" would 
> change.
> > > 
> > > How did you pick the memory address to poke at?
> > 
> > I don't know if you saw my reply to Grant, but I was mistook!
> > PEEK & POKE work fine - they default to 8b Bytes. (I had my 
> variable typed incorrectly) But you have only 2k of memory to 
work 
> with (f780 to FFFF) 
> > 
> > > 
> > > Right... Which kinda' circles back to how fast you can move 
> memory; how 
> > > deep the INT buffer is on the H8; what the inherent 
overhead of 
> an ISR is 
> > > (in relation to moving data fast enough to keep up with pitch 
> tracking); etc.
> > > 
> > >
> > Plus... assembler support is still pretty vaporous....
> > besides
> > I have Kenton boxes that do a ripping job of MIDI->CV !
> > and thus insufficient motivation to climb this glass hill (again) 
I 
> did one commercial MIDI-imp in the 80's and swore to gouge 
out my own 
> eyes if I ever even THOUGHT of doing it again! 
> > I like the PSIM for the unique things it does. IMHO a 
dedicated 
> MIDI-CV box yields much more bang/buck - and that frees up 
the PSIM 
> to do envelope generation with time ranges measured in 
HOURS or LFO's 
> based on fractal curves (which the Kenton doesn't do very 
well...) 

> > ;'> 
> > 
> > > 
> > > heh... All of my free time would be gone if I had my PSIM...
> > > 
> > > ...in fact, I'd be tempted to bring it to work and create "free 
> time" here 
> > > to play with it. :)
> > 
> > hmmmmmmmmmm,
> > just mount it in a discarded zip drive housing.....
> > THANX!
> > 
> > best-
> > -doc

drmabuce (09:18 PM 4/8/2004) wrote:

 >Hi Mark
 > BTW while i'm thinking about it, THANX for all the terrific content you've
 >put on the web over the years. You are truly one of the guys who made the
 >internet-era analog renaissance fun for all...Kudos!

(Sorry for the slow response, I just got back from 3 days in Las Vegas and 
I didn't want this to go unnoticed...)

Thank you for the thanks Doc! I love to babble. :)


On the topic of all the MIDI babble, a big WOOHOO! out to Dave!

Nice work in digging through the weird undocumented world of ATOMPRO and 
getting this to fire up!

YAYAYAYAYAYAYAY!!!!!!!!!!!!

Mark