Re: USB PVR recordings -> computer File systems and file types
Paul D Smith
Have you you tried a USB stick formatted with ext3 (the Linux FS)?
Panasonic TVs use a Linux sub-system so might be more forgiving if given
something they like.
Paul DS
Jeff Layman
> I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
> find that this TV is VERY choosy as to what usb disk it will use and
> will not record to a USB stick at all, or indeed any USB disk that has
> an interface eg any caddy type. It also insists on formatting the disk
> to its own file system which cannot be used on a computer, and is
> encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings - you would have to
> re-format the hdisk) .... all this is obviously done to prevent ANY
> transfer of HD recordings. There is a Component connection but it is TV
> input only - no output. The only output is SD from SCART.
> My guess is that all modern HD tVs are probably protecting HD recordings
> like this to prevent any transfer....Maybe part of the HDMI encryption
> standard licence?
> (the Panasonic model no is TXL32E30B (about �500) if this is of
> interest to others)!
It is, thanks.
Without downloading umpteen manuals for other TVs and checking, does
anyone know whether this sort of "tying-down" applies to USB recording
with other makes as well as Panasonic?
--
Jeff
J G Miller
> It also insists on formatting the disk to its own file system which
> cannot be used on a computer
Please let us all stop using the Micro$oft incorrect use of the
term "formatting".
Formatting is a low level operation only usually
done by the disk manufacturer.
The TV creates a file system (probably ext3 or possibly XFS) which is
not supported on *your* computer.
> and is encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings
This is exactly the same for Samsung and I would guess all
other brands of TV which have built in recording facilities.
In the case of Samsung TVs, the the models with "TV Recording"
and "Pause Live TV" will only provide functionality with a
disk which has an XFS file system. And as you have observed
the recorded files are encrypted using the identity of the
mainboard in the TV to prevent playback on any other system.
This is the TV manufacturers attempt at keeping the broadcasters
happy after the introduction of "Broadcast Flag" technology
to prevent copying was thwarted.
<http://en.wikipedia.ORG/wiki/Broadcast_flag>
What is even more annoying about the Samsung TV implementation
is that the MediaPlay facility will only play files put on a
USB disk with an NTFS (or maybe FAT32) file system and refuses
to recognise any files put on the disk with XFS file system.
> Im also interested in a (non Sky) HD satellite receiver eg Technomate,
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
I can only speak of experience with AZbox receiver which will record and
playback TV recordings as well as audiovideo files for which it has codec support,
which is just about everything except the more esoteric commercial ones
eg Quicktime, Realmedia, on USB disks with ext2/3, XFS, and FAT32 but not
NTFS file systems.
John Legon
> Im also interested in a (non Sky) HD satellite receiver eg Technomate,
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
Very definitely. My Ross HD satellite box, with its cheap and cheerful
Chinese chipset, doesn't have any qualms about recording HD material to
memory stick, or USB HDD with adaptor/caddy, in a format that can be
transferred to a PC. Since it uses FAT 32, however, the files are saved
in 2GB chunks, which may be inconvenient especially for HD. A better
bet might be the Xoro satellite box, which can use NTFS format disks,
but you may need a conversion program to make the files playable. I use
mpeg Streamclip to edit SD material, and it joins up the 2GB chunks, but
it doesn't work with HD...
Paul D Smith
< A better
> bet might be the Xoro satellite box, which can use NTFS format disks,
>
>
Can this write NTFS? Many boxes can read NTFS, but not write it.
Paul DS.
Paul - xxx
> On Mon, 10 Oct 2011 10:32:43 +0100, Jeff Layman
> <JMLa...@invalid.invalid> wrote as :
> My guess would be that the mfg. coys have to have pre-agreed to this
> together otherwise someone not agreeing to the knobbling would have an
> obvious market advantage!
Hmm, mums TV is a new Panasonic and she records via USB, either a stick
or more recently to a laptop HD on a USB cable so TV is now a PVR .. I
dunno if the copied TV shows and recordings can be copied further onto
a PC, but I can check this weekend!
I do know I just picked one of my USB sticks at random, used that and
it just worked .. same for the HD on a lead ..
I'll post back!
--
Paul - xxx
Una vita - vitate
Adrian C
> On Monday, October 10th, 2011 at 09:11:06h +0100, Charlie+ wrote:
>
>> It also insists on formatting the disk to its own file system which
>> cannot be used on a computer
>
> Please let us all stop using the Micro$oft incorrect use of the
> term "formatting".
>
No.
--
Adrian C
Paul - xxx
> On 10 Oct 2011 11:25:35 GMT, "Paul - xxx" <notchec...@hotmail.com>
> wrote as underneath my scribble :
> Thanks Paul that is more like the USB facility I would have liked!!
> Look forward to your trial! Perhaps you cd also let us all know the
> model No of her TV, Thanks C+
Can't remember off-hand, but it's got internet, satellite and HD,
freeview and HD, USB, SD, loads of connectivity and a damn fine picture
.. cost �500 (including a glass stand!) in an online sale and now up to
�749 ish .. with the stand at �84 ish .. ;)
We only just got her onto the internet last night with an old laptop of
ours, so won't go through again till Saturday at the earliest, but
whenever it is I'll post back.
Roger Mills
> I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
> find that this TV is VERY choosy as to what usb disk it will use and
> will not record to a USB stick at all
On a similar theme, does anyone know how to convert the .wtv files
created on my PC by Windows Media Center(sic) into something (XviD?)
which my Humax HDR-Fox T2 can understand, so that I can play them on my TV?
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.
Peter Duncanson
wrote:
>On 10/10/2011 09:11, Charlie+ wrote:
>> I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
>> find that this TV is VERY choosy as to what usb disk it will use and
>> will not record to a USB stick at all
><snip>
>
>On a similar theme, does anyone know how to convert the .wtv files
>created on my PC by Windows Media Center(sic) into something (XviD?)
>which my Humax HDR-Fox T2 can understand, so that I can play them on my TV?
I have no experience of that.
This forum discussion is from two years ago, but it might give a few
pointers:
http://www.sevenforums.com/media-center/2202-how-convert-wtv-files.html
A Google search for .wtv converter finds that and various other links.
--
Peter Duncanson
(in uk.tech.digital-tv)
J G Miller
> Thanks very much for the info JGM - I just looked up the AZbox (Southern
> Satellite) and it looks very well specified...but not el cheapo!
No it is not cheap because it is a full Linux box which does full 1080p
output. There are only one or two other satellite receivers which have
the hardware to do this, and not even the "Rolls Royce" of satellite brands
Dreambox does 1080p even though being 150 - 200% more expensive, depending
on the model.
You may also look at their new budget models which are in the process
of coming on to the market.
AZbox Me
<http://www.azbox.COM/index.php?id=46&tbl=registos&id2=14>
AZbox MiniMe
<http://www.azbox.COM/index.php?id=45&tbl=registos&id2=14>
> I understand it will playback all the things you say and more but will it
> actually allow you to export the files themselves in a playable form to
> a PC or Linux box?
The AZbox records the TV shows as an unencrypted transport stream file .ts
If recorded onto an internal disk you can either
1) telnet into the box and copy over to an external USB
2) setup samba server on the AZbox to allow your Windoze PC
to see the internal disk (or even the external disk) as
a SHARE
3) export the file system as an NFS share
4) setup an FTP server on the AZbox or telnet into the AZbox
and ftp the files back to an external FTP server
So it is more a case of what is more convenient for you to
transfer files -- GNU/Linux gives you that choice.
The downside of the AZbox is that the proprietary AZbox firmware
does not provide the best of user interfaces and does sometimes
crash when eg trying to fast forward and then suddenly go to
fast reverse on a video file.
However the "Rolls Royce" of satellite firmware, the Enigma II
firmware is being actively developed for the AZbox and over a 12
month period went from being a mere rumor to a full 1.0 release
version with most functionality and a third party media player
with enhanced features and visually sharp user interface was
also created.
Another alternative is the Technomate 800HD which is another
GNU/Linux receiver with full 1080p output and comes with
Enigma II from the manufacturer.
<http://www.technomate.COM/viewproduct2.php?product=126>
Only a link to product description, no endorsement of seller intended --
<http://www.satellitetv.IE/shop/index.php?controller=product&path=79&product_id=280>
This box was marred by the fact that on the initial sales run,
people had to return the box to the manufacturer to have the
first version of their firmware which had some serious defects replaced.
NB The AZbox HD and HD Premium comes with WiFi capability installed
whereas this is an optional add on purchase for the Technomate.
Also the AZbox has a slot for a second tuner -- either DVB-c, DVB-s2,
and DVB-t (maybe one day DVB-t2 will be available?), whereas the
Technomate has no expansion slot for a second tuner.
J G Miller
> No.
Obviously people like you who have been brainwashed
by Microsoft are incapable of using the correct terms.
J G Miller
> On a similar theme, does anyone know how to convert the .wtv files
> created on my PC by Windows Media Center(sic) into something (XviD?)
> which my Humax HDR-Fox T2 can understand, so that I can play them on my
> TV?
found by using a web search engine, amongst which
<http://www.youtube.COM/watch?v=1YxmYshPsP0>
John Legon
wrote in article <j6ukm2$ptp$1...@dont-email.me>:
Good question. The support for NTFS with the Xoro HRS 8520 is provided
through a firmware upgrade so it's not in the manual I've seen. The
notes for the upgrade mention being able to store the channel list on
NTFS and the recordings are apparently in chunks of 4GB instead of 2GB.
--
John L
Adrian C
No.
--
Adrian C
Peter Duncanson
wrote:
There is low-level formatting and there is high-level formatting.
High-level formatting is what a user can do using the "format" utilities
provided by OSes.
Low-level formatting, physical formatting, can not be done by a user,
therefore the qualifying phrase "high-level" is omitted from what the
user can do leaving just the word "format".
http://www.webopedia.com/TERM/L/LLF.html
LLF
(n.) Short for low-level format, a formatting method that creates
the tracks and sectors on a hard disk. Low-level formatting creates
the physical format that dictates where data is stored on the disk.
Also see high-level format.
Modern hard drives are low-level formatted at the factory for the
life of the drive.
http://www.webopedia.com/TERM/H/HLF.html
HLF
(n.) Short for high-level format, a formatting method that
initializes portions of the hard disk and creates the file system
structures on the disk, such as the master boot record and the file
allocation tables. Also see low-level format.
Brian Gaff
features are going in. for example could we in future have time expiry of
recordings?
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
Blind user, so no pictures please!
"Charlie+" <cha...@xxx.net> wrote in message
news:i7759759eq1h55mee...@4ax.com...
> find that this TV is VERY choosy as to what usb disk it will use and
> an interface eg any caddy type. It also insists on formatting the disk
> to its own file system which cannot be used on a computer, and is
> encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings - you would have to
> re-format the hdisk) .... all this is obviously done to prevent ANY
> transfer of HD recordings. There is a Component connection but it is TV
> input only - no output. The only output is SD from SCART.
> My guess is that all modern HD tVs are probably protecting HD recordings
> like this to prevent any transfer....Maybe part of the HDMI encryption
> standard licence?
> (the Panasonic model no is TXL32E30B (about £500) if this is of
> interest to others)!
>
Brian Gaff
thing is counter productive in the long run? If Icannot make a permanent
copy of something to look at when I like, I'm unlikely to bother with
watching it, at least that is waht people seem to suggest. Mind you with
some program material who cares!
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
Blind user, so no pictures please!
"Jeff Layman" <JMLa...@invalid.invalid> wrote in message
news:j6ue3r$ur5$1...@news.albasani.net...
Brian Gaff
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
Blind user, so no pictures please!
"Charlie+" <cha...@xxx.net> wrote in message
news:q8p597t8t497ovpa7...@4ax.com...
> On 10 Oct 2011 11:25:35 GMT, "Paul - xxx" <notchec...@hotmail.com>
> wrote as underneath my scribble :
>
Brian Gregory [UK]
news:33hjQHAm...@legon.demon.co.uk...
Why? I have a 300GB file on one of my external NTFS formatted HDs.
--
Brian Gregory. (In the UK)
n...@bgdsv.co.uk
To email me remove the letter vee.
Brian Gregory [UK]
news:hea6975g7lppmicqf...@4ax.com...
That's as I've understood the meanings.
Incidentally I quite regularly low level format things -- floppy disks.
Brian Gaff
convert to have screenreaders on them, since they use established operating
systems, not some cobbled together heap of bits and pieces as others do.
There is still no talking sat box or talking pvr.
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
Blind user, so no pictures please!
"J G Miller" <mil...@yoyo.ORG> wrote in message
news:j6v6pk$nfl$1...@dont-email.me...
Paul Ratcliffe
> If recorded onto an internal disk you can either
>
> 1) telnet into the box and copy over to an external USB
> 2) setup samba server on the AZbox to allow your Windoze PC
> to see the internal disk (or even the external disk) as
> a SHARE
> 3) export the file system as an NFS share
> 4) setup an FTP server on the AZbox or telnet into the AZbox
> and ftp the files back to an external FTP server
Oh dear JGM, you cannot use "either" with 4 options. You are only allowed 2.
Either X or Y. Obvious really. Loads of people make this mistake too.
Adrian C
> Shadows of regional dvds again. When will the industry realise this sort of
> thing is counter productive in the long run? If Icannot make a permanent
> copy of something to look at when I like, I'm unlikely to bother with
> watching it, at least that is waht people seem to suggest. Mind you with
> some program material who cares!
In the future Holywood will be allowed enhanced read/write access to
peoples brains. A short period after watching a film ya mind will be
wiped so ye can enjoy the experience of watching and paying for it again.
--
Adrian C
John Legon
> "John Legon" <jo...@nospam.demon.co.uk> wrote in message
> news:33hjQHAm...@legon.demon.co.uk...
>> At 12:24:48 Mon, 10 Oct 2011, Paul D Smith <paul_d...@hotmail.com>
>> wrote in article <j6ukm2$ptp$1...@dont-email.me>:
>>> ...snip...
>>>
>>> < A better
>>>> bet might be the Xoro satellite box, which can use NTFS format disks,
>>>>
>>>>
>>> Can this write NTFS? Many boxes can read NTFS, but not write it.
>> Good question. The support for NTFS with the Xoro HRS 8520 is provided
>> through a firmware upgrade so it's not in the manual I've seen. The
>> notes for the upgrade mention being able to store the channel list on
>> NTFS and the recordings are apparently in chunks of 4GB instead of 2GB.
>
> Why? I have a 300GB file on one of my external NTFS formatted HDs.
>
Die Teilung erfolgt nun ab 4GB, nicht mehr bei 2GB. Aus technischen
Gr�nden ist eine Aufhebung leider nicht m�glich!
Make of that what you will...
MikeS
>I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
> find that this TV is VERY choosy as to what usb disk it will use and
> will not record to a USB stick at all, or indeed any USB disk that has
> an interface eg any caddy type. It also insists on formatting the disk
> to its own file system which cannot be used on a computer, and is
> encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings - you would have to
> re-format the hdisk) .... all this is obviously done to prevent ANY
> transfer of HD recordings. There is a Component connection but it is TV
> input only - no output. The only output is SD from SCART.
> My guess is that all modern HD tVs are probably protecting HD recordings
> like this to prevent any transfer....Maybe part of the HDMI encryption
> standard licence?
> (the Panasonic model no is TXL32E30B (about �500) if this is of
> interest to others)!
>
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
You can connect any USB stick or drive formatted with FAT32 and PLAY a
modest range of files. If you want to use the PVR function you need to
register a different stick or disk. Provided this is > 160GB (at least on
older TVs) the disk is formatted in UFS2 format. This disk can be mounted on
many Linux PCs including Ubuntu but as already stated does not achieve much
due to the encryption. The limitation to one non-repaired TV is annoying but
it did give me a very useful 2TB Freeview+Freesat PVR for �60.
J G Miller
> Oh dear JGM, you cannot use "either" with 4 options.
True.
I shall slap myself with a wet halibut as a form of
punishment to try and instill a memory to never do it again.
Probably what went wrong was I was thinking you can do either
of two options A or B. And then I realized there was a third
options so it was A or B or C, no make that four options ...
But then again, nobody expects the Spanish Inquisition.
Brian Gregory [UK]
So it's "technical reasons".
A very useful phrase for explaining something you don't want to explain.
John Rumm
> "John Legon"<jo...@nospam.demon.co.uk> wrote in message
> news:GfudnSysG8En1w7T...@brightview.co.uk...
>> Brian Gregory [UK] wrote:
>>> "John Legon"<jo...@nospam.demon.co.uk> wrote in message
>>> news:33hjQHAm...@legon.demon.co.uk...
>>>> At 12:24:48 Mon, 10 Oct 2011, Paul D Smith<paul_d...@hotmail.com>
>>>> wrote in article<j6ukm2$ptp$1...@dont-email.me>:
>>>>> ...snip...
>>>>>
>>>>> < A better
>>>>>> bet might be the Xoro satellite box, which can use NTFS format disks,
>>>>>>
>>>>>>
>>>>> Can this write NTFS? Many boxes can read NTFS, but not write it.
>>>> Good question. The support for NTFS with the Xoro HRS 8520 is provided
>>>> through a firmware upgrade so it's not in the manual I've seen. The
>>>> notes for the upgrade mention being able to store the channel list on
>>>> NTFS and the recordings are apparently in chunks of 4GB instead of 2GB.
>>>
>>> Why? I have a 300GB file on one of my external NTFS formatted HDs.
>>>
>> Quote:
>>
>> Die Teilung erfolgt nun ab 4GB, nicht mehr bei 2GB. Aus technischen
>> Gr�nden ist eine Aufhebung leider nicht m�glich!
>>
>> Make of that what you will...
>
> So it's "technical reasons".
>
> A very useful phrase for explaining something you don't want to explain.
Roughly translated, the code uses 32 bit integer pointers... sometimes
signed 32 bit giving a 2GB limit, and sometimes a unsigned, giving 4GB.
--
Cheers,
John.
/=================================================================\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\=================================================================/
John Rumm
> On Monday, October 10th, 2011 at 09:11:06h +0100, Charlie+ wrote:
>
>
> Please let us all stop using the Micro$oft incorrect use of the
> term "formatting".
>
> done by the disk manufacturer.
To borrow the phrase from Wolfgang Pauli: that's not even wrong...
Formatting *can* be a low level operation, and can done by the disk
manufacturer, but it is also sometimes done by the user and also
sometimes a higher level activity.
In the case of floppy disks, low and high level formatting is usually
done at the same time by the user with an OS utility. Some also have the
option of skipping the low level phase and doing a "quick" (i.e. high
level only) format.
Hard drives from antiquity (i.e. we are talking ST506 vintage drives on
MFM/RLL controllers here) - required two (or three depending on what you
count) different formats: low and high level. Typically a utility
specific to the disk drive or controller would accomplish the former (or
a BIOS routine in the case of a IBM PC), and the OS format command the
latter. The user could carry out a low level format themselves.
From the advent of IDE/SCSI drives onward, they were usually provided
pre low level formatted by the OEM, and would typically ignore attempts
to redo the low level format (or in some cases even be rendered useless
by such an attempt). However a higher level activity would still be
required to lay out the data structures required for organisation of
data on the drive including the partitions and the particular file
systems to be used on each. It is entirely appropriate to also describe
this as "formatting".
Flash based storage, obviously has no requirement for traditional low
level formatting at all - done by either the OEM or the user.
(now if you want to rail against the incorrect use of the term 1.44MB
floppy disk by MS, then be my guest!)
Andy Burns
> Hard drives from antiquity (i.e. we are talking ST506 vintage drives on
> MFM/RLL controllers here) - required two (or three depending on what you
> count) different formats: low and high level. Typically a utility
> specific to the disk drive or controller would accomplish the former (or
> a BIOS routine in the case of a IBM PC
Ahhh, the good old
DEBUG.COM
G=C800:5
Paul D Smith
> Roughly translated, the code uses 32 bit integer pointers... sometimes
> signed 32 bit giving a 2GB limit, and sometimes a unsigned, giving 4GB.
read-only. NTFS is jealously guarded by Microsoft and most implementations
are based on either reverse engineering or as little as has slipped out from
Microsoft.
I've come across a number of read-only solutions, but writing means that you
have to leave the disk is exactly the state that microsoft would, and if you
don't know what that is...
Paul DS.
Paul Cummins
Smith) came up to me and whispered:
> I've come across a number of read-only solutions, but writing means
> that you have to leave the disk is exactly the state that microsoft
> would, and if you don't know what that is...
Linux seems to manage quite well...
--
Paul Cummins - Always a NetHead
Wasting Bandwidth since 1981
---- If it's below this line, I didn't write it ----
John Legon
From what I've read it seems that the Xoro will record to NTFS media,
and the 4GB chunk size is a limitation of the firmware not the filing
system. Since the box sells for about �65 it wouldn't be too much of a
gamble to buy one, but I've been put off by the poor channel editor
which means that it takes forever to organize the channel list after a
scan. IIRC editing the transponder data etc is also problematical.
J G Miller
> In the case of floppy disks, low and high level formatting is usually
> done at the same time by the user with an OS utility. Some also have the
> option of skipping the low level phase and doing a "quick" (i.e. high
> level only) format.
>
> Hard drives from antiquity (i.e. we are talking ST506 vintage drives on
> MFM/RLL controllers here) - required two (or three depending on what you
> count) different formats: low and high level. Typically a utility
> specific to the disk drive or controller would accomplish the former (or
> a BIOS routine in the case of a IBM PC), and the OS format command the
> latter. The user could carry out a low level format themselves.
>
> From the advent of IDE/SCSI drives onward, they were usually provided
> pre low level formatted by the OEM, and would typically ignore attempts
> to redo the low level format (or in some cases even be rendered useless
> by such an attempt). However a higher level activity would still be
> required to lay out the data structures required for organisation of
> data on the drive including the partitions and the particular file
> systems to be used on each. It is entirely appropriate to also describe
> this as "formatting".
>
> Flash based storage, obviously has no requirement for traditional low
> level formatting at all - done by either the OEM or the user.
>
> (now if you want to rail against the incorrect use of the term 1.44MB
> floppy disk by MS, then be my guest!)
a modern USB 2.0 disk which was under discussion and to which the
term "formatting" was being applied?
Paul D Smith
news:memo.2011101...@postmaster.local.domain...
> We were about to embark at Dover, when paul_d...@hotmail.com (Paul D
> Smith) came up to me and whispered:
>
>> I've come across a number of read-only solutions, but writing means
>> that you have to leave the disk is exactly the state that microsoft
>> would, and if you don't know what that is...
>
> Linux seems to manage quite well...
Interesting. I thought Linux was read-only. That's particularly
interesting because the Humax PVR, which is Linux based, can specifically
only read NTFS. Seems an odd restriction if they're using the standard
Linux drivers.
Paul DS
Roger Mills
> On Monday, October 10th, 2011 14:07:52 +0100, Roger Mills asked:
>
>> On a similar theme, does anyone know how to convert the .wtv files
>> created on my PC by Windows Media Center(sic) into something (XviD?)
>> which my Humax HDR-Fox T2 can understand, so that I can play them on my
>> TV?
>
> Yes somebody does know and numerous replies to this question can be
> found by using a web search engine, amongst which
>
> <http://www.youtube.COM/watch?v=1YxmYshPsP0>
>
Thanks for the link - it gets me half-way there! I *had* previously
Googled, and had found links saying that it was a two-stage process -
going via dvr-ms. I had even downloaded a program to convert from wtv to
dvr-ms, but couldn't make it work. What I *hadn't* realised was that
this feature was built into WMC!
So, using WMC's built-in conversion facility, I have now converted a
file to dvr-ms - so far so good, except that the youtube clip suggests
that the dvr-ms file will be approx the same size as the wtv original -
but my file is only *half* the size. Does this matter?
As per the youtube clip, I have downloaded Format Factory. However, it
appears to be able to convert into a number of formats - AVI, MOV, MPG,
etc.- but no mention of XviD! Where do I go from here?
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.
Rick
"Charlie+" <cha...@xxx.net> wrote in message
news:i7759759eq1h55mee...@4ax.com...
>I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
> find that this TV is VERY choosy as to what usb disk it will use and
> will not record to a USB stick at all, or indeed any USB disk that has
> an interface eg any caddy type. It also insists on formatting the disk
> to its own file system which cannot be used on a computer, and is
> encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings - you would have to
> re-format the hdisk) .... all this is obviously done to prevent ANY
> transfer of HD recordings. There is a Component connection but it is TV
> input only - no output. The only output is SD from SCART.
> My guess is that all modern HD tVs are probably protecting HD recordings
> like this to prevent any transfer....Maybe part of the HDMI encryption
> standard licence?
> (the Panasonic model no is TXL32E30B (about �500) if this is of
> interest to others)!
>
> Im also interested in a (non Sky) HD satellite receiver eg Technomate,
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
>
I have a Technomate 5420 HD satellite receiver with USB record facility, as
has my Fox DVB-T2 Freeview reciever.
They are both fitted with 500 GB 2.5 inch hard drives, which for some reason
can only be seen by the respective receivers and not a PC, however if I
record a program on the Technomate box using a USB flash drive the .trp
files will play perfectly OK on the Humax box and can be displayed and
converted to quite a large number of different formats on my PC using a
program called Tipard TRP converter, which you can download to test and can
be bought for about �12.00 + vat.
This morning I recorded the BBC HD the test card, converted it to the Divx
HD format using the aforementioned programme, a screen grab here.
Java Jive
remembering, Linux could only read NTFS safely, not write to it.
However, modern distros, such as recent Ubuntu, can read and write
NTFS perfectly well.
There are, however, a couple of catches ...
Firstly, when writing to the disk under Linux, you have to make sure
that you do not create or rename a file to differ only by case from an
existing filename. Linux will create the new file without any
problems, but if you subsequently notice this under Windows, and
attempt to delete one of the files, BOTH will be deleted.
Differing versions of Windows use differing versions of NTFS. I have
not had any other problem, besides the above, subsequently using such
disks under Windows 2000/XP, but haven't tested more recent versions,
such as W7, and it's theoretically possible that they might throw a
wobbly.
On Tue, 11 Oct 2011 11:16:46 +0100, "Paul D Smith"
<paul_d...@hotmail.com> wrote:
>
> "Paul Cummins" <uset...@stedtelephone.invalid> wrote in message
> >
> > Linux seems to manage quite well...
>
> Interesting. I thought Linux was read-only.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Andy Burns
> "Paul Cummins" <uset...@stedtelephone.invalid> wrote:
>
>> Linux seems to manage quite well...
>
> Interesting. I thought Linux was read-only.
The in-kernel NTFS drivers are read only, the NTFS-3G drivers use FUSE
(user-space rather than kernel) and can read, write, resize etc, I've
never had a peep of trouble from them, they do leave checking for and
fixing corruption to Windows itself, which is probably a safe bet.
Adrian C
> On 10/10/2011 11:48, J G Miller wrote:
>> On Monday, October 10th, 2011 at 09:11:06h +0100, Charlie+ wrote:
>>
>>> It also insists on formatting the disk to its own file system which
>>> cannot be used on a computer
>>
>> Please let us all stop using the Micro$oft incorrect use of the
>> term "formatting".
>>
>> Formatting is a low level operation only usually
>> done by the disk manufacturer.
>
> To borrow the phrase from Wolfgang Pauli: that's not even wrong...
>
> Formatting *can* be a low level operation, and can done by the disk
> manufacturer, but it is also sometimes done by the user and also
> sometimes a higher level activity.
>
> In the case of floppy disks, low and high level formatting is usually
> done at the same time by the user with an OS utility. Some also have the
> option of skipping the low level phase and doing a "quick" (i.e. high
> level only) format.
I've come across hard sectored floppy discs, 8 inch with many holes
peppered for the opto wotsit near the spindle centre. Presumably only a
high level format needed for these to create a blank catalog / table of
contents?
So, what was that disc operation generically called then? This was
before Microsoft, in the land of CP/M or suchlike.
>
> (now if you want to rail against the incorrect use of the term 1.44MB
> floppy disk by MS, then be my guest!)
>
Oh, he's off his rails. I think JGM's a Dalek of some sort. I suggest
new names for his distributions.
Dalek Linux - exterminate MS
or, Orwellian Linux - Rewrite 'incorrect' history... ;-)
--
Adrian C (Linux & MS user)
Michael Chare
>
> Im also interested in a (non Sky) HD satellite receiver eg Technomate,
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
I have recently bought an Xtrend (Clarke Tech) ET9000, to which I fitted
a 2GB Samsung hard disk. I run VIX which is UK supported.
The ET9000 can read the Freesat and various other EPGs.
I am not aware of any encryption of recorded files. If I click on one of
the HD recordings with my PC I can view it with Windows Media Player (or
VLC).
I have not tried recording to a USB device but no doubt it would work to
a USB hard disk. I have recorded to my NAS.
There are two USB ports on the back and one on the front.
See http://www.world-of-satellite.com
The Vu+ Duo is a slightly inferior alternative. (From what I have read.)
Linux boxes have the advantage that they offer more opportunity to adapt
them to your own requirements.
I can select UK (and foreign) programmes to record from the EPG. There
is no series link, but recordings can be scheduled on the basis of
programme name. (Similar to the Jags Tap on the Toppy)
My newish Samsung TV refused to record to a USB stick. I don't think
that it could write fast enough. I don't own a USB hard drive so I have
not tried one.
--
Michael Chare
Rick
"Charlie+" <cha...@xxx.net> wrote in message
news:i7759759eq1h55mee...@4ax.com...
>I baught a 32" Panasonic TV recently, it has PVR over USB facility - I
> find that this TV is VERY choosy as to what usb disk it will use and
> will not record to a USB stick at all, or indeed any USB disk that has
> an interface eg any caddy type. It also insists on formatting the disk
> to its own file system which cannot be used on a computer, and is
> encrypted to this single TV ( if the TV goes for repair - you cannot
> even play your previously made USB recordings - you would have to
> re-format the hdisk) .... all this is obviously done to prevent ANY
> transfer of HD recordings. There is a Component connection but it is TV
> input only - no output. The only output is SD from SCART.
> My guess is that all modern HD tVs are probably protecting HD recordings
> like this to prevent any transfer....Maybe part of the HDMI encryption
> standard licence?
> (the Panasonic model no is TXL32E30B (about �500) if this is of
> interest to others)!
>
> Icecrypt etc, and interested in the ones with a more friendly USB PVR
> facility, does anyone here have an idea if any of this type of Sat
> reciever will allow computer readable files in case you want to transfer
> anything to DVD, edit out adverts etc. ? Thanks
>
I have a Technomate 5420 HD satellite receiver with USB record facility, as
MikeS
> It does say in the manual somwhere that a stick (ie. USB powered) cannot
> be used for the PVR function... so effectively it is separately
> powered HDisks only that will work for the PVR function and then only
> through the rear USB port... we havnt been talking about what files the
> TV will Play from a stick but the list in the manual seems to be fairly
> comprehensive!....C+
The manuals are not very precise. My 2010 model says "This TV supports USB
HDD with capacity from 160 GB up to 2 TB". If you could find a stick > 160GB
I doubt the TV would know the difference. Likewise my manual implies you can
only play back your own media files from an SD card or a USB flash drive:
"Media Player allows you to enjoy photo, video or music recorded on an SD
Card and a USB Flash Memory, and recorded contents on the registered USB
HDD".
However, as I noted it also plays back from a NON registered FAT32 HDD. I
use a powered 3.5" HDD for recording but two self-powered FAT32 2.5" HDDs
work OK for playback, even of videos.
Re your other point, I think you will find that not all video files are
created equal and that many versions of file formats listed in the manual
will not play correctly. Anything recorded on Panasonic cameras will be OK
but beyond that you may need to convert some types (eg .avi videos from my
Canon camera will not play directly).
J G Miller
> What I *hadn't* realised was that this feature was built into WMC!
Sometimes features are buried under non obvious menu items, so unless
you know where the item is located, it can be awkward to find.
> Does this matter?
Do you have gspot? Does that work with these file formats?
<http://www.headbands.com/gspot/>
If it does, then run it on both, and compare the lengths and
properties (resolution, bit rate etc).
> As per the youtube clip, I have downloaded Format Factory. However, it
> appears to be able to convert into a number of formats - AVI, MOV, MPG,
> etc.- but no mention of XviD! Where do I go from here?
You need to be aware that for multimedia formats there are two main
issues -- containers and codecs.
AVI, MOV, and MPG are file format containers.
The type of file format container determines what type of encoded
multimedia content can be stored within.
MOV (proprietary to Apple) files can contain audio or video encoded
with Apple's proprietary Quicktime format.
AVI (proprietary to Miscrosoft) files can contain audio or video encoded
with a variety of codecs.
WTV and DVR-MS (Microsoft Digital Video Recording) are a proprietary video
and audio file container format.
See comparison at
<http://en.wikipedia.ORG/wiki/Comparison_of_container_formats>
XviD is the free open source video codec library following the MPEG-4 standard,
specifically MPEG-4 Part 2, which started as the project openDivX sponsored by
DivX but was subsequently closed down, and it is now the well established competitor
to DivX.
From what I understand (corrections invited) the WTV and DVR-MS containers
from a TV recording will contain the MPEG-2 video stream data.
So to play on a Humax HDR-Fox T2 player, the question is what container formats
does it support? If if does not support DVR-MS then you need to extract the
MPEG-2 video stream data and simply up it into an MPEG-2 or even just .ts
(transport stream) format file.
If you want to reduce the size of the file (by lossy encoding and reduce picture
quality to a degree) then you must encode the MPEG-2 data stream eg with XviD
and then store the resultant smaller encoded data in a suitable container eg
avi or mkv.
Some boxes such as the Fox T2 may only support certain combinations of codecs
and containers and not the full range for which containers can be used, so
consulting your manual is essential, but XVid + avi should be okay.
Believe it or not, but some early media players eg Iomega Screenplay Pro
model would play Divx in avi, but not XVid in avi.
Now I thought that the YouTube Video which I located
"Convert .WTV files to AVI, MP4 and Other Video File Formats"
actually explained how to convert WTV files not just to DVR-MS
format but to AVI (with the appropriate codec).
A simple web search also reveals this link to free software
"WTV to AVI Converter"
<http://download.cnet.COM/WTV-to-AVI-Converter/3000-2194_4-10969083.html>
J G Miller
> My newish Samsung TV refused to record to a USB stick.
Was the file system on the USB memory stick was FAT32?
Did the Samsung TV when prompted to record, ask you for
permission to replace the FAT32 with an XFS file system?
This is what happens when you connect a USB hard disk
with a non-XFS file system to a Samsung TV and press record
or pause live TV.
Rick
> On Tue, 11 Oct 2011 14:35:15 +0100, "Rick" <ri...@nowhere.com> wrote as
> underneath my scribble :
> I am assuming you can transfer a file ok from the hard disk in either
> machine to the USB stick which preumably is formatted FAT 32 etc or is
> the USB file system Linux too? C+
>
As far as I can gather the format is EXT3, be warned however that Humax has
fixed the Fox so that it will only 'play' recordings via a USB stick and
will not record even if you actually manage to re-format it in the Fox-T2
itself, whilst theTechnomate has absolutely no problems and will allow you
to plug your USB stick into a PC and play about with the files.
Rick
> On Tue, 11 Oct 2011 16:47:20 +0100, Charlie+ <cha...@xxx.net> wrote as
> underneath my scribble :
>
>>On Tue, 11 Oct 2011 16:42:35 +0100, "Rick" <ri...@nowhere.com> wrote as
>>...C+
> PS Do you mean TM5402 or did you really mean TM 5240 as you said!!
> Southern Sats do Technomate TM5402 HD Super + With LAN £139 ...C+
>
'Techno mate TM5402 HD Super', that's the one, for some reason I always
remember numbers in the wrong order, even if I have to write them down a few
seconds later, perhaps I'm dyslexic :-)
Michael Chare
>
> Re your other point, I think you will find that not all video files are
> created equal and that many versions of file formats listed in the manual
> will not play correctly.
>
So I have found! Particularly with .ts format files :-(
--
Michael Chare
Deri James
> Firstly, when writing to the disk under Linux, you have to make sure
> that you do not create or rename a file to differ only by case from an
> existing filename. Linux will create the new file without any
> problems, but if you subsequently notice this under Windows, and
> attempt to delete one of the files, BOTH will be deleted.
>
which will stop you being able to create files which have the same name
under windows.
Cheers
Deri
J G Miller
> Im not sure how Linux based receivers do in the hands of those like
> me who normally dont use Linux at all except when Windoze needs a
> hand from a bootable DVD system! C+
Well ask yourself, how do Samsung TVs or SONY Bravia TVs do in the
hands of those who do not use computers at all?
(NB Samsung TVs and SONY Bravia TVs run on GNU/Linux plus some
proprietary software.)
Andy Champ
> I've come across hard sectored floppy discs, 8 inch with many holes
> peppered for the opto wotsit near the spindle centre. Presumably only a
> high level format needed for these to create a blank catalog / table of
> contents?
>
I'll be surprised. I never used them, so I can't be sure, but
formatting a soft-sectored floppy meant writing data with the
head/cyl/sector number for every sector on the disc, and writing other
data for the data part. Special patterns that cannot occur in data are
written around the sector ID and data fields, and there are carefully
calculated gaps between the different fields. The ID fields are written
on formatting, and only the data fields as the disc is used. Together
BTW with some of the gap and the special pattern bit. Because the clock
never quite lined up you get a "write splice" (clock glitch) where the
writing of the data sectors starts and ended - so the first bit of the
data written has to be a clock recovery pattern.
> So, what was that disc operation generically called then? This was
> before Microsoft, in the land of CP/M or suchlike.
CP/M's high level format consisted of writing E5 in every byte of the
disc. I did this as I wrote out all the other crud.
Next question: Why can't I forget this to make room for something more
useful? I don't even own a working floppy drive!
Andy
Rick
> On Tue, 11 Oct 2011 16:42:35 +0100, "Rick" <ri...@nowhere.com> wrote as
>
(haven't yet tried it with the Fox T2) if you haven't already got it,
download Ubuntu (I assume that Mint will work just as well) and copy it as
an iso onto a DVD disc, boot it up and the Ubuntu OS will now display the
formerly unrecognised attached USB hard drive, simply copy and paste the
.trp files you want into a folder on the also displayed main drive and
reboot the PC back into Windows, select the folder that you have saved the
files into when using Tipard and Bob's your uncle.
J G Miller
> I've found a way around Windows not recognizing the Technomate 2.5inch
If the file system on the disk really is ext3, then why not try this?
Of course if one tries out Ubuntu, there is a danger that one may not
want to boot back into Windoze, since once can do any media file conversion
for free using mencoder without having to pay for proprietary software
such as Tipard.
Rick
"J G Miller" <mil...@yoyo.ORG> wrote in message
news:j728mf$p11$2...@dont-email.me...
Won't run in Windoze seven.
J G Miller
> Won't run in Windoze seven.
Will this? <http://www.diskinternals.COM/linux-reader/>
Of course the other possibility is just to put the USB disk on
your GNU/Linux network server and then just access the
disk contents via CIFS network share.
Johny B Good
> On Tuesday, October 11th, 2011 at 21:15:22h +0100, Rick wrote:
>
>> I've found a way around Windows not recognizing the Technomate 2.5inch
>
> If the file system on the disk really is ext3, then why not try this?
>
> <http://www.fs-driver.org/>
can forget the IFS applet to assign/de-assign drive letters - just do it
from diskmanager like you do for FAT and NTFS disk volumes).
--
Regards JB Good
John Rumm
> John Rumm wrote:
>
>> Hard drives from antiquity (i.e. we are talking ST506 vintage drives on
>> MFM/RLL controllers here) - required two (or three depending on what you
>> count) different formats: low and high level. Typically a utility
>> specific to the disk drive or controller would accomplish the former (or
>> a BIOS routine in the case of a IBM PC
>
> Ahhh, the good old
>
> DEBUG.COM
> G=C800:5
That would be the one ;-)
(although there was often a "utility" supplied to call that for you
without needing debug!)
(a utility so complex I suspect I could write the binary for it with
nothing more sophisticated than "copy con: llform.com")
--
Cheers,
John.
/=================================================================\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\=================================================================/
John Rumm
> On Tuesday, October 11th, 2011 at 05:51:27h +0100, John Rumm explained:
>
>> In the case of floppy disks, low and high level formatting is usually
>> done at the same time by the user with an OS utility. Some also have the
>> option of skipping the low level phase and doing a "quick" (i.e. high
>> level only) format.
>>
>> MFM/RLL controllers here) - required two (or three depending on what you
>> count) different formats: low and high level. Typically a utility
>> specific to the disk drive or controller would accomplish the former (or
>> latter. The user could carry out a low level format themselves.
>>
>> From the advent of IDE/SCSI drives onward, they were usually provided
>> pre low level formatted by the OEM, and would typically ignore attempts
>> to redo the low level format (or in some cases even be rendered useless
>> by such an attempt). However a higher level activity would still be
>> required to lay out the data structures required for organisation of
>> data on the drive including the partitions and the particular file
>> systems to be used on each. It is entirely appropriate to also describe
>> this as "formatting".
>>
>> Flash based storage, obviously has no requirement for traditional low
>> level formatting at all - done by either the OEM or the user.
>>
>> (now if you want to rail against the incorrect use of the term 1.44MB
>> floppy disk by MS, then be my guest!)
>
> a modern USB 2.0 disk which was under discussion and to which the
> term "formatting" was being applied?
Well someone asked:
"Please let us all stop using the Micro$oft incorrect use of the
term "formatting"."
Which contained the implied assumption that the term formatting was
inappropriate for the process of laying out data structures of a file
system on a disk. So I was illustrating why this assumption was incorrect.
They then went on to claim: "Formatting is a low level operation only
usually done by the disk manufacturer.", which is also incorrect, and I
demonstrated why this is so, by giving some counter examples.
HTH
John Rumm
> On 11/10/2011 12:45, Adrian C wrote:
>> I've come across hard sectored floppy discs, 8 inch with many holes
>> peppered for the opto wotsit near the spindle centre. Presumably only a
>> high level format needed for these to create a blank catalog / table of
>> contents?
>>
>
> I'll be surprised. I never used them, so I can't be sure, but formatting
> a soft-sectored floppy meant writing data with the head/cyl/sector
> number for every sector on the disc, and writing other data for the data
> part. Special patterns that cannot occur in data are written around the
> sector ID and data fields, and there are carefully calculated gaps
> between the different fields. The ID fields are written on formatting,
> and only the data fields as the disc is used. Together BTW with some of
> the gap and the special pattern bit. Because the clock never quite lined
> up you get a "write splice" (clock glitch) where the writing of the data
> sectors starts and ended - so the first bit of the data written has to
> be a clock recovery pattern.
Yup, that matches my recall as well. The soft sectored disks had a
single index hole that could be used to establish a track starting
point. Having said that, many drives ignored that anyway, and relied on
correlating the sync pattern in the format to establish position. (some
like the Amiga floppy FS, would use the blitter to read and write whole
tracks at a time, thereby negating the need to even bother with track to
track sector alignment, and eliminating write latency).
Hard sectored floppies were still available when I first started buying
them (early '80s, in the days where one bought one floppy at a time!),
but it was rare to find a drive that used them. IIRC they normally had
11 index holes - one for each sector start position, and one start of
track index. (they did usually work in soft sector drives however)
>> So, what was that disc operation generically called then? This was
>> before Microsoft, in the land of CP/M or suchlike.
Not unexpectedly it was called "FORMAT". Needless to say Tim Patterson
borrowed this for his CP/M 86 workalike clone called QDOS (Quick n Dirty
Operating System) which a certain Mr Gates and co licensed and
eventually acquired outright to turn into PC/MS-DOS, hence the
continuation into MS terminology.
> CP/M's high level format consisted of writing E5 in every byte of the
> disc. I did this as I wrote out all the other crud.
>
> Next question: Why can't I forget this to make room for something more
> useful? I don't even own a working floppy drive!
Astounding the old crap one can remember... often at the expense of
forgetting what you are supposed to be doing tomorrow it seems to me! ;-)
J G Miller
> Which contained the implied assumption that the term formatting was
> inappropriate for the process of laying out data structures of a file
> system on a disk. So I was illustrating why this assumption was
> incorrect.
file systems on a disk (note disk and not floppy diskette)
it is a correct assumption to make.
NAME
mke2fs - create an ext2/ext3/ext4 filesystem
NAME
mkfs.xfs - construct an XFS filesystem
NAME
mkntfs - create an NTFS file system
NAME
mkdosfs - create an MS-DOS file system under Linux
Whereas
NAME
fdformat - Low-level formats a floppy disk
Why do you think the name of the utilities are mkfs (make file system)
rather than fdfs (format file system) as is the case for floppy diskettes?
Java Jive
(ls), while to 'list' the contents of a file you 'catalog' (cat) it.
Come off it, JGM, there is only the most tenuous logic to the naming
of Linux commands at the best of times. On this issue, I'm afraid
you're being a pedantic PITA.
On Wed, 12 Oct 2011 00:50:58 +0000 (UTC), J G Miller <mil...@yoyo.ORG>
wrote:
> Why do you think the name of the utilities are mkfs (make file system)
> rather than fdfs (format file system) as is the case for floppy diskettes?
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Java Jive
<see.my.s...@nowhere.null> wrote:
>
> Yup, that matches my recall as well.
And mine.
I wrote a disk utility for the Amstrad CPC series. It could format,
copy disks, copy files, etc. Also, a number of software publishers,
particularly of games, used to release their stuff on disks that would
fail with the normal disk copy programmes, which meant that you only
had one copy, and you know how unreliable floppies were and still are!
However, my utility could copy all of the ones I tried.
One standard trick employed was to use non-sequential sector numbers,
but all a utility had to do was try to and read the next sector it
expected, and if/when that failed, try all the other possible sector
numbers that hadn't yet been tried. Another common trick was simply
not to format one of the tracks, and ensure that this was before or in
the middle of the tracks holding the software, but all you had to do
was keep going after the error track, rather than giving up. However,
at least one tried to read the unformatted track, so you had to be
careful that the destination disk wasn't formatted already.
The real bummer on that machine was the 3" drive. It meant that to
rescue all my work off it when I upgraded to a PC, I had to get a
second drive, devise a dual-format and write a PC program that could
read and write the dual-format.
>The soft sectored disks had a
> single index hole that could be used to establish a track starting
> point.
Yes.
> Having said that, many drives ignored that anyway, and relied on
> correlating the sync pattern in the format to establish position. (some
> like the Amiga floppy FS, would use the blitter to read and write whole
> tracks at a time, thereby negating the need to even bother with track to
> track sector alignment, and eliminating write latency).
By the time I'd finished struggling to get my data off my CBM8096, I
was deeply anti-Commodore!
I don't definitely recall doing anything with Amiga disks, though, at
the school I worked at for a while, some kids would do their homework
on whatever seemed to have the same disks at home, Ataris and Amigas
were the usual culprits, and then find they couldn't hand it in,
because the PCs wouldn't read the disks. I have a feeling that I
probably copied stuff off some Amiga disks somehow, but have no
definite recollection.
But I definitely remember doing it for Ataris. IIRC, the way with
Ataris was to format the floppy in the PC, not the Atari. The Atari
could read and write to a PC-formatted 720Kb floppy quite happily, but
the other way round wouldn't work. I think I concluded that the Atari
assumed the disk was 720Kb, so didn't put down some of the info in the
first sector that the PC needed to know which size disk was in the
drive.
AIR, BBC floppies couldn't be read by anything else around at the time
without a special program. It used the same low-level format -
sector sizes, etc - but the high-level format was so different that
nothing else would read it natively.
> Not unexpectedly it was called "FORMAT". Needless to say Tim Patterson
> borrowed this for his CP/M 86 workalike clone called QDOS (Quick n Dirty
> Operating System) which a certain Mr Gates and co licensed and
> eventually acquired outright to turn into PC/MS-DOS, hence the
> continuation into MS terminology.
And it was never quick but always dirty ...
> > CP/M's high level format consisted of writing E5 in every byte of the
> > disc. I did this as I wrote out all the other crud.
Yes. Floppies were (presumably still are) formatted one track at a
time, looping through from Track 0 to the highest one, 39 or 79,
depending on the capacity of the disk. The floppy controller chip
(OOTTOMH a uPD765A?) expected a value for the filler byte as part of
the command string sent to it to format a track. The value of the
filler byte tended to vary with the OS doing the formatting: CP/M was
E5, MSDOS I think was F6, etc.
> > Next question: Why can't I forget this to make room for something more
> > useful? I don't even own a working floppy drive!
I find that life is like that generally.
The musical instrument I picked up most recently is the flute, but due
to ill-health, I've not really been able, and certainly have had no
motivation, to play much recently. When I do have a go, it's
initially like relearning it all over again. By contrast, when I pick
up a guitar, which I started to play in my late teens, although I'm
hampered by no longer having callouses on my left-hand fingertips,
it's a lot quicker getting to sound musical. When I pick up a
whistle, which I learnt to play in childhood, I can sound pretty good
almost straightaway.
> Astounding the old crap one can remember... often at the expense of
> forgetting what you are supposed to be doing tomorrow it seems to me! ;-)
Yes.
Roderick Stewart
wrote:
> CP/M's high level format consisted of writing E5 in every byte of the
> disc. I did this as I wrote out all the other crud.
>
> Next question: Why can't I forget this to make room for something more
> useful? I don't even own a working floppy drive!
Same reason I can't forget the pinouts for an HL2 triode valve...
Rod.
--
Virtual Access V6.3 free usenet/email software from
http://sourceforge.net/projects/virtual-access/
John Legon
> But I definitely remember doing it for Ataris. IIRC, the way with
> Ataris was to format the floppy in the PC, not the Atari. The Atari
> could read and write to a PC-formatted 720Kb floppy quite happily, but
> the other way round wouldn't work. I think I concluded that the Atari
> assumed the disk was 720Kb, so didn't put down some of the info in the
> first sector that the PC needed to know which size disk was in the
> drive.
Actually, the Atari formatted disks could be made readable on a PC by
changing the first three bytes in the boot sector to EB 34 90 - which is
an Intel 808x short jump instruction to some executable code. On the
Atari disks those bytes were a Motorola 68k op code, but thankfully I
can't remember what they were. Just more useless information...
Michael Chare
"J G Miller" <mil...@yoyo.ORG> wrote in message
news:j71ib0$cc5$2...@dont-email.me...
presume).
The TV asked to format the stick to VFAT, and then formatted the stick with
XFS
Now it says that the stick does have adequate performance.
I tried to copy a file to the stick using Ubuntu on my PC but I have
encountered a permissions problem!
I don't have a USB hard drive.
Michael Chare
J G Miller
> Now it says that the stick does have adequate performance.
> I tried to copy a file to the stick using Ubuntu on my PC but I have
> encountered a permissions problem!
operation as root.
When you plug in the stick, check with dmesg that the device is seen,
to get the device number associated with the file system on the stick,
probably /dev/sdg1.
If needed, as root, manually mount the stick to some directory
eg
mkdir /mnt/usb
mount -t xfs /dev/sdg1 /mnt/usb
You can change the file system on the USB to ntfs with mkntfs
or to FAT32 with mkdosfs
Do not forget to use fdisk to change the file system type
in the partition table from Linux to NTFS or FAT32, but
the TV probably did not change the file system information
in the partition table from FAT32 to Linux (82) as it should
have done.
fdisk -l /dev/sdg1
to see current settings
Max Demian
news:I4adnTgU5bF17AjT...@brightview.co.uk...
without reloading it by running a zero length file called @.COM (or
similar).
--
Max Demian
Michael Chare
Thanks I have made a note.
--
Michael Chare
John Rumm
> On Wednesday, October 12th, 2011 at 00:50:22h +0100, John Rumm wrote:
>
>> Which contained the implied assumption that the term formatting was
>> inappropriate for the process of laying out data structures of a file
>> system on a disk. So I was illustrating why this assumption was
>> incorrect.
>
> In the context of creating ext2, ext3, ext4, FAT32, NTFS, UFS, XFS
> file systems on a disk (note disk and not floppy diskette)
> it is a correct assumption to make.
Only if you base your world view on the belief that the terminology used
in some flavours of *nix, is the one and only true and proper way.
It does not escape the reality that in order to fully
format/initialise/header/erase (choose your terminology based on OS) the
disk and use if for file storage and retrieval, there are various steps
that need to be accomplished. including laying out (or formatting as
many would say) the basic data structures of a file system. Different OS
vendors call these different things, and achieve them in a different
number of stages - sometimes they are all tied together in one, in
others they are embodied in separate executables that need running in
sequence.
Many use the term format - and this is certainly not a Microsoft only
thing. The fact that your preferred OS uses different terminology does
not make that the only "correct" terminology.
Note how in OS X one uses the Disk Utility application, and selects the
"file system" from the Volume Format selection box, before clicking the
"Erase" button. Does that mean the "correct" term is "erase"? VMS uses
the terminology INITIALIZE, is that the proper term? CP/M used FORMAT?
My old C128 used HEADER?
> Why do you think the name of the utilities are mkfs (make file system)
> rather than fdfs (format file system) as is the case for floppy diskettes?
Because that is what someone decided to call them. Since when have *nix
commands followed a consistent naming convention? For that matter why
bother to have separate commands to specify the file system? There are
plenty of other ways you could chose to allow the selection of a file
system.
John Rumm
> On Wed, 12 Oct 2011 01:21:20 +0100, John Rumm
> <see.my.s...@nowhere.null> wrote:
>>
>> Yup, that matches my recall as well.
>
> And mine.
>
> I wrote a disk utility for the Amstrad CPC series. It could format,
> copy disks, copy files, etc. Also, a number of software publishers,
> particularly of games, used to release their stuff on disks that would
> fail with the normal disk copy programmes, which meant that you only
> had one copy, and you know how unreliable floppies were and still are!
> However, my utility could copy all of the ones I tried.
>
> One standard trick employed was to use non-sequential sector numbers,
> but all a utility had to do was try to and read the next sector it
> expected, and if/when that failed, try all the other possible sector
> numbers that hadn't yet been tried. Another common trick was simply
> not to format one of the tracks, and ensure that this was before or in
> the middle of the tracks holding the software, but all you had to do
> was keep going after the error track, rather than giving up. However,
> at least one tried to read the unformatted track, so you had to be
> careful that the destination disk wasn't formatted already.
Yup errored/missing sections on a disk was a common copy protection
method on lots of machines of the time.
There were some more sinister ones though like "weak bits" (i.e. sectors
formatted with lower than normal flux changes or slightly off position
tracks such that you got different (i.e. random ish) data every time
they were read. Any attempt to duplicate these on a normal drive would
then permanently fix the sector in one state and hence fail the
protection check. (in the C64 world, "Parameter" copiers were initially
one solution - these nibble copied the disk as best they could, and then
hacked the binary for the particular disk in question to null out the
protection check!)
Freezer cartridges were my favourite. Load the program, and wait until
you are past all the tiresome protection checks etc, hit the tit on the
cartridge to take control of the machine, and have it write out a
compressed version of what was in memory along with a complete system
context and all chip registers etc. You could then load your copy much
quicker than the original, and have it start running from exactly where
you froze it!
> The real bummer on that machine was the 3" drive. It meant that to
> rescue all my work off it when I upgraded to a PC, I had to get a
> second drive, devise a dual-format and write a PC program that could
> read and write the dual-format.
>
>> The soft sectored disks had a
>> single index hole that could be used to establish a track starting
>> point.
>
> Yes.
>
>> Having said that, many drives ignored that anyway, and relied on
>> correlating the sync pattern in the format to establish position. (some
>> like the Amiga floppy FS, would use the blitter to read and write whole
>> tracks at a time, thereby negating the need to even bother with track to
>> track sector alignment, and eliminating write latency).
>
> By the time I'd finished struggling to get my data off my CBM8096, I
> was deeply anti-Commodore!
There is nifty little utility called Big Blue Reader that runs on the
C128. Armed with one of its multi format drives (that can handle MFM and
GCR encoded disks) you can transfer data between any of the CBM format
disks, half a dozen common CP/M ones, and also a number of DOS variants.
Quite handy for all sorts of data recovery from old systems.
These days there are also various adaptors that will let you hook up one
of the serial bus varient IEEE 488 drives to the parallel port of a PC
and access stuff directly.
> I don't definitely recall doing anything with Amiga disks, though, at
> the school I worked at for a while, some kids would do their homework
> on whatever seemed to have the same disks at home, Ataris and Amigas
> were the usual culprits, and then find they couldn't hand it in,
> because the PCs wouldn't read the disks. I have a feeling that I
> probably copied stuff off some Amiga disks somehow, but have no
> definite recollection.
The Amiga could use any number of file systems and disk formats, so it
was easy enough to have it read and write FAT formatted disks for
shifting stuff between machines (although you had to respect the file
naming limitations of those file systems).
I used to have various mountlist entries that mapped onto each physical
removable drive so you could interpret and access the contents of
various "foreign" formats simply by accessing the drive by a different
device name. So DF0: was the first floppy with the native
"FastFileSystem" on a 880K miggy format disk, PC0: was the same drive
but using FAT and 720K DSDD PC format etc. Same for ZIP or JAZZ disks.
> But I definitely remember doing it for Ataris. IIRC, the way with
> Ataris was to format the floppy in the PC, not the Atari. The Atari
> could read and write to a PC-formatted 720Kb floppy quite happily, but
> the other way round wouldn't work. I think I concluded that the Atari
> assumed the disk was 720Kb, so didn't put down some of the info in the
> first sector that the PC needed to know which size disk was in the
> drive.
>
> AIR, BBC floppies couldn't be read by anything else around at the time
> without a special program. It used the same low-level format -
> sector sizes, etc - but the high-level format was so different that
> nothing else would read it natively.
Depended a bit on which DFS you had as well... but access to beeb disks
on other machines was certainly difficult at the time. (pretty sure
there are PC utilities that will do it now)
>> Not unexpectedly it was called "FORMAT". Needless to say Tim Patterson
>> borrowed this for his CP/M 86 workalike clone called QDOS (Quick n Dirty
>> Operating System) which a certain Mr Gates and co licensed and
>> eventually acquired outright to turn into PC/MS-DOS, hence the
>> continuation into MS terminology.
>
> And it was never quick but always dirty ...
and not as good as CP/M it had to be said, so neither was DOS to start
with.
>>> CP/M's high level format consisted of writing E5 in every byte of the
>>> disc. I did this as I wrote out all the other crud.
>
> Yes. Floppies were (presumably still are) formatted one track at a
> time, looping through from Track 0 to the highest one, 39 or 79,
> depending on the capacity of the disk. The floppy controller chip
35 and 77 also being common track counts.
> (OOTTOMH a uPD765A?) expected a value for the filler byte as part of
> the command string sent to it to format a track. The value of the
> filler byte tended to vary with the OS doing the formatting: CP/M was
> E5, MSDOS I think was F6, etc.
>
>>> Next question: Why can't I forget this to make room for something more
>>> useful? I don't even own a working floppy drive!
>
> I find that life is like that generally.
>
> The musical instrument I picked up most recently is the flute, but due
> to ill-health, I've not really been able, and certainly have had no
> motivation, to play much recently. When I do have a go, it's
> initially like relearning it all over again. By contrast, when I pick
> up a guitar, which I started to play in my late teens, although I'm
> hampered by no longer having callouses on my left-hand fingertips,
> it's a lot quicker getting to sound musical. When I pick up a
> whistle, which I learnt to play in childhood, I can sound pretty good
> almost straightaway.
Perhaps that is an advantage of having no musical talent whatsoever, I
can sound equally bad on any instrument straight away! ;-)
>> Astounding the old crap one can remember... often at the expense of
>> forgetting what you are supposed to be doing tomorrow it seems to me! ;-)
>
> Yes.
--
Java Jive
<see.my.s...@nowhere.null> wrote:
>
> Yup errored/missing sections on a disk was a common copy protection
> method on lots of machines of the time.
>
> There were some more sinister ones though like "weak bits" (i.e. sectors
> formatted with lower than normal flux changes or slightly off position
> tracks such that you got different (i.e. random ish) data every time
> they were read. Any attempt to duplicate these on a normal drive would
> then permanently fix the sector in one state and hence fail the
> protection check. (in the C64 world, "Parameter" copiers were initially
> one solution - these nibble copied the disk as best they could, and then
> hacked the binary for the particular disk in question to null out the
> protection check!)
That's interesting! I don't think I ever encountered such a disk on
Amstrad CPCs though.
> Freezer cartridges were my favourite. Load the program, and wait until
> you are past all the tiresome protection checks etc, hit the tit on the
> cartridge to take control of the machine, and have it write out a
> compressed version of what was in memory along with a complete system
> context and all chip registers etc. You could then load your copy much
> quicker than the original, and have it start running from exactly where
> you froze it!
Yes, I know the sort of thing. However I always found that I could
get round copy protection with a good debugger.
I remember inserting a wedge into Sorcery+ so that I could use it with
the cursor keys instead of a joystick, because I couldn't afford a
joystick at the time! IIRC, that had one of the disks copy-protected
by unexpected sector numbers. The day after I'd developed my program
sufficiently to make a working backup copy, I was going to visit
someone, and my disks were on the shelf in my car. In the Forest Of
Dean, I took a wrong turning and found myself going up a forestry
track rather than the B-road I'd thought I'd turned into, AND it was
barred by a pole across the road! Jumping on the brake pedal, the car
skidded to a halt just as the windscreen hit the pole. Although I had
to pay for a new windscreen, which, I dare say, cost more than a
joystick would have, the thing I remember is that the broken glass
shafted the original disk of Sorcery+. Fortunately, I still had my
newly-made backup at home!
> > By the time I'd finished struggling to get my data off my CBM8096, I
> > was deeply anti-Commodore!
>
> There is nifty little utility called Big Blue Reader that runs on the
> C128. Armed with one of its multi format drives (that can handle MFM and
> GCR encoded disks) you can transfer data between any of the CBM format
> disks, half a dozen common CP/M ones, and also a number of DOS variants.
> Quite handy for all sorts of data recovery from old systems.
My CBM8096 was such a buggy pile of sh*te that I was determined never
to have another Commodore machine in my life, so I didn't have a C128.
Also, as from your comments I'm sure you know, those early CBMs, like
the early Apples, used their own proprietary low-level disk format, so
their disks could not be read in any other drive.
Also, as I think I've related here before, the CBM gear had very weak
PSUs, and the 8080 floppy drive's was kaput. I advertised in Exchange
& Mart for advice and help, and to my stunned amazement, some really
kind guy in the West Country sent me, I think it was even at his own
expense, some old CBM drive mainboards and a kaput 4040 drive.
Although I only had a dodgy 2nd or 2rd hand 'scope with loose
connections in its controls, and a rank bad meter whose leads kept
coming out of the plugs, and no desoldering gear except a sucker, from
these various dead bits of kit, I was eventually able to retrieve
enough working chips to replace the dead ones on the 8080, and using a
spare PC PSU, it seemed, as far as I could then tell, to be powering
up correctly.
Then there was the problem of controlling it and reading the data off
the disks from a PC. I bought an ISA card from Maplin that had a
Programmable Interface Controller chip on it. Hacked about an IEEE
cable to fit the D-connector on the card and wrote a C and assembler
programme to read and write to the drives via the card.
Although it was only something of a minor triumph against the many
adversities of life, it had been such a tortuous process that I don't
suppose I'll ever forget that moment when I first saw the drives
00,OK,00,00 status symbol come up on the PC screen!
> These days there are also various adaptors that will let you hook up one
> of the serial bus varient IEEE 488 drives to the parallel port of a PC
> and access stuff directly.
Yes, buying an IEEE PC card was an option then as well, but they were
very expensive, and AIR the Maplin card was about a quarter of the
price.
> The Amiga could use any number of file systems and disk formats, so it
> was easy enough to have it read and write FAT formatted disks for
> shifting stuff between machines (although you had to respect the file
> naming limitations of those file systems).
So that's probably why I have no definite recollection - there was
no problem to solve, so I have no memory of solving one.
> Depended a bit on which DFS you had as well... but access to beeb disks
> on other machines was certainly difficult at the time. (pretty sure
> there are PC utilities that will do it now)
Yes, ISTR there were significant differences between DFS and ADFS.
I've just remembered how I solved the BBC to PC problem - the school
had an Archimedes that could read and write both, so I could copy
between them. It was a bore though. You had to boot the Arc normally
and copy the files from the BBC disk to the HD, then reboot into DOS
emulator mode, and copy them back to a PC-format floppy.
> >> Not unexpectedly it was called "FORMAT". Needless to say Tim Patterson
> >> borrowed this for his CP/M 86 workalike clone called QDOS (Quick n Dirty
> >> Operating System) which a certain Mr Gates and co licensed and
> >> eventually acquired outright to turn into PC/MS-DOS, hence the
> >> continuation into MS terminology.
> >
> > And it was never quick but always dirty ...
>
> and not as good as CP/M it had to be said, so neither was DOS to start
> with.
Early versions of DOS were certainly not as good as CP/M, but from
about v3.3 they started to improve. In fact I suspect there'd be some
who'd say that DOS v3.3 was the best version of DOS ever.
> >>> CP/M's high level format consisted of writing E5 in every byte of the
> >>> disc. I did this as I wrote out all the other crud.
> >
> > Yes. Floppies were (presumably still are) formatted one track at a
> > time, looping through from Track 0 to the highest one, 39 or 79,
> > depending on the capacity of the disk. The floppy controller chip
>
> 35 and 77 also being common track counts.
ISTR that the CBM 8080 drive I had used the latter.
> Perhaps that is an advantage of having no musical talent whatsoever, I
> can sound equally bad on any instrument straight away! ;-)
But I dare say you have other talents which surpass any that I may
have. For example, I can't draw for toffees. If any of the diagrams
on my site are any good, it's because graphics software allows even
no-hopers like myself to produce something that is at least neat and
tidy, if merely given enough time.
Paul Ratcliffe
> Actually, the Atari formatted disks could be made readable on a PC by
> changing the first three bytes in the boot sector to EB 34 90 - which is
> an Intel 808x short jump instruction to some executable code.
EB 34 is a short jump instruction. 90 is a NOP.
E9 xx yy is a 16 bit jump.
John Rumm
> On Thu, 13 Oct 2011 03:45:26 +0100, John Rumm
> <see.my.s...@nowhere.null> wrote:
>>
>> Yup errored/missing sections on a disk was a common copy protection
>> method on lots of machines of the time.
>>
>> There were some more sinister ones though like "weak bits" (i.e. sectors
>> formatted with lower than normal flux changes or slightly off position
>> tracks such that you got different (i.e. random ish) data every time
>> they were read. Any attempt to duplicate these on a normal drive would
>> then permanently fix the sector in one state and hence fail the
>> protection check. (in the C64 world, "Parameter" copiers were initially
>> one solution - these nibble copied the disk as best they could, and then
>> hacked the binary for the particular disk in question to null out the
>> protection check!)
>
> That's interesting! I don't think I ever encountered such a disk on
> Amstrad CPCs though.
It was not a common technique as far as I could tell (probably because
it was difficult for commercial duplicators as well). Met it once or
twice....
There were some other odd ones, like "LensLok" - a plastic gadget with a
perspex window with a prism in it. You held it over the screen to
interpret a pattern that was rendered readable by said gadget, and then
typed it in!
I recall using that once, then freezing and saving the program after
entering the code. ;-)
>> Freezer cartridges were my favourite. Load the program, and wait until
>> you are past all the tiresome protection checks etc, hit the tit on the
>> cartridge to take control of the machine, and have it write out a
>> compressed version of what was in memory along with a complete system
>> context and all chip registers etc. You could then load your copy much
>> quicker than the original, and have it start running from exactly where
>> you froze it!
>
> Yes, I know the sort of thing. However I always found that I could
> get round copy protection with a good debugger.
Which the cartridges also did nicely - and you did not need to find
space in memory for it prior to loading the game either.
> I remember inserting a wedge into Sorcery+ so that I could use it with
> the cursor keys instead of a joystick, because I couldn't afford a
> joystick at the time! IIRC, that had one of the disks copy-protected
> by unexpected sector numbers. The day after I'd developed my program
> sufficiently to make a working backup copy, I was going to visit
> someone, and my disks were on the shelf in my car. In the Forest Of
> Dean, I took a wrong turning and found myself going up a forestry
> track rather than the B-road I'd thought I'd turned into, AND it was
> barred by a pole across the road! Jumping on the brake pedal, the car
> skidded to a halt just as the windscreen hit the pole. Although I had
> to pay for a new windscreen, which, I dare say, cost more than a
> joystick would have, the thing I remember is that the broken glass
> shafted the original disk of Sorcery+. Fortunately, I still had my
> newly-made backup at home!
Stroke or luck (well if you ignore the whole new windscreen thing!)
>>> By the time I'd finished struggling to get my data off my CBM8096, I
>>> was deeply anti-Commodore!
Ah well my first was a VIC-20, which was a major step up from the ZX80!
That and the C64 were quite different to the older CBMs/PETs in many ways.
>> There is nifty little utility called Big Blue Reader that runs on the
>> C128. Armed with one of its multi format drives (that can handle MFM and
>> GCR encoded disks) you can transfer data between any of the CBM format
>> disks, half a dozen common CP/M ones, and also a number of DOS variants.
>> Quite handy for all sorts of data recovery from old systems.
>
> My CBM8096 was such a buggy pile of sh*te that I was determined never
> to have another Commodore machine in my life, so I didn't have a C128.
> Also, as from your comments I'm sure you know, those early CBMs, like
> the early Apples, used their own proprietary low-level disk format, so
> their disks could not be read in any other drive.
Well, it was proprietary in much the same way that everyone else's was -
although with a of couple of twists. Using GCR encoding was one... That
allowed variable data density on the disk and hence more sectors on the
outer longer tracks. The result was that a SSSD 35 track disk stored
170K in the days where other platforms would have got less than 100K out
of them.
(IIRC Chuck Peddle also produced a 5.25" drive that could store over 1MB
per disk several years before IBM/Shugart got round to doing DSHD
drives, and what is more, his system worked on DSDD disks without the
need for the high coercivity media)
The other difference from many was the use of intelligent drives with
their own CPU, RAM, and OS etc. Made the drives more expensive, but
offloaded work to them. Having said that I think Atari did similar with
the early 400 and 800 drives.
> Also, as I think I've related here before, the CBM gear had very weak
> PSUs, and the 8080 floppy drive's was kaput. I advertised in Exchange
> & Mart for advice and help, and to my stunned amazement, some really
> kind guy in the West Country sent me, I think it was even at his own
> expense, some old CBM drive mainboards and a kaput 4040 drive.
John Bickerstaf perhaps? (Chairman of what was originally IPUG, later ICPUG)
> Although I only had a dodgy 2nd or 2rd hand 'scope with loose
> connections in its controls, and a rank bad meter whose leads kept
> coming out of the plugs, and no desoldering gear except a sucker, from
> these various dead bits of kit, I was eventually able to retrieve
> enough working chips to replace the dead ones on the 8080, and using a
> spare PC PSU, it seemed, as far as I could then tell, to be powering
> up correctly.
I can beat that for serendipity... got asked to look at a failing
computer for a customer, which ran all his business database and contact
management (with no backup of course). Turned out to be a very rare 8296
"SuperPet" style CBM. (in the Porsche style case, clever banked memory
system etc). It was obviously having a major internal logic fault. After
much titting about with an old Solotron scope (complete with valves!),
managed to work out the fault was one of three custom ULA chips - but
could not work out which without another machine. What were the chances
of finding one (pre internet days)? Well I drove into town the following
day, and found the last remaining space in a car park - someone had not
used it because there was a small pile of junk in it. I thought "I
recognise that!", popped out, picked up a somewhat broken looking 8296
that had been fly tipped in the car park and put it in the boot and
parked in its space (the GF said, "I can't believe you just did that!"
Took it home, hosed the crap off it (literally) and dug the main board
out. Later I found that it was also knackered with a similar but
slightly different fault But, by swapping chips about was able to
identify the actual faulty one. Phoned CPC, gave them the part number
and they said "Oh, we have got one of those left". �6 quid later we had
a working computer again. ;-)
> Then there was the problem of controlling it and reading the data off
> the disks from a PC. I bought an ISA card from Maplin that had a
> Programmable Interface Controller chip on it. Hacked about an IEEE
> cable to fit the D-connector on the card and wrote a C and assembler
> programme to read and write to the drives via the card.
Yup, hooking a 1541 up to a PC seems quite common these days...
> Although it was only something of a minor triumph against the many
> adversities of life, it had been such a tortuous process that I don't
> suppose I'll ever forget that moment when I first saw the drives
> 00,OK,00,00 status symbol come up on the PC screen!
I bet! ;-)
(I remember the feeling of victory when I managed to transfer another of
my collection of VIC tape based games onto disk (most VIC stuff was
never released on disk). Learnt lots about hacking assembler (probably
because I spent more time doing that than actually playing the games!)
>> These days there are also various adaptors that will let you hook up one
>> of the serial bus varient IEEE 488 drives to the parallel port of a PC
>> and access stuff directly.
>
> Yes, buying an IEEE PC card was an option then as well, but they were
> very expensive, and AIR the Maplin card was about a quarter of the
> price.
No, these were far far simpler - basically just a custom cable to
connect the drives serial bus to the parallel port of the PC, and doing
everything in software from then on...
http://sta.c64.org/xcables.html
>> The Amiga could use any number of file systems and disk formats, so it
>> was easy enough to have it read and write FAT formatted disks for
>> shifting stuff between machines (although you had to respect the file
>> naming limitations of those file systems).
>
> So that's probably why I have no definite recollection - there was
> no problem to solve, so I have no memory of solving one.
Could be!
IIRC at first you had to buy the official MS-DOS filesystem, so someone
produced a freeware version called Messydos. Seemed to work ok.
>> Depended a bit on which DFS you had as well... but access to beeb disks
>> on other machines was certainly difficult at the time. (pretty sure
>> there are PC utilities that will do it now)
>
> Yes, ISTR there were significant differences between DFS and ADFS.
> I've just remembered how I solved the BBC to PC problem - the school
> had an Archimedes that could read and write both, so I could copy
> between them. It was a bore though. You had to boot the Arc normally
> and copy the files from the BBC disk to the HD, then reboot into DOS
> emulator mode, and copy them back to a PC-format floppy.
Still, given the amount of disks one tended to have in those days,
probably not too much of a job.
>>>> Not unexpectedly it was called "FORMAT". Needless to say Tim Patterson
>>>> borrowed this for his CP/M 86 workalike clone called QDOS (Quick n Dirty
>>>> Operating System) which a certain Mr Gates and co licensed and
>>>> eventually acquired outright to turn into PC/MS-DOS, hence the
>>>> continuation into MS terminology.
>>>
>>> And it was never quick but always dirty ...
>>
>> and not as good as CP/M it had to be said, so neither was DOS to start
>> with.
>
> Early versions of DOS were certainly not as good as CP/M, but from
> about v3.3 they started to improve. In fact I suspect there'd be some
> who'd say that DOS v3.3 was the best version of DOS ever.
Well 4 was certainly a turkey... later ones were ok I suppose.
>>>>> CP/M's high level format consisted of writing E5 in every byte of the
>>>>> disc. I did this as I wrote out all the other crud.
>>>
>>> Yes. Floppies were (presumably still are) formatted one track at a
>>> time, looping through from Track 0 to the highest one, 39 or 79,
>>> depending on the capacity of the disk. The floppy controller chip
>>
>> 35 and 77 also being common track counts.
>
> ISTR that the CBM 8080 drive I had used the latter.
Yup. 15 sectors at the inner disk sections, rising to 21 at the outside.
>> Perhaps that is an advantage of having no musical talent whatsoever, I
>> can sound equally bad on any instrument straight away! ;-)
>
> But I dare say you have other talents which surpass any that I may
> have. For example, I can't draw for toffees. If any of the diagrams
> on my site are any good, it's because graphics software allows even
> no-hopers like myself to produce something that is at least neat and
> tidy, if merely given enough time.
Well same here really. I can draw ok with a computer.
Java Jive
<see.my.s...@nowhere.null> wrote:
>
> John Bickerstaf perhaps? (Chairman of what was originally IPUG, later ICPUG)
It was so long ago that I can't remember any name now.
> I can beat that for serendipity... got asked to look at a failing
> computer for a customer, which ran all his business database and contact
> management (with no backup of course). Turned out to be a very rare 8296
> "SuperPet" style CBM. (in the Porsche style case, clever banked memory
> system etc).
Sounds exactly like my 8096 but with more RAM.
> It was obviously having a major internal logic fault. After
> much titting about with an old Solotron scope (complete with valves!),
> managed to work out the fault was one of three custom ULA chips - but
> could not work out which without another machine. What were the chances
> of finding one (pre internet days)? Well I drove into town the following
> day, and found the last remaining space in a car park - someone had not
> used it because there was a small pile of junk in it. I thought "I
> recognise that!", popped out, picked up a somewhat broken looking 8296
> that had been fly tipped in the car park and put it in the boot and
> parked in its space (the GF said, "I can't believe you just did that!"
>
> Took it home, hosed the crap off it (literally) and dug the main board
> out. Later I found that it was also knackered with a similar but
> slightly different fault But, by swapping chips about was able to
> identify the actual faulty one. Phoned CPC, gave them the part number
> and they said "Oh, we have got one of those left". �6 quid later we had
> a working computer again. ;-)
LOL!
> (I remember the feeling of victory when I managed to transfer another of
> my collection of VIC tape based games onto disk (most VIC stuff was
> never released on disk). Learnt lots about hacking assembler (probably
> because I spent more time doing that than actually playing the games!)
Yes, I tended to be a bit like that. I don't regret some of it
though, it's a very good way to learn things.
> No, these were far far simpler - basically just a custom cable to
> connect the drives serial bus to the parallel port of the PC, and doing
> everything in software from then on...
>
> http://sta.c64.org/xcables.html
I don't think those were around when I was trying to do the transfer.
> IIRC at first you had to buy the official MS-DOS filesystem, so someone
> produced a freeware version called Messydos. Seemed to work ok.
Yes, AIR the Ataris had similar emulators, I remember solving a
problem for my brother who was trying to get a DOS emulator working on
his Atari so that he work at home. Something to do with an incorrect
filename.
John Legon
uk78> wrote in article <slrnj9eqe9...@news.pr.network>:
Yes, that's true, 90 is a NOP and doesn't do anything. Early versions
of MS-DOS used the 16-bit E9 xx xx, and the third byte was replaced
with a NOP in boot sectors that begin with a short jump.
--
John Legon
John Rumm
> On Fri, 14 Oct 2011 00:29:20 +0100, John Rumm
> <see.my.s...@nowhere.null> wrote:
>>
>> John Bickerstaf perhaps? (Chairman of what was originally IPUG, later ICPUG)
>
> It was so long ago that I can't remember any name now.
>
>> I can beat that for serendipity... got asked to look at a failing
>> computer for a customer, which ran all his business database and contact
>> management (with no backup of course). Turned out to be a very rare 8296
>> "SuperPet" style CBM. (in the Porsche style case, clever banked memory
>> system etc).
>
> Sounds exactly like my 8096 but with more RAM.
Yup basically it was. It was the last model they did and sort of hovered
between the end of the PETs and the 500 and 700 series. Looked like:
http://www.northnet.org/rayzor/cbm/8296.html
>> (I remember the feeling of victory when I managed to transfer another of
>> my collection of VIC tape based games onto disk (most VIC stuff was
>> never released on disk). Learnt lots about hacking assembler (probably
>> because I spent more time doing that than actually playing the games!)
>
> Yes, I tended to be a bit like that. I don't regret some of it
> though, it's a very good way to learn things.
Indeed... its surprising for how many software engineers these days, the
concept of doing anything in assembler scares them ;-)
>> No, these were far far simpler - basically just a custom cable to
>> connect the drives serial bus to the parallel port of the PC, and doing
>> everything in software from then on...
>>
>> http://sta.c64.org/xcables.html
>
> I don't think those were around when I was trying to do the transfer.
>
>> IIRC at first you had to buy the official MS-DOS filesystem, so someone
>> produced a freeware version called Messydos. Seemed to work ok.
>
> Yes, AIR the Ataris had similar emulators, I remember solving a
> problem for my brother who was trying to get a DOS emulator working on
> his Atari so that he work at home. Something to do with an incorrect
> filename.
Messydos was just a file system rather than an emulator as such (there
were various PC emulators as well, ranging from software only, to PC on
a card solutions called bridge boards (that plugged into the internal
zorro expansion bus and also the undriven ISA but that existed on the
motherboard of some of the machines - hence the name))
Andy Champ
> Well, it was proprietary in much the same way that everyone else's was -
> although with a of couple of twists. Using GCR encoding was one... That
> allowed variable data density on the disk and hence more sectors on the
> outer longer tracks. The result was that a SSSD 35 track disk stored
> 170K in the days where other platforms would have got less than 100K out
> of them.
Don't see the relevance of the encoding standard to variable bit rates.
ISTR some machine that had variable spin speeds to produce this effect
- Apricot? - and they were not the most reliable of things.
Andy
John Rumm
> On 14/10/2011 00:29, John Rumm wrote:
>> Well, it was proprietary in much the same way that everyone else's was -
>> although with a of couple of twists. Using GCR encoding was one... That
>> allowed variable data density on the disk and hence more sectors on the
>> outer longer tracks. The result was that a SSSD 35 track disk stored
>> 170K in the days where other platforms would have got less than 100K out
>> of them.
>
> Don't see the relevance of the encoding standard to variable bit rates.
capacity due to greater efficiency of the coding method. The CBM drives
(which were "normal" constant angular velocity drives) also had a data
pump that can alter the data read/write rate to enable the generation of
different data densities within different zones of the disk.
> ISTR some machine that had variable spin speeds to produce this effect -
> Apricot? - and they were not the most reliable of things.
read/write bit rate. Later Apple II systems like the GS and possibly
some of the Macs did this trick... I don't know much about the Apricot.
Andy Champ
> Its not directly - the GCR encoding accounted for some gain in storage
> capacity due to greater efficiency of the coding method. The CBM drives
> (which were "normal" constant angular velocity drives) also had a data
> pump that can alter the data read/write rate to enable the generation of
> different data densities within different zones of the disk.
But the drives had a data pump? Every floppy drive I ever used had an
amplifier. And that was about it. All the bitwise stuff was in the
controller. Mind, even then I hardly had to trouble myself over FM and
MFM - except when writing tests, or helping the HW guys.
Andy
John Rumm
> On 15/10/2011 18:30, John Rumm wrote:
>> Its not directly - the GCR encoding accounted for some gain in storage
>> capacity due to greater efficiency of the coding method. The CBM drives
>> (which were "normal" constant angular velocity drives) also had a data
>> pump that can alter the data read/write rate to enable the generation of
>> different data densities within different zones of the disk.
>
> Ah, thanks.
>
> But the drives had a data pump? Every floppy drive I ever used had an
the process the data need to be coded, serialised, and clocked out to
the write head. Most floppy drive controllers of the era had fixed write
clock rates. This in effect meant you were constrained by the maximum
rate at which you could achieve reliable operation on the smallest
circumference tracks with the lowest linear velocity of the disk past
the head. The CBM controllers could vary this clock rate under the
control of the drives software - and hence would use progressively
higher rates when operating on the outer tracks, allowing more bpi and
hence more sectors per track.
> amplifier. And that was about it. All the bitwise stuff was in the
> controller. Mind, even then I hardly had to trouble myself over FM and
> MFM - except when writing tests, or helping the HW guys.
computer needed to pay any attention to really, since the drives were
computers in their own right (they had their own processor, ROM, RAM,
DOS etc) all the messing about was hidden in the drive.
Paul - xxx
> Charlie+ wrote:
>
> > On 10 Oct 2011 11:25:35 GMT, "Paul - xxx"
> > <notchec...@hotmail.com> wrote as underneath my scribble :
> >
> > > Charlie+ wrote:
> > >
> > >> On Mon, 10 Oct 2011 10:32:43 +0100, Jeff Layman
> > >> <JMLa...@invalid.invalid> wrote as :
> > >>
> > >> > On 10/10/2011 09:11, Charlie+ wrote:
> > >> >> I baught a 32" Panasonic TV recently, it has PVR over USB
> > facility >> - I >> find that this TV is VERY choosy as to what usb
> > disk it will >> use and >> will not record to a USB stick at all, or
> > indeed any USB >> disk that has >> an interface eg any caddy type.
> > It also insists on >> formatting the disk >> to its own file system
> > which cannot be used on >> a computer, and is >> encrypted to this
> > single TV ( if the TV goes >> for repair - you cannot >> even play
> > your previously made USB >> recordings - you would have to >>
> > re-format the hdisk) .... all this >> is obviously done to prevent
> > ANY >> transfer of HD recordings. There >> is a Component
> > connection but it is TV >> input only - no output. >> The only
> > output is SD from SCART. >> My guess is that all modern HD >> tVs
> > are probably protecting HD recordings >> like this to prevent any >>
> > transfer....Maybe part of the HDMI encryption >> standard licence?
> > >> >> (the Panasonic model no is TXL32E30B (about £500) if this is
> > of >> >> interest to others)! >> >
> > >> > It is, thanks.
> > >> >
> > >> > Without downloading umpteen manuals for other TVs and checking,
> > >> > does anyone know whether this sort of "tying-down" applies to
> > USB >> > recording with other makes as well as Panasonic?
> > >>
> > >> My guess would be that the mfg. coys have to have pre-agreed to
> > this >> together otherwise someone not agreeing to the knobbling
> > would have an >> obvious market advantage!
> > >
> > > Hmm, mums TV is a new Panasonic and she records via USB, either a
> > > stick or more recently to a laptop HD on a USB cable so TV is now
> > > a PVR .. I dunno if the copied TV shows and recordings can be
> > > copied further onto a PC, but I can check this weekend!
> > >
> > > I do know I just picked one of my USB sticks at random, used that
> > > and it just worked .. same for the HD on a lead ..
> > >
> > > I'll post back!
> > Thanks Paul that is more like the USB facility I would have liked!!
> > Look forward to your trial! Perhaps you cd also let us all know the
> > model No of her TV, Thanks C+
>
> Can't remember off-hand, but it's got internet, satellite and HD,
> freeview and HD, USB, SD, loads of connectivity and a damn fine
> picture .. cost £500 (including a glass stand!) in an online sale and
> now up to £749 ish .. with the stand at £84 ish .. ;)
>
> We only just got her onto the internet last night with an old laptop
> of ours, so won't go through again till Saturday at the earliest, but
> whenever it is I'll post back.
Sorry about the extra week wait! Stuff happens ...
Anyway, the TV is a Panasonic Viera TX.L32D28BPA, same as
http://www.electronicworldtv.co.uk/32_Panasonic_TXL32D28BPA_Viera_Full_HD_1080p_Freesat_Digital_Freeview_LED_TV_1142_d
or http://tinyurl.com/3avfud9
USB port, accepts the generic 2gb USB memory stick, cheap off ebay,
no-name!
Accepted the HD, a Hitachi 80G 2 1/2" Sata in a cobbled together
enclosue and generic USB lead.
Both need to be formatted to suit the Panasonic, neither will then copy
the recorded content to a PC, or at least they wouldn't to my Laptop,
Dell E5500 running W7 Ultimate and Windows Media Centre. Not an
exhaustive set of tests as I didn't try all possibilities, didn't get a
chance to try streaming, for instance, from the HD connected directly
to the laptop.
I tried a Sandisk 4gb USB stick and it wouldn't see it, though it did
see a 2gb sandisk stick.
When I get chance I'll try to get an hour or three to play and check
but doubt it will be soon! I also doubt it'll reveal much!
However, I'd guess that when mum gets connected to t'interweb we might
be able to connect via ethernet/wifi and stream stuff then, with a
possibility of WMC recording the stuff to a laptop/computer/harddisk
connected somewhere other than the TV.
Hope it helps, but I don't think it does much!
--
Paul - xxx
"You know, all I wanna do is race .. and all I wanna do is win"
Mark Cavendish, World Champion 2011.
Rick
"Charlie+" <cha...@xxx.net> wrote in message
news:t1daa751l86ctlv4u...@4ax.com...
> On 23 Oct 2011 11:21:16 GMT, "Paul - xxx" <notchec...@hotmail.com>
>
>>
>>SNIP!!
>>
>>Anyway, the TV is a Panasonic Viera TX.L32D28BPA, same as
>>http://www.electronicworldtv.co.uk/32_Panasonic_TXL32D28BPA_Viera_Full_HD_1080p_Freesat_Digital_Freeview_LED_TV_1142_d
>>
>>or http://tinyurl.com/3avfud9
>>
>>USB port, accepts the generic 2gb USB memory stick, cheap off ebay,
>>no-name!
>>
>>Accepted the HD, a Hitachi 80G 2 1/2" Sata in a cobbled together
>>enclosue and generic USB lead.
>>
>>Both need to be formatted to suit the Panasonic, neither will then copy
>>the recorded content to a PC, or at least they wouldn't to my Laptop,
>>Dell E5500 running W7 Ultimate and Windows Media Centre. Not an
>>exhaustive set of tests as I didn't try all possibilities, didn't get a
>>chance to try streaming, for instance, from the HD connected directly
>>to the laptop.
>>
>>I tried a Sandisk 4gb USB stick and it wouldn't see it, though it did
>>see a 2gb sandisk stick.
>>
>>When I get chance I'll try to get an hour or three to play and check
>>but doubt it will be soon! I also doubt it'll reveal much!
>>
>>However, I'd guess that when mum gets connected to t'interweb we might
>>be able to connect via ethernet/wifi and stream stuff then, with a
>>possibility of WMC recording the stuff to a laptop/computer/harddisk
>>connected somewhere other than the TV.
>>
>>Hope it helps, but I don't think it does much!
>
> USB recording media!! and the files are useless to anything else but
> that single TV,,, much as we thaught in OP!
> C+
>
The Humax fox-T2 encrypts its .ts files, which makes it pretty useless for
doing anything with them as well, no problem at all with the Technomate
TM5402 HD though.
>
>