UHS FAQ. If you dont know what a FAQ is, too bad ;) Questions are as follows: 1) What is uhs? 2) Why do you like the C64? 3) How fast will UHS be? 4) Just how compatible will it be? 5) Will it use kernal calls for compatibility? 6) What are the maximum partition sizes? 7) Will it support CD-ROM drives like the regular PC drives? 8) Will it have any ROMs to improve other areas of the c64 that are lacking? 9) Why SCSI? Why not something more common than IDE? 10) Will it work in 127 Native mode? 11) Ah.. 128 mode. 12) When will it be finished? 13) How much will it cost? [me!!] Answers: 1) What is uhs? UHS is an alternative mass storage system for stock- and supercpu-equpped commodore 64 machines. The ultimate goal is to provide a reasonably priced performance/speed ratio while keeping a decent amount of compatibility with current software. 2) Why do you like the C64? Why do _you_ like the C64? I'm sure its for the same reason. If you dont like the c-64, I'm certain you wouldnt understand without experiencing the c-64. I'm not talking about some silly thing running in an emulator window like vice or ccs64, although they give you an idea. It's just not as impressive to see it on a fast peecee's display. What's impressive is seeing what a ~1mhz cpu can do given the right programming skills and hardware combinations. 3) How fast will UHS be? That depends on the system in use. UHS intends on fully supporting the superCPU, and in fact, intends on being drastically enhanced if one's present. Using a stock system, UHS will use a DMA controller to burst data in as fast as the system clock will allow. For techies, that's one byte per bus cycle ;) On the SuperCPU, DMA will be disabled, due to technical issues beyond the scope of this question ;) Overall, however, a 1meg/sec burst is still possible to all 16 megs of memory. Practical speed is as-yet unkown. UHS will have many features, which leads to lots of code before the file gets accessed. However, actually reading the file should still be very quick, and on a stock system, I figure on getting at LEAST 150k/sec average speed, and possibly as much as 5-600k/sec on optimised routines in the future. SuperCPU systems will enjoy a reliable 7-800k/sec I believe, since the SCPU can do thinking tasks between block requests and byte fetches. The DMA chip will be disabled in this mode, because DMA from the cartridge port can only access the first 64k of ram. ;) 4) Just how compatible will it be? Compatibility will be a lesser point. UHS will support any program that makes kernal calls, including illegal (but common) calls to the GETBYTE routine. Due to filesystem changes and partition size limits, however, GEOS and alike environments will have difficulties due to limitations in the VLIR file structure. Creating support for these systems is planned, but is currently a low-priority project. 5) Will it use kernal calls for compatibility? Yes, and no. :) Since its a custom storage device, it wont be using kernal calls to access its own hardware. However, it WILL be using kernal calls to access other devices, like the 1541 or CMD HD. Using UHS is a matter of making kernal calls, and will support most regular command-channel commands as well. 6) What are the maximum partition sizes? That question is more complex than you might realize. UHS isnt a disk drive. Rather, its a storage system and OS extension for the c-64 kernal. Using CBMfs (the sector-linked filesystem identical to the 8050, 4040, 1541, 1571, 1581, cmd hd, ramlink, etc), the maximum will be 16 megs per partition. However, UHS will support, and in fact, prefer, a native 32-bit filesystem designed and optimised for use on classic 8bit machines. Since the standard hardware sector size of a scsi harddisk is 512 bytes, and the filesystem is 32-bit, there's a "limit" of two terabytes per partition. ;) Other filesystems will be supported in the future also. Refer to the cd-rom questoin below. 7) Will it support CD-ROM drives like the regular PC drives? Damn skippy it will. The only real challenge here is figuring out the ISO9660 filesystem (ISOfs), and making a driver for the cd-rom drive itself. Reading a CD-ROM is almost identical to reading a harddisk, so this shouldnt be too difficult. This is a medium priority part of the project ;) 8) Will it have any ROMs to improve other areas of the c64 that are lacking? I've discussed with AR developer C0untz3r0 with the possibilities of adding AR-like functions to the UHS cartridge for stock systems. Since UHS, by design, will turn itself into a 'kernal' cart if it detects a stock system, it will be free to improve on any area of the c-64 the user desires. The OS is loaded from floppy disk, or from the harddisk, into the kernal cart before it's engaged, allowing the user to quickly and easily load patched kernals, even if they dont support UHS. ;) As for the freezer functions present in the AR carts, these may or may not be present, depending on the complexity required to implement them. 9) Why SCSI? Why not something more common than IDE? Why ide? Why not something that so easily supports 8bit systems? Realistically, I researched IDE, and decided (after staring blankly at the documentation) that I just didnt like it. To be honest, I dont even understand how IDE works. I tried, I failed. :( Why scsi? IDE doesnt belong outside a computer. It wasnt made for that. SCSI can be inside, or outside. it's equally comfortable in both environments. Also, have you seen an IDE flatbed scanner? ;) Dont bother re-reading that question. I did, in fact, say scanner. UHS aims to have sufficient speed to provide support for streaming devices like scanners and tape drives. While the OS itself wont support a scanner, UHS will provide a generic SCSI program interface so that someone else is free to support these devices ;) I could go on and on and on and on why scsi is better. Technically it IS better. The design is more found, supports multitasking, supports multiple hosts on one bus (a majior selling point for me), allows bus lengths over 5 metres, etc, etc. A real selling point for me, its an 8-bit bus. I wont have to make any screwy glue logic to interface a 16bit device with an 8bit bus. ;) I realize scsi is more expensive, but how many SCSI drives <2gigs have I seen for <$100? Lots. SCADS.. HOARDS!!! Muahahahha! >:-) 10) Will it work in 127 Native mode? Um, what's a 127? 11) Ah.. 128 mode. Oh!! :) I dont have a c-128. If someone would care to donate one in my direction I'll be able to work on it. ;) I know approximately zippo about native c128 programming, however, so initially, its going to have to be a c-64 only device. Sorry. :( UPDATE: Mech has offered to send a flat 128 to me for the cost of shipping. I guess people would like to see UHS on their beloved 128's! ;) Now all I need to do is learn the tech side of the 128 and I have it made. 12) When will it be finished? See the goals link on the UHS main site. If that file's still empty, this indicates that I'm still evaluating the amount of time each stage of development will take. A special note needs to be made>> Seeing interest in this project encourages its development and completion. UHS was originally going to be some lil kernal cart with a scsi chip attached for lil old me to access a scsi drive, so that I would be able to work around the pricing issues of a niche market that CMD is unfortunate enough to have to follow. I've heard rants and what-not about CMD's prices, and lack of support. I understand their position to some extent, as they're a business trying to stay above ground. (gets off pulpit) 13) How much will it cost? [me!!] I dunno. =) I expect my development board to cost me in excess of $150 to make. This includes fried chips, design time, short-run PCB production, etc. Final development devices will be available in several forms, prices dependant on what I have to pay to get the parts. I dont really intend on selling UHS in assembled form unless there's either a (real) small demand for pre-assembled units, or a (extremely) large demand. ;) I'll offer bare PCBs, hopefully solder-masked and silkscreened, PCBs with custom chips (i.e. any PLA/GAL/PLD's and the rom), as well as full kits.