Re: [LAU] Editing zynadsuxfx/yoshimi patches?

On Thu, 28 Apr 2011 08:23:42 +1000 cal <cal(a)graggrag.com> wrote: At the risk of going back to the 1980s. How about a jump table, but 64bits wide. The lower 32bits being the address offset into the table and the upper 32 bits the data - or address of data block - not that I can imagine any yoshimi parameter value being more than 32bit! Now I know this is not user friendly as it stands, but it is fast, relatively easy to implement, and once it is set up you (or anyone else) can plug in whatever translation layer is the current fashion. For those not familiar with this sort of idea, as it is a fixed width table, all you need to supply is a simple human-readable list describing each entry. This is not part of the code but a separate file/document than can have just as much waffle as you like. You don't even have to bother to put numbers on the entries. The first item on the list obviously is the zero entry into the table (which I always kept as the 'do nothing' entry). The second one is 64 bits higher up the table etc. I did something similar (in assembly language actually) for text adventure game tests and actions on the BBC Model B. It was damn fast, and whenever I thought of a new test/action, all I had to do was stick another address to the end of the jump table. They didn't have to be added in any special order, but the *table* entry could not change once entered - the final code address didn't matter at all. It would be resolved at compile time. My translation layer was mostly parsing verbs, nouns, adjectives etc. in text form into the jump offsets. Finally, the table can have some built in redundancy. In my game generator, if I abandoned a particular action as unnecessary I never took out the jump address, as that would have put many of the others out of step, I simply re-routed it to a null action or a generic one. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.