Rear Admiral goods received (upgrade for the Lt. Kernal)

RobertB · August 17, 2010, 12:43 PM

In the mail today, I received my upgrade package for the venerable Lt. Kernal hard drive. Wow, after 25 years since the Lt. Kernal was first produced, here is a new package, copyright 2010!
A bit of a back story... Originally from the collection of another user, the Lt. Kernal sat in my storage for several years. About 3 years ago, I dug out the Lt. Kernal, and LtK expert, Andrew Wiskow examined it. The hard drive box was there, the host adapter cartridge was there, a cable was there... but where was the rest of it? The modded C128 with MMU adapter to which the cable was attached? The modded C128 could not be found or could not be recognized among the others in storage. Well, with the help of C= tech Charles Gutman, he and Andrew got the LtK up and running after replacing the original, frozen hard drive mech and fashioning a new cable so that the LtK would work on a C64. Having the LtK work with a C128 remained a dream.
2010 came around, and after discussion with Jeff J., I found out he was working on a LtK-compatible hard drive called the Rear Admiral. He also had parts and program to upgrade the older LtK's and bring them up to Rear Admiral standards. That included the MMU adapter!
O.K., I paid the bucks. Here's what I received in the package -- the Rear Admiral DOS v7.3 disk (improved over the original LtK DOS), the RA Boot EPROM (for the Host Adapter), two RA PLD chips (for the Host Adapter), and the C128 MMU adapter (for a flat C128, not the version with the different cable lengths for the C128DCR).
The MMU adapter requires a bit of work to install on the C128. I'll keep everybody informed on how everything goes.

Photos to come,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

BigDumbDinosaur · August 18, 2010, 11:01 AM

Quote from: RobertB on August 17, 2010, 12:43 PMIn the mail today, I received my upgrade package for the venerable Lt. Kernal hard drive...The MMU adapter requires a bit of work to install on the C128. I'll keep everybody informed on how everything goes.

The MMU daughterboard installation should be straightforward. The one you should have received is a narrow rectangle and fits both the flat and DCR models. It is possible to incorrectly install it, but takes some doing. Does the daughterboard look something like the following image? The blue lines represent the board's perimeter. Other details will vary.

RobertB · August 18, 2010, 11:36 AM

Quote from: me on August 17, 2010, 12:43 PMPhotos to come...

Here they are. The first ...

DOS upgrade disk and Host Adapter chips,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

RobertB · August 18, 2010, 11:38 AM

The second...

The Host Adapter upgrade chips,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

RobertB · August 18, 2010, 11:46 AM

The third...

MMU adapter and cable,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

RobertB · August 18, 2010, 11:49 AM

The fourth...

Close-up of the MMU adapter,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

RobertB · August 18, 2010, 11:56 AM

The last photo.

Not pictured are the 2 1/3 pages of installation instructions,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

maraud · September 03, 2010, 07:31 AM

Is this actually available as the only reference I can find anywhere is your post. I have two LtK's and would be like to see what this swap has to offer!

RobertB · September 03, 2010, 02:39 PM

Quote from: maraud on September 03, 2010, 07:31 AM
Is this actually available...

Yes! You can buy a complete Rear Admiral hard drive (mechanism and host adapter cartridge and cables), parts of the Rear Admiral (like just the host adapter cartridge if you need one for your Lt. Kernal), or just the Rear Admiral upgrade parts to improve your classic Lt. Kernal (the economical method to get the Rear Admiral benefits). I'd have to look back at my notes, but I also think the Multiplexer is available where you connect several Commodores to one Rear Admiral/classic Lt. Kernal.

Quote...as the only reference I can find anywhere is your post.

Right. Rear Admiral talk has been limited to "those in the know", like at certain European chats (or so I was told). Until the R.A. website is ready, though, I am not inclined to make a widespread announcement of the Rear Admiral.

QuoteI have two LtK's...

Congratulations!

Quote...and would be like to see what this swap has to offer!

I will give you the e-mail of the creator of the Rear Admiral, and you can discuss all the particulars with him.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

maraud · October 11, 2010, 01:05 PM

Thank for the contact info. I thought I'd update the thread. I've been in contact with Jeff from MyTec for several weeks. THe end result is that I got an upgrade for an existing LtK HA and enclosure, as well as a new host adapter/enclosure (to hook up an "newer old school" ZIP100 for backups) and a MUX. The main reason for upgrading one of my two Xetec units was the excitement of playing with a MUX. Long story short, the RA works exactly like the old LtK's. There are many improvements, but to be honest, I've not had time to explore those as well. However, as of this writing I've got two machines via a MUX sharing the same LtK. THe quick win here is that I can now run multiple BBS' on one HDD. In addition I'm working on a "project" for an ML-based "Remote Desktop" app. The hope is to get this to run on a 128, eventually via the embedded "extra ROM" socket. What I'm looking for eventually is a 100% test-based access to the machine via an RR Net. This would allow me to remote it and edit BBS system files, (for other systems via MUX) live.

Great product, and excellent support from Jeff. Oh, I also got one of his MMU adapters to take a legacy Xetec 64 unit and get it running on a 128. Great stuff there too!

BigDumbDinosaur · October 11, 2010, 03:15 PM

Quote from: maraud on October 11, 2010, 01:05 PMHowever, as of this writing I've got two machines via a MUX sharing the same LtK. THe quick win here is that I can now run multiple BBS' on one HDD.

You'll need a little more than a working Lt. Kernal unit with MUXer to run a multiple line BBS on your system. The Lt. Kernal DOS doesn't have any method by which record, file and LU write operations can be limited to one workstation, an essential feature on any system that allows concurrent user access. As an example, if someone on one line is uploading a file to an LU and someone on another line starts doing the same thing to the same LU, it is highly likely that you will end up with a corrupted LU due to unarbitrated writes to the directory and BAM. In some cases, the same disk block could get allocated by two different workstations, leading to crosslinked files, a problem that frequently plagued MS-DOS years ago.

A similar problem exists with RELative files. In order to reduce disk activity, the LK's implementation of RELative files may result in delayed disk updates to modified records. This means the disk version of a file may not immediately reflect any content changes. As individual workstations have no knowledge of what other workstations are doing, you may also get bitten by an effect I describe to non-technical types as the "Peter, Paul and Mary" syndrome:

Mary, the lead salesperson of a mail order company, is on the phone with long-time customer Peter. Having been told that his shipping address has changed, Mary retrieves Peter's customer master record so she can update it. Mary chats with Peter for a minute or two before actually editing his address. At the same time and unbeknownst to Mary, Paul in the accounting department also retrieves Peter's customer master record, edits the credit limit field and immediately saves the changed record. Shortly after Paul has updated Peter's credit limit, Mary finishes editing the address field and saves her changes. However, she saved her edits after Paul saved his, causing Paul's change to the credit limit field to be overwritten with the old information that was part of the record written out by Mary's workstation. Paul's work has been lost and as far as the system is concerned, Peter's credit limit hasn't changed at all.

Incidentally, consider what would have happened if Mary had saved her changes before Paul saved his. Peter's new credit limit would have been saved but his new shipping address would have been reverted to the old one, causing future orders to be delivered to the wrong location!

I'll let it go at that for now, but give it some thought before you start pounding code into your favorite text editor. BTW, some of the technical information required to compensate for this oversight in the Lt. Kernal DOS exists on line but is incomplete.

RobertB · October 11, 2010, 04:19 PM

Quote from: maraud on October 11, 2010, 01:05 PMHowever, as of this writing I've got two machines via a MUX sharing the same LtK.

Sweet! Hey, can you post pictures of the parts you got?

QuoteIn addition I'm working on a "project" for an ML-based "Remote Desktop" app. The hope is to get this to run on a 128, eventually via the embedded "extra ROM" socket. What I'm looking for eventually is a 100% test-based access to the machine via an RR Net.

That's an interesting project.

Back from the SCCAN meeting,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

maraud · October 12, 2010, 03:04 AM

I should clarify that I'm not running a multi-line BBS, but rather multiple BBS' off of a single HD unit. They're separated by LU / USER designation.

BigDumbDinosaur · October 12, 2010, 03:51 AM

Quote from: maraud on October 12, 2010, 03:04 AMI should clarify that I'm not running a multi-line BBS, but rather multiple BBS' off of a single HD unit. They're separated by LU / USER designation.

If each BBS is confined to exactly one LU then you should be okay. If two or more BBSes run out of the same LU, you will have opened the door to LU corruption, regardless of the USER area in use.

The USER area is merely a four bit flag in each file's directory listing that produces the illusion of isolation. All files in any given LU are cataloged in the same directory without regard to the USER area. The LK DOS primitives that read and write directories simply skip over directory entries whose USER flag bit pattern doesn't correspond to the currently-logged USER area. Correspondingly, all files in any given LU share the same block pool, which is maintained in the DISCBITMAP file. This is why concurrent LU access can be hazardous to the LU. BTW, should something like that ever happen, immediately VALIDATE the LU as soon as the problem is discovered.

maraud · October 12, 2010, 01:41 PM

Thanks for the insight BDD. I had kinda figured out that the "USER" designation was simply an attribute for the file. I arrived at that assumption based on how quickly MOVES occurred. However, to be honest, I didn't take into consideration that they're not actually separate directories.

That all said, I'm still quite enjoying exploring the possibilities of multi-use. To be honest that's the only reason i've really pursued the RA equipment (well not counting of course that it's new and thus I'm less likely to fall prey to failure of 25 year old components). I mean all said, the RA unit's have cost more than the vintage xetec equipment I have. However, I like supporting folks in the retro-dev-world, and the owner of MyTec has been a very valuable and personable resource!

BigDumbDinosaur · October 13, 2010, 04:41 AM

Quote from: maraud on October 12, 2010, 01:41 PMThanks for the insight BDD. I had kinda figured out that the "USER" designation was simply an attribute for the file. I arrived at that assumption based on how quickly MOVES occurred. However, to be honest, I didn't take into consideration that they're not actually separate directories.

The USER feature is something that was borrowed from CP/M. MOVEs are fast because all that is being done is walking through the directory structure and flipping some bits. The files themselves stay where they are. Copying or moving files from one LU to another is a different story, involving significant disk activity (the LK DOS uses "raw" disk access, unlike modern operating systems).

Logical units are a software abstraction of the dual drive concept in such CBM drives as the 8050 and 8250. However, in the LK/RA you can have up to 10 user-defined LUs, along with up to 16 USER areas (0-15). Hence a statement such as OPEN 2,8,2,"6:4:MYFILE" makes perfect sense in the LK/RA environment, 6 being the LU and 4 being the USER area.

QuoteThat all said, I'm still quite enjoying exploring the possibilities of multi-use.

As I earlier explained, the LK/RA environment has no provisions for arbitrating concurrent access in MUXed systems, which is absolutely essential if a true multiuser environment is to be supported. The lack of access arbitration is a design oversight that defies explanation, given that the MUXer was available as early as mid-1987, not too long after Xetec took over the production and sales of the Lt. Kernal.

Curiously, there is a locking stub in the LK DOS primitives, but it does nothing except clear carry before returning. Unfortunately, the stub is "landlocked" by other code, thus precluding the possibility of completing it. So anything that would arbitrate concurrent access would have to be external to the LK DOS. There is a possibility that such features could eventually be developed, along with features required to implement ISAM databases. The latter would be very useful in many applications, a BBS being but one of them. Needless to say, such an undertaking would not be trivial.

dr.v · October 31, 2010, 10:25 AM

Wow. The impression I got from your post was that the Rear Admiral was for existing Lt. Kernal units. I had no idea this would translate into ACTUAL Lt. Kernal II units being sold.

http://cgi.ebay.com/XETEC-LT-KERNAL-II-160MB-HARD-DRIVE-COMMODORE-128-NEW-/300486908771?pt=LH_DefaultDomain_0&hash=item45f66a5b63

Thinking about brand new Commodore hard drive systems being sold in 2010 makes me smile. I hope he sells lots of units.

BigDumbDinosaur · October 31, 2010, 03:30 PM

Quote from: dr.v on October 31, 2010, 10:25 AM
Wow. The impression I got from your post was that the Rear Admiral was for existing Lt. Kernal units. I had no idea this would translate into ACTUAL Lt. Kernal II units being sold.

http://cgi.ebay.com/XETEC-LT-KERNAL-II-160MB-HARD-DRIVE-COMMODORE-128-NEW-/300486908771?pt=LH_DefaultDomain_0&hash=item45f66a5b63

Thinking about brand new Commodore hard drive systems being sold in 2010 makes me smile. I hope he sells lots of units.

I can't go into much detail right now, but I'm working on a little something to go with the newly resurrected Lt. Kernal/RA system, especially one that is multiplexed. It's already up to about 2,000 lines of code...

Now, since I do all my 65xx assembly language development on a UNIX box, I had to concoct a way to transfer files over to the C-128D setup that will be used for debugging and testing. Floppy disk access is too slow and I don't feel like tinkering with programs that allow a 1571 to read DOS format disks. It so happens the UNIX machine has a plethora of serial ports (16, to be exact) and I have lots of UTP cable around here. So I cobbled together a dual port EIA-232 adapter that runs off the C-128's expansion port (with pass through), at speeds up to 38.4 Kbps. See attached PCB layout pic. As soon as I get the adapter assembled I'll post some more pics.

RobertB · October 31, 2010, 08:13 PM

Quote from: dr.v on October 31, 2010, 10:25 AMI had no idea this would translate into ACTUAL Lt. Kernal II units being sold.

I didn't know he would go the eBay route in selling the Rear Admiral.

Back from a concert,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

redrumloa · November 01, 2010, 12:21 AM

Quote from: dr.v on October 31, 2010, 10:25 AM
Wow. The impression I got from your post was that the Rear Admiral was for existing Lt. Kernal units. I had no idea this would translate into ACTUAL Lt. Kernal II units being sold.

http://cgi.ebay.com/XETEC-LT-KERNAL-II-160MB-HARD-DRIVE-COMMODORE-128-NEW-/300486908771?pt=LH_DefaultDomain_0&hash=item45f66a5b63

Thinking about brand new Commodore hard drive systems being sold in 2010 makes me smile. I hope he sells lots of units.

Nice... I remember the extreme negativity and skepticism when word of the Rear Admiral first came out. It is nice to see that indeed an actual product followed. I'm doubtful I'll ever get one as it seems to not be compatible with the SuperCPU 128. Still, nice to see new product on the market.

dr.v · November 01, 2010, 02:26 AM

I can't seem to find any mention of the Lt. Kernal II/RA drives outside of some forums and the ebay listing. Does MyTec have a website with product information?

It's tough to justify the purchase since I already own 2 CMD HD's. But the multiplexing feature makes it a very attractive product. That is something I wish I could do with my CMD HD. I recall reading in the CMD HD users manual mention of a multiplexer HD accessory, but I have never seen one. Even in all of the dieHard and Commodore World CMD ads I've read through - I couldn't seem to find any mention of such a device.

BDD - I am quite familiar with how CMD HD's work (and the associated limitations on partition size, etc. due to the HD DOS), but I have no idea how Lt. Kernal's work. What is the mathematical reasoning behind the 160mb max capacity on the drives?

Tom

BigDumbDinosaur · November 01, 2010, 07:16 AM

Quote from: dr.v on November 01, 2010, 02:26 AMBDD - I am quite familiar with how CMD HD's work (and the associated limitations on partition size, etc. due to the HD DOS), but I have no idea how Lt. Kernal's work. What is the mathematical reasoning behind the 160mb max capacity on the drives?

Actually, it's possible to go beyond 160 MB with some careful configuration. It works like this.

All internal pointer arithmetic is done with 16 bit integers. A standard hard drive block size is 512 bytes. The maximum number of blocks that can be addressed in any given logical unit (LU) is 2^16 or 65,536. Hence the maximum capacity per LU is 65,536*512 or 33,553,920â€"32 megabytes, in other words (real megabytes, not those fake SI ones). Up to 11 LUs may be defined en toto, producing a theoretical capacity of 33,553,920*11 or 369,093,120 bytes for the entire system. In practice, this can't happen because the size of LU 10 (which contains the DOS itself) is normally fixed. So the practical limit of user storage is around 320 MB.

The limitations of the Lt. Kernal DOS stem from the period of time in which the system was developed. The Lt. Kernal actually predates the SCSI-1 standard that was issued in 1986. In itself, that doesn't limit capacity as seen on the Lt. Kernal. SCSI-1 uses 21 bit logical block addresses (LBA), which can access up to 2,097,152 blocks per disk, amounting to 1 GB of storage. Up to seven disks can be attached to a "narrow" host adapter, which gives a theoretical aggregate storage limit of 7 GB. SCSI-2 and latter can work with 32 bit LBAs, which feature was added when disk sizes surpassed 1 GB.

Another limitation that the original Lt. Kernal had to face was the characteristics of the OMTI SASI-to-ST412/506 controller that interfaced the drive mechanism to the SCSI busâ€"ST412/506 drives are "dumb." As the drive had no provisions for telling the controller anything about its characteristics, that information had to be configured into the controller at boot time (the config data is stored in physical block zero on the first disk). Fiscal could have changed the system to deal exclusively with embedded controller drives, but they would have had to completely abandon their installed base of users with the older ST412/506 hardware. So they stuck with the older cylinder-head-sector method of defining disks, which meant 16 bit integers, ergo a 320 MB (give or take a few) limit.

RobertB · November 01, 2010, 02:24 PM

Quote from: dr.v on November 01, 2010, 02:26 AM
I can't seem to find any mention of the Lt. Kernal II/RA drives outside of some forums...

Which other forums?

QuoteDoes MyTec have a website with product information?

As of now, no.

QuoteI recall reading in the CMD HD users manual mention of a multiplexer HD accessory, but I have never seen one.

It was never developed.

Back from a long day,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

RobertB · November 01, 2010, 02:28 PM

Quote from: BigDumbDinosaur on November 01, 2010, 07:16 AMSo the practical limit of user storage is around 320 MB.

And I always thought it was about 270 megs.

I stand corrected,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

dr.v · November 02, 2010, 06:01 AM

BDD - Thanks for the information. As usual, I walk away from reading your posts feeling like a more enlightened person.

Robert - Like I said I simply heard mention of it elsewhere. Like in the following forum back in early October (someone mentions they own such a unit):

http://www.lemon64.com/forum/viewtopic.php?t=35339&start=25&sid=3b51cfeccd18171b4e0139a462565356

But I haven't found any posts (beyond yours) which contained any substance with resepct to the actual unit or details surrounding the release of a new product.

Tom