Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


DZ-Jay last won the day on December 30 2016

DZ-Jay had the most liked content!

Community Reputation

6,544 Excellent


About DZ-Jay

  • Rank
  • Birthday 12/13/1970

Profile Information

  • Custom Status
    The P-Machinery AGE is almost here!
  • Gender
  • Location
    NC, USA
  • Interests
    Music, books, video games, and programming.
  • Currently Playing
    Various Intellivision games...
  • Playing Next
    Some more Intellivision games...

Recent Profile Visitors

36,631 profile views
  1. Sorry, my comment was meant as a joke in response to C-Mart’s comment. So I will end with the obligatory ... WHOOOOOOSH! :)
  2. I disagree. The price sticker is mildly interesting, but the "new" sticker is lame. dZ.
  3. Today, Ghostbusters ... tomorrow, Fortnight! 👍🏻
  4. I just caught up. So everything is working then? Yay! 👍🏻 Good job, guys!
  5. Ah. So the one gone missing is the HK without the white sticker. Gotcha.
  6. A couple of people have already asked me about purchasing the LTO Flash! and Christmas Carol units. To be honest, all those Christmas Carol units were always intended for my own personal collection and for my family, so I do not intend to trade or sell them ever. The LTO Flash!, however, I purchased a few in order to have something of value to trade. So, if anybody is interested in trading some item or items missing from my collection for a brand new, sealed, LTO Flash!, I'd be open to the idea. I am not really looking for variants, and I do not really care about INTV Corp. titles; I tend to collect Mattel Electronics games, because that's what I had when I was a kid, and anything else that is actually a good game that I'd like to play. Also ... I'd be willing to trade a sealed LTO Flash! for a Cuttle Cart 3 (CC3) cartridge in good and working condition. I know some people think that's a little odd, but I currently have a CC3 and use it for play-testing my games in development on the console, and I prefer not having to muck about with additional software and stuff -- especially because my personal computer is old, obsolete, and finicky with newer software. The fact that I can transfer files to the CC3 from any PC via the MicroSD card easily, is a feature I enjoy. I would like to have a spare CC3 in case the first one goes kaput. -dZ.
  7. I have three 5161-0910, two of which are made in USA, and one made in Hong Kong. The USA ones do not have the plastic cartridge holder, but the Hong Kong one does. It seems to be an edition for the Australian market, for it includes a large label in the inside cover describing the 90 day limited warranty, from "Lifestyle Electronics" in New South Wales. It also includes a copyright notice label pasted on the bottom lid specifying the following: Copyright Mattel, Inc. Distributed by Lifestyle Electronics Cartridge made in Hong Kong Controller Overlays Printed in USA Balance made and printed in Hong Kong Manufactured by Mattel Electronics (H.K.) Ltd. Trademark Mattel, Inc. The box is of a slightly "bluer" blue color, if you know what I mean: a little darker and deeper than the USA ones. I am missing the instruction manual for this Hong Kong variant, but I have the box, the cartridge, the plastic holder, and overlays. It also included an insert leaflet for registration from Lifestyle Electronics, which I gave to Rev. (I kept one from another Australian game.) Is this the variant you are looking for, @BSRSteve? -dZ.
  8. Well, I know I have terrible memory. Hehehe. And you are right that you will need to follow that in order to replicate the original mechanics of PK computation for the end game. That is true, although I imagine it could have been a consequence of stringing together the mini-games with minimum global state. It seems like a more natural approach (which is why it felt right to assume the original did), but it may precipitate the end game, preventing the player from catching more ghosts and making more money. I guess it is something to test once the entire game is finished to see if it works well. If it doesn't affect the difficulty balance or progression significantly, then I still believe your current implementation is the superior approach. Besides, there is already a $500 masterpiece that is a perfect replica of the original, so less pressure on you to attain 100% fidelity. dZ.
  9. Ah, no worries. I can't wait to play it but ... really, I can wait for it to be ready. 😉 I don't really remember, but I think it did. In any case, I agree that it feels right to do that. Plus, players can enter any code generated from one of those Account Generators on the Web, or the ones they noted down when they were kids. 👍 -dZ.
  10. No worries. I tend to edit instead of posting new messages. I re-posted it anyway. I'm really excited about your game, and I can't wait to test it. (hint, hint!)
  11. That'll work! Or you could switch "#check_byte" to an 8-bit variable and avoid the hassle. name_checksum = $05 ' Iterations check_byte = $2C ' BCD high-byte + low-byte tmp = 0 FOR I = 1 to name_checksum ' Compute temporary obfuscation code tmp = ((check_byte * 2) XOR check_byte) tmp = ((tmp * 2) XOR check_byte) tmp = ((tmp * 4) XOR check_byte) ' Compute check-byte check_byte = (check_byte * 2) IF (tmp AND $80) THEN check_byte = (check_byte OR 1) END IF NEXT There really is no need to consume a 16-bit variable on this. -dZ.
  12. Well, that's easy, it's because I forgot to "AND $FF" to the 16-bit variable. DOH! In reality, all these variables should be 8-bits, because the original software was written for 8-bit processors, so no values would go higher than a byte, and so the algorithms sort of expect it. This is why the BCD balance amount is stored in two bytes. You could store it in 16-bit memory, but then you'll have to manipulate it if you want to add both upper and lower bytes. I should really check my code before posting. Here's the updated code name_checksum = $05 ' Iterations check_byte = $2C ' BCD high-byte + low-byte tmp = 0 FOR I = 1 to name_checksum ' Compute temporary obfuscation code tmp = ((check_byte * 2) XOR check_byte) tmp = ((tmp * 2) XOR check_byte) tmp = ((tmp * 4) XOR check_byte) ' Compute check-byte check_byte = (check_byte * 2) IF (tmp AND $80) THEN check_byte = (check_byte OR 1) END IF NEXT Because the variables are 8-bit, the overflow will be discarded on every store. Alternatively, just add "AND $FF" to all expressions where the value is stored on a 16-bit variable. -dZ.
  13. But you must know that that was part of the fabulous design, and it is definitely superior -- enough to warrant at least half of the price. -dZ.
  14. You are right, I missed the "%4" from your code, but that's not right either. Looking more at the code, I don't think it is a simulation of rotate at all; it only looks like that with the example. Your %4 also is also a misdirection, although it works on the $2C example value as well. The Python code clearly shows that the $80 is tested on every iteration (in Python, nested code blocks are defined by indentation, so all indented code following the "for" statement is part of the iteration block). The key is that the test is not performed against the shifted value in the iteration (#check_byte), but against a computed temporary value, which is a combination of shifts and XORs. The actual check-byte is merely shifted to the left, not rotated. I think that's just more obfuscation. David Crane has said that they spent considerable effort in obfuscating the code to keep curious players from discovering the algorithm by observation alone, and to prevent randomly entered values from working. So the correct logic in IntyBASIC should be: #name_checksum = $05 ' Iterations #check_byte = $2C ' BCD high-byte + low-byte tmp = 0 FOR I = 1 to #name_checksum ' Compute temporary obfuscation code tmp = ((#check_byte * 2) XOR #check_byte) tmp = ((tmp * 2) XOR #check_byte) tmp = ((tmp * 4) XOR #check_byte) ' Compute check-byte #check_byte = (#check_byte * 2) IF (tmp AND $80) THEN #check_byte = (#check_byte OR 1) END IF NEXT -dZ.
  • Create New...