Use of parallel ports in NES/PC interfaces

I was excited about FDS writing in TapeDump until I saw this:

Then all my hopes went down.

Seriously, what is worse than parallel ports. I fracking hate them and anyone who still use them. They got defunct since 1998 or so. You'd have to be stupid to expect people to still own PCs with them. Seriously.

I'm sorry for the harsh attitude, but I am so disappointed I can't remain polite in such circumstances.

Bregalad, if you don't like it, you can go home. You don't have a parallel port, and you're upset when someone who does have one uses it? Tough.

I am home already and yes I am upset. Because all my previous attempts to ever use a parallel ports ended being a complete waste of time. Again this technology is defunct since 1998 or so and no PC since then are made with them.

What GPIO method do you recommend using instead of a parallel port?

Anything that can be used in 2013.
Micro-controllers costs about $1 nowadays, and they can communicate with USB/Jtag very easily from Windows and Linux.

Another option from a PC that should be considered seriously is the serial RS-232 port. It's also old and somewhat outdated, but not nearly as much as the parallel port, and desktop stations of nowadays still have one on them (even if laptops doesn't have any).

I thought the reason for parallel ports being used was that other ports sent data too fast for the Famicom to read it accurately enough...

Barrier to entry with a parallel port: pretty minimal. Two connectors. Barrier to entry with a serial port: about the same, but now you have to emulate a UART in the FC, which slows things down by a factor of ten and keeps the FC busy from doing anything else. Using an "ordinary" serial port doesn't actually help, because if you're using it as bit-bangable I/O it's incompatible with USB, and if you send asynchronous serial you still need voltage limiters to keep from frying the FC. You could use a "logic level" USB serial port, like a PL2303 or a FT232, but now that's an explicit cost, rather than one lumped into "do you have a parallel port".

Adding a microcontroller dramatically increases the cost (you still need all the connectors), and even if you specify a USB-enabled microcontroller you don't actually save much over the separate USB-RS232 bridge and crappy micro. (Don't lie to me about how easy it is to use V-USB in a hard real-time system. It's not.) It doesn't even actually increase the availability to the end user, because PCI and PCIe parallel ports are still available, and cost about as much as a microcontroller plus programmer.

On the other hand, you keep on running your mouth about How Other People Should Do Things and don't ever put your money where your mouth is. You have single-handedly diverted too many conversations by being toxic and loud.

And here I go, feeding the troll...

Could we split of Bregalad's rant from ccovell's original thread?

And a parallel port card. And a desktop (not laptop) PC to put it in.


A microcontroller and programmer cost less than a desktop PC for someone who currently uses a laptop. Or is there some suitable external version of PCIe now?

P8H61-M LX. Your argument is invalid

I've got one of these in 2011 for less than 40 bucks when I bought my current computer. It sports a 1156 socket for i3/i5/i7 processors, fast PCI-e 3.0 slots, SATA connectors, DDR3 RAM, and with a parallel and serial ports.

My small media pc (about the size of a PS2) has a parallel port on it with I do use. Many motherboards have headers for installing the parallel port. What is more of a problem is being able to use the parallel port in newer versions of Windows OS.

There's nothing wrong with using the parallel port though. It's a readily available option for fun projects. Yes it would be nice if we could just smush a USB interface on everything but it just isn't that easy.

Should I have gotten that USB-to-Centronics adapter I saw recently at a thrift store?

All the 3 desktop computer I have in my house still have parallel port. I use it for my old tototek card and gba flash cart without issue. But then again I'm still too stubborn to move away from Windows XP, I keep hearing people struggling running thing on Windows 7 and I ain't about to switch to Win 8 anytime soon

Some common USB to parallel port adapters are only for printers. They don't have the sort of timing needed for GPIO. As of right now, with laptop computers having no GPIO port, USB to MCU is probably the best workaround.

Unfortunately pretty much every USB parallel adapter (and a lot of newer parallel ports on computers) don't implement all of the lines properly, often just enough to let printers work. I learned this the hard way and it's what drove me to use a 9 year old machine as my main laptop...

Edit: goddomot toppls

I do find it ironic how arguably the least neutral person on this forum is the guy from Switzerland. But maybe that's just a false stereotype


I'm guessing this statement is directed towards me, so I'll abstain from making any points/comments. But I would like to better understand what you mean because your statement mystifies me. I value your view point/argument and would merely like to understand it better. That and I'd like to understand why people think I'm a liar.

Are you saying that V-USB isn't easy from a developers standpoint or an end user's? Or both?

What you mean by 'a hard real-time system'. I assume the FC/NES, but how is it a hard real-time system compared to any other computer like system? Or is it that an mcu in general is challenging to interface with the FC/NES (not V-USB specifically)?

V-USB implements USB by polling, so your microcontroller can only pay attention to USB lines or to the NES at a time. Hard real time would be being able to juggle continuous activity on both, which basically requires hardware assistance in the form of ≈DMA or USB hardware.

I did speak too hyperbolically: there are clear workarounds, such as time-sharing. They have their own trade-offs, of course.

My two cents to Bregalad: If you hate someone else and their project so much because of their design decisions then get off your ass and build something yourself. Use that to prove why your choices are better vice trash talking someone else and a inanimate data communication protocol who isn't listening.

I'm also curious where one can buy a PC with a user JTAG port...


Yeah that was my basic solution. Even with the limitation of the NES waiting on the mcu while USB transfers are in progress doesn't seem like a significant loss to me. In my use the data transfers are always initiated by the Host PC anyways. If things are constantly streaming back and forth it would be a more penalizing draw back though.

First of all, I have absolutely nothing against Chris Cowell at all. This is a total misunderstanding.

Then, yes I am upset about the usage of parallel port, yes, for the simple reason it's hard to find PCs with them, and if you find a PC with one, it's extremely hard to make it work.

Under any Windows more recent than 98 (and who still uses 98...) you need the special .dll files to have any hope to acess the LPT, and even then it will randomly fail because your motherboard is form brand X instead of brand Y, etc...

The reason why I reacted so was because of my last attempt at using a parallel port to communicate with the Commodore-64 disk drive to test my programs developed on my PC on my C64. This ended up being a complete waste of time because nothing worked at all and all transfer programs were dating from 1992 or so, and were completely unusable as of the 200X years. This is where my hatred towards parallel ports comes from. Eventually I was able to use a fake tape cassette in order to download data from the sound jack of my PC, works flawlessly. It can't write disks but at least it's a simple and reliable way to download a program into the C64 from a PC.

Now if someone can proof me otherwise that it's easy to access to PCs which are more recent than 2000 and have parallel port, and that access them with Windows 7 (or even XP), or any common Linux distro, without reinventing the wheel and rewrite your own OS/Kernel/Drivers yourself, then I'm all ears.

Yes USB is complicated to use and yes it's not easy, however at least it's modern and widely supported. You can get microcontrollers with embedded USB interfaces, or a regular microcontroller with software support of USB with open source and free software available on the internet. I used such a program once at my work, so I know it is possible, and on a tiny AVR micro with only 8 pins !
Thanks to interrupt they can both listen to USB and do something else at the same time if programmed right.

Of course I'd do such a device myself if I could the problem is that the timing from the FDS drives are a total mystery for me and I have no hope of doing it right.
In the end I am very glad for Chris's hard work and I hope it will be useful for me one day, but as long as you can't get rid of the LPT, I can't see myself successfully using it.

www.highrez.co.uk/Downloads/InpOut32/default.htm

I'm using a Willem on a 64 bits Windows 7 Home Premium.

Huh? If that's the case then I suggest you refrain from making comments like this:



It's pretty hard to think we're the ones who 'misunderstood' what you said. It sounds more like you don't understand the words coming out of your own mouth...

Just let me be vulgar when I want to, ok ?

Also remember that english is not my language, and I don't know how to sound a little vulgar but not too much. So I just do what I can.

Yeah, I initially bought a "USB to Parallel" adapter and ended up with one of those useless printer-only cables. Then I bought a parallel port card but it turned out not to work with my motherboard. A few months ago I bought a second one that I think should work, but I haven't felt like taking my PC apart to install it yet.

It's probably convenient to work with from a hardware perspective once you have it going, but I do think it's an extremely inconvenient thing to get working. In general I prefer to use my laptop, and there's really no hope of doing anything parallel port there.

My old(er) laptop has a parallel port, but I could never get anything with bidirectional mode working properly. (Copynes)

I actually encountered the exact opposite of your problem.
I tried to access my Commodore 1541C via parallel port on a computer using a 64-Bit Linux distro and had absolutely no problems. But Windows XP (32 Bit !) has been a lot of trouble and I have not gotten it to work.
To do all this I used the OpenCBM software which was last updated in 2007 if the website is not telling lies.
I also tried to write cassette tapes but had no luck. Not on Windows, not on Linux, not on a different computer. I don't know whether it's the programs, the tapes or the datasette device or something else. It just never worked.
The computer I used was built from single parts and not bought as a complete machine. By today's standards it is nothing great with a single core CPU and only 1.5GB of RAM. And unfortunately it broke on me last year.

I have been looking for alternatives and found the SD2IEC device which consists of a microcontroller that transfers data from an SD card to the C64 or vice versa via the seriell connection.
It's not any faster than the floppy drive is (except if you use speedloaders...had bad luck with those). But it is very convenient and actually really easy to build yourself if you don't want to import it from somewhere.
By the way if anyone knows of something similar (inexpensive, easy to build and use) for the Atari ST, please let me know!

So yeah, now that I don't have access to a parallel port anymore I also find it annoying if modern electronics projects rely on it.
But honestly instead of having to put microcontrollers in every device I'd rather have my parallel port back. And while we're at it: I don't have a serial port either and I have not seen computers with serial connections in a while...same with the gameport or PS/2 connectors. And we could go further with IDE, Floppy controllers or even ISA cards.
But I also really don't like these USB to MIDI converters, because I often have notes getting stuck on a channel or a lot of latency. And my serial to USB converter and PS/2 to USB converter never really worked.

So what is my point on this? I'd like to be able to use both the old and the new connections! It becomes considerably harder especially with complete PCs or laptops. You really have to look for parts that allow you to use those older interfaces with success. What I found was usually really expensive because it was aimed at industries and not consumers or it was just incredibly outdated.

It's funny because it seems that everything that works for you don't for me and vice-versa. I have a MIDI <-> USB adapter wich works great. The only problem is if you're plugging it in and out while the PC is active, but as long as you don't touch the connexion it works flawlessly. I didn't even to install a driver for it !

And yes you are right that modern PCs doesn't have serial ports any longer, and that no new design should rely on them. I just have the impression they disappeared only recently while the parallel ports have been gone for a looooong time.
I think many PCs still have PS/2 ports surprisingly. I use them on desktop stations to save USB ports for better usage (I never have enough USB ports !).

Also usually PS/2 -> USB adapter are passive. Don't ask my why this works, but sometimes it does. Probably only if they were shipped by the same manufacturer. It's possible they simply use USB protocol trough the PS/2 port, and that some kind of multiplexer comes afterwards that can detect if it's a true PS/2 peripheral, or their USB peripheral with an adapter. It's just speculation.

I share most of bregalad's feelings, because I too had a lot of problems with parallel ports. Many years ago I tried really (really!) hard to find a motherboard that still had a parallel port built in, and when I did I simply couldn't get anything to work with it. Tried every mode and every suggestion I found online but it was no use. Even the PC I had before that, which had a working parallel port, wasn't exactly what you'd call reliable. My Willem programmer for example would randomly refuse to be detected.

I haven't seen a parallel port in a while now, and that doesn't bother me a bit. All game/hobby devices I currently own have USB connections, and I have no problems with them. I don't plan on buying anything that needs a parallel port ever again.

Personally, I find the irony of trying to start a flame-war about how you shouldn't use an outdated piece of hardware on a forum which revolves around EVEN MORE ancient hardware quite amusing. The best kind of comedy is often unintentional.

Had I woken up on my more sarcastic side today I'd start a rant on how spending time in 2013 on making new products for a system which hasn't been produced for over 20 years is totally retarded and excludes 99.9something% of the potential user-base. But I'll spare myself the effort this time around...

Such a rant wouldn't involve recommending Pygame or DHTML instead, would it?

Yes, but the NES still works perfectly after all these years. The same can't be said about old PCs and their parallel ports....

Sure it can. Lots of old PCs still work fine.

The problem we're having is new PCs and their lack of parallel ports.

LPT port is my favorite part on a PC... and it really is not hard to find on a modern computer, it is harder to get a board with IDE than with one that has LPT port. At least so have been my experiences as a computer repairman and seller past few years. I sometimes took liberties of trying some of my own devices on these modern computers and I cannot say there were any problems. I did only use a boot CD though.

blah blah blah....

One question - did you paid for that programms? If answer is "NO", why do you complaining?

Thinkpad T20 made in 2001 have parallel port.

Microcontroller and FDS? Ask kyuusaku, he is not clueless, but kinda f***ed up, guess why?

P.S. Yum-yum-yummy thread

Because I lost a considerable amount of energy and time trying to make this PC <-> commodore 64 connexion, only to find out that my parallel port was apprently completely not working ?

Don't worry, Bregalad, I didn't take your comments personally or out of context.

Poor-man's dumpers like TapeDump are supposed to get things working with the least extra hardware/construction/circuit building as possible. Someday if I get experiments working right, I'll get FDS uploading with only the Famicom mic and a loudspeaker.

If you want a microcontroller solution, that's in quite the opposite direction of purpose as TapeDump.

Anyway, I'm satisfied with my choice of cable using the parallel port because:

1) Software to upload files already exists (DTVTrans)
2) Parport is easily accessible by hobbyists (Wikipedia says: "For electronics hobbyists the parallel port is still often the easiest way to connect to an external circuit board."
3) It at least WORKS on my computer, while FDSLoadr never did.

Yes, I understand this point of view. A microcontroller itself is not expensive, but it's true that programming it is another story and this is impossible without "expensive" equipment. I think the easiest solution is Arduino things, but even that costs at least $30.

A parallel port costs nothing if you have a working one, but alas....

This is probably a huge improvement over FDSLoadr anyways... requiring a true (non emulated) DOS and accurate CPU timing was a pretty terrible idea.

It was better than nothing at all. Before that you needed to have a MGD1 I think? And you still may have needed a parallel port.

I think use of parallel port these days is a poor choice if one wants one's device to work with people's machines here. I wouldn't go out and buy another PC and deal with all the headaches of that just to use some piece of hardware, or even restrict my choice of PC, when there are easy and flexible alternatives over USB (Teensy comes to mind). Of course if the software is written reasonably cleanly, it wouldn't be hard to modify it to use a Teensy.

Or you just use a bootloader that makes it free: http://www.obdev.at/products/vusb/bootloadhid.html

Of course if it were to get 'bricked' you'd need the programmer to recover it. There are a few things you can do to minimize that risk though.

Teensy starts at $16 and there are even cheaper imitations.

Cry me a river. I have an Asus PX79LE that didn't come with one, so I got a PCI Parallel Port card that I checked to make sure it specifically supported all protocols. Works great. I also got an Adaptec SCSI card WITH DB25 SCSI port and an ATA card with IDE ports. I have a Belkin USB to serial which I use to console into Cisco Routers using a Rollover cable, and also works great with my C64TPC box which I used to load disk images on my C64. You CAN find USB adapters that support all the right protocols but, you just have to look around. Don't just buy any old cheap POS adapter from china and expect it to work with everything you throw at it. So if I can find these adapters all for under 50 bux each its really not that big of a deal.

If you want an IEEE1284 Card that is worth your money get a "2S1P Combo-Value" by SIIG It is fully compliant with IEEE 1284-1994 parallel port standard and supports ECP, EPP, PS2 and SPP modes.

or go to the local thrift store and get an old computer with all that stuff on it for next to nothing.

There... I just completely invalidated your entire argument.

Any help with the right query? Would usb ecp epp spp return mostly relevant results? I tried that and got If you need to connect a legacy parallel-port device like [...] EPROM programmer [...] please use our cardbus version which doesn't help for a laptop that has only USB, not CardBus.


On siig.com I see PCIe and PCI, one of which should work provided your PC is a desktop.

Huh ?
All your solutions implies buying very particular extra piece of hardware that aren't easy to find. This is just as hard/annoying as to find a PC with a working LPT port.

In addition to not being easy to find, PCs have a fairly short life expectancy. Sure, there are a few cases where they'll last decades, but some day out of the blue the motherboard/hard disk/video card/etc. dies. I certainly wouldn't expect a 10+ year old computer to last much longer.

I've really got to disagree; the only part that really ages in a computer of any era is the moving parts. The hard drive may well stop running after a decade of continuous use—they're often rated for 100k hours—but for anything that's been in safe storage, I'ven't had much difficulty coaxing old machines to life.

Anything that stores charge, such as a capacitor or a battery, will eventually lose its ability to hold a charge. Copying data onto and off of an obsolete computer requires either a network or a removable storage device, and these removable storage devices tend to be incompatible between decades-separated computers as well: 5.25" disks to 3.5" disks to USB flash drives, or ATA to SATA hard drives. Even storage devices with their own controller cards aren't always compatible, as controller cards shift from ISA to PCI to PCIe.

It's not hard to get a PCI-E parallel port for a modern computer, it is however difficult to rewrite legacy software to use it.

I feel Cardbus Technology died off too quickly. There were so many great options.

Worst case scenario you could build a USB2LPT...
http://www-user.tu-chemnitz.de/~heha/ba ... -16.en.htm

or buy it....
http://www.aliexpress.com/store/product ... 29698.html

The drivers virtualize the port so the legacy hardware doesn't know the difference. I got one a while back and works like a champ.


Additionally there is the Targus ACP45US1, but I have never used it personally but it is listed that it supports EPP/ECP and even comes with DB9 serial. Decent brand, but never tried this particular product before.

http://www.newegg.com/Product/Product.a ... 6834994907




With well written drivers you don't need to rewrite legacy software to use it. A proper legacy adapter should be fully transparent, and function as the original would using hardware virtualization if it isn't a junk product.

USB, almost by definition, is incompatible with the way most legacy bit-banging parallel ports is used; it's not ECP or EPP that's necessary, but rather MMIO.

Now, this is something that—modulo timing constraints—could be supported by dosbox, dosemu, or the windows NTVDM; for 32-bit code running not in ring 0, a fault handler. All of these all involve more involvement from lower-level kernel bits than most people are comfortable with.

That is a very good point, I really do take for granted all the virtual machines I run on my rig. Being in network administration, virtualization kinda becomes an every day thing for me, and I forget not everyone can or knows how to run virtual machines. But still as it stands, the information provided in the write ups that use these parallel ports are free and generally intended to be a low cost solution so people really shouldn't complain that the writeup calls for a parallel port rather than a specialized piece of hardware such as a programmable IC.

I thought anybody who used NES programs developed since 1997 was aware of emulators, which are a kind of virtual machine.

yeah that is true, but it does not fit the context of this thread for what the parallel port is intended to be used for. OP wanted to write/dump some Famicom Disk system games, and the only option was via parallel port.. An Emulator for the NES would be of no use to him in this particular case. He can't just emulate .FDS images onto or off of a stack of Famicom disks to be used on a real Famicom/NES.

If he wanted to just play Famicom disk system games on an emulator I am sure he wouldn't have posted a rant on how he hates parellel ports can't get a hold of a computer with one.

Will USB adapter drivers hook to port-writing DOS apps in NTVDM?
Virtual machines? Which virtual machines are able to forward port access (today)?
I know Dosbox can, but obviously there's timing jitter which still renders it unacceptable for many applications.

My LPT solution has been to use a USB MCU to issue buffered I/O with deterministic timing. It works well for almost every LPT application (as long as they don't use a write-back protocol), but reimplementing protocols sucks, and there's the unavoidable latency.

VirtualBox is by far the best free virtual machine, it can forward port access as well as direct access to any hardware you'd like (with a bit of editing a few xml files). I've had virtual box setup before where it accessed a partition or another hard drive in a dual boot setup with full 3D hardware acceleration. I did this because I did not want to constantly reboot to switch between an OS, and I had brute force CPU power (i7 3930K) and plenty of ram on my side (32gb)

https://www.virtualbox.org/

As far as I know though it does not support parallel ports, but it does have, serial passthrough and emulation. There are some "hacks" to get it kinda working, and there is a release candidate version that has it added which you can try at your own risk.

https://forums.virtualbox.org/viewtopic ... rt#p233253


VMWare on the other hand, has full parallel virtualization or passthrough, but it isn't free.

http://www.vmware.com/

If it can forward port access, why doesn't it support parallel ports? By serial support it sounds like its just hooking the Windows API, not actually trapping the ports which apparently requires IOMMU--a recent hardware extension.

Speaking of which, has anybody written a version of FDSLOADR that runs on a modern platform? (e.g. Windows 7 desktop with a PCIe parallel port installed)

If no, I'm planning to attempt it myself, but it would make me pretty happy to find out it's already done.

FDSloadr needs a reliable timebase, which you can't get in a non-RTOS like Windows. If you rewrite it, you're better off targetting a FTDI chip in bit-bang mode (I'm saving this for a rainy week), or offloading the whole program to a microcontroller.

Then wouldn't the simple solution be to Emulate an RTOS environment?

http://www.freertos.org/FreeRTOS-Window ... MingW.html

I figure if you are going to write a modern implementation for Legacy hardware you should make modern systems behave more like legacy systems. That is part of the reason DOSBox exists because it is easier to make a modern OS behave like DOS rather than having a DOS application behave like a modern one. WOW32 is a wonderful example as well. Windows 7 64-bit runs 32 bit applications because it recreates a 32 bit environment natively by simulating 32 bit memory addresses and a few other things that aren't present or changed in a 64 bit OS. I can run Windows 3.1 in a virtual machine on a 64-bit processor so it would stand to reason that creating an RTOS wrapper for an application like FDSloader is possible to do. I am not saying it would be easy, just saying just because a Modern OS does things differently or doesn't do something an older OS did doesn't mean it can't be adapted to do so. XBOX 1 kernel and software operates at Ring 0, something Windows normally wouldn't do, and people had said it wasn't possible, yet people managed make Xbox Emulators that execute these very applications at Ring 0. (albeit they worked slowly and with faults but the point is the applications ran)

So we know the appropriate hardware can be found via PCI or USB, and the Above link shows that RTOS process threads can be created, now we just need the software to run with the RTOS threads and address the hardware.

here is a commercial RTOS virtualization..

http://www.tenasys.com/index.php/tenasy ... or-windows

Yes, there are ways of circumventing windows' scheduler when necessary.

Can you run a 64-bit OS in a virtual machine inside a 32-bit OS and keep the benefits of a 64-bit OS?

Can you run a real-time OS in a virtual machine inside a non-real-time OS and keep the benefits of a real-time OS?

For things that don't run constantly, there's always the 100% CPU approach to getting better scheduling on a non-real-time OS (though not the full guarantee of a real-time one).

No (or you shouldn't at least), unless the 32-bit OS is designed to explicitly allow this (in which case it can switch to long mode when needed). Of course this assumes you aren't emulating the CPU, if you are then pretty much anything is possible.

Or you could cheat and go the Windows 3.11 way, where the kernel was 32-bit but all the other software (including pretty much the rest of the OS) were 16-bit. In this case you'd have a 64-bit kernel but the rest of the OS could be 32-bit. Does that count?


You can run a real-time OS inside a VM (since the real-time part is the kernel scheduler), but the benefits probably are thrown away by the unguaranteed timeslices of the non-RTOS host. Between the different tasks of the RTOS it should stay real-time, though (although not against real life time), so I guess at least a minimum amount of the benefits stay (probably only useful in very few specific cases though).

Also reading back the thread... Wait a second, are you arguing about software compatibility with parallel ports? Huh, that isn't the biggest issue here really, the real issue is the hardware connection (parallel port to FDS). This is why USB is pretty much hated for this kind of stuff, without a microcontroller in the way you're pretty much screwed - unless you somehow feel like emulating an USB device on the other end, that is (can you even get enough speed to make it in-spec?).

My point was that to bit-bang successfully on a parallel port, you pretty much need an RTOS, and no, running the RTOS in a VM on a mainstream desktop OS isn't going to help. So going forward, to communicate with devices through bit-banging, you'll really need a microcontroller on the other end of a USB cable.

I'm not sure a RTOS is going to help either... Hardware isn't perfect, oscillators can end up being slightly off, and that can in the long term drift the signals enough as to break things. You're going to need some sort of synchronization regardless of what you do, even if you go with a single tasking OS (which is even more accurate than RTOS as nothing can interrupt you).

Ok, so new direction with things, how about this...Getting a Commodore 64 OR an Apple ][e to communicate with a modern PC isn't all that difficult or that big of a deal to do. Get the NES to communicate with either a C64 or Apple ][e I got both of those and they are a dime a dozen. I have an IDE64 as well. (Its expensive as hell but it saved me lots of pain with 5.25 floppies ) I know a bit of Basic and 6502 assembly. Maybe I will fool around with it over the summer and see what I come up with. I want to go with the apple II because of the RS-232 port and I can even run TCIP over it, but a commodore 64 is a bit smaller and easier to store and I could rig up something to the cassette or serial ports and with the IDE64 and the USB link capabilities it will make development so much easier.... but oh wait.... that's been done too...

viewtopic.php?f=2&t=9909

Anything that works on a C64DTV will work with a real C64..., and they are literally available at nearly any yard sale or local ad. I bought mine from the basement of an old church.

I used to use Star Commander with a x1541 cable off a boot CD to write .D64 files onto Floppies with my 1541 drive. I really got sick of that and got the IDE64.

I guess what I am getting at is if people want a cheap solution to something without spending a lot of money or messing around with programmable ICs, they are going to get stuck with a Parallel port or some other Serial port. It's just how it is. Cheap = Serial.

So if an RTOS cant be run reliably within windows then I guess a Boot CD like with Star Commander for the 1541 drive would be the next option, and have this RTOS on a CD address the hardware in question via PCIE or that USB to Parallel adapter full legacy support on it to accommodate modern computers.

I also strongly disagree with the short life expectancy of a PC. Moving parts aside, such as the fan or HDD most computers will outlive us all, and even if a HDD did fail, it isn't something that couldn't be easily replaced with something more reliable such as a USB stick. (for the purposes of this PC being used for Serial communications a full featured HDD isnt needed) Cooling fans are dirt cheap and so are low end power supplies, which if kept dust free work fine. The real problem is the people who smoke around their computers and the tar makes all the dust stick to everything, and then the system overheats and they wonder why their computer doesn't last more than 3 or 4 years. I have a Powerbook 190 (18 years old) with Lead acid batteries and it still works just as well as it did the day I got it, with all original parts, and Powerbook G3 Pismo (13 years old) and also a Blue and White G3 PowerMac (14 years old) that works as well. I had to replace the RTC battery on it because it showed signs of leakage, but that is easy enough for any simpleton to replace. I really want an Amgia 4000T and the USB add-on card.

Interfacing with C64 peripherals etc is a completely different matter, FDSLoadr must somewhat accurately shift out/sample a ~100 kHz raw disk head signal whereas many other protocols are data layer, and handshaked such that jitter is irrelevant. Clearly one of the design principles of FDSLoadr was minimal hardware; if you give FDSLoadr an external timebase (oscillator, register, missed bit flag) the LPT can easily keep up in Windows and the jitter won't be of concern.

So the options are:

a) figure out how to reuse FDSLoadr in Windows through kernel sorcery
b) give the LPT an external timebase
c) custom USB MCU firmware
d) FTDI module or maybe Arduino or something

For Game Boy development, I hooked it to my SNES since that was the most accessible device I had that could do the protocol and timing easily. So I have the PC to the SNES via bit-banged serial on the SNES, and then the SNES to the GB via bit-banged clocked serial. I used to use a Tandy 102 (8085-based portable computer) for my I/O needs. Now I'd probably just use a Teensy 2.0 that I have.

Another option: give this guy some support viewtopic.php?f=22&t=9631