Hard Reset

[doktor1360]

Let me begin this stating I'm pretty certain a reinstall of the operating system is required here, but I'm gonna get some extra eyeballs on this and see what, if anything, anyone can add to this. The best place for me to start is to reference two (2) recent threads I started here that are relative to this, but I didn't want to get anything lost in the mix of things.

viewtopic.php?f=2&t=2518
viewtopic.php?f=2&t=2519

To sort of recap and get all that tied in here, originally this all started with an issue I noticed with the digital syncing (word clock) was some squirrely-ness in syncing with just my D8B and HDR with a single coax (75 ohm) BNC cable. Among other things, I noticed that with the D8B clock card set as Master it wouldn't sync with the HDR unless the HDR's clock card was set to 'bridged mode' for termination - in other words when set to 75 ohm terminated (switch pushed 'in') the HDR couldn't sync up the D8B's clock source... however, when set to '3.3kHz' bridged (switch pushed 'out') the HDR appeared to 'happily' sync up - red clock LED solid, and the digital sync in the HDR reporting 'locked' (44.1kHz)... and of course the D8B digital sync indicating use of the internal clock (44.1kHz) and things 'locked'. Scratching my head in wonderment, I just sorta took note and move forward as I was about to introduce a new player on the platform, a Cranborne R8 500 series rack w a robust master clock circuit, 16 ch of usable ADAT and USB via my Mac Mini. OK, let's introduce the master clock from the R8 into the mix; the overview of that is in that first url above...

The recap there, introduce a proper master clock with separate BNC connections to any/all slaved units in the rack requiring a clock. To that end, I purchased a Rosendahl Nanosyncs DDS (for a ridiculous price!) and when it arrived, this is where it gets interesting. In the interim waiting for the master clock generator to arrive, my D8B had a 'moment' and went tits up... all appearances and triage pointed to the motherboard/cpu just giving up the ghost as it wouldn't even POST when isolated. Great, motherboard shelf life expiration; the overview there is in the second included url above. As reported in that discussion thread, it all of a sudden just 'booted up' after some cleanup on my bench - no desk attached, just the cpu host and mouse/keyboard/monitor as I was just attempting to access the BIOS and/or listen for the beep code diagnostics for reference...

So, at this point I had the D8B successfully booting and loading up the Mackie OS displaying the GUI splash screen without the console... kewlio, step #1. On to the next 'test' with just the word clock generator and the D8B. What I had also done during all this is verify that the Rosendahl clock was functioning correctly (besides indicating as such on the front panel display). I connected it to the HDR's 'clock in' with the HDR configured to look for a 44.1 kHz master clock in the digital sync configs. Flawless... syncs right up, whether the clock is on or off during the HDR boot cycle - it doesn't care (as opposed to my D8B). The Rosendahl / HDR combination works exactly as it should, so I can eliminate these variables from the process now too. I also reseated the D8B's Apogee clock card and reinstalled it. Continuing on with just the D8B is when I started noticing other things I either never noticed or just weren't taking place. I'd boot the D8B up, it would look for the word clock and report a 'lock error'... and momentarily 'lock' only to cycle back to trying to lock on the clock source. Forget about booting the D8B with the clock generator on... it's the Vegas Strip with all the lights, the console essentially flipping out. This also happened when I'd switch the clock source from 'internal' to 'word clock' in the configs. I'd get an immediate reaction from the desk - different lights but all indicative of an obvious failure. I shut the desk down, removed the AC cord for 5 minutes or so to continue moving forward. This was repeatable, so I chalked it up as a potential Apogee clock card malfunction in the D8B... just very odd indeed...

I continued on, doing what I could to determine anything logically sound regarding how to isolate any issue(s) that seemed present. As I was proceeding along, I encountered a situation and things just got out of hand. I booted the D8B up (looking for a master clock) and it successfully loaded, albeit looking for a clock. I turned on the Rosendahl, and no bueno... still had a 'lock error'. However, I noticed it did lock sporadically for a split second and immediately returned to the 'lock error' condition, doing this same thing in a loop of some short duration... rinse/repeat, ad nauseum. So, I left the everything on just to see if the clocks would somehow magically sync with a little time involved. Nope... and I also started noticing things that were strangely new. The fluorescent displays right channel of the R/L meter would every now and then spike a bit, and upon turning on the monitors there was a low level buzz or something... some sort of static-y garbage. I verified this by repeating these same steps... and upon the third run, when loaded up and running it suddenly and randomly displayed a 'one moment please...' message and the desk locked up hard... lost all serial comm with the cpu (no mouse or keyboard). Wow...

Now, it boots up to the GUI, does the requisite blinking of the rude solo light waiting for the interface code to finish executing and then LOCKS UP HARD... right when you usually get the audio flash of the meters and things settling like normal. I removed the start up file from the disk several times to have it recreate one, just in the event it was an issue related to the file execution. The D8B creates the new file, but still locks up at the same point (final mixer display) consistently. This is kinda pissing me right off at this juncture...

So I'm assuming based on what I'm seeing is the next step would be to reinstall the OS (sighs) just to get this to boot again. As I started in on that, the thread with the 5.1 crack is so friggin' confusing - which is probably why it's 19 or so pages... but its insane trying to follow it all. I've got two different .ZIP files - d8b_kit.zip & d8b_v5_1_B445 PC.zip - and both have different procedures. Now, I've got a USB stick with the installation images for the D8B v5.1 & HDR v1.4 on it, along with services packs, etc. Now, I can't remember what I did to get this working (files are date stamped @ APR-2016) after I did the installation. Everything I'm reading appears that maybe something has changed?!? The kicker is I run Linux as my primary everyday operating system, and most if not all the input on these threads are based on Windoze. In reality, I just need to know what's taking place here on an overarching level. I suppose the first thing I could do is install the images I have on USB via the emulator and see how that goes. After I can get that accomplished, it seems that the zip file with the 'patched' MackieOS.EXE file would be the path forward. Just load the flash card w the installed OS into a reader, and copy the new MackieOS.EXE file over the 'original' for it for execute. Is that correct or can somebody straighten me out here... I'm thinking it's essentially the properly curated (read cracked) community 5.1 image with the patched MackieOS.EXE as the executable... no need to f*ck around with the control.asc file and the assorted fart-knockery I can recall was part of this process at some point in the past...

I apologize to anyone/everyone about any bandwidth waste here, and if it's confusing or poorly organized. This has really has simply kicked my ass for the last few days and I'm getting sorta frustrated. I'd like to a) get this reset, reinstalled & working properly to be productive again and b) document the process, if not just for myself, so that everything regarding the imaging is clearly understood and easily executed... regardless of platform (Windows, MacOS or Linux) and/or media choice (hard disk or compact flash) being selected. As a professional hardware/software engineer for so many years, defining these types of process (how to's) are nothing new to me. I just wanna know what it is that actually needs to be done, for minimizing the somewhat confusing process to restore things (at this point)... any/all input in those regards are certainly well received. And let it be said that I appreciate everyone that's contributed in any way to this thread to date, in the bigger picture it's all important...

And of course, thanx in advance for the cooperation and any/all input to this endeavor - it is greatly appreciated...

[doktor1360]

This is getting uglier...

I took a blank compact flash card, my usb stick with OS 5.1 build 445 and reinstalled the software. The process of installing the software went without a hitch... and upon rebooting at the end of the installation cycle, once again gets to the splash screen, initializes the host and displays the interface... and boom, locks up HARD when complete. The desk is unresponsive to anything... albeit nothing abnormally lit up. It's as if it reaches an execution point, displays the interface and then communications just simply craps out between the host and the console itself...

It seems as tho everything works to the point of the interface code itself taking control of the execution, and something in the mixer itself is behaving very badly. My reasoning for this is that when I have the cpu isolated on my bench (no mixer attached via the BFC), it boots and gets to the V5.1 splash screen - cpu host hardware n firmware functional. When including the attached console, the process then goes about initializing the interface and displays the mixer interface gui... with the rude solo light doing it's thing, and when it would normally turn control of the interface over to the user, that very moment it simply LOCKS UP HARD... no communication to the host whatsoever... mouse, keyboard and frozen video display. This is with two different 5.1 OS images... the original image when the issue arose and the freshly installed image... no differences...

I'm thinking there's something very wrong inside the desk hardware-wise, because at this point the cpu boots without fail (hardware/BIOS), and passes control to the OS (software) where everything then just goes to hell in a hand basket. I'm thinking this is indicative of the cpu host booting up & functioning, but when handshaking with the desk begins everything gets unstable (to say the least). Communications, voltages? They all appeared to be OK (5VDC & 12.12VDC)... I did not check the +/- 16VDC however. I'm sure there's an adequate way to check, but I'm unsure of the actual test points and what voltage levels that could/should be expected - there doesn't appear to be any docs referencing this, just some test points on the various boards inside the desk unit. Any of y'all contributing to RJ's power supply thread can jump in here if it's appropriate. My thoughts at the moment are the CPU is most likely OK... it doesn't misbehave any and there aren't any BIOS beep codes beyond the short single beep indicating all is well with the motherboard, cpu, video and RAM components when booting up. The desk, I think that's another story but I can't completely condemn it yet because, quite frankly, this just doesn't make a whole helluva lot of sense...

It's almost as tho I need to start hunting for a replacement cpu/desk... or (gulp) begin entertaining the unpleasant thought of bailing on the platform... which I really, really, really don't wanna do... {sighs}

This is sort of an SOS, y'all... it should not be happening, but yet it is. This equipment has been SO stable until about a week ago, and life in the studio here has been f'n miserable since. I've spent so much time and resources just making sure this platform was absolutely rock solid (and it was)... until it wasn't. This is more than a bit disheartening, it actually pisses me dafuq off more than it does anything else. I need to take a break from this and eat, read and circle back tomorrow. Right now, I've had it and I can't see the forest for the trees...

Feel free to jump in here, I'm really addled and groping at the moment. Really tho, in the back of my mind I'm committed to seeing this thru successfully... I'm just banking on reality agreeing with those thoughts...

Thanx in advance everything/anything... it's greatly appreciated!

Peace

[Y-my-R]

First thing that comes to mind is: Do you happen to have a second Apogee clock card you can try?

I'd think that's one of the things that happens shortly after the rude solo button turns off, is that the desk looks to lock onto word clock... and if something isn't right with that, might lock up at that point.

This would also fit in with those other world clock issues you were having prior to this, IMO.

Little side-story: I bought a used apogee clock card off of someone in Europe at some point and it got shipped over here to the US (well packaged and all). When I took the card out of its anti-static bag on my end, I noticed one loose yellow component bouncing around in the bag, and just when I carefully pulled the card out of the bag, a 2nd of those little yellow components fell right off the card.
I was able to solder them both back on, and the card worked as it should afterwards... but this experience always makes me think about the potential for unexplained weird sync/clock issues that something like this could have caused... so, this makes me wonder if your Apogee clock card might simply have an issue.

If you have a spare one, I'd just try with that first.

If you don't, I'd try all clock-variations again when booting up, especially trying to get the desk run off of the internal clock on the apogee card to see if at least that works.

...and just quickly about the cracks/hacks: Sounds like you got that installed right, but yes... there are two different cracks. The older one requires replacing that .asc file and then authorizing all the plug-ins with the codes that were shared on here.

With the newer crack, you leave the .asc file alone and simply replace the MackieOS.exe file with the patched one after installation. No need to authorize the plug-ins separately - they'll already come up as authorized.
...but again, sounds like you got all that taken care of, already.

(On a side-note - I did order the HDR parts you recommended and have the unit apart... waiting for the IDE to SATA adapter to arrive before I can put it back together. I do have one IDE/SATA adapter here, but it points upwards too much and doesn't fit in the cavity where the new drive bay for the SSD drive goes... oh well... shipping from China... waiting. But so far, so good).

[nuss]

it don't think it would have to be an apogee card to test.....if you have an original clock card you can try that to. clocking is clocking when using an external master clock. Apogee or Mackie won't make a difference as the clock source remains external.

[Jondav1120]

Hi Doc,

Can you try booting with one of the serial ports disconnected, easiest way is probably to disconnect one of the 10pin dual-in-line headers on the motherboard. And then try with the other one disconnected.

Regards

John

[doktor1360]

First thing that comes to mind is: Do you happen to have a second Apogee clock card you can try?

I'd think that's one of the things that happens shortly after the rude solo button turns off, is that the desk looks to lock onto word clock... and if something isn't right with that, might lock up at that point.

This would also fit in with those other world clock issues you were having prior to this, IMO.

Little side-story: I bought a used apogee clock card off of someone in Europe at some point and it got shipped over here to the US (well packaged and all). When I took the card out of its anti-static bag on my end, I noticed one loose yellow component bouncing around in the bag, and just when I carefully pulled the card out of the bag, a 2nd of those little yellow components fell right off the card.
I was able to solder them both back on, and the card worked as it should afterwards... but this experience always makes me think about the potential for unexplained weird sync/clock issues that something like this could have caused... so, this makes me wonder if your Apogee clock card might simply have an issue.

If you have a spare one, I'd just try with that first.

If you don't, I'd try all clock-variations again when booting up, especially trying to get the desk run off of the internal clock on the apogee card to see if at least that works.

You and I pretty much occupy the same Brain Lane... it's the 1st thing I 'wished' I had on hand. I'm gonna take the approach of backing myself into this... I can either get a) an Apogee clock card or b) another console. I've done the DD, and they're out there, not many, but either can be obtained. If it somehow ends up being internal to the CPU... then the hunt will ensue for those individual parts therein (mobo, cpu, RAM, video card). The pragmatic geek that I am, I have a 'plan of action', I just gotta execute things accordingly. Something is locking this all up HARD, I really just need to work things out to identify and replace the offending hardware. What I'm trying avoid is the 'shot-gunning' (and costly) replacement of unnecessary parts...

...and just quickly about the cracks/hacks: Sounds like you got that installed right, but yes... there are two different cracks. The older one requires replacing that .asc file and then authorizing all the plug-ins with the codes that were shared on here.

With the newer crack, you leave the .asc file alone and simply replace the MackieOS.exe file with the patched one after installation. No need to authorize the plug-ins separately - they'll already come up as authorized.
...but again, sounds like you got all that taken care of, already.

This is interesting... previewing that, what I think I was viewing is that whoever, more importantly whatever, the user here had his friend do is 'patch' the OS executable. I can't really say at this point what the Python linking was ultimately used for in the overarching process (need to attentively reread it)... but if, and that's a very big 'if', no other files were changed from a basic Build 445 installation and only used in the command line build of the executable, then from the description provided it appears the ability of the rebuilt executable can now read the contents of the .asc file, defeat the authorization code and register all plugins 'silently' when booting up. If the developer shoe-horned some code into a customized build script that can read .DLL exports (function list that's usable), these configurations could then be preset and "cooked into" the new code... but I'm speculating. But if so, then any B445 installed media (hard disk, cf card, etal) could then be loaded up in a file manager, the alternate MackieOS.EXE copied to the root of the install of the media... and be done with things as you've indicated - no authorizations and/or registering plugins, .asc file changes... let me know your perspective on this, because I have some interesting thoughts regarding creating an .ISO image (if only for myself). You know I'd be more than interested in any input...

(On a side-note - I did order the HDR parts you recommended and have the unit apart... waiting for the IDE to SATA adapter to arrive before I can put it back together. I do have one IDE/SATA adapter here, but it points upwards too much and doesn't fit in the cavity where the new drive bay for the SSD drive goes... oh well... shipping from China... waiting. But so far, so good).

Man, you'll be happy you did... all the conveniences, stability and support of 'modernized tech' (relative to the gear of course) associated with just those upgrades is well worth it... I personally think anywho. I have 3 or 4 of those StarTech drive 'cages' with 128GB SSD's populating them... easily swapped in and out. The only 'feature' missing here is hot-swapping, but doesn't change anything because we both know ya couldn't do that with OEM drive tray to begin with.

[doktor1360]

So here I sit (after a week of some really rigorous testing, troubleshooting and triage) in front of an executing D8B v5.1 SP3 patched system, with all the plugins registered successfully. The issue I'm now facing is the actual D8B v5.1 authorization code (LOL). I'm pretty certain of what I have to do to clear this issue and get things registered appropriately, now that I better understand the mechanics of the various sub-systems. Oh, and the word clock issue IS working correctly - locking onto a master clock almost immediately when I set it... problem solved with a possible Apogee word clock failure. I purchased another D8B system (more on that later) and the word clock that came with the unit works as advertised...

Meanwhile, back at the ranch... I set out to determine what dafuq I did many years back originally when we in the community were all feverishly working on getting 'The Crack' worked out and readied. The files I have are all date stamped with '04/13/2016', so it's been a while. I went thru the directory where it appears I've kept all the files and notes I jotted down during the process, and started to reassemble logically what ensued. After spending some time, it's a bit 'blurry' but here's where I'm at.

I physically opened and cleaned both the CPU host and console, re-seating cables... making very sure I removed, cleaned and reinstalled both ends of the cables of the power distribution board in the console. Wasn't much to clean, units were essentially dustless and pristine from the last cleanup... a quick coupla short blasts from a compressed air can cleaning what little that was present. I buttoned them back up, made the appropriate connections and resumed testing.

Using the 4GB compact flash disk when the failure(s) occurred, it repeatedly would not boot properly... interface would freeze up after the boot routine right at the point of handing control back to the interface (and subsequently the user i.e. me). It was consistent in the fact the console was obviously losing serial communications with the cpu, but locked up differently regarding the fluorescent display. It would either look 'normal', or have a 'one moment please' message as it froze up. The console itself always appeared to be behaving to that point, as any LED's that on were on were nothing out of the observational ordinary... then just freeze. Both Apogee word cards were also swapped in n out at various points, and made no difference at this juncture in the proceedings...

So, then I started thinking 'what about the operating system?'... everyone that's been in this user base for more than a day realizes it's certainly within the realm of possibilities, especially considering these mercurial pieces of gear we all know and love... so...

That all being said, I had a backup 4GB compact flash disk on my bench... bueno. Time to see what kind of, if any, train wreck that happens when attempting a re-installation (just for shitz n grinz). So, I pulled out the USB stick that has the installation files I used way back when, put the USB stick in the floppy emulator and booted the system up. In the fluorescent display, the loader came up, so I loaded the three (3) disk images and installed the operating system. Upon completion, removed the USB per instructions and rebooted. TADA - success... D8B v5.1 running, albeit in Demo mode... but I'll take it for now. I then shutdown and reboot, after reinserting the USB drive and loaded/installed the 3 service pack plugin images and updated the service packs... reboot. Once again, bueno... interface with the Authorization screen and plugins evidently updated/upgraded.

Onto the plugins themselves, and their individual authorization entries. After a couple of reboot cycles, ALL plugins were successfully registered and authorized for use... this is getting good. It appears I've followed the directions I used previously to this point to my knowledge and recollection, with no apparent glitches. This is where I actually checked that digital syncing/clocking issue that started all this a week ago - I fired up the Rosendahl and the D8B synced to the 44.1kHz clock almost immediately. OK, this is kewl, now I'm f'n stoked...

Really, I'm thinking all that's left to do is get this damn console authorized... it wasn't liking the code I had (never authorized), so I knew there was something, somewhere a step was omitted or some other anomaly in the process... most likely a cockpit error somewhere along the way. So I examined things, did some other tests and observed some of the notes and remnants contained from my initial experience with all this back in 2016.

After doing the required reconnaissance between the new image and the original now suspected 'corrupted' image, there were some difference's that I began to look a bit deeper at... if for nothing more than my own attempt at conceptually understanding the underlying engineering. Right now the various authorization codes entered are completely different from one image comparatively to the next. Looking at some other information I have, these differences are relative to the 'Hack 1' zip archive containing two (2) versions of the 'control.asc' ('original' and 'hack1') file and a 'licenses.txt' file. The licenses text file contains the esn, v5.1 auth code and plugin auth codes that are utilized by the suspected corrupt image of mine... hrrmmm. As I mused over that for a moment or three, the light bulbs engaged and began to flicker.

Correct me if I'm wrong here please, but at this point it seems I could easily wrap this up performing the following relative to the 'Hack1' zip contents. First, replace the 'control.asc' file that resides in the ~/Firmware/ directory with the modified file in the 'hack1' folder of the archive - that should take care of any esn related issue(s). Then, edit the 'rs422.key' file in the ~/system5/Drivers/rs422/ directory and replace the file contents (v5.1 authorization code text from the licenses.txt file), save n exit. Lastly, edit the *.key file in each of the sub-directories in the parent ~/Plugins/{plugin name}/ directory, replacing the appropriate authorization key codes (from the licenses.txt file), saving and exiting each. That should by all accounting prepare things for a reboot and subsequent authorized execution of the operating system... no keying of any codes required. I should be able to insert the compact flash disk into the rear pci bracket adapter, flip the D8B's switch to 'on' and sit back wait for the magic to happen... a completely authorized and operational v5.1 system.

Once that target is realized, I'm going to take the newly installed D8B compact flash card / disk image, and then mount it to my linux workstation in a cf reader. Then I'll quickly pull up a terminal window and use the 'dd' utility to create images at the command line, of .ISO & .IMG types, which could then be subsequently restored easily in the event of another catastrophic failure by reversing said 'dd' command line arguments. It would give me the resource I need to quickly restore things to an operational level in a matter of minutes - as opposed to hours, a week or whatever, it's a win/win scenario. That might even be a file archive that others could use, it doesn't take much to burn a .ISO image file in Windoze providing this all stands up to the scrutiny, testing and implementation. I've got most of that already ironed out, including the documentation of the process to a degree...

Anyone wanna quickly jump in here add to this endeavor, I'd certainly appreciate any/all input. I would also like to humbly apologize for any bandwidth waste for anyone put off by this dissertation of sorts...

Thanx in advance, y'all!

\m/

[Y-my-R]

I'm afraid I don't know much about the inner workings of the Hack(s), sorry!

While I'm also very interested in how these things work, I'm glad that someone else did the job and I'm not "incriminating" myself by giving pointers on how to circumvent copy protection, other than pointing to an already available solution that is available here, and appears to be "tolerated" in order to allow hardware owners to keep operating otherwise useless "vintage" products

As far as I understand the mechanics of the serial number check, though:

The brain board (I think) in the console has the ESN number embedded in a chip. The serial code you enter needs to match the ESN number of THAT particular console.
Depending on how the serial code works (e.g. via Hexadecimal encoding and a "key" that converts from one to the other), there may be only one true match, or multiple matches for serial codes that may work with that ESN.
It's usually safe to assume, that ONLY the code that was issued for the console with THAT ESN, will unlock that console.
E.g., if you had two D8Bs with "original" auth codes, and you connected the rack unit from one system to the console from the other system, it would give an authorization error, because the ESN doesn't match. That's even if you own both units legally and purchased legitimate units with auth codes. The auth codes only work for the console unit they were issued for.

So, when you enter an 'original' never-used code that was intended for a different console, it will NOT authorize the OS, since it will not match the ESN embedded in the brain board in the console.

When applying the "early" hack, there were two sets of serial codes available. Each "set" containing an auth code for the OS and a set of codes for the plug-ins (if I remember right... unless there was no OS unlock code - I don't recall - but then you'd still have to use it along with a hacked control.asc file that has these plug-ins authorized).

Anyway - these serial codes need to be used as a "set" from what I understand. I don't think you can mix your own OS auth code and plug-in auth codes from elsewhere.

That "early" hack, relies on a hacked "control.asc" file. I'm not sure what exactly it does, but I would expect that it is made to think that the hardware has a different ESN code than it actually has. Probably by "baking" a different ESN into the control.asc that matches the shared serial codes directly into the control.asc. This way, the query/response would always result in a match, if the set of codes was used, that match the ESN in the control.asc file.

So, with the replaced control.asc, the D8B would basically send an auth query, saying something like "hey, is there an auth code that matches my ESN, which is this one xyz-123" (with xyz-123 being the "hack" code that is being reported, instead of what's actually in the chip), so that a response with the entered serial from the hack, would create a match, and the console is happy and thinks it is authorized.

I don't think you can authorize the plug-ins from one set of codes (e.g. original ones) and the OS from one of the "hacks". But if you use one of the "sets" and authorize the OS with the code from one of the hacks, and then authorize the plug-ins with the codes from the same "set", it should work.

If I'd have to re-do this, I'd go with the newer hack and would just replace the MackieOS.exe instead of dealing with the control.asc file and separate OS/plug-in authorizations. Or is there a reason why you don't want to do that?

My expectations is that the original MackieOS.exe sends out a query for the ESN periodically (or at certain events), and at that point, compares what it gets back, to see if they match to each other. If they don't, you get an "auth" error.

So, I expect that the hacked MackieOS.exe has both, the query and the response baked into the file. Possibly with actual codes serial and ESN codes, but maybe by just resolving the "match?" question with "yes!" to lay the auth check to rest every time it crops up.
I'm sure it's not quite as simple in the actual code... but in principle, it should be doing something like this, I think.

In any case... happy to hear the clock issue is resolved. Once it's all working, it would be interesting to hear if the other clock card now also works, or if it was at the root of the problem, after all. But as long as the whole system works, that's all that matters.

If it was me, I'd just use the "new" MackieOS.exe hack and put the old/original control.asc file back where it was. I think this should solve the issue quicker than trying to figure out what's going wrong with the OS Auth code that needs to go with the right hack and set of codes.

(...and sorry for making myself a bit rare here, lately... work has been kinda crazy and it doesn't look as if it would let up any time, soon).

[doktor1360]

If it was me, I'd just use the "new" MackieOS.exe hack and put the old/original control.asc file back where it was. I think this should solve the issue quicker than trying to figure out what's going wrong with the OS Auth code that needs to go with the right hack and set of codes.

Ultimately, this is exactly what needs to be done... and I concluded this in a round-about way. I went over to my desk right after reading this earlier (and the pm, thx), and went to load the D8B up. HERE we go {face palm}... froze again. As much as a drag that is, it pissed me off just the same. So, fuck it, I pulled the CF card from the drive assy bracket in the cpu's pci back plane and walked over to my Linux workstation. I then inserted it into a card reader, brought it up to take a quick peek at it in a file manager, then opened a command shell. That's where I quickly viewed things at the device level from a command line (yay!), and with the 'fdisk' utility and deleted the D8B's partition... thus blanking the disk. Walked back over to the D8B and inserted the CF disk back in it's home, inserted the USB installation media into the emulator and booted up. I then proceeded without event reinstalling both the OS v5.1 and the ancillary plugins service pack. Rebooted, and up it came... unauthorized. So I shut it down, good to go at the moment...

And at this point, I can wholeheartedly vouch how EASY it was to just pull the CF back out, walk back over to my Linux workstation, rinse/repeat with the card reader and simply copy that forked 'MackieOS.EXE' file to the CF. Then another short walk back to the cpu, reinsert the CF disk and flip the 'on' switch... moments later, a fully authorized v5.1 system... and syncing to my external master clock... BOOM

I've also learned a great deal more about what this ancient warrior is doing... from the time the 'on' button is engaged to when a functional gui is rendered. I'll most likely post it up here eventually, to be honest I'm still not 100% on certain operations it appears to be performing... but that's something that'll come to me in time. It's the Geek Engineer in me...

At any rate, thanx for the assistance Y-my-R... appreciate it, man...

\m/