How incompatible does the old divider have to be to require this clause in the first place? If a compatible machine was available back then, it's a pro. If the gameplay doesn't change, it's a pro.
It'd probably be game dependent, but it's theoretically possible that changing the CPU divider by as little as 1 could completely invalidate a .jrsr input file.
EDIT: I have to admit that c-squares chart of average clock speeds is definitely a more simplified resource than the big chart I did. I'd suggest either as being valid values for jpc-rr TASes.
That's not what I'm asking at all. I don't mean incompatible with a movie, but incompatible with the perfectly legitimate architecture.
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.
Hi feos,
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
Castle Adventure (1984) by Ilari & Truncated
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Hitchhiker's Guide to the Galaxy (1984) by c-square
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Space Quest 1 (1986) by DrD2k9, c-square & Radiant
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 55 (18 MHz)
All other DOS runs are actually considered "underclocked", which is allowed by the new rules.
Hi feos,
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
Castle Adventure by Ilari & Truncated
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Hitchhiker's Guide to the Galaxy (1984) by c-square
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Space Quest 1 (1986) by DrD2k9, c-square & Radiant
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 55 (18 MHz)
All other DOS runs are actually considered "underclocked", which is allowed by the new rules.
Curiosity on SQ1, does the year (1986) consider the game/interpreter version?
For that matter how should we consider game versions released in later years than the original game? (sorry if this was already answered somewhere else)
Regardless of the answers to the above questions: I'd be willing to eventually re-do SQ1 at an appropriate CPU divider setting, if the resulting video has the opportunity to obsolete the current publication even though it may be a slower overall run due to the slower CPU setting.
Curiosity on SQ1, does the year (1986) consider the game/interpreter version?
For that matter how should we consider game versions released in later years than the original game? (sorry if this was already answered somewhere else)
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
How does gameplay change between the divider that was used and the one that should be used?
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.
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
How does gameplay change between the divider that was used and the one that should be used?
The currently published runs play faster than they would under the new rules. That should be the only change between a faster divider and a slower divider.
For what it's worth, I have no intention on revisiting the HHGttG run, so the grandfather rule isn't a big thing for me. I'm much more interested in having a list of one CPU divider per year to keep the choice simple without needing extensive research or fear of rejection due to someone digging up a specs doc after submission.
I'm much more interested in having a list of one CPU divider per year to keep the choice simple without needing extensive research or fear of rejection due to someone digging up a specs doc after submission.
I think a list of one CPU Divider per year is a very good idea as a resource for new DOS TASers. It would give them a quick reference to know how to setup JPC-rr and know their run is 'safe' from being rejected for the reason of bad emulator settings.
However, I don't think all DOS TASes should be concretely limited to that list; simply because there was variability in real systems, and utilizing variability (within reason) that still yields a valid system environment should be acceptable for the site.
EDIT: Side note regarding SQ1. The published run uses version 2.2 which was released in 1987. Therefore it's not overclocked, and could theoretically be run even faster than what it is.
I think a list of one CPU Divider per year is a very good idea as a resource for new DOS TASers. It would give them a quick reference to know how to setup JPC-rr and know their run is 'safe' from being rejected for the reason of bad emulator settings.
However, I don't think all DOS TASes should be concretely limited to that list; simply because there was variability in real systems, and utilizing variability (within reason) that still yields a valid system environment should be acceptable for the site.
We're in full agreement here. feos, any objection to making this happen?
The safest way is just following the official instructions. If that's not available, going for the most common CPU speed of that era is also safe. I wish the table gave some insight about popularity.
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.
The safest way is just following the official instructions. If that's not available, going for the most common CPU speed of that era is also safe. I wish the table gave some insight about popularity.
This is why I think the trend line works very well, as it is likely the closest we can get to the most common CPU speed of each year with the information we have.
I googled around to see if I could find data on market share of various microprocessors, but couldn't find anything older than about 2008. What I found was pretty much dominated by Intel and AMD.
I'm sure the information is out there somewhere, but I've got no other ideas on how to find it.
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
How does gameplay change between the divider that was used and the one that should be used?
The currently published runs play faster than they would under the new rules. That should be the only change between a faster divider and a slower divider.
For what it's worth, I have no intention on revisiting the HHGttG run, so the grandfather rule isn't a big thing for me. I'm much more interested in having a list of one CPU divider per year to keep the choice simple without needing extensive research or fear of rejection due to someone digging up a specs doc after submission.
Choosing an unverified custom initial RAM state which is identical to the state used by default for another accepted emulator for the same platform is frowned upon, but is allowed for compatibility reasons.
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.
