"Sparkling" sprites - presumably when DMA-ing from ROM

[Matt Phillips]

I'm seeing artefacts on animated sprites in Sonic 3, Sonic 3D, Mega Turrican and Tanglewood. Videos here:

https://www.dropbox.com/s/0laigjb9eg4vn9e/MOV_1616.mp4?dl=0

https://www.dropbox.com/s/kpcfhvv04sn1jzg/MOV_1617.mp4?dl=0

https://www.dropbox.com/s/qtrwm9bc1yecv60/MOV_1618.mp4?dl=0

https://www.dropbox.com/s/a2vvefcih3r00qf/MOV_1620.mp4?dl=0

https://www.dropbox.com/s/q5jw8a3lobeqi5n/MOV_1621.mp4?dl=0

This sort of thing is usually caused by slow ROM read speeds, and all the games here DMA sprite frames direct from cart. Sonic 1 doesn't show this behaviour, presumably because it decompresses art into RAM before DMA-ing to VRAM. My Cross Products kit does this, and I have to build without DMA support to debug on it.

Is the flash ROM too slow, or is the problem elsewhere?

[Chris McClelland]

This looks like a problem already reported on SpritesMind[1]. IIRC that was tracked down to noisy/bouncy signals on the MD1 bus, causing the address lines to remain in flux after /OE has asserted[1]. Unfortunately I don't know of any way to fix it; the timing is already very tight on DMA cycles so more debounce logic would likely break things, and the clock-domain SDRAM-controller optimization I proposed in [3] turned out to need board-level changes to the LX9 PCB, so I never got around to attempting it, and I have not heard from anyone else who has tried it. In the end[4] we basically wrote off the MD1 as an unsupported platform. I have never heard of any MD2, MD3 or Nomad users having this problem.

Chris

[1]http://gendev.spritesmind.net/forum/viewtopic.php?f=20&t=2324
[2]http://gendev.spritesmind.net/forum/viewtopic.php?f=20&t=2239&p=28599&hilit=trace#p28599
[3]http://gendev.spritesmind.net/forum/viewtopic.php?f=20&t=2324#p28859
[4]http://gendev.spritesmind.net/forum/viewtopic.php?f=20&t=2324&start=15#p29360

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Phillips]

This is on an MD 2 PAL. I could give a few other machines a try to see if it happens on more.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.

[Tasos Sahanidis]

If you have a SEGA/MEGA CD, try plugging it in. I know at least the model 2 has RC filters on the data lines which tend to help the situation.

Speaking of noise, this is what I get with my UMDK on a VA 1.8 Genesis 2.
https://vps.tasossah.com/.autoindex/umdk/umdk_overdrive.mp4

[Matt Phillips]

Well, plugging in the MegaCD may have shed some light on the problem at least:

http://m.imgur.com/npjtFFw

I'll try Sonic 3 from an actual cart and see if all is fine.

[Chris McClelland]

Without first checking to see if the UMDK design (i.e the VHDL[1]) doesn't clash in some way with the Mega-CD, I would not recommend doing it.

Chris Smith proposed a great idea which has not yet been done: make a big table with machine descriptions on the horizontal (i.e one column would be labelled "Tasos's VA 1.8 Genesis 2") and games/ROMs on the vertical (i.e one row would be labelled "Sonic 1") and each cell would be a description of the problems seen running that particular game on that particular console, with video links, etc. That way, we get to see if any patterns emerge, that could give a hint as to what's wrong.

Chris

[1]https://github.com/makestuff/umdkv2/tree/20170319/vhdl

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[csmith]

Hi Chris,

do you want this table of UMDK compatibilities to be on the project's or would you like me to add a Wiki to Zako-Factory [1].

ZF is run by some of us.

[1] http://www.zako-factory.org/

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.

[Matt Phillips]

My MegaCD glitch was a red herring, it worked fine after disassembling and reassembling it.

Same issue with MCD connected (sprites sparkle) and the issue isn't present on a retail Sonic 3 so I don't think it's a console fault.

I'll add my machines to that chart.

On Saturday, 25 March 2017 11:11:33 UTC, mintythecat wrote:

Hi Chris,

do you want this table of UMDK compatibilities to be on the project's or would you like me to add a Wiki to Zako-Factory [1].

ZF is run by some of us.

[1] http://www.zako-factory.org/

On 25/03/17 12:08, Chris McClelland wrote:

Without first checking to see if the UMDK design (i.e the VHDL[1]) doesn't clash in some way with the Mega-CD, I would not recommend doing it.

Chris Smith proposed a great idea which has not yet been done: make a big table with machine descriptions on the horizontal (i.e one column would be labelled "Tasos's VA 1.8 Genesis 2") and games/ROMs on the vertical (i.e one row would be labelled "Sonic 1") and each cell would be a description of the problems seen running that particular game on that particular console, with video links, etc. That way, we get to see if any patterns emerge, that could give a hint as to what's wrong.

Chris

[1]https://github.com/makestuff/umdkv2/tree/20170319/vhdl

On 25 March 2017 at 11:05, Matt Phillips <mattph...@mail.com> wrote:

Well, plugging in the MegaCD may have shed some light on the problem at least:

http://m.imgur.com/npjtFFw

I'll try Sonic 3 from an actual cart and see if all is fine.

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris McClelland]

GitHub markdown doesn't lend itself very well to vary large tables (which this is likely to be), and permissioning it so anyone can edit it is always tricky. TBH it doesn't matter where it lives, as long as it's easily accessible and easily editable. By all means create it for now on ZF.

[Chris McClelland]

FWIW, Sonic 3 works flawlessly on my PAL MD2 + self-built UMDK cart. Sometimes I do have to clean contacts and insert the UMDK cart several times, which supports the theory that the edge-connector contacts should ideally be finished in hard gold. But that's a minor inconvenience: once good connections have been established, they remain good.

I assume you've been through the testing and verification procedure (especially the "sigtest" MD5-compare) in the wiki?

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Matt Phillips]

I've run through everything except the sigtest, still can't build the MD ROMs properly (sigtest bin, firmware) under latest GCC+SGDK.

I can build GCC with a few modifications, and "build" the ROMs by adding _hard_reset to sega.s and fixing up some renamed enums, but there's some logic errors in there somewhere I haven't yet tracked down.

I have another spare laptop, so I'll throw Debian Jessie on it later and run through it all again.

[Chris McClelland]

You don't need to build anything from source, at least not until everything works and you're ready to start hacking. In the wiki[1], the sigtest.bin is just downloaded, as a compressed blob:

wget -qO- http://tiny.cc/umdk-sigtest | bunzip2 > sigtest.bin

Aside from that, if you're running your own hacked version of things, it will be extremely difficult for me to help you.

[1]https://github.com/makestuff/umdkv2/wiki/Getting-Started#basic-signal-test

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Matt Phillips]

Ah I didn't notice that. This was from back when the links were broken; I was building everything myself.

I'm half-way through a Jessie install *anyway* so that we're all on the same page.

Also off to the shop to get a new voltmeter, mine was stored in a damp garage for a year and it's seen better days :(

[Tasos Sahanidis]

I can confirm the game works fine with no glitches on my VA6 MD1.

https://vps.tasossah.com/.autoindex/umdk/s3k.png

I also had a look at the bridge board schematic. I can see that the CART_IN pin is shorted to GND, so I don't see how the Mega CD could affect the umdk logic, unless of course I am missing something.

You received this message because you are subscribed to a topic in the Google Groups "UMDKv2 Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/umdkv2-dev/rcehoBJcBKE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to umdkv2-dev+...@googlegroups.com.

[Matt Phillips]

Excellent! Hopefully that means the problem is me or my Mega Drive(s), and not the kit.

To unsubscribe from this group and all its topics, send an email to umdkv2-dev...@googlegroups.com.

[Chris McClelland]

Regular cartridges use the C_CE line on the cartridge-port, which without a Mega-CD attached will assert for accesses to the 4MiB region 0x000000-0x3FFFFF, but with a Mega-CD attached will assert for accesses to the 4MiB region 0x400000-0x7FFFFF. But UMDK does not use C_CE at all, it just decodes the addresses, thus allowing it to map stuff into the full 8MiB region 0x000000-0x7FFFFF. So with a Mega-CD and a UMDK attached, there will be no arbitration for reads from the lower 4MiB region 0x000000-0x7FFFFF: both the Mega-CD and the UMDK will drive the data-bus at the same time. Perhaps one of them will "win", and you'll see something sensible. But given time (maybe an hour, maybe a year), the line-drivers in one or the other will die under the strain of endlessly fighting. Hence my suggestion to look at the VHDL, because that's the unambiguous definition of what the UMDK does under any circumstances.

To unsubscribe from this group and all its topics, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Chris McClelland]

Sorry, that should have been, "there will be no arbitration for reads from the lower 4MiB region 0x000000-0x3FFFFF"...

[Tasos Sahanidis]

Ah, I see now.

Apologies, not that famliar with this side of the hardware yet, only just starting out.

To unsubscribe from this group and all its topics, send an email to umdkv2-dev+...@googlegroups.com.

[Chris McClelland]

No apology necessary - we're ALL learning, after all. Also, the MegaCD problem is not at all obvious (I had to think about it again before I could write about it). Part of the problem is that when I originally proposed the UMDK idea on SpritesMind many years ago, knowing next to nothing about the MegaDrive, asking for help from experienced people, ChrisS was the only person willing to help. Unfortunately he's more of a software guy than a hardware guy, so I basically had to deduce a lot of stuff myself, by experimentation. Unfortunately the only hardware available to me for experiments was a PAL MD2 (no other models, no MegaCD, etc). It was only after I had built a prototype which worked on my particular console that more knowledgeable people pointed out the pitfalls inherent in the design (e.g the MegaCD incompatibility). I fixed some incompatibilities when ChrisS got his own UMDK cart and tested on his VA7 MD1, and I fixed some more incompatibilities when the first production batch was organised by Montserrat. It's an ongoing battle, to try to find the bad assumptions I made in the design.

The transistor driving DTACK was originally intended for fixing the MegaCD incompatibility, whereby if the UMDK could do its own DTACK generation, I could map the monitor program into some other region of memory that would not clash with the MegaCD, but I never got around to trying that. Also that would have only solved part of the problem because there are insufficient FPGA pins to include C_CE anyway.

[Matt Phillips]

Back from town with a new voltmeter... and two new Mega Drives. Stumbled across them in a second hand store! The more the merrier.

My Debian installation has also finished, so I'm fully *fully* prepared now. Let's start the whole thing again from the top.

How do I identify the boards? I'll test on all of them.

[Matt Phillips]

Ok, all done, the firmware boots.

I've tested on every (working) Mega Drive in the house, including the two new ones I bought today. Wildly different behaviours, but I've found two that present minimal problems so I can use them for development - they're MD1 VA4's with socketed CPUs (used for dev in the '90s).

My findings here: https://docs.google.com/spreadsheets/d/1_ylZQYq66COgB-HraOJ2wt8OExrPcUwWc-cZ-BGDIGs/edit?usp=sharing

On Sunday, 19 March 2017 16:48:00 UTC, Matt Phillips wrote:

[Tasos Sahanidis]

Interesting how all your VA6 MD1s have issues, whereas mine works perfectly. I've only had some random hangs, but that was due to bad contacts on the console itself.
I noticed that I get much better results if the UMDK board is in an actual cart, as it doesn't wiggle around as easily.

I've tested Sonic 2, Sonic 3, S3&K, and watched all of Titan Overdrive quite a few times, without any issues.
I'll make a similar spreadsheet tomorrow and report back.

Earlier, I did probe some of the address lines on my Genesis 2, and with the UMDK attached there seemed to be a lot more noise in there. Not sure if it is the UMDK causing it, or just a bad ASIC on the console (as originally it was badly broken due to excessive noise).
Normal carts do work fine on it though, as well as the SEGA CD itself.


Also, Chris, still unsure, but in order for that issue to occur, wouldn't the Mega CD need to be initialised first? And if I am not mistaken, its bios doesn't kick in if there is a cart present, although I am aware of cases where its bios can be executed from a cart.
I really ought to find some documentation.

One last thing, any idea if such a conflict would have any apparent effects? (Other than the possibility of hardware damage.) I had the SCD hooked up before you told me about it, and I didn't notice any graphical or code execution issues, unless it's exclusive to the monitor, as I didn't have gdb set up at that point.
I would like to get this working at some point in the future, as I use the SCD for its audio output jacks.

[Chris McClelland]

The Sonic1 0x71FC6 crash appears to be very similar to the problem[1] reported by burbruee with his MD1; yours fails at 0x71FC6, his fails at 0x71FCA. IIRC the region around 0x71FC6 is the 68000 code that executes whilst the Z80 (or whatever it is) is playing the "Sega!" sample. It seems like older models have a bit of bus contention when the Z80 takes control of the bus.

I'm starting to think that it's not the model (i.e the PCB revision, etc) that introduces incompatibilities, but something else (the number of hours the machine has/has not been used, the gradual degradation of the PSU smoothing capacitors, etc). Would you be willing to sell me one of your non-working VA6s?

Chris

[1]http://gendev.spritesmind.net/forum/viewtopic.php?f=20&t=2239&hilit=address+lines&start=225#p28597

--

[Chris McClelland]

> wouldn't the Mega CD need to be initialised first? And if I am not mistaken, its bios doesn't
> kick in if there is a cart present
>

I honestly don't know. I've never even seen a MegaCD, never mind experimented with it. Is it possible to play a cart-game whilst the MegaCD is attached?

Bottom line is I didn't design the UMDK with the MegaCD in mind. It might work, it might not. I wouldn't want to try it on my hardware without first getting a good understanding of the low-level details of how the MegaCD works.

--

[Chris McClelland]

Ah yes, here it is, the "Sega!" sample code:

https://github.com/sonicretro/s1disasm/blob/master/s1.sounddriver.asm#L683-L703

[Matt Phillips]

If it helps any, here's where it crashed on Tanglewood (at 000011a8):

0000118c :                     | VDP_ClearMapPlaneA:

                               |   

                               |         ; Address bit pattern: --DC BA98 7654 3210 ---- ---- ---- --FE

0000118c : 223C @@@@ @@@@      |         move.l  #vram_addr_plane_a, d1  ; Add VRAM address offset

00001192 : E599                |         rol.l   #0x2, d1                                ; Roll bits 14/15 of add

                               + ress to bits 16/17

00001194 : E449                |         lsr.w   #0x2, d1                                ; Shift lower word back

00001196 : 4841                |         swap    d1                      ; Swap address hi/lo

00001198 : 0081 @@@@ @@@@      |         ori.l   #vdp_cmd_vram_write, d1 ; OR in VRAM write command

0000119e : 23C1 @@@@ @@@@      |         move.l  d1, vdp_control         ; Move dest address to VDP control port

                               | 

000011a4 : 303C @@@@           |         move.w  #vdp_plane_size_t, d0  ; Num words in d0, minus 1 for counter

                               |         

000011a8 :                     |         @Copy:

000011a8 : 33FC 0000 @@@@ @@@@ |         move.w  #0x0, vdp_data           ; Move to VRAM

000011b0 : 51C8 FFF6           |         dbra.w  d0, @Copy              ; Loop

                               |         

000011b4 : 4E75                |         rts

A word write to VRAM, without DMA.

If I can find another in town to replace it with during the week then I'll give up one of the VA6's, I'll get back to you.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.

[Tasos Sahanidis]

Understandable.
The MCD does not start up if there is a cart in. The only way to get it to start, is if the "cart inserted" pin is high/floating. That setup is officially used for the MCD expansion SRAM.
https://farm2.static.flickr.com/1373/4602357299_82be54bfa7_b.jpg B32 can be seen floating.

Unofficially (by putting some tape over the pin), it can be used to dump cartridges over the player 2 controller port, although I see no reason to do this with the UMDK.
See: https://www.retrodev.com/transfer.html

I'll do some research and probing when I have more time, and make a new topic with my findings.


FWIW, in the past I had to replace the 7805 regulators on my VA6 MD1, however the capacitors are all original. Not aware of any possible performance degradation on old linear regulators though.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.

[csmith]

On 26/03/17 00:02, Tasos Sahanidis wrote:
> FWIW, in the past I had to replace the 7805 regulators on my VA6 MD1,
> however the capacitors are all original. Not aware of any possible
> performance degradation on old linear regulators though.

You would know pretty quickly if you had issues with the 7805.

>
> Unofficially (by putting some tape over the pin), it can be used to
> dump cartridges over the player 2 controller port, although I see no
> reason to do this with the UMDK.

You can write to UMDK pages that can be r/w between the PC and the MD.
When I first started to program the MD I used the MD's ports for data
and control but, although it can be useful to use the Command-Monitor
over RS232 you would never need to rely on the MD's very slow ports :)
If you look at the GENMIDI project it is appalingly bad as it drops MIDI
messages. Using UMDK though over USB should ensure that this will not
be an issue.

[csmith]

At a guess: is this binary correctly aligned?

Best thing would be to use the trace logging and then find out what happened before it goes nuts.  You only need to take the last entries and not the entire log and then send a reply on the group.