Jump to content
IGNORED

VAPI library source code


ijor

Recommended Posts

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

  • Like 13
Link to comment
Share on other sites

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".

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

REQUIREMENTS

1) 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.

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Mclaneinc
Link to comment
Share on other sites

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 by Shannon
Link to comment
Share on other sites

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 by Mclaneinc
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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. ...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...