4kb Rotating Cube Demo

[dreso741]

Hello all. I don't know much about programming but, I made this little demo. I haven't tried it on a emulator but it works fine on real hardware.

I'd like to make a new library to access the hardware without KOS. I've only looked over the graphics section of KOS and, it seems way underdeveloped. Especially considering we now have the system architecture documentation.

[BlueCrab]

I'm not entirely sure what you mean by underdeveloped? Care to elaborate on that? If you're referring to the base library's lack of 3D support, that's because it is largely offloaded into an libraries such as libgl in the kos-ports tree. That way, we don't pollute the main so much with pieces that aren't core to the kernel.

Also, I have a feeling that by the "architecture documentation", you're referring to that rather large piece (400 or so pages, IIRC) of confidential Sega documentation on the console that has been floating around for years? We've always tried to stay away from documents that we shouldn't legally have in order to ensure that there's no cloud of doubt at the legality of KOS.

[dreso741]

I'm not entirely sure what you mean by underdeveloped? Care to elaborate on that? If you're referring to the base library's lack of 3D support, that's because it is largely offloaded into an libraries such as libgl in the kos-ports tree. That way, we don't pollute the main so much with pieces that aren't core to the kernel.

I've looked at libgl and, it looks like a wrapper for the pvr library. IDK how to explain this shit. The code is littered with wrongness.

Code: Select all

    /* 3d-specific parameters; these are all about rendering and
       nothing to do with setting up the video; some stuff in here
       is still unknown. */
    PVR_SET(PVR_UNK_00A8, 0x15d1c951);      /* M (Unknown magic value) */
    PVR_SET(PVR_UNK_00A0, 0x00000020);      /* M */
    PVR_SET(PVR_FB_CFG_2, 0x00000009);      /* alpha config */
    PVR_SET(PVR_UNK_0110, 0x00093f39);      /* M */
    PVR_SET(PVR_UNK_0098, 0x00800408);      /* M */
    PVR_SET(PVR_TEXTURE_CLIP, 0x00000000);      /* texture clip distance */
    PVR_SET(PVR_SPANSORT_CFG, 0x00000101);      /* M */
    PVR_SET(PVR_FOG_TABLE_COLOR, 0x007f7f7f);   /* Fog table color */
    PVR_SET(PVR_FOG_VERTEX_COLOR, 0x007f7f7f);  /* Fog vertex color */
    PVR_SET(PVR_COLOR_CLAMP_MIN, 0x00000000);   /* color clamp min */
    PVR_SET(PVR_COLOR_CLAMP_MAX, 0xffffffff);   /* color clamp max */
    PVR_SET(PVR_UNK_0080, 0x00000007);      /* M */
    PVR_SET(PVR_CHEAP_SHADOW, 0x00000001);      /* cheap shadow */
    PVR_SET(PVR_UNK_007C, 0x0027df77);      /* M */
    PVR_SET(PVR_TEXTURE_MODULO, 0x00000000);    /* stride width */
    PVR_SET(PVR_FOG_DENSITY, 0x0000ff07);       /* fog density */
    PVR_SET(PVR_UNK_00C8, PVR_GET(0x00d4) << 16);   /* M */
    PVR_SET(PVR_UNK_0118, 0x00008040);      /* M */

pvr_init_shutdown.c
There shouldn't be this many magic numbers in a 2.0 release. On the real.

Code: Select all

        /* Object Pointer Buffers */
        /* XXX What the heck is this 0x50580 magic value?? All I
           remember about it is that removing it makes it fail. */
        buf->opb_size = 0x50580 + polybuf;
        outaddr += buf->opb_size;
        // buf->poly_buf_size = (outaddr - polybuf) - buf->vertex;
        polybuf_alloc = buf->opb = outaddr - polybuf;

        for(j = 0; j < PVR_OPB_COUNT; j++) {
            if(pvr_state.opb_size[j] > 0) {
                buf->opb_type[j] = polybuf_alloc;
                polybuf_alloc += pvr_state.opb_ind[j];
            }
            else {
                buf->opb_type[j] = 0x80000000;
            }
        }

        outaddr += buf->opb_size;   /* Do we _really_ need this twice? */

pvr_buffers.c
Again, not suitable for a 2.0 release. We know how to calculate the buffer sizes at this point. SMH


There are tons of bug causing code in here. It's no wonder why so many people experience bugs when running their shit on real HW. This is barely alpha. I'm just keeping it real.

I respect KOS for what it is but, this is not what the dreamcast community needs. Correct me if I'm wrong but KOS was created as a portable OS. As far as it's OS features (memory, threads, etc.) go I fuks with it. But I think we need something more suited to embedded development.

Also, I have a feeling that by the "architecture documentation", you're referring to that rather large piece (400 or so pages, IIRC) of confidential Sega documentation on the console that has been floating around for years? We've always tried to stay away from documents that we shouldn't legally have in order to ensure that there's no cloud of doubt at the legality of KOS.

IDK where you live mane but, in the US a design patent only lasts 14 years. I live 30 minutes from Sega USA Headquarters. I fiend to go down there and, ask them if it's ok to use it. They might go for it. The bay is crazy like that.

[bogglez]

The pvr API is lower level than the GL library and exposes the GPU capabilities directly, so it makes sense to use it. Still, I wouldn't call the GL library a wrapper, it does a lot of extra things for you, clipping and multi-texturing for example.
If it doesn't suit your needs yet you should try to improve it or create an alternative, instead of just telling people "what the community needs" and how everything is "shit". Provide patches and people will listen to you.
libgl is in active development right now and feedback is strongly encouraged. You will find a feedback thread specifically for it and lots of threads about experiments to make it better.

Most of these "magic numbers" you referred to in your code are something called colors, the others are documented with comments. What would you improve here?
Do you seriously suggest this?

Code: Select all

unsigned someBlue = 0x007f7f7f; PVR_SET(PVR_FOG_TABLE_COLOR, someBlue);   /* Fog table color */

There are tons of bug causing code in here. It's no wonder why so many people experience bugs when running their shit on real HW. This is barely alpha. I'm just keeping it real.

This is a quite large code base handed down from maintainer to maintainer. Of course you can point out some bad code here and there randomly, I think that's to be expected.
Point out the concrete bugs you found and patch them if you can, at least try to describe the issue. As it is, this is not constructive criticism.
So everything is shit, it's not what the community needs yada yada. Ok, I want to fix it. But what do you want me to do? And why do you have this expectation that the devs have some obligation to the community? This is a hobby project, you're not a paying customer. You should be thankful you don't need to program this stuff from scratch yourself.
And I don't know about you, but I'd never put shit in my Dreamcast. For realz.

IDK where you live mane but, in the US a design patent only lasts 14 years. I live 30 minutes from Sega USA Headquarters. I fiend to go down there and, ask them if it's ok to use it. They might go for it. The bay is crazy like that.

Would be great if you tried, but the chances are sadly slim. They would need you to talk to their lawyer, but why would they do that? Law is a minefield. There's no gain in that for them, only potential problems.
If you want to hire a lawyer to check whether we can use the document, go ahead.
As it is, I think everyone is happy enough that Sega doesn't constantly pester the project with lawyers.

[dreso741]

The pvr API is lower level than the GL library and exposes the GPU capabilities directly, so it makes sense to use it. Still, I wouldn't call the GL library a wrapper, it does a lot of extra things for you, clipping and multi-texturing for example.

I was referring to the libgl in kos-ports. Not the one released by PH3NOM. That port is is very good. But still suffers from bugs in the underlying KOS kernel.

If it doesn't suit your needs yet you should try to improve it or create an alternative, instead of just telling people "what the community needs" and how everything is "shit". Provide patches and people will listen to you.
libgl is in active development right now and feedback is strongly encouraged. You will find a feedback thread specifically for it and lots of threads about experiments to make it better.

...

This is a quite large code base handed down from maintainer to maintainer. Of course you can point out some bad code here and there randomly, I think that's to be expected.
Point out the concrete bugs you found and patch them if you can, at least try to describe the issue. As it is, this is not constructive criticism.
So everything is shit, it's not what the community needs yada yada. Ok, I want to fix it. But what do you want me to do? And why do you have this expectation that the devs have some obligation to the community? This is a hobby project, you're not a paying customer. You should be thankful you don't need to program this stuff from scratch yourself.
And I don't know about you, but I'd never put shit in my Dreamcast. For realz.

It looks like you're offended. I think there has been a miscommunication. This is my fault. The internet is a global platform and, I am used to using a regional slang. I think I should explain myself more clearly. I don't mean everything is shit. If this is what you truly inferred I apologize. Shit is a vulgar word in english but, is also used to mean "a thing" with no negative connotation whatsoever. Real and being real is cultural thing. Many people are fake so, being real or truthful is respected.

I don't think anyone has any obligation to contribute to anything. This is what the dreamcast needs as I see it. It's just my opinion. I am entitled to an opinion. If we don't share that sentiment I can learn to respect that.

I should have made this more clear but, I'm working on translating the dreamcast system architecture documentation to a small library with extensive documentation and examples. The 5kb demo is the result of the translation so far.

Most of these "magic numbers" you referred to in your code are something called colors, the others are documented with comments. What would you improve here?
Do you seriously suggest this?

Code: Select all

unsigned someBlue = 0x007f7f7f; PVR_SET(PVR_FOG_TABLE_COLOR, someBlue);   /* Fog table color */

Those are just some things that caught my eye on first glance. There are more fundamental errors in the code. The PVR is capable of several functions that are not usable with KOS. In fact many hardware functions are not usable with KOS and, several design choices of KOS don't coincide with the system design.

[BlueCrab]

I'm going to end up regretting saying anything now (since there's no way I'm going to make a full, coherent post at this hour of the night with the kind of day I've had), but I somewhat feel the need to say a few things now.

First, I reiterate my point that the document you're referring to is a confidential piece of Sega documentation that was never meant to be released to the public. I know of its existence, obviously, along with various other pieces of documentation that I've happened across on the Internet. That said, anything produced with that documentation will have a legal cloud of doubt over it. If you'd like to take that and make it into a library for the system, have at it. I won't touch it myself, and I have a feeling that I'm not the only one. It has nothing to do with patents (and I don't even know why you brought them into the discussion to start with) -- it has a lot more to do with respect. Respect for the company that put out the console, as well as respect for those who reverse-engineered it the right way. Perhaps I am the only person who cares about such things these days, and perhaps I'm biased as the one that maintains KOS. I'm set in my ways and I'll stay that way for a long time if I have my way.

Second, I can see exactly why bogglez finds the way you've phrased your posts to be on the insulting side. I do too, to tell the truth. Your use of "shit" is one thing. Saying that "[t]he code is littered with wrongness" and saying it is "barely alpha" in quality is another. That, to me, is quite insulting. I don't see any way to take that as anything but insulting. There's nothing "constructive" about that criticism at all.

If you want to report bugs, please do. I'll be happy to look into them as I get the time to do so. Just do so in a constructive fashion.

True, KOS doesn't expose everything that the PVR can do -- it exposes a common-use subset and gives you many of the building blocks to go from there. Sure, there are pieces of legal documentation of more of the primitive types that the PVR supports, and sure I could add them to KOS if I so desired. There's a reason I haven't though -- many are just needless confusion.

Also, on the point of what KOS is. No, the KOS that exists today was never meant as a "standard OS". That may have been a goal long ago, but that was just that -- long ago. Perhaps for some things threads and POSIX-like I/O and such are overkill, but they make for a much simpler development experience, and one that is much closer to what one would expect on a standard OS. Yes, those parts of KOS were designed to be portable, but they still are fairly tightly coupled to what the Dreamcast does. That's why the "ports" of KOS to other platforms all died out. The whole thing was tied way more to the Dreamcast than any "portable" OS has any business being. KOS was designed to be developer-friendly, while still giving you a lot of power if you choose to use it.

I will say one thing though. I do agree that a smaller library without much of the heavier parts of KOS is a very useful thing. It is something I've had planned out on paper for a long time, but have never had the time and/or drive to make a decent stab at it. Unfortunately, I'm pretty much the only person working on KOS itself these days and I've got almost no time to work on it. Between my research for work and my studies in my PhD program, I'm stretched thin enough as it is. Add to that the several other open-source projects I'm a part of, and it means I almost never have a chance to do anything big in any of them.

One final thing to keep in mind, with regard to libgl, if you're looking at the version from 2.0.0, you're looking at something that has been not included in the kos-ports tree for months now. PH3NOM's libgl is the libgl that's a part of KOS going forward.

[dreso741]

First, I reiterate my point that the document you're referring to is a confidential piece of Sega documentation that was never meant to be released to the public. I know of its existence, obviously, along with various other pieces of documentation that I've happened across on the Internet. That said, anything produced with that documentation will have a legal cloud of doubt over it. If you'd like to take that and make it into a library for the system, have at it. I won't touch it myself, and I have a feeling that I'm not the only one. It has nothing to do with patents (and I don't even know why you brought them into the discussion to start with) -- it has a lot more to do with respect. Respect for the company that put out the console, as well as respect for those who reverse-engineered it the right way. Perhaps I am the only person who cares about such things these days, and perhaps I'm biased as the one that maintains KOS. I'm set in my ways and I'll stay that way for a long time if I have my way.

I find this an interesting point of discussion and, would like if you could expand on those ideas. Especially because it does seem to be a shared sentiment among the community.

What does it mean to reverse-engineer something the right way? Does it mean hooking up the dreamcast to a logic analyzer and dissembling ripped games? How is that any better then figuring out the architecture documentation? And for that matter how does doing so show disrespect to the company that designed and implemented it? I'm genuinely curious.

Second, I can see exactly why bogglez finds the way you've phrased your posts to be on the insulting side. I do too, to tell the truth. Your use of "shit" is one thing. Saying that "[t]he code is littered with wrongness" and saying it is "barely alpha" in quality is another. That, to me, is quite insulting. I don't see any way to take that as anything but insulting. There's nothing "constructive" about that criticism at all.

If you want to report bugs, please do. I'll be happy to look into them as I get the time to do so. Just do so in a constructive fashion.

I wasn't commenting on the whole of KOS. I was only commenting on the snippets. I just want to make that clear. If you're terribly offended please don't be.

That being said. As I see it this isn't an opinion and, therefore is not a criticism. Take an honest look at the code written there. Do you disagree? I was just being brutally honest. I actually said I respected KOS for what it is.

True, KOS doesn't expose everything that the PVR can do -- it exposes a common-use subset and gives you many of the building blocks to go from there. Sure, there are pieces of legal documentation of more of the primitive types that the PVR supports, and sure I could add them to KOS if I so desired. There's a reason I haven't though -- many are just needless confusion.

Also, on the point of what KOS is. No, the KOS that exists today was never meant as a "standard OS". That may have been a goal long ago, but that was just that -- long ago. Perhaps for some things threads and POSIX-like I/O and such are overkill, but they make for a much simpler development experience, and one that is much closer to what one would expect on a standard OS. Yes, those parts of KOS were designed to be portable, but they still are fairly tightly coupled to what the Dreamcast does. That's why the "ports" of KOS to other platforms all died out. The whole thing was tied way more to the Dreamcast than any "portable" OS has any business being. KOS was designed to be developer-friendly, while still giving you a lot of power if you choose to use it.

I will say one thing though. I do agree that a smaller library without much of the heavier parts of KOS is a very useful thing. It is something I've had planned out on paper for a long time, but have never had the time and/or drive to make a decent stab at it. Unfortunately, I'm pretty much the only person working on KOS itself these days and I've got almost no time to work on it. Between my research for work and my studies in my PhD program, I'm stretched thin enough as it is. Add to that the several other open-source projects I'm a part of, and it means I almost never have a chance to do anything big in any of them.

One final thing to keep in mind, with regard to libgl, if you're looking at the version from 2.0.0, you're looking at something that has been not included in the kos-ports tree for months now. PH3NOM's libgl is the libgl that's a part of KOS going forward.

Personally I have no interest in KOS. That's why I wouldn't contribute to it or report bugs. In my opinion it's poorly documented, buggy, and fundamentally not suited for game development. I know you contribute to the source so please don't take it personally. I like KOS but wouldn't use it seriously.

[BlueCrab]

I find this an interesting point of discussion and, would like if you could expand on those ideas. Especially because it does seem to be a shared sentiment among the community.

What does it mean to reverse-engineer something the right way? Does it mean hooking up the dreamcast to a logic analyzer and dissembling ripped games? How is that any better then figuring out the architecture documentation? And for that matter how does doing so show disrespect to the company that designed and implemented it? I'm genuinely curious.

Hooking the system up to a logic analyzer is certainly one way of reverse engineering it the right way. Watching what games do through other means, such as the old DreamFreeze program that Dan Potter wrote back in the day to analyze running code on the system is another (and that's how a lot of the hardware was reverse engineered). Back in the day, there were actually people at Sega who would follow the progress of those reversing all the hardware and who would somewhat cheer the homebrew community along (and occasionally prod them in the correct direction). Sega actually looked on at what the homebrew developers were doing and didn't view them with contempt (compare that to Nintendo and Sony's view on homebrew code running on their consoles).

Do you think Sega would have looked at what they were doing with such a good attitude if we were using stolen documentation to write the code? Do you think that Sega would have respected us for that? I certainly don't. The way they would've seen us would have probably been no different than how they saw the active pirate groups if we were using stolen documentation.

Now, maybe you're thinking (like many people do think these days) that why should we care? Sega's not going to sue or anything for using said stolen documentation, just like they aren't going to sue people for pirating Dreamcast games. Why should that matter though? How does it change the fact that there'd be a legal cloud of doubt over the software? Just because you're sure that Sega wouldn't care right now doesn't mean they might not in the future or if you were to ever make any money off of it.

Another way to look at it is this: what is more satisfying -- beating a really hard video game with a player's guide that tells you exactly what to do and how to go about it, or beating it on your own? Would you expect respect from your peers if you used a guide to get through a game? The system architecture document is pretty much like a really detailed player's guide (to my understanding). There's no inherent joy in getting something to work based on it -- it pretty much gives you the answers.

I wasn't commenting on the whole of KOS. I was only commenting on the snippets. I just want to make that clear. If you're terribly offended please don't be.

That being said. As I see it this isn't an opinion and, therefore is not a criticism. Take an honest look at the code written there. Do you disagree? I was just being brutally honest. I actually said I respected KOS for what it is.

Knowing the history of how that code was developed, no I don't agree with your point. I know how those "magic" numbers were found, and they truly were/are magic in that regard. I'm also not the kind of person that feels the need to give every single number in a piece of code a name. I tend to have random constants strewn throughout code I wrote because I don't waste my time coming up with pointless names for them (if part of the complaint is directed at things like the register sets that are not commented just as /* M */ and such).

I fail to see how this piece of software (that has been used in several commercially released games, mind you) can be considered to be "barely alpha" quality because of magic numbers. Quite obviously, the code works for what people have used it to do.

[dreso741]

If you reverse-engineer that way aren't you just side stepping the issue. In reality you're just trying to decompile and map out binary that belongs to Sega and whatever company wrote the game. It seems to me that your saying "well it's hard and sega cheered us on so that makes it ok."

[bogglez]

http://en.wikipedia.org/wiki/Clean_room_design

[nymus]

I just felt the urge to chime in on the whole reverse engineering concept. Personally, I think the act itself generally goes against the wishes of a developer/manufacturer who did not publicly describe or document their product and is therefore wrong regardless of how one goes about it. The only valid justification would be if the product of reverse engineering does not offend the intent that the originator had for obfuscating their product in the first place.

In the case of most hardware and software, people reverse engineer it so that they can learn from it (good), use it(good if you paid) or make(okay-ish) and sell a copy(bad-ish). This would obviously steal sales from the originator. In the case of a library such as KOS, it would have dishonoured SEGA's intent for secrecy if developers had used it instead of SEGA's licensed libary to create commercial content. It wouldn't have mattered if the KOS creators had received a magical vision that granted them all knowledge of Dreamcast hardware.

e.g. Treamcast creators had a right to acquire/use Dreamcast knowledge but it was wrong of them to try and sell it. Bleemcast had a right to acquire/use Playstation knowledge but it offended Sony's intentions to sell more Playstation hardware. In Bleemcast's case, it was "legally" right because they did indeed use "Clean Room Design" but our buying games is okay-ish only by justifying that Sony and the game developer get some return from an original disc. If this wasn't the case then it would be completely immoral regardless of the legal right.

Most software today carries license agreements that prohibit reverse engineering so the purity of KOS' foundation will never be perfect. What we have is (almost) pure intent. Regarding the stolen document, I can understand the reluctance but its use can also be rationalized because a lot of knowledge was acquired from official dev boxes that carry non-disclosure agreements and details about numerous functions. Knowing a magic value or the function of a hardware component for the purpose of fair use is okay, I believe. The fact that the creators/maintainers of KOS have seen and read the offending document certainly pollutes the "Clean Room" environment.

[Tangent]
If someone throws "Hacked/Stolen knowledge" in my face, I cannot unsee it. If it increases my interest, knowledge and use of the work of the originator, then I can argue that I have turned that "illicitly-acquired" knowledge towards good (for the originator). I can only hope that the thieves are dealt with for their crime and I honour the originator by not promoting the stolen property. It would be paradoxical to play dumb by refusing to use this knowledge if I needed it, especially if there was no conflict of interest with the originator. People create works so that they may be used. They hope that use of their work will be profitable to them and others (cyclically). The only reason people/entities hide their work is so that it won't be used without them, against them or for evil.
[/Tangent]

KOS' is not a copy. It is an original work so its own existence is arguably moral and legal. The more important dilemma is whether commercial products created using it have offended SEGA's commercial intentions for the Dreamcast.

[BlueCrab]

The binary that you have the right to use and the right to do just that to, as established by case law in the US (like Sega v. Accolade and Sony v. Connectix).

That said, that's not what DreamFreeze did. DreamFreeze was essentially an in-circuit emulator. It essentially emulated the Dreamcast on the Dreamcast. It allowed the early homebrewers to have a controlled environment to run code on while still allowing the hardware to do what it does when written to.

In the end, yes, you get register values that might be useful, but that doesn't just give you everything like that system architecture document does. You still have to play around with the hardware and see what happens. There's still a challenge to it.

[nymus]

Interesting topic. I have great respect for the pioneers of DC homebrew. KOS is certainly an amazing achievement and a credit to Dreamcast's legacy in spite of any rough edges it might possess. I certainly learned a lot from it and anyone who sees mistakes should take it as an opportunity to learn/practice better methods.

This discussion made me think of a hypothetical scenario where someone steals all Dreamcast documents from SEGA to create FreeLib, a better library than OfficialLib, intended only to help Dreamcast developers create games that are better than PS2/XBOX/GC. They inform SEGA of their goal to offer it to developers with the condition that games will contain markers indicating it was made using FreeLib and a EULA that requires them to pay SEGA's licensing and distribution fees for commercial games.

Developers agree to pay SEGA's fees but use FreeLib not OfficialLib to make excellent games. FreeLib creators have committed a crime, but Police will ask SEGA if they want to press charges... what happens next?

[BlueCrab]

By the way... In case it isn't obvious, my last post up there was not directed at either of the posts by bogglez or nymus. Not sure why it didn't tell me that people had posted in the meantime between when I started typing my reply and when I submitted it (which was about an hour, due to being distracted by many other things)...

[dreso741]

I think you are confused when it comes to the difficulty. Difficulty is subjective. However, if you can turn the doc spec into code you can also dissemble a binary and figure it out. They are very similar things and about the same in difficulty in my mind.

Can you comment on the use of non-public domain sources that have been used by the community?

For example you said you could add some features to KOS that have been documented by the community. I believe you are referring to ta-intro.txt and ta-reg.txt. These documents were written using documents from VideoLogic for another pvr chip which is not a PD document.

In fact you not only referenced but added as an attachment hitachi sh-4 documents in some other thread. Which are not in the PD.

[BlueCrab]

The Hitachi documents were and still are most certainly publicly available. They were all available on the Hitachi website back in the day, and newer versions are available on Renesas' site: http://am.renesas.com/products/mpumcu/s ... tation.jsp

In addition, I'm not sure what you mean by ta-intro.txt and ta-reg.txt containing non-public information. I've never heard of those two documents being based on anything that was non-public. Can you present evidence to support this assertion?

Even assuming it was based on anything non-public, this still doesn't change the fact that it would still be an example of clean-room design if someone were to use those two documents to write up their code for the system.

Also, I wasn't necessarily referring to those two documents (I had actually completely forgotten they exist, tbh ), but rather to source code of emulators like nulldc and reicast. Two more sources that could be used to derive code from in a clean-room design type fashion.

You also say I'm confused when it comes to difficulty. I'm not. It is not at all difficult to take a piece of documentation that exactly lists out every single register and to be able to fill in the register values correctly. It is a lot more difficulty to simply know ONE value to put in the register then to figure out how to modify that value with no guidance on what the various bits do. This is especially true when you're dealing with registers like those used for memory refresh and such things, where changing the value might well completely clobber RAM and such.

[dreso741]

Hitachi neither warrants nor grants licenses of any rights of Hitachi’s or any third party’s patent, copyright, trademark, or other intellectual property rights for information contained in this document...

...

No one is permitted to reproduce or duplicate, in any form, the whole or part of this document without written approval from Hitachi.

Just because it's on the internet does not make something PD.

Note: There are a few different incarnations of the PowerVR-chipset and they
are not completely compatible with each other. Unfortunately previous versions
of this document contained information only relevant to the older CLX1 chipset
whereas the Dreamcast uses a chipset similar to the newer CLX2. Information has
now been updated and where differences exist they are noted with the tags CLX1
and CLX2. [This note was mistakenly excluded from the previous version.]

Originally written using documentation for the CLX1 chipset.

Code: Select all

#define REGION_BASE_addr    0x0000002C  //  RW  Base address for Region Array  
#define SPAN_SORT_CFG_addr    0x00000030  //  RW  Span Sorter control  

#define VO_BORDER_COL_addr    0x00000040  //  RW  Border area color  
#define FB_R_CTRL_addr      0x00000044  //  RW  Frame buffer read control  
#define FB_W_CTRL_addr      0x00000048  //  RW  Frame buffer write control  
#define FB_W_LINESTRIDE_addr  0x0000004C  //  RW  Frame buffer line stride  
#define FB_R_SOF1_addr      0x00000050  //  RW  Read start address for field - 1/strip - 1  
#define FB_R_SOF2_addr      0x00000054  //  RW  Read start address for field - 2/strip - 2  

#define FB_R_SIZE_addr      0x0000005C  //  RW  Frame buffer XY size  
#define FB_W_SOF1_addr      0x00000060  //  RW  Write start address for field - 1/strip - 1  
#define FB_W_SOF2_addr      0x00000064  //  RW  Write start address for field - 2/strip - 2  
#define FB_X_CLIP_addr      0x00000068  //  RW  Pixel clip X coordinate  
#define FB_Y_CLIP_addr      0x0000006C  //  RW  Pixel clip Y coordinate  


#define FPU_SHAD_SCALE_addr    0x00000074  //  RW  Intensity Volume mode  
#define FPU_CULL_VAL_addr    0x00000078  //  RW  Comparison value for culling  
#define FPU_PARAM_CFG_addr    0x0000007C  //  RW  Parameter read control  
#define HALF_OFFSET_addr    0x00000080  //  RW  Pixel sampling control
#define FPU_PERP_VAL_addr    0x00000084  //  RW  Comparison value for perpendicular polygons  
#define ISP_BACKGND_D_addr    0x00000088  //  RW  Background surface depth  
#define ISP_BACKGND_T_addr    0x0000008C  //  RW  Background surface tag  

#define ISP_FEED_CFG_addr    0x00000098  //  RW  Translucent polygon sort mode  

#define SDRAM_REFRESH_addr    0x000000A0  //  RW  Texture memory refresh counter  
#define SDRAM_ARB_CFG_addr    0x000000A4  //  RW  Texture memory arbiter control  
#define SDRAM_CFG_addr      0x000000A8  //  RW  Texture memory control  

#define FOG_COL_RAM_addr    0x000000B0  //  RW  Color for Look Up table Fog  
#define FOG_COL_VERT_addr    0x000000B4  //  RW  Color for vertex Fog
#define FOG_DENSITY_addr    0x000000B8  //  RW  Fog scale value  
#define FOG_CLAMP_MAX_addr    0x000000BC  //  RW  Color clamping maximum value  
#define FOG_CLAMP_MIN_addr    0x000000C0  //  RW  Color clamping minimum value  
#define SPG_TRIGGER_POS_addr  0x000000C4  //  RW  External trigger signal HV counter value  
#define SPG_HBLANK_INT_addr    0x000000C8  //  RW  H-blank interrupt control  
#define SPG_VBLANK_INT_addr    0x000000CC  //  RW  V-blank interrupt control  
#define SPG_CONTROL_addr    0x000000D0  //  RW  Sync pulse generator control  
#define SPG_HBLANK_addr      0x000000D4  //  RW  H-blank control  
#define SPG_LOAD_addr      0x000000D8  //  RW  HV counter load value  
#define SPG_VBLANK_addr      0x000000DC  //  RW  V-blank control  
#define SPG_WIDTH_addr      0x000000E0  //  RW  Sync width control  
#define TEXT_CONTROL_addr    0x000000E4  //  RW  Texturing control  
#define VO_CONTROL_addr      0x000000E8  //  RW  Video output control  
#define VO_STARTX_addr      0x000000Ec  //  RW  Video output start X position  
#define VO_STARTY_addr      0x000000F0  //  RW  Video output start Y position  
#define SCALER_CTL_addr      0x000000F4  //  RW  X & Y scaler control  
#define PAL_RAM_CTRL_addr    0x00000108  //  RW  Palette RAM control  
#define SPG_STATUS_addr      0x0000010C  //  R  Sync pulse generator status  
#define FB_BURSTCTRL_addr    0x00000110  //  RW  Frame buffer burst control  
#define FB_C_SOF_addr      0x00000114  //  R  Current frame buffer start address  
#define Y_COEFF_addr      0x00000118  //  RW  Y scaling coefficient  

If you actually look at the nulldc code you can see the PVR part is based off the manual. All these names come from the architecture documentation just with "_addr" at the end.


Again in regards to difficulty I think this is subjective but I still disagree with you. If you dissemble the binary you can step through it slowly. Just because you know what all the registers do doesn't make programming the machine easy. There are many ways to do things right and wrong that work. Just look at the way KOS allocates it's buffers for the TA. I know why it just barely works but, the PVR should reject it. There are also some errors in the documentation and, instead of worrying about a few commands at a time you must considered the whole of the system, interrelated.

[bogglez]

I still don't know what you actually want. You said you have no interest in KOS so you don't want to point out concrete issues or provide patches. Yet you constantly make very vague statements (e.g. "there are some errors in the documentation").
You tell everybody to just use the official documents and basically rewrite most of KOS or even make a new, smaller library that is based on those documents.
So I don't want to be too provocative, but all I hear is "KOS sucks, why don't you guys scrap everything?". You don't seem to be interested in improving KOS at all.

[dreso741]

I still don't know what you actually want. You said you have no interest in KOS so you don't want to point out concrete issues or provide patches. Yet you constantly make very vague statements (e.g. "there are some errors in the documentation").
You tell everybody to just use the official documents and basically rewrite most of KOS or even make a new, smaller library that is based on those documents.
So I don't want to be too provocative, but all I hear is "KOS sucks, why don't you guys scrap everything?". You don't seem to be interested in improving KOS at all.

Right now I'm conversating with BlueCrab about the concepts of legality and reverse engineering to get a better idea of the dreamcast community. I explicitly state my goals in the first post. The rest of the answers are in the other posts. I don't blame you for not reading them this thread has quickly become a wall of text between my new school mentality vs his old school mentality. I find it very interesting and, I'm curious what people did back then.

[BlueCrab]

Just because it's on the internet does not make something PD.

Did I assert that the documentation is in the public domain? No. Does that mean we can't use it? No.

If you want me to kill the links here, I'll do it and just link to the new documentation on their website. Will that make you happy?

Note: There are a few different incarnations of the PowerVR-chipset and they
are not completely compatible with each other. Unfortunately previous versions
of this document contained information only relevant to the older CLX1 chipset
whereas the Dreamcast uses a chipset similar to the newer CLX2. Information has
now been updated and where differences exist they are noted with the tags CLX1
and CLX2. [This note was mistakenly excluded from the previous version.]

Originally written using documentation for the CLX1 chipset.

Clearly? How so? Couldn't it be just as well written based on reverse engineering of the CLX1? After all, with all the unknowns and question marks all over that document, I find that to be much more likely.

Hypothetically speaking, how do you know that if it was written based off of documentation that said documentation is not legal for one to have? Just because documentation on the CLX1/CLX2 is rather difficult to find, but that doesn't mean it was always that way.

Still, based on the contents of the document itself, it seems a lot more likely that it was based on reverse engineering than on any sort of documentation. Nowhere in that document does it say it was written based on documentation and the sheer amount of unknowns and question marks throughout make it seem a lot more like it was reverse engineered to me.

If you actually look at the nulldc code you can see the PVR part is based off the manual. All these names come from the architecture documentation just with "_addr" at the end.

Once again, clean-room design. One person has access to privileged information and writes documentation of some sort based on it. Another person, with no access to the privileged documentation, implements something based on the first person's documentation.

I'm only saying that we could do something like that if we really wanted to. I'm not suggesting that I'm planning on doing something like that.

Again in regards to difficulty I think this is subjective but I still disagree with you. If you dissemble the binary you can step through it slowly. Just because you know what all the registers do doesn't make programming the machine easy. There are many ways to do things right and wrong that work. Just look at the way KOS allocates it's buffers for the TA. I know why it just barely works but, the PVR should reject it. There are also some errors in the documentation and, instead of worrying about a few commands at a time you must considered the whole of the system, interrelated.

I still don't see how knowing exactly how the system works makes it difficult to implement something for it. I could probably whip up a whole new PVR system in a week tops based on my understanding of what is in that system architecture document. The reverse engineered stuff in KOS has been developed over many years to get to the point where it is now. Which of those seems more difficult?

Once again, what is more difficult -- completing a video game on your own or with a player's guide? Sure, the guide doesn't play the game for you, but it tells you everything about how to do it. Just as how the system architecture document doesn't write the code for you -- it tells you pretty much exactly how to do it though.

I still don't know what you actually want. You said you have no interest in KOS so you don't want to point out concrete issues or provide patches. Yet you constantly make very vague statements (e.g. "there are some errors in the documentation").
You tell everybody to just use the official documents and basically rewrite most of KOS or even make a new, smaller library that is based on those documents.
So I don't want to be too provocative, but all I hear is "KOS sucks, why don't you guys scrap everything?". You don't seem to be interested in improving KOS at all.

He's not interested in improving KOS at all. He's interested in writing his own library that he perceives to be a better fit for the system than KOS. I heartily disagree with both his methods and his assertion that it'll provide a better programming environment for people looking to make games. It'll most likely provide something much smaller, as can be seen by the size of his demo, but with that smallness comes a massive hit in the ability to easily port code from other places that assumes a full-fledged standard-compliant libc, for instance. For some things, that won't be as much of a problem as for other things.