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 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-11 15:32 -0400 |
| Subject | Ting: SVFIG FPGA Design Workshop Featuring eP8080 |
| Message-ID | <negtug$23c$1@dont-email.me> |
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. -- Rick
[toc] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-14 08:10 -0700 |
| Message-ID | <3177fbb1-2367-45fe-b238-1c5364d3b7f5@googlegroups.com> |
| In reply to | #46626 |
On Monday, April 11, 2016 at 8:32:41 PM UTC+1, 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. > > -- > > Rick I tried Meetup - - has the link to the Lattice files already been distributed?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-14 12:43 -0400 |
| Message-ID | <neoh4c$3t9$1@dont-email.me> |
| In reply to | #46656 |
On 4/14/2016 11:10 AM, JUERGEN wrote: > On Monday, April 11, 2016 at 8:32:41 PM UTC+1, 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. >> >> -- >> >> Rick > > I tried Meetup - - has the link to the Lattice files already been distributed? I don't know anything about the link. I sent Ting an email and he sent the files in an email. Kevin Appert is the only person who said there was a link. I think you can ask Ting for it or ask him for the files. I made the mistake of looking at some of the code. I'm already not happy with what I see. He uses clk_i'event and clk_i='1' rather than rising_edge(clk_i). Yes, they are typically the same... unless your clock has any of the values that don't equate to a 1 or a 0 by To_X01(). It's also more typing, especially when you copy code and need to change the name of the clock. lol I also see things like signals in sensitivity lists that are not used in a process, rather than are assigned. I think Ting is new to VHDL and has not learned some of the techniques that help make the code more readable. In particular factoring. For example, in the CPU module the decode process is *huge* and hard to read. There is some irony there, no? I'm curious. Why do you wish to take the workshop? What are you hoping to get from it? I'm taking it to learn something about Ting's and the class's perspective on hardware. Curiosity as much as anything. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-14 17:33 -0700 |
| Message-ID | <f1749ea1-ea9e-4bdb-85d2-548db4161cda@googlegroups.com> |
| In reply to | #46657 |
On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman wrote: > > I'm taking it to learn something about Ting's and the class's > perspective on hardware. Curiosity as much as anything. > May be you can help Ting to improve his design and support him? Cheers, Dirk
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-14 21:09 -0400 |
| Message-ID | <nepepv$dvq$1@dont-email.me> |
| In reply to | #46660 |
On 4/14/2016 8:33 PM, visualforth@rocketmail.com wrote: > On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman wrote: >> >> I'm taking it to learn something about Ting's and the class's >> perspective on hardware. Curiosity as much as anything. >> > May be you can help Ting to improve his design and support him? I'd be happy to, but I don't want to intrude. We'll see what happens in the class. Maybe he will ask for help. I never realized there was much interest in FPGAs in the Forth community. There have been many FPGA implementations of stack processors for programming in Forth like languages, but they are seldom discussed here. Maybe no one asked much about them because no one offered to teach a class before. That's one reason why I asked what Juergen was interested in learning. I'd like to understand what people are looking for. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-15 04:38 -0700 |
| Message-ID | <bac41655-69a1-4ef5-a04e-de93db2f6b0d@googlegroups.com> |
| In reply to | #46661 |
On Friday, April 15, 2016 at 2:09:29 AM UTC+1, rickman wrote: > On 4/14/2016 8:33 PM, visualforth@rocketmail.com wrote: > > On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman wrote: > >> > >> I'm taking it to learn something about Ting's and the class's > >> perspective on hardware. Curiosity as much as anything. > >> > > May be you can help Ting to improve his design and support him? > > I'd be happy to, but I don't want to intrude. We'll see what happens in > the class. Maybe he will ask for help. I never realized there was much > interest in FPGAs in the Forth community. There have been many FPGA > implementations of stack processors for programming in Forth like > languages, but they are seldom discussed here. Maybe no one asked much > about them because no one offered to teach a class before. That's one > reason why I asked what Juergen was interested in learning. I'd like to > understand what people are looking for. > > -- > > Rick I wonder if there is a comparison somewhere regarding: take processor run a program x in Forth run the same program - but on a Forth processor should be faster, lower power, less code. Theoretically it should be possible to grow a Forth Processor implementation in the same way as Forth grows - and in the end you would only have Forth Hardware - no Forth SW at all - or anywhere in between as the split makes sense. I am surprised it has not been done yet - at least I have not heard about it. Try this in C ...
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-15 11:55 -0400 |
| Message-ID | <ner2nc$ej3$1@dont-email.me> |
| In reply to | #46664 |
On 4/15/2016 7:38 AM, JUERGEN wrote: > On Friday, April 15, 2016 at 2:09:29 AM UTC+1, rickman wrote: >> On 4/14/2016 8:33 PM, visualforth@rocketmail.com wrote: >>> On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman wrote: >>>> >>>> I'm taking it to learn something about Ting's and the class's >>>> perspective on hardware. Curiosity as much as anything. >>>> >>> May be you can help Ting to improve his design and support him? >> >> I'd be happy to, but I don't want to intrude. We'll see what >> happens in the class. Maybe he will ask for help. I never >> realized there was much interest in FPGAs in the Forth community. >> There have been many FPGA implementations of stack processors for >> programming in Forth like languages, but they are seldom discussed >> here. Maybe no one asked much about them because no one offered to >> teach a class before. That's one reason why I asked what Juergen >> was interested in learning. I'd like to understand what people are >> looking for. >> >> -- >> >> Rick > > I wonder if there is a comparison somewhere regarding: > > take processor run a program x in Forth run the same program - but on > a Forth processor > > should be faster, lower power, less code. In theory, but how many Forth processors are there in the world? It would be a bit like comparing apples and oranges. Many processors do a good job of running Forth without needing to be "Forth" processors. I believe Forth could be implemented well on the PDP-11, no? Hard to measure the power consumption of that machine though without an AC amp meter, lol. > Theoretically it should be possible to grow a Forth Processor > implementation in the same way as Forth grows - and in the end you > would only have Forth Hardware - no Forth SW at all - or anywhere in > between as the split makes sense. I am surprised it has not been done > yet - at least I have not heard about it. Try this in C ... I'm not sure what that means. Processors are inherently instruction oriented. If you aren't writing Forth words in software, how do you "grow" a processor? Processors are either hardwired or micro-programmed. Hardwiring is not amenable to extension of the hardware without recompiling the HDL. I'm not sure how your Forth compiler would accomplish that. Micro-programmed processors would still use software to do the same thing, it would just be in the microcode rather than the assembly language. When I designed my processor I didn't design it with Forth primitives. I designed it with primitives that could do a good job of implementing Forth. If you want to program in Forth (such as ANS-Forth) you still need a compiler. There is not much point really to extending the hardware for most applications, unless you have some particular function that might be useful for speed enhancement like a barrel shifter, multiplier or similar. If you needed that sort of extension you could easily add it to the HDL along with a corresponding instruction. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-15 10:24 -0700 |
| Message-ID | <d75be6fc-180d-4b1d-8672-51bab1bae90f@googlegroups.com> |
| In reply to | #46666 |
On Friday, April 15, 2016 at 4:55:35 PM UTC+1, rickman wrote: > On 4/15/2016 7:38 AM, JUERGEN wrote: > > On Friday, April 15, 2016 at 2:09:29 AM UTC+1, rickman wrote: > >> On 4/14/2016 8:33 PM, visualforth@rocketmail.com wrote: > >>> On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman wrote: > >>>> > >>>> I'm taking it to learn something about Ting's and the class's > >>>> perspective on hardware. Curiosity as much as anything. > >>>> > >>> May be you can help Ting to improve his design and support him? > >> > >> I'd be happy to, but I don't want to intrude. We'll see what > >> happens in the class. Maybe he will ask for help. I never > >> realized there was much interest in FPGAs in the Forth community. > >> There have been many FPGA implementations of stack processors for > >> programming in Forth like languages, but they are seldom discussed > >> here. Maybe no one asked much about them because no one offered to > >> teach a class before. That's one reason why I asked what Juergen > >> was interested in learning. I'd like to understand what people are > >> looking for. > >> > >> -- > >> > >> Rick > > > > I wonder if there is a comparison somewhere regarding: > > > > take processor run a program x in Forth run the same program - but on > > a Forth processor > > > > should be faster, lower power, less code. > > In theory, but how many Forth processors are there in the world? It > would be a bit like comparing apples and oranges. Many processors do a > good job of running Forth without needing to be "Forth" processors. I > believe Forth could be implemented well on the PDP-11, no? Hard to > measure the power consumption of that machine though without an AC amp > meter, lol. > > > > Theoretically it should be possible to grow a Forth Processor > > implementation in the same way as Forth grows - and in the end you > > would only have Forth Hardware - no Forth SW at all - or anywhere in > > between as the split makes sense. I am surprised it has not been done > > yet - at least I have not heard about it. Try this in C ... > > I'm not sure what that means. Processors are inherently instruction > oriented. If you aren't writing Forth words in software, how do you > "grow" a processor? Processors are either hardwired or > micro-programmed. Hardwiring is not amenable to extension of the > hardware without recompiling the HDL. I'm not sure how your Forth > compiler would accomplish that. Micro-programmed processors would still > use software to do the same thing, it would just be in the microcode > rather than the assembly language. > > When I designed my processor I didn't design it with Forth primitives. > I designed it with primitives that could do a good job of implementing > Forth. If you want to program in Forth (such as ANS-Forth) you still > need a compiler. > > There is not much point really to extending the hardware for most > applications, unless you have some particular function that might be > useful for speed enhancement like a barrel shifter, multiplier or > similar. If you needed that sort of extension you could easily add it > to the HDL along with a corresponding instruction. > > -- > > Rick Rick, I do not understand what you are saying here. Ting did a Forth processor and did eforth, so this would be a comparison. And yes, you do measure current with an AMMeter - how else? LOEL. The software guy speaking? With the PDP11 it is even easier - ask your local energy suppier or look at the meter in your house ... There was never the idea to compare ALL Forth processors - just start with one. If the existing processor do a good job there might be no market for such a product - which is independant - look at the GA144. Even there seems to be no real comparison to a standard processor in a useful application. I think you should read it again - in the same way as you program new Forth words you generate new VHDL - which compiler can digest this is at the moment irrelevant; if there is a paid for case - Inc and MPE would do the job and out might come a new compiler. Even parallel processing would be possible then. And you do not have to recompile on the fly if you design well before - though Altera does it for years. Probably Xilinx as well. But as we are talking about different things so let's stop here.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-15 14:07 -0400 |
| Message-ID | <nerafm$ejh$1@dont-email.me> |
| In reply to | #46667 |
On 4/15/2016 1:24 PM, JUERGEN wrote: > On Friday, April 15, 2016 at 4:55:35 PM UTC+1, rickman wrote: >> On 4/15/2016 7:38 AM, JUERGEN wrote: >>> On Friday, April 15, 2016 at 2:09:29 AM UTC+1, rickman wrote: >>>> On 4/14/2016 8:33 PM, visualforth@rocketmail.com wrote: >>>>> On Thursday, April 14, 2016 at 12:43:02 PM UTC-4, rickman >>>>> wrote: >>>>>> >>>>>> I'm taking it to learn something about Ting's and the >>>>>> class's perspective on hardware. Curiosity as much as >>>>>> anything. >>>>>> >>>>> May be you can help Ting to improve his design and support >>>>> him? >>>> >>>> I'd be happy to, but I don't want to intrude. We'll see what >>>> happens in the class. Maybe he will ask for help. I never >>>> realized there was much interest in FPGAs in the Forth >>>> community. There have been many FPGA implementations of stack >>>> processors for programming in Forth like languages, but they >>>> are seldom discussed here. Maybe no one asked much about them >>>> because no one offered to teach a class before. That's one >>>> reason why I asked what Juergen was interested in learning. >>>> I'd like to understand what people are looking for. >>>> >>>> -- >>>> >>>> Rick >>> >>> I wonder if there is a comparison somewhere regarding: >>> >>> take processor run a program x in Forth run the same program - >>> but on a Forth processor >>> >>> should be faster, lower power, less code. >> >> In theory, but how many Forth processors are there in the world? >> It would be a bit like comparing apples and oranges. Many >> processors do a good job of running Forth without needing to be >> "Forth" processors. I believe Forth could be implemented well on >> the PDP-11, no? Hard to measure the power consumption of that >> machine though without an AC amp meter, lol. >> >> >>> Theoretically it should be possible to grow a Forth Processor >>> implementation in the same way as Forth grows - and in the end >>> you would only have Forth Hardware - no Forth SW at all - or >>> anywhere in between as the split makes sense. I am surprised it >>> has not been done yet - at least I have not heard about it. Try >>> this in C ... >> >> I'm not sure what that means. Processors are inherently >> instruction oriented. If you aren't writing Forth words in >> software, how do you "grow" a processor? Processors are either >> hardwired or micro-programmed. Hardwiring is not amenable to >> extension of the hardware without recompiling the HDL. I'm not >> sure how your Forth compiler would accomplish that. >> Micro-programmed processors would still use software to do the same >> thing, it would just be in the microcode rather than the assembly >> language. >> >> When I designed my processor I didn't design it with Forth >> primitives. I designed it with primitives that could do a good job >> of implementing Forth. If you want to program in Forth (such as >> ANS-Forth) you still need a compiler. >> >> There is not much point really to extending the hardware for most >> applications, unless you have some particular function that might >> be useful for speed enhancement like a barrel shifter, multiplier >> or similar. If you needed that sort of extension you could easily >> add it to the HDL along with a corresponding instruction. >> >> -- >> >> Rick > > Rick, I do not understand what you are saying here. Ting did a Forth > processor and did eforth, so this would be a comparison. But you were talking about the Forth code modifying the hardware of the processor rather than just compiling code. > And yes, you > do measure current with an AMMeter - how else? LOEL. The software guy > speaking? With the PDP11 it is even easier - ask your local energy > suppier or look at the meter in your house ... Yes, I should have used the house power meter as my example (jokingly of course). Actually, you don't often measure current of low power processors directly with an amp meter. Meters usually drop more voltage than is appropriate for powering digital electronics. Rather you can insert a very small series resistance and measure the voltage on that with a high impedance millivolt meter. > There was never the > idea to compare ALL Forth processors - just start with one. If the > existing processor do a good job there might be no market for such a > product - which is independant - look at the GA144. Even there seems > to be no real comparison to a standard processor in a useful > application. Again, I'm not clear on what you mean here. The GA144 is actually a poor example in my book. It is not a good chip for most applications, so comparing it to other processors is hard. Often it requires external support circuitry and so ends up more expensive, larger and more power consuming. Not much point in analyzing code running on a chip that isn't actually part of an application. Any application should be measured in the full context of the solution, not just a small piece of it. There should be a few applications where the GA144 can do well. I'm just not familiar with them. > I think you should read it again - in the same way as you program > new Forth words you generate new VHDL - which compiler can digest > this is at the moment irrelevant; if there is a paid for case - Inc > and MPE would do the job and out might come a new compiler. Even > parallel processing would be possible then. And you do not have to > recompile on the fly if you design well before - though Altera does > it for years. Probably Xilinx as well. But as we are talking about > different things so let's stop here. If you generate VHDL any compiler can synthesize it. My point is that extending the processor is only useful for some small subset of the code you write, usually to improve speed. In those cases why not just code VHDL directly? I think it would be a *huge* job to write an optimizing compiler that would turn Forth code into HDL or harder, directly to the hardware. Even then the Forth code would likely need to be specialized to make it easily synthesizable. There are efforts to do this with C actually. You can use a subset of C to write code that is translated to Verilog (if I remember correctly). The idea being that you can code an application and compile some parts to hardware and other parts remain as software. Change the dividing line as your requirements for speed change. It has not taken off. I think the complexities of the task are not so small and even though both are written in C, the coding methods are very different between software and hardware. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-04-15 10:56 -0700 |
| Message-ID | <727ed282-d511-415b-9300-d8678b5a078d@googlegroups.com> |
| In reply to | #46666 |
On Friday, April 15, 2016 at 5:55:35 PM UTC+2, rickman wrote: > On 4/15/2016 7:38 AM, JUERGEN wrote: [..] > > I wonder if there is a comparison somewhere regarding: > > > > take processor run a program x in Forth run the same program - but on > > a Forth processor > > > > should be faster, lower power, less code. > > In theory, but how many Forth processors are there in the world? It > would be a bit like comparing apples and oranges. Many processors do a > good job of running Forth without needing to be "Forth" processors. Why in theory? This is clearly a false statement. Forth is a way of expressing tasks the hardware should do. Expressing it in a different language doesn't change the task. Forth might be (a lot) easier on the programmer side, but there is only one hardware way to open VALVE A after 1 MINUTE. A Forth processor, executing only Forth standard words, will not have a compiler that is able to reorganize the task specification in an efficient way. Add a compiler to a Forth chip and the result will execute faster, with lower power, with less memory usage than without. However, if you have a good Forth compiler, it can generate code for all existing CPUs, even for yet-to-be-invented FPGA designs, and there is a very big chance that one of these possible future) CPUs is smaller, cheaper, and faster than the first generation Forth chip. All hardware Forth CPUs had some nifty hardware that lifted them above their competitors, and I think *that* was the basis for their (limited) success, not the fact that they could run naive Forth source. -marcel
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-15 14:33 -0400 |
| Message-ID | <nerbup$kn4$1@dont-email.me> |
| In reply to | #46668 |
On 4/15/2016 1:56 PM, mhx@iae.nl wrote: > On Friday, April 15, 2016 at 5:55:35 PM UTC+2, rickman wrote: >> On 4/15/2016 7:38 AM, JUERGEN wrote: > [..] >>> I wonder if there is a comparison somewhere regarding: >>> >>> take processor run a program x in Forth run the same program - but on >>> a Forth processor >>> >>> should be faster, lower power, less code. >> >> In theory, but how many Forth processors are there in the world? It >> would be a bit like comparing apples and oranges. Many processors do a >> good job of running Forth without needing to be "Forth" processors. > > Why in theory? This is clearly a false statement. I don't agree, that's why I made it. I also explained it based on the fact that so many processors run forth very well. > Forth is a way of expressing tasks the hardware > should do. Expressing it in a different language doesn't > change the task. Forth might be (a lot) easier on the > programmer side, but there is only one hardware way to > open VALVE A after 1 MINUTE. I don't understand your point here. > A Forth processor, executing only Forth standard words, > will not have a compiler that is able to reorganize the > task specification in an efficient way. Add a compiler > to a Forth chip and the result will execute faster, with > lower power, with less memory usage than without. I'm not sure what you mean by "add a compiler to a Forth chip", but I also don't see any basis for your conclusion that it would be better in any fundamental way. > However, > if you have a good Forth compiler, it can generate code > for all existing CPUs, even for yet-to-be-invented FPGA > designs, and there is a very big chance that one of these > possible future) CPUs is smaller, cheaper, and faster than > the first generation Forth chip. > > All hardware Forth CPUs had some nifty hardware > that lifted them above their competitors, and I think > *that* was the basis for their (limited) success, not > the fact that they could run naive Forth source. There have been stack processors that Forth can be compiled to. I don't recall any of them being standouts really. There was the RTX2000 if I get the name right. I think mostly it was used because it was rad hard and qualified for space flight. Once you get that accomplished a part will continue to be used long after it is obsolete. It is not the only processor to go into space. I believe they still use the COSMAC 1802 in amateur satellites today. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-18 17:59 -0700 |
| Message-ID | <4d6ad263-e3bd-492a-ac69-844992ff6169@googlegroups.com> |
| In reply to | #46666 |
On Friday, April 15, 2016 at 11:55:35 AM UTC-4, rickman wrote: > Many processors do a > good job of running Forth without needing to be "Forth" processors. I had several projects with the RTX2000 until it disappeared. KK wrote an excellent Forth for it. The RTX2000 was amazing fast and did not need any Assembler programming - Forth is the RTX2000 machine language. That's the most important point! I still have some of these wonderful Forth processors. If you like to try it, please let me know. http://www.somersetweb.com/BruehlConsult/Projects/mc-RISC-EMUF.html I am sure that other microprocessors do a good job emulating Forth, but a Forth chip always is magnitudes better. I guess there are not so many people around using FPGA Forth micros because this still is a more complicated work than using a ready made micro. A ready made and affordable package of a FPGA Forth micro would help to encourage more people to use it. Cheers, Dirk.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-19 03:50 -0400 |
| Message-ID | <nf4nqh$uog$1@dont-email.me> |
| In reply to | #46682 |
On 4/18/2016 8:59 PM, visualforth@rocketmail.com wrote: > On Friday, April 15, 2016 at 11:55:35 AM UTC-4, rickman wrote: >> Many processors do a good job of running Forth without needing to >> be "Forth" processors. > > I had several projects with the RTX2000 until it disappeared. KK > wrote an excellent Forth for it. The RTX2000 was amazing fast and did > not need any Assembler programming - Forth is the RTX2000 machine > language. That's the most important point! > > I still have some of these wonderful Forth processors. If you like to > try it, please let me know. > > http://www.somersetweb.com/BruehlConsult/Projects/mc-RISC-EMUF.html > > I am sure that other microprocessors do a good job emulating Forth, > but a Forth chip always is magnitudes better. The RTX2000 is very obsolete now unless you need rad hardened where there are relatively few choices. The only thing like a Forth chip now is the GA144 which, I hate to say, seems like a miserable failure overall. An interesting experiment, but surely not a commercial success. So saying a "Forth chip always is magnitudes better" seems a bit disingenuous. That was my point, there really are *very* few chips that are much like Forth other than the fact that they use stacks which nearly *every* CPU does these days. > I guess there are not so many people around using FPGA Forth micros > because this still is a more complicated work than using a ready made > micro. A ready made and affordable package of a FPGA Forth micro > would help to encourage more people to use it. Not sure what you are trying to say here. Do you mean there aren't readily available compilers for FPGA Forth micros? Certainly there are plenty of designs for FPGAs, one of the better ones is the J1 which seems to have some degree of popularity (for a stack machine anyway). Another FPGA CPU design which seems to be as popular, if not more so, is the ZPU, a stack machine designed for C programming. Lol! Go figure! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-22 00:33 -0700 |
| Message-ID | <c3746364-4562-4be5-be93-06241253df10@googlegroups.com> |
| In reply to | #46682 |
On Monday, April 18, 2016 at 5:59:19 PM UTC-7, visua...@rocketmail.com wrote: > On Friday, April 15, 2016 at 11:55:35 AM UTC-4, rickman wrote: > > Many processors do a > > good job of running Forth without needing to be "Forth" processors. > > I had several projects with the RTX2000 until it disappeared. > KK wrote an excellent Forth for it. The RTX2000 was amazing fast and did not need any Assembler programming - Forth is the RTX2000 machine language. > That's the most important point! Well, the MiniForth/RACE does have an assembly-language. http://www.testra.com/Forth/index.htm This allows the system to be expanded by adding new primitives. By comparison, a processor such as my Stundurd that has a limited number of primitives (64 for the Stundurd, plus some others that have embedded operands) can't be expanded with new primitives. The MiniForth/RACE assembly-language is extremely low-level. AFAIK, there are only 3 people who know it, and I'm one of them (I wrote the assembler). For the most part, users just program in Forth and leave assembly-language programming to the compiler-writer (I wrote the compiler). The Stundurd, because it is not extendable, is really just a toy. AFAIK, the RTX2000 also had a fixed number of primitives and did not provide any way to extend it to support more primitives. For commercial use, you need a processor like the RACE that can be extended to support the application program. > I am sure that other microprocessors do a good job emulating Forth, but a Forth chip always is magnitudes better. > > I guess there are not so many people around using FPGA Forth micros because this still is a more complicated work than using a ready made micro. > A ready made and affordable package of a FPGA Forth micro would help to encourage more people to use it. Use it for what? When I asked at Testra why an experimenter board had never been made for the MiniForth/RACE I was told: "Hobbyists require too much support and they don't have any money." If you mean, use it for hobbyist projects, then forget it --- that is not what it is for. A lot of C.L.F. folks, especially those on the Forth-200x committee, take themselves super-seriously --- ultimately though, C.L.F. is just a hobbyist forum --- ANS-Forth was just a marketing gimmick from Forth Inc. designed to make people believe that Forth Inc. sets the standard for the Forth community, and Forth-200x is just a marketing gimmick from Forth Inc. designed to make people believe that ANS-Forth matters (that is the whole point of the mandate that Forth-200x has to be 100% compatible with ANS-Forth). The truth is that there are fewer than 20 ANS-Forth programmers in the world, and none of them have written a commercial program in ANS-Forth --- everybody who writes commercial software in Forth abandons ANS-Forth on the first day of the project --- ANS-Forth is primarily used by Anton Ertl's students to write the code for their homework assignments (sudoku, etc.), and most of those programs aren't ANS-Forth anyway because gForth is incompatible with the other ANS-Forth compilers (VFX and SwiftForth) on pretty much every major point (for example, gForth's FIND returns different xt values for certain words depending upon what STATE is at the time that FIND executes; nobody else does that!).
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-15 04:27 -0700 |
| Message-ID | <4fab0b44-aac9-4b70-9811-7d1ca3a15b09@googlegroups.com> |
| In reply to | #46657 |
On Thursday, April 14, 2016 at 5:43:02 PM UTC+1, rickman wrote: > On 4/14/2016 11:10 AM, JUERGEN wrote: > > On Monday, April 11, 2016 at 8:32:41 PM UTC+1, 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. > >> > >> -- > >> > >> Rick > > > > I tried Meetup - - has the link to the Lattice files already been distributed? > > I don't know anything about the link. I sent Ting an email and he sent > the files in an email. Kevin Appert is the only person who said there > was a link. I think you can ask Ting for it or ask him for the files. > > I made the mistake of looking at some of the code. I'm already not > happy with what I see. He uses clk_i'event and clk_i='1' rather than > rising_edge(clk_i). Yes, they are typically the same... unless your > clock has any of the values that don't equate to a 1 or a 0 by To_X01(). > It's also more typing, especially when you copy code and need to > change the name of the clock. lol > > I also see things like signals in sensitivity lists that are not used in > a process, rather than are assigned. I think Ting is new to VHDL and > has not learned some of the techniques that help make the code more > readable. In particular factoring. For example, in the CPU module the > decode process is *huge* and hard to read. There is some irony there, no? > > I'm curious. Why do you wish to take the workshop? What are you hoping > to get from it? > > I'm taking it to learn something about Ting's and the class's > perspective on hardware. Curiosity as much as anything. > > -- > > Rick When I was at Mixed Mode many years ago - actually 18 - I suggested a very small Processor IP, the speed of an 8051 about - when not many people knew what IP was. It was used as a demonstrator at shows running in a Lattice CPLD! Now as the kid is 18 it is time to get it back to life - any FPGA will do probably. I still have the VHDL and Verilog Code - can hardly read either, but there are many out there who can. Ting's project will give me all I need: Training on Lattice tools A core that is working, probably with some IO Interfacing to Lattice DevKit Hardware Having gone through the 2 days, I can ask for help, and with a bit of cut and paste my core should be alive again. And who wrote the Verilog and adapted a Forth for it at the time: Bernd Paysan. Just quoting from an email June 1997, Bernd wrote: I misjudged the work; to build the MISC in Verilog did not take weeks or days - but only hours. Get your soldering irons ready and a demoboard ... Worth reviving for fun - or actually let it do some useful work. see http://homepage.cs.uiowa.edu/~jones/arch/risc/
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-15 06:30 -0700 |
| Message-ID | <cca7c554-779a-4ee8-b9b9-da862f5d0a7a@googlegroups.com> |
| In reply to | #46663 |
On Friday, April 15, 2016 at 12:28:53 PM UTC+1, JUERGEN wrote: > On Thursday, April 14, 2016 at 5:43:02 PM UTC+1, rickman wrote: > > On 4/14/2016 11:10 AM, JUERGEN wrote: > > > On Monday, April 11, 2016 at 8:32:41 PM UTC+1, 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. > > >> > > >> -- > > >> > > >> Rick > > > > > > I tried Meetup - - has the link to the Lattice files already been distributed? > > > > I don't know anything about the link. I sent Ting an email and he sent > > the files in an email. Kevin Appert is the only person who said there > > was a link. I think you can ask Ting for it or ask him for the files. > > > > I made the mistake of looking at some of the code. I'm already not > > happy with what I see. He uses clk_i'event and clk_i='1' rather than > > rising_edge(clk_i). Yes, they are typically the same... unless your > > clock has any of the values that don't equate to a 1 or a 0 by To_X01(). > > It's also more typing, especially when you copy code and need to > > change the name of the clock. lol > > > > I also see things like signals in sensitivity lists that are not used in > > a process, rather than are assigned. I think Ting is new to VHDL and > > has not learned some of the techniques that help make the code more > > readable. In particular factoring. For example, in the CPU module the > > decode process is *huge* and hard to read. There is some irony there, no? > > > > I'm curious. Why do you wish to take the workshop? What are you hoping > > to get from it? > > > > I'm taking it to learn something about Ting's and the class's > > perspective on hardware. Curiosity as much as anything. > > > > -- > > > > Rick > > When I was at Mixed Mode many years ago - actually 18 - I suggested a very small Processor IP, the speed of an 8051 about - when not many people knew what IP was. It was used as a demonstrator at shows running in a Lattice CPLD! > Now as the kid is 18 it is time to get it back to life - any FPGA will do probably. > I still have the VHDL and Verilog Code - can hardly read either, but there are many out there who can. > Ting's project will give me all I need: > Training on Lattice tools > A core that is working, probably with some IO > Interfacing to Lattice DevKit Hardware > Having gone through the 2 days, I can ask for help, and with a bit of cut and paste my core should be alive again. > > And who wrote the Verilog and adapted a Forth for it at the time: Bernd Paysan. > Just quoting from an email June 1997, Bernd wrote: I misjudged the work; to build the MISC in Verilog did not take weeks or days - but only hours. Get your soldering irons ready and a demoboard ... > > Worth reviving for fun - or actually let it do some useful work. see http://homepage.cs.uiowa.edu/~jones/arch/risc/ I just happened to check Forth-ev,de for news, and there I find: CPU Design Workshop I will run a CPU Design Workshop in the SVFIG May 28 meeting. Our European friends are welcome to participate. I recently finished a project in creating an 8080 CPU on Lattice's Brevia2 FPGA Kit. It will serve as a template for participants to try, before they embark on their own target CPU. If any of your friends like to participate, please forward them the two attached files. Regards, Ting. eP16inVHDL.zip : http://www.forth-ev.de/filemgmt/singlefile.php?lid=616 eP8080.zip : http://www.forth-ev.de/filemgmt/singlefile.php?lid=615
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-04-18 21:47 +0000 |
| Message-ID | <nf3kl5$o93$1@dont-email.me> |
| In reply to | #46663 |
Am Fri, 15 Apr 2016 04:27:21 -0700 schrieb JUERGEN: > Just quoting from an email June 1997, Bernd wrote: I misjudged the work; > to build the MISC in Verilog did not take weeks or days - but only > hours. Get your soldering irons ready and a demoboard ... I later wrote a real Forth processor, the b16, and it didn't take much more time than the MISC, but is a much faster processor with denser code. If people want to learn how to create processors in FPGAs, the J1 and the b16 are IMHO the first place to look at, as they are both pretty small and simple, and sufficiently well documented. IMHO they are both more fun than the 8080 and the MISC, because the other two are not really made for Forth. -- 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/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-04-21 01:27 +1000 |
| Message-ID | <nf874q$13tl$1@gioia.aioe.org> |
| In reply to | #46680 |
Bernd Paysan wrote: > Am Fri, 15 Apr 2016 04:27:21 -0700 schrieb JUERGEN: > > > Just quoting from an email June 1997, Bernd wrote: I misjudged the work; > > to build the MISC in Verilog did not take weeks or days - but only > > hours. Get your soldering irons ready and a demoboard ... > > I later wrote a real Forth processor, the b16, and it didn't take much > more time than the MISC, but is a much faster processor with denser > code. If people want to learn how to create processors in FPGAs, the J1 > and the b16 are IMHO the first place to look at, as they are both pretty > small and simple, and sufficiently well documented. > > 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 :)
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-04-20 21:12 +0000 |
| Message-ID | <nf8rcn$4qn$2@dont-email.me> |
| In reply to | #46694 |
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 :) 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. -- 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/
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-20 15:54 -0700 |
| Message-ID | <439e0cd3-2144-4e46-9696-491e0b95dbcf@googlegroups.com> |
| In reply to | #46697 |
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. Cheers, Dirk.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web