Forums

As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use.

I'm throwing up the first function ;)

PSG_Mute:
; Set all PSG channels volume to zero
; Affect: HL, BC
ld hl, PSG_Table
ld c, $7F
ld b, 4
otir
PSG_Table:
.byte $9F, $BF, $DF, $FF

I'll e-mail you my routines sometime soon.

Quote

> As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use.

I think this is a fine idea. However, if it is to truly be a "library" (and not just a random collection of functions with little or no documentation), I believe a small set of standards should be set in place. These standards will ease the process of learning the library, as well as allowing the library routines to be called from a high-level language (such as C) if we ever get far enough to create or port a compiler.

I make the following recommendations:

When writing a library routine, the programmer should be aware of the following:

1.) Code space is in ROM, and consequently mapped to addresses 0x0000 through 0xBFFF.

2.) Pre-defined and constant data (graphic tiles, sound data) is also in ROM and is mapped to addresses 0x0000 through 0xBFFF

3.) The static and global data area begins in RAM at address 0xC000

4.) The HEAP begins immediately after the static and global data area and grows UP towards address 0xDFFF

5.) A STACK is always defined and starts at 0xE000 (i.e., SP=E000, which is O.k. since the Z80 pre-decrements the SP before storing data) and grows down towards the HEAP. Because the SMS/GG doesn't use an Operating System it is the programmer's responsibility to ensure the STACK does not crash into the HEAP.

6.) A library routine should be completely self-contained. That is to say it does not modify any registers, and only uses memory it allocates from the stack. (I acknowledge that this may be difficult for many library routines, especially those depending on large tables. Perhaps a section of ROM can be devoted to library routine constant data. May I recommend the area 0x0100 to 0x1000, which is non-pageable in real SMS/GG systems? Temporary variables should still be allocated from the stack, though.)

7.) In accordance with the above, I recommend that the "back-up" registers (AF', BC', DE', HL') be reserved for use as scratch registers, meaning that a library routine or interrupt handler can use these registers to temporarily store data. A programmer using the library functions should NOT assume the values in the back-up registers will remain consistent across a call to a library function.

8.) Standard registers are used for returning values from functions. I suggest C for 8-bit, BC for 16-bit and DE:BC for 32-bit values. Providing this definitions facilitates calling these functions from a high-level language.

In light of the above, I suggest modifying Zoop's function as follows:




; PSG_Mute


;


; INPUTS -- None


; OUTPUT -- None


;


; Set all PSG channels volume to zero


;


PSG_Mute:


   exx


   ld hl, PSG_Table


   ld c, $7F


   ld b, 4


   otir


   exx


   ret


; END PSG_Mute





; Somewhere in ROM 0x0100 and 0x1000





 PSG_Table:


    .byte $9F, $BF, $DF, $FF

These are just my recommendations. Let me know what you think.

Eric Quinn

Quote

> As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use.

Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used.

Alternatively, we could create a set of code snippets for the sole purpose of documentation, intended to show how to do some random simple task.

--Nyef

Quote

> > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use.
> Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used.

I thought about doing both on the same time.
I mean, making the game, but always keeping in mind some parts will need to be re-usable in the future.

One important problem is that we must define the right point between a nice written code and a speedy one.

[snipped quotes]

I don't understand the reasons/meanings of points 1 to 5.
It's not related to the library.
In the case of accessing data, the function will take an address in a register anyway.

About 4/5:
It's right, but it's the case with just every system of this kind anyway.
And even if we could check SP on each PUSH, what to do if it reach the limit, if not crashing?

6:
Back on the good-looking or fast-running question. The smaller and very oftenly used functions shouldn't save anything. Only what's required would be manually saved by the programmer.
On another side I'm not sure about how much this kind of thing would alter performances, I'm no expert.

On last point of course: all constants, register values, etc, will be of course DEFINEd.

Quote

> I thought about doing both on the same time.
> I mean, making the game, but always keeping in mind some parts will need to be re-usable in the future.

You mean some people don't? Okay, I don't most of the time, but I find that most of my code turns out to be reusable anyway. ^_^

--Nyef

Quote

> I don't understand the reasons/meanings of points 1 to 5.
> It's not related to the library.
> In the case of accessing data, the function will take an address in a register anyway.

They are there simply to define the environment. They're necessary to know if designing the library for use with a high-level language.

Quote

> About 4/5:
> It's right, but it's the case with just every system of this kind anyway.
> And even if we could check SP on each PUSH, what to do if it reach the limit, if not crashing?

Nothing can be done. It should just be noted that the programmer is responsible for making sure the stack doesn't get to large. This can be difficult to visualize when programming in a high-level language (some of which support making sure overrunning the stack doesn't happen).

Quote

> 6:
> Back on the good-looking or fast-running question. The smaller and very oftenly used functions shouldn't save anything. Only what's required would be manually saved by the programmer.

I disagree. There's no point to having a library if the programmer needs to understand the side-affect of every single function, they may as well write each routine themselves. Library functions should not alter machine state. Additionally, this is absolutely necessary if the library is to be used in a high-level language (exspecially C/C++).

Quote

> On another side I'm not sure about how much this kind of thing would alter performances, I'm no expert.

It would affect performance, but that's usually the price you pay for using pre-fabricated libraries.

Eric Quinn

Quote

> > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use.

> Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used.

> Alternatively, we could create a set of code snippets for the sole purpose of documentation, intended to show how to do some random simple task.

> --Nyef

That sort of thing would go great in a sort of basic SMS tutorial, to help beginners who are having trouble getting started (like myself) understand how to program the SMS :)

Author	Message
Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Sega 8-bit library project Posted: Thu Mar 09, 2000 9:59 pm
	As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use. I'm throwing up the first function ;) PSG_Mute: ; Set all PSG channels volume to zero ; Affect: HL, BC ld hl, PSG_Table ld c, $7F ld b, 4 otir PSG_Table: .byte $9F, $BF, $DF, $FF

Poseidon Guest	Posted: Fri Mar 10, 2000 5:55 am
Poseidon Guest	I'll e-mail you my routines sometime soon.

Eric Guest	Posted: Fri Mar 10, 2000 4:10 pm
Eric Guest	Quote > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use. I think this is a fine idea. However, if it is to truly be a "library" (and not just a random collection of functions with little or no documentation), I believe a small set of standards should be set in place. These standards will ease the process of learning the library, as well as allowing the library routines to be called from a high-level language (such as C) if we ever get far enough to create or port a compiler. I make the following recommendations: When writing a library routine, the programmer should be aware of the following: 1.) Code space is in ROM, and consequently mapped to addresses 0x0000 through 0xBFFF. 2.) Pre-defined and constant data (graphic tiles, sound data) is also in ROM and is mapped to addresses 0x0000 through 0xBFFF 3.) The static and global data area begins in RAM at address 0xC000 4.) The HEAP begins immediately after the static and global data area and grows UP towards address 0xDFFF 5.) A STACK is always defined and starts at 0xE000 (i.e., SP=E000, which is O.k. since the Z80 pre-decrements the SP before storing data) and grows down towards the HEAP. Because the SMS/GG doesn't use an Operating System it is the programmer's responsibility to ensure the STACK does not crash into the HEAP. 6.) A library routine should be completely self-contained. That is to say it does not modify any registers, and only uses memory it allocates from the stack. (I acknowledge that this may be difficult for many library routines, especially those depending on large tables. Perhaps a section of ROM can be devoted to library routine constant data. May I recommend the area 0x0100 to 0x1000, which is non-pageable in real SMS/GG systems? Temporary variables should still be allocated from the stack, though.) 7.) In accordance with the above, I recommend that the "back-up" registers (AF', BC', DE', HL') be reserved for use as scratch registers, meaning that a library routine or interrupt handler can use these registers to temporarily store data. A programmer using the library functions should NOT assume the values in the back-up registers will remain consistent across a call to a library function. 8.) Standard registers are used for returning values from functions. I suggest C for 8-bit, BC for 16-bit and DE:BC for 32-bit values. Providing this definitions facilitates calling these functions from a high-level language. In light of the above, I suggest modifying Zoop's function as follows: `; PSG_Mute ; ; INPUTS -- None ; OUTPUT -- None ; ; Set all PSG channels volume to zero ; PSG_Mute: exx ld hl, PSG_Table ld c, $7F ld b, 4 otir exx ret ; END PSG_Mute ; Somewhere in ROM 0x0100 and 0x1000 PSG_Table: .byte $9F, $BF, $DF, $FF` These are just my recommendations. Let me know what you think. Eric Quinn

Nyef Guest	Posted: Fri Mar 10, 2000 6:26 pm
Nyef Guest	Quote > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use. Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used. Alternatively, we could create a set of code snippets for the sole purpose of documentation, intended to show how to do some random simple task. --Nyef

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Fri Mar 10, 2000 7:01 pm
	Quote > > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use. > Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used. I thought about doing both on the same time. I mean, making the game, but always keeping in mind some parts will need to be re-usable in the future.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Fri Mar 10, 2000 7:12 pm
	One important problem is that we must define the right point between a nice written code and a speedy one. [snipped quotes] I don't understand the reasons/meanings of points 1 to 5. It's not related to the library. In the case of accessing data, the function will take an address in a register anyway. About 4/5: It's right, but it's the case with just every system of this kind anyway. And even if we could check SP on each PUSH, what to do if it reach the limit, if not crashing? 6: Back on the good-looking or fast-running question. The smaller and very oftenly used functions shouldn't save anything. Only what's required would be manually saved by the programmer. On another side I'm not sure about how much this kind of thing would alter performances, I'm no expert. On last point of course: all constants, register values, etc, will be of course DEFINEd.

Nyef Guest	Posted: Fri Mar 10, 2000 8:15 pm
Nyef Guest	Quote > I thought about doing both on the same time. > I mean, making the game, but always keeping in mind some parts will need to be re-usable in the future. You mean some people don't? Okay, I don't most of the time, but I find that most of my code turns out to be reusable anyway. ^_^ --Nyef

Eric Guest	Posted: Fri Mar 10, 2000 8:57 pm
Eric Guest	Quote > I don't understand the reasons/meanings of points 1 to 5. > It's not related to the library. > In the case of accessing data, the function will take an address in a register anyway. They are there simply to define the environment. They're necessary to know if designing the library for use with a high-level language. Quote > About 4/5: > It's right, but it's the case with just every system of this kind anyway. > And even if we could check SP on each PUSH, what to do if it reach the limit, if not crashing? Nothing can be done. It should just be noted that the programmer is responsible for making sure the stack doesn't get to large. This can be difficult to visualize when programming in a high-level language (some of which support making sure overrunning the stack doesn't happen). Quote > 6: > Back on the good-looking or fast-running question. The smaller and very oftenly used functions shouldn't save anything. Only what's required would be manually saved by the programmer. I disagree. There's no point to having a library if the programmer needs to understand the side-affect of every single function, they may as well write each routine themselves. Library functions should not alter machine state. Additionally, this is absolutely necessary if the library is to be used in a high-level language (exspecially C/C++). Quote > On another side I'm not sure about how much this kind of thing would alter performances, I'm no expert. It would affect performance, but that's usually the price you pay for using pre-fabricated libraries. Eric Quinn

Keilin Silverfox Guest	Posted: Sat Mar 11, 2000 12:55 pm
Keilin Silverfox Guest	Quote > > As mentionned on a message in the big tree which no one will ever notice, doing a Sega 8-bit project together would be a nice way to assemble a general-purpose library for later use. > Yes, it would be a good way to assemble a set of usable code fragments. But I think that it would be better to write a game _first_, and then look at what bits could be reused. Otherwise you will have bits of code written but not used and code that has to be changed before it can be used. > Alternatively, we could create a set of code snippets for the sole purpose of documentation, intended to show how to do some random simple task. > --Nyef That sort of thing would go great in a sort of basic SMS tutorial, to help beginners who are having trouble getting started (like myself) understand how to program the SMS :)

Forums

View topic - Sega 8-bit library project