Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

tep392

Global Moderator
 View Profile  See their activity

  • Content Count

    3,397

  • Joined

  • Last visited

  • Days Won

    16

Posts posted by tep392

  1. Posted

     

     

    It's actually different, which is why I said it's not a bug. It is a natural consequence of the collision detection mechanism that was chosen, there is no way around it. The "fix" would be to implement a different collision detection mechanism. The designers thought the simple mechanism worked 99% of the time, and the 1% chance of it failing was an edge-case rare enough that it was not worth spending effort in doing something better.

     

    It's like the "side trap" in Centipede: it's not a bug, it's the way the game works which opens itself up to exploitation.

     

    You are right that you need a pattern to exploit it reliantly, since it depends on the precise position of the sprites and their velocities. These factors are purely deterministic in Pac-Man, and therefore, they can be measured and exploited.

     

     

     

     

    I believe, that the original Donkey Kong arcade game uses regular pixel collisions or bounding boxes, not grid-tile positions like Pac-Man. I don't know about Donkey Kong for 7800, though.

     

     

     

     

    Haven't played it, but if they implement the collision detection in the same way as the arcade, then it'll happen as well. My Intellivision game, Christmas Carol, started life as game engine I implemented for a Pac-Man clone, so it has the same grid-based tile positional collision detection as Pac-Man, and sure enough, people have managed to find the same glitch. You can also build patterns due to the same deterministic nature as Pac-Man.

     

     

     

     

    :thumbsup: :thumbsup: :lol:

     

     

    -dZ.

    This is an interesting debate. I totally understand what you are saying about it be a consequence of the collision detection method, and not a necessarily a coding error. But I still tend to consider it a bug. The question in my mind is whether or not it is an intended "feature". If it's just an accident that they didn't intend, then I would personally call it a bug. I not convinced they want the player to be able to pass thru the ghost. They may not have even known about it when it was first released. Who knows. It would be a fairly easy fix though. Instead of check for collisions after all ghosts and pac-man have had their positions updated, they could check for collision after the ghosts have moved, but before pac-man has moved. Bug or feature, I just consider it a quirk of the game that has been a fun part of Pac-man lore.

    • Like 2

  5. Posted

     

     

     

    It uses the same movement logic for the ghosts/monsters, so strategy should be the same as you would use on the arcade version, but the patterns don't work because the maze geometry doesn't match the arcade version. It's shorter and has few dots. It should be possible to develop new patterns for it.

    The game was absurdly easy (due to how less unpredictably the pink monster moved in certain positions relative to the player), as well as other behavior oddities, including more 'safe' zones where you could simply go AFK (the arcade version only had one or two, and it was not always reliable).

     

    Although most are still recognizable, the strategy is completely different for some of the ghosts.

    The only two that act like their arcade counterparts are Blinky and Sue (Clyde).

     

    While pinky still tries to cut you off and will move in the direction you are moving if you are close to him (meaning, you can make him run away from you if you approach him closely at an intersection), certain tricks (or bugs) that are present in the arcade version will get you killed here. One example: when Pinky is moving north, approaching him from the right (moving left) on the arcade machine will have him keep moving up or left (forgot which). However on the 5200 version, he just comes right at you instead, if he can't turn left. This behavior was fixed in MS-Pac-Man, which is a better port, although it is still plagued with inconsistent slowdowns when gobbling pellets.

     

    Also, Inky does not move anywhere near like his arcade counterpart does.

     

    The Ms-Pacman version is more authentic. I still loved pac-man to death on the 5200, until I got the ms pacman version!

     

    Do you know I was responding to a question about "Pac-man Arcade", my homebrew?

  8. Posted

    The XEGS IS a real Atari computer and can be used to program the cart. You'd probably need the optional keyboard though. Do you have the keyboard?

    Is the keyboard needed to boot an ATR to flash the cart? To keep things simple he should just get the Atarimax programmer. Once programmed, he can navigate the cartridge menu with the joystick. But then a lot of games do use the keyboard for various functions, so it's not a bad idea to get one eventually.

  9. Posted

    I tend to go with the simplest theory. The input file/save state technique is pretty complicated and tedious. He's good enough to play thru to the kill screen, so he really just needed some help with the odds on the points. It would be pretty easy to hack the ROM to improve the odds. It would really only take a few bytes of code changes. I'm no pro coder, but I could do it. For either method to happen, I'm guessing he would have needed help, so there is probably some others involved in the scam.

     

    I also wonder if it couldn't be hacked to reduce the odds of barrels and firefoxes going down the ladders. I saw lots of times in his video were he did risky moves going up ladders when there was a firefox moving across the top. Almost like he knew they wouldn't go down. The logic uses probablility so there is no way to know.

     

    I checked out the current champs 1.2M game and he really is much better than Billy at generating points on the barrel screen. He has amazing reflexes.

  10. Posted

    A bit of a noob question here, but I've never ordered from the site before and am extremely confused. I recieved the 1 MB MaxFlash today, but I didn't receive the adapter to load roms onto it. From what I've seen, this is supposed to be included and necessary for transferring roms onto it. Is there something I'm missing?

    You should read this post. The first couple topics will be very helpful.

    http://atariage.com/forums/topic/176545-topic-for-newbies/?do=findComment&comment=2199612

  15. Posted

    Around here you have to pay to recycle CRT TV's. Some dumps will not take them and the ones that do they make you pay them a fee. With that said I believe Best Buy and some of my local Recycling centers WILL accept Trinitrons for free, but that is the ONLY CRT they don't charge for.

     

    Keep an eye out because certain days out of the year at least in my area places hold free recycling days. I actually seen we have one this Saturday and here I paid $20 to recycle on old CRT TV last year. It was not a great one and the sound was distorted and low. I tried giving it away for months and finally just gave my dad $20 and told him to take it to his dump, they take them for $20 there.

    I just read a craigslist add from a guy offering up to $50 to buy a Sony Trinitron. He only wanted a Sony. Craigslist and Facebook marketplace are still good sites for finding cheap or free CRT's.

  16. Posted

    Do they make HDTVs that handle de-interlacing??

    This question made me flashback to the early days of HD when I would spend a lot of time comparing the quality of the deinterlacing from my cable STB and upscaling DVD to my HD set, trying to decide if I should send the 480i material as-is to the TV or let the STB do the deinterlacing/upscaling.

  18. Posted

     

    I always liked Happy products more. But to be honest, not sure it is fair comparison in this case. In first place the Happy doesn't really copy this disk, the BitWriter does. Also I think they have different targets. The Happy was more a product to the general public, specially with the track buffer that makes it so fast. SA products, and the original The Chip, IMHO, really targeted the hacker.

    Although the Happy doesn't produce a true copy, it's a good option for someone who is just looking for a way to run off a backup to keep the original safe. The speed boost is of course very welcome. If I had a second 1050, I would put a happy in it just so I could have both. I have two 810's, one Chip and one Happy.

     

    Now I'm wondering what's actually on the Happy backup. I created one on my 810 Happy drive. What do the long tracks look like on the Happy backup? Looks like I have something to do tonight. :)

  19. Posted

    This has been very educational. I can see that backing up the more sophisticated copy protection schemes requires knowledge, analysis and some trial and error. Happy was smart to do the up front work and provide files to their customers to make it user friendly. I feel like CSS kind of left people out to dry with the Archiver products by making them figure out the details needed to make a backup on their own. While the SA and Bitwriter are a powerful hardware and software, it is far from user friendly.

  20. Posted

    Are those two sectors with the same sector number? I'm not familar with the FDC. If two sectors with duplicate sector numbers were spaced so closely, it would not be reliable to read the second sector unless it was done at just the right time. If duplicate sectors can be read by the application, then I don't know why it would be difficult for the archiver program to use an algorithm that would find the duplicates. Seems like that would be a very fundamental requirement of any sector copier.

     

    edit: thinking about this more, I guess I don't understand how that second header can be read reliably.

     

    2nd edit: I found some documentation on the FDC so now understand it is scanning every byte in a track until it finds the header with matching track#, sector# and crc. So I'm back to thinking it should not be difficult to find all the sectors by sequentially requesting the same sector number. Looking at the sector scan I posted yesterday, it appears that is how they are actually read as the program is loaded.

  21. Posted

    I did a few track and sector traces that might be helpful. The track trace counts how many sectors have been read from each track. It is the sum of booting syncalc and booting the SA trace progam, which is necessary to download the data from the drive. Tracks 16,17,20 are the tracer program. Tracks 5-14 are the main program for Syncalc, (Axlon version). You can see that some tracks have 34 sectors read, but when you look at the sector trace I did, it appears some sectors are read multiple times, or they could be duplicate sectors numbers. There is limited space to store the sectors, so I didn't quite get the entire track 7 traced.

     

    post-24519-0-08204500-1523331465_thumb.jpg

    post-24519-0-00258100-1523331474_thumb.jpg

    post-24519-0-24828200-1523331482_thumb.jpg

  22. Posted

     

    I'm afraid the pictures are not very useful for distinguishing the (minor) version. And certainly not the manual. Many titles were recorded in multiple versions that I used to call "types". The actual software might be exactly the same. But the loader or the protection might be different.

     

    I understand you are reluctant to ship the disk, but as DjayBee suggested, making a plain sector copy will probably let us know if it is a different version than the ones we have or not.

     

    I wouldn't be surprised that the SA software is missing some sectors on those tracks. The layout is very, very tricky. Just that as we said, the wrong sector level analysis is not fatal for the bitwriter.

     

    Is there a program I can use to make an image file that I could then upload for you to inspect?

  23. Posted

    The template book is dated 1985 and the main manual is dated 1983, 1985. I don't think these are unique. I see them on Ebay all the time. I re-checked using the 3.02 editor program and it confirmed the sector counts from the bitwriter program.

     

    An interesting observation of this disk is that it loads from different tracks if I boot on my 800 with Axlon RAM (tracks 5-14) than it does on my 800XL with U1MB (tracks 29-38). Also, it only supports 64K extra RAM on the 800XL (84k free) while supporting 256K Axlon on the 800 (245k free). So the 800 is the superior machine for SynCalc. :)

     

    post-24519-0-36005600-1523318435_thumb.jpg

    post-24519-0-66325700-1523318449_thumb.jpg

    post-24519-0-69324400-1523321587_thumb.jpg

    post-24519-0-57170200-1523321598_thumb.jpg

  24. Posted

    I'll post some pics later of the disks, and manual pages with publication dates. If someone in the Peoria IL area has a Kryoflux, I'll let them copy it, but I don't want to mail the original and risk loss/damage. These are the sector counts identified by the bitwriter.

     

    sector count - track

    0 - track 15

    17 - track 04

    18 - tracks 0-3, 8-10, 18-20, 26-28, 39

    21 - tracks 5-7, 11-14, 16-17, 21-25, 29-38

  25. Posted

    It could be that the bitwriter s/w misidentified the number of sectors on the long tracks. As you said, it doesn't matter though since it's still going to copy all the bits.

     

    I just re-copied track 4, making sure the fuzzy sector feature was enabled and that fixed it. The copy works now! :D Skew didn't seem to be a factor because I used 3.02, not 3.12 which is the skew version of the archiver/editor. So copying took multiple steps.

     

    1) copy entire disk with 3.02 making sure phantom sectors are enabled with P+ option. If you know which tracks are long ahead of time you can set it to not copy them. I would sometimes get logic read-write errors as it tried to write the long tracks, so it may actually be necessary to identify the long tracks first and exclude them.

    2) copy long tracks with bitwriter program. If you are copying an original disk, make sure "write splice" is enabled. If it's a 2nd gen copy, the option is not required. When using the long track copy option, it will ask how many sectors per track for the tracks you want to copy. I just entered 18 and let it do it's scan so I could identify the number of sectors for each long track, which was 21 for this disk. Then I aborted the copy and restarted using 21 as the parameter. It then only copied the tracks with 21 sectors.

     

    Perhaps it would have been better to reverse the order I used and identify/copy the long tracks first, then use the 3.02 program to copy the remaining tracks to avoid the write errors that slowed it down.

     

    It was fun using the Bitwriter to do what is was intended for!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...