All working ok!! New beta!!


New Member
Not you Ex. You've been quite regular. I was thinking more in the way of Artemio Urbina or Charles Doty ^o^; both have a PAR and knowledge of SGL :p. Urbina normally posts at weekends, so I expect to hear from him soon ^^; Charles just well, appears and saves us all every now and then :)

As for my debbuging, after 3 CD's that make perfect coasters, I'm totally sure that the VideoDecode() function is causing all this grief (I created a version that didn't even booted the emulation code and it still crashed the same way). I've not yet found out _why_... and i'm out of CD's again (and without any cash, just bought a switcher and a network card :) )


New Member

Just for debugging, i think im need to add in beginning of every function the slprint with name of this function and waiting for START button.. (And even, may add the IF pressed button A - skip those function)

So this way we will know what cause the crash..

Artemio Urbina

New Member
hello guy... Great news here!!!

Congrats to Denis and Takashi for this!!! I am so happy =)

Well, will give it a try ASAP. Will report in half an hour.... Had been TOO busy lately. WIll try both, PAR and burnt ISO...

Artemio Urbina

New Member
OK.. tryied the safe one burnt in a CD-R .. First got the instructions screen, then the Loading ROMS message and finally a screen full of tiles in a blu/greenish pattern.. locked there...

Beta has the same problem, except it is in a higher res and the credits are show twice...

Will give it a try...

(Edited by Artemio Urbina at 11:31 pm on Dec. 1, 2001)

Obviusloy (should have though about that) the poor thing crashed when using the PAR.. could not access the files.. better will go on with CD-Rs to test the code, just giving a "message " debugging for now...

(Edited by Artemio Urbina at 11:35 pm on Dec. 1, 2001)

Artemio Urbina

New Member
The problem is in the load_color_proms() function I guess...

It goes to teh tiles screen just after displaying the "Loading ColorROM.." Message, never displays the "Converting Palletes..." one.. will try to do more research on this...

Artemio Urbina

New Member
Yup another post by me... well,

It definetively appears to be a problem in teh function mentioned above. I made a return before converting teh palletes and teh rest of my debugging messages were show, although (obviously) the emu didn't work (but it made it to

ClsFast((void *)map_data);

ClsFast((void *)gfx_data);

And went trough.

I uploaded a modified version of main.c, with file validation and some cosmetic changes for it to look better on a real TV.


The main.c is at

(Edited by Artemio Urbina at 2:33 am on Dec. 2, 2001)


New Member
BTW, if you used slPrint() to display text, the color used to color the letters is set to black. That's why you can't see a thing after it runs. I'm pretty sure it's perfect. Otherwise there wouldn't be any green tiles appearing, only white, blue and black colors are set when the SGL boots :)

(Edited by TakaIsSilly at 9:46 pm on Dec. 4, 2001)


New Member

BTW, Found how to use bitmaps - seems that they need that any pallette loaded to color ram or they will, as TakaIsSilly said, use only 3 colors (blue/white/black - because SEGA logo inititally sets this pallete??)


Our phoenix emu.... About ASCII Characters - seems that they not shown after loading roms, because not color pallete changes - but because, we trash ASCII cells/tiles with phoenix one (i.e. if you will try to slprint something after emulation begins - there will be "garbage" characters).Will try today to change all memory locations which emu use (based on Samples from SGL) - i.e. for example, for map_data will use not VDP2_VRAM_A0, but VDP2_VRAM_B1 + 0x12000 and so all (i.e. all memory locations from sgl samples). (Possibly this will not even trash the ASCII characters cells.

Also, will insert here and there (as said TakaIsSilly) slTVOff()/slTVOn(). Maybe slScrAutoDisp() of any use??


New Member
Didn get any real result :(

So the main direction i think - it's:

1) to play with memory locations for cells(tiles)

2) add TVOn/TVOff

3) what if the problem in the video_decode? Can't wrote directly to VDP2_VRAM? (but it's weird)


Staff member
AFAIK, it's entirely possible to write directly to VDP2 VRAM. I think you might encounter problems if you try to write during active display (i.e. not during vblank or hblank), but as I recall there is also a way to configure access to the VRAM so that this is possible (try a search for "cycle pattern register" if you have the VDP2 manual or tech bulletin PDF.


New Member
That's the odd part. Stardust operates on the VRAM mutch often and in mutch worst conditions, and I never got the real system jammed. I can only think of 2 things to try...

- Trying placing the ROMS on the L-WORKRAM (an empty 1Mb space of data), instead of arrays. Maybe there's some weird sharing violation, or the lack of an MMU makes stuff dificult.

- Decoding the tiles previously on the PC and then placing them on another file. This is how Phantasy Star Collection works, i belive.


New Member
Taka, i'm not totally sure PSC does that entirely. I know one time(just for the heck of it mind you) I tried screwing around with the rom files included on the disc. For instance I took out PS3, changed the font and a bit of text, then re-inserted it at runtime using an AR. It showed my changes immediately. So that means it must still be accessing various graphics, etc. from the roms.

Cyber Warrior X

Artemio Urbina

New Member
Well guys wish you luck.. If want me to try anything new on teh Sat, feel free to ask, but send me an e-mail for me to be aware faster... I wil be able to test stuff Saturday morning and Friday night... maybe tonight too.




New Member
Well, tonight i'll make a step by step debug of the tile routine, using video_decode. If it doesn't work, I'll start modifing it.

ExCyber - You are right, since SGL clarely states you should use SlSynch() to prevent writing during that process (it stops execution til VSynch)... This isn't a video writing problem, seems more like a limitation when adresssing memory. And you just gave me an idea ^^;

Artemio, don't worry, you'll have a handfull :)

CyberWarriorX, I'm not sure about PSC, but there was the word some time ago that some graphics (provably from the more incompatible Genesis modes) seem to be hacked into some files (assumingly for speed reasons). I don't have a copy of it, so I can't clearly say anything.


It runs!

I just burnt it and loaded it up on my modded saturn.

It has the screen displacement that is shown in your screenshots from the 0.5Beta. However it also displays some yellow graphical 'junk' in the centre portion that is black in your pics.


The bottom three quarters of the screen has a flicker to it.

The background also loads from the bottom up in rows, rather than scrolling down from the top.

Some background item disappear and reappear.

Your ship's explosion occurs well up the screen.

The alien's colours don't change in the second level.

The background transition from level one to level two overwrites instead of scrolling.

It all goes a bit strange by the third level. The eggs appear in front of the scores/lives/credits at the top of the screen. Some of the birds on the third and fourth stage are vertically displaced. Their sprite is in one spot but the game behaves as if they are in another.

The birds don't change colour in the fourth stage either.

In the fifth stage, the mothership(?) doesn't descend.

Also the aliens fly 'behind' it.

I think they should be green and purple too, but I can't be sure...

Please don't think I'm bagging you or expect any or all of these bugs squashed any time soon. You probably know most of them, but I just want to help.

I'll post some more after I ,ahem, test some more. :)

[edit] I had to download it with GetRight as Netscape kept downloading it badly. That is, CDRWin and CDMage would both reject it.

(Edited by mal at 1:31 am on Dec. 8, 2001)

[edit] Added some more bugs.

(Edited by mal at 1:55 am on Dec. 8, 2001)