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.
Guys I am very interested in this as I currently own a LTK Clone and owned a real one back in the day.. There is a website floodgap that has a ton of info about the LTK.. Would love to test anything yo uwant to throw at me also.. Is there a .crt file available to download to get this going?? I am ready to put this thing through it's paces!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Groepaz was right, at least 2 people will use this. :)
The support is in the latest svn. You can find it on pokefinder.
I'm attaching some of the test stuff I used along with a little read me on how to do a fresh install. I intend to setup a website later detailing everthing LTK as well as the CMDHD stuff as well. The floodgap stuff has some wrong info on it.
It would be great if you could "image" the contents of your current drive and test it in the emulator.
I will create a full hd and install my BBS on it, then create another one on a muxed setup if I can get it running to use my second BBS. I can setup tons of boards to test it.. LOL
Just an add on, got it running like a charm.. Restoring backups of my 1993 BBS which I backed up when right before my old Lt Kernal died.. If I get that running, I will back up my current BBS on the HyperDrive and set that up and run it for public consumption.. If this works with the swiftlink it is a game changer!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will create a full hd and install my BBS on it, then create another one on a muxed setup if I can get it running to use my second BBS. I can setup tons of boards to test it.. LOL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just an add on, got it running like a charm.. Restoring backups of my 1993 BBS which I backed up when right before my old Lt Kernal died.. If I get that running, I will back up my current BBS on the HyperDrive and set that up and run it for public consumption.. If this works with the swiftlink it is a game changer!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you used the premade image files I provided? I hope you can fill that 300MB of storage with something. :)
I would still like to see someone image the real disk directly and use that just to see if it works.
I'm not too sure about the swiftlink support. I've heard about a lot of problems with that, so much so other users use older versions of vice as it works better for that. But I can't back any of that up, it is just what I've heard on forums and emails.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, Jay I am still combining boards.. :) Roberto, actually I did have issues with Fastcopy restoring images of my first BBS from back in 1993, it would lock up in Windows version r38882, I am using r38886 on my linux test bed and am copying files with no issues right now. I haven't tried restoring those images I have from my old board just yet. I am copying files from d4m disks using CopyAll and so far it is copying great. I am going ot finish setting up my test bed here tonight leave it running (it will have issues with time as it runs inside a VIrtual Box VM but at least I will be able to see how it runs over the week) if it runs well till Friday I will copy my real LTK to either d4m disks or d81 disks and copy them over and run one of my BBS' on the emulation from that point forward. I will test Swiftlink if there are no conflicts between the two (there is none with my real hardware) Iwill be set to go...
Something that is happening though.. I copied about 400 blocks of files to lu 0 now I am copying about another 100 and the emulation slows to a crawl. CPU is running at 100% fps is around 59 ot 60 but the emulation is for all intents and purposes dead in the water.. I have to do a reboot and when trying to reboot, it doesn't like ALT F12 or the x I have to forcibly shut it down.
I will keep an eye on that..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay. Well, the best thing is to try to replicate the problem. If you can do so, reliably, then send me the files and procedure you did to cause the problem. I recently submitted a bug fix for the FD-4000 emulation. I don't know which svn has it though. You may or may not have it. It may be causing some issues as well. I'm not sure if the copy-all uses any fast disk code from the LTK and how it affects the FD-4000.
You should be able to warp the system so that it runs faster during the copy. I did a lot of testing with warp on and it works just fine.
I don't know the difference between the two versions of vice you are using. There are a lot of changes form day to day and your issues may not have anything to do with the LTK emulation. Try to run it with the least possible number of features. For example, turn off the sound, or set it to "dummy" output and that might correct or help with somethings. I'm told a lot of vice's time is spent dealing with the SID emulation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am hitting the sack right now but I will do a bunch of testing tomorrow night. I have a fully configured BBS running on it now. I just have to setup the modem properly and I will be able to connect and get things moving for testing tomorrow night.. Thanks for this Roberto I never thought I would see the day when the LTK could be emulated... I just installed a BBS on it and ran through it head to toe remotely Swiftlink works fine so far, DTR Hangup is an issue at the moment but I can get around that.. I will report back when I have more info.. Thanks again...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Al, I've been able to "trick" DTR into behaving somewhat by running the &D2 command from dsp.modem 8 (on DS2) and +.modem (on Image). And there's no shame in using the cursor right cheat from the 11.1 days. (ats2=27) if using BBS-Server.
If you're using TCPser it will no doubt work using ats2=43 and +++ with the &D2&C1 hook. I've learned to live without DTR after all these years.
There's just SO MUCH to consider and test, and play with. This is most definately a game changer.
Last edit: Jay Campey 2020-10-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When it starts crawling for me, I just reset VICE and it's fine again, but I can't recreate the set of circumstances.
I'm almost done pulling a global off my actual LTK in hopes of cramming it on this. I've already populated 4 different users and 6 LUs each, with different versions of BBS. I have successfully run C-Net DS2 multi-node on it, answers fine and disconnects quickly. I have not tried the swiftlink version of it yet. I am insanely curious to see if I can store content beyond user 13 without risking corruption.
Am I missing the trigger for the ICQUB button, or is that not part of this implementation?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We still have to determine if the slow down is because of other changes to VICE or the LTK. What is they typical type of workload? Maybe I can simulate it. I ran several high work loads on it in the same instance, autocopy a full LU to another. Filling an LU completely, then reading it back, and more copying, so I never noticed a slow down. If the files were on "vdrive" or "fsdrive", would the same slow down happen? Which platform are you using?
How are you running multi-node? I haven't tried this, but it might be possible to run different instances of vice using the same disk image, but having a different LTK port for each instance. I actually have a real LTK and multiplexer unit, but I never tried it as I just got it about a month ago. Maybe one day.
The IQCUB button is the "cartridge freeze" button in vice. Of course you have to prepare the system first by running IQCUB.
Did you use the attachment I posted here with the pre-made disk images or using the SYSGEN I created of did you make your own? The disk geometry matters and some configurations will corrupt the system.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I originally used the geometry of my existing dual HD system, but then I came across yours that looked real attractive, so I abandoned mine in favor of yours. Not proud of the fact that it took me 45 minutes just to do the math originally.
For the multi node, I just ran 4 instances of vice with the same 3 HD images, but different config files, and different cartridge files. I wasn't sure if the chips on the cartridge got written with geometry info, so I just made a separate one for each. In theory, 4 machines would need 4 host adapters anyway, so I just replicated that scenario.
Each config file calls a different LTKport=#, and has a separate modem setting. Other than that, they are identical.
Once loaded, I had to turn on NMI trap for all 4 ports, and adjust the startup LU/USER in CONFIG. From there, it's all up to the BBS software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this the scenario then the slow down happens? Maybe it is when you have multiple instances accessing the same file.
I setup that config so LU10 was on one disk, LU0-4 was on another, and LU5-9 on another. The idea was incase the DOS got hosed, you could rebuild it without damaging the data on the other LUs. I'm not sure how the shared file access will work, but according to the LTK manual, you should never have two systems writing to the same LU.
You can use the same ltk.crt or bin file. It doesn't change or store anything other than the serial number, but the LTKserial parameter will adjust this accordingly.
Well, I'm glad this works. This was one of the original motivations for doing this: BBSes and shared disk space which the LTK provided. I hope to see more C64 BBSes on the internet now.
Do you have the LTK clone? I'm intersted in getting my hands on the 7.3 DOS what was "updated" for it. I would like to test that.
Please keep me updated on anything else you find. I want this to be as stable as possible.
BTW, do you have any other software for the LTK? I heard someone made a backup to tape thing for it, but I can't find it. I would like to get that to work too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the original LTK (serial# 87000003), but I do have the updated ROMs in the original HA and the 7.3 DOS disk. I keep my original ROMs put away just in case I decide to sell this thing to a religious purist. The original seagate took a dump years ago so I got the Rear Admiral internals to replace it but used my original casing.
One thing I will be watching for, sometimes on my RA unit I get "User bleed", which is when I have files within 1 USER partition of each other, I can access content between them sporatically. For example, I backup my BBS data file from LU1 USER0 to LU1 USER1. From time to time, the BBS will read data from the wrong USER. I have to separate the USERS and stick to only using even numbers. For whatever reason, leaving a space in between them helps with that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ROMs are just a first stage loader. They shouldn't matter much, but back then the SASI drive spec (pre SCSI-1) was implemented different on some drives so they may have had to make some modifications to make things work right for the changing drives which they offered, at least on boot up. They probably also had to do some stuff with the LTK multiplexer in case another port was using the drive.
Just to confirm, 7.2 was the last official DOS. 7.3 is the LTK clone version, correct? Were there any patches after the release?
As for the USER problem, I'm sure the LTK still has some bugs. I suggest you use different LUs to back up data and avoid the USER option. The USER value is simply a separate attribute to the file so I can see how things might get confused. I'm also helping out on the LTK dos project which is trying to reverse engineer the DOS and make it so it can use larger disks as well as any other features. If you can reliably replicate the problem, I'm sure I can hunt it down.
With vice it it is easy to do backups. You just start up with different images. You can keep your backups on another image that you use from time to time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I've not been this excited about VICE since FD4000 became a thing.
That's correct, 7.2 was the last release. 7.3 is the RearAdmiral clone version, and I'm a nosey b@$+ard so I snoop around a bit, and a file comparison shows very little more than hex edit painting. Even the spacing is the same. So make of it what you will.
Yeah, I just compared it to 7.2. It is a blatant duplication and the only thing that is different is the branding. Sadly, he claims credit for the whole DOS and removed all references to the original authors. I was under the impression that there was an improvement based on his ebay ad for selling the clones. Perhaps the documentation is better, or am I wrong there too?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found it humorous that even the PLAs on the host adapter are branded in that fashion. A few of the dos commands are also altered. SHIP instead of PARK for example. The load screen of the device even, with the author's name and company are the exact letter length. As I would expect if I were to sector edit my name onto it.
Hell, I'll even dump the new ROMs for you so you can offer that version as an option for the emulation. I doubt he will give you much trouble at the patent office. LOL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want to, sure, but I don't think they will be that different. In fact, the original ROMS accidently have code from Jason Ranheim's Promenade programmer at the end. I'm sure that will be included in the clone ROMs as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you add the drive image's as well to the LTK Host Adapter menu, under the Cartridges menu? And if so, did you decide to use the existing ones or make your own?
I ended up making my own from scratch. I might have needed to done the DOS install using 1541 as drive #9 but I'd have to redo it to verify. If you are using the images that were provided, then after you added the LTK cartridge and it rebooted, it should boot to the LTK bootup screen instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
all applied in trunk, we can close this now :) cheers!
Guys I am very interested in this as I currently own a LTK Clone and owned a real one back in the day.. There is a website floodgap that has a ton of info about the LTK.. Would love to test anything yo uwant to throw at me also.. Is there a .crt file available to download to get this going?? I am ready to put this thing through it's paces!!
Groepaz was right, at least 2 people will use this. :)
The support is in the latest svn. You can find it on pokefinder.
I'm attaching some of the test stuff I used along with a little read me on how to do a fresh install. I intend to setup a website later detailing everthing LTK as well as the CMDHD stuff as well. The floodgap stuff has some wrong info on it.
It would be great if you could "image" the contents of your current drive and test it in the emulator.
I will create a full hd and install my BBS on it, then create another one on a muxed setup if I can get it running to use my second BBS. I can setup tons of boards to test it.. LOL
Just an add on, got it running like a charm.. Restoring backups of my 1993 BBS which I backed up when right before my old Lt Kernal died.. If I get that running, I will back up my current BBS on the HyperDrive and set that up and run it for public consumption.. If this works with the swiftlink it is a game changer!
I will create a full hd and install my BBS on it, then create another one on a muxed setup if I can get it running to use my second BBS. I can setup tons of boards to test it.. LOL
Just an add on, got it running like a charm.. Restoring backups of my 1993 BBS which I backed up when right before my old Lt Kernal died.. If I get that running, I will back up my current BBS on the HyperDrive and set that up and run it for public consumption.. If this works with the swiftlink it is a game changer!
This coming from the guy who hours ago said he was running too many BBSes.
:D
So you used the premade image files I provided? I hope you can fill that 300MB of storage with something. :)
I would still like to see someone image the real disk directly and use that just to see if it works.
I'm not too sure about the swiftlink support. I've heard about a lot of problems with that, so much so other users use older versions of vice as it works better for that. But I can't back any of that up, it is just what I've heard on forums and emails.
Yes, Jay I am still combining boards.. :) Roberto, actually I did have issues with Fastcopy restoring images of my first BBS from back in 1993, it would lock up in Windows version r38882, I am using r38886 on my linux test bed and am copying files with no issues right now. I haven't tried restoring those images I have from my old board just yet. I am copying files from d4m disks using CopyAll and so far it is copying great. I am going ot finish setting up my test bed here tonight leave it running (it will have issues with time as it runs inside a VIrtual Box VM but at least I will be able to see how it runs over the week) if it runs well till Friday I will copy my real LTK to either d4m disks or d81 disks and copy them over and run one of my BBS' on the emulation from that point forward. I will test Swiftlink if there are no conflicts between the two (there is none with my real hardware) Iwill be set to go...
Something that is happening though.. I copied about 400 blocks of files to lu 0 now I am copying about another 100 and the emulation slows to a crawl. CPU is running at 100% fps is around 59 ot 60 but the emulation is for all intents and purposes dead in the water.. I have to do a reboot and when trying to reboot, it doesn't like ALT F12 or the x I have to forcibly shut it down.
I will keep an eye on that..
Okay. Well, the best thing is to try to replicate the problem. If you can do so, reliably, then send me the files and procedure you did to cause the problem. I recently submitted a bug fix for the FD-4000 emulation. I don't know which svn has it though. You may or may not have it. It may be causing some issues as well. I'm not sure if the copy-all uses any fast disk code from the LTK and how it affects the FD-4000.
You should be able to warp the system so that it runs faster during the copy. I did a lot of testing with warp on and it works just fine.
I don't know the difference between the two versions of vice you are using. There are a lot of changes form day to day and your issues may not have anything to do with the LTK emulation. Try to run it with the least possible number of features. For example, turn off the sound, or set it to "dummy" output and that might correct or help with somethings. I'm told a lot of vice's time is spent dealing with the SID emulation.
I am hitting the sack right now but I will do a bunch of testing tomorrow night. I have a fully configured BBS running on it now. I just have to setup the modem properly and I will be able to connect and get things moving for testing tomorrow night.. Thanks for this Roberto I never thought I would see the day when the LTK could be emulated... I just installed a BBS on it and ran through it head to toe remotely Swiftlink works fine so far, DTR Hangup is an issue at the moment but I can get around that.. I will report back when I have more info.. Thanks again...
Al, I've been able to "trick" DTR into behaving somewhat by running the &D2 command from dsp.modem 8 (on DS2) and +.modem (on Image). And there's no shame in using the cursor right cheat from the 11.1 days. (ats2=27) if using BBS-Server.
If you're using TCPser it will no doubt work using ats2=43 and +++ with the &D2&C1 hook. I've learned to live without DTR after all these years.
There's just SO MUCH to consider and test, and play with. This is most definately a game changer.
Last edit: Jay Campey 2020-10-29
When it starts crawling for me, I just reset VICE and it's fine again, but I can't recreate the set of circumstances.
I'm almost done pulling a global off my actual LTK in hopes of cramming it on this. I've already populated 4 different users and 6 LUs each, with different versions of BBS. I have successfully run C-Net DS2 multi-node on it, answers fine and disconnects quickly. I have not tried the swiftlink version of it yet. I am insanely curious to see if I can store content beyond user 13 without risking corruption.
Am I missing the trigger for the ICQUB button, or is that not part of this implementation?
We still have to determine if the slow down is because of other changes to VICE or the LTK. What is they typical type of workload? Maybe I can simulate it. I ran several high work loads on it in the same instance, autocopy a full LU to another. Filling an LU completely, then reading it back, and more copying, so I never noticed a slow down. If the files were on "vdrive" or "fsdrive", would the same slow down happen? Which platform are you using?
How are you running multi-node? I haven't tried this, but it might be possible to run different instances of vice using the same disk image, but having a different LTK port for each instance. I actually have a real LTK and multiplexer unit, but I never tried it as I just got it about a month ago. Maybe one day.
The IQCUB button is the "cartridge freeze" button in vice. Of course you have to prepare the system first by running IQCUB.
Did you use the attachment I posted here with the pre-made disk images or using the SYSGEN I created of did you make your own? The disk geometry matters and some configurations will corrupt the system.
I originally used the geometry of my existing dual HD system, but then I came across yours that looked real attractive, so I abandoned mine in favor of yours. Not proud of the fact that it took me 45 minutes just to do the math originally.
For the multi node, I just ran 4 instances of vice with the same 3 HD images, but different config files, and different cartridge files. I wasn't sure if the chips on the cartridge got written with geometry info, so I just made a separate one for each. In theory, 4 machines would need 4 host adapters anyway, so I just replicated that scenario.
Each config file calls a different LTKport=#, and has a separate modem setting. Other than that, they are identical.
Once loaded, I had to turn on NMI trap for all 4 ports, and adjust the startup LU/USER in CONFIG. From there, it's all up to the BBS software.
Is this the scenario then the slow down happens? Maybe it is when you have multiple instances accessing the same file.
I setup that config so LU10 was on one disk, LU0-4 was on another, and LU5-9 on another. The idea was incase the DOS got hosed, you could rebuild it without damaging the data on the other LUs. I'm not sure how the shared file access will work, but according to the LTK manual, you should never have two systems writing to the same LU.
You can use the same ltk.crt or bin file. It doesn't change or store anything other than the serial number, but the LTKserial parameter will adjust this accordingly.
Well, I'm glad this works. This was one of the original motivations for doing this: BBSes and shared disk space which the LTK provided. I hope to see more C64 BBSes on the internet now.
Do you have the LTK clone? I'm intersted in getting my hands on the 7.3 DOS what was "updated" for it. I would like to test that.
Please keep me updated on anything else you find. I want this to be as stable as possible.
BTW, do you have any other software for the LTK? I heard someone made a backup to tape thing for it, but I can't find it. I would like to get that to work too.
I have the original LTK (serial# 87000003), but I do have the updated ROMs in the original HA and the 7.3 DOS disk. I keep my original ROMs put away just in case I decide to sell this thing to a religious purist. The original seagate took a dump years ago so I got the Rear Admiral internals to replace it but used my original casing.
One thing I will be watching for, sometimes on my RA unit I get "User bleed", which is when I have files within 1 USER partition of each other, I can access content between them sporatically. For example, I backup my BBS data file from LU1 USER0 to LU1 USER1. From time to time, the BBS will read data from the wrong USER. I have to separate the USERS and stick to only using even numbers. For whatever reason, leaving a space in between them helps with that.
The ROMs are just a first stage loader. They shouldn't matter much, but back then the SASI drive spec (pre SCSI-1) was implemented different on some drives so they may have had to make some modifications to make things work right for the changing drives which they offered, at least on boot up. They probably also had to do some stuff with the LTK multiplexer in case another port was using the drive.
Just to confirm, 7.2 was the last official DOS. 7.3 is the LTK clone version, correct? Were there any patches after the release?
As for the USER problem, I'm sure the LTK still has some bugs. I suggest you use different LUs to back up data and avoid the USER option. The USER value is simply a separate attribute to the file so I can see how things might get confused. I'm also helping out on the LTK dos project which is trying to reverse engineer the DOS and make it so it can use larger disks as well as any other features. If you can reliably replicate the problem, I'm sure I can hunt it down.
With vice it it is easy to do backups. You just start up with different images. You can keep your backups on another image that you use from time to time.
Well I've not been this excited about VICE since FD4000 became a thing.
That's correct, 7.2 was the last release. 7.3 is the RearAdmiral clone version, and I'm a nosey b@$+ard so I snoop around a bit, and a file comparison shows very little more than hex edit painting. Even the spacing is the same. So make of it what you will.
Yeah, I just compared it to 7.2. It is a blatant duplication and the only thing that is different is the branding. Sadly, he claims credit for the whole DOS and removed all references to the original authors. I was under the impression that there was an improvement based on his ebay ad for selling the clones. Perhaps the documentation is better, or am I wrong there too?
I found it humorous that even the PLAs on the host adapter are branded in that fashion. A few of the dos commands are also altered. SHIP instead of PARK for example. The load screen of the device even, with the author's name and company are the exact letter length. As I would expect if I were to sector edit my name onto it.
Hell, I'll even dump the new ROMs for you so you can offer that version as an option for the emulation. I doubt he will give you much trouble at the patent office. LOL
If you want to, sure, but I don't think they will be that different. In fact, the original ROMS accidently have code from Jason Ranheim's Promenade programmer at the end. I'm sure that will be included in the clone ROMs as well.
i wonder how this is supposed to work? after the ltk.crt is loaded i cannot access drive #8 anymore, so no, i also cannot launch load"*",8,1
well, i can, but it does NOT load from the attached dos72-s1.d64
so after all the ltk_install.txt are either misleading or i am too stupid.
Last edit: Querino 2020-10-29
Did you add the drive image's as well to the LTK Host Adapter menu, under the Cartridges menu? And if so, did you decide to use the existing ones or make your own?
I ended up making my own from scratch. I might have needed to done the DOS install using 1541 as drive #9 but I'd have to redo it to verify. If you are using the images that were provided, then after you added the LTK cartridge and it rebooted, it should boot to the LTK bootup screen instead.