Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46626 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2016-04-11 15:32 -0400 |
| Last post | 2016-05-21 22:32 -0400 |
| Articles | 20 on this page of 146 — 19 participants |
Back to article view | Back to comp.lang.forth
Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-11 15:32 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-14 08:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 12:43 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-14 17:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 21:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 11:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 10:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 mhx@iae.nl - 2016-04-15 10:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:33 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-18 17:59 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-19 03:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 00:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:27 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 06:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-18 21:47 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-21 01:27 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-20 21:12 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-20 15:54 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-20 19:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-21 17:13 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-21 22:26 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-22 11:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-22 14:47 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-22 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 01:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 15:11 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 16:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 22:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 21:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 00:53 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-04-24 14:59 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 22:15 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 20:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-24 20:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 18:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-30 08:39 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 13:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 11:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-02 16:31 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 16:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-02 16:49 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 09:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 10:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 14:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 14:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 16:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 16:28 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-03 13:37 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-05 02:56 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-05 23:56 +0100
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-06 08:42 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:00 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-06 13:56 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 03:48 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-07 14:05 +0100
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 08:34 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 pahihu <pahihu@gmail.com> - 2016-05-08 12:22 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 12:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 11:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 15:23 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 17:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:38 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 15:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 18:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:20 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 13:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 14:57 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-05-03 10:58 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-03 21:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:21 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:21 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:40 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:29 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 19:03 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 10:42 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 15:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 16:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 21:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-27 01:18 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 09:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-27 09:48 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-28 23:23 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 stephen@mpeforth.com (Stephen Pelc) - 2016-04-23 12:10 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 08:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-23 13:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-23 21:33 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 09:47 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "WJ" <w_a_x_man@yahoo.com> - 2016-04-25 07:24 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 16:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 03:15 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 11:22 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 07:48 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 12:05 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 10:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 10:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:27 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 11:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:52 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:25 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 10:06 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 11:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 02:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-28 00:43 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 11:53 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-04-28 18:39 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 17:02 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 13:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 16:49 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 18:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 22:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 09:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Coos Haak <chforth@hccnet.nl> - 2016-04-27 23:45 +0200
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-29 07:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-16 18:48 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Cecil Bayona <cbayona@cbayona.com> - 2016-05-17 14:28 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-21 22:32 -0400
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-20 19:03 -0400 |
| Message-ID | <nf91l7$11d$1@dont-email.me> |
| In reply to | #46698 |
On 4/20/2016 6:54 PM, visualforth@rocketmail.com wrote: > On Wednesday, April 20, 2016 at 5:16:19 PM UTC-4, Bernd Paysan wrote: >> >> I'm old enough that CPUs like 8080, Z80 or 6502 were something I learned >> when I was young, and my reaction back then was that they were really >> awful, and cumbersome to program, and too small to be useful. When you >> then look at Forth processors, it is even worse: These processors are >> both considerably smaller and simpler than an 8080 (both conceptually and >> from the number of gates), *and* more useful. >> > I started programming with MOS TECHNOLOGY's 6502 KIM, I am glad I did, and I am thankful for this opportunity. > > The orthogonal command set with 13 addressing modes was easy to learn and easy to use. But most people I knew used the 80xx line, because it was main stream. > I heard about their problems, their complaints, and I was wondering. I never had such problems with the 6502. > > Later I was asked to teach microprocessing at the GRUNDIG academy. They only had 8080 boards for teaching. So I had to teach my students 8080 assembly. > I did my best, they learned it, but I finally was totally happy that I professionally used the 65xx line only. Once I had a request to program a 8085 board, and I was glad this project got cancelled. > > With the arrival of RSC-Forth I switched over to Forth programming, and I could use all my standard machine language programs - like barcode and magstripe reader - with Forth. > > But the best in my career was the RTX2000. No machine language programs needed, everything in plain Forth. That was like feeling to be in heaven. > It's a pity that there is no real Forth micro with a RTX2000 like CPU available any more. With such a Forth micro programming would be much easier and faster. Why can't you program in Forth on other CPUs just as easily? I think what you are expressing is appreciation of the compiler more than the CPU. If you had a compiler that worked as well, I think the choice of CPU is not so important. I write code that talks to the hardware and I've never needed to use assembly. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-21 17:13 -0700 |
| Message-ID | <2e10ffb5-6f07-44b7-83cd-c93af6823de6@googlegroups.com> |
| In reply to | #46699 |
On Wednesday, April 20, 2016 at 7:03:16 PM UTC-4, rickman wrote: > On 4/20/2016 6:54 PM, visualforth.com wrote: > > On Wednesday, April 20, 2016 at 5:16:19 PM UTC-4, Bernd Paysan wrote: > >> > >> I'm old enough that CPUs like 8080, Z80 or 6502 were something I learned > >> when I was young, and my reaction back then was that they were really > >> awful, and cumbersome to program, and too small to be useful. When you > >> then look at Forth processors, it is even worse: These processors are > >> both considerably smaller and simpler than an 8080 (both conceptually and > >> from the number of gates), *and* more useful. > >> > > I started programming with MOS TECHNOLOGY's 6502 KIM, I am glad I did, and I am thankful for this opportunity. > > > > The orthogonal command set with 13 addressing modes was easy to learn and easy to use. But most people I knew used the 80xx line, because it was main stream. > > I heard about their problems, their complaints, and I was wondering. I never had such problems with the 6502. > > > > Later I was asked to teach microprocessing at the GRUNDIG academy. They only had 8080 boards for teaching. So I had to teach my students 8080 assembly. > > I did my best, they learned it, but I finally was totally happy that I professionally used the 65xx line only. Once I had a request to program a 8085 board, and I was glad this project got cancelled. > > > > With the arrival of RSC-Forth I switched over to Forth programming, and I could use all my standard machine language programs - like barcode and magstripe reader - with Forth. > > > > But the best in my career was the RTX2000. No machine language programs needed, everything in plain Forth. That was like feeling to be in heaven. > > It's a pity that there is no real Forth micro with a RTX2000 like CPU available any more. With such a Forth micro programming would be much easier and faster. > > Why can't you program in Forth on other CPUs just as easily? I think > what you are expressing is appreciation of the compiler more than the > CPU. If you had a compiler that worked as well, I think the choice of > CPU is not so important. > > I write code that talks to the hardware and I've never needed to use > assembly. > > -- > > Rick What hardware are you using? When I started using Forth, the 6502 had a 2MHz clock, later the M38049 had 8MHz, but still needed assembly language for the serial line, barcode and magstripe needed it, too. Now I have a project with audio, sampling speech. The MSP430 which I am using needs assembly language to do this. I programmed a 2MBaud fiber optic link with the RTX2000, running at 8MHz, without a problem. What is the highest speed of your I/O? What micro are you using with which Forth?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-21 22:26 -0400 |
| Message-ID | <nfc1tj$oq1$1@dont-email.me> |
| In reply to | #46706 |
On 4/21/2016 8:13 PM, visualforth@rocketmail.com wrote: > On Wednesday, April 20, 2016 at 7:03:16 PM UTC-4, rickman wrote: >> On 4/20/2016 6:54 PM, visualforth.com wrote: >>> On Wednesday, April 20, 2016 at 5:16:19 PM UTC-4, Bernd Paysan wrote: >>>> >>>> I'm old enough that CPUs like 8080, Z80 or 6502 were something I learned >>>> when I was young, and my reaction back then was that they were really >>>> awful, and cumbersome to program, and too small to be useful. When you >>>> then look at Forth processors, it is even worse: These processors are >>>> both considerably smaller and simpler than an 8080 (both conceptually and >>>> from the number of gates), *and* more useful. >>>> >>> I started programming with MOS TECHNOLOGY's 6502 KIM, I am glad I did, and I am thankful for this opportunity. >>> >>> The orthogonal command set with 13 addressing modes was easy to learn and easy to use. But most people I knew used the 80xx line, because it was main stream. >>> I heard about their problems, their complaints, and I was wondering. I never had such problems with the 6502. >>> >>> Later I was asked to teach microprocessing at the GRUNDIG academy. They only had 8080 boards for teaching. So I had to teach my students 8080 assembly. >>> I did my best, they learned it, but I finally was totally happy that I professionally used the 65xx line only. Once I had a request to program a 8085 board, and I was glad this project got cancelled. >>> >>> With the arrival of RSC-Forth I switched over to Forth programming, and I could use all my standard machine language programs - like barcode and magstripe reader - with Forth. >>> >>> But the best in my career was the RTX2000. No machine language programs needed, everything in plain Forth. That was like feeling to be in heaven. >>> It's a pity that there is no real Forth micro with a RTX2000 like CPU available any more. With such a Forth micro programming would be much easier and faster. >> >> Why can't you program in Forth on other CPUs just as easily? I think >> what you are expressing is appreciation of the compiler more than the >> CPU. If you had a compiler that worked as well, I think the choice of >> CPU is not so important. >> >> I write code that talks to the hardware and I've never needed to use >> assembly. >> >> -- >> >> Rick > > What hardware are you using? > When I started using Forth, the 6502 had a 2MHz clock, later the M38049 had 8MHz, but still needed assembly language for the serial line, barcode and magstripe needed it, too. Why? If it was on an Intel type processor I/O is through special instructions that the Forth programming model does not support directly. Otherwise CPUs have memory mapped I/O which can be done from Forth. > Now I have a project with audio, sampling speech. The MSP430 which I am using needs assembly language to do this. Again, why? > I programmed a 2MBaud fiber optic link with the RTX2000, running at 8MHz, without a problem. > > What is the highest speed of your I/O? > What micro are you using with which Forth? I use serial ports often or Bluetooth. The I/O is not so fast. Are you saying you have to use assembly because of speed? The processors I use run a lot faster than 10 MHz. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-22 11:35 -0700 |
| Message-ID | <cd050275-266e-4b00-bee6-604f87c2be8f@googlegroups.com> |
| In reply to | #46707 |
On Thursday, April 21, 2016 at 10:26:09 PM UTC-4, rickman wrote: > On 4/21/2016 8:13 PM, visualforth.com wrote: > > On Wednesday, April 20, 2016 at 7:03:16 PM UTC-4, rickman wrote: > >> On 4/20/2016 6:54 PM, visualforth.com wrote: > >>> On Wednesday, April 20, 2016 at 5:16:19 PM UTC-4, Bernd Paysan wrote: > >>>> > >>>> I'm old enough that CPUs like 8080, Z80 or 6502 were something I learned > >>>> when I was young, and my reaction back then was that they were really > >>>> awful, and cumbersome to program, and too small to be useful. When you > >>>> then look at Forth processors, it is even worse: These processors are > >>>> both considerably smaller and simpler than an 8080 (both conceptually and > >>>> from the number of gates), *and* more useful. > >>>> > >>> I started programming with MOS TECHNOLOGY's 6502 KIM, I am glad I did, and I am thankful for this opportunity. > >>> > >>> The orthogonal command set with 13 addressing modes was easy to learn and easy to use. But most people I knew used the 80xx line, because it was main stream. > >>> I heard about their problems, their complaints, and I was wondering. I never had such problems with the 6502. > >>> > >>> Later I was asked to teach microprocessing at the GRUNDIG academy. They only had 8080 boards for teaching. So I had to teach my students 8080 assembly. > >>> I did my best, they learned it, but I finally was totally happy that I professionally used the 65xx line only. Once I had a request to program a 8085 board, and I was glad this project got cancelled. > >>> > >>> With the arrival of RSC-Forth I switched over to Forth programming, and I could use all my standard machine language programs - like barcode and magstripe reader - with Forth. > >>> > >>> But the best in my career was the RTX2000. No machine language programs needed, everything in plain Forth. That was like feeling to be in heaven. > >>> It's a pity that there is no real Forth micro with a RTX2000 like CPU available any more. With such a Forth micro programming would be much easier and faster. > >> > >> Why can't you program in Forth on other CPUs just as easily? I think > >> what you are expressing is appreciation of the compiler more than the > >> CPU. If you had a compiler that worked as well, I think the choice of > >> CPU is not so important. > >> > >> I write code that talks to the hardware and I've never needed to use > >> assembly. > >> > >> -- > >> > >> Rick > > > > What hardware are you using? > > When I started using Forth, the 6502 had a 2MHz clock, later the M38049 had 8MHz, but still needed assembly language for the serial line, barcode and magstripe needed it, too. > > Why? If it was on an Intel type processor I/O is through special > instructions that the Forth programming model does not support directly. > Otherwise CPUs have memory mapped I/O which can be done from Forth. > > > > Now I have a project with audio, sampling speech. The MSP430 which I am using needs assembly language to do this. > > Again, why? > > > > I programmed a 2MBaud fiber optic link with the RTX2000, running at 8MHz, without a problem. > > > > What is the highest speed of your I/O? > > What micro are you using with which Forth? > > I use serial ports often or Bluetooth. The I/O is not so fast. Are you > saying you have to use assembly because of speed? The processors I use > run a lot faster than 10 MHz. > > -- > > Rick Yes, I only use assembly when Forth isn't fast enough. I learned this more than thirty years ago. Most of the time I worked with small micros, with one exception: a project where I used an ARM micro from MPE for 3phase PWM, not needing assembly. Sorry about the confusion.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-22 14:47 -0400 |
| Message-ID | <nfdrcp$d5f$1@dont-email.me> |
| In reply to | #46713 |
On 4/22/2016 2:35 PM, visualforth@rocketmail.com wrote: > On Thursday, April 21, 2016 at 10:26:09 PM UTC-4, rickman wrote: >> On 4/21/2016 8:13 PM, visualforth.com wrote: >>> On Wednesday, April 20, 2016 at 7:03:16 PM UTC-4, rickman wrote: >>>> On 4/20/2016 6:54 PM, visualforth.com wrote: >>>>> On Wednesday, April 20, 2016 at 5:16:19 PM UTC-4, Bernd Paysan wrote: >>>>>> >>>>>> I'm old enough that CPUs like 8080, Z80 or 6502 were something I learned >>>>>> when I was young, and my reaction back then was that they were really >>>>>> awful, and cumbersome to program, and too small to be useful. When you >>>>>> then look at Forth processors, it is even worse: These processors are >>>>>> both considerably smaller and simpler than an 8080 (both conceptually and >>>>>> from the number of gates), *and* more useful. >>>>>> >>>>> I started programming with MOS TECHNOLOGY's 6502 KIM, I am glad I did, and I am thankful for this opportunity. >>>>> >>>>> The orthogonal command set with 13 addressing modes was easy to learn and easy to use. But most people I knew used the 80xx line, because it was main stream. >>>>> I heard about their problems, their complaints, and I was wondering. I never had such problems with the 6502. >>>>> >>>>> Later I was asked to teach microprocessing at the GRUNDIG academy. They only had 8080 boards for teaching. So I had to teach my students 8080 assembly. >>>>> I did my best, they learned it, but I finally was totally happy that I professionally used the 65xx line only. Once I had a request to program a 8085 board, and I was glad this project got cancelled. >>>>> >>>>> With the arrival of RSC-Forth I switched over to Forth programming, and I could use all my standard machine language programs - like barcode and magstripe reader - with Forth. >>>>> >>>>> But the best in my career was the RTX2000. No machine language programs needed, everything in plain Forth. That was like feeling to be in heaven. >>>>> It's a pity that there is no real Forth micro with a RTX2000 like CPU available any more. With such a Forth micro programming would be much easier and faster. >>>> >>>> Why can't you program in Forth on other CPUs just as easily? I think >>>> what you are expressing is appreciation of the compiler more than the >>>> CPU. If you had a compiler that worked as well, I think the choice of >>>> CPU is not so important. >>>> >>>> I write code that talks to the hardware and I've never needed to use >>>> assembly. >>>> >>>> -- >>>> >>>> Rick >>> >>> What hardware are you using? >>> When I started using Forth, the 6502 had a 2MHz clock, later the M38049 had 8MHz, but still needed assembly language for the serial line, barcode and magstripe needed it, too. >> >> Why? If it was on an Intel type processor I/O is through special >> instructions that the Forth programming model does not support directly. >> Otherwise CPUs have memory mapped I/O which can be done from Forth. >> >> >>> Now I have a project with audio, sampling speech. The MSP430 which I am using needs assembly language to do this. >> >> Again, why? >> >> >>> I programmed a 2MBaud fiber optic link with the RTX2000, running at 8MHz, without a problem. >>> >>> What is the highest speed of your I/O? >>> What micro are you using with which Forth? >> >> I use serial ports often or Bluetooth. The I/O is not so fast. Are you >> saying you have to use assembly because of speed? The processors I use >> run a lot faster than 10 MHz. >> >> -- >> >> Rick > > Yes, I only use assembly when Forth isn't fast enough. > I learned this more than thirty years ago. > > Most of the time I worked with small micros, with one exception: a project where I used an ARM micro from MPE for 3phase PWM, not needing assembly. > Sorry about the confusion. No confusion. I don't find much need to use assembly since the speed of modern MCUs are much faster than they were when the RTX2000 was designed. There is also a wide range of processors out there that will run at very high speeds. If I need a faster processor, I use a faster processor. MPE has a clean room implementation of the RTX. I'm sure they charge for it or I would be interested n playing with it. FPGAs allow many things to be studied that would have required a full eval board at one time. FPGAs are cheap and common as evidenced by Ting's workshop in FPGA development being presented at SVFIG. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-22 12:51 -0700 |
| Message-ID | <87fuudmngf.fsf@nightsong.com> |
| In reply to | #46714 |
rickman <gnuarm@gmail.com> writes: > MPE has a clean room implementation of the RTX. I'm sure they charge > for it or I would be interested n playing with it. No idea about an FPGA implementation but a software emulation should be pretty easy to do, and on a Cortex M or A at high enough clock, would be faster than a real RTX. Duplicating the RTX instruction timing exactly might not be easy, however. I don't know how likely that is to matter.
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 01:55 -0700 |
| Message-ID | <1167dcd8-e973-4998-bbeb-502c6fb1b0e8@googlegroups.com> |
| In reply to | #46715 |
On Friday, April 22, 2016 at 8:51:30 PM UTC+1, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > MPE has a clean room implementation of the RTX. I'm sure they charge > > for it or I would be interested n playing with it. > > No idea about an FPGA implementation but a software emulation should be > pretty easy to do, and on a Cortex M or A at high enough clock, would be > faster than a real RTX. Duplicating the RTX instruction timing exactly > might not be easy, however. I don't know how likely that is to matter. Paul, if you is so easy as you say to do RTX in software - why do you not just do it and prove how easy it is? Timing does not matter as a first step. RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. So I can tell the kids on 11 June at the Maker Fair in Bristol when we build more MicroBoxes: load this software and you have the same processor that landed Philae on the Asteroid - and as we will build about 50 - thia would be more Processing Power and probably faster that what was on there - including the carrier ... Looking forward to a solution. You would be famous with the kids http://www.ukesf.org/news/ukesf-joins-digimakers-microbox-project-kit/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-23 15:11 -0700 |
| Message-ID | <8737qcm0vh.fsf@nightsong.com> |
| In reply to | #46716 |
JUERGEN <epldfpga@aol.com> writes: > RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. Might not be feasible on those small parts. I was thinking more like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > So I can tell the kids on 11 June at the Maker Fair in Bristol when we > build more MicroBoxes: load this software and you have the same > processor that landed Philae on the Asteroid Doesn't seem like a convincing application. Why would they care about running the weird RTX instruction set? Main reason I can think of to want it is you have a pile of RTX software that you want to keep using.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-23 18:50 -0400 |
| Message-ID | <nfgu0n$c1e$1@dont-email.me> |
| In reply to | #46722 |
On 4/23/2016 6:11 PM, Paul Rubin wrote: > JUERGEN <epldfpga@aol.com> writes: >> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > > Might not be feasible on those small parts. I was thinking more > like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > >> So I can tell the kids on 11 June at the Maker Fair in Bristol when we >> build more MicroBoxes: load this software and you have the same >> processor that landed Philae on the Asteroid > > Doesn't seem like a convincing application. Why would they care about > running the weird RTX instruction set? Main reason I can think of to > want it is you have a pile of RTX software that you want to keep using. I don't get the need to emulate one machine on another. That is essentially using a compiler based on a virtual machine (the RTX) which has already been done with Forth programming. Why not just compile directly to the target CPU and cut out the middle man? It's got to be faster and easier. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-23 16:01 -0700 |
| Message-ID | <87y484kk04.fsf@nightsong.com> |
| In reply to | #46724 |
rickman <gnuarm@gmail.com> writes: > Why not just compile directly to the target CPU and cut out the middle > man? It's got to be faster and easier. For spaceflight software there might have been some tedious certification process that would have to be done all over again if you change even one line of code. Therefore if you had something flying with an RTX on board and wanted to launch another one, it might be easier to emulate the RTX hardware and run the exact same code as before, than port the code to a new CPU. I don't know how likely this is but it's one possibility.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-23 22:03 -0400 |
| Message-ID | <nfh9be$86c$1@dont-email.me> |
| In reply to | #46725 |
On 4/23/2016 7:01 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Why not just compile directly to the target CPU and cut out the middle >> man? It's got to be faster and easier. > > For spaceflight software there might have been some tedious > certification process that would have to be done all over again if you > change even one line of code. Therefore if you had something flying > with an RTX on board and wanted to launch another one, it might be > easier to emulate the RTX hardware and run the exact same code as > before, than port the code to a new CPU. I don't know how likely this > is but it's one possibility. Who said anything about changing code? The point of this discussion was that the RTX Forth code would be run on a different architecture by using some type of emulation. The RTX code is still Forth and could be run on any target using a Forth compiler. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-23 21:55 -0700 |
| Message-ID | <87twirli5m.fsf@nightsong.com> |
| In reply to | #46726 |
rickman <gnuarm@gmail.com> writes: > Who said anything about changing code? The point of this discussion > was that the RTX Forth code would be run on a different architecture > by using some type of emulation. The RTX code is still Forth and > could be run on any target using a Forth compiler. I suspect that code that ran on actual RTX's had considerable machine specific content.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 01:58 -0400 |
| Message-ID | <nfhn36$hbk$2@dont-email.me> |
| In reply to | #46727 |
On 4/24/2016 12:55 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Who said anything about changing code? The point of this discussion >> was that the RTX Forth code would be run on a different architecture >> by using some type of emulation. The RTX code is still Forth and >> could be run on any target using a Forth compiler. > > I suspect that code that ran on actual RTX's had considerable machine > specific content. Do you mean the source code? Machine specific in what way? If it was machine specific, then why would someone want to port it? This conversation seems to go in a lot of different directions. I'm not following the divergent thoughts. Maybe it's just too late... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-24 00:53 -0700 |
| Message-ID | <87potfl9xj.fsf@nightsong.com> |
| In reply to | #46731 |
rickman <gnuarm@gmail.com> writes: > Do you mean the source code? Machine specific in what way? If it was > machine specific, then why would someone want to port it? I'm imagining a situation like this: 1) someone builds and flies a piece of spaceflight hardware (an instrument on board a satellite, say), using an RTX and fancy RTX-specific software, that might depend on the exact RTX timing characteristics etc. 2) The hardware works for some number of years, but then it expectedly or otherwise reaches EOL, so they want to launch another one. 3) The RTX is no longer made so they have to either: a) port or rewrite the code to a different cpu; or, b) clone the RTX itself somehow, so they can run the code without changes. I can understand that 3(b) might be more attractive than 3(a) for some people, some of the time. That's where MPE's emulation comes in.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 12:08 -0400 |
| Message-ID | <nfiqrg$e9r$1@dont-email.me> |
| In reply to | #46737 |
On 4/24/2016 3:53 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Do you mean the source code? Machine specific in what way? If it was >> machine specific, then why would someone want to port it? > > I'm imagining a situation like this: > > 1) someone builds and flies a piece of spaceflight hardware (an > instrument on board a satellite, say), using an RTX and fancy > RTX-specific software, that might depend on the exact RTX timing > characteristics etc. > > 2) The hardware works for some number of years, but then it expectedly > or otherwise reaches EOL, so they want to launch another one. There you go. This is the weak link in the rational. Why would they want to launch another sat like one that is some 10 years old? How long have these parts been out of production? > 3) The RTX is no longer made so they have to either: a) port or rewrite > the code to a different cpu; or, b) clone the RTX itself somehow, so > they can run the code without changes. > > I can understand that 3(b) might be more attractive than 3(a) for some > people, some of the time. That's where MPE's emulation comes in. Possible, but highly unlikely. Also, the CPU specific portions of the code are mostly just that, CPU specific, like interrupt handlers, etc. Not such a big deal to port. Any dependency on RTX specific timing could easily be rewritten in a new CPU and would likely be offloaded to a piece of hardware which would make the code portable in the future. The RTX design is not bad for a controller. But the chips are decades old. There are other choices available now, even rad hard. It's nice to be able to port certified software, but that only works if you have certified hardware to run it on. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-04-24 14:59 -1000 |
| Message-ID | <nNidnSpqC71p9oDKnZ2dnUU7-dednZ2d@supernews.com> |
| In reply to | #46727 |
On 4/23/16 6:55 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Who said anything about changing code? The point of this discussion >> was that the RTX Forth code would be run on a different architecture >> by using some type of emulation. The RTX code is still Forth and >> could be run on any target using a Forth compiler. > > I suspect that code that ran on actual RTX's had considerable machine > specific content. > Yes. The RTX definitely had a machine language level, although some Forth primitives did map directly to machine equivalents. There was a compiler (in fact, there were several compilers; Harris wrote one, as did FORTH, Inc.). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 22:15 -0400 |
| Message-ID | <nfjuct$rrg$1@dont-email.me> |
| In reply to | #46749 |
On 4/24/2016 8:59 PM, Elizabeth D. Rather wrote: > On 4/23/16 6:55 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> Who said anything about changing code? The point of this discussion >>> was that the RTX Forth code would be run on a different architecture >>> by using some type of emulation. The RTX code is still Forth and >>> could be run on any target using a Forth compiler. >> >> I suspect that code that ran on actual RTX's had considerable machine >> specific content. >> > > Yes. The RTX definitely had a machine language level, although some > Forth primitives did map directly to machine equivalents. There was a > compiler (in fact, there were several compilers; Harris wrote one, as > did FORTH, Inc.). I may be wrong, but I think Paul is saying the Forth source has machine specific content. I'm not sure if it did or not, other than controlling various features of the hardware which all machines must have. But the issue is whether it is practical to port the Forth code because the code is too specific to the part. I'm thinking very little of the Forth source is specific to the hardware. Regardless of how hard it would be to port the code, the bottom line is the market for RTX hardware (or hardware that emulates the RTX) is very, very low. There might be enough of a market for a vendor to have a product. Clearly MPE has a product. The question is how much of a market is there for it? I would guess it was not developed for sale, but rather was a byproduct of a contract for a compiler for the RTX. RTX hardware is rather expensive and the FPGA code was developed as a vehicle for code development. I'd be interested to know. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-24 20:05 -0700 |
| Message-ID | <87eg9ul76j.fsf@nightsong.com> |
| In reply to | #46750 |
rickman <gnuarm@gmail.com> writes: > RTX hardware is rather expensive and the FPGA code was developed > as a vehicle for code development. That's an interesting possibility that I hadn't thought of. Software emulation with correct timing wouldn't be able to plug into a surrounding hardware system.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-24 20:24 -0700 |
| Message-ID | <0b151e55-4663-438b-9745-f83418a6ec2f@googlegroups.com> |
| In reply to | #46751 |
On Sunday, April 24, 2016 at 8:05:09 PM UTC-7, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > RTX hardware is rather expensive and the FPGA code was developed > > as a vehicle for code development. > > That's an interesting possibility that I hadn't thought of. Software > emulation with correct timing wouldn't be able to plug into a > surrounding hardware system. The RTX2000 was available in 1994 when Testra started the MiniForth project --- it wasn't considered due to its high cost --- the Lattice isp1048 PLD was pretty inexpensive, but nobody had ever built a processor on it before, so we were doing something new. The competition in the laser-etching business was using an MC68000 board --- the MiniForth provided much higher speed at a much lower cost --- the competition just gave up on laser-etching. To me, Forth is supposed to be high performance and low cost --- something high-cost like the RTX2000 is not interesting to me --- I don't really know why Pelc is willing to spend money hiring somebody to do RTX2000 programming, but I suppose he has some scheme for making money with the thing. After ANS-Forth came out, Forth just died. Nobody wanted anything to do with Forth anymore --- ANS-Forth was a coup; it killed everything that was good in Forth.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-25 18:41 -0700 |
| Message-ID | <9167520c-b901-4f64-bbc1-fd35739cf33e@googlegroups.com> |
| In reply to | #46749 |
On Sunday, April 24, 2016 at 8:59:34 PM UTC-4, Elizabeth D. Rather wrote: > Yes. The RTX definitely had a machine language level, although some > Forth primitives did map directly to machine equivalents. There was a > compiler (in fact, there were several compilers; Harris wrote one, as > did FORTH, Inc.). Harris wrote a C compiler and sold their RTX2000 board with a C compiler. That's why I could sell our RTX2000 board to Siemens in Munich: http://www.somersetweb.com/BruehlConsult/Projects/mc-RISC-EMUF.html The person responsible for programming preferred to use Forth.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web