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

0 Members and 1 Guest are viewing this topic.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.194
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2021
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: 38
  • Country: us
  • Liked: 23
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.

Offline ThomH

  • CPC464
  • **
  • Posts: 38
  • Country: us
  • Liked: 23
Re: Adding mine to the emulator pool
« Reply #22 on: 23:20, 07 November 17 »
It's barely substantial enough to mention, but the latest release (at the top of here, as ever) has a few fixes over the previous for CPC users:
  • both HFE and DSK files are now writable — previously they were read-only;
  • there are some minor 8272 and 6845 improvements, though nothing huge; and
  • an alignment error in video output was fixed, making that slightly faster.
Most work has been under-the-hood, as towards working on platforms other than the Mac. An SDL proof-of-concept is pretty much ready to go, as long as you hate UIs, but that hasn't even quite formulated into a complete pull request yet.

Oh, and the 'ready' signal from the disk drive now does what it's really meant to do, though I'm not aware of any software on which that has an effect. General theme of my progress: everything's probably going to remain very incremental.

EDIT: minor note on DSK writing: it's a bit brute-force. It'll keep an in-memory copy of your complete disk image, and rewrite your entire DSK file at appropriate intervals. As a side effect, plain DSK files will be upgraded to Extended DSK. Can anybody think of a reason why that silent upgrade might be problematic? What about if it were to switch in the other direction if and when contents allow (i.e. all tracks the same size or close enough, no sectors that aren't either a real supported power of two or the 0x1800 special case)?
« Last Edit: 23:54, 07 November 17 by ThomH »

Offline ThomH

  • CPC464
  • **
  • Posts: 38
  • Country: us
  • Liked: 23
Re: Adding mine to the emulator pool
« Reply #23 on: 18:06, 13 November 17 »
Update on Linux compatibility:

The SDL-based UI-less mode has a build system and builds without warnings or errors under both Ubuntu 16.04 and 17.10. However my virtual machine doesn't support OpenGL 3 so I can't test locally. The one person who has tested remotely reported that although audio played, the emulator's window didn't paint. So I suspect an error in my use of SDL, but it's also possible that I've a mistake or two lurking on the OpenGL code. I'm possibly going to have to abandon the virtual machine, but we'll see, as I wanted to back-port to support GL ES 2+ anyway, even though it'll be a hassle not having access to integer operations on the GPU.

If anybody is curious enough, download or clone the latest source from GitHub, and run scons in OSBindings/SDL. Prerequisites are SDL 2, ZLib and OpenGL. That should produce a binary, clksignal. You'll want to put the CPC ROMs into either /usr/share/CLK/AmstradCPC or /usr/local/share/CLK/AmstradCPC. See here for a complete list of the filenames I selected, but if you're only going to load disk images then amsdos.rom, basic6128.rom and os6128.rom will suffice as it always picks 6128 emulation when loading disks*. Then launch with clksignal yourfile.dsk/hfe.

All SDL code is contained entirely within OSBindings/SDL/main.cpp as it's the sort of emulator that's designed to keep the platform binding out at the fringe. If you know SDL and can spot anything obvious that I'm doing wrong, let me know. I used to use 1.3 a lot but this is my first meeting with SDL 2.0. Also, if anybody tries it, and it doesn't work, a capture of the console might be helpful, though it'll mostly be 8272 logging after a couple of helpful comments re: the environment provided by SDL.

* actually, I think I might have left it as always picking the 6128 for everything, because I'm lazy.

EDIT: quick addendum: the problem seems not to be SDL misuse but rather some other issue in my OpenGL code. Given that it works correctly on the Mac but seemingly fails on an Intel-chipset-powered Ubuntu box there's a possibility you might be more lucky if you're an AMD or Nvidia user. In the meantime, I'm working on it.
« Last Edit: 23:06, 13 November 17 by ThomH »