DBUGII/NEXT gave me this url so i guess someone will finally take care of this great soundtracker

Enjoy the Toki loader protection made by:IllegalMITZarathustra

Does that image boot for you? I've looked at the image (can't get it to boot), and nothing in it reminds me of Audio Sculpture. Esp. not the Toki strings ...

"TOKI-LOADER" on track 01 sector 02 ... and after the fade from blue to black when you try to boot it, "You cannot escape your destiny. You must face Dark Vador again...INSERT ORIGINAL DISK IN A." is in memory.

But if it's a real AS 1.5 that would be awesome. For one, it should have more than 4 channels ..

troed wrote:Does that image boot for you? I've looked at the image (can't get it to boot), and nothing in it reminds me of Audio Sculpture. Esp. not the Toki strings ...

"TOKI-LOADER" on track 01 sector 02 ... and after the fade from blue to black when you try to boot it, "You cannot escape your destiny. You must face Dark Vador again...INSERT ORIGINAL DISK IN A." is in memory.

But if it's a real AS 1.5 that would be awesome. For one, it should have more than 4 channels ..

Hi Troed ,

Blue screen, reset, black screen and finally bug : here's what I get with STeem 3.2...

I haven't installed the SSE for the moment or Hatari .

And main problem is I never had an original in hands during all those years .

DBUGII/NEXT gave me this url so i guess someone will finally take care of this great soundtracker

Enjoy the Toki loader protection made by:IllegalMITZarathustra

It crashes in emulators and on my STE as HFE.Could be an emulation issue (Steem or Pasti) and a disk protection too tough for HxC but I see a potential problem with the disk image.If you compare track 2 reading with sector 6, there are data differences I can't really explain.It's also strange how sector 6 is only half used. What's the point of big sectors then (sectors 1-5 seem to be 1KB)?By the way, the track contains "DEAD FACE" and "DEAD CODE" as keys.

Hiit's possible the original disk used a protection not supported by Pasti, as was seen in a few others games, for example variable bit cells length or weak bits outside of a sector (in track or gap), which STX format doesn't support at the moment.As the HFE image didn't work either on real HW, I think the STX image is not good and doesn't contain all the informations describing the protection that was used.A deeper look at the protection code, checking where the code expects the track data to differ between original and copy could help to see if the required informations are supported by STX imaging.

npomarede wrote:As the HFE image didn't work either on real HW, I think the STX image is not good and doesn't contain all the informations describing the protection that was used.

Only some STX images will work as HFE, which has no bit density information, it's not conclusive.On the other hand, the "DEAD CODE" sequence was also found on Jupiter's Masterdrive, which can run as HFE.This would point to a disk "mastered" using the WD1772?

Maartau wrote:And main problem is I never had an original in hands during all those years .

"I don't know what to think at the moment..."

Well if i remember correctly, one of the first version of Toki-Loader obfuscated the loading code of Audiosculpture and contained the following tricks:

-Starting in Monochrome.-Trace vector used to decrypt the next instruction to execute.-Clearing memory and triggering the bus error vector.-Jump in the Rom.-Illegal put several messages including his own address: "Please Don't Crack" "It's Hard to Do but Easy to Undo" etc etc ......

dsp56001 wrote:So TOKI-LOADER was used instead for the protection of Audiosculpture published by Expose Software.

Alright, I'll check with Redhead. The source code I'm looking at (with defines for including or not including protection code when compiling) makes no reference to any such strings - but I don't know what would be added later in mastering.

HFE format before this new enhancement didn't support neither variable bit rate neither weak bits. This doesn't necessarily means the HxC hardware couldn't use those protections because the software can load and use other formats without converting to HFE.

The SD based HxC emulator doesn't support those protections either no matter the file format. Probably the hardware is not powerful enough. The Gotek with the HxC firmware, with this recent addition seems it does support variable bit rate, but not yet weak bits.

Additionally, the conversion from Pasti implemented by the HxC software is not perfect. This is unrelated to the hardware or HFE format.

dsp56001 wrote:Well if i remember correctly, one of the first version of Toki-Loader obfuscated the loading code of Audiosculpture and contained the following tricks:

-Starting in Monochrome.-Trace vector used to decrypt the next instruction to execute.-Clearing memory and triggering the bus error vector.-Jump in the Rom.-Illegal put several messages including his own address: "Please Don't Crack" "It's Hard to Do but Easy to Undo" etc etc ......

Good luck Maartau

Eh eh, I'm happy to get The TOKI Loader .

I'll trace the whole later as I'm missing of time ATM (late on projects : I do what I can between Hospital, free time, and sides effects medication).

Thx but I see CTR and RAW, not SCP?Anyway, I converted to SCP using HxC, so I could check the MFM.The difference between "read track" and "read sector" data is explained by a C2 mark.But data is different from the first image.