|Re: [hatari-devel] Audio Sculpture and disk access|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Audio Sculpture and disk access
- From: David Savinkoff <dsavnkff@xxxxxxxxx>
- Date: Fri, 20 Feb 2015 11:35:16 -0700 (MST)
- Thread-index: 6Khb7gI96LpqviFuYVNtA1bRS03WMQ==
- Thread-topic: Audio Sculpture and disk access
Make certain that "Boot faster by patching TOS and sysvars"
is Not checked in the SDL menu. Also, be certain that Hatari is
set up to exactly emulate the real hardware you are testing.
----- Troed Sångberg wrote:
> I've been a bit fast and loose with which version I tested what with. So;
> here are the results:
> On my TOS 1.62 STE the Replicants crack of Audio Sculpture 1.4 works
> exactly like on Hatari. That means, quite badly - the whole "right click,
> edit volume name, get the path not found message, retry loading
> module"-workaround is needed.
> The internal test version, with no protection, works just fine on TOS 1.62
> STE. _However_ - the original issue found by my group member, that it
> doesn't work in Hatari, holds true. On the real machine I press Load
> Module, the Volume name changes (to blank, not the actual volume name of
> the disk, which indicates some sort of error still), the next Load Module
> correctly shows the disk content.
> On Hatari (STE mode, TOS 1.62, even the same locale) the same thing happens
> to begin with, clock mouse pointer and change to blank volume name, but the
> next Load Module press does not show any disk content - only the amount of
> free space. I'm currently unable to find any workaround - I simply cannot
> get the file list to appear.
> ... so:
> *) In 2015 we find out that the Replicants crack of AS 1.4 isn't very good,
> on STE. Looking at the protection code in the source I can fully understand
> *) However, for the purposes of getting Hatari to emulate the hardware
> we're now in the situation where I can only show the problem with an
> internal unreleased version (additionally a build of v1.3 which as far as I
> know never even made it to the public). So, I'll have to sort that out
> before I'm able to offer any more insight.
> (I'm very very sorry for being lazy and not writing the cracked version to
> disk earlier - but at least it resulted in some "scene news")
> Now I'll look into debugging the offending code in MonST - if I can get
> that to work then I'll get back with exactly what causes the empty file
> list ...
> On Fri, Feb 20, 2015 at 10:06 AM, Nicolas Pomarède wrote:
> > Le 19/02/2015 20:31, Troed Sångberg a écrit :
> >> Awesome research into the issue! I'll certainly do what I can to help. I
> >> _think_ I'm at the point of interest in the source but it's almost like
> >> reading pure disassembly - not a lot of help gained from labels,
> >> variables etc. So, with some uncertainty, the check is simple whether it
> >> was able to read a volume or not from the disk. If it did, it's shown.
> >> If not, it continues on.
> >> There's also some logic around a forced mediachange that I'm trying to
> >> follow. I'll try to put some time into understanding it.
> > by the way, to check if disk change is related or not to the issue, could
> > you try this on your STE :
> > - start the cracked version
> > - at the crack intro screen, insert a floppy with some modules on it
> > - press space to start depacking
> > - once in AS, go to te fileselector ; does it still work correctly on
> > your STE, or is it different from what you get when your inserted a floppy
> > after AS was started ?
> > In summary : does it changes something to insert a floppy with mod files
> > before the protection check instead of after ?
> > Nicolas