[HN Gopher] Nintendo 64 Java
___________________________________________________________________
Nintendo 64 Java
Author : zdw
Score : 125 points
Date : 2023-01-12 20:15 UTC (2 hours ago)
(HTM) web link (www.mikekohn.net)
(TXT) w3m dump (www.mikekohn.net)
| [deleted]
| sebazzz wrote:
| Java runs on one million devices plus one, it appears :-)
| [deleted]
| naet wrote:
| I want one of those Everdrive 64s for myself to play with N64
| development but it's nearly the price of a new console at $200...
| qiqitori wrote:
| This is one of the things (along with repair) that finally
| motivated me to learn electronics. You could probably build
| your own Everdrive 64 for less than $20! (Plus hundreds of
| dollars for an oscilloscope and other equipment but you can
| keep that for the next project)
|
| Maybe worth it?
| Decabytes wrote:
| Is there an equivalent to Java Grinder for C#?
| exabrial wrote:
| > "RISC architecture is going to change everything"
|
| Classic
| [deleted]
| aussieshibe wrote:
| Maybe I'm missing something here? This line read like a joke /
| sarcasm to me. But RISC _did_ change everything, didn 't it?
| asveikau wrote:
| > But RISC _did_ change everything, didn 't it?
|
| Iirc it's not such a meaningful distinction anymore. "CISC"
| x86 uses micro-operations internally. "RISC" ARM has several
| different instruction encodings (ARM, Thumb, Thumb-2, A64).
| Increasing numbers of people are working in high level
| languages anyway.
| msla wrote:
| > "CISC" x86 uses micro-operations internally.
|
| Like generations of CISC before it. That doesn't make it
| any less CISC.
|
| https://userpages.umbc.edu/~vijay/mashey.on.risc.html
|
| From that page, which collects a number of Usenet posts by
| John Mashey:
|
| > The RISC characteristics:
|
| > a) Are aimed at more performance from current compiler
| technology (i.e., enough registers).
|
| > OR
|
| > b) Are aimed at fast pipelining
|
| > - in a virtual-memory environment
|
| > - with the ability to still survive exceptions
|
| > - without inextricably increasing the number of gate
| delays (notice that I say gate delays, NOT just how many
| gates).
|
| The point b is where RISC chips really pulled away from
| CISC in terms of architectural design, especially chips
| like the MIPS, which Mashey worked on: The MIPS had a
| number of points where it exposed the tricks it used to
| pipeline more aggressively, even at the expense of making
| compilers somewhat harder to write and/or human assembly-
| language programmers think a bit harder. However, the lack
| of complicated addressing modes (post-increment, scale-and-
| offset, etc.) and the lack of register-memory opcodes with
| ALU operations, and total lack of memory-memory operations,
| is still a very common feature of RISC design.
| bee_rider wrote:
| That seems like RISC changing everything. How much did it
| change things? CISC has been transformed from a true
| competitor to RISC to a sort of abstraction layer on top of
| it.
| chaosite wrote:
| It's a quote from Hackers (1995).
|
| https://www.youtube.com/watch?v=wPrUmViN_5c
| aussieshibe wrote:
| Thanks, somehow I've never seen this movie.
| newswasboring wrote:
| I just rewatched that clip, did the writer transition from
| technobable to relationship dialogue? Because the scene has
| this tension and saying "RISC is good" can also be heard as
| "risk is good".
| doublerabbit wrote:
| Could be a double entendre? Great film.
| kevin_thibedeau wrote:
| Superscalar processors are a bigger advancement.
| als0 wrote:
| Projects like this is why I come to Hacker News.
| mberning wrote:
| That's really cool. I had not heard of Java Grinder before, but
| I'm definitely checking it out.
| monocasa wrote:
| > Most likely most game devs used someone else's RSP code
|
| Yeah, almost all RSP code used was written by SGI/Nintendo and
| used as shipped in the SDK. For a long time emulators simply high
| level emulated the RSP code based on the hash of the RSP binary
| and accepted that a few games like Rogue Squadron simply wouldn't
| run.
| kmeisthax wrote:
| I've heard Nintendo didn't even release an RSP SDK until
| _really late_ in the N64 's life cycle. AFAIK Factor 5 loved
| writing custom microcode for it.
| fexecve wrote:
| There's a fun conspiracy theory that Nintendo intentionally
| made the default RSP binary they provided sub-optimized, so
| that later in the console's life they could release an
| optimized version so that games continue to appear to get
| better. This is likely entirely rubbish, of course.
| JamesSwift wrote:
| I couldnt find an answer online... what does RSP stand for?
| mikepurvis wrote:
| Reality Signal Processor:
| https://www.retroreversing.com/n64rsp
|
| Basically a very, very early programmable GPU, but you were
| writing actual firmware for it, rather than writing the kind
| of high level shader functions that would come a decade+
| later.
| tadfisher wrote:
| I always heard it referred to as "microcode", and there
| were different RSP microcode packages floating around,
| shipped by Nintendo/SGI, or programmed from scratch and
| included in the ROM.
| davb wrote:
| What a wonderful project to read about. It's too easy to get into
| a mindset where you auto-filter your ideas based on whether or
| not it'll make money, or directly help you reach some career goal
| (especially in the HN bubble). This is fun. This is art. I wish I
| took more time to do "pointless" (in the least derogatory sense
| of the word) projects like this one. Bravo.
| andrewmcwatters wrote:
| The graphics and music are next level. I love it.
___________________________________________________________________
(page generated 2023-01-12 23:00 UTC)