test-drb March 2007

test-drb@ccmp.vtda.org

239 participants
488 discussions

Report on vintage "Programmer Electronnic Control" alias "RAF Tornado Computer"

by roger.holmes＠microspot.co.uk

> >>>>>> 13 Divide >>>>> HMMM, the command takes very long but the results are >>>>> very strange. I thought it might be some type of >>>>> random number generation by an irreducible polynomal, >>>>> but it is definitively not Divide. Maybe here is something >>>>> different or wrong with the microcode. >>>> This divides a signed DOUBLE LENGTH number in the A and Q registers >>>> by a signed memory operand. IIRC the A register gets the result and >>>> the Q register the remainder. >>> OK, I will verify this in the coming days. Now I >>> know what to look form but according to my records >>> the results of this command always have been junk. > > Did the experiment on the real unit: > > Memory operand had always value 0x003, executed > several of the (with index register zero at > the start) broken-divide: > > Akku before: 001 005 010 020 050 100 120 150 200 500 fff > Q before: fff 500 200 150 120 100 050 020 010 005 002 > > Akku after: 2ab d55 ff5 fe5 fb5 f05 ee5 eb5 e05 b05 d57 > Q after: 000 000 001 001 002 002 003 003 004 004 005 Hmm, difficult to spot a pattern, but then with these large 24 bit values you will be getting overflow when dividing by such a small number and try to fit the result into a 12 bit register. I would try with a much larger number as the memory operand, say 0x100. Another thing you can try is using the 12 order to do a multiply and then using the 13 order to do a divide by the same memory operand and see if you get anything like the numbers you started with. > > So honestly speaking I cannot see the system behind > these numbers ;-) In repeating the experiment I get > the same numbers. Changing the memory operand to > 0x234 I get the following: > > Akku after: 003 013 03b 075 123 3a1 415 4c5 743 f2f ffd > Q after: 000 000 001 001 002 002 003 003 004 004 005 > > So... ...big questionmark ... Ah that's better. Except I still can't see any pattern except that the Q register is counting up every other time. I wonder if it is doing one step in the division each time and you are supposed to loop and stop when Q reaches a certain value. This would improve maximum interrupt latency. But you say this order takes a long time. Maybe it is just broken as you thought. I'll see what I can come up with. > >>> "MTA - Move To Accu" is one of two "two-read-cycles" >>> instructions. Up to now I did not fugire out, what >>> the other instruction does with the data read. Do >>> you remember any "two-read" instructions in the Elliotts? >> Only the instruction I invented. The first word had the address of a > Hey, you where active in the design of these beasts! > Really great! So I am proud, that you join this > discussion so actively! > >> a call without lots of special literals. We reused /3 I think, anyway >> the original instruction was corrupt the Q Register with B-Line >> indexing, but B-Line indexing corrupted the Q register at the start >> of the instruction, so a totally useless opcode. > Interesting story! In my opinion and in modern > times using VHDL to implement everything into hardware > very easy, the true heroes are the people like you > who implemented microcode with the solder iron or > the hand wired type of core-ROM! Really great! Actually I was employed a junior programmer and eventually became responsible for the Coral 66 compiler and utility software for the 920. Later on I became a 'Senior Systems Engineer' and made some suggestions to the engineers here and there. I really learned about hardware as a hobby with my ICT1301 mainframe. After I left I designed interface cards for micros and my most complex hardware design was a NuBus card for the Macintosh which could transfer up to 64k of data to wide format Versatec Plotters at a million BYTES a second without any intervention from the CPU (i.e. by Direct Memory Access). While that was going on the CPU was imaging the next chunk of data to be sent. It had to be real time because if the plotter ran out of data it would stop and the liquid toner would soak into the paper and spoil the image. > >>>> I suspect the big plug is for the OMP (Operator's Monitor >>>> Panel), and >>> Some kind of blinking-light console? Something like >>> this exists for the Rolm 1666b, too. This would be >>> cool to have! ;-) >> Yes, but these were of course much rarer than the computers >> themselves. > > Sniff... > >> For a level 1 interrupt when the processor is on level 2, it stores >> the SCR in location 2, and the B in location 3. Then it loads the SCR >> from location zero and the B from location 1. > That is a clever concept and should be easy to detect. > So I will have to do some hardware work in supplying the > signals to the appropriate lines and than I will be > able to test this hypothesis. Good. > >>> BTW: Have there been timers on the Elliotts you >>> know about? >> Yes bit not within the CPU box. > Ah OK, so there is some kind of external data bus on the > Elliotts. In the case of PEC it consists of a multiplexed > open collector bus with a strobe line: address is > applied, than the strobe line is set low by the CPU. > Shortly afterwards address is removed by the CPU again > and the memory unit applies the data to the bus if > read is compite and signalizes this to the CPU. This > bus runs quite stable even with the 75cm of ribbon > cable of my setup attached to it. The shortest instructions > which read only onw word are executed within 1.2us > independent of the value of the index register. Yes the CPU and some memory was in one box and extra memory in others, and lots of peripherals too. Not commercial things of course, things like compasses, gyros, special digital radio receivers and transmitters, custom keyboards and vector and raster monitors, chart recorders and much more. > >> No, when I started working for Elliotts, all computers were out of my >> reach, but then I was offered an old mainframe (which originally cost >> 247,000 pounds, for scrap value, 150 pounds). It was built in 1962. I >> now have two of them in a barn at home. LOTS of lights and switches, >> each has a card reader, card punch, line printer and one has a paper >> tape reader and punch. Oh they both have drum stores and ten track >> magnetic tape. > Wow - that is a really great setup!!!! Do you > have got any photos???? How much space offered > the drum memory?? Recently I saw a card reader > in action at the cray-cyber.org and I know that > this is really great stuff!! A chap who used to be a service engineer on my computer many years ago contacted a while back and kindly agreed to help me bring my computer back into a useable state. He has a web site describing the project, and there are some pictures of him and my machine at http:// ict1301.co.uk/13010510.htm . The rotary switches can be used to put data into registers, including the three instruction registers, so you can enter programs from the keys if all else fails. The green squares have four indicators in each one, so can display one decimal digit (it is primarily a decimal machine, 12 digits * 4 bits) The machine can be run at full speed, or at three instructions per second, or at one instruction per keypress, or at three clock cycles per second or at one clock cycle per keypress. There are 6 tape decks see http://web.onetel.com/~rodritab/mtani.htm The bigger picture of a complete machine is here: http:// ict1301.co.uk/13012006.htm though it is actually a model and has the earlier one inch tape decks. An actual machine is the lower picture at : http:// www.milsom100.freeserve.co.uk/1301/1301f.htm Oh for all that space! I have two machines in less space they use for one. Mind you one of mine is not assembled. It makes taking pictures very difficult. Roger.

17 years, 9 months

Classic computing as a hobby when rocks were still soft (was Re: SWTPC craze)

by ethan.dicks＠gmail.com

On 3/14/07, Lyle Bickley <lbickley at bickleywest.com> wrote: > Count me in as an old fart as well... > > I had the following home/hobby computers: > > PDP-8/L in 1971 > PDP-8/I in 1972 Wow... those were relatively fresh, then. My recollection was that a PDP-8/L was $10K USD in 1967 or 1968. Any peripherals, or just TTY? > PDP-12 in 1975 Very nice. I've seen one up close, but never got to play. -ethan

17 years, 9 months

Report on vintage "Programmer Electronnic Control" alias "RAF Tornado Computer"

by roger.holmes＠microspot.co.uk

> >>> not know how long development of such an aircraft takes but >>> the first take-off was in 1974 I think, so this would match >>> the design of this box wuite well - what do you think? >> Aircraft development takes a long long time. To make it worthwhile >> the aircraft has a long service life. Whilst the computers are bullet >> proof in an office/home, the temperature extremes, vibration, high G >> forces etc in service means that many failures occur and PCBs could >> be replaced many times over the years, so do not pay too much notice >> of the dates on components of the boards currently installed. > OK, I understand this. I do not know much about these > issues, but on the internet often the COTS strategy > is mentioned and in using standard components, I think > moderen aircraft swap technology more often than was done > in the 60s and 70s, right? I am no longer in the Avionics field so I don't know anything about modern practice. > >> There were at least four 12 bit versions, and one 13 bit apparently. >> Then 12 bit models were the 902, 102C, ARCH 105 and Minim or 12/12. > Thank you - I will try to find information on the > web in the next days. Compared to the Elliott machines > the DECs are very common stuff ;-) I doubt you will find much apart from the names in timelines. Specialised machine will always be rarer than general purpose ones. The design considerations for a harsh environment plus the need to save weight means much more expense, so they are not affordable for normal use. Every extra Kg in the Avionics adds a lot to the overall takeoff weight. For a helicopter, I think the ratio was somewhere around six. Then there's the power, every extra watt needs bigger alternators/generators and a bigger engine to drive them, and more fuel to carry, which means more engine power and so on. > >>> Yes, that matches - the core memory module already has the >>> label GEC. So this is (as I suspected) older than the CPU and >>> taken maybe from a different design?! >> You have it the wrong way around. The GEC name replaced the Marconi >> name, which had earlier replaced Elliott. Core memory was very > Thank you for this hint. I checked wikipedia and obviously > GEC got involved very early and the name was changed to GEC > later (1984). Sorry for my misunderstanding, now I got it. > >> convenient for military applications and was in use long after it was >> replaced in commercial applications. Think of a missile or torpedo >> held in stock for many years, stick a power plug into it and program >> the target, pull out the plug and then launch it. Only then does the >> internal power supply come up, the processor boots up and does its >> thing. > The internet claimes sometimes, that core memory is less sensitive > to radiation, too. This might have been an advantage in certain > military applications (really bad applications, honestly speaking). DEAD right! > Data retenttion of the core memory should be quite good, > but since reading is always destructive, there is the > rist, that bad data gets written back. In the case of > Programmer Electronic Control, they did quite a lot > to adjust the core memory's dirver current automatically > according to a temerature measurement of the core. As > my experiments show, you have to reduce the current if > temperatuere goes up. This physically understandable > (1/T). My old mainframes also have a temperature sensor in the core store, and they are only allowed to be used in a narrow temperature band, about 10 to 30 degrees C. > >>>> bit 920s before moving on to the Zilog Z8001. >>> Hey, than you are a valuable expert on these - do you have >>> got any source of intormation about the 920s? >> Not directly but I may be able to help. > Hey, that is even better. I highly appreciate, that > you spend time in sharing your information! Thanks > a lot in advance! > >>> >>>> 9 Jump if negative >>> RIGHT - all three jumps are relative ones >> On the 18 bit machines these were relative to the start of the 8k >> memory module the instruction was in. An interesting modification. > In my case they are relative and you can jump > +/-127 words (crossing any border). Here again, the > box uses 1complement and thus jump 0x00 is the same > as jump 0x80: An infinite loop! If 0x00 is the same as 0x80, then it is not one's complement. Sounds like sign/absolute. In ones complement, the two representations of zero are all zeroes and all ones. On the 920, a jump to itself was referred to as a 'Dynamic Stop', and was the standard was to stop the computer as there is no stop instruction. I try to avoid doing it on my mainframes as continually accessing the same word in core might make it overheat. > >>>> 11 Store program counter (for function return) >>> SIMILAR - This stores PC and then does a >>> table jump >> On the 18 bit machines, it actually stored the program counter + 1 >> and the following instruction was either an 8 or a "/8", i.e. 24. > Hmm, I do not understand fully what you mean by "the following > instruction was either an 8 or a "/8", i.e. 24". In 920 assembler, instructions did not have mnemonics, you used their decimal operation code values. To indicate 'B Line modification' in the assembler you wrote a / before the operation code. The assembler simply added 16 to the opcode, so /8 = 24, but you don't have the B-Line bit on your machine - its always on. > > The Programmer Electronic Control (Let's call it PEC in the future) > stores PC+1 (as your 18bit) to the specified location into > core. The new address is taken from the position in memory > where the index register points to. So in my case this is > a perfect table jump. Ah, so you do this ? 0 word with address of routine 11 link word > >>>> 12 Multiply >>> RIGHT, unsigned multiplication >> This should multiply the signed accumulator and the signed memory >> operand giving a double length result in the A and Q registers. > Results are as you mention, but if either operand is > negative, the result contains wrong values. But maybe > I check whether this depends on the content of the > index register prior to the operation... > >>>> 13 Divide >>> HMMM, the command takes very long but the results are >>> very strange. I thought it might be some type of >>> random number generation by an irreducible polynomal, >>> but it is definitively not Divide. Maybe here is something >>> different or wrong with the microcode. >> This divides a signed DOUBLE LENGTH number in the A and Q registers >> by a signed memory operand. IIRC the A register gets the result and >> the Q register the remainder. > OK, I will verify this in the coming days. Now I > know what to look form but according to my records > the results of this command always have been junk. > >>>> 14 Shift >>> In PART: Here exist many subgroups of commands including >>> shift left/right. Also the Q as you call it can be transferred >>> to Accu and vice versa. There als is a MTA (MoveToAccu as I >>> call it) >>> which is a two-word instruction (most others are one-word) and >>> transfers the word following this command into Accu. About >>> 16 bit patterns have (at least to me now) the same meaning in >>> this segment. >> Shifting by the entire word length does transfer Q to A or A to Q > Right. But here again, the bit 11 is the sign bit and > thus the shift does not affect the bit 11 of the > destination. I.e. bit 0 of A is moved to bit 10 of Q > in shifting right for example. I see. The Q register was always a bit weird. > >> (but the data disappears from the source). A load immediate >> instruction would have been very handy. > Yes, the load immediate is really nice. A block > move does not exist on PEC. Essentially the immediate > "MTA - Move To Accu" is one of two "two-read-cycles" > instructions. Up to now I did not fugire out, what > the other instruction does with the data read. Do > you remember any "two-read" instructions in the Elliotts? Only the instruction I invented. The first word had the address of a link word (in page 0) and the whole second word was the address of where to jump to. So this was convenient for the compile to generate a call without lots of special literals. We reused /3 I think, anyway the original instruction was corrupt the Q Register with B-Line indexing, but B-Line indexing corrupted the Q register at the start of the instruction, so a totally useless opcode. > >> orders were encoded in the 14 order on the 12 bit machines with only >> 256 numbers available compared with 8k on the 18 bitters. > Yes, this seems to be absolutely correct! > >>>> 15 Input/Output and special (like interrupt return) >>>> 16 to 31, as above but indexed by B register. >>> >>> NOPE - The box is 12-bit and does not have got this block. >>> EVERYTHING is done via the index register I as I called it. >> >> Do you mean you cannot turn the B-register modification off? > Correct: Everything is modified by the index register. > Exceptions are the jumps, MTA for example. > >> Does it get cleared automatically somehow? > You are clever - that is exactly what appens: > Every instruction which is affected by this > register (ADD, SUB, LDA, STA, ...) clear > the register. So you have to load it right before > each instruction. A severe constraint in my > opinion is, that the index register can only > be loaded from words 0-127 in the lower 4k. So > this might be a bottleneck in memory since the > table jump (I called it IDXCALL since it used > the index register to get ne new address from) > requires memory for each routine called, too. > >>> perhaps studying the Elliot would help to solve the remaining >>> problems??!?!?!! >> I am willing to try. > Great! T H A N K S a L O T! > >> By the way, there are two 't's in Elliott. > Thanks - is stored into my brain now ;-) > > >>>> bootstrap, in later versions, this was just copied into core >>>> when the >>>> machine was initialised. >>> Interesting. The Programmer Electronic Control starts execution >>> at 0x0a0 after reset. >> Could it be that there is a value of 0x0A0 at location 0? > No, if the machine is held in reset state, > the PC is forced to 0x0a0 since the reset line > is connected to the Set/Clear pins of the flip-flops > making the program counter. Immediately after reset > is set high, the first word is read and executed > from this address. > >>> But of course the application was different >>> and the operation software was completely loaded via the big plug >>> boefore operation. >> I suspect the big plug is for the OMP (Operator's Monitor Panel), and > Some kind of blinking-light console? Something like > this exists for the Rolm 1666b, too. This would be > cool to have! ;-) Yes, but these were of course much rarer than the computers themselves. > >> yes the program would be loaded via this once, probably in the >> factory or at a maintenance depot, and the machine would probably be >> rebooted many times afterwards. > If data gets corrupted, than the complete aircraft has > to return to a maintenance depot for reprogramming > the machine? So if there are 10 or 20 of these boxes in > one aircraft, they need service quite often I think. > Roger, how was your experience - was this reliable with > the Elliotts or did you have to reporgram the pater tape > loader quite often? > > In my case, the transputer setup generates some spikes > doring it bootup. If PEC is already turned on, this > corrupts the data in core memory. So I always do a > memory-test on PEC after turn on (to adjust the core > driver current) and than freshly program my test > routines. > >> The 920 was unusual in that it booted into the highest level >> interrupt, level 1, so no interrupts will be serviced until you go >> down an interrupt level or two or three. > So 15 7168 increases the interrupt level and > after executing this once, the interrupt 1 can be > serviced, right? Thats it. > > What happens in the Elliott, if an interrupt occurs? > Is there a jump to a certain address in core or is the > new program counter itself read from core? For a level 1 interrupt when the processor is on level 2, it stores the SCR in location 2, and the B in location 3. Then it loads the SCR >from location zero and the B from location 1. > > I have to think how to figure this out for PEC.... Of > course I have to apply signals to all possible interrupt > sources, load a program trying the yet unknown instructions > and watch wheter any irregularities or jumps occur. I will > have to trap PEC if the idle-loop is left. This is a bigger > project and I will need some weeks to check this. > >> The 15 order is coded thus: >> >> 15 0 to 2047 Input >> 15 2048 Shift A register left 7 places and OR in a character >> from the >> paper tape reader (via OMP) >> 15 2052 (IIRC) Wait until character pressed on teletype and >> read into >> A register (via OMP) >> 15 4096 to 6143 Output >> 15 6144 Output character to paper tape punch (via OMP) >> 15 6148 Output character to teletype (via OMP) if I remember >> correctly >> 15 7168 Terminate current program level i.e. return from >> interrupt >> 15 7169 Test if standardised IIRC, skip the next instruction >> if the >> accumulator is zero or top two bits are different >> 15 7170 Increment B and skip the next instruction if bottom >> 13 bits >> are zero >> 15 7171 Read the value of the control keys on the OMP >> 15 7172 Move l.s. 17 bits of A to the m.s. 17 bits of Q. >> Bottom bit >> of Q is zeroed >> 15 7173 Move m.s. 17 bits of Q to l.s. 17 bits of A. Top bit >> of A is >> zeroed >> 15 7174 Move A to B >> 15 7175 Move B to A >> 15 7176 Set relative addressing mode >> 15 7177 Set absolute addressing mode > > Thank you very much for this list. This gives me > valuable hints and ideas what to try out next. > > BTW: Have there been timers on the Elliotts you > know about? Yes bit not within the CPU box. > > Since you are such an expert I am sure you > have a nice collection of vintage hardware, > right? Perhaps you even have got an Elliott > up and running? No, when I started working for Elliotts, all computers were out of my reach, but then I was offered an old mainframe (which originally cost 247,000 pounds, for scrap value, 150 pounds). It was built in 1962. I now have two of them in a barn at home. LOTS of lights and switches, each has a card reader, card punch, line printer and one has a paper tape reader and punch. Oh they both have drum stores and ten track magnetic tape. Roger Holmes.

17 years, 9 months

Upgraded my VAXstation 3520...

by pat＠computer-refuge.org

The VAXstation 3520 (and 3540) are dual and quad processor pedestal vaxes (BA213-sized chassis) that DEC breifly tried to sell, with a weird (only used on those models) processor/memory bus called the "M bus". I was hoping that I could get more than 4 CPUs to function in the machine, and after a lot of effort (module order did matter!), I got some encouraging results. I bet no one else here can claim that they've got a "VAXserver 3560"... ------------------------ KA60 V1.2 F..E..D..C..B..A..9..8..7..6..5..4..3..2..1..0 7 01010004 L2003 3 ? V1.3 1 SSC 00000001 2 DZ 00031200 ? 3 NI 19210770 ? 4 SCSI 00000901 5 SYS 00000001 Tests completed. 08-E1,P1 0B-E1,P1 0C-E1,P1 0F-E1,P1 14-E1,P1 17-E1,P1 08 <snipped OpenVMS 7.2 boot> $ show cpu VS3200, a VAXserver 3560 Multiprocessing is ENABLED. Streamlined synchronization image loaded. Minimum multiprocessing revision levels: CPU = 3 FBIC = 1. PRIMARY CPU = 08 Active CPUs: 08 11 12 15 20 23 Configured CPUs: 08 11 12 15 20 23 --------------------------------------------- Note that "VS3200" is the name of the system as the disk was supposed to go into a VAXstation 3200. Also, the system doesn't seem to be completely reliable in bringing up all 6 processors, but that may be related to a firmware version mis-match between processor boards (and/or timing issues when you've got 3 CPU boards). I set out to try to do this 3 years ago now, and finally have managed to obtain enough spare parts (via ebay) to try it out. Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

17 years, 9 months

Introduction And Questions About Media Preservation "MostlyDecStuff"

by fsmith＠ladylinux.com

On Tuesday 13 March 2007 12:47:04 pm cctalk-request at classiccmp.org wrote: Dwight Wrote .. > Are you looking for single sided or double sided? If single sided, > the SA800's that were on ebay should work fine. If double sided, > you'll need that SA851. These have two heads. > If your connector is a 50 pin, you need a the SA800 and SA851's. > The SA900's have a 44 pin edge connector but are otherwise > similar to the 800's. Double sided would be preferred since It would be more flexible in the long run. Although I could get by with a single sided drive if I had to. I will read up on this. I have come across some tables of the differences of each type of 8 inch drive but nothing all encompassing enough to give me a good decision. -- Kindest Regards, Francesca Smith "No Problems Only Solutions" Lady Linux Internet Services Baltimore, Maryland 21217

17 years, 9 months

trying to think of a terminal brand

by spectre＠floodgap.com

The ADDS auction made me try to remember the serial terminals (connected via Xylogics Annexes) that I used at UC San Diego. There were two: big boxy green ones sitting under H&SS lecture hall, and then the orange screen ones in AP&M 2337. The green screen ones were good solid VT-100 emulation, with double height and width support, but not a whole lot else. They were all-in-one white units with black keys and a very boxy form factor. The orange screen ones could do Tektronix 4014 emulation and had a small configuration menu you could get at with the function keys. I seem to remember the model number having four digits in it, and they were grey with detached keyboards. Anyone have any idea what model terminals these were? -- --------------------------------- personal: http://www.armory.com/~spectre/ --- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Aibohphobia, the fear of palindromes. -- Brian Braunschweiger --------------

17 years, 9 months

ftp archives disappearing?

by adamg＠pobox.com

The Internet used to have a number of useful features that it no longer does today -- for example, the finger and talk protocols. These protocols no longer exist on the Internet, mostly due to valid security reasons. As an example of how 'talk' differs from today's instant messaging systems, one time I was having trouble with some Internet site -- maybe their FTP server was down or something, I don't remember. I fingered the host, found an active user, and 'talk'ed him. He was happy to fill me in on what was up. You can't do that any more. And if you could, it would surely be abused into oblivion by spammers and phishers. Usenet, which is decentralized, requires no access credentials, and has a programmatic interface that allows for sophisticated filtering and offline reading, has largely been displaced by the network prisons known as web forums, which require a separate account for each forum, have a clunky and slow user interface, and are prone to vanishing when their operator loses interest. In general, Internet services which were designed to be accessed programmatically have been replaced with Web services which can only be used manually. On the other hand: HTTP actually isn't that bad as a replacement for FTP, except that uploads are much harder. There's also the problem of machine parsing the directory listings, but FTP had that problem too, to some extent. And the network itself is much faster and more reliable than it used to be. -- Adam

17 years, 9 months

8" drive variations

by julesrichardsonuk＠yahoo.co.uk

As hinted at in another post a few days ago, I'd like to add an 8" drive (or possibly more than one if necessary) to my Imagedisk machine in order to be able to archive 8" media. My knowledge of 8" drives is practically non-existent, so what are the gotchas involved? Things like: Do 8" drives exist in both hard and soft sector variants? Is one far more common than the other (as with 5.25")? Do 8" drives exist with wildly different track counts (40, 77, 80 etc.) and again is any one particular flavour far more common than the others? Are there any problems with some particular drives that'll make interfacing them to a '765 type FDC more difficult? etc. etc. I suppose the real big question is: Is there a particular flavour (i.e. geometry and interface, not specific brand) of 8" drive I could use that will mean that I can read and write the majority of 8" floppies found in vintage hardware? That would at least seem like a good initial step, and I could worry about the minority formats later on. cheers Jules

17 years, 9 months

ImageDisk Viewer

by dave06a＠dunfield.com

Necessity has been inventing again .... FYI, I have just added a new small utility to the ImageDisk package - this is called "ImageDisk Viewer" (IMDV). It is essentially a simple HEX editor that lets you easily poke through .IMD images with HEX displays accompanied by either ASCII or EBCDIC translations. Addtional features include the ability to search the image for specific strings, and to extract and view all printable strings from any arbirary location in the image (including scanning the whole image) - this is VERY handy when you are trying to figure what the heck a particular disk image contains. It's a simple viewer, but it's advantage over fancier dump utilities is that it knows about the .IMD format and can search/scan in the correct order for interleaved sectors (or not if you don't want), and scans/searches transparently across sector boundaries. If you have a reason too (or even if you don't), you can also use it to patch the content of individual sectors within the image (I take no responsibility...) Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

17 years, 9 months

Fwd: Featured Offer of the Month: Free FD100 Terminal!

by blstuart＠bellsouth.net

> Depends on your point of view. Absolutely. That's one of the great things about our hobby. There is enough variety of backgrounds and systems that almost every system can find a champion. I guess the Brother-type WPs fail to catch my attention because they're so much like other things I've designed or worked with. Of course, that doesn't mean I don't still have claim to the Brother we got my mother about 12 years ago. That sounded weird. Does that make it my uncle???? > The Brother floppies are interesting-- > 240K single-sided 80 (sometimes 40) track 3.5" SS2D using GCR. The > drives were really gutless wonders. IIRC, many were Z80/64180 based > systems. I've not tried to get CP/M running on one but it might well > be possible. Hmmm. There's an idea. Maybe there's more hack value than I had thought. BLS

17 years, 9 months

← Newer
1
...
28
29
30
31
32
33
34
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb March 2007