LTK emulation patch - adds Lt. Kernal host adaptor cartridge support.
I also reordered some of the case statements in c64cart.c so the cartridges were in the standard alphabetical order.
The LTK is not a trivial install. The ltk_install.txt file I provided assumes you are using the command line. The LTK can only install from drive 8, as a 1541.
The LTK images I provided in this post are set to a default device of 8. You can change this by typing "config", then f3, and then scroll down to change the device number. press the <- to exit this screen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay. It all makes sense now.
The first few lines of the ltk_install.txt use the "touch" command (unix/linux/mac, but not windows) to create empty disk images (0 bytes each). It looks like you are just using the pre-installed images. For that you don't have to run anything, it is ready to go, just boot up x64sc and you are there. You can omit the settings for drive 8.
The load"<star>",8,1 is inadvertently loading the icqub program all ready installed in the dos partition as that is the default partition.</star>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, I wanted to thank you for the nice job on getting LTK support added. I'm looking forward to seeing any fixes/changes/upgrades. I also am looking forward to seeing CMD HD support later as you mentioned.
I did want to note, that it seems that currently LTK support doesn't seem to like running JiffyDos. If you replace the kernel rom with the JiffyDos rom, the system will boot but when you try to do anything after it will act up. I don't own an LTK, but from what I understand LTK is supposed to play nice with JD on real hardware? I have several FD-2000 images that I was going to try to copy files from onto LTK, but the stock load routines are very slow doing this, so it'd be nice if JD can be sorted out.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LTK predates JD. Unfortunately, they both took the same approach of patching the kernal ROMs by removing the tape routines. And since there is so little space in there, they can't co-exist. You have to use a stock c64 kernal for the LTK to work as it patches it on boot up, that is to say, it copies it to the onboard LTK ram, and then changes it, and turns off the stock kernal.
The simplest thing you can do is just use the copy-all that comes with the LTK which uses the standard serial IO transfers and just warp vice so it will copy faster.
Another option you can do is to copy the FD-2000 files to 1581 images (using dirmaster for example) and then use fastcopy (with warp) to move the data to the LTK.
If you know anyone who wants to try to incorporate JD with the LTK, I would be more than willing to help them, but it isn't something I can work on now. I'm finalizing the CMD HD code, and will be moving onto Ramlink soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Roberto, if you need anyone to test your CMD HD emulation, I would love to. I have another BBS all set (running now) that can use the CMD HD and lock it into my SCPU emulation I use on it.. It would be nice to get a true HD on that BBS instead of just using the FD4000 disks... Let me know...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since I've heard about testers using multiplexed configurations, I wanted to be 100% sure that there was no file buffering, so I added in code in this latest patch which turns it off.
I also had to do minor update in the scsi module for snapshots. I thought snapshots were a stream and that the module names didn't have to be unique. I figured out that wasn't the case. So I patched scsi to handle that as well as other minor things that will be need for the CMD HD.
Having a really strange issue, not sure if it is Vice related or the LTK emulation. Suddenly on my BBS I am losing approximately 1 minute an hour on the clock. Only on the Windows version. I updated my Linux box last night and set both systems at the same time. The Linux box didn't lose any time, but the Windows box lost 10 minutes. Both are running the exact same setups..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you ever run vice on windows for such a long time to notice the clock shift? I'm just guessing here, but I think windows just isn't giving vice 100% of the time it needs and that results in the clock skew. It isn't systemic to vice as it doesn't happen on linux.
Try this: After you launch vice, start the Task Manager, go to the details tab, right clock on the vice process, and set the priority to real time. This should hopefully make windows devote more time to it. Windows is very aggressive on power management so it will try to keep processes running the least amount. Also make sure your PC is set on "best performance" in the power options. Since the C64 "clock" is actually just based on the timer, any reduction in CPU cycles to vice may lower the number of cycles actually run. It is worth a try anyways. Worst case scenario is you can always reset the C64 clock from some RTC source hourly.
In my experience, Windows process slicing is terrible especially when it comes to CPU and IO balancing. Unix is way better, and linux is getting there; they seem to change up the process scheduler all the time but it always seems better than windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The VICE timing code compensates for a long sleeps automatically, and will run faster to catch up to where it should have been. Although - I did just add something that skips the catch up if there is more than 4 frames of time elapsed between vsync. In this case it will log a warning: "vsync %d ms late, resetting"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, make sure you aren't overworking the machine. If your CPU utilization is high, then you can't expect vice to work in "real time". All operating systems today rely on the fact that most processes are sleeping. If you have N cores, and N fully active processes, the CPU will be over utilized. Depending on your cooling system, your CPUs may also be throttled back to reduce heat and power consumption. It is impossible to achieve N fully active processes as all these overheads take away from the process time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe it was 38887 in windows. My Linux box which I update regularly did not have this issue. I have since moved off of the Windows setup and have moved to my Linux setup. I will let you all know how it goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It runs on Fd4000 disks with little to no difference. I did change the cpu speed to 60fps instead of 100% and it is keeping time from what I can tell fine now. I am going to keep an eye on it..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LTK is not a trivial install. The ltk_install.txt file I provided assumes you are using the command line. The LTK can only install from drive 8, as a 1541.
The LTK images I provided in this post are set to a default device of 8. You can change this by typing "config", then f3, and then scroll down to change the device number. press the <- to exit this screen.
this is pretty much what i'm doing:
and i can see all 3 LTK images are attached, also image in #8.
still, doing the next step
VICE comes up with what i attched as a screenshot.
but this is not what we want?
Okay. It all makes sense now.
The first few lines of the ltk_install.txt use the "touch" command (unix/linux/mac, but not windows) to create empty disk images (0 bytes each). It looks like you are just using the pre-installed images. For that you don't have to run anything, it is ready to go, just boot up x64sc and you are there. You can omit the settings for drive 8.
The load"<star>",8,1 is inadvertently loading the icqub program all ready installed in the dos partition as that is the default partition.</star>
ahhhhhhhh.... got it now! i thought after launching x64sc, it looks like "ready to use".
i'm new to this, so i wasn't sure what to expect/what to do exactly.
thanks a lot Roberto! thanks also to Bob for hints.
First, I wanted to thank you for the nice job on getting LTK support added. I'm looking forward to seeing any fixes/changes/upgrades. I also am looking forward to seeing CMD HD support later as you mentioned.
I did want to note, that it seems that currently LTK support doesn't seem to like running JiffyDos. If you replace the kernel rom with the JiffyDos rom, the system will boot but when you try to do anything after it will act up. I don't own an LTK, but from what I understand LTK is supposed to play nice with JD on real hardware? I have several FD-2000 images that I was going to try to copy files from onto LTK, but the stock load routines are very slow doing this, so it'd be nice if JD can be sorted out.
Thanks!
The LTK predates JD. Unfortunately, they both took the same approach of patching the kernal ROMs by removing the tape routines. And since there is so little space in there, they can't co-exist. You have to use a stock c64 kernal for the LTK to work as it patches it on boot up, that is to say, it copies it to the onboard LTK ram, and then changes it, and turns off the stock kernal.
The simplest thing you can do is just use the copy-all that comes with the LTK which uses the standard serial IO transfers and just warp vice so it will copy faster.
Another option you can do is to copy the FD-2000 files to 1581 images (using dirmaster for example) and then use fastcopy (with warp) to move the data to the LTK.
If you know anyone who wants to try to incorporate JD with the LTK, I would be more than willing to help them, but it isn't something I can work on now. I'm finalizing the CMD HD code, and will be moving onto Ramlink soon.
Roberto, if you need anyone to test your CMD HD emulation, I would love to. I have another BBS all set (running now) that can use the CMD HD and lock it into my SCPU emulation I use on it.. It would be nice to get a true HD on that BBS instead of just using the FD4000 disks... Let me know...
I'm hoping to post the CMD HD patches this weekend. It might be a few days to resolve stuff before it is put in the trunk.
Since I've heard about testers using multiplexed configurations, I wanted to be 100% sure that there was no file buffering, so I added in code in this latest patch which turns it off.
I also had to do minor update in the scsi module for snapshots. I thought snapshots were a stream and that the module names didn't have to be unique. I figured out that wasn't the case. So I patched scsi to handle that as well as other minor things that will be need for the CMD HD.
Nice, when the CMD setup is available i will install it on my other board. So far the LTK setup is running well. Look forward to the updates..
Having a really strange issue, not sure if it is Vice related or the LTK emulation. Suddenly on my BBS I am losing approximately 1 minute an hour on the clock. Only on the Windows version. I updated my Linux box last night and set both systems at the same time. The Linux box didn't lose any time, but the Windows box lost 10 minutes. Both are running the exact same setups..
Have you ever run vice on windows for such a long time to notice the clock shift? I'm just guessing here, but I think windows just isn't giving vice 100% of the time it needs and that results in the clock skew. It isn't systemic to vice as it doesn't happen on linux.
Try this: After you launch vice, start the Task Manager, go to the details tab, right clock on the vice process, and set the priority to real time. This should hopefully make windows devote more time to it. Windows is very aggressive on power management so it will try to keep processes running the least amount. Also make sure your PC is set on "best performance" in the power options. Since the C64 "clock" is actually just based on the timer, any reduction in CPU cycles to vice may lower the number of cycles actually run. It is worth a try anyways. Worst case scenario is you can always reset the C64 clock from some RTC source hourly.
In my experience, Windows process slicing is terrible especially when it comes to CPU and IO balancing. Unix is way better, and linux is getting there; they seem to change up the process scheduler all the time but it always seems better than windows.
on my win7, the VICE speed seems to be really accurate. it's way less than a second in 1 hour, i checked with WinVICE and
https://csdb.dk/release/?id=87173
just make sure it's running at 100%, not the fancy new FPS speed settings.
That would be my guess as well, perhaps Windows lets the process "sleep" too much.
The VICE timing code compensates for a long sleeps automatically, and will run faster to catch up to where it should have been. Although - I did just add something that skips the catch up if there is more than 4 frames of time elapsed between vsync. In this case it will log a warning: "vsync %d ms late, resetting"
Also, make sure you aren't overworking the machine. If your CPU utilization is high, then you can't expect vice to work in "real time". All operating systems today rely on the fact that most processes are sleeping. If you have N cores, and N fully active processes, the CPU will be over utilized. Depending on your cooling system, your CPUs may also be throttled back to reduce heat and power consumption. It is impossible to achieve N fully active processes as all these overheads take away from the process time.
One more thing: can you run the same BBS off of FD-4000 or some other drive to see if it happens without the LTK?
What VICE svn revision are you seeing this lost time on?
I believe it was 38887 in windows. My Linux box which I update regularly did not have this issue. I have since moved off of the Windows setup and have moved to my Linux setup. I will let you all know how it goes.
It runs on Fd4000 disks with little to no difference. I did change the cpu speed to 60fps instead of 100% and it is keeping time from what I can tell fine now. I am going to keep an eye on it..