|
|
Post by SignOfZeta on Feb 21, 2019 23:52:17 GMT
Hmm... I see what you mean, but it still doesn't make sense. 1) The whole mapping of a ROM at bank $90 is only actually performed if the machine is NOT a TG-16, so... huh ? And it's not even a JSR, so it doesn't appear as though it could be setting anything up... just a dead-end. 2) This code actually doesn't *do* anything except check one bit on a piece of hardware. Unless, when they decided not to include the ROM, they also decided to reverse-sense that bit. But even then, why did the fall-through execute the actual game ? One would expect that "fail" should go into an infinite loop or something. 3) In any case, Gunboat and Klax used that code, but put NOPs in-between the branch and the NO_PROTECT label. So, no "NEC" string either, so no appearance of copyright. And no protection either. Given the cost dynamics of Japanese versus American systems, they would have been trying to protect things so that American machines couldn't play the much-cheaper Japanese games, but the Japanese games had nothing in them to stop them from playing. I think somebody was simply taking too many drugs or something. Dave I can’t pretend to understand half of this thread but this part puzzled me. At what point in 1987-1990 were Japanese games much cheaper than US ones? My memory is...never. Maybe a few years earlier in the Famicom days (lower cart prices and much better exchange rate for Americans) but even then...checking the prices in period adverts for import games in the US shows $60-100 as normal for PCE, way more than any US MSRP TG16 game. And I feel weird typing that because I’m pretty sure you know this too so I’m confused... The region lockout seemed pretty easy to understand in non-techncial means. They did it to protect Japan. Both from pirate carts and from reverse importing. Japanese companies still do things to discourage reverse importing. A LP box set I got this week (80s New Age music) is specifically prohibited from going on sale in Japan. Everywhere else is fine. |
|
|
|
Post by dshadoff on Feb 22, 2019 2:23:12 GMT
Given the cost dynamics of Japanese versus American systems, they would have been trying to protect things so that American machines couldn't play the much-cheaper Japanese games, but the Japanese games had nothing in them to stop them from playing. I think somebody was simply taking too many drugs or something. Dave I can’t pretend to understand half of this thread but this part puzzled me. At what point in 1987-1990 were Japanese games much cheaper than US ones? My memory is...never. Maybe a few years earlier in the Famicom days (lower cart prices and much better exchange rate for Americans) but even then...checking the prices in period adverts for import games in the US shows $60-100 as normal for PCE, way more than any US MSRP TG16 game. And I feel weird typing that because I’m pretty sure you know this too so I’m confused... The region lockout seemed pretty easy to understand in non-techncial means. They did it to protect Japan. Both from pirate carts and from reverse importing. Japanese companies still do things to discourage reverse importing. A LP box set I got this week (80s New Age music) is specifically prohibited from going on sale in Japan. Everywhere else is fine. I mentioned this on another thread, but the cost in Japan was around 4500-6000 yen for most games in this period, while the yen was about 160 to the US dollar (although getting stronger through this period). So basically, games were roughly $30US to $45US in Japan, but $60 to $70 for American versions of the same game. The fact that people spent $100+ on games when imported has nothing to do with this comparison. The prices you saw as an end consumer were based on the fact that most of those were bought at retail, shipped overseas, and had ~100% profit margin added to make it worthwhile for somebody to do. If the American machine had been more popular, the profit margin would have dropped substantially due to volume and competition. Nobody in Japan would pay for games to flow in the other direction, even with a 0% profit margin (for various reasons), so the protection was a waste of effort. Dave |
|
|
|
Post by dshadoff on Feb 22, 2019 2:45:55 GMT
If you're that far along, I should perhaps reconsider adding Tennokoe Bank functionality to the TED os.pce; it seems that your system would be *MUCH* easier to add it to (and I'll bet you've already thought about how you're going to do it). I wanted to wait until I got some more stuff working before responding, but sure, I'd be happy to work with you to add that functionality to a new TED OS. I am now able to load and run HuCard images, so I'm finally confident that there isn't anything weird that's going to bring the whole concept crashing down. It's still early-days, and there is no UI work done beyond simple debugging output, but it's time to start cleaning things up so that it can be shared. As for Tennokoe Bank functionality ... your disassembly shows that KRIKzz is enforcing a minimum cluster size of 8 sectors (i.e. 4KB). While generic file creation functions on FAT32 would be a nasty mess to write, it should be pretty easy to write something that would create a few single-cluster files (i.e. up to 4KB long) in a directory that you *know* is almost-empty ... like the "TBED" directory. The directory only contains 4 entries right now (including "." and ".."), so there's enough room in there to add another 8 files, say "BACKUP_0.SAV" ... "BACKUP_7.SAV", inside the first sector of the directory. It seems like you'd probably want to keep each file as 2KB-long in order to match the PCE's built-in Backup RAM, and to make it easy to copy and share the files. Is that the sort of system that you're thinking about? That's pretty much *exactly* what I was thinking about. I am happy with making the /TBED/BACKUP_0.SAV file set part of the original install set. (We could send out boring "empty" ones, or pre-loaded ones... just saying) I can write the portion about managing the backup memory, but I would expect to have the following available: 1) a 2KB buffer in regular memory (just tell me where) that I can move to/from as a staging area in/out. 2) a function that will locate a specific filename, and give me a "handle" if found (for example, a cluster address), or an error code if not. 3) a read function (could be 512-byte, or size could be parameterized: you tell me) which can use this "handle" (i.e. cluster address) 4) a write function with similar interface 5) an idea of what the rest of the UI is expected to look like (like a style guide - screen width, margin/borders, colors, key assignments etc. if different from existing TED), and for example any print functions which exist. Within the OS.PCE size limitations, I think we can squeeze something like: - all the existing functionality - a screen to move from BRAM to BACKUP FILE - a screen to move from BACKUP FILE to BRAM I don't think there is any additional benefit to the "swap" functionality or the "manager entries" functionality in the Tennokoe bank Having said this, within these two last screens I would still want the user to be able to: 1) validate whether the internal BRAM exists or not, and whether it's formatted - if properly formatted, list (but don't otherwise manage) the names of the entries in it 2) select a file using the direction pad (up/down), and for each file which gets scrolled to: - identify whether it exists, and whether it's properly formatted - list the names of the entries contained in it Then the user can decide whether to "commit" (different button to say "go ahead" than select; and another different button to answer "are you sure ?") Dave |
|
|
|
Post by SignOfZeta on Feb 22, 2019 2:48:56 GMT
I never paid more that $50 for any US Turbo game. I don’t think they charged more than that in the TTI era (when I got really into it) maybe earlier? I remember Black Tiger saying he paid some crazy huge prices, $90 or whatever, for games wherever he lives, Alaska or some place, but they don’t track with what I paid for stuff. I don’t rememeber any $70 US games. Maybe if you bought it at EB the day it came out, since EB had the highest prices back then? Some Googling lead me to a $59.99 advertised price for Splatterhouse in 1990. That’s the best I could do. Of course, if it didn’t flop massively and the yen didn’t skyrocket I suppose the protection would have made more sense. It still seems more like a reverse import protection. I know the Japanese market at large has no interest in this but neither does the 1980s American market have at large have any interest in playing any game with even one character of Japanese text in it. Maybe they were afraid of Color Dreams?  There is all sorts of reverse import protection crap going on. When when some crappy anime gets released here they make sure the (%90 cheaper) US version uses a lower bit rate or it has subtitles burned into the video. Regardless of the need for doing it they do it all the time. |
|
|
|
Post by elmer on Feb 22, 2019 5:33:05 GMT
1) The whole mapping of a ROM at bank $90 is only actually performed if the machine is NOT a TG-16, so... huh ? And it's not even a JSR, so it doesn't appear as though it could be setting anything up... just a dead-end. You're assuming that the hardware that shipped is *exactly* the same as the hardware that was proposed when NEC was telling developers to put that piece of code into their games. Why? Instead, look at it from the other direction. *IF* NEC had wanted to put protection into their games, then do we have any clues about how it would have worked given the hardware that shipped? I think that we do. There are spots for two extra chips on the TurboGrafx board, one Boot ROM chip, which TailChao says would have room for approx 1KB of code, and something small that looks like an address-selection IC. (BTW I'd be *REALLY* curious to know if that chip location has a line going to the bit 6 of the CPU's built-in input port.) Then, for the protection to work, you just have manufacture the USA versions of the CPU to boot into bank $90 instead of bank $00, and have the code in the Boot ROM check for the "Protection" code in the HuCard and set bit 6 of the input port if it finds that code-sequence. Then have the Boot ROM page bank $00 into MPR7 and jump to the normal HuCard reset vector. When the HuCard runs, it checks bit 6, and if it doesn't find it set correctly, it pages in the Boot ROM and jumps to a piece of code that says "This game is NOT Licensed by NEC.", and then hangs. Suddenly, and quite easily, you've got a simple hardware change that requires licensees to have a sequence of NEC-copyrighted code, plus NEC's trademarked name, inside their ROM in order for it to run on the TurboGrafx. It's not a totally *foolproof* system, but it's something that you'd have to hardware-hack your console to get around.
You've got to understand ... console manufacturers don't care too much about region-protection. That's an issue of IP-licensing more than it is about the money. They have lots of ways to limit Grey Imports *IF* they have a means to control exactly who can actually produce games for their consoles. Look at the SNES ... and the TurboGrafx. A simple physical switching of the case size on the SNES, or the data-bus on the TurboGrafx, is all that's needed to discourage imports from other regions. Sure, it doesn't make importing *impossible*, but it keeps it small and underground. What they're really worried about is losing control and money by having unlicensed publishers making games for their console and not paying the manufacturer any royalties. Now you may think that software protection like I've described is too simple, but it worked fine when the Gameboy appeared, and when Nintendo didn't even bother with a hardware lockout like the 10NES chip that they used on the US/EU release of the NES, and instead they just used a software sequence and an internal-to-the-CPU Boot ROM, just like I'm describing. For more fun, take a look at some of the licensing protection lawsuits that were going on the 1980s ... CIC (Nintendo)Atari Games Corp. v. Nintendo of America Inc.Sega v. Accolade3) In any case, Gunboat and Klax used that code, but put NOPs in-between the branch and the NO_PROTECT label. So, no "NEC" string either, so no appearance of copyright. And no protection either. Sure ... but by the time that those were written, NEC had already changed their mind on the whole idea of protection, and released the TurboGrafx without it. They just didn't care whether developers used the sequence at that point. Since it was documented as something that developers needed to do, most of them did it, even if it made no sense. Some didn't. Nobody cared. Back in the 1980s, no major American retail chain would stock shelves full of games that were in a foreign language that their customers couldn't understand. Manufacturers think about sales in terms of tens or hundreds of thousands of units to major outlets. Nobody cares about some Mom & Pop store grey importing a few dozen cheaper games from Japan to satisfy their small-but-rabid customer base of true-fans. |
|
|
|
Post by dshadoff on Feb 22, 2019 11:50:48 GMT
1) The whole mapping of a ROM at bank $90 is only actually performed if the machine is NOT a TG-16, so... huh ? And it's not even a JSR, so it doesn't appear as though it could be setting anything up... just a dead-end. Then, for the protection to work, you just have manufacture the USA versions of the CPU to boot into bank $90 instead of bank $00, and have the code in the Boot ROM check for the "Protection" code in the HuCard and set bit 6 of the input port if it finds that code-sequence. Then have the Boot ROM page bank $00 into MPR7 and jump to the normal HuCard reset vector. When the HuCard runs, it checks bit 6, and if it doesn't find it set correctly, it pages in the Boot ROM and jumps to a piece of code that says "This game is NOT Licensed by NEC.", and then hangs. Sure, your proposed system would work... but then why would the bank 0 "copyright" string look anything like it does ? It should be something obviously incriminating (to human eyes) to include. And it should be at a fixed location, rather than "wherever your entry address is". While it often happens to be at the same locations, in a significant amount of the time it is somewhere different. I'm not saying that your proposal is not what they were aiming for - it probably was. But if it was, then it was a botched job from start to finish. What they're really worried about is losing control and money by having unlicensed publishers making games for their console and not paying the manufacturer any royalties. Now you may think that software protection like I've described is too simple, but it worked fine when the Gameboy appeared, and when Nintendo didn't even bother with a hardware lockout like the 10NES chip that they used on the US/EU release of the NES, and instead they just used a software sequence and an internal-to-the-CPU Boot ROM, just like I'm describing. For more fun, take a look at some of the licensing protection lawsuits that were going on the 1980s ... CIC (Nintendo)Atari Games Corp. v. Nintendo of America Inc.Sega v. AccoladeOh, I remember these cases well. The software protection was easily overcome (but in an incriminating-looking way), but generally wasn't sufficient on a legal basis as well. The best thing going for NEC was the obscure format of the cartridge - very difficult to produce (especially at an acceptable cost) in those days. And we need to ask ourselves, why was there no similar system at NEC Japan for HuCards ? And why would the "licensing" module be introduced in the American version ? And given the time that had passed between PC Engine introduction and TurboGrafx introduction, how did they botch it up so much (the proposed ROM was abandoned after all) ? 3) In any case, Gunboat and Klax used that code, but put NOPs in-between the branch and the NO_PROTECT label. So, no "NEC" string either, so no appearance of copyright. And no protection either. Sure ... but by the time that those were written, NEC had already changed their mind on the whole idea of protection, and released the TurboGrafx without it. They just didn't care whether developers used the sequence at that point. Since it was documented as something that developers needed to do, most of them did it, even if it made no sense. Some didn't. Nobody cared. So you're saying that nobody actually communicated this to the developers ? I could believe that. Really only about a half-dozen games were in production before the machine was released; you're saying that for the other several dozen, nobody would care... plausible. Back in the 1980s, no major American retail chain would stock shelves full of games that were in a foreign language that their customers couldn't understand. Manufacturers think about sales in terms of tens or hundreds of thousands of units to major outlets. Nobody cares about some Mom & Pop store grey importing a few dozen cheaper games from Japan to satisfy their small-but-rabid customer base of true-fans. The point I was trying to make is that most of the games didn't need any localization, because there was literally (or effectively) no Japanese text. Pretty much any shooter would have done well, and needed no changes whatsoever. Or, the developer in Japan could have taken trivial effort to proof their text, and release in both markets. But that was never going to happen, because the American subsidiary apparently wanted two things which were unreasonable: 1) too much licensing money on the basis of sales which would never exist (because they put the cart before the horse, and thought about licensing before commercial success), and 2) editorial control - too many unnecessary change were made, which were simply wasted money. But the irony is that Japanese games could have made it here, and there really weren't technical barriers (recall that the protection is backwards); the Japanese companies simply weren't interested (and many still aren't) to deal with anybody outside of Japan. And we all know that the American-original games had the best protection of all, from the start: they simply weren't very good, so nobody was going to bother copying them or shipping them to another market. And that is because Japan and the West had very different ideas about what "computer games" were, but that's a whole separate discussion. Dave |
|
|
|
Post by elmer on Feb 22, 2019 18:54:25 GMT
Sure, your proposed system would work... but then why would the bank 0 "copyright" string look anything like it does ? It should be something obviously incriminating (to human eyes) to include. And it should be at a fixed location, rather than "wherever your entry address is". While it often happens to be at the same locations, in a significant amount of the time it is somewhere different. It doesn't really matter where the code is in bank 0 ... as we've found out, it takes less than 1/30s to search the entire bank for it. To be copyrightable, the code should *not* be obvious ... it actually has to do something, and it certainly doesn't need to be human-readable. That's where this whole idiotic scheme falls apart. Those few lines of code don't actually do anything significant, and any copyright claim by NEC USA could be challenged. I'm not saying that your proposal is not what they were aiming for - it probably was. But if it was, then it was a botched job from start to finish. I'm just coming up with a theory of how it *could* have worked. That doesn't mean that it would have made any real sense to do it that way. Pretty much everything that NEC USA did regarding the design/launch/marketing of the TurboGrafx was a completely botched job. And we need to ask ourselves, why was there no similar system at NEC Japan for HuCards ? And why would the "licensing" module be introduced in the American version ? And given the time that had passed between PC Engine introduction and TurboGrafx introduction, how did they botch it up so much (the proposed ROM was abandoned after all) ? NEC Japan didn't seem to want to be in the software-licensing business, they were happy being hardware manufacturers, and charging software companies for making the proprietary HuCards. I imagine that the whole push to the "licensing" model came from the American videogame marketing geniuses at NEC USA. Then, at some point, someone in Japan finally told them "No, we're not going to do that.". Or, the developer in Japan could have taken trivial effort to proof their text, and release in both markets. But that was never going to happen, because the American subsidiary apparently wanted two things which were unreasonable: 1) too much licensing money on the basis of sales which would never exist (because they put the cart before the horse, and thought about licensing before commercial success), and 2) editorial control - too many unnecessary change were made, which were simply wasted money. I think that all Western PCE fans are amazed at just how badly NEC USA messed things up. |
|
|
|
Post by spenoza on Feb 22, 2019 19:20:43 GMT
To be copyrightable, the code should *not* be obvious ... it actually has to do something, and it certainly doesn't need to be human-readable. That's where this whole idiotic scheme falls apart. Those few lines of code don't actually do anything significant, and any copyright claim by NEC USA could be challenged. Well, this was NEC US, and copyright in the US is not predicated upon function but rather creative expression. For something to be copyrightable it must have some creative element. One cannot copyright facts, but one can copyright a specific arrangement and organization of facts. That's how encyclopedias and factual works get copyrighted. Even with the extra leeway given computer code, I do not think, based on your description of their code, that it would be a shoo-in for copyright, but I could also see a copyright being granted on it. That said, it would be easy for a would-be unlicensed publisher to simply write new code that does the same thing. Since copyright in the US does not protect function but rather expression, a new expression of code that performs the same essential function would not violate copyright. Modern laws concerning bypassing DRM restrictions MIGHT stop something like that, but those laws didn't exist then. The best protection was indeed the format itself. Also, let's keep in mind that NEC actually had to pay a licensing fee to Hudson for every system sold. Hudson was definitely in the licensing business. I don't know about NEC's business model, so I can't say whether they passed that along in Japan. |
|
|
|
Post by dshadoff on Feb 23, 2019 20:34:15 GMT
My point was that copyright on computer/videogames had not yet been seriously tested yet at that time; they usually felt initially that a better case was based on violation or misrepresentation of a licensing relationship. If I recall correctly, this was Sega's deal - that their startup screen showed a licensing message, and therefore if that screen showed without a valid licensing relationship, it would misrepresent the relationship, and they felt that would be the best approach (although it could also be considered entrapment, or even Sega's own misrepresentation).
Back to NEC, In order to prove copyright, the snippet would have had to be *obvious*, because nobody back then - courts, juries, etc. was technical enough to understand whether a specific 7-to-19-byte snippet was clearly a unique and a deliberate copy, or could be merely coincidental. Fair use also allowed short excerpts to be used for various reasons. And the idea of using that "copyrighted" snippet as a barrier to deny competition was also an untested concept.
So referring back to my original statement, using the text " NEC " seems a bit weird. This text could actually be a jump to subroutine at $454E, followed by another opcode. If it were a longer sentence, it would obviously be text, and therefore lose the ambiguity.
NEC's approach on the CDROM boot sector was closer to the approach I mentioned above (re: Sega), and would have been easier to discuss in a court (although whether it would have been persuasive is another matter). Probably enough for Japan, but hard to say about the USA, because of the heavy-handed lockout. In any case, Games Express avoided it altogether by creating their own boot card.
|
|
|
|
Post by elmer on Feb 24, 2019 19:01:24 GMT
My point was that copyright on computer/videogames had not yet been seriously tested yet at that time; they usually felt initially that a better case was based on violation or misrepresentation of a licensing relationship. IIRC (and I could easily be wrong), it was misuse of a Trademark rather than misrepresenting a licensing relationship. Trademark law was/is pretty strong all over the world, including places that didn't recognize software copyrights. I believe that's why Nintendo made the Gameboy's "protection" be a small piece of code that displays the "Nintendo" logo on the screen. Even if the code itself was challenged, any unlicensed company would still be including code that actively displayed the "Nintendo" logo without permission. Back to NEC, In order to prove copyright, the snippet would have had to be *obvious*, because nobody back then - courts, juries, etc. was technical enough to understand whether a specific 7-to-19-byte snippet was clearly a unique and a deliberate copy, or could be merely coincidental. Fair use also allowed short excerpts to be used for various reasons. And the idea of using that "copyrighted" snippet as a barrier to deny competition was also an untested concept. So referring back to my original statement, using the text " NEC " seems a bit weird. This text could actually be a jump to subroutine at $454E, followed by another opcode. If it were a longer sentence, it would obviously be text, and therefore lose the ambiguity. But a sentence isn't, by-itself, enough to be a "creative" work that could be copyrighted in US law. Honestly, IMHO, neither is the simple test that is in the US HuCards. It's just testing a bit and branching.
Perhaps the " NEC " string would have been displayed on the screen by the TurboGrafx BIOS ... by then that still wouldn't have been enough, because the code on the HuCard doesn't *actively* do anything to display that logo. It's all a half-thought-out mess. Which might be why the whole idea was finally dropped. NEC's approach on the CDROM boot sector was closer to the approach I mentioned above (re: Sega), and would have been easier to discuss in a court (although whether it would have been persuasive is another matter). The code in the boot sector is much more substantial, and is actually "creative" in my opinion. There are lots of ways to do what that bootloader is doing, and the particular sequence and options that are in it would probably count as unique (IMHO). As you say, whether it would have actually held up in court is a different matter. |
|
|
|
Post by elmer on Mar 1, 2019 5:56:01 GMT
What I was doing is to confirm your work, and to find out some extra information that you didn't specify ... I wanted to know where those region-checks are in the HuCards. They're all in the first bank (not surprising, but it's good to have that confirmed). It also shows that the tests are not in all 32 pages of the bank, so it opens-up the possibility of optimizing the search/removal. I was getting the horrible feeling that I was missing something, and so I checked again. The protection code is supposed to be run as soon as the HuCard is started, so I compared the location of the protection code in every TurboGrafx HuCard with its Reset Vector. Errrrr ... wow!  Every TurboGrafx HuCard that includes the protection sequence (except one), executes the protection code immediately, i.e. it is located wherever the Reset Vector points to. The one exception is Order of the Griffon. Therefore, the code to remove the region-protection can be reduced to simply checking two specific locations instead of searching through the whole of bank 0. That reduces the time taken from approx 175,000 cycles in the TED2's routine, to 219 cycles. That's nearly 1,000 times faster! Here is the code ... ; ***************************************************************************
; ***************************************************************************
;
; tos_fix_region - Search for and patch the TurboGrafx region test.
;
; Takes 219 cycles if the code is found, less if it is not.
;
tos_fix_region: lda #$4F ; Map in TED2 512KB bank 4.
sta TED_BASE_ADDR + TED_REG_MAP
lda #$40 ; Select bank 0 of the HuCard
tam3 ; image in TED2 memory.
clc ; Try 6 bytes after the reset
lda #6 ; vector.
adc $7FFE
sta <__bp + 0
cla
adc $7FFF
and #$1F
ora #$60
sta <__bp + 1
bsr .find_start ; Test for the code sequence.
lda #<$6391 ; Try $E391 in HuCard bank 0.
sta <__bp + 0
lda #>$6391
sta <__bp + 1
.find_start: lda [__bp] ; 1st byte of region code?
cmp #$AD
bne .finished
cly
.test_loop: iny ; Check for the rest of the
lda [__bp],y ; code sequence.
cmp .sequence - 1,y
bne .finished
cpy #5
bne .test_loop
.patch: lda #$80 ; Patch in BRA instruction.
sta [__bp],y
.finished: rts
.sequence: db $00,$10,$29,$40,$F0
|
|
pokun
Gun-headed
Posts: 85 
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 4, 2019 16:45:39 GMT
Great job everyone and thanks for sharing this!
I don't think it's a JSR $454E since the source code says: "db ' NEC '". The " NEC " string is at the end of the 25 byte protection routine so I guess it might just be a signature used to easily find the routine in the ROM for manual or automatic checks. According to this (from Dave Shadoff's site I believe) the source code was first "leaked" by Nimai Malle sometime around 1996. In here it seems the NEC string is missing the trailing space though, so he might have rewritten the code for the sake of posting it and made a mistake. But the full code appears to be those 25 bytes. Elmer what manual page and section does that protection code comes from? I don't recognize it. BTW I checked Klax and it seems to have the full 25 byte code right at the beginning of the ROM. No NOPs. 78 54 A9 FF 53 01 AD 00 10 29 40 F0 0C A9 90 53 04 4C 00 40 20 4E 45 43 20Is there something wrong with my ROM (it's from no-intro)? Gunboat has NOPs though and Ghost Manor does not seem to have the code at all as expected. I guess it's always possible there are multiple versions of Klax of which not all has been dumped. The region lockout seemed pretty easy to understand in non-techncial means. They did it to protect Japan. Both from pirate carts and from reverse importing. Japanese companies still do things to discourage reverse importing. A LP box set I got this week (80s New Age music) is specifically prohibited from going on sale in Japan. Everywhere else is fine. From reverse importing, possibly, but this region lockout code can not be used for locking out pirates like Nintendo's lockout chips does. Nintendo has a key chip in the cartridge and a lock chip in the console so that only Nintendo could make the carts (although Tengen cloned the key chip for NES as mentioned above). The lock on PC Engine however is in the software of the HuCard and the key is in the console in the form of a single pin that is wired in one way on PC Engine and in another way on Vistar/TurboGrafx-16/TurboGrafx, and the code checks this pin and freezes the game if it detects a PC engine. If the game contains no lock, the key doesn't matter. A game is by no means forced to have the lock so it won't prevent pirates from creating unlicensed HuCard games. |
|
|
|
Post by elmer on Nov 4, 2019 20:21:50 GMT
Elmer what manual page and section does that protection code comes from? I don't recognize it. "Hu7 System 2 Technical Manual 1", First Edition, page 147 ... as supplied to North American TurboGrafx-16 development teams. |
|
|
|
Post by ndiddy on Mar 29, 2020 5:34:20 GMT
Elmer what manual page and section does that protection code comes from? I don't recognize it. "Hu7 System 2 Technical Manual 1", First Edition, page 147 ... as supplied to North American TurboGrafx-16 development teams. Is the manual public? I don't see that snippet (or page number) in any of the manuals you posted. |
|
|
|
Post by elmer on Mar 29, 2020 20:36:47 GMT
Is the manual public? I don't see that snippet (or page number) in any of the manuals you posted. No, the whole manual has not been scanned, because it doesn't contain any particularly-useful information for modern developers. I already posted a scan of that one page here ... pcengine.proboards.com/post/8141/thread |
|
There is all sorts of reverse import protection crap going on. When when some crappy anime gets released here they make sure the (%90 cheaper) US version uses a lower bit rate or it has subtitles burned into the video. Regardless of the need for doing it they do it all the time. 
