English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 20 May 2024, 22:30   #1
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 578
N64 recompilation and amiga application

I'd be interested in a thought experiment into the practicality of using this technique with Amiga related projects.

Existing emulators have used recompilation but were limited in how the recompiled version worked and differed from the original. This new tool allows how the game works to be modified so it can run natively, rather than as before on presumably an emulated display that is rendered natively.

Here is Digital Foundry showing different ways a recompiled project can be generated (anti-aliasing, ray tracing, original resolution, etc) and comparison between the outputs:

[ Show youtube player ]

Here is Modern Video Gamer showing himself going through the process and doing it for several games:

[ Show youtube player ]
copse is offline  
Old 20 May 2024, 22:33   #2
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 578
The process of recompilation is not automatic. Someone has to disassemble the code and:
  1. Identify the entry point.
  2. Functions.
  3. External calls.

This is then used to produce C (c++ ?) code that is portable and can be compiled against a target API.

Now this is for N64 and the library calls are fixed and known and there is perhaps more of a mapping of it to the native target APIs we use today.
copse is offline  
Old 21 May 2024, 13:44   #3
lmimmfn
Registered User
 
Join Date: May 2018
Location: Ireland
Posts: 686
What JOTD is doing with his arcade ports is similar except rather than converting Z80 instructions to C its transcoding directly to 68K instructions(JOTD can clarify ). Arcade ports are different from N64 though in that each arcade machine has different gfx/sound hardware and those need to be rewritten to map to Amiga hardware vs N64 where it is just one platform.

The N64 recompilation to C code & compiling natively is fine for modern hardware as CPUs/Gfx hardware has hugely improved since the days of the N64 so its not required to recompile to native assembly, i.e. the C step would be too slow on Amiga.
lmimmfn is online now  
Old 21 May 2024, 15:12   #4
gimbal
cheeky scoundrel
 
gimbal's Avatar
 
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,949
Simple version: you need a monster PC to run a game which looks like a PC game from the 90's that ran fine on late 90's hardware
gimbal is offline  
Old 21 May 2024, 23:18   #5
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 578
Quote:
Originally Posted by lmimmfn View Post
What JOTD is doing with his arcade ports is similar except rather than converting Z80 instructions to C its transcoding directly to 68K instructions(JOTD can clarify ). Arcade ports are different from N64 though in that each arcade machine has different gfx/sound hardware and those need to be rewritten to map to Amiga hardware vs N64 where it is just one platform.

The N64 recompilation to C code & compiling natively is fine for modern hardware as CPUs/Gfx hardware has hugely improved since the days of the N64 so its not required to recompile to native assembly, i.e. the C step would be too slow on Amiga.
I think the focus on C is irrelevant. As I understand it, the framework that this recompilation is based on translates to assembly as well and the C or C++ is just a variation of this (I think MVG refers to this specifically). For this to happen it is likely there is an intermediate representation that can be translated to whatever platform's assembler you want. This would be a more general form of what JOTD does.

The more complicated part is the automatic mapping of hardware access. In the case of the linked external functions for the N64 these can likely be shimmed out as a layer. In the case of CPC, ZX, C64, Amiga, Atari ST, etc where hardware access is performed, this layer is internalised and merged into the translated code and is much harder to shim out.

If an Amiga or Atari ST instead uses OS calls then this can ideally be shimmed out. In fact, I would suspect that vamos could be extended in the same way.

Now, if we look back to the N64 recompilation we can see that there is an intermediate step where a coder needs to mark methods to guide the recompilation translation to C step. We can now think to paraj's efforts to shim out graphics methods for the flight simulator to speed it up by doing graphics operations in fast memory for instance. Of course there's a lot more work here and it's much harder for output platforms with direct hardware access.
copse is offline  
Old 22 May 2024, 12:53   #6
x-vision
Registered User
 
Join Date: Oct 2019
Location: Spain
Posts: 39
Quote:
Originally Posted by gimbal View Post
simple version: You need a monster pc to run a game which looks like a pc game from the 90's that ran fine on late 90's hardware
no.
x-vision is offline  
Old 22 May 2024, 17:42   #7
Cris1997XX
Registered User
 
Join Date: Oct 2022
Location: Roma
Posts: 333
Quote:
Originally Posted by x-vision View Post
no.
yes.
Cris1997XX is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
TEKNO AMIGA application disk Lumby request.Apps 12 18 September 2023 07:29
JAG/AMIGA/N64/GB/GG/NES/SNES/GENESIS/NEOGEO/MISC scene collection cage Collections 5 21 September 2019 12:18
Question regarding ADF to Amiga Floppy using DMS application Kenan support.Hardware 25 09 May 2013 10:35
Amiga Application museum onkelarie News 42 21 December 2009 08:25
Best N64 emulator? MethodGit Retrogaming General Discussion 7 11 July 2004 11:31

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:07.

Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Page generated in 0.07657 seconds with 15 queries