Farb

I believe that in the original, each animal type did a different amount of wall damage so certain types broke out quicker than others.

It looks like a good start. I agree with Goochman that it is running too slow -- both the player (especially vertically) and the animals. In the original, the animals would attack multiple sections of wall at a pretty good clip so you were forced to go back and forth to keep them contained. Keep in mind that the "real" goal of Zookeeper was not to keep the animals contained -- it was to set things up so that you could create clusters of animals outside the enclosure that you could jump over. Jumping over one animal gave you 100 points, 2 at once is 500, 11 animals at once is 1000000, etc. The animals would always move away from the player as they left the enclosure so you could "force" them all to move in the same direction. Different animal types also moved at slightly different rates so you could time the jumps when they were clustered together as much as possible. I would think the large variation of the animal sizes in your video would make this goal much more difficult. Also, the player's sprite was animated in such a way that it was easy to see his feet and the collision detection was set up so that touching an animal with the front of his foot didn't kill him. It made it easier to coordinate and time the more ambitious jumps. Ideally, the strategy after the first couple of levels was to let all the animals out, do as many high point jumps as possible and then use the "net" to get them back into the enclosure in the last few seconds before the timer ran out. Most levels timed the appearance of the net near the very end so it became a mad scramble to capture as many animals as possible. EDIT: I forgot to mention that being able to change directions in mid-air was an important capability as well. I don't believe animals ever changed direction. EDIT EDIT: It also seems like your player doesn't jump high enough to clear the animals. It seems like he's jumping on them rather than over them.

A quick update: I implemented the 810 firmware retry logic and that has further improved compatibility. Of the 100 ATX images I test with, 100% are working. I will need to expand the images I test with now These changes should be in the next release of the firmware.

I'm not sure what is more amazing - the phenomenon itself or the work you guys did to figure it out! Sent from my ONEPLUS A6003 using Tapatalk

a8preservation.com has a highly curated list of disk, cassette and cartridge dumps from confirmed, original media. Sent from my ONEPLUS A6003 using Tapatalk

Hehe, sorry, I'm afraid not. ijor is a long-time contributor to our preservation project and the author of the ATX specification. I'd send it to him for free if I could - I just don't know how to easily get my hands on an SIO cable :-P Here are the parts I ordered for my last one and it worked fine: https://www.aliexpress.com/item/2-8-inch-TFT-color-LCD-touch-screen-module-for-Arduino-UNO-MEGA2560-R3-Development-board/32831754174.html?spm=a2g0s.9042311.0.0.4fc74c4dsRrZrr https://www.aliexpress.com/item/2016-high-quality-One-set-UNO-R3-CH340G-MEGA328P-for-Arduino-UNO-R3-NO-USB-CABLE/32697443734.html?spm=a2g0s.9042311.0.0.4fc74c4dsRrZrr https://www.aliexpress.com/item/50Pcs-1N5819-5819-1A-40V-SCHOTTKY-DIODE-NEW/32216810320.html?spm=a2g0s.9042311.0.0.4fc74c4dsRrZrr

If you send me an SIO cable, I will send you an SDrive Max :-)

Thank you for taking the time to do this, Fred!

Hi all, Does someone have an Atari 810 drive and one or more of the following Databyte releases: Mr. Robot and His Robot Factory Boulder Dash II Spy vs. Spy II: The Island Caper It would be really helpful to know if any of these titles boot correctly on a real Atari 810. Any info someone can provide would be appreciated! Thanks.

FYI, version v09 has been released which features further improved ATX support including support for long sectors and better handling of missing sectors.

What would the value of using the 8mb of flash for drive storage be over the microSD card? How would you load images into that memory? As for a modem, all I can say is that we are really nearing the upper limit of the firmware we can fit on the device. I’m not saying it is impossible (I honestly wasn’t confident we could get ATX compatibility as high as we have so far) but it would be a challenge.

I simply took a photo of the package as I received it from eBay. If yours ends up being more pristine, I'd appreciate it if you could submit a scan of it to use on the site instead of what is up there now.

There's some more information here: http://a8preservation.com/#/software/title/2784 And attached are dumps of version 1.1. Although this version has copy protection, it was reported that a later version removed it. ypnw.zip

What do you mean when you say these were "rescued"? Was this the result of multiple dump attempts or hand-tweaking things using other dumps?

Thanks for this and your previous round of contributions, Zarxx!

Thanks, phaeron. I've updated the page link above as well as the grammar file with the info you provided.

Ok, here is a proposed update to the ATX page: http://a8preservation.com/proto/#/guides/atx I have explicitly called out all data chunk structures I am aware of with a warning to the effect that phaeron and ijor mentioned. I have also created an ATX Synalyze It!/Hexinator grammar file that can be downloaded from that page. It should help with ATX file analysis. The following items are still open issues or questions: 1. What are the 8 bytes at the end of each track record for? These are all 0 values in the files I inspected. 2. What is the purpose of the extended sector header and what are its possible data values? 3. What is the format of the host data record? This is present in early ATX files (such as Hellcat Ace on Atarimania). 4. There is a slight discrepancy with the data chunks as I've documented them. It has been said that all data chunks start with an 8 byte header. As previously documented, sector list (0x01) and sector data (0x00) chunks have a 4 byte length, 2 byte type and 2 bytes of reserved padding. However, also as previously documented, weak sector data (0x10) and extended sector header (0x11) chunks have a 4 byte length, 1 byte type, 1 byte sector index and 2 bytes of data. To account for this discrepancy in the proposed new documentation, I have defined a data chunk's header as 5 bytes and defined sector list and sector data chunks as starting with 3 bytes of reserved padding. This doesn't feel right so if anyone has a suggestion for a better way to handle it, please let me know.

Corrections and suggestions for improvement are highly encouraged. As far as I know, that page is the most complete documentation we currently have for the ATX format that isn't code-based. What specially do you feel isn't accurate? Sent from my ONEPLUS A6003 using Tapatalk

Thanks, Ijor and Phaeron. Those posts were very helpful! Sent from my ONEPLUS A6003 using Tapatalk

Warhawk or WarGames? Sent from my ONEPLUS A6003 using Tapatalk

@ijor (or anyone else) - do you know any of the specifics of the protection check? In other words, what kind of behavior is it expecting in that address range? Sent from my ONEPLUS A6003 using Tapatalk

I have merged the ili9430 into the v08 branch as well.

I would think standard postal service or DHL would be the cheapest options depending on weight. Sent from my ONEPLUS A6003 using Tapatalk

I just tried Temple of Apshai Trilogy in NTSC XL mode booting with the Option key. I created a character at random and entered level 1 of Temple of Apshai. It showed the dungeon very quickly and I was able to move around until I was quickly killed by a mosquito. Bit of a let down. What specifically were you trying that was causing it to hang?

I've done some further compatibility testing with the current code in Github master. 86% compatibility! https://docs.google.com/spreadsheets/d/1AdzgPt2Z8SDk_Yy3FwAP8TRt8aackjzh_UVgOxOs4vM/edit?usp=sharing