Winfellow Status

[mtb]

I was browsing sourceforge, and seems that Torsten Enderling is working on winfellow during the last days.

http://sourceforge.net/projects/fellow/ , browse cvs.

[Paul]

That’s excellent news but they will have a lot of work to do.

[mtb]

Originally Posted by Paul

That’s excellent news but they will have a lot of work to do.

Unfortunatly i haven't understood exactly what he wants to do. Seems that he wants to change the gui, import the uae filesystem and convert some assembler to c. Please verify browsing the cvs.

[andreas]

worfje too has closed some ancient threads containing bug reports, with some of them started from about 2000.
The reason of some of the closures escapes me, though.

[carfesh]

That's right, we're again actively making changes to the Winfellow CVS repository. WinFellow filesystem code has been updated to the UAE 0.8.22 codebase, several bugs have been fixed, though some incidents also have been closed because they couldn't be confirmed by us and were ages old, and conversion of parts of the assembler code in WinFellow to C have also been done. I also recently added some very basic (and still pretty experimental) support for CAPS. I have a list lieing somewhere...

We're right now in the process of evaluating if we have enough changes to do a new release, so stay tuned, I'm eventually going to set up some beta-testing and see if we can do something

Kind Regards,
Torsten

[RCK]

Hey ! they are moving again !

@Worfe: your last post has two years, but your activity status is moving !
Feel free to PM me if you lost the passwords to access the http://fellow.abime.net/ mirror website & sql

[Big-Byte]

Why change the assembler code back to C ? wont that make it slower.. ? Winfellow was my fave for a long time cause it was so fast on low end PCs.

[fiath]

Done carefully, you might not even notice a speed difference. I can think of one very good reason for doing this for a very compact and fast emulator...

[StevenJGore]

It's not as if WinUAE is slow anymore though? It's been faster than WinFellow for a couple of years now. WinUAE 0.8.27 is close to perfection, IMHO, in terms of speed, compatibility, and stability. Why bother with another emulator? Wouldn't it be better to concentrate all efforts on just one, given the gradually shrinking size of the Amiga community?

Steve.

[carfesh]

Well, we ourselves thought of many reasons to do so

Coding in assembler doesn't make a program faster; modern C compilers do lots of different optimizations so you won't necessarily notice a difference, as long as your coding style is not too disastrous.

Porting to C makes the code more readable, debugable, and allows for easier addition of new features. We already fixed several older inherent bugs in WinFellow, some of which only became visible after porting to C, we really only hope to be able to produce an even more stable and efficient emulator.

We're doing everything we can to make sure the changes we make don't have any negative impact on speed. The benefits far outweigh that possible disadvantage.

[Toni Wilen]

Originally Posted by carfesh

We're doing everything we can to make sure the changes we make don't have any negative impact on speed

Say good bye to working CAPS-image support (copy protection code) then

[carfesh]

I was talking about the conversion from assembler

Complete CAPS support will require some changes to the floppy emulation we're really hesitant to make, since they will result in considerable slowdowns. That's why it's still experimental, and probably will remain for some time. Many titles work, but variable cell densities require a timing process we'd like to avoid to introduce into WinFellow.

[mtb]

Originally Posted by carfesh

That's right, we're again actively making changes to the Winfellow CVS repository. WinFellow filesystem code has been updated to the UAE 0.8.22 codebase, several bugs have been fixed, though some incidents also have been closed because they couldn't be confirmed by us and were ages old, and conversion of parts of the assembler code in WinFellow to C have also been done. I also recently added some very basic (and still pretty experimental) support for CAPS. I have a list lieing somewhere...

We're right now in the process of evaluating if we have enough changes to do a new release, so stay tuned, I'm eventually going to set up some beta-testing and see if we can do something

Kind Regards,
Torsten

Glad to have an official reply , and to see that winfellow is not death, even if i have moreless abandoned windows i'll try to experiment with wine and the last release i have on the hd .

[Kodoichi]

Originally Posted by StevenJGore

Why bother with another emulator? Wouldn't it be better to concentrate all efforts on just one, given the gradually shrinking size of the Amiga community?

Yeah, how come there are so many emulators for the same system (see SNES, NES, Mega Drive...)? I only want one for each system.

And while we're at it, why should we still use MacOS, Linux and whatever stupid OS's there are? Windows is fine, why bother with others?

[Worfje]

Hi all,

I guess we can't hide anymore

originally posted by mtb
Seems that he wants to change the gui, import the uae filesystem and convert some assembler to c.

We started working on WinFellow again from april this year. We converted 5000 lines of assembly code to C, which is almost 20% of the total. It is a slow and tedious undertaking, but very nice to do. No drastic changes to the GUI. Carfesh already stated the other changes.

originally posted by andreas
The reason of some of the closures escapes me, though

I closed down one or two bug reports because I expect them to be outdated. If some of these closures are unjust, please let me know!

originally posted by Big-Byte
Why change the assembler code back to C ? wont that make it slower.. ? Winfellow was my fave for a long time cause it was so fast on low end PCs.

There are several reason for converting the assembly code to C. It will make the code readible again and thereby making it easier to find bugs, fix bugs and add features. It would also make Fellow (the emulation core of WinFellow) processor independent. Currently, Fellow can only run on x86 processors, due to the used assembly code. We don't expect WinFellow to be slower when all code is converted to C. On the contrary, it may be even faster, as Carfesh explained already.

Greetings!

Originally Posted by Worfje

Hi all,

I guess we can't hide anymore

<cut>

There are several reason for converting the assembly code to C. It will make the code readible again and thereby making it easier to find bugs, fix bugs and add features. It would also make Fellow (the emulation core of WinFellow) processor independent. Currently, Fellow can only run on x86 processors, due to the used assembly code. We don't expect WinFellow to be slower when all code is converted to C. On the contrary, it may be even faster, as Carfesh explained already.

Greetings!

This is really interesting, but i would like if possible know what are the plans for the future ( e.g. ports to other os or only a better and portable emulation core always staying within the windows environment, with the possibility to use the core in other ports not done by your team but feasible since winfellow is gpl )

[carfesh]

This is really interesting, but i would like if possible know what are the plans for the future ( e.g. ports to other os or only a better and portable emulation core always staying within the windows environment, with the possibility to use the core in other ports not done by your team but feasible since winfellow is gpl )

Right now there aren't any concrete plans for that, but one of the reasons for the conversion to C is portability, yes.

On my personal agenda I would like to support or maybe even myself do a PocketPC port one day, since I'd love to be able to use Fellow on my iPAQ; the PocketPC port of ScummVM showed me that PocketPC really is a performant platform for multimedia applications, I've been playing Sam&Max on my iPAQ during my vacations sitting in the sun - I'd love to do the same with Fellow.

That's why I'll also evalute the use of SDL in WinFellow (which BTW xFellow already used, that might be usable for WinFellow also); but that's pretty long term and we'll have to see about that.

You should note though that this is my personal agenda; don't know if the team has other plans, but the general idea is known there

[mtb]

Originally Posted by carfesh

Right now there aren't any concrete plans for that, but one of the reasons for the conversion to C is portability, yes.

On my personal agenda I would like to support or maybe even myself do a PocketPC port one day, since I'd love to be able to use Fellow on my iPAQ; the PocketPC port of ScummVM showed me that PocketPC really is a performant platform for multimedia applications, I've been playing Sam&Max on my iPAQ during my vacations sitting in the sun - I'd love to do the same with Fellow.

That's why I'll also evalute the use of SDL in WinFellow (which BTW xFellow already used, that might be usable for WinFellow also); but that's pretty long term and we'll have to see about that.

You should note though that this is my personal agenda; don't know if the team has other plans, but the general idea is known there

I have just tried both xfellow 0.0.4a and the last winfellow 2001/11/15 under wine.

I can say that i have been unable to run the first ( a lot of segfaults even without gcc optimization ), but the second one under wine works well ( the "only" problem is that i can't use the joystick ( wine limitation afaik ) and that the keyboard doesn't work, only the mapped joystick with the arrows works ).

Maybe when it'll be ported to C you can take a look at libwine to compile it for other platforms ( when i'll find some time i'll read the docs ).

With Winfellow, I can emulate the Amiga on a Sony C1VFK, because this processor is low, only Winfellow work fine on it (90% of CPU and 95% on C1VE). With this, I
have today the smaller Amiga of world, thanks Winfellow !

This computer work with a crusoe processor capable of translate X86
codes, and perhaps 68K codes in future !?

You can visit my webpage (the link is my name !) of the Sony Vaio C1 computer

My suggested project for develloppement of Winfellow is:

- Support of 1024x480 and 1280x600 resolution screen (Widescreen)
- Support of crusoe processor
- Support of AGA
- Snapshot memory for save games and restituate these later

WinUAE is too slow on my machine and don't emulate perfectly an Amiga (true interlace screen, speed chipset, ...)

true interlace screen

You mean a flickering screen? Surely we don't need that.