Comdex, that hardware board based disk copier to win the escalating copy-protection war. I doubt anyone born after the 1990s can understand/appreciate it.
At the end of the TRS-80 lifespan one of the hardware mods they came out with was "high resolution" graphics ability to go from 128x48 to 640x240 res (still monochrome). How far we've come.
Tandy was just bringing the Model 4 up to par with the Model II/12/16, their business line. Those machines had high resolution (same 640x240) available as an option almost since their inception.
There were also some color graphics solutions for the TRS-80 Model 1. They generally ran at 256x192. As a kid I used to lust after them when I saw ads in 80 Micro.
Is that “Speadsheet” in the top right of the first screen dump a bug or a typo by whoever made that screen?
Also: interesting choice for a 50% gray pattern, with those vertical lines instead of a checkerboard. Is that purely artistic, or does it hide hardware ugliness on some systems?
These things would've been written in assembly code back in the day. So that's your source code. In this case, it looks like they used a custom interpreted VM.
They still used Assembler - imagine looking at any code today without comments or variable names. Reading Assembly without source code is exactly like that.
It was and still is fairly common to disassemble and annoate machine code dumps (which were written in assembly) so that it becomes human readable again.
For instance in the 80's, the main selling point of the "Intern" books about various home computer models on the German market was the annotated ROM assembly listing. Each memory location and jump target got a descriptive label, and each line of assembly got a comment describing what it does in the context of the surrounding code. Due to the descriptive comments, this was actually more readable than most modern code bases written in high level languages I've seen. It's also much more readable than assembly code which was produced by a compiler from a high level languages (e.g. what you see on godbolt.org), because the code was written by a human in assembly in the first place.
Here's a 'modern' example for the ZX Spectrum ROM which just turned up as first result when googling: https://skoolkid.github.io/rom/
> These things would've been written in assembly code back in the day. So that's your source code. In this case, it looks like they used a custom interpreted VM.
According to the Byte magazine interview about VisiOn, it was mostly C with some assembly.
I remember Visi On, but never used it. The first GUI I used was Gem on an Atari ST (not too bad), and then Windows 2.0 (awful).
Then I moved jobs to a Unix training company (C, the shell and all that stuff, and later C++ expert), and one day Windows 3.0 (and later 3.1) came out and my boss came up to me:
Him: "You are now our Windows C programming trainer"
Me: "But [in Manuel voice] I know nothing"
Him: "Well, everybody else refuses point-blank to do it -learn, read some books"
Me: "Grumble"
But I did read some books, and learnt and taught a lot, enjoyed myself and today generally prefer Windows to Unix.
Windows is much more end-user-focused than Unix. This was even true in the 3.x days. I played around with a late-90s Solaris 2.x image recently and its usability was garbage compared to Windows 3.x, let alone 9x or NT 4.
Plus, the NT kernel is just a much better design than Unix. Multithreading, dynamic linking, fine-grained access control, and async I/O are baked into the NT design, not bolted on as afterthoughts.
I thought when I studied in 1994 that HP's VUE was way better than Windows 3.x which was the going Windows at the time.
W95 Chicago kinda brought it on par in terms of GUI. Obviously not in terms of OS.
It was quite saddening when I started my first job in 2000. And got.. a Win 3.11 desktop. The company I worked for had it tuned so well they never moved to 95. If I logged into another office it would basically download the whole system image to that office XD. Very weird design choice.
> Plus, the NT kernel is just a much better design than Unix.
Let's no go overboard here - both OSs have their good and bad points
> Multithreading
In both, better in Windows, IMHO, but still.
> dynamic linking
Once again, in both. Though I am not a fan of either.
> fine-grained access control
I have never understood the Windows security model (programming Windows since the mid 1980s) and I sincerely doubt that anyone else has. The Linux/Unix model has at least the benefit of simplicity.
I prefer both the Windows user experience/GUI and the programming API (thread rather than process based, drag and drop being built in, lots of stuff like that), great documentation, Visual C++ and so on.
They were probably designed exactly for a crt and they look merely acceptable but sub-optimal on anything else.
Like things that rely on ntsc artifact colors. In emulators and on vga/hdmi they are just white pixels on black in odd seeming arrangement. But via composite to a color crt they become sensible images with black, white, red, and blue areas from a source video mode that was just 1bpp.
In fact these could be exactly that. (probably not but possible, and I'll say both the for and against arguments)
Alternating single pixel vertical black & white lines, is exactly how you get solid blue or solid red from a b&w signal fed over ntsc composite to a color crt.
(or lcd depending on the composite input electronics. It's not really the crt that matters but the ntsc signal. I have seen tvs and monitors that replicated the original fuzziness and ntsc artifacts, and ones that digitized the input to produce an artificially perfect, and thus actually wrong image like an emulator that is ignorant of such display hardware details.)
But countering that theory is that I would expect software of this nature and from this time to be optimized for monochrome displays, as in, Herculese, because the crts were all mono and this gave far more detail for text and information-dense graphics. High res color was either unavailable or stupid expensive. Color was low res, ate all your ram, and was more for games and schhool computers. Feeding a mono signal via ntsc to a color tv would be an absolute garbage way to try to do office productivity work, and ntsc color artifacts don't happen in cga or other rgb formats even though the screen is a color crt.
So, all in all, I think this simply needs to be tried on some actual Herculese, ttl mono, rgb, cga, and ega screens to see what the intended look was. It was probably a compromise that didn't look as good as possible on any one type of display, but looked acceptable on all of them.
Actually thinking more, it may be simply mostly about the scanlines.
Maybe it was cheaper code to have all the background lines the same rather than 2 alternating lines to make a checkerboard, and probably vertical lines that crossed the crt scanlines was better than horizontal lines that would combine with scanlines in annoying ugly ways.
Or yet another consideration, the pattern simply needed to be distinct from the diagonals and other patterns in other areas. The different patterns are taking the place of colors. None of the patterns look especially great on their own, but they do the more important job of being easily distinct from each other, like hatch/fill patterns on architectural and landscaping drawings.
My favorite of these pre-Windows PC GUIs was Ashton-Tate's Framework. It was vaguely similar to VisiOn but tremendously powerful. It was coded by a guy who used to work for PARC, and was based on the central notion of a "frame". A frame could hold formatted text, a spreadsheet, graphics, or other things depending on its type; and each cell in a spreadsheet-type frame counted as a frame of its own. It was completely programmable in a scripting language with Lotus-formula-like syntax and Lisp-like semantics called FRED, and the content of any frame was easily addressable from within the language. You could also run a DOS shell, or do RS232 communications, with the input and output going through a frame of specialized type.
This made Framework usable in a manner similar to how many people use Emacs today: pulling information into frames, programmatically processing and consolidating them into other frames. FRED was powerful enough to build entire applications in this way. The word processor bit even featured a powerful outlining facility somewhat similar to Org mode. It was still a piece of office software, not a programming tool; but, tellingly, it was marketed to executives as a decision making tool, not a productivity tool for clerks, accountants, or secretaries.
> a kind of non machine specific "virtual machine" (called the Visi Machine) that all applications were written for. Only the very core of Visi On (called the Visi Host) was machine specific... Sounds kind of like Java or .Net doesn't it?
This messes with my chronology a bit —- where did you get the mouse to work with this? Did it come with the software? Were mice prevalent on PCs before the Mac and Windows?
Mice were available, just not generally that useful because so few applications supported them. Usually they came with a bundled paint-type program. IIRC, in the early days of Windows (i.e. 1980's probably into the early 90's) they sold bundles with mice since they were still quite rare for people to have on PCs. They were just another input peripheral you could buy like joysticks and digitizers. Getting software to work with them was another story...
I think I probably played with it at my job on my early model IBM PC/XT since evaluation was one of my jobs. But I also had a Lisa on my desk for a while, which was much better (but insanely expensive). PCs back then were just not powerful enough to do much in the way of a graphics UI. Visi On was ahead of its time but way too far. Most people were using DOS based UI which wasn't bitmapped and was mostly fine for the time. Even Windows wasn't all that great until 3.0. Today we take for granted how ridiculously more powerful everything is.
I think the webpage was created before archive.org existed as we know it today. The oldest in the wayback machines for this site page goes back to 2003
35 comments
[ 3.3 ms ] story [ 77.8 ms ] threadoo. I should dig mine up.
Comdex, that hardware board based disk copier to win the escalating copy-protection war. I doubt anyone born after the 1990s can understand/appreciate it.
At the end of the TRS-80 lifespan one of the hardware mods they came out with was "high resolution" graphics ability to go from 128x48 to 640x240 res (still monochrome). How far we've come.
Also: interesting choice for a 50% gray pattern, with those vertical lines instead of a checkerboard. Is that purely artistic, or does it hide hardware ugliness on some systems?
It may have also made a solid color on composite CGA.
Besides, it is also faster to render.
For instance in the 80's, the main selling point of the "Intern" books about various home computer models on the German market was the annotated ROM assembly listing. Each memory location and jump target got a descriptive label, and each line of assembly got a comment describing what it does in the context of the surrounding code. Due to the descriptive comments, this was actually more readable than most modern code bases written in high level languages I've seen. It's also much more readable than assembly code which was produced by a compiler from a high level languages (e.g. what you see on godbolt.org), because the code was written by a human in assembly in the first place.
Here's a 'modern' example for the ZX Spectrum ROM which just turned up as first result when googling: https://skoolkid.github.io/rom/
According to the Byte magazine interview about VisiOn, it was mostly C with some assembly.
Then I moved jobs to a Unix training company (C, the shell and all that stuff, and later C++ expert), and one day Windows 3.0 (and later 3.1) came out and my boss came up to me:
Him: "You are now our Windows C programming trainer"
Me: "But [in Manuel voice] I know nothing"
Him: "Well, everybody else refuses point-blank to do it -learn, read some books"
Me: "Grumble"
But I did read some books, and learnt and taught a lot, enjoyed myself and today generally prefer Windows to Unix.
Plus, the NT kernel is just a much better design than Unix. Multithreading, dynamic linking, fine-grained access control, and async I/O are baked into the NT design, not bolted on as afterthoughts.
W95 Chicago kinda brought it on par in terms of GUI. Obviously not in terms of OS.
It was quite saddening when I started my first job in 2000. And got.. a Win 3.11 desktop. The company I worked for had it tuned so well they never moved to 95. If I logged into another office it would basically download the whole system image to that office XD. Very weird design choice.
Let's no go overboard here - both OSs have their good and bad points
> Multithreading
In both, better in Windows, IMHO, but still.
> dynamic linking
Once again, in both. Though I am not a fan of either.
> fine-grained access control
I have never understood the Windows security model (programming Windows since the mid 1980s) and I sincerely doubt that anyone else has. The Linux/Unix model has at least the benefit of simplicity.
Me: Like both - both are flawed.
Edit: I am referring to Linux/Unix now, not then.
Mind you, I still use Linux.
Like things that rely on ntsc artifact colors. In emulators and on vga/hdmi they are just white pixels on black in odd seeming arrangement. But via composite to a color crt they become sensible images with black, white, red, and blue areas from a source video mode that was just 1bpp.
In fact these could be exactly that. (probably not but possible, and I'll say both the for and against arguments)
Alternating single pixel vertical black & white lines, is exactly how you get solid blue or solid red from a b&w signal fed over ntsc composite to a color crt.
(or lcd depending on the composite input electronics. It's not really the crt that matters but the ntsc signal. I have seen tvs and monitors that replicated the original fuzziness and ntsc artifacts, and ones that digitized the input to produce an artificially perfect, and thus actually wrong image like an emulator that is ignorant of such display hardware details.)
But countering that theory is that I would expect software of this nature and from this time to be optimized for monochrome displays, as in, Herculese, because the crts were all mono and this gave far more detail for text and information-dense graphics. High res color was either unavailable or stupid expensive. Color was low res, ate all your ram, and was more for games and schhool computers. Feeding a mono signal via ntsc to a color tv would be an absolute garbage way to try to do office productivity work, and ntsc color artifacts don't happen in cga or other rgb formats even though the screen is a color crt.
So, all in all, I think this simply needs to be tried on some actual Herculese, ttl mono, rgb, cga, and ega screens to see what the intended look was. It was probably a compromise that didn't look as good as possible on any one type of display, but looked acceptable on all of them.
Actually thinking more, it may be simply mostly about the scanlines.
Maybe it was cheaper code to have all the background lines the same rather than 2 alternating lines to make a checkerboard, and probably vertical lines that crossed the crt scanlines was better than horizontal lines that would combine with scanlines in annoying ugly ways.
Or yet another consideration, the pattern simply needed to be distinct from the diagonals and other patterns in other areas. The different patterns are taking the place of colors. None of the patterns look especially great on their own, but they do the more important job of being easily distinct from each other, like hatch/fill patterns on architectural and landscaping drawings.
This made Framework usable in a manner similar to how many people use Emacs today: pulling information into frames, programmatically processing and consolidating them into other frames. FRED was powerful enough to build entire applications in this way. The word processor bit even featured a powerful outlining facility somewhat similar to Org mode. It was still a piece of office software, not a programming tool; but, tellingly, it was marketed to executives as a decision making tool, not a productivity tool for clerks, accountants, or secretaries.
Sounds kind of like 1990s Microsoft Excel.
"A Guided Tour of Visi On" https://archive.org/details/byte-magazine-1983-06/page/n255/...
"Visi On's Interface Design" https://archive.org/details/byte-magazine-1983-07/page/n165/...
and an early example of third party tutorial
"Introducing Visi On : the system, its concepts and applications" https://archive.org/details/introducingvisio0000tros/mode/2u...
I wonder how hard it would be to port the Visi Machine to a modern platform?
https://web.archive.org/web/20030609235119/http://toastytech...
This web site is what I would call the old school internet with "warning under construction" and direct email.
This used to be how personal web-log's, now known as blogs, were formatted : http://toastytech.com/guis/news.html
"12/31/01 Move to new server with addr.com. Old sever was from Interliant, which was bought out."
http://toastytech.com/about/index.html
EDIT: If anyone wondered what many of these pages in the mid 90's really looked like, here it is : http://toastytech.com/evil/index.html