wolf: like the graphics on msx1 then? or does the msx2 have drawbacks compared to the msx1? And demostuff
being impossible never stopped people from doing them anyway, right? And regarding sound I personally am more into
stuff that SOUNDS 8-bit, like the PSG or SID on c64.. Though I have to agree that moonsound is impressive coming from
an 8-bitter, sounds more like a record.

btw are there any msx-related channels on ircnet?

esau: MSX emulation (mostly openMSX) on irc.freenode.net #openMSX
MSX social talk on #msx on Undernet
MSX social and dev talk on #msx on Rizon
MSX dev talk (and probably other stuff as well) on #msxdev on Rizon (long story why there are 2 channels on Rizon)

esau: except that your demo doesn't run on MSX2 (see discussion), it doesn't have disadvantages.

esau, since you seem to be into the Amiga, you might know TBL? As far as I know I'm still a TBL member atm..

hop by @ #msx (irc.rizon.org, irc.gamepad.ca etc.) ^_^

manuel: It happens in openmsx too, check the stars in the background of Alpha Roid: every 8 pixels or so they shift to the left for 1 frame, and then back. It happens on my MSX2 too btw, but like I said, I don't know if it does this on a Japanese MSX1. Either the programmers were baffled at how to fix this very noticeable glitch and just left it in, or this glitch doesn't happen on the real thing. For now we'll have to assume the first, until it's confirmed. tmsposting.txt = http://bifi.msxnet.org/msxnet/tech/tmsposting.txt

Great demo btw.

Quote:

Quote: There seem to be quite some differences It actually looks the same in latest dev build of blueMSX as in the video. The demo does only run properly on MSX1 machines though (at least in the emu). Could someone with a cassette deck try it on a real MSX2 and compare to the video. Especially the second plasma like part and the end part with the picture of two guys. I'm quite sure it does not run properly on an MSX2 machine because the demo relies on V9918 specific stuff.

What are those specific stuffs?

Are you saying that before a register write if VRAMPTR=0x0001 , then after will be != 0x0001?
What kind of crazy thing is!

This is what happens. Asume you want to write 1Fh to vdp register 2, then you'd do:

ld    a,1Fh
out   (99h),a
ld    a,82h
out   (99h),a

On MSX1, this will also set the VRAM pointer to 021Fh, but not on MSX2.

I guess the author of this demo either knows this or its just a coincidence that the VRAM pointer was set to the desired value while writing registers.

The problem on MSX2 though is that the VRAM pointer is not updated when bit 7 is set in the second write to port 99. So on MSX2, you need to explicitly do the following to set the VRAM pointer:

ld    a,1Fh
out   (99h),a
ld    a,42h    ; bit 7 cleared, bit 6 set
out   (99h),a

I happened to realize this only a couple of weeks ago when writing a new demo where I didn't want the vram pointer to reset while writing vdp registers. So I had to change the whole demo part and take this effect into concideration.

Btw, can anyone try this demo on a Philips VG-8020. I just want to confirm its running properly on that machine.

We found a bug in the Waves demo related to this issue which makes it not run on some (perhaps all) MSX1 machines. I'm sure I tested Waves successfully on a VG-8020 but I'm not sure if the failing code related to this issue may have been introduced after testing or that the VG-8020 doesn't have this behavior. In either case, I'll do an update to waves to fix this issue.

Quote:

manuel: It happens in openmsx too, check the stars in the background of Alpha Roid: every 8 pixels or so they shift to the left for 1 frame, and then back. It happens on my MSX2 too btw, but like I said, I don't know if it does this on a Japanese MSX1. Either the programmers were baffled at how to fix this very noticeable glitch and just left it in, or this glitch doesn't happen on the real thing. For now we'll have to assume the first, until it's confirmed. tmsposting.txt = http://bifi.msxnet.org/msxnet/tech/tmsposting.txt

I checked and this is what I found:
- on a 50Hz MSX1 and MSX2, it only happens at the top few stars
- on a 60Hz MSX1 and MSX2, it happens for all stars

I tested this only on openMSX, by the way.
And I also tested it on a real 50Hz MSX2: it looks exactly the same. So it's most likely not an emulation bug, but a program bug.

[quote]This is what happens. Asume you want to write 1Fh to vdp register 2, then you'd do:

ld    a,1Fh
out   (99h),a
ld    a,82h
out   (99h),a

On MSX1, this will also set the VRAM pointer to 021Fh, but not on MSX2.


Bleah! What crappy VDP!.

fortunately writing to set VRAM PTR does not set any vdp reg...

Orrible. Congratulations to tms engineer....

Quote:

I checked and this is what I found: - on a 50Hz MSX1 and MSX2, it only happens at the top few stars - on a 60Hz MSX1 and MSX2, it happens for all stars I tested this only on openMSX, by the way. And I also tested it on a real 50Hz MSX2: it looks exactly the same. So it's most likely not an emulation bug, but a program bug.

Sounds like crappy programmers. They probably wanted to update the stars during vblank but failed. I highly doubt its a bug in the emus. They are accurate enough to handle this type of programs.

heya esau! i really enjoyed seeing MSX on the bigscreen @ BP... thnx! :-)

in fact, frequent/eph gave me a headsup about the release the evening before the compo already.. so it wasnt a real surprise anymore but still very cool

That was a really cool demo, especially the ending screen with the EPA-traktor!