OS 6.1 New Operating System

[doktor1360]

Absolutely the best, and probably generally informative, thread I've seen on this forum board in quite a while... and there's been more than a few of them...

This is just awesome - I always like to hear about other engineers workflow steps, and all that's involved. A person can always learn something new, each n every day. And these forum boards are always a fountain of information - some really talented and damn smart people can always be found adding their experience(s) to the collective...

Everyone who participates and contributes here should understand what they bring to this curation of valuable data. We all know, that if these forum boards don't exist, the D8B (and most likely the HDR and derivatives) would have died a painfully silent death long ago. Personally, I'm grateful to each and every one of y'all thru-out the years. Been a helluva ride to date, and one I have no plans of abandoning into the foreseeable future...

\m/

[RJH_MUSIC]

I made one small mistake in my description of my setup. the master outs of the d8b that handles VSTi and vocals are fed into the inputs of the Apolllo 8 so i can get the vocals into Cubase. I assign the vocal and live instrument channels to the main mix and all others to the bus outs.

Part of my problem is that I have too much hardware. I hoard stuff I bought years ago a top dollar that aren't worth the shiping cost today if I sold them, (Bought M3R brand new for $950 in 1988 and today worht less than $150) so the first d8b is handling all 48 channels plus the 2 track in A, B, and C. In addition to that, the 32x8 bus handles 8 additional channels for keyboards. All of this because I hate using patch bays. d8b 1; XV-5080, XV-3080, JV-1080, JD-990, Integra-7, JV-880, U-110, U-220, D-110, O3R/W, M3R, TR Rack, Triton Rack, K-4R, K-1R, D-70, Dr-880 Drum, R-70 Drum, D-05, JU-06(1), JU-06(2), RA-50, Korg Minilogue. and 2 spares. d8b 2; 1-6 Vocal Mics, 7-14 Analog Instruments, 15-16 Apollo master Outs, 17-24 Apollo Outs 1-8. Mackie 32x8 bus CH 1-8 MOTIF XF7, Fantom 76, XP-80, JV-1000. CH 9-16 BUS 1-8 d8b(1), CH 17-24 BUS 1-8 d8b (2), 25-26 d8b (1) Master Outs, CH 27-28 d8b (2) master Outs, CH 29-30 d8b (1) Control Room Outs. CH 31-32 Spare. SO you can see why I love my d8b's. If i were to replace with current technology, i would have to find something that can handle audito and DAW control, have ideally 24-32 channel faders, (48 would be nicer) and a 96 point patch bay.

[Y-my-R]

FYI, I tried around a little with the Virtual Machine/Linux/Wine/MackieOS idea, with these components:

- Oracle VM Virtualbox (free virtual machine software)
- Ubuntu 20.04 (free Linux distribution)
- Wine 6.0.1 (free Windows "environment" in host OS such as Linux etc.)
- Winetricks (free app that makes configuring Wine for such things as 32-bit easier)

I tried launching the Mackie OS in all available 32-bit Windows environment choices that Wine made available, but it always crashed immediately (page fault). The choices were these:

Windows XP
Windows 2000
Windows ME
Windows 98
Windows 95
Windows NT 4
Windows NT 3.51
Windows 3.1

Virtual Box does allow to customize the hardware environment it exposes to the OS to some degree (e.g. chipset, etc.), so there's still a lot of choices I could play with there.

Wine also allows to customize the set of .dll files it uses for the Windows environment it creates, and make edits to the registry, etc. But anything I'd do here would really be just shooting in the dark.

So, I might try around a bit more with this, but it doesn't look particularly promising for someone with my limited understanding of what such customizations would have a chance of success.

I'll play with this every now and then as a low-priority leisure project, but don't really expect to be able to share a success story any time soon.

So, again, if anybody with more knowledge about the needed customizations wants to try this instead of me, go ahead... not trying to hog the idea for this possible approach.

Does anybody happen to know the EXACT Windows version Mackie had licensed for the Mackie OS, though? This may be helpful with choosing the right environment and DLL set for it.

[captainamerica]

You *should* be able to virtualize any system if its the the same architecture as your actual machine...question is does the Mackie OS stick to those PC architecture rules or make unique hardware calls?. If that's the case, you may have a hard time getting that O/S to work under any Windows platform because virtualizing a system with different hardware profiles is hard to emulate IMHO.

[Y-my-R]

I don't think the actual hardware plays much of a role in the Virtual Box virtualization of hardware I've been using for this.

In my case, I ran Virtual Box (and inside of it Linux/Wine) on a Hackintosh that is running MacOS, which in turn is running on PC hardware. Or in order of what's running on top of what: PC hardware->MacOS->VirtualBox->Linux->Wine/Windows->MackieOS (which is really just an executable for a Windows environment... I just don't know which).

I think for this setup, there aren't a whole lot of "direct" hardware API calls happening.

Also, Virtual Box makes you to choose which chipsets you want to emulate - so, basically the hardware architecture that is at the core of what makes a mainboard that type of mainboard.

Beyond that, there will definitely be some driver components that may recognize the actual PC hardware that is in use, beyond the selected chipset emulation, etc. But I think for the purpose of getting the MackieOS.exe application to start, there mainly needs to be the right (emulated) chipset, and the right Windows environment, that the MackieOS is based on.

If that was correct, I'm sure it still wouldn't boot fully... but I should at least get a little further than an immediate page fault. Like, booting up to a DSP error message, or at least a green blinking asterisk, if the video card emulation needs to be messed with (which is also possible in VirtualBox and Wine).

Chipset choices in VirtualBox include stuff like "PIIX3" and "ICH9"...and a few others. I'll have to look at that a little more carefully next time I play with it, and research if there's a chipset type that is close to what has been used on the actual mainboards that came in the D8B rack units... but this past weekend, I just wanted to get the basic VM/Wine environment set up, so I can start playing with it.

So, these were just my initial findings before going about this in a more coordinated and better researched manner. But again... my chances for success are relatively slim, as I can't really do any custom coding myself. I'm just your average small-time hack, that can follow instructions or sometimes solve things by logical deductions, using readily available tools... but as soon as I'd have to custom-code a driver (...and not just arguments how it's loaded, etc.), I'm at a loss.

Anyway... next step will definitely be to find out what the closest chipset emulation is and try around with that. Maybe I'll do that next weekend... or whenever I have the time (and muse).

[Y-my-R]

Maybe I missed the point of your post with my last response, Captain

The goal of using Virtual Box/Linux/Wine, is of course to create a virtual machine with emulated hardware components, that is close enough to the hardware Mackie used in the D8B rack units, to fool it into believing that it runs on the actual hardware (without having to make modifications to the MackieOS.exe or the other files it relies on, that are part of the Mackie OS installation).

In other words, the precise hardware that is being emulated has EVERYTHING to do with if there will be a chance to get the MackieOS.exe to run in a virtual environment or not.

What I meant in my last post was, that the actual computer hardware I'm running the virtual machine on, doesn't have much to do with this experiment succeeding or not.
In fact, my whole goal with taking this approach was, to have a cross-platform solution, that (if successful) would work on many different kinds of computers, to replace the actual D8B rack unit (no matter if they're MacOS or Windows or Linux based... as long as they can run the free Oracle VM Virtual Box software, to run a custom machine that can launch the MackieOS.exe).

(Any such solution would then still require that a SPECIFIC USB/Serial adapter with two ports would be used to hook the D8B up to... but I'm far away from reaching this point... first, I need to get the Mackie OS to get a little further than the page fault... then solve likely issues with video card hardware emulation, etc., before attempting to add serial port hardware. So, figuring out that crucial part (i.e. the requirement that two serial ports exist to communicate with the Console), will need to happen at a later point).

Now that I have at last the Virtual Machine thing working, I also intend to create a clone of the Mackie OS harddrive, that already comes with everything it needs to boot... then trying booting that again from all the 32-bit hardware emulations VirtualBox/Wine offers. But I expect that I would still have to customize the hardware VirtualBox/wine expose to the Mackie OS that runs on the virtual box. But with this approach, I'd at least get around any sort of custom calls the Mackie OS would make to, for example, the boot sector or file system to ensure it's an authentic system (e.g. the finicky harddrive formatting issue when installing the Mackie OS, that usually doesn't take a regular FAT or FAT32 formatted drive, etc.).

Anyway... again, this is just the beginning. It means that I have something I can experiment with.

If someone has a clue about this stuff and would like to jump in without having to create the virtual machine and install Wine from scratch, let me know. It should be possible that I share the Virtual Box "Virtual Machine", and others should be able to load it on their end and make their own experiments. (However, I think if trying different chipsets in Virtual Box, you'd probably have to install the virtual machine from scratch every time, anyway, since Linux would then install different drivers, before adding Wine on top for the Windows environment).

Anyway... sorry for the ramble. Hey, but if you ever tried to read "Ulysses" or anything by Virginia Woolf, my blathering here is just light (and comparably coherent) conversation, haha

[captainamerica]

hahah no ramble at all. This is hard stuff to do, so keep us posted !

[RJH_MUSIC]

Awesome information - I have been thinking about this as I just finished building a new 1R unit power supply for the console. I am beginning to wonder if the problem is not the OS, but with the peripherals. (Or maybe I do not know enough about what i am talking about, because i think you are saying that the OS is also tied to Chip Architecture)

The CPU uses the 2 COM ports on the motherboard to communicate with the console using the data cable. So in modern day computers, there is no such thing as COM ports, they are all USB and USB C ports. So maybe all you need are drivers or emulators to convert the serial data cable to USB? Why would you even need Windows, MAC OS or Lynx at all. Just keep the proprietary Mackie OS.

[RJH_MUSIC]

Did i just say the same thing that Y-M-R did?? LOL

[Y-my-R]

It wasn't exactly what I said... or at least not what I meant.

The "MackieOS" isn't really an OS at all. It is an executable file (.exe) that was created to run in a very specific Windows environment, that runs invisible to the Mackie OS user in the background.

Basically, when you boot the D8B, a "Windows" environment boots in the background, but without showing any of it's "Windows." Then, it automatically launches the MackieOS.exe, which is the first thing during bootup that is designed to show you a "Window" with a graphical user interface.

So, while it's true that the "MackieOS" comes with it's own flavor of Windows that we just can't see, it is possible to clone the entire installation of it to another harddrive (or virtual harddrive), in a very similar fashion to how people who lost their installation floppy disks, would install this on a new harddrive or CF card for the D8B.

The problem with this is, that the Windows portion of the "MackieOS" doesn't ONLY need Serial/COM ports to work.

What is typically done for "custom" versions of operating systems, that ONLY need to run on very specific hardware and no other computers that use other components, is to include ONLY the drivers in such an OS, that are mandatory for such a custom computer/OS to start. Everything else is stripped out, to keep the installation small so the installer fits on a few floppy drives, and nothing unnecessary will get loaded by the OS, so no unnecessary RAM is being used, etc.

So, the MackieOS with it's custom Windows version that runs in the background, has drivers built in for the standard D8B video card, the standard D8B network card, the standard D8B MIDI card, and a whole bunch of essential, but less noticable drivers as well (e.g. the keyboard and mouse controller drivers and chipset drivers for the mainboard, etc.).

However, since it ONLY comes with the drivers it absolutely needs to run on the SPECIFIC computer hardware Mackie used in the D8B, it will not run properly, if any of these hardware components is different, because it then doesn't have a driver that tells the Mackie/Windows OS what that hardware component is and how the OS can talk to it (that's sort of what a driver is... the thing that explains to the OS what a device is, what capabilities it has and how to talk to it).

What I'm trying to do with the "Virtual Machine" approach, is to create a virtual environment, that presents all the hardware the Mackie/Windows OS expects, so it already has the drivers in it that allow it to communicate with that "virtual" hardware.

So, first I need to try if I can get a virtual emulation of the video card in the D8B hardware running, before there will be any chance to display a graphical user interface (aka GUI) to the user.

...the same thing goes for all those other components in the D8B hardware rack unit (e.g. network card, MIDI card, keyboard controller, etc. etc).

What gives me a little bit of hope that this might work, is because Mackie chose rather generic components for the hardware in those rack computers. The MIDI card, for example, is the grandmother of all computer MIDI interfaces, and the driver exists in pretty much all flavors of Windows. The network card is also pretty generic.

Also, back in those days, there weren't THAT many different hardware components available as now. So, when a virtual machine emulates old hardware, there's somewhat of a chance that it has an emulation of THAT specific hardware, since there really were only a handful of choices for video-card chips back then (...and I kinda expect that once I figure out something to get the main chip on the video card to work, I'll probably still have to modify the registry to force certain RAMDAC settings, etc., like you had to in the early-ish Linux days, when trying to get XWindows to work so you get a GUI).

Only after all of that works, will it make sense to find a COM/Serial to USB adapter, and try to expose it to the MackieOS/Windows, where it only sees that COM ports are available (again, luckily the drivers for that part are rather generic), and doesn't know anything about this being converted to USB.

Long story short... the COM/Serial-to-USB adapter comes at the end of a long list of other hardware components the MackieOS/Windows have to recognize, before you'd even be able to see the GUI you're familiar with right now.

There's still a lot of luck needed, to find/modify an existing emulation of all the hardware components in a way so the MackieOS.exe will just load and display it's GUI. If something needs to be programmed custom for this (and not just flags/arguments how a driver is loaded, etc.), then it's already over my head and I won't be able to do this.

I do intend to experiment with all available hardware emulations in Virtual Box and possibly in Wine (this gives some extra options Virtual Box doesn't have), but it's far from certain that this will work out.

Basically, the COM/Serial-to-USB adapter is the one hardware component that is definitely needed IN ADDITION to all of the "virtual" versions of the hardware that need to work flawlessly before the MackieOS would load to the point of where you can see the GUI, and it would be ready to exchange data with the console.

So, it isn't that simple. The COM/Serial-to-USB adapter is really just that famous "tip of the iceberg" that obviously needs to be there... but all the "behind the scenes" (or "under the waterline") stuff needs to work first, or this isn't going anywhere.

Anyway... I didn't have time to play with this all week. Maybe I can spend a little time with it this weekend.