The 950, well, I don't have that. But I have two tvi925 keyboards, and back when I worked with both, I never could tell them apart without checking the label in the upper right corner, so the key layout is very similar (identical, I think). The keyboard is slightly too large to fit my scanner. So I scanned it twice, with much overlap between the images. The resulting scans were rather dark, so I stretched the contrast; the results are up for ftp in the directory ftp.rodents.montreal.qc.ca:/mouse/misc/ under the names tvi925kbd.pgm.1 and tvi925kbd.pgm.2 for PGM files; change pgm to jpg for jpeg versions. For size reference, those scans are 75 pixels to the inch. Not perfect, but certainly good enough to extract a keybaord layout from. The VT-100 I can't help with. /~\ 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 bought a Zorro2 card a few years ago, back when I was still playing with micro's. Personally I thought the product was SERIOUSLY misrepresented. They claimed it could read a whole slew of disk formats, when in reality the Amiga version of the board was able to read Amiga and C-64 floppies (and I think I might have gotten it to read DOS and Mac as well using some 3rd party drivers). While it might be physically capable of reading all the formats that they advertise, the drivers to read them don't exist. Having said that, you might want to investigate Linux support for the board, I think you might find it to be much better. Also, WinUAE, and some other emulators might support it. Zane

Fred Cisin wrote: ... ... Actually, I'm mucking with a catweasel card right now. I took Tim Mann's code as a starting point and I'm going from there. I don't have any use for his decoding routines nor of making virtual disk images since my needs are different. However, I can't imagine how many hours of work he saved me by having routines that locate the card in PCI space. Also, his "trackhist" program provided some very useful subroutines. With the help of Tim's code, it took me less time to modify/write the code to decode the disk format than it did to rig up the 34-pin to 50-pin ribbon cable adapter. Anyway, I can provide an example disk format where the catweasel, as it stands, can't write the disk image, at least not without some dodgey trial & error (try to write a track, read it back and if it is mucked up, try and adjust the write timing for the next attempt. Even then, there is a lot of luck involved). Hard sectored disks are a problem for the catweasel to write. There is a function to write from index mark to index mark, except the catweasel assumes there is just a single index mark per revolution. Thus, you can write one sector, but you can't even reliably tell it which sector you want -- it just starts at the next index hole that appears. Perhaps under DOS you can disable interrupts and figure out via polling when sector N is about to appear and use index-to-index write mode. Even this doesn't suffice for the disk format used by the Processor Tech Helios system. It ignored every other sector mark so that effectively there were 16 256B sectors instead of 32 128B sectors. Further, blocks of data could be larger than 256B -- they simply spanned more than one sector. Thus, this mode is useless for that scheme. You can do a write where you specify "wait for an index hole, then write this sequence of transitions". The problem is that due to speed variations you can't say that index 5 is going to come exactly (166 2/3 ms / 32) after index 4. That is where you could try to write the whole track, then read everything back to see if you succeeded and if not, adjust the clock pulses wider or shorter to make things line up. Oh yeah, in this mode I think it doesn't wait for an index hole, it just goes whenever you tell it to, so good luck trying to get the data to line up with the index marks at all. As it turns out, now that I have the catweasel set up and running, there are three disk formats that I would personally find useful to be able to decode -- 8" Helios, 8" Wang 2200, and 5.25" Northstar. Guess what -- all three are hard sectored formats. Luckily, I'm really only looking to use it to archive virtual disk images, not to create new disks.

Multiple choice: "It can read xxxx disks" means: A. It has the physical capability to be able to handle the physical encoding, if somebody were to write appropriate software to do so - none currently exists. B. It can read the physical disk, and has software that will permit making an exact duplicate of the disk and/or creating a file that contains an image used for replicating the disk. C. It COULD transfer a byte for byte image of a file from certain "alien" disk formats to and from a local disk of the host computer, IFF somebody were to write such software (not currently in existence). D. It has (or IS) software to transfer a byte for byte image of a file from certain "alien" disk formats to and from a local disk of the host computer. (XenoCopy, Media Master, Uniform, 22Disk) E. It can "mount" disks of certain formats, and access files on them with what appear to be "normal" OS operations (Uniform) F. When it access a file on the disk of certain formats, it will also translate formatting codes into those of your current aps (open a Kaypro Wordstar file with Office Word XP) With XenoCopy, I had to expend an enormous amount of effort making it clear to people that it did category D above, NOT F. (The Kaypro Wordstar file is copied into a PC Wordstar file) The Cat Weasel appears to be able to do A, C, and maybe B. There are way too many situations where use of the phrase "can read xxxx disks" is ASSUMED to mean D, E, or F, and there isn't always enough effort made to clarify! The result is expectations of being able to use it for things that it isn't ready for [YET?]. I just wish that NOBODY would EVER say "can read xxxx disks" without clarifying which definition is intended. -- Grumpy Ol' Fred cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com PO Box 1236 (510) 558-9366 Berkeley, CA 94701-1236 On Sat, 24 Jan 2004, Zane H. Healy wrote: