Makaqu Networking on DC

JasonX · Post by **JasonX** » Thu Mar 24, 2011 2:43 pm

Suddenly, this question came to my mind: is networking possible in the Dreamcast with Makaqu or other ports?

Spirit · Post by **Spirit** » Thu Mar 24, 2011 3:50 pm

Check the readme files.

mh · Post by mh » Thu Mar 24, 2011 3:57 pm

Sure nobody ever reads those!

ceriux · Post by **ceriux** » Thu Mar 24, 2011 5:01 pm

i think anytime someone makes a project, they should make a small page with an online readme that opens with in that projects page. i'd probably read the readme's then. i just hate reading out of text files.

leileilol · Post by **leileilol** » Thu Mar 24, 2011 5:10 pm

I hate reading out of HTM files.

dreadlorde · Post by **dreadlorde** » Thu Mar 24, 2011 7:47 pm

ceriux wrote:i think anytime someone makes a project, they should make a small page with an online readme that opens with in that projects page. i'd probably read the readme's then. i just hate reading out of text files.

That makes perfect sense. Why read a simple text file with a simple text editor when you can read a complex document with flashy colours in a complex web browser.

mh · Post by mh » Thu Mar 24, 2011 8:29 pm

dreadlorde wrote:Why read a simple text file with a simple text editor when you can read a complex document with flashy colours in a complex web browser.

Reason #1 would be because people don't read readme files. It might be a simple text file in a simple text editor, but 95% of the time you're wasting your time and energy writing it because it won't be read. You could write any old rubbish in there and I can guarantee that most people will never even be aware of it. Forget about security, readme files are probably the safest place in the world to stash confidential or personal info.

Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.

Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.

Team Xlink · Post by **Team Xlink** » Fri Mar 25, 2011 12:28 am

JasonX wrote:Suddenly, this question came to my mind: is networking possible in the Dreamcast with Makaqu or other ports?

Not yet, however I'm working on a way to network it and avoid requiring PPP support, BlueCrab says he thinks it will work, so I'm expecting a good outcome.

frag.machine · Post by **frag.machine** » Fri Mar 25, 2011 12:37 am

mh wrote:I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either.

Huh... There's no such thing as "Unix line endings". In Unix, Linux and others OSes, a line break is signaled with the '\n' (0xd). However, there is a "DOS/Windows line ending", where the line break is signaled by TWO characters, '\n' and '\r' (0xd and 0xa, respectively). Every current *nix text editor I used in the last 10 years or so can handle both formats in a seamless way; the same cannot be said about Windows Notepad, which is unable to understand this complex concept of line breaks with just a single char.

Oh, well...

mh · Post by mh » Fri Mar 25, 2011 1:15 am

Either/or, it doesn't matter what I call it, you know what I'm talking about anyway.

Incidentally, there's no such thing as DOS/Windows line endings either, and Unix was certainly not the first OS to adopt a line-ending convention.

The CR/LF convention came from emulating teletype machines, DOS inherited it's convention from CP/M (which copied the teletype emulation convention) and Unix from Multics. Modern Windows (which - let's be clear - has absolutely no relationship whatsoever to DOS) is just following the CP/M standard.

None of which excuses the shocking disgrace of Windows notepad of course, which is one reason why I always keep a shortcut to Wordpad in my "Send To" menu; it has no problems recognising them.

And nor does it excuse the developers I was talking about from not getting the line endings right in the readme.

dreadlorde · Post by **dreadlorde** » Fri Mar 25, 2011 10:22 pm

mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.

"Correct" line endings? Your mean a carriage return and then a new line? Talk about going back to the days of teletypes and typewriters!

Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.

Something better: Keep it simple stupid. Why would someone go to a website to essentially read a readme file if the won't even read the readme? Not everyone downloads software from where it was created.

mh · Post by mh » Sat Mar 26, 2011 3:28 pm

dreadlorde wrote:
mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.
"Correct" line endings? Your mean a carriage return and then a new line? Talk about going back to the days of teletypes and typewriters!

Context - line endings that are correct for the target platform.

Using CR/LF actually has a lot of advantages; not least that it's also compliant with RFCs 821, 1939, 2060 and 2616. Unix also actually does use CR/LF for on-screen display; it's only for storage where it just uses LF (it converts from LF to CR/LF when displaying). So it's storage of plain text files on Unix that is actually the odd one out. Some more interesting history and discussion here: http://blogs.msdn.com/b/oldnewthing/arc ... 91899.aspx (by somebody who is namechecked as a contributor by Linus in the Linux kernel 1.0 docs, so he's knows what he's talking about from both sides of the fence).

dreadlorde wrote:
Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.

Something better: Keep it simple stupid. Why would someone go to a website to essentially read a readme file if the won't even read the readme? Not everyone downloads software from where it was created.

OK, that's a valid enough reason, but I can think of reasons why an online readme might be preferred by many. Hyperlinks is one, bookmarks is another, searching and indexing is a third.

Either way it still doesn't excuse the author from not having used line endings that are correct for the target platform.

Baker · Post by **Baker** » Sun Mar 27, 2011 2:58 am

mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.

Interesting stuff. Visited the link. I always wondered what the carriage return was for. Prior to that, I thought a carriage return was silly and seemed to only make text document compatibility a pain in the arse.

I guess there was a reason for it back in the day. Dot matrix printers or whatever the deal was back in the day.

/Honestly I've got no idea what TextPad and WinMerge do to line endings nor do I think about whether or not my readmes are "Notepad" compatible. I may be guilty.

mankrip · Post by **mankrip** » Sun Mar 27, 2011 8:28 pm

No Dreamcast homebrew software was ever able to connect to the Internet via dial-up, due to the lack of a PPP stack in the DC modem's KallistiOS driver.

There are many homebrew programs that uses the broadband adapter instead, but this adapter is so expensive and rare there's no point in supporting it, due to the extremely limited userbase. Well, actually I'd implement support for it anyway if there weren't higher priorities in my list.

However, BlueCrab certainly knows a lot more about DC networking than I do, so good luck. Networking via dial-up Internet is something the DC homebrew scene always needed.

Team Xlink · Post by **Team Xlink** » Wed Apr 06, 2011 4:58 pm

mk wrote:No Dreamcast homebrew software was ever able to connect to the Internet via dial-up, due to the lack of a PPP stack in the DC modem's KallistiOS driver.

There are many homebrew programs that uses the broadband adapter instead, but this adapter is so expensive and rare there's no point in supporting it, due to the extremely limited userbase. Well, actually I'd implement support for it anyway if there weren't higher priorities in my list.

However, BlueCrab certainly knows a lot more about DC networking than I do, so good luck. Networking via dial-up Internet is something the DC homebrew scene always needed.

It avoids using PPP, think "system link" and your on the right track.

InsideQC Forums

Makaqu Networking on DC

Makaqu Networking on DC

Re: Makaqu Networking on DC