TheRaven81 Posted December 7, 2022 Share Posted December 7, 2022 Is there any way to do this at all? Quote Link to comment Share on other sites More sharing options...
Rybags Posted December 7, 2022 Share Posted December 7, 2022 For the most part software isn't really PAL or NTSC. In terms of movement speed it will often be tuned on whatever system it was developed in and often seem too slow or fast (many games seem slow on PAL). With software that's PAL only the problem is available cycles per frame. Most games of the era are rendered a frame at a time, PAL has a lot more available cycles to do this since it's 312 scanlines vs 262 for NTSC. The 50 scanlines difference equals about 5,200 cycles. That lack of available cycles for NTSC could mean the difference of several software sprites or plenty of other missed work. In the 1980s it generally wasn't an issue as games were made for the broadest market possible so full compatibility was important. In the modern day there can be workarounds or multiple versions of a game. Usually the NTSC version will have less frame updates or fewer moving objects. But often there will not be an NTSC version, this is usually the case with demos. 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted December 7, 2022 Share Posted December 7, 2022 Music too, 'instruments' can be geared to one system and then sound 'off' when played on the other. For me, case in point is the AR:City introduction Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 7, 2022 Share Posted December 7, 2022 (edited) but in the same time period NTSC does about 10 more frames making game play smoother and code can be spread into those frames cutting the disparity by more than half, though sometimes a quick fix makes a stutter when not fully converted. change interrupts to deferred and vice versa/trimming blank scanlines within what is wanted to be displayed make it a bit more even between the two. It kind of goes on and on. Nearly everything could be fully implemented for just about anything but would require whole sections of code (and sometimes d*amn near all of the code to be moved around). Certain things can be critical to happen before another action takes place. The speed difference can also make music too fast or too slow, changing pitch or timbre, and certain times effects in instruments can be off, again needs to be adjusted. Edited December 7, 2022 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted December 7, 2022 Share Posted December 7, 2022 There's a cheat way to do this via emulation, just select a higher clock speed ie PAL 60 in Altirra, that way it keeps the system as PAL but 17.5% (?) faster. But as the guys say, it will break some stuff, especially those written / clocked for the PAL market. Display lists may break / fire at the wrong time etc etc It can be done, but its say a game developed and released ONLY in the UK then it's down to a coder to decide if they want to spend x time recoding the pre-written code and maybe have to relocate other code to make space. Quote Link to comment Share on other sites More sharing options...
TheRaven81 Posted December 7, 2022 Author Share Posted December 7, 2022 Yeah I was looking at some things ("Rogue", and "Deimos", to name a few) now that I have an AVG cart coming, but I was not sure how well they were going to work without possibly converting them to NTSC. But from what i gather of your comments, "conversion" would probably mean a re-write of the entire thing on an NTSC machine, to get timing of everything correct. 1 Quote Link to comment Share on other sites More sharing options...
Mrshoujo Posted December 9, 2022 Share Posted December 9, 2022 If Vertical Blank timing is a critical part of code execution, that would affect things. Some PAL designed code crashes on NTSC machines. It might require some DLI adjustment to squash the display down (or up?) a bit for those extra bits for extra time because you can always shut off the screen for a little bit but you must always hit that VBSYNC. It's really odd (and sad) this is basically the difference. The OS might also be a little different. Anywho, something to think about. Quote Link to comment Share on other sites More sharing options...
tjlazer Posted December 12, 2022 Share Posted December 12, 2022 Yes many have done NTSC fixes over the years, you can find them on the forum here. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted December 12, 2022 Share Posted December 12, 2022 On 12/7/2022 at 3:28 PM, TheRaven81 said: Yeah I was looking at some things ("Rogue", and "Deimos", to name a few) now that I have an AVG cart coming, but I was not sure how well they were going to work without possibly converting them to NTSC. But from what i gather of your comments, "conversion" would probably mean a re-write of the entire thing on an NTSC machine, to get timing of everything correct. Not everything, just the display timing code and DLI related stuff, the annoying part is digging through someone else's code and trying to make sense of how they did things..Basically, it's a boring old process... When I used to train games, I would swear some people were just evil in the way their code went all over the show just to do a decrement, god know's how much time they lost with this rambling way of coding. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.