One additional: Clock Signal

Paragon (1810)

23-02-2018, 16:46

I just gate it a try and so far it has worked with the few ROMs I've tried! (but I'm at work, so, I've only tested a couple). I see that now I can just open it, and then drag ROMs onto it on the task bar, and it all works! nice!

As for the autodetection, that sounds interesting. How do you determine when one of the simulations is working fine? I guess is one of them starts trying to "write" on a ROM page, or if it does a "di,halt", or something like that, it's obvious, but otherwise, which things are you looking at for this? (just out of curiosity! )

Par TomH

Champion (370)

23-02-2018, 20:16

At the minute it's primarily statistics about writes to ROM — if you exactly hit one of the idiomatic paging addresses then you get an improved confidence, if you hit something that causes paging (or is the SCC) but isn't one of the idiomatic addresses then confidence also improves but only if it was below 50%, if you hit something that has no effect then confidence declines. There are also a couple of hard stop conditions: the program counter finding itself at 0 a second time, or attempting to execute from a part of the memory map that has nothing mapped to it.

A remaining failure case that I want to work on is typified by Aliens: all of the code it runs prior to user interaction is all at the start of the cartridge but it loads graphics from its second page. So if paging is incorrect, it shows rubbish. I'm contemplating mixing in some sort of measure that roughly correlates to an entropy check on the contents of video memory as a factor, subject to suitable constraints. That'd seek to reproduce what a human being might do if they didn't know the cartridge type but were expected to find it of trying each and seeing which one looks right.

As you'd imagine, factors needn't be weighted equally. Hard stops are absolute, and I'll probably be able to come up with a few more if I have to, everything else is only of relative importance.

In principle a similar approach can be used to determine between any combination of factors, but processing cost could prevent that in practical terms. I've the four main paging schemes implemented at present; if I were trying dynamically to pick between MSX 1 or 2, 50 or 60Hz, and cartridge paging scheme then I'm at running 16 machines simultaneously! Which is not unrealistic on a modern computer but it's a heavyweight way of solving the problem and anybody using a battery-powered device probably isn't going to appreciate it.

(EDIT: in case anybody was thinking to ask the follow-up question: yes, this emulator also uses multiple threads when running just a single MSX. The main body of emulation is serial, naturally, but the two tasks of throwing data to the GPU and then rendering the display, and of producing and then resampling the audio stream, are separately threaded. The GPU itself applies either the composite encoding and decoding for television output, or the [high-threshold] lowpass filter for monitor output. All adds up to usage of about a third of a core on my 2011 MacBook Air, which is dual core so one sixth of total available processing.

I'm not sure I was explicit about the fact that even monitor output is not a completely dumb pixel copying before but it's not; proper signal processing concerns still apply because even a monitor cannot handle a signal of infinite bandwidth.)

Par TomH

Champion (370)

04-03-2018, 00:30

This emulator has just been updated again.

Like thousands before, I took a quick detour into ColecoVision to try to flush out any latent TMS bugs. There were a couple, but also a lingering timing error in my purely-MSX code related to connecting the TMS to the interrupt line occurred while I was just poking around. So the new release:

improves the timing of TMS interrupts;
corrects a TMS mode selection bug; and
causes multicolour mode to work.

Par TomH

Champion (370)

08-03-2018, 00:06

Quick note: I have uploaded a Youtube video to prove definitively that I am awful at playing video games.

Also it shows the emulated MSX in action. Hopefully that helps to resolve any concerns about the composite video (which, remember, is optional — just like on a real MSX) as I'm not sure the still images really do it justice.

Par Grauw

Ascended (10772)

08-03-2018, 00:14

Nice video! Though Youtube compression destroys it a bit, if you upload 720p60 it deals with it much better. Next implement colour crawl?

But hey TomH, I keep finding the title of this thread so subtle . Why not change it to something a bit more explicit like “New emulator: Clock Signal”? (You probably can’t edit it yourself, but submitting a mod alert works too.)

Par TomH

Champion (370)

08-03-2018, 03:02

I'm emulating only an NTSC machine at the minute, which means that the colour signal is in-phase. So there is no colour crawl, including in real life. The emulator does produce colour crawl in PAL mode, but does not currently support a PAL MSX, primarily because I've yet to think of a good way of deciding that I need one. I briefly considered cartridge => NTSC, tape or disk => PAL, but that felt a little broad. Might be better than nothing though.

I definitely cannot edit the title of this thread at present, and made the probably false assumption in originally titling it that 'one additional' on the 'emulation' section would imply one additional emulator. If a mod did change it that wouldn't necessarily be a bad thing, but I'm not that bothered about it unless or until it at least does an MSX 2 anyway. I just find it really hard to believe that anybody is going to be that interested right now. It's just too much less than the emulators they already have.

Par TomH

Champion (370)

08-03-2018, 17:14

Re: my assertion that colour crawl shouldn't be evident on a real NTSC machine, I arrived at that just as my emulator does as a simple result of the mathematics involved (i.e. 228 colour cycles per line means an in-phase signal) but have now found documentary evidence of it in the TMS99x8 document stash.

Specifically, from 'message on modification to 9918 from 1982':

Quote:

Rainbowless 9918

Pete Rickert sent samples of the "rainbowless" 9918 (where the horizontal line count is changed from 342 to 340 dots). We are interested in PCD's reaction to the screen effect, and particularly want to know if the current 9918 should be phased out with this new version phased in. There are several known problems with the current "rainbowless" 9918.

text mode does not work. This is a fixable problem but will require some layout effort
there is a slight rolling or crawling effect along the transition between two colours (is this effect better or worse than the rainbow effect
the vertical line frequency (and the vertical interrupt timing) are slightly different (by a ratio of 340/342). This might have an effect on real time operations
the 9928 and 9929 are still at 342 dots per line. (is this a compatibility problem?)
are there any other problems that PCD might know about?

The bottom line question is whether the rainbowless 9918 causes more problems than is solves.

The second bulletpoint covers the fact that there is not ordinarily colour crawl, and reducing the line from 342 to 340 does indeed produce a non-integer number of colour cycles per line. Still not the correct NTSC colour number, but one that would produce crawl.

So I stand by the way the emulator currently operates in NTSC.

Incidentally, a vaguely similar discovery I made while in ColecoVision land is that my guessed approach at handling the fifth sprite number is known to be correct. For as long as no fifth sprite condition occurs, the status register can be observed counting over the sprites as it fetches them. So it can be used as a coarse and slightly irregular horizontal counter.

Par Grauw

Ascended (10772)

08-03-2018, 18:11

Oh, that's an interesting scanned message. Is there more of that?

And awesome that the sprite counter thing is confirmed, that seems quite useful!

Par TomH

Champion (370)

08-03-2018, 19:42

Grauw wrote:

Oh, that's an interesting scanned message. Is there more of that?

Spatula City has a stash of memos from the 9918's development and early market period, all from Karl Guttag, one of the original designers of the A revision. Sadly due to the period covered there's a lot of stuff like 1981's "the video display processor debacle" on "the near disastrous state of affairs with the 9918 VDP and its associated spin-offs", which is "another embarrassment". I suspect that later memos, after the ColecoVision and the original MSX, would have been a lot more upbeat...

Grauw wrote:

And awesome that the sprite counter thing is confirmed, that seems quite useful!

Yes, and I [re]found the source of that confirmation. Here. The user nanochess seems to have been the author of the first modern ColecoVision emulator — i.e. the first one to account for the VDP having limited access windows, not to emulate it a line at a time, etc. He provides the ColecoVision test ROM that he used to verify the result. I don't think anything else he uncovered is unconfirmed here in MSX world: sprite collisions are pixel perfect but the pixels have to be on screen, there is the race condition on reading the status register that can cause skipped interrupts, a sprite 'drawn' in colour 0 will still flag collisions even though it is invisible, and a few other things.

Par Grauw

Ascended (10772)

08-03-2018, 20:00

Oh, nanochess also released a number of titles for MSX!

And yeah, the race condition is kinda known… I had forgotten about it, but was reminded in a recent thread :). And the other results aren’t unexpected I think, but nice to have confirmation.

Thanks for the link to the memos as well, those’ll be nice to read!