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


Floppy run from HD-booted WB



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.



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..com/files/415675025/uae4all.rar
(mirror) http://www./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]

Originally Posted by 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.

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]

Originally Posted by finkel

- 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]

Originally Posted by Toni Wilen

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]

Originally Posted by Anotherguest

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]

Originally Posted by finkel

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!
(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]

Originally Posted by andreas

(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:///dl/68573971/60364..._0.04.rar.html
http://www.megaupload.com/?d=W1VJC5HD