More Digital Content......

[POLARIS at VAX1.Mankato.MSUS.EDU]

First off, I must publicly thank all who responded to the query.  I should
have mentioned that this is by far the most digital I've been, ever.  I.E.,
I'm among the digitally-challenged. As a result, all of your suggestions
were thought provoking, and some just plain beyond my faculties! :) 

Here are some responses I thought of to all of your fine thoughts:
(Sorry for the long post)
---------------------------------------------------------------------

Brad Sanders wrote:

>2048? so do you want hex - or BCD? Hex is easy: ues three binary>hex
>decoder chips (7441 I think).

>BCD is harder. My suggestion is you learn to use hex.


Well, if by hex you mean that I'd be reading numbers on the front
panel like 4FA3 or something, I'd rather avoid this.  If this isn't
what you meant, could you please illucidate?  Is there a way to go
from the Hex to BCD?

----------------------------------------------------------------------

Don wrote:

>The "painstakingly proper" approach would be to build a binary-to-BCD
>converter which would work arithmetically the same as you'd do it by
>hand.  I think there are some CMOS chips available that do this four
>bits at a time.
 
If anyone knows of such chips, I'd be gratefull to hear from you. I've 
seen 4-digit LED modules with some sort of decoder built-in, but I
think these are meant to count clock pulses.  Are there any which
display big binary numbers directly (for example, 11111111111 would
show up as 2047 on the display, etc...)

>A far more practical approach is to just use BCD counters to address
>the SRAM, 11-bits counting from 000 to 799, wasting off a fraction of
>the memory.  Not enough for you?  Use larger SRAM, it's dirt cheap.

Hmmm, this sounds reasonable. I'll look into it. I really didn't need
all 2048 notes anyway....

----------------------------------------------------------------------

JBV wrote:

>I didn't spend more than one minute on the problem, but why don't you
>use a ROM ? At first glance, I find it worth exploring that direction...
>The ROM would be adressed in 8 bits like the RAM, and its outputs would
>drive the BCD-segments.
>Of course, you would have to design "by hand" the code to burn into the
>ROM,
>(and even perhaps be forced to use more than one ROM if several
>BCD-segments),
>but I think the confort and ergonomics of the final result are worth
>handling this painstaking task.

I actually thought of this; there would be four LED displays (0-9999 
capability to cover the 2048 memory locations), so there would be four
groups of 4-bit BCD code.  That means 16 bits of the corresponding BCD
data need be stored for each memory address of the RAM.  No real problem
there.  Hmmmm....

----------------------------------------------------------------------

David Halliday wrote:

>Rather than going with a hardwired logic setup, why not take it one step
>farther and go with a BASIC Stamp or PIC microprocessor.  I do not know
>of pricing and availability in Europe but in the states, they are cheap
>( $30 ) for a full system.  The system is about 1 by 3 centemeters, runs
>from a 9-volt battery, uses serial input from a program running on your
>computer and it has a number ( varies with the model ) of digital I/O
>lines, analog (8-bit only) analog lines, on-board counter/timers, etc...

This one sounds sounds too sophistocated.  I'm a guy who gets the OR and
AND gate symbols confused.  What you're proposing is probably a really
great solution, only it went entirely over my head (making a cold digital
sound when it finally landed on the floor behind me ;) Seriously, could
you elaborate on this idea?

-----------------------------------------------------------------------

Ken Stone wrote:

>Simply have the reset pulse you use to reset the address counters reset the
>display counters at the same time. As long as they are always reset together
>and receive clock pulses together, they should remain in sync.

Ok, I thought something like that would work, but wasn't sure.  I guess
the only drawback to this scheme is the idea that the system could ever
get out of synch (but then again, I guess as long as didn't happen in-use,
it wouldn't really matter which memory was _called_ 0001, as long it stayed
that afterward.)
Hmmmm....

>However... there are better ways of tackling the whole project as suggested
>by others. A CPU of some sort would be a good idea. Perhaps you could do
>what I do and drive it off the parallel port of your pc and do everything in
>software. You can even save your sequences to disk.

Well, I'd do that if A) I understood that, and B)I had a computer.  I'm
using the school's computer lab for now (and getting full use of that pesky 
tuition!)  Still, saving the sequences would be nice, but then again, if
one were using the computer approach, it might be better to just go the
MIDI route.

--------------------------------------------------------------------------

Wow, thanks again for the friendly, helpful advice.  

I do have a related question: What sort of D/A and A/D would you use
in this application? (Yes, my keyboard is an analog interface, maybe
eventually I'll build the digital one.  For now, I need to convert the
CV to an 8-digit binary number and convert the numbers back again to
CV's.)


Thanks,

Dave Forsyth