[J-core] Pondering j-core kickstarter ideas.

[mike maloney]

What about porting or extending something similar to
http://belogic.com/uzebox/index.asp

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.

Mike

On Oct 18, 2017 8:45 PM, "Ken Phillis Jr" <kphillisjr at gmail.com> wrote:

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