Posts by LordCrass

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.

Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    Would it be possible to add the parallel port feature so that DolphinDOS could work? The C64 core in MiSTer supports this.

    Even if it only works in standalone/docked mode, it would be quite nice for speeding up loads.

    This happened to me with a 1581 as well.

    NTSC C64, TC64v2 presenting drive #8, 1581 attached to C64's IEC port. I was copying files from d64 images on the TC64 drive to the 1581. Tried using the file copier built into the Super Snapshot 5 cart (presented by TC), as well as Maverick's file copier. Probably 3 out of 4 attempts would fail on start of the actual copy with an error stating that the device was not found.

    The timing is per-GCR byte. The loop counts bytes and exits to update the table when sync is detected, looping primarily on byte-ready condition. The modification was to increase the 4 cycle delay in the ldx command to a 6 cycle delay (and 8 cycles in speed zone for tracks 18-24)

    1. loop ldx $eaea
    2. loop2 clv
    3. ldx $1c00
    4. bpl sync_detected
    5. bvc *
    6. lda $1c01
    7. iny
    8. bne loop
    9.         inc $0d
    10. bne loop2

    The condition that occurs on tracks 1-17 happens when SO is asserted after the ldx $1c00 command but before a new byte is ready, so the loop sits through the entire sync mark instead of exiting and recording the block length. Instead of having separate entries in the table, one for header block and one for data block, each entry is actually the combination of both.

    Since a GCR byte is received approx every 26 cycles at this speed zone, 2 cycles difference in this case is nearly 8%, and equivalent to a neighbouring speed zone or a drive speed difference of over 20RPM.

    The issue might not be rotational speed. I don't know the inner workings of this implementation and I can only see symptoms, so it could be something else, such as a delays on sync detection, assertion of SO line, setting of the overflow bit, or any other number of conditions.

    Sounds good.

    Tested a bit more with the beta9-h drive code and it looks like it's running about 2 cycles too fast (or the rotational speed of the virtual disk is 2 cycles too slow, however you want to look at it). By increasing the delay instruction in the protection routine an extra 2 cycles, the protection check passes every time. At +1 cycle it usually works, but a failure will occur now and then.

    Also modified the test program to cover up to track 35. Assumed +2 cycle delay for each further density zone and included the T31-35 results that original disks return for comparison. While these are never checked from what I've seen, it might be useful in testing timing at each density level.

    There was an error in the previous test. I had not noticed that the timing of the test was modified in games that checked T18+, where it uses a 6 cycle delay instead of 4. After accounting for this, Vice now passes the checks on those tracks reliably.

    Interestingly, this disk layout is found on many disks, even those that don't use this protection check. It must be common to one or more mastering facilities of the time. For example, my original of Ultima III passes the test, as does Garry Kitchen's Gamemaker, which uses a different protection (Xemag 2.0).



      (121.15 kB, downloaded 96 times, last: )

    The above results were with beta-9l. When trying with beta-9h, it worked much better and failed in the way I expected it to fail. It reads the track very quickly, but some of the results are wrong. The sync mark arrives just a little bit too late and causes the read to pass through the mark and include the next block in its total, so instead of a block length of $163 on T1-18, you frequently get $2c8, but sometimes other results occur as well.

    On tracks 18+, the results are even further off the mark.

    Here is the test program. It fails on the TC in a way I did not anticipate nor understand. It works perfectly on real hardware (tested with 1541-II), although if the TC emulated drive is on the bus (I had TC as dev #9, in cartridge mode, internal IEC bus) it randomly introduces errors and the kernal IEC commands will sometimes hang. I noticed this as well when using emulated WarpSpeed cartridge to read 1541-II drive memory. This is a separate issue though, so as not to get distracted from the topic.

    When the test program is reading a track on the emulated TC drive, it takes a very long time, on the order of 30 seconds or so. On real hardware (and on Vice emu) this takes a fraction of a second. The results that come back are completely nonsensical as well. I don't know where it is consuming all of it's time. I would have to add some additional debugging options in the drive code, perhaps with the LED.

    When you run the program, it shows what bytes it expects for each block and what it actually got from the drive code. There are four bytes, which are:

    length of block (low byte), length of block (high byte), byte before sync, byte after sync

    There are only 2 different tables of results which correspond with the two most-dense speed zones. The check becomes unreliable once you hit track 25, and no titles I have run into will check past track 24, so the test program stops you at 24 as well. Vice (as of version 3.5) is not completely reliable in the track 18-24 speed zone either.

    Press + to increase track

    Press - to decrease track

    Run/stop to exit

    any other key to run the check again on the same track

    You can run the test on the g64 image it's provided on (which, incidentally, was originally the Batman disk image), or you can put in any of the game disks that use this protection, as it's exactly the same disk layout on all of them.

    If you want to change the disk being tested, run/stop to exit the program first, then RUN again after swapping. Otherwise the disk ID bytes will not be updated and further results are invalid.

    You could master a blank disk with this layout just using a special format routine. Such a disk should pass the protection check. However, I believe the timing of the check might be altered subtlety by the higher-than-normal density of the tracks, in which case you would have to slow your drive motor down when creating the disk. If these disks are remasterable with ZoomFloppy without changing drive speed, then no-speed change should be needed for this either.



      (121.11 kB, downloaded 98 times, last: )

    If it would help, I could create a g64 image that contains just a single prg file that does nothing but the protection check and reports back to the user what the resulting values of the check returned (it measures block length and byte before/after sync for a number of sectors on the track).

    There is a protection (which I believe is written by Herndon Labs?) that does not work in the emulated drive. It is described in a Vice bug report a few years back and was determined to be due to timing of the SO line with regards to sync detection, as well as these tracks being written at a higher-than-standard density.

    This protection is used on many commercial games, and is the reason for a number of the entries in the "not-working" G64 list. I tried a handful on both beta-9l and beta-9h, and they did not work on either firmware. Here are some titles that I had encountered in the past which used this:

    In Super Mario Bros 64 1.2 when running in docking station mode in NTSC, the sprites all seem to be shifted about 8-10 pixels to the right of where they should be in relation to the background. This is very noticeable when hitting bricks from underneath. If the character is a little to the left-of-centre of the brick, he passes through it. If you connect, the brick immediately shifts to the right before animating. Walking into a pipe from the left results in the character embedding himself into the pipe before stopping, approaching from the right results in him being stopped before he even touches the pipe.

    This doesn't happen in PAL mode, or if it's connected to an NTSC C64C in cartridge mode, so it seems to be an issue with the FPGA implementation of the NTSC VIC-II.

    Also, colours from the VGA output seem much more washed-out and dull in NTSC mode, while they look rich and vibrant with it set to PAL. The default yellow colour in the TC menu is particularly bad for this. It's almost white in most NTSC configurations. On my 1702 monitor from the same C64, the NTSC colours via composite are as rich and vibrant as the PAL VGA output in the TC64. This was reproducible on 4 different LCDs (3xSamsung and 1xNEC)

    I'm running the VGA output at 800x600 60Hz when in NTSC, and 800x600 50Hz when set to PAL.

    I noticed that quite a few of my G64 images do not work in the TC64's emulated drive. By this I mean they appear completely corrupted, you cannot get a directory listing or load any file. It's as if the image contained random data and you get nothing but read-error returned by the DOS.

    In looking at the ones that worked and ones that didn't, it seemed that the ones that did not were images where the GCR data wasn't aligned on an 8-bit boundary like you would see if it were read and framed by the shift-register of the 1541 and thus in images created by Zoomfloppy. These images were created by flux copiers such as Kryoflux and SuperCard-Pro and converted to G64. They work fine in Vice emulator as it does bitwise rotation of the image, but I'm guessing TC64 does not? I don't have any other explanation. This kind of alignment is required to properly represent protections such as the offset sync mark on many earlier V-Max games such as Bop'N Rumble, Defender of the Crown, and Into the Eagle's Nest.

    My config is:

    NTSC C64C

    TC64v2 in cartridge mode

    Single emulated drive device #8



      (267.44 kB, downloaded 70 times, last: )