Forums

Hi Folks :),

if I try to load in normal mode a bios image for example, Alex Kidd in Miracle World Bios.sms, the game does not start (looping in the initial Sega logo)...

Now ...is the problem related to port 3Eh (in my Emu I haven't emulate this) ?

How could I start the game ?

Could everyone post a piece of source code (for example in C).. or even Pseudo Code that explain how do this thing.

Thanks in advance.

BIOS images are doing BIOS things. They are copying some code into RAM, then running that code which uses port $3E to make the various slots (expansion, card, cartridge) active and checking each for a valid ROM image. If one is found, they let it run; so, for example, your Alex Kidd BIOS sees itself, notices that it is valid and runs itself, hence the never-ending loop.

There are many ways to handle port $3e. Basically, what is returned from the ROM space needs to be dependent on the value written there, so when it's written to, you will probably be filling your 48KB mapped rom space memory from a buffer storing the appropriate image (BIOS, game, blank data) according to its value. There might be better ways of doing it than that, I am not an emulator author.

An alternative is to store ROM patches for BIOSes that force them to boot to the game instead of attempting detection, and automatically patch them in memory when loaded. Meka includes the required patch information for these.

Thank you for your answer...

but do you know exactly which value I have to checked in port 3E ?
or... Could you explain me the meka patch ?

...however... I could like/prefer to do the 'real things' that the bios normally do...

PS:
I already 'have done' sms memory/mapper procedure... Doesn't the bios recall the mapper to fill properly some memory area ?

Think of it this way...

Your mapper emulation deals with mapping the ROM onto the first 48KB of ROM space.

What if you had FOUR cartridges loaded at once? Obviously only one of them can be active at a time, but if each has a boolean specifying "active" or not, and you make sure only one has it set to true, then when the Z80 reads from that 48KB, just the active one will respond.

That's what the hardware is like. Port $3E contains those booleans:

D7 : Expansion slot enable (1= disabled, 0= enabled)
D6 : Cartridge slot enable (1= disabled, 0= enabled)
D5 : Card slot disabled (1= disabled, 0= enabled)
D4 : Work RAM disabled (1= disabled, 0= enabled)
D3 : BIOS ROM disabled (1= disabled, 0= enabled)
D2 : I/O chip disabled (1= disabled, 0= enabled)
D1 : Unknown
D0 : Unknown

Bit 7 is the boolean for the expansion slot, bit 6 for the cartridge slot, bit 5 for the card slot and bit 3 for the BIOS. If more than one is set to true (0) then more than one will try to respond to reads at the same time and you end up with junk data, so the software running on the SMS should generally not do that.

There are a couple of other enablers for RAM and I/O (controllers), but you don't usually need to worry about them.

For accurate emulation, you should try to copy that behaviour exactly. However, an easier way would be:

when it writes to port $3E
figure out which slot is active
make a note (for future mapper accesses)
make it so that slot's data is in the 48KB ROM space
(or, blank the space if nothing is mapped in)

which doesn't handle more than one at once but will be less overhead than four function calls for every byte read.

Again, I am not an emulator author. Charles MacDonald's smstech.txt includes the information I gave above and shouldn't be too hard to understand; specific questions in here are good, but questions like "how do I emulate port $3e?" make it seem like you aren't making the effort to find out before asking. I'm sure that's not the case.

Sure. I already knew that document. (I will try however to read it that again ) ...infact my question was a supposition to be related to port 3e, but I think my problem is an other. I haven't loaded more than 1 cartridge or something else ...or better... I only have the bios (to run)... I suppose that all the slot (main slot, card slot etc.) are empty...

Question is, Why the bios in the real machine runs correctly (alex kidd starts, the game is playable)... and in an emulator (without the patch that you have described) does not ?

May be I haven't understand very well... but.. the bios try to read in port $3E a value... right ? if this value match... the game starts normally, else loop in the sega logo... finally... Is this value a specific value ? Eg. 0xFF or whatelse ?

You haven't understood at all.

The BIOS image is in the BIOS slot. The cartridge slot is empty.

The BIOS slot is enabled by the hardware and it runs. It displays the SEGA logo, then copies some code to RAM, and executes from there.

That code DISABLES the BIOS slot, so it cannot be accessed. It ENABLES the cartridge slot and has a look at what's there.

If it is blank, it ENABLES the BIOS slot and runs the BIOS built-in game.

If it is not, it runs the cartridge game.

If you put a BIOS on a cartridge, this happens:

1. Run cartridge
2. Display SEGA logo
3. Copy code to RAM
4. Disable BIOS (was already disabled) and enable cartridge (was already enabled)
5. Look at cartridge data
6. Notice it is not blank
7. Decide to run it
8. Go to step 1

which is the infinite loop showing the logo.

To fix it, you (1) need the BIOS data to be in a separate slot from the cartridge data and (2) need to emulate port $3e so it returns blank data when the enabled slot is empty.

OK, that's enough for me. I hate explaining things 3 times.

I'm sorry, the problem is mine ! You have been super clear ! Today afternoon I'll try to implement that code... If I obtain a good result I will post here a succefull message ...else I'll try again ! Now I must 'run' to my university to follow english lesson... I hope after few lessons my English will be better :) !

Thanks for all, bye.

http://mesadx.home.att.net/

MesaDX properly emulates port $3e, and the various slots in a SMS1 system (bios, card, cartridge, and expansion).

Feel free to try loading the Alex Kidd BIOS in MesaDX as BIOS (BROM) to see the correct behavior. You can set breakpoints on the IO writes to port $3e to see what the code is doing. You can also look at the low 8-bits in the DDR register in the MIOH AXR View to see what the status of the various memory device disables are (i.e., the last value written to port $3e).

The problem you are having is (as Maxim said) the Alex Kidd BIOS is detecting itself and then re-starting. The reason it is detecting itself is because you aren't emulating port $3e correctly. If you run it in MesaDX (as BROM) you will see that it will write to port $3e and attempt to enable another memory device. For example, it'll write $CB to port $3e to enable the Sega CARD device. (It'll write $AB for the Cartridge, and $6B for the expansion port). The BIOS will then look for the Sega header at address $7ff0. If it finds the header, then it knows that memory device exists. Look at the memory view in MesaDX as different values are written to $3E: you will sometimes see that the data between address $0000 and $BFFF is all $FF. This means that the memory device doesn't exist. If the BIOS discovers that no other memory is installed, it will then (and only then) run the Alex Kidd game. So, the problem is not an issue of the exact value read from $3e, it's an issue of finding the SMS header at address $7ff0 when different memory devices are
enabled/disabled via port $3e.

However, emulating port $3e correctly is not trivial. It requires the ability to load multiple ROM images and successfully map them in and out of Z80 address space as desired. Right now, MesaDX may be the only emulator to implement $3e correctly. Most emulators simply don't allow you to run BIOS images directly, or support patching (like Meka) to allow the BIOS to run a particular way.

Good luck.

--
Eric R. Quinn

I Did It !!! :)

I have done that with a few rows (though emulation is very incomplete...), but I only wanted Alex Kidd Bios to start...

Here the code :

void Z80_Out (BYTE port, BYTE val)
{
.
.
.

if (port == 0x3E)
{
// D3 : BIOS ROM disabled (1 = disabled, 0 = enabled)
if (val & 8)
memset (Z80Ram, 0xFF, 32768); // Question : 32 Kb or 48 Kb ?
else
memcpy (Z80Ram, RomBuf, 32768);
}

.
.
.
}

To Eric:

I have tried mesadx with Alek kidd bios but I only obtain a black screen... Where I'm wrong ?

I have selected Open Rom Image... Boot Device -> Boot Rom (Brom) and as check box ... -> only install Brom device with relative bios rom...

PS:
Why mesaDX requires 16 bit colors ? Do you use direct writes to screen buffer in 16 bit rgb color mode ?

Oops... I forgot to press F5 key... I'm an idiot :) ... now ... it's all Ok !

Bye.

darq wrote

I Did It !!! :)

I have done that with a few rows (though emulation is very incomplete...), but I only wanted Alex Kidd Bios to start...

Here the code :

void Z80_Out (BYTE port, BYTE val)
{
.
.
.

if (port == 0x3E)
{
// D3 : BIOS ROM disabled (1 = disabled, 0 = enabled)
if (val & 8)
memset (Z80Ram, 0xFF, 32768); // Question : 32 Kb or 48 Kb ?
else
memcpy (Z80Ram, RomBuf, 32768);
}

.
.
.
}

Good job, that'll work. By the way, writing 32K of $FF should be sufficient. Actually, you could probably just copy $FF into addresses $7FF0 through $7FFF since (most?) BIOS images really just look for the Sega Header at those addresses to determine if memory is present.

I hope you will consider implementing a more complete solution, especially if you intend to support running BIOS and have execution transfer to the cartridge correctly. (You can use MesaDX again to see how it works. This time load the Alex Kidd BIOS as BROM, and load another game ROM into the Cartridge (EXT0) slot. You'll see the "SEGA" splash screen, and then the Cartridge game will run.)

darq wrote

To Eric:

PS:
Why mesaDX requires 16 bit colors ? Do you use direct writes to screen buffer in 16 bit rgb color mode ?

I've already implemented 32-bit color for the next release. I'm using DirectX and it requires setting up different surfaces for different color depths. I just happened to do 16-bit color first, and didn't prioritize 32-bit color very high. However, after using MesaDX for a while, I decided not having 32-bit color was becoming very annoying. So, it'll be in the next release (which is probably several months away).

--
Eric R. Quinn

Quote

Good job

Thanx ;)

Quote

I hope you will consider implementing a more complete solution, especially if you intend to support running BIOS and have execution transfer to the cartridge correctly. (You can use MesaDX again to see how it works. This time load the Alex Kidd BIOS as BROM, and load another game ROM into the Cartridge (EXT0) slot. You'll see the "SEGA" splash screen, and then the Cartridge game will run.)

I will.
I think I will create a new directory (eg. Bios Dir) and I'll put all the bios files there. Then I'll add a new menù voice like Default Bios with (for example) the following items (a group of radio buttons or checkbox ) :

- No Bios Emulation
- Alex Kidd
- Sonic the Hedgehog
- Hang On
etc...

...plus the classic Load menù to run a game normally.

Quote

I've already implemented 32-bit color for the next release. I'm using DirectX and it requires setting up different surfaces for different color depths. I just happened to do 16-bit color first, and didn't prioritize 32-bit color very high. However, after using MesaDX for a while, I decided not having 32-bit color was becoming very annoying. So, it'll be in the next release (which is probably several months away).

I have done (in my emu) nearly the same thing ... but I have chosen 32 bit color mode only to avoid the screen switching in windows ever and ever.

In the future I think also to replace direct screen buffer write with DirectX, even if I HATE DirectX procs... too many code to write, only to initialize a video mode, too many structs to fill etc.. It's very annoying.

I'm not sure how the Japanese BIOS checks for a cart since some Japanese games have no header.

Well, I had a look. This code is run from RAM, once for each of the three slots (first card, then cartridge, then expansion slot):

CheckSlotForStuff:
ld hl,$0000 ; 000118 21 00 00 ; look at ROM from $0000
ld bc,$003c ; 00011B 01 3C 00 ; count 256 times, mask $3c
ld a,(hl) ; 00011E 7E ; get byte
and c ; 00011F A1 ; and with 3c = %00111100
ld e,a ; 000120 5F ; store in e

Loop:
ld a,(hl) ; 000121 7E ; get byte
inc l ; 000122 2C ; pointer++
and c ; 000123 A1 ; and with 3c
cp e ; 000124 BB ; compare to previous
jp nz,$0000 ; 000125 C2 00 00 ; if not equal, run slot
djnz Loop;$0121 ; 000128 10 F7 ; repeat 256 times
ret ; 00012A C9 ; ta-da! Nothing found

There we go: the Japanese BIOS works by checking if any of the first 256 bytes differ in their middle 4 bits. I'm not sure why they chose to mask them like that; perhaps the other 4 bits can float and these ones are held high or low when undriven.

Maxim wrote

There we go: the Japanese BIOS works by checking if any of the first 256 bytes differ in their middle 4 bits. I'm not sure why they chose to mask them like that; perhaps the other 4 bits can float and these ones are held high or low when undriven.

Thanks, Maxim. I knew there'd be an exception to the SMS Header checking (which is why I covered myself by saying "(most?) BIOS"); I never even considered how Japanese BIOS would do it. I guess darg should just keep the code the way it is and load the first 32K with $FF (or implement $3e more completely).

--
Eric R. Quinn

The last one that hasn't been mentioned is the Majesco GG BIOS which (as far as I remember) only checks for the TMR SEGA string. So, a minimal "corruptor" should modify make the middle 4 bits of the first 256KB identical and also modify at least one bit from that string. I think a call to memset() is probably easier to code.

Maxim wrote

The last one that hasn't been mentioned is the Majesco GG BIOS which (as far as I remember) only checks for the TMR SEGA string. So, a minimal "corruptor" should modify make the middle 4 bits of the first 256KB identical and also modify at least one bit from that string. I think a call to memset() is probably easier to code.

Using memset to fill 32 Kb with 0xFF, I have tried to run all the bios that I have. All of them works fine.

PS:
Maxim, what is this Majesco GG Bios ? Does game gear have a bios ? (I don't have got a game gear...)

That's what I meant - your memset() will satisfy all checks. It's something of a hack - it doesn't aim to act exactly like the system, just to give the wanted effect - but if that's all you want, it's OK.

There was a late re-release of the Game Gear in the US, UK and possibly elsewhere by a company called Majesco which licences and re-releases old consoles cheaply, perhaps aiming to shift ageing software stockpiles. It made the Genesis 3 in the US, for example. Its systems are generally newly manufactured and usually contain custom hardware to make them cheaper; I think the Majesco GG integrates almost everything apart from RAM onto a single chip.

Anyway, it also has a small internal BIOS that displays "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES, LTD." and delays booting the game. It only checks for "TMR SEGA" in the ROM, although strangely it checks for it at offsets 7ff0, 3ff0 and 1ff0 which is unnecessary since all GG roms have the header at 7ff0.

BIOSes can be found here.

Thank you for the useful infos. ...Now I've to do some experiments with all these bios... :)

Well, some of those files aren't SMS BIOSes, they're BIOSes from Mega Drive dumping hardware and as such aren't so useful to experiment with. The details.txt file should be clear enough.

Maxim wrote

Well, some of those files aren't SMS BIOSes, they're BIOSes from Mega Drive dumping hardware and as such aren't so useful to experiment with. The details.txt file should be clear enough.

sorry to bump this very old topic, but the details.txt file should be updated since the Missile Defence BIOS has been dumped. in fact, the bios itself appears in the folder, but the text file is outdated.

feel free to delete this post when the correction is done :)

Author	Message
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Bios Question Posted: Mon Mar 07, 2005 4:37 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Hi Folks :), if I try to load in normal mode a bios image for example, Alex Kidd in Miracle World Bios.sms, the game does not start (looping in the initial Sega logo)... Now ...is the problem related to port 3Eh (in my Emu I haven't emulate this) ? How could I start the game ? Could everyone post a piece of source code (for example in C).. or even Pseudo Code that explain how do this thing. Thanks in advance.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Mar 07, 2005 5:15 pm
	BIOS images are doing BIOS things. They are copying some code into RAM, then running that code which uses port $3E to make the various slots (expansion, card, cartridge) active and checking each for a valid ROM image. If one is found, they let it run; so, for example, your Alex Kidd BIOS sees itself, notices that it is valid and runs itself, hence the never-ending loop. There are many ways to handle port $3e. Basically, what is returned from the ROM space needs to be dependent on the value written there, so when it's written to, you will probably be filling your 48KB mapped rom space memory from a buffer storing the appropriate image (BIOS, game, blank data) according to its value. There might be better ways of doing it than that, I am not an emulator author. An alternative is to store ROM patches for BIOSes that force them to boot to the game instead of attempting detection, and automatically patch them in memory when loaded. Meka includes the required patch information for these.

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Mon Mar 07, 2005 8:09 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Thank you for your answer... but do you know exactly which value I have to checked in port 3E ? or... Could you explain me the meka patch ? ...however... I could like/prefer to do the 'real things' that the bios normally do... PS: I already 'have done' sms memory/mapper procedure... Doesn't the bios recall the mapper to fill properly some memory area ?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Mar 07, 2005 8:24 pm
	Think of it this way... Your mapper emulation deals with mapping the ROM onto the first 48KB of ROM space. What if you had FOUR cartridges loaded at once? Obviously only one of them can be active at a time, but if each has a boolean specifying "active" or not, and you make sure only one has it set to true, then when the Z80 reads from that 48KB, just the active one will respond. That's what the hardware is like. Port $3E contains those booleans: D7 : Expansion slot enable (1= disabled, 0= enabled) D6 : Cartridge slot enable (1= disabled, 0= enabled) D5 : Card slot disabled (1= disabled, 0= enabled) D4 : Work RAM disabled (1= disabled, 0= enabled) D3 : BIOS ROM disabled (1= disabled, 0= enabled) D2 : I/O chip disabled (1= disabled, 0= enabled) D1 : Unknown D0 : Unknown Bit 7 is the boolean for the expansion slot, bit 6 for the cartridge slot, bit 5 for the card slot and bit 3 for the BIOS. If more than one is set to true (0) then more than one will try to respond to reads at the same time and you end up with junk data, so the software running on the SMS should generally not do that. There are a couple of other enablers for RAM and I/O (controllers), but you don't usually need to worry about them. For accurate emulation, you should try to copy that behaviour exactly. However, an easier way would be: when it writes to port $3E figure out which slot is active make a note (for future mapper accesses) make it so that slot's data is in the 48KB ROM space (or, blank the space if nothing is mapped in) which doesn't handle more than one at once but will be less overhead than four function calls for every byte read. Again, I am not an emulator author. Charles MacDonald's smstech.txt includes the information I gave above and shouldn't be too hard to understand; specific questions in here are good, but questions like "how do I emulate port $3e?" make it seem like you aren't making the effort to find out before asking. I'm sure that's not the case.

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Mon Mar 07, 2005 9:07 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Sure. I already knew that document. (I will try however to read it that again ) ...infact my question was a supposition to be related to port 3e, but I think my problem is an other. I haven't loaded more than 1 cartridge or something else ...or better... I only have the bios (to run)... I suppose that all the slot (main slot, card slot etc.) are empty... Question is, Why the bios in the real machine runs correctly (alex kidd starts, the game is playable)... and in an emulator (without the patch that you have described) does not ? May be I haven't understand very well... but.. the bios try to read in port $3E a value... right ? if this value match... the game starts normally, else loop in the sega logo... finally... Is this value a specific value ? Eg. 0xFF or whatelse ?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Mar 07, 2005 10:59 pm
	You haven't understood at all. The BIOS image is in the BIOS slot. The cartridge slot is empty. The BIOS slot is enabled by the hardware and it runs. It displays the SEGA logo, then copies some code to RAM, and executes from there. That code DISABLES the BIOS slot, so it cannot be accessed. It ENABLES the cartridge slot and has a look at what's there. If it is blank, it ENABLES the BIOS slot and runs the BIOS built-in game. If it is not, it runs the cartridge game. If you put a BIOS on a cartridge, this happens: 1. Run cartridge 2. Display SEGA logo 3. Copy code to RAM 4. Disable BIOS (was already disabled) and enable cartridge (was already enabled) 5. Look at cartridge data 6. Notice it is not blank 7. Decide to run it 8. Go to step 1 which is the infinite loop showing the logo. To fix it, you (1) need the BIOS data to be in a separate slot from the cartridge data and (2) need to emulate port $3e so it returns blank data when the enabled slot is empty. OK, that's enough for me. I hate explaining things 3 times.

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Tue Mar 08, 2005 6:10 am
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	I'm sorry, the problem is mine ! You have been super clear ! Today afternoon I'll try to implement that code... If I obtain a good result I will post here a succefull message ...else I'll try again ! Now I must 'run' to my university to follow english lesson... I hope after few lessons my English will be better :) ! Thanks for all, bye.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Tue Mar 08, 2005 7:26 pm
	http://mesadx.home.att.net/ MesaDX properly emulates port $3e, and the various slots in a SMS1 system (bios, card, cartridge, and expansion). Feel free to try loading the Alex Kidd BIOS in MesaDX as BIOS (BROM) to see the correct behavior. You can set breakpoints on the IO writes to port $3e to see what the code is doing. You can also look at the low 8-bits in the DDR register in the MIOH AXR View to see what the status of the various memory device disables are (i.e., the last value written to port $3e). The problem you are having is (as Maxim said) the Alex Kidd BIOS is detecting itself and then re-starting. The reason it is detecting itself is because you aren't emulating port $3e correctly. If you run it in MesaDX (as BROM) you will see that it will write to port $3e and attempt to enable another memory device. For example, it'll write $CB to port $3e to enable the Sega CARD device. (It'll write $AB for the Cartridge, and $6B for the expansion port). The BIOS will then look for the Sega header at address $7ff0. If it finds the header, then it knows that memory device exists. Look at the memory view in MesaDX as different values are written to $3E: you will sometimes see that the data between address $0000 and $BFFF is all $FF. This means that the memory device doesn't exist. If the BIOS discovers that no other memory is installed, it will then (and only then) run the Alex Kidd game. So, the problem is not an issue of the exact value read from $3e, it's an issue of finding the SMS header at address $7ff0 when different memory devices are enabled/disabled via port $3e. However, emulating port $3e correctly is not trivial. It requires the ability to load multiple ROM images and successfully map them in and out of Z80 address space as desired. Right now, MesaDX may be the only emulator to implement $3e correctly. Most emulators simply don't allow you to run BIOS images directly, or support patching (like Meka) to allow the BIOS to run a particular way. Good luck. -- Eric R. Quinn

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Wed Mar 09, 2005 2:40 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	I Did It !!! :) I have done that with a few rows (though emulation is very incomplete...), but I only wanted Alex Kidd Bios to start... Here the code : void Z80_Out (BYTE port, BYTE val) { . . . if (port == 0x3E) { // D3 : BIOS ROM disabled (1 = disabled, 0 = enabled) if (val & 8) memset (Z80Ram, 0xFF, 32768); // Question : 32 Kb or 48 Kb ? else memcpy (Z80Ram, RomBuf, 32768); } . . . } To Eric: I have tried mesadx with Alek kidd bios but I only obtain a black screen... Where I'm wrong ? I have selected Open Rom Image... Boot Device -> Boot Rom (Brom) and as check box ... -> only install Brom device with relative bios rom... PS: Why mesaDX requires 16 bit colors ? Do you use direct writes to screen buffer in 16 bit rgb color mode ?

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Wed Mar 09, 2005 2:53 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Oops... I forgot to press F5 key... I'm an idiot :) ... now ... it's all Ok ! Bye.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Wed Mar 09, 2005 5:38 pm
	darq wrote I Did It !!! :) I have done that with a few rows (though emulation is very incomplete...), but I only wanted Alex Kidd Bios to start... Here the code : void Z80_Out (BYTE port, BYTE val) { . . . if (port == 0x3E) { // D3 : BIOS ROM disabled (1 = disabled, 0 = enabled) if (val & 8) memset (Z80Ram, 0xFF, 32768); // Question : 32 Kb or 48 Kb ? else memcpy (Z80Ram, RomBuf, 32768); } . . . } Good job, that'll work. By the way, writing 32K of $FF should be sufficient. Actually, you could probably just copy $FF into addresses $7FF0 through $7FFF since (most?) BIOS images really just look for the Sega Header at those addresses to determine if memory is present. I hope you will consider implementing a more complete solution, especially if you intend to support running BIOS and have execution transfer to the cartridge correctly. (You can use MesaDX again to see how it works. This time load the Alex Kidd BIOS as BROM, and load another game ROM into the Cartridge (EXT0) slot. You'll see the "SEGA" splash screen, and then the Cartridge game will run.) darq wrote To Eric: PS: Why mesaDX requires 16 bit colors ? Do you use direct writes to screen buffer in 16 bit rgb color mode ? I've already implemented 32-bit color for the next release. I'm using DirectX and it requires setting up different surfaces for different color depths. I just happened to do 16-bit color first, and didn't prioritize 32-bit color very high. However, after using MesaDX for a while, I decided not having 32-bit color was becoming very annoying. So, it'll be in the next release (which is probably several months away). -- Eric R. Quinn

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Wed Mar 09, 2005 10:54 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Quote Good job Thanx ;) Quote I hope you will consider implementing a more complete solution, especially if you intend to support running BIOS and have execution transfer to the cartridge correctly. (You can use MesaDX again to see how it works. This time load the Alex Kidd BIOS as BROM, and load another game ROM into the Cartridge (EXT0) slot. You'll see the "SEGA" splash screen, and then the Cartridge game will run.) I will. I think I will create a new directory (eg. Bios Dir) and I'll put all the bios files there. Then I'll add a new menù voice like Default Bios with (for example) the following items (a group of radio buttons or checkbox ) : - No Bios Emulation - Alex Kidd - Sonic the Hedgehog - Hang On etc... ...plus the classic Load menù to run a game normally. Quote I've already implemented 32-bit color for the next release. I'm using DirectX and it requires setting up different surfaces for different color depths. I just happened to do 16-bit color first, and didn't prioritize 32-bit color very high. However, after using MesaDX for a while, I decided not having 32-bit color was becoming very annoying. So, it'll be in the next release (which is probably several months away). I have done (in my emu) nearly the same thing ... but I have chosen 32 bit color mode only to avoid the screen switching in windows ever and ever. In the future I think also to replace direct screen buffer write with DirectX, even if I HATE DirectX procs... too many code to write, only to initialize a video mode, too many structs to fill etc.. It's very annoying.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Japanese BIOS cartridge detection code Posted: Wed Mar 09, 2005 11:11 pm
	I'm not sure how the Japanese BIOS checks for a cart since some Japanese games have no header. Well, I had a look. This code is run from RAM, once for each of the three slots (first card, then cartridge, then expansion slot): CheckSlotForStuff: ld hl,$0000 ; 000118 21 00 00 ; look at ROM from $0000 ld bc,$003c ; 00011B 01 3C 00 ; count 256 times, mask $3c ld a,(hl) ; 00011E 7E ; get byte and c ; 00011F A1 ; and with 3c = %00111100 ld e,a ; 000120 5F ; store in e Loop: ld a,(hl) ; 000121 7E ; get byte inc l ; 000122 2C ; pointer++ and c ; 000123 A1 ; and with 3c cp e ; 000124 BB ; compare to previous jp nz,$0000 ; 000125 C2 00 00 ; if not equal, run slot djnz Loop;$0121 ; 000128 10 F7 ; repeat 256 times ret ; 00012A C9 ; ta-da! Nothing found There we go: the Japanese BIOS works by checking if any of the first 256 bytes differ in their middle 4 bits. I'm not sure why they chose to mask them like that; perhaps the other 4 bits can float and these ones are held high or low when undriven.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Re: Japanese BIOS cartridge detection code Posted: Thu Mar 10, 2005 1:41 am
	Maxim wrote There we go: the Japanese BIOS works by checking if any of the first 256 bytes differ in their middle 4 bits. I'm not sure why they chose to mask them like that; perhaps the other 4 bits can float and these ones are held high or low when undriven. Thanks, Maxim. I knew there'd be an exception to the SMS Header checking (which is why I covered myself by saying "(most?) BIOS"); I never even considered how Japanese BIOS would do it. I guess darg should just keep the code the way it is and load the first 32K with $FF (or implement $3e more completely). -- Eric R. Quinn

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Mar 10, 2005 9:24 am
	The last one that hasn't been mentioned is the Majesco GG BIOS which (as far as I remember) only checks for the TMR SEGA string. So, a minimal "corruptor" should modify make the middle 4 bits of the first 256KB identical and also modify at least one bit from that string. I think a call to memset() is probably easier to code.

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Thu Mar 10, 2005 1:09 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Maxim wrote The last one that hasn't been mentioned is the Majesco GG BIOS which (as far as I remember) only checks for the TMR SEGA string. So, a minimal "corruptor" should modify make the middle 4 bits of the first 256KB identical and also modify at least one bit from that string. I think a call to memset() is probably easier to code. Using memset to fill 32 Kb with 0xFF, I have tried to run all the bios that I have. All of them works fine. PS: Maxim, what is this Majesco GG Bios ? Does game gear have a bios ? (I don't have got a game gear...)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Mar 10, 2005 1:27 pm
	That's what I meant - your memset() will satisfy all checks. It's something of a hack - it doesn't aim to act exactly like the system, just to give the wanted effect - but if that's all you want, it's OK. There was a late re-release of the Game Gear in the US, UK and possibly elsewhere by a company called Majesco which licences and re-releases old consoles cheaply, perhaps aiming to shift ageing software stockpiles. It made the Genesis 3 in the US, for example. Its systems are generally newly manufactured and usually contain custom hardware to make them cheaper; I think the Majesco GG integrates almost everything apart from RAM onto a single chip. Anyway, it also has a small internal BIOS that displays "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES, LTD." and delays booting the game. It only checks for "TMR SEGA" in the ROM, although strangely it checks for it at offsets 7ff0, 3ff0 and 1ff0 which is unnecessary since all GG roms have the header at 7ff0. BIOSes can be found here.

darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Posted: Thu Mar 10, 2005 1:55 pm
darq Joined: 07 Mar 2005 Posts: 14 Location: Italy	Thank you for the useful infos. ...Now I've to do some experiments with all these bios... :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Mar 10, 2005 1:59 pm
	Well, some of those files aren't SMS BIOSes, they're BIOSes from Mega Drive dumping hardware and as such aren't so useful to experiment with. The details.txt file should be clear enough.

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Fri Sep 15, 2006 7:19 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Maxim wrote Well, some of those files aren't SMS BIOSes, they're BIOSes from Mega Drive dumping hardware and as such aren't so useful to experiment with. The details.txt file should be clear enough. sorry to bump this very old topic, but the details.txt file should be updated since the Missile Defence BIOS has been dumped. in fact, the bios itself appears in the folder, but the text file is outdated. feel free to delete this post when the correction is done :)

Forums

View topic - Bios Question