Pragmatics of a polyphonic calculator (chapter 2) - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: Not HP Calculators (/forum-7.html) +--- Forum: Not quite HP Calculators - but related (/forum-8.html) +--- Thread: Pragmatics of a polyphonic calculator (chapter 2) (/thread-5831.html) |
Pragmatics of a hypothetical polyphonic calculator - Joseph_21sv - 02-06-2016 07:57 PM Ever since fully programmable monophonic sound came to handheld calculators in the form of the User RPL BEEP command with 12-digit floating point frequency control, there has been technical thought that it could be nice for a calculator to have polyphonic sound. After all, they all reasoned, it could only be logical that a polyphonic calculator should materialize. However, that failed to happen because no major manufacturer thought that that could be done profitably without crippling the calculator's numerical functionality very much. How correct that might ever have been is up for debate, but this is not the thread for that debate. Rather, it is a thread for discussing exactly what specifications a polyphonic calculator would need to have to be taken as at least a semi-amateur grade instrument. Anyway, here is my list of minimum requirements for that standard: CPU data bus/data register width: 8 bits CPU base clock rate: 894.886 kHz Hardware sound mixer (if used): Monaural Triphonic with at least one user-assignable voice Display resolution: equivalent to 160x88 Display master palette: 8 colors (preferably 3-bit RGB) Calculator type and level: Entry level Scientific/Business programmable Floating point display precision: 10 digits Programming model: partially merged keystroke Program flow control: branching, conditional transfers Storage memory on board: 64K Do you agree that this, by post-HP 28C standards, makes a passable semi-amateur grade instrument? RE: Pragmatics of a hypothetical polyphonic calculator - BarryMead - 02-06-2016 09:20 PM Perhaps if you could share your VISION of how this instrument would be useful to an average user, we would be better able to evaluate how practical it would be to embark on a mission to bring this device into open-source development reality. How would such a device make YOUR life better? Are there any GENERAL PURPOSE uses for this device that vast numbers of users could get behind. What real world PROBLEMS would this device solve, and why to you think no-one has previously gone after these markets? RE: Pragmatics of a hypothetical polyphonic calculator - Garth Wilson - 02-06-2016 09:41 PM Some projects are just for the fun of it. Why would anyone need a model railroad locomotive, especially a steam engine? But enthusiasts go to great expense to make operational ones, and they enjoy it immensely. A users'-group contribution for the HP-71 in the 1980's was the LEX file NOISE which could make the beeper do a wide range of sounds, including music. Through HPIL, you could sync two or more together and have them play various voices of a piece of music, for polyphonic sound. I don't see anything particularly wrong with your choice of specifications above; but why the arbitrary numbers? and why color? (Color is always a battery hog, because it cannot be reflective only. It requires that you continuously power a light source, unlike B&W. There goes the battery life. Written music is never in color anyway.) Note (haha) that there's no need for floating-point for this application (unless you really want it to be a calculator too). I have an article on scaled-integer and how it can be used very effectively in situations that most people think require floating-point. Note also that you can mix sounds digitally with simple addition before sending the result to a single D/A converter, so you don't need a hardware analog mixer. A hardware multiplier would be good though. I expect you'll want more memory though, or at least serial flash storage space. FWIW, I would be able do what you're talking about with my home-made 65c02 workbench computer that I use as a Swiss army knife of the workbench for controlling processes, taking data, etc.. I also put a MIDI port on it, although I've never used that part for anything serious. (I'm a musician, cellist, and had visions of composing keyboard and orchestral music that beyond my ability to play, editing it, and playing it through my MIDI keyboard. I never did it, and now my interest is gone.) The piezoelectric beeper on the board definitely does not have music-worthy sound quality, but the D/A converter and output amplifier does; and if I use MIDI, then the sound is generated by the musical keyboard itself per the instructions from the computer. RE: Pragmatics of a hypothetical polyphonic calculator - Joseph_21sv - 02-08-2016 05:37 AM (02-06-2016 09:20 PM)BarryMead Wrote: Perhaps if you could share your VISION of how this instrument would be useful to an average user, we would be better able to evaluate how practical it would be to embark on a mission to bring this device into open-source development reality. How would such a device make YOUR life better? Are there any GENERAL PURPOSE uses for this device that vast numbers of users could get behind. What real world PROBLEMS would this device solve, and why to you think no-one has previously gone after these markets? The vision of this device is that it will be the electronic parallel of a pocket harmonica, only more acceptable for real amateur musicians to use (Disclaimer: in no way to be taken to represent any opinion currently held or endorsed by poster). It would be a handheld device that I could use to make polyphonic music out of the box. Because its hardware can mix polyphonic sound, it could be recommended for music theory courses. One significant real world problem this device would solve is that people no longer seem to feel very enthusiastic about buying new touchscreen devices, at least not for the touchscreen part of them. For example, I am enthusiastic for the 128GB model of the current generation of iPod Touch because it is 128GB and I can then upgrade to a 128GB iPad rather than because it has a touchscreen. I know I have chosen a very general real world problem, but to say that this device would solve a real world problem which only applies to a particular market, even though that may well be true, would make it appear inapplicable to people who would otherwise actually want it. (02-06-2016 09:41 PM)Garth Wilson Wrote: Some projects are just for the fun of it. Why would anyone need a model railroad locomotive, especially a steam engine? But enthusiasts go to great expense to make operational ones, and they enjoy it immensely. The idea of this thread is the pragmatics of what would be the minimum needed for a polyphonic calculator project not to be seen as just for the fun of it, although it is fun, in a nerdy way, to entertain the thought of a polyphonic calculator existing. And it is convenient to be able to hold in one's hand the equivalent of a daisy chain of HP-71S with NOISE.LEX stored in ROM as well. As to the numbers in the specifications, they are not arbitrary, but rather represent just about the weakest platform that should be taken as more than just a toy. Here is where the numbers come from: 8-bit CPU data bus: The first music-worthy home computer systems were 8-bit 894.886 kHz: This was the CPU clock frequency of the NTSC version of the Intellivision Triphonic sound: This is not a literal minimum, but would be just powerful enough to get through a beginning tonal music theory course 160x88 resolution display: This was the resolution of the Bally Astrocade in Basic Programming mode 3-bit RGB master palette: This was what the Atari Television Interface Adaptor could output to a color television through a SECAM decoder (it could output 8 shades of 13 or 16 colors through a PAL or NTSC decoder) although I have no idea why it was designed in such a way that it would output different color palettes to the television through different decoders 10 digit "floating" point display precision: Most business and scientific calculators have a display at least this precise 64K user memory on board: Home computers with polyphonic sound generally came off the shelf with no less than this much RAM Color is not because it is necessary to have it simply to write music, but because home computers with polyphonic sound have always had full color display capability, which Demoscenes grew up around these home computers to take advantage of, and special mixing hardware is not out the question because hardware-mixed sound channels use minimal CPU power. By the way, "floating" point arithmetic on normal computers technically uses a fixed precision internally where the numbers are stored either as BCD or binary (e. g. HP Voyagers use 56-bit BCD numbers to do "floating" point arithmetic). Therefore, floating point merely exists as a convention for talking about how computers display the fractional numbers they operate on. RE: Pragmatics of a hypothetical polyphonic calculator - BarryMead - 02-08-2016 12:44 PM Thanks for sharing your vision of how this device would be used, and why you wanted to list the minimum requirements for making a device that would accomplish your envisioned hardware/software embodiment. After noticing the "Color" display requirement, I began to wonder if perhaps this device could be more easily implemented as an Android, or iPhone app. These gadgets already have all of the other requirements, in addition to the color screen requirements. Since Android, and Cell Phone devices already include sound card equivalent hardware, I believe polyphonic sound would be within their capabilities as well. For "Dedicated Hardware" to be practical you really should have at least several HUNDRED users ready to invest in the specialized hardware, otherwise it is just easier and less risky to create an APP for existing hardware. I don't say this to diminish the enthusiasm that you obviously have for creating such an instrument, only to help you to achieve that goal with the shortest time to market, and least development costs. Custom hardware carries with it non-trivial development costs and risks, that can and should be avoided, if the same product can be created with application software on existing hardware. This is only my humble opinion as a senior Electronics Engineer and Software Developer. I wish you the very best of good fortune and hope you continue to strive to bring your dreams into reality. Sincerely, Barry Mead RE: Pragmatics of a hypothetical polyphonic calculator - Chris Chung - 02-08-2016 01:06 PM The required hardware to realize this is minimal. The requirement is quite similar to a project I did a few years back. Except that It was not a calculator. It got a decent size b&w LCD (from a nokia phone), simple polyphonic tone generation via s/w + pwm. Just add a keyboard and it can be a calculator. It runs on the same 16bit MCU as the NP-25. The schematic for this project is as below. Code: // MSP430F20x2/3 ----------o--------------o Audio out RE: Pragmatics of a hypothetical polyphonic calculator - Joseph_21sv - 02-11-2016 03:14 AM My bad, the calculator can get away with a graphic resolution equivalent to no less than 32x24 (I must have written off the Atari 8-bit family because it used a CPU little different than the Atari 2600 did) and a 16-bit CPU address bus width (in case the latter wasn't obvious from giving the base calculator 64K of on board memory). Chris, speaking of the Nokia 5110, it looks to have been a very entry-level mobile phone and even entry-level mobile phones have supported polyphonic ringtones since the late 1990s, which is coincidentally the time polyphonic sound was predicted to come to handheld calculators (1979: monophonic sound output to audiocassette [Casio fx-501P], 1988: monophonic sound via internal speaker [HP-28C], ca. 1997: polyphonic sound via internal speaker [heaven knows which because never happened]). Since this calculator only needs to be an entry-level scientific or business calculator with a triphonic synthesizer, I suppose it can technically also get away with a monochrome display. Of course, if you agree that these amendments to the minimum requirements for the calculator specifications are sound (pun for those willing to take it), you would still want more pixels or colors even so (there is very little that is really possible with only 96 bytes per frame unless you are clever with how you implement video interface logic). Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-07-2016 05:56 PM At the bottom of the previous thread on this subject, I have proposed the following as the absolute minimum specifications needed for a polyphonic calculator to be viable as at least a quasi-amateur grade instrument, asking you if they still stand up: CPU: 6502/M68xx, Z80/i8080 @ 894.886 kHz Display: monochrome 32x24 dot matrix Numerical functions and precision: Entry-level scientific/business-financial, 10 digits Internal speaker Sound decoder: Monaural Triphonic, 10-digit frequency precision Programming model: merged keystroke with branching and conditional execution On-board RAM: 64K If they do, remember that this list of specifications is as minimal as possible and represents the least such a calculator can get away with and not all I or any one of you would want.[/code] RE: Pragmatics of a polyphonic calculator (chapter 2) - BarryMead - 03-07-2016 09:35 PM I can think of one other requirement that seems important for a polyphonic device. The KEYBOARD LOGIC should allow for multiple simultaneous keys to be pressed at once if you intend to support chords. Typical row/column decoders do not allow for this so you may have to have one CPU I/O pin for each key if you want no limitations on key press combinations. Hope this helps, Barry RE: Pragmatics of a polyphonic calculator (chapter 2) - Garth Wilson - 03-07-2016 11:08 PM Quote:Typical row/column decoders do not allow for this so you may have to have one CPU I/O pin for each key if you want no limitations on key press combinations. So you could go atypical and put a diode in series with each switch in the crosspoint matrix, so you can still scan 64 keys with 8 column output bits and 8 row input bits, and press any number of keys at once, unlike the situation with 2-key rollover. The output bits can also be used for other things between keyboard scans. The other topic covered the other material. RE: Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-08-2016 06:49 PM (03-07-2016 09:35 PM)BarryMead Wrote: I can think of one other requirement that seems important for a polyphonic device. That would be interesting to try. However, pragmatically, since the concept of this calculator is that it is to be handheld (e. g. a triphonic HP 38G) and handheld scientific and business-financial calculators, especially programmable ones, normally have fairly small keys so as to make room to dedicate keys to commonly-needed functions, it would then be too hard for people with low fine-motor skills to simply play a single line of melody on it. Moreover, since it is to be programmable, it is not even going to make sense to try to fix its synthesizer to any exact scale, although we could at least concede a pre-programmed frequency lookup table. Pragmatics of a polyphonic calculator (chapter 3) - Joseph_21sv - 03-11-2016 04:43 PM At the bottom of the previous thread on this subject, I have proposed the following as the absolute minimum specifications needed for a polyphonic calculator to be viable as at least a quasi-amateur grade instrument, asking you if they still stand up: CPU: 6502/M68xx, Z80/i8080 @ 894.886 kHz Display: monochrome 32x24 dot matrix Numerical functions and precision: Entry-level scientific/business-financial, 10 digits Internal speaker Sound generator: Analog Monaural Triphonic, no sampling/modulation hardware, 10-digit frequency precision Firmware frequency lookup table Programming model: merged keystroke with sound and graphics commands and subroutines, conditionals and for/while loops On-board RAM: 64K If they do, remember that this list of specifications is as minimal as possible and represents the least such a calculator can get away with and not all I or any one of you would want. RE: Pragmatics of a polyphonic calculator (chapter 3) - Garth Wilson - 03-11-2016 10:08 PM There's no new material here. We've already been over this. I am interested in your project, but I would recommend keeping it all in one topic, unfragmented, so newcomers can more easily see where we've been, and to avoid cluttering the forum. Original topic: http://hpmuseum.org/forum/thread-5648.html Next installment: http://hpmuseum.org/forum/thread-5831.html Edit: I see the moderators have combined the topics now. My signature line has the HP-41 links portion of my website, but for this topic I should mention that most of the website is on the 6502 and related processors, methods in both hardware and software. I'm sure you'll find material there that's interesting, relevant, and helpful. RE: Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-13-2016 02:17 AM Is it OK with most of you that my list of minimum requirements assumes the calcuator side of the device to support either algebraic or RPN entry or should I have specified that verbally? RE: Pragmatics of a polyphonic calculator (chapter 2) - Garth Wilson - 03-13-2016 06:58 AM (03-13-2016 02:17 AM)Joseph_21sv Wrote: Is it OK with most of you that my list of minimum requirements assumes the calcuator side of the device to support either algebraic or RPN entry or should I have specified that verbally? I'm sure most here, being on an HP forum, prefer RPN. I didn't start out in the RPN camp, but I've been there for the last 30 years now. If you want your little machine to do both (which you seem to be saying), go ahead. It sounds like two selectable calcs in the same package, having very little (if any) impact on the hardware cost, although there will be more software development time. RE: Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-13-2016 06:13 PM (03-13-2016 06:58 AM)Garth Wilson Wrote:(03-13-2016 02:17 AM)Joseph_21sv Wrote: Is it OK with most of you that my list of minimum requirements assumes the calcuator side of the device to support either algebraic or RPN entry or should I have specified that verbally? I mean to say either one or the other of the two, I just wanted to do a sanity check of my "grocery list" of the least that would be accepted as "not just a glorified toy". Besides, it feels clumsy to me to have them implemented as opposed system-level operating modes on the same calculator because each uses a feature the other does not need (RPN does not need brackets, DAL/AOS does not need an external stack). That is, it would have been less clumsy for HP to implement the 20b/30b, for example, as separate Algebraic (with or "without" precedence) and 'Polish' (forward/reverse) models. As for the "grocery list" itself, it is by no means to be taken as all anyone here desires because: 894.886 kHz is a fairly low clock frequency for a modern calculator 32x24 pixels is a very low resolution and monochrome is a very shallow color palette This forum is mostly concerned with scientific and business-financial calculators which are not merely entry-level Advanced programmers eventually discovered ways to make even a programmable interval timer simulate sample playback (MSX engineers have even made a plain AY-3-89xx PSG simulate CD-frequency PCM sample playback) and they even created AM synthesis effects collaterally when they did this simulation by certain techniques RE: Pragmatics of a polyphonic calculator (chapter 2) - Garth Wilson - 03-15-2016 08:52 PM This topic is similar: http://hpmuseum.org/forum/thread-5752.html Note: The page linked there, https://www.teenageengineering.com/products/po, takes a long time to load, so be patient. RE: Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-16-2016 04:04 AM (03-15-2016 08:52 PM)Garth Wilson Wrote: This topic is similar: The dot matrix display of the potential calcuator, though, will be programmable to do the a equivalent of everything the OP-1's is preprogrammed to do and more. Also, it will deliver fully preassembled with the batteries completely covered, as this other synthesizer of theirs does. Finally, it will have a synthesis engine up to the the quality of both of these. RE: Pragmatics of a polyphonic calculator (chapter 2) - Joseph_21sv - 03-18-2016 04:43 AM I normally do not spam consecutive posts to threads, but I have to propose this to get the topic back on the rails: The "least" any one of us might actually think needed in a polyphonic calculator is: SoC: RISC CPU with 4KB RAM + 128KB Flash interfaced to Adobe RGB 64x32x3 gradient LCD driver + monaural sound codec with 10-digit frequency precision and MIDI Internal speaker Firmware melody voices: 3 (virtual square wave) Firmware tracker and frequency lookup table Numerical functions: HP-10/12C Notation support: Algebraic only (with/"without" precedence) or Polish only (forward/reverse) Programming model: HP-41C with graphics and sound commands If this is acceptable, remember that it is intended to represent the least I or any one of you would let such a calculator actually get away with and not yet enough to be what any one of us would want |