Topic by Noxxa

Posted: 7/29/2019 12:59 AM

Quote

zaphod77

Joined: 1/13/2007
Posts: 343

Well the default system has at best a datasette. the disk drive didn't even come with the system. So all that worked by default is tapes and carts. There are a number of commodore peripherals, and 3rd party peripherals. The 1541 drive is the only other commodore peripheral that actually matters. Magic Voice was another commodore peripheral, but its' not needed to TAS anything. Every original 5 1/4 in disk is compatible with the 1541 disk drive. that makes it a standard peripheral, even though it didn't come with the system. there were other drives as well. the 1571 (for use with c128) and some official hard drives and 3 1/2 drives as well. It is valid for the same reason that the FDS disk drive is valid. it's a first party peripheral. it was also bundled with the sx-64 (a portable model). it wasn't exactly the same drive, but was close enough. Because software was protected, it couldn't be legit converted formats in general. Sometimes you could do format conversion, if tere was no protection. But generally you must crack it, and then it's no longer a legit game. Fastload carts and freezer carts were very common peripherals. None were actually made by Commodore, but they were very commonly available. There were also after market ROM replacements. JiffyDOS is the most notable one of those, which as for both the computer and the drive. It was highly compatible, and sped up loading. In the US, the major cart was the Epyx Fastload. most other carts that were for sale in the USA that weren't freezer carts were similar to this. the more advance carts were mainly found in europe. expert cartridge final cartridge, Datel Action Replay, etc. TAP images can never be sped up. they just work or not work. there is no tape accelerator cartridge. .g64 images can rarely be sped up by any means, as they tend to have their own fast loaders, but it's sometimes possible to speed them up with a fastload cart, and sometimes with jiffydos. .d64 images are much more likely to be possible to speed up with a fastload cartridge, and nearly ALL speed up with jiffydos. Many emulators also support non true drive emulation, which traps the kernal loads and makes them happen darn near instantly. When a game works with this, it loads orders of magnitude faster. Try, for example, necromancer. The .d64 with errors is an original disk image. It does not load significantly faster with fast load. it does load a bit faster with jiffydos. it loads amazingly fast with true drive emulation turned off. But this was an option that nobody ever actually had. The main argument for allowing speeders is that a) they were very commonly used on real hardware and b) they usually shave many minutes off of the total time. A game that takes 2 minutes to load from disks will often load in a fifth of that time with an epyx fastload cart. that knocks off 96 seconds of downtime, and doesn't modify the software. if the game is a multiload, even more time is saved. A speeder art does not modify the game in any way. it just replaces the standard load routines with something faster. This is why they are arguably allowed. Another argument for no true drive emulation. lets take Below the Root. turning off true drive emulation in vice causes screen transitions to be instant, instead of a second or two pause between every screen. this adds up. Again this is an unmodified original. sometime it's possible to get a single PRG version that IS an original. emulators tend to load these darn near instantly. Here's a special example. take a .TAP original of Sentinel from Synapse Software. use Final TAP to extract the main program from the tape (or any other c64 side novaload extractor program). it's a simple rle encoded binary that contains the entire game. it IS the original program. this file can be instaloaded and ran in an emulator. presto. at title screen in seconds. But, in most cases, a .prg is NOT an original piece of software. it's generally a onefile crack. only digital releases tend to be available that way. as a .prg or a .d64 with a .prg on it. Just be glad that there are many originals available for c64. Atari 8 bit, for example is much harder to get images for true original disks.

Posted: 7/30/2019 8:21 AM

Quote

Oziphantom

He/Him

Joined: 7/21/2019
Posts: 11

There is "only released in PAL" and "PAL only" they are not the same thing. Mayhem In Monsterland is PAL only ( there is now a mostly 100% NTSC fix for it, but it as far as I know still has some slight compromises ) , Sam's Journey is PAL only but has a NTSC version that uses an REU to make up for the NTSC deficit. PAL has 19656 clocks per frame 63 clocks per line NTSC Fixed has 17095 clocks per frame 65 clock per line NTSC old has 16768 clocks per frame 64 clocks per line if you just want to go "fastest" Drean, as its has PAL clocks at 60fps Another issue is "graphics" in the borders, when a game opens the border to put the HUD into it, on PAL this is fine as the borders are large and can show a sprite height. NTSC has very small borders hiding most of the status bar. Having an extra 2 clocks per line than expected will cause more code to run before an interrupt fires changing the code state, this could open up more exploits. Unlike Consoles such as the NES and SNES which are VBlank locked for graphics and sprite updates, the C64 is active and shared RAM so any part of the graphics display can and is updated as it draws. So if the game logic needs the PAL length of frame, on an NTSC machine you might get enemies updating at 30fps, and have some update this frame and some next frame, while the interrupt moves the player at 60fps, which gives a different result to player + enemies updating at 50fps. Also worth noting that some games have NTSC and PAL versions which are completely different from each other, also Tape and Disk versions of games can differ greatly. Some games are C128 enhanced to which they will run faster when they are run in C64 mode but on a 128. An enhanced 128 64 title can match a PAL 64 for clocks.

Posted: 7/31/2019 12:29 AM

Quote

zaphod77

Joined: 1/13/2007
Posts: 343

yeah. it' really complicated. The general rule is use what's faster, i'd say. When the PAL and NTSC programs are entirely dfifferent (say, bionic commando, and others) you have to play the game in the right reigon, because the other region got a totally different version. This is a relatively rare case. If there are different versions, compare pal version on PAL with NTSC version on NTSC. Official releases by software publishers only. Run whichever's faster (usually NTSC) When there is on version if the game is glitch free on NTSC, that should be used, with PAL only being used if NTSC doesn't work right. So games must be tested on both. The only real question is speeder carts. They do not affect gameplay of single loads. they can make multiloads play faster, for obvious reasons. For RTA it's a non issue as they time from game start. but TAS times from poweron. So the main dilemma is what, if any speeders should be allowed? Possible options. 1) JIffyDOS allowed if compatible withe the game and it loads from disk. This ROM replacement is highly compatible, was very commonly used in real life, and will lower TAS time of nearly ANY disk game. It removes tape compatibility though. True Drive emulation required. 2) speeder carts allowed, but aftermarket roms (like JiffyDOS) not. this will generally give a 5x speedup in loading, but cannot accelerate block reads, so many games will still load really slow. 3) non true drive emulation allowed. When this works, it gives a super fast load time that cannot be obtained on real hardware. But in the case of a single load, it vastly speeds up time to game start to console levels. The same on multiload actually affects gameplay. so it should not be allowed. 4) no speeders beyond ones programmed into the game itself. this is the easiest to police, but often causes horrible load times. argument for jiffydos/carts is that they were very commonly used in real life, and thus are valid peripherals. argument against is they were not first party peripherals like the 1541 disk drive. argument for non true drive emulation is minimum downtime. argument against is can never be replicated on real hardware. also note that there's a standard sdcard solution to run a limited subset of .d64 images. used together with jjiffydos, this is a very fast loading platform on real hardware, but not sure if it's emulated. It's generally 20x faster than stock 1541 drive speeds. And yes, tape/disk/cart versions can be different. only the disk version of lode runner has all the levels. Frogger had different cart/disk versions. and TAPE version of Indiana jones is single load, but disk is a multiload. but both ARE the same game! multiload tape games are horrid and should almost NEVER be TASed. they are usually sloppy conversions from disk. the example given with enemies slower on NTSC vs PAL is an example of a glitch that would preclude the game being ran NTSC, IMHO.

Posted: 8/1/2019 5:48 AM

Quote

Oziphantom

He/Him

Joined: 7/21/2019
Posts: 11

zaphod77 wrote:

.g64 images can rarely be sped up by any means, as they tend to have their own fast loaders, but it's sometimes possible to speed them up with a fastload cart, and sometimes with jiffydos. .d64 images are much more likely to be possible to speed up with a fastload cartridge, and nearly ALL speed up with jiffydos.

This is not true, a D64 and G64 can be used the same way, it just so happens that we only make g64s when a game needs the extra detail in order to load, but you can have a G64 with plain prgs and no fast loader.

Many emulators also support non true drive emulation, which traps the kernal loads and makes them happen darn near instantly. When a game works with this, it loads orders of magnitude faster. Try, for example, necromancer. The .d64 with errors is an original disk image. It does not load significantly faster with fast load. it does load a bit faster with jiffydos. it loads amazingly fast with true drive emulation turned off. But this was an option that nobody ever actually had. The main argument for allowing speeders is that a) they were very commonly used on real hardware and b) they usually shave many minutes off of the total time. A game that takes 2 minutes to load from disks will often load in a fifth of that time with an epyx fastload cart. that knocks off 96 seconds of downtime, and doesn't modify the software. if the game is a multiload, even more time is saved. A speeder art does not modify the game in any way. it just replaces the standard load routines with something faster. This is why they are arguably allowed.

It only work on older games that don't use KERNAL loads, which is not many, single loads will be speed up, or budget releases and cracks. Most commercial releases will have a custom loader, so EPYX and AR and Jiffy Dos will only boost the "load the loader" load. Jiffy Dos is still sold and needs a license, so basically its unfair DLC ala Amibo's so I would think it would need to be banned. I think a better solution is to use the "you can load a save state and just add X time to you run" where the save state is "post load". also given different drives load at different rates, some are 290rpm some are 320rpm etc

Posted: 8/1/2019 5:57 AM

Quote

Oziphantom

He/Him

Joined: 7/21/2019
Posts: 11

zaphod77 wrote:

Possible options. 1) JIffyDOS allowed if compatible withe the game and it loads from disk. This ROM replacement is highly compatible, was very commonly used in real life, and will lower TAS time of nearly ANY disk game. It removes tape compatibility though. True Drive emulation required.

needs to be purchased though

zaphod77 wrote:

2) speeder carts allowed, but aftermarket roms (like JiffyDOS) not. this will generally give a 5x speedup in loading, but cannot accelerate block reads, so many games will still load really slow.

Epyx works on NTSC, but AR6 is faster but PAL only

zaphod77 wrote:

3) non true drive emulation allowed. When this works, it gives a super fast load time that cannot be obtained on real hardware. But in the case of a single load, it vastly speeds up time to game start to console levels. The same on multiload actually affects gameplay. so it should not be allowed.

for single load you could do Direct RAM Injection

zaphod77 wrote:

4) no speeders beyond ones programmed into the game itself. this is the easiest to police, but often causes horrible load times.

don't TAS's need to be "hardware verified" to be counted as true? so we are limited to doing them within hardware limits?

zaphod77 wrote:

argument for jiffydos/carts is that they were very commonly used in real life, and thus are valid peripherals. argument against is they were not first party peripherals like the 1541 disk drive. argument for non true drive emulation is minimum downtime. argument against is can never be replicated on real hardware. also note that there's a standard sdcard solution to run a limited subset of .d64 images. used together with jjiffydos, this is a very fast loading platform on real hardware, but not sure if it's emulated. It's generally 20x faster than stock 1541 drive speeds.

nobody emulates a SD2IEC, what is the point? Direct RAM injection, Traps etc are faster

zaphod77 wrote:

And yes, tape/disk/cart versions can be different. only the disk version of lode runner has all the levels. Frogger had different cart/disk versions. and TAPE version of Indiana jones is single load, but disk is a multiload. but both ARE the same game! multiload tape games are horrid and should almost NEVER be TASed. they are usually sloppy conversions from disk. the example given with enemies slower on NTSC vs PAL is an example of a glitch that would preclude the game being ran NTSC, IMHO.

sure but how does one test such things? I guess you could scale all the time points and then test on PAL to see if it works the same, but that is tricky to do and get working Edited by feos: fixed the quotes.

Posted: 8/3/2019 7:17 AM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

Yes, we are limited by "works on original hardware". What is emulated can be seen if you load a C64 game into bizhawk and observe C64 -> Settings dialog.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 8/4/2019 3:34 AM

Quote

zaphod77

Joined: 1/13/2007
Posts: 343

anything that is not revealed with cursory testing probably doesn't matter. that example of the enemies moving slower on ntsc, for example is easily revealed. flickering that's not present on the other shows up quite easily. bubble bobble intro is the same issue. it drops to roughly half speed. this is not rocket science. :) really arcane "only possible under TAS conditions with one video system" stuff is probably fair game. But if there are issues a normal player would notice, then you need to use the correct standard. there is also a system to do perfect freezes of the game, to set up for direct ram injection. it's a royal pain, but i know how to do it. you need to set a breakpoint at the load address of the game, then set up a loop elsewhere in memory and resume there, then freeze, then change the loop to point back to the start address. this technique will usually create a single load that can be direct injected. but again you can't do this on real hardware. also, there is an NTSC version of AR v5.0. i'm not sure if it uses ramload, though (which is the ultra fast loading solution that spools entire tracks into the cart ram so they can load fast interleave independent). there is no NTSC ar 6.0 but the 5.0 ROM is commonly available. While nothing about the .g64 format precludes use of kernal load, generally stuff that uses kernal load is compatible with .d64 format, so that's what it's usually found on, to save space. that's why i said a fastload cart will rarely speed up a g64 significantly. There are exceptions. An example of a disk original on .g64 that is significantly sped up by jiffyDOS is Encounter. The g64 format is required to store the twin sector (one sector is stored twice on disk with different values in it) to pass the copy protection, but once that's passed, it block reads the main program into memory one sector at a time with standard block read code, which fastload does not accelerate, but JiffyDOS does. No cart speeder that I know of accelerates block read. But licensing restrictions are an issue for JiffyDOS, even though the roms can be obtained. The licensing issue prohibits jiffyDOS. While every other speeder cost money as well, JiffyDOS is still being actively sold new. That's the issue. for US, FastLoad was THE standard cart speeder, and it was EVERYWHERE. The AR cart was often cloned, and is considered a standard speeder. there are also other aftermarket ROMs with speeders that are NOT JiffyDOS, but they tend to have compatibility issues. examples EXOS Beast System (pretty much same as EXOS) 64'er ROM 1514 Flash (earlier than diffydos, undumped as far as I know) StarDOS (undumped, as far as I know, faster than 1541 flash) Only the last two ever made it to the usa, and they were not common.

Posted: 11/15/2021 3:12 PM
(Edited: 2/25/2023 8:05 AM)

Quote

zaphod77

Joined: 1/13/2007
Posts: 343

Seems there is still debate 1) It must be possible in theory to verify the run by replacing the keyboard and joystick inputs with a bot in theory. This disqualifies ram injection/vdrive/virtual device traps. 2) The fastest loading original should be preferred. Cartridge is always fastest, but if it's not available for cart, usually disk is faster. But taking advantage of a glitch only present in an earlier release. 3) Format conversion was never intended to be possible. as programs were usually copy protected. It sometimes is still doable without extra peripherals. There are a number of tape to disk transfer utilities. The action replay cart, for example has a built in "novaload transfer" routine that will save a novaload tape to disk for later loading. many cracking groups wrote their own tape transfer utilities. But you would often usually need to crack the protection. transferrig form tape to disk can speed load times. transferring from disk to tape is pointless. transferring to cart is impossible under our guidelines. 4) while glitches are generally fair game, glitches that are only present when the game runs on the wrong video game system, and affect gameplay beyond the 50/60 hz change are not fair game, and mean you must use the video system where the glitch is not present, unless the game was officially released in that territory. 5) i still disagree on the decision that running a game that was not released in ntsc territory in ntsc is a valid choice. It's not a valid choice because real people don't have that option. their real tvs back in the day can only handle their own video standards. This is also to provide parity with console releases, where PAL versions must be tased on PAL emulation, admn NTSC versions must be tased on ntsc emulations. If we are allowed to tas pal released c64 games on NTSC settings, we would also allowed to tas pal NES game son NTSC settings. The fact that many games run on both is not a valid argument. c64 preservation (https://rittwage.com/c64pp/dp.php?pg=database) is an authority on if an original is PAL or NTSC for games released on disk. Look up the game there if it's a disk image. I will throw some examples. Great Giana SIsters. if you look it up there, ther'es only a (PAL) version. that's a very strong clue that the game is PAL. it was neve released in the USA at all. Ollies Folies. It notes that the loader crashes on NTSC, but the game doesn't appear to be PAL. NTSC is correct for this game. Encounter. The disk release is NTSC, as it's by synapse software. all novagen releases of the game are PAL, because they crash on NTSC intentionally. the game was developed on PAL, but got a commercial NTSC port. The novagen tape orginals only run on PAL, so they must be TASed there. There IS a ROM difference, in this case. Uridium. the game has pal releases, as well as a worldwide release by mindscape. NTSC is correct. It turns out most of Andrew Braybrook's games (Uridium, Gribbly's Day Out, Alleykat, etc.) account for pal/ntsc differences in their coding. Whichever is faster should be used, and it's probably NTSC. Any game that accounts for differences is a glabal release, even if not actually sold as such. For uridium he outright states that the us and europe releaes are identical. Thing on a Spring. there's no PAL after it, s it got an NTSC release by Epyx. TAS that release there, or other tape releases on pal, if it's faster. Working out pal/ntsc is not as hard as it seems. If you can't find a disk release of the game, unless it was made by a known US company (Epyx, Synapse,Activision non lucasfilm, br0derbund, etc.), the game is most likely PAL. If you CAN find a disk orginal, and it works fine on NTSC, it's PROBABLY a NTSC game. high voltage sid collection is a fairly authoritative resource. you simply punch the game title into the sid search, and usually it will come up. there's usually enough info to make a reasonable determination. That said, it's still not perfect (it say Commando is PAL, where a listen and compare with the arcade says otherwise, and c64 preservation confirms a US release from data east).

Posted: 11/15/2021 5:23 PM
(Edited: 11/15/2021 6:04 PM)

Quote

DrD2k9

He/Him

Editor, Judge, Expert player (2213)

Joined: 8/21/2016
Posts: 1090
Location: US

zaphod77 wrote:

5) i still disagree on the decision that running a game that was not released in ntsc territory in ntsc is a valid choice. It's not a valid choice because real people don't have that option. their real tvs back in the day can only handle their own video standards. This is also to provide parity with console releases, where PAL versions must be tased on PAL emulation, admn NTSC versions must be tased on ntsc emulations. If we are allowed to tas pal released c64 games on NTSC settings, we would also allowed to tas pal NES game son NTSC settings. The fact that many games run on both is not a valid argument.

The bolded aspect of this statement is untrue (bolding added by me). Real people had the option/ability to play a PAL released games on a NTSC C64 system (and vice-versa) with no special requirements/modifications. I had an NTSC C64 growing up. I also had games which were only officially released in PAL territories. These games worked just fine on my NTSC system. It's true that we shouldn't allow emulation of a PAL system at the 60hz framerate. However, while a PAL system wouldn't function with a 60hz NTSC monitor/tv, PAL software itself often runs perfectly well on the NTSC system making it playable on a 60hz tv/monitor. This was not only possible but frequently done by real people. Parity with console releases doesn't need to be considered. Consoles often have some form of region locking mechanisms in place that prevent play of a PAL cartridge/software on the NTSC system. It's therefore impossible to play such releases on an out-of-region system without modifying the hardware/cartridge to allow it. The C64 does not have this type of region-locking restriction, and no modification of the hardware is necessary to load out-of-region software onto the system for execution. EDIT: If a game was specially coded to work with a specific regions frame timing, one of three things will happen when played on an out-of-region system. 1) The game will play normally aside from slightly increased/decreased speed. 2) The game will run, but glitches will be introduced due to the out of sync code/system refresh rate. 3) The game won't run at all. Options 2 & 3 would be the only thing preventing someone in real life from playing an out-of-region game on their own system. EDIT 2: The above three possibilities still occur with properly emulated systems (BizHawk included). From my play/testing, BizHawk appears to perform the same as real systems would when presented with out-of-region software. An example is Monty On the Run; the game appears to play fine other than a glitched end-game when played in NTSC mode. It was this glitch that required the TAS to be completed in PAL settings.

Posted: 11/15/2021 5:30 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

zaphod77 wrote:

c64 preservation (https://rittwage.com/c64pp/dp.php?pg=database) is an authority on if an original is PAL or NTSC for games released on disk. Look up the game there if it's a disk image.

How was that database created? Also it says "THIS DOMAIN IS GOING AWAY" so I'm not sure if it will reliably persist.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 11/26/2021 7:26 AM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

How the database created: the author is a known archivist, specializing in C64 and Floppies. The physical copies came from a wide ranges of sources. The entries (the database) are uploaded to other C64 communities. The link is fine, it's already the new domain. I'm pretty sure the database is reliable and will stay for a long time.

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 11/26/2021 10:28 AM

Quote

phoenix1291

Joined: 7/17/2012
Posts: 543
Location: Switzerland

I allow myself to put these two videos of a French youtuber who compares 16 Commodore 64 games with the European and USA versions. The videos are in French, but there are English subtitles. The interesting thing is that some games are really different depending on the region. Link to video Link to video

My Citra 3DS rerecording movie files test repositery: https://cutt.ly/vdM0jzl Youtube playlist "Citra Tests": https://cutt.ly/AdM0wg9 http://www.youtube.com/user/phoenix1291

Posted: 11/28/2021 1:36 AM

Quote

RGL

Joined: 7/13/2017
Posts: 57

Here is some info on the whole PAL VS NTSC thing on the C64 http://unusedino.de/ec64/technical/misc/vic656x/pal-ntsc.html "Two other differences account for most of the problems related to the PAL/NTSC division. PAL systems have 312 raster lines and 63 processor cycles on each raster line. The most common NTSC systems have 263 raster lines and 65 cycles on each line. This means that PAL systems have 19,656 cycles per frame, while NTSC systems have only 17,095. PAL systems thus have about 15% more processing time for each video frame. Any PAL routine which uses up most of the available processing time will not complete in a single frame on an NTSC machine and will probably have a distorted display."

Posted: 2/25/2023 8:08 AM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

MESHUGGAH wrote:

How the database created: the author is a known archivist, specializing in C64 and Floppies. The physical copies came from a wide ranges of sources. The entries (the database) are uploaded to other C64 communities. The link is fine, it's already the new domain. I'm pretty sure the database is reliable and will stay for a long time.

Looks like it doesn't store hashsums?

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Forum BizHawk C64 - PAL or NTSC?

Forum

BizHawk

C64 - PAL or NTSC?