8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / JIFFYDOSMSGS.ARC / 01JIFFYDOS < prev

Wrap

Text File | 2019-04-13 | 15.9 KB | 388 lines

Would CMD be considering manufacturing the C-65 should it become available for them to do so? Doc. ------------ Category 12, Topic 6 Message 79 Thu Oct 14, 1993 C128.JBEE at 04:49 EDT Good question! ------------ Category 12, Topic 6 Message 80 Fri Oct 15, 1993 CMD-DOUG at 00:35 EDT I'm sure we'd give that prospect due consideration if it did become possible, but I don't forsee it. I'd have to wonder just how we'd make the required custom chips without spending a few million dollars on building a chip fabrication facility... ------------ Category 12, Topic 6 Message 81 Fri Oct 15, 1993 D.BURR at 00:59 EDT And a practical answer! ;) ------------ Category 12, Topic 6 Message 82 Sat Oct 16, 1993 D.TUOMI [Doctor] at 07:21 EDT Well, with the rumors of Commodore's demise on the wind, perhaps you could get whomever might buy up CMOS to make you up a few since the masks and everything must be complete. Doc. ------------ Category 12, Topic 6 Message 83 Sat Oct 16, 1993 CMD-DOUG at 11:56 EDT The masks are not really complete, so far as the last info I have on that subject. So far as I know, there were still some chip bugs existing at the time the project was cancelled. Even if they were complete, the cost of having them produce the chips would be extremely high. Normally, in the chip industry, you need to produce at least 10,000 chips to make a run cost effective. Less could be produced, but the cost per chip goes right through the ceiling. In the long run it would probably be cheaper to alter the designs to try to use something already on the market, but this of course leads into a lot of re-design time. Personally, I don't think there is any way you'll ever see a production version of this machine. Only a very large company, with a lot of cash to burn could possibly bring this to market, and I certainly wouldn't count on finding such a company outside of CBM willing to gamble on an 8-bit machine, no matter how good it is. ------------ Category 12, Topic 6 Message 84 Sun Oct 17, 1993 L.MCCLURE at 10:49 EDT D.TUOMI [Doctor]: I thought Commodore had sold off the CMOS chip manufacturing division some years ago (during another financial squeeze). ------------ Category 12, Topic 6 Message 85 Sun Oct 17, 1993 CMD-DOUG at 15:05 EDT No, they did not sell off MOS, but it is no longer known by that name. I believe they currently refer to it as the Commodore Semiconductor Group (or Division). Without this facility, Commodore wouldn't be able to design and manufacture its own chips for the Amiga so cheaply, and I suspect they'd have had to hang it up a long time ago without this ability. ------------ Category 12, Topic 6 Message 86 Tue Oct 19, 1993 D.TUOMI [Doctor] at 04:26 EDT Well, one can only dream. Doc. ------------ Category 12, Topic 6 Message 87 Sun Sep 11, 1994 J.BARBER9 [Dan Barber] at 00:19 EDT Is JiffyDos compattable with ARC? Thanks in advance. :) Dan ------------ Category 12, Topic 6 Message 88 Sun Sep 11, 1994 CBM-ED [e.g.bell] at 05:19 EDT Yes, Dan... Jiffy Dos gets along just fine with ARC. ------------ Category 12, Topic 6 Message 89 Sun Nov 06, 1994 D.LAUX [Taz'z Dad] at 13:50 EST I Doug Hi Doug :-9 )...If I install Jiffy Dos in my 64 is Geos Still going to Boot??? E-Mail or Reply To D.Laux Thanks ------------ Category 12, Topic 6 Message 90 Sun Nov 06, 1994 B.MASSE [BIG BOB] at 15:09 EST Category 12, Topic 6 > Hi Doug :-9 )...If I install Jiffy Dos in my 64 is Geos Still going > to Boot??? E-Mail or Reply To D.Laux Thanks ------------ I aint Doug, But I can tell you right now that GEOS will just IGNORE JiffyDos, And load up just the way it always did, SLOWLY! If someone suddenly told me "you must choose between Geos and JiffyDos". JiffyDos would win. Bob ------------ Category 12, Topic 6 Message 91 Sun Nov 06, 1994 CMD-DOUG at 18:50 EST JiffyDOS won't interfere with GEOS at all, but it also won't do much in the way of speeding any disk access under GEOS, either. ------------ Category 12, Topic 6 Message 92 Mon Nov 07, 1994 D.LAUX [Taz'z Dad] at 03:59 EST Thanks...Everyone I thought replacing the Kernal would affect Geos! [C! But I'm pretty new at all this and the trouble I have had with Geo's Boot Disks o are frightning real s SCARY See !!! ------------ Category 12, Topic 6 Message 93 Mon Nov 07, 1994 B.MASSE [BIG BOB] at 10:02 EST Category 12, Topic 6 Thanks...Everyone I thought replacing the Kernal would affect Geos! [C! But I'm pretty new at all this and the trouble I have had with Geo's Boot Disks o are frightning real SCARY See !!! ^^^^^ GEOS= SCAREWARE I can certainly relate to that! Once you get used to the system (that is if you don't fry the disk in meantime) you will find it is a very good system. And JiffyDos will turn your machine into a lean mean screaming computing machine... except when in GEOS. You'll love it. Bob ------------ Category 12, Topic 6 Message 94 Tue Nov 15, 1994 J.THOMPSO122 [JIMBOB51] at 20:17 EST Amen ------------ Category 12, Topic 6 Message 95 Sun Dec 18, 1994 I.MCKINNEY [TheBigMac] at 04:18 EST A member of my user's group was wanting to trade a 128D with me for my JiffyDOS and VDC chip equipped 128. I also own a RAMLink. If I got the 128D, would I also need to get a drive ROM for the built-in 1571 drive to retain the JiifyDOS loading speed? ------------ Category 12, Topic 6 Message 96 Sun Dec 18, 1994 CMD-DOUG at 10:43 EST Yes, the internal drive isn't handled by the RAMLink. ------------ Category 12, Topic 6 Message 97 Sun Jan 22, 1995 E.GBELL [e.g.bell] at 00:01 EST I have a question about JiffyDos that has consumed some time and I simply can't waste more time trying to figure it out on my own. I have a program I wrote that, among other things, offers a batch scratching capability. I reasoned that the scratch command is only 1 character different that the JD lock command, and my program could thus be easily enabled to lock batches of files (or unlock them) by just putting in an 'l' where the 's' was. Works fine on the RamLink. However, it does not work on the 1581 or 1571. Any suggestions Doug? Does this sound like something that makes sense. Just to make sure of things, I did a hack in BASIC to send the commands 1 char at a time as in ML (w/a <CR> on the end) and this returned a syntax error on all devices, even the RamLink, and I did put a delay after each char sent to the device (and tried it w/o delays too). Bottom line is I have to put a qualifier in my menus which I'd prefer not to have there. But is there any reason you can offer why JD is reacting this way. Since it is a JD command, and since it works on the RamLink with the exact same code, I am coming to the conclusion that something is different in the way Jiffy Dos acts with the 1571/81, or at very least, on the serial bus. Also, while I'm on this subject, I would like to ask another question. I have seen in your posts (Doug), and in your documentation, referenes to 'efficient, well-written machine-language routines', but have never seen an example from the most logical source, CMD. Are there such examples? I'Ve seen similar comments over the years about Xmodem/Punter stuff from people who would not know how to code either... which is not the case w/CMD. If there are not such routines, doesn't it seem there should be? And would this not make a great article for your magazine? I for one would like to see what these efficient, well-written machine-language routines look like. :) ------------ Category 12, Topic 6 Message 98 Sun Jan 22, 1995 CMD-DOUG at 02:04 EST The Lock command, ah yes... if memory serves me correctly, there are two variations here... I could be wrong, but it seems to me that the JiffyDOS version requires first that the drives be equipped with JiffyDOS drive ROMs, at least in the case of the 1581 and MSD. It might also be that the syntax given in the JiffyDOS manual is not correct, and that the L needs to be OUTSIDE of the quotes. It's been, well, years since I played with that command much myself on anything but an HD, RL or FD. I'll try to take a look at it next chance I get. Efficient, well-written code. Heh, don't you know by now there is no such thing? ;) But in all seriousness, you're probably as familiar with writing efficient code as anyone. Efficient code is that which attains the objective in a minimal number of clock cycles, OR using the fewest (or as few as is reasonable) number of bytes. Many of us just write code that gets the task done, with a few changes here and there while debugging. Rarely do we tend to go back and analyze how to make the code more efficient, unless absolutely forced to. Usually when we mention efficient code, we're talking about speed efficient - not size efficient - since we deal most often with I/O code, where you want to get speed. Well-written would probably be best if read as 'well-behaved', since that is what we generally mean by that statement. What we're saying here is that it shouldn't skip necessary steps like clearing the status byte, or skip UNTALKing a device before telling it to LISTEN, and other such things. For that matter, using TALK and LISTEN and the other super-low-level Kernal I/O routines themselves are sort of a no-no, since there are devices out there that don't work with them (such as the Lt.Kernal drives). Here's another one... don't assume that RAM vectors hold a specific address - always read the vector and store it for your return if you plan to re-direct a vectored routine to your own routine first. All of these things lead to better compatibility with various systems, as opposed to the "well, it works fine on MY system" approach. A great example of a bad coding decision came in Super 81 Utilities, where they decided to determine if a drive was a 1581 by checking the ROM CHECKSUM value! Had Commodore ever offered an upgrade ROM to the 1581, that program wouldn't have worked with it. As you can probably guess, this kind of info could probably stuff a book, but it isn't likely to all come from one source. It would take getting a lot of expert programmers to scour their notes and brains to even scratch the surface. But you're right - it would make a good subject to cover, even if we couldn't do it full justice. I'll look into what we might be able to do by way of Commodore World along those lines. Thanks for the 'push'. ;) ------------ Category 12, Topic 6 Message 99 Sun Jan 22, 1995 E.GBELL [e.g.bell] at 08:38 EST Good answer! All of what you identify as efficient code is what I suspected you had meant. As to the locking command, I do want to say that I can use the JD '@' command to lock files on all drives successfully. This works as the manual describes it. What I cannot get to work on the 1571/81 (both of which do have JD installed) is an ML routine that sends the DOS command byte by byte. I would have assumed that your wedge traps the '@' commands and twiddles them somehow before sending to the unit, but my code works with the RamLink flawlessly. Just can't get it to send anything the 71/81 like... always get syntax errors. ------------ Category 12, Topic 6 Message 100 Sun Jan 22, 1995 C128.JBEE at 09:58 EST > I'Ve seen similar comments over the years about Xmodem/Punter stuff from > people who would not know how to code either...If there are not such > routines, doesn't it seem there should be? And would this not make a great > article for your magazine? I for one would like to see what these > efficient, well-written machine-language routines look like. :) You mean something like the Bellterm code in Lib#9? ;D ------------ Category 12, Topic 6 Message 101 Sun Jan 22, 1995 CMD-DOUG at 13:45 EST Ed, Without having a chance to check with Mark, I believe that the 1541/1571 and 1581 file locking is not completely in the drive ROM, but is part of the computer's JiffyDOS. From the comments in the JiffyDOS manual (and it has just been so long since I wrote it that I don't recall) it appears that the 1581 and MSD JiffyDOS drive ROMs recognize when the computer is attempting to do a 1541/1571 file lock, and they have extra code to "translate" that action since those devices handle it differently. Where I think the problem is, then, is that your ML sends this command as if it were a drive command, whereas the command is only accessable via JiffyDOS' BASIC error vector redirection command detection routines. All that technobabble means is that your ML would have to dummy the computer into thinking it's executing a BASIC instruction, similar to the way MCOPY sends the @P0 command to disable RAMLink parallel code. It's a, er, difficult thing to code (read PITA). Bottom line is, it isn't as easy as you might have hoped. ------------ Category 12, Topic 6 Message 102 Sun Jan 22, 1995 E.GBELL [e.g.bell] at 17:12 EST O well... glad I asked before spending 2 days trying to code for it. What you are saying makes perfect sense about why it does not work. I don't think it is worth my time to make my code do it, esp. since it works fine on the RamLink, where I really needed it when I decided to add it. I know there is a way to get ML programs to be able to call Basic commands because programs like Intelligentsia and cSDOS do it... Probably not all that complicated.... tho I don't know how the JD commands re-enter after execution... probably through the main BASIC vector I'd guess. I'll have to give it a thought... perhaps something like this.... .... ahhh, maybe I'll check out what it would take to execute a bASIC command from ML. I probably have the code to do it already in MegabAsic in the merge routine.... I believe it redirects the main vector back into itself after each line is merged if I recall right. Tho this is piqueing my interest, it is more work than I think I need to put forth right now. Thanks for the good answers. They have doubtless saved me a day or two's work doing something that cannot be done as I had originally thought! ------------ Category 12, Topic 6 Message 103 Sun Jan 22, 1995 J.THOMPSO122 [JIMBOB51] at 21:26 EST >MY system" approach. A great example of a bad coding decision came in Super 81 >Utilities, where they decided to determine if a drive was a 1581 by checking >the ROM CHECKSUM value! Had Commodore ever offered an upgrade ROM to the 1581, What are you talking about? I boot Super utlities from my 1581 and it crashes then I boot it from my 1571 and it runs fine. When I type list I catch "poke??" then it says Blitzed! Is there a patch for this? Since I use Jiffy Dos I'm not going back to the old ROM. Also FAST/TRAC won't boot from the 1581? Jimbob;] PS Have you ever thought about a dos shell on a chip for that free socket in my 128. Maybe some utilites like the Partner 128 Cart? ------------ Category 12, Topic 6 Message 104 Sun Jan 22, 1995 CMD-DOUG at 23:00 EST I've had no trouble booting Super 81 Utilities from a 1581 in the past. As for FastTrac, I've never owned a copy, so I don't have any experience with it. We had a project scheduled at one point for a utility ROM for the 128, but other more important projects shuffled ahead of it. ------------ Category 12, Topic 6 Message 105 Sun Jan 22, 1995 C128.JBEE at 23:43 EST FastTrac 128 has serious bugs and would corrupt 1581 partitions when copying files. I returned mine to SSI for a refund. ------------ 12 |