How it works? -- The interplay of programming & electronics

[Dan]

Here are some questions of mine where I couldn't find an answer on the Internet. The questions are mainly 'how it actually works' questions correlated to the interplay of electronics and programming.
I hope it will be a reasonable topic for people who seek some enlightenment regarding the interplay of electronics (physics) and programming.
I also hope it suits this forum, otherwise I sincerely apologize for posting a needles and/or an unreasonable topic.
As time passes, I am intending to post more 'how it works' questions in here, if everything is fine w/ that. I hope there are also some curious folks out there whose intentions are overlapping with mine.

1) _Bare-metal DC GPU programming_
How to program a Dreamcast's GPU w/o any libraries, only w/ a DC BBA and a computer hooked up to it? Is it possible to create 3D games with this method? I know, it is said that you shouldn't reinvent the wheel, but this measurement is intended for educational purposes…

2) _BBA hooked up to PC/notebook_
How is the DC BBA actually 'communicating' when hooked up to a PC/notebook? How does the BBA and the PC/notebook 'know' when to send or receive data, or even 'know' that there's a connection? Is there some 'coordination' going on? Which electrical component, which software does that? How do you actually get access to the DC's GPU/CPU via a DC BBA?
PS: Is a DC BBA platform independent? Can you use it w/ any machine?

3) _No public GPU documentation in general_
Why there are usually no public GPU documentations available, but public CPU documentations instead? Is there no need for it because of a CPU bottleneck (the CPU sending the instructions to the GPU, while in most consoles the instructions are fetched independently from the CPU and the GPU)? Why the manufacturers want us to program the GPU only via an API such as OpenGL & DirectX? Why they're still insisting us to use APIs in the future such as Mantle (a no CPU overhead GPU API), instead of giving us 'bare-metal' access to the hardware like in consoles?
Furthermore, let's say I would have a GPU documentation/programming model of a graphics card, would I be able to 'communicate' directly with a graphics card then? So, can I bypass the CPU bottleneck when I have a documentation?
PS: Are there any other GPUs which can be directly accessed except video game console GPUs?


4) _Programming 3D homebrew games for DC_
According to this site: http://www.boob.co.uk/tutorials/guide.html KOS is not suitable for 3D programming. So how can I program
a 3D game for DC? Revolver (a homebrew 3D game for DC): https://www.youtube.com/watch?v=YXGUIGd ... freload=10

Best,
Dan

EDIT: Question 4 is needles I guess. Blacked it out.

[AaronGlazer]

Well, to answer #2, the DC BBA is not used for programming, it's just used as a means of uploading ELF/BIN executables to your Dreamcast. You don't plug it into your machine, you plug it into your router and assign it a local IP pointing to its MAC address. Then, dctool-ip (software on your computer) uploads the executable file to the Dreamcast which would be running dcload-ip (burned onto a CD-R).

[Dan]

@AaronGlazer: Thanks for your answer!

So, a BBA is used to upload ELF/BIN executables to your Dreamcast. Why can't you 'access' the DC hardware w/o any tools, only w/ the BBA, then? I mean you could write some executable which will command the DC GPU/CPU.
PS: What about the 'Coders Cable'?

There must be some way to access the DC hardware w/o any second-party/third-party tools, otherwise I think that there would be no tools such as dctool-ip.

My intention is to program a DC w/o any library, tools and such out of curiosity. If tools like dctool-ip exists, then I assume that there must be a way to make your own tools and libraries w/o any additional 'help', by only using 'standard' software such as GCC.

That's why I wanted to know how the BBA exactly works when hooked up to a computer or laptop.

EDIT: Oh, and does it matter which router someone uses w/ the BBA? Is it still platform independent? Can you access it from any machine?

[AaronGlazer]

Again, the Broadband Adapter does not "access the hardware" or anything like that. All the BBA does is allow you to connect your DC to a router for uploading executable files. The only other ways to get your program to run on a Dreamcast are to either use a coder's cable. or to burn a CD-R every time you wanted to test something which is obviously neither feasible nor desirable.

If you wanted to write a Dreamcast program without using KOS or any of the like, you sure as hell could but it probably wouldn't be very practical. KOS is well over a decade old at this point.

With the coder's cable, it's the same situation, except you plug the cable into your PC and use dctool-serial and dcload-serial instead of -ip.

[Light-Dark]

If you want to write your own PVR driver you're going to have to become intimately familiar with SH4 assembly and the hardware's memory system in general. I would advise you just use KOS and it's libraries as it is pretty dang good. It's PVR related functions are pretty easy to pick up and understand. The only hard part about making a 3D engine using this route is getting used to using the Dreamcast's special vector/matrix math instructions on the CPU because the PowerVR is fixed function which means there are no shaders; the PVR is not programmable in the modern graphics card sense. If you are looking for a great implementation of "old-school" (no shaders) OpenGL on the Dreamcast for KOS check out the library by a user on dcemulation known as "PH3NOM". His OpenGL library is pretty amazing.

[YourNerdyJoe]

I agree with Light-Dark but if you want to do it yourself then reading through the KOS source and finding any information about the hardware you can will help.
Found this http://mc.pp.se/dc/. Seems to have some useful info on the GPU as well as other things but I'm not a Dreamcast guy so what do I know

[Falco Girgis]

3) _No public GPU documentation in general_
Why there are usually no public GPU documentations available, but public CPU documentations instead? Is there no need for it because of a CPU bottleneck (the CPU sending the instructions to the GPU, while in most consoles the instructions are fetched independently from the CPU and the GPU)? Why the manufacturers want us to program the GPU only via an API such as OpenGL & DirectX? Why they're still insisting us to use APIs in the future such as Mantle (a no CPU overhead GPU API), instead of giving us 'bare-metal' access to the hardware like in consoles?
Furthermore, let's say I would have a GPU documentation/programming model of a graphics card, would I be able to 'communicate' directly with a graphics card then? So, can I bypass the CPU bottleneck when I have a documentation?
PS: Are there any other GPUs which can be directly accessed except video game console GPUs?.

That's because the SH4 processor is a very commonly used microprocessor in a wide array of embedded devices, outside of the Dreamcast; the PowerVR2DC was a specialized GPU designed specifically for the Dreamcast.

Trust me, you have more bare-metal access than even Mantle could offer on the Dreamcast... If you really want to, yeah, you have to manually encode and submit instructions and primitives to be processed by the GPU. As has previously been mentioned, the PVR has a fixed-function pipeline, meaning you do not write code to be run on the GPU itself. Instead you send simple commands and primitives to it from the CPU to tell it what you want to do.