12 Mar
2004
12 Mar
'04
8:19 p.m.
Hey ya'll I finally went to the archives when I didn't receive any responses here
and found that ya'll couldn't open the pics... so here they are in zip form...
could someone please tell me what the heck this is from? Thanks
Lyos Gemini Norezel
http://geocities.com/lyosnorezel/strangekeyboard.zip
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
13 Mar
13 Mar
3:46 a.m.
Date: Fri, 12 Mar 2004 23:19:15 -0800 (PST)
From: Lyos Norezel <lyosnorezel(a)yahoo.com>
To: cctalk(a)classiccmp.org
Subject: Strange Keyboard (take 2)
Reply-to: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
Hey ya'll I finally went to the archives when I didn't receive any responses here
and found that ya'll couldn't open the pics... so here they are in zip form...
could someone please tell me what the Lyos Gemini Norezel
http://geocities.com/lyosnorezel/strangekeyboard.zip
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
Never ever use yahoo website, has tiny bandwidth limit and it aborted
the download and closed it down.
Please find decent website or use your website that you got from your
ISP.
Cheers,
Wizard
10:46 a.m.
Hey ya'll I finally went to the archives when I
didn't receive any
responses here and found that ya'll couldn't open the pics... so here
they are in zip form... could someone please tell me what the heck
this is from?
I tried, but they all cause bmptoppm to crash. (For others: the zip
file contains four files, keyboard%d.bmp for %d from 1 thorugh 4.)
[Sparkle] 1701> bmptoppm < keyboard1.bmp > keyboard1.ppm
bmptoppm: Windows BMP, 637x825x24
bmptoppm: cbFix: 40
bmptoppm: cx: 637
bmptoppm: cy: 825
bmptoppm: cPlanes: 1
bmptoppm: cBitCount: 24
bmptoppm: warning: offBits is 54, expected 67108918
xshowppm: can't read input picture: EOF looking for magic number
Segmentation fault (core dumped)
[Sparkle] 1702>
Not that I'm all that likely to recognize it, but it would help if you
could use a format like ppm, or gif, or jpeg....
As for the geocities issue, I have some ftp space I can put the zipfile
up for ftp from if you want.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
12:39 p.m.
der Mouse wrote:
I tried, but they all cause bmptoppm to crash.
It works fine for me (stock version supplied with Red Hat 9).
I've converted the pictures to jpeg and put them in http://vt100.net/tmp/
--
Paul
6:37 a.m.
On Sat, 13 Mar 2004, Paul Williams wrote:
der Mouse wrote:
Thanks for going to all that trouble but I still won't look at them until
Lyos manages to get his act together. Sheesh.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
I tried, but they all cause bmptoppm to crash.
It works fine for me (stock version supplied with Red Hat 9).
I've converted the pictures to jpeg and put them in http://vt100.net/tmp/
4:48 p.m.
Thanks Paul... now if only someone can look at these photo's and tell me what the heck
it is.
Thanks.
Lyos Gemini Norezel
Paul Williams <paul(a)frixxon.co.uk> wrote:
der Mouse wrote:
http://geocities.com/lyosnorezel/strangekeyboard.zip
I tried, but they all cause bmptoppm to crash.
It works fine for me (stock version
supplied with Red Hat 9).
I've converted the pictures to jpeg and put them in http://vt100.net/tmp/
Paul
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
1:48 p.m.
I tried, but they all cause bmptoppm to crash. (For
others: the zip
file contains four files, keyboard%d.bmp for %d from 1 thorugh 4.)
[Sparkle] 1701> bmptoppm < keyboard1.bmp > keyboard1.ppm
bmptoppm: Windows BMP, 637x825x24
bmptoppm: cbFix: 40
bmptoppm: cx: 637
bmptoppm: cy: 825
bmptoppm: cPlanes: 1
bmptoppm: cBitCount: 24
bmptoppm: warning: offBits is 54, expected 67108918
xshowppm: can't read input picture: EOF looking for magic number
Segmentation fault (core dumped)
[Sparkle] 1702>
Not that I'm all that likely to recognize it, but it would help if you
could use a format like ppm, or gif, or jpeg....
As for the geocities issue, I have some ftp space I can put the zipfile
up for ftp from if you want.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
I managed to view them fine with xv under solaris, is there a problem
with bmptoppm ?
Dan
14 Mar
14 Mar
12:45 a.m.
On Sun, 2004-03-14 at 00:48, Dan Williams wrote:
>I tried, but they all cause bmptoppm to crash.
(For others: the zip
>file contains four files, keyboard%d.bmp for %d from 1 thorugh 4.)
>
>[Sparkle] 1701> bmptoppm < keyboard1.bmp > keyboard1.ppm
>bmptoppm: Windows BMP, 637x825x24
>bmptoppm: cbFix: 40
>bmptoppm: cx: 637
>bmptoppm: cy: 825
>bmptoppm: cPlanes: 1
>bmptoppm: cBitCount: 24
>bmptoppm: warning: offBits is 54, expected 67108918
54 looks fine - offbits is the byte offset after the file header where
the image data begins. The image header itself (giving width, height
info etc.) is always 54 bytes in length, so an offset of 54 is quite
normal, implying the image data begins right after the image header.
An expected offset over 60MB in size seems extremely wrong :)
I managed to view them fine with xv under solaris, is
there a problem
with bmptoppm ?
Here's a theory...
Run hexdump -C on the file:
Bytes 0 and 1 should have the ascii characters 'BM'.
Bytes 2,3,4,5 give the size in 4 byte units of the file.
Bytes 6,7,8,9 are reserved - I've only ever seen these set to zero.
Bytes 10,11,12,13 give the offbits value, least significant byte first.
It's found 54, so is obviously reading that correctly.
Bytes 14,15,16,17 are within the image header itself and give the size
of the image header - 12 bytes for an OS/2 bmp file, 40 bytes for a
Windows bmp, and no expected other values. Maybe this is set wrong in
the bmp files Lyos created for some reason - I could see that some image
decoders might be really strict about this value (and bail because
offbits is less than the image header size + the file header size)
whilst others might be sloppy (i.e. "if it isn't set to 12 then simply
assume a 40 byte Windows header"). bmptoppm extracts the
width/height/colour-depth info from the image header though, so it's
obviously seems to assume Windows format and read 40 bytes at that
point; looks like it only sanity-checks the header size against the
offbits value after this and then breaks.
I haven't got a copy of the zipfile that Lyos sent to try otherwise I'd
take a look...
cheers
Jules
8:48 a.m.
> [Sparkle]
1701> bmptoppm < keyboard1.bmp > keyboard1.ppm
> bmptoppm: warning: offBits is 54, expected 67108918
54 looks fine - offbits is
the byte offset after the file header
where the image data begins. [...]
An expected offset over 60MB in size seems extremely wrong :) > I managed to view them fine with xv under solaris,
is there a
> problem with bmptoppm ?
Yes, there obviously is something wrong with bmptoppm; even if it can't
work, it shouldn't actually core.
However, it's the only bmp-reading tool I have, and I have no
documentation on BMP format to either fix it or write another.
I may see if I can deduce enough from the code to fix it; this
discussion has gotten me curious.
Run hexdump -C on the file:
Bytes 0 and 1 should have the ascii characters
'BM'.
Check.
Bytes 2,3,4,5 give the size in 4 byte units of the
file.
Mismatch. Bytes 2,3,4,5 give the size in bytes (little-endian; you
didn't specify which byte sex).
Bytes 6,7,8,9 are reserved - I've only ever seen
these set to zero.
Check. The bmptoppm code implies these are a hot-spot location.
Bytes 10,11,12,13 give the offbits value, least
significant byte
first. It's found 54, so is obviously reading that correctly.
"36 00 00 00" - yes.
Bytes 14,15,16,17 are within the image header itself
and give the
size of the image header - 12 bytes for an OS/2 bmp file, 40 bytes
for a Windows bmp, and no expected other values.
"28 00 00 00" - that's 40.
I haven't got a copy of the zipfile that Lyos sent
to try otherwise
I'd take a look...
I still have it. Shall we take this offlist?
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
13 Mar
13 Mar
12:37 p.m.
Dude, compressed pictures are usually JPEG.
Aaaand, *.zips are more and more frequently
viruses, so please avoid giving us those.
John A.
7436
days inactive
7437
days old
9 comments
8 participants
participants (8)
-
allain＠panix.com -
dan_williams＠ntlworld.com -
jpero＠sympatico.ca -
julesrichardsonuk＠yahoo.co.uk -
lyosnorezel＠yahoo.com -
mouse＠Rodents.Montreal.QC.CA -
paul＠frixxon.co.uk -
vcf＠siconic.com