Ultimate Amiga
Other => Ultimate Amiga Site News and Announcements => Topic started by: Hungry Horace on February 07, 2012, 05:27:05 PM
-
I'm happy to be able to report that there appears to be a new Amiga emulator on the scene....
Norwegian Developer FrodeSolheim, has announced a new amiga emulator called "fs-uae" - its is beased on the previous UAE and WinUAE developements, but is focused on being both multi-platform (great news for OSX and Linux users) and being usable entirely via a Controller-driven Graphical User Interface, much like PSPUAE.... This should make it ideal for anyone looking to run UAE on a media-centre dedicated PC.
There is, of course, the drawback (or advantage?) of the emulator being less option-driven than it's WinUAE / PUAE counterparts, but I will certainly be interested in giving this a try on my MacMini.
You can find binaries and further info on the website: http://fengestad.no/fs-uae/
-
Should I get a group of people together and get them to implement some kind of online functionality. :D
-
I could never get it working, instructions are'nt that clear.
@Skate, bloody hell, where did you spring up from, :).
-
I could never get it working, instructions are'nt that clear.
Even in it's fuirst week, there have already been several revisions.
I will be giving it a try tonight I hope...
-
There is, of course, the drawback (or advantage?) of the emulator being less accuracy / option-driven than it's WinUAE / PUAE counterparts, but I will certainly be interested in giving this a try on my MacMini.
Hi there! fs-uae author here. I wrote the description on the home page in a hurry, and it seems the text was misunderstood a bit. fs-uae only enables the most accurate emulation modes from WinUAE (cycle-exact emulation). With regards to options, the point is that I wanted to limit options to the most useful, to have fewer configurations / combinations to test (not having to support an "Amiga 1200" but with OCS chipset etc.)
Just wanted to clarify :)
(EDIT: I also updated the description on the homepage)
-
I could never get it working, instructions are'nt that clear.
I will admit that the instruction were written last-minute ;) Please let me know what part you got stuck on, an I can improve the instructions.
-
Hi there! fs-uae author here. I wrote the description on the home page in a hurry, and it seems the text was misunderstood a bit. fs-uae only enables the most accurate emulation modes from WinUAE (cycle-exact emulation). With regards to options, the point is that I wanted to limit options to the most useful, to have fewer configurations / combinations to test (not having to support an "Amiga 1200" but with OCS chipset etc.)
hi FrodeSolheim! Great to have you at our forum - I hope you will be willing to take comments and feeback from here too :)
I have taken your clarification on-board and adjusted the first post.
I understand you are working on HD support? I hope this will include the option to mount two HD folders for one Game-Setup? I tend to favour having a generic "first disk" and then having a set of game-files (WHDload) in the second disk... this way i can get all the benefits of WHDload installs (like saving high-scores, bugfixes, joypad support etc) but also keep the games set-up for a single-click system, like fs-uae seems to use, without duplicating files such as WHDload and my keyfile for every single game.
Good luck with this great project!
-
hi FrodeSolheim! Great to have you at our forum - I hope you will be willing to take comments and feeback from here too :)
No prob. I have marked this thread for notifications, so I will answer questions popping up here :)
I have taken your clarification on-board and adjusted the first post.
Great!
I understand you are working on HD support? I hope this will include the option to mount two HD folders for one Game-Setup? I tend to favour having a generic "first disk" and then having a set of game-files (WHDload) in the second disk... this way i can get all the benefits of WHDload installs (like saving high-scores, bugfixes, joypad support etc) but also keep the games set-up for a single-click system, like fs-uae seems to use, without duplicating files such as WHDload and my keyfile for every single game.
Yes, I just started looking at it tonight - does not work so far, but I usually get things working eventually :) Your setup makes sense, so I will definitely take that into account. I have actually never used hard drives with Amiga myself, neither on real hardware, nor in emulation. But I see that WHDload-games etc would fit in with fs-uae's goals. But don't worry, I will make sure I support at least two drives :) (do you use virtual folders, or disk images btw?)
-
Your setup makes sense, so I will definitely take that into account. I have actually never used hard drives with Amiga myself, neither on real hardware, nor in emulation. But I see that WHDload-games etc would fit in with fs-uae's goals.
given fs-uae's "target" (i'm thinking like "Amiga MAME Cabinet") I think you would really appreciate the extra features added to some games via WHDload, such as HighScore Saving, basic bugfixes (such as fixing the colour palette on Midnight Resistance!) and full control of games via a CD32 Pad setup.
But don't worry, I will make sure I support at least two drives :) (do you use virtual folders, or disk images btw?)
I always opt for virtual folders if i can, because it makes it far easier to add the latest WHDLoad patches when they are released, without needing to re-install the entire game.
-
I always opt for virtual folders if i can, because it makes it far easier to add the latest WHDLoad patches when they are released, without needing to re-install the entire game.
I have just managed to make both hard drive files and virtual folders work :) -Logging off now, will probably make another release with preliminary HD support tomorrow evening.
-
I always opt for virtual folders if i can, because it makes it far easier to add the latest WHDLoad patches when they are released, without needing to re-install the entire game.
I have just managed to make both hard drive files and virtual folders work :) -Logging off now, will probably make another release with preliminary HD support tomorrow evening.
I will have to a take another look, proberly this weekend.
Im currently setting up MicroA1 for OS4.1 coding. So just aint got time as yet.
-
i finally managed to get fs-uae running, by putting the kickstart file into the same folder as the program.
I am sure it is ignoring my config file though. I have specified;
[application]
## You can override the title displayed in menu mode
title = "first test"
## You can also override the sub-title displayed in menu mode
sub_title = more test
but neither show in the menus.
i also have the following, which is meant to look on a USB stick called "gaming"
rom_dir = /Volumes/GAMING/AMIGA/Roms/
I have been using TextEdit on OSX (10.6.7) and saved with the.utf-8 format.....
EDIT: it seems i can only get it to load fs-uae.conf without using command line...
Will the option to load .conf files from directly be in the emulator be added?
Will you be adding full Joypad-remapping, so that we can set up four joysticks using Parrallel-Port Joysticks, for example (i.e. to play Gauntley 2 with 4 PS3 pads) ... or allow keyboard mapping to the joysticks? This would allow endless possiblities within the configs, and really eliminate the need for anyone to ever use a keyboard ever again!
-
i finally managed to get fs-uae running, by putting the kickstart file into the same folder as the program.
I am sure it is ignoring my config file though. I have specified;
[application]
## You can override the title displayed in menu mode
title = "first test"
## You can also override the sub-title displayed in menu mode
sub_title = more test
but neither show in the menus.
i also have the following, which is meant to look on a USB stick called "gaming"
rom_dir = /Volumes/GAMING/AMIGA/Roms/
I have been using TextEdit on OSX (10.6.7) and saved with the.utf-8 format.....
Hi
Yes, it looks like it is ignoring it. If you run fs-uae.app by clicking on it, there are a couple of valid locations for the config file (see the README). but basically /Users/yourusername/.config/fs-uae/fs-uae.conf
If you start from a console, you can specify the path to the configuration file by running
fs-uae.app/Contents/MacOS/fs-uae -c /path/to/config/file
One of the things I am working on is better feedback when fs-uae does not find things - an on-screen error display (for instance, "could not find config file at <location>". This will make it a bit more user-friendly.
Btw, where did you put your config? could post here the path to the config file (and the path to fs-uae.app)? If you thought your current setup should work, this indicates that I should either fix the documentation, or even better, look for the file where you put it (that's why I wanted to know the path).
-
Version 0.9.6 released:
* Support for hard drive images (hdf)
* Support for mounting virtual folders as hard drives (experimental)
* Bugfix in calculation of save location of overlay adf files
* UTF-8 is now used internally in libamiga also on Windows, and
text is converted to other character sets / encodings as needed.
This enables support for non-ASCII characters in paths on Windows.
* Added a copyright notice at startup crediting the original WinUAE,
E-UAE and PUAE authors, and added a more prominent notice in the start
of the README.
Source code and binaries for Windows, Mac OS X and Linux are posted here:
http://fengestad.no/fs-uae/
-
@ FrodeSolheim
i think you can ignore my comments about it not finding the config file.
I had expected that when i clicked on a ".conf" file, and selected "open with... fs-uae" that the config would be opened. I now see that I need to give it jsut the one file in a certain location (the program folder is fine)
I think i would still like to see a Config browser, and editor, for OSX though!
Also, any thoughts on my comments about joystick/keyboard/port 3-4 mapping etc?
-
i think you can ignore my comments about it not finding the config file.
I had expected that when i clicked on a ".conf" file, and selected "open with... fs-uae" that the config would be opened. I now see that I need to give it jsut the one file in a certain location (the program folder is fine)
No, you made a good point. Why shouldn't you be able to open a config file with fs-uae -or drag and drop a config file on top of fs-uae for that matter. I have fixed this already, so the next version will support this.
I think i would still like to see a Config browser, and editor, for OSX though!
I am not likely to create a configuration editor - I do not think it is worth the time (i.e. I would rather make other features) :-\ -But of course, anyone can create a configuration front-end without my involvement.
As for configuration browser, I do not plan for fs-uae to become a "game center" for amiga games (I have a separate project for this ;-)). Having a simple on-screen file browser for selection a configuration file wouldn't be stupid though - it could help people get started since they would not have to put the config file in exactly the right place etc. I'll think about it.
Also, any thoughts on my comments about joystick/keyboard/port 3-4 mapping etc?
I haven't played Gauntled II 4-player -but if I understand you correctly (plus a little guessing), it can be played on the Amiga with two players having one joystick each, and the last players using separate sets of keys on the Amiga keyboard?
Yes, I think mapping options such as you suggest could be appropriate for fs-uae, for cases like these. I have to think a bit on how it should be configured. I'll put it on the wishlist :)
I am more likely to first implement another feature which has been suggested: An on-screen keyboard for pressing keyboard keys once in a while (say "Escape" to exit a level) from a game pad.
-
Acutall, Gauntlet II is the "exception" in that it uses the parallel port joysticks for Players 3/4 (sometimes called "Par Joy 0 / Pat Joy 1") ... these only support up/down/left/right and single fire button each, and so usually need to be supported by some keyboard keys as well, for any additional functions (e.g. casting magic in Gauntlet II) .... it's a feature that does appear on WinUAE and E-UAE though.
The keyboard mapping I find helpful for games like Pinball Dreams (the original) which did not have CD32 versions, and therefore cannot be played on joystick alone, but do quite suit being played via a joypad.
Perhaps i should post an example (video?) of how this is managed on PSPUAE, where you have the similar problem of trying to set-up multiple control-types with only a joypad input to control it from!!
I am glad you are adding an OSK - this was also found very helpful with PSPUAE!
Also i am glad you have taken on-baord the comments about the Config browser - this would suit me to the ground, as I am likely to "auto-script" a lot of my .conf files anyway, so this is certainly more important for "casual users" than the config editor.
Keep up the great work fs - this project is very exciting!
-
Acutall, Gauntlet II is the "exception" in that it uses the parallel port joysticks for Players 3/4 (sometimes called "Par Joy 0 / Pat Joy 1") ... these only support up/down/left/right and single fire button each, and so usually need to be supported by some keyboard keys as well, for any additional functions (e.g. casting magic in Gauntlet II) .... it's a feature that does appear on WinUAE and E-UAE though.
Good description, now I get it :) -I had noticed parallel port joystick emulation in the WinUAE UI, but did not really know what it was used for.
The keyboard mapping I find helpful for games like Pinball Dreams (the original) which did not have CD32 versions, and therefore cannot be played on joystick alone, but do quite suit being played via a joypad.
Perhaps i should post an example (video?) of how this is managed on PSPUAE, where you have the similar problem of trying to set-up multiple control-types with only a joypad input to control it from!!
I understand what you mean.
I have also gotten a feature request for online multi-player functionality (well, I think this was the request). -Had no such plans, but thinking about it made me a bit interested (at least enough to try creating a simple prototype at some point). Anyway, this requires modifications to the input event code, so I am going to rewrite the input handling system to allow for:
- input event synchronization between multiple clients
- generic mapping of input events
- on-screen keyboard
-
I have also gotten a feature request for online multi-player functionality (well, I think this was the request). -Had no such plans, but thinking about it made me a bit interested (at least enough to try creating a simple prototype at some point). Anyway, this requires modifications to the input event code, so I am going to rewrite the input handling system to allow for:
- input event synchronization between multiple clients
- generic mapping of input events
- on-screen keyboard
Wow! My heart just skipped a beat! We have a section of this forum dedicated to online play via winuae-kaillera but with that not being developed anymore, I had given up hope of ever having online Amiga play ever again!
How brilliant to know you are considering it, and across multiple platforms too... fs-UAE is fast going up in the world!
Good luck with it all, and I will try my hardest I give useful input where I can!
-
Awesome. I would donate to help motivate you to do the online stuff. :)
Maybe get in touch with the guy who created winuae-kaillera and ask him how he did it and for any advice he might have.
-
How brilliant to know you are considering it, and across multiple platforms too... fs-UAE is fast going up in the world!
Good luck with it all, and I will try my hardest I give useful input where I can!
Awesome. I would donate to help motivate you to do the online stuff. :)
I'm more short on time than on money, so this would probably not help :) -Also, I'm not promising anything! What I need most help with is actually testing FS-UAE -not the online stuff (yet), but everything else. No point in online play if there are bugs in the basic functionality :)
Maybe get in touch with the guy who created winuae-kaillera and ask him how he did it and for any advice he might have.
That might not be necessary. I did some prototyping yesterday evening (well, early night anyway), so during 6 hours I got a basic synchronization working across two clients (One on Mac, one on Windows), communicating with a custom game server I made. It actually seems to be working quite good -no input event synchronization yet, but the emulation does seem to be in sync across both UAE instances (after I also synchronized the Amiga battery backed up clock ;-)). I'm developing a custom protocol sending a reasonable minimum amount of data back and forth, but haven't tried in over the Internet yet (only on LAN).
Well, anyway, looks promising (based on limited testing).
-
Networked play is actually working now! I have rewritten the input system, and extended the netplay system to synchronize input events across clients. I tested playing Pinball Dreams across three computers at the same time :) (a Windows, a Mac and a Linux box, even). I have played several sessions without de-sync, but have also gotten one session out of sync, which means that synchronization of the emulation is not 100% stable (yet).
I have also tried running the fs-uae-netplay-server on the server running fengestad.no, with two fs-uae clients connected. Performance seems fine, with a (roundtrip) time of 25 ms to the server.
-
hmm, how would one resync on the fly if a desync happens? Or create a more stable sync? I just can't figure it out.
If a game used a random number generator, how do both games randomise the same number or would those game just not be playable online?
-
hmm, how would one resync on the fly if a desync happens?
Short answer: You wouldn't! But one way would actually be to let one client perform a save state, transfer this save state to the other clients, and reset the emulation. Currently, desync isn't even detected. The emulations run independently from each-other -apart from having frame output and input events synchronized. One could perhaps checksum the amiga memory content and send this checksum to the server. -Then the server should be able to detect most desyncs by comparing the checksums from all clients.
Or create a more stable sync? I just can't figure it out.
If things are working as intended, the emulations should get out of sync at all. When I got the desync, I had full vsync-mode on one of the clients. Vsync mode does have a bit separate code-path in some of the UAE code, so it is possible that this could be the culprit. After I switched both clients to the same video sync mode, I have not been able to get a desync.
If a game used a random number generator, how do both games randomise the same number or would those game just not be playable online?
Random number generators are not truly random. They either need a seed value (often the current time), or read other random data from an external source (for instance a microphone). I synchronize the (emulated) battery-backed-up Amiga clock so that all clients will agree on the time. Also, input events are synchronized.
Here are some conditions which must be fulfilled for synchronization to work 100%:
- Input events must be applied in the same order, and in the same "emulated time" on all clients [done]
- The clients must not be allowed to drift too much from each other (in emulated time) (well, really more of a lag issue) [done]
- Clocks and other inputs which can be read from the Amiga must be synchronized [clocks are synchronized]
- There must not exists bugs in the synchronization
- The emulation itself must be deterministic / stable given the same inputs. If there are random factors involved, those must be either removed, or synchronized across clients. Subtle bugs / differences in emulation could also occur when running on different processor architectures (x86 vs x86-64) if the emulation code is not "perfect".
The question is: are there other random factors involved? I see for instance in disk.cpp:update_jitter that UAE uses random numbers in disk procedures, and this could affect emulation.
-
this makes for some really interesting reading!!!
Some questions I can think of....
- How will you ensure if (for example) you have HD-Folders in the setup, that you have the same files on each side? Run a check on startup, or check files exist as-you-play and then abort if something is missing on one side?
- How will you determine which side has control of which joysticks/keyboard inputs? will one side have control of certain inputs, and "allow/block" the other side to determine the remaining? Or will you just leave it to the people setting up the configs to arrange it in a fair manner?
- I noticed you mentioned a 25ms ping via the server method - these seems pretty good to me from previous experience with winuae-kaillera, but will you be adding a P2P method as well?
Just a few thoughts I had!!
Very excited about this. Just going to try making some auto-scripting of config files here....
-
this makes for some really interesting reading!!!
Yes, it is a quite interesting challenge :)
- How will you ensure if (for example) you have HD-Folders in the setup, that you have the same files on each side? Run a check on startup, or check files exist as-you-play and then abort if something is missing on one side?
Currently, this is not checked. I would call what I have now a (fully working!) prototype. A final version could either:
- assume that everyone has the same files (all persons could for instance unzip the same zip file)
- the client could create a checksum of the entire content before starting, an refuse starting if the content differs
- the client could in theory synchronize the contents (much more work, but simple to do).
- How will you determine which side has control of which joysticks/keyboard inputs? will one side have control of certain inputs, and "allow/block" the other side to determine the remaining? Or will you just leave it to the people setting up the configs to arrange it in a fair manner?
Currently all input events can originate from any client, and will propagate to all clients. That is, everyone can press keyboard keys and and joysticks/mouse should be handled by one player using joystick_port_0 and the other joystick_port_1. It would not be very difficult to later configure the server/game with rules concerning who gets to send which types of input. One could in theory give on player control of a specific set of keyboard keys and another player could control the rest. As I said, this is definitively not rocket-science, but I will not do this for the prototype.
(For now, it works just fine if all players agree on who controls what).
- I noticed you mentioned a 25ms ping via the server method - these seems pretty good to me from previous experience with winuae-kaillera, but will you be adding a P2P method as well?
P2P will add much more complexity without any real gain. One cannot compare "UAE netplay" to another game designed for multiplayer.
Games designed with multiplayer in mind can broadcast UDP events without guaranteed delivery, and the game can implement logic to constantly keep the game state in sync (e.g. in a FPS, all clients need not get every movement commands, since movement can be predicted based on current speed, and position can be exactly updated when a later game event arrives). The point here is that the game itself can allow missing events, or events arriving out of order, as long as it handles this in some sensible way.
This won't work with the Amiga - if two key presses are applied in the opposite order on two clients, the emulation will get out of sync! This means that someone must order the events - this is done by the server. P2P will just make it more difficult to synchronize, and you will not get the benefits from P2P that other applications can get (Events can be ordered in a distributed manner, but this is much more complex, and probably much slower). The IP traffic required to sync games is actually quite modest - the most demanding cases are mouse event propagation. Low latency is more important than bandwidth.
Regarding the ping. Yes, I tested with two clients locally which both played through a server about 12.5 ms away. In this case, you will get a minimum delay (lag) of 25 ms for input, but in practice more, since the input events also are synchronized to frame events.
I do *not* recommend using wireless network. I tested with one client on wireless, and got more jittering (it still worked properly, and not *BAD*, but significantly less smooth). The problem with wireless is packet loss. Since the synchronization protocol cannot work with missed events, or events out of order, guaranteed delivery is required (fs-uae uses TCP for this). This means that packets *must* be resent when a packet loss is detected, and if a frame confirmation event is significantly delayed (the server allows some slack), this will delay the game for all clients. When testing with ping, I saw that the computer on wireless got rounds trips to the server of either 25 ms (good), but relatively often 50 ms.
Ideal conditions for netplay:
* a server with relatively low latency connections to clients. It would be most fair for all players if everyone's latency is comparable.
* low packed loss rate (avoid wireless if possible and do not saturate the link with downloads / P2P traffic while playing).
Very excited about this. Just going to try making some auto-scripting of config files here....
The upcoming version supports overriding the memory settings (probably needed if in many cases you auto-write configs from another configuration database).
-
- How will you ensure if (for example) you have HD-Folders in the setup, that you have the same files on each side? Run a check on startup, or check files exist as-you-play and then abort if something is missing on one side?
A similar issue is configuration. It isn't difficult to a small group of people to agree on the same files and configuration, but desync bugs caused by unintentional errors can be both frustrating and difficult to figure out.
I plan to create a checksum based on all relevant client configuration and state
* disk files
* kickstart image
* relevant configuration values (amiga model, memory, ...)
With HD setups, the following should also be included:
* HD configuration and file data
* File attributes which can be seen from the Amiga
The server will refuse to start a game if the checksums do not match across clients.
-
The question is: are there other random factors involved? I see for instance in disk.cpp:update_jitter that UAE uses random numbers in disk procedures, and this could affect emulation.
Regarding use of rand() in the emulator itself (such as calculating random jitter in disk emulation), this should be synchronized by seeding the random number generator with the same seed on all clients. Then all clients will generate the same (semi-)random number sequence. Must search/go through all code and make sure all relevant code uses the same random number generator.
-
"Good news, everyone!" (but this really _is_ good news). I have now synchronized random number generation on clients - they use the same algorithm on all platforms, and the seed is synchronized - even more importantly, a bit of UAE code is changed so Windows and other platforms use the random functions in exactly the same places / situations.
To ensure that synchronization is maintained, and subtle bugs do not go unnoticed, the clients send a random number, and a checksum of the contents of the amiga memory for every video frame. The server controls that these matches for each frame across the clients. This is a very powerful control mechanism, and well detect even very subtle out-of-sync-errors which you might not even have notice otherwise.
It is effectively impossible to "prove" that the implementation is correct, but further play testing will give further assurance. I have not been able to get the clients out of sync at all :) -But of course, I haven't exactly been testing for days.
-
FrodeSolheim - i am amazed at the speed at which you have implemented this!!
I am even more surprised that you made this a priority over other improvements/changes to fs-uae... but, you are the author afterall, and you have truly created a landmark in amiga emulation :)
*opens the champagne!*
-
I am even more surprised that you made this a priority over other improvements/changes to fs-uae... but, you are the author afterall, and you have truly created a landmark in amiga emulation :)
I'm suprised myself ;D (it was really at the bottom at the list, if on the list at all :P)
I will probably leave it as an experimental (but working) feature while concentrating on other issues. Later, I can implement improvements to the synchronization protocol (mechanisms to minize lag etc -I have several improvements on the todo list).
A requirement for netplay was a new input system (which is also suitable for custom mapping by the way), but now I will focus on getting this cleaned up for a release. I have several smaller bugfixes and improvements I want to push out.
-
FrodeSolheim - i am amazed at the speed at which you have implemented this!!
I am even more surprised that you made this a priority over other improvements/changes to fs-uae... but, you are the author afterall, and you have truly created a landmark in amiga emulation :)
*opens the champagne!*
I think FrodeSolheim has erned his own section and mod rights to it.
What do you think?
-
Yep, +1 Vote from me.
Ultimate Amiga Emulation->FS-UAE
With a view to an online child board so the multi-player fans can become 12 year olds again. ;D
Ultimate Amiga Emulation->Amiga Online->FS-UAE Online
-
if fs is interested, then yep, that seems a good idea.
just tried out 0.9.6 on OSX, definately needing memory options (i.e. 2 meg chip, 8+ meg z3 ram) for HD games, in order to preload all the data... also awaiting on the clicking-of-.conf file fix to work.
My template loader is now fixed and up-and running, so i may end up uploading my HD bootloader to this website if anyone wants to try it out. :)
looking forward to 0.9.7 already!
-
Version 0.9.7:
* FS-UAE can open configuration files without (-c) parameter, makes FS-UAE.
easier to start with config from graphical shells (Windows Explorer,
Mac OS X Finder).
* Added chip_memory, fast_memory and slow_memory options (see example.conf).
* Fixed bug where save states would not be saved if floppies where specified
with absolute path.
* Fixed problem with opening CUE files on systems other than Windows.
* Fixed audio buffering issues.
* Buffer additional audio data on buffer underrun before resuming playback.
* Fixed problem with renaming files in virtual (mounted) disks on Windows.
* Code cleanup in libamiga, new wrapper functions for some platform-specific
code.
* Support for large HDF files (> 2GB) (untested, and not supported on Windows
yet).
* Better implementation of write_log in libamiga.
* Updated README to clarify that you can use ALT+F11 on Mac to toggle mouse
pointer (since the OS intercepts F11 alone).
* Write information about base WinUAE version to log file.
* Use same random number generator on all platforms.
Downloads:
http://fengestad.no/fs-uae/files/fs-uae-0.9.7-windows.zip
http://fengestad.no/fs-uae/files/fs-uae-0.9.7-macosx.tar.gz
http://fengestad.no/fs-uae/files/fs-uae_0.9.7-0_i386.deb
http://fengestad.no/fs-uae/files/fs-uae_0.9.7-0_amd64.deb
http://fengestad.no/fs-uae/files/fs-uae-0.9.7.tar.gz
-
if fs is interested, then yep, that seems a good idea.
Well, it's no rush, the message volume isn't that large :) -but I would read and answer posts in such sub-forums.
just tried out 0.9.6 on OSX, definately needing memory options (i.e. 2 meg chip, 8+ meg z3 ram) for HD games, in order to preload all the data... also awaiting on the clicking-of-.conf file fix to work.
Both features are out now :)
EDIT: Actually, there is no z3 RAM setting, because FS-UAE does not allow to choose an Amiga model with 32-bit addressing mode (well, currently, anyway). You can configure z2 fast now. What other configuration options do you use with z3 RAM? An "Amiga 1200", but with 68020 instead of 680ec20?
-
EDIT: Actually, there is no z3 RAM setting, because FS-UAE does not allow to choose an Amiga model with 32-bit addressing mode (well, currently, anyway). You can configure z2 fast now. What other configuration options do you use with z3 RAM? An "Amiga 1200", but with 68020 instead of 680ec20?
I was just going on the previous Hi-Toro / E-UAE settings, where fast-ram only went up to 8meg, and to have any more than that required setting Z3 ram (from 0->512meg).
I tend to always use a "normal" 020 / 030 rather than any EC version for exactly that reason.
Perhaps, where you select A500 / A1200 mode, you could just have an "enhanced a1200" option , with an 030 or 040 and 64 meg of fastram or something like this?
This would save adding too many options back into the emulator itself.
looking forward to testing this new release out :)
-
I think the ideal setup is an 030 with around 64MB RAM.
Alot of users just want to emulate a HDD for WHDLoad gaming.
@FrodeSolheim
If you need any info on stuff I have learnt over the years in regard to increasing speed.
Let me know.
-
I have also gotten a feature request for online multi-player functionality (well, I think this was the request). -Had no such plans, but thinking about it made me a bit interested (at least enough to try creating a simple prototype at some point). Anyway, this requires modifications to the input event code, so I am going to rewrite the input handling system to allow for:
- input event synchronization between multiple clients
- generic mapping of input events
- on-screen keyboard
Yes it was me, and yes you understood correctly it was for net-play/online multiplayer! Can't wait! Amiga scene will see a whole new life and FS-UAE will now be at the forefront after many years of WinUAEXP ...
-
welcome to the forum lesta_smsc :)
be sure, we will be jumping on the Online potential of fs-uae here at Ultimate Amiga, as previously I had spent a lot of time trying to make the best out of of WinUAE-Kaillera but with frustrated efforts!