Author Topic: Adding mine to the emulator pool  (Read 877 times)

0 Members and 1 Guest are viewing this topic.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.140
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 1965
Re: Adding mine to the emulator pool
« Reply #20 on: 11:42, 05 September 17 »
I'll try and get some pictures of what I see but I'll be using a mobile phone not any special setup so the result may not be that clear.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline ThomH

  • CPC464
  • **
  • Posts: 23
  • Country: us
  • Liked: 16
Re: Adding mine to the emulator pool
« Reply #21 on: 03:42, 07 September 17 »
So based on the description it sounds like the implementation with at least one modulator is to use the luminance output from the CPC and add — possibly in the literal additive sense — a colour burst after each Gate Array sync? That would fit with the description of shortened horizontal syncs being problematic, as luminance wouldn't be at the blanking level even if the border is black, and if it's not black then there's probably colour information that would cause the colour burst not to be recognised?

My emulator has code in it already to do a composite encode and decode, because composite decode is what I do with machines that natively produce a composite signal, and a default composite encoder is available for machines which you'd expect to be used with a TV but for which further specifics aren't known. But to cut down redundant costs I've applied a rule that the composite signal is specified in segments — "blank for x cycles, then this byte stream for y cycles, using this GLSL snippet to convert between bytes and signal levels" and so far every machine has been able just to say "... and then a colour burst for z cycles". So I have a PLL that should be able to support genuine no-prior-knowledge PAL (and NTSC) composite colour decoding but so far have never tested it. I'll have to make a judgment call on whether to bother with that here, or just to insert an ideal colour subcarrier after every sync ends, I guess. I'll need to think about it.

In more practical terms, I'm working immediately on resolving the drive logic ownership design error as mentioned earlier. So I'm hoping to do that, then power onwards back up to the 8272. My short-term objective is that everything be able to load, even if it then acts incorrectly. A cool thing about the way I've set it up is that arbitrarily-timed flux transitions plus a PLL in principle allows weak sectors to be modelled just like on the real hardware, as simply having some bits right on window boundaries and having those happen to fall one way or the other due to random rotation speed noise. And this will be my first opportunity to find out whether that works.