Posts by LordCrass

The problem turned out to be the SD card. I noticed I was unable to create new D64 images through the file browser. It would error out and create a 0 byte file. Put the card into my PC and ran a chkdisk on it and then after that both of those issues were solved.

I didn't know there were cartridge images built into the firmware. I was always attaching them from CRT files on the SD card through the file browser.

The built in one does indeed work just fine, every time.

Thanks!

No, nothing else in any other slot.

What I'm doing is selecting the cartridge to be mounted in slot 4, which is set to Retro Replay type. I have it set to auto use that slot, so just hitting Return on it in the file browser activates it. Happens even after choosing "restore defaults" (and then using slot 1 as that's been defined as RR in the defaults). I also tried this with TC64 beta9h release, and it happens there too.

Yes, it happens in standalone mode as well as in cartridge mode.

It's odd and my first assumption would be the crt image is bad, but I've deleted it, copied it back over and verified the resulting file is the same as the source and it still happens. Does it happen to anyone else?

The NTSC Retro Replay cartridge (either 3.8a or 3.8y) will load from SD card through the file browser and then display either a standard empty blue/light-blue C64 screen with the READY. prompt in the top left and a flashing cursor, or some fragment of "FILENAME:" in the top-left corner instead of jumping into the RR menu screen. If I go to the TC64's file browser and select it again, and again, and again, it will eventually work. About 1 in 10 tries works.

This happens when attached to my NTSC C64C or in standalone mode in NTSC. The PAL RR cart files work every time in either NTSC or PAL mode system (but of course won't load programs from disk properly in NTSC mode due to timing).

The NTSC Action Replay 5 crt image works every time in NTSC as well. This only seems to affect the RR NTSC images. When selecting the images in the file browser, it identifies them as type 36, "8k game" cartridge as well, if that matters.

The crt files are the same that I've used in Vice and I checked that the file wasn't damaged on the SD card by comparing the hashes.

This is on firmware 9q on a TC64 v2.

Is it possible to run the C64 core as "standalone", meaning the TC64 is using the FPGA for everything, but while plugged into a real C64?

Reason: I have an NTSC C64C that I'd like to run PAL software on occasionally. Other cores like Minimig or Genesis can run this way, using the C64 as a docking stations just for the keyboard/joysticks, but I can't see a way to do this with the C64 core.

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)

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

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.

Is it safe/possible to use Sega Genesis/MegaDrive controllers with the docking station?

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.

https://sourceforge.net/p/vice-emu/bugs/203/

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:

On reading through the known bugs in the wiki, it seems this SMB issue is probably related to one of those NTSC entries, although I am not sure how to tell.

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.

Realms of Darkness. Faster screen rendering.

After reverting back to beta-9h, these disks were readable, so that was it.

Is this on the roadmap to be enabled again in a future release?