What I have so far are simple demos, without anything even close to a kernEl. What I have is closer to the c64 karnAl in the sense that I have a few functions that do stuff but then again it's even smaller than that. Also I expect the usual firmware that boots linux to do its setups before booting my program.
A "sprite" is a small bitmap image that can be moved around and rendered onto the screen at an arbitrary position. For example, Mario and his enemies in Super Mario Bros. are displayed as sprites.
"Hardware sprites" means you can tell the graphics hardware to draw the sprite itself, as opposed to the programmer having to redraw the background and then copy the sprite's pixel data on top of it for every frame.
yep :-) only thing to add: hardware sprites do not necessarily have to be small in size. What characterise them is the fact that you don't have to redraw them in software every frame in order to move them.
The SOC designer decided for whatever reason not to disclose this kind of information. They published quite a lot of stuff about the GPU on the other hand. They must have their own reasons and I am going to respect that.
Apologies, this is what I posted nonetheless. Showing the reverse engineering would be probably extremely boring for most people. It's many hours of me coding, extracting the SD card from the Mac, inserting it into the pi and getting frustrated because it does not work as I expected yet until finally I get it right and say "YES!" :-)
> Why does one need to reverse engineer a Raspberry Pi?
For fun probably!
> Isn't it fairly well documented?
In terms of installing linux to a sdCard, basic IO manipulation, serial interfaces like i2C SPI, sure. The GPU, no. It has actually always been famously a closed-source/closed-hardware black box.
This is fine for an intro to embedded systems and kids, but when you really want to take your hardware/low-level-software knowledge to the next level it can be frustrating.
I always loved low level programming. I started as a kid on a c64 and then on an Amiga and really loved tinkering with those. Then when I got old enough to get a job in the computer industry there were layers of software everywhere and no more tinkering. I felt cheated.
I love old school games more than modern ones. This is only a matter of personal preference. People still play chess after thousands of years and nobody complains that the chessboard is obsolete, so there must be something about games that does not age with time and technological progress.
With modern video games there is a perceivable delay between when I press a button and when something happens. That is called "latency", and for many reasons it is one thing that has become worse and worse with advancements in technology. It appears to me that most people are used to having high latency in games and they do not bother too much. To me it breaks the immersion. Again, purely personal preference. One strategy to reduce latency is to remove software layers between the game code and the hardware.
2) isn't the pi hardware already fairly well documented?
Yes and no. Yes if you want to play with electronics via GPIO. No if you want to make old school games or if you want to write your own toy but fully functional operating system.
My 1) is a reply to why I did it. I took it as a literal question and I gave a genuine answer.
EDIT: Ok, I think I see what you mean now. I believe your question is about what is the appeal in doing this stuff. It's pretty much the same reason why someone would build a chair or a table from scratch versus buying one at IKEA and building it. The former gets the enjoyment from all of the journey from a piece of wood to the finished chair and from building exactly the chair that they want and the latter is probably more focused on the chair itself. END_OF_EDIT
As for the rest, I believe that some answers are already in the post and in the comments that I and other people made.
I may have misunderstood what you meant and if that is the case let's restart from scratch:
Do you want to program a raspberry pi at the hardware register level, without any APIs ?
15 comments
[ 2.8 ms ] story [ 39.9 ms ] threadParticularly, I have audio over HDMI and hardware sprites.
"Hardware sprites" means you can tell the graphics hardware to draw the sprite itself, as opposed to the programmer having to redraw the background and then copy the sprite's pixel data on top of it for every frame.
https://en.wikipedia.org/wiki/Sprite_(computer_graphics)
Perhaps you posted the wrong link??
For fun probably!
> Isn't it fairly well documented? In terms of installing linux to a sdCard, basic IO manipulation, serial interfaces like i2C SPI, sure. The GPU, no. It has actually always been famously a closed-source/closed-hardware black box.
This is fine for an intro to embedded systems and kids, but when you really want to take your hardware/low-level-software knowledge to the next level it can be frustrating.
1) why?
I always loved low level programming. I started as a kid on a c64 and then on an Amiga and really loved tinkering with those. Then when I got old enough to get a job in the computer industry there were layers of software everywhere and no more tinkering. I felt cheated.
I love old school games more than modern ones. This is only a matter of personal preference. People still play chess after thousands of years and nobody complains that the chessboard is obsolete, so there must be something about games that does not age with time and technological progress.
With modern video games there is a perceivable delay between when I press a button and when something happens. That is called "latency", and for many reasons it is one thing that has become worse and worse with advancements in technology. It appears to me that most people are used to having high latency in games and they do not bother too much. To me it breaks the immersion. Again, purely personal preference. One strategy to reduce latency is to remove software layers between the game code and the hardware.
2) isn't the pi hardware already fairly well documented?
Yes and no. Yes if you want to play with electronics via GPIO. No if you want to make old school games or if you want to write your own toy but fully functional operating system.
What EXACTLY needs to be reverse engineered to "make old school games" or "fully functional operating system"?
It's an ARM and the GPU has some API.
EDIT: Ok, I think I see what you mean now. I believe your question is about what is the appeal in doing this stuff. It's pretty much the same reason why someone would build a chair or a table from scratch versus buying one at IKEA and building it. The former gets the enjoyment from all of the journey from a piece of wood to the finished chair and from building exactly the chair that they want and the latter is probably more focused on the chair itself. END_OF_EDIT
As for the rest, I believe that some answers are already in the post and in the comments that I and other people made.
I may have misunderstood what you meant and if that is the case let's restart from scratch:
Do you want to program a raspberry pi at the hardware register level, without any APIs ?