ijor Posted May 2, 2016 Share Posted May 2, 2016 This is the source for the VAPI library. Big note: As I already said, I lost my disk long ago and I am recovering from backups. I can't yet be sure if this the very latest version I coded, but it should be much newer than the one used for the public library anyway. I didn't try to build it. A couple of Windows resource files are missing yet. And I don't have restored my original development environment anyway. But the release is not for the purpose of rebuilding the library in its original form (DLL). I don't have now time for an actual build and test. But I don't want to delay this any longer. If somebody finds that something is missing (it shouldn't), please let me know. VapiDllPublicSource.zip 13 Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 3, 2016 Share Posted May 3, 2016 Fortunately, Visual Studio has the ability to reverse binary resources back to an .rc file. VS2013-buildable version attached; seems to work with the modified Atari800WinPLus binary and successfully boots a couple of protected ATX disks. vapisrc-fixed.zip 5 Quote Link to comment Share on other sites More sharing options...
Panther Posted May 3, 2016 Share Posted May 3, 2016 Fortunately, Visual Studio has the ability to reverse binary resources back to an .rc file. VS2013-buildable version attached; seems to work with the modified Atari800WinPLus binary and successfully boots a couple of protected ATX disks. It's trying to import the project file "Microsoft.Cpp.Default.props". Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 3, 2016 Share Posted May 3, 2016 It's trying to import the project file "Microsoft.Cpp.Default.props". That comes standard with the Visual C++ compiler. The project's configured for the v140_xp toolchain -- you'll need to switch it to whatever you have installed. Quote Link to comment Share on other sites More sharing options...
ijor Posted May 3, 2016 Author Share Posted May 3, 2016 Fortunately, Visual Studio has the ability to reverse binary resources back to an .rc file. VS2013-buildable version attached; seems to work with the modified Atari800WinPLus binary and successfully boots a couple of protected ATX disks. Thanks phaeron. I'm glad it builds ok. Note that at the time I was introducing some significant changes and additions. You can see there is some WIP code to support the variations among different drive types. So conceivable there is a regression. An historical comment might in place. VAPI inherited code from a predecessor that I named FX7. FX7 were a set of tools I developed at the late 90's.The goal was to make digital backups of my copy protected disks. At the time I wasn't thinking on public preservation or emulators. But I did implement a SIO2PC type tool that was able to run the copy protected images under real hardware. And that was the basis of the VAPI library. For quite some time the library even supported loading FX7 images. That's why you see structure and function names starting or ending with FX7. Quote Link to comment Share on other sites More sharing options...
Farb Posted May 3, 2016 Share Posted May 3, 2016 Thanks for releasing this, Ijor. Quote Link to comment Share on other sites More sharing options...
ijor Posted May 4, 2016 Author Share Posted May 4, 2016 This is a link to the imaging tool for 1050 enhanced drives. http://vapi.fxatari.com/beta/VapiImgTool_02a.zip Note that it has some issues and limitations. I quickly moved to use tools with more advanced hardware (mainly ST Discovery Cartridge and the Catweasel for the PC). So I halted further development of this tool very early. It runs at very high speed, so it is quite picky about a good serial connection. Nevertheless, I does let you image most (not all) copy protected disks with a rather common setup. It also has, as a bonus, an extremely fast way to create ATR images. Note that I didn't use this software for more than a decade! No idea how it behaves in newer versions of Windows. I currently has no way of testing this neither fixing bugs. This is released AS IS for the time being. REQUIREMENTS1) Atari 1050 with any one of the following enhancements: Happy, Duplicator, or Speedy. The software will not work at all with a stock 1050 or with other drives.2) A PC running Windows.3) A Prosystem or 1050-2PC cable connecting the 1050 drive to the PC. 1 Quote Link to comment Share on other sites More sharing options...
ebiguy Posted July 16, 2016 Share Posted July 16, 2016 This is the source for the VAPI library. Big note: As I already said, I lost my disk long ago and I am recovering from backups. I can't yet be sure if this the very latest version I coded, but it should be much newer than the one used for the public library anyway. I didn't try to build it. A couple of Windows resource files are missing yet. And I don't have restored my original development environment anyway. But the release is not for the purpose of rebuilding the library in its original form (DLL). I don't have now time for an actual build and test. But I don't want to delay this any longer. If somebody finds that something is missing (it shouldn't), please let me know. Hi ijor, I was looking at the timing in your source code and I would like some explainations on this line in at8fx.cpp: #define CMNDACK_DELAY 250 // From low CMND to start of ACK There is a comment some lines above which says that it is in microseconds but not sure if the scope of this comment includes the above line. If this delay is from the Command line getting low to the start of Ack, it means that it includes at least both t0 and t1 from the SIO specs. The min for t0 is 750 microseconds and the min for t1 is 650 microseconds which is much more than 250. Sorry if I did not understand something in the source. Could you explain the 250 please ? Thank you very much. Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 16, 2016 Share Posted July 16, 2016 I think "low CMND" means deasserted command line, which would be a high signal for active low. The delay in question would then be t2, which has no guaranteed minimum. SIO routines on the computer side have to delay releasing /COMMAND until the last minute since this edge is essentially how the computer holds off the device until it is ready to receive the ACK. In measurements I've seen about 0.3ms between -COMMAND and the ACK byte being received on a 1050, which is about the same (250us to start of ACK + 50us to transmit ACK). Quote Link to comment Share on other sites More sharing options...
ebiguy Posted July 16, 2016 Share Posted July 16, 2016 Hi phaeron, Your explanation looks logical. Thank you for the answer. Quote Link to comment Share on other sites More sharing options...
ijor Posted July 17, 2016 Author Share Posted July 17, 2016 Yes, phaeron is right. I meant deasserted, of course. And yes, it is in microseconds. I didn't pay too much attention to the SIO official timing. I used what the hardware actually performs. The archive here includes a text file with all the measurements I performed on a 1050. In this specific case (t2 as performed by a 1050), the timing is not 100% constant. There is some jitter as elaborated in the mentioned text file. Quote Link to comment Share on other sites More sharing options...
Shannon Posted July 21, 2016 Share Posted July 21, 2016 So Phaeron... Looking at the source code. How close would you say you were from what you were able to glean from the actual documentation? Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 21, 2016 Share Posted July 21, 2016 Pretty close. I already had a working implementation just by reverse engineering, and the main fix was the chunk parsing after ijor clarified that part of the format. The main part that this source revealed was the creator field, which I still need to fix in my code. Timing-wise, I had already done some rudimentary tests on the DLL through the patched A8WP, though mainly just rotational timing. Altirra's 810 timing is based off of cycle counting the code in the ROM and the 1050 timing is from measurements of an actual 1050. So far, the ACK timing at least agrees. 1 Quote Link to comment Share on other sites More sharing options...
Shannon Posted July 27, 2016 Share Posted July 27, 2016 Thanks for the information. I was doing some testing on Altira 2.60 and the following 2 games do not work right (atx images). I confirmed they work with Atari800win modified to use vapi.dll.. Alternate reality: The City -> When you load Disk 1 side 2 after creating a new character it keeps on reading the same sector over and over and over. Mr. Do! - Keeps rebooting. Thanks Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 27, 2016 Share Posted July 27, 2016 Please upgrade to Altirra 2.71 or the latest 2.80 test release. 2.60 is a full release back and over a year old. I'm not sure which ATX images you are using, but at least Mr. Do! from Atarimania's collection and from the Preserved Software dump work for me. (Not enough time to try AR at the moment since it's more involved.) Check that you are booting in a relatively vanilla configuration, i.e. XL/XE OS v.2 with 64K and no add-ons. Note that Mr. Do! has a trap where the game will deliberately crash during game play if the disk loads too fast and a timing check fails. In Altirra, you must boot it with disk acceleration options off and accurate sector timing on. A8WP+VAPI always disables SIO patch when loading ATX disks; Altirra can run SIO patch on and still simulate disk errors such that many disks load accelerated, but ones that have timing checks will still fail. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted July 27, 2016 Share Posted July 27, 2016 (edited) Never had Mr Do reboot, normally when it failed the check it became unplayable due to deliberate code corruption with characters doing daft stuff, you might also want to check the image you have as well as doing what Phaeron said. As Phaeron said, do upgrade to at least 2.71 but I'd fully recommend the very latest beta, unlike a lot of beta software Altirra remains very stable in beta form and apart from a few fixes from time to time its normally additions or feature upgrades to increase machine emulation preciseness which is already incredibly good, so the use of the beta's really does ADD rather than awaiting a final which in Phaerons known love of "its done as a final when he's happy no matter how many beta's" can be a wait that really is unneeded.. The man is a perfectionist and it shows in Altirra...8 bit goodness all the way through... So new beta's are a very useful update with drive emulation being one of Avery's pet projects at the moment. Btw, just incase, here's the known good dump from Farbs wonderful Software team.. Mr. Do! (1984)(Datasoft)(US).zip Edited July 27, 2016 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
Shannon Posted July 27, 2016 Share Posted July 27, 2016 (edited) ok... I had to use (oddly enough 810 timing) to get Mr. Do to work for me. It did not like the 1050. Still no love with Alternate Reality.. I'm gonna get the latest Altirra now. Edit: Trying 2.80 test 49.. Still no luck with Alternate Reality the city. No biggy.. I just thought I'd mention it. I was gonna take a crack at implementing the VAPI library source code into A800 and was using Altirra to test the problem images to see if my documented behavior was fixed on certain images. However these images work fine in Atari800 win modified so my next step is to take a crack at implementing the new source code. Edited July 27, 2016 by Shannon Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted July 27, 2016 Share Posted July 27, 2016 (edited) Re Alternate reality The City.. Found the issue but not sure if its 100% the right fix although the game does run now.. When it asks for disk 1 side B if you actually put in disk 2 side A it will read a sector and then ask for disk 1 side B, if this is inserted now it runs the game and just follow on screen disk requests now....Tried twice and seems to be the way to work, the possible answer is that it may work on multpile drives and expects disk 2 side A in D2: at boot up and hence it works the other way on one drive? Paul.. Disk attached, contains 2 version from Farbs set and both work.. Alternate Reality - The City (1985)(Datasoft)(US).zip Edited July 27, 2016 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
Shannon Posted July 27, 2016 Share Posted July 27, 2016 ok... This is a rather bizarre one. If I disable all drives except for drive one then it works for me. What I was doing previously was loading up drives 1 thru 4 so that I should use the move up/move down to switch disks quickly and that was not working. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted July 27, 2016 Share Posted July 27, 2016 (edited) AR makes use of multiple drives and as I recal it expects certain disks in certain drives. It might be covered in he manuals. So it makes sense that if the game detects multiple drives it wants to use them. Edited July 27, 2016 by kheller2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted July 27, 2016 Share Posted July 27, 2016 Yes, my presumption from the solve was that D1: used all disk 1 disks and D2: did all disk 2 disks. Either way, it works and not an emulation bug.... Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted July 27, 2016 Share Posted July 27, 2016 ok... This is a rather bizarre one. If I disable all drives except for drive one then it works for me. What I was doing previously was loading up drives 1 thru 4 so that I should use the move up/move down to switch disks quickly and that was not working. Yes, that it what I found in my post above this original one.. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted July 27, 2016 Share Posted July 27, 2016 (edited) http://www.digitpress.com/library/manuals/atari8bit/alt_reality_city.pdf Boot: D1: D1S1, D2: D2S1 (I'm assuming D1S2 is asked for at a point and this goes into D1) When game asks for D2S2: D1:D2S2, D2: D2S1 Edited July 27, 2016 by kheller2 Quote Link to comment Share on other sites More sharing options...
ijor Posted July 27, 2016 Author Share Posted July 27, 2016 Regarding AR The City ... This game has to be tested up to entering the tavern (that's the place, IIRC) and until your first encounter. It has multiple protections. If the last one (the most important which involves the weak sectors) fails, the game will load and will appear to run correctly ... but ... you always die shortly after the game starts. So be careful. There are a couple of ATX images sets floating around that don't work (even when they seem to, as I explained above). I tested good images under Altirra some time ago and it works fine (although didn't try multiple drives combinations). Please everybody update to the latest Farb set. We corrected, fixed and changed several images. Quote Link to comment Share on other sites More sharing options...
ijor Posted July 27, 2016 Author Share Posted July 27, 2016 So far, the ACK timing at least agrees. ACK timing, and in general timings that depend on the firmware are, surprisingly, quite critical. They usually need more precision that timing that relates to the actual disk. The reason is that firmware timing is (almost, due to running off its own clock) cycle accurate. So if some program depends, probably unintentionally, on very strict firmware timing, chances that would run fine and would be released like this. On the other hand, if some program depends too much on timings related to the disk, it would not work. Disks and drives are not very precise, both mechanically and magnetically. Too strict timing and the very same disk might fail in other drives, or even a different original copy might fail in the same drive, etc. ... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.