UAE4ALL for Symbian

[finkel]

Hi everyone.

I am currently trying to add some of the missing features into UAE4ALL port for Symbian phones. I was very pleasantly surprised when I saw my favorite games run with 30fps (only with sound disabled, unfortunately, it's more like 15fps with sound enabled), so I decided to give it a try.

Hard disk support was the first on the list, so I've spent last 2 weeks porting bits and pieces of PocketUAE code (which has disk support, both for native file system and HDF files) into UAE4ALL. Fast/bogo memory, 68020 and AGA support are next on the list, but it's still early to even consider going there right now.

Anyway, after some struggling with byte-ordering and FAME core stuff, and a big, big help from watching & debugging WinUAE 1.45 (which was the only version I could compile), I've finally reached a phase where my virtual hard disk boots, and both Workbench 2.1 and 3.1 work (almost) perfectly.

I now have some games installed on my virtual Amiga HD, some of which work perfectly (Darkseed), some that work partially (Syndicate, Hired Guns), and some that don't work at all (too many to name).

My problem is the following...

Games that don't work, don't work only if I start them from HD. If I mount a floppy, and run them from there (Altered Destiny, for example), they work perfectly.

Those that work partially have everything right, except for, what I believe to be, sprites. Background images are OK, but sprites seem to be completely messed up. Just some junk graphics where something meaningful should be.

My guess is that all of the problems are caused by incorrect synchronization between hard disk access and custom chipset, but that's just a guess, since I am not that familiar with Amiga chipset functions and timing. Got some books to read the hardware reference from, but due to time constraints (full time job), that's like the last resort right now.

I'm gonna find out what's causing these graphics glitches (and freezes/crashes), but it's probably gonna take plenty of time, 68K instruction tracing, memory dumping, and who knows what else...

So, anyone with experience in porting UAE, any UAE, can give me some direction in which I should be looking for a fix?

Anyone has ever had similar kind of problems with HD access and graphics glitches/freezes?

[Toni Wilen]

I don't see how HD accesses can cause these kinds of problems.

Does it work if you run the game from RAM disk? (boot with HD config, copy game exe and data to RAM:)

Any change if you use Chip-RAM only configuration?

[finkel]

Thanks for a quick reply.

I've tried to copy something to RAM disk, but was immediately greeted with a message that RAM disk is full. :) But that's OK. I get "not enough memory available" message in WinUAE as well, so I prefer not to get involved in that subject right now. :)

UAE4ALL for Symbian only supports chip RAM, so that's not it either. I've set both test configurations, in UAE4ALL and in WinUAE, to:
- 2MB chip RAM (no slow, no fast),
- Kickstart 3.1,
- Workbench 2.1, and
- identical hard disk content

What I find very interesting is that if I run Hired Guns directly from HD, I get that graphical garbage on screen. But if I run it from floppies (inserted after Workbench has booted from HD), and run it from there, everything looks just fine.

Here are some pictures for comparison:

HD run
http://i36.tinypic.com/33tie8j.jpg

Floppy run from HD-booted WB
http://i35.tinypic.com/2qisr9l.gif


It's one mighty strange problem to tackle.

You may also notice that vertical stripe on the left, of (presumably) XOR-ed data. It appears in WB as well, and I haven't been able to figure out why.

I am definitely missing something out, and it seems that only a long and thorough debugging session will reveal what it is. If I get stuck, I'll just move on to some simpler stuff, like turning slow and fast RAM back on. All the code seems to already be there, with values simply hard-coded to 0. :)

[Toni Wilen]

Can't you enable >2M chip ram option (4M or 8M) and try RAM: copy again?

[finkel]

OK, changed chip RAM to 8MB.

Well, who could've thought that a simple copy to RAM would produce... complete garbage. :)

http://i35.tinypic.com/2pyvmf8.gif

Some icons are now completely messed up, both those in RAM and on HD (those which are cashed in memory, I guess), and, of course, the game doesn't even start.

This is starting to look like a bug with memory handlers.

Thanks for your help. I have something concrete to chew on now. :)

[finkel]

... or, maybe, it's DOS packet buffer overflow?

Man, it feels great to have some meaningful places to look for bugs. :)

[Toni Wilen]

Where can I download sources? I can quickly check most obvious places.

[finkel]

I haven't set up any on-line version control, so file hosting will have to do the job.

http://rs526.rapidshare.com/files/415675025/uae4all.rar
(mirror) http://www.fileserve.com/file/2DCkGpp

Please, don't waste too much time on it. It makes me feel somewhat uncomfortable to have someone do my work for me, so don't take it too seriously. It's more of a pet project for me. I had Amiga 500 from 1990 till 1998, and working with it again brings back the happy memories. :)

I really appreciate your help, regardless of whether you actually find something or not.

I will have to warn you, though. If you haven't worked with FAME core , it's a bit of... tricky. :)

Due to byte-ordering requirements (Cyclone 68K engine for ARM has the same requirements), I had to put in some stuff that makes sure that access to odd addresses and reading/writing of odd-length data works in all the cases I've encountered so far. However, I can't guarantee that I've checked every single corner of the code. It probably doesn't cause this particular problem, but it's good to keep in mind.

[Toni Wilen]

I am not going to touch CPU emulation, I don't want to :)

Attach also a log file that includes possible messages when garbage appears.

[finkel]

Do you mean debug messages and log file? I think that all DEBUG macros are defined as empty, so there are no log messages to look at. There are no messages in DOS either.

One thing I've noticed is that icon corruption happens when somewhere around 490KB of RAM disk has been filled. That's suspiciously close to 512K, so I'm starting to suspect some memory wrapping/masking going on, but I won't be able to take a serious look at it until tomorrow.

[Toni Wilen]

Do you mean debug messages and log file? I think that all DEBUG macros are defined as empty, so there are no log messages to look at. There are no messages in DOS either.


log file (write_log() functions). I really recommend redirecting write_log() data to a file, it might have some interesting messages..

[finkel]

I will most certainly turn logging on, but in the meanwhile, I've wrote some tracing routines of my own, and guess where that tracing has led me to?

After days of backtracking icon data, with all the reads and writes back and forth throughout chip memory, the final memory breakpoint that revealed the big secret was hit, and I found myself in the completely unfamiliar forest of... blitter functions. :)

Specifically blitdofast_a(), which uses CHIPMEM_WGET/CHIPMEM_WPUT macros to access chip memory. Just as I suspected, that access is masked to the lower 1MB.

Naughty, naughty & ~0xfff00000 mask. :)

I've just changed it to work with 8MB chip ram, and I'm proceeding with my quest through the jungle of yet more unfamiliar, and now much more hostile-looking, code. Hope I won't get tripped on another trap like this, but one can never tell.

Btw, don't mind my writing style. It's just a professional deformation after years and years of playing RPGs and adventures on the good ol' Amiga - the best machine that ever was. :)

Thanks again for all the help. If you don't hear from me again, it's either because I've got everything working perfectly... or I've finally given up on the whole matter. :)

[finkel]

OK...

Got all of the following working as expected (that is, with no visible bugs):
- chip memory up to 8MB,
- native file system mounting (had to put in some simple my_rmdir() implementation) and HDF file (no problems from the start),
- slow memory (will most probably limit it to 1MB)
- fast memory up to 8MB (but will most probably limit it to 4MB, since 8MB causes some problems with WHDLoad)

This is slowly starting to look like a proper HD-enabled Amiga emulator for Symbian. Especially since WHDLoad seems to be working flawlessly with 2MB chip / 2MB fast memory combination. Tried several games in the emulator, and they were working perfectly. Combined with a bluetooth mouse and keyboard, this is going to be a true Amiga-in-a-phone. :)

The only things left are adding a new menu window with all the new options, and...

... solving that mystery of the vertical xor-ed strip on the left side of the screen.

It's more of annoyance than a serious bug (it vanishes in most games), but I'd like to get rid of it if I can, so I'll welcome any suggestions.

For now, I've located some of the paths the screen data goes through:

- drawing.cpp : pfield_doline_n2(), with some heavy crunching of bits going on, and I get completely lost there. Probably not the right place to start looking.

- custom.cpp : long_fetch_ecs macros and functions, where both fetched[] and line_data[] are read and modified. I have no idea which one I should follow, and it feels like I'm just going around in circles.

- custom.cpp : do_playfield_collisions and do_sprite_collisions(), which seem to be the best candidates for bug-hunting, but I'm not sure.

Do you have any idea where I should start looking for the very first modification of screen data before all of the above bit-crunching starts?

Or, even better, where the heck is hiding that vertical "sprite" that's messing with my screen? :)

[Toni Wilen]

- fast memory up to 8MB (but will most probably limit it to 4MB, since 8MB causes some problems with WHDLoad)


Which means something is broken in 8M option..

Or, even better, where the heck is hiding that vertical "sprite" that's messing with my screen? :)

Does it change if you disable SPEEDUP define in custom.c? (display emulation will get much slower so this is only useful for debugging)

If it is still visible: does it disappear if you keep SPEEDUP disabled and clear fetched[] in fetch() (disable chipmem_wget()). Note that this blanks the display. If garbage still does not disappear: beginning_of_plane_block(), reset_decision() not clearing todisplay or something wrong in drawing.c

It does have anything to do with collision stuff.

[Anotherguest]

This looks like very nice UAE4ALL Symbian updates indeed. I have just updated the code to the latest Pandora version, cleaning up menus and adding volume control etc. So getting hard drive support in that would be very nice.

I will upload the source so you can base your work on that. :-D (later this evening or tomorrow)

Cheers
AG

[finkel]

Which means something is broken in 8M option..

No, not really. I forgot to mention that WHDLoad, or at least the version I have, doesn't work with 8MB fast memory in WinUAE either. WinUAE 1.45 that is. Haven't tried with the latest version, but I think that everyone will be able to survive with "just" 4MB fast memory. :)

For the rest of the places to look in, it's been a busy week at my work, so I haven't had a chance to dive in the problem. I'll take a look over the weekend. That screen garbage has suddenly jumped to the top of my list. It's messing with Lemmings 1, and no one messes with Lemmings. :)

[finkel]

I will upload the source so you can base your work on that. :-D (later this evening or tomorrow)

Cheers
AG
Hey, that's great news! I've just finished all the changes I had in mind to do (except for that screeny mess, which promises to be a royal pain-in-the... ahem), and wrote a readme file with change log. I was planning to archive it all, UAE4ALL project and all the dependencies (header files and libraries), and send it to your email tomorrow. You beat me to it. :)

I will still send you the archive before I start comparing your changes to mine. It's better to have some kind of backup, just in case my computer blows up, or something. :)

There are some details I still have to check on, but you can expect the archive by tomorrow.

[andreas]

Fast/bogo memory, 68020 and AGA support are next on the list, but it's still early to even consider going there right now.
Depends on viewpoint.
Though 020/AGA could wait: for bogo mem support, it can't be early enough.

That's why it was a great idea to tackle this task now.
Well done! :great
(many ancient disk-based games - mainly scene releases - will break if you have chip-only support; they MUST have their >= 512K bogo mem area, which they might even address in absolute (!!!) fashion sometimes)

[finkel]

(many ancient disk-based games - mainly scene releases - will break if you have chip-only support; they MUST have their >= 512K bogo mem area, which they might even address in absolute (!!!) fashion sometimes)
That's very true.

Back then in 1995 or something, I actually built a hardware switch for my 512K bogomem card. There was a manual in some computer magazine how to transform your bogo to chip memory. One simply had to cut one line on the board, and weld it to another one. A piece of cake. :) Autofire switch from my (by then completely broken) joystick took the role of the arbiter. :)

I still remember that every now and then I would flip that switch, and the game would miraculously start working. :)

[finkel]

AG,

I sent you the project archive this morning, along with the support archive with headers and libraries, but I'm not certain it got through. It seems that my third email, with some corrections in menu_main.cpp was recognized as spam. :)

In case you didn't get it, I accidentally broke initial chip memory allocation for 512K. I considered sending another email, but right now it seems safer to just put the whole thing on some file sharing host. This archive contains corrected versions of menu_main.cpp and menu_memory_disk.cpp.

Mirrors:
http://hotfile.com/dl/68573971/6036481/uae4all_symbian_0.04.rar.html
http://www.megaupload.com/?d=W1VJC5HD

[Anotherguest]

Got it. Thanks. I will update my source base. I have reorganized the menus as you can see and more modularized so you can enable or disable some parts. And great to see a extra fontchars also.

I hope that harddrive support also can go over to the Pandora and Gp2x versions, I guess they want it too. :-D

[finkel]

Got it. Thanks. I will update my source base. I have reorganized the menus as you can see and more modularized so you can enable or disable some parts. And great to see a extra fontchars also.
Yeah, took me some time to find a suitable PNG editor. It turned out that GIMP has everything I needed, and much more. :)

I hope that harddrive support also can go over to the Pandora and Gp2x versions, I guess they want it too. :-D
I believe it can. The parts I wasn't sure about were all put under __SYMBIAN32__ define checks. Extending them with other system defines should definitely work.

The only thing that people may want to be aware of was a strange bug that I encountered in Symbian emulator. fwrite() would not write to the specified offset in HDF, but would *always* append to the end of the file, regardless of fopen() argument. One strange bug indeed. Got rid of it by using write() instead, and that part is also under define check.

[Anotherguest]

Mergeing always takes such a time. I guess that diagonal controls would be nice, I have a remapping feature enabled now, you can try that and see what you think, i.e key->joy. Kind of the same but different. Looks good for now at least.

[Anotherguest]

Got something to build and run, but I need to get the menus looking and working abit better. Anyone with a link to a small nice hdf file to boot anything from?

[finkel]

Mergeing always takes such a time.
Yep, I know. Never enough time to work on the things one likes. Real life job always takes precedence.

I won't be pushing you for a release, and I hope others won't either. Those who appreciate the work won't say anything bad, and those who do say don't appreciate the work. Simple logic, and very useful in many cases. :)

I guess that diagonal controls would be nice, I have a remapping feature enabled now, you can try that and see what you think, i.e key->joy. Kind of the same but different. Looks good for now at least.
You have key mapping!? Ye-haa! :)

I put in the keypad config just so I don't have to make a full mapping feature. I know what it has to look like, but just thinking of the work that has to be put in... Keypad config was much faster, but it doesn't help with some special and dear games like Pinball Dreams & Fantasies (was it alts or shifts + enter or something), and Warhead (1-4 + F1-F4 + ENTER + other keys), just to name a few.

Will take a look at it as soon as I find time.

[finkel]

Got something to build and run, but I need to get the menus looking and working abit better. Anyone with a link to a small nice hdf file to boot anything from?
Err... HDF is easy enough to create from WinUAE, but for the Workbench... copyrights and all, you know. I think they still apply.

[finkel]

And the best news of the day...

After a 12-hour bug-hunting marathon I conducted yesterday, I finally found the reason for the screen mess. It turned out to be a sort of "buffer underrun". The culprit seems to be hiding in either finish_final_fetch() (flush_plane_data() in WinUAE) or toscr() (toscr_0() in WinUAE) functions, or possibly anywhere where out_nbits are modified.

The problem, as I see it right now, is that toscr_1() is called 1 too many times in the finish_ function. The first 2 calls shift all the screen data out of todisplay[] and outword[] buffers, so the 3rd call tries to work on zero data, and some part of the screen gets lost in limbo. Funny thing that it affects only the first word in a line (16 pixels on 2-bitplane screen) and not the whole screen, but I don't have the time to dwell into that mystery right now.

Anyway, removing one of the unconditional calls to toscr_1() seems to make everything right again, and the strip is no longer visible either in Workbench screen or while games are running. Tested with some half a dozen of games, including Lemmings 1, and the bug is gone. That bug, that is. Who knows what other bugs I'm putting in by removing that one line? :)

This may be too much to ask for, since those functions have most probably not changed since 1995 when they were first written, but does anyone have any idea where this particular behavior may be coming from?

I tried comparing UAE4ALL and WinUAE sources, and that yielded zero results. The next thing to try is compare the data as Workbenches run in parallel, but that will have to wait for a while.

[Anotherguest]

I added that keymapping just to be able to play those nice pinball games. :-D Hmm on touch devices touching is really way off.

And compare the bug you have with the latest source you got from me. They updated the drawing some.

[finkel]

And compare the bug you have with the latest source you got from me. They updated the drawing some. They did? That's the first thing I'll be checking today after work.

There are some bugs I've found in the meanwhile, specifically:
- Boot HD option is not working properly (if you are using the new menu).
- Chip memory allocation and resetting are in the wrong order.
- Kickstart 3.1 freezes if more than 1MB of chip memory is selected. Probably another mask hiding somewhere in the code. I'll have to trace it down over the weekend.

I will send you the changed files once I have everything working properly.

[Anotherguest]

Yes HAM and halfbrite are modified so they actually works.
Ok so boot HD needs reset in a different order. And memory.I will check that. :-) Boot HD is important, almost as important as your Lemmings.
I actually booted workbench 2.1 with kickstart 3.1 with 2mb of memory +1 extra. it worked fine. but gurufied the boot hd.

[Anotherguest]

And kick2.1workbench2.1+harddrive works. Phew.. 2mb chip 1 mb slow but workbench reports 2 mb graphics and 0 mb other. hmm got 1+1 before. strange. or is it the harddrive?

Got harddrive to work once, then I changed the order of settings default and loadconfig. Hmm That GURU is always present. Must be some memory integration not working as it should

Edit.. ohh.. Fast memory needed for harddrive operation. Booting 3.9 was n't a great success though. :-D

[finkel]

Yes HAM and halfbrite are modified so they actually works.
Ok so boot HD needs reset in a different order. And memory.I will check that. :-) Boot HD is important, almost as important as your Lemmings.
I actually booted workbench 2.1 with kickstart 3.1 with 2mb of memory +1 extra. it worked fine. but gurufied the boot hd.
No luck with new version. Even that version has the screen bug present.

Howeeeeveeeer.... :) :) :)

I finally figured it out, and you won't believe what was causing it. I was on the right track, but it's not buffer underrun. It's actually buffer overflow, but in line_data[].

The only difference between UAE4ALL and WinUAE is in one simple, yet so important line in custom.h:
#define MAX_WORDS_PER_LINE 40

Value of 40 should be enough for 640 pixels per line. WinUAE, though, defines it as 50, which should be enough for 800 pixels. The problem is that the engine runs well over the limit by up to 3 words, and that messes with the beginning of the next line.

The simplest solution, therefore, is to simply define it as 44 and you won't have any problems... until you try to set some 800 pixel resolution, when you'll most probably set it off again. :)

+4 to any meaningful value (eg. 40+4, 50+4, 100+4) should solve the problem once and for all.

I've changed the way HD configuration is reset. I'll send you all the changes this evening.

Kickstart 3.1 mystery is deepening. I've also succeeded in booting it with extra chip memory a couple of times, and the number of floppy drives seems to play some role in it as well. Never succeeded in booting 3.1 with 4 floppies. Well, weekend is twice as long now that I've got that nasty screen bug out of the picture. :)

Problems with extra memory are most probably because of wrong byte-ordering. All the memory functions must have those USE_FAME_CORE checks.

[finkel]

Got harddrive to work once, then I changed the order of settings default and loadconfig.
Yep, the order of defaults and loadconf is important, but simply changing the order messes things up, as I recall. I had to write some changes in one or both of them. You should easily find them.

Edit.. ohh.. Fast memory needed for harddrive operation. Booting 3.9 was n't a great success though. :-D
Ah, then it must have been something in expamem.cpp, like a call to some some initialization.

HD should work even with just 512K chip memory (with KS 2.0), but fast memory is required by WHDLoad, so no point in not using it. :)

WB 3.9 probably needs plenty of fast memory, but I've never tried it myself.

[finkel]

Ah, yes, one more thing.

Initially, I used memory access functions just as it was set up by default. But once I found out that chipmem_bank.baseaddr (and its equivalents for bogo and fast memory) determine if functions (NULL) or bank arrays (!= NULL) are used, I set up all memory to work with bank arrays.

There's no visible difference in FPS, though, so you may want to keep using memory functions. Just make sure all of them have those checks. I'm not getting any problems with functions simply because I 'm not using them. :)

[Toni Wilen]

The only difference between UAE4ALL and WinUAE is in one simple, yet so important line in custom.h:
#define MAX_WORDS_PER_LINE 40

Value of 40 should be enough for 640 pixels per line. WinUAE, though, defines it as 50, which should be enough for 800 pixels. The problem is that the engine runs well over the limit by up to 3 words, and that messes with the beginning of the next line.


Hardware does not have "640 pixel" resolution, only 35ns/70ns or 140ns pixel clocks :) "Resolution" includes also borders and overscan. That array must have space for about 750 or so pixels

[Anotherguest]

I guess that the fixed rescale to 320 (pixel line) screen size, made some errors when setting those constants. I'm wondering how much fps I will loose if going back to variable resolution and not defined.
Anyway harddrive with fast mem works fine, without I'm getting guru meditation (both with 2.0 and 3.1) and the only difference was access to that fast mem area, I guess that gvp emulation is using some of its addresses or? You are setting some hooks in fastmem?? Nice to see hd support without fps degredation. :-D

So Nokia N8 + bt mouse, keyboard and UAE4all+hdmi out.. and well. 640 resolution support. Must be good. :-D amiga in the sofa. :-)

[Anotherguest]

And that 40 setting, I mean even though we render 640 pixels, the actual size would be more with overdrawing (which I guess the amiga supports) so there for the extra pixes. 4*16 gives 64 extra pixels.. Whats the amiga overscan resolution? aha. checked 704 pixels so thats 64 == 4 extra. So 100 = 1600 pixels, thats a max resolution of 1600 with overscan. So 44 can be documented as max hor resolution with overscan. Phew. :-D

[Toni Wilen]

Hires overscan is at least 752 pixels, perhaps slighly more depending how do you define overscan in Amiga..

[finkel]

I guess that the fixed rescale to 320 (pixel line) screen size, made some errors when setting those constants. I'm wondering how much fps I will loose if going back to variable resolution and not defined.
Anyway harddrive with fast mem works fine, without I'm getting guru meditation (both with 2.0 and 3.1) and the only difference was access to that fast mem area, I guess that gvp emulation is using some of its addresses or? You are setting some hooks in fastmem?? Nice to see hd support without fps degredation. :-D

So Nokia N8 + bt mouse, keyboard and UAE4all+hdmi out.. and well. 640 resolution support. Must be good. :-D amiga in the sofa. :-)
Hmmm... I just tried using memory functions again (those chipmem_bget() and such), and I'm just getting yellow screen, and Amiga keeps resetting. I don't even reach guru meditation. :)

Checked some of the memory at startup, and interrupt vector table (if I'm not mistaken) at 0x00000008 doesn't fill correctly. Argh... that's too much problems for very little gain, if any. I think I'll stick to memory banks for now. :)

Yep, HD doesn't have impact on FPS, unless something is loading or saving, which is usually not the case when you're playing a game. :)

[finkel]

So 44 can be documented as max hor resolution with overscan. Phew. :-D
I was just playing safe with extra 4 words. That, and the visual beauty of the screen without artifacts. :) There's not reference that states any such thing.

As it turns out, even 2 extra words would do the job for Workbench.

[finkel]

Hires overscan is at least 752 pixels, perhaps slighly more depending how do you define overscan in Amiga..
That would explain a lot.

I guess it's safest to set that define to 50, and stop worrying about it. :)

[Anotherguest]

Working on refreshing some parts of SDL for touch right now. Really needed. Also need to split keys. Hmm and my small (not) functions are so easy to handle. To much options implemented. :-D

[finkel]

Just to let people know, I'll be taking a well deserved rest now that HD support is working. The problem with KS 3.1, which only appears if more than 2 floppy drives are selected, will have to remain. It appears to happen because of some timing issues or something. At some point KS gets stuck on VHPOS reading, and just keeps looping around, waiting for some condition that never happens.

So, as far as I'm concerned, everything is working just fine. And who needs 2 extra drives when they have full HD support? :)

For those who do need all 4 drives, KS 2.0 with WB 3.1 is the winning combination. I've encountered no problems with it whatsoever.

Again, big thanks to Toni for all the help, and best wishes to AG with his new release.

I'm also hoping that someone out there will take a look at AGA support. Plenty of superb AGA games just waiting to be played on your phones. :)

[FOL]

Just to let people know, I'll be taking a well deserved rest now that HD support is working. The problem with KS 3.1, which only appears if more than 2 floppy drives are selected, will have to remain. It appears to happen because of some timing issues or something. At some point KS gets stuck on VHPOS reading, and just keeps looping around, waiting for some condition that never happens.

So, as far as I'm concerned, everything is working just fine. And who needs 2 extra drives when they have full HD support? :)

For those who do need all 4 drives, KS 2.0 with WB 3.1 is the winning combination. I've encountered no problems with it whatsoever.

Again, big thanks to Toni for all the help, and best wishes to AG with his new release.

I'm also hoping that someone out there will take a look at AGA support. Plenty of superb AGA games just waiting to be played on your phones. :)

Have to ask, does this work on 5800 XP, as it lacks a dial pad.

[Anotherguest]

Working on getting touch support better, BT keyboard would probably work with your 5800. But just as device it will also work, just not as usefriendly and quite slow due to a flaw in the hardware design

[finkel]

Well, a couple of news...

The good news is that AGA code has been ported from PocketUAE to UAE4ALL, and it's working. Some 30% of AGA games will work, more or less successfully, with just 68000 core.

The bad news is that none of the WHDLoad AGA games will work, because WHDLoad checks CPU before running a game. The same goes for WHDLoad CD32 games.

So I have a big request. I'm considering extending Cyclone engine (and FAME engine as a consequence) with the necessary subset of 68020 instructions. Meaning - just the stuff that would be used in games.

For that purpose, I need any document that has 68020 opcodes/mnemonics table. I do have some hardware manuals I found on the net, but none of them has opcodes.

[Toni Wilen]

www.freescale.com for official Motorola (now Freescale) pdf manuals. For example "M68000 Family Programmer's Reference Manual" includes all 680x0 opcodes.

MOVEC is generally always used for CPU type detection.

[finkel]

www.freescale.com (http://www.freescale.com) for official Motorola (now Freescale) pdf manuals. For example "M68000 Family Programmer's Reference Manual" includes all 680x0 opcodes.

MOVEC is generally always used for CPU type detection.
Wow, great! I will definitely download everything I can find there. :)

Yep, I've seen that movec is used for detection. Found some Kickstart disassembled code with comments somewhere on the net, and CPU detection was the first thing I looked for. Then AG sent me some manual that explains differences between 68020 and 68000, and it seems that 020 added plenty of new instructions to the set, as well as 32-bit addressing modes.

Looking back at some of the games that wouldn't work, and some that had very interesting graphics problems, I'm starting to get some ideas why they behaved the way they did.

Plenty of reading to go through, though. This is gonna take some time.

[FOL]

Any download for this, so I can have a play?

[finkel]

I wouldn't know about downloading unfinished 68020/AGA support. The first one is still not implemented, and the second one is still not optimized, but I leave such decisions to AG. It's his project after all.

Speaking of 68020, I've ported some of the stuff to FAME core - addressing modes, exception handling, control register handling, etc...

Right now, I'm messing with 68020+ instructions, and I have some questions regarding bit field manipulation.

Here's the piece of the WinUAE 2.30 code that's confusing me. It's taken from the get_bitfield() function.

case 5:
tmp = get_long (src);
res = tmp << offset;
bdata[0] = tmp & ~(mask >> offset);
tmp = get_byte (src + 4);
res |= tmp >> (8 - offset);
bdata[1] = tmp & ~(mask << (8 - offset));
break;
default:
/* Panic? */
res = 0;
break;

The question is this - is there any specific reason why code only works with up to 1 extra byte in the next long? Shouldn't it work with all 4 extra bytes?

680x0 reference states that both offset and width fields can have values of up to 31 (with 0 meaning 32), so the following example should be possible to code with 68K instructions.

I've used nibble-bounded values for simplicity, and [] contain affected nibbles:
offset = 28,
width = 32,

(N) (long containing the base byte) =
0x[f]00f0fff

(N+1) (next long) =
0xF[F0F0FFF]

CPU should give the following result with BFEXTU instruction:
0xF0F0FFFf

WinUAE 1.45 returns:
0x00000FFf

WinUAE 2.30 will obviously return 0, but I can't build it, so gencpu.cpp is my only guide for that version.

I've adjusted the code I ported from WinUAE so that it works with both longs that may contain the bit field, but I'm concerned that it may not be behavior of the real 68020 CPU.

Should I go with the reference (which, for example didn't state that offset should be calculated from the most-significant bit, and not the least-significant one, as only seems logical), or should I stick to just 1 extra byte?

[Toni Wilen]

Check cpuemu_x.

dsta += offset >> 3;
tmp = get_bitfield (dsta, bdata, offset, width);

EDIT: originally it used 2 long fetches but that breaks MMU emulation because real CPU internally handles it as 4+1 (even if it appears as 4+4 to outside world)

[finkel]

Check cpuemu_x.

dsta += offset >> 3;
tmp = get_bitfield (dsta, bdata, offset, width);

EDIT: originally it used 2 long fetches but that breaks MMU emulation because real CPU internally handles it as 4+1 (even if it appears as 4+4 to outside world)
Aha, that's it. Thanks.

[Anotherguest]

I think that a pre-release could be good. Now. I would make a Cyclone release, and Finkel is using Fame for his emulation right now. And I have n't got that remerge quite right yet.

[Anotherguest]

OK reintegration done. need to do that UI for screen and chipset mode (don't think I saw that in the UI)

[Anotherguest]

So not having fast or slow mem with the last AGA integration gives some courrpt graphics (on Faery tale adventure). but not if I have the mem allocated. Running Pinball fanaties for AGA is 3-4 fps slower then the non AGA version. Not toobad. Kind of playable on my Nokia N97 Mini (which is very slow to begin with) Running cyclone core also.

[phnikola]

Hi AG, Finkel,

any news - when will the new version be available for download?

Many thanks

[nd4567]

Anybody answers me-regulary playing
games on this emulator on my phone
symbian 60 version 3 Nokia C5-00
but I have three questions:
-How to redefine controls for
pinball dreams due virtual
emulator`s keyboard is
not practic cause of arrow
which can not press both
shifts so rapidly.
-How to insert disk 2 in
"Crime Wave" in "specific"
DH1 drive.
-In Lotus III black screen after
starting the game doesnt remove
even after pressing both buttons
ond mouse and joystick..

[FOL]

Anybody answers me-regulary playing
games on this emulator on my phone
symbian 60 version 3 Nokia C5-00
but I have three questions:
-How to redefine controls for
pinball dreams due virtual
emulator`s keyboard is
not practic cause of arrow
which can not press both
shifts so rapidly.
-How to insert disk 2 in
"Crime Wave" in "specific"
DH1 drive.
-In Lotus III black screen after
starting the game doesnt remove
even after pressing both buttons
ond mouse and joystick..

Never really went to much into it.
It is slow and awkward to use.

[nd4567]

Never really went to much into it.
It is slow and awkward to use.

Sound is very precise
graphic in 90%.....

Anybody answer me ?

:banghead

[FOL]

Sound is very precise
graphic in 90%.....

Anybody answer me ?

:banghead

Not sure, you can remap the keys on it.
I never found a way.

Changing disk, theres a menu button, on my XM5800, it was top right.
It would only use my touchscreen, Im guessing you dont have touchscreen.

Im guessing LotusIII doesnt like you current config or dodgy adf/s?
Do you have it setup as an A500, with 1MB MEM?

Im interested in the specs of your phone, cause with my XM5800, its barely playable and sound was stuttering all the time.

[nd4567]

Not sure, you can remap the keys on it.
I never found a way.

Changing disk, theres a menu button, on my XM5800, it was top right.
It would only use my touchscreen, Im guessing you dont have touchscreen.

Im guessing LotusIII doesnt like you current config or dodgy adf/s?
Do you have it setup as an A500, with 1MB MEM?

Im interested in the specs of your phone, cause with my XM5800, its barely playable and sound was stuttering all the time.

http://www.mobilnisvet.com/mobilni/2488/Nokia/C5-00

This is our most respected site in Serbia about mobile phones.
Specifications are listed above.

Mobile phones does not has to be just "fancy stuff"
In that case,I respect Motorola

http://www.telekoplus.com/model.php?proiz=Motorola&model=MILESTONE&gclid=CPTzxurlt64CFYpN3wodNxTKrw

In regard of model Nokia C5-00 it is obvious that they are
not predicted...but why not to exploit the maximum
of performance...by the way..I can suggest one link
to old Serbian (Belgrade) magazines which where
popular (Amiga descriptions 80 %) before the time
of Milosevic in age of 1984-1994 and far on...

http://pc.sux.org/indexSK.html

[nd4567]

In regard of Lotus III

system clock 100 this vere changed and nothing
sync threshold 100
frameskip auto
mouse speed 1
sound on
sound rate 22k this also
video mode pal also this
autosave on
memory chip size 1Mb and this
number of drives 1
enable scripts yes this
skip intro no
kickstart 1.3
enable HW scaling yes this
control config 2

Three questions in my past post
Piball dreams controls
Lotus III black screen
Crime Wave second disk

Who knows..if knows..if manufacturer
of uae4all read this also..doesnt matter....