<tnt>
corecode: my only issue ith the code is that during a time you have the RGBPU port that still exists and still has a 'net' pointer in it that points to free'd memory.
<maikmerten>
(my RV32I core @25.125 MHz, doing everything in soft-float)
<emeb>
Nice
<emeb>
maikmerten: what FPGA is that running on?
<maikmerten>
ice40 HX8K
<maikmerten>
about 1000 - 1100 LEs for the CPU
<maikmerten>
(of 7680)
<maikmerten>
with single-cycle shift operations, resource consumption goes up to about ~1300 LEs for the CPU
<emeb>
not bad. your own design for risc-v?
<maikmerten>
and then it renders in ~32000 ms
<maikmerten>
yup
<emeb>
fun
<maikmerten>
yes, indeed!
<emeb>
Just serial I/O for now?
<maikmerten>
no, it also has 640x480@16 colors VGA-signal output
<maikmerten>
but I haven't wired that mandelbrot renderer to the VGA framebuffer yet
<emeb>
doo eeet!
<maikmerten>
oh, I will. I will.
<emeb>
I imagine that will take some time tho ;)
<emeb>
(to render)
<maikmerten>
yes, and will also make the CPU ~20% slower
<maikmerten>
(because the VGA unit will steal every other RAM clock cycle when in active display region)
<emeb>
Hmm...
<maikmerten>
so that whole thing is pretty much like a Sinclair Spectrum: If you want to go fast, you have to disable display output ;-)
<emeb>
External RAM I suppose.
<maikmerten>
yes, 512kx8 SRAM
<tnt>
maikmerten: how much cycle per instruction do you use ?
<emeb>
Can't run the RAM interface @ 2x and interleave access?
<maikmerten>
emeb, in theory, yes. I don't trust such high-frequency operations over 2.54 mm pin headers, though. Also I don't trust my board design ;-)
<maikmerten>
tnt, oh, quite a lot, actually
<maikmerten>
I have a state diagram somewhere, wait a sec
<emeb>
maikmerten: should at least try - you may be pleasantly surprised.
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<maikmerten>
emeb, yeah :-)
<maikmerten>
the usual ALU-Ops work in fetch - decode - exec, so three states
<maikmerten>
(I do register writeback in fetch)
<emeb>
maikmerten: I've done SDR stuff @ 40-80MSPS over 2.54mm pin headers w/ Lattice & Xilinx parts on my own boards and it worked fine.
Laksen has quit [Quit: Leaving]
<maikmerten>
HOWEVER, my SRAM is 8 bits wide, instructions are 32 bit, so I need 4 accesses to SRAM - plus one cycle to get things moving. So 5 cycles are spent on fetch. So that is the bottleneck
<tpb>
Title: GitHub - maikmerten/hx8k-breakout-extension: A PCB with SRAM, buttons, LEDs and some pmod-compatible connectors for the Lattice HX8K Breakout Board (at github.com)
<maikmerten>
signals look good on the oscilloscope, though
<maikmerten>
(and yes, one single pin-connector does not have enough signals for that SRAM, so I have to borrow signals from two)
<emeb>
maikmerten: what HX8k board are you using?
<tnt>
I pushed 300 Mbps though a 2.54mm connector not that long ago.
<maikmerten>
it's a wacky little board, with a lot of IO accessible.
<emeb>
indeed
<maikmerten>
currently on its way from asia is another extension board, which will give me another three pmod-ports (and one IR-receiver)
<emeb>
RAM is one of the reasons I prefer the iCE40 Ultra Plus over the HX, even though its got slower timing.
<maikmerten>
yeah, the embedded SPRAM is a big bonus
<emeb>
having 128kB on-chip makes small system design a whole lot easier.
<maikmerten>
indeed.
<maikmerten>
but I was hell-bent on 640x480 with at least 16 colors, so that doesn't fit
<maikmerten>
with 512kx8 I even have room for several framebuffers (err... exactly three), so I could do double-buffering if needed
<emeb>
Nice
<emeb>
tnt has an interesting video system in the works with lots of indirection that manages to do some nice hi-res color in minimal RAM using lots of maps and tiling.
<emeb>
I've been working on an 800x600 VGA using 8x8 characters w/ 16 color fore/back selectable on a per-char basis. Full screen fits in < 16kB
<maikmerten>
oh, nice
<maikmerten>
I also have a primitive 40x30 text mode, 8x8 pixels per character, 8 bit color (split for fore- and background)
<maikmerten>
currently uploading a little demo
<maikmerten>
that one is reasonably fast ;-)
<maikmerten>
(upload takes forever)
<maikmerten>
(yeah consumer DSL)
<emeb>
heh
<maikmerten>
(~66% done)
<emeb>
I need to add a pixel-graphics mode to mine. It'll be just 1bpp and 400x300 to keep it fitting in the available RAM, but at least I can draw monochrome stuff.
<maikmerten>
yeah, that'd still be very useful
<maikmerten>
keep in mind the first Mac was 1bpp, too
<emeb>
True. You can do a lot w/ a bit of dithering.
<tnt>
I also tried temporal dithering, how it turns out highly depend on the screen. PC monitors tend to be fine. TVs ... not.
<tpb>
Title: badapple.mp4 - Google Drive (at drive.google.com)
<emeb>
cute. how did you get all that data into the FPGA?
<maikmerten>
emeb, there's a 32 MBit SPI-Flash device (that tiny board hanging onto the SRAM-extension board, visible at around ~0:40)
<maikmerten>
it's all character-based graphics, but the font is not hardcoded. The font is generated on my PC by reading in all frames, determining all 8x8 pixel blocks - and then doing k-means clustering
<tnt>
neat !
<maikmerten>
so I basically have one 256-entry codebook, and every frame is 1200 bytes
<maikmerten>
but I compress that down with simple run-length encoding
<emeb>
amaze
<tnt>
Definitely would be interested to see that code :)
<maikmerten>
so on average every frame is about 280 bytes
<emeb>
haha
<emeb>
I guess that explains the "torn paper" edges.
<maikmerten>
heh
<emeb>
"art"
<maikmerten>
yes
<maikmerten>
it's basically very bad vector quantization, but in motion things end up being "fine-ish"
<emeb>
looks like your changing the color sometimes too
<maikmerten>
nope, I don't. Camera cleverness, I guess.
<emeb>
how does white balance work? :)
<maikmerten>
"badly"
<maikmerten>
tnt, oh, I can provide the code. It's horrible.
<maikmerten>
tnt, on a scale of evilness, it's about 8.79 metric Cthulus
<emeb>
lol
<emeb>
"Disclaimer: running this (or even looking at it too long) may invoke Old Gods"
<tnt>
and a few lines later the definition of spi_regs
rohitksingh has quit [Remote host closed the connection]
<tnt>
this is how I do hw registers now and it works and maps fine without any overhead vs directly doing the lenghty *((volatile char*)REG_ADDRESS)
<maikmerten>
heh
<maikmerten>
oh, and the compressor that compresses the animation is written in Java. Anyone really wants to see *that* code?
<tnt>
hehe, sure.
<maikmerten>
eeek.
<tnt>
Although I don't really like most implementations of java, I actually find the language pretty nice. Haven't used it in forever but I loved the concept of interface / implemtation and also the fact it came with a standard lib that was actually useful.
<tnt>
Compared to other languages at the time, I think it was nice.
<tnt>
Basically this pushes the noise at much higher frequencies than PWM, making it easier to filter out.
<maikmerten>
ah, neat
<maikmerten>
thanks
<tnt>
and in FPGA you can do PDM just as easy as PWM.
<corecode>
tnt: the video
<tnt>
In microcontroller usually not ... they have pwm peripheral but not pdm.
<tnt>
corecode: Ah oki :) Yeah it's fun stuff.
<maikmerten>
yeah, the idea of using PWM is basically µC-inspired
<maikmerten>
for instance, how the RPi handles its audio
<maikmerten>
(well, that is not a µC)
<maikmerten>
but if PDM pushes the noise much higher, then I can get away with a less steep lowpass
<tnt>
Exactly :)
<maikmerten>
perhaps RC or whatever
<tnt>
Yeah and if you have 45 min to waste you can listen to my rambling about tricks to increase precisions and lower noise even more : https://www.youtube.com/watch?v=2pAy5DvuidA