That was not too hard :)

I just implemented the PPU on the bare metal raspberry pi 3 port of UXN. Likely slow for now, we still need to track dirty tiles/lines and use the DMA for copying memory to the framebuffer.

Also, we can make this more efficient if we request an 8 bit depth or smaller instead of the 32 bit, but I'm unsure about how to best handle that at the moment.

With a small resolution though, doesn't seem to be a performance issue. We may want to add VSYNC though lol.

Ah much better, no more zipping around my dvd friend!

Probably there is a better way of doing the 60 Hz sync, but I don't really want to mess around with interrupts right now.

Follow

Bare metal UXN running on the PI4 hardware!

For some reason this refused to work with -O2 optimizations, but works fine on -O1. Probably need to do some assembly archeology to find what is going on.

@neauoire this may take a bit of time I need to research how the usb protocol works lol

@neauoire we can totally do input via gpio if that suits you ;)

@bd could be its own device, I have a bunch of little resistance strips and other things like it

@neauoire it can just be the controller device, we just assign a pin to each button, we have more than enough

@bd it would be so neat if mouse and keyboard were GPIO instead of USB..

@neauoire the uart works for input/output via gpio, this works already on the went image of you do uqrt_getc but noise I don’t think so, apparently Bluetooth is easier than usb but I know neither in detail

@neauoire @bd good point, but i'm guessing it could be easier to connect one to the gpio pins, and implement the PS/2 protocol, than implement USB 🤔

@bd
> assembly archeology
look for “undefined behaviours”
very few other ways exists that can break things like this.

@smlckz I couldn’t really see UB, since the issue appears when writing to an initialized stack allocated array, but only when the writes are at specific positions.

Looks to me that the optimizations break the ARM 16 bit alignment requirements but need to dig into assembly to see what is going on.

@smlckz Thanks this is nice, though I can't use memcpy since I'm not using the standard library. As I suspected the strb instructions got converted into a rev16 + sturh. I imagine that when the offset is not aligned it was rising the issue. The mempoke16 function was behaving correctly in -O2 but the compiler was inlining it and was being optimized as mentioned.

If I force the compiler to not inline the mempoke16 function, everything seems to work again.

@bd baaaaaare metal? I knew this was gona happen. awesome <3

Sign in to participate in the conversation
Merveilles

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.