Forums

Hello everyone,
I'm having fun coding a little snake game in assembler.
At first, I used MEKA as an emulator for debug my code in runtime without any problem.

See meka.png image

But switching to Emulicious, I've seen bugs with my graphics.
These bugs seems to only apply in my init function but not during the gameplay where I refresh the snake tiles.

See emulicious.png image

My init function does in this order:
- Disable interrupt;
- Flush RAM and VRAM;
- Setup VDP registers;
- Loading COLOR RAM and tiles in memory;
- Init default values in variables;
- Enable interrupt and jump to the main loop;

Reading the official documentation and some topics, I seen there is different timing constraint accessing the VDP.

My first mistake was: when I setup the VDP register, I enable the display through the VDP Register 1 and after I load the palette in CRAM and tiles in memory.

But the official documentation said:
The VDP chip cannot process data any faster than the following rates:
16 Z80A T-States during VBLANK
29 Z80A T-States during active video.

So by default, when setting up VDP registers, the display is disabled and I only enable it just before enable interrupt and jumping in the main loop.

Working well.

But now I tried on a real hardware (Sega Master System 2 PAL) with an "Krikzz Everdrive X7" and same bugs reappears again.

See realhardware.png image

It seems that the option "Emulate VDP constraints" in Emulicious is not available anymore (or now by default), but how to be sure to respect contraints of the VDP on real hardware ?

I added 'nop' instruction between two 'out' without any improvement.
Do you have any ideas on how to do this ?

meka.png (9.43 KB)

emulicious.png (20.56 KB)

realhardware.png (1.47 MB)

yes, it looks like you're writing too quickly to VRAM

note that it's the distance between successive data writes and between the last data and the next time you set the address that needs to be 'slow enough'

also, if the display is OFF, you shouldn't see any of these problems, but they might happen if an interrupt happens between your writes - note that you might have the screen OFF and the VDP interrupt(s) on anyway

hard to tell without seing any part of your code...

maybe you expect the display to be OFF but it isn't?
I would suggest you to reset all the VDP registers when you start to these values:

0x04, /* reg0: Mode 4 */
0x20, /* reg1: display OFF - frame int (vblank) ON */
0xFF, /* reg2: PNT at 0x3800 */
0xFF, /* reg3: should always be 0xFF with mode 4 */
0xFF, /* reg4: should always be 0xFF with mode 4 */
0xFF, /* reg5: SAT at 0x3F00 */
0xFF, /* reg6: Sprite tiles at 0x2000 */
0x00, /* reg7: backdrop color (zero) */
0x00, /* reg8: scroll X (zero) */
0x00, /* reg9: scroll Y (zero) */
0xFF /* regA: line interrupt count (offscreen) */

but Calindro is surely interested in seing a program that behaves differently on hardware than what does on Emulicious :)

Hi,

I pushed the code on a github repository.
it's not finished, so there are bugs and the implementation isn't clean yet.

But good enough to try on real hardware:
https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1

I tried with your VDP registers values without any success.

My program start with the instruction 'DI' and the init function finished with the instruction 'EI' but do I need to disable the VBlank Interrupt by setting the 5th bit on the VDP Register 1 ?

I can't find any clear culprit here - I mean, sure the code needs some love but I can't spot any reason why parts of that border should not appear... and they in fact appear even in Emulicious, which leaves only one option IMHO...
Though I don't have one, I know the Master EverDrive X7s have some advanced functions (listed as "Save States function and In-Game menu function") and I suspect they might disturb in some situations, so try turning them off, and let's see if something changes.

I've just had a cursory glance, no time yet to run it, but looks like you're not using sprites but I can't immediately see any place you are disabling them or putting them offscreen, although I could easily have overlooked it if you are.

Anyway, if there are sprites being rendered, they could be landing over the border? Still can't explain why that would appear on ED but not Emulicious. I was thinking some different initial palette values on ED but that doesn't make any sense.

EDIT: actually scratch that, you are zeroing out the whole of VRAM so at least all the sprites should appear in the same place which doesn't explain why there are a few gaps in the border.

Hi,

As this is the first time I've developed on this console and coded in assembler, I figured that a snake was pretty simple and didn't require sprites at all, only draw tiles in right place (no pixel displacement).

I really think it's a problem about writting the VDP too quickly, because I have two Sega Master System 2 :
- One OG without any modification;
- One custome for switching 50/60hz.

Clearly, in 60hz I have more artefacts than in 50hz.
And, in 50hz, I have the same artefacts on the OG SMS or the custome one.

Also, I check the Everdrive X7 and try with or without the In-Game menu function but no success.

50hz.png (618.19 KB)

60hz.png (626.38 KB)

this is quite weird but to verify if you're indeed writing too fast (which would make sense ONLY if the display was ON, as far as we know) let's add a few NOPs (SIX of them is fine) in the code after the OUT at line 660
https://github.com/Allard-Chris/SMS_Snake_Game/blob/main/src/main.asm#L660

Adding 6 'nop' after the line 660 solved the problem, whether in 50 or 60 hz on the hardware !

So, timing doesn't seem to be an exact science, and it may just be a problem for the European model of the Sega Master System 2.

However, isn't it a bit odd to have to do this? Does it have to be done after each VDP writing ?

good.png (629.74 KB)

meme.jpg (117.51 KB)

Come to think of it, it's strange to have such a long writing constraints while the display is disabled when drawing borders.

KingQuack wrote

Come to think of it, it's strange to have such a long writing constraints while the display is disabled when drawing borders.

Yeah it doesn't sound right at all, I'm as baffled as sverx. By all accounts, you should need no NOPs at all with the display off, let alone six or so of them! Bear in mind you already have a LD instruction inbetween writes which ought to easily be enough.

I've tried your game on Emulicious now (cute game BTW!) and can confirm the display is indeed off for the entire border writing routine.
I can also confirm that no interrupts appear to be happening to interrupt the routine.

It's also strange that you don't see any problems outside of the border writing routine.

I'm starting to suspect some aberrant hardware here, either the base system is operating out of tolerance — unlikely, because you have two which both exhibit the same behaviour — or the Everdrive is injecting some delay, or some additional interrupts. I know nothing about Everdrives but this seems plausible.
Does the ED intercept and regenerate an NMI for a custom pause handler? If so, I wonder whether that could be causing a problem. You might try making your NMI routine actually do something to see if it's firing when you don't expect it to.

With these NOPs we are complying with the access times needed when the screen is ON, which doesn't make much sense here but...

KingQuack wrote

So, timing doesn't seem to be an exact science, and it may just be a problem for the European model of the Sega Master System 2.

I suspect that's just like the model I have, and we (should) have enough knowledge regarding this hardware to say that there's something strange going on. BTW you can run the SMS Test Suite to verify which VDP model / CPU / BIOS you have - again I don't suspect anything peculiar here.

I still suspect the Master Everdrive is doing something that breaks this - either interfering with interrupts or with the VDP operations.

willbritton wrote

Yeah it doesn't sound right at all, I'm as baffled as sverx. By all accounts, you should need no NOPs at all with the display off, let alone six or so of them! Bear in mind you already have a LD instruction inbetween writes which ought to easily be enough.

When the display is OFF or you're in vBlank, you can't really write too fast - even if you use a block of 'OUT (N),A' (11 cycles) none of them will fail. I'm pretty sure I even tested that once. When the display is on and during vDraw, you need at least 26 cycles delay between the writes (if we talk SMS only) with the LD operation there and 6× NOP we already get to 28 cycles even not counting the OUT operation itself, so it's safe in every situation.

I'm baffled but I suspect if we could remove the EverDrive from the equation we would not see this.

edit: it would all make sense if at some point the EverDrive turned the screen ON - unfortunately we can't read the VDP registers and see if that happened.

sverx wrote

edit: it would all make sense if at some point the EverDrive turned the screen ON - unfortunately we can't read the VDP registers and see if that happened.

Oh that's interesting!

You could, of course, try and test this indirectly by setting R1 to turn the display off immediately before starting the border routine.
If that fixes it, I think that's got to be the explanation.

As i've tested with DMA (direct writing to the VDP bypassing the Z80) i can write nearly 2.4x faster than OUTI before corruption. (transfered more than x50 tiles - 32 bytes - in vblank @60hz)

So you can't write too fast with basic Z80 instructions if done in vblank / screen off

willbritton wrote

You could, of course, try and test this indirectly by setting R1 to turn the display off immediately before starting the border routine.
If that fixes it, I think that's got to be the explanation.

Yes, he could try calling the VDP initialization function once again right before line 111, where he calls the function that draws the field, and remove those 6 NOPs - it might actually work.

KingQuack wrote

Hi,

I pushed the code on a github repository.
it's not finished, so there are bugs and the implementation isn't clean yet.

But good enough to try on real hardware:
https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1

I tried with your VDP registers values without any success.

My program start with the instruction 'DI' and the init function finished with the instruction 'EI' but do I need to disable the VBlank Interrupt by setting the 5th bit on the VDP Register 1 ?

In Emulicious's Debugger find the Exceptions tab at the bottom. You will want to enable all/most of them while developing. To avoid common mistakes such as accessing the VDP too fast or relying on uninitialized memory.

I can test with my fruggal mapper card, and see if I still see the corruption.

kusfo wrote

I can test with my fruggal mapper card, and see if I still see the corruption.

please, do! :)

It's really strange, this morning I carried out new tests and it was impossible to reproduce the problem...
I tried on both hardware, with the first version of the rom released on the github repository, and all seems to works.
I tried with the ED with and without the "In-Game Menu" option, 50 and 60hz.

As a reminder, the first released is:
- Screen disabled when the VDP Registers are initialized and before drawing the field.
- Without the 6 'nop' in the function that draw the field.
- Screen enabled after the field has been drawn.

The second release on the github repository just add a color swap when the Pause button is pressed (to check any unexpected NMI interrupt).

So there are several possibilities:
- Human error (most likely). I need to perform an MD5 checksum at compiling to be sure which rom version is on the SD Card now.
- Something going on with my SD card.
- Oxidation on cartridge contacts ? Which can create delays. And by inserting the cartridge several times between yesterday and today, contacts are made more easily.

In any case, thank you all for answering my questions and providing many clues as to the origin of the problem.
Be sure that if I have any further information or if the problem recurs, I'll continue this thread.

sms_test_suite.png (736.77 KB)

Well...glad you got it sorted in the end!

KingQuack wrote

- Oxidation on cartridge contacts ? Which can create delays. And by inserting the cartridge several times between yesterday and today, contacts are made more easily.

Although for sure a thing, unlikely to be the culprit here since you were only seeing corruptions when drawing the border area and (I assume) you were seeing it consistently, rather than intermittently.
Problems due to cartridge contact tend to be very generalised and usually prove terminal early into system boot.

willbritton wrote

Although for sure a thing, unlikely to be the culprit here since you were only seeing corruptions when drawing the border area and (I assume) you were seeing it consistently, rather than intermittently.

You're right !

The only way to reproduce the bug again is to enable the screen when initializing VDP registers and after that draw the edges.
So all the evidence suggests that this was a mistake I made with the versions of the rom on the SD card.

Which strikes me as odd because screen management was something I was aware of, even before creating this topic.

Should I still try on a board, or it's already clarified?

Only if it's not something that consumes your whole afternoon.
I don't want to waste your time on it, it's already very kind to suggest it.
I'd be curious to confirm that the first version of the ROM works without any delay: https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1

KingQuack wrote

The only way to reproduce the bug again is to enable the screen when initializing VDP registers and after that draw the edges.
So all the evidence suggests that this was a mistake I made with the versions of the rom on the SD card.

I think it's important that we verified that the cause wasn't the EverDrive messing with the VDP (and that our knowledge about how the VDP works still stands...)

sverx wrote

I think it's important that we verified that the cause wasn't the EverDrive messing with the VDP (and that our knowledge about how the VDP works still stands...)

Agree in particular about the ED, but only because it seems much less understood than the base system.

The VDP I think we are surely very confident about especially as Ichigo points out with the DMA experiments that the VDP should be able to deal with data even faster than the SMS clocked Z80 can send it, when the display is off. This also tracks with our understanding of the underlying timing slots.

Okey! I'll do it today after work!

Please, confirm the tags of the releases I've to test and the expected behaviour. My current understanding is:
v0.1 May fail in hardware
v0.1a Should work on hardware

Yep v0.1 failed on my hardware.
v0.1a only adds a routine to handle Pause Button and NMI interrupt (so it should failed too, but at the time I tested, both v0.1 and v0.1a works on my hardware today).

V0.1 worked flawlessly on Emulicious and on my PAL SMS 1

photo_2023-12-22_15-51-32.jpg (94.46 KB)

So clearly, something that I did wrong with my rom and the everdrive.
Thank you all for looking at this topic and Kusfo for taking the time to do a test on a cartridge.

Author	Message
KingQuack Joined: 15 Jul 2022 Posts: 29	VDP Timing Constraint: Meka VS Emulicious VS Everdrive Posted: Wed Dec 20, 2023 4:26 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Hello everyone, I'm having fun coding a little snake game in assembler. At first, I used MEKA as an emulator for debug my code in runtime without any problem. See meka.png image But switching to Emulicious, I've seen bugs with my graphics. These bugs seems to only apply in my init function but not during the gameplay where I refresh the snake tiles. See emulicious.png image My init function does in this order: - Disable interrupt; - Flush RAM and VRAM; - Setup VDP registers; - Loading COLOR RAM and tiles in memory; - Init default values in variables; - Enable interrupt and jump to the main loop; Reading the official documentation and some topics, I seen there is different timing constraint accessing the VDP. My first mistake was: when I setup the VDP register, I enable the display through the VDP Register 1 and after I load the palette in CRAM and tiles in memory. But the official documentation said: The VDP chip cannot process data any faster than the following rates: 16 Z80A T-States during VBLANK 29 Z80A T-States during active video. So by default, when setting up VDP registers, the display is disabled and I only enable it just before enable interrupt and jumping in the main loop. Working well. But now I tried on a real hardware (Sega Master System 2 PAL) with an "Krikzz Everdrive X7" and same bugs reappears again. See realhardware.png image It seems that the option "Emulate VDP constraints" in Emulicious is not available anymore (or now by default), but how to be sure to respect contraints of the VDP on real hardware ? I added 'nop' instruction between two 'out' without any improvement. Do you have any ideas on how to do this ? meka.png (9.43 KB) emulicious.png (20.56 KB) realhardware.png (1.47 MB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Dec 20, 2023 5:09 pm
	yes, it looks like you're writing too quickly to VRAM note that it's the distance between successive data writes and between the last data and the next time you set the address that needs to be 'slow enough' also, if the display is OFF, you shouldn't see any of these problems, but they might happen if an interrupt happens between your writes - note that you might have the screen OFF and the VDP interrupt(s) on anyway hard to tell without seing any part of your code... maybe you expect the display to be OFF but it isn't? I would suggest you to reset all the VDP registers when you start to these values: 0x04, /* reg0: Mode 4 / 0x20, / reg1: display OFF - frame int (vblank) ON / 0xFF, / reg2: PNT at 0x3800 / 0xFF, / reg3: should always be 0xFF with mode 4 / 0xFF, / reg4: should always be 0xFF with mode 4 / 0xFF, / reg5: SAT at 0x3F00 / 0xFF, / reg6: Sprite tiles at 0x2000 / 0x00, / reg7: backdrop color (zero) / 0x00, / reg8: scroll X (zero) / 0x00, / reg9: scroll Y (zero) / 0xFF / regA: line interrupt count (offscreen) */ but Calindro is surely interested in seing a program that behaves differently on hardware than what does on Emulicious :)

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Wed Dec 20, 2023 10:28 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Hi, I pushed the code on a github repository. it's not finished, so there are bugs and the implementation isn't clean yet. But good enough to try on real hardware: https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1 I tried with your VDP registers values without any success. My program start with the instruction 'DI' and the init function finished with the instruction 'EI' but do I need to disable the VBlank Interrupt by setting the 5th bit on the VDP Register 1 ?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Dec 21, 2023 8:51 am
	I can't find any clear culprit here - I mean, sure the code needs some love but I can't spot any reason why parts of that border should not appear... and they in fact appear even in Emulicious, which leaves only one option IMHO... Though I don't have one, I know the Master EverDrive X7s have some advanced functions (listed as "Save States function and In-Game menu function") and I suspect they might disturb in some situations, so try turning them off, and let's see if something changes.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Thu Dec 21, 2023 9:08 am
	I've just had a cursory glance, no time yet to run it, but looks like you're not using sprites but I can't immediately see any place you are disabling them or putting them offscreen, although I could easily have overlooked it if you are. Anyway, if there are sprites being rendered, they could be landing over the border? Still can't explain why that would appear on ED but not Emulicious. I was thinking some different initial palette values on ED but that doesn't make any sense. EDIT: actually scratch that, you are zeroing out the whole of VRAM so at least all the sprites should appear in the same place which doesn't explain why there are a few gaps in the border.

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Thu Dec 21, 2023 11:12 am
KingQuack Joined: 15 Jul 2022 Posts: 29	Hi, As this is the first time I've developed on this console and coded in assembler, I figured that a snake was pretty simple and didn't require sprites at all, only draw tiles in right place (no pixel displacement). I really think it's a problem about writting the VDP too quickly, because I have two Sega Master System 2 : - One OG without any modification; - One custome for switching 50/60hz. Clearly, in 60hz I have more artefacts than in 50hz. And, in 50hz, I have the same artefacts on the OG SMS or the custome one. Also, I check the Everdrive X7 and try with or without the In-Game menu function but no success. 50hz.png (618.19 KB) 60hz.png (626.38 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Dec 21, 2023 11:18 am
	this is quite weird but to verify if you're indeed writing too fast (which would make sense ONLY if the display was ON, as far as we know) let's add a few NOPs (SIX of them is fine) in the code after the OUT at line 660 https://github.com/Allard-Chris/SMS_Snake_Game/blob/main/src/main.asm#L660

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Thu Dec 21, 2023 12:03 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Adding 6 'nop' after the line 660 solved the problem, whether in 50 or 60 hz on the hardware ! So, timing doesn't seem to be an exact science, and it may just be a problem for the European model of the Sega Master System 2. However, isn't it a bit odd to have to do this? Does it have to be done after each VDP writing ? good.png (629.74 KB) meme.jpg (117.51 KB)

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Thu Dec 21, 2023 12:32 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Come to think of it, it's strange to have such a long writing constraints while the display is disabled when drawing borders.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Thu Dec 21, 2023 1:01 pm
	KingQuack wrote Come to think of it, it's strange to have such a long writing constraints while the display is disabled when drawing borders. Yeah it doesn't sound right at all, I'm as baffled as sverx. By all accounts, you should need no NOPs at all with the display off, let alone six or so of them! Bear in mind you already have a LD instruction inbetween writes which ought to easily be enough. I've tried your game on Emulicious now (cute game BTW!) and can confirm the display is indeed off for the entire border writing routine. I can also confirm that no interrupts appear to be happening to interrupt the routine. It's also strange that you don't see any problems outside of the border writing routine. I'm starting to suspect some aberrant hardware here, either the base system is operating out of tolerance — unlikely, because you have two which both exhibit the same behaviour — or the Everdrive is injecting some delay, or some additional interrupts. I know nothing about Everdrives but this seems plausible. Does the ED intercept and regenerate an NMI for a custom pause handler? If so, I wonder whether that could be causing a problem. You might try making your NMI routine actually do something to see if it's firing when you don't expect it to.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Dec 21, 2023 1:56 pm Last edited by sverx on Thu Dec 21, 2023 2:21 pm; edited 1 time in total
	With these NOPs we are complying with the access times needed when the screen is ON, which doesn't make much sense here but... KingQuack wrote So, timing doesn't seem to be an exact science, and it may just be a problem for the European model of the Sega Master System 2. I suspect that's just like the model I have, and we (should) have enough knowledge regarding this hardware to say that there's something strange going on. BTW you can run the SMS Test Suite to verify which VDP model / CPU / BIOS you have - again I don't suspect anything peculiar here. I still suspect the Master Everdrive is doing something that breaks this - either interfering with interrupts or with the VDP operations.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Dec 21, 2023 2:04 pm
	willbritton wrote Yeah it doesn't sound right at all, I'm as baffled as sverx. By all accounts, you should need no NOPs at all with the display off, let alone six or so of them! Bear in mind you already have a LD instruction inbetween writes which ought to easily be enough. When the display is OFF or you're in vBlank, you can't really write too fast - even if you use a block of 'OUT (N),A' (11 cycles) none of them will fail. I'm pretty sure I even tested that once. When the display is on and during vDraw, you need at least 26 cycles delay between the writes (if we talk SMS only) with the LD operation there and 6× NOP we already get to 28 cycles even not counting the OUT operation itself, so it's safe in every situation. I'm baffled but I suspect if we could remove the EverDrive from the equation we would not see this. edit: it would all make sense if at some point the EverDrive turned the screen ON - unfortunately we can't read the VDP registers and see if that happened.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Thu Dec 21, 2023 2:21 pm
	sverx wrote edit: it would all make sense if at some point the EverDrive turned the screen ON - unfortunately we can't read the VDP registers and see if that happened. Oh that's interesting! You could, of course, try and test this indirectly by setting R1 to turn the display off immediately before starting the border routine. If that fixes it, I think that's got to be the explanation.

ichigobankai Joined: 04 Jul 2010 Posts: 542 Location: Angers, France	Posted: Thu Dec 21, 2023 2:25 pm
	As i've tested with DMA (direct writing to the VDP bypassing the Z80) i can write nearly 2.4x faster than OUTI before corruption. (transfered more than x50 tiles - 32 bytes - in vblank @60hz) So you can't write too fast with basic Z80 instructions if done in vblank / screen off

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Dec 21, 2023 2:44 pm
	willbritton wrote You could, of course, try and test this indirectly by setting R1 to turn the display off immediately before starting the border routine. If that fixes it, I think that's got to be the explanation. Yes, he could try calling the VDP initialization function once again right before line 111, where he calls the function that draws the field, and remove those 6 NOPs - it might actually work.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Dec 22, 2023 7:47 am
Calindro Joined: 14 Apr 2013 Posts: 624	KingQuack wrote Hi, I pushed the code on a github repository. it's not finished, so there are bugs and the implementation isn't clean yet. But good enough to try on real hardware: https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1 I tried with your VDP registers values without any success. My program start with the instruction 'DI' and the init function finished with the instruction 'EI' but do I need to disable the VBlank Interrupt by setting the 5th bit on the VDP Register 1 ? In Emulicious's Debugger find the Exceptions tab at the bottom. You will want to enable all/most of them while developing. To avoid common mistakes such as accessing the VDP too fast or relying on uninitialized memory.

kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Posted: Fri Dec 22, 2023 8:22 am
kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	I can test with my fruggal mapper card, and see if I still see the corruption.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Dec 22, 2023 11:28 am
	kusfo wrote I can test with my fruggal mapper card, and see if I still see the corruption. please, do! :)

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Fri Dec 22, 2023 12:11 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	It's really strange, this morning I carried out new tests and it was impossible to reproduce the problem... I tried on both hardware, with the first version of the rom released on the github repository, and all seems to works. I tried with the ED with and without the "In-Game Menu" option, 50 and 60hz. As a reminder, the first released is: - Screen disabled when the VDP Registers are initialized and before drawing the field. - Without the 6 'nop' in the function that draw the field. - Screen enabled after the field has been drawn. The second release on the github repository just add a color swap when the Pause button is pressed (to check any unexpected NMI interrupt). So there are several possibilities: - Human error (most likely). I need to perform an MD5 checksum at compiling to be sure which rom version is on the SD Card now. - Something going on with my SD card. - Oxidation on cartridge contacts ? Which can create delays. And by inserting the cartridge several times between yesterday and today, contacts are made more easily. In any case, thank you all for answering my questions and providing many clues as to the origin of the problem. Be sure that if I have any further information or if the problem recurs, I'll continue this thread. sms_test_suite.png (736.77 KB)

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Fri Dec 22, 2023 12:34 pm
	Well...glad you got it sorted in the end! KingQuack wrote - Oxidation on cartridge contacts ? Which can create delays. And by inserting the cartridge several times between yesterday and today, contacts are made more easily. Although for sure a thing, unlikely to be the culprit here since you were only seeing corruptions when drawing the border area and (I assume) you were seeing it consistently, rather than intermittently. Problems due to cartridge contact tend to be very generalised and usually prove terminal early into system boot.

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Fri Dec 22, 2023 12:48 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	willbritton wrote Although for sure a thing, unlikely to be the culprit here since you were only seeing corruptions when drawing the border area and (I assume) you were seeing it consistently, rather than intermittently. You're right ! The only way to reproduce the bug again is to enable the screen when initializing VDP registers and after that draw the edges. So all the evidence suggests that this was a mistake I made with the versions of the rom on the SD card. Which strikes me as odd because screen management was something I was aware of, even before creating this topic.

kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Posted: Fri Dec 22, 2023 12:53 pm
kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Should I still try on a board, or it's already clarified?

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Fri Dec 22, 2023 12:56 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Only if it's not something that consumes your whole afternoon. I don't want to waste your time on it, it's already very kind to suggest it. I'd be curious to confirm that the first version of the ROM works without any delay: https://github.com/Allard-Chris/SMS_Snake_Game/releases/tag/v0.1

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Dec 22, 2023 1:02 pm
	KingQuack wrote The only way to reproduce the bug again is to enable the screen when initializing VDP registers and after that draw the edges. So all the evidence suggests that this was a mistake I made with the versions of the rom on the SD card. I think it's important that we verified that the cause wasn't the EverDrive messing with the VDP (and that our knowledge about how the VDP works still stands...)

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Fri Dec 22, 2023 1:07 pm
	sverx wrote I think it's important that we verified that the cause wasn't the EverDrive messing with the VDP (and that our knowledge about how the VDP works still stands...) Agree in particular about the ED, but only because it seems much less understood than the base system. The VDP I think we are surely very confident about especially as Ichigo points out with the DMA experiments that the VDP should be able to deal with data even faster than the SMS clocked Z80 can send it, when the display is off. This also tracks with our understanding of the underlying timing slots.

kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Posted: Fri Dec 22, 2023 1:08 pm
kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Okey! I'll do it today after work! Please, confirm the tags of the releases I've to test and the expected behaviour. My current understanding is: v0.1 May fail in hardware v0.1a Should work on hardware

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Fri Dec 22, 2023 1:27 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	Yep v0.1 failed on my hardware. v0.1a only adds a routine to handle Pause Button and NMI interrupt (so it should failed too, but at the time I tested, both v0.1 and v0.1a works on my hardware today).

kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	Posted: Fri Dec 22, 2023 2:52 pm
kusfo Joined: 29 Mar 2012 Posts: 886 Location: Spain	V0.1 worked flawlessly on Emulicious and on my PAL SMS 1 photo_2023-12-22_15-51-32.jpg (94.46 KB)

KingQuack Joined: 15 Jul 2022 Posts: 29	Posted: Fri Dec 22, 2023 3:17 pm
KingQuack Joined: 15 Jul 2022 Posts: 29	So clearly, something that I did wrong with my rom and the everdrive. Thank you all for looking at this topic and Kusfo for taking the time to do a test on a cartridge.

Forums

View topic - VDP Timing Constraint: Meka VS Emulicious VS Everdrive