The PS2 validates the inserted disc in hardware before software gets ahold of it. If a disc is inserted that isn't a valid PS1 or PS2 disc, the CDVD drive will simply spindown the disc and return errors on any disc access.
There was a method discovered some time ago that allows you to swap the current (valid) disc with an invalid one and boot it all the same. This requires a PS2 boot disc that was designed to facilitate this and was mostly fixed in later PS2 revisions.
So a pure software loader would be unable to access an invalid disc unless it were swapped, but there are so many obstacles there that it isn't practical to attempt that (if it would even work) with this exploit - I am not naive enough to say it isn't possible - it just isn't practical to implement or use.
I have no idea if I would get burned (as in Sony would have a valid case) legally if this were to happen with the exploit, since the flaw that enables swapping has existed since the PS2 was launched. I guess what I'm trying to say is that the exploit doesn't enable any piracy features not already present in the PS2.
The first site we always recommend is ps2dev.org. You can also find us on IRC in #ps2dev on EFNet, where we can help you get setup (if ps2dev.org or it's links aren't enough).
I don't typically read or post on/. these days, but since you folks were so kind as to saturate my cable connection:P, I read through the comments and wanted to clarify a few things:
The hack does not enable or facilitate mass, rampant, or Carribean piracy of PS2 or PS1 software. The design of the PS2 thwarts software from patching the system so that the hardware copy/region protection fails.
I am aware that Sony will be furious over this release. I myself know that legally, I have not broken the law. I used clean room reversing techniques to find the exploit, and Open Source software to develop it. Also, the exploit does not circumvent any security measures in the PS2, this should be obvious since you need a legal PS1 disc to perform the hack in the first place.
Yeah, I interviewed for Sony and didn't get the job (it was for a position on SCEA's R&D team). Me getting turned down was not my motivation for releasing ps2id. The Sony folks that I've dealt with are very cool, they've always treated me with respect (their office in Foster City, CA is amazing too:P). I hope that SCE* continues to produce consoles as fun to hack as the PS2.
My primary motivation was in getting this in people's hands was so that the barriers that prevent all PS2 owners from experiencing what I experience (when I develop homebrew PS2 software, or use it) would be removed. My ulterior motive (heh, there is always one, isn't there?) was to try and land other console hacking jobs professionally.
Yeah, the initial release was very rushed, but some wily hacker came up with the mantra Release Early, Release Often:P. A couple of people have already submitted tutorials and save files for other memcard adapters, and a ton of people have offered to mirror the site. Testament to the power of Open Source, blah, blah, blah...:P. I will be updating the site within the next few days with all of this, and working on the next ps2id release.
Overall, I'd like to see all kind of fun apps come from this that average, gaming PS2 owners can use, not just hackers.
Oh, about all the Linux posts: I've been developing a way to get ps2linux to boot without Sony's kit, and it will all tie into this. No ETA on that yet.
Cheers to all who've stepped up with the positive posts.
How is KOS better suited for this? The author of KOS has long since stated that for true OS development, you'd wanna stick with NetBSD or Linux/Dreamcast. Superior memory management, mature threading and network code, and easy of porting all make Linux a viable platform for DC development. *Ahem*, I meant embedded Linux development.
Most PC games use the mouse, with a lot of keyboard shortcuts. That
won't work on a console.
Hmm, standard Linux apps seem to work fine with the keyboard and mouse I use with the Dreamcast. More talking out of your arse here?
If the Dreamcast has less, you've got problems. (And the resolution of a TV ain't great.)
Jesus, grab yourself a clue along with your VGA box from Lik Sang. It's USD $12.50.
It's pathetic how you seem so hellbent on providing advice and bashing something you haven't even had the courage to read a couple of websites about.
It's nice to see the portability of Linux demonstrated. And you can use it to really freak out some non-Linux people.
For starters, read the article before posting... but I know that's asking a bit too much from this crowd.
But has this any practical use?...The Dreamcast community has created tools that are far better suited...
The Linux/Dreamcast port (in my vision at least) is designed for embedded Linux hacking, not to turn the DC into a powerful PC-like workstation. It has 16 megs of system RAM, more than enough to run most Linux apps as is anyway.
When Karl Kalleberg and myself started the port at LinuxDC (yes, not the same as the originial.jp port, for reasons I won't go into, but we're all friends now:P), the idea was to provide an embedded Linux system as an alternative for the hobbyist Dreamcast developers instead of the plucky toolkits (libdream, KOS, etc.) that were available. LinuxDC is *designed* to go as close to the metal as possible.
I'm still doing DC kernel hacking, check out the Task Manager on the SF project page for info on what's currently being worked on.
Really, it's a nice hack.
I wouldn't expect you to understand, as you obviously are inhibited from reading in some sort of way, but anyway, the port of Linux to the SuperH processor (to which the LinuxDC port belongs) is very real. Just browse your latest mainline kernel tree in the arch/sh/ directory for code relating the the DC and other SuperH boards.
If there are true kernel hackers, people interested in porting apps, testers, or people who are serious about tinkering with embedded Linux development feel free to stop by linuxdc.org. The developers are usually on #linuxdc on irc.openprojects.net.
Have fun, and thanks goes to Bill for the well-written article:P.
I've been a linux user since 1.0.9, and I'm not
trying to imply that I'd put a 2.4.8 kernel into production on monday, or even change a working
2.4.5 system to anything later without a good reason. But if the devteam want
to break things, it's high time to start breaking them in a 2.5.0.
and
You should have known it would be broken" is
not an acceptable response to a compatability
bug report from the field. 2.4.[678] are updates to a stable product, not incremental beta releases.
You should limit your use of blanket statements to avoid confusing newbies into thinking the wrong thing.
What's broken? Your compilation of third party modules (where it's always been accepted practice that the onus is on the third-party developer to stay in sync with the mainline). The kernel isn't broken, the point releases are bugfixes and improvements. If a header or API changes slightly (which AFAIK is the only reason why VMWare fails on recent kernels) it should be viewed as a bugfix or cleanup, not an attempt to radically change the way the kernel works.
Again, it's the responsibility of third-party developers (i.e. VMWare) to insure that their product is compatible with the kernel, not vice-versa. Let the kernel developers worry about stability.
Case-in-point: The CVS of SGI's XFS is constantly kept in sync with stable kernel releases.
It's slashdot, but some people forget to do their homework.
Hehe, so where did you go do your homework? If you knew the slightest about PS2 compatiblity with the PSX, you would know that after detecting a valid PSX CD (which has to be valid, not a burned copy) it executes it on the IOP - the original PSX processor.
And if you played close enough attention, you'd also notice that the orginial PSX BIOS loads as well... hmm.
Using your logic, you might as well keep developing for the original PSX, because on the PS2, that's all you would have access to.
The PS2 does depend on the proper format for its own games, but I won't go so far to say that it requires DVDs as I don't know that for certain.
BTW, what the hell are "proper ps1 headers" anyway? Just curious.
I wouldn't mention this, but 2.4 is supposed to be the STABLE tree. If the interface is changing, that's what the 2.5 series is for.
You shouldn't have. 2.4.x is the stable tree, which means that bugfixes, optimizations, and suggestions of improvement go into these kernels. Massive changes to the entire tree (like a rewrite of the MM, CML2) do not, as it would break kernel builds for a number of releases.
Something as big as compatability with VMWare ought to be checked before releasing.
Hmm, I think you have it the other way around. The VMWare developers are responsible for any breakage to their source-only modules, that's the reason they distribute them in source form, so that they can be in tune with the latest kernel release.
Anyway, get all your 2.4.6+ (and older) VMWare kernel fixes here:
Professional users of Linux are still hurting for credibility, and this kind of thing just does not help.
Professional Linux users already know that when you update a kernel, anything that's closely tied to the kernel (ALSA, VMWare, etc.) gets recompiled too. It comes with the territory.
M. R.
Re:tell that to the whiney hypocrites (liberals)
on
Review: Rush Hour 2
·
· Score: 1
The people you refer to that call each other "nigger" are actually calling each other "nigga" (there is still, however mute, a difference). It is a slang term that came from rap culture.
African-americans have been calling each other "nigger", "nigga" (or any other deviations) since slavery times. I hope you don't honestly believe that "nigga" is a slang term - although if you grew up listening to rap, I can see why you're so misinformed.
In most of the circles I grew up in/know, "nigga" is either used as a term of endearment (as in "that's my nigga"), or it's used to describe a certain mentality (ala Chris Rock's Bring The Pain bit). In the latter case, yes, it's used as an inflammatory remark, just like the term ghetto is.
There are many people (namely black people) that find even this offensive and I agree with them as is something that trivializes the fight for equality.
Yes, a lot of african-americans find it offensive, but usually when applied the wrong way by one of us or by another race.
But you're dead wrong with your assertion "it... trivializes the fight for equality" - I think you need to grab a history book (or two, and not the ones that brought you through middle/high school) and read up on the Civil Rights movement.
It has a 200Mhz Hitachi SH-4 processor, 16MB of system RAM, 8MB of video RAM, a seperate ARM7 core (with 2MB ram) for audio,... the list goes on. You can find a lot more info here and here.
You didn't really specify in your post how big or small of a system you're looking to target, but for a small net appliance and/or hobbyist 2D/3D gfx fun, nothing out there (in my opinion) tops the DC.
In the US a base DC is now only $99, and the 10/100Mbit ethernet adapter ranges from $50-70, depending on where you find it (e.g. the cheapest would be eBay, but Sega also sells them). A keyboard and mouse will probably run you about $10-25 apiece.
Current OSes scrambling for exposure in the DC arena include:
Finally a gem from Slashdot! I'm using the Socks4/5 Ads Blocker, and by voting for how crappy these clowns look, I can simultaneously block every ad on the page!
All I need to do is copy the image or link location (depending on whether it's a banner or text ad), paste it into my SAB config files, `killall -HUP sab`, and WHAM! C'ya rackspace spam! C'ya discounted airline travel!
After I vote you *NOT*, one less ad forever!
I seriously urge you to do this just to get a good laugh, kill ads, and relieve stress all at the same time!
.. find ethernet support in the latest CVS snapshot of the LinuxDC kernel. I'm writing up docs now (for NFS mounting and initrd), and I'll post to the site as soon as they're in CVS.
I know this is a shameless plug, but I spent all weekend working on ethernet, and I sent my friends a couple of e-mails via a telnet session (under a BusyBox filled initrd) from my Dreamcast:). But seriously, we need more kernel hackers in there so we can spit out more drivers....
Back on topic, the LinuxDC framebuffer writes from CPU RAM directly to PVR2 RAM, which is about as slow as you can get. I ran a simple SDL parallax scrolling example, and the results, were shall we say CRAP:). I've started thinking about how to accelerate the FB using the PVR2's Tile Accelerator, but I'm not that keen with its internals or how Tile-based redering would work (yet). If anyone there can point to some TA-based resources in general - there are a few good docs linked from julesdcdev, but I was thinking more general TA docs (e.g. not Dreamcast-specific).
We *need* interested developers, testers, and authors, to stop by LinuxDC (we're also in the process of restructuring our site), as we're finally starting to get the ball rolling...
Check out the LinuxDC (Linux on Dreamcast) project at linuxdc.sourceforge.net
. LinuxDC is about getting Linux to run on, well, the Sega Dreamcast with full hardware support for all peripherals, etc. We also want to document its mysterious hardware while doing.
Currently there's support for the hardware interrupts, and just last nite I committed initial framebuffer support. Other things to work on are GD-ROM support, PCI support (for the broadband adapter), Maple input (keyboard, controllers, mice), etc. So if you're a kernel hacker or good with documentation, we need you.
As things progress, we'll also start porting userland apps and libraries over as well. There's already a initial port of Debian to the SH arch, so that'd probably be where we headed.
Note: This is NOT the binary-ony kernel that was floating around some time back, we didn't do that kernel and we don't do GPL violations;).
Standards are supposed to be hacked on by lots of people and the more open they are the better. Microsoft fails to fulfill this requirement because most of the standards they push are designed to create inoperability so that they can get ahead.
Remember: Open Source does not imply chaos. I wish there was a universal "standard" for binary packaging for Linux and other free OSes, if we did the interoperablility between current distros would probably increase tenfold. Now the current binary packinging standards that exist are IMHO all Open Source, so yes, people can choose which one to use, but no, it's not trivial to move packages between different distros with the same kernel. I would think this is something you wouldn't want.
But I digress: standardization of library versions, basic files (now you did read the LDPS before posting didn't you?) is very much needed, especially for third party developers and brand new developers (such as myself). We can use this to make sure apps run on all distros that adhere to this, and given the list on the site, most do anyway. Also, the list of recommendations is basically what you would need create a usable Linux system, so you aren't forced into being compatible with something you won't use.
As Linux continues to grow, projects/organizations such as these will advance Open Source software, as Open Source development seems to revolve around Linux. It would be wise not to look for FUD where there is none.
I've heard that Linux on SH is further along in terms of booting to console then NetBSD is. I also have a Linux bias, but I'm willing to try out NetBSD when I get my stuff together. I've been wanting to try out FreeBSD as a devel. platform for a while now, just haven't had the time or motivation;P.
SDL is the Simple Direct media Library at libsdl.org. It's a small, low-level (but it sits over X, the frame buffer, GGI, DirectX, etc.) multimedia library that is responsible for most of Loki's ports to Linux.
I am currently in the process of getting the tools necessary to do homebrew development on the Dreamcast. I'm building the DCPC serial cable on Marcus' site, and I also have access to a burner so I can make bootable discs.
I don't really agree with some of the other posts which say this is limited to serving content or security, I see the advantages of this is increasing the ability to port *nix games and to be able to develop for multiple platforms at once.
I'm pushing for Linux to be ported to the DC, because then we can have a port of OpenGL (I hear the PowerVR2 supports it natively), and SDL (which AFAIK has been ported to FreeBSD) among other things. Just porting OpenGL and/or SDL would allow QuakeForge to be compiled for DC with probably little to no modifications. With a ppp driver in the kernel (or on a ramdisk if you prefer) you will have netplay for these types of games with a *minimum* of porting effort. Any linux games that don't require X (unless you want to port X, but why??) could be ported, off the top of my head I can think of xmame, lsdldoom, just to name some obvious ones.
Here's what I thought needed to be done:
Get the linux kernel up and running with a console on the serial port.
Allow the kernel to load a ramdisk from a CDR.
Write an accel. frame buffer to access the DC's frame buffer.
Impose certain constraints on the dev. system since this is a *console* and not an athalon w/ 128MB ram. One constraint would be instead of porting glibc, use newlib instead (is this even possible?). This would eliminate the majority of command-line Linux utils, but why would you want these anyway?
Port SDL using the frame buffer, I have no clue about OpenGL though.
This would replace WinCE as a devel. system, and allow broke college students such as myself to go nuts with the DC. Third-party developers might even be interested in this.
The SB AWE-WAVE kernel module uses the principle you described in your question. You can load the driver, but you must use userspace utilites to load SoundFonts and instruments for MIDI playback. I think that would be the best way to approach it (reading in a file and calling an ioctl on the driver), because if your firmware is updated all you have to do is load a new file, not recompile and reship a new module.
Consists of Telocity DSL protected via Linux Router Project Materhorn running on a 486DX-66.
All my internal boxes (including a roommates win98 machine) are masqueraded through my LRP router. I forward ssh, http/https, and smtp to an internal box, so my web server is publicly accessible, and I can receive my own mail (I use Qmail).
I also used the Public DNS service to provide forward DNS for 0xd6.org, which goes to my network at home. One bad thing about Telocity is that because they're swamped with tech support, etc., they won't delagate reverse DNS. For my simple home setup, I don't care.
This setup has been up and running for the last few months, I have also assisted a friend and my mother in getting this going. All you need is Telocity and a cheap 486 with two NICs and you're ready to go.
About telocity: It took about a month from ordering Telocity to having our service installed. My friend and mother's installation went fine but I had a few minor quirks which were easily solved by Telocity (i.e. they knew what the problem was and fixed it themselves). As I mentioned before, Telocity's one true failing is technical support. Be prepared to spend hours waiting to get a human, this is due to the fact that Telocity has many users in many cities. But as for running your own network, Telocity doesn't care what you do as long as you don't do anything commercial. In fact, we were told that our service was limited to 768k down/384k up, but in actuality Telocity doesn't limit up (I've gotten 768k consistently) and they're rate-limiting software doesn't work as well as they thought, because I've gotten over 900k downloading before my speeds started dropping. The moral of this story is: get telocity and go nuts with your setup. Make sure that you protect your network.
In lieu of the announcement on the DDH and the ability to burn Dreamcast software to CDRs (see the same article for info), here are some ideas surrounding OpenGL on the Dreamcast:
As I understand it, right now licensed developers can use Sega's built in OS for low-level stuff on the DC, or they can use WinCE + DirectX. I've read that there is OpenGL support for the PowerVR2 that powers the Dreamcast, but whether or not that's available to developers now, I have no idea.
Instead of WinCE and DirectX, we could finish the port of Linux and add OpenGL. Linux would handle all MM, networking, input devices, and the framebuffer (which is 8MB on the DC). Then we could also port SDL because I see it as the most full-featured and cross-platform (7 different platforms) open source multimedia library in existence. For example, this would allow a port of QuakeForge much simpler than a full native DC port.
Finally, OpenGL (which can be accessed through SDL) would be ported (still fuzzy on this) and you would have a full development system for the DC that was fully open source and useable by anyone with a DC (without a GD-ROM).
DC software developers would be able to choose which kernel features and libraries they want distributed with their final project. Even Sega would win with something like this, only problem is, finding concrete specs on the Dreamcast is next to impossible. Hopefully this could be started without waiting on the DC to be "opened" by Sega.
Right now I'm trying to determine how the CDX demo CD fooled the DC into thinking it was a valid DC app. This DC development site has info on how to build a serial cable to interface to the PC. If software can be burned that accesses the serial port, then we can do cheap development on the DC. I've also e-mailed the guy who put up the DDH page (for more info + schematics), but I haven't got a response yet. If anyone out there has any low-level info at all on the DC please let me know.
Hmm, maybe I should clarify my questions. The Slashdot post implied that the technical specs were out there which is what I'm interested in, not "The Matrix" in MP4 on a website (that's what Gnet is for!). Where are the MP4 specs, and is there any open code out there that does anything with it?
Where are the specs on the MP4 format? By encoding, do they mean from MPEG2 -> MP4? The "hacked" codec from M$, does anyone have it out there (source?)??
Slashdot Mirror
There was a method discovered some time ago that allows you to swap the current (valid) disc with an invalid one and boot it all the same. This requires a PS2 boot disc that was designed to facilitate this and was mostly fixed in later PS2 revisions.
So a pure software loader would be unable to access an invalid disc unless it were swapped, but there are so many obstacles there that it isn't practical to attempt that (if it would even work) with this exploit - I am not naive enough to say it isn't possible - it just isn't practical to implement or use.
I have no idea if I would get burned (as in Sony would have a valid case) legally if this were to happen with the exploit, since the flaw that enables swapping has existed since the PS2 was launched. I guess what I'm trying to say is that the exploit doesn't enable any piracy features not already present in the PS2.
The first site we always recommend is ps2dev.org. You can also find us on IRC in #ps2dev on EFNet, where we can help you get setup (if ps2dev.org or it's links aren't enough).
I don't typically read or post on /. these days, but since you folks were so kind as to saturate my cable connection :P, I read through the comments and wanted to clarify a few things:
Oh, about all the Linux posts: I've been developing a way to get ps2linux to boot without Sony's kit, and it will all tie into this. No ETA on that yet.
Cheers to all who've stepped up with the positive posts.
Linux Test Project.
M. R.
C'mon now, please don't tell me that emucrap is the only thing you see running on the Dreamcast.
M. R.
It's pathetic how you seem so hellbent on providing advice and bashing something you haven't even had the courage to read a couple of websites about.
M. R.
When Karl Kalleberg and myself started the port at LinuxDC (yes, not the same as the originial .jp port, for reasons I won't go into, but we're all friends now :P), the idea was to provide an embedded Linux system as an alternative for the hobbyist Dreamcast developers instead of the plucky toolkits (libdream, KOS, etc.) that were available. LinuxDC is *designed* to go as close to the metal as possible.
I'm still doing DC kernel hacking, check out the Task Manager on the SF project page for info on what's currently being worked on.
I wouldn't expect you to understand, as you obviously are inhibited from reading in some sort of way, but anyway, the port of Linux to the SuperH processor (to which the LinuxDC port belongs) is very real. Just browse your latest mainline kernel tree in the arch/sh/ directory for code relating the the DC and other SuperH boards.If there are true kernel hackers, people interested in porting apps, testers, or people who are serious about tinkering with embedded Linux development feel free to stop by linuxdc.org. The developers are usually on #linuxdc on irc.openprojects.net.
Have fun, and thanks goes to Bill for the well-written article :P.
M. R.
That "demo" has very little hardware support, and is from Summer 2000 (or before).
Real Linux/Dreamcast distributions (e.g. Debian) are currently in the works.
M. R.
NT user passwords are stored in the registry, as well as on disk.
M. R.
What's broken? Your compilation of third party modules (where it's always been accepted practice that the onus is on the third-party developer to stay in sync with the mainline). The kernel isn't broken, the point releases are bugfixes and improvements. If a header or API changes slightly (which AFAIK is the only reason why VMWare fails on recent kernels) it should be viewed as a bugfix or cleanup, not an attempt to radically change the way the kernel works.
Again, it's the responsibility of third-party developers (i.e. VMWare) to insure that their product is compatible with the kernel, not vice-versa. Let the kernel developers worry about stability.
Case-in-point: The CVS of SGI's XFS is constantly kept in sync with stable kernel releases.
M. R.
And if you played close enough attention, you'd also notice that the orginial PSX BIOS loads as well ... hmm.
Using your logic, you might as well keep developing for the original PSX, because on the PS2, that's all you would have access to.
The PS2 does depend on the proper format for its own games, but I won't go so far to say that it requires DVDs as I don't know that for certain.
BTW, what the hell are "proper ps1 headers" anyway? Just curious.
M. R.
Anyway, get all your 2.4.6+ (and older) VMWare kernel fixes here:
I'm currently using VMWare with 2.4.7.
Professional Linux users already know that when you update a kernel, anything that's closely tied to the kernel (ALSA, VMWare, etc.) gets recompiled too. It comes with the territory.M. R.
In most of the circles I grew up in/know, "nigga" is either used as a term of endearment (as in "that's my nigga"), or it's used to describe a certain mentality (ala Chris Rock's Bring The Pain bit). In the latter case, yes, it's used as an inflammatory remark, just like the term ghetto is.
Yes, a lot of african-americans find it offensive, but usually when applied the wrong way by one of us or by another race.But you're dead wrong with your assertion "it ... trivializes the fight for equality" - I think you need to grab a history book (or two, and not the ones that brought you through middle/high school) and read up on the Civil Rights movement.
M. R.
It has a 200Mhz Hitachi SH-4 processor, 16MB of system RAM, 8MB of video RAM, a seperate ARM7 core (with 2MB ram) for audio, ... the list goes on. You can find a lot more info here and here.
You didn't really specify in your post how big or small of a system you're looking to target, but for a small net appliance and/or hobbyist 2D/3D gfx fun, nothing out there (in my opinion) tops the DC.
In the US a base DC is now only $99, and the 10/100Mbit ethernet adapter ranges from $50-70, depending on where you find it (e.g. the cheapest would be eBay, but Sega also sells them). A keyboard and mouse will probably run you about $10-25 apiece.
Current OSes scrambling for exposure in the DC arena include:
Dan Potter's KallistiOS (the first native DC OS),
NetBSD/Dreamcast,
Our very own LinuxDC Project, and
There's even a port of RedHat's eCos underway!
M. R.
Adding CDDB xref'ing is an excersise left to the reader ;-).
M. R.
All I need to do is copy the image or link location (depending on whether it's a banner or text ad), paste it into my SAB config files, `killall -HUP sab`, and WHAM! C'ya rackspace spam! C'ya discounted airline travel!
After I vote you *NOT*, one less ad forever!
I seriously urge you to do this just to get a good laugh, kill ads, and relieve stress all at the same time!
M. R.
I know this is a shameless plug, but I spent all weekend working on ethernet, and I sent my friends a couple of e-mails via a telnet session (under a BusyBox filled initrd) from my Dreamcast :). But seriously, we need more kernel hackers in there so we can spit out more drivers....
Back on topic, the LinuxDC framebuffer writes from CPU RAM directly to PVR2 RAM, which is about as slow as you can get. I ran a simple SDL parallax scrolling example, and the results, were shall we say CRAP :). I've started thinking about how to accelerate the FB using the PVR2's Tile Accelerator, but I'm not that keen with its internals or how Tile-based redering would work (yet). If anyone there can point to some TA-based resources in general - there are a few good docs linked from julesdcdev, but I was thinking more general TA docs (e.g. not Dreamcast-specific).
We *need* interested developers, testers, and authors, to stop by LinuxDC (we're also in the process of restructuring our site), as we're finally starting to get the ball rolling...
M. R.
Currently there's support for the hardware interrupts, and just last nite I committed initial framebuffer support. Other things to work on are GD-ROM support, PCI support (for the broadband adapter), Maple input (keyboard, controllers, mice), etc. So if you're a kernel hacker or good with documentation, we need you.
As things progress, we'll also start porting userland apps and libraries over as well. There's already a initial port of Debian to the SH arch, so that'd probably be where we headed.
Note: This is NOT the binary-ony kernel that was floating around some time back, we didn't do that kernel and we don't do GPL violations ;).
M. R.
Standards are supposed to be hacked on by lots of people and the more open they are the better. Microsoft fails to fulfill this requirement because most of the standards they push are designed to create inoperability so that they can get ahead.
Remember: Open Source does not imply chaos. I wish there was a universal "standard" for binary packaging for Linux and other free OSes, if we did the interoperablility between current distros would probably increase tenfold. Now the current binary packinging standards that exist are IMHO all Open Source, so yes, people can choose which one to use, but no, it's not trivial to move packages between different distros with the same kernel. I would think this is something you wouldn't want.
But I digress: standardization of library versions, basic files (now you did read the LDPS before posting didn't you?) is very much needed, especially for third party developers and brand new developers (such as myself). We can use this to make sure apps run on all distros that adhere to this, and given the list on the site, most do anyway. Also, the list of recommendations is basically what you would need create a usable Linux system, so you aren't forced into being compatible with something you won't use.
As Linux continues to grow, projects/organizations such as these will advance Open Source software, as Open Source development seems to revolve around Linux. It would be wise not to look for FUD where there is none.
Marcus
I've heard that Linux on SH is further along in terms of booting to console then NetBSD is. I also have a Linux bias, but I'm willing to try out NetBSD when I get my stuff together. I've been wanting to try out FreeBSD as a devel. platform for a while now, just haven't had the time or motivation ;P.
SDL is the Simple Direct media Library at libsdl.org. It's a small, low-level (but it sits over X, the frame buffer, GGI, DirectX, etc.) multimedia library that is responsible for most of Loki's ports to Linux.
Marcus
I don't really agree with some of the other posts which say this is limited to serving content or security, I see the advantages of this is increasing the ability to port *nix games and to be able to develop for multiple platforms at once.
I'm pushing for Linux to be ported to the DC, because then we can have a port of OpenGL (I hear the PowerVR2 supports it natively), and SDL (which AFAIK has been ported to FreeBSD) among other things. Just porting OpenGL and/or SDL would allow QuakeForge to be compiled for DC with probably little to no modifications. With a ppp driver in the kernel (or on a ramdisk if you prefer) you will have netplay for these types of games with a *minimum* of porting effort. Any linux games that don't require X (unless you want to port X, but why??) could be ported, off the top of my head I can think of xmame, lsdldoom, just to name some obvious ones.
Here's what I thought needed to be done:
Get the linux kernel up and running with a console on the serial port.
Allow the kernel to load a ramdisk from a CDR.
Write an accel. frame buffer to access the DC's frame buffer.
Impose certain constraints on the dev. system since this is a *console* and not an athalon w/ 128MB ram. One constraint would be instead of porting glibc, use newlib instead (is this even possible?). This would eliminate the majority of command-line Linux utils, but why would you want these anyway?
Port SDL using the frame buffer, I have no clue about OpenGL though.
This would replace WinCE as a devel. system, and allow broke college students such as myself to go nuts with the DC. Third-party developers might even be interested in this.
Marcus
Marcus
All my internal boxes (including a roommates win98 machine) are masqueraded through my LRP router. I forward ssh, http/https, and smtp to an internal box, so my web server is publicly accessible, and I can receive my own mail (I use Qmail).
I also used the Public DNS service to provide forward DNS for 0xd6.org, which goes to my network at home. One bad thing about Telocity is that because they're swamped with tech support, etc., they won't delagate reverse DNS. For my simple home setup, I don't care.
This setup has been up and running for the last few months, I have also assisted a friend and my mother in getting this going. All you need is Telocity and a cheap 486 with two NICs and you're ready to go.
About telocity:
It took about a month from ordering Telocity to having our service installed. My friend and mother's installation went fine but I had a few minor quirks which were easily solved by Telocity (i.e. they knew what the problem was and fixed it themselves). As I mentioned before, Telocity's one true failing is technical support. Be prepared to spend hours waiting to get a human, this is due to the fact that Telocity has many users in many cities. But as for running your own network, Telocity doesn't care what you do as long as you don't do anything commercial. In fact, we were told that our service was limited to 768k down/384k up, but in actuality Telocity doesn't limit up (I've gotten 768k consistently) and they're rate-limiting software doesn't work as well as they thought, because I've gotten over 900k downloading before my speeds started dropping. The moral of this story is: get telocity and go nuts with your setup. Make sure that you protect your network.
Marcus
As I understand it, right now licensed developers can use Sega's built in OS for low-level stuff on the DC, or they can use WinCE + DirectX. I've read that there is OpenGL support for the PowerVR2 that powers the Dreamcast, but whether or not that's available to developers now, I have no idea.
Instead of WinCE and DirectX, we could finish the port of Linux and add OpenGL. Linux would handle all MM, networking, input devices, and the framebuffer (which is 8MB on the DC). Then we could also port SDL because I see it as the most full-featured and cross-platform (7 different platforms) open source multimedia library in existence. For example, this would allow a port of QuakeForge much simpler than a full native DC port.
Finally, OpenGL (which can be accessed through SDL) would be ported (still fuzzy on this) and you would have a full development system for the DC that was fully open source and useable by anyone with a DC (without a GD-ROM).
DC software developers would be able to choose which kernel features and libraries they want distributed with their final project. Even Sega would win with something like this, only problem is, finding concrete specs on the Dreamcast is next to impossible. Hopefully this could be started without waiting on the DC to be "opened" by Sega.
Right now I'm trying to determine how the CDX demo CD fooled the DC into thinking it was a valid DC app. This DC development site has info on how to build a serial cable to interface to the PC. If software can be burned that accesses the serial port, then we can do cheap development on the DC. I've also e-mailed the guy who put up the DDH page (for more info + schematics), but I haven't got a response yet. If anyone out there has any low-level info at all on the DC please let me know.
Marcus
M. R.
Where are the specs on the MP4 format? By encoding, do they mean from MPEG2 -> MP4? The "hacked" codec from M$, does anyone have it out there (source?)??
M. R.