Surftec-STD launch DigiFlash2 - RISC OS News, Software and Information

Surftec-STD launch DigiFlash2

Published: 8th May 2003, 12:19:29GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Where's me digital camera? [Updated 18:43 8/5/2003] USB-Parallel port

After a brief period of subtle whisperings in the direction of mass storage USB, Surftec and Stuart Tyrrell Developments have jointly announced today the immediate availability of their DigiFlash2 product.

DigiFlash2 is designed to read and write to CompactFlash (type 1) and SmartMedia cards, allowing RISC OS users to transfer files and data between their computers and various gadgets that use CompactFlash or SmartMedia cards to store information. Such gagdets include digital cameras and MP3 players - devices rapidly growing in consumer popularity.

DigiFlash2 is USB based and requires the Simtec USB interface to plug into a RISC OS machine. RISC OS drivers for the card reading device are, of course, included. We had originally claimed that STD had whipped Surftec in the race to first market a USB based mass storage device for RISC OS although this couldn't have been further from the truth, which is a nasty habit for a news website.

In actual fact, Surftec and STD were originally working on a larger project to develop DigiFlash2 for both the Castle Technology USB standard and the Simtec USB standard, however support for the Castle USB hardware was recently dropped. As a result, we're told the two developers concentrated on completing their DigiFlash2 product for the Simtec USB interface.

USB-Parallel (update)
Riding the Simtec USB rollercoaster some more and this time inviting along Explan, the two developers have produced a USB-to-Parallel port converter, or "USB Parallel port thingy" as STD describes using clearly baffling yet highly technical terminology.

"The interface plugs into the USB podule on the computer and offers a second parallel port", writes Stuart Tyrrell in a later email to drobe.co.uk. "This allows the use of printers with Centronics parallel interfaces to be driven from a USB card, whilst using their standard RISC OS driver (a special USB driver is not required)."

The USB provided parallel port is faster than the internal parallel port, we're informed. Having a second port is useful for running two parallel port based devices at the same time from a single machine, such as a printer and Zip drive.

Links
DigiFlash website - should have product details and ordering info on it real soon.
STD wesbite

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

ribbit 8/5/03 3:25PM	This looks lovely and makes a RISC OS machine looks a more tempting prospect.
diomus 8/5/03 3:40PM	An MP3 player and digital camera look tempting now that I can use them with my RPC (after getting a USB podule..) Chris, drobe.co.uk
danielbarron 8/5/03 4:45PM	I'd buy one if it worked with my Iyonix and my Iyonix was not sitting collecting dust waiting for 32-bit network support apps such as lanman98, lirc, and a few others that aemulor can't fix.
diomus 8/5/03 5:27PM	I'm sure I could find someone willing to take your Iyonix off your hands for a while A 32 bit Bitchx in Nettle is also good, btw, if you're missing Lirc. Chris, drobe.co.uk
mavhc 8/5/03 9:45PM	A USB to parallel converter that doesn't work with the only RISC OS computer with no parallel port and usb, that's probably ironic or something. What speed are parallel ports on various RISC OS machines? Max a new ECP/EPP port can do is 3MB/sec, usb 1 is 1.5MB/sec.
stdevel 8/5/03 10:05PM	The Iyonix generally ships with a USB->Parallel converter due to the lack of parallel port. I have every reason to believe mine would work on the Iyonix too. However, I cannot provide support for the vagaries of Castle's modifications to !Printers (which have broken some legitimate drivers - indeed VDU2/3 was dead at one stage, although I understand this is now fixed). The Simtec card has supported USB printers all along (and indeed the adaptors) - the pack I ship is purely hardware and instructions, there's no need for other drivers. At least I stand a snowball's chance of providing support for this as !Printers isn't changing underneath it by a 3rd party with an interest in breaking it! Max the combo chip can be written to on the RPC is in the order of 1MB/sec (witness Pat Herborn's postings many moons ago) - in real life it's much slower. I've not done full analysis yet, which is why the original press release says that the speed tests are informal (I suppose for completeness the word should have been "subjective").
epistaxsis_RISC OS 8/5/03 11:47PM	Any advance on the simtec podule for iyonix yet?
imj 9/5/03 1:31PM	Podule for Iyonix would be totally stupid. What's required is for someone to write a DeviceFS wrapper for the Simtec card (so it looks like a Castle API!) and/or write a Simtec-API module sat on top of the Castle stuff. Can't really be that hard. Then, of course, there'd be all the stupid 32bit issues...
AMS 13/5/03 7:08PM	*In reply to imj:* why have you a bee in your bonnet over 32bit ? It's not as if Castle or ROL had any hand or part in the matter. ARM decided it was dropping 26bit PSR+PC and that was that. The fact you can still get a working processor (SA) for Omega (or RPC for that matter) is because Intel don't seemed to have got fully bored with them yet.... when they do the fastest 26bit compatible will be 56MHz and it's called a ARM7500FPE !!!!! Some day Intel will retire the SA and then what ? I would agree with you that it would have been nice to have an uprated 26bit processor clocked like an xScale - but that is simply not going to happen. That being the case we have a need to get code 32bit clean (all of us). And with the C/C++ development suite it's relatively easy. As to the USB API that's another kettle of monkeys.... for example would a "wrapper" round the USB API (whichever one) not hit the speed (and effect isosynchronous performance - that is if that's supported ?)). Regards -- Annraoi McShane,