Jump to content

Recommended Posts

Posted (edited)
5 hours ago, evank said:

Guys, I'm confused about something. Is this link (https://datamuseum.dk/wiki/Bits:30003061) the actual Lego Lines for Piccoline software? If so, then could someone run it in an emulator (or whatever) and show us a screenshot?

If it's not the software, then is all of the excitement over a one-line mention in a book? Just because something was mentioned doesn't mean it ever actually shipped (there is a Lego catalog mentioning MSX but no reason to believe they ever delivered this.)

That's the image of the legolines disk for the piccoline computer for sure. There is the legolines.bin file in the download section. 

This the direct dowload link

https://datamuseum.dk/bits/30003061

This is the content of the disk

https://datamuseum.dk/aa/cpm/30003061.html

This is the online emulator.

http://retroweb.maclab.org/?emulator=pce-rc759

 

I have just sent a request for help with the legolines image disk to the creator of the Rc piccoline emulator.

Edited by amine
Posted
5 hours ago, evank said:

f it's not the software, then is all of the excitement over a one-line mention in a book? Just because something was mentioned doesn't mean it ever actually shipped

Well, as @amine has now posted, it's all there. This is where the excitement comes from :D Secondly, the screenshot he posted shows the actual LEGO order numbers for the cable and the instructions for the RC759.

I was too dumb to navigate the Danish site - but now it simply is all there, as we have the links. And we have the emulator for the RC759 on the rc700 site. I guess the emulator will freeze when not finding Interface A, as it does with TC Controller in the C64 emulator, even if the COMAL80 v2.01 is virtually inserted; it shows the splash screen, but then freezes up. If there is machine code looking for IntA using some register checking, then yes, it may do so.

I also believe that TLG really was initially looking for Danish school computers as well as generally for all other systems.

On another thought: TC Controller for the PC (I guess this is what @evank and @alexGS are referring to as the German "Steuern und Regeln mit LEGO Lines und dem TC Controller" book, they obtained from the original authors Albrecht/Hödl) is a memory resident PC program residing in the upper memory. There is also a little program that allows direct control of the outputs and inspection of the input status of IntA, but the idea of TC Controller is getting transparent access to the I/O of IntA through Pascal, Basic, Comal etc. via commands rather than PEEK/POKE. This is how I understand TC Controller. 

As TC Controller for the C64/C128 needs the COMAL80 v2.01 cartridge to function properly (this cartridge provides extra memory) may infer that the TC Controller could also be a memory resident program on the C64. 

Well could be.

Best
Thorsten

 

Posted (edited)

 

8 hours ago, evank said:

Guys, I'm confused about something. Is this link (https://datamuseum.dk/wiki/Bits:30003061) the actual Lego Lines for Piccoline software? If so, then could someone run it in an emulator (or whatever) and show us a screenshot?

If it's not the software, then is all of the excitement over a one-line mention in a book? Just because something was mentioned doesn't mean it ever actually shipped (there is a Lego catalog mentioning MSX but no reason to believe they ever delivered this.)

image.png

Done !!

Edited by amine
Posted (edited)

Thank you @amine.

Google translated https://datamuseum.dk/wiki/RC_Piccoline into English for me. In the Architecture section, it says: "The operating system is Concurrent CP/M 86 (CCP/M). This was later updated to Concurrent DOS, which made it possible to run text-based DOS programs." The same page elaborates ("The Use of Piccoline" section), "In 1987 it became possible to run Concurrent DOS (C-DOS) on the Piccolines."

Lego released Interface A starting in 1986-1987. So I have to wonder if Lego Lines for Piccoline is a translated version of Lego Lines for the PC, not an entirely different program.

I'm not trying to minimize @Amine's research, I just want to understand exactly what has been found: should we consider this another brand/model of computer that Lego endorsed for Interface A, or just a Lego Lines for PC offshoot, since the company was in Lego's backyard of Denmark?

It would help to see any copyright information in the Lego Lines for Piccoline software or manuals.

Edited by evank
Posted (edited)
7 hours ago, evank said:

Thank you @amine.

Google translated https://datamuseum.dk/wiki/RC_Piccoline into English for me. In the Architecture section, it says: "The operating system is Concurrent CP/M 86 (CCP/M). This was later updated to Concurrent DOS, which made it possible to run text-based DOS programs." The same page elaborates ("The Use of Piccoline" section), "In 1987 it became possible to run Concurrent DOS (C-DOS) on the Piccolines."

Lego released Interface A starting in 1986-1987. So I have to wonder if Lego Lines for Piccoline is a translated version of Lego Lines for the PC, not an entirely different program.

I'm not trying to minimize @Amine's research, I just want to understand exactly what has been found: should we consider this another brand/model of computer that Lego endorsed for Interface A, or just a Lego Lines for PC offshoot, since the company was in Lego's backyard of Denmark?

It would help to see any copyright information in the Lego Lines for Piccoline software or manuals.

I just figured out we have the manual it is the same than those just released for C64 and IBM on Dubbekaris   Blog.

Edited by amine
Posted (edited)
19 hours ago, evank said:

"The operating system is Concurrent CP/M 86 (CCP/M). This was later updated to Concurrent DOS, which made it possible to run text-based DOS programs." The same page elaborates ("The Use of Piccoline" section), "In 1987 it became possible to run Concurrent DOS (C-DOS) on the Piccolines."

Well, my take on this: CP/M as well as DOS derivatives need their hardware level adjusted code. The operating system may always look the same on the screen, but an, e.g., 80186 CPU has a different instruction set than a Z80, and so on. Much more importantly, the hardware configuration inside many CP/M systems (and DOS and so on), are mostly entirely different. But they all run CP/M, DOS etc. This may be the reason your Google translation says "possible to run text-based DOS programs": This is happening on an abstraction layer, which are all the same for different hardware configurations. 

Accessing Interface A however is a full hardware configuration dependent process. One may be using a memory mapped approach (has been done by LEGO as well as by me :pir-laugh: (ZX81)) or using the I/O space (e.g., on the IBM XT or the ZX Spectrum), if the CPU provides it.

I believe if LEGO designed Lines smartly, there are numerous modules, which are independent of the OP system, at least for the same operating system class (CP/M, DOS). Then there are modules, which are always to be tailored toward each individual hardware configuration, and toward individual languages.

One example: If I use C on >any< system capable of running a C compiler, "println" will, well print a line. If I do a change to a memory or I/O space address, it will be >purely< hardware dependent ... I/O address 925 on an XT will certainly crash a 80186 system (Compis/Scandis/Piccoline) running CP/M ...  

This is why it seems to be relatively straight forward to adapt a LEGO Lines edition to another language, as @alexGS and @amine have done. But only for one specific computer system. I mean, LEGO Lines looks identical on a C64 screen or an IBM XT (color) screen. But the software is entirely different. And it even looks differently on an RC759 screen.

Example: LEGO Lines for the C64 in Dutch is using identical code than LEGO Lines for a C64 in English, just the naming (stored in a separate file) is changing. LEGO Lines for a Compis running CPM-86 is totally different from LEGO Lines for an IBM XT running CP/M-86. I tried to run LEGO Lines for the Compis on my XT booted into CPM-86 and it just tells me "?". However, I could type out text based Compis files on the XT. I had to copy the Compis CP/M floppy format to the CP/M XT format first, of course.

So yes, I believe LEGO Lines for the RC759/CP/M is totally different from LEGO Lines for the IBM XT/CP/M. The same hold true for DOS versions, should they exist.

Hey, where are all the computer gurus??? I'm a chemist and what I am writing may all be just total garbage!!!

Anyway: Here is to feeling good :pir-huzzah2:

Best
Thorsten  

 

Edited by Toastie
Posted (edited)
5 hours ago, Toastie said:

Well, my take on this: CP/M as well as DOS derivatives need their hardware level adjusted code. The operating system may always look the same on the screen, but an, e.g., 80186 CPU has a different instruction set than a Z80, and so on. Much more importantly, the hardware configuration inside many CP/M systems (and DOS and so on), are mostly entirely different. But they all run CP/M, DOS etc. This may be the reason your Google translation says "possible to run text-based DOS programs": This is happening on an abstraction layer, which are all the same for different hardware configurations. 

Accessing Interface A however is a full hardware configuration dependent process. One may be using a memory mapped approach (has been done by LEGO as well as by me :pir-laugh: (ZX81)) or using the I/O space (e.g., on the IBM XT or the ZX Spectrum).

I believe if LEGO designed Lines smartly, there are numerous modules, which are independent of OP system, at least for the same operating system class (CP/M, DOS). Then there are modules, which always to be are tailored toward each individual hardware configuration, and toward individual languages. This is why it seems to be relatively straight forward to adapt a LEGO Lines edition to another language, as @alexGS and @amine have done. But only for one specific computer system. I mean, LEGO Lines looks identical on a C64 screen or an IBM XT (color) screen. But the software is entirely different. And it even looks differently on an RC759 screen.

Example: LEGO Lines for the C64 in Dutch is using identical code than LEGO Lines for a C64 in English, just the naming (stored in a separate file) is changing. LEGO Lines for a Compis running CPM-86 is totally different from LEGO Lines for an IBM XT running CP/M-86. I tried to run LEGO Lines for the Compis on my XT booted into CPM-86 and it just tells me "?". However, I could type out text based Compis files on the XT. I had to copy the Compis CP/M floppy format to the CP/M XT format first, of course.

So yes, I believe LEGO Lines for the RC759/CP/M is totally different from LEGO Lines for the IBM XT/CP/M. The same hold true for DOS versions, should they exist.

Hey, where are all the computer gurus??? I'm a chemist and what I am writing may all be just total garbage!!!

Anyway: Here is to feeling good :pir-huzzah2:

Best
Thorsten  

 

reference to Lego and robotics at 30:36

Piccolinien_1986_04

Screenshot-20260625-191528-Chrome-2.jpg

Lego_vaskopg7.png

Edited by amine
Posted
5 hours ago, amine said:

Screenshot-20260625-191528-Chrome-2.jpg

 

What's the source of this?

5 hours ago, Toastie said:

Well, my take on this: CP/M as well as DOS derivatives need their hardware level adjusted code. The operating system may always look the same on the screen, but an, e.g., 80186 CPU has a different instruction set than a Z80, and so on. Much more importantly, the hardware configuration inside many CP/M systems (and DOS and so on), are mostly entirely different. But they all run CP/M, DOS etc. This may be the reason your Google translation says "possible to run text-based DOS programs": This is happening on an abstraction layer, which are all the same for different hardware configurations. 

Accessing Interface A however is a full hardware configuration dependent process. One may be using a memory mapped approach (has been done by LEGO as well as by me :pir-laugh: (ZX81)) or using the I/O space (e.g., on the IBM XT or the ZX Spectrum).

I believe if LEGO designed Lines smartly, there are numerous modules, which are independent of OP system, at least for the same operating system class (CP/M, DOS). Then there are modules, which always to be are tailored toward each individual hardware configuration, and toward individual languages. This is why it seems to be relatively straight forward to adapt a LEGO Lines edition to another language, as @alexGS and @amine have done. But only for one specific computer system. I mean, LEGO Lines looks identical on a C64 screen or an IBM XT (color) screen. But the software is entirely different. And it even looks differently on an RC759 screen.

Example: LEGO Lines for the C64 in Dutch is using identical code than LEGO Lines for a C64 in English, just the naming (stored in a separate file) is changing. LEGO Lines for a Compis running CPM-86 is totally different from LEGO Lines for an IBM XT running CP/M-86. I tried to run LEGO Lines for the Compis on my XT booted into CPM-86 and it just tells me "?". However, I could type out text based Compis files on the XT. I had to copy the Compis CP/M floppy format to the CP/M XT format first, of course.

So yes, I believe LEGO Lines for the RC759/CP/M is totally different from LEGO Lines for the IBM XT/CP/M. The same hold true for DOS versions, should they exist.

Hey, where are all the computer gurus??? I'm a chemist and what I am writing may all be just total garbage!!!

Anyway: Here is to feeling good :pir-huzzah2:

Best
Thorsten  

 

@alexGS what do you think?

Posted (edited)
9 minutes ago, evank said:

What's the source of this?

https://ddhf.dk/wiki/Bits:30002429 then click on this link, and you get a PDF from Sep. 1986 (Danish). Inside, you'll find several Interface A references, such as order forms from Regnecentralen for the cable, interface A, software, as well as the article about Technic Control for the Piccoline computer. 

It's on the website of the "Dansk Datahistorisk Forening" (Danish Data History Association) in their wiki. The main page is https://datamuseum.dk/.

All in Danish - I do understand some of it. 

Wow.

Best
Thorsten

Edited by Toastie
Posted

Everyone,

Yes, even you @amine:laugh:

Please help me finish this table for my somewhat outdated Interface A website: https://brickhacks.com/table.htm.

Are there any mistakes? What software support should be listed that isn't? Where does "TC Controller" fit into this?

On the MSX side (not yet a table entry), I'm only interested in including this if someone's documented it for Interface A, vs. that book which discusses an entirely different homemade method.

Posted

Nineteen hours later, crickets :) ... Does anyone have comments on my chart? I'm sure there are errors and/or omissions.

Posted (edited)
2 hours ago, evank said:

Nineteen hours later, crickets :) ... Does anyone have comments on my chart? I'm sure there are errors and/or omissions.

Sorry Evan, I did try but the page didn’t open, and being a workday I didn’t have time to write this message to tell you…

It’s opened now and I don’t spot any glaring errors; I think by the same token as not including MSX, you wouldn’t include Toastie’s interfacing to Sinclair Spectrum which would be a shame not to .) perhaps you need two tables, one official and one for ‘hacks’

Edited by alexGS
Posted
1 hour ago, alexGS said:

Sorry Evan, I did try but the page didn’t open, and being a workday I didn’t have time to write this message to tell you…

It’s opened now and I don’t spot any glaring errors; I think by the same token as not including MSX, you wouldn’t include Toastie’s interfacing to Sinclair Spectrum which would be a shame not to .) perhaps you need two tables, one official and one for ‘hacks’

The difference is the MSX approach doesn't use Interface A at all, whereas @Toastie's projects do.

But I agree that there should be two tables, one for official connections and one for hacks.

Posted

Take a fresh look at the table; clear your cache/refresh if needed.

www.brickhacks.com/table.htm ... @Toastie you have your own section, at least until someone else hacks another system!

Posted (edited)
17 hours ago, evank said:

Nineteen hours later, crickets :) ... Does anyone have comments on my chart? I'm sure there are errors and/or omissions.

About the MSX support that's a mystery, there are a lot of homebrew projects but none of them  use the Lego interface. Like this one.

https://download.file-hunter.com/Technical/Hans Otten/legolift.pdf

 

https://hansotten.file-hunter.com/uploads/files/printercable.pdf

 

Do we have news on the Compis Legolines ?

Screenshot-20260627-001539-Google-2.jpg

Edited by amine
Posted (edited)
18 hours ago, evank said:

Nineteen hours later, crickets :)

Sorry Evan ... I looked at the table and initially did not find much to add. I shall have a more serious look next week. We just returned to our hotel in Paderborn - today was Nixdorf Computer Museum day - man. I am blown away ...

9 hours ago, amine said:

Do we have news on the Compis Legolines ?

I don't know exactly where we stand - news wise ;) I believe to having this posted here ???

So, Paul Findley from Sweden got in touch with Evan who got him in touch with me. Paul and I then tried to figure out a way to at least make a copy of his two Compis floppies, but it did not really work out on his DOS machine, when using the famous ANADISK and 22DISK software. 

He then sent the floppies over, and I nervously began thinking about "how to" ... 

In the end, I installed two new hardware features on my IBM XT: A TEAC FD55F floppy drive and an IDE CF LITE 4.1 ISA bus card, to get an HDD analog device on board. Mounted the CF drive onto the FD, and swapped this unit for the 2nd 5 1/4 Tandon Floppy in the XT:

640x416.jpg

640x379.jpg

The FD55F is a DS 96TPI 80T/side drive and thus compatible with the Compis floppy CP/M format holding 620 kByte formatted. The format is a bit weird, but 22DISK (A CP/M disk format and CP/M to DOS copy program) luckily has a full descriptor for the Compis format.

First I made 3 copies of each of the two Compis floppies and send them back to Paul/Sweden. Then I copied them to DOS format. This way, any computer running DOS/22DISK can make the original Compis floppies for usage in a Compis. I can't make disc images, which is also not necessary as there is no Compis emulator nor a Compis computer available for testing.

On the copies there is Lines, Comal, a Pascal file, a plot program, and tons of Lines files:

400x191.jpg

So that's where we are Compis-wise ;)

Best
Thorsten

 

 

     

Edited by Toastie
Posted (edited)
19 hours ago, Toastie said:

Sorry Evan ... I looked at the table and initially did not find much to add. I shall have a more serious look next week. We just returned to our hotel in Paderborn - today was Nixdorf Computer Museum day - man. I am blown away ...

I don't know exactly where we stand - news wise ;) I believe to having this posted here ???

So, Paul Findley from Sweden got in touch with Evan who got him in touch with me. Paul and I then tried to figure out a way to at least make a copy of his two Compis floppies, but it did not really work out on his DOS machine, when using the famous ANADISK and 22DISK software. 

He then sent the floppies over, and I nervously began thinking about "how to" ... 

In the end, I installed two new hardware features on my IBM XT: A TEAC FD55F floppy drive and an IDE CF LITE 4.1 ISA bus card, to get an HDD analog device on board. Mounted the CF drive onto the FD, and swapped this unit for the 2nd 5 1/4 Tandon Floppy in the XT:

640x416.jpg

640x379.jpg

The FD55F is a DS 96TPI 80T/side drive and thus compatible with the Compis floppy CP/M format holding 620 kByte formatted. The format is a bit weird, but 22DISK (A CP/M disk format and CP/M to DOS copy program) luckily has a full descriptor for the Compis format.

First I made 3 copies of each of the two Compis floppies and send them back to Paul/Sweden. Then I copied them to DOS format. This way, any computer running DOS/22DISK can make the original Compis floppies for usage in a Compis. I can't make disc images, which is also not necessary as there is no Compis emulator nor a Compis computer available for testing.

On the copies there is Lines, Comal, a Pascal file, a plot program, and tons of Lines files:

400x191.jpg

So that's where we are Compis-wise ;)

Best
Thorsten

 

 

     

https://github.com/mamedev/mame/blob/master/src/mame/telenova/compis.cpp

Mame emulator has support for the compis

https://www.mamedev.org/?page=20

 

The archive online emulator might be abble to run thoses images. I am going to give it a try.

Edited by amine
Posted (edited)
On 6/27/2026 at 12:04 AM, evank said:

Does anyone have comments on my chart?

Hi Evan,

browsing the chart ...

  1. Regarding the Compis: The Computer Brand is "TeleNova", the Computer Model is "Compis" (Sweden) or "Scandis" (Norway, Finland, Denmark).
  2. All my hacks are using the LEGO 20 pin ribbon cable (1:1)
  3. As per Lukazi's website as well as what @amine found, the BBC Micro cable is #9773
  4. As per the Danish datamuseum site, the Piccoline cable is #950004

Best
Thorsten 

Edited by Toastie
Posted (edited)
2 hours ago, evank said:

I updated the table: https://brickhacks.com/table.htm.

Someone explain to me where this "TC Controller" software fits in.

I’d like to test it out and start a new thread just for this :) From reading the 9760 PDF as best as I can, TC Controller is a set of commands added into COMAL that gives it similar capability to TC-Logo.

Note; it is different to the code samples included with the hardware manuals (e.g. 9765) that show BASIC and COMAL without command extensions; those rely on POKE. They are perhaps just starter examples for a situation where the full software (TC-Logo, TC Controller) had not been purchased. Remember that the special software came at a cost :)

I notice TC Controller is only used in the context of Control II (1092), while LEGO Lines is used with Control I (1090), just as we’ve previously seen in the Teacher’s Guide for the Apple II and the BBC Micro. We’ve never seen any other material dedicated to 1092 - everything else is for TC-Logo and 1090 or 9700. That’s what makes this an exciting find.

Edited by alexGS
Posted (edited)
4 hours ago, alexGS said:

From reading the 9760 PDF as best as I can, TC Controller is a set of commands added into COMAL that gives it similar capability to TC-Logo

That is my take as well. 

TC Controller for DOS is a memory resident program - at least on PC's. It is loaded into "upper" memory first and then sits there, wanting to be called from BASIC, COMAL, PASCAL etc. This is described in the Albrecht/Mödl book "Steuern und Regeln mit LEGO LInes und dem TC Controller". On a PC it also provides a console type thing, mimicking Interface A, so you can turn on/off outputs, check inputs etc.

As the C64 requires the COMAL-80 V2.01 module to work properly with TC Controller, I believe it may do something similar - occupy some memory and then waits there to be called.

As Alex can run the code on his Ultimate, we shall see!

Yes, this is really exciting!

Best
Thorsten

     

Edited by Toastie
Posted (edited)
3 hours ago, Toastie said:

That is my take as well. 

TC Controller for DOS is a memory resident program - at least on PC's. It is loaded into "upper" memory first and then sits there, wanting to be called from BASIC, COMAL, PASCAL etc. This is described in the Albrecht/Mödl book "Steuern und Regeln mit LEGO LInes und dem TC Controller". On a PC it also provides a console type thing, mimicking Interface A, so you can turn on/off outputs, check inputs etc.

As the C64 requires the COMAL-80 V2.01 module to work properly with TC Controller, I believe it may do something similar - occupy some memory and then waits there to be called.

As Alex can run the code on his Ultimate, we shall see!

Yes, this is really exciting!

Best
Thorsten

     

 

 

The 9760 also had an English version  for the bbc micro 

display.jpg

Edited by amine
Posted

Dear All,

with regard to Evans table:

The Compis cable remains to be a mystery to me.

We have the Compis technical manual. And we have the LEGO Lines manual for the Compis. The latter says on page 3 that the cable from the Interface A goes into socket J5 (control and measurement port) on the back of the Compis. J5 has 6 pins; according to the technical manual (page 41, section 3.12.6, as well as shown on the circuit diagrams in the back section), four are connected to the 8255 PIO and two to GND/+5V:

  1. to 8255 port c/0 as output
  2. to 8255 port c/1 as output
  3. GND
  4. to 8255 port b/0 as input (connected via resistor R16 to +5V = pull-up)
  5. to 8255 port b/1 as input (connected via resistor R15 to +5V = pull-up)
  6. +5V

The LEGO lines manual for the Compis says that you can control 6 outputs (motors, lights) and read 2 inputs. Now inputs are fine, but what about the outputs?

The only thing I can think of is that there is some active logic in the Compis plug that connects to the 20 pin socket of Interface A? The latter is just a TTL "amplifier" output-wise and thus two lines will not be enough for six static outputs? Pure speculation: One Compis output could be some sort of clock including a sync pulse, the other a multiplexed (one out of six transient) logic signal that is then latched accordingly?

Are there any other options?

Best
Thorsten   

Posted (edited)

Waaaay more than 24 hours later - crickets :pir-huzzah2:

OK, let me summon the usual suspects @BrickTronic, @alexGS, @maehw, @evank, @amine and many more ... :pir-skel:

Folks, what do we propose regarding just two 8255 output lines of the Compis controlling 6 Interface A outputs (i.e., its TTL inputs on the 20 pin connector)??? 

Hmm - I was thinking :pir-wink::

Fact: LEGO Lines provides no PWM control - as far as I read the replies on threads here (I am only here and on Google of course).

Question: How often does Lines read the inputs? I never used it, so maybe you guys know. Lines appears to be rather slow (which is totally fine; I love to see the progress "bar" moving!). In contrast, TC Logo reads the inputs and updates the outputs of IntA every ms per interrupt. That is demanding but allows PWM @125 Hz. A Compis could do that as well, but - this is not required for Lines.

Proposal: The data refresh rate of the Compis Lines version (or any Lines version) is rather "slow". That would allow using two 8255 outputs to actually providing some sort burst mode: Generating a burst of 6 clock pulses on line 0 and synchronously emit 6 bits (0/1) for the 6 IntA outputs. Representing some sort of a 6 bit serial protocol. This then needs to be latched into a (6 bit) D-flip-flop device of course to make it static for the time between bursts.

At the presumably comparably low update rate, there is no need for synching: Reset on startup, and then just do the 8 cycle dance: Read two bits (the two 8255 inputs), generate 6 pulses on line 0 and latch the info on line 1 of the 8255 outputs.

Which of course requires some circuitry in the Compis plug for IntA; +5V and GND are provided. As we are in 1996, this should be feasible?

Any thoughts?

Best
Thorsten 

 

Edited by Toastie
Posted

I understand your concept about making it fit by running slower, but beyond that you're over my head with those electrical details.

1996? You mean 1986.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...