<div dir="auto">What about porting or extending something similar to <a href="http://belogic.com/uzebox/index.asp">http://belogic.com/uzebox/index.asp</a><div dir="auto"><br></div><div dir="auto">It's open source console running on a microcontroller. The j2 should be able to handle it. Though an extended library to support 3d on the j3+ should be doable. Just a thought.</div><div dir="auto"><br></div><div dir="auto">Mike</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 18, 2017 8:45 PM, "Ken Phillis Jr" <<a href="mailto:kphillisjr@gmail.com">kphillisjr@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I actually got a side Message in regards to this that was off list... However I figure some of the idea is pertinent...<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 18, 2017 at 3:58 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-244003702632348630gmail-">On 10/16/2017 12:18 PM, Ken Phillis Jr wrote:<br>
</span><span class="m_-244003702632348630gmail-">> I saw this thread from over a year ago, and figured I'd offer a two stage<br>
<br>
</span>This is really a Jeff question (and I think he's flying back from north<br>
america to tokyo this week), but we have a working board design:<br>
<br>
<a href="https://www.cnx-software.com/2017/03/13/turtle-board-is-a-raspberry-pi-2-like-fpga-board-for-j-core-j2-open-source-superh-sh2-soc/" rel="noreferrer" target="_blank">https://www.cnx-software.com/2<wbr>017/03/13/turtle-board-is-a-ra<wbr>spberry-pi-2-like-fpga-board-<wbr>for-j-core-j2-open-source-<wbr>superh-sh2-soc/</a><br>
<br>
None of the problems with that are technical, it's a business-side<br>
thing. We're understaffed and everybody's gotten pulled off to put out<br>
customer fires like _five_times_ now.<br>
<br>
The _technoogy_ has been ready for a year, we have a dozen working<br>
prototypes but haven't done the production run yet. (Ok, Jeff says he<br>
wants to replace the Atmel 8-bit boot processor with an ice40 so it's<br>
open all the way down. Basically there's a tiny proprietary bit in the<br>
existing prototypes that stops mattering after power-on, its job is just<br>
to load (or re-flash) the fpga from the spi ROM, but as long as we<br>
haven't manufactured a production run yet we might as well get _all_ the<br>
programmable logic open hardware, and ICE40 can load _itself_ from SPI,<br>
so... That's probably only a couple days for Martin to modify one of the<br>
prototypes and Jeff has ice40 vhdl code for this from a previous project<br>
in a repo somewhere...)<br>
<br>
(Blah, reading the above article I should take the twitter account back<br>
over. I was doing it initially, but then a sales guy was doing it and he<br>
left last year. I've got the login credentials around here somewhere...)<br>
<span class="m_-244003702632348630gmail-"><br>
> Stage 1: An do it yourself Arduino-like device.<br>
><br>
> This is probably going to use either the J1, and/or J2 core. However,<br>
> almost all of these features will probably make it into the newer cores<br>
> in some form since there is very little reason to exclude these features.<br>
> * 8 Channels of Analog to Digital ( ADC).<br>
<br>
</span>We made a high-end ADC sensor chip as our first asic (in like 2014?)<br>
There's a 150 nanometer shuttle in March we really really really want to<br>
get our SOC on, an that's ANOTHER thing distracting engineers from<br>
shipping Turtle at the moment...<br>
<span class="m_-244003702632348630gmail-"><br>
> * 8 Channels of Digital to Analog Conversion ( DAC). ( Should Match the<br>
> ADC in bits).<br>
> * Inter-Integrated Circuit (I2C) support<br>
> * Inter-IC Sound ( I2S)<br>
> * Serial Peripheral Interface (SPI) support<br>
> * Universal Asynchronous Receiver-Transmitter (UART)<br>
> * Pulse Width Modulation (PWM) support.<br>
> * full-size USB Port or Micro USB Port.<br>
> * Built-in USB Programmer support<br>
> * Built-in USB OTG Support - The example code for this will be use as<br>
> Serial I/O.<br>
> * support for Full size or Micro SDHC Cards.<br>
> * 40 pin gpio header that is electrically compatible with Raspberry Pi GPIO.<br>
<br>
</span>There's a standard for that, it's call the HAT specification.<br>
<br>
  <a href="https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/" rel="noreferrer" target="_blank">https://www.raspberrypi.org/bl<wbr>og/introducing-raspberry-pi-ha<wbr>ts/</a><br>
  <a href="https://docs.particle.io/datasheets/raspberrypi-datasheet/" rel="noreferrer" target="_blank">https://docs.particle.io/datas<wbr>heets/raspberrypi-datasheet/</a><br>
<br>
As far as I know Martin made our thing compatible with that. (The data<br>
pins are wired straight to the FPGA, possibly with little anti-static<br>
filter thingies. I dunno about the power an ground pins, those might be<br>
board-level. There's a thing on it somewhere, I should dig it up and<br>
properly post it on the website, but "complete website redo" is one of<br>
those big can-of-worms things that needs a couple uninterrupted weeks<br>
devoted to it. I have quite the todo list for that...)<br>
<span class="m_-244003702632348630gmail-"><br>
> KickStart Idea 2: Game Console.<br>
<br>
</span>It's nice of <a href="http://archive.org" rel="noreferrer" target="_blank">archive.org</a> to put up the Giant Rom Tarball for download,<br>
but MAME is still a legal minefield, and emulating a saturn turns out to<br>
be a wretched hive of timing dependencies and villainy, based on the<br>
fact that the sh2 didn't _really_ support smp (we _added_ cmpxchg to j2)<br>
so they just had them talk on the same bus and write over each other<br>
with contention managed by wait states, and every game ever goes NUTS if<br>
the timing varies even slightly (our instructions don't take the same<br>
number of clock cycles as sh2 did, several take _less_, and that screws<br>
stuff up...) And they did the same thing with the other custom chips on<br>
the board for sound and video and such, and then they sprayed everything<br>
down with DRM on top of that:<br>
<br>
<a href="https://www.geek.com/games/sega-saturn-finally-cracked-saving-the-console-from-extinction-1661486/" rel="noreferrer" target="_blank">https://www.geek.com/games/seg<wbr>a-saturn-finally-cracked-savin<wbr>g-the-console-from-extinction-<wbr>1661486/</a><br>
<br>
So yeah.<br>
<span class="m_-244003702632348630gmail-"><br></span></blockquote><div><br></div><div>Honestly, I was not thinking of an Emulation Console in my suggestion. My actual Idea was a usable console so developers can learn how to program/develop games in a restrained system. Actually the fact that the base device is limited to 256mb of ram is actually useful in this regards.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-244003702632348630gmail-">
> This is pretty much for the J3, J4 and/or J64 chips. In general mostly<br>
> expansion of features. I also figure a lot of the features on this will<br>
> probably take a lot of time/effort... The features for this are provided<br>
> blow...<br>
><br>
> * EMMC Support<br>
<br>
</span>Per-unit license fee from a lawsuit-happy consortium managing a patent<br>
pool, that's why we implemented the slower spec that's out of patent.<br>
<span class="m_-244003702632348630gmail-"><br></span></blockquote><div><br></div><div>Realistically, having SDCard/MicroSDCard support is the biggest feature. Most end users will not be bothering with EMMC.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-244003702632348630gmail-">
> * SATA Support<br>
> * Memory Controller - This is either DDR3 and/or ddr4 memory support.<br>
<br>
</span>We implemented... lpddr2 is it? Maxes out at 256 megs (largest chip they<br>
manufacture at that spec). Shouldn't be too hard to have 2 of them in<br>
parallel, although the cache controller would have to dispatch (probably<br>
an even/odd straddle by cache line? Ask Niishi-san...)<br>
<br>
Has anybody solved rowhammer in ddr3 or ddr4 yet?<br>
<span class="m_-244003702632348630gmail-"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-244003702632348630gmail-">
> *Audio Output - this not required, but should be helpful. The I2S<br>
> support can probably serve to implement this.<br>
<br>
</span>Turtle has audio out, it's in Rasperry PI.<br>
<span class="m_-244003702632348630gmail-"><br>
> * Video Output - Examples of this includes DisplayPort, DVI, HDMI, MIPI<br>
> Display interface, and VGA ports.<br>
<br>
</span>Turtle has HDMI, it's in Raspberry PI. (Jeff even made a frame buffer<br>
VHDL thing for ELC in the spring, but I didn't get it integrated into my<br>
demo in time due to travel and my own talk the day before.)<br>
<span class="m_-244003702632348630gmail-"><br>
> * 2D Graphics Process - This is mostly OpenVG 1.1<br>
<br>
</span>It's a frame buffer.<br>
<span class="m_-244003702632348630gmail-"><br>
> * 3D Signal Processing - 3d Rendering in OpenGL ES 1.1 or 2.0 should be<br>
> helpful.<br>
<br>
</span>Can 'o worms, plenty of VHDL space though. A guy came to the<br>
<br></blockquote><div><br></div><div><br></div><div>I honestly believe the current J2 Core lacks hardware Floating Point, but that is not a major problem... I was thinking the fastest solution for this would be to add Instructions for Fixed Point math, and have this task broken down into four major stages/tasks...</div><div><br></div><div>Stage 1: Add hardware Accelerated Fixed Point math - Luckily this has two main wikipedia articles, and some example C/C++ code exists. Either way, this can be used to help coax the Integer unit of the device to speed up 3D math.<br></div><div><div><br></div><div><div>Wikipedia: Fixed Point Arithmetic: <a href="https://en.wikipedia.org/wiki/Fixed-point_arithmetic" target="_blank">https://en.wikipedia.org/wiki/<wbr>Fixed-point_arithmetic</a></div>Wikipedia: Q Number Format: <a href="https://en.wikipedia.org/wiki/Q_(number_format)" target="_blank">https://en.wikipedia.org/wiki/<wbr>Q_(number_format)</a> <br></div><div>Github: Libfixmath - the fixed point math library: <a href="https://github.com/PetteriAimonen/libfixmath" target="_blank">https://github.com/<wbr>PetteriAimonen/libfixmath</a></div><div><div>Github: LibfixMatrix - Fixed Point matrix math library: <a href="https://github.com/PetteriAimonen/libfixmatrix" target="_blank">https://github.com/<wbr>PetteriAimonen/libfixmatrix</a></div><div><br></div><div><br></div><div>Stage 2: Add SIMD Instructions for integer math (Signed, Unsigned, and fixed Point)<br></div><div><br></div><div>This is cloning the expanded ALU to handle running various math functions in parallel... In general this should cover the following Functions:</div><div>* Parallel instructions for basic ALU Functions - Think Addition, Subtraction, multiplication, division, etc.</div><div>* Vector Instructions - This is stuff like Dot Product, Cross Product, and Linear Interpolation.</div><div>* Vector Interpolation - this is Linear interpolation between two values with a values.<br></div><div><br></div><div>Stage 3: Implement Texture Block...</div><div>This is mainly 4 sub-Tasks...</div><div>Task 1: Implement Texture Lookup for 1D Textures, 2D Texture (U, V), 3D Texture (U, V, W). In general this is well defined in the OpenGL specification. The biggest change is from the addition of GL_EXT_texture3D which is released in 1996.</div><div><br></div><div>Task 2: Implement basic Texture Filtering. This is mainly texture Interpolation, and most 3D Engines make use of this in some form or another. The filters for this are as follows....</div><div>* Nearest-neighbor interpolation<br>* Bilinear filtering<br>* Trilinear filtering<br>* Optional: anisotropic filtering - This is an extremely expensive operation, which will probably need to wait until the cores support ddr3 or ddr4.</div><div><br></div><div>Task 3: Implement Alpha Blending/Compositing engine - This is mostly hardware implementation of the math functions outlined in:</div></div></div></div><a href="https://www.w3.org/TR/compositing/" target="_blank">https://www.w3.org/TR/composit<wbr>ing/</a></div><div class="gmail_extra"><a href="https://www.w3.org/TR/compositing/" target="_blank"><br></a></div><div class="gmail_extra">Task 4: Texture data is probably going to use options that are not in the Powers of Two.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Stage 4: Implement OpenGL ES 1.1 with this functionality. The big part is include the GL_OES_fixed_point extension.<br></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote"><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * USB Host capability<br>
<br>
In Turtle because Raspberry PI. Our current VHDL is USB 1.1 but the hub<br>
chip upshifts it to 2.0 for the outside world. (And I _think_ somebody<br>
had a clever hack that could make 2.0 work in the VHDL? Ask Jeff, he<br>
keeps finding things Japanese engineers did that never got translated<br>
into English...)<br>
<br>
I believe 3.0 is out though, our hub chip is 2.0 and the FPGA isn't fast<br>
enough to do 3.0 anyway. (That I know of.)<br>
<span class="m_-244003702632348630gmail-"><br>
> * Ethernet/Wireless capabilities<br>
> * Bluetooth<br>
<br>
</span>Did you follow Steam's attempt to make its own game console a few years<br>
back? (Jeri Elsworth was involved, back before CastAR.) They at least<br>
had an existing library of games they could easily port to it. (The<br>
"Good Old Games" people might have some similar luck, although large<br>
chunks of that old stuff is x86 assembly code so there's nothing to port<br>
really...)<br>
<span class="m_-244003702632348630gmail-"><br>
> J-Core Instruction set expansion: Add a cpuid Function -<br>
> This is seen on most major processors, and can save end users/developers<br>
> a lot of problems since the code being run can ensure the rest of the<br>
> program can road since the developer can safely detect missing features<br>
> that are expected.<br>
<br>
</span>That's a Jeff question, but such a thing would probably be on the SOC<br>
not in the processor, meaning we'd do it via device tree. (The boot rom<br>
passes a device tree into the rest of the system, but we're starting to<br>
hit size constraints, so may need some sort of compressed format or<br>
something. Can we save more size than a gzip decompressor is big? Let's<br>
find out!)<br>
<br>
I'm all for the enthusiasm and we REALLY need to get the turtle board<br>
out into everybody's hands. I feel terrible that we haven't already,<br>
Jeff was meeting with somebody just yesterday about getting that going.<br>
<span class="m_-244003702632348630gmail-HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Actually, The CPUID Instruction is an efficient way to pass information about the current SoC/Chip  to the Operating System, Boot loader and software. For intel systems the modern CPUID Function contains about 2048 bits of information (see: <a href="https://en.wikipedia.org/wiki/CPUID" target="_blank">https://en.wikipedia.org/wiki/<wbr>CPUID</a> )... If we apply this to the current project, you can see a lot of information which is extremely useful without wasting a lot of space... Some of the Information provided is as follows....<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* Number of CPUID Pages.<br></div><div class="gmail_extra">* Vendor ID</div><div class="gmail_extra">* Extended Processor Information<br></div><div class="gmail_extra">* Processor/SoC serial Number</div><div class="gmail_extra">* Memory Management Unit Support - If so, possible revision.<br></div><div class="gmail_extra">* Address Mode Support - Does the chip have 16-bit, 32-bit, 64-bit, etc Memory Space.</div><div class="gmail_extra">* Number of CPU Cores</div><div class="gmail_extra">* CPU Core number that ran the instruction.</div><div class="gmail_extra">* Floating Point Unit Support - This is stuff Like 16-bit, 32-bit, 64-bit, etc...</div><div class="gmail_extra">* Floating Point Unit Version/Revision<br></div><div class="gmail_extra">* CPU Memory Address mode - Some chips can toggle between little endian and big endian.<br></div><div class="gmail_extra">* Available Instructions sets - This includes stuff like SIMD Instructions, DSP Instructions, etc.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div></div>
<br>______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a><br>
<br></blockquote></div></div>