| Author: | VMAXX (registered user: 6 posts ) |
|---|---|---|
| Date: | Mon, Feb 28th, 2011 @ 11:19 ( . ) |
V-Max V3 was, as was noted in an article before, both a copy protection and fast loader. The only faster loader of the time was the final version of Vorpal. V-Max could transfer the complete contents of one track in only two disk rotations, which was faster than even MS DOS MFM formatted floppies. Vorpal could, I believe, do it in one rotation. But V-max was also designed to be the most space efficient GCR floppy disk format, in order to enable bigger games to be shipped on fewer disks, and to do this took a number of tricks. Firstly, only one short 10 bit sync was needed at the start of the track to ensure all subsequent data was properly framed. The repeating byte pattern before that sync was used by the duplication hardware to find the start of the track data, it had no useful role on the C64. Only on disks that had some kind of save function were additional track syncs actually required, however by placing them between every sector, we reduced the amount of time it took to to synchronize the framing after moving the heads to a new track. The next bit of saved space was in the GCR format itself. It was more space efficient that both Apple and Commodore GCR, and had the added benefit of being simple enough that it could be converted to real data in real time, as it was being loaded from disk. This gave some additional speed benefit as well. The actual data and the file header information were contained in the same block, and the sectors could be variable in size. A pair of marker bytes signaled the end of one sector, start of another, as I recall. The filesystem data was limited to a file number and a sector number. Before reading a file, the loader would pick up a small table which told it what track to start to load, and how many blocks of data were on each track. The loader kept track of the sector numbers it had already transferred, so if it read the same sector twice it would just discard the data after reading it, as it would if the file identifier number didn't match the desired value. Whereas, if the data hadn't been transferred yet, it would get sent over the serial port in less time than it took a full block of fresh data to pass under the heads. Thereafter, the counter of how many file sectors to send from this track would be decremented, when it reach zero the heads would step to the next track. This meant we could store whatever block size was convenient, without wasting space on unused end of file bytes. This was especially important given we used a simplified Huffman coding scheme of run-length encoded data, which resulted in huge space savings but somewhat unpredictable block sizes. Each code/data block also had a load address embedded in it, so reading the data in random order did not result in scrambled files... Additionally, the first data header byte was an RTS instruction, which overloaded the RTS on the loader routine, so that at any time we could sneak in a self executing drive block if we felt the need for additional copy protection checks. The final capacity expanding feature was that the tracks were written at a slightly higher clock bit rate than standard, but still close enough to standard that even allowing for a 10% wow and flutter on belt driven 1541's, we could use software timing rather that hardware flags, to read bursts of data from the disk. We needed every one of those freed up clock cycles to enable the real time GCR decoding, sometimes we'd do a flag test and branch to the next instruction to delay our routine to stay in time with hardware (drive motors) that were running slow. Since the loader was integral to the game, disk based games could not be easily patched to remove the copy protection, unlike competing protections which might have had better signature checks, but which were easily patched with parameter copiers. And since it reduced duplication costs on larger games, it was still cost effective, even with it's somewhat steep royalty rates. We provided the automated tools to convert the files, as well as tools the duplicator used to verify the disk images. As a result, publishers which used the protection rarely had a reason to look at any other option. Eventually however, the end of the C64 era itself brought the useful life of V-Max v3 to a close. |
--- 0 Users Online --- 0 Recent Unique Posters |