Can I set up a WinVista computer as the drive for a C64 through a USB
port through a program like HDD64?  IIf so, how?  I have a DOS-based
laptop, but it is stuck networked with another laptop for the hard
drive.  I have a Win98 computer, but it has a virus and is otherwise
not working properly.

> Can I set up a WinVista computer as the drive for a C64 through a USB
> port through a program like HDD64?

If you mean 64HDD, it works under real DOS only and doesn't support
any kind of USB cable or a cable with a USB-to-parallel transceiver.

On Feb 8, 10:44=A0am, "Joe Forster/STA" <s...@c64.org> wrote:
> > Can I set up a WinVista computer as the drive for a C64 through a USB
> > port through a program like HDD64?
>
> If you mean 64HDD, it works under real DOS only and doesn't support
> any kind of USB cable or a cable with a USB-to-parallel transceiver.

Sorry about the typo.  Is there another program that can do what I
need?

> > > Can I set up a WinVista computer as the drive for a C64 through a USB
> > > port through a program like HDD64?
>
> > If you mean 64HDD, it works under real DOS only and doesn't support
> > any kind of USB cable or a cable with a USB-to-parallel transceiver.
>
> Sorry about the typo. =A0Is there another program that can do what I
> need?

No, you can't emulate a Commodore drive with software running in a
multi-tasking system.

No, not really the right answer actually.

More correct answer, Vista, like XP is based on NT kernal. NT kernal doesn't 
allow for direct access to the printer port which X-cables tend to use. 
64HDD was designed around direct I/O access via these ports.

The main thing is not emulating. VICE does it all the time on a multi-task 
OS and so does many other emulators.
So the main thing is the software has to support the interface cable/device 
and is programmed to support the ports like USB. Otherwise, you be basically 
using the wrong driver.

I read something in the big fat book about the 95/98 and NT API and stuff. I 
don't have the book in front of me at time of writing to word it just right. 
I'll get back with the exact thing I read in the book. It appears to be 
something on the order of a protective layer.

64HDD justs needs to be written to poke a hole in the NT kernal's condom.

"Joe Forster/STA" <sta@c64.org> wrote in message 
news:4305cd7e-ba6f-4b66-8a51-0d2bc364a456@j38g2000yqa.googlegroups.com...
> > > Can I set up a WinVista computer as the drive for a C64 through a USB
> > > port through a program like HDD64?
>
> > If you mean 64HDD, it works under real DOS only and doesn't support
> > any kind of USB cable or a cable with a USB-to-parallel transceiver.
>
> Sorry about the typo. Is there another program that can do what I
> need?

No, you can't emulate a Commodore drive with software running in a
multi-tasking system. 

[blabla skipped] Read again what I wrote:

> No, you can't emulate a Commodore drive with software running in a
> multi-tasking system.

Do you see the word "Windows" in this sentence? No. And I repeated
almost the very same sentence in a parallel thread where the same
question was asked but related to Linux. Multi-tasking systems are not
very good for real-time communication - unless aided by hardware
taking off the burden -, especially when they're emulating a device
that needs to conform to an external source that requires precise
timing to the microsecond.

The only solution I see would be having the software (user space
software, kernal driver, whatever, doesn't matter in this context)
eating up the CPU completely so that it can react to external
"stimulus" within microseconds, without any chance for being
interrupted. That seems like going back to good old DOS times but it
isn't: give the process a dedicated CPU on a multi-CPU system -  such
hardware is now available for acceptable prices - and the system will
still remain responsive and run other processes with the other CPU's.
(Dunno how CPU dedication would work along with virtualization, though
- haven't tried a hypervisor software yet.)

"Joe Forster/STA" <sta@c64.org> wrote in message 
news:252fe20a-10a7-4169-8a4d-68512b41284f@q9g2000yqc.googlegroups.com...
> [blabla skipped] Read again what I wrote:
>
>> No, you can't emulate a Commodore drive with software running in a
>> multi-tasking system.
>
> Do you see the word "Windows" in this sentence? No. And I repeated
> almost the very same sentence in a parallel thread where the same
> question was asked but related to Linux. Multi-tasking systems are not
> very good for real-time communication - unless aided by hardware
> taking off the burden -, especially when they're emulating a device
> that needs to conform to an external source that requires precise
> timing to the microsecond.

No, but this thread is about Windows. So when you imply multitasking OSs, 
you are talking about Windows.
Since the thread focuses on Windows, I focused on Windows. It also would be 
inappropriate to speak much about Linux
without knowing enough about it.

> The only solution I see would be having the software (user space
> software, kernal driver, whatever, doesn't matter in this context)
> eating up the CPU completely so that it can react to external
> "stimulus" within microseconds, without any chance for being
> interrupted. That seems like going back to good old DOS times but it
> isn't: give the process a dedicated CPU on a multi-CPU system -  such
> hardware is now available for acceptable prices - and the system will
> still remain responsive and run other processes with the other CPU's.
> (Dunno how CPU dedication would work along with virtualization, though
> - haven't tried a hypervisor software yet.)

Sure you can when you hold the application with highest priorities and run 
it on a stimulus clock. I agree, DOS would be better but if YOU really want 
to get deep into the hardware, then you go without an "OS" and write to BIOS 
level operation. Pure x86 assembly if you have the balls to learn it.   :-P 
Sorry I don't have big enough cohonies for doing that.

Oh well. As for multi-cpu deals, it can be interesting. For what it's worth, 
once you are in a single-tasking environment then basically why have an OS 
per se. Just turn the PC into a big glorified Nintendo and include all the 
driver codes in the application. Also apply multi-thread technology and so 
on.

If I really need a Super-Smart Drive controller, why not a C-One?

The multi-cpu/multi-core cpu deal is interesting to figure out.

 

On Feb 10, 4:06=A0am, "Rick Balkins"
<rickbalkins.nos...@nospam.gmail.com> wrote:
> "Joe Forster/STA" <s...@c64.org> wrote in message
>
> news:252fe20a-10a7-4169-8a4d-68512b41284f@q9g2000yqc.googlegroups.com...
>
> > [blabla skipped] Read again what I wrote:
>
> >> No, you can't emulate a Commodore drive with software running in a
> >> multi-tasking system.
>
> > Do you see the word "Windows" in this sentence? No. And I repeated
> > almost the very same sentence in a parallel thread where the same
> > question was asked but related to Linux. Multi-tasking systems are not
> > very good for real-time communication - unless aided by hardware
> > taking off the burden -, especially when they're emulating a device
> > that needs to conform to an external source that requires precise
> > timing to the microsecond.
>
> No, but this thread is about Windows. So when you imply multitasking OSs,
> you are talking about Windows.
> Since the thread focuses on Windows, I focused on Windows. It also would =
be
> inappropriate to speak much about Linux
> without knowing enough about it.
>
> > The only solution I see would be having the software (user space
> > software, kernal driver, whatever, doesn't matter in this context)
> > eating up the CPU completely so that it can react to external
> > "stimulus" within microseconds, without any chance for being
> > interrupted. That seems like going back to good old DOS times but it
> > isn't: give the process a dedicated CPU on a multi-CPU system - =A0such
> > hardware is now available for acceptable prices - and the system will
> > still remain responsive and run other processes with the other CPU's.
> > (Dunno how CPU dedication would work along with virtualization, though
> > - haven't tried a hypervisor software yet.)
>
> Sure you can when you hold the application with highest priorities and ru=
n
> it on a stimulus clock. I agree, DOS would be better but if YOU really wa=
nt
> to get deep into the hardware, then you go without an "OS" and write to B=
IOS
> level operation. Pure x86 assembly if you have the balls to learn it. =A0=
 :-P
> Sorry I don't have big enough cohonies for doing that.
>
> Oh well. As for multi-cpu deals, it can be interesting. For what it's wor=
th,
> once you are in a single-tasking environment then basically why have an O=
S
> per se. Just turn the PC into a big glorified Nintendo and include all th=
e
> driver codes in the application. Also apply multi-thread technology and s=
o
> on.
>
> If I really need a Super-Smart Drive controller, why not a C-One?
>
> The multi-cpu/multi-core cpu deal is interesting to figure out.

I have to agree with Joe on this one. Back in Windows 95/98 days (and
remember, these versions *don't* limit your hardware access), I had
timing issues...

Running a PC99 emulator (emulating a TI-99) and running the Wsector/
Rsector program to transfer disks over serial cable, therefore writing/
reading from a "disk" file on the hard drive on the PC, writing/
reading from a real drive on the TI, generally the transfer would
"hang" during the handshaking of the save/load operation (the
operation underlying it all in the TI's BIOS). And if it made it past
that, it would usually hang somewhere during the transfer.

Run it in DOS, nearly 100% perfection.

Timing issue - multi-tasking OS doesn't allow a "real-time" task to
execute within the performance boundaries necessary for proper
operation.

winston19842005@yahoo.com wrote:

> Timing issue - multi-tasking OS doesn't allow a "real-time" task to
> execute within the performance boundaries necessary for proper
> operation.

Not inherently, no.  However, it might be worth taking a look at Real Time 
Linux.  IIRC, they implement a fast, light-weight hypervisor that runs 
directly on the metal and handles tasks with hard real-time deadlines.  The 
Linux kernel runs as a low-priority task under that framework and communicates 
with the hypervisor using a message queue or mailbox arrangement of some sort.

I believe the work is under GPL for non-commercial application.

Steven Hirsch wrote:

> winston19842005@yahoo.com wrote:
> 
>> Timing issue - multi-tasking OS doesn't allow a "real-time" task to
>> execute within the performance boundaries necessary for proper
>> operation.
> 
> Not inherently, no.  However, it might be worth taking a look at Real Time
> Linux.  IIRC, they implement a fast, light-weight hypervisor that runs
> directly on the metal and handles tasks with hard real-time deadlines.  The
> Linux kernel runs as a low-priority task under that framework and
> communicates with the hypervisor using a message queue or mailbox
> arrangement of some sort.
> 
> I believe the work is under GPL for non-commercial application.

Not to mention the realtime extensions present in the existing kernel.  I
don't know how they work, but I'm willing to guess that, on anything
reasonably modern, those extensions offer more than enough precision to a
drive emulator without consuming 100% CPU.  Some existing programs (some very
old, like XMMS) can be given realtime priority by the user, presumably for
the very reasons we're talking about here.

Recall that all Commodore drives are async relative to the C64 or C128, and
they only transfer around 0.5 to 8 KB/sec or so.  They have to handshake to
exchange data, and unless I'm wrong, either end can make the other wait if
necessary, by simply doing nothing.

The cause, in my opinion, of routines that are too brain dead to properly
handshake is this strict "real C64 +  real 1541" mentality.  It's 2009, there
are tons of other storage devices out there for a C64, and most stuff works
fine if the program's loader behaves properly.  Why haven't we moved on
already?  

-- 
"There are some things in life worth obsessing over.  Most
things aren't, and when you learn that, life improves."
http://starbase.globalpc.net/~vanessa/
Vanessa Ezekowitz <vanDEesLEsaTEezeTHkoISwitz@gmail.com>

> Recall that all Commodore drives are async relative to the C64 or C128, a=
nd
> they only transfer around 0.5 to 8 KB/sec or so.

Not entirely, there are stages in the protocol where the other party
must reply within a given amount of time; if it doesn't, a timeout
occurs. Also, as far as I remember, the "last byte of any stream (file
or sector) gets lost when read from the disk in normal mode" bug in
Star Commander was also caused by an EOI detection problem.

> The cause, in my opinion, of routines that are too brain dead to properly
> handshake is this strict "real C64 + =A0real 1541" mentality. =A0It's 200=
9, there
> are tons of other storage devices out there for a C64, and most stuff wor=
ks
> fine if the program's loader behaves properly. =A0Why haven't we moved on
> already? =A0

Probably because the 1541 drive is the lowest common denominator that
pretty much all people (also) have.

It would be possible to replace the built-in KERNAL IEC routines in
the host (C64, C128) with a completely asynchronous protocol - see
http://www.64hdd.com/64hdd/64carts.html for a great example of such
cartridges - but then you still haven't solved the problem of fast
loaders (a great percentage of which use synchronous transfer with an
even tighter timing than the original).

Hi again Steven,

at first I wrongly replied to your email
address only and forgot to include the
newsgroup. So here it is for all.

Steven Hirsch schrieb:
>> Timing issue - multi-tasking OS doesn't allow a "real-time" task to
>> execute within the performance boundaries necessary for proper
>> operation.
> 
> Not inherently, no.  However, it might be worth taking a look at Real 
> Time Linux.  IIRC, they implement a fast, light-weight hypervisor [...]

Even then, by using a dedicated real-time OS
kernel, you will not be able to hold a timing
in the �s range due to latency constraints.

For OpenCBM (Linux as well as Windows) this
was solved by using true hardware interrupt
handling (kernel mode driver) for the line
with the very most tight timing requirement.

This is the so named "Talker Response Limit"
with a typical/maximum reaction time of
30�s/60�s (micro seconds, not milliseconds!),
where a signal change coming in on the DATA
line needs to be signaled/answered on the
CLOCK line.


When the PC should emulate an IEC bus device
instead of an IEC bus master as the original
poster asked for, then there is another such
timing requirement on a different incoming
IEC line (ATN, Talk-Attention Release). But
the LPT port is limited such that it can
handle hardware interrupt only at one line.
Therefore it is pretty much practically not
possible to create something similar to
OpenCBM but for IEC slave/device mode, I'm
sorry.


Womo

> reaction time of 30=B5s/60=B5s (micro seconds, not milliseconds!)

Fuck! Me no engineer, me not understand difference between micro and
milli. <:-) Then the real-time patched Linux's 200 microsecond latency
(=3D 200 CPU cycles in the 1541) is also way, way too large for this
purpose...

Joe Forster/STA wrote:
>> reaction time of 30�s/60�s (micro seconds, not milliseconds!)
> 
> Fuck! Me no engineer, me not understand difference between micro and
> milli. <:-) Then the real-time patched Linux's 200 microsecond latency
> (= 200 CPU cycles in the 1541) is also way, way too large for this
> purpose...

Anyone know the typical latency and jitter of RT Linux?  The one I'm thinking 
of is NOT just a kernel with low-latency patches.  It's a hypervisor that 
handles hard-deadline events and hands off cycles to a real linux kernel when 
possible.  On a multi-processor or multi-core machine, I have to believe it 
can do the trick.

Steven Hirsch wrote:
> Joe Forster/STA wrote:
>>> reaction time of 30�s/60�s (micro seconds, not milliseconds!)
>>
>> Fuck! Me no engineer, me not understand difference between micro and
>> milli. <:-) Then the real-time patched Linux's 200 microsecond latency
>> (= 200 CPU cycles in the 1541) is also way, way too large for this
>> purpose...
> 
> Anyone know the typical latency and jitter of RT Linux?  The one I'm 
> thinking of is NOT just a kernel with low-latency patches.  It's a 
> hypervisor that handles hard-deadline events and hands off cycles to a 
> real linux kernel when possible.  On a multi-processor or multi-core 
> machine, I have to believe it can do the trick.

Nevermind... Answered my own question.  Looks like you can get tantalizingly 
close with linux-rt.  I found a chart showing average interrupt response of 
7.3 usec. with maximum up around 50 usec.

Take a look at:

http://www.scribd.com/doc/3469938/Soft-hard-and-ruby-hard-real-time-with-Linux

Hello,
Steven Hirsch wrote:

> Joe Forster/STA wrote:

> Anyone know the typical latency and jitter of RT Linux?

Having used RT-Linux/Free myself, and having teached it to our students
(cf. http://ivs.cs.uni-magdeburg.de/EuK/lehre/lehrveranstaltungen/Wintersemester0405/EZS_VL_WS0405.shtml),
I feel obliged to answer here: The possible latency of RT-Linux/Free is
clearly in the range that an OpenCBM solution for it would be possible -
at least if changes on *any* parallel port line would generate an
interrupt - something that is not possible currently, only one line, so,
yet another cable would be needed. Then, we would have a completely
interrupt-driven implementation of the IEC bus protocol. Anyhow, I think
even a non-interrupt-driven implementation would be possible.

But: How many persons would install the RT-Linux patch (which requires
choosing a Linux kernel which fits exactly one of the RT-Linux patches,
and hoping that it compiles somehow - which is not always the case!) in
order to use CBM equipment? Especially since other solutions exist. I
don't think it is worth the effort.

Regards,
Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

Spiro Trikaliotis wrote:
> Hello,
> Steven Hirsch wrote:
> 
>> Joe Forster/STA wrote:
> 
>> Anyone know the typical latency and jitter of RT Linux?
> 
> Having used RT-Linux/Free myself, and having teached it to our students
> (cf. http://ivs.cs.uni-magdeburg.de/EuK/lehre/lehrveranstaltungen/Wintersemester0405/EZS_VL_WS0405.shtml),
> I feel obliged to answer here: The possible latency of RT-Linux/Free is
> clearly in the range that an OpenCBM solution for it would be possible -
> at least if changes on *any* parallel port line would generate an
> interrupt - something that is not possible currently, only one line, so,
> yet another cable would be needed. Then, we would have a completely
> interrupt-driven implementation of the IEC bus protocol. Anyhow, I think
> even a non-interrupt-driven implementation would be possible.
> 
> But: How many persons would install the RT-Linux patch (which requires
> choosing a Linux kernel which fits exactly one of the RT-Linux patches,
> and hoping that it compiles somehow - which is not always the case!) in
> order to use CBM equipment? Especially since other solutions exist. I
> don't think it is worth the effort.

I won't argue the merits of practicality, but I could see putting together an 
"appliance" distribution on CD or DVD using the RT-Linux kernel.  Depending 
upon what folks really wanted to do with it, you might not even need X 
running.  A server does not need a GUI.

Hello Steven,

Steven Hirsch wrote:

> I won't argue the merits of practicality, but I could see putting together an 
> "appliance" distribution on CD or DVD using the RT-Linux kernel.  Depending 
> upon what folks really wanted to do with it, you might not even need X 
> running.  A server does not need a GUI.

How is this different from having a booting CD or DVD (or USB stick or
floppy disk) with 64HDD on it?

Regards,
Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

"Spiro Trikaliotis" <usenet-200901@spiro.trikaliotis.net> wrote in message 
news:slrngs98c2.uf.usenet-200901@news.trikaliotis.net...

>> "appliance" distribution on CD or DVD using the RT-Linux kernel. 
>> Depending

> How is this different from having a booting CD or DVD (or USB stick or
> floppy disk) with 64HDD on it?

Well, you'd get all the Linux advantages:  Native long filenames, much 
easier networking, remote management etc.  64HDD is great but I abandoned it 
long ago because the DOS limitations were too frustrating.  Something 
similar for RTLinux would be nifty.


There's a completely different approach to solving this problem, namely 
swapping in a custom Kernal onto the C64 so it uses a multitasking 
OS-friendly protocol instead of (or in addition to) IEC.  This has been done 
already in a few ways (serslave, udpslave, etc)

My favorite (as you've all heard) is the IDE64 - it lets you use your PC's 
hard drive (Linux, Windows) as a virtual drive on the C64 which is 
incredibly handy.  You can use USB, Ethernet, serial, X cables, etc.

-Leif 

"Harry Potter" <maspethrose7@aol.com> wrote:

>Can I set up a WinVista computer as the drive for a C64 through a USB 
>port<snip>

Hi Joseph,

I use a usb mmc memory card formatted to FAT16 to transfer disk images 
between my Windows computer and my C64.

I got mine in about a week from ProtoVision

http://www.protovision-online.de/catalog/product_info.php?products_id=112

Better info over here:

http://www.vesalia.de/e_mmcreplay.htm

Next I will be getting a UIEC from Jim Brain (hopefully he'll have some 
left)

http://archive.netbsd.se/?ml=cctech&a=2008-12&t=9428859


Bill

Leif Bloomquist wrote:

> My favorite (as you've all heard) is the IDE64 - it lets you use your PC's 
> hard drive (Linux, Windows) as a virtual drive on the C64 which is 
> incredibly handy.  You can use USB, Ethernet, serial, X cables, etc.

Yes, looks nice.  However, even after chasing every obvious link from the 
website I'm unable to determine if anyone is manufacturing these cards and, if 
so, what the price is.