Starting Coding again (AtariOwl)

[AtariOwl]

Hello Guys it's been a long time, but i'm considering again the possibility of DC Coding.

Some of you may know i was working on a Jaguar game, but the will for that has kind of waned somewhat and i'm considering switching the project to the DC which is immeasurably more suited to the project.

Essentially I'm trying to figure out what is the most sensible toolset and the easiest way to get going.
Is emulation a way forward?
Serial?
SD?


Lets see if i can answer the questions that are likely to come up

1. I'm using Windows.. Win7 mainly but i could probably muster up an XP if necessary

2. I know my way around
C/C++
ASM on Z80, 680x0, 5600x, Jag RISC so hopefully picking up new ones especially RISCS wont be much hassle
So it shouldn't be too much of a stretch i hope

3. I can't seem to find any DC DEV R? ISO that work not sure what makes the most sense anyway.
4. I seem to have a Coders Cable but no idea how to use it.
5. I seem to have a file called WinCE Dreamcast Dev Kit 2.1 I don't know anything about it.
6. Is there any point in an SD Reader?
7. What is the standard method of debugging these days?

VEry much hoping i wont have to go through the pain i did with the Jag.

http://atariowlproject.blogspot.co.uk/s ... results=10

Cheers
AO

[BlueCrab]

Essentially I'm trying to figure out what is the most sensible toolset and the easiest way to get going.
Is emulation a way forward?

While it is somewhat convenient to test out code, if you have another sensible choice, I'd avoid it.

Serial?
SD?

Both of these are potentially sensible choices, as well as ethernet if you get your hands on a LAN adapter or a BBA.

1. I'm using Windows.. Win7 mainly but i could probably muster up an XP if necessary

Linux/BSD/[insert other UNIX-like system here] will work best, but many people have used Windows without problems in the past. You'll need something like Cygwin in order to build a toolchain and whatnot, and I'm sure you can find ample directions on what exactly you'll need around these forums if you search a bit.

2. I know my way around
C/C++
ASM on Z80, 680x0, 5600x, Jag RISC so hopefully picking up new ones especially RISCS wont be much hassle
So it shouldn't be too much of a stretch i hope

C or C++ will get you pretty much anything done on the Dreamcast. Assembly is rarely needed, unless you have something REALLY compute intensive to deal with.

3. I can't seem to find any DC DEV R? ISO that work not sure what makes the most sense anyway.

It is horribly outdated at this point, and I'd recommend against trying to use it.

4. I seem to have a Coders Cable but no idea how to use it.

dcload-serial. 'nuf said.

5. I seem to have a file called WinCE Dreamcast Dev Kit 2.1 I don't know anything about it.

You won't find help with that here as it is illegal to use without a license from Sega/Microsoft (and they aren't going to sell you a license for it now anyway). KOS can do pretty much anything you'll want to do anyway, and potentially with a lot less overhead than WinCE would have incurred.

6. Is there any point in an SD Reader?

Sure. You can put binaries or resources and whatnot on it and use it fairly easily with the code that is built-in to KOS. The only sticking point would be potentially the filesystem, as there is no native method on Windows to read ext2 (which is the filesystem provided for the SD card in KOS itself, mainly due to potential patent issues with certain features of FAT32).

7. What is the standard method of debugging these days?

Usually, either using dcload-serial or dcload-ip depending on whether you have a Coder's cable or a BBA/LAN adapter. As mentioned above, you can use the SD card reader to do this too, since you'd be able to read/write files with whatever debugging information you'd want to print out.

[AtariOwl]

Hi Bluecrab for the response. Its extremely helpful.

I'll avoid emulation i guess
Plainly Serial is the way for me to go at the moment


1. Windows/DC DEV ISO etc

Ah. OK i'm going to have to make an admission here, i've never used GCC I've never set it up never done anything with it.
I dont have any Linux or BSD machines.

I'm looking at the KallisTOS site and there's a list of thing

Unfortunately, due to the vast differences between various distributions and OSes, it is pretty much impossible to tell you exactly how to set up your environment on your computer. However, here is a general list of packages you will need to get started:

A full GCC setup and development libraries for your OS
A working POSIX-compatible shell (such as bash — should be installed in any POSIX environment)
A working POSIX-compatible awk (such as GNU awk — should also be installed in any POSIX environment)
patch version 2.5.4 (or later)
bzip2 version 1.0.2 (or later)
GNU tar version 1.14 (or later)
GNU make version 3.80 (or later)
GNU Multiple Precision Library (GMP) version 4.3.2 (or later) — make sure to install the development library for this as well
MPFR Library version 2.4.2 (or later) — once again, you need the development library too
MPC Library version 0.8.1 (or later) — once again, you need the development library too
gettext version 0.14.5 (or later) — only needed if you want localized error messages from the compiler
wget (any version should work, I think) — needed to use the download script with dc-chain. Not really necessary, since you can download all the source code to GCC and friends yourself.
libelf — make sure to install the development package for this too. Only needed for building dc-tool (serial or broadband). If you do not need to build them, then you do not have to worry about it.
texinfo (not sure of the version) — Needed for building Newlib documentation. Newlib's Makefile complains if you don't have it, so it is a good idea to install it.
bison, flex, and sed — Probably already installed along with the rest of the POSIX environment, but it does not hurt to list them here too.
Git version 1.7.5 (or later)

And i'm coming up with a big fat duck egg about these, isimply have no idea.
Nor do i have any idea about Cygwin.
Never had a call to use it.

I'll do some more looking around I guess.


2. OK C it is

5. I should probably get rid of that WinCE thing.

[RyoDC]

Crab, I'm deeply sorry, but what are this thing that you're constantly talking about when it comes down to even mention the possibility of usage of one of those old Dev kits.
Who the hell would even care about them, not to mention all that licensing crap, when particularly at this moment almost 15 years gone after those SDK's were even released?
I mean yes, at the time they were released and had commercial value there was a sense to pursue such illegal users (and mostly those SDK were closed and non-free due to the SEGA deep intention to constrain the concurrence and hedge the market from unwanted developers), but now, seriously? Who would hunt down or even observe this?

P.S. Sorry for such an emotional post, just want to hear your reasons and motivation.

[AtariOwl]

I can understand it, sometimes retro comes back into fashion and you would be surprised how ferociously some companies will pursue their rights even of seemingly obsolete materials.

I will use KallistiOS and forget about the other thing. I'm not even sure who gave it to me now.
There's no point in asking for trouble

One good thing about the Jaguar was at least it was released, together with the devkit to the PD.
It may have been a bear to code to do anything special, with a somewhat toxic community, but at least it was legal.

[BlueCrab]

Crab, I'm deeply sorry, but what are this thing that you're constantly talking about when it comes down to even mention the possibility of usage of one of those old Dev kits.
Who the hell would even care about them, not to mention all that licensing crap, when particularly at this moment almost 15 years gone after those SDK's were even released?
I mean yes, at the time they were released and had commercial value there was a sense to pursue such illegal users (and mostly those SDK were closed and non-free due to the SEGA deep intention to constrain the concurrence and hedge the market from unwanted developers), but now, seriously? Who would hunt down or even observe this?

P.S. Sorry for such an emotional post, just want to hear your reasons and motivation.

They're illegal to use. Plain and simple. Sega probably wouldn't come after you for using them, and neither would Microsoft in all likelihood, but does that make it right and legal? No. I mean, you could steal the money out of a cup that a homeless person is sitting on the side of the street with and probably get away with it too, but would you?

Why should you use something that's illegal to use (and that many sites, including this one, will not distribute) if there are legal tools to use? Not to mention the fact that finding documentation and help with those tools will be difficult since most of the development community realizes there's no value in using them.

And if to you I seem overly concerned with this kind of stuff, you're probably correct. I'm a student in Computer Science and basically look at it this way... If I want people to respect the copyrights/licenses on the software I write, then I should probably respect the copyrights and licenses of the other software I use.

[AtariOwl]

OK dc-tool

What am i doing wrong?

i've got an elf flile to check if my serial cable works
i've got a dc load boot disk running

i try to send the file using dc-tool

NOTHING.

Any ideas?

[BlueCrab]

What is it doing exactly when you run dc-tool? Is it saying it uploaded the file successfully, or is it not saying that at all? Also, how are you running the program (command line arguments, any output, etc would be helpful).

[AtariOwl]

Its not saying anything

I start dc-tool -x example.elf

I get

Console Enabled
Upload <example.elf>
File Format iois elf32-shl, start addresss os 0x8c010000
Section .txt, lma 0x8c010000. size 226720


Then nothing happens


On the DC i get something off screen
load 1.03
ile...


And similarly nothing happens
wondering if its my gable or the serial port on my docking station , clueless really

[BlueCrab]

You usually have to specify what serial port you want it to send to on the command line as well. I don't know for sure how one would do that on Windows/Cygwin, but I know on Linux, it would be something like this:
dc-tool -t /dev/ttyS0 -x example.elf

[AtariOwl]

Got It!

I think it was my burn of the CD. The screen was black apart from that text.
When i burned a new CD there was a white bar on the right hand side.
It now transfers correctly.

The dangers of not knowing what you're looking for

OK at least i have a working setup to transfer files

[AtariOwl]

ok

i'm using an old installation until i get the hang of things

now i'm having difficulty changing the mode to PAL

i tried to use vid_set_mode(DM_640x480_PAL_IL, PM_RGB565); but its not seeing the DM_640x480_PAL_IL

i have a section shich sets up the video flags but i'm not sure how to make them DM_640x480_PAL_IL or at least to set NTSC or PAL

There is a line which says
/* enable NTSC */
videoflags |= 1<<6;

WOndering

[BlueCrab]

Are you doing a #include <dc/video.h> (or #include <kos.h>)? If so, DM_640x480_PAL_IL is definitely defined in an enumeration.

[AtariOwl]

i'm doing an include <kos.h> but not a dc/video.h


hmmm no such file or directory... there is my issue when i try the dc/video.h there is a local video.h which is probably messing things up

edit: ok i added the kos.h and its not finding it, although another build i have in another directory finds it just fine.
Is it something to do with the makefile?
the .svn?
the romdisk?

[BlueCrab]

The only thing I'd be able to guess would be potentially something odd in the Makefile...

[AtariOwl]

In essence i'm trying to get this 3d example going as a base from which to experiment.

http://mc.pp.se/dc/files/tatest.tar.gz

It compiles fine but i cant see it on my PAL screen

Makefile
AS = sh-elf-as -little
LD = sh-elf-ld -EL
CC = sh-elf-gcc -ml -m4-single-only -mhitachi

OBJS = startup.o main.o matrix.o ta.o video.o

tatest.srec : $(OBJS)
$(CC) -o $@ -Wl,--oformat,srec,-Ttext=0x8c010000 -nostartfiles -nostdlib $(OBJS) -lgcc -lc -lgcc

startup.o : startup.s

main.o : main.c video.h ta.h matrix.h

matrix.o : matrix.s

ta.o : ta.c ta.h

video.o : video.c video.h



The video.h referred to is local and not the standard video.h which it doesnt pick up anyway.
Its not seeing the includes

It has o be a makefile issue

[BlueCrab]

Ah... Yes, Marcus' examples don't use KOS at all. Unless you're planning on not using KOS for some reason, you might want to just look around the KOS examples tree for interesting examples to start from.

Marcus' examples predate KOS, and actually helped form the basis for a lot of later stuff. The startup.s file that KOS uses actually is pretty much the same as the one in Marcus' examples, for instance. That said, they're (in general) a lot more low-level than you'd need to worry about when using KOS. Very good for learning how to make the hardware work if you're really interested in doing so without the benefit of the existing libraries, but probably not as useful otherwise.

Also, they're very useful if you find (for whatever reason) that you can't use KOS for a given project, as I did with my PSO Patcher disc.

[AtariOwl]

Ahhhhhhhhh

OK

There is much there i should like to use
Is there anyway to attach KOS to this example?
It has some good useful parts.

Am i correct that it was the makefile that has caused me to be unable to use KOS? Yes of course i am its patently obvious. Just read the darn makefile Joe. SOrry, not entirely with it. I need to understand the association in the makefile.
I'm not sure how to reassociate it.



Otherwise.. i'd really like to be able to set that videomode at least.
It was easy with KOS, but it does not seem to be so in that example.

if(res==2)
/* interlace mode */
videoflags |= 1<<4;

/* enable NTSC */
videoflags |= 1<<6;


Does not seem to tie up with

// These are for the "flags" field of "vid_mode_t"
#define VID_INTERLACE 0x00000001
#define VID_LINEDOUBLE 0x00000002 // <-- For 240 scanlines on VGA cable
#define VID_PIXELDOUBLE 0x00000004 // <-- For low-res modes (320)
#define VID_PAL 0x00000008 // <-- This sets output to 50Hz PAL if not CT_VGA


I guess i need to make a makefile that can reassociate it with KOS

[AtariOwl]

Good grief this is a pain

if i try to add kos.h
from main.c:4 :
/usr/local/dc/kos/kos/kernal/arch/dreamcast/include/arch/arch.h:15:22: dc/video.h: No such file or directory

All i'm trying to do is change the video system to PAL so it doesn't blow up my TV.
None of the information seems to match up. I've changed all the bits in the videoflags register and its still not right.

I'm not sure i have the patience i once had.

[AtariOwl]

I think i'll stop rushing and slowly take my time
Read and see what i'm actually doing

Nahhh its not me its the installation i think, several of the examples are giving the same errors