Forums

How do language compilers like C work? I mean, I understand the process but I don't understand how it letterly converts text into code. For instance, codes like...




char me;


int mydata;

How does it know where to declare the data? How does it refer to those variables after that? Even in assembly, how does an assembler refer to a variable by just a label? Also, how are functions converted? When you call a function in C, I know that it follows a list of instructions in it but how does the compiler set it up? Does the compiler convert the function into an assembly subroutine and the program merely jumps to that section of memory where the function is? Where is the function code even stored?

And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here. Mabye give enough interest for them to someday write they're own Z80 language compiler or something.

Chris :o)

Quote

> And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here.

It is seriously off-topic but I think we are all used to you accidentally posting off-topic stuff (until you'll get accidentally banned).
I'm not againt such thread, but I suggest to buy yourself a book about compilers.

Quote

>Mabye give enough interest for them to someday write they're own Z80 language compiler or something.

Bad point. Making a Z80 assembler is *very* different (and quite easy) than making a C compiler.

Quote

> How do language compilers like C work? I mean, I understand the process but I don't understand how it letterly converts text into code. For instance, codes like...

it's implementation specific (the C standard doesn't specify how it should be done, just what the end result should be).
but..

Quote

> > char me; > int mydata; >
> How does it know where to declare the data?

Again, implementation specific.
The usual methods:
If the variables are global (or static), the compiler inserts a small bit of startup code that allocates the total number amount of global (and static) storage used, and assigns each variable an address in that space. During execution, when the variable is references, it is compiled into code which looks up the variable by adding the offset to the variable (which will be a constant value by the time is compiled) to the location where the global/static storage space was allocated (probably different every time the program is run).
If the variables are local, the compiler inserts code which offsets the stack pointer by the total amount of space used by global variables(the previous stack pointer value is saved). The variables are referenced by adding the offset to that variable in the local storage space (again, constant by the time the program is finished compiling) to the value of the stack pointer before it was incremented (changes each time you get to it). When the routine is finished, the stack pointer is reverted ot its original value.
The reason you add the number of bytes used to the value of the stack pointer is that, by doing that, you are making sure the bytes between the addresses pointed to by old and new stack pointers is unused. So you have quickly allocated a little batch of memory for variables that don't have to stick around after the function is finished. Handy, but you do run the risk of overflowing your stack if you allocate too much too often.

Quote

> How does it refer to those variables after that? Even in assembly, how does an assembler refer to a variable by just a label?

The compiler (or assembler) creates a symbol table as it goes through your code. When you declare a variable, it makes a note of its name and type, and what area of storage it's in (global or local space, or an explicitly delcared address). When it encounters a variable down the line, it checks it against the table to make sure it's been declared, and if so, whether it's legal and sensible to use that kind of variable in that context.
If so, it'll again check the table for the proper way to refer to that variable (offset from the stack pointer, or from the global space, or froma particular address) and insert the appropriate machine instructions.

Quote

> Also, how are functions converted? When you call a function in C, I know that it follows a list of instructions in it but how does the compiler set it up? Does the compiler convert the function into an assembly subroutine and the program merely jumps to that section of memory where the function is?

Uh... yes. (generally, sometimes the compiler will actually in-line the whole function if it's small, since the jump and return instructions add a little overhead that's more noticable in smaller functions. but other than that, yeah, it'll just jump to the address of the function.)

Quote

> Where is the function code even stored?

Any old place in the executable that the compiler sees fit. When you load the program, the OS allocates some space the size of the executable, copies that executable in that memory, and runs the program (it does a bit more than that, but it's the basiuc idea)

Mind you, I'm giving you oversimplifications, but I

Quote

> And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here.

I don't know how useful it is to anyone but the dev forum's been dead the past few days to who cares anyway?

Quote

> Mabye give enough interest for them to someday write they're own Z80 language compiler or something.

Could be.
I actually -did- write (and never finished) a compiler which compiled a subset of the C language into a native bytecode for a simple virtual machine I wrote (the program also ran the program after compiling). It was eventually intended to compile to native x86 code, with the idea that I'd stick it in a sound synthesizer/manipulation package I was writing, so the user could write their own modules within the program without a seperate compiler, and still get speedy performance from running machine-native code.
Like I said, I never finished, but I did get as far as flow control (if/else and for loops), correct operator precedence, variable definition, multiple data types, arrays, error checking, and more. And it's not all -that- big either, maybe I'll dig it up someday if the old hard drive's still got some life in it.

Quote

> It is seriously off-topic but I think we are all used to you accidentally posting off-topic stuff (until you'll get accidentally banned).
> I'm not againt such thread, but I suggest to buy yourself a book about compilers.

There are also articles online. And no, I don't remember where to find them.

Quote

> >Mabye give enough interest for them to someday write they're own Z80 language compiler or something.

> Bad point. Making a Z80 assembler is *very* different (and quite easy) than making a C compiler.

Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of.

Quote

> Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of.

Yes, technically it is.
But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS.
Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;)

Never mind.

Quote

> > Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of.

> Yes, technically it is.

Forget kind of. It is a development tool. More programmers would be open to develop SMS software in a high level language as opposed to plain assembly and you know this. If there were a Z80 C or any other high level language compiler for the Z80, I wouldn't do anything else but write games for the system. I personally dislike pure assembly when creating projects. Not because I don't know it but you have to setup so much bull before you can get down to the nitty-gritty. And even then you have to cooperate with the registers and the memory, etc. Besides, if someone created a C compiler for Z80 processors with SMS routines, are you not gunna post it in the Tools section of here because it's "Technically Off-Topic?"

Quote

> But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS.
> Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;)

Zoop, I love ya. I love this site. I love everything that you've done with SMS emulation so far. But that is the most ignorant thing I've ever heard you say. And many times the mean things you say make sense later on but this like a wild swing in the majors. Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games. Just because a game was written in a high level language does not mean it sucks. And just because a game sucks doesn't mean it was written in a high level language.

Sheesh, man. I guess I won't post at all. Just respond to other people's stuff.

Chris :o|

Well, atleast I have a better general idea on the whole process. I guess I'll go browsing the web or some university homepages for stuff on compilers.

Chris :o)

Quote

> > > Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of.

> > Yes, technically it is.

> Forget kind of. It is a development tool. More programmers would be open to develop SMS software in a high level language as opposed to plain assembly and you know this. If there were a Z80 C or any other high level language compiler for the Z80, I wouldn't do anything else but write games for the system.

Well, first let me say there are z80 C compilers out there.
One of them is ZCC, which I have completely lost track of. It would probably need to be overhauled substantially to support the z80 memory model, and of course there are no SMS libraries, so you'd either have to muck around with registers and all, or write some libraries to obfuscate all the nuts and bolts.
There's also a C compiler for Gameboy which may or may not be based on ZCC. Nobody really uses it for much more than doinking around, i -think-.
Go crawl around subport.org if you want to find anything about that. I couldn't find the c compiler listed as a seperate file, but I tihkn it may be part of one of those 'tool kits' listed in the tools section.

Quote

> I personally dislike pure assembly when creating projects. Not because I don't know it but you have to setup so much bull before you can get down to the nitty-gritty.

Not all that much, but it reminds me of a little project I was going to work on.
I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc.
Might just do that.

Quote

> And even then you have to cooperate with the registers and the memory, etc.

Yes, well, that's part of the fun, you see? I rather like scraping my skin against the hardware so much, to be aware of the limits of the machine and try to squeeze as much out of it asI can (not that I have been doing that with tetracycline, but I have plans. Yes, don't we all).

Quote

> > But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS.
> > Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;)

> Zoop, I love ya. I love this site. I love everything that you've done with SMS emulation so far. But that is the most ignorant thing I've ever heard you say.

(acid boils in stomach)
Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"?
God, that brought me back to high school: "You like that new Snoop Dogg album?" "Er, no, I don't listen to rap." "Whut? Why's you so ignorant?"

Quote

> And many times the mean things you say make sense later on but this like a wild swing in the majors.

> Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games.

I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..)
In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used.
I don't see much of that in later sega games.
As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible.
Trust me, people who wrote z80 code for a living could write these sorts of gmes in pure assembly. Back in the day nearly every commercial game (action oriented at least) was written in assembly, be it for c64's, atari 8-bits, amigas, st's, or pc's (to a lesser degree I think).

Quote

> Just because a game was written in a high level language does not mean it sucks.

That is an exaggeration, I admit.
I still question the value of a c compiler for the sms.
The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it.
Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that.
Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that.
A Z80 C compiler might be good for some simpler games (maybe like pit pot) but you'll hit the wall pretty quick on an sms.

Quote

>And just because a game sucks doesn't mean it was written in a high level language.

He never even said that.
There's the classic logical fallacy for you:
Chris is a human.
Humans are primates.
Shit throwing monkeys are primates.
Chris is a shit throwing monkey.

Quote

> Not all that much, but it reminds me of a little project I was going to work on.
> I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc.
> Might just do that.

I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly.

Quote

> (acid boils in stomach)
> Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"?

Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op

Quote

> God, that brought me back to high school: "You like that new Snoop Dogg album?" "Er, no, I don't listen to rap." "Whut? Why's you so ignorant?"

Exactly. Btw, might I add that Chronic 2001 (Dr. Dre's latest
album) is tight :o)!!!

Quote

> > Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games.

> I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..)
> In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used.
> I don't see much of that in later sega games.

Well, I'd wager my collection (measly 17), my Genesis collection (11), my Dreamcast collection (5), and everything else I own but there's no use. No matter how much you examine the games with a debugger no one will know exactly which games came from high level. You can suspect though.

Quote

> As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible.

True, but it's not impossible. What if Sega had Asm/C compilers like the ones today? Create the skeleton of the program in a high level language and the details like graphics and priorties in Asm.

Quote

> Trust me, people who wrote z80 code for a living could write these sorts of gmes in pure assembly. Back in the day nearly every commercial game (action oriented at least) was written in assembly, be it for c64's, atari 8-bits, amigas, st's, or pc's (to a lesser degree I think).

Alright, I'll trust you. Only cause I was like an infant during the early '80's.

Quote

> > Just because a game was written in a high level language does not mean it sucks.

> That is an exaggeration, I admit.
> I still question the value of a c compiler for the sms.
> The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it.

Yeah, all the docs clearly state the importance of Vblank. But, mabye they had libraries that automatically handled graphics inserts and such. Like the function would wait until vblank until updating the video writes.

Quote

> Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that.

> Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that.

But that kinda depends on the person. I try to avoid that stuff with shifts and macros (the stuff you guys taught me). I know what you mean. It's so easy to use a multiply function as opposed to calculating shifts to match.

Quote

> A Z80 C compiler might be good for some simpler games (maybe like pit pot) but you'll hit the wall pretty quick on an sms.

I think it all depends on the libraries as opposed to the language. Even thought the software would've been written in a high level language, many of the time extensive routines would be handled by the library.

Quote

> >And just because a game sucks doesn't mean it was written in a high level language.

> He never even said that.
> There's the classic logical fallacy for you:
> Chris is a human.
> Humans are primates.
> Shit throwing monkeys are primates.
> Chris is a shit throwing monkey.

*munching on banana* I guess that makes us all shit throwing monkeys, eh? Man, whatever.

Chris :o|

Since when was being a good programmer equivalent to the status of Demigod? Why do you (Zoop) feel that, because of your astounding level of coding knowledge, you have automatic permission to shove your foot into the ass of anyone who isn't as advanced or experienced as you? What I see here is a novice with a good cause who is interested in the Sega 8-bit dev scene but doesn't quite have what it takes when it comes to coding. But when he asks for help, you hold his inexperience against him, claiming that all he knows is worth shit. Are you so self-righteous with your own programming know-how that you can't get off your high horse long enough to help out a novice? And what about you, Heliophobe? Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope. You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies? It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation.

Sincerely,

Bill S. Preston, Esq.

Quote

> Since when was being a good programmer equivalent to the status of Demigod? Why do you (Zoop) feel that, because of your astounding level of coding knowledge, you have automatic permission to shove your foot into the ass of anyone who isn't as advanced or experienced as you? What I see here is a novice with a good cause who is interested in the Sega 8-bit dev scene but doesn't quite have what it takes when it comes to coding. But when he asks for help, you hold his inexperience against him, claiming that all he knows is worth shit. Are you so self-righteous with your own programming know-how that you can't get off your high horse long enough to help out a novice? And what about you, Heliophobe? Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope. You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies? It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation.

I can't believe this. For once, somebody understands and is one my side. I never look at things around here like that but it has been fustrating has hell to talk about anything around here lately. Jesus Crist man. I've been posting some interesting things. The KSS format which is still practically unheard of. SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time), nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else.

Chris :o|

I'm sorry if my answer to Chris sounded quite rude, but you should understand a bit that I'm supporting (that's the word) him bitching since 18 months, even if he almost never followed the rules we set there. A year ago he was telling us all about his sexual complexes on that same forum, and being totally frank I am a bit sick of his attitude. He posted offtopic stuff for months and for the first time he had something interesting to say (a month ago) he sent it to me by e-mail instead of posting on the forum. Let me point out you are new to this forum (at least it is the first message I read from you). Give yourself a few months reading Chris posts and you'll understand us a bit better.

But that doesn't mean I do not respect newbies or interested people which is plain wrong. Everytime there is someone asking a question if I can answer myself I will gladly answer.

Also keep in mind the real way to learn is not to ask questions and get an easy answer.
That's prolly why in 18 months Chris learned less in programming that my girlfriend did in one month.
And why in some cases I feel it's better not to give a profound answer to someone and let him learn for real and by himself, giving him only a hint.

Beside I do not consider myself as having an "astounding" level of programming. I'm learning a lot by reading other people answers right here.

Now if ever I offended anyone, I'm sorry.

Quote

> I can't believe this. For once, somebody understands and is one my side.

He is new to the forum, that's why :)

Quote

>The KSS format which is still practically unheard of.

You told us all about us then disappeared without posting any files (or sent them to me so I could post them), which lead to the usual fact that you doesn't finish what you're starting.

Quote

>SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time),

How lowsy are the VMUs is off-topic, as for SMS emulationon the dreamcast you just suggested the idea.
"Heh guys, what about a SMS emulator on the Playstation 2 ????"
That's another fine suggestion from me.

Quote

>nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else.

Thank you for the compliments to Nicolas, I'm sure he'll appreciate.
Yes maybe you'll get undirectly some respect if ever you could program something like that.
Undirectly because if you could finish such project, you'll have learned enough to be humble.

Quote

>> Not all that much, but it reminds me of a little project I was going to work on.
>> I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc.
>> Might just do that.
> I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly.

I though about such things quite a lot of times then abandonned, because as I pointed it out in my reply
to Bill, you wouldn't be learning correctly about the SMS if following such tutorial. The way to masterize
a language and a system is to learn by yourself from the very basis. Source code of full working programs
(such as Heliophobe's "boring ass" tetris clone) can be proven very useful in such cases, but surely not
tutorials.

Quote

>> (acid boils in stomach)
>> Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"?
> Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op

Which leaded you to the "Now, you've gone too far... ".

Quote

>> I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..)
>> In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used.
>> I don't see much of that in later sega games.
> Well, I'd wager my collection (measly 17), my Genesis collection (11), my Dreamcast collection (5), and everything else I own but there's no use. No matter how much you examine the games with a debugger no one will know exactly which games came from high level. You can suspect though.

I'm betting stricly nothing that 95% of the SMS games are made in pure assembly. It's easily noticeable wheter a game is made in assembly or not (and the Codemasters games I saw aren't).

As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance.

See how Fantastic Dizzy push all registers 3 or 4 times recursively in an interrupt routine and repeat instructions a billion time and you'll understand the difference.

Quote

>> As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible.
> True, but it's not impossible. What if Sega had Asm/C compilers like the ones today? Create the skeleton of the program in a high level language and the details like graphics and priorties in Asm.

On a simple system like the SMS, nothing is a detail, even the gameplay is directly related to the technical specs.

Quote

>> That is an exaggeration, I admit.
>> I still question the value of a c compiler for the sms.
>> The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it.

Sorry to push you again, but while I'm doing it I prefer to do everything at once and forget it in a few days:

Quote

> Yeah, all the docs clearly state the importance of Vblank.

That's exactly what I'm reproaching you: you are reading docs since 18 months and having made nothing you simply can't argue about such points, without experience. Then you complain because we don't answer to all your messages. :(

Quote

>> Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that.
>> Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that.
> But that kinda depends on the person. I try to avoid that stuff with shifts and macros (the stuff you guys taught me). I know what you mean. It's so easy to use a multiply function as opposed to calculating shifts to match.

Whenever you get used to it's not hard. I've been finding myself doing multiplication manually on the VMS even if the CPU has a multiplication opcode.

Quote

> > I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly.

> I though about such things quite a lot of times then abandonned, because as I pointed it out in my reply
> to Bill, you wouldn't be learning correctly about the SMS if following such tutorial. The way to masterize
> a language and a system is to learn by yourself from the very basis. Source code of full working programs
> (such as Heliophobe's "boring ass" tetris clone) can be proven very useful in such cases, but surely not
> tutorials.

I'd have to disagree with you there. I think a tutorial covering the basics of sms coding, and some common pitfalls (like how I didn't realize you had to read the data port to satisfy the IRQ's, which fucked me up for a good month) could be a good ice-breaker for someone with a bit of programming experience (hopefully with some assembly).
But, I forgot to write this part in my earlier message, as I was trying to get out the door, I would -not- make it into a tutorial about how to program the z80, or program in assembly in general for that matter. You'd have to supplement it with a guide on z80.

Quote

> >> (acid boils in stomach)
> > Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op
> Which leaded you to the "Now, you've gone too far... ".

See, as I said it's pet peeve of mine, in high school everyone used 'ignorant' to mean stupid, foolish, close minded, to express a difference of opinion, etc. But if somebody demonstrated a lack of knowledge, they never used the word 'ignorant', they just said "You just don't know shit."

Quote

> As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance.

Well I understand, but it doesn't use the shadow regs anywhere else, and you'd think you'd want a fairly slim hblank handler. (BTw the games I'm referring to are my hero and transbot)

Quote

> See how Fantastic Dizzy push all registers 3 or 4 times recursively in an interrupt routine and repeat instructions a billion time and you'll understand the difference.

ld a,($c020)
add a,10
ld ($c020),a
ld a,($c020)
sub 10
ld ($c020),a
...

Quote

> On a simple system like the SMS, nothing is a detail, even the gameplay is directly related to the technical specs.

exactly the thing I've been learning in my sms exploits.

Quote

> > Yeah, all the docs clearly state the importance of Vblank.
> That's exactly what I'm reproaching you: you are reading docs since 18 months and having made nothing you simply can't argue about such points, without experience. Then you complain because we don't answer to all your messages. :(

That is true.

Quote

> Whenever you get used to it's not hard. I've been finding myself doing multiplication manually on the VMS even if the CPU has a multiplication opcode.

It's the 'arbitrary' multiplication that's the killer, though (neither is constant).

Do like I'm doing. Instead of bickering back and fourth and arguing your good points, just be quiet and work on something. Even if your doc doesn't come out right or whatever the case may be, just work on it.

Besides, I gotta work my ass off or I'm banned from this site.

Chris :o)

Quote

> Besides, I gotta work my ass off or I'm banned from this site.

I'm not gonna ban you, last time I did ban someone it was on the main forum because he posted porn on a message ^_^
And that was montttthhhhs ago.

Quote

>> As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance.
> Well I understand, but it doesn't use the shadow regs anywhere else, and you'd think you'd want a fairly slim hblank handler. (BTw the games I'm referring to are my hero and transbot)

To be honnest I never had the idea to use those shadow registers myself before you or Eric (I don't remember) suggested it in a post.

Having checked Transbot and MyHero, they more seems like quickly and not-so-good programmed games than anything else.
I guess HBlank optimisation is not their main preoccupation. Transbot use mid-screen scrolling once, though.

They are both some of the very first SMS games, made very quickly from the arcade version to release something taking advantage of the Mark3 possibilities when being released.
Still a questionnable point, though.

Quote

> > I can't believe this. For once, somebody understands and is one my side.

See, actually, I do understand. I understand all too well what your bad habits are,

Quote

> >The KSS format which is still practically unheard of.

> You told us all about us then disappeared without posting any files (or sent them to me so I could post them), which lead to the usual fact that you doesn't finish what you're starting.

> >SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time),

> How lowsy are the VMUs is off-topic, as for SMS emulationon the dreamcast you just suggested the idea.
> "Heh guys, what about a SMS emulator on the Playstation 2 ????"
> That's another fine suggestion from me.

> >nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else.

Well, as I once stated, Tetracycline was an exercise in low level programming, not game design. I find the game itself to be rather boring (I burned out on tetris long ago), developing it was the real game for me.
Well, anyhow, I think I've exhausted all the glory that Tetracycline is going to give me, unless I start working on it again. So far I've turned out to be a one hit wonder.

Quote

> Thank you for the compliments to Nicolas, I'm sure he'll appreciate.

Who?
Oh, yeah.

Quote

> Undirectly because if you could finish such project, you'll have learned enough to be humble.

Yeah, you'll be humble, because you'll realize you can never be as great a coder as The Fabulous Heliophobe, Undisputed Z80 Champion!
(the smiley would go here).

Quote

> And what about you, Heliophobe?

mm?

Quote

> Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope.

Yeah, I'm just Zoop's little toady, aren't I?
Chris reminds me too much of other Chris's I know (and I'm not just using the name as a generic term, all the Chris's I've know have been like this.). Common traits:

-Makes lots of lofty plana (typical Archtypical Chris plans: Single handedly writing a new operating system, because 'Windows is stupid.' Writing a 'good' emulator for his favorite system, because the other emulators available are too slow due to their lousy programmers)
-Despite minimal coding experience, is convinced they can accomplish their outrageously complicated task easily, because he's smarter than most. And reads books. (similar arrogance makes them want to reinvent every wheel, because nobody else's code could possibly be good enough).
-Generally is shown to be ignorant of some very basic coding fundamentals when actually pressed to reveal some code.
-When presented with a challenge, gives up easily. Finds new project.
-And, has a complete lack of tact.

It's the special combination of arrogance, laziness, and social incompitence that makes one of these Chris's.

So why do I oscillate between helpful and rude?
Because I've noticed that this type does in fact benefit from the occasional boot in the ass. Plus, he gets on my nerves after a while.

Quote

>You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies?

Because millions of people buy them?

Quote

>It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation.

Holy shit, Zoop, we're the establishment!

Author	Message
Consolemu Guest	Language Compilers (Preferably C) Posted: Sun Aug 20, 2000 4:20 am
Consolemu Guest	How do language compilers like C work? I mean, I understand the process but I don't understand how it letterly converts text into code. For instance, codes like... `char me; int mydata;` How does it know where to declare the data? How does it refer to those variables after that? Even in assembly, how does an assembler refer to a variable by just a label? Also, how are functions converted? When you call a function in C, I know that it follows a list of instructions in it but how does the compiler set it up? Does the compiler convert the function into an assembly subroutine and the program merely jumps to that section of memory where the function is? Where is the function code even stored? And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here. Mabye give enough interest for them to someday write they're own Z80 language compiler or something. Chris :o)

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sun Aug 20, 2000 9:07 am
	Quote > And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here. It is seriously off-topic but I think we are all used to you accidentally posting off-topic stuff (until you'll get accidentally banned). I'm not againt such thread, but I suggest to buy yourself a book about compilers. Quote >Mabye give enough interest for them to someday write they're own Z80 language compiler or something. Bad point. Making a Z80 assembler is very different (and quite easy) than making a C compiler.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Sun Aug 20, 2000 9:37 am
	Quote > How do language compilers like C work? I mean, I understand the process but I don't understand how it letterly converts text into code. For instance, codes like... it's implementation specific (the C standard doesn't specify how it should be done, just what the end result should be). but.. Quote > `> char me; > int mydata; >` > How does it know where to declare the data? Again, implementation specific. The usual methods: If the variables are global (or static), the compiler inserts a small bit of startup code that allocates the total number amount of global (and static) storage used, and assigns each variable an address in that space. During execution, when the variable is references, it is compiled into code which looks up the variable by adding the offset to the variable (which will be a constant value by the time is compiled) to the location where the global/static storage space was allocated (probably different every time the program is run). If the variables are local, the compiler inserts code which offsets the stack pointer by the total amount of space used by global variables(the previous stack pointer value is saved). The variables are referenced by adding the offset to that variable in the local storage space (again, constant by the time the program is finished compiling) to the value of the stack pointer before it was incremented (changes each time you get to it). When the routine is finished, the stack pointer is reverted ot its original value. The reason you add the number of bytes used to the value of the stack pointer is that, by doing that, you are making sure the bytes between the addresses pointed to by old and new stack pointers is unused. So you have quickly allocated a little batch of memory for variables that don't have to stick around after the function is finished. Handy, but you do run the risk of overflowing your stack if you allocate too much too often. Quote > How does it refer to those variables after that? Even in assembly, how does an assembler refer to a variable by just a label? The compiler (or assembler) creates a symbol table as it goes through your code. When you declare a variable, it makes a note of its name and type, and what area of storage it's in (global or local space, or an explicitly delcared address). When it encounters a variable down the line, it checks it against the table to make sure it's been declared, and if so, whether it's legal and sensible to use that kind of variable in that context. If so, it'll again check the table for the proper way to refer to that variable (offset from the stack pointer, or from the global space, or froma particular address) and insert the appropriate machine instructions. Quote > Also, how are functions converted? When you call a function in C, I know that it follows a list of instructions in it but how does the compiler set it up? Does the compiler convert the function into an assembly subroutine and the program merely jumps to that section of memory where the function is? Uh... yes. (generally, sometimes the compiler will actually in-line the whole function if it's small, since the jump and return instructions add a little overhead that's more noticable in smaller functions. but other than that, yeah, it'll just jump to the address of the function.) Quote > Where is the function code even stored? Any old place in the executable that the compiler sees fit. When you load the program, the OS allocates some space the size of the executable, copies that executable in that memory, and runs the program (it does a bit more than that, but it's the basiuc idea) Mind you, I'm giving you oversimplifications, but I Quote > And I'm sorry if you think this is off topic but I think it's interesting and it could pose benefit for anyone who visits here. I don't know how useful it is to anyone but the dev forum's been dead the past few days to who cares anyway? Quote > Mabye give enough interest for them to someday write they're own Z80 language compiler or something. Could be. I actually -did- write (and never finished) a compiler which compiled a subset of the C language into a native bytecode for a simple virtual machine I wrote (the program also ran the program after compiling). It was eventually intended to compile to native x86 code, with the idea that I'd stick it in a sound synthesizer/manipulation package I was writing, so the user could write their own modules within the program without a seperate compiler, and still get speedy performance from running machine-native code. Like I said, I never finished, but I did get as far as flow control (if/else and for loops), correct operator precedence, variable definition, multiple data types, arrays, error checking, and more. And it's not all -that- big either, maybe I'll dig it up someday if the old hard drive's still got some life in it.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Sun Aug 20, 2000 9:40 am
	Quote > It is seriously off-topic but I think we are all used to you accidentally posting off-topic stuff (until you'll get accidentally banned). > I'm not againt such thread, but I suggest to buy yourself a book about compilers. There are also articles online. And no, I don't remember where to find them. Quote > >Mabye give enough interest for them to someday write they're own Z80 language compiler or something. > Bad point. Making a Z80 assembler is very different (and quite easy) than making a C compiler. Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sun Aug 20, 2000 11:21 am
	Quote > Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of. Yes, technically it is. But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS. Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;) Never mind.

Consolemu Guest	Now, you've gone too far... Posted: Sun Aug 20, 2000 3:22 pm
Consolemu Guest	Quote > > Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of. > Yes, technically it is. Forget kind of. It is a development tool. More programmers would be open to develop SMS software in a high level language as opposed to plain assembly and you know this. If there were a Z80 C or any other high level language compiler for the Z80, I wouldn't do anything else but write games for the system. I personally dislike pure assembly when creating projects. Not because I don't know it but you have to setup so much bull before you can get down to the nitty-gritty. And even then you have to cooperate with the registers and the memory, etc. Besides, if someone created a C compiler for Z80 processors with SMS routines, are you not gunna post it in the Tools section of here because it's "Technically Off-Topic?" Quote > But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS. > Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;) Zoop, I love ya. I love this site. I love everything that you've done with SMS emulation so far. But that is the most ignorant thing I've ever heard you say. And many times the mean things you say make sense later on but this like a wild swing in the majors. Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games. Just because a game was written in a high level language does not mean it sucks. And just because a game sucks doesn't mean it was written in a high level language. Sheesh, man. I guess I won't post at all. Just respond to other people's stuff. Chris :o\|

Consolemu Guest	Thanks a lot Posted: Sun Aug 20, 2000 3:24 pm
Consolemu Guest	Well, atleast I have a better general idea on the whole process. I guess I'll go browsing the web or some university homepages for stuff on compilers. Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Zoop vs. Consolemu Posted: Sun Aug 20, 2000 8:18 pm
	Quote > > > Weeeeelll, I think he means, writing a C (or other high level language) compiler for z80. Which actually is in the ballpark of being on topic. Kind of. > > Yes, technically it is. > Forget kind of. It is a development tool. More programmers would be open to develop SMS software in a high level language as opposed to plain assembly and you know this. If there were a Z80 C or any other high level language compiler for the Z80, I wouldn't do anything else but write games for the system. Well, first let me say there are z80 C compilers out there. One of them is ZCC, which I have completely lost track of. It would probably need to be overhauled substantially to support the z80 memory model, and of course there are no SMS libraries, so you'd either have to muck around with registers and all, or write some libraries to obfuscate all the nuts and bolts. There's also a C compiler for Gameboy which may or may not be based on ZCC. Nobody really uses it for much more than doinking around, i -think-. Go crawl around subport.org if you want to find anything about that. I couldn't find the c compiler listed as a seperate file, but I tihkn it may be part of one of those 'tool kits' listed in the tools section. Quote > I personally dislike pure assembly when creating projects. Not because I don't know it but you have to setup so much bull before you can get down to the nitty-gritty. Not all that much, but it reminds me of a little project I was going to work on. I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc. Might just do that. Quote > And even then you have to cooperate with the registers and the memory, etc. Yes, well, that's part of the fun, you see? I rather like scraping my skin against the hardware so much, to be aware of the limits of the machine and try to squeeze as much out of it asI can (not that I have been doing that with tetracycline, but I have plans. Yes, don't we all). Quote > > But thinking about it, I don't think it would be worth anything to program in a high level language for the SMS. > > Reminding me Codemasters games seems to have been made with a high level language. Go figures why they sucks ;) > Zoop, I love ya. I love this site. I love everything that you've done with SMS emulation so far. But that is the most ignorant thing I've ever heard you say. (acid boils in stomach) Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"? God, that brought me back to high school: "You like that new Snoop Dogg album?" "Er, no, I don't listen to rap." "Whut? Why's you so ignorant?" Quote > And many times the mean things you say make sense later on but this like a wild swing in the majors. > Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games. I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..) In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used. I don't see much of that in later sega games. As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible. Trust me, people who wrote z80 code for a living could write these sorts of gmes in pure assembly. Back in the day nearly every commercial game (action oriented at least) was written in assembly, be it for c64's, atari 8-bits, amigas, st's, or pc's (to a lesser degree I think). Quote > Just because a game was written in a high level language does not mean it sucks. That is an exaggeration, I admit. I still question the value of a c compiler for the sms. The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it. Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that. Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that. A Z80 C compiler might be good for some simpler games (maybe like pit pot) but you'll hit the wall pretty quick on an sms. Quote >And just because a game sucks doesn't mean it was written in a high level language. He never even said that. There's the classic logical fallacy for you: Chris is a human. Humans are primates. Shit throwing monkeys are primates. Chris is a shit throwing monkey.

Consolemu Guest	Ohh, Hooh, Ahh Ahhck! Posted: Sun Aug 20, 2000 9:45 pm
Consolemu Guest	Quote > Not all that much, but it reminds me of a little project I was going to work on. > I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc. > Might just do that. I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly. Quote > (acid boils in stomach) > Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"? Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op Quote > God, that brought me back to high school: "You like that new Snoop Dogg album?" "Er, no, I don't listen to rap." "Whut? Why's you so ignorant?" Exactly. Btw, might I add that Chronic 2001 (Dr. Dre's latest album) is tight :o)!!! Quote > > Do you seriously think Sega wrote all of their games in assembly? They may have in the early days but I seriously think after '87 and later they created high level language tools for developing games. > I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..) > In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used. > I don't see much of that in later sega games. Well, I'd wager my collection (measly 17), my Genesis collection (11), my Dreamcast collection (5), and everything else I own but there's no use. No matter how much you examine the games with a debugger no one will know exactly which games came from high level. You can suspect though. Quote > As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible. True, but it's not impossible. What if Sega had Asm/C compilers like the ones today? Create the skeleton of the program in a high level language and the details like graphics and priorties in Asm. Quote > Trust me, people who wrote z80 code for a living could write these sorts of gmes in pure assembly. Back in the day nearly every commercial game (action oriented at least) was written in assembly, be it for c64's, atari 8-bits, amigas, st's, or pc's (to a lesser degree I think). Alright, I'll trust you. Only cause I was like an infant during the early '80's. Quote > > Just because a game was written in a high level language does not mean it sucks. > That is an exaggeration, I admit. > I still question the value of a c compiler for the sms. > The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it. Yeah, all the docs clearly state the importance of Vblank. But, mabye they had libraries that automatically handled graphics inserts and such. Like the function would wait until vblank until updating the video writes. Quote > Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that. > Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that. But that kinda depends on the person. I try to avoid that stuff with shifts and macros (the stuff you guys taught me). I know what you mean. It's so easy to use a multiply function as opposed to calculating shifts to match. Quote > A Z80 C compiler might be good for some simpler games (maybe like pit pot) but you'll hit the wall pretty quick on an sms. I think it all depends on the libraries as opposed to the language. Even thought the software would've been written in a high level language, many of the time extensive routines would be handled by the library. Quote > >And just because a game sucks doesn't mean it was written in a high level language. > He never even said that. > There's the classic logical fallacy for you: > Chris is a human. > Humans are primates. > Shit throwing monkeys are primates. > Chris is a shit throwing monkey. munching on banana I guess that makes us all shit throwing monkeys, eh? Man, whatever. Chris :o\|

Bill S. Preston, Esq. Guest	Re: Ohh, Hooh, Ahh Ahhck! Posted: Sun Aug 20, 2000 10:26 pm
Bill S. Preston, Esq. Guest	Since when was being a good programmer equivalent to the status of Demigod? Why do you (Zoop) feel that, because of your astounding level of coding knowledge, you have automatic permission to shove your foot into the ass of anyone who isn't as advanced or experienced as you? What I see here is a novice with a good cause who is interested in the Sega 8-bit dev scene but doesn't quite have what it takes when it comes to coding. But when he asks for help, you hold his inexperience against him, claiming that all he knows is worth shit. Are you so self-righteous with your own programming know-how that you can't get off your high horse long enough to help out a novice? And what about you, Heliophobe? Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope. You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies? It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation. Sincerely, Bill S. Preston, Esq.

Consolemu Guest	Well, I'll be damn! Posted: Sun Aug 20, 2000 10:44 pm
Consolemu Guest	Quote > Since when was being a good programmer equivalent to the status of Demigod? Why do you (Zoop) feel that, because of your astounding level of coding knowledge, you have automatic permission to shove your foot into the ass of anyone who isn't as advanced or experienced as you? What I see here is a novice with a good cause who is interested in the Sega 8-bit dev scene but doesn't quite have what it takes when it comes to coding. But when he asks for help, you hold his inexperience against him, claiming that all he knows is worth shit. Are you so self-righteous with your own programming know-how that you can't get off your high horse long enough to help out a novice? And what about you, Heliophobe? Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope. You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies? It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation. I can't believe this. For once, somebody understands and is one my side. I never look at things around here like that but it has been fustrating has hell to talk about anything around here lately. Jesus Crist man. I've been posting some interesting things. The KSS format which is still practically unheard of. SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time), nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else. Chris :o\|

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Ohh, Hooh, Ahh Ahhck! Posted: Sun Aug 20, 2000 11:15 pm
	I'm sorry if my answer to Chris sounded quite rude, but you should understand a bit that I'm supporting (that's the word) him bitching since 18 months, even if he almost never followed the rules we set there. A year ago he was telling us all about his sexual complexes on that same forum, and being totally frank I am a bit sick of his attitude. He posted offtopic stuff for months and for the first time he had something interesting to say (a month ago) he sent it to me by e-mail instead of posting on the forum. Let me point out you are new to this forum (at least it is the first message I read from you). Give yourself a few months reading Chris posts and you'll understand us a bit better. But that doesn't mean I do not respect newbies or interested people which is plain wrong. Everytime there is someone asking a question if I can answer myself I will gladly answer. Also keep in mind the real way to learn is not to ask questions and get an easy answer. That's prolly why in 18 months Chris learned less in programming that my girlfriend did in one month. And why in some cases I feel it's better not to give a profound answer to someone and let him learn for real and by himself, giving him only a hint. Beside I do not consider myself as having an "astounding" level of programming. I'm learning a lot by reading other people answers right here. Now if ever I offended anyone, I'm sorry.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Well, you'll be damn! Posted: Sun Aug 20, 2000 11:19 pm
	Quote > I can't believe this. For once, somebody understands and is one my side. He is new to the forum, that's why :) Quote >The KSS format which is still practically unheard of. You told us all about us then disappeared without posting any files (or sent them to me so I could post them), which lead to the usual fact that you doesn't finish what you're starting. Quote >SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time), How lowsy are the VMUs is off-topic, as for SMS emulationon the dreamcast you just suggested the idea. "Heh guys, what about a SMS emulator on the Playstation 2 ????" That's another fine suggestion from me. Quote >nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else. Thank you for the compliments to Nicolas, I'm sure he'll appreciate. Yes maybe you'll get undirectly some respect if ever you could program something like that. Undirectly because if you could finish such project, you'll have learned enough to be humble.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Various answers Posted: Sun Aug 20, 2000 11:32 pm
	Quote >> Not all that much, but it reminds me of a little project I was going to work on. >> I was thinking it might be a good idea to write a short guide outlining the very basics of an SMS program, taking you step by step from a blank source file to a 32k basic program that supports a static screen display. Further installments could add scrolling, sprites, sound, etc. >> Might just do that. > I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly. I though about such things quite a lot of times then abandonned, because as I pointed it out in my reply to Bill, you wouldn't be learning correctly about the SMS if following such tutorial. The way to masterize a language and a system is to learn by yourself from the very basis. Source code of full working programs (such as Heliophobe's "boring ass" tetris clone) can be proven very useful in such cases, but surely not tutorials. Quote >> (acid boils in stomach) >> Wow, you just brought up one of my biggest pet peeves. "Ignorant" means not knowledgable. Not quite the word for Zoop here. Maybe you mean "close minded"? > Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op Which leaded you to the "Now, you've gone too far... ". Quote >> I'd bet my entire SMS collection that you are dead wrong. (it's only 7 games at stake but still..) >> In fact, it's the earlier games that exhibit signs of being written in a high level language, or at least inexperienced z80 coders using development libraries. You see a lot of glaringly inefficent things in old sms games like the tendancy to push all z80 registers and shadow registers onto the stack for every interrupt (including h-interrupts), despite the fact that the shadow registers are never used. >> I don't see much of that in later sega games. > Well, I'd wager my collection (measly 17), my Genesis collection (11), my Dreamcast collection (5), and everything else I own but there's no use. No matter how much you examine the games with a debugger no one will know exactly which games came from high level. You can suspect though. I'm betting stricly nothing that 95% of the SMS games are made in pure assembly. It's easily noticeable wheter a game is made in assembly or not (and the Codemasters games I saw aren't). As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance. See how Fantastic Dizzy push all registers 3 or 4 times recursively in an interrupt routine and repeat instructions a billion time and you'll understand the difference. Quote >> As games pushed the limits further it became more and more necessary to manage the resourced of the sms as closely as possible (resources here being ram, rom space,vram, sprites, and of course clock cycles). High level abstraction makes this difficult if not impossible. > True, but it's not impossible. What if Sega had Asm/C compilers like the ones today? Create the skeleton of the program in a high level language and the details like graphics and priorties in Asm. On a simple system like the SMS, nothing is a detail, even the gameplay is directly related to the technical specs. Quote >> That is an exaggeration, I admit. >> I still question the value of a c compiler for the sms. >> The sms is a limited machine, and when you take one step back from the hardware you lose the awareness of its limits. For one thing, vblank time is very precious, as all of your tile, sprite, and tile map updates need to be done is this tiny window. You need to be very very aware of how much you can change, and how little messing around can be done in that time. Using a high level language you will not get as good an idea what's going on in there, and how much the impact of each line of code has in the number of cycles elapsed. Plus, when you want to profile it in the debugger you'll be looking at machine language disassembly, and it will be unfamiliar to you because you didn't write it. Sorry to push you again, but while I'm doing it I prefer to do everything at once and forget it in a few days: Quote > Yeah, all the docs clearly state the importance of Vblank. That's exactly what I'm reproaching you: you are reading docs since 18 months and having made nothing you simply can't argue about such points, without experience. Then you complain because we don't answer to all your messages. :( Quote >> Even little things like in tetracycline when you complete a row and the whole puzzle contracts 'immediately' are much trickier than it looks. That eats up a lot of vblank time redrawing the tile map like that. >> Also, high level languages encourage you to do things like arbitrary multiplcation and division, which is -dog- slow on a z80 since there are no instructions for that. > But that kinda depends on the person. I try to avoid that stuff with shifts and macros (the stuff you guys taught me). I know what you mean. It's so easy to use a multiply function as opposed to calculating shifts to match. Whenever you get used to it's not hard. I've been finding myself doing multiplication manually on the VMS even if the CPU has a multiplication opcode.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Various answers Posted: Mon Aug 21, 2000 3:22 am
	Quote > > I'm personally begging you to do that. That's exactly what every SMS programmer would like to have in getting started writing stuff in assembly. > I though about such things quite a lot of times then abandonned, because as I pointed it out in my reply > to Bill, you wouldn't be learning correctly about the SMS if following such tutorial. The way to masterize > a language and a system is to learn by yourself from the very basis. Source code of full working programs > (such as Heliophobe's "boring ass" tetris clone) can be proven very useful in such cases, but surely not > tutorials. I'd have to disagree with you there. I think a tutorial covering the basics of sms coding, and some common pitfalls (like how I didn't realize you had to read the data port to satisfy the IRQ's, which fucked me up for a good month) could be a good ice-breaker for someone with a bit of programming experience (hopefully with some assembly). But, I forgot to write this part in my earlier message, as I was trying to get out the door, I would -not- make it into a tutorial about how to program the z80, or program in assembly in general for that matter. You'd have to supplement it with a guide on z80. Quote > >> (acid boils in stomach) > > Fine. "Close Minded". Either way, he said the broad, exagerated statement first. Nah! :op > Which leaded you to the "Now, you've gone too far... ". See, as I said it's pet peeve of mine, in high school everyone used 'ignorant' to mean stupid, foolish, close minded, to express a difference of opinion, etc. But if somebody demonstrated a lack of knowledge, they never used the word 'ignorant', they just said "You just don't know shit." Quote > As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance. Well I understand, but it doesn't use the shadow regs anywhere else, and you'd think you'd want a fairly slim hblank handler. (BTw the games I'm referring to are my hero and transbot) Quote > See how Fantastic Dizzy push all registers 3 or 4 times recursively in an interrupt routine and repeat instructions a billion time and you'll understand the difference. ld a,($c020) add a,10 ld ($c020),a ld a,($c020) sub 10 ld ($c020),a ... Quote > On a simple system like the SMS, nothing is a detail, even the gameplay is directly related to the technical specs. exactly the thing I've been learning in my sms exploits. Quote > > Yeah, all the docs clearly state the importance of Vblank. > That's exactly what I'm reproaching you: you are reading docs since 18 months and having made nothing you simply can't argue about such points, without experience. Then you complain because we don't answer to all your messages. :( That is true. Quote > Whenever you get used to it's not hard. I've been finding myself doing multiplication manually on the VMS even if the CPU has a multiplication opcode. It's the 'arbitrary' multiplication that's the killer, though (neither is constant).

Consolemu Guest	On SMS Tutorials Posted: Mon Aug 21, 2000 3:49 am
Consolemu Guest	Do like I'm doing. Instead of bickering back and fourth and arguing your good points, just be quiet and work on something. Even if your doc doesn't come out right or whatever the case may be, just work on it. Besides, I gotta work my ass off or I'm banned from this site. Chris :o)

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Banning Posted: Mon Aug 21, 2000 7:00 am
	Quote > Besides, I gotta work my ass off or I'm banned from this site. I'm not gonna ban you, last time I did ban someone it was on the main forum because he posted porn on a message ^_^ And that was montttthhhhs ago.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Games made using highlevel languages? Posted: Mon Aug 21, 2000 7:06 am
	Quote >> As for pushing all registers, etc, whenever a program get bigs it is more confortable not to take care of the multiple call sources of a function and save every registers, that's usually not a big loss of performance. > Well I understand, but it doesn't use the shadow regs anywhere else, and you'd think you'd want a fairly slim hblank handler. (BTw the games I'm referring to are my hero and transbot) To be honnest I never had the idea to use those shadow registers myself before you or Eric (I don't remember) suggested it in a post. Having checked Transbot and MyHero, they more seems like quickly and not-so-good programmed games than anything else. I guess HBlank optimisation is not their main preoccupation. Transbot use mid-screen scrolling once, though. They are both some of the very first SMS games, made very quickly from the arcade version to release something taking advantage of the Mark3 possibilities when being released. Still a questionnable point, though.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	I be done seen 'bout everythin', when I see an elephant fly. Posted: Mon Aug 21, 2000 4:44 pm
	Quote > > I can't believe this. For once, somebody understands and is one my side. See, actually, I do understand. I understand all too well what your bad habits are, Quote > >The KSS format which is still practically unheard of. > You told us all about us then disappeared without posting any files (or sent them to me so I could post them), which lead to the usual fact that you doesn't finish what you're starting. > >SMS emulation on the dreamcast (I didn't know how lowsy the VMUs were at the time), > How lowsy are the VMUs is off-topic, as for SMS emulationon the dreamcast you just suggested the idea. > "Heh guys, what about a SMS emulator on the Playstation 2 ????" > That's another fine suggestion from me. > >nothing I do or talk about is ever good enough or on topic. I guess I'll gain some respect when I create a boring ass Tetris clone like everyone else. Well, as I once stated, Tetracycline was an exercise in low level programming, not game design. I find the game itself to be rather boring (I burned out on tetris long ago), developing it was the real game for me. Well, anyhow, I think I've exhausted all the glory that Tetracycline is going to give me, unless I start working on it again. So far I've turned out to be a one hit wonder. Quote > Thank you for the compliments to Nicolas, I'm sure he'll appreciate. Who? Oh, yeah. Quote > Undirectly because if you could finish such project, you'll have learned enough to be humble. Yeah, you'll be humble, because you'll realize you can never be as great a coder as The Fabulous Heliophobe, Undisputed Z80 Champion! (the smiley would go here).

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Be EXCELLENT to Chris. Posted: Mon Aug 21, 2000 6:50 pm
	Quote > And what about you, Heliophobe? mm? Quote > Sure, you might start out helpful, but as soon as Zoop enters the picture you get on his side and ruin whatever was left of Chris' hope. Yeah, I'm just Zoop's little toady, aren't I? Chris reminds me too much of other Chris's I know (and I'm not just using the name as a generic term, all the Chris's I've know have been like this.). Common traits: -Makes lots of lofty plana (typical Archtypical Chris plans: Single handedly writing a new operating system, because 'Windows is stupid.' Writing a 'good' emulator for his favorite system, because the other emulators available are too slow due to their lousy programmers) -Despite minimal coding experience, is convinced they can accomplish their outrageously complicated task easily, because he's smarter than most. And reads books. (similar arrogance makes them want to reinvent every wheel, because nobody else's code could possibly be good enough). -Generally is shown to be ignorant of some very basic coding fundamentals when actually pressed to reveal some code. -When presented with a challenge, gives up easily. Finds new project. -And, has a complete lack of tact. It's the special combination of arrogance, laziness, and social incompitence that makes one of these Chris's. So why do I oscillate between helpful and rude? Because I've noticed that this type does in fact benefit from the occasional boot in the ass. Plus, he gets on my nerves after a while. Quote >You wonder why shitty games like Pokemon and Mortal Kombat sell millions of copies? Because millions of people buy them? Quote >It's cause as soon as any kid comes along with an interest in the classics, the true gaming originals, it's the assholes like you that claim the territory for yourselves and force that kid to become another dollar spender in today's money-trapping video game crap market. Think about it. Don't make me ashamed to support emulation. Holy shit, Zoop, we're the establishment!

Forums

View topic - Language Compilers (Preferably C)