yaz80 - yet another z80 core
pullmoll
Posts: 817
Last night I wrote another Z80 CPU emulation based on the experiences and code snippets from the ditched attempt to do a dynamically recompiling Z80. For obvious reasons I named it yaz80. The code isn't complete yet, but almost as complete as the last try was, and it is much simpler and also (or thus) faster than pm80.
The concept this time was: keep some registers in hub RAM, except PC, SP, A and flags, i.e. the most often used ones. All opcodes are executed as LMM instructions by a 4 times expanded classic LMM fetch + execute loop. Every repeatedly appearing alu operation and flag effects are subroutines in cog RAM. Also the core of LDIR and LDDR are in cog RAM to speed up things. The tables indexing the opcode functions are words, and thus as compact as possible.
The only thing left to do is fixing the opcodes, or their flag effects, that fail the EXZ80DOC exercise. Currently there are some well known candidates which I hope to nail down soon.
The code is available via my CVS repository at anoncvs@pmbits.ath.cx:/anoncvs with the module name yaz80.
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs login</font>
Just hit ENTER when asked for a password.
If this fails with an error message, try
you@host:~$</font> touch ~/.cvspass</font>
to create an empty file for CVS passwords.
Check out the source with:
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs co yaz80</font>
Enter the new directory with:
you@host:~$</font> cd yaz80</font>
And build, upload to /dev/ttyS0 (COM1) and run with:
you@host:~/yaz80$</font> make</font>
Updates to the source can later be fetched doing:
you@host:~/yaz80$</font> cvs up -dAP</font>
Note: There is no blank between ':' and 'pserver:', but the forum software mangles the text, if I leave no space between ':' and 'p'. You gotta love it!
The required software to translate it all is:
<ul>
[*] BradC's bst.linux or the corresponding Windows executable (change Makefile for your system)
[*] GNU compiler collection (gcc)
[*] GNU make
[*] BISON a replacement for yacc, a parser generator.
[*] FLEX a replacement for lex, a lexical analyzer for compiler-compilers.
[*] GtkTerm in your path is fired up after running the compiled code from RAM (change Makefile to your needs)
[/list]
YAZ80 now supports reading the image files on FAT12, FAT16 and FAT32!
History:
0.0.1 first public
0.0.2 moved all registers to the cog RAM
0.0.3 shrink size by moving repeated code to cog RAM
0.0.4 extend io.spin to access SD card
0.1.0 fixed add16, shrunk hub RAM use, add RamBlade support
0.1.1 fixed sbc16/adc16 - not much more left to do until perfect bonus 10'000 pts
0.1.2 fixed DAA - perfect!?
0.2.0 add code to find hard disk images inside the FAT filesystem
0.2.1 fixed <rot/res/set> (ix/iy+disp8), though the implementation should have been okay, but it breaks exerciser
0.2.2 add timed flush to the 128 byte sector writing (1 second idle), reducing the SD 512 byte sector rewrites
0.2.3 for TriBladeProp call idle/active around SD card functions in io.spin; Add optional code to check for Z80 interrupts
0.2.4 Separate FAT fs functions from io.spin to fatfs.spin, add date/time info for the files being inspected
0.2.5 Add optional cycle counting and speed measuring to yaz80. I get abt. 1,4MHz on the DracBlade with CP/M ;-P
0.2.6 Found a bug in SRL (IX/IY+disp8); it was calling alu_rlc - a copy+paste bug. Doesn't fix the opcode group, though
0.3.0 Fixed the shift/rotate bug after reading the Propeller manual. Note to self: do that more often.
0.3.1 Add support for interrupt modes 0, 1 and 2. Changed I/O to use a single long for inter cog communication
0.3.2 Support a bastard 8080 CPU, i.e. one without Z80 opcodes except DJNZ and JR <cond>
0.3.3 Got the PS/2 keyboard interface working on the DracBlade. RamBlade still doesn't work.
0.3.4 Working on a TV 80x24 display and VT100 terminal emulation. It's halfway done. Out of cogs again, so no Keyboard or no TV text...
0.3.6 Fixed the bug causing Wordstar to send broken escape sequences. It was ADD16, i.e. ADD HL,BC or ADD IY,SP.
0.3.7 Fixed a bug in ADC16/SBC16 that could leave H with a value > $FF, which is - of course - impossible for an 8bit register
0.3.8 Not released - tried to reduce cog memory, rearranged some TRS80 specific code, broke ADC16/SBC16 again.
0.3.9 ADC16/SBC16 fixed again. The exerciser is happy with everything, except INI/IND/INIR/INDR and OUTI/OUTD/OTIR/OTDR
0.3.10 Add CPU_8085 flag and opcodes, so you can now chose between CPU_Z80, CPU_8080 and CPU_8085
That's all for now. The attachment will have the latest version, updated from time to time.
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 4/1/2010 10:58:28 AM GMT
The concept this time was: keep some registers in hub RAM, except PC, SP, A and flags, i.e. the most often used ones. All opcodes are executed as LMM instructions by a 4 times expanded classic LMM fetch + execute loop. Every repeatedly appearing alu operation and flag effects are subroutines in cog RAM. Also the core of LDIR and LDDR are in cog RAM to speed up things. The tables indexing the opcode functions are words, and thus as compact as possible.
The only thing left to do is fixing the opcodes, or their flag effects, that fail the EXZ80DOC exercise. Currently there are some well known candidates which I hope to nail down soon.
The code is available via my CVS repository at anoncvs@pmbits.ath.cx:/anoncvs with the module name yaz80.
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs login</font>
Just hit ENTER when asked for a password.
If this fails with an error message, try
you@host:~$</font> touch ~/.cvspass</font>
to create an empty file for CVS passwords.
Check out the source with:
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs co yaz80</font>
Enter the new directory with:
you@host:~$</font> cd yaz80</font>
And build, upload to /dev/ttyS0 (COM1) and run with:
you@host:~/yaz80$</font> make</font>
Updates to the source can later be fetched doing:
you@host:~/yaz80$</font> cvs up -dAP</font>
Note: There is no blank between ':' and 'pserver:', but the forum software mangles the text, if I leave no space between ':' and 'p'. You gotta love it!
The required software to translate it all is:
<ul>
[*] BradC's bst.linux or the corresponding Windows executable (change Makefile for your system)
[*] GNU compiler collection (gcc)
[*] GNU make
[*] BISON a replacement for yacc, a parser generator.
[*] FLEX a replacement for lex, a lexical analyzer for compiler-compilers.
[*] GtkTerm in your path is fired up after running the compiled code from RAM (change Makefile to your needs)
[/list]
YAZ80 now supports reading the image files on FAT12, FAT16 and FAT32!
History:
0.0.1 first public
0.0.2 moved all registers to the cog RAM
0.0.3 shrink size by moving repeated code to cog RAM
0.0.4 extend io.spin to access SD card
0.1.0 fixed add16, shrunk hub RAM use, add RamBlade support
0.1.1 fixed sbc16/adc16 - not much more left to do until perfect bonus 10'000 pts
0.1.2 fixed DAA - perfect!?
0.2.0 add code to find hard disk images inside the FAT filesystem
0.2.1 fixed <rot/res/set> (ix/iy+disp8), though the implementation should have been okay, but it breaks exerciser
0.2.2 add timed flush to the 128 byte sector writing (1 second idle), reducing the SD 512 byte sector rewrites
0.2.3 for TriBladeProp call idle/active around SD card functions in io.spin; Add optional code to check for Z80 interrupts
0.2.4 Separate FAT fs functions from io.spin to fatfs.spin, add date/time info for the files being inspected
0.2.5 Add optional cycle counting and speed measuring to yaz80. I get abt. 1,4MHz on the DracBlade with CP/M ;-P
0.2.6 Found a bug in SRL (IX/IY+disp8); it was calling alu_rlc - a copy+paste bug. Doesn't fix the opcode group, though
0.3.0 Fixed the shift/rotate bug after reading the Propeller manual. Note to self: do that more often.
0.3.1 Add support for interrupt modes 0, 1 and 2. Changed I/O to use a single long for inter cog communication
0.3.2 Support a bastard 8080 CPU, i.e. one without Z80 opcodes except DJNZ and JR <cond>
0.3.3 Got the PS/2 keyboard interface working on the DracBlade. RamBlade still doesn't work.
0.3.4 Working on a TV 80x24 display and VT100 terminal emulation. It's halfway done. Out of cogs again, so no Keyboard or no TV text...
0.3.6 Fixed the bug causing Wordstar to send broken escape sequences. It was ADD16, i.e. ADD HL,BC or ADD IY,SP.
0.3.7 Fixed a bug in ADC16/SBC16 that could leave H with a value > $FF, which is - of course - impossible for an 8bit register
0.3.8 Not released - tried to reduce cog memory, rearranged some TRS80 specific code, broke ADC16/SBC16 again.
0.3.9 ADC16/SBC16 fixed again. The exerciser is happy with everything, except INI/IND/INIR/INDR and OUTI/OUTD/OTIR/OTDR
0.3.10 Add CPU_8085 flag and opcodes, so you can now chose between CPU_Z80, CPU_8080 and CPU_8085
That's all for now. The attachment will have the latest version, updated from time to time.
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 4/1/2010 10:58:28 AM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
How does he do it???
I guess, like Cluso, I've got to ask about speed. There are many models, but the fastest one is the one that wins. Though smaller is good too, especially if it frees up the 10-20 longs needed to run banked memory. Which I think LMM already does easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
That 4 COG version I tried was put together in a day or so just by copy and pasting from the version before. Likewise for the ZiCog we have now. Of course shaking out all the last remaining "features" might take longer....
I'm fascinated to see the results. ZiCog has had a good run but there is always a new kid on the block [noparse]:)[/noparse]
We don't need 10 longs to do banked memory which ever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW: I'd like to add the DracBlade memory access to yaz80, too, of course. Unfortunately the Prop isn't detected on the serial port (using bstc). Any idea what I may be doing wrong?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I use BST on windows via Comm1 via a three transistor interface, often the first connect atempt fails but the second onwards are ok (I wonder if the baud rate is being learnt)
Anyway, It is coming up towards lunchtime there, have you finished that total re-write yet?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Excellent.
Re "Anyway, It is coming up towards lunchtime there, have you finished that total re-write yet?"
Lucky Toby is not your boss, eh?
Re BST - which board, which circuit, real RS232 or serial adaptor, and windows or ubuntu??
Dracblade works fine with real rs232 and usb serial adaptor.
It won't work if another program is using the serial port. I get trapped by that one sometimes.
Not finding a propeller - maybe the propeller isn't working? What circuit are you using? Was it working before??
They finally let me out of work. I'm happily coding an xmodem variant in basic on the propeller while listening to Rammstein. Life doesn't get much better than this!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Your board. Female Sub-D connector to real RS232, Ubuntu 9.10. BST says no prop detected.
Running CP/M off the SD it works with 19k2, so it can't be all that bad. Perhaps the reset circuit?
Tried again with the 19k2 terminal: every key I send resets the prop. Wrong cabling? But how should my board then have been working!?
Ok, toggling DTR manually from the terminal resets the prop, too. But why is it resetting when I send a character?
I couldn't, it arrived this morning (local time). It's YOUR board. My PropRPB works fine with the RS232 cable I made, DracBlade doesn't seem to want to.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 11:22:55 AM GMT
What is the pinout of the RS232 cable you have? Sounds like pin 3 and 4 crossed or joined if resetting when data going from PC to the board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/19/2010 11:32:50 AM GMT
Ok, I managed to overwrite the EEPROM with the Python script Loader.py, and after that also bstc is able to find the prop. It looks like the bootstrap code had no chance to download anything after a reset. It always just said:
Timeout Failed at read 1
No Propeller detected on port /dev/ttyS0
Now it seems to work, so I can test the external RAM access.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 11:39:55 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Anyway, I'll find out what the reason for this is/was later on. First I'll play around a bit with latches and RAM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
www.smarthome.viviti.com/files/documents/Propeller_v5.pdf
and this is the code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yep, I found it in an archive of yours. I'll have a top level #define DracBladeProp which enables the necessary things.
It's getting tight in the cog RAM with latched memory addresses. I have to optionally throw out some "kernel code" with debugging on. Without debugging it still fits.
What's not so nice is that BSTC only every now and then manages to upload to the DracBlade - perhaps 1 out of 10 times. Either BSTC's timing is too tight, or the reset is different from how the PropRPM does it. Are there any things to try? Bigger capacitor on the DTR line perhaps? Or even with a resistor instead? Or without the transistor at all? It isn't fun developing code when the uploads fail most of the times :-/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
My version is a little older - 15th Jan.
And I'm using windows rather than ubuntu.
Try a bigger cap on the reset line?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Isn't there a reset from DTR, or something else, as an option ?
As for being a slave driver, I have just got back from the pub. The first of many practice "Goodbyes" to the guys I work with. Hic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
No, it's not an option, it's a must. BSTC resets the Propeller to activate the builtin boot loader. I then sends data to either RAM, or to write to the EEPROM, and/or to run it. I'm using the option to write to the RAM, because I do dozens of builds a day.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
A proper RS232 interface inverts the signal coming from the port prior to it being introduced to the transistor via the cap on the base.
The FTDI circuit uses the correct TTL levels. bst[noparse][[/noparse]c] makes the reset pulse longer than the pulse from the prop tool to accommodate some scheduling issues with OSX. This might pose a problem for "budget" reset circuits, but works perfectly on FTDI based devices (which are all I have). I guess I need to build an RS232-Prop interface to test with <sigh>.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
A perhaps helpful hint: The python script Loader.py that someone posted to the forums manages to talk to the DracBlade. It usually fails once, though, and only in the second try uploads to the EEPROM. And after that script succeeded, I can upload with BSTC to RAM exactly once. It looks to me as if there is some ttySx control or state that is different after the script has been run?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
That could be an important clue.
1) what is the timing?
2) If the signal is inverted, is it resetting on the trailing edge rather than the leading edge, and if so, is this now not leaving enough time?
So if variables are going to be adjusted, I see two variables, not one.
1) The length of the reset pulse
2) The delay from the reset pulse to the start of the download.
In addition, there are different circuits around.
www.parallax.com/Portals/0/Downloads/docs/prod/prop/SerialtoPropeller.pdf
Note the 10k between DTR and reset. I think its function is to borrow the -12V from the DTR line to keep pin 2 resting at -12V. Then the 3906 pulls it up to 3V3 as needed.
But I am not sure how pulses on DTR then go and affect the Rx line. I wanted a circuit that did not couple the DTR line and the Rx line in any way, so this 10k is not on the dracblade circuit. Since the max232 already is creating the correct voltages, borrowing negative volts from other lines is not necessary.
The dracblade download circuit comes from the pocketerm circuit www.brielcomputers.com/wik/images/0/01/PTschematic.pdf
I need to check with Brad - do you have direct control over the DTR line, and if so, is its resting state -12V and you make it +12V to reset, or is the signal inverted? Could you give us a setting in bst where you can adjust the polarity, reset pulse width and delay between reset pulse and the start of download?
@pullmoll, I am presuming you don't have windows so you can't run the standard proptool program and test if that works?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/19/2010 11:46:38 PM GMT
If it is RESET timing's problems with to longht reset time from BST YOU can experiment with change RESET Capacitor to litle smaller capacitanse.
That can compensate reset pulse time
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I have Windows, yes. Need to reboot my box. I'll give it a try and report in this post how it behaves.
Edit: It works like a charm with Parallax' Prop Tool. Not one failure in 10-15 tries to upload to RAM.
FWIW: In the terminal the reset happens when DTR goes high. I can toggle it off without any effect, then toggling it on resets the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 12:28:19 AM GMT
Did you have similar experiences or is this just a guess? I'll see if I can find anything smaller than .01µF in my shland box
Edit: No difference with an 1nF cap, i.e. 1/10th of the original value. If it is the wrong edge of the DTR pulse, then I won't change anything with another cap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 12:24:59 AM GMT
On the FTDI devices, the resting state is GND. You set it high to reset. I twiddle it a bit before hand to work around some other misc OS bugs. The direct output from the RS232 port is of course inverted.
I'm not keen at all on making any of the communications or reset sequences configurable. It must just work *all* the time.
I'm sure if I can build one of those RS232-Prop circuits I can get it on the CRO and make it work as reliably as the Prop Plug, but I need some time to sit down and build it, and time is something I'm short of right now. Like I said in the bst thread, I test the detect/load 20,000 times in my regression test, so I'm sure I can tweak it to make it work on all hardware variants.
It would be working after the Python loader as it would leave the DTR in a different state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I not had problems to short pulse if edge of it was correct.
BUT not had problems with wrong DTR polarity
Regards
On SerPlug I and Bill Henning have build we can select If it is RTS else DTR that will triger Reset and none of them have that problems You describe.
BUT I Only tested it ON Windows.
It is one thing to consider from that You describe that Yours Linux else one of programs initiate Serial Port's DTR signal line in bad way ( (Pulse it only istead of change state from inactive to active else not activate it at als). Some of Programs need DTR be Connected to DSR to work to work correctly.
Have You LED's connected to TX and RX to see if In casses of problems Program transmit anything at als.
Regards
Christoffer J
PS. I see You use BSTC with script in Linux - Have You posibility to Control Serial Port TTYx Initial state in it. If so You can tray Reset initial DTR state to HIGH - Inactive before You CALL - BSTC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/20/2010 1:38:31 AM GMT
Ok, I think we're close to the reason now. I have to read a few man pages if I can change DTR before running BSTC. It's not exactly a script but a Makefile that calls BSTC, i.e. I just type "make" to build and upload a new version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Exactly. This is what I wrote in your thread. Loader.py leaves DTR=0 all the time and also when exiting. I thought that perhaps stty has a command to modify the DTR line, but it doesn't seem so. Right now I'm just calling Loader.py to fail before calling BSTC and this awful hack works for me [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Sorry - I have one question to YOU that Not are Propeller related.
You not need answer if You not like it.
Question.
As I read in one post from YOU Yours Family comme from Finland - Why I ask is as first time I see YOUrs Picture I think It is my FRIEND that started with propeller and nos say me anything - YOU are very like HIM. I needed look on his PICTURE to be sure at it is not he so like it is.
Know You if You still have any family in FINLAND ad what City else part of Finlad them come ?
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
That was just a JOKE - we were talking about drinking alcohol and I jokingly said I think my ancestors came from Finland.
HTH,
Juergen (born in Bonn, Germany, still living in Bonn, and all of the family coming from close around Bonn)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.