fuse-emulator-devel — Development of Fuse (the Free Unix Spectrum Emulator), the associated utilities and libspectrum, the ZX Spectrum file-format handling library.

[fuse-emulator-devel] Fuse web pages / logo

[Philip K. <pa...@sr...>]

IMO, Darren's updated web pages for Fuse[1] are perfectly good enough to
go up as http://fuse-emulator.sourceforge.net/

Any views to the contrary?

One thing we should probably agree on before all this happens is which
of the numerous logos[2] we like for Fuse; personally, I quite like
Darren's fuse-ds-3.jpeg, but don't have too many strong views on this.

Cheers,

Phil

-- 
Entertainment channel unavailable due to jamming. Movie channel
unavailable due to jamming. Sports channel unavailable due to jamming.
Adult channel unavailable due to jamming. ISN available.
                              Babylon 5 television selection: Racing Mars

Re: [fuse-emulator-devel] win32 default system directories

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 11:55:53PM -0500, Marek wrote:
> 
> I never liked windows registry and I don't want to promote using it this
> time.

Whilst it may suck somewhat, it's how people expect a Windows
application to work, so I think we'll need it in the end; it's not a
priority yet, and I don't think it will be until anyone does a native
Win32 (DirectX?) video implementation.

> Will utils_find_lib for Mac differ that much from the one for linux?

Yes :-) See fuse/fusepb/utils.c in the OS X source tarball.

Cheers,

Phil

-- 
"Can we talk?"
"Vocal cord-wise, yes. With each other? No".
                                             Spike and Buffy: Tabula Rasa

Re: [fuse-emulator-devel] win32 default system directories

[Marek <sp...@we...>]

> On Tue, Oct 28, 2003 at 05:49:18PM +0100, Marek wrote:
> > 
> > So I propose replacing every instance of getenv("HOME")
> > with a function in utils.c similar to utils_get_temp_path.
> 
> Done; it's pretty simple at the moment but can always be made more
> intelligent in future if we need it to be.

I think that's ok - I just noticed that java applications like borland
jbuilder put stuff straight into %USERPROFILE% too. Application Data\Fuse
would just make it more fancy and the program is not at there yet to care for
this stuff.

> 
> > As far as the problem with dirname on win32 - I don't have libgen.h on my
> > system, and (this time ;)) I check in the current mingw runtime 3.2. File
> > functions don't care about consistensly of slashes, so for example
> > c:\fuse/roms works perfectly fine.
> 
> It shouldn't be too hard to get glibc's dirname() working as a
> replacement; you may have to worry about backslashes here as that looks
> only for slashes as directory separators.

As opposed to part of filename? Windows doesn't allow those at all. If you try
to create a file with / or \ you get an error message: that "filename cannot
contain \ / : * ? " < > |" so both slashes are separators now, although / is
not fully implemented everywhere, and definitely will cause trouble on alder
system (if used with native win32 function, not mingw wrappers).

Best regards,
Marek

Re: [fuse-emulator-devel] win32 default system directories

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 10:53:36PM +0000, Fred wrote:
> Maybe we could have a dists hierarchy that would containing the varying
> platform files (settings may also differ per platform as opposed to per UI)

I certainly wouldn't disagree with this as an idea, although I think
that things like the menus should probably end up as something like
ui/cocoa, rather than under dists/ (or whatever we call it: I'm not sure
dists is the right name). This probably applies to the widget/ directory
as well :-)

Cheers,

Phil

-- 
"Well, then, I have a question. I mean, granted, I am stuck in Medlab most of
the time, and granted, I'm usually the last one to know anything around here,
and granted, we've all been pretty busy lately, but could someone *please*
tell me what the hell these Shadows are?"      Franklin: B5: Matters of Honor

Re: [fuse-emulator-devel] win32 default system directories

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 05:49:18PM +0100, Marek wrote:
> 
> So I propose replacing every instance of getenv("HOME")
> with a function in utils.c similar to utils_get_temp_path.

Done; it's pretty simple at the moment but can always be made more
intelligent in future if we need it to be.

> As far as the problem with dirname on win32 - I don't have libgen.h on my
> system, and (this time ;)) I check in the current mingw runtime 3.2. File
> functions don't care about consistensly of slashes, so for example
> c:\fuse/roms works perfectly fine.

It shouldn't be too hard to get glibc's dirname() working as a
replacement; you may have to worry about backslashes here as that looks
only for slashes as directory separators.

Phil

-- 
"It's a trick. They get inside my head, make me see things I want."
"Then why would they make you see me?"
"You're right. Let's go."       Giles and Xander: Buffy: Becoming, Part 2

Re: [fuse-emulator-devel] win32 default system directories

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 05:49:18PM +0100, Marek wrote:
> 
> In line 340 of utils.c in fuse
> function returns values of TEMP or TMP directory, or "./" if neither found.
> Later caller function assumes that the returned path ends with "/", but
> both TMP and TEMP miss it (those variables are required by windows so it's
> always a problem).

Fixed.

> In libspectrum in zlib.c it is still hardcoveded as "/tmp".

Yeah; I wasn't going to bother porting all the compatibility stuff to
libspectrum until we decide that's the method we actually want to use
for gzipped files. I'm leaning towards using the undocumented hook into
zlib (assuming I can get it to work).

Phil

-- 
"And I appreciate that I'm the one you chose to wake at 3 in the morning
to tell that you've been dreaming about semicircles, but maybe we can
talk about this in the morning?"
                                                    Max: Roswell: Missing

RE: [fuse-emulator-devel] win32 default system directories

[Marek <sp...@we...>]

Fred wrote:
>
[...]
>
> I have to override utils_find_lib for the Mac platform as distribution
> files are packaged with the application "bundle", rather than being
> spread around the filesystem, it would be nice if we could come up with
> an approach for handling these extra differences.
> Maybe we could have a dists hierarchy that would containing the varying
> platform files (settings may also differ per platform as opposed
> to per UI)
>
> e.g.
>
> ui/
>     gtk/
>     sdl/
> dists/
>     x/
>       settings.pl            (contains only references to $HOME)
>       utils_find_lib.c
>     win32/
>       settings.pl            (Uses registry?)
>       utils_find_lib.c
>       win32_menu.cpp         (Win32 C++ menus for SDL UI)
>     cocoa/
>       settings.pl            (Uses User preferences framework)
>       utils_find_lib.c
>       cocoa_menu.m           (Objective-C menus for SDL UI)
>
> etc. etc.

I don't think there's enough win32 stuff to create a separate win32
directory.
I never liked windows registry and I don't want to promote using it this
time.
The xml settings are simple and nice, and the libxml2.dll is really small.
If it wasn't there already I would rather like to see apache style settings
file
rather than registry.

As far as windows menu, I'm working on both sdl and gtk2 interface and the
latter
has really nice menu system and it doesn't need any modifications when
ported from linux.
Difference between sdl and gtk is that sdl already has sound routines - I'm
currently
almost done with directx sound unit.
The only thing I miss from sdl is the choice of filters - I really like mame
ones.

AFAIK the menu system for SDL can be very easily accomplished by sending
windows messages
to the system. Rather than that I was thinking about creating a whole new
interface for native windows.

Will utils_find_lib for Mac differ that much from the one for linux?

Best regards,
Marek

[fuse-emulator-devel] Re: [ fuse-emulator-Bugs-830660 ] Endless loop in opening /dev/audio

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 04:37:33PM +0000, Philip Kendall wrote:
> Anyone got any clues on this one? I can't replicate it

OK, got it; if the sound initialisation failed, it called
fuse_emulation_unpause(), which attempted to reinitialise the sound...

Yes, I should have got this before :-)

Now fixed in CVS.

Cheers,

Phil

-- 
"That's my underwear." "What does this say?"
"Calvin." "They're not yours."
                           Crichton and Aeryn: Farscape: Rhapsody in Blue

[fuse-emulator-devel] Re: Notification of tracker items

[Philip K. <pa...@sr...>]

On Sun, Oct 26, 2003 at 09:17:58PM +0000, Philip Kendall wrote:
> I've currently got Fuse's SourceForge stuff set up such that it mails me
> whenever a new tracker item is submitted. However, it would seem more
> sensible to me to mail this list when this happens.
> 
> If I don't get any objections, I'll change this over sometime in the
> next couple of days.

Now done.

Phil

-- 
"I'd like to live just long enough to be there when they cut off your head and
stick it on a pike as a warning to the next ten generations that some favours
come with too high a price. I'd look up at your lifeless eyes and wave like
this. Can you and your associates arrange it for me, Mr. Morden?"      Vir: B5

Re: [fuse-emulator-devel] stupid SDL sound question

[Philip K. <pa...@sr...>]

On Tue, Oct 28, 2003 at 10:23:48PM +0000, Fred wrote:
> Yes, it is just a typo - well spotted!

And fixed...

Cheers,

Phil

-- 
"You, I can't believe you got into Oxford." "It's pretty exciting."
"That's some deep academia there." "There's where they make Gileses." "I
know. I can learn and have scones."
                                            Buffy, Willow and Oz: Choices

Re: [fuse-emulator-devel] win32 default system directories

[Fred <fr...@sp...>]

Marek wrote:
> For home directory on win32 there's no "HOME" system variable. For
> all windowses except 95 and 98 there's a system variable called 
> USERPROFILE (so getenv( "USERPROFILE" ) - would work fine). Here's
> some reference: 
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/per_user_installations.asp >
>  
> So I propose replacing every instance of getenv("HOME") with a
> function in utils.c similar to utils_get_temp_path. Since there's no
> USERPROFILE on win 95 and 98 I propose it to look something like:

I have to override utils_find_lib for the Mac platform as distribution
files are packaged with the application "bundle", rather than being
spread around the filesystem, it would be nice if we could come up with
an approach for handling these extra differences.
Maybe we could have a dists hierarchy that would containing the varying
platform files (settings may also differ per platform as opposed to per UI)

e.g.

ui/
    gtk/
    sdl/
dists/
    x/
      settings.pl            (contains only references to $HOME)
      utils_find_lib.c
    win32/
      settings.pl            (Uses registry?)
      utils_find_lib.c
      win32_menu.cpp         (Win32 C++ menus for SDL UI)
    cocoa/
      settings.pl            (Uses User preferences framework)
      utils_find_lib.c
      cocoa_menu.m           (Objective-C menus for SDL UI)

etc. etc.

Fred

Re: [fuse-emulator-devel] stupid SDL sound question

[Fred <fr...@sp...>]

Hi Marek,

Marek wrote:
> forgive me if I'm being stupid, but I couldn't find a rational
> answer.
> 
> in sdlsound.c on line 54 there is: memset( &requested, sizeof(
> SDL_AudioSpec ), 0 );
> 
> shouldn't it be: memset( &requested, 0, sizeof( SDL_AudioSpec ) ); ?

Yes, it is just a typo - well spotted!

Fred

[fuse-emulator-devel] stupid SDL sound question

[Marek <sp...@we...>]

 Hello,

 forgive me if I'm being stupid, but I couldn't find a rational answer.

 in sdlsound.c on line 54 there is:
memset( &requested, sizeof( SDL_AudioSpec ), 0 );

 shouldn't it be:
memset( &requested, 0, sizeof( SDL_AudioSpec ) );
?

Thanks,
Marek

[fuse-emulator-devel] win32 default system directories

[Marek <sp...@we...>]

Hello,

In line 340 of utils.c in fuse
function returns values of TEMP or TMP directory, or "./" if neither found.
Later caller function assumes that the returned path ends with "/", but
both TMP and TEMP miss it (those variables are required by windows so it's
always a problem).

In libspectrum in zlib.c it is still hardcoveded as "/tmp".



For home directory on win32 there's no "HOME" system variable.
For all windowses except 95 and 98 there's a system variable called
USERPROFILE (so getenv( "USERPROFILE" ) - would work fine).
Here's some reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/per_user_installations.asp

So I propose replacing every instance of getenv("HOME")
with a function in utils.c similar to utils_get_temp_path.
Since there's no USERPROFILE on win 95 and 98 I propose it to look something like:

  home = getenv( "USERPROFILE" );
  if( !home ) {
    home = getenv( "WINDIR" );
  } 

(the return of the above doesn't contain trailing slash)

WINDIR is required by windows and it's either c:\windows or c:\winnt.
Minus of this solution would be that the few people that still use win95/98
and have multiple profiles on their systems would have to use the same
fuse configuration.

Also, since windows applications don't put any files directly to %USERPROFILE%
directory, the more elegant way would be to create a directory called fuse in
utils_get_home_path + "\Application Data" (directory Application Data also
exists on win 95/98 under %WINDIR% on single profile machines - I can't check
on multiple profile win 95/98 machines, but I think it will still be there).
So the complete path to fuse.cfg would be utils_get_home_path + "\Application
Data\fuse".

My only concern is if the above will work on multi profile win 95/98 machines,
but I'm almost positive it will.


As far as the problem with dirname on win32 - I don't have libgen.h on my
system, and (this time ;)) I check in the current mingw runtime 3.2. File
functions don't care about consistensly of slashes, so for example
c:\fuse/roms works perfectly fine.


Best regards,
Marek

[fuse-emulator-devel] [ fuse-emulator-Bugs-830660 ] Endless loop in opening /dev/audio

[Philip K. <pa...@sr...>]

Anyone got any clues on this one? I can't replicate it on (say)

$ uname -a
SunOS cass30 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-4

with either 0.6.1 or current HEAD...

Cheers,

Phil

----- Forwarded message from "SourceForge.net" <no...@so...> -----

From: "SourceForge.net" <no...@so...>
To: no...@so...
Subject: [ fuse-emulator-Bugs-830660 ] Endless loop in opening /dev/audio
Date: Tue, 28 Oct 2003 01:16:52 -0800

Bugs item #830660, was opened at 2003-10-26 12:27
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=596648&aid=830660&group_id=91293

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Kunze (eku)
Assigned to: Philip Kendall (pak21)
Summary: Endless loop in opening /dev/audio

Initial Comment:
Fuse 0.6.1 loops if if cannot open /dev/audio:

./fuse

The Free Unix Spectrum Emulator (Fuse) version 0.6.1.
Copyright (c) 1999-2003 Philip Kendall <pak...@sr...> and
others;
See the file `AUTHORS' for more details.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'
./fuse: error: Couldn't open sound device '/dev/audio'


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-10-28 01:16

Message:
Logged In: NO 

OS: Solaris 9/x86 
UI: X11/FB 

----------------------------------------------------------------------

Comment By: Philip Kendall (pak21)
Date: 2003-10-26 13:08

Message:
Logged In: YES 
user_id=29214

Works for me:

$ ./fuse 

The Free Unix Spectrum Emulator (Fuse) version 0.6.1.
Copyright (c) 1999-2003 Philip Kendall <pak...@sr...> and others;
See the file `AUTHORS' for more details.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

./fuse: error: Couldn't open sound device '/dev/audio'

[ runs normally ]

What user interface etc are you using?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=596648&aid=830660&group_id=91293

----- End forwarded message -----

-- 
"Well, here we are. If you just plug yourself in to the matrix, we'll take
it from there." "Ahm, it's .. ahm .. occupied." "Oh, yes, of course, my
mistake. I spend so much time out of my body, I sometimes forget where it
is. If you'll excuse me."  Draal and Ivanova: Babylon 5: Voices of Authority

RE: [fuse-emulator-devel] porting to win32: proposition for checking for and replacement of ssize_t

[Marek <sp...@we...>]

> $ grep ssize_t mingw-runtime-3.2/include/sys/types.h 
> typedef long _ssize_t;
> typedef _ssize_t ssize_t;
> 
> or even
> 
> $ grep ssize_t mingw-runtime-3.1/include/sys/types.h 
> typedef long _ssize_t;
> typedef _ssize_t ssize_t;
> 
> What am I missing?

something on my defence:
http://sourceforge.net/forum/forum.php?forum_id=318170

Summary: Released: mingw-runtime-3.2.tar.gz
[..]
2003-10-10 Earnie Boyd <ea...@us...>

* include/sys/types.h: Revert last change.

2003-10-10 Earnie Boyd <ea...@us...>

* include/sys/types.h (ssize_t): Correct the definition.
[..]
--
Summary: Released: mingw-runtime-3.1.tar.gz
[..]
2003-05-30 Sascha Sommer <sas...@fr...>

* include/sys/types.h (_ssize_t, ssize_t): Add typedefs.
[..]

---

so for people who chose the latest, unstable dev-cpp  like I did
are not going to have ssize_t defined anywhere.

Best regards,
Marek

RE: [fuse-emulator-devel] porting to win32: proposition for checking for and replacement of ssize_t

[Marek <sp...@we...>]

> >  I have a small problem with compilation on win32 mingw.
> There's no ssize_t
> > declared anywhere in includes.
>
> $ grep ssize_t mingw-runtime-3.2/include/sys/types.h
> typedef long _ssize_t;
> typedef _ssize_t ssize_t;
>
> or even
>
> $ grep ssize_t mingw-runtime-3.1/include/sys/types.h
> typedef long _ssize_t;
> typedef _ssize_t ssize_t;
>
> What am I missing?
>

I'm running dev-cpp 5 beta:
http://www.bloodshed.net/dev/devcpp.html
"Dev-C++ 5.0 beta 8 (4.9.8.0) (12 MB) with Mingw/GCC 3.2
Dev-C++ version 4.9.8.0, includes full Mingw compiler system
(GCC 3.2) and GDB 5.1 See NEWS.txt for changes in this release."

it's nice to know this.
gcc is definitely 3.2:
"gcc version 3.2 (mingw special 20020817-1)"

and the sys/types.h definitely doesn't contain a single instance of ssize_t.
so I'm running gcc 3.2 but not mingw-runtime 3.2 (I thought it's one and the
same).

Sorry about that.
Marek

Re: [fuse-emulator-devel] porting to win32: proposition for checking for and replacement of ssize_t

[Philip K. <pa...@sr...>]

On Mon, Oct 27, 2003 at 10:09:07PM +0100, Marek wrote:
> 
>  I have a small problem with compilation on win32 mingw. There's no ssize_t
> declared anywhere in includes.

$ grep ssize_t mingw-runtime-3.2/include/sys/types.h 
typedef long _ssize_t;
typedef _ssize_t ssize_t;

or even

$ grep ssize_t mingw-runtime-3.1/include/sys/types.h 
typedef long _ssize_t;
typedef _ssize_t ssize_t;

What am I missing?

Phil

-- 
"Have you ever spied on anyone?"
                                 Francie to Sydney: Alias: A Broken Heart

[fuse-emulator-devel] porting to win32: proposition for checking for and replacement of ssize_t

[Marek <sp...@we...>]

 Hi,

 I have a small problem with compilation on win32 mingw. There's no ssize_t
declared anywhere in includes.
 Since in mingw write function is defined as:
int		write (int, const void*, unsigned int);
 I propose to check for ssize_t in configure script and modify compat.h to
include:
#ifndef HAVE_SSIZE_T
  typedef	int ssize_t;
#endif
and including compat.h in appropriate units that use ssize_t - that is in
libspectrum's zlib.c and in fuse's trdos.c

Thanks,
Marek

[fuse-emulator-devel] Re: Transparent reading of gzipped files

[Philip K. <pa...@sr...>]

On Sun, Oct 19, 2003 at 10:05:14PM +0100, Philip Kendall wrote:

[ uncompressing gzipped files ]

> /* We have a fairly huge impedance mismatch between libspectrum and
>    zlib here: libspectrum likes to deal with everything in memory,
>    whilst zlib will only deal with gzip data in files on disk. Hence
>    we have to write the data to a temporary file, and then read the
>    data back from that again. This is particularly silly if we started
>    with a simple file before feeding this to libspectrum... */
> 
> /* There is another way to do this. The zlib functions have an
>    undocumented option (setting the window size negative) to assume
>    that there is no zlib header on the file. Would using that be nicer
>    than doing this? (see gzopen and inflateInit2 in zlib for more
>    details). */

Further thought leads to more possibilities: zlib's gz* functions deal
with file descriptors, which are of course slightly more general than
files.

This leads to the idea of using an anonymous pipe to feed the idea to
zlib. I see two ways of doing this:

1) Use a separate process to run the gz* functions. This works, but
   may have portability problems.
2) Use one process and two non-blocking file descriptors. This _almost_
   works: the problem is that gzread() doesn't grok non-blocking IO and
   assumes end-of-file as soon as it can't read a block of size
   Z_BUFSIZE (which defaults to 16Kb) from its input, even if the error
   it gets is just EAGAIN. This is obviously going to present problems if
   the pipe buffers used by the OS are smaller than 16Kb...

Anyone got anything I've missed?

Phil

-- 
  Philip Kendall <pa...@sr...>
  http://www.srcf.ucam.org/~pak21/

[fuse-emulator-devel] Notification of tracker items

[Philip K. <pa...@sr...>]

Hi all.

I've currently got Fuse's SourceForge stuff set up such that it mails me
whenever a new tracker item is submitted. However, it would seem more
sensible to me to mail this list when this happens.

If I don't get any objections, I'll change this over sometime in the
next couple of days.

Cheers,

Phil

-- 
DK: "Launch conditions are optimal as of oh five thirty."
 [ ... ]
Aeryn: "You and your timing."
                                                   Farscape: 1999 - 2003?

Re: [fuse-emulator-devel] poke finder

[Marek <sp...@we...>]

> > I don't know why but I failed to find any pokes to other games - even 
bruce 
> > lee (which is almost as old as manic miner). 
>  
> I've got it working on quite a couple of games anyway: 
>  
> * Gryzor (128K, .tap version): start game, search for '6', get 931 
>   matches. Lose life, search for '5', get 1 match at page 2, offset 
>   0x00bc; in the debugger, 'break write 0x80bc'. Lose life; execution 
>   halts at 0x91cd. Step up a few instructions and spot the very obvious 
>   DEC A at 0x91c9. 'set 0x91c9 0'. Bingo :-) 
>  
> * MidnightResistance.slt: 5 => 275 locations, lose life, 4 => 1 location 
>   at 2:0x09aa. 'break write 0x89aa', lose life, execution stops at 
>   0x8e84, spot the obvious at 0x8e80, 'set 0x8e80 0'. Infinite lives. 
>  
 
it works almost perfectly for me too. I used it on rex. additionally to what 
tipshop has on their website, I found the dec for unlimited time. 
 
AFAIR not all games were as easy to poke. I don't remember the tricks now 
after all these years, but the game that gives me problems is BRUCE LEE. 
 
also I played a little with finding just increased and decreased value 
(without giving exact number) as described in my original request, but it 
gives far too many values. this would be useful for energy - it's definitely 
hard to do that would poke finder. 
 
Marek 
 

Re: [fuse-emulator-devel] poke finder

[Philip K. <pa...@sr...>]

> I don't know why but I failed to find any pokes to other games - even bruce
> lee (which is almost as old as manic miner).

I've got it working on quite a couple of games anyway:

* Gryzor (128K, .tap version): start game, search for '6', get 931
  matches. Lose life, search for '5', get 1 match at page 2, offset
  0x00bc; in the debugger, 'break write 0x80bc'. Lose life; execution
  halts at 0x91cd. Step up a few instructions and spot the very obvious
  DEC A at 0x91c9. 'set 0x91c9 0'. Bingo :-)

* MidnightResistance.slt: 5 => 275 locations, lose life, 4 => 1 location
  at 2:0x09aa. 'break write 0x89aa', lose life, execution stops at
  0x8e84, spot the obvious at 0x8e80, 'set 0x8e80 0'. Infinite lives.

Cheers,

Phil

-- 
"Hey. I know you. You're that first original Slayer who tried killing us
all in our dreams... How've you been?"
                                   Willow: Buffy: The Weight of the World

Re: [fuse-emulator-devel] poke finder

[Philip K. <pa...@sr...>]

>  debugger is great - I was looking for instructions everywhere else but in 
> commandy.y . with those capabilities poke'ing feature is the lowest 
> priority. I'm wondering if it would be useful to write some documentation, 
> both on debugger commands and on poke finding?  

$ man fuse
[...]
MONITOR/DEBUGGER
[ skip 127 lines of debugger documentation ]

THE .DSK FORMAT

:-)

The poke finder does need doing at some stage, but I was waiting until
we've worked out want we actually want from it before documenting it.

Phil

-- 
"What are you doing with Ray?" "What is necessary." "Could you be a
little more specific? 'Cause I left my copy of Wacky Cult Rituals for
Dummies at home."   Max and Breeding Cult Priestess: Dark Angel: Exposure

Re: [fuse-emulator-devel] poke finder

[Marek <sp...@we...>]

 
 Hello, 
 
 Please ignore the previous message. I think connecting the close handler 
with destroy event is a bad idea. I submited the new patch to "patches" at 
sf.net/projects/fuse-emulator. 
 
 debugger is great - I was looking for instructions everywhere else but in 
commandy.y . with those capabilities poke'ing feature is the lowest 
priority. I'm wondering if it would be useful to write some documentation, 
both on debugger commands and on poke finding?  
 
Marek