From jbevren@starbase.globalpc.net Sat Aug 3 18:47:35 2002 Date: Sat, 3 Aug 2002 18:32:07 -0500 (CDT) From: David Wood To: CommodoreOne@yahoogroups.com Subject: Re: [CommodoreOne] Re: available os's On Sat, 3 Aug 2002, Matthew Montchalin wrote: > And just which Kernal routines scan for the IDE drives? The routines the ide64's onboard rom adds to the kernal, of course. The commoodore kernal doesnt know what the heck a 1541 is, much less a 1571 or 1581, not even an fd 2000/4000 or cmd hd. They all look exactly the same. Havent you noticed the semantics on controlling these devices? They're all the same. LOAD the file named $ to get a directory. the kernal has NO idea that that's the directory. That's the drive controller's responsibility. The kernal further cares not how large the drive is. all it cares about is select, talk, and listen, and happens to have multiple data channels on a device. As far as the kernal is concerned, every drive is teh same. This is the beauty of it. It doesnt differentiate the ide64 from the 1541 if you use the -proper- jump tables, and even ramDOS (the 1750's ramdisk sofotware) will appear exactly the same to a user. The only difference is the command set in the firmware on the device (firmware used loosely because the 1750's dos is actually in the c64 once loaded). IDE64, RAMDOS, the 1571, the 1541, 1581 etc all use a completely different disk layout. IDE64, RAMDOS, and the 15xx/cmd drives even use completely different concepts for accessing and storing data. DOes it matter? No. Why? Cause the kernal makes it all the same via its standardised API, commonly called 'the jump table'. > If you are using Commodore Kernal TALK/LISTEN routines, then I agree > that you are using the Commodore Kernal. But if you rewrite the TALK/ > LISTEN routines, and put them somewhere else (say, in the pages > located around $5000 to $6000) then you are definitely avoiding the > Kernal. > > Bit-banging the CIA chips directly is definitely avoiding the Kernal. This is where I turn on everything I said above. :) The kernal has its limitations. The stock c64 kernal, for example, would likely never survive in 816 native mode, much less operate properly with long registers. This doesnt even mention the multitasking that Wings/JOS are capable of. The drives' firmware is the same way since its modelled after the kernal protocol. Unfortunately, its necessary to bitbang the serial port, not only on the c64, but also from inside the drives, to properly support multitasking. The c64 kernal has its place. It should be used everywhere multitasking isn't. Note that multitasking also includes irq loaders that play music while loading data (two tasks at once). If you cant stand the (lack of) speed the c64 kernal offers, use a speed loader. If you want enhanced storage to work with that speed loader, choose your loaders carefully. next topic that's covered in this thread is whether or not the c-1 kernal should scan for IDE, etc. -> I agree wholly that the commodore one's firmware should scan for ide devices. Not because I dont like the c64 kernal, but because its onboard hardware. Nothing's more irritating than having onboard hardware that's not supported by the firmware. ;) However, in c64 compatibility mode a kernal jump table should be put in the right place so that programs that think they're on a c64 will survive. This doesnt mean not supporting the commodore one's enhanced hardware like the ide drive etc, and if you think it does, start from the top of this long mail and read again. However, a good question is how much to support. Commodore Basic on the c64 doesnt even support drives. It doesnt even support the tape device. If you look close at it, it's all done by file I/O. OPEN this INPUT that PRINT this CLOSE that. Even 'load' is redirected to a kernal call ;) I think the commodore one should be similar, such that programs can be made hardware independent unless necessary (disk scanning and repair utils). This means including enough firmware to load a dos, either from a harddisk or from the CF if possible. However, since so many things are onboard, there should also be a BIOS interface, via which progams can quickly read and write devices like disks on a block per block basis, as well as fast services to getting to the screen to change modes. I realise we all hate PC, but I really recommend you look at its way of doing services. Not how to call them, but rather what services are provided. Before an OS is even loaded, its possible to change video modes to a specific set of standards, read the keyboard, send output to the screen, and read or write blocks. The PC is even nice enough to load a couple sectors from the drive for you so that you can have offboard init code (MS-DOS all the way up to windows XP use this, as do any other OS on PCs) to load the rest of your dos/OS/software. The CommodoreOne is a great invention, but we all need to take a look at what's out here before re-inventing yet another silly wheel. The PC bios interface still exists today not because it sucks like most closed minded people believe, but rather because it still works. Enough ramble ;) -David