SuperRT - realtime raytracing expansion chip

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Bgonzo
Posts: 2
Joined: Wed Dec 16, 2020 8:52 am

Re: SuperRT - realtime raytracing expansion chip

Post by Bgonzo » Wed Dec 16, 2020 9:18 am

This is amazing work! I and many other people on other forums are very curious if these FPGA cores could be implemented on a FXPak Pro, which runs on a Cyclone V just like the DE10- Nano. Does this setup use anything other than the FPGA on the DE-10, like its onboard ram? I know that FXPak Pro users would be ecstatic if this could be run off that device.

93143
Posts: 1314
Joined: Fri Jul 04, 2014 9:31 pm

Re: SuperRT - realtime raytracing expansion chip

Post by 93143 » Wed Dec 16, 2020 5:26 pm

There are conflicting sources. How certain are you that it's a Cyclone V?

It would be incredible to have this on a flash cart.

User avatar
Nikku4211
Posts: 381
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SuperRT - realtime raytracing expansion chip

Post by Nikku4211 » Wed Dec 16, 2020 8:14 pm

93143 wrote:
Wed Dec 16, 2020 5:26 pm
It would be incredible to have this on a flash cart.
As long as it's a flash cart I already own and not some new thing I have to pay an additional $192.99 for.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

ShironekoBen
Posts: 6
Joined: Mon Dec 14, 2020 5:05 am

Re: SuperRT - realtime raytracing expansion chip

Post by ShironekoBen » Wed Dec 16, 2020 9:47 pm

Thanks for all the feedback, everyone!

For reference, no, I'm not Japanese, I just live here! I have no idea where they got that idea from. ShironekoBen is purely a handle formed because my real name is often taken on sites.

And to answer some of the technical questions:
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to use this chipset as a standard rasteriser? If so, how much faster would it be at rasterisation than the Super FX 2 would be? I have heard that raytracing is much slower than rasterisation.
No, it's very much dedicated hardware for raytracing only.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to make a watered down version that's compatible with the non-Pro SD2SNES'/non-Pro FXPak's FPGA?
I'm looking into this, but I suspect if it is possible to do an FXPAK version it will likely be pro-only.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to change calculations to take into account the extra stretch that the SNES does to the internal screen? It seems like each pixel on the SNES in 256x224 mode is pretty wide, with the original 8:7 internal aspect ratio being stretched to 64:49, making your spheres look less like spheres.
...oops! Yes, that's a really simple tweak, which I'm embarrassed to say was on my "to do" list at one point and then got forgotten until you mentioned it here!
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
If you chose 200x160 as a compromise between image size and v-blank time, why not chose a resolution that uses all 256 horizontal pixels, but also uses a smaller vertical resolution? It does give you a letterbox, but hey, at least there's no pillarbox. Also, using a smaller vertical resolution like in 256x120 gives you even more v-blank time, and using that with all the horizontal resolution utilised also allows you to zoom in with a modern widescreen HDTV and not miss anything, since it's letterboxed anyway. Unless you're also using HDMA and you need more h-blank time too.
There's no particularly deep reason there, aside from a vague idea that I wanted to avoid going into ultra-widescreen aspect ratios. It doesn't use HBlank time during the display region so it should definitely be possible to do 256x120 or similar.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
What kind of dithering does your chipset do? What do you think about making it just column-based dithering? Column-based dithering would take more advantage of how some video cables like composite have a blurry horizontal resolution, while probably not being as noticeable as checkerboard dithering.
It's a 4x2 dither matrix applied when converting the image data from 24 bit to 15 bit (and then to 8 bit via a palette mapping table). Vertically-orientated dithering is an interesting idea, though - I prototyped the dithering (well, all the algorithms really) on a PC so I was viewing it on a pixel-accurate monitor, and the notion of playing to the console's output quirks hadn't occurred to me. I may well give that a try - thanks!
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
This demo is running in mode 3, right? 200x160 does require 500 unique tiles, after all, so it can't be mode 7.
It's actually mode 4 due to wanting 2bpp to keep the debug overlay compact (which is what is drawing the little text at the bottom of the screen in the videos), but yeah, not mode 7.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
If your chipset were to convert to mode 7's chunky pixel format rather than mode 3's planar format, and the resolution would be 128x80, which would have 160 unique tiles, and the tilemap is scaled using mode 7's innate scaling abilities to 256x160, would the framerate be any better since there's only 1/4 as much pixels to render and chunky 8BPP is generally faster to render to?
Yeah, that would make it faster as performance essentially scales linearly with rendered resolution. I considered that trick (indeed, I actually used a very similar trick in the Catnip "C# on the GBA" demo I did a while back (https://www.shironekolabs.com/posts/the ... prototype/), which uses the GBA's affine mapping to rotate/scale the screen 90 degrees for easy scanline plotting and to reduce load), but I didn't really want to reduce the resolution that far if I could help it. For an actual game it might be a better tradeoff, though, as it would free up more VRAM for sprites/etc.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Would using 256 colour internally instead of 16 million be faster for your chipset, too, if possible?
That would be difficult to achieve - the ray tracer does a lot of colour maths, so the only way 8 bit color would be realistically usable without a ton of extra logic would be if it was a fixed mapping with (say) 2 bits R, 3 bits G and 2 bits B. That would reduce quality an awful lot :-( It also wouldn't be an "automatic" speed boost, although the space saving might potentially allow adding an extra execution unit, thus gaining speed that way.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
I wonder how a demo with an external ROM would be like. Would you be able to do actual textures in it? If so, how would it be compared to how Super FX 2 does textures? Is it possible to do affine texture mapping with raytracing? If not, is it possible to combine rasterised textures with raytraced CSGs?
Texture mapping in a raytracer is very definitely doable. Texturing would most likely require the chip to have an external texture cache (one per execution unit) that data would be loaded into ahead of time - so an external ROM would be helpful in terms of having more storage space, and maybe a little bit helpful in terms of being able to load data directly from the ROM into the cache rather than having to go via the SNES CPU, but it wouldn't really be a game-changer in that respect.

Adding rasterised textures would require adding rasterisation itself and thus would be an awful lot of work as there's no support for that at all right now.
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
How fast is your chipset's SNES multiply unit compared to the SNES' own multiplication? I heard that you can only do native SNES multiplication during v-blank. Is that true only when you're using mode 7, or is that true for every video mode?
However it's slower than it could be due to the fact that my hardware interface doesn't actually connect the write line on the cartridge to the FPGA (one of those "hey, I don't really need this right now, and I'll wire it up later when I do" decisions that I never got around to correcting), and so writes to the SRT chip are "emulated" by performing reads - essentially there's a 256 byte chunk of address space reserved for "proxied writes", and when the SNES wants to write to a register on the chip it first reads from it (which updates a "last register accessed" value on the chip), and then reads from the appropriate offset in the proxied read area for the byte it wants to write, which gets interpreted on the chip as a write to that register, and increments the "last register accessed" address.

So that adds a bit of extra overhead at present, but it's something I intend to fix when I get a spare moment!

If you're curious, the relevant code looks like this (there's also some obvious optimisations that could be done here like removing the subroutine jumps/etc, too):

Code: Select all

	; Multiplies 16-bit signed fixed-point values in Temp1 and Temp2, putting the 32-bit result in Temp3 and Temp4 (high word in Temp4)
	; Uses the hardware multiply unit on the SuperRT chip
	; Corrupts everything
proc FixedMul16x16Signed, a16i16

	; Write inputs to SRT registers

	RW a8i16
	lda SRTIO_MulAL ; Initialise IO register address
	lda Temp1
	jsr SRTProxyWrite
	lda Temp1 + 1
	jsr SRTProxyWrite
	lda Temp2
	jsr SRTProxyWrite
	lda Temp2 + 1
	jsr SRTProxyWrite

	; Read result
	RW a16i16
	lda SRTIO_MulO0
	sta Temp3
	lda SRTIO_MulO2
	sta Temp4
	rts
endproc

	; Perform a proxied write to an IO register on the SuperRT chip
	; The register to write to must be set beforehand (by reading it)
	; The value to write should be in A
	; Corrupts A and X
proc SRTProxyWrite, a8i16
	xba
	lda #$BF ; Set upper byte to upper byte of SRTIO_WriteProxy
	xba
	tax
	lda 0, x ; Perform read (proxied write)
	rts
endproc
93143 wrote:
Wed Dec 16, 2020 1:57 am
First, would it be possible to support texture mapping? Reflectivity mapping? Normal mapping or some form of bump mapping? (Getting greedy here... but perhaps normal mapping could be a way to integrate sprites for high-detail actors without an unreasonable primitive count? It might be hard to get shadowing to work properly with a normal-mapped sprite...)
Texture mapping is as described above - if texture mapping was implemented then reflectivity mapping and normal mapping would be pretty trivial to add. Sprites are actually interestingly fiddly if you want to do them "properly" (i.e. have them show up in reflections/etc) - they would most likely have to be implemented as a kind of sphere that has special logic to munge the texture UV calculation so that it always appears to be facing the incoming ray. Probably not impossible to do, but I'm not sure if the complexity tradeoff would be worth it, especially as textures would likely be constrained by a relatively small texture cache size so big detailed bitmaps would be off the table (think N64 here, only worse...).
93143 wrote:
Wed Dec 16, 2020 1:57 am
It appears to me that objects can have inherent non-black colours when shadowed. This could presumably be sufficient to create the impression of diffuse lighting, at least as far as being able to see things at all in a shadowed area. Actual diffuse lighting is probably too expensive, but what about multiple light sources? Local (inverse-square), coloured light sources? Could a light source be limited to a defined volume, to avoid the cost of running several sources for the whole scene? (This could also allow flashlights and such without having to physically obstruct the source in order to form the beam... uh, how hard would it be to add cones to the primitive list?) As I understand your scheme, right now it would break on something as simple as a tunnel in a racing game.
At present there's just a single directional light source, with, as you've observed, a bit of an anti-light effect to give some volume in shadowed areas. Multiple light sources could be added but the shadowing would be expensive... I have a vague idea for unifying the ray/exec engine units to allow programmable lighting (so as many light sources as performance permits), which would also allow culling light contributions based on volumes, but that's very much in the "maybe someday" category right now!

Cones... hm... I haven't thought about cones. You could easily build a polygonal cone out of planes if you wanted to, but there isn't any inherent support for "perfect" cones. That would probably be something that could be done as an extension of a cylinder primitive (basically make a cylinder and then warp space to "pinch" one end), but space constraints made me drop the idea of having cylinders for the moment.
93143 wrote:
Wed Dec 16, 2020 1:57 am
How about the ability to include partly transparent objects, both scattering/absorptive and additive? With variable intensity over the volume of the primitive, to produce realistic glow effects or fog/smoke?
(clipped the rest of this paragraph to keep the quote length down, but very good points!)

Basic transparency would probably be relatively easy (it would just require an extra blend unit when merging spans) but with one big caveat - no sorting, so transparency order would be fixed and potentially look wrong when viewed from certain angles. As you say, simple "blend based on ray depth" type participating media like fog would be simple (again, subject to ordering constraints). Since the system already handles clipping ray spans against each other objects inside fog would "just work" as long as the object was processed before the fog.

True participating media with lighting/shadows computed through the volume is far beyond what could be handled, though, I fear!

(continued)

ShironekoBen
Posts: 6
Joined: Mon Dec 14, 2020 5:05 am

Re: SuperRT - realtime raytracing expansion chip

Post by ShironekoBen » Wed Dec 16, 2020 9:49 pm

(continued from above)
93143 wrote:
Wed Dec 16, 2020 1:57 am
Surely N64-style global distance fogging would be easy? Simply adjust the colour of the ray based on how far it's travelled (at every bounce, so reflections would be correctly double-fogged)... maybe allow an adjustment for height or angle, or use some form of fast integral or lookup table to emulate atmospheric altitude effects or fog layers... (I'm a greedy bastard, and my games would run at 3 fps...)
Yep, distance fog with maybe a simple ray angle based colour lookup would be pretty easy to add - I nearly did it at one point but then got distracted.
93143 wrote:
Wed Dec 16, 2020 1:57 am
Having variable frame size could be useful. The Super FX allowed multiple framebuffer sizes, and there was no requirement for the SNES to actually use the whole thing, or even for the Super FX to render to the whole thing.

If my calculations are correct, it should be possible to fractional-buffer 216x176 at 20 fps and still have a bit of VRAM left over for sprites. If you used HDMA for VRAM transfers, you could get 224x168 at 30 fps by expending all 8 HDMA channels (24 bytes per line) and restricting sprites to only 16 or so of the active scanlines. (VRAM HDMA requires you to force blank during the transfer, which kills sprites on the next line.) These numbers assume fully contiguous data, so you don't have to keep stopping to adjust the source address like you do on Super FX if you're using an image height it doesn't support...
I think that would be reasonably easy to add support for, at least for frame sizes smaller than the maximum - the basis parameters that are used to generate the rays are generated on the SNES side, so it would just be a question of fiddling with those to frame the scene correctly, and then adding some extra registers to tell the rendered to not bother with rays outside a defined scissor region. Making the resulting output easier for the SNES to handle would be a question of adjusting the PPU converter - there's some fiddliness there as it has hard-coded assumptions about how to swizzle addresses, but nothing too insurmountable I suspect?

It might actually be easier to do if I implement an optimisation I was pondering - at the moment the renderer builds a full frame and then passes that to the PPU convertor to turn into SNES format data, but it would be faster to run the two in parallel, with the renderer generating one 200x8 slice of screen and then the convertor getting to work on that whilst the renderer does the next slice. In that scheme the convertor would be start/stopping every slice anyway, so it could have an "address adjustment" register to fudge the write address after each line to make the data contiguous.
93143 wrote:
Wed Dec 16, 2020 1:57 am
It's a shame this project appears to be out of reach for the FXPak Pro (Cyclone IV if I'm not mistaken)...
I'm not entirely sure on that yet - since the design makes it very easy to scale down (at the cost of performance) I think there's a decent chance it could be made to work, but it may well be that it's too slow to be useful :-(
Bgonzo wrote:
Wed Dec 16, 2020 9:18 am
This is amazing work! I and many other people on other forums are very curious if these FPGA cores could be implemented on a FXPak Pro, which runs on a Cyclone V just like the DE10- Nano. Does this setup use anything other than the FPGA on the DE-10, like its onboard ram? I know that FXPak Pro users would be ecstatic if this could be run off that device.
Thanks! And no, it doesn't use the onboard RAM or anything else except the FPGA and GPIO pins (well, the debug interface uses the HDMI interface, but that's completely optional), so on that front there's no barrier to it working on an FXPAK... as far as I'm aware it's purely a question of if the design can be made to fit (and what the resulting performance is like). I'm planning to do some initial experiments as soon as I get a bit of spare time!

Thanks for all the awesome ideas!

User avatar
Nikku4211
Posts: 381
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SuperRT - realtime raytracing expansion chip

Post by Nikku4211 » Thu Dec 17, 2020 12:02 am

ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Thanks for all the feedback, everyone!

For reference, no, I'm not Japanese, I just live here! I have no idea where they got that idea from.
So you have no citizenship there? Wow, what a weeb. UwU
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to use this chipset as a standard rasteriser? If so, how much faster would it be at rasterisation than the Super FX 2 would be? I have heard that raytracing is much slower than rasterisation.
No, it's very much dedicated hardware for raytracing only.
And I oop.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to make a watered down version that's compatible with the non-Pro SD2SNES'/non-Pro FXPak's FPGA?
I'm looking into this, but I suspect if it is possible to do an FXPAK version it will likely be pro-only.
And I oop #2.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Is it possible to change calculations to take into account the extra stretch that the SNES does to the internal screen? It seems like each pixel on the SNES in 256x224 mode is pretty wide, with the original 8:7 internal aspect ratio being stretched to 64:49, making your spheres look less like spheres.
...oops! Yes, that's a really simple tweak, which I'm embarrassed to say was on my "to do" list at one point and then got forgotten until you mentioned it here!
Bruh moment.

Yeah, it's really important to make your spheres look like spheres.

Glad it was on your list, at least.

Perhaps it may be possible to use calculations for an anamorphic 40:21 aspect ratio (200x160 is 5:4, which when stretched by the SNES' vide output, becomes 10:7, which is pillarboxed to 4:3, and when stretched to 16:9, 200x160 becomes 40:21 instead of 5:4) so that you can have an anamorphic widescreen mode.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
If you chose 200x160 as a compromise between image size and v-blank time, why not chose a resolution that uses all 256 horizontal pixels, but also uses a smaller vertical resolution? It does give you a letterbox, but hey, at least there's no pillarbox. Also, using a smaller vertical resolution like in 256x120 gives you even more v-blank time, and using that with all the horizontal resolution utilised also allows you to zoom in with a modern widescreen HDTV and not miss anything, since it's letterboxed anyway. Unless you're also using HDMA and you need more h-blank time too.
There's no particularly deep reason there, aside from a vague idea that I wanted to avoid going into ultra-widescreen aspect ratios. It doesn't use HBlank time during the display region so it should definitely be possible to do 256x120 or similar.
Why were you trying to avoid widescreen?

Sure, it'd be weird for people with classic CRTs or 4:3 monitors. However, most people use wide TVs, and they often have a zoom mode. I think it'd be cool if there was a homebrew SNES game that decided to only do letterboxes and not window boxes, that way you can zoom in on an actual TV and it would fill more of the TV's screen without cutting out any actual detail.

If it's anachronistic, I'd like to remind you yet again that your project uses 2 FPGAs to do live raytracing on the SNES, something that consoles didn't seem to do in real-time until the PS5 came out last month.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
What kind of dithering does your chipset do? What do you think about making it just column-based dithering? Column-based dithering would take more advantage of how some video cables like composite have a blurry horizontal resolution, while probably not being as noticeable as checkerboard dithering.
It's a 4x2 dither matrix applied when converting the image data from 24 bit to 15 bit (and then to 8 bit via a palette mapping table). Vertically-orientated dithering is an interesting idea, though - I prototyped the dithering (well, all the algorithms really) on a PC so I was viewing it on a pixel-accurate monitor, and the notion of playing to the console's output quirks hadn't occurred to me. I may well give that a try - thanks!
You're welcome uwu.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
This demo is running in mode 3, right? 200x160 does require 500 unique tiles, after all, so it can't be mode 7.
It's actually mode 4 due to wanting 2bpp to keep the debug overlay compact (which is what is drawing the little text at the bottom of the screen in the videos), but yeah, not mode 7.
But I thought you just did debug through HDMI. Is the overlaid debug text for the things that are only happening on the SNES' side?
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
If your chipset were to convert to mode 7's chunky pixel format rather than mode 3's planar format, and the resolution would be 128x80, which would have 160 unique tiles, and the tilemap is scaled using mode 7's innate scaling abilities to 256x160, would the framerate be any better since there's only 1/4 as much pixels to render and chunky 8BPP is generally faster to render to?
Yeah, that would make it faster as performance essentially scales linearly with rendered resolution. I considered that trick (indeed, I actually used a very similar trick in the Catnip "C# on the GBA" demo I did a while back (https://www.shironekolabs.com/posts/the ... prototype/), which uses the GBA's affine mapping to rotate/scale the screen 90 degrees for easy scanline plotting and to reduce load), but I didn't really want to reduce the resolution that far if I could help it. For an actual game it might be a better tradeoff, though, as it would free up more VRAM for sprites/etc.
Speaking of programming languages, are you coding what the SNES sends to the FPGAs in ASM?

If so, what kind of ASM?
If not, what programming languages are you using?

Also, speaking of ARM-based machines, why do you have an ARM chip in your chipset if it's never used at all?
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
Would using 256 colour internally instead of 16 million be faster for your chipset, too, if possible?
That would be difficult to achieve - the ray tracer does a lot of colour maths, so the only way 8 bit color would be realistically usable without a ton of extra logic would be if it was a fixed mapping with (say) 2 bits R, 3 bits G and 2 bits B. That would reduce quality an awful lot :-( It also wouldn't be an "automatic" speed boost, although the space saving might potentially allow adding an extra execution unit, thus gaining speed that way.
Okay, then how about using 32,768 colours internally with 5 bits R, 5 bits G, and 5 bits B?
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
I wonder how a demo with an external ROM would be like. Would you be able to do actual textures in it? If so, how would it be compared to how Super FX 2 does textures? Is it possible to do affine texture mapping with raytracing? If not, is it possible to combine rasterised textures with raytraced CSGs?
Texture mapping in a raytracer is very definitely doable. Texturing would most likely require the chip to have an external texture cache (one per execution unit) that data would be loaded into ahead of time - so an external ROM would be helpful in terms of having more storage space, and maybe a little bit helpful in terms of being able to load data directly from the ROM into the cache rather than having to go via the SNES CPU, but it wouldn't really be a game-changer in that respect.
Okay. :thonk:
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
Nikku4211 wrote:
Tue Dec 15, 2020 4:01 pm
How fast is your chipset's SNES multiply unit compared to the SNES' own multiplication? I heard that you can only do native SNES multiplication during v-blank. Is that true only when you're using mode 7, or is that true for every video mode?
However it's slower than it could be due to the fact that my hardware interface doesn't actually connect the write line on the cartridge to the FPGA (one of those "hey, I don't really need this right now, and I'll wire it up later when I do" decisions that I never got around to correcting), and so writes to the SRT chip are "emulated" by performing reads - essentially there's a 256 byte chunk of address space reserved for "proxied writes", and when the SNES wants to write to a register on the chip it first reads from it (which updates a "last register accessed" value on the chip), and then reads from the appropriate offset in the proxied read area for the byte it wants to write, which gets interpreted on the chip as a write to that register, and increments the "last register accessed" address.

So that adds a bit of extra overhead at present, but it's something I intend to fix when I get a spare moment!

If you're curious, the relevant code looks like this (there's also some obvious optimisations that could be done here like removing the subroutine jumps/etc, too):
Cool, but I'm much more of a newbie when it comes to 65816 code than you are.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
First, would it be possible to support texture mapping? Reflectivity mapping? Normal mapping or some form of bump mapping? (Getting greedy here... but perhaps normal mapping could be a way to integrate sprites for high-detail actors without an unreasonable primitive count? It might be hard to get shadowing to work properly with a normal-mapped sprite...)
Texture mapping is as described above - if texture mapping was implemented then reflectivity mapping and normal mapping would be pretty trivial to add. Sprites are actually interestingly fiddly if you want to do them "properly" (i.e. have them show up in reflections/etc) - they would most likely have to be implemented as a kind of sphere that has special logic to munge the texture UV calculation so that it always appears to be facing the incoming ray. Probably not impossible to do, but I'm not sure if the complexity tradeoff would be worth it, especially as textures would likely be constrained by a relatively small texture cache size so big detailed bitmaps would be off the table (think N64 here, only worse...).
If only we had something in the SNES hardware itself that allows us to overlay sprites on top of the 3D action...

:hyperthonk:

Get you a SNES VRAM plumber that can unclog the VRAM.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
It appears to me that objects can have inherent non-black colours when shadowed. This could presumably be sufficient to create the impression of diffuse lighting, at least as far as being able to see things at all in a shadowed area. Actual diffuse lighting is probably too expensive, but what about multiple light sources? Local (inverse-square), coloured light sources? Could a light source be limited to a defined volume, to avoid the cost of running several sources for the whole scene? (This could also allow flashlights and such without having to physically obstruct the source in order to form the beam... uh, how hard would it be to add cones to the primitive list?) As I understand your scheme, right now it would break on something as simple as a tunnel in a racing game.
At present there's just a single directional light source, with, as you've observed, a bit of an anti-light effect to give some volume in shadowed areas. Multiple light sources could be added but the shadowing would be expensive... I have a vague idea for unifying the ray/exec engine units to allow programmable lighting (so as many light sources as performance permits), which would also allow culling light contributions based on volumes, but that's very much in the "maybe someday" category right now!

Cones... hm... I haven't thought about cones. You could easily build a polygonal cone out of planes if you wanted to, but there isn't any inherent support for "perfect" cones. That would probably be something that could be done as an extension of a cylinder primitive (basically make a cylinder and then warp space to "pinch" one end), but space constraints made me drop the idea of having cylinders for the moment.
Please do programmable lighting. I want to virtually rave on my SNES as a v-tuber.

When you can't do cans.

If you can't do cones, how are you going to temporarily redirect traffic in a safe manner?
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
How about the ability to include partly transparent objects, both scattering/absorptive and additive? With variable intensity over the volume of the primitive, to produce realistic glow effects or fog/smoke?
(clipped the rest of this paragraph to keep the quote length down, but very good points!)

Basic transparency would probably be relatively easy (it would just require an extra blend unit when merging spans) but with one big caveat - no sorting, so transparency order would be fixed and potentially look wrong when viewed from certain angles. As you say, simple "blend based on ray depth" type participating media like fog would be simple (again, subject to ordering constraints). Since the system already handles clipping ray spans against each other objects inside fog would "just work" as long as the object was processed before the fog.

True participating media with lighting/shadows computed through the volume is far beyond what could be handled, though, I fear!
What would happen if you tried to use the overlay layer as a 'transparent' layer, using the SNES' innate transparency?

Then again, that'd require a bit too much VRAM, even if you're using mode 4.
ShironekoBen wrote:
Wed Dec 16, 2020 9:49 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
Surely N64-style global distance fogging would be easy? Simply adjust the colour of the ray based on how far it's travelled (at every bounce, so reflections would be correctly double-fogged)... maybe allow an adjustment for height or angle, or use some form of fast integral or lookup table to emulate atmospheric altitude effects or fog layers... (I'm a greedy bastard, and my games would run at 3 fps...)
Yep, distance fog with maybe a simple ray angle based colour lookup would be pretty easy to add - I nearly did it at one point but then got distracted.
Fog would be nice, glad to see that a SuperRT Silent Hill can be made.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
Having variable frame size could be useful. The Super FX allowed multiple framebuffer sizes, and there was no requirement for the SNES to actually use the whole thing, or even for the Super FX to render to the whole thing.

If my calculations are correct, it should be possible to fractional-buffer 216x176 at 20 fps and still have a bit of VRAM left over for sprites. If you used HDMA for VRAM transfers, you could get 224x168 at 30 fps by expending all 8 HDMA channels (24 bytes per line) and restricting sprites to only 16 or so of the active scanlines. (VRAM HDMA requires you to force blank during the transfer, which kills sprites on the next line.) These numbers assume fully contiguous data, so you don't have to keep stopping to adjust the source address like you do on Super FX if you're using an image height it doesn't support...
I think that would be reasonably easy to add support for, at least for frame sizes smaller than the maximum - the basis parameters that are used to generate the rays are generated on the SNES side, so it would just be a question of fiddling with those to frame the scene correctly, and then adding some extra registers to tell the rendered to not bother with rays outside a defined scissor region. Making the resulting output easier for the SNES to handle would be a question of adjusting the PPU converter - there's some fiddliness there as it has hard-coded assumptions about how to swizzle addresses, but nothing too insurmountable I suspect?

It might actually be easier to do if I implement an optimisation I was pondering - at the moment the renderer builds a full frame and then passes that to the PPU convertor to turn into SNES format data, but it would be faster to run the two in parallel, with the renderer generating one 200x8 slice of screen and then the convertor getting to work on that whilst the renderer does the next slice. In that scheme the convertor would be start/stopping every slice anyway, so it could have an "address adjustment" register to fudge the write address after each line to make the data contiguous.
Awesome. Good luck on that optimisation.
ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
93143 wrote:
Wed Dec 16, 2020 1:57 am
It's a shame this project appears to be out of reach for the FXPak Pro (Cyclone IV if I'm not mistaken)...
I'm not entirely sure on that yet - since the design makes it very easy to scale down (at the cost of performance) I think there's a decent chance it could be made to work, but it may well be that it's too slow to be useful :-(
Raytracing at any speed on SNES is never too slow. Especially if it can still be run on a flashcart more than 1 person has.

Heck, how would SuperRT be like if only the SNES' own hardware was used, with no expansions?

You'd have to count seconds per frame.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

Erockbrox
Posts: 384
Joined: Sun Nov 23, 2014 12:16 pm

Re: SuperRT - realtime raytracing expansion chip

Post by Erockbrox » Thu Dec 17, 2020 1:29 am

Here are my thoughts:

1) This is amazing. It is not everyday that the SNES gets a new expansion chip like this.

2) It would be great to see if the DE-10 nano could apply this expansion chip to run with the SNES core on the Mister FPGA project.

3) It would also be great to see if this new expansion chip could be made to run on the FPGA on the SD2SNES Pro cartridge. Please note that even in the worst case scenario that it can't be run on the SD2SNES Pro right now that Krikzz may upgrade the FPGA inside the device in the future just like what happened in the Pro version.

4) It would be great if the rom could be separated from the expansion chip itself as a stand alone rom. This way other developers can get a chance to run the rom themselves. An SNES emulator developer could also re-create the SRT expansion chip so that it can potentially be run on an emulator. Could you provide a stand alone rom download for this demo?

5) Sometimes you see really cool tech demos on the SNES, but at the end of the day it's just some pre-rendered movie being played back, so its hard to make an actual game out of that, but your SRT expansion chip allows for a real time environment experience. So now you have the expansion chip, but what you now need is a killer app to show off what the chip can do in the form of a SNES game. It's like if Nintendo/Argonaut made the Super FX chip, but didn't make Star Fox. You could do a port of Doom or similar, but you don't want to use any license that's not yours. So you want to make an original game with this new expansion chip. You could potentially sell the game as a rom download and people with the proper hardware like SD2SNES Pro could potentially play it on real hardware or emulation if the chip is eventually supported via emulator.

6) The next goal in my opinion, is to optimize the engine and maybe further develop the engine and see if this new expansion chip can run on other devices such as the SD2SNES Pro. Once that is more of less done, then you can think about maybe making a full game using the engine if you really want to see this project taken to the next level.

Thanks for reading and you did an outstanding job with this project.

User avatar
Nikku4211
Posts: 381
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SuperRT - realtime raytracing expansion chip

Post by Nikku4211 » Thu Dec 17, 2020 2:26 pm

Erockbrox wrote:
Thu Dec 17, 2020 1:29 am
3) It would also be great to see if this new expansion chip could be made to run on the FPGA on the SD2SNES Pro cartridge. Please note that even in the worst case scenario that it can't be run on the SD2SNES Pro right now that Krikzz may upgrade the FPGA inside the device in the future just like what happened in the Pro version.
Yeah, then you'd have to buy the entire flashcart again for $196.99 or perhaps even more if this FPGA turns out to be even more expensive.
Erockbrox wrote:
Thu Dec 17, 2020 1:29 am
4) It would be great if the rom could be separated from the expansion chip itself as a stand alone rom. This way other developers can get a chance to run the rom themselves. An SNES emulator developer could also re-create the SRT expansion chip so that it can potentially be run on an emulator. Could you provide a stand alone rom download for this demo?
Yeah, maybe Byuu can do it. Oh wait. He's gone.
Erockbrox wrote:
Thu Dec 17, 2020 1:29 am
5) Sometimes you see really cool tech demos on the SNES, but at the end of the day it's just some pre-rendered movie being played back, so its hard to make an actual game out of that, but your SRT expansion chip allows for a real time environment experience. So now you have the expansion chip, but what you now need is a killer app to show off what the chip can do in the form of a SNES game. It's like if Nintendo/Argonaut made the Super FX chip, but didn't make Star Fox. You could do a port of Doom or similar, but you don't want to use any license that's not yours. So you want to make an original game with this new expansion chip. You could potentially sell the game as a rom download and people with the proper hardware like SD2SNES Pro could potentially play it on real hardware or emulation if the chip is eventually supported via emulator.
Bruh.

Who's going to make this 'killer app'? Who's going to buy this 'killer app'?

Oh no!!! He can't use anime characters now!!! TwT

What's the game got to be like, anyway? I mean, you have to take into account the SNES controller only being as good as the original digital-only PS1 controller from the 1990s.

I mean, I have tried 3D modeling in the past, but only for standard polygons.

I wouldn't know what my gay rabbits would look like with CSG, though.

If such a 'killer app' game would be made, I'd want to do the music.

chek out muh mixtape on ModArchive bro its fire bro (Still waiting for 3 of my MODs to be screened there. One of them is a literally Discord.MOD.)
Erockbrox wrote:
Thu Dec 17, 2020 1:29 am
6) The next goal in my opinion, is to optimize the engine and maybe further develop the engine and see if this new expansion chip can run on other devices such as the SD2SNES Pro. Once that is more of less done, then you can think about maybe making a full game using the engine if you really want to see this project taken to the next level.
Yeah, the engines should be optimised before you can start making vidya for it.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

93143
Posts: 1314
Joined: Fri Jul 04, 2014 9:31 pm

Re: SuperRT - realtime raytracing expansion chip

Post by 93143 » Fri Dec 18, 2020 12:39 am

Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
If only we had something in the SNES hardware itself that allows us to overlay sprites on top of the 3D action...
...okay, so there's two types of "sprites" that we're talking about here.

1) overlay sprites, like for a HUD. These are easy to do with the S-PPU.

2) in-world sprites, like monsters in Doom or coins in Super Mario 64. These would pretty much have to be handled by the SuperRT because they have to be integrated into the world - lighting, clipping, fogging, glow, shadowing, reflections (these last two requiring the whole set of view angles to be rapidly accessible to the SuperRT)... It's actually pretty complicated. A simple overlay would look laughably fake, and to get proper occlusion clipping in the general case (not to mention scaling) you'd have to software-render it anyway, so you might as well render it into the picture.
What would happen if you tried to use the overlay layer as a 'transparent' layer, using the SNES' innate transparency?
The SNES is pretty bad at fog (no true alpha blending), and can only do one layer of one type of transparency at a time. This would also hit bandwidth pretty hard, and you'd have to render it on the SuperRT anyway so you might as well blend it at the source IMO.

ShironekoBen wrote:
Wed Dec 16, 2020 9:47 pm
I'm not sure if the complexity tradeoff would be worth it, especially as textures would likely be constrained by a relatively small texture cache size so big detailed bitmaps would be off the table (think N64 here, only worse...).
The potential need for fast access to a bunch of different view angles is a big problem for this, yes. I see that now.

Also, the lack of self-shadowing would give it away. You'd almost be further ahead with voxels; you'd get smooth rotation at least...

...

Regarding texture caching: if the SuperRT had its own ROM, it could fill the texture cache as needed. A dual-ported cache, or a pair of caches, would allow texture loading without interrupting rendering. But if I understand ray tracing correctly, you can't just draw a whole primitive and then refresh the texture cache like you can on N64; you'd need random access. Perhaps it would be possible to determine roughly where on the screen a certain texture will be needed, and load it before you get there... but then that runs into the same problem as 3D sprites: reflective surfaces can be anywhere. Nintendo's FastROM spec back in the day was 120 ns, so at 50 MHz that'd be at least a 5-cycle wait state on a cache miss...

It strikes me that alpha (or at least 1-bit transparency) in textures might be possible. Does this ruin your branch prediction?
True participating media with lighting/shadows computed through the volume is far beyond what could be handled, though, I fear!
My desperate flailing didn't give you any ideas for a workable algorithm?

There's a SNES homebrew that uses raymarching with fractional occlusion on the bare S-CPU (in 2D, of course, and crucially at tile resolution), using a massive unrolled loop. It looks pretty good in motion (I believe the latest version of the lighting is here, but IMHO the best-looking shadowcasting is in this version).

Unfortunately the memory required to do a whole 3D world even at low resolution would be prohibitive, not to mention the computational cost. Just tracking the space occupied by fog objects (and scaling the resolution with distance) could help, but it still seems like it would be at best a tradeoff between resource overload and being blocky/blurry...

And it still wouldn't work on distance fogging.

Hmm... Doing even a 32x32x32 grid (of whatever shape) would take 32 KB of RAM and an awful lot of calculation (that's more nodes than there are pixels in the image), and it would still look blocky, or blurry if interpolated, and you'd still need to integrate through it for every pixel...

I thought of constructing projected shadow objects from every solid primitive, once per light source (requiring cylinders at a minimum, and truncated cones for local light sources). A texture's alpha bit could be used as-is for a mask to produce finer detail... But even this would make observer rays take several times as long to compute, as well as at least doubling the number of objects the chip needs to track...

Maybe it is best to just use one illumination test per fog object after all, and forget about casting shadows into distance fog...

ShironekoBen
Posts: 6
Joined: Mon Dec 14, 2020 5:05 am

Re: SuperRT - realtime raytracing expansion chip

Post by ShironekoBen » Fri Dec 18, 2020 8:11 pm

Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Why were you trying to avoid widescreen?
I wasn't trying to avoid widescreen entirely, just that I felt like a very widescreen aspect ratio would make it feel "less SNES-like". It was purely an aesthetic decision, really.
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
But I thought you just did debug through HDMI. Is the overlaid debug text for the things that are only happening on the SNES' side?
The HDMI debug output is for the internal state of the SRT chip, whilst the SNES-side debug output is for SNES-side stuff. Especially when debugging communication between the two being able to see debug data from both sides was important.
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Speaking of programming languages, are you coding what the SNES sends to the FPGAs in ASM?

If so, what kind of ASM?
If not, what programming languages are you using?
The command buffer that gets sent to the SRT is in a custom instruction format - it can be hand-coded (and indeed, I did initially), but that got pretty painful once I moved beyond simple debug scenes, so I wrote a scene compiler that takes a textual description of the scene and compiles it down into an instruction sequence.
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Also, speaking of ARM-based machines, why do you have an ARM chip in your chipset if it's never used at all?
That's because I'm using an off-the-shelf FPGA development board (the DE10-Nano), which has an ARM core and a bunch of other peripherals included.
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Okay, then how about using 32,768 colours internally with 5 bits R, 5 bits G, and 5 bits B?
15-bit colour is used as part of the conversion process (because it keeps the lookup table for the palette map at a sensible size)... 15-bit colour for the internal maths would be perfectly doable but there would be a quality hit (you get quite a lot of banding on 15-bit colour - that's why I added dithering) and it probably wouldn't save that much logic.
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
What would happen if you tried to use the overlay layer as a 'transparent' layer, using the SNES' innate transparency?

Then again, that'd require a bit too much VRAM, even if you're using mode 4.
That would work fine, but as you say VRAM is limited.
93143 wrote:
Fri Dec 18, 2020 12:39 am
Regarding texture caching: if the SuperRT had its own ROM, it could fill the texture cache as needed. A dual-ported cache, or a pair of caches, would allow texture loading without interrupting rendering. But if I understand ray tracing correctly, you can't just draw a whole primitive and then refresh the texture cache like you can on N64; you'd need random access. Perhaps it would be possible to determine roughly where on the screen a certain texture will be needed, and load it before you get there... but then that runs into the same problem as 3D sprites: reflective surfaces can be anywhere. Nintendo's FastROM spec back in the day was 120 ns, so at 50 MHz that'd be at least a 5-cycle wait state on a cache miss...
Yeah, it would need to be random-access. With an on-chip cache the fetch latency is effectively two cycles, which isn't *so* bad, especially since it should be possible to mask some of the access time by making texture mapping use two instructions (one that calculates the lookup address and starts the fetch, and another one a couple of cycles later that uses the result, allowing some other instructions to do useful work whilst waiting).
93143 wrote:
Fri Dec 18, 2020 12:39 am
It strikes me that alpha (or at least 1-bit transparency) in textures might be possible. Does this ruin your branch prediction?
Alpha blending would have the same constraints as discussed earlier for transparent objects in general, but alpha blend/test wouldn't have any impact on the branch prediction as program flow wouldn't diverge based on the test result (SRT uses ARM-like conditional instructions to avoid branching in cases like that, so branches are really only something that happens when doing culling tests and the like).
93143 wrote:
Fri Dec 18, 2020 12:39 am
Maybe it is best to just use one illumination test per fog object after all, and forget about casting shadows into distance fog...
Yeah... as cool as true lit fog would be, I have enough performance headaches already! :D

User avatar
Nikku4211
Posts: 381
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SuperRT - realtime raytracing expansion chip

Post by Nikku4211 » Sat Dec 19, 2020 4:17 am

ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Why were you trying to avoid widescreen?
I wasn't trying to avoid widescreen entirely, just that I felt like a very widescreen aspect ratio would make it feel "less SNES-like". It was purely an aesthetic decision, really.
Because as we all know, the SNES was known for its raytracing capabilities.

Nice A E S T H E T I C .

Now we just need some Windows 9x icons and GUI elements.
ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Speaking of programming languages, are you coding what the SNES sends to the FPGAs in ASM?

If so, what kind of ASM?
If not, what programming languages are you using?
The command buffer that gets sent to the SRT is in a custom instruction format - it can be hand-coded (and indeed, I did initially), but that got pretty painful once I moved beyond simple debug scenes, so I wrote a scene compiler that takes a textual description of the scene and compiles it down into an instruction sequence.
So how optimised is this compiler when it comes to the performance of the compiled program?
ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Also, speaking of ARM-based machines, why do you have an ARM chip in your chipset if it's never used at all?
That's because I'm using an off-the-shelf FPGA development board (the DE10-Nano), which has an ARM core and a bunch of other peripherals included.
0wO So more than 1 cartridge can be produced with the right wiring and voltage converters.
ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
Nikku4211 wrote:
Thu Dec 17, 2020 12:02 am
Okay, then how about using 32,768 colours internally with 5 bits R, 5 bits G, and 5 bits B?
15-bit colour is used as part of the conversion process (because it keeps the lookup table for the palette map at a sensible size)... 15-bit colour for the internal maths would be perfectly doable but there would be a quality hit (you get quite a lot of banding on 15-bit colour - that's why I added dithering) and it probably wouldn't save that much logic.
When you only have 32 shades of each colour and not 256. :sadpeepo:
ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
93143 wrote:
Fri Dec 18, 2020 12:39 am
Maybe it is best to just use one illumination test per fog object after all, and forget about casting shadows into distance fog...
Yeah... as cool as true lit fog would be, I have enough performance headaches already! :D
Yeah bro, you don't need the fog to be lit in order for the whole thing to be lit. :fire:
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

93143
Posts: 1314
Joined: Fri Jul 04, 2014 9:31 pm

Re: SuperRT - realtime raytracing expansion chip

Post by 93143 » Sat Dec 19, 2020 8:12 am

ShironekoBen wrote:
Fri Dec 18, 2020 8:11 pm
Alpha blending would have the same constraints as discussed earlier for transparent objects in general, but alpha blend/test wouldn't have any impact on the branch prediction as program flow wouldn't diverge based on the test result (SRT uses ARM-like conditional instructions to avoid branching in cases like that, so branches are really only something that happens when doing culling tests and the like).
Okay. I was just thinking that for transparency keying, you'd have to decide whether or not the ray continued to propagate. But I haven't got a low-level understanding of what you're doing, which is why I asked.

...

Please excuse me if I sound like I'm trying to dictate a development pathway. I was just thinking about what additional features might be useful for games, and a couple of the answers I came up with turned out to be more complicated than they looked. And then it turned out to be interesting to speculate and try to wrap my brain around how one might, in principle, do those things, with the possibility in mind of maybe giving you a good idea in the process.

...

Fun fact (which you may already know): the Nintendo 64's blender doesn't clamp its output. This design decision seems to have been based on the idea that since it was an alpha blender and all the inputs were clamped, it was impossible for the result to overflow.

Unfortunately, there are things you can't do with an alpha blend, and while an additive blend mode was included in the final product, it was kneecapped by the lack of output clamping. This had a profound effect on the visual character of the N64's library - developers effectively couldn't use additive blending, so they had to try to fake it with alpha, and it doesn't quite work. In principle, it's possible to get around the problem using multipass rendering with the color combiner (or software rendering, obviously), but it's a lot more work and would have slowed things down.

This is why I mentioned glow objects...

ShironekoBen
Posts: 6
Joined: Mon Dec 14, 2020 5:05 am

Re: SuperRT - realtime raytracing expansion chip

Post by ShironekoBen » Tue Dec 22, 2020 1:55 am

Nikku4211 wrote:
Sat Dec 19, 2020 4:17 am
So how optimised is this compiler when it comes to the performance of the compiled program?
The nature of the instruction set (more-or-less one instruction per primitive) means that it's fairly close to "optimal"... or, if you want to look at it the other way around, it's pretty hard for it to be sub-optimal most of the time because there generally isn't more than one way to represent a given object.

That said, there is one exception to that I'm aware of - there's a (very small) speed boost that could be had in some circumstances from determining if a branch is likely to be taken or not and rearranging the code to make the "branch not taken" case the more common one, as a taken branch incurs a two cycle penalty even if correctly predicted. But that's a very, very minor speed win, I imagine.
Nikku4211 wrote:
Sat Dec 19, 2020 4:17 am
0wO So more than 1 cartridge can be produced with the right wiring and voltage converters.
Yeah, the hardware is pretty flexible - my version is handicapped a bit by only having address bus A wired up (so max 64K address space), and not having the write line attached (so you have to do hoop-jumping to simulate writes), but fixing those would just be a case of adding another level shifter IC and some wires, at which point you'd have a setup that could be used to develop almost any type of cartridge you felt like (well, maybe with the exception of if you wanted to do clever things with the external audio feed, but again that could be supported relatively easily too).

The DE10-Nano is a very nice board for FPGA dev - decently meaty hardware, lots of expansion devices and a very strong user community (especially around MISTer).

ShironekoBen
Posts: 6
Joined: Mon Dec 14, 2020 5:05 am

Re: SuperRT - realtime raytracing expansion chip

Post by ShironekoBen » Thu Dec 24, 2020 5:57 am

Answering some of the tools questions in a little more details, I've posted a bit more info and some screenshots here.

Post Reply