SSlmixed.com Forum
XK-System (community project) => General Discussion => Topic started by: Artur D'Assumpção on November 03, 2013, 10:49:47 PM
-
Hi guys,
This is going to be a long post, so grab a coup of tea, sit back and relax. ;)
Lately we've been discussing the SSL computer problem revealing the problems the we SSL owners are/will be facing in the near future with computer replacements becoming scarce and so expensive. Obviously our consoles are not getting younger needing regular overall maintenance that we've become so acquainted with. So far this maintenance as been possible due to the existence of service manuals, a good design that assured it could be maintainable in the future, and our more knowledgeable members that are willing to put themselves out there, sharing information and actively helping other members to troubleshoot and fix problems. Despite this fact, good will can go so far and come at the cost of personal time expended studying the service manuals, troubleshooting and sometimes reverse engineering the design and behavior intended by SSL. The apex of this effort comes in the form of the SSL computer which is very hard or close to impossible to maintain, needing a more urgent attention and also the biggest effort. The are a bunch of motivations to find a modern alternative replacement, among them, the ability to continue to enjoy a console with computer support, lower power consumption, maintainability, small form factor, modern software and updated workflow, and so on...
We all have knowledge of projects such as the Dramastic Audio and Pelle G's which have been taking enormous effort to reverse engineer and design a modern system to completely replace the SSL computer. This has been done at such a high cost that in 2-3 years that we know about these projects none of them as seen the light of day in the form of a commercial viable option. Also we could testify that this task almost took Pelle G to bankruptcy (his own words), having spent so much time and money investing in this endeavor. Of Dramastic Audio we can only guess what's really going on...
After careful thought about this problem it's my personal conviction that any SSL computer project will have to come from the community itself. No proprietary alternative will offer the future assurance, level of continuity and innovation that we are looking for, leaving us in the hands of a small company that might change its mind anytime and drop their solution support or even go bankrupt. Also a solution that comes from a 1-man job can go hairy since this person may stop being able to support his creation and his clients due to personal problems. This is a fact and a risk specially if one has to pay many thousands for such a system only to see it obsolete just around the corner.
I believe that we have a rich community with capable electronic and software engineers that together and motivated could take this task in and design a long term replacement for the SSL Computer assuring a viable solution for this problem. Such solution would be maintained by the community guaranteeing the continuous development of its electronics design and software, constantly evolving to meet users needs. This could be approached like any other OpenSource project out there, embracing an open approach and development best practices, adopting models such as eXtreme Programming or Agille for instance. The open approach would also guarantee that the solution would always belong to the SSLMixed community and its users, allowing anyone to actively participate with ideas, designs, code contributions and patches.
This being said, there's only one major deal-breaker that I think it's in the way of such a project, which is the huge blackbox that the SSL Computer is. Reverse engineering is possible, as we've testified before, but this comes at a great cost and, although I think that this would be easier with more heads involved, it's not a simple task at all. The optimal solution would be to have access to the development documentation that SSL should have on its archives and explains top to bottom how the system works. This documentation would enable us to develop alternatives at a much less cost, not requiring a reverse-engineering phase.
This looooooong post leads me to my main topic which is writing a letter to SSL. This letter would be written by the community asking SSL to donate all the necessary documentation (to be determined) to enable us to fully grasp the console plus computer design and behavior, allowing the community to fully maintain and design the necessary alternatives to keep the SSL legacy alive in the future, as also maintain a clean and solid image that would respect and promote the brand. I believe SSL wouldn't have nothing to lose with this move since any of the related documentation would not endanger any of the company's secrets (any of this technology is currently supported or present on current products). On the other side, donating this documentation (even if under an N.D.A. to the community) would assure SSL that there's a community committed and willing to provide support and keep a great technology alive. This would only benefit SSL and we would have nothing to loose by doing it.
If we decide to write such letter, although this would always be written by the community and "signed" by all users, I think it should be handed over to SSL by a known-friendly face to them. Someone that could have a meeting and explain our motives and give it the necessary credibility. Obvious names for this task, if they are ok with this, could be Jim and Mattia, for their past and current relationship with SSL. Regarding the letter itself I don't mind to draft a sketch and post it for discussion.
I hope this makes any sense to you guys. Please discuss and share your thoughts.
Cheers,
Artur
-
I believe, and you can probably Pelle on this, that the most difficult part is the hardware on this. I am sure that is where the bulk of his money was spend on this project.
-
the entire source code was coded in assembly
i don't really see myself as a coder - i'm more of a hardware man but i was forced to use about 40-50 lines of assembly to make Konnektor work
to be honest, that task alone was making me seriously, seriously angry and i hated it big time!
but it was the only way to make it work as it was the fastest and smallest way to achieve what was needed
so that's my personal limits
anyone out there to be able to decode the source code?
i don't know if you know that ssl did not design the computer at all but licensed it from CA - a company called computer automation
http://en.wikipedia.org/wiki/Computer_Automation
i'm still running one of these on my B-series - it's called the 'naked mini'
it's from 1977 and runs the 'latest' E-series software - actually still responds faster than a G series, btw?!
i wrote half of the konnektor code on that cpu - only to discover that i needed to slow down everything for the g-series
what ssl added was:
the tape interface card:
to decode the 80 bit smpte t/c, which was realized by 10x 74C164 8bit serial in - parallel out shift registers + 11x 74ls368n
it actually allows you to measure every single bit of the t/code - bits 0-63 contain t/c + user bits and bits 64-79 contain sync words
something that could be done with one chip nowadays?
then they added the tape machine interface which are basically solid state (excuse the pun) relays to control various machines and scan their switches:
PLAY / STOP / FFWD / FREW / REC
the leds + switches interface which feeds the parallel bus into the computer (trim/abs leds)
and finally, the analogue i/o cards with their multiplexed signals of the converters - i.e. one a/d + d/a converter which feed the parallel bus of the ssl computer
and then there's a z80 card for the total recall - which is serial information running through the fader lines of each channel
so yes, technically i would probably be able to provide the hardware required for a more modern computer - but is it really worth it?
you'd need to code everything from scratch on a new platform - that rules me out
maybe someone is able to convert the original assembly code to a newer system?
like i said..it's 74 ttl chips :) cheers, werner
-
Very exciting! I found a few references on the web searching - CA "naked mini" computer - there are people out who know all about these machines, CA apparently was the 4th biggest computer manufacturer in the world.
Werner, are you saying you are using a "generic naked mini", not the SSL Rack we all know?
Check out the attached brochure I found on the web!
-
This must be the CA "naked mini" in the rack below the vertical 8" floppies. Love the printer to the right. This is the 1979 intro of E series.
-
I wonder how SSL dealt with CA going bust around 1992? As far as I know some of the last 4K consoles were sold around 2001.
I think it could be a great open source community project to develop parts and software for a new mix computer. BTW, there are plenty of people out there who worked for CA back in the days. It only takes a bit of luck, and one of them joins the open source community.
-
yep :)
Werner, are you saying you are using a "generic naked mini", not the SSL Rack we all know?
(http://www.thekonnektor.com/ssl/B-computer01.jpg)
-
Like!
-
We should have saved all the thousands of CA computers that were probably thrown away in the late 80s/early 90s!
I could do with an E-Series CPU-Card and memory, especially if it's faster than the G-Computer LoL!!!
-
This must be the CA "naked mini" in the rack below the vertical 8" floppies. Love the printer to the right. This is the 1979 intro of E series.
There's one here to .. in the rack on the right.
(http://solidstatelogic.files.wordpress.com/2009/07/original-factory-1.jpg?w=1200&h=)
-
i have found that it is indeed a tad faster on tape interface operations
but as soon as r/w to the 8 inch floppies gets involved it's a completely different story.. :)
I could do with an E-Series CPU-Card and memory, especially if it's faster than the G-Computer LoL!!!
-
Hi guys,
This is very exciting news!! I knew there were some info out there to be uncovered and I am sure that together as a community we will get a new and modern computer working... and yes IT is worth it! ;)
On a personal side I can contribute with low-level and high-level software design. I've been involved in several projects for the past 15 years, these projects go from low level embedded systems to application layer projects, so the spectrum where I can act and help regarding software is very broad.
I also have a long experience in managing software projects, including opensource projects where dozens-hundreds of persons were actively contributing. This experience may also come in hand if we want to develop an open project that stays and belongs to the SSLMixed community instead of a one-person only project.
Where I particularly fall in short is with electronic hardware design. I have experience with it because I worked along side with embedded systems teams that where designing the hardware and I had to directly support it on the software level, but the design itself was never part of my skill set. What i can really do are all much more simple designs. So I'm sure we have experts here that are willing and can contribute with a great design that fulfills the prerequisites.
This is something we need to start thinking about if we really want to embrace this. I don't mind to prepare all the support infrastructures for the project, such as a Wiki knowledgebase, project webpage, Bugtracker, SVN, project manager, etc.
Regarding the old software, if we don't have access to the source code (which by now I'm 99% sure we won't) we can try to reverse it by disassembling the code. This is possible but we will need the Computer Automation manual for the CPU's architecture and instruction set to make any sense of it. This will enable us to understand the assembly routines that we are going to disassemble. I'm sure we won't be able to make total sense of everything because the software wasn't confined to the computer and interacted with the outside world (console), so we might have more difficulties on that side. But the idea here is not to copy anything at all, it is only to understand how things work, such as: - i/o ports, i/o structure, guard times, HZ, and so on. When we know better how the system works we will be able to implement this on a totally new and modern system that has no relation with old one other than the I/O ports and the way the computer communicates/handles the console. Actually we can implement much powerful features these days, even considering the limitations of the console.
There also another thing that might help. If we know exactly the CPUs that were used in the SSL computer (which we already know) there might be a chance that some other geek on the internet has already implemented an emulator that will let us run the SSL software in there. It's a long shot, but it might actually work and be of help, specially if you can trace the emulator instructions.
Any of the features that Werner spoke can be implemented on a small computer with a standard low consumption chip such as an ARM x86 architecture chip (those chips than come on your cellphone). The power and capacity of these chips will give us total freedom to do what we want without compromise and multitask whatever tasks we need too, and add more powerful features without compromising the console function and the realtime needs of automation and similar time critical tasks. Using an x86 architecture chip will also enable us to change the chip in the future without having to rewrite any code, being the x86 architecture the most commonly implemented out there in the chip world. The only thing here that will need to be thought about is the AD/DA + "more simple logic" to process (read/write) the console VCAs, transport, leds, total recall info, status and other stuff we can actually access and read/write to the computer. This is where the really catch is.
To develop such system we could easier to adopt an already established Real Time operating system, such as RTOS which is opensource and licensed under GPL (free). This operating system is a hard real time operating system (UNIX based) and it's fully POSIX compliant so we can use standard glib C to develop our server core daemon and install 3rd party services that we might need. It also supports full TCP/IP stack for full IP network support and has a veryyyyy small footprint (Kilobytes) so we don't need lots of flash space. This would be a perfect base for development in my opinion, giving no compromises and at a very affordable cost.
I have already a few ideas for the software architecture for this new "SSLMixed Mini Computer" that I will share later.
Comment?
Cheers,
Artur
-
Is there a point to completely reverse engineer the SSL code? Is it just to figure out how the analog console communicates with the computer? If so, I'm sure there are ways to do that without needing a CA Mini Naked. I would think the ultimate goal would be to develop a hardware box that can be plugged into a USB port and communicate with any standard DAW system for the automation portion. Is there a still huge need to still have transport control for 2" machines from the desk? I don't know. I interface my desk to Pro Tools so I don't have that need. Do we have to recreate every feature that SSL currently has? We need to think more forward on this. Most new engineers are familiar with DAWs so we need to try and keep the automation within that realm. Total recall is the other huge feature and that to me is just a database issue once the hardware interface is figured out. I could be missing the point here, but I think we should be thinking along those lines.
-
By the way,
These are the Computer Automation computer/cpu models:
http://computer-automation-museum.org/ca/index.html#Computer_models
This is the instruction set for the LSI-2 chips:
http://computer-automation-museum.org/ca/instructionset/lsi-2.html
What chips models do these SSLs computers have exactly?
Cheers,
Artur
-
No, you're getting the wrong idea I guess. The idea here is not to reverse the SSL code so you can replicate it, that would be stupid. What we are talking here is to take a peek at the SSL code to understand how the system is designed so we can interact with the console and basically know what we are doing, not having to "drive in blind". We need to know what data goes through which buses, what signals flow through which ports, how it is "formated", what are the read/write times so we can cope the slower logic frequency, etc. This is something we will need to have documented (by already existent documentation or by us) so that we can do a new computer. There's no way to go around this... Well you can always go in with your oscilloscope and spend insane hours reversing it, testing every possible scenario and testing stuff. It would be easier to just disassemble code (I might be wrong).
My idea is exactly what you are saying regarding the new computer, but in the end of the day we will always need a box (now matter how small it is) where we can design the logic to connect all the console cables and interact with it. I wouldn't go for the USB option, but I will explain why later, since it could be limiting for what we are looking for. I am already sketching a draft for an architecture that I think you'll be happy to see! I'll try to post it later. ;)
Cheers,
Artur
Is there a point to completely reverse engineer the SSL code? Is it just to figure out how the analog console communicates with the computer? If so, I'm sure there are ways to do that without needing a CA Mini Naked. I would think the ultimate goal would be to develop a hardware box that can be plugged into a USB port and communicate with any standard DAW system for the automation portion. Is there a still huge need to still have transport control for 2" machines from the desk? I don't know. I interface my desk to Pro Tools so I don't have that need. Do we have to recreate every feature that SSL currently has? We need to think more forward on this. Most new engineers are familiar with DAWs so we need to try and keep the automation within that realm. Total recall is the other huge feature and that to me is just a database issue once the hardware interface is figured out. I could be missing the point here, but I think we should be thinking along those lines.
-
By the way,
These are the Computer Automation computer/cpu models:
http://computer-automation-museum.org/ca/index.html#Computer_models
This is the instruction set for the LSI-2 chips:
http://computer-automation-museum.org/ca/instructionset/lsi-2.html
What chips models do these SSLs computers have exactly?
Cheers,
Artur
Its the LSI-4 that SSL used, unfortunately the instruction set is different to the LSI-2 . I was in contact with the owner of the computer automation museum website some time ago and explained my plan to implement a NM4 in a FPGA. He has some LSI-4 documentation but no time to scan it.
It gets a bit harder, it seams the models used on the first E series was LSI-4/30 SSL gradually migrated to the LSI-4/90 which was backwardly compatible. The G series computer used the LSI-4/100 which there is even less information about. It does have an additional Z80-ish processor (made by Hitachi) to handle the SCSI drives.
The document we really need is the NM4 4/100 computer reference manual, at a push the 4/30 computer reference manual (CA part number 91-20991-00A0) would be a good place to start.
I could assist with the dis-assembly of the code when we get the necessary docs.
Cheers,
Steve.
-
Nice! :D
I think implementing an FPGA is overkill and we should run away from it completely. We really need to implement a totally new system and look ahead to the future. Having our own system will enable us to do whatever we want, and that's the beauty of it, providing us the best return we'll have for such a great task.
We just need to start documenting stuff, making diagrams regarding how the SSL interconnection is done and processed. After that we need to start designing a hardware base. For development we could design it on breadboards for the i/o and using a development board for ARM or similar chips (i hope i'm not committing electronic design murder) that will give us enough freedom to test the design without committing and develop the initial software base. This would be a very good starting point. Later when we had a design settled in we could start thinking on minimizing stuff and produce a printed circuit board with SMD chips or something.
What do you think?
Cheers,
Artur
-
You guys are on to something - very exciting!
-
the entire source code was coded in assembly
i don't really see myself as a coder - i'm more of a hardware man but i was forced to use about 40-50 lines of assembly to make Konnektor work
to be honest, that task alone was making me seriously, seriously angry and i hated it big time!
but it was the only way to make it work as it was the fastest and smallest way to achieve what was needed
so that's my personal limits
anyone out there to be able to decode the source code?
i don't know if you know that ssl did not design the computer at all but licensed it from CA - a company called computer automation
http://en.wikipedia.org/wiki/Computer_Automation
i'm still running one of these on my B-series - it's called the 'naked mini'
it's from 1977 and runs the 'latest' E-series software - actually still responds faster than a G series, btw?!
i wrote half of the konnektor code on that cpu - only to discover that i needed to slow down everything for the g-series
what ssl added was:
the tape interface card:
to decode the 80 bit smpte t/c, which was realized by 10x 74C164 8bit serial in - parallel out shift registers + 11x 74ls368n
it actually allows you to measure every single bit of the t/code - bits 0-63 contain t/c + user bits and bits 64-79 contain sync words
something that could be done with one chip nowadays?
then they added the tape machine interface which are basically solid state (excuse the pun) relays to control various machines and scan their switches:
PLAY / STOP / FFWD / FREW / REC
the leds + switches interface which feeds the parallel bus into the computer (trim/abs leds)
and finally, the analogue i/o cards with their multiplexed signals of the converters - i.e. one a/d + d/a converter which feed the parallel bus of the ssl computer
and then there's a z80 card for the total recall - which is serial information running through the fader lines of each channel
so yes, technically i would probably be able to provide the hardware required for a more modern computer - but is it really worth it?
you'd need to code everything from scratch on a new platform - that rules me out
maybe someone is able to convert the original assembly code to a newer system?
like i said..it's 74 ttl chips :) cheers, werner
Hi Werner,
I have just read you post again in more detail, are you saying you wrote code in assembly for the NM4? and then patched it into the E series software? If so does this mean you have access to some of the NM4 CA documents?
Cheers,
Steve.
-
hi Steve,
i meant that i had to write some assembly code for the chip which is inside the konnektor
unfortunately i don't have access to any information regarding the NM
and you're totally right about the CPUs
- g-series uses the 4/100
- e-series also runs on 4/30 and 4/90 - i have both of them, the 4/30 has a reduced instruction set but works - it's a bit slower, though
- both, e and g series, use a z80 for total recall
cheers, werner
-
Hi guys,
Please take a quick peek at this thread and leave your thoughts so we can move this discussion as soon as possible to a more appropriate place and start collecting and organizing the necessary information for this project.
http://forum.sslmixed.com/index.php?topic=431.0
Cheers,
Artur
-
just found this NM4 information:
http://www.thekonnektor.com/ssl/NM4_General_Information.pdf
-
Thanks Werner,
You're welcome to our humble community! ;) I hope to count with your help to make this project a success! :D
Cheers,
Artur
-
Please repost that info here. ;)
ah cool - will post some useful info in the new thread in a minute
the whole forum thing is all very new to me :)
-
Please repost that info here. ;)
ah cool - will post some useful info in the new thread in a minute
the whole forum thing is all very new to me :)
I guess after this I will have to shuffle all the posts in the new category of the forum... 8)
Mattia.
-
yes, there is a need, or at least desire to maintain tape transport control. I have several SSL boards that are interfaced to Studer machines.
Alan
-
The requisite specification thread is now open
http://forum.sslmixed.com/index.php?topic=446.msg2496#msg2496
-
A quick note to say that the chap leaning over the back of the console in the first pic (page 1) is the late Colin Sanders. The bearded chap in the other photo I recognise, but can't put a name to him
The computer rack shown in the second pic was the standard one supplied with the console in the early days. Twin floppies, miniPC rack mounted below, big ugly silver rack. I think a lot of the computers were swopped out with later models as part of a rolling update program. I know the power supplies at Eden were huge tall rackmount things and were replaced by a 2U PSU that took two people to lift. If you have one of those racks with scratches on the front edge, now you know why!
The first London 4000E console was at RG Jones, the second at Eden. Sarm East followed pretty soon after. All predated by the Townhouse Studio 2 4000B with (I think) rotary routing switches
Nick Froome
-
Hi Nick,
Thanks so much for the info! I'm always baffled by the SSL history! :D
Cheers,
Artur
-
The bearded chap in the other retro SSL picture with the 651 pulled out is Jim Smith. I thought I mentioned him before in another post but he could be a useful chap to contact if possible regarding this new computer system replacement. Before SSL he engineered the Buggles single, Video killed the Radio star with Trevor Horn on keyboards amongst other things but, more importantly since being at SSL, he was a young design engineer responsible for the new computer.
Faced with the problems at CA, SSL set about designing their own computer rack and floppy drive system and Jim Smith was the main man behind this concept. He designed both the 11u rack and the 2u Floppy unit and I made some of the earlier prototypes and production versions whilst working with him. He was also responsible for the 3u Synchroniser rack (linked to the Adam Smith or Lynx synchronisers) plus the Real time and Events controllers as well, most of which I also made in the earlier years along with the associated cables.
My point is, he may be worth checking out as he would have extensive knowledge about the SSL computer system hardware then. He used to live in Hailey in Oxfordshire I think and I did some work for him whilst he was designing F1 racing car wind tunnel systems in the early nineties.
Hope this helps and maybe someone can track him down (I'll give it a go as well).
-
The bearded chap in the other retro SSL picture with the 651 pulled out is Jim Smith.
I should have remembered. AFAIK Jim is still very much in touch with Sarm so you should be able to contact him via Sarm West
Nick Froome