Slashdot Mirror

Nope, not that generous any more. Plus, I no longer have a paper tape reader. :) I'll probably sell it someday, so it doesn't get lost in some relative's WTF box at the time of my death.

However, I did write a complete emulation of the 6809 and the Flex OS, which you can get from here, if you're so inclined. It's a few years later than the paper tape, but on the other hand, it's hugely more capable, just as one might expect. Plus, the 6809 is a dream to program, unlike any other microprocessor of its vintage, or prior.

Yeah, Adobe. Just finished dealing with them this morning. And by "finished", I mean finished.

I just set up a Mac with MacOS Sierra 10.12, and attempted to install my copy of Photoshop CS5. Sierra advised me to throw the installer in the trash. Seriously. That's the dialog I got. Adobe "support" told me "not compatible with 10.12", and also "there is no fix or upgrade" other than enter into a permanent wallet-sucking fest for their "subscription" based product. No. Not a chance.

So, that's the end of a multi-hundred dollar investment. Thanks, Adobe. Also, thanks, Apple. Whoever is responsible for the idiocy. Both, perhaps.

Well. So I'm screwed, right?

Not necessarily.

I know a "little bit" about image manipulation from making Windows image manipulation software. I'm retired, and previously really lacked the motivation to build an image manipulation app of my own for the Mac. Previously.

Insofar as my own needs go, I can definitely handle this, and in fairly short order, too. Others might end up benefitting as well. We will see.

Surely just an empty claim, amiright?

Well, take a Look: My bonafides begin right here.

Let's just see how many of those features I can move over from my (mostly very portable) existing image manipulation code. And how quick. Today serves as the starting line. Assuming age doesn't kick me nipples north in the short term, and no other unforeseen disaster shows its ugly face, I expect to be raising my figurative middle finger in Adobe's direction quite soon as these things go.

But can you program in Z80 and 6502 machine code?

Yes. But more importantly, I can program in 6809 machine code. Including building all the index modes. Which, back in the day, is one of the things that saved me from having to design in, and then program, CPUs like the 6502 and z80, both of which are seriously anemic by comparison. But I prefer to program in assembler. Because I'm sane.

My affection for the 6809 ran so deep that I wrote the 6809 emulator you'll find here, which required me to implement the entire instruction set from the ground up.

But yeah, I can write machine code for about 10 microprocessors. And you know what? In the day... that was useful. I could read (E)(P)ROM dumps, I could cold-patch... but today, I just wish I could get the brain cells back. :)

Not famliar with "rMorf"; Google can't seem to find anything prior to the 2000's about it, and the archives Google references that I looked at no longer have the files, other than one ZIP that appears to be defective. What's the history of rMorf?

As far as I know as of right now, first to market for desktop PCs is correct. The original code, which was a freeform point morphing engine, not a grid morpher, was written in early 1986 in 68000 assembler for the Amiga 1000, demonstrated in working form (though with a pretty basic UI) in a dedicated vertical package at the 1986 spring Comdex in Atlanta, in Commodore's Amiga booth (my company was one of Commodore's four featured developers, showing some PCB layout and schematic capture CAD in a showcase section of their Amiga booth... they generously put one of my CAD products in the Amiga software brochure, too, really gave me a terrific "kickstart") to some Commodore execs. In late 1991, in my next company, we began shipping a similar morphing engine for the Amiga within a more extensive image processing system aimed at, and priced for, consumers, written in c. I laid out the basis for the engine on a napkin at lunch in a Dairy Queen during the summer of 1991 and seeing my then-lead programmer's eyes light up), and we shipped a similar product for Windows shortly after that. After I retired, I made the EOL versions of both the Amiga and Windows image processing software (and some other things) freely available on the web. (Amiga / Windows)

Does rMorf predate my 1986 work, and if so, can you provide a reference for me? I'd be very interested to learn that was not first shipping package for an actual desktop PC. It's certainly possible, it's just news to me, and I'd need to rewrite some of my memoirs -- so I'd really like to know. :)

Not famliar with "rMorf"; Google can't seem to find anything prior to the 2000's about it, and the archives Google references that I looked at no longer have the files, other than one ZIP that appears to be defective. What's the history of rMorf?

As far as I know as of right now, first to market for desktop PCs is correct. The original code, which was a freeform point morphing engine, not a grid morpher, was written in early 1986 in 68000 assembler for the Amiga 1000, demonstrated in working form (though with a pretty basic UI) in a dedicated vertical package at the 1986 spring Comdex in Atlanta, in Commodore's Amiga booth (my company was one of Commodore's four featured developers, showing some PCB layout and schematic capture CAD in a showcase section of their Amiga booth... they generously put one of my CAD products in the Amiga software brochure, too, really gave me a terrific "kickstart") to some Commodore execs. In late 1991, in my next company, we began shipping a similar morphing engine for the Amiga within a more extensive image processing system aimed at, and priced for, consumers, written in c. I laid out the basis for the engine on a napkin at lunch in a Dairy Queen during the summer of 1991 and seeing my then-lead programmer's eyes light up), and we shipped a similar product for Windows shortly after that. After I retired, I made the EOL versions of both the Amiga and Windows image processing software (and some other things) freely available on the web. (Amiga / Windows)

Does rMorf predate my 1986 work, and if so, can you provide a reference for me? I'd be very interested to learn that was not first shipping package for an actual desktop PC. It's certainly possible, it's just news to me, and I'd need to rewrite some of my memoirs -- so I'd really like to know. :)

And that includes when it is complex; there are other ways to do it.

No. You can't do this by hand at all because in the work flow you are suggesting, you are either required to do as a correct operation the first time for each of the successive regional selections, or build them into distinct layers or scripted actions, and you can't conveniently, in fact trivially, modify anything/everything about those selections intuitively and interactively once they begin to interact with one another in any significant way. The effect of non-destructive change, when extended to multiple area selections computing blending set-logic/feathering/position/size as a live-and-change-anytime trivial user interface matter, is not something you can practically manage without this precise set of features, or better.

I'll put it another way: What minor subset of what Viveza can do which can be done with the types of workflow you describe in, say, an hour, Viveza can pull off in seconds, and having done so, one is in no way committed to any aspect of that unless you want to be, no matter what else you do to the image within the context of Viveza.

And in gimp if I need to base something on a calculation, there is a Perl interface and I can easily calculate and apply something by hand from a command line.

Come on. Seriously now. Are you honestly thinking that is in ANY way comparable to real-time, non-destructive manipulation, trivial mousing of many complex regions with varying effects on and combination of brightness, contrast, saturation, hue, and a whole host of other variables? Because if you are, I can't possibly take you seriously. I've been writing Perl and Python since... well heck, about since they hit first release. I LOVE scripting. I make sure there is a scripting interface in every serious application I write. I am the primary author of what remains one of the most capable and complex image manipulation systems to hit the market to date (WinImages F/x+Morph), well beyond both Gimp and Photoshop in a very large number of capabilities from layering modes to live animation of everything from area selections to every setting of every one of a myriad of effects and processing options. Broad scripting support. I've designed and implemented a far more capable (and easier to use, and easier to write, and better integrated) plugin system than Photoshop/Lightroom has to offer. And WinImages is as different from Photoshop and Gimp as Photoshop and Gimp are different from each other, and not just because it's an older application, either. In addition, I'm building a similar vertical application targeted at DSLR image processing that I already can use more effectively than either Lightroom and Aperture, both of which I own, as well as having both the Gimp and Photoshop on the system, plus others. And I'm telling you, in that context, that there is NO way you can do, via scripting, what Viveza does, with those tools. Not without actually recreating the complete set of Viveza's high level features as a holistic system and then trivially launching that from the script itself.

In my software, WinImages F/x (and my DSLR app, presently unreleased), there are layer modes that apply similar processes as to what Viveza does; Photoshop's "adjustment layers" can also do a (very) little bit of this. Once those layers are set up, you can (comparatively clumsily) shift those layer modifications around, and they wil re-blend, and they can be changed as to effect, feathering, etc., though it takes quite a few small steps to do when there's more than one of them.

In terms of smooth and easy accomplishment of what you actually want to do, Viveza destroys that model of image manipulation with its specific paradigm. Just destroys it.

If they're happy with it, why should they change?

Happiness and c

Not a problem here. I've tried CrossOver on and off for a few years now; it's still shite.

Way back when, I was considering releasing my software under Wine on Linux, under the terms of "if you run this product under Wine, you owe us nothing." (I didn't copy protect, I used registration enabling, and would have been delighted to enable everyone under Linux.) So, I got and installed Wine, and tested it. It broke. Really badly. Several system calls that weren't covered, or broken, or whatever -- they flat out didn't work. So I contacted the authors. They said, and I am paraphrasing here but this is very close: "give us money and we'll fix our product."

So, that's why my product never ran under Linux/Wine.

Although, it may be that Wine works now. I'm not saying it does, or doesn't. I don't know. I don't even own/have a Windows OS any more. But if it does, I long ago made enough money from my product and now give it away, and you are certainly welcome try to get it going under Wine, etc. It's here: WinImages and it was last aimed at Windows XP. Docs are here. WinImages is neither Gimp nor Photoshop, but something else. In a very, very large number of cases, it can replace either/both of them, functionally speaking. In other cases, it does things they cannot. And it is extremely fast, offers a small executable, and the last version, which is what is up there, has very few problems that aren't actually caused by bugs in Windows. Feel free to have at it if you like. Under any OS, real or virtual, you can get it running under. Or not. :)

PS: Known to work under [OS X + VMWare Fusion + XP] and, of course, under XP itself.

Not a problem here. I've tried CrossOver on and off for a few years now; it's still shite.

Way back when, I was considering releasing my software under Wine on Linux, under the terms of "if you run this product under Wine, you owe us nothing." (I didn't copy protect, I used registration enabling, and would have been delighted to enable everyone under Linux.) So, I got and installed Wine, and tested it. It broke. Really badly. Several system calls that weren't covered, or broken, or whatever -- they flat out didn't work. So I contacted the authors. They said, and I am paraphrasing here but this is very close: "give us money and we'll fix our product."

So, that's why my product never ran under Linux/Wine.

Although, it may be that Wine works now. I'm not saying it does, or doesn't. I don't know. I don't even own/have a Windows OS any more. But if it does, I long ago made enough money from my product and now give it away, and you are certainly welcome try to get it going under Wine, etc. It's here: WinImages and it was last aimed at Windows XP. Docs are here. WinImages is neither Gimp nor Photoshop, but something else. In a very, very large number of cases, it can replace either/both of them, functionally speaking. In other cases, it does things they cannot. And it is extremely fast, offers a small executable, and the last version, which is what is up there, has very few problems that aren't actually caused by bugs in Windows. Feel free to have at it if you like. Under any OS, real or virtual, you can get it running under. Or not. :)

PS: Known to work under [OS X + VMWare Fusion + XP] and, of course, under XP itself.

My native FLEX / 6809 machine emulator (for Windows XP and at least several Windows versions on up... don't use Windows any more, so I dunno. :)

Late-70s / early-80's machine era.

Front panel, graphics card, single stepping, lots of software including assemblers and compilers. Stable.

If you ever used 6809 Flex, you'll be right at home. Otherwise, probably don't bother.

So what experience do you have that leads you to be so adamant that typing speed is a major factor in coding?

Not is. Can be.

Among other things, I write major applications and libraries, generally in c or c++ these days. I've been at it for about 45 years, coming from an assembler background. I extensively document what I write, both for the user and within the code (you'd have to download the import library to see the docs... the link is just to the cover page.) I also wrote the user documentation system (in Python/SQL) itself. I often produce as fast as I can type (35-40wpm) when coding, and almost all the time when documenting. There is no question in my mind that my productivity would be reduced if my typing speed or accuracy were to be seriously impacted in any way.

In my early career, I worked alongside a lot of very good people, and I can't recall any that were really noticeably similar to one another. IMHO, really good programmers tend to not fit stereotypes very well as they are not only (necessarily) brilliant, but are bringing some kind of broader experience to the table. Later on, I ran a couple of hardware and software companies for about 25 years, producing first for 6809 custom hardware of my design (coin-op arcade industry), then the Amiga and later on software-only for Windows.

During that time, aside from my own work, I hired, directed and supervised many programmers and a small group of hardware engineers as well. I'm well acquainted with various combinations of lines-per-whatever, reliability, and complexity across a pretty good sample of coworkers and employes -- my own observation consequent to this is that there is a very wide range of acceptable performance, and for various reasons, at that. These days I'm retired and spend my time doing AI research, real-time signal processing and image processing applications, working on building an interior into my home with my SO's considerable assistance, and generally whatever else takes my interest. I still write as fast as I can go when I'm writing, chewing up about a keyboard a year. Matias keyboards.

That's my experience. In no way am I suggesting it is, or should be, yours. Just avoid painting me (and by extension, everyone) with your own particular brush and I'll shut up. About this, at least. :)

> You can create a Hue/Saturation 'adjustment layer' that will turn all the green pixels beneath it blue.

This has those features, and many more, including some Photoshop does not have such as warp layers (put a warp on a layer, and it'll warp the layers (or just the previous layer, selectively) below, but remain movable and adjustable, etc), in fact there are over 70 layer modes and it's now free (and unsupported):

http://www.datapipe-blackbeltsystems.com/windows.html

Free (and now unsupported, but...) Windows image manipulation software:

http://www.datapipe-blackbeltsystems.com/windows.html

70+ layer modes, morphing, warping, all manner of filters, animation, ray tracer, particle system, heightfield/texture generator, high end jpeg and gif rendering, plasma effects, warp layers(!), fractals, user toolboxes, splined animation (both area selections and effect settings) for all filters, preview filmstrip, color separations, scripting, multi-undo/redo, etc

Might be worth a look, depending on what you're doing.

I really, *really* liked my late 1970's-era 6809 system. 64k of RAM, custom graphics and sound cards of my design, timers, serial port, multiple floppies. I thought it was getting old in the tooth (it wasn't, it still works, should have had more faith I suppose), so I wrote an emulator for it -- the entire system, hardware, software, a front panel (which the original didn't even have) everything. Still works great, but due to the increase in CPU power over the years, the emulator is one heck of a lot faster than the original hardware. You can use it too, if you're so inclined and you're running some version of Windows, XP or later (might still work under Windows 95 and/or 98 for that matter.) Includes various compilers (Dugger's c compiler, for instance), forth, assembler, cross-assemblers, linkers, basics, some arcade video games that used the graphics hardware, and probably the vast majority of the commands that were available for the DOS, which was FLEX09. Percom PSYMON monitor. If you ever wanted to play in a nice, safe assembler sandbox, it doesn't get any better than the 6809. It just gets faster and wider.

For linux, the answer is Midnight Commander. Between the very nice editor and the dual-pane do-lots-of-things text mode interface, it's still my go-to under linux, I even use it on the Mac. Thankfully, they've kept it reasonably up to date, although making a native mac version without inflicting a much broader *nix ports package on the system is a real pain in the butt.

For the Mac, I use both of the above, MC natively and my emulator under a VM running a network-isolated XP, and I still run a PPC version of my HP-48G, which, I'm afraid, has made any other calculator use not only pointless, but nearly impossible. I also have two of these calculators in hardware, both of which still work fine. Because Apple dropped PPC support at OSX 10.7, my daily driver machine still runs OSX 10.6 and is likely to continue to do so unless I can find a native version of the HP emulator for Mavericks. When I decided to move past OSX 10.6 (Mavericks is actually quite nice, finally), I bought a new machine and plopped it down in my ham shack.

Ham radio: Easy. My Palomar loop antenna. This tiny (about a cubic foot) antenna system has pluggable loops for 150-500 khz, 500-1700 khz, 1700-4000 khz, and 4000-15000 khz. I like to drag it out into the unimproved areas a few tens of miles from here where there are zero power lines, telephone cables carrying data, neon and other signage, plasma TVs, buildings and so on, and enjoy amazingly good, noise-free SW and amateur radio reception on the radio in my truck without having to set up a physically large and cumbersome antenna. I also have a Panasonic RF-2200 portable analog radio that I take on trips. Both of these are pretty old, tech-wise, but both remain in regular use and have stood the test of time very well indeed.

Music: A Marantz 2325 stereo receiver and a pair of Marantz HD-880 speakers. Not only does this setup sound nothing less than awesome, it eliminates the tedious menu surfing that more modern gear forces upon us. Everything's on a front panel knob. Everything. I have (very) modern gear in the home theater, but in my office, the old Marantz blue face remains king.

Lastly, I still have, and continue to play, a 1950's Fender Stratocaster guitar. I have a fair collection of more modern guitars, but the strat's neck is still the best of all of them. Luckily, for most of my life I've been a casual enough musician, and have spent enough time on other guitars, that I've not had to have the thing re-fretted. I don't look forward to that. I can't imagine it'll be the same. Of all the old stuff I have, this is the thing that has not only kept its value, but appreciated far beyond any dollar figure I could ever have anticipated. Not selling it, though. Ever. :)

I wrote, and my company shipped, a free icon/text configurable speech generation system for the Amiga that does essentially what the iPad app in question here does at least two years before the date of the patent in question (the complaint dates the patents 1995 and 1997 -- Talkboard hails from 1993 and before, though I can only document it to 1993 -- that's the copyright date in the archive.) The application is called "Talkboard" and is still available from our company's historical archive.

Talkboard presented a layered interface pretty much just like the one in the iPad app, It used a synthesized voice and provided for unusual phonetic construction so as to obtain the best clarity (the Amiga's text-to-speech could be.... quirky.) You could load and save phrase banks, and one phrase bank could partially replace another or completely replace another. Single words or short phrases or entire complex sentences could be stored for 1-click or multiple click retrieval. The phrase could be represented by any shorthand that was convenient. It came with presets, but was really intended to be customized by the end user - what a kid has to say and an adult has to say tend to not be the same things in most cases. It could also be driven from ARexx, a system-wide scripting facility, and could dynamically change definitions based upon whatever criteria you needed it to.

As far as I can tell, there's nothing unique, new or even interesting in the two patent claims.

Hopefully that's of use to the EFF or the defending party.

You would if you virtualized those analog parts.

Yes, you would, but you'd also take a hit to simulation throughput, I'm guessing a pretty significant one, too. I'm not sure you'd gain anything specifically more useful than you would in a pure digital approach without this kind of low level detail, either. More interesting to add something a bit more "macro" in the sense that it's a high level behavior / feature you can see and evaluate by simple observation.

My qualifications to guess? I'm the author of "Digital Soup", a system that uses genetic algorithms to drive robotic actors ("crits") in a world where simulated food gives them energy, they can trip over simulated rocks which takes energy from them, they can bump into each other -- similar to tripping on a rock -- they lose energy in the search for food, they can mate, breed, and so forth.

You have control over breeding selection criteria, in that they (the crits) can pick from other crits that are high performing, or one of them can be, or neither, or it can be random. You can also fiddle with how the genomes of the breeders mix. You can hand-write the genomes, or preload from saved before you start, or you can generate them randomly.

Once they're let go, performance is evaluated on a per-crit basis using a histogram for the currently living crits that evaluates their energy state. You have control over the size of the living space, the number of crits... and more. You can actually watch them run around, chase food and each other, avoid rocks, etc. Generation times can be exceedingly fast. Built-in hypertext docs/help. It is really a pretty cool program.

Also... if you write a genome yourself, one you think will do well, the result is very rarely what you expect. It's fascinating to mess with.

You can get the software for free here, but there is a pretty big catch for most people: It's Amiga software. I wrote all this over a decade ago. It probably would run fine on any decent Amiga emulation, though, as there's nothing "funny" about the code or the resources used.