Archive of the former Yahoo!Groups mailing list: Korg Poly800/EX800 Users

previous by date index next by date
previous in topic topic list next in topic

Subject: using interrupts instead of polling...

From: Michael Hawkins <korgpolyex800@...>
Date: 2012-04-15

"I could be wrong, but it seems that implementing the use of the 8259 chips would be a way to decrease the scanning requirements of the CPU. It's just all the rewriten code to support the changes in the IRQ lines that may be troublesome."

This is a nice idea but is much, much harder than you might think due to the way the Poly was designed. All three interrupts are already used. And although I think you could possibly intercept the IRQ used for MIDI in, I would recommend designing the encoder hardware so that it could just be polled. My suggestion would be to use two seven bit  binary counters (CMOS 4024 chips) and feed the "up" and "down" encoder output signals to those two counters. Then the CPU would read the counter chips each time it looped through the main line program. The counts would be held in memory and each time the CPU would read the counters it would compare last count to the current count of the 4024's. And would increment or decrement x y z parameters according to how much the count had changed.

There are 6 IO select lines available on the HAWK board. So, three encoders could be supported. And, the eighth bit could be used for push buttons too. Supporting up to 6 news switches.

Mike





From: bimmerfan222 <bperkins211@...>
To: korgpolyex@yahoogroups.com
Sent: Sunday, April 15, 2012 12:44 PM
Subject: [korgpolyex] @ Ulrich--Re: rotary data dial +/-

 


Thank you Peter and Mike for the feedback of my inquiries to mod encoders onto a P800.

I suppose I'm driven to do the mod because I just simply like the idea that my keyboard would have them on board and would not require the use of outside peripherals/MIDI to do on the fly changes/expressions..
Another part is I just simply like the challenge and I have been learning quite a bit about how digital/computer circuits work in the process.

I'm very eager to get a Hawk mod in the near future to tweak the P800 to places it's never gone before.. all the new features sound very exciting (pun purely by accident). First I have to fix the joystick on my recently acquired P800 (it wont modulate DCO/VCF correctly), purchase a MIDI controller, then get the Hawk800..
The most exciting features I read about are the new waveforms, ability to invert the WF's, 3 additional LFOs, ability to assign the LFO's to any DCO or the VCF. There are many more, but those in themselves will make some very new and interesting patches I'm sure.

I did have an idea on perhaps building an extra board that would use 8259-Programmable Interrupt Controllers to branch out the limited CPU IRQ lines.. I've read they can be cascaded up to 64 chips for a total 512 interrupt input request lines. Of course a handful of encoders may only require 3 of these chips at most.

If I understand it correctly, this board could be hooked up to the encoders on the IRQ lines, then it would need the chips to all share paths on the data IO bus.. that bus would have to be merged in with the one inside the P800.. this is something I feel I could build/design, but tweaking the assy. code is where I fall into very dark areas of knowledge (but I'm eager to learn).
I can see issues where one of the IRQ lines on board the P800 might have to be severed and relocated to the 8259's physically.. but then of course the code would have to be rewritten so the CPU will know where to look for that IRQ line.

I could be wrong, but it seems that implementing the use of the 8259 chips would be a way to decrease the scanning requirements of the CPU. It's just all the rewriten code to support the changes in the IRQ lines that may be troublesome.

Any input/opinions on my concepts will be greatly appreciated. And please have patience with my limited understanding of digital electronics/software.. I try to research and learn as much as possible before posting. I am going to make mistakes in terminology and application many times over, Im sure.

And thank you Mike for breathing new life into an old favorite synth of mine.. this is the second time I've owned a P800.

-Blaine

--- In korgpolyex@yahoogroups.com, Michael Hawkins <korgpolyex800@...> wrote:
>
> Hi all,
>
> There are several unused IO ports available on the HAWK board and it would be possible to create a new board that exploited those available IO ports. There is also plenty of space available in the flash ROM for adding new software features.
>
> I don't know what the scan rate is for the multiplexed keyboard but I would imagine that there is enough CPU available to handle inputs of some kind coming from encoders. However, the number of encoders that could be supported might be restricted to the hardware design along with the available CPU. And it is also important to consider that the scan rate is variable because the HAWK software has a simple "threading" scheme in place that gives priority to handling note on events when they occur. This reduces the Poly-800 note onset delay but does mean that keyboard, joystick and other "stuff" is scanned at a different and slower rate when note on events happen.
>
>
> I am hoping to post all of the assembly code on the sourceforge HAWK800 project site this year. Then anyone that wants to add new mod's can also modify the code too.
>
> From my perspective though, I use the "old" Novation Remote SL25 Midi controller which works well for me. If you read the HAWK MIDI implementation chart, and the HAWK owners manual, you will see that I set up a couple of different ways to modify HAWK parameters using MIDI control messages. This gives the HAWK quite a bit of flexibility so that it can work with all sorts of different types of controllers. And, adding additional MIDI controllers is always possible if and when someone comes up with a new, unique or better way of doing it.
>
>
> And since the cost of hardware MIDI controllers is so low, I don't really see the point in trying to put encoders into the HAWK itself. But if enough HAWK owners show interest, I could be convinced to look into it further. Or, if others do some/most of the heavy lifting, then I will be on hand to provide assistance and write code for an encoder mod too.
>
>
> For now though, I have several HAWK customers that are hanging out for the 1RU rack kit and a host of others who are hanging out for an arpeggiator. So those two projects stay firmly in the priority queue for now. And, as I am sure many of you have noticed by now, I am somewhat overwhelmed by many other projects at this time, so my work on the HAWK has slowed to a crawl.
>
>
> But, don't let me stop or discourage any of you from continuing the idea because I am hoping that by posting the assembly code and all of my documentation on the sourceforge site, then Poly-800 fans will continue the tradition on. The music industry has generally spurned the Poly-800 but it has a fan base with a passion that I share.
>
>
> Mike
>
>
>
> ________________________________
> From: Ullrich Peter <peter.ullrich@...>
> To: "korgpolyex@yahoogroups.com" <korgpolyex@yahoogroups.com>
> Sent: Sunday, April 15, 2012 5:38 AM
> Subject: Re: [korgpolyex] @ Ulrich--Re: rotary data dial +/-
>
>
>  
>
> Hi Blaine!
>
> Of course it would be possible to add some more encoders, but you have to take care of them in the software.
> The more you need to scan or poll the long it takes. What you really have to avoid is that teh scanning rate gets too low
> so that there are remarkable delays in the musical keyboard section!
>
> I don't know if the editing buttons are in the same scanning thN the musical keyboard, maybe the scan rate for the buttons is lower and also the encoders could be scanned a little bit lower as they don't have to many pulses per revolution.
>
> For myself the effort in adding too many encoder for e Poly800 would be too much, for this this synthesizer is too poor in its features and sound possibilities - having said this I must add that I don't have the Hawk mod - maybe this mod offers some features that could lead to a better sound.
> But for me that one for all VCF part is too limiting.
>
> Ciao
> Peter
> ________________________________________
> Von: korgpolyex@yahoogroups.com [korgpolyex@yahoogroups.com] im Auftrag von bimmerfan222 [bperkins211@...]
> Gesendet: Sonntag, 15. April 2012 04:22
> An: korgpolyex@yahoogroups.com
> Betreff: [korgpolyex] @ Ulrich--Re: rotary data dial +/-
>
> Hey Peter,
>
> I think this is what Mike (the creator of the Hawk800) was intending to do with the idea of adding some encoder dials to the Poly800.
>
> Couldnt there be a way to use a multiplexer/de-multiplexer to allow more than 4 knobs?
> Isnt that what Korg did to cram an entire set of playing keys(switches) on the keyboard AND all the panel switches to be scanned by the 8 pins on the 80C85A CPU?
> Refer to section 21 in the P800 schematics.. I think there you will find that both the keyboard and the panel switches all merge into a demultiplexer.. then are converted to a bit code that is dumped onto the bus... AD0-AD7 (pins 12-19 on the CPU).
>
> I read that there is a 3-to-8 demultiplexer on board (TC-40H138).. doesnt that mean three 8bit streams are from mostly the keyboard and the panel switch matrix's and used to share the CPU's data bus?
> Couldnt the circuit be modded to integrate more 8bit streams?
> I could be wrong.. lol. I understand very little about digital electronics, obviously.
>
> Another idea I had was to somehow have 4-6 knobs and with a momentary switch of sorts, make the knobs change from one series of controllers to another.
> Say in one scene, the dials will control VCF parameters, then punch a button and the dials turn into Envelope Generator dials (preferably six for the "break point" and "slope" parameters of the EG). Punch it again and it becomes Depth control of each of the four LFO's... not necessarily in that order, but you get the idea.
>
> Keep in mind that the encoders can have a momentary switch on each of them.. push the knob/dial down and it activates a change..
> There could be a simple series of LED's nearby to indicate what "scene" the knobs are in.. or use the encoders with LED's built into the encoder.. so when you switch scenes, the color of the knob changes! :)
> You could even make the LED knobs be steady on, blink slowly, blink quickly.. and of course change colors.. heck, lets make them blink red, green, red, green... lol.
>
> I wish I could offer more assistance in this mod, but I admit I know little to none of digital circuits and assy. code. That's where Mike would come in with all his custom code already in place.
> Chances are that many of the subroutines that these new dials would need may already be there in use by the extra MIDI access coding he's done.. he'd simply just need to point to those subroutines already in ROM.
>
> I really dont have any idea how much memory Mike has left to add in more features. I would think that 64K wouldnt all have been used up yet. Back in 1983, that was ALOT of memory for a home PC. I thought it was amazing when the Commodore 64 came out with it's 64K and all the fun things it did back then.
>
> Cheers
> -Blaine
>
> --- In korgpolyex@yahoogroups.com, Ullrich Peter <peter.ullrich@> wrote:
> >
> > Hi Blaine!
> >
> > If you are in the situation that you can change the source code then you have more features of course.
> > I bet that it would be possible to add some encoders for interesting parameters if there is enough space in the eprom.
> > In this case you can maybe complete bypass the keyboard matrix and could add maybe an 8 bit port for 4
> > encoders on a free I/O address and the software does the encoding and parameter changes.
> >
> > In theory it would be possible but its work that has to be done, and of course some tesing.
> >
> > Ciao
> > Peter
> >
>
> ------------------------------------
>
> Feel free to upload into the files section any sysex dumps and tape dumps of patches that you may have but please discuss (with the entire group) the posting of other files ∗before∗ posting them. This helps us to keep redundant information from showing up everywhere and also allows us to constantly improve the format and structure of the documentation. We talk about the HAWK-800 quite a bit but we also discuss and help owners of the original Poly-800 models. So don't be shy if you haven't got the HAWK-800.Yahoo! Groups Links
>
> The information contained in this e-mail message is privileged and
> confidential and is for the exclusive use of the addressee. The person
> who receives this message and who is not the addressee, one of his
> employees or an agent entitled to hand it over to the addressee, is
> informed that he may not use, disclose or reproduce the contents
> thereof, and is kindly asked to notify the sender and delete the e-mail
> immediately.
>