Fast Red Zone and other fastmem-relocated projects

[jotd]

emulation is only useful to check if the game can have good fps. Running from chipmem in emulation doesn't slow the game down.

[Galahad/FLT]

Originally Posted by jotd

More good news:

- started Infestation. Infestation gave me hell but is slowly taking shape.
- Resumed work on Hunter with the gained experience from previous reloc projets. Hunter is now running from a different memory address. Now I have to relocate chip data in chip again for a full test in fastmem.
- Epic has been released officially.

I think Robocop 3 should be a good & rewarding project too.

Ha, good luck with Robocop 3, code wise its a fucking mess, lots of separare code sections encrypted on the disks.

I will say that a lot of the Robocop 3 code is not well optimised at all.

[tolkien]

Damn! Hunter is now a lot of faster in my a1260. Fantastic work!

[jotd]

Originally Posted by Galahad/FLT

Ha, good luck with Robocop 3, code wise its a fucking mess, lots of separare code sections encrypted on the disks.

I will say that a lot of the Robocop 3 code is not well optimised at all.

So all the various sections are different programs? that complicates the work all right (encrpytion: not that much as whdload slave already decrypts them)

[Reynolds]

Originally Posted by jotd

Reynolds is that a video from real amiga? Framerate is really good. I see what gfx glitches you're refering to: landing strips seem to fly in space at some point right?

Can you try again with NOCACHE? that game is not the best programmed game, uses self-modifying code.

Tried out last night with Nocache tooltype. The glitches were gone, but the game ran with noticeably less framerate. Started on level 2 (pass: AURIGA) and progressed to level 3, but then it suddenly crashed. Got the QUIT/RESTART/MAKE COREDUMP requester. Noob question, but if I want to make coredump, where will it be put by default?
Anyway, I was so happy seeing how fast the game became. That was what I missed during the years when bought more and more powerful cards for my Amigas, but suffering of poor framerate were remained, unlike it happened on friends' pcs in any vectorgfx-based stuff. Wonder if this issue can be solved somehow?

Ahh, and Starglider 2 crashed before anything happens, after the doubleclick on the icon gets rainbow-ish screen and freeze.

[Aardvark]

Originally Posted by Reynolds

Ahh, and Starglider 2 crashed before anything happens, after the doubleclick on the icon gets rainbow-ish screen and freeze.

It's not crashed. Click mouse to proceed.

[Reynolds]

Originally Posted by Aardvark

It's not crashed. Click mouse to proceed.

Hmm... well then, I'll try again tonight, thx for the tip.

[jotd]

Originally Posted by Reynolds

Tried out last night with Nocache tooltype. The glitches were gone, but the game ran with noticeably less framerate. Started on level 2 (pass: AURIGA) and progressed to level 3, but then it suddenly crashed. Got the QUIT/RESTART/MAKE COREDUMP requester. Noob question, but if I want to make coredump, where will it be put by default?

Level 3 has a documented crash (the new HD version). By default, the files are created in "C:". The small file is usually enough for me to analyze.

If it runs without glitches without caches it means that some self-modifying code remains (it can be investigated and fixed of course!). I think DID themselves had issues as there's code in the game to turn on/off the caches.

Anyway, I was so happy seeing how fast the game became. That was what I missed during the years when bought more and more powerful cards for my Amigas, but suffering of poor framerate were remained, unlike it happened on friends' pcs in any vectorgfx-based stuff. Wonder if this issue can be solved somehow?

It's a chipmem speed issue. It happens on 3D games (not blitter dependent) which install their code in chipmem. And the irony is adding an accelerator only makes it worse as some accelerators like Phase 5 A1260 focus on running code in fastmem, and are super slow when it comes to run the code in chipmem.

Relocation process requires a kind of reverse engineering to compute the relocation addresses, which can be a pain in some ambiguous case where pointers are mixed with data with almost the same range of values. Not the case of EPIC which just used a classic executable, but forced in chipmem to avoid issues... wankers!

[Predseda]

I always adored Starglider 2, can someone make a video with comparison of NoFastmem / Fastmem version?

[Reynolds]

Originally Posted by Predseda

I always adored Starglider 2, can someone make a video with comparison of NoFastmem / Fastmem version?

maybe I can tonight...

[jotd]

some news:

- Fixed Starglider 2 tunnel force field crash (check the zone)
- Hunter all 3 versions supported and officially released

[Aardvark]

Originally Posted by jotd

some news:

- Fixed Starglider 2 tunnel force field crash (check the zone)

I'm not seeing Starglider 2 in the zone

[jotd]

fixed!

[Aardvark]

Still crashing in a tunnel [ Show youtube player ]
Other bugs:
Missing cross-hair
Many cockpit indicators are not working
High pitched sound effects

[Aardvark]

Tried with ExpChip, and it's still much faster than the original slave (chip access time on Warp1260 is not bad), and it fixed the cross-hair, and cockpit bars, but tunnel crash still exists. [ Show youtube player ]

NoVBRMove option revealed that there is also an in-game error message.

[jotd]

good test. There are 2 separate problems to address when relocating a game. First the relocs must be accurate. Too much or not enough can crash the game.
Then chip data must point to chipmem.

I'll fix those issues. I'm surprised that the slave is faster running in chipmem... new slave has speed regulation that makes the game unplayable because too fast (but most of the time problem wasn't noticeable because it crawled)

[Aardvark]

Originally Posted by jotd

I'm surprised that the slave is faster running in chipmem...

Ok, this seems to be only because the official slave had caches off by default. With Cache option they're about same speed.

[lmimmfn]

Originally Posted by jotd

good test. There are 2 separate problems to address when relocating a game. First the relocs must be accurate. Too much or not enough can crash the game.
Then chip data must point to chipmem.

I'll fix those issues. I'm surprised that the slave is faster running in chipmem... new slave has speed regulation that makes the game unplayable because too fast (but most of the time problem wasn't noticeable because it crawled)

I'm curious how you do this as you know there's no difference between data and code? Its very impressive, do you step through the code looking for calls to chipmem or some other technique?

[jotd]

Originally Posted by lmimmfn

I'm curious how you do this as you know there's no difference between data and code? Its very impressive, do you step through the code looking for calls to chipmem or some other technique?

I have described the process in one answer here https://retrocomputing.stackexchange.com/a/24613/3316

Basically, disassembly gets you the easy ones (LEA, MOVE direct... in obvious code sections). The problems arise with move.l # and mostly dc.ls (pointers in data)

There are a lot of "little secrets" (which aren't secrets) to prepare the source file (like renaming the labels with the offset in it, or splitting ORIB #0,d0 i 2 DC.W 0...), plus the script which catches undefined pointer table labels you just inserted and declares them at the proper location in the source file. README in my github for the projects try to list how to proceed.

With kickstart files it's easier since addresses range from 0xF8000/0xFC000 to 0x100000.

On a game, you have to use memory protection (winuae or whdload) so if the game tries to access the old memory you catch it. But it can be very tedious so I have developed a lot of scripts to try to detect pointer tables.


The most annoying case (happens in Starglider) is a list of structures containing pointers and also data, but not periodically (kind of varying structures I dunno...). In that case if you declare a relocation when it's data then you introduce a bug which is super hard to track. Then you have to doubt of all the relocations, remove them, run with memory protection on, retry.... Time consuming even with the right tools. Without any tools it's just impossible.

Originally Posted by Aardvark

Ok, this seems to be only because the official slave had caches off by default. With Cache option they're about same speed.

Ah, that makes sense. So ATM play with the old install with CACHES on. But it hasn't speed regulation so for instance in WinUAE the game is unplayable because of speed (a bit like freescape games)
But I think I'm very close to making it work from fastmem so stay tuned Working on infestation ATM.

Yesterday I tried Hunter on my 060 with fastmem or chipmem and I thought that even with chipmem the FPS were good. But clearly with fastmem it was smoother.

[Angus]

Originally Posted by jotd

Yesterday I tried Hunter on my 060 with fastmem or chipmem and I thought that even with chipmem the FPS were good. But clearly with fastmem it was smoother.

I looked at the Hard Drivin' games, Jean Francois.



HD 1 goes pretty fast but it's really nasty to control.


HD 2 (which is an expanded, improved and bug fixed HD1) is decent to control but seems to run at a lower framerate.


Race Drivin' is just horrible, in my opinion. :-)


It maybe that HD2 could be made to run smoother, maybe not.
In my opinion the other 2 games are not of the same quality,