JiffyDOS Plus4/C16
Maurice Randall
JiffyDOS coded for the C16 and the Plus4. I've actually
powered up a C16 with a very early development version of
JiffyDOS. It couldn't do much at this point, but it powered
up without any problems.
-Maurice
--
** Maurice Randall - Click Here Software Co.
** High-Performance for your Commodore
** email: mau...@cmdrkey.com, sup...@cmdrkey.com
** web: http://cmdrkey.com
Riccardo Rubini
"Maurice Randall" <mau...@cmdrkey.com> wrote in message
news:7mQCf.15039$_S7....@newssvr14.news.prodigy.com...
> Update: I'm about 30-40 percent of the way though getting
> JiffyDOS coded for the C16 and the Plus4. I've actually
> powered up a C16 with a very early development version of
> JiffyDOS. It couldn't do much at this point, but it powered
> up without any problems.
Maurice, do you plan to improve the 1551 support as well?
Riccardo
Maurice Randall
> Maurice, do you plan to improve the 1551 support as well?
I don't have a 1551 and have never used one. In what way
would it need to be improved?
Maurice Randall
definitions for the C16 and Plus/4 in the JiffyDOS kernal.
A little input from some existing users might help.
JiffyDOS adds function key definitions to the 64 and VIC-20.
The 128 already uses the function keys in BASIC, but JiffyDOS
changes the definitions of them.
On the 64 and VIC-20, you can disable the function keys with
the @F command. On the 128, the @F command restores the
standard definitions, it doesn't disable the function keys.
The C16 and Plus/4 will work like the 128, @F will restore
the standard definitions if you don't like the way JiffyDOS
programs them. Of course, a small BASIC program will code
them any way you like.
In all cases, a SYS command can restore the JiffyDOS keys.
In my opinion, Commodore goofed when they labelled the F keys
on the C16 and Plus/4. It confuses a regular 64/128 user with
the numbering scheme. For this discussion, I will just call
the keys 1,2,3, and 4 as they sit on the keyboard. This would
be the same as F1,F3,F5, and F7 on a 64.
My plan is to code the keys similar to the way JiffyDOS 64
does it so there is some consistency for existing JiffyDOS
users. The main difference will be with key 4 on both the
C16 and Plus/4 and key 1 on the Plus 4. Here's the layout:
C16:
1 @$ (to display the directory)
2 / (to load a file)
3 ^ (to load and run a file)
4 HELP
SHIFT-1 @D (to display a BASIC program)
SHIFT-2 @T (to display a text file)
SHIFT-3 [left arrow] (to save a program)
SHIFT-4 @ S" (to delete a file)
The only difference between the C16 and C64 is key 4. I'm
leaving that with the help command because the key is
labelled "HELP".
Plus/4:
The Plus/4 is very similar to the C16 layout except for
key 1 in its shifted position. Instead of having @T on
that key, it will function to start the 3 in 1 software.
So that key definition gets moved from the unshifted
position to the shifted position.
I've given this considerable thought and feel the above
is the most logical setup. Any thoughts are welcomed.
James @ cbm264
My two cents is that the factory function key definitions already
support most of what you are defining them as. I can see why you would
want to duplicate the 64/128 function key assignments as closely as
possible, for those who might have JiffyDOS on a Plus/4 (or 16) as well
as on their 64.
But at the same time, the Plus/4 (and 16) users are already used to the
function key assignments that Commodore defined, and changing them for
JiffyDOS might cause more confusion than if they were left alone.
The factory assignments are:
F1=Internal software on Plus/4, GRAPHIC or external software on 16
F2=External software on Plus/4, DLOAD otherwise
F3=DIRECTORY (the architecture allows for another external software but
we don't have a multi-cart expander)
F4=SCNCLR
F5=DSAVE
F6=RUN
F7=LIST
HELP=HELP
Therefore, I suggest the following key definitions for JiffyDOS:
F1=(remaining as internal software on Plus/4, or external software on
16, otherwise GRAPHIC)
F2=/ (load) (or external software on Plus/4)
F3=@$ (directory)
F4=@S (scratch)
F5=<- (save)
F6=^ (load and run)
F7=@D (list)
HELP=HELP
The only definition not used is @T (display text file), since there is
a possibility of the user having either 3+1 (screen code files, similar
to SpeedScript) or Script/Plus (CBM ASCII files).... unless you intend
to support both file formats.
Another reason why the Plus/4 (and 16) definitions can be different is
because the function keys are in a different place on the Plus/4
keyboard (upper left). The 64 and 128 have them on the right.
OR --- have two sets of JiffyDOS ROMs, one for the 16 (with 64's
definitions as you proposed), and one for Plus/4 defintions!
OR --- detect the Commodore or Control keys, and use that to display
the JiffyDOS defintions. Otherwise use the factory definitions.
Higgyterm (1660 terminal software) used this technique to have 16
different function key definitions.
James
www.cbm264.com
James @ cbm264
A friend in Europe asks if the Plus/4 and 16 version of JiffyDOS will
come in both NTSC and PAL versions.
James
Maurice Randall
> A friend in Europe asks if the Plus/4 and 16 version of JiffyDOS will
> come in both NTSC and PAL versions.
Yes, both versions will be available. I'm testing the NTSC version
right now. Once I get it bug-free, I'll apply the changes needed
for the PAL version.
MagerValp
RR> Maurice, do you plan to improve the 1551 support as well?
MR> I don't have a 1551 and have never used one. In what way would it
MR> need to be improved?
As a 1551 owner myself, I can't really see anything that would need to
be improved, as long as the normal @/^/%/etc commands work with the
1551. I'm not sure if the 1551 has a faster format routine than the
1541, but that's really all I can think of. Speed-wise, the 1551 is
just fine (even though it could be lots faster).
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
MagerValp
MR> I'm trying to decide on how to set up the function key definitions
MR> for the C16 and Plus/4 in the JiffyDOS kernal. A little input from
MR> some existing users might help.
Personally, I've never understood the point of JiffyDOS' function key
definitions. It's faster to just use the normal /, %, ^, and @ keys on
the keyboard, and easier to remember too. If you compare it with AR6
and FC3, they actually execute the commands as well, and don't just
type them, saving you a few keystrokes.
Maurice Randall
> Personally, I've never understood the point of JiffyDOS' function key
> definitions.
I partially agree with you. The only two function keys I ever
use are F1 and F8. F1 to view a directory and if I want to
delete a file, scroll to the file from the directory listing,
press F8 and hit return. Quick and easy.
Maybe there could be some handier F key definitions than what
are currently in there. Once things are finalized, it will be
too late, they'll have to stay that way. But I can make the VIC-20,
C16, and Plus/4 keys anyway I want right now.
Riccardo Rubini
"MagerValp" <Mage...@cling.gu.se> wrote in message
news:p14mzhd...@panini.cling.gu.se...
> As a 1551 owner myself, I can't really see anything that would need to
> be improved, as long as the normal @/^/%/etc commands work with the
> 1551. I'm not sure if the 1551 has a faster format routine than the
> 1541, but that's really all I can think of. Speed-wise, the 1551 is
> just fine (even though it could be lots faster).
There are a few 1551 speed loaders out there. I haven't done much testing
myself, but when I gave them a try, the improvement was noticeable. So, I
empirically guess it's possible to improve something.
The co-moderator of the mailing-list I founded, who is a brilliant, maybe
the best Italian 264 coder ever, gave me a modified ROM with a bunch of
improvements for the 1551. Among them, the ability for format up to 859
blocks on standard DSDD disks.
I should have that material somewhere, another part is on my mailing-list.
You can get in touch with us at http://groups.yahoo.com/group/cbmclub_main/
. The mailing-list is for Italian speakers, but we have "tolerated" through
the years English as well :-)
Riccardo
MagerValp
RR> There are a few 1551 speed loaders out there. I haven't done much
RR> testing myself, but when I gave them a try, the improvement was
RR> noticeable. So, I empirically guess it's possible to improve
RR> something.
Yes, there's plenty of room for improvement, but considering the very
limited market, it doesn't make sense. 1541s are butt slow, but 1551s
are usable as they are.
MagerValp
MR> I partially agree with you. The only two function keys I ever use
MR> are F1 and F8. F1 to view a directory and if I want to delete a
MR> file, scroll to the file from the directory listing, press F8 and
MR> hit return. Quick and easy.
Yeah, F1 is the only one I use in JiffyDOS. In my custom version I've
copied the F-keys from TFC3:
F1: LIST
F2: MONITOR
F3: RUN:ret
F4: (don't remember, don't use it :)
F5: DLOAD:ret
F6: DSAVE"
F7: {clr}DIR ret
F8: DOS"
IMHO they're the best ones so far. Especially when loading it's just
F7, cursor, F5, F3.
Riccardo Rubini
> Yes, there's plenty of room for improvement, but considering the very
> limited market, it doesn't make sense. 1541s are butt slow, but 1551s
> are usable as they are.
True, the 1551 is very nice as it is. We were talking about improvements,
though. While Maurice is at it, he can throw one or two nifty hacks. Think
about it: Maurice is probably the last hero in drive improvement left in
this niche. We should jump at this opportunity while we can :-)
Riccardo
Maurice Randall
Plus/4 gets overwritten by the standard "SYS1525: 3-PLUS-1"
definition. It looks like the internal function rom does this
before the bootup sequence is all finished. This would tend to
indicate that if the function rom is removed, then whatever
is coded into the JiffyDOS F1 key will remain.
So, I won't be putting SYS1525... onto shifted F1. And I won't
be putting it on the unshifted F1. But unshifted F1 will have to
have something that is useful but not necessarily needed.
That must be what James was eluding to with shifted F1 having
either GRAPHIC or another function rom definition. So, I will
have to decide carefully how the JiffyDOS F key definitions
are laid out.
Thanks for the suggestions thus far.
By the way, the C16 and Plus/4 JiffyDOS roms are running
fairly well but with some bugs. The actual coding is all in
there, I'm just debugging now.
silverdr
> Yeah, F1 is the only one I use in JiffyDOS. In my custom version I've
> copied the F-keys from TFC3:
>
> F1: LIST
> F2: MONITOR
> F3: RUN:ret
> F4: (don't remember, don't use it :)
> F5: DLOAD:ret
> F6: DSAVE"
> F7: {clr}DIR ret
> F8: DOS"
>
> IMHO they're the best ones so far. Especially when loading it's just
> F7, cursor, F5, F3.
>
I found exactly those also the most useful. Have them in DolphinDOS in
the very same functions and places. At least the unshifted ones. Very
handy and very appreciated: my most used sequence: F7, cursor, F5, F1
(to check what's in the BASIC part), F3.
Riccardo Rubini
> By the way, the C16 and Plus/4 JiffyDOS roms are running
> fairly well but with some bugs. The actual coding is all in
> there, I'm just debugging now.
Maurice, is very nice to know you have all the things going well and are
here with chatting in the channel. When do you expect the ROMs to be
available for order? Good luck with your project.
Riccardo
Maurice Randall
> When do you expect the ROMs to be
> available for order? Good luck with your project.
I expect to have the C16/Plus4 rom ready for beta testers by the
end of this week. Then I would expect a couple of weeks of testing
to give it a good shakedown.
ramswell
curious about something. Ever thought about coding Jiffy Dos for the
"BIG" CBM Dual Drives (that is if it's possible)? I would LOVE to have
one for my 8250! No hurry, of course. I was just wondering......
Charles
Maurice Randall
> Ever thought about coding Jiffy Dos for the
> "BIG" CBM Dual Drives (that is if it's possible)?
No, I don't plan on doing anything for the early PET computers
and their variations or the IEEE drives.
CMD's (actually Mark Fellows) original idea behind JiffyDOS was to
speed up the slow CBM serial bus routines. Once he got into the
development a bit, he found out he could add more features other
than just the disk drive speedup. There was never any intention
of supporting the parallel IEEE drives.
The amount of development time involved would never be recovered,
anyway. Even with the VIC-20, C16, and Plus/4 JiffyDOS, it will
take awhile before I get my development costs back on these. I figure
I'll have to sell maybe 75-100 JiffyDOS for the VIC-20 and 125-150
for the C16/Plus4 combined. I may never sell that many. I'm doing
this mainly because I think it is a good thing to have available.
ramswell
of JIFFY DOS, I was wondering if you will be selling a +4 Computer that
is Jiffy Dos enabled, and if so, then when and how much? I wanna be on
the list for that as well.
Charles
Maurice Randall
> I was wondering if you will be selling a +4 Computer that
> is Jiffy Dos enabled, and if so, then when and how much?
No, I won't. I've only got 2 Plus/4's. One works and one doesn't.
I've got just one C16. It's a nice one and it works. These are the
JiffyDOS test mules here.
50 years from now, these computers along with one of my VIC-20's
will be famous. They were the first of their kind to run JiffyDOS. :)
ramswell
Charles
Sam Gillett
"Maurice Randall" wrote ...
>
> No, I won't. I've only got 2 Plus/4's. One works and one doesn't.
> I've got just one C16. It's a nice one and it works. These are the
> JiffyDOS test mules here.
>
> 50 years from now, these computers along with one of my VIC-20's
> will be famous. They were the first of their kind to run JiffyDOS. :)
50 years from now... ???
In 2056 very few people will know who Jack Tramiel was. And even fewer will
remember what JiffyDOS was.
Even now, very few people can tell you who built ENIAC without looking it up
somewhere. Or what the names of the engineers at Bell lab who discovered
the transistor were.
For all but a few, such as Julius Caesar and George Washington, fame fades
away rapidly.
In 100 years even the mighty C64 may be forgotten... :-(
--
Best regards,
Sam Gillett
Why is the third hand on a watch
called the second hand?
Clockmeister
"Sam Gillett" <samgille...@diespammermsn.com> wrote in message
news:2WfEf.29349$5G.19389@trnddc08...
>
> "Maurice Randall" wrote ...
>>
>> No, I won't. I've only got 2 Plus/4's. One works and one doesn't.
>> I've got just one C16. It's a nice one and it works. These are the
>> JiffyDOS test mules here.
>>
>> 50 years from now, these computers along with one of my VIC-20's
>> will be famous. They were the first of their kind to run JiffyDOS. :)
>
> 50 years from now... ???
>
> In 2056 very few people will know who Jack Tramiel was. And even fewer
> will
> remember what JiffyDOS was.
>
> Even now, very few people can tell you who built ENIAC without looking it
> up
> somewhere. Or what the names of the engineers at Bell lab who discovered
> the transistor were.
>
> For all but a few, such as Julius Caesar and George Washington, fame fades
> away rapidly.
>
> In 100 years even the mighty C64 may be forgotten... :-(
Maybe not, someone, somewhere, going through some old stuff will find
something and they will be curious as to what it was...
Sam Gillett
"Clockmeister" wrote ...
>
> "Sam Gillett" <samgille...@diespammermsn.com> wrote in message
> news:2WfEf.29349$5G.19389@trnddc08...
>>
>> away rapidly.
>>
>> In 100 years even the mighty C64 may be forgotten... :-(
>
> Maybe not, someone, somewhere, going through some old stuff will find
> something and they will be curious as to what it was...
If they find an old C64 they may have sweet dreams.
If they find an old Spectrum they will have nightmares! ;-)
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
Payton Byrd
> "Clockmeister" wrote ...
>> "Sam Gillett" <samgille...@diespammermsn.com> wrote in message
>> news:2WfEf.29349$5G.19389@trnddc08...
>>> For all but a few, such as Julius Caesar and George Washington, fame fades
>>> away rapidly.
>>>
>>> In 100 years even the mighty C64 may be forgotten... :-(
>> Maybe not, someone, somewhere, going through some old stuff will find
>> something and they will be curious as to what it was...
>
> If they find an old C64 they may have sweet dreams.
> If they find an old Spectrum they will have nightmares! ;-)
If they find an old spectrum they'll have a perfectly good doorstop, no
matter what century it is!
Clockmeister
"Payton Byrd" <plb...@bellsouth.net> wrote in message
news:VOWEf.16476$vp6....@bignews6.bellsouth.net...
Right on!
Lars Haugseth
I'm now envisioning speccies being crunched to smithereens by B5/ST-style
sliding doors closing rapidly. Ahh, what a lovely thought. Thank you.
--
Lars Haugseth
"If anyone disagrees with anything I say, I am quite prepared not only to
retract it, but also to deny under oath that I ever said it." -Tom Lehrer
Maurice Randall
giving me fits. But I'm finally making some headway. The
biggest struggle is getting the serial bus timing right.
If JiffyDOS was a whole new development, it probably wouldn't
be a problem. But I have to make the C16/Plus4 work with
disk drives that can't be changed.
Today is the first day that I can say JiffyDOS looks very
promising for the C16 and Plus/4. It's finally working good,
but just needs a few minor bugs worked out.
Maurice Randall
Getting them to do well was a real pain in the rear, though.
Getting the serial bus timing to work while trying to avoid
TED was a real task. But after about 40 hours of work on just
the JiffyDOS fastload routine, it finally works without any
lost bits or bytes. And, it's extremely fast!
The big problem was getting the timing of the C-16/PLUS4 to
work with the existing JiffyDOS routines in the disk drives.
If JiffyDOS were being coded all brand new today, it wouldn't
have been a problem, but there are a lot of 1541's and other
drives out there that already have JiffyDOS and the C-16 and
PLUS/4 have to be able to work with them "at their speed".
Both the NTSC and PAL versions appear to have no known bugs
and it's time for some serious beta testing.
The 1551 still works but at the same speed. JiffyDOS only
speeds up the serial bus drives. The filecopier and DOS
wedge and other features of JiffyDOS work fine with the
1551, however.
I downloaded the few fast load programs from Bo Zimmerman's
site and tried them out on the PLUS/4. I'm happy to say
that JiffyDOS is at least twice as fast as any of these
fastloaders. And you don't have to preload JiffyDOS, it's
already in the computer when you turn it on.
MagerValp
MR> Getting them to do well was a real pain in the rear, though.
MR> Getting the serial bus timing to work while trying to avoid TED
MR> was a real task. But after about 40 hours of work on just the
MR> JiffyDOS fastload routine, it finally works without any lost bits
MR> or bytes. And, it's extremely fast!
Very nice! I'm curious though, how do you handle processor speed
switching - do you just drop down to 0.88 MHz when transferring?
A Grosz
switches to single clock mode for RAM refresh (remember, the TED is
constantly alternating between single clock and double clock mode for
allowing higher CPU speed when it does not need the bus). On single
clock cycles, writes take twice as long as in double clock ones before
becoming valid so one has to accomodate his transfer routine for
allowing both possibilities. There's a bit in one of the TED registers
however (bit #1 of $FF13) that forces the TED to single clock mode
(~887 kHz), so that cycles not required by the TED (usually on the
border) will not be utilised by the CPU, and all the cycles will be
"equally long", this makes life much easier, but you lose horsepower of
course.
All disk turbos for the 264 family that do not blank the screen are
running in forced single clock mode, although there are a bunch that
are running with the screen blanked AND in "allow for double clock"
mode.
I am not sure how and what exactly you did with JiffyDOS, but if you
could somehow sync the machine with the screen on AND without forcing
single clock mode, that could be an improvement over the existing turbo
loaders.
Attila
Maurice Randall
> how do you handle processor speed
> switching - do you just drop down to 0.88 MHz when transferring?
Yes, during the actual data transfer, the show processor speed
is used. For those who don't know, it's impossible to use the
fast speed and get the timing correct because the TED chip can
interrupt and change the timing to the slow speed. Then the data
transfer fails. But there was a lot more to getting this to work
then just setting the slow speed.
A Grosz
tricky. Here's a turbo that runs in fast clock mode (although with
screen blanked):
http://plus4.emucamp.com/sd.php?pid=12886
Attila
Maurice Randall
> I am not sure how and what exactly you did with JiffyDOS, but if you
> could somehow sync the machine with the screen on AND without forcing
> single clock mode, that could be an improvement over the existing turbo
> loaders.
There's no way, believe me I tried. That's why I spent so much time
on this. Even with the screen blanked and the processor switched to
.894 mhz, TED got in the way. I was pulling what hair I had left.
But I finally figured it out yesterday.
It's only the fastload routine where the screen gets blanked. The
128 JiffyDOS in 40 column mode also blanks the screen during
fastload. All other transfers that use the kernal CHRIN, CHROUT,
CIOUT, and ACPTR routines are done without blanking the screen.
JiffyDOS needs about 88 clean clock cycles to get one byte loaded
in during the fastload routine on the C-16 and PLUS/4. And it has
to do this 254 times for each sector.
The 64 can do this without blanking the screen because it only has
to avoid one bad raster line out of every 8. TED gets in the way
for 2 raster lines out of every 8.
Even with the screen blanked and at .894mhz, TED still causes
a problem, but this is what I was finally able to work around.
Early on, I was able to make the fastload routine work with the
screen displayed and only the clock speed slowed down. But the
fastload transfer times weren't acceptable due to having to avoid
the two bad raster lines. The time spent avoiding those lines
caused the disk drive to miss the next sector in the interleave
and it had to go around again. None of the fastloaders on Bo's
site are able to keep up with the interleave on the disks I've
been testing with. The VIC-20, 64, and 128 all keep up just fine.
So, to have the C-16 and PLUS/4 with JiffyDOS not be able to keep
up as well just wouldn't be acceptable.
To the end user, all he notices is the screen blanking just like
the 128 in 40 column mode. This I can live with. What's actually
going on underneath doesn't matter as far as the user is
concerned, he's just looking at a blank screen for a very, very
short time.
One of the test files I've been using is a game called "WU LUNG"
which I downloaded from Bo's site. I used this because it's
big enough and gives me enough time to listen to the drive while
it's loading. I can hear the stepper motor moving as it changes
tracks.
At 117 blocks long, this file loads in about 9 seconds on a 1541.
It only took just a little under 5 seconds on a 1581 with JiffyDOS.
This is due to the 1581 being able to load a whole half track
into it's own memory. The 1541 can only load 1 sector at a time.
Other fastloaders took 25-32 seconds on a 1541.
On a stock 1541, with no fastloader, it took 1 minute and 15 seconds.
From the above results, I think I succeeded and we can live with
a blank screen for the short time it takes to load a file. A 49
block file loads in just 3 seconds on the 1541.
Maurice Randall
> It is not impossible to use fast clock during transfer, but indeed very
> tricky. Here's a turbo that runs in fast clock mode (although with
> screen blanked):
I can see this one must be doing what I did in JiffyDOS. It also
loaded the 117 block file in about 9 seconds.
However, the disadvantage of using a disk based fast loader is
I had to type in DLOAD"FASTLOADNAME" and hit RETURN, then RUN
and RETURN. It took about 6 seconds then to load in MEGALOAD V4.
Then I was able to DLOAD the 117 block file.
With JiffyDOS, I just press a function key to display the directory,
cursor up to the file and hit the UP-ARROW key and RETURN.
On the C-16 and PLUS/4, I've made F5 an UP-ARROW with RETURN, so
it's just a matter of cursoring to the file and pressing F5 to
load and run it.
A Grosz
ROM ;-) I was only refering to the fact that it IS possible to do a
transfer routine in fast mode.
BTW, here's an old post of mine where someone looked for a very fast
1541 turbo for the 264 series:
(sorry for the long link)
I have never measured it accurately, but that 'TSS turbo' seemed
lightning fast to me, even faster then the above mentioned Megaload 4.
It also blanks the screen, and handles interleave (AFAIR).
Attila
Maurice Randall
> I have never measured it accurately, but that 'TSS turbo' seemed
> lightning fast to me, even faster then the above mentioned Megaload 4.
I downloaded it and tried it, but it would break out from
the load with a load error. The 1541 continued to run as if
it were still sending data. I could hear the tracks changing
and that part seemed quite fast. I tried this a few times, each
time with a load error.
So, I tried it in Vice and it still wouldn't work.
My conclusion on this one is it might be fast, but it also
needs to be reliable.
I like it when something works right out of the box.
A Grosz
be an issue that it was written for PAL machines and I assume you are
using an NTSC one. On the other hand, VICE's drive emulation is not
very good when it comes to the 264 series (actually not the drive
emulation itself is problematic but the synchronization between the
emulated machine and the 1541). You could try Yape, that is running
this turbo just fine.
Attila
Maurice Randall
> Odd, I never had problems with that turbo, it always worked. It could
> be an issue that it was written for PAL machines and I assume you are
> using an NTSC one.
That's probably the reason for it not working for me. The timing
is probably too tight to work on both systems.
MagerValp
MR> But I finally figured it out yesterday.
Thanks, interesting read!
Maurice Randall
beta test the new JiffyDOS for the PLUS/4. I need someone with
a PAL PLUS/4 to do the testing. If you need JiffyDOS for your
1541, 1571, or 1581, I'll also send one of those to you. I
need someone who has a fair amount of original software to
test with.
It would also be a help if you have access to a 1551 to make
sure the 1551 still works OK with JiffyDOS enabled. But it's
not entirely necessary since one of the beta testers in the
US has a 1551 to test with.
If you think you can help with this, send me an email, I'd
really appreciate it. I'll be sending some NTSC versions to
a couple of beta testers this week and would like to send out
a couple of PAL versions as well.
Thanks...
MagerValp
MR> I need someone who has a fair amount of original software to test
MR> with.
MR> It would also be a help if you have access to a 1551 to make
MR> sure the 1551 still works OK with JiffyDOS enabled.
I don't have a single piece of original software for the Plus/4, but I
do have a 1551. I do have a bunch of demos and other freeware that I
can test with, as well as a couple of drives with JiffyDOS.
Robert Bernardo
> I could use someone in Europe or Australia (or wherever) to
> beta test the new JiffyDOS for the PLUS/4. I need someone with
> a PAL PLUS/4 to do the testing.
I have a PAL Plus/4 and some PAL software for it.
FCUG celebrating 25 years,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
Maurice Randall
now. Thanks to those who responded.