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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-26 21:10 -0400 |
| Message-ID | <nfp3as$rjh$1@dont-email.me> |
| In reply to | #46794 |
On 4/26/2016 7:51 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> hardware multiplier even if the 2553 doesn't. I'm not sure why deep >> stacks would make the RTX a more powerful chip. It has been shown >> many times that when running Forth a stack does not need to be deep. > > The RTX has about 1kB of memory in the stacks alone. The 2553 has 0.5k > of ram on the whole chip, plus 40-50 usable bytes in the registers if > you want to count those. I don't know if the RTX has any addressible > ram, e.g. if the stacks support random access. > > I also forgot to consider program memory. The 2553 has 16k and I don't > know if the RTX has any. As I already said, stacks aren't RAM and the two are not interchangeable no matter what size. You still need RAM for any but the most simple of programs. >> the thing that usually limits performance in MCUs is the Flash memory, >> not the CPU. That's why the faster processors don't include Flash. > > The fast Cortex-M's have some feature (ART) that speeds up execution > from flash. I think it's basically a small hardware cache but I'm not > sure. You are confusing the "fast" processors of 10-15 years ago with the fast processors today. Flash cripples performance of any processor that runs directly from it. In MCUs they aren't focused on speed so much, so they don't worry about. Some of the faster, but still low end MCUs, use *wide* flash and a 1 line buffer like a cache. Fast and Cortex-M are mutually exclusive. >> So instead of comparing it to the MSP430 line of MCUs, the RTX should >> be compared to CPUs without internal RAM like the higher end ARMs >> which run at hundreds of MHz. > > The lower end ARMs may be more appropriate: they could also copy code to > ram if necessary, and any way they run at so much higher frequency than > the RTX that they can stand a few extra cycles to read from flash. Why would low end ARMs be more appropriate? Because they are slow? Look at the features of the chips. The RTX is a CPU, not an MCU. According to the data sheet it has no peripherals (other than timers), no on-chip memory and requires an external reset. MCUs typically have both RAM and Flash, have multiple peripherals and these days nearly always have an internal reset. In other words, MCUs are more like System on Chips and the RTX is just a CPU. The higher end ARMs are more like the RTX. They seldom have any on board memory other than perhaps a bootloader. They do often incorporate some set of peripherals now that they are becoming center stage for many products. But resetting themselves is not one of those features. The bottom line is that the RTX is old school, from when a CPU was a CPU and the whole peripheral thing would be something you bolt onto the CPU. It has few peers in that all the other chips have moved on. The RTX found its way into a Rad-hard process, so it had a long life. Without that it would have ended up in the same dust bin as the Seaforth chips and the likely future fate of the GA144. BTW, wasn't the GA144 supposed to be reincarnated as a 32 bit chip? I wonder how that is going? I'd like to find out what peripherals it has. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-27 01:18 -0700 |
| Message-ID | <70b9b0b7-3863-4f8f-b074-babf2497f144@googlegroups.com> |
| In reply to | #46796 |
On Tuesday, April 26, 2016 at 6:10:04 PM UTC-7, rickman wrote: > The bottom line is that the RTX is old school, from when a CPU was a CPU > and the whole peripheral thing would be something you bolt onto the CPU. > It has few peers in that all the other chips have moved on. > > The RTX found its way into a Rad-hard process, so it had a long life. > Without that it would have ended up in the same dust bin as the Seaforth > chips and the likely future fate of the GA144. The reason why Forthers are interested in the RTX2000 is that it reminds them of a time when Forth was still being taken seriously. In its day (1988), the RTX2000 was considered to be a pretty good processor --- it compared favorably to other 16-bit processors of that time, such as the 68000 and 80186. I said earlier that the RTX2000 was not considered for use by Testra for laser-etching due to it being too expensive, and Testra developed the MiniForth instead --- this doesn't mean that I think the RTX2000 was a bad processor --- everything I've heard about the RTX2000 indicates that it was one of the best processors of that era. After ANS-Forth torpedoed the Forth community, nobody took Forth seriously anymore. I wrote MFX in 1994/1995, so just as I had an accomplishment in Forth that I expected to propel me into a career as a Forth programmer, Forth collapsed --- ANS-Forth really pulled the rug out from under my feet --- after ANS-Forth came out, nobody wanted anything to do with Forth any more; nobody would listen to any success story involving Forth because Forth was dead. Rickman is putting down the RTX2000 (comparing a 28-year-old processor to modern processors is hardly fair) --- he is doing this because he is a sycophant of Elizabeth Rather, so it is his job to support ANS-Forth and to denounce everything incompatible with ANS-Forth. First we had John Passaniti as E.R.'s chief sycophant, but he disappeared. Then we had Alex McDonald as E.R.'s chief sycophant, but he disappeared. Now we have Rickman as E.R.'s chief sycophant, but he hasn't disappeared yet (hopefully soon though). The 1980s and early 1990s were the golden-age of Forth --- it is reasonable for Forthers to be nostalgic of a time when Forth was still being taken seriously --- after ANS-Forth came out in 1994 however, Forth was not taken seriously anymore. ANS-Forth was a total joke! Here is one of the funnier quotes from the ANS-Forth document (section 3.2.3.2): ---------------------------------------------------------------------------- The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. ----------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-27 09:44 -0400 |
| Message-ID | <nfqfi8$92j$1@dont-email.me> |
| In reply to | #46798 |
This is such a great example of Hugh's mental illness. He seems to think I have some connection with Elizabeth Rather and have some reason to be her sycophant. That is a term that is virtually *never* applied to me. Anyone who knew me would know it to be the exact opposite of my personality. lol I truly feel sorry for Hugh. He is going through life miserable and full of hate. I feel sorry for the rest of c.l.f in that we have to witness this. Rick On 4/27/2016 4:18 AM, hughaguilar96@gmail.com wrote: > On Tuesday, April 26, 2016 at 6:10:04 PM UTC-7, rickman wrote: >> The bottom line is that the RTX is old school, from when a CPU was a CPU >> and the whole peripheral thing would be something you bolt onto the CPU. >> It has few peers in that all the other chips have moved on. >> >> The RTX found its way into a Rad-hard process, so it had a long life. >> Without that it would have ended up in the same dust bin as the Seaforth >> chips and the likely future fate of the GA144. > > The reason why Forthers are interested in the RTX2000 is that it reminds them of a time when Forth was still being taken seriously. In its day (1988), the RTX2000 was considered to be a pretty good processor --- it compared favorably to other 16-bit processors of that time, such as the 68000 and 80186. I said earlier that the RTX2000 was not considered for use by Testra for laser-etching due to it being too expensive, and Testra developed the MiniForth instead --- this doesn't mean that I think the RTX2000 was a bad processor --- everything I've heard about the RTX2000 indicates that it was one of the best processors of that era. > > After ANS-Forth torpedoed the Forth community, nobody took Forth seriously anymore. I wrote MFX in 1994/1995, so just as I had an accomplishment in Forth that I expected to propel me into a career as a Forth programmer, Forth collapsed --- ANS-Forth really pulled the rug out from under my feet --- after ANS-Forth came out, nobody wanted anything to do with Forth any more; nobody would listen to any success story involving Forth because Forth was dead. > > Rickman is putting down the RTX2000 (comparing a 28-year-old processor to modern processors is hardly fair) --- he is doing this because he is a sycophant of Elizabeth Rather, so it is his job to support ANS-Forth and to denounce everything incompatible with ANS-Forth. First we had John Passaniti as E.R.'s chief sycophant, but he disappeared. Then we had Alex McDonald as E..R.'s chief sycophant, but he disappeared. Now we have Rickman as E.R.'s chief sycophant, but he hasn't disappeared yet (hopefully soon though). > > The 1980s and early 1990s were the golden-age of Forth --- it is reasonable for Forthers to be nostalgic of a time when Forth was still being taken seriously --- after ANS-Forth came out in 1994 however, Forth was not taken seriously anymore. > > ANS-Forth was a total joke! Here is one of the funnier quotes from the ANS-Forth document (section 3.2.3.2): > ---------------------------------------------------------------------------- > The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. > ---------------------------------------------------------------------------- > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-04-27 09:48 -0500 |
| Message-ID | <FpadnZNQ5a_RTL3KnZ2dnUU78LednZ2d@supernews.com> |
| In reply to | #46800 |
rickman <gnuarm@gmail.com> wrote: > This is such a great example of Hugh's mental illness. Please don't quote him in full, lest ye be killfiled also. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-28 23:23 -0700 |
| Message-ID | <a1cd2b10-6392-4643-8d05-2eba79fb5931@googlegroups.com> |
| In reply to | #46801 |
On Wednesday, April 27, 2016 at 7:48:46 AM UTC-7, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: > > This is such a great example of Hugh's mental illness. > > Please don't quote him in full, lest ye be killfiled also. > > Andrew. ANS-Forth is a cult --- saying that the critics of the cult have "mental illness" is typical cult behavior --- it seems unrealistic that you expect me to get upset because Rickman says I have mental illness; he is just a sycophant of E.R. similar to Passaniti in that he has never written a Forth program in his life, but he wants to be a big Forth expert in so much as Elizabeth Rather praises him publicly. The ANS-Forth Standard was a marketing gimmick from Elizabeth Rather. All of that ambiguity comes from political concessions. The problem that the control-stack may or may not be the data-stack (section 3.2.3.2) is a typical example. Somebody had the control-stack distinct from the data-stack (which makes sense because the control-flow stuff doesn't get in the way of the user's data on the data-stack) and they wanted their compiler to be ANS-Forth compliant, so E.R. said okay that is standard, but Forth Inc. has the control-flow stuff on the data-stack and so that was made standard too, although the two implementations are incompatible. Similarly, GFORTH has a FIND that produces different xt values for the same word depending upon what STATE is at the time that FIND executes. That is crazy! GFORTH is also ANS-Forth compliant though for political reasons (Anton Ertl is E.R.'s appointee as the Forth-200x chair-person). VFX has a lot of words that were traditionally immediate, such as IF etc., that are now non-immediate and are special-cased by COMPILE, to execute at compile-time as if they were immediate. That is crazy! VFX is also ANS-Forth compliant though for political reasons (Stephen Pelc is E.R.'s appointee to the Forth-200x committee). Pretty much any crazy idea can be considered to be ANS-Forth compliant so long as E.R. says so, and never mind that none of these crazy ideas are compatible with each other, and never mind that none of these crazy ideas were seen in Forth prior to ANS-Forth --- Elizabeth Rather is the Queen of Crazy! I consider Stephen Pelc to be a hypocrite. He is interested enough in the RTX2000 that he is willing to pay somebody to program it for him. As I said, the RTX2000 comes from the good old days when Forth was still taken seriously, before ANS-Forth torpedoed Forth. On the other hand, Stephen Pelc supports ANS-Forth and he even got appointed to the Forth-200x committee by Elizabeth Rather (Forth-200x is mandated by E.R. to be 100% compatible with ANS-Forth, and it has no real purpose except to make ANS-Forth seem important). Another reason why I consider Pelc to be a hypocrite is that he refuses to support my disambiguifiers, although he knows that my disambiguifiers make FIND behave the same way between different ANS-Forth compilers (VFX, GFORTH and SwiftForth) in which FIND currently behaves differently. The whole purpose of having a standard is that programs can be ported between compatible compilers because they behave the same, and my disambiguifiers allow FIND to behave the same despite the weird differences between the ANS-Forth compilers. So why doesn't Pelc support my disambiguifiers? If he doesn't understand what the word "compatible" means, then why is he on the Forth-200x committee?
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-26 05:05 -0700 |
| Message-ID | <bcdb775d-1646-454a-a043-7d44bd55930f@googlegroups.com> |
| In reply to | #46769 |
On Tuesday, April 26, 2016 at 3:03:59 AM UTC+1, visua...@rocketmail.com wrote: > On Saturday, April 23, 2016 at 4:55:53 AM UTC-4, JUERGEN wrote: > > 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 - this would be more Processing Power and probably faster that what was on there - including the carrier ... > > Programs running on the RTX2000 written in Forth will run on the MSP430G2553, too, having a Forth system on chip - except the hardware specific I/O and Timers. > > But instead telling the kids they would have the same processor, tell them that they are using the same programming language that landed Philae on the Asteroid. > > See Wolfgang Allinger's report on https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.forth/rtx2000$20allinger|sort:relevance/comp.lang.forth/7Byy-42cvTg/7tbbuuEGbYkJ Pictures and links have been prepared already to take with me ...
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-04-23 12:10 +0000 |
| Message-ID | <571b6554.266460861@news.eternal-september.org> |
| In reply to | #46715 |
On Fri, 22 Apr 2016 12:51:28 -0700, Paul Rubin <no.email@nospam.invalid> 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. Yes, we charge for 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. The original RTXcore design was done specifically to match the RTX timing. The application was a timing pulse generator. People with a knowledge of Forth and RTX2000 are welcome to contact me about consultancy work. A port to rad-hard FPGAs is under consideration. Please submit CVs/Resumes. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 08:05 -0700 |
| Message-ID | <082986ee-53dc-4f14-b53c-d06296043a3e@googlegroups.com> |
| In reply to | #46718 |
On Saturday, April 23, 2016 at 1:10:35 PM UTC+1, Stephen Pelc wrote: > On Fri, 22 Apr 2016 12:51:28 -0700, Paul Rubin > <no.email@nospam.invalid> 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. > > Yes, we charge for 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. > > The original RTXcore design was done specifically to match the RTX > timing. The application was a timing pulse generator. > > People with a knowledge of Forth and RTX2000 are welcome to > contact me about consultancy work. A port to rad-hard FPGAs > is under consideration. Please submit CVs/Resumes. > > Stephen > > -- > Stephen Pelc, stephenXXX@mpeforth.com > MicroProcessor Engineering Ltd - More Real, Less Time > 133 Hill Lane, Southampton SO15 5AF, England > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 > web: http://www.mpeforth.com - free VFX Forth downloads Microsemi and Xilinx would probably love the availability of such a processor core implementation and as well the UK Microsatellites - looks like going back to AMSAT times on a professional basis. See http://www.xilinx.com/applications/aerospace-and-defense/space.html and http://www.microsemi.com/products/fpga-soc/rad-tolerant-fpgas The result should be similar to a b16++ and a J1++.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-23 13:01 -0700 |
| Message-ID | <559da780-177f-4ded-8200-c7b8e1f5fc22@googlegroups.com> |
| In reply to | #46718 |
On Saturday, April 23, 2016 at 5:10:35 AM UTC-7, Stephen Pelc wrote: > People with a knowledge of Forth and RTX2000 are welcome to > contact me about consultancy work. A port to rad-hard FPGAs > is under consideration. Please submit CVs/Resumes. I'm not opposed to people making money programming in Forth. I've done it myself. I'm opposed to a corporation writing the Standard (capital 'S') for the Forth programming language. I think that Pelc is the worst possible candidate for the Forth-200x standards committee because he is financially motivated to cripple Forth-200x as much as possible in order to prevent Forthers from using Forth-200x to compete against MPE. ANS-Forth and Forth-200x are all about keeping the little people in their place --- let them take Anton Ertl's class and write a sudoku solver in gForth --- prevent them from building motion-control boards that are commercially viable. I spent a few minutes reading up on the RTX2000. There is similarity between it and the MiniForth. Specifically, the high bit of the opcode determines if it is a function call (in which case the low 15 bits are the function address) or if it is a primitive (in which case the low 15 bits determine which primitive it is). Reading this, it occurs to me that Testra most likely borrowed the idea from the RTX2000 which I had not been aware of at the time (the RTX2000 came out in 1988 and the MiniForth was developed in 1994/1995). Note, btw, that the F3C designer is unaware of this idea and consequently has bloated code because every function call is 32 bits (a 16-bit opcode for CALL and a 16-bit address) --- Forth code tends to be heavily factored, so reducing the size of a function call to 16 bits will significantly reduce the program size (speeds it up too, as there are fewer memory accesses to program memory). Pelc said that an MPE employee applicant needs to have familiarity with Forth and with the RTX2000. He should have also said that the applicant needs to support him politically --- that is, to give lip-service to Forth-200x being the Standard of the Forth community, despite the fact that Forth-200x is purposely crippled (it is mandated to be 100% compatible with ANS-Forth) --- from Pelc's perspective, becoming an elite means that the person has to actively work at holding the little people down (by comparison, I wrote MFX for the MiniForth, but I never made any effort to prevent other Forthers from also doing something commercially viable in Forth). What I'm saying is that Pelc is a hypocrite --- on one hand he does commercial work using the RTX2000 etc. --- on the other hand though, he is on the Forth-200x committee and as such he strives to prevent the rest of the Forth community from doing commercial work in Forth by forcing a purposely-crippled standard down their throats. I encourage every Forth programmer to ignore ANS-Forth and Forth-200x --- these were just marketing gimmicks from Elizabeth Rather, the Zig Ziglar of Forth Inc. --- they have no value in the real world.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-23 18:36 -0400 |
| Message-ID | <nfgt6o$9jc$1@dont-email.me> |
| In reply to | #46720 |
On 4/23/2016 4:01 PM, hughaguilar96@gmail.com wrote: > On Saturday, April 23, 2016 at 5:10:35 AM UTC-7, Stephen Pelc wrote: >> People with a knowledge of Forth and RTX2000 are welcome to >> contact me about consultancy work. A port to rad-hard FPGAs >> is under consideration. Please submit CVs/Resumes. > > I'm not opposed to people making money programming in Forth. I've done it myself. I'm opposed to a corporation writing the Standard (capital 'S') for the Forth programming language. > > I think that Pelc is the worst possible candidate for the Forth-200x standards committee because he is financially motivated to cripple Forth-200x as much as possible in order to prevent Forthers from using Forth-200x to compete against MPE. ANS-Forth and Forth-200x are all about keeping the little people in their place --- let them take Anton Ertl's class and write a sudoku solver in gForth --- prevent them from building motion-control boards that are commercially viable. > > I spent a few minutes reading up on the RTX2000. There is similarity between it and the MiniForth. Specifically, the high bit of the opcode determines if it is a function call (in which case the low 15 bits are the function address) or if it is a primitive (in which case the low 15 bits determine which primitive it is). Reading this, it occurs to me that Testra most likely borrowed the idea from the RTX2000 which I had not been aware of at the time (the RTX2000 came out in 1988 and the MiniForth was developed in 1994/1995). Note, btw, that the F3C designer is unaware of this idea and consequently has bloated code because every function call is 32 bits (a 16-bit opcode for CALL and a 16-bit address) --- Forth code tends to be heavily factored, so reducing the size of a function call to 16 bits will significantly reduce the program size (speeds it up too, as there are fewer memory accesses to program memory). > > Pelc said that an MPE employee applicant needs to have familiarity with Forth and with the RTX2000. He should have also said that the applicant needs to support him politically --- that is, to give lip-service to Forth-200x being the Standard of the Forth community, despite the fact that Forth-200x is purposely crippled (it is mandated to be 100% compatible with ANS-Forth) --- from Pelc's perspective, becoming an elite means that the person has to actively work at holding the little people down (by comparison, I wrote MFX for the MiniForth, but I never made any effort to prevent other Forthers from also doing something commercially viable in Forth). > > What I'm saying is that Pelc is a hypocrite --- on one hand he does commercial work using the RTX2000 etc. --- on the other hand though, he is on the Forth-200x committee and as such he strives to prevent the rest of the Forth community from doing commercial work in Forth by forcing a purposely-crippled standard down their throats. > > I encourage every Forth programmer to ignore ANS-Forth and Forth-200x --- these were just marketing gimmicks from Elizabeth Rather, the Zig Ziglar of Forth Inc. --- they have no value in the real world. I know there is no point in trying to show you what a loon you are, but I just irritates me too much sometimes to see your rants here and I am compelled to let you know how deranged you are. Now you can reply about me being a puppet or whatever you think is the reason behind my post... while the reality fully escapes you. You have mental problems and need help. Help you will never get on your own. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-04-23 21:33 +1000 |
| Message-ID | <nffmhi$f2h$1@gioia.aioe.org> |
| In reply to | #46698 |
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. > ... My only fondness for the 6502 is that it was the first processor I learned. After several years of 6502 hell (no 16-bit regs, broken Jump Indirect, limited free zero-page, lack of decent assemblers/OS/software, buggy Fig-Forth etc) I switched to the 8080 and it was like I'd gone to heaven :) In fairness, the 6502 was intended for controller use - not high-level applications - but due to it's low cost was picked up by hobbyists such as Wozniak and the rest is history.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-22 09:47 -0700 |
| Message-ID | <c5e80891-45e5-4303-8f74-1a32a58b9083@googlegroups.com> |
| In reply to | #46697 |
On Wednesday, April 20, 2016 at 2:16:19 PM UTC-7, Bernd Paysan wrote: > Am Thu, 21 Apr 2016 01:27:41 +1000 schrieb HAA: > >> IMHO they are both more fun than the 8080 and the MISC, because the > >> other two are not really made for Forth. > > > > Perhaps Ting's choice of 8080 has to do with the fact it's a classic > > processor with countless source code available for it. As for the link > > to Forth possibly the most widely used implementation for the 8080 was > > Fig-Forth - something which Ting knows well having written a book about > > it. There's plenty of fun to be had in retrocomputing - you just need > > to be old enough to appreciate it :) There are various FPGA designs available for free supporting old retro processors such as the 6502 etc.. Most likely, Ting chose the 8080 because he found a free 8080 FPGA system on the internet somewhere --- there is no other reason for why anybody would choose such an obsolete processor as the 8080 --- this isn't really the best qualification for somebody to teach a class in processor design. People in the Forth community are overly focused on promoting themselves into teaching positions, and not focused enough on writing programs. I've noticed the same trend in gun ownership --- at the shooting range, almost every group at every bench has someone in the group being a lofty expert and teaching the others, but almost nobody is focusing on improving their own marksmanship --- also, I'm the only one shooting a pistol at 50 yards, but everybody else is blasting away at 15 yards and missing most of their shots. > 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 wrote a cross-compiler for the 65c02 based on ISYS Forth. The trick to making it generate fast code is to use a split parameter stack. Have the high byte in one stack and the low byte in another stack. Use X as the stack index. This way, a single INX does the DROP. Also, I had every producer (word that pushes data to the stack) do its DEX at the end, and I had every consumer (word that removes data from the stack) do its INX at the beginning --- this way the DEX and INX are juxtaposed and the peephole-optimizer can remove them. Another trick is to convert a JSR followed by a RET into a JMP --- that improves speed a lot, and it also reduces return-stack usage in tail-recursive functions. I haven't written a Z80 Forth, but I did think about the subject. I think the trick would be to use IX as the return-stack pointer. At the beginning of every function, the return-address would be removed from the SP stack and put on the IX stack --- then SP would be used as the data-stack which is much faster for pushing and popping --- also, for a primitive function (one that doesn't call any other functions), the return-address can be held in a register throughout rather than put on the IX return-stack at all. The mainstream 6502 and Z80 Forth systems available in the 1980s were awfully inefficient --- this tended to ruin Forth's reputation --- even today, most people who have had contact with Forth are old guys who programmed Forth in the 1980s and their recollection of the experience is entirely negative, so they continue to denounce Forth now. > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > http://bernd-paysan.de/ If you want the job done right, you have to think up some clever tricks to work around the limitations of the processor. If you want the job completely screwed up, you have to find a whiny loser who complains that the job can't be done: "my reaction back then was that they were really awful, and cumbersome to program, and too small to be useful." "Boo hoo hoo! I can't do the job! It is all the fault of the 6502 and Z80 designers though, and not my fault. I'm a member of the Forth-200x committee, so I just teach programming, but I can't actually program..."
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-04-25 07:24 +0000 |
| Message-ID | <nfkgo1$e1u$1@dont-email.me> |
| In reply to | #46712 |
hughaguilar96@gmail.com wrote: > The mainstream 6502 and Z80 Forth systems available in the 1980s were awfully inefficient On the 6502 Atari I used something called Turbo Forth. I seem to recall that one could use it to write a routine to be executed during the vertibal blank interrupt, which means it was pretty fast. -- [I]n Norway ... a ... man [who] was gang raped by Somali immigrants ... is opposing ... deportation [of his rapist]. http://renseradioarchives.com/dduke/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-23 16:16 -0400 |
| Message-ID | <nfgl0f$9v4$1@dont-email.me> |
| In reply to | #46626 |
On 4/11/2016 3:32 PM, rickman wrote: > Ting will be leading a workshop on using a Lattice FPGA to implement an > emulation of the 8080 instruction set which will run Forth. > > http://www.meetup.com/SV-FIG/events/229926249/ > > I believe you need to be a member of Meetup to see this page. I'm not > sure but you may need to be a member of the SVFIG meetup group as well. > There is no charge to join either. Ting is giving a presentation on the HDL 8080 which he uses to run Forth at the SVFIG meeting. https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-26 03:15 -0700 |
| Message-ID | <20bcf422-2197-4b33-99c9-a63f3722d704@googlegroups.com> |
| In reply to | #46721 |
On Saturday, April 23, 2016 at 9:16:29 PM UTC+1, rickman wrote: > On 4/11/2016 3:32 PM, rickman wrote: > > Ting will be leading a workshop on using a Lattice FPGA to implement an > > emulation of the 8080 instruction set which will run Forth. > > > > http://www.meetup.com/SV-FIG/events/229926249/ > > > > I believe you need to be a member of Meetup to see this page. I'm not > > sure but you may need to be a member of the SVFIG meetup group as well. > > There is no charge to join either. > > Ting is giving a presentation on the HDL 8080 which he uses to run Forth > at the SVFIG meeting. > > https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be > > -- > > Rick Has anybody looked at the VHDL yet? Is the processor small enough to run in the Lattice IceStick as J1a? I own one of these sticks so could try it on this HW - actually try both.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-26 11:22 -0400 |
| Message-ID | <nfo0t2$pgn$1@dont-email.me> |
| In reply to | #46776 |
On 4/26/2016 6:15 AM, JUERGEN wrote: > On Saturday, April 23, 2016 at 9:16:29 PM UTC+1, rickman wrote: >> On 4/11/2016 3:32 PM, rickman wrote: >>> Ting will be leading a workshop on using a Lattice FPGA to implement an >>> emulation of the 8080 instruction set which will run Forth. >>> >>> http://www.meetup.com/SV-FIG/events/229926249/ >>> >>> I believe you need to be a member of Meetup to see this page. I'm not >>> sure but you may need to be a member of the SVFIG meetup group as well. >>> There is no charge to join either. >> >> Ting is giving a presentation on the HDL 8080 which he uses to run Forth >> at the SVFIG meeting. >> >> https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be >> >> -- >> >> Rick > > Has anybody looked at the VHDL yet? Is the processor small enough to run in the Lattice IceStick as J1a? I own one of these sticks so could try it on this HW - actually try both. To figure out if the 8080 processor Ting has written will fit on the iCE40 you would need to download the iCECube software and compile it. It is hard to tell from the code how much resources it will take in any given part. Ok, I spent a little time getting my old 2014 copy of iCECube re-licensed and running. Looks like the eP8080 design needs 1728 LUT4s in the iCE40 chip and there are only 1280 available in the part on the iCEstick. I was able to reduce this to 1623 by fiddling with the synthesis options, but that's still a long way to go. If you want to do some soldering, the HX4K part comes in the same package and should fit on the board. I quickly scanned the source code and found a number of warnings. Mostly these are items declared in the HDL which are not driven or optimized away. I don't think there is much room for space savings without digging through the code to see how it was constructed. The HX1K part is not very large for a processor like the 8080. It would be more than enough for a MISC type processor. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-27 07:48 -0700 |
| Message-ID | <da9922a2-8b4f-4150-b89c-7fec0b9ba16a@googlegroups.com> |
| In reply to | #46785 |
On Tuesday, April 26, 2016 at 4:22:25 PM UTC+1, rickman wrote:
> On 4/26/2016 6:15 AM, JUERGEN wrote:
> > On Saturday, April 23, 2016 at 9:16:29 PM UTC+1, rickman wrote:
> >> On 4/11/2016 3:32 PM, rickman wrote:
> >>> Ting will be leading a workshop on using a Lattice FPGA to implement an
> >>> emulation of the 8080 instruction set which will run Forth.
> >>>
> >>> http://www.meetup.com/SV-FIG/events/229926249/
> >>>
> >>> I believe you need to be a member of Meetup to see this page. I'm not
> >>> sure but you may need to be a member of the SVFIG meetup group as well.
> >>> There is no charge to join either.
> >>
> >> Ting is giving a presentation on the HDL 8080 which he uses to run Forth
> >> at the SVFIG meeting.
> >>
> >> https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be
> >>
> >> --
> >>
> >> Rick
> >
> > Has anybody looked at the VHDL yet? Is the processor small enough to run in the Lattice IceStick as J1a? I own one of these sticks so could try it on this HW - actually try both.
>
> To figure out if the 8080 processor Ting has written will fit on the
> iCE40 you would need to download the iCECube software and compile it.
> It is hard to tell from the code how much resources it will take in any
> given part.
>
> Ok, I spent a little time getting my old 2014 copy of iCECube
> re-licensed and running. Looks like the eP8080 design needs 1728 LUT4s
> in the iCE40 chip and there are only 1280 available in the part on the
> iCEstick. I was able to reduce this to 1623 by fiddling with the
> synthesis options, but that's still a long way to go. If you want to do
> some soldering, the HX4K part comes in the same package and should fit
> on the board.
>
> I quickly scanned the source code and found a number of warnings.
> Mostly these are items declared in the HDL which are not driven or
> optimized away. I don't think there is much room for space savings
> without digging through the code to see how it was constructed. The
> HX1K part is not very large for a processor like the 8080. It would be
> more than enough for a MISC type processor.
>
> --
>
> Rick C
Thank you very much Rick. Unfortunate. I was hoping the IceStick would be enough.
MISC is definitely to be tried - Performance comparison: does not matter.
BUT - today I received the image of another oldie: CDP1802. I have not had the time to look at it or try it out, but here Scott achieves in the http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard.aspx:
He says:
I have attached a bitstream for an iCE40-hx8k dev board that implements a SOC
The SOC contains:
a) 1802 CPU
b) 4k RAM
c) Timer
d) UART
e) 8-bit output port
The address map is:
-- $0000 -> $0FFF Boot RAM (4k)
-- $F000 -> $F007 UART registers
-- $F008 -> $F00B Timer registers
-- $F00C Output Port
-- $F00D Interrupt mask register
-- $F00E Interrupt source register
The FPGA I/O pins are assigned as follows:
UART_RXD G1 -pullup yes
UART_TXD G2
PORTA[0] B5
PORTA[1] B4
PORTA[2] A2
PORTA[3] A1
PORTA[4] C5
PORTA[5] C4
PORTA[6] B3
PORTA[7] C3
RESET N3 - pullup yes
FCLK J3 - pullup yes
The RAM is pre-loaded with the hello.asm program (also attached).
This program prints "'Hello CDP-1802" and increments the PortA output register (blinks LEDs.
A bit more that the 8080 - but as full Microcontroller with RAM and UART.
Now I have to dig deep for the Fig-Forth 1802 and try to get a hex of this.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-27 12:05 -0400 |
| Message-ID | <nfqnp1$apt$1@dont-email.me> |
| In reply to | #46802 |
On 4/27/2016 10:48 AM, JUERGEN wrote: > On Tuesday, April 26, 2016 at 4:22:25 PM UTC+1, rickman wrote: >> On 4/26/2016 6:15 AM, JUERGEN wrote: >>> On Saturday, April 23, 2016 at 9:16:29 PM UTC+1, rickman wrote: >>>> On 4/11/2016 3:32 PM, rickman wrote: >>>>> Ting will be leading a workshop on using a Lattice FPGA to implement an >>>>> emulation of the 8080 instruction set which will run Forth. >>>>> >>>>> http://www.meetup.com/SV-FIG/events/229926249/ >>>>> >>>>> I believe you need to be a member of Meetup to see this page. I'm not >>>>> sure but you may need to be a member of the SVFIG meetup group as well. >>>>> There is no charge to join either. >>>> >>>> Ting is giving a presentation on the HDL 8080 which he uses to run Forth >>>> at the SVFIG meeting. >>>> >>>> https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be >>>> >>>> -- >>>> >>>> Rick >>> >>> Has anybody looked at the VHDL yet? Is the processor small enough to run in the Lattice IceStick as J1a? I own one of these sticks so could try it on this HW - actually try both. >> >> To figure out if the 8080 processor Ting has written will fit on the >> iCE40 you would need to download the iCECube software and compile it. >> It is hard to tell from the code how much resources it will take in any >> given part. >> >> Ok, I spent a little time getting my old 2014 copy of iCECube >> re-licensed and running. Looks like the eP8080 design needs 1728 LUT4s >> in the iCE40 chip and there are only 1280 available in the part on the >> iCEstick. I was able to reduce this to 1623 by fiddling with the >> synthesis options, but that's still a long way to go. If you want to do >> some soldering, the HX4K part comes in the same package and should fit >> on the board. >> >> I quickly scanned the source code and found a number of warnings. >> Mostly these are items declared in the HDL which are not driven or >> optimized away. I don't think there is much room for space savings >> without digging through the code to see how it was constructed. The >> HX1K part is not very large for a processor like the 8080. It would be >> more than enough for a MISC type processor. >> >> -- >> >> Rick C > > Thank you very much Rick. Unfortunate. I was hoping the IceStick would be enough. > > MISC is definitely to be tried - Performance comparison: does not matter. > > BUT - today I received the image of another oldie: CDP1802. I have not had the time to look at it or try it out, but here Scott achieves in the http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard.aspx: > > He says: > I have attached a bitstream for an iCE40-hx8k dev board that implements a SOC > The SOC contains: > a) 1802 CPU > b) 4k RAM > c) Timer > d) UART > e) 8-bit output port > > The address map is: > -- $0000 -> $0FFF Boot RAM (4k) > -- $F000 -> $F007 UART registers > -- $F008 -> $F00B Timer registers > -- $F00C Output Port > -- $F00D Interrupt mask register > -- $F00E Interrupt source register > > The FPGA I/O pins are assigned as follows: > UART_RXD G1 -pullup yes > UART_TXD G2 > > PORTA[0] B5 > PORTA[1] B4 > PORTA[2] A2 > PORTA[3] A1 > PORTA[4] C5 > PORTA[5] C4 > PORTA[6] B3 > PORTA[7] C3 > > RESET N3 - pullup yes > FCLK J3 - pullup yes > > The RAM is pre-loaded with the hello.asm program (also attached). > This program prints "'Hello CDP-1802" and increments the PortA output register (blinks LEDs. > > A bit more that the 8080 - but as full Microcontroller with RAM and UART. > Now I have to dig deep for the Fig-Forth 1802 and try to get a hex of this. That is not really much more than the 8080 code Ting distributed. That code includes RAM, UART, GPIO and of course the processor. Your 1802 list includes a timer the Ting 8080 code doesn't include. The size part required by each of these processors depends on how the code is written. I'd be willing to bet the LUT requirements can be reduced by a little attention to detail in writing the code. I seldom start writing the code until I have picked an architecture to implement. For example, the 8080 has a number of 8 bit registers which can be implemented by distributed RAM rather than separate registers. This eliminates a lot of multiplexers that otherwise have to be implemented in the FPGA fabric. The 8080 has multiple clock cycles per instruction time, so it would be easy to implement with distributed RAM if a bit of thought is given. Same is potentially true of the 1802 code. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-27 10:34 -0700 |
| Message-ID | <6a900d09-c808-49ba-98ff-8dcebdd7491c@googlegroups.com> |
| In reply to | #46803 |
On Wednesday, April 27, 2016 at 5:05:06 PM UTC+1, rickman wrote: > On 4/27/2016 10:48 AM, JUERGEN wrote: > > On Tuesday, April 26, 2016 at 4:22:25 PM UTC+1, rickman wrote: > >> On 4/26/2016 6:15 AM, JUERGEN wrote: > >>> On Saturday, April 23, 2016 at 9:16:29 PM UTC+1, rickman wrote: > >>>> On 4/11/2016 3:32 PM, rickman wrote: > >>>>> Ting will be leading a workshop on using a Lattice FPGA to implement an > >>>>> emulation of the 8080 instruction set which will run Forth. > >>>>> > >>>>> http://www.meetup.com/SV-FIG/events/229926249/ > >>>>> > >>>>> I believe you need to be a member of Meetup to see this page. I'm not > >>>>> sure but you may need to be a member of the SVFIG meetup group as well. > >>>>> There is no charge to join either. > >>>> > >>>> Ting is giving a presentation on the HDL 8080 which he uses to run Forth > >>>> at the SVFIG meeting. > >>>> > >>>> https://www.youtube.com/watch?v=s9cnnPiQtn8&feature=youtu.be > >>>> > >>>> -- > >>>> > >>>> Rick > >>> > >>> Has anybody looked at the VHDL yet? Is the processor small enough to run in the Lattice IceStick as J1a? I own one of these sticks so could try it on this HW - actually try both. > >> > >> To figure out if the 8080 processor Ting has written will fit on the > >> iCE40 you would need to download the iCECube software and compile it. > >> It is hard to tell from the code how much resources it will take in any > >> given part. > >> > >> Ok, I spent a little time getting my old 2014 copy of iCECube > >> re-licensed and running. Looks like the eP8080 design needs 1728 LUT4s > >> in the iCE40 chip and there are only 1280 available in the part on the > >> iCEstick. I was able to reduce this to 1623 by fiddling with the > >> synthesis options, but that's still a long way to go. If you want to do > >> some soldering, the HX4K part comes in the same package and should fit > >> on the board. > >> > >> I quickly scanned the source code and found a number of warnings. > >> Mostly these are items declared in the HDL which are not driven or > >> optimized away. I don't think there is much room for space savings > >> without digging through the code to see how it was constructed. The > >> HX1K part is not very large for a processor like the 8080. It would be > >> more than enough for a MISC type processor. > >> > >> -- > >> > >> Rick C > > > > Thank you very much Rick. Unfortunate. I was hoping the IceStick would be enough. > > > > MISC is definitely to be tried - Performance comparison: does not matter. > > > > BUT - today I received the image of another oldie: CDP1802. I have not had the time to look at it or try it out, but here Scott achieves in the http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard.aspx: > > > > He says: > > I have attached a bitstream for an iCE40-hx8k dev board that implements a SOC > > The SOC contains: > > a) 1802 CPU > > b) 4k RAM > > c) Timer > > d) UART > > e) 8-bit output port > > > > The address map is: > > -- $0000 -> $0FFF Boot RAM (4k) > > -- $F000 -> $F007 UART registers > > -- $F008 -> $F00B Timer registers > > -- $F00C Output Port > > -- $F00D Interrupt mask register > > -- $F00E Interrupt source register > > > > The FPGA I/O pins are assigned as follows: > > UART_RXD G1 -pullup yes > > UART_TXD G2 > > > > PORTA[0] B5 > > PORTA[1] B4 > > PORTA[2] A2 > > PORTA[3] A1 > > PORTA[4] C5 > > PORTA[5] C4 > > PORTA[6] B3 > > PORTA[7] C3 > > > > RESET N3 - pullup yes > > FCLK J3 - pullup yes > > > > The RAM is pre-loaded with the hello.asm program (also attached). > > This program prints "'Hello CDP-1802" and increments the PortA output register (blinks LEDs. > > > > A bit more that the 8080 - but as full Microcontroller with RAM and UART. > > Now I have to dig deep for the Fig-Forth 1802 and try to get a hex of this. > > That is not really much more than the 8080 code Ting distributed. That > code includes RAM, UART, GPIO and of course the processor. Your 1802 > list includes a timer the Ting 8080 code doesn't include. > > The size part required by each of these processors depends on how the > code is written. I'd be willing to bet the LUT requirements can be > reduced by a little attention to detail in writing the code. I seldom > start writing the code until I have picked an architecture to implement. > For example, the 8080 has a number of 8 bit registers which can be > implemented by distributed RAM rather than separate registers. This > eliminates a lot of multiplexers that otherwise have to be implemented > in the FPGA fabric. The 8080 has multiple clock cycles per instruction > time, so it would be easy to implement with distributed RAM if a bit of > thought is given. > > Same is potentially true of the 1802 code. > > -- > > Rick C Thanks Rick, I have asked if there is an easy way to just cut out 8 of the 16 16bit registers for now to fit into the IceStick1k - this would be a nice solution. My so called 901 - 1/2 of the 1802 in registers. Fig Forth 1802 found. A lot of fun and history brought back to life. For your info: I was part of the application team in Brussels introducing the CDP1802 in Europe - AND USED IN ONE OF THE FIRST INTELLIGENT PHONES at the time. I have no clue if Forth was involved.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-27 10:51 -0700 |
| Message-ID | <87eg9rhrdl.fsf@nightsong.com> |
| In reply to | #46804 |
JUERGEN <epldfpga@aol.com> writes: > Thanks Rick, I have asked if there is an easy way to just cut out 8 of > the 16 16bit registers for now to fit into the IceStick1k - this would > be a nice solution. My so called 901 - 1/2 of the 1802 in registers. > Fig Forth 1802 found. A lot of fun and history brought back to life. I wonder what you guys get out of implementing this stuff in FPGA's instead of software. I understand the enjoyment of emulating old processors, but unless you need exact timing etc., why not just save a lot of effort by just writing code? > For your info: I was part of the application team in Brussels > introducing the CDP1802 in Europe - AND USED IN ONE OF THE FIRST > INTELLIGENT PHONES at the time. I have no clue if Forth was involved. Cool!
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web