tomharte / clk Goto Github PK

The Vic-20 has native S-Video output, the Atari 2600 can be modified easily for it — TIA natively outputs S-Video. S-Video offers a higher-quality picture than composite video.

Add an S-Video path to the emulator, and enhance those machines to support it.

For both releases 2018-04-13 and 2018-05-15, on macOS Sierra (10.12.6):

1. Launch Clock Signal
2. Go to menu "File -> New ..."
3. Select Oric1 or Atmos (both cause the issue)
4. Select "Microdisk"
5. Start the guest machine

This will produce a very colorful animated random screen.
The guest computer does not seem to respond to any input thereafter.

Note that dropping a disk image such as the one listed in the Defense Force forum post linked below generates a non animated version of that screen, at least for release 2018-05-15.
Post: http://forum.defence-force.org/viewtopic.php?p=17531#p17531

Running the test at http://www.stardot.org.uk/forums/viewtopic.php?t=10069 , all modes are correct except Mode 3. The program should take almost 12s to run; it completes in just 7.74.

Provide a user-friendly system for importation of those system ROMs that are not bundled with the macOS build of the application.

Particular obstacles:

• different storage, e.g. the Disk II ROM is sometimes in its natural order, sometimes bits are rearranged into Beneath Apple DOS order;
• different packaging, e.g. sometimes the Apple II ROMs are distributed as their individual original chips, sometimes as the full block of 12kb;
• compression, possibly.

Based on a very quick analysis, specifically in point sampling to form the in-phase composite buffer. It's very easy to see on a TMS or Atari because they remain in phase for their entire frame.

When running in kiosk mode, Clock Signal provides no interface chrome whatsoever. This would prima facie make it ideal as an embeddable emulator: one that could be used to provide the Linux/Windows/macOS version of a homebrew title for any of the supported machines.

Two obstacles present themselves:

• the title to load must be specified at the command line; and
• the machine's system ROMs, if any, are always sought out in a location intended to conform to the Filesystem Hierarchy Standard.

The former implies an extra level of indirection in launching that could confuse a user; the latter effectively blocks embedded distribution for Windows and macOS and introduces an undesired side-effect in Linux in branding the embedded game with the CLK name.

Therefore it is desirable to offer:

• the trivial ability to build or to package an existing build so that it will perform only exactly one command line; and
• to allow system ROM locations to be specified on the command line.

So e.g. a Windows distribution of Stormlord might look like:

• stormlord.exe (identical to clksignal.exe, appropriately renamed);
• stormlord.conf (which contains the proper command line to launch Stormlord);
• sdl2.dll (as this hypothetical is a Windows target);
• data/basic11.rom (the Oric BASIC ROM);
• data/stormlord.tap (the original Oric tape file).

Where the user launches stormlord.exe and is promptly greeted by the Stormlord title screen.

Per http://forum.defence-force.org/viewtopic.php?f=22&t=1698&p=16926#p16925:

About CLK for Linux - build from current git sources fails with 3 problems:

• I have to add ../../ClockReceiver to include path
• StaticAnalyser.cpp - memcmp wants #include <string.h>
• MultiJoystickMachine.cpp - std::find wants #include

Hi
When I try to build, I have this error :

'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128)

OS : Manjaro

Thank for your help.

Where to find executables files? There are unix versions?

Using this release: https://github.com/TomHarte/CLK/releases/download/2018-03-23/Clock.Signal.macOS.2018-03-23.zip

Accessing the menu entry "File -> New" causes CLK to crash.

(Note that Sierra offers to send a bug report to Apple, do you receive them? If so, I will fill and tag them so you can associate them with the corresponding issues in GitHub.)

In particular, each sound chip is itself a speaker — it's both something that privately knows how to generate audio and, through inheritance, something that knows how to filter for an output.

This coupling of discrete tasks creates composition problems.

See this thread:

It looks like something I'm doing in BiggOil upsets Clock Signal. Let me know if there's anything you would like from me if you choose to investigate.

BiggOil is a GitHub project and a binary is available here.

On my machine with an exactly-60Hz display:

• a machine that outputs exactly 60Hz may find itself permanently out of phase with the output display, leading to unambiguously avoidable visual strobing/tearing; and
• a machine that is outputting very close to 60Hz will similarly strobe, when nudging its clock rate a little would lead to a more accurate emulation (in the sense that: not strobing and running 0.1% off the real speed is closer to a real experience than strobing).

Consider implementing sufficient tracking and a negligibly variable clock in order to: (i) be able to move the first case into phase with the output device; and (ii) to be able to move and to accelerate/decelerate the latter case, within acceptable bounds, so that it is in phase.

Naturally nothing about 60Hz should be specified: 50 -> 50, 50 -> 100, 60 -> 120, etc, should all work equivalently. Given that some machines have a variable output frequency (at least the Atari, ZX80/81 and CPC), this will also need to be the result of active tracking rather than something knowable in advance.

As per http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?f=14&t=8057&start=45#p100159 :

You should check the timing of the NTSC (and possibly also the PAL) version.

In the first screenshot, the splits of the background register happen at the wrong place (after the first text column), whereas they're supposed to happen just after HSync, at the beginning of the raster. With non-interlaced modes on NTSC, the change of the raster register ($9004) actually happens in the middle(!) of the raster line, not at the start, this is being taken care of by my routines.

The splits also do not honor, that changes of the colour registers on real h/w take effect one hires pixel late w.r.t. half char boundaries.

I realize that this might be an unconventional suggestion, technically as well as user experience wise but maybe you might think there is some value to it, so bear with me for a few paragraphs. ;)

Upon reading a Symoon post on the "Experimental very fast tape loading" thread on the Defence Force forums where he attached a ZIP file containing WAV files to be used as tape input for physical Oric machines, I wondered about the feasibility and practicality of being able to emulate a similar setup. (The post: http://forum.defence-force.org/viewtopic.php?p=17538#p17391.)

Since I do not have access to an actual Oric at the moment, I must resort to emulation to test Symoon's fast loading technique. However, it does not look like Clock Signal offers a way to use an audio file to emulate a tape input signal at the moment.

Providing an user interface of some kind to allow the (necessarily interactive/dynamic) specification of an audio file to be used to emulate the tape input signal seems simple enough. It even seems possible that some other Oric emulators already offer such an interface and adding one to Clock Signal does not seem particularly technically challenging (feel free to contradict me though, I would love to learn about it).

But, another idea popped into my devious mind:

what if, instead of offering a conventional "please choose your audio file to be used as tape input signal" selection dialog, Clock Signal simply used an actual macOS audio input channel for tape signal input?

I see several advantages to such a system:

• no need to offer a silly selection dialog, users are responsible for sending audio to the emulator
• most macOS applications which output sound allow to configure on which channel to send the audio, so users can use their favorite app and possibly scripts
• users are in perfect control of when they start playing audio, just like they are on an actual Oric (or other) machine
• audio streaming/mixing systems/apps such as "Audio Hijack" and "Loopback" from Rogue Amoeba allow to interject audio processing filters in between the audio source and the receiving channel, offering potential ways to enhance signal decoding by the emulated machine when using digitized audio from actual cassette tapes, possibly damaged. (Audio Hijack: https://rogueamoeba.com/audiohijack/.)
• technically, this is much simpler to implement: just read the bytes from the input audio channel, no audio format to decode, no library to add, etc.
• this is actually real audio input emulation and kinda really fits with Clock Signal "signal" philosophy.

What do you think? ;)

The latest macOS release of CLK crashes when drag and dropping the .d64 image of the "kindness" demo on its dock icon.

(OS: Sierra 10.12.6)

Steps:

• download https://github.com/c64scene-ar/4kindness/raw/master/bin/4kindness.d64
• launch the latest release of CLK (*)
• drag 4kindness.d64 over the dock icon of CLK
• notice CLK crashes

(*) https://github.com/TomHarte/CLK/releases/download/2018-03-22/Clock.Signal.macOS.2018-03-22.zip

With a real floppy drive what should happen when there are no flux transitions for an extended period is that the automatic gain is dialled up until the drive starts to report background noise as data. In other words: no flux transitions for 12ms or so implies random data subsequently reported.

This feature is utilised by some original copy-protected titles on platforms where the disk controller does not natively allow a long gap with no flux transitions to be written. It is also a prerequisite for claiming a complete implementation of the WOZ file format.

For exposing too much information, too widely. Why should the Electron care if I introduce a new Vic-20 memory model?

Putting it on the heap and getting to expected types by dynamic casting would be more appropriate.

Per http://forum.defence-force.org/viewtopic.php?f=22&t=1698&p=16926#p16925:

... none of my HFE images are working. :( I use the command line tool to convert DSK to HFE.

Specifically: get_byte's hard-coded polarity (ostensibly to the MSX BIOS spec) is problematic.

Specifically re: repetition across two source files, and undocumented binding guarantees.

Which implies being able to disambiguate them from Atari images.

Using the latest version (https://github.com/TomHarte/CLK/releases/tag/2018-04-13).
Under macOS (Sierra 10.12.6).
Using a new instance of the Oric/Atmos (no MicroDrive).
Copy (using Command-C) the BASIC program listed in this Defense Force forum thread : http://forum.defence-force.org/viewtopic.php?p=5611#p5611.
Then, selecting the CLK Oric window so it has focus.
Type Command-V to paste the copied program.

Notice that this results in a series of "V" characters (and a few others) typed sequentially in the BASIC window.

Note that, if the Oric window loses focus, the sequence stops and does not resume upon giving it focus again.

I am not sure if Copy-Pasting of text is actually supported by the emulator (as a naive user, I would expect it to, otherwise I would not have tried this and discovered the issue ;) ) but it seems reasonable to think that the current behavior is not as designed. ;)

Here is the exact text copied from the forum post:

1 '***********************
2 ' MICROSOFT! Easter Egg
3 '***********************
4 B=#E435 : E=B+9
5 FOR I=E TO B STEP -1
6 J=PEEK(I) : J=J-INT(J/64)*64
7 IF I>B THEN A$=A$+CHR$(J+64) ELSE A$=A$+CHR$(J)
8 NEXT I
9 PRINT A$

This said, I would wager that any copied text causes this result.

On a VIC-20 instance, copying that same text generates a single "V" character but seems to confuse further the input routine:

• Typing the "A" key does not produce any result
• Typing the "Q" key produce the "QV" sequence of characters, "E" gives "EV", and so on...
  As for the Oric instance, losing focus and restoring it restores normal behavior.

With release https://github.com/TomHarte/CLK/releases/download/2018-03-23/Clock.Signal.macOS.2018-03-23.zip,

(With CLK automatically loading the kindness.d64 disk image mentioned in #378 )
Start CLK
Notice the VIC20 display window opens with kindness.d64 being loaded
Access the menu entry "View -> Show Tab Bar" to have the tab bar showing.
Click the "+" button of the tab bar.
Notice that CLK crashes.

So the process for launching software on those platforms is not always fully automated.

Cf. http://rich12345.tripod.com/aiivideo/softalk.html

... a complete sixty-five-cycle scan line consists of sixty-five consecutive bytes of display buffer memory that starts twenty-five bytes prior to the actual data to be displayed.

During VBL the data acts just as if it were starting a whole new frame from the beginning, but it never finishes this pseudo-frame. After getting one third of the way through the frame (to scan line $3F), it suddenly repeats the previous six scan lines ($3A through $3F) before aborting to begin the next true frame

As the emulated machines become more disk heavy — particularly re: the CPC and the upcoming Apple II — it becomes more of an impediment to use that there are no visible or audible cues indicating disk activity. Correct this.

Which, as I understand it, primarily means putting RAM in place of the ROM mirrors in the low 16kb area.

It applies the same phase shift formula, in multiples of a cycle, as for NTSC, which is clearly incorrect.

When implementing the direct TED phases as part of the Vic colour revamp, PAL numbers transcribed directly but NTSC phases had to be entered as 90° - phase.

Given that the Oric uses its colour ROM so I'm not directly generating the PAL colour signal there but the correct thing is coming out, that strongly suggests I'm switching chrominance channels somewhere when dealing with NTSC colour.

Implement a machine with fully well-defined NTSC signal generation to verify that — an absolutely basic Apple II, for example.

This is certainly not a big issue but on Sierra (10.12.6), after obtaining the latest release from GitHub and extracting it from the archive, the quicklook icon which appears in the Finder looks like the generic Apple application image:

The app's icon itself as shown next to the file name seems normal (a dark/grey CRT monitor).

As presently formulated the emulator is launched by providing a piece of media. It runs an analyser on the media to determine target machine and machine configuration, then launches that machine with the media inserted.

It is a user request that the emulator also be launchable by specifying a machine (and configuration), more like a classic emulator.

When attempting to open the latest release on macOS Sierra (10.12.6) (*),
GateKeeper indicates that the application is from an unidentified developer and thus cannot be opened.

This can of course be worked around manually but it is probably a good idea to not teach users to ignore GateKeeper warnings and to properly register the app to Apple instead.
The required fee is not too high (90$ if I recall correctly).

As a developer and end user, I would feel much safer knowing that the app is running under the protection of GateKeeper.

Thanks!

(*) https://github.com/TomHarte/CLK/releases/download/2018-03-22/Clock.Signal.macOS.2018-03-22.zip

Owing to a failure in static analysis to determine the type of paging scheme.

It initially reports a zero audio output rate, before settling on its real number.

http://forum.defence-force.org/viewtopic.php?f=22&t=1698&p=16926#p16925:

But more important is that when I start ./clksignal it breaks my Window Manager i.e. all open windows lose their title bars, frames, buttons etc.