Forums

Hello.

I tinker around with a homebrew sidescroller beat 'em up. Well, at least that is the idea - by now I can design a level background and step through it left or right in 8 pixel steps.

I write my code in a text editor (Context), and compile it with WLA-DX and run it in MEKA, following the setup laid out in Maxim's lesson 1 tutorial. In MEKA everything is fine (my stuff actually works!). When I copy the .sms file to my SD card holding a lot of other ROMS, and boot into it via my Master Everdrive cartridge on my real system (SMS I), the graphics are all wrong. But I can see that the 'game' still responds to the joystick, so I'm guessing that there is something about the graphics/tiles/tilemap I'm not taking into account.Are there any known graphics issues with regards to running homebrew games in MEKA compared to a real system?

By the way, I think I have found a nice way to work with Photoshop as a kind of tilebased level editor. I will do a post on it when I'm a little deeper into the project.

pp7.zip (5.67 KB)

I guess you end up updating VRAM in the middle of active display when the VDP can only receive some 10 writes per line.
Try adding some delays between VRAM writes or make sure that VRAM writes only happen during blanking period where you can push data as fast as possible.

Hi TmEE - thank you for your suggestion. It is not as if the background wobbles or flickers like when writing too much too fast to VRAM during i.e. scrolling. My game does not even scroll yet. It just steps 8 pixels either left or right. New tiles are written to every position on the screen map. Then it waits for another user move.

I use Maxim's function to write to VRAM:

WriteToVRAM:
-:ld a,(hl)
out ($be),a
inc hl
dec bc
ld a,c
or b
jp nz,-
ret

I cannot describe what it looks like. The tiles are jumbled, but mostly totally destroyed or missing (on the screen - when I try it out on my real machine). In MEKA there are no problems.??

When you write too fast to the VRAM you will experience skipped writes and most emulators do not emulate this behaviour.
When you try the game on Emukon you'll experience something similiar to what you do on real hardware.

Tho code you posted can manage whole lot more than 10 writes per line, which means in active scan it will overflow the buffer of VDP and that results in skipped writes.

OK - thank you. I will try it in Emukon and see what happens.

EDIT: Emukon is the same as MEKA. Everything seems to be working here.??

How are the graphics wrong? Can you post a picture of the screen on a real system?

I seem to remember that this is an optional feature in Emukon. Also, it logs messages to its message window when the writes are too fast, even if its emulated corruption seems less bad than on a real system.

Bock wrote

How are the graphics wrong? Can you post a picture of the screen on a real system?

Im sorry, I have tried and tried, but the forum wont let me post the pic (jpeg or png, small size).

Maybe the problem has to do with my Everdrive? I think I will try to download some of the homebrew games from here, and then test them in the Everdrive to see if they run OK...

Upload it on http://www.imgur.com or http://www.minus.com until Maxim turns on your image posting privileges.

You should be able to post image attachments as a new user. It's the links to imgur etc that are blocked.

PhantasyStar-SMS-KR-6.png (2.16 KB)

That was me testing what I thought to be the case.

I'm getting wildly different results with Fusion 3.64, Meka 0.80, Emukon 1.05 and Mednafen 0.9.28. I've attached these screenshots.

Hmm...

I can tell you that you haven't initialised map_counter. You should treat the RAM as having random values, and clear it manually when your program starts. (I made the exact same mistake exactly a year ago today!)

Initialise map_counter to zero and that satisfies all the emulators... except Mednafen. Weird. When you scroll the map in Mednafen, I can see a bunch of pixels moving around in the bottom left corner. It looks like what happens when you display the entire contents of VRAM (including tile indices and sprite attribute table) as tile graphic data, so I think the VDP register that controls where the tile indices are read from ("Register $02 - Name Table Base Address" in the vdp register doc) isn't set up right.

Edit - Yep, that's solved it.

You should initialise all the VDP registers when your game starts otherwise you'll get a mangled display on almost any hardware. Like the RAM, these registers are left in a messy state due to the BIOS/startup stuff.

Near where you've written

; turn screen on, set various bits (please refer to the manual p. 15)

Add the following:

ld a, %11111111
out (VDP_command), a
ld a, $82
out (VDP_command), a

This sets the mask bits of VDP Register 2 to all 1s. This causes the name table base address (where the tile indices are read from) to be at $3800 in VRAM.

emukon_1_05.png (1.82 KB)

meka_0_80.png (3.59 KB)

fusion_3_64.png (776 B)

mednafen_0_9_28.png (2.17 KB)

Maybe you have VBL handler touching the VDP while you mess with it in the main code (or the other way)...? That is not really the case when the corruption is mostly consistent.

Yo guys are amazing!!!

Thank you so much for the detailed feedback. I can't wait for Monday to come, so that I can go to my workplace and try out your detailed suggestions, MrD. Yes - I have all my SEGA stuff on my Windows computer at work, as we are all Mac's at home :) - not that my work even remotely has something to do with Z80 or programming in general, anyway :)

Maxim - sorry, I think I made a mistake when I tried to upload a photo. I misjudged the file size. Now it seems to be working, and as you all can see, MrD's screenshots are pretty close to what I experience on my real system.

EDIT: Thank you for your image-optimizing assistance, Maxim :) Those pesky high-res smartphone cameras...

tv_948.jpg (73.71 KB)

My stuff on the TV

You're still doing it wrong :) Photos should be JPG, images for the web should be lower resolution... I changed your attachment from 1.25MB to 74KB.

Succes! The problem was caused by me just assuming that my variable map_counter contains $0000 from the start.

Wow!!! Now it works on my real system too! This is so..... great! A small step for mankind, but a giant leap for me.

I also tried to initialize VDP register 2 to $FF, but it makes no difference. Could it be that Mednafen does not emulate how VDP registers are initialized at power on:
------
The VDP registers are initialized at power on to the following values:
R0 $36
R1 $A0
R2 $FF
R3 $FF
R4 $FF
R5 $FF
R6 $FB
R7 $00
R8 $00
R9 $00
R10 $FF

(according to the software ref. manual, p. 18).
-------

Anyway, thank you guys. And thank you MrD for reviewing my actual code!

Author	Message
hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Homebrew on a real system? Background tiles messed up... Posted: Wed May 01, 2013 6:10 pm
	Hello. I tinker around with a homebrew sidescroller beat 'em up. Well, at least that is the idea - by now I can design a level background and step through it left or right in 8 pixel steps. I write my code in a text editor (Context), and compile it with WLA-DX and run it in MEKA, following the setup laid out in Maxim's lesson 1 tutorial. In MEKA everything is fine (my stuff actually works!). When I copy the .sms file to my SD card holding a lot of other ROMS, and boot into it via my Master Everdrive cartridge on my real system (SMS I), the graphics are all wrong. But I can see that the 'game' still responds to the joystick, so I'm guessing that there is something about the graphics/tiles/tilemap I'm not taking into account.Are there any known graphics issues with regards to running homebrew games in MEKA compared to a real system? By the way, I think I have found a nice way to work with Photoshop as a kind of tilebased level editor. I will do a post on it when I'm a little deeper into the project. pp7.zip (5.67 KB)

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Wed May 01, 2013 6:28 pm
	I guess you end up updating VRAM in the middle of active display when the VDP can only receive some 10 writes per line. Try adding some delays between VRAM writes or make sure that VRAM writes only happen during blanking period where you can push data as fast as possible.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed May 01, 2013 8:31 pm
	Hi TmEE - thank you for your suggestion. It is not as if the background wobbles or flickers like when writing too much too fast to VRAM during i.e. scrolling. My game does not even scroll yet. It just steps 8 pixels either left or right. New tiles are written to every position on the screen map. Then it waits for another user move. I use Maxim's function to write to VRAM: WriteToVRAM: -:ld a,(hl) out ($be),a inc hl dec bc ld a,c or b jp nz,- ret I cannot describe what it looks like. The tiles are jumbled, but mostly totally destroyed or missing (on the screen - when I try it out on my real machine). In MEKA there are no problems.??

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Wed May 01, 2013 9:26 pm
	When you write too fast to the VRAM you will experience skipped writes and most emulators do not emulate this behaviour. When you try the game on Emukon you'll experience something similiar to what you do on real hardware. Tho code you posted can manage whole lot more than 10 writes per line, which means in active scan it will overflow the buffer of VDP and that results in skipped writes.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed May 01, 2013 9:38 pm
	OK - thank you. I will try it in Emukon and see what happens. EDIT: Emukon is the same as MEKA. Everything seems to be working here.??

Bock Site Admin Joined: 08 Jul 2001 Posts: 8652 Location: Paris, France	Posted: Wed May 01, 2013 11:27 pm
	How are the graphics wrong? Can you post a picture of the screen on a real system?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu May 02, 2013 7:10 am
	I seem to remember that this is an optional feature in Emukon. Also, it logs messages to its message window when the writes are too fast, even if its emulated corruption seems less bad than on a real system.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Thu May 02, 2013 9:10 pm
	Bock wrote How are the graphics wrong? Can you post a picture of the screen on a real system? Im sorry, I have tried and tried, but the forum wont let me post the pic (jpeg or png, small size). Maybe the problem has to do with my Everdrive? I think I will try to download some of the homebrew games from here, and then test them in the Everdrive to see if they run OK...

olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	Posted: Thu May 02, 2013 11:57 pm
olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	Upload it on http://www.imgur.com or http://www.minus.com until Maxim turns on your image posting privileges.

Mr New User Joined: 03 May 2013 Posts: 1	Posted: Fri May 03, 2013 5:07 am
Mr New User Joined: 03 May 2013 Posts: 1	You should be able to post image attachments as a new user. It's the links to imgur etc that are blocked. PhantasyStar-SMS-KR-6.png (2.16 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Fri May 03, 2013 5:12 am
	That was me testing what I thought to be the case.

MrD Joined: 25 May 2012 Posts: 32	Posted: Fri May 03, 2013 11:54 am Last edited by MrD on Fri May 03, 2013 2:38 pm; edited 8 times in total
MrD Joined: 25 May 2012 Posts: 32	I'm getting wildly different results with Fusion 3.64, Meka 0.80, Emukon 1.05 and Mednafen 0.9.28. I've attached these screenshots. Hmm... I can tell you that you haven't initialised map_counter. You should treat the RAM as having random values, and clear it manually when your program starts. (I made the exact same mistake exactly a year ago today!) Initialise map_counter to zero and that satisfies all the emulators... except Mednafen. Weird. When you scroll the map in Mednafen, I can see a bunch of pixels moving around in the bottom left corner. It looks like what happens when you display the entire contents of VRAM (including tile indices and sprite attribute table) as tile graphic data, so I think the VDP register that controls where the tile indices are read from ("Register $02 - Name Table Base Address" in the vdp register doc) isn't set up right. Edit - Yep, that's solved it. You should initialise all the VDP registers when your game starts otherwise you'll get a mangled display on almost any hardware. Like the RAM, these registers are left in a messy state due to the BIOS/startup stuff. Near where you've written ; turn screen on, set various bits (please refer to the manual p. 15) Add the following: ld a, %11111111 out (VDP_command), a ld a, $82 out (VDP_command), a This sets the mask bits of VDP Register 2 to all 1s. This causes the name table base address (where the tile indices are read from) to be at $3800 in VRAM. emukon_1_05.png (1.82 KB) meka_0_80.png (3.59 KB) fusion_3_64.png (776 B) mednafen_0_9_28.png (2.17 KB)

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Fri May 03, 2013 12:02 pm
	Maybe you have VBL handler touching the VDP while you mess with it in the main code (or the other way)...? That is not really the case when the corruption is mostly consistent.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sat May 04, 2013 7:13 pm Last edited by hang-on on Sat May 04, 2013 8:34 pm; edited 1 time in total
	Yo guys are amazing!!! Thank you so much for the detailed feedback. I can't wait for Monday to come, so that I can go to my workplace and try out your detailed suggestions, MrD. Yes - I have all my SEGA stuff on my Windows computer at work, as we are all Mac's at home :) - not that my work even remotely has something to do with Z80 or programming in general, anyway :) Maxim - sorry, I think I made a mistake when I tried to upload a photo. I misjudged the file size. Now it seems to be working, and as you all can see, MrD's screenshots are pretty close to what I experience on my real system. EDIT: Thank you for your image-optimizing assistance, Maxim :) Those pesky high-res smartphone cameras... tv_948.jpg (73.71 KB) My stuff on the TV

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat May 04, 2013 8:25 pm
	You're still doing it wrong :) Photos should be JPG, images for the web should be lower resolution... I changed your attachment from 1.25MB to 74KB.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Solved: Must initialize variables Posted: Mon May 06, 2013 6:43 pm
	Succes! The problem was caused by me just assuming that my variable map_counter contains $0000 from the start. Wow!!! Now it works on my real system too! This is so..... great! A small step for mankind, but a giant leap for me. I also tried to initialize VDP register 2 to $FF, but it makes no difference. Could it be that Mednafen does not emulate how VDP registers are initialized at power on: ------ The VDP registers are initialized at power on to the following values: R0 $36 R1 $A0 R2 $FF R3 $FF R4 $FF R5 $FF R6 $FB R7 $00 R8 $00 R9 $00 R10 $FF (according to the software ref. manual, p. 18). ------- Anyway, thank you guys. And thank you MrD for reviewing my actual code!

Forums

View topic - Homebrew on a real system? Background tiles messed up...