|
Page 1 of 1
|
[ 10 posts ] |
|
j68 - a 68000 implemented on a forth microarchitecture
Author |
Message |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
. Frederic Requin wrote an open source 68000 core called J68. It's microcoded but with a two-stack forth-like approach, and comes out pretty small. Only caveat is that there's 3x clock cycle penalty, so a 50MHz implementation would match a 16MHz 68k. (There's another version here which I think might be a little older.) The comments describe it like this: Quote: // Simple re-implementation of the MC68000 CPU // The core has the following characteristics: // - Tested on a Cyclone III (90 MHz) and a Stratix II (180 MHz) // - from 1500 (~70 MHz) to 1900 LEs (~90 MHz) // - 2048 x 20-bit microcode ROM // - 256 x 28-bit decode ROM // - 2 x block RAM for the data and instruction stacks // - stack based CPU with forth-like microcode // - not cycle-exact : needs a frequency ~3 x higher // - all 68000 instructions are implemented // - all 68000 exceptions are implemented
Found via a comment to Experimenting with TG68: Quote: The big advantage of the J68 is its size : 2000 LEs instead of 3500-4000 LEs. I do know that by doing the instruction fetch/decode in parallel with the execute, the performance will be almost doubled. For the moment, I have been too lazy to do it ![Smile :-)](./images/smilies/icon_e_smile.gif) . ... and indeed that whole blog series about the TG68-based miniSOC is worth a look. Index here: http://retroramblings.net/?page_id=770Quote: Part 1 – A Counter Part 2 – A VGA Controller Part 3 – Writing to the Framebuffer Part 4 – Improving memory performance Part 5 – Interrupts and other tweaks Part 6 – A Sprite and a Simple UART Part 7 – The Mouse Part 8 – Timers and C Code Part 9 – Accessing the SD Card Part 10 – Multiple Boards Part 11 – Porting to the Turbo Chameleon 64 Part 12a – A Better Cache Part 12b – A Better Cache Part 13 – Timing Closure at Last Part 14 – Improving the SDRAM controller
|
Mon Jan 09, 2017 12:12 pm |
|
![](./styles/serenity/theme/images/spacer.gif) |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
(See also the kind-of-followup post here: Seeking the smallest 68000 implementation...(Hat tip to hoglet for finding the connection) )
|
Wed Sep 20, 2017 8:50 am |
|
![](./styles/serenity/theme/images/spacer.gif) |
Hugh Aguilar
Joined: Sun Jul 23, 2017 1:06 am Posts: 93
|
BigEd wrote: . Frederic Requin wrote an open source 68000 core called J68. It's microcoded but with a two-stack forth-like approach, and comes out pretty small. Only caveat is that there's 3x clock cycle penalty, so a 50MHz implementation would match a 16MHz 68k. This is rather pedestrian speed --- for a lot of applications though, this is plenty fast --- blazing speed isn't always needed. I think the MC68000 is pretty cool! ![Smile :)](./images/smilies/icon_e_smile.gif) The MC68 was micro-coded, and I have read about Forth-specific versions of the MC68000 being developed in the late 1980s or early 1990s, but I am not aware of them getting much use. I might be interested in working with this J68. There is definitely a ![Cool 8-)](./images/smilies/icon_cool.gif) aspect to this! The MC68000 is for large applications that need data structures, which is also what my TOYF design is for. By comparison, a lot of micro-controllers primarily access I/O ports, but they don't really need data-structures except perhaps the array --- that is what my 65ISR design is for, and ye olde 8051 has been used successfully at this for decades --- I don't see either the J68 or the TOYF shining in this low-level kind of application. BigEd wrote: . Found via a comment to Experimenting with TG68: Quote: The big advantage of the J68 is its size : 2000 LEs instead of 3500-4000 LEs. I do know that by doing the instruction fetch/decode in parallel with the execute, the performance will be almost doubled. For the moment, I have been too lazy to do it ![Smile :-)](./images/smilies/icon_e_smile.gif) . Can anyone make an estimate as to how many LEs the TOYF would require? I don't actually know what an LE is, except that it is a measure of FPGA usage. I have also heard the term LUT used as a measure of FPGA usage, but I don't know what that means exactly either. One of my goals with the TOYF was to make it super-simple so that a small inexpensive FPGA could be used. In most cases, speed is not the primary issue --- cost is the only issue!
|
Wed Feb 28, 2018 5:43 pm |
|
![](./styles/serenity/theme/images/spacer.gif) |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
> Forth-specific versions of the MC68000 I think I've heard this before, but have never been able to find a reference. Can you help with any leads? I do know there was an IBM-flavoured custom microcode version of the 68k - for the XT/370. See here http://www.cpushack.com/2013/03/22/cpu- ... micro-370/or indeed this previous thread viewtopic.php?f=22&t=350
|
Wed Feb 28, 2018 6:15 pm |
|
![](./styles/serenity/theme/images/spacer.gif) |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
Quote: I don't actually know what an LE is, except that it is a measure of FPGA usage. I have also heard the term LUT used as a measure of FPGA usage, but I don't know what that means exactly either. To within a small factor they are comparable. See here and links within. In general all you care about is whether you fit on the FPGA you have, or which FPGA to choose. Any reasonable CPU, I would think, should fit on any reasonable FPGA these days. Quote: Can anyone make an estimate as to how many LEs the TOYF would require? It will very much depend on how the HDL is coded. The various HDLs for 6502 have resulted in implementations ranging from 500 to 3000 LUTs. There's a good chance your CPU could fit in the same range. But I think there's no HDL, or block diagram, for it?
|
Wed Feb 28, 2018 9:45 pm |
|
![](./styles/serenity/theme/images/spacer.gif) |
Hugh Aguilar
Joined: Sun Jul 23, 2017 1:06 am Posts: 93
|
I moved my post over to the TOYF thread at BigEd's request. viewtopic.php?f=13&t=469&p=3473#p3473I am interested in this J68 design though --- anything involving Forth interests me --- also, I always liked the MC68000 design, although I never owned an MC68000 computer so I didn't do any programming for it (I wanted to get a Commodore Amiga or Atari ST, but didn't have the money, and then they became obsolete anyway). I was interested in the Canon Cat too, but it was hugely expensive. The Canon Cat software was written in Forth. I wonder if this J68 could be used instead. The Canon Cat source-code is publicly available now. It might be possible to compile the Canon Cat software using a Forth compiler that has been modified to generate code that takes advantage of the J68 Forth-specific aspects. The J68 is fully MC68000 compatible, so primitives written in MC68000 assembly-language would work with minimal modification. This would allow the J68 to get a big program working on it. This could presumably be done faster than writing a program from scratch in Forth for the J68 --- if you are going to write a program from scratch, you might as well use an ARM Cortex --- the point of the J68 is to run legacy MC68000 Forth programs, I would think.
Last edited by Hugh Aguilar on Thu Mar 01, 2018 8:13 am, edited 1 time in total.
|
Thu Mar 01, 2018 7:35 am |
|
![](./styles/serenity/theme/images/spacer.gif) |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
(The TOYF discussion continues over here.)
|
Thu Mar 01, 2018 7:37 am |
|
![](./styles/serenity/theme/images/spacer.gif) |
Hugh Aguilar
Joined: Sun Jul 23, 2017 1:06 am Posts: 93
|
Hugh Aguilar wrote: I am interested in this J68 design though --- anything involving Forth interests me --- also, I always liked the MC68000 design, although I never owned an MC68000 computer so I didn't do any programming for it (I wanted to get a Commodore Amiga or Atari ST, but didn't have the money, and then they became obsolete anyway).
I was interested in the Canon Cat too, but it was hugely expensive.
The Canon Cat software was written in Forth. I wonder if this J68 could be used instead. The Canon Cat source-code is publicly available now. It might be possible to compile the Canon Cat software using a Forth compiler that has been modified to generate code that takes advantage of the J68 Forth-specific aspects. The J68 is fully MC68000 compatible, so primitives written in MC68000 assembly-language would work with minimal modification. This would allow the J68 to get a big program working on it. This could presumably be done faster than writing a program from scratch in Forth for the J68 --- if you are going to write a program from scratch, you might as well use an ARM Cortex --- the point of the J68 is to run legacy MC68000 Forth programs, I would think. Does anybody know what the legal status of the Commodore Amiga OS or Atari ST is? As I mentioned above, the Canon Cat software is public-domain now. I don't really know what an FPGA is capable of doing. The Commodore Amiga was primarily for game-machine video, and the Atari St was primarily for MIDI --- can an FPGA do this?
|
Fri Mar 02, 2018 12:18 am |
|
![](./styles/serenity/theme/images/spacer.gif) |
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1783
|
An FPGA is a huge number of logic gates with a programmable connection between them. It can do pretty much anything you can do in logic, if it has the capacity: enough gates and enough connectivity and enough pins and enough performance.
Yes, the Amiga and the ST are within the parameters of what an FPGA can do. The Amiga is more complex and therefore requires more FPGA capacity. In both cases you'd need to find suitable HDL descriptions of all the components, or write them. I don't know if that's been done, but a web search would be the first step.
|
Fri Mar 02, 2018 9:00 am |
|
![](./styles/serenity/theme/images/spacer.gif) |
NorthWay
Joined: Thu Jan 17, 2013 4:38 pm Posts: 53
|
There are both OCS/ECS and AGA implementations of the Amiga with matching 68000/68020+ implementations. You can check out Minimig and MiST for starters. There are also ports for the C-One and Turbo Chameleon 64. I think the FPGAArcade has a port and also has its very own implementation in the works. As for "can be done in an FPGA"? Very much so; there is a "68080" Apollo Core implementation that should be a complete Amiga-in-a-box in its v4 incarnation that should be on par with a 150-300MHz 68060 (or perhaps more). Impressive stuff (though not all of us see it as exactly what we were hoping for).
|
Fri Mar 02, 2018 6:39 pm |
|
|
|
Page 1 of 1
|
[ 10 posts ] |
|
Who is online |
Users browsing this forum: No registered users and 45 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|