[cc65] - object oriented style

Hi there, sorry this is so long! I've already done a bunch of working  
coding, but I've got a high level, sky view type question, and I'd  
love to hear what you all think! Again, only if you find music making  
programs on 6502 machines interesting!

I've been rewriting PetSynth from scratch so that it's modular. I've  
completed the functions for the following modules (if anyone is  
interested)

- non-machine specific note handling routines
- machine specific PET keyboard to system note format (based on MIDI  
note values) (this also lets me support a lower level of keyboard  
scanning the PET, so I can have sound play as long as a key is held  
down)
- non-machine specific LFO routines (low frequency oscillators -  
based on system timers)
- machine specific PET timer routines (using the 3 bytes of jiffy  
data in memory)
- machine specific note value to PET oscillator routines (values for  
the VIA chip)
- non-machine specific functions for setting and oscillator to a  
specific note, or no sound (off or 0)
- non-machine specific functions for effects, which call the above  
functions,
- part of the above is setup such that it's easy for a programmer to  
edit the big list of keyboard to note values in one function, which  
describe where middle C note is on a qwerty keyboard, and another big  
list that turns note values (midi based) into oscillator values, so  
it's easy for me to manually tune by hear each note just by editing  
one list of values
---------> VIBRATO: in this case, I've got an LFO setup as a single  
oscillating bit, which trigger at the nearest 10 jiffies since the  
last read of the system jiffies, which then causes the program to  
read the currently held down note, and re-write the current  
oscillator up on the 1's of the LFO and reset the current note to the  
current_note value in global variables, which has the value of the  
note that's currently being pressed down.

So, now that these is out of the way, what I've got a collection of  
functions that manage keyboard data, note data, LFO timers, and  
specific effects, in such a way that I'll be able to re-write only a  
handful of function when I port it to other CBM system. In most  
cases, I'll be re-writting very little, just the memory locations of  
low level keyboard stuff, and times, and addresses for

My last version, as it ran on the pet, would allow me to play the  
keyboard, and the notes only made sound as long as I held them down.  
I have have a vibrato effect, which is enabled when I hold SHIFT  
while playing.

So it all works right now, but I realize there's certain benefits to  
doing this in a more object oriented way.

Now that you know why I'm wondering this, my questions is:
---> Is there some way of doing some of ideas in object oriented  
programming in plain C using cc65 specifically, such that I'm not  
creating code that might be okay for the Linux kernel, but not really  
good for the specifics of cc65.

For example, what I want to do is just create a simple struct object,  
that holds pointers to functions, so that all my functions are nicely  
organized. So that's really just a collection of tools.

But what I want to know is, if I wanted an class, such as an LFO  
class, so that I could create LFO objects. I could create an LFO  
object that's tied to the fastest jiffy byte and then have it work  
with sine table creating a sine wave oscilator. Or I could create  
another object, but this one is slower, and has a square wave output  
instead.

In this case, object oriented means more than just putting together a  
nice little function collection.

Does this makes sense? Probably not!

Anyway, there are lots of ways of applying object oriented ideas to  
C, and I can read those. My question to the group, and only if  
someone finds it interesting enough to answer, is what's the object  
oriented ideas that would have the best qualities to this  
applications, that don't put too much of a demand on cc65 and the 8- 
bit machines they target, and what are the ideas to avoid since they  
would just make things more complicated, bloated, slow, and take up  
too much RAM.

A great example was what I just read here from Shawn about Ullrich's  
optimizations:
"although I was thinking recently that with the optimizations that  
Ullrich has done for string storage, that it makes more sense to put  
everything into one big file, as the string optimization doesn’t work  
across object files."

It's little things like that , that would help me figure out a game  
plan before my program gets out of hand! I mean, I'll try, but I'll  
probably just paint a great big random messy modern art deco of a  
source code regardless!

I'm fine with abandoning the idea of being object oriented on this  
project, and hard coding a few good LFO's with good old fashioned  
copy-paste-modify style programming too :)

Thanks for any insights, hints, links, tips or tricks!!
-Chiron

----------

www.PetSynth.org



----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.