PropAltair - CP/M operating system for Propeller anyone?
heater
Posts: 3,370
Hi all,
I have just registered with this forum having been lurking for some months. Having been involved in embedded systems since 1982 and hence been through many generations of microprocessors, microconrollers and associated operating systems I could not resist looking into this new fangled Propeller chip.
The Propeller is totally facinating in that the thinking that went into it's architecture is so far "out of the box":The multiple processors, the spin interpreter, the lack of interrupts, the required use of (normally frowned upon) self modifying code in PASM, the deterministic timing etc. etc. Well you all know that.
It's also has severe limitations in the lack of general purpose memory and the tiny spaces available for PASM in each cog.
So I have yet to envisage the ultimate killer application for it. Something that it can do with ease that other controllers cannot. Something that uses all it's power to the max.
Now, I have a "retro computing" hobby project going on which is to build up a little sytem with an old Intel 8085 processor some RAM and some ROM and get running the CP/M operating system. This of course needs some peripherals like serial ports and disk drives which I really don't want to build the old way.
My first thought was to use a Propeller to implement those peripherals. Very easily it could provide the console output on TV or VGA. Keyboard, no problem. Disks, easy just use an SD card.
Then it hit me. Why not save all that hardware construction effort, junk the 8085 CPU, RAM and ROM chips and implement the whole thing in software in the Propeller ?
The result is that my first ever Propeller program is an 8085 emulator written in PASM. Amazingly I can fit an interpreter for the entire 8085 instruction set in one COG!
On top of that I have origanal CP/M components loaded from files into a DAT section. The Command Processor (CPP) the Basic Disc Operating system (BDOS) and a BIOS.
So far I have managed to get as far as getting the CP/M sign on message to display followed by the command prompt.
There is still someway to go before I have CP/M booting up from my SD card. My current hold up is actually getting a CP/M boot disk image onto an SD card.
This must be the most useless project ever described in this forum however it does have some interesting points:
1. It shows off the Propellers capabilities.
2. It has been a great learning exercise.
3. It enables the use of a C compiler on the Prop !
For that last point there is BDSC for CP/M written in 1979 which is now free and open source (http://www.bdsoft.com/resources/bdsc.html)
I have not attached my code here as I'm not sure if anyone wold be slightly interested. I would be more than happy to do so if anyone is.
It would be great if someone would like to review my effort and suggest improvements. There must be a lot of PASM idioms and optimizations I have not considered yet.
Further it would be great to have suggestions on which way to proceed. For example, currently I can only fit a small CP/M system into the available HUB RAM, enough to run CP/M and some small programs. Using external RAM chips we could have a fullup 64K byte system capable of running the C compiler. Imagine that, the Propeller hosting an entire development system! However that is extra hardware that maybe no one wants to get into.
Any one interested?
Heater.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/2/2010 10:27:25 AM GMT
I have just registered with this forum having been lurking for some months. Having been involved in embedded systems since 1982 and hence been through many generations of microprocessors, microconrollers and associated operating systems I could not resist looking into this new fangled Propeller chip.
The Propeller is totally facinating in that the thinking that went into it's architecture is so far "out of the box":The multiple processors, the spin interpreter, the lack of interrupts, the required use of (normally frowned upon) self modifying code in PASM, the deterministic timing etc. etc. Well you all know that.
It's also has severe limitations in the lack of general purpose memory and the tiny spaces available for PASM in each cog.
So I have yet to envisage the ultimate killer application for it. Something that it can do with ease that other controllers cannot. Something that uses all it's power to the max.
Now, I have a "retro computing" hobby project going on which is to build up a little sytem with an old Intel 8085 processor some RAM and some ROM and get running the CP/M operating system. This of course needs some peripherals like serial ports and disk drives which I really don't want to build the old way.
My first thought was to use a Propeller to implement those peripherals. Very easily it could provide the console output on TV or VGA. Keyboard, no problem. Disks, easy just use an SD card.
Then it hit me. Why not save all that hardware construction effort, junk the 8085 CPU, RAM and ROM chips and implement the whole thing in software in the Propeller ?
The result is that my first ever Propeller program is an 8085 emulator written in PASM. Amazingly I can fit an interpreter for the entire 8085 instruction set in one COG!
On top of that I have origanal CP/M components loaded from files into a DAT section. The Command Processor (CPP) the Basic Disc Operating system (BDOS) and a BIOS.
So far I have managed to get as far as getting the CP/M sign on message to display followed by the command prompt.
There is still someway to go before I have CP/M booting up from my SD card. My current hold up is actually getting a CP/M boot disk image onto an SD card.
This must be the most useless project ever described in this forum however it does have some interesting points:
1. It shows off the Propellers capabilities.
2. It has been a great learning exercise.
3. It enables the use of a C compiler on the Prop !
For that last point there is BDSC for CP/M written in 1979 which is now free and open source (http://www.bdsoft.com/resources/bdsc.html)
I have not attached my code here as I'm not sure if anyone wold be slightly interested. I would be more than happy to do so if anyone is.
It would be great if someone would like to review my effort and suggest improvements. There must be a lot of PASM idioms and optimizations I have not considered yet.
Further it would be great to have suggestions on which way to proceed. For example, currently I can only fit a small CP/M system into the available HUB RAM, enough to run CP/M and some small programs. Using external RAM chips we could have a fullup 64K byte system capable of running the C compiler. Imagine that, the Propeller hosting an entire development system! However that is extra hardware that maybe no one wants to get into.
Any one interested?
Heater.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/2/2010 10:27:25 AM GMT
Comments
In case you don't know yet. use [noparse][[/noparse]url]search.parallax.com[noparse][[/noparse]/com] and not the forum search.
(I know that some CP/M machines used the 8085, but many, many more used the Z80, and a lot of SW takes advantage of the expanded instruction set)
Anyway, what you describe sounds awesome! and then some...
What is the execution speed of your system?
(How fast does it emulate the 8085?)
If you can fit the 8085 interpreter into a single COG, I can't imagine that there's much more optimisation possible...
About the lack of RAM(which can be alleviated by waiting for the Prop II, but who wants to wait...), what about setting up a COG as a 'memory controller' and have it swap bits of RAM in and out from FRAM chips(I2C interface) or something?
It'll mean adding a layer of complexity to the interpreter, though...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
I was thinking of·using one or more good old fashioned 32K RAM chips that I just happen to have a tube of. But at the moment my·Propeller hardware consists of a home made version of the Propeller Demo Board so I don't have·enough spare pins for that.
One·idea I had was to just have·a serial interface for the keyboard/console I/O and the SD card interface·entirely coded in PASM. Then when they·and the 8085 emulator are loaded into their respective cogs the entire 32K of HUB RAM becomes free for CP/M (except for a few words to provide communication betwen cogs which can be hidden in some free space in the CPM·BIOS or such). Then a second propeller chip would provide the console on TV or VGA. Still that is a long way of yet.
Of course by the time I've done all that we might have a Prop II which would accomodate everything easily.
For now I need to:
1. Be sure my·8085 emulator is 100% correct.
2. Get a boot disk image into an SD card and boot from it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Interesting project.
Have You inplemented 8085 special instructions on it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
1.·As far as I can tell the extra instructions and addressing modes that it has would make the emulator 10 times bigger !·Perhaps when all this is sorted I might want to look into it but it looks like a lot of work and I may want to move onto something else by then.
2. Suprisingly I am not familiar with the Z80 at that level. Some how I missed out on that chip in my career.
3. I was inspired by the fact that you can now get the original Digital Reasearch source code for CP/M which is entirely 8080 only.
4. I have been playing around with the SIMH Altair 8800 emulator which runs on Windows, Mac, Linux. With that you can switch from Z80 to 8080 emulation. Turns out a lot of stuff will run in 8080. Editors, assemblers, compilers etc etc. One stumbling block is that you cannot rebuild you CP/M disks from source code in 8080 mode· as some tool requires Z80, I forget which.
Execution speed is unknown at the moment but I don't have to wait an age for the CP/M prompt to come up. I don't have the code in front of me now but there must be a going on for 100 PASM instructions executed for every 8080 op code in the worst cases. For sure running off an SD card is a lot faster than those old floppy disks [noparse]:)[/noparse]
Optimisation is a funny thing. I started writing this in a simple minded way, trying to do all as fast as possible. Soon found out that I had run out of COG space. Then I had to start optimizing for size, reusing code here and there etc etc·Then I realised I could put the op-code jump table into HUB RAM and access it with rdword. All of a sudden I had loads of free COG space without losing to much speed. In fact the whole thing became faster that·the original.
I'll look into the FRAM idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't have the docs in front of me but aren't the only extra instuctions in 8085 over 8080 "in" and "out" of the serial data pin ?
Anyway I have been working from the Intel 8085 Assemly Language Programming Manual.·I know I·have·omitted a few instructions. Anything to do with interrupts is just stubs at the moment as my CP/M does not use interrupts. Same for that serial I/O. Also DAA is so far not implemented, nothing I've run so far uses it !
Still I have enough GOG space left for these and was pondering about connecting up some real I/O pins to the interrupts and serial I/O.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's quite an achievement for a first program. I'd certainly be interested in seeing the 8085 PASM emulator code. Emulating a CPU so compilers for that can be used is something I'd considered as a fast-track for running C on the Propeller; there has to be some sort of 'CPU' emulated ( Virtual Machine ) anyway so this is a good way to go where native Propeller speed isn't required -- so a very long way from being useless IMO.
It doesn't look like it that would be that hard to extend the 8085 instruction set to also support Z80 instructions ...
www.cpmspectre.pwp.blueyonder.co.uk/z80/z80.htm
Additional Z80 super-sets could also be supported. Emulation isn't limited to the size of Cog memory; LMM allows Hub RAM to be interpreted as well, albeit slightly slower and taking that RAM away from other uses.
There may be licensing issues with distributing any 'original CP/M images' but that shouldn't otherwise affect what you're doing and what else you can publish.
Well done. I look forward to seeing what you have done, and good luck with the rest of the project.
Post Edited (hippy) : 2/25/2008 12:57:07 PM GMT
8085 is an 8080 with an added serial port and a few extra instructions...
Z80 is an 8080 with NO serial port, an incredibly expanded interrupt, a mirrored set of registers, additional IX and IY registers to use as pointers(with 8bit relative offset. Nice in databases), R-register used for refresh of Dynamic RAM(consider it an 7-bit 'free-running' counter/register. Nice for Random), and a total of 138 different instructions.(not counting address modes, of which they also added a few)
The most important new instructions are probably the EXX set(to switch between the two register sets), and the 'DMA' type instructions. (256Byte COPY in a single instruction is nice, sometimes. Doing an 256Byte OUT instruction isn't bad, either... )
In theory, when the interpreter bumps into one of the 'Prefixed' instructions, it could copy the registers into HUB RAM, then set a semaphore to activate an alternative interpreter in another COG, which does the instruction(s), then when it's finished, copies the registers back to HUB, and semaphores that it is finished. The original COG copies the registers back, and resumes interpreting. (Can be made easier if you're willing to take the penalty of keeping registers in HUB all the time)
Edit:
BTW: if·100 PASM instructions/8085 instructions is your 'worst case', then your stuff must be screaming along... (100:1 is considered a 'good' average on interpreters... )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 2/25/2008 1:26:11 PM GMT
Well, "first program" is a tad of an exageration. I did of course work through all he examples in the Propeller manual first. After that the emulator just grew bit by bit trying things this way and that.
At last, someone is mad enough to want to see this code[noparse]:)[/noparse] Give me a few days to pretty it up a bit, add some comments, instructions etc and I will post it.·You'll probably tell me it's a horrible spagetti mess but I'll be glad of any input.
The C compiler thing is what drives me sometimes. Especially as the author of BDS C was gracious enough to open source it. I have yet to get as far as trying to run anything compiled with it, still testing my opcodes and·getting CPM to boot from SD card.·I have however managed to run programs·assembled with the Microsoft Z80 assembler (M80)
What fascinates me is the idea of the Prop·itself hosting the compiler, if I can just get enough memory for it. But why stop there? We could have PLM or ALGOL or·PASCAL....
Haven't really looked into what is required to jump from 8080 to Z80 but·there is an instruction set test program for 8080 and Z80 (forget what it's called just now) for sure it has many times more tests for Z80. Actually that test suite is holding me up now as my emulator has many failures when running it. I've been trying to bust my opcodes with my own hand made test programs but havn't found the fault yet. And CP/M runs..so far.
I'm facinated by LMM, but as you say we start losing·CP/M space in HUB RAM·then.
As for licensing, all the CP/M operating system and utilities I'm using have come from the Altair 8800 simulator project http://www.schorn.ch/cpm/intro.html. This all need checking carefully. For example I cannot imagine that Microsoft has ever allowed free distribution of it's assemblers linkers etc. On the other hand I believe our actual CP/M sources and BDS C are allowed out, as it were.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I like your project, as I see it as a "framework" for similar emulations. These come up from time to time (most recent an unfinished C64 emulation).
The basic problems are so far
- not enough computing power in the Prop to emulate the "system", as the main power of early homecomputers did not lay in their processors but in their support chips!!
- missing RAM (It has to be 48k to 64k for any serious application)
CP/M as such however does not have those embarrassments
...
The 8085 is a very emulation friendly processor... the Z80 is not, as it is hard wired with about a hundered of undescribed instructions (this was the main issue of the HD64180)
I am very familiar with all three processors and will gladly look through your interpreter. But be aware! Could be I shall come up with an alternative implementation
Post Edited (deSilva) : 2/25/2008 1:58:57 PM GMT
Intel 8085 have 8 extra undocumented instruktions and some 16 bit.
I´m interested in You project code.
Ps. CP/M was my first operating system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
So far all undocumented opcodes cause my emulator to halt (or did I treat them as NOP can't remember off hand). I would be very interested if you have a description of those or know where I can find one.
It's encouraging to hear that there is some interest in this harebrained scheme.
My first operating system, at least for real work on a personal computer, was Intel's ISIS II on their MDS series II development systems. Big blue boxes with 8 inch floppy disks.·It seems that is what Gary Kildall used to develop CP/M on.
deSilva:
I'm afraid "framework" might be to grand a term for this. For now it is more like a giant hack that just about does what it should [noparse]:)[/noparse] I can't see much that could be reused anyway, but we'll see.
As you say RAM and support chips are not an issue. No fancy sound or graphics. In my openning post I used the term "retro-computing". What I originally had in mind was an Altair 8800 style front panel with lots of LEDS and switches. Key your boot loader in manually and then use a VT100 style terminal !
OK I will for post the code. But let me make it a little more presentable first. All suggestions welcome, after all there must be lots of acumulated PASM wisdom that I have missed out on whilst I've had my head down doing this.
Alternative implementation - sure why not, we could have a benchmark shoot out:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DSUB
Hex Code: 08H
Description: BC pair is subtracted from HL Pair affecting all flags.
JNK [noparse][[/noparse]16bit location] - Jump to Location if 'K' flag is reset
Hex code : DDH
JK [noparse][[/noparse]16bit location] - Jump to Location if 'K' flag is set
Hex Code: FDH
RRHL - Rotate Right HL Pair
Description: Rotates the HL pair 16 bit towards right.
Hex code : 10H
Operands : none
Flags unaffected
RLDE - Rotate Left DE Pair
Description: Rotates DE Pair to left.
Hex code: 18H
Operands : none
Carry affected : depends on Bit 15
ADI HL - Add Immidiate to HL pair
Description: Adds an 8 byte number to the HL pair.
Hex Code : 28H
Operands : 8 bit number
Flags: All affected
ADI SP - Add Immidiate to Stack Pointer
Description: Adds an 8 byte number to the SP
Hex Code : 38H
Operands : 8 bit number
Flags: All affected
RSTV
Description: Does a RST 8 instruction when the 'V' (must be overflow)flag is SET.
Hex Code: CBH
LHLX
Description: Loads HL Pair with the contents of address stored in the DE pair
Hex Code: EDH
SHLX
Description: Stores the HL Pair contents to the address specified in the DE pair.
Hex Code: D9H
It was never clear what set the K-Flag
I used one of them, but only very briefly. My work for many years was with the SWTPC 6800.
I think there are a lot of people round here who have been in the embedded field for quite a while and have very fond memories of those days. It's great to see so many people into retro-computing, and quite amazing to me that so many are interested in taking 'the latest' to recreate the past.
I'm all in favour of that. In these days of GHz CPU's, MB RAM and GB HDD, with a tendency IMO to believe 'bloat is consequently irrelevant', it's good to show just how much can be done with much smaller systems - A case perhaps of teaching new dogs old tricks ?
A rule with the Z80 was: 4 ticks for each byte and additionally 5 for each instruction. For general 4 MHz system that would come to roughly 1µs per byte, which will correspond to 20 Prop instructions (or 40 for a one byte instruction)
So it should be feasible to emulate it at the original speed of a -say - advanced 6 MHz Z80 system; the 8085 itself had a more favourable timing as it was a true 8-bit system whilest the Z80 was internally a 4-bit system which is widely unknown...
Excellent info thanks. Hope I can fit all those in ! What K flag ? I don't have one.
hippy:
Now we are going down memory lane. Never saw an SWTPC but my first ever paid programming work was to write a debug monitor for the 6809. We had the chip, apparently one of the first to arrive in England but no hardware or software. So first build a board with RAM, ROM serial etc to put it on then start writing the monitor.
Ah but no assembler or such luxury. First we design the code in pseudo code, then translate that into assembler mnemonics on paper, then assemble that by hand to HEX and blow the EPROM. Just when we got the thing completed my boss took delivery of an 6809 assembler disk to run on the Intel MDS box !
Some times you have to take the latest to recreate the past. A lot of those components are hard to find now. But the software can live on.
If I could get my hands on one of those huge 8 inch floppy drives and some disks I'd love to drive it from a Propeller. Just to hear that werrr, clunk, werrr clunk sound again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nor the 8086 ... which is different architecture but strived to be "a little bit" compatible... Gossip goes that they tried to enhance the 8085 with some of those new 8086 instruction, but found out later that they had used an obsolete 8086 proposal and so they decided to leave all that undocumented. So the 8085 became MUCH MORE compatible to the 8080 than expected by the public
However there can be C-Compilers with specific target options as "Z80" or "8085" which MIGHT generate them, as they MIGHT also generate the undocumented Z80 instructions which were used more widely as being VERY handy...
CP/M use only native 8080 instruction set.
None compiler use 8085 instructions.
But pople use them in assembler macros only tu extend capablities
RSTV was aritmetic overflow on 16 bit.
Z80 Instructions set is not part on CP/M but used only on ZX and similar computers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
The 8080 was developed as a custom single chip implementation of the Datapoint 2200 which was a discrete medium-scale TTL logic processor originally with serial delay line memory. HL was the data pointer and D and E were used as an alternate address holding register which could be swapped with HL as they were incremented or decremented for memory to memory operations using loops that were optimized for the length of the delay lines since the processor would stall waiting for the memory location to "come around" ... sort of like the Propeller's hub. The chip was never delivered as ordered. Intel's version didn't work. TI's version worked, but required too much support logic to be practical. The 3 companies went their separate ways. Datapoint is now history, but the processor architecture lingers on.
One litle corection.
It was 8008 implementation of the 2200.
8080 was fuly corected tu it´s funktion as 3 chip system
8085 implements 8080 3 chip´s in one and single voltage
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
It was 4 ticks for the first Byte, then 3 ticks for each additional memory access.
The exception is of course on systems like the MSX which forced the CPU to wait for a tick after each M1 state.
http://map.tni.nl/resources/z80instr.php
Didn't know that the Z80 was 4bit internally. Strange, as it was based on the 8080 chip.
(The Zilog crew came from Intel after a disagreement on the design of the next generation)
Anyway, seems it might be time to resurrect the Old-school hackers' thread in the Sandbox...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Ad 4 Bit: INTEL would have looked at each single transistor they had in their design! They were very ambitious and this was most likely the only possibility to put so many features onto the silicon.. Remember it even had 2 register sets...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen
I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.
"Failure is not an option -- it comes bundled with Windows."
Use The Best...
Linux for Servers
Mac for Graphics
Palm for Mobility
Windows for Solitaire
I love those extra registers. They make interrupts so much faster...
(3 PUSH + 3 POP = EXX... )
It's just a pity that most never understood the usage of the more 'specialized' instructions, or Interrupt MODE 2.
(I've never seen anyone use MODE 2 )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
The 8088 is a 8086 in disguise(8bit external databus, 16bit internally)
It has a vastly expanded instruction set, large memory address, which is also segmented...
Even IF you could make the interpreter, it'd move at glacial speed.
(Maybe the Prop II could do it, but I can't see a reason to do it)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
But anyway, it was mainly meant as a "neat idea" post, to get other people thinking about the possibilities.
Regards,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen
I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.
"Failure is not an option -- it comes bundled with Windows."
Use The Best...
Linux for Servers
Mac for Graphics
Palm for Mobility
Windows for Solitaire
Should I tell you how batches of 8085s all made by Intel and all with the same part number responded differently to HOLD line timing depending on if they originated from the Philipines or where ever alse it was they were made ?
No. I'm going to shutup for a few days now until I can put my code where my mouth is, err as it were.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
And since the i8086/88 has such a messy(and large) memory map, the Prop will mostly be busy swapping in or out memory.
I admit that it would be neat, though...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
http://www.speakeasy.org/~rzh/bb.html
http://www.s100-manuals.com/