What would make the ultimate C128 system?

Jheitmuller

unread,

Mar 25, 2004, 7:55:06 PM3/25/04

to

Hi all, I want to put together the ultimate C128 system. I want to
use a C128, not a C128D, as the base system. I only really have a
surface understanding of Commodore systems. Some upgrades are
obvious, like upgrade the video ram to 64K and install JiffyDos. What
else would you add/upgrade/modify to create a cool C128 system?

Alan Reed

unread,

Mar 25, 2004, 8:23:35 PM3/25/04

to

"Jheitmuller" <jo...@jrcc.net> wrote in message
news:de16c5ec.04032...@posting.google.com...

I recommend you check out 64HDD at http://www.64hdd.com/index_en.html
In my opinion, dollar for dollar, it's the nicest thing you can do for your
Commodore. Since I got it I'm using my 128 far more than I have in years.
Of course, you want some type of RGB capable monitor so you can use the 80
column mode of your 128. I have a Commodore 1084, but there are others.
You mentioned JiffyDOS and the RAM upgrade. There are only a few
applications that require the video RAM upgrade. Unless you're using a
program that specifically uses the extra RAM, it makes no difference
whatsoever in your 128's normal operation.

Alan

Matthew Montchalin

unread,

Mar 25, 2004, 9:18:59 PM3/25/04

to

Jheitmuller wrote:
|Hi all, I want to put together the ultimate C128 system. I want to
|use a C128, not a C128D, as the base system. I only really have a
|surface understanding of Commodore systems. Some upgrades are
|obvious, like upgrade the video ram to 64K and install JiffyDos.

If you install JiffyDos, you may well be confronting incompatibility
issues head-on. And remember, it isn't enough to install JiffyDOS
on your C-128, you also have to install it on every disk drive you
hook up to it. As for myself, I never have any reason to use JiffyDos,
so that is one modification you can skip if you want to.

|What else would you add/upgrade/modify to create a cool C128 system?

Well, it might be a good idea to install Alf Jonassen's SERVANT128 in the
empty rom socket.

Robert Bernardo

unread,

Mar 25, 2004, 10:54:36 PM3/25/04

to

On Thu, 25 Mar 2004, Matthew Montchalin wrote:

> If you install JiffyDos, you may well be confronting incompatibility
> issues head-on.

I have had extremely few compatibility problems (I can't even
remember the last time there was a problem) with JiffyDOS and
a flat C128 with 1571 and 1581 drives. And you can also turn off JD for
the total compatibility.

> And remember, it isn't enough to install JiffyDOS
> on your C-128, you also have to install it on every disk drive you
> hook up to it.

True. Without JD in the drives, you forfeit the speed loader
and bug fixes but retain the DOS wedge in the JD chip in the C128.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

Alan Reed

unread,

Mar 25, 2004, 11:13:28 PM3/25/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
news:Pine.LNX.4.44.040325...@lab.oregonvos.net...

> Well, it might be a good idea to install Alf Jonassen's SERVANT128 in the
> empty rom socket.
>

Tell me more. What is it, what does it do? Where can you get it?

Thanks
Alan

Sam Gillett

unread,

Mar 25, 2004, 11:16:07 PM3/25/04

to

"Jheitmuller" <jo...@jrcc.net> wrote ...

CMD RAMLink for one thing. When you are not using programs that take
advantage of the the extra RAM, it can be used as a very nice RAM drive. You
can store a lot of C= programs on a 16 Mb RAM drive.
--
Best regards,

Sam Gillett

Change is inevitable,
except from vending machines!

Cameron Kaiser

unread,

Mar 25, 2004, 11:29:18 PM3/25/04

to

"Sam Gillett" <samgille...@diespammermsn.com> writes:

>>Hi all, I want to put together the ultimate C128 system. I want to
>>use a C128, not a C128D, as the base system. I only really have a
>>surface understanding of Commodore systems. Some upgrades are
>>obvious, like upgrade the video ram to 64K and install JiffyDos. What
>>else would you add/upgrade/modify to create a cool C128 system?

>CMD RAMLink for one thing. When you are not using programs that take
>advantage of the the extra RAM, it can be used as a very nice RAM drive. You
>can store a lot of C= programs on a 16 Mb RAM drive.

I also recommend a Turbo232 and a Lantronix UDS-10 to give your C128 easy,
fast Internet access over Ethernet using any terminal program that supports
the ACIA (NovaTerm, HyperLink 2.5, and the Wave [needs SCPU, SuperRAM and
Wheels], to name just a few).

--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **

Rod Gasson

unread,

Mar 25, 2004, 11:25:09 PM3/25/04

to

"Robert Bernardo" <rber...@iglou.com> wrote in message
news:Pine.GSO.4.56.0403252246540.13079@shell1...

> On Thu, 25 Mar 2004, Matthew Montchalin wrote:
>
> > If you install JiffyDos, you may well be confronting incompatibility
> > issues head-on.
>
> I have had extremely few compatibility problems (I can't even
> remember the last time there was a problem) with JiffyDOS and
> a flat C128 with 1571 and 1581 drives. And you can also turn off JD for
> the total compatibility.

Robert, Almost all JiffyDos users will agree with you 100%.
Matthew is a rare exception.

Cheers
Rod

Alan Jones

unread,

Mar 26, 2004, 12:42:28 AM3/26/04

to

Add a CBM REU!
Add 128K of main memory ( 4 64K RAM banks total)
Add a Swiftlink like RS232 device for using fast external modems
Add a CMD HD or at least a CBM 1581 drive.

Matthew Montchalin

unread,

Mar 26, 2004, 1:01:32 AM3/26/04

to

On Fri, 26 Mar 2004, Alan Jones wrote:
|On 25 Mar 2004 16:55:06 -0800, jo...@jrcc.net (Jheitmuller) wrote:
|
|>Hi all, I want to put together the ultimate C128 system. I want to
|>use a C128, not a C128D, as the base system. I only really have a
|>surface understanding of Commodore systems. Some upgrades are
|>obvious, like upgrade the video ram to 64K and install JiffyDos. What
|>else would you add/upgrade/modify to create a cool C128 system?
|
|Add a CBM REU!

Yes.

|Add 128K of main memory ( 4 64K RAM banks total)

Yes, that's a good idea, too.

|Add a Swiftlink like RS232 device for using fast external modems
|Add a CMD HD or at least a CBM 1581 drive.

Well, yes, at least a CBM 1581 disk drive. But if he can't find one,
he could settle for a 1571, which is a less satisfactory alternative,
but it sure beats a 1541.

Rick Balkins

unread,

Mar 26, 2004, 1:26:33 AM3/26/04

to

"Rod Gasson" <r...@videocam.net.au> wrote in message
news:c40bfj$tve$1...@vcsweb.com...

> Robert, Almost all JiffyDos users will agree with you 100%.
> Matthew is a rare exception.
>

I follow that all up. Anyway, me and Lord Alberonn I had written a JiffyDOS
detection utility. I know about JiffyDOS's compatibility and
incompatibility. There is NO way that you can modify a C64 without some
incompatibility when those mods are active. That is because people used
every damn memory location to do things regardless of what problems may
occur. It is just impossible to expect perfect compatibility. The only
upgrade you can do will involve no mods to the internal or have a mod that
can switch between its modified mode and compatibility mode. With JiffyDOS -
it does just that. There is JiffyDOS and there is original ROMs.

If you run a JiffyDOS equipped computer in original ROM mode then you won't
have much of any problem depending on which "original" ROM revision version.
It may very slightly vary but none that I know of. I know about it.

Matthew is correct to say that you will face incompatibility but he
overlooks the fact that JiffyDOS is two ROMs in one. The Original ROM code
and the JiffyDOS ROM code and is bankswitched as to which is active based on
the switch. It did look like two ROM chips piggybacked but I am not sure
that is the case. Anyway, I installed them before and really found that
there wasn't all that much trouble. I found some program may not run when
JiffyDOS is active but most of the hacks are the ones that would fail.

Niklas Ramsberg

unread,

Mar 26, 2004, 2:56:20 AM3/26/04

to

Matthew Montchalin <mmon...@OregonVOS.net> wrote in message news:<Pine.LNX.4.44.040325...@lab.oregonvos.net>...

> If you install JiffyDos, you may well be confronting incompatibility
> issues head-on. And remember, it isn't enough to install JiffyDOS
> on your C-128, you also have to install it on every disk drive you
> hook up to it. As for myself, I never have any reason to use JiffyDos,
> so that is one modification you can skip if you want to.

I have to disagree. JiffyDOS is the best thing I have ever bought for
my 128 and 1541-II drive. Never had any compatibility problems.

> |What else would you add/upgrade/modify to create a cool C128 system?
>
> Well, it might be a good idea to install Alf Jonassen's SERVANT128 in the
> empty rom socket.

The Servant is great, but if you don't have an EPROM burner you'll
have to find someone who can program an EPROM for you.

As someone mentioned, 64HDD is nice too, and there's a freeware
version that's very capable.

A good monitor is well worth the investment. Alternatively, check out
the Commodore->VGA adaptor being developed at
http://www.commodorescene.org.uk/. Looks promising.

And of course, the Retro Replay/RR-net combo from Individual
Computers, http://www.jschoenfeld.de, provides your C128 with an
ethernet adaptor so you can surf the web (only in C64 mode for now,
but a C128 version of the Contiki software should be in the works).
Not that useful, to tell you the truth (I have one myself) but the
feeling you get the first time you run a web browser in your C128 is
unbeatable :-)

/Niklas Ramsberg
aka
< .
(:) Bacon
< .

Matthew Montchalin

unread,

Mar 26, 2004, 3:25:33 AM3/26/04

to

Niklas Ramsberg wrote:
|Matthew Montchalin <mmon...@OregonVOS.net> wrote in message news:<Pine.LNX.4.44.040325...@lab.oregonvos.net>...
|> If you install JiffyDos, you may well be confronting incompatibility
|> issues head-on. And remember, it isn't enough to install JiffyDOS
|> on your C-128, you also have to install it on every disk drive you
|> hook up to it. As for myself, I never have any reason to use JiffyDos,
|> so that is one modification you can skip if you want to.
|
|I have to disagree. JiffyDOS is the best thing I have ever bought for
|my 128 and 1541-II drive. Never had any compatibility problems.

There's nothing wrong with collecting stuff just for the sake of
collecting, but I honestly have never had a use for JiffyDOS. By
all means, he ought to go ahead and collect it. It is highly
compatible with BASIC 7.0, if that means anything to you, and you
happen to find yourself doing a lot of BASIC programming.

RajW

unread,

Mar 26, 2004, 6:38:32 AM3/26/04

to

On Fri, 26 Mar 2004 14:55:09 +1030, "Rod Gasson" <r...@videocam.net.au>
wrote:

>Robert, Almost all JiffyDos users will agree with you 100%.
>Matthew is a rare exception.

Agreed... JiffyDOS is a GREAT, useful, and timesaving addition to any
C64, C128, or 15x1 drive. Maurice/CMDRKey even has JiffyDOS for the
1541 compatible drives like the IndusGT and Enhancer drives.

If JiffyDOS gives you a problem... just flip the switch and it's back
to plain old CBM DOS. Compatibly issue goes away.

/*Raj*/

Jerry Kurtz

unread,

Mar 26, 2004, 9:11:58 AM3/26/04

to

If you're interested, I have a new Retro Replay available for $60, and
a couple 1581's available for $75 (loose), or $110 (boxed).

But I do have a question about JiffyDos... Why doesn't the 1571, 1581
and Excelerator Plus drives have a switch to revert back to the
original rom like the 1541 version?

Matthew Montchalin <mmon...@OregonVOS.net> wrote in message news:<Pine.LNX.4.44.040325...@lab.oregonvos.net>...

Paul Rosenzweig

unread,

Mar 26, 2004, 1:00:19 PM3/26/04

to

Robert Bernardo <rber...@iglou.com> wrote in message news:<Pine.GSO.4.56.0403252246540.13079@shell1>...

> On Thu, 25 Mar 2004, Matthew Montchalin wrote:
>
> > If you install JiffyDos, you may well be confronting incompatibility
> > issues head-on.
>
> I have had extremely few compatibility problems (I can't even
> remember the last time there was a problem) with JiffyDOS and

The header message excluded the use of a C128D. I'm going there
anyway. I have a RAMLink and a CMD hard drive connected to my
C128D. With all RL switches set to on, at power up to C128
mode, there is a conflict with the newer SID chip in the C128D.
Printing the CTRL G produces a tone that doesn't fade to silence.
Printing CTRL G behaves normally when all RL switches are off.
When I'm in C64 mode, I need all RL switches on to access data
on the hard drive. Most of the time, STEREOPLAYER works correctly.
I am confused.

Michael Hunter

unread,

Mar 26, 2004, 1:11:55 PM3/26/04

to

Hello Jerry,

> But I do have a question about JiffyDos... Why doesn't the 1571,
1581
> and Excelerator Plus drives have a switch to revert back to the
> original rom like the 1541 version?

The 1571 & 1581 JiffyDOS ROM chips can "detect" the mode of the host
computer and switch automatically. This eliminates the need for the
switch on these models.

Michael Hunter
mhu...@videocam.net.au

Sam Gillett

unread,

Mar 26, 2004, 1:24:43 PM3/26/04

to

"Alan Jones" <ala...@nospam.mchsi.com> wrote ...

Let's add a CMD FD-2000 3.5" drive to the list of drives. The nice thing
about the FD2000 is this; you can still find _new_ blank disks that are
compatible at most department, office supply, and computer stores.

Add to that, twice the storage space per disk of the 1581 and you have a
winner! ;-)
--
Best regards,

Sam Gillett

Global warming is caused by the sun.

mikec

unread,

Mar 26, 2004, 2:29:03 PM3/26/04

to

Hi,

Has any one bothered to ask what you plan to do with an "ultimate C128
system?"

Is it for gaming? Music? Productivity? Telecom-type apps; do you want
to run a BBS? Do you want to access the Internet? Is it for demo
coding? Do you want to write C128-specific software? Do you expect to
run it in C-64 mode more often than C-128 mode? How important is
running CP/M?

Knowing your intent will enable people to better respond to the
question.

Maybe a C-64 with a SuperCPU would be better suited to whatever it is
you want to do.

MikeC

Sam Gillett

unread,

Mar 26, 2004, 3:07:53 PM3/26/04

to

"Sam Gillett" <samgille...@diespammermsn.com> wrote ...

> Add to that, twice the storage space per disk of the 1581 and you have a
> winner! ;-)

Whoops! That sentence was worded badly... and easily misunderstood. That
should be:

Add to that, The CMD FD2000 has twice the storage capacity of the C=1581, and

you have a winner! ;-)
--
Best regards,

Sam Gillett

UFO's are real.
It's the Air Force that doesn't exist!

Alan Jones

unread,

Mar 26, 2004, 3:28:58 PM3/26/04

to

On 26 Mar 2004 06:11:58 -0800, jerry...@earthlink.net (Jerry Kurtz)
wrote:

>But I do have a question about JiffyDos... Why doesn't the 1571, 1581
>and Excelerator Plus drives have a switch to revert back to the
>original rom like the 1541 version?

The 1541 JiffyDos ROM has a switch? I don't think any of the drive
ROMS need a switch. I have JiffyDos on my C64 and 1581 drive, which
is a great combo. The switch is on the computer. In 128 mode with a
1571 drive or better you don't need JiffyDos as much, but it is nice
to have. I have a 128CDR and I get JD via a RamDrive. I still don't
have JD ROMS for any of my 1541 or 1571 drives.

J. Robertson

unread,

Mar 26, 2004, 4:08:02 PM3/26/04

to

On Fri, 26 Mar 2004 20:28:58 GMT, Alan Jones <ala...@nospam.mchsi.com>
wrote:

>The 1541 JiffyDos ROM has a switch?

Yep. However, as I don't have a 1571/1581 I didn't know that those
drives were switchless when it came to JiffyDos. I know why now from
reading this thread.

Jason

--
E-mail #1: jkr[at]westol.com
E-mail #2: jk...@juno.com
(Use E-mail #1 for a quicker response.)
Web site : http://www.westol.com/~jkr/
--

Joseph Fenn

unread,

Mar 26, 2004, 4:40:27 PM3/26/04

to

I have the jiffydos incorporated in my Ram/Link so its always available
hence I am always useing it for file copying, chooseing drives,
etc. Albeit the drives 3 out of 4 dont have the jiffy dos installed
in the drives themselves. No problem at all the very fact that just
having jiffydos in the ramlink offers no end of shortcuts with its
many features of dos commands, deleting files, renameingfiles,
viewing seq files, et al ad infinitum. Its just the best thing
that ever happened on the CBM stuff.
Joe (aka kilroy)

****************************************************
* Ham KH6JF AARS/MARS ABM6JF QCWA WW2 VET WD RADIO *
****************************************************

On Fri, 26 Mar 2004, Alan Jones wrote:

krs...@nospamnetscape.net

unread,

Mar 26, 2004, 4:49:00 PM3/26/04

to

Jheitmuller wrote:

Get a SuperCPU128, a RAMlink, and either an FD2000 or a hard drive. The
SCPU & RL both provide JiffyDOS for your 128 so you'll only need to add
drive ROMS, and the FD2000 already has JD built in.
-Ron

Matthew Montchalin

unread,

Mar 26, 2004, 9:02:13 PM3/26/04

to

If all he wants to do, is use Basic 7.0, and avoid reaching for
the stars, then JiffyDos does the job nicely enough.

But if he wants to spend all day long writing custom loaders, and doing
'weird' stuff to the serial port, then he is going to find himself
running into a brick wall's worth of incompatibility problems.

Bel...@uplink.net

unread,

Mar 26, 2004, 9:37:24 PM3/26/04

to

I have a 128DCR and RamDrive as well. Do I need to install the JiffyDos Rom
for the internal drive to get full advantage of it? I have it installed in
an external 1571 which works better than the internal drive. It seems like
the internal drive is running at the same speed it was before.

Belmar

Robert Bernardo

unread,

Mar 26, 2004, 11:27:42 PM3/26/04

to

> On Fri, 26 Mar 2004 20:28:58 GMT, Alan Joneswrote:

>
> >The 1541 JiffyDos ROM has a switch?

On Fri, 26 Mar 2004, J. Robertson wrote:

> Yep. However, as I don't have a 1571/1581 I didn't know that those
> drives were switchless when it came to JiffyDos. I know why now from
> reading this thread.

The JD drive chips have no switch. Only the JD chip that resides
in the computer has a switch.

If you do have a switch on your JD
drive chip, then it's a strange one,

Robert Bernardo

unread,

Mar 26, 2004, 11:33:03 PM3/26/04

to

On Fri, 26 Mar 2004, Sam Gillett wrote:

> Let's add a CMD FD-2000 3.5" drive to the list of drives.

Or add the CMD FD-4000 3.5" enhanced density drive. A tough beast
to find. :-)

> The nice thing
> about the FD2000 is this; you can still find _new_ blank disks that are
> compatible at most department, office supply, and computer stores.

Finding ED disks is difficult. However, there is a supplier in
Oregon.

> Add to that, twice the storage space per disk of the 1581 and you have a
> winner! ;-)

With an ED disk, you get four times the storage space of a 1581!

Truly,

Marc Walters

unread,

Mar 27, 2004, 6:05:28 AM3/27/04

to

"Robert Bernardo" <rber...@iglou.com> wrote in message

news:Pine.GSO.4.56.0403262323560.24409@shell1...

> > On Fri, 26 Mar 2004 20:28:58 GMT, Alan Joneswrote:
> >
> > >The 1541 JiffyDos ROM has a switch?

[snip]

> The JD drive chips have no switch. Only the JD chip that resides
> in the computer has a switch.
>
> If you do have a switch on your JD
> drive chip, then it's a strange one,

I have both CMD and MRE JiffyDOS ROMs for the 1541-II. The chips come with a
switch attached, and the instructions include a diagram and suggestions for
placement of the switch. Perhaps it's the old style 1541 JD ROM that does
not have a switch?

Marc Walters

RajW

unread,

Mar 27, 2004, 6:42:27 AM3/27/04

to

Marc,

On Sat, 27 Mar 2004 22:05:28 +1100, "Marc Walters"
<dd...@au.net.hunterlink> wrote:
>I have both CMD and MRE JiffyDOS ROMs for the 1541-II. The chips come with a
>switch attached, and the instructions include a diagram and suggestions for
>placement of the switch. Perhaps it's the old style 1541 JD ROM that does
>not have a switch?

All of the 1541 and 1541-II JiffyDOS chips have switches. I think the
previous poster was only referring to the 1571 and 1581 drives.

/*Raj*/

mau...@cmdrkey.com

unread,

Mar 27, 2004, 10:15:02 PM3/27/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> If all he wants to do, is use Basic 7.0, and avoid reaching for
> the stars, then JiffyDos does the job nicely enough.

> But if he wants to spend all day long writing custom loaders, and doing
> 'weird' stuff to the serial port, then he is going to find himself
> running into a brick wall's worth of incompatibility problems.

Not true. JiffyDOS doesn't get in the way of any custom serial
bus routine any more than the stock kernal would. Since a custom
serial routine doesn't even access any kernal serial routines, how
could JiffyDOS possibly pose any compatibility problems?

-Maurice

--
** Maurice Randall - Click Here Software Co.
** High-Performance for your Commodore
** email: mau...@cmdrkey.com, sup...@cmdrkey.com
** web: http://cmdrkey.com

mau...@cmdrkey.com

unread,

Mar 27, 2004, 10:18:00 PM3/27/04

to

Alan Jones <ala...@nospam.mchsi.com> wrote:
> The 1541 JiffyDos ROM has a switch? I don't think any of the drive
> ROMS need a switch. I have JiffyDos on my C64 and 1581 drive, which

unread,

Mar 27, 2004, 10:31:22 PM3/27/04

to

Alan Jones <ala...@nospam.mchsi.com> wrote:
> is a great combo. The switch is on the computer. In 128 mode with a
> 1571 drive or better you don't need JiffyDos as much, but it is nice
> to have. I have a 128CDR and I get JD via a RamDrive. I still don't
> have JD ROMS for any of my 1541 or 1571 drives.

Even in 128 mode, you will benefit from JiffyDOS in the 1571 and
1581. Without JiffyDOS, the 1571 and 1581 is still pretty fast
when reading files or loading files. But when saving or writing
files, they are still slow. JiffyDOS speeds up saving and any
other write operations, so there is a definite gain when using
JiffyDOS in these drives.

Matthew Montchalin

unread,

Mar 27, 2004, 11:50:16 PM3/27/04

to

mau...@cmdrkey.com wrote:
|Matthew Montchalin <mmon...@oregonvos.net> wrote:
|> If all he wants to do, is use Basic 7.0, and avoid reaching for
|> the stars, then JiffyDos does the job nicely enough.
|
|> But if he wants to spend all day long writing custom loaders, and doing
|> 'weird' stuff to the serial port, then he is going to find himself
|> running into a brick wall's worth of incompatibility problems.
|
|Not true. JiffyDOS doesn't get in the way of any custom serial
|bus routine any more than the stock kernal would.

Strange. I just have *never* had any luck with JiffyDOS.

|Since a custom serial routine doesn't even access any kernal serial
|routines, how could JiffyDOS possibly pose any compatibility problems?

For one thing, my own custom serial routines require the ROM's to be
completely banked out of the C-128. I simply haven't had any luck
with JiffyDOS, sorry. How often do you drive the C-128 cia chips
from a configuration realized with 7E stored into $ff00? And the
preconfiguration registers $ff01 to $ff03 similarly set up?

Rick Balkins

unread,

Mar 28, 2004, 1:09:02 AM3/28/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.04032...@lab.oregonvos.net...>

> Strange. I just have *never* had any luck with JiffyDOS.

Have you actually used JiffyDOS ?

Some of the early versions were more buggier. Anyway, even a change of a bit
can cause incompatibility of some sort to at least one or more programs.
Because some programs check the status of every dam* but and a change can
cause some problem. Some programs are just rotten this way but why worry.

I actually have used JiffyDOS and if I found a program that is incompatible
with JiffyDOS being on then I just turn off JiffyDOS and restart the
computer then I run the program and for the most part it will run especially
if I am using a 1541 (grey).

Matthew Montchalin

unread,

Mar 28, 2004, 3:20:54 AM3/28/04

to

Rick Balkins wrote:
|"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
|news:Pine.LNX.4.44.04032...@lab.oregonvos.net...>
|
|> Strange. I just have *never* had any luck with JiffyDOS.
|
|Have you actually used JiffyDOS ?

I've attempted to get it to work with software that I *do* use, why?

<snip>

|I actually have used JiffyDOS and if I found a program that is incompatible
|with JiffyDOS being on then I just turn off JiffyDOS and restart the
|computer then I run the program and for the most part it will run especially
|if I am using a 1541 (grey).

Which is why I said that I have no use for it. -Sure, it is probably
a great program to collect, but the best thing about is the ROM swap
switch. I don't understand why you are acting like this is some kind
of shock to you, but why don't YOU write some code some day, something
that expects 7E to be in $ff00 at all times? (True, even storing 3E in
$ff00 and refraining from allowing $00 in, causes it to crash also.) You
can't just store $00 in $ff00 without finding somewhere to replace the
first 16K of RAM, because if any of those bytes are tampered with, it
crashes my code. The bottom line being, sure, I might let JiffyDOS
play with memory, but stay out of the bottom 16K of RAM, don't interfere
with the Common RAM register, and stay away from $ff00-ff03. Am I asking
for too much?

Rick Balkins

unread,

Mar 28, 2004, 4:15:33 AM3/28/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040328...@lab.oregonvos.net...

> I've attempted to get it to work with software that I *do* use, why?
>
> <snip>
>

> Which is why I said that I have no use for it. -Sure, it is probably
> a great program to collect, but the best thing about is the ROM swap
> switch. I don't understand why you are acting like this is some kind
> of shock to you, but why don't YOU write some code some day, something
> that expects 7E to be in $ff00 at all times? (True, even storing 3E in
> $ff00 and refraining from allowing $00 in, causes it to crash also.) You
> can't just store $00 in $ff00 without finding somewhere to replace the
> first 16K of RAM, because if any of those bytes are tampered with, it
> crashes my code. The bottom line being, sure, I might let JiffyDOS
> play with memory, but stay out of the bottom 16K of RAM, don't interfere
> with the Common RAM register, and stay away from $ff00-ff03. Am I asking
> for too much?

Did you read the manual ? Did you know that JiffyDOS can be turned off.
Anyway, Maurice can give details but I remember some SYS code had to be
typed in and something of the sort which I believe turned on and off
JiffyDOS. Now, there is also a way to simply switched JiffyDOS offf. Now I
can say that you wrote your code in certain areas. JiffyDOS does have some
incompatibilities with some programs when active. I wrote an article on
JiffyDOS and wrote programs code that can detect JiffyDOS in BASIC and in ML
(I first did this with Lord Alberon) and I know of some other locations that
change. Awhile back I have done this. This after I got JiffyDOS for my C128
and did the checks in both C64 and C128 mode. Anyway, it is not something
special but certainly stuff of some credibility. This little JiffyDos
detection program/routine idea was Lord Alberon's idea and I assisted in the
C-128 as I was working with other projects at the time and gave him a hand
in that.

I want to make sure he is credited for his efforts.

Matthew Montchalin

unread,

Mar 28, 2004, 5:45:13 AM3/28/04

to

On Sun, 28 Mar 2004, Rick Balkins wrote:
|Did you know that JiffyDOS can be turned off.

If it is always turned off, why buy it?

unread,

Mar 28, 2004, 5:46:33 PM3/28/04

to

Do I ever turn JiffyDOS on?

mau...@cmdrkey.com

unread,

Mar 28, 2004, 10:10:09 PM3/28/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> Strange. I just have *never* had any luck with JiffyDOS.

> For one thing, my own custom serial routines require the ROM's to be
> completely banked out of the C-128. I simply haven't had any luck
> with JiffyDOS, sorry.

Matthew,

I've been trying to think of what might be giving you trouble
when you use JiffyDOS with your own custom serial routines. I've
thought of one thing, but you'll have to tell me if I'm on the
right track or not.

Let's say you first start out with the kernal banked in so that you
can use the kernal routines or even BASIC to get a file opened
for reading. Next, you read the first two bytes of the file to get
a load address. Now, you switch out the kernal and begin using your
own custom serial routines to read in all the data bytes from the
file and store them into memory.

With a stock kernal, this would work just fine as long as your
custom serial routines work OK with the stock serial routines
built into the disk drive. I assume they do.

But, if you are using a secondary address of 0 to open the file,
this would put the drive's DOS into "load" mode rather than just
plain old "read" mode. The drive will dedicate itself to getting
all the data from the file and feeding it to the computer until
either the end of file is reached, or the computer closes the
file prematurely.

With JiffyDOS, by reading the first two load address bytes, you've
triggered the drive into JiffyDOS load mode and the drive DOS will assume
it can use the JiffyDOS protocol during the entire data transfer.
But you used JiffyDOS to fetch the first two bytes and now you
want to use your own custom serial routines to fetch the remaining
data bytes. That won't work, because your serial routines don't
work with the JiffyDOS protocol.

Now, if you use a secondary address of 2-14, you will put the
drive into 'read' mode instead of 'load' mode. Your program
doesn't need load mode, read mode will do just fine. You read
the first two bytes using the kernal routines (JiffyDOS) and then
you switch the kernal out and finish reading the rest of the
data with your own custom serial routines.

Why would this work OK? Because the JiffyDOS protocol in 'read'
mode is negotiated during the start of every byte. When your
code switches to using your own custom serial routines, the
drive will notice this and will use the stock routines instead
of the JiffyDOS routines.

But in 'load' mode, the negotiations only occur during the
first two bytes. From there on, the JiffyDOS protocol remains
in effect.

So, if I'm right on my assumption on how your program works,
it's not really a fault of JiffyDOS, but rather the way in
which your program is handling the reading of the data. Use
a secondary address of 2-14 and you shouldn't have a problem.
Use a secondary address of 0, and your code might fail due to
the switching of transfer protocols.

Let me know if I guessed this one correctly.

mau...@cmdrkey.com

unread,

Mar 28, 2004, 10:44:01 PM3/28/04

to

Matthew,

I think I stated something a little incorrectly in my previous
post. I went and studied the JiffyDOS protocol a little after
leaving that message. The negotiation actually occurs during
the LISTEN/SECOND or TALK/TALKSA phases. Once that occurs, the
drive will stay in JiffyDOS mode if that's what was negotiated
during those phases.

So, if you read in a load address using the kernal, you would
have to send an UNTALK command. Then switch the kernal out,
and using your own custom routines, send a TALK and TALKSA
command sequence, and then read the remaining bytes.

Basically, you can't switch transfer protocols once the
negotations have completed.

If you're doing the entire opening and closing of the files
with your own custom serial routines, then ignore what I've
said in these two messages because none of it would apply and
I'll have to think of another reason for failure on your part.

But I will say one thing, JiffyDOS really does work for most
software. GEOS uses custom serial routines and JiffyDOS doesn't
need to be switched off. I'd like to know what it is that you
are doing that gives you so much trouble.

Matthew Montchalin

unread,

Mar 28, 2004, 10:56:23 PM3/28/04

to

mau...@cmdrkey.com wrote:
|I've been trying to think of what might be giving you trouble
|when you use JiffyDOS with your own custom serial routines. I've
|thought of one thing, but you'll have to tell me if I'm on the
|right track or not.
|
|Let's say you first start out with the kernal banked in so that you
|can use the kernal routines or even BASIC to get a file opened
|for reading.

Not a good idea, as zero page is not organized like it is for the
C-128. In order to open a file, you have to use my own TALK/LISTEN
routines - see the vector table at $2008 to locate them, they are
not in ROM. Furthermore, you should not count on any addresses in zero
page to act like the addresses that are used on the C-128. Addresses
like $90 and $ba are not used in the same way as the C-128 uses them.
There is a completely DIFFERENT zero page down there. And in order to
scan the keyboard, the "keyboard zero page" has to be flipped into
context 60 times a second, unless file transfers are actually active.
(This is one of the reasons I can get away with doing all kinds of
different things by holding the CTRL and ESC and CMDR keys down
*simultaneously* (in addition to separately, that is a different
kind of keyboard scan) while scanning the keyboard.)

Oh, and I forgot to mention, the Z80 startup code under ROM, should
not be modified - I don't use it, but I do adjust it - just in case
the Z80 accidentally comes alive, like Frankenstein's monster arising
after dark.

|Next, you read the first two bytes of the file to get a load address.

It simply doesn't get that far.

Just off the top of my head, when you do the following,

.enter_here lda #$00 sta status ; this is like poking $90 with 0

.entry_point1 lda devnum jsr listen
bit $90 bmi .error_found
lda #$ff jsr second
bit $90 bmi .error_found

ldx #length_of_name-1
.loop1 lda name,x jsr ciout dex .loop1 bpl .loop1

jsr unlisten ; device is now open and the red light is on
bit $90 bmi .error_found

.entry_point2 lda devnum jsr talk bit status bmi .error_found
lda #$6f jsr tksa bit status bmi .error_found

at which point you can start doing your calls to the ACPTR routine
(check out the vector table at $2008 to find out where the ACPTR
routine is)...

Anyway, it always seems to jam up at the start of the initialization
routine. And since my software was written before JiffyDOS was written,
it would take me a lot of work to second guess where JiffyDOS needs to
have something in one place, or done in some sequence, whereas I have
been doing my own thing my way, long before that.

Please don't think I am putting you down, your program is probably
a fine thing for BASIC 7.0 programmers, or programmers that actually
use the Commodore Kernal, and don't bypass anything, or "roll their
own."

mau...@cmdrkey.com

unread,

Mar 28, 2004, 11:30:30 PM3/28/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> Please don't think I am putting you down, your program is probably
> a fine thing for BASIC 7.0 programmers, or programmers that actually
> use the Commodore Kernal, and don't bypass anything, or "roll their
> own."

I don't think that at all. I'm just curious as to why JiffyDOS doesn't
work for you. Is the program in question "MAS-128" by any chance?

-Maurice

Matthew Montchalin

unread,

Mar 28, 2004, 11:43:45 PM3/28/04

to

On Mon, 29 Mar 2004 mau...@cmdrkey.com wrote:
|> Please don't think I am putting you down, your program is probably
|> a fine thing for BASIC 7.0 programmers, or programmers that actually
|> use the Commodore Kernal, and don't bypass anything, or "roll their
|> own."
|
|I don't think that at all. I'm just curious as to why JiffyDOS doesn't
|work for you. Is the program in question "MAS-128" by any chance?

And all of those exec files that you can invoke by entering the command

@exec "filename,u,r"

What good is an operating system if you can't import files and execute
them under the specific conditions of your own prefered environment?

Jim Brain

unread,

Mar 29, 2004, 1:27:16 AM3/29/04

to

The way I see it, it isn't any good.... For you....

But, I think you need to qualify your opinion as such. As an ML
programmer, I have used JDOS since the laste 80's and I have rolled my
own IO routines at times. JDOS was switched in. Heck, I even wrote a
system that used the 1541 drive CPU as a multitasking coprocessor. JDOS
didn't mind at all...

IN fact, if you bank out KERNAL, U: your own routine in the 1541 and
bypass it's KERNAL, I can't think of a reason why JDOS would ever get in
the way.

Jim

Matthew Montchalin

unread,

Mar 29, 2004, 1:39:49 AM3/29/04

to

Jim Brain wrote:
|As an ML programmer, I have used JDOS since the laste 80's and I have
|rolled my own IO routines at times. JDOS was switched in. Heck, I
|even wrote a system that used the 1541 drive CPU as a multitasking
|coprocessor. JDOS didn't mind at all...
|
|IN fact, if you bank out KERNAL, U: your own routine in the 1541 and
|bypass it's KERNAL, I can't think of a reason why JDOS would ever get
|in the way.

Fine, think whatever you want.

Are you still stuck on your tokenizing problem?

Rick Balkins

unread,

Mar 29, 2004, 3:38:24 AM3/29/04

to

<mau...@cmdrkey.com> wrote in message
news:lsM9c.18016$t16.9...@newssvr28.news.prodigy.com...

> Matthew,
>
> I've been trying to think of what might be giving you trouble
> when you use JiffyDOS with your own custom serial routines. I've
> thought of one thing, but you'll have to tell me if I'm on the
> right track or not.
>

<<< snip >>>

Maurice, I believe there is a QUICK fix to the issue.

One, he needs to detect if JiffyDOS is active. You can go about this based
on what is right before your face.

We remember in BASIC that the computer starts up with a specific text.
JiffyDOS happens to provide a different set of text up on the top of the
screen when the C64 turns on. By locating the "J" will take care of the
issue. There are other areas that one can choose to look at as well.

Now that you have the principle idea in detecting JiffyDOS, little PEEK job
will do or ( LDA,LDX or LDY will do that just fine in ML).
Now that is figured out. Matthew, following ?

Once you know that JiffyDOS is active, you now can go with the basic process
of disabling JiffyDOS through software (SYS command or JSR to the location
that you would send an SYS command to disable JiffyDOS or whatever it is to
disable JiffyDOS in software. Now that being done, should then allow for him
to execute his program. By first detecting if JiffyDOS is active and then
disable it then proceed. Got the idea, Matthew ???? Maurice, can you clarify
which memory location it is to disable JiffyDOS. I believe it was an SYS
command or something. There is a way to do it in software, I believe.

Rick Balkins

unread,

Mar 29, 2004, 3:57:32 AM3/29/04

to

"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote in
message news:106fo47...@corp.supernews.com...

>
> Maurice, I believe there is a QUICK fix to the issue.

<<< snip >>>

> Once you know that JiffyDOS is active, you now can go with the basic
process
> of disabling JiffyDOS through software (SYS command or JSR to the location
> that you would send an SYS command to disable JiffyDOS or whatever it is
to
> disable JiffyDOS in software. Now that being done, should then allow for
him
> to execute his program. By first detecting if JiffyDOS is active and then
> disable it then proceed. Got the idea, Matthew ???? Maurice, can you
clarify
> which memory location it is to disable JiffyDOS. I believe it was an SYS
> command or something. There is a way to do it in software, I believe.

Well, correction - the SYS code is to enable it but there is a command to
disable JiffyDOS. Matthew, follow this command:

@Q

(THEN physically flip the switch from JiffyDOS enable to disabled).

This should take care of the issue. NOW, you can patch this through BASIC as
well and this BASIC program would be a "loader" for your program. Now, there
is another method, I believe. Maurice, you can clarify any details. I
apologize but I have looked at the manual in about 4-5 years and had not had
to use the command for any reason.

Here is the example from the JiffyDOS manual section available at the
8BitDesigns HowTOs section.

Switching JiffyDOS on or off:

Commonly, JiffyDOS will be enabled or disabled with the toggle switch while
the computer is switched off. When you turn the computer on, (depending on
the mode selected by the switch) you will see either the standard Commodore
startup screen, or the JiffyDOS startup screen.
Likewise, some drives also utilize a similar toggle switch to enable or
disable their JiffyDOS ROM routines. Again, common practice is to set the
switches in the desired position before turning the computer on or off.

1541 drives (and drives compatible with the 1541) typically require a toggle
switch to be installed to enable you to switch JiffyDOS on or off.
1571 and 1581 drives, automatically detect whether JiffyDOS is enabled or
disabled on the computer. If the drive detects that JiffyDOS is enabled,
then the drive's JiffyDOS routines will be enabled. If the drive detects
that JiffyDOS is disabled on the computer, then the drive's JiffyDOS
routines will also be disabled.

FD-2000, FD-4000, and CMD Hard Drives will behave similarly to the 1571 and
1581 drives in respect to determining the appropriate mode of operation.

JiffyDOS can be enabled or disabled while the computer is on. You should be
certain that there is not anything being read or written from the drives
when you switch the ROM's on or off. If you do flip the switch while a disk
drive is being accessed, your computer will most likely lockup).
You might find the need to disable JiffyDOS to load certain programs with
custom disk routines (or copy-protection). Sometimes you can re-enable
JiffyDOS once the program has been loaded. This might enable you to take
advantage of the improved performance of JiffyDOS even when the program will
not load with JiffyDOS enabled.

Some programs may crash if you switch from the Commodore kernal to JiffyDOS
while the program is running. This may or may not happen with any of the
programs that you have. Occasionally the program may wait to lockup until
the next disk access.
If you would like to disable JiffyDOS from BASIC, you can type @Q and then
flip kernal mode switch to the JiffyDOS disable position. You can re-enable
JiffyDOS by switching the switch back to the JiffyDOS enabled position, and
then type in one of the following commands:

SYS 58551 (C-64 or 128 in 64 mode)
SYS 65137 (Commodore 128)
and then press the "Return" key.
----------------------------------------------------------------------------
-----------------------------------------------

Matthew, the MOST important thing that you NEED to understand is that YOU do
NOT need to do ANYTHING except turn JiffyDOS off before you turn the
computer on when you use the program(s) that is/are having trouble executing
properly when JiffyDOS is enabled.

You can enable JiffyDOS when you use other programs that do not have
problems with JiffyDOS.

Matthew Montchalin

unread,

Mar 29, 2004, 4:12:01 AM3/29/04

to

On Mon, 29 Mar 2004, Rick Balkins wrote:
|Maurice, I believe there is a QUICK fix to the issue.

hoooooooo boy

|One, he needs to detect if JiffyDOS is active. You can go about this based
|on what is right before your face.

There are TWO kinds of activity, Rick. One of them is on the C-128 side
of reality, and the other one is on the 1541's side or reality. In order
for him to fix the JiffyDOS in the 1541, he should have it display the
1541's copyright message. -I look for this kind of a message at powerup,
and if it's not there, I assume the machine is a generic 'slow' device,
no fast I/O, nothing special, not even a dual disk drive like the MSD-2.
(Which makes me wonder how well JiffyDOS works with the MSD-2 dual disk
drive.)

So, first off, he can fix his *own* JiffyDOS rom, and that will take care
of that. If he happens to have JiffyDOS installed in the 1581, there
should be some way of having the JiffyDOS come up with the standard
1581 Commodore copyright message, so I know what I am dealing with.
Then, bingo, fast '1581' style I/O will be supported. But I cannot be
expected to know about strange, secret copyright messages that didn't
even EXIST when my software was written - in 1985. At the time, it
should have been enough to have ALL unknown disk drives be presumed to
be slow devices. (That means that it is supposed to flunk a fast
handshake, which is usually sent out as a test, right after the first JSR
LISTEN passes through.)

But as for the C-128 side of reality, you should dwell on this little
tidbit, Rick: MAS-128 makes absolutely NO rom calls. Ever. Think
about it.

Matthew Montchalin

unread,

Mar 29, 2004, 4:46:56 AM3/29/04

to

Rick Balkins wrote:
|Well, correction - the SYS code is to enable it but there is a command to
|disable JiffyDOS. Matthew, follow this command:
|
|@Q

Rick, I want you to spend the next 24 hours memorizing the IO_Init and
RAM_TAS routines in Kernal ROM, and then - as soon as you understand
them - resume our conversation. Something similar to that, happens
when MAS-128 takes over, eradicating all vestiges of flags in the
first 7 pages of memory. The VIC-II is directed to obtain screen
information from Bank 1 (which is cleared so that a message is
displayed, SORRY - 80 COLUMN RGBI ONLY), and my own equivalents of
IND_FETCH and IND_STORE and LOCATE_SYM and LINE_PARSE are deposited
in the first 7 pages of RAM in Bank 0. The Common RAM register is
adjusted so the only thing that can see Bank 1 is the VIC-II chip,
the rest of the code above Common RAM is actually in Bank 1. If you
want to follow the Interrupts, take a look at $FFFA and $FFFE when you
store #$7f into $ff00, it does not look the same as when you store #$3f
into it, let alone #$00 in it. Trust me, there is nothing left for
JiffyDOS to look at, even if it were allowed to.

It is possible, however, some of the jamming up occurs because of
the SuperCPU that the JiffyDOS came with. It is best to turn them
*both* off.

mau...@cmdrkey.com

unread,

Mar 29, 2004, 8:17:22 AM3/29/04

to

Rick Balkins <rickbalki...@nospam.wavestarinteractive.com> wrote:
> One, he needs to detect if JiffyDOS is active. You can go about this based
> on what is right before your face.

No, he doesn't need to do that. Matthew's solution is to disable
JiffyDOS with the hardware switch.

Matthew wrote this particular software in the 80's a couple of
years or so before JiffyDOS was introduced. So, it really makes
no difference if it works with JiffyDOS or not, especially since
the software might not be in widespread use. He hasn't stated
if many other people also use the program (or I haven't read his
latest message yet). If the software had seen widespread use during
the last 15 years, I'm sure Matthew would have figured out why it
doesn't work with JiffyDOS by now because that would be a serious
issue with other users of his software. He would have contacted
CMD a long time ago seeking help in solving the problem. Apparently
it wasn't a big issue as he's already stated.

I'm not concerned about the JiffyDOS compatibility issue with Matthew's
software, I'm only curious, nothing more.

mau...@cmdrkey.com

unread,

Mar 29, 2004, 8:33:01 AM3/29/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> of reality, and the other one is on the 1541's side or reality. In order
> for him to fix the JiffyDOS in the 1541, he should have it display the
> 1541's copyright message. -I look for this kind of a message at powerup,
> and if it's not there, I assume the machine is a generic 'slow' device,
> no fast I/O, nothing special, not even a dual disk drive like the MSD-2.
> (Which makes me wonder how well JiffyDOS works with the MSD-2 dual disk
> drive.)

Now I'm beginning to see where the problem lies with MAS-128. It's
in your drive detection code. You should not rely on the drive's
startup message for detecting the drive type. It sounds like your
software sees the JiffyDOS equipped 1541 as a drive that is capable
of fast I/O using the serial bus burst routines like the 1571 and
1581 can use.

It would have been better if your software defaulted to slow serial
for drives it didn't recognize, rather than assuming if it doesn't
look like a 1541, then it must support fast serial.

> So, first off, he can fix his *own* JiffyDOS rom, and that will take care
> of that.

It's already fixed. The 1541 comes with a switch.

My guess is your custom serial routines will work as long as the
switch on the 1541 is turned off, but the switch on the computer
makes absolutely no difference.

So, the problem is not with JiffyDOS in the computer itself, but
in the way you detect the drive. So, I'm not concerned about this
problem at all.

The solution is simple for all existing MAS-128 users, just disable
the JiffyDOS in the 1541 or stick to using fast serial drives like
the 1571 or 1581. If there were thousands of MAS-128 users out
there, I'd consider offering a special JiffyDOS 1541 rom for them,
but there's no point in it, obviously.

Rick Balkins

unread,

Mar 29, 2004, 11:06:58 AM3/29/04

to

<mau...@cmdrkey.com> wrote in message
news:ClV9c.18142$t16.9...@newssvr28.news.prodigy.com...

> No, he doesn't need to do that. Matthew's solution is to disable
> JiffyDOS with the hardware switch.

It even sounds like Matthew. Such a simple thing. By issuing @Q in a
subroutine would set the computer to disable JiffyDOS from my understanding
and to make sure the switch is off and would take care of the issue. I
believe @Q disables it in the drive level but this little adjustment in his
software would do it. The detection of JiffyDOS being active in the computer
would solve the issue. If JiffyDOS is disabled at the computer, then the
drives will not be operating in JiffyDOS mode.

He has several fairly simple options that he can choose.

> Matthew wrote this particular software in the 80's a couple of
> years or so before JiffyDOS was introduced. So, it really makes
> no difference if it works with JiffyDOS or not, especially since
> the software might not be in widespread use. He hasn't stated
> if many other people also use the program (or I haven't read his
> latest message yet). If the software had seen widespread use during
> the last 15 years, I'm sure Matthew would have figured out why it
> doesn't work with JiffyDOS by now because that would be a serious
> issue with other users of his software. He would have contacted
> CMD a long time ago seeking help in solving the problem. Apparently
> it wasn't a big issue as he's already stated.

I agree with you there. If Matthew wants to make it run with JiffyDOS then
he can fix the problem himself.
Anyone that can write an assembler has the skills to do the job, Matthew
listening ????

Matthew Montchalin

unread,

Mar 29, 2004, 1:57:29 PM3/29/04

to

On Mon, 29 Mar 2004 mau...@cmdrkey.com wrote:

|I'm not concerned about the JiffyDOS compatibility issue with Matthew's
|software, I'm only curious, nothing more.

Nor am I particularly concerned with JiffyDOS's compatibility issue,
either. It is a passing curiosity, and nothing more. There really
is very little reason for me to ever turn on JiffyDOS.

Jim Brain

unread,

Mar 30, 2004, 12:51:02 AM3/30/04

to

I and many others will.

>
> Are you still stuck on your tokenizing problem?
>
>

unread,

Mar 30, 2004, 8:15:50 PM3/30/04

to

Matthew Montchalin wrote:

Only when the code detects you telnetting to it. One annoyance deserves
another.

I'm not biting. Troll somewhere else.

Jim

Matthew Montchalin

unread,

Mar 30, 2004, 8:34:16 PM3/30/04

to

Rick Balkins wrote:
|"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
|news:Pine.LNX.4.44.040329...@lab.oregonvos.net...
|
|> Is it going to be as slow as all the other ones are that use JiffyDOS?
|
|JiffyDOS isn't slow dude.

If you aren't bright enough to bypass a directory search, it's going
to be *painfully* slow. But once you know where your most regularly
accessed files are going to be, you are going to be able to beat JiffyDOS
every time, by doing nothing more than plugging the tracks and sectors
into the job queue, and take the file in, that way.

|JiffyDOS does speed up load time upto 15 times faster then stock systems
|do.

Which reminds me, most people don't have the slightest idea of how they
arrived at their numbers, they just repeat what other people tell them.

Matthew Montchalin

unread,

Mar 30, 2004, 8:44:49 PM3/30/04

to

Haven't you EVER bypassed a directory search?

sheeeeesh

mau...@cmdrkey.com

unread,

Mar 30, 2004, 8:42:35 PM3/30/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> If you aren't bright enough to bypass a directory search, it's going
> to be *painfully* slow. But once you know where your most regularly
> accessed files are going to be, you are going to be able to beat JiffyDOS
> every time, by doing nothing more than plugging the tracks and sectors
> into the job queue, and take the file in, that way.

Dedicated commercial software can work that way, but it has to
be specific for the disk drive, such as the 1541.

You must remember, Matthew, that JiffyDOS is much more than just
a speedup in disk access. It provides the user with a built-in
DOS wedge, a built-in filecopier, and works with more commercial
software than any other speed enhancer software. It also works
with the CIOUT and ACPTR kernal routines, whereas many other
enhancements do not. Others have to use CHROUT and CHRIN.
JiffyDOS also provides programmable function keys for the 64
and changes the default settings on the 128. Just press F1 to
get a directory. It also includes a built-in PETASCII text file
reader, and a built-in BASIC program lister without having to
load the program into memory.

Matthew Montchalin

unread,

Mar 30, 2004, 9:18:53 PM3/30/04

to

mau...@cmdrkey.com wrote:
|Matthew Montchalin <mmon...@oregonvos.net> wrote:
|> If you aren't bright enough to bypass a directory search, it's going
|> to be *painfully* slow. But once you know where your most regularly
|> accessed files are going to be, you are going to be able to beat JiffyDOS
|> every time, by doing nothing more than plugging the tracks and sectors
|> into the job queue, and take the file in, that way.
|
|Dedicated commercial software can work that way, but it has to
|be specific for the disk drive, such as the 1541.

Does JiffyDOS work with the MSD-2?

|You must remember, Matthew, that JiffyDOS is much more than just
|a speedup in disk access.

Although that does seem to be its best selling point.

|It provides the user with a built-in DOS wedge, a built-in filecopier,
|and works with more commercial software than any other speed enhancer
|software. It also works with the CIOUT and ACPTR kernal routines,
|whereas many other enhancements do not. Others have to use CHROUT and
|CHRIN. JiffyDOS also provides programmable function keys for the 64
|and changes the default settings on the 128. Just press F1 to
|get a directory. It also includes a built-in PETASCII text file
|reader, and a built-in BASIC program lister without having to
|load the program into memory.

Ah, so it seems to duplicate most of MAS-128's features?

DOS wedge, built-in RAMDOS with commands for transferring entire batches
of files into and out of the REU, has its own ACPTR and CIOUT vectors in
the vector table at $2020, has a 1581 backup (not built in, you have to
type @exec "1581 backup" to get it started, but at least it has switches
for skipping empty tracks, or tracks with read errors), direct track and
sector access, both manually and automatically, redefinable function
keys, and you get to type either DIR for a formatted directory display,
or @read "$0" to read a directory that has PETASCII control codes
sprinkled in it throughout, not to mention finding out where the DEL
files are hiding.

But your strongest selling point for JiffyDOS, *does* seem to be its
compatibility with BASIC 7.0.

Sam Gillett

unread,

Mar 30, 2004, 11:31:40 PM3/30/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote ...

> Ah, so it seems to duplicate most of MAS-128's features?

Back in "the day" quite a few Commodore users told me that the greatest thing
to ever "happen" to CBM machines was JiffyDOS.

Strangely enough, only one person has _ever_ told me that MAS-128 was the
greatest thing ever to happen to the Commodore. That one person is you
Matthew.

Rod Gasson

unread,

Mar 30, 2004, 11:03:38 PM3/30/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040330...@lab.oregonvos.net...

> Rick Balkins wrote:
> |"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
> |news:Pine.LNX.4.44.040329...@lab.oregonvos.net...
> |
> |> Is it going to be as slow as all the other ones are that use JiffyDOS?
> |
> |JiffyDOS isn't slow dude.
>
> If you aren't bright enough to bypass a directory search, it's going
> to be *painfully* slow. But once you know where your most regularly
> accessed files are going to be, you are going to be able to beat JiffyDOS
> every time, by doing nothing more than plugging the tracks and sectors
> into the job queue, and take the file in, that way.

Matthew, for many years now I've kept out of discussing the technicalities
as to why your software doesn't play nicely with JiffyDos, mainly because it
has been many years since I've done any C= programming and have literally
forgotten most of the details, routines, etc.
:-(

However, what I can remember is that with both QWKRR and Browser, I had to
make *extensive* use of "plugging tracks and sectors into the job queue" in
order to get them to do what I needed them to do, namely, the ability to
quickly go to any portion (forward or backward) of any size file, with
minimal delay, and although I really can't remember the detail of exactly
HOW I did it, but I do know that making it work with JiffyDos enabled
machines really wasn't all that difficult - In fact I seem to recall that I
had a harder time getting it to work a certain non-jiffydosed drive (either
the 1541mkII, or the 1571, I think) than I did with JiffYDos enabled (IOW,
JiffyDos actually fixed a bug that one of these drives had).

The thing I'm coming to here though is that I wrote this code a VERY long
time ago, and it was in fact written while I was first starting to learn
assembler (earlier versions of QWKRR were written in BASIC, but I digress) -
The point being, is that if a raw novice such as myself was able to perform
job queue manipulation while being both jiffyDos and non jiffydos compatible
then any problems I encountered couldn't have been TOO difficult to figure
out and overcome.

Perhaps (if you are interested) if may want to take a look at the QWKRR
source code to see what I did, or how I did it (Assuming you are able to
'read' my code <g>), because the solution to whatever incompatibilty you
have may simply be a matter of using a couple of different pointer locations
than what you are currently using - or perhaps just a different way of
detecting the type of drive being accessed.

If it IS an easy fix/change for you to make, then maybe you'll come to love
JD as much as the rest of us do :-)

Cheers
Rod

Matthew Montchalin

unread,

Mar 30, 2004, 11:50:23 PM3/30/04

to

On Wed, 31 Mar 2004, Sam Gillett wrote:
|> Ah, so it seems to duplicate most of MAS-128's features?
|
|Back in "the day" quite a few Commodore users told me that the greatest
|thing to ever "happen" to CBM machines was JiffyDOS.

I had no use for it.

|Strangely enough, only one person has _ever_ told me that MAS-128 was the
|greatest thing ever to happen to the Commodore. That one person is you
|Matthew.

Yeah, and you think your BBS is fast, too.

Rick Balkins

unread,

Mar 31, 2004, 12:05:37 AM3/31/04

to

That's called direct disk access and is certainly a violation of CBM DOS.
Sure you can but what is your point. You really wouldn't even have a
filesystem.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040330...@lab.oregonvos.net...

> If you aren't bright enough to bypass a directory search, it's going
> to be *painfully* slow. But once you know where your most regularly
> accessed files are going to be, you are going to be able to beat JiffyDOS
> every time, by doing nothing more than plugging the tracks and sectors
> into the job queue, and take the file in, that way.
>

Rick Balkins

unread,

Mar 31, 2004, 12:09:09 AM3/31/04

to

First off, you suggested a method that would not even have a true
filesystem. If I wanted to play that game, I would but we are talking about
a filesystem and you are comparing a nut to an banana.

You violate every concept of standards and Maurice is right and you missed
everyone's point here and you go off into some irrelevent issue.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040330...@lab.oregonvos.net...

> Does JiffyDOS work with the MSD-2?
>

> Although that does seem to be its best selling point.
>

Rick Balkins

unread,

Mar 31, 2004, 12:10:21 AM3/31/04

to

DIRECT DISK ACCESS, what's your POINT ???? Why even have a file system / DOS
with that.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
news:Pine.LNX.4.44.040330...@lab.oregonvos.net...

unread,

Mar 31, 2004, 1:57:16 AM3/31/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.04033...@lab.oregonvos.net...

> The filesystem exists, for if it didn't, the M-R and M-W commands,
> as applied to the job queue, wouldn't even work.

Well to an exten you need a format but that is not necassarily a full file
system as you miss something called "filenames" and therefore there really
is no functional file structure. What I see here is that you simply call for
Direct Disk Access.

> That's a bunch of hooey. You are just upset because I don't want
> to open up my machine to put a ROM in that I am never going to use.

No, I am not upset and I never said that you had to install JiffyDOS. I am
correcting the mistakes and bullsh*t that you are saying because they are
false. You said incorrect things because you know nothing about it. You made
sweeping assumptions based on some things.

Rick Balkins

unread,

Mar 31, 2004, 2:06:36 AM3/31/04

to

It hardly implies the need for a filename. Now, of course you may need one
file to kickstart everything though.
Yet, I see a fundamental flaw, how DO you know where the file would be saved
after you remove a file.

Avoiding directory means avoiding have filenames and simply assumes that the
data will be in the same spot all the time.
In a real world situation where you would be loading, saving, scratching
files (deleting files) and so forth - you can't be certain.

Even though CBM DOS is fairly stable in this respect.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.04033...@lab.oregonvos.net...

> The M-R and M-W commands exist for a reason, and using them is to be
> encouraged.
>

Rick Balkins

unread,

Mar 31, 2004, 2:14:31 AM3/31/04

to

I didn't say it isn't good but it has some practical uses and areas where it
is not so practical and BTW: You can do direct access without jeopardizing
functionality under JiffyDOS. By writing directly to disk will not cause
problems with JiffyDOS its other stuff but you would need to have an initial
file that begins things and JiffyDOS certainly helps to make that FASTER.

First off, when you type load"*",8,1:[Shift+Run/Stop key combo] the initial
file will load significantly faster with JiffyDOS but what is the big deal.
You don't want to put a ROM chip in, OK. Your choice. Yet, you make false
statements and make something out as hard when it isn't. You say flipping a
switch is hard - do you complain about flipping a switch to turn your
computer on ????

Get real.

PS: I never said that you have to buy JiffyDOS - I simply said that you made
false statements about JiffyDOS.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.04033...@lab.oregonvos.net...

Matthew Montchalin

unread,

Mar 31, 2004, 3:40:47 AM3/31/04

to

Rick Balkins wrote:
|> The filesystem exists, for if it didn't, the M-R and M-W commands,
|> as applied to the job queue, wouldn't even work.
|
|Well to an exten you need a format but that is not necassarily a full file
|system as you miss something called "filenames" and therefore there really
|is no functional file structure. What I see here is that you simply call for
|Direct Disk Access.

That's not true. The M-R and M-W commands allow you to make the file
names much more complex than they were to start with. You apparently
never looked at how many bytes are actually available, and how many
are actually used by the 1541 ROM. There are more bytes there that
you can put to good use, and which the 1541 ROM doesn't mind if you
do, that is the whole point of learning how to program, and push the
envelope.

Just because you don't feel like using the M-R and M-W commands,
combined with U1 and U2, doesn't mean that you can't flesh out a
really rich, deep, and complex system.

Matthew Montchalin

unread,

Mar 31, 2004, 3:45:43 AM3/31/04

to

On Tue, 30 Mar 2004, Rick Balkins wrote:

|It hardly implies the need for a filename. Now, of course you may need one
|file to kickstart everything though.
|Yet, I see a fundamental flaw, how DO you know where the file would be saved
|after you remove a file.

You look at the BAM, of course. And that is not the same thing as the
FAT. The FAT needs to be examined regardless of when you read and write,
no wonder PC harddrives fall apart so quickly. The BAM on the other hand
needs to be examined only half as often, if that. When you write, never
when you read.

|Avoiding directory means avoiding have filenames and simply assumes
|that the data will be in the same spot all the time.

No, if you launch a utility that performs a "once-through" then you
no longer have to go through multiple directory searches just to spool
a file to somebody who has just dialed up your BBS, you just launch
the thing, ready to go, by plugging the tracks and sectors into the
job queue.

|In a real world situation where you would be loading, saving,
|scratching files (deleting files) and so forth - you can't be certain.

You launch your utility to perform a straight-through, with no
recursions permitted. That is the beauty of it.

|Even though CBM DOS is fairly stable in this respect.

The number of defects that do exist, can be compensated for by direct
access programming.

Matthew Montchalin

unread,

Mar 31, 2004, 3:49:48 AM3/31/04

to

Rick Balkins wrote:
|I didn't say it isn't good but it has some practical uses and areas
|where it is not so practical and BTW: You can do direct access without
|jeopardizing functionality under JiffyDOS. By writing directly to disk
|will not cause problems with JiffyDOS its other stuff but you would need
|to have an initial file that begins things and JiffyDOS certainly helps
|to make that FASTER.

How well does it work with the MSD-2? You haven't seemed to address that
one.

|First off, when you type load"*",8,1:[Shift+Run/Stop key combo] the
|initial file will load significantly faster with JiffyDOS but what is
|the big deal.

It's no big deal, you are making a mountain out of a molehill.

|You don't want to put a ROM chip in, OK. Your choice. Yet, you make
|false statements and make something out as hard when it isn't.

Oh, like half of the stuff you say is gospel truth when it is clear
you haven't done any real "systems level" programming on a Commodore.

mau...@cmdrkey.com

unread,

Mar 31, 2004, 8:22:08 AM3/31/04

to

Matthew Montchalin <mmon...@oregonvos.net> wrote:
> Does JiffyDOS work with the MSD-2?

Yes, JiffyDOS is available for the MSD-2. It's $24 plus shipping.

> Ah, so it seems to duplicate most of MAS-128's features?

But there's a difference. MAS-128 and JiffyDOS are not
competitors. They are two different things. MAS-128 is an
application that runs on the 128 and gives you a programming
environment. JiffyDOS becomes part of the kernal and is always
there with every application.

unread,

Mar 31, 2004, 10:43:19 AM3/31/04

to

Dude, you don't even need much for a file as you can treat the directory as
data, hmmm.... Anyway - direct disk access means that you are writing to
track & sector. It is kind of funny but there really isn't a whole lot for a
reason for a filesystem by doing this. Didn't you know that was part of the
copyprotection system used by many software makers. There is only one
working file in the directory and that's about it.

Sure anyone can do anything and that's fine. Yet, what is the exact benefits
???? In an OS environment ???? How would an OS know where data files are
stored. You would need a database for this.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040331...@lab.oregonvos.net...

Rick Balkins

unread,

Mar 31, 2004, 10:53:46 AM3/31/04

to

Maurice answered you and I am not the one to answer that. I don't have an
MSD-2 drive and from my understanding of what Maurice said, it WORKS !!!!

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040331...@lab.oregonvos.net...

> How well does it work with the MSD-2? You haven't seemed to address that
> one.
>

> It's no big deal, you are making a mountain out of a molehill.

You certainly made mountain range out of a molehill by simply complaining
about flipping a switch.

> Oh, like half of the stuff you say is gospel truth when it is clear
> you haven't done any real "systems level" programming on a Commodore.

Done it but is there a need. I actually know something about JiffyDOS and
you don't really. When you state absolute false statements and keep claiming
them to be correct. I stated logical philosophy of the concepts you
mentioned. You failed to catch a point that I was pointing at. There is no
real need to have a filename and all (except for asthetics) if you simply
wrote content to a disk. BTW: BAM alone doesn't make a file system. It's the
having "filenames" as well. The BAM is just a table to assist the drive to
organize data but it would be just a disk data manager.

Rick Balkins

unread,

Mar 31, 2004, 11:00:15 AM3/31/04

to

Typically, the "boot file" would be stored the normal way. I seen stuff like
this and he would store all the main stuff to get things loading by starting
off with a traditional file that would do the following disk access. That
initial boot file would load 5-15 times faster with JiffyDOS. (Depending on
disk warm up time.

You made a point Maurice. In an OS environment, I would need to store this
into a database for the file start track&sector and length.(or ending track
& sector).

Yet, isn't that what the directory system does ???? (basically)

<mau...@cmdrkey.com> wrote in message
news:tWzac.19090$t16.10...@newssvr28.news.prodigy.com...

Quantum Leaper

unread,

Mar 31, 2004, 4:26:18 PM3/31/04

to

Jay wrote:
> Impossible Mission (and one other non-Epyx title using the same
> protection -- can't remember the name) needs JiffyDOS turned off at
> the 1541 (not the C64) to load.
>
> It utilizes duplicate sectors on the same track the are read and
> XORd. JiffyDOS throws off the interleave on sector reads so that the
> duplicated sector is always missed and the protection fails. The
> timing is such that a couple consecutive reads hits the other sector.
>
> And Bob's your Uncle.
>
I have about 4 or 5 games that require JD to be turned of in 1541 for them
to work. Whats interesting is a couple of the games didn't seem to have
any type of fast loading, the games loaded slow. I just wish I could
remember the games...

Matthew Montchalin

unread,

Mar 31, 2004, 4:49:17 PM3/31/04

to

Rick Balkins wrote:
|Anyway - direct disk access means that you are writing to track & sector.
|It is kind of funny but there really isn't a whole lot for a reason for

|a filesystem by doing this. Didn't you know that was part of the copy-

|protection system used by many software makers. There is only one working
|file in the directory and that's about it.
|
|Sure anyone can do anything and that's fine. Yet, what is the exact

|benefits???? In an OS environment ???? How would an OS know where data

|files are stored. You would need a database for this.

Those are rhetorical questions that each person should answer for
himself; it is like asking people why files should have 'dates' on
them if the 1541 disk operating system doesn't know what 'dates'
are. And if that is the case, why have a battery backed up clock
in a harddrive? I guess it is because it is far better to have a
variety of options at one's disposal than having to buy a "one size
fits all" computer/harddrive setup. People should have the choice.
As I have kept repeating, people don't HAVE to buy JiffyDos, but it
makes plenty of sense to go ahead and buy one for the sake of their
collection.

In much the same way that people should buy a PC, I guess. It is
better to have two PC's - one of which is a PC that asks you to insert
your system disk whenever it powers up - than only one that never
does that sort of thing.

Matthew Montchalin

unread,

Mar 31, 2004, 5:03:23 PM3/31/04

to

On Wed, 31 Mar 2004 mau...@cmdrkey.com wrote:
|> No, if you launch a utility that performs a "once-through" then you
|> no longer have to go through multiple directory searches just to spool
|> a file to somebody who has just dialed up your BBS, you just launch
|> the thing, ready to go, by plugging the tracks and sectors into the
|> job queue.
|
|Let's assume the drive in use is a CMD-HD running in a native
|partition with about 2000 files in the directory. After doing a
|once through, where would you store all of those directory entries
|in the memory of the computer, and still have space for your
|application as well as whatever data you are processing?

I've always disliked the CMD 'partitioning' system, but why not
store all the tracks and sectors in a partition of its own? Would
not this be the most typical way a programmer would solve the
problem?

But expecting a long distance dialer to sit through a 2,000 file
directory search - as you seem to be saying, a worst case scenario -
just to spool an intro screen at him, does seem rather high-handed,
even if it were for a PC based BBS and not a CBM based BBS. In that
same worst case scenario, expecting the LD caller to sit for a
2,000 file directory search and finally finding the desired file
at the very end, is an unpleasant experience at 1200, 1800, or 2400
baud - no matter how you cut the cake. Instead, the sysop ought to
know in advance exactly which partition already contains the file in
question, and be able to take it from there.

Matthew Montchalin

unread,

Mar 31, 2004, 5:07:55 PM3/31/04

to

mau...@cmdrkey.com wrote:
|> Rick Balkins wrote:
|> |DIRECT DISK ACCESS, what's your POINT ????
|
|> What is YOUR point? DIRECT ACCESS is GOOD for you, and it BEATS having
|> to swap roms around for something you aren't even going to be USING.
|
|Matthew, I don't mean to argue, but think for a second...
|
|How can I load up and run any software using direct access?

Not all software runs on all platforms. It's like asking me how to
get Microsoft 'Word' to run on a C-128, sometimes it is not even a
good idea trying to get it to.

|How can thousands of other people do it?

They can buy the software they like, for whatever reason. But
encouraging programmers to do it right, is a good thing and not
a bad thing. The 1541 is capable of doing far more than run of
the mill consumers think it can. A bbs that performs poorly for
LD callers (and local callers) reflects badly on the hardware
that is set up for it.

Telling a programmer not to do something X because it doesn't
work on machine Y is a cop out.

Rick Balkins

unread,

Mar 31, 2004, 5:10:27 PM3/31/04

to

Now you got the IDEA !!!! Good. People don't have to buy JiffyDOS. Of course
but don't complain that JiffyDOS doesn't work with your program. You never
made your program(s) available widely enough nor have you bothered to make
it run on JiffyDOS either. Anyway, its a choice on your behalf. It won't be
hard if you decide to do so. In the meantime, JiffyDOS is fairly compatible
and has been one of the most compatible upgrade by number of different
titles that runs.

I just don't like the fact that you were saying things that are clearly
false or becomes false when you overly states things and exaggerate the
difficulty and incompatibility to the point where it is false. You have a
tendency to do that Matthew. When you over exaggerate things and literally
make up stuff along the way - By doing that, you loose credibility.

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message
news:Pine.LNX.4.44.040331...@lab.oregonvos.net...

> Those are rhetorical questions that each person should answer for

Rick Balkins

unread,

Mar 31, 2004, 5:18:50 PM3/31/04

to

"Matthew Montchalin" <mmon...@OregonVOS.net> wrote in message

news:Pine.LNX.4.44.040331...@lab.oregonvos.net...

> mau...@cmdrkey.com wrote:
> |> Rick Balkins wrote:
> |> |DIRECT DISK ACCESS, what's your POINT ????
> |
> |> What is YOUR point? DIRECT ACCESS is GOOD for you, and it BEATS having
> |> to swap roms around for something you aren't even going to be USING.
> |
> |Matthew, I don't mean to argue, but think for a second...
> |
> |How can I load up and run any software using direct access?
>
> Not all software runs on all platforms. It's like asking me how to
> get Microsoft 'Word' to run on a C-128, sometimes it is not even a
> good idea trying to get it to.

MATTHEW !!!! LISTEN !!!!

I was referring to Commodore software since WE ARE TALKING ABOUT COMMODORE
!!!!!!!!!!
Now quit being an IDIOT !!!! It does have a tendency to be F*CKING annoying.

> |How can thousands of other people do it?
>
> They can buy the software they like, for whatever reason. But
> encouraging programmers to do it right, is a good thing and not
> a bad thing. The 1541 is capable of doing far more than run of
> the mill consumers think it can. A bbs that performs poorly for
> LD callers (and local callers) reflects badly on the hardware
> that is set up for it.

Okay.

> Telling a programmer not to do something X because it doesn't
> work on machine Y is a cop out.

You answer why when it happens to work fine so far.

Matthew Montchalin

unread,

Mar 31, 2004, 5:29:18 PM3/31/04

to

Rick Balkins wrote:
|> They can buy the software they like, for whatever reason. But
|> encouraging programmers to do it right, is a good thing and not
|> a bad thing. The 1541 is capable of doing far more than run of
|> the mill consumers think it can. A bbs that performs poorly for
|> LD callers (and local callers) reflects badly on the hardware
|> that is set up for it.
|
|Okay.
|
|> Telling a programmer not to do something X because it doesn't
|> work on machine Y is a cop out.
|
|You answer why when it happens to work fine so far.

Because Maurice proposed to speculate about why 1541-only programming
techniques may not always work on CMD harddrives, that's why. My own
CMD harddrive disappeared some 14 years ago, and I never got around to
replacing it, so a lot of this is pure speculation. I can't say for
sure why his harddrive can't be 'jobbed' around, but in the same way,
it was my understanding that you could program it at the SCSI level
if you really HAD to have some kind of secret partititons somewhere
that the CMD DOS should not touch.

The CMD harddrive fills a great niche, and it would be a shame if
people didn't get one for their collection. User group 'librarians'
should definitely get one.