Clock Signal — an Oric emulator for macOS and Linux

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

Small bump on this: Clock Signal now also emulates the Jasmin disk interface, completing the trifecta. Releases are here, as always.

With conflicting or limited information I made a few guesses:
  • I've used a WD1770 rather than a WD1773 or an older FDC197x, so relevant bits relate to a potential spin-up sequence rather than a head load, and the side fields in sectors aren't checked; and
  • even though I'm an electrical dunce, I could see references to reset and an output to /RES on the schematic so I assumed that the Jasmin boot button causes a processor reset, and since that doesn't achieve much if the Jasmin ROM isn't paged I decided that it probably does that too. I tried defaulting to the Jasmin ROM paged at initial boot, but then the machine wouldn't start at all if a disk is present so I decided that probably doesn't happen.
The emulator will attempt automatically to detect Jasmin-format disks, and will automatically boot them, but it has a preference for the Microdisc in any case where a disk would work on either as: (i) it boots more quickly; and (ii) it's better tested within Clock Signal.

So:
Jasmin.png
Jasmin.png (3.71 KiB) Viewed 10307 times
As a footnote aside, there seems to be a decent overlap here with Atari ST folk so perhaps also worth dropping into the conversation is that Clock Signal now also has a mediocre Atari ST emulation. Not good enough yet for me to dare show my face in the mainstream Atari ST world though. Probably my next item of work there is support for the STX file format, which I've argued elsewhere I think would also be a good fit for the Oric. So it's very possible I'll provide support for that for the Oric soon. In the meantime, you can continue to use standard DSKs or HFEs.

(And, as an aside: the ST uses a WD1772, which is a WD1770 with different stepping rates, so that exposure should also feed back into improving my Oric emulation)
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

Thanks, @ThomH! Perfectly timed release - just what I need at the moment :).
About the Jasmin button: actually there are 2 buttons on Jasmin ver.2 ;) - the left button acts as simple reset with paged BASIC ROM, the right button activates Jasmin ROM tries to boot and if there is no disk then falls back to BASIC ROM.
I've changed the order (in StaticAnalyser.cpp) to prefer Jasmin over Microdisc and ... it works! Congrats!

A little off-topic question: I found that Sedoric can format disks with 15,16,17,18,19 sectors does anyone has info about how exactly the GAP's are calculated? Is there any "standard" formula to use?
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

iss wrote: Mon Jan 06, 2020 9:25 am Thanks, @ThomH! Perfectly timed release - just what I need at the moment :).
That’s lucky! I saw elsewhere that there were some floppy images that work under emulation but not on real hardware; in case it’s relevant, I’ve implemented all Jasmin-specific registers as write-only, with the FDC mirroring to supply reads. I’m sure that isn’t going to be exactly right, but it is sufficient to match the documentation. I'm keen to update as and when anything new is learnt.

EDIT: oh, except that my force interrupts are still very questionable. I strongly suspect that the datasheet isn't completely forthright in saying that they return the status register to type 1 as quite a few pieces of software I've looked at expect still to be able to check for a CRC error after a force interrupt. Also I've not yet implemented all the force interrupts, but will do so soon.
iss wrote: Mon Jan 06, 2020 9:25 am About the Jasmin button: actually there are 2 buttons on Jasmin ver.2 ;) - the left button acts as simple reset with paged BASIC ROM, the right button activates Jasmin ROM tries to boot and if there is no disk then falls back to BASIC ROM.
I've changed the order (in StaticAnalyser.cpp) to prefer Jasmin over Microdisc and ... it works! Congrats!
Oh, well I also finally implemented my Oric’s NMI button, which isn’t a reset but is obviously similar, but I put that on F12 and the Jasmin’s reset-with-ROM on F1. So maybe I should shunt F1 to F2 and add a plain reset as F1...
iss wrote: Mon Jan 06, 2020 9:25 am A little off-topic question: I found that Sedoric can format disks with 15,16,17,18,19 sectors does anyone has info about how exactly the GAP's are calculated? Is there any "standard" formula to use?
While reading on the Atari ST, I think I read that the WD can’t cope with compressed gaps between the sector header and sector body; it assumes it has a certain amount of time for the field comparisons and misses the sector body if it don’t. So don’t reduce there. That’s everything I can currently think of about that.

EDIT: this is the document I was thinking of. Amongst other tips, it posits a known-working 18-sector format for 256-byte sectors but also has some useful tips as to the behaviour of the WD in amongst the Atari-specific stuff:
  • minimum lengths for gap 3a & 3b are 22 and 12;
  • gap 4 can be arbitrarily short, but at some point the WD will be unable to do consecutive reads because it hasn't had enough time to finish dealing with the previous sector data before the next header passes by, so it'll have to catch the next sector on the next rotation — though you could interleave, and if you're not doing multi-sector reads then you obviously needn't worry.
That author seems to have read all of WD's patents plus a whole lot more; he's probably the world expert on the WD1772.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

It's late in the day, so I'll be quick: I've uploaded a new release that takes a shot at Byte Drive 500 emulation.

EDIT: it appears there’s a dangling bug with drive spin-up on the Byte Drive; it’ll happen the first time but not subsequently. Either issue all of your DOS commands really quickly, before the drive spins down the first time, or wait for the inevitable fix, hopefully this evening.

@iss: because I ended up adding sort-of momentum to my disk drive emulation, based on my fairly random guess as to how the BD-500 manages the drive motor, I've also unwittingly invalidated your sys-info.dsk. With hindsight, the fact that your real hardware prompt allows for the possibility of a WD1770 would have been quite a hint had I been trying to do this on purpose but actually it's more a case of being pushed over a shame cliff.

If it's any help, I've still yet to implement drive speed fluctuations — that's been on my mental list for a long time. So something like timing index pulses should still work for detection of this emulator, as they'll always be exactly the same distance apart. Otherwise, I'm suspicious that a real Oric might not completely fill up the 300 page with a disk interface attached, so it may well be that you can sniff video data on a real Oric but you can't presently on my emulator as it's just a suspicion.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

@ThomH: Amazing work :!:
Here some thoughts:
- BD500 - it works, but if you type just after boot screen command "DIR" then it lists first part of filenames and waits for key, if you wait more (i.e. 10 sec) and press key then an error is issued : ?Drive Error. It looks like there is kind of timeout and the motor is turned "off" automagically and not again "on" on continue. (No idea how it's on real hardware).
BD500-error.png
BD500-error.png (16.02 KiB) Viewed 10174 times
- 60Hz problem - 50Hz works fine, but in 60Hz the image goes "out-of-sync". In the attached ZIP file are 2 DSK images for 50Hz and 60Hz for testing.
60Hz.png
60Hz.png (22.34 KiB) Viewed 10174 times
- Speed issue: with the attached DSK file (which read a track and write it back) the real hardware (Jasmin :!: and Microdisc) works faster than CLK Signal. I'll post video during weekend.

- Jasmin behavior: looking at the schematics the LS259 allows all for drives to be "selected" simultaneously - stupid but it's a fact :). I don't have a bright idea if this should be supported in emulators but here's the patch:

Code: Select all

diff --git a/Machines/Oric/Jasmin.cpp b/Machines/Oric/Jasmin.cpp
index 50295336..15dc8a64 100644
--- a/Machines/Oric/Jasmin.cpp
+++ b/Machines/Oric/Jasmin.cpp
@@ -43,7 +43,8 @@ void Jasmin::write(int address, uint8_t value) {
                break;
 
                case 0x3fc: case 0x3fd: case 0x3fe: case 0x3ff: {
-                       if(drives_[selected_drive_]) drives_[selected_drive_]->set_motor_on(false);
+                       // LS259 allows *ALL* drives to be on in the same time
+                       // if(drives_[selected_drive_]) drives_[selected_drive_]->set_motor_on(false);
                        select_drive(size_t(address - 0x3fc));
                        if(drives_[selected_drive_]) drives_[selected_drive_]->set_motor_on(motor_on_);
                } break;
@@ -57,7 +58,7 @@ void Jasmin::set_motor_on(bool on) {
        motor_on_ = on;
        if(drives_[selected_drive_]) drives_[selected_drive_]->set_motor_on(motor_on_);
        if(observer_) {
-               observer_->set_led_status("Microdisc", on);
+               observer_->set_led_status("Jasmin", on);
        }
 }
Attachments
test-dsk-for-rw-and-50-60-hz.zip
(48.72 KiB) Downloaded 261 times
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

Most importantly: the BD-DOS spin-down issue is 'fixed' (in the sense: I've taken a different guess at the sort of RDY it's expecting from the drive) in a new release.

Otherwise:

Sync

60Hz is out of sync because it is genuinely out of sync. The simulated Oric produces a real 1d video signal with appropriate embedded syncs, the in-emulator CRT decodes that via the proper sync classification and PLLs. That stuff is a lot more important for machines where the syncs are programmable, but there it is. The in-emulator Oric is connected to a 50Hz display and that's that. So what you're seeing should be a really excellent emulation of a 50Hz-only display being fed a 60Hz signal.

... which is completely useless. I need to take a moment to determine the best way to support multi sync displays. There's already a partial solution local to the Atari 2600 so it shouldn't be too tough. I'll finally bother to do it.

I'd definitely rather stick with everything having to produce the 1d signal with sync info and having to maintain only one backend, rather than mucking about with alternative code paths.

The Jasmin

There are other machines on which you can select multiple simultaneous drives, and it wouldn't be too hard to do in terms of my emulator, I've just never bothered. In my emulator drives are just things which provide a sequence of events, so selecting multiple of them would just mean writing a quick intermediate shim that keeps e.g. two upcoming events instead of one, and passes on only whichever is next.

I will probably address this at some point also.

I will also merge your changes as attached and rerelease; I'm very grateful! The Jasmin LED thing should have been obvious — clearly I haven't been paying attention to my own UI. You'll have noticed the lack of an activity indicator light when booting a Jasmin disk.

EDIT: actually, follow-up query on the Jasmin: if you can select arbitrarily many then how do you deselect drives? All I used for the Jasmin was Hardware Programming on the Oric, which lists 0x3fc et al as a route to drive selection, not a sequence of drive enables.

Disk Speed

Have you any idea which sort of slowness it is? Otherwise immediate guesses are either that I have the incorrect stepping rate, or that the tracks I'm reconstructing from .DSK files are too short (i.e. when stretched to a whole track's length, not dense enough).

And, if it's likely to be stepping, I guess I could just be wrong about the exact controller chips at use? In Jasmin land the WD1772 and WD1770 have different stepping rates, and I've used those of the FDC1793 for the Microdisc but if it's not exactly that one then the rates may differ there.
christian
Pilot Officer
Posts: 96
Joined: Sun Nov 24, 2013 9:58 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by christian »

actually, follow-up query on the Jasmin: if you can select arbitrarily many then how do you deselect drives?
Drive 0 -> 0x3FC, Drive 1->0x3FD, Drive 2->0x3FE, Drive 3->0x3FF
To select a drive write 1 to the corresponding address and 0 to deselect.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

christian wrote: Fri Jan 17, 2020 10:41 am
actually, follow-up query on the Jasmin: if you can select arbitrarily many then how do you deselect drives?
Drive 0 -> 0x3FC, Drive 1->0x3FD, Drive 2->0x3FE, Drive 3->0x3FF
To select a drive write 1 to the corresponding address and 0 to deselect.
Cool, thanks! I'm going to hold back on iss's suggestion until I can implement multiple simultaneous drives, then I'll implement that properly. Otherwise I'm immediately going to trip over myself with propagation of the motor signal versus the current structure that attempts to enforce a selected_drive_. I also want an opportunity to clean up a lot of silliness around there with shared_ptrs. That was very early in my learning curve for modern C++.

In the meantime I have support for the STX file format slowly improving, which I hope also to permit as an alternative higher-fidelity Oric disk image. The emulator already also allows HFEs, but I suspect STX might be easier to retrofit onto Oricutron and therefore is more likely to be accepted.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

I want to try to tackle at least the Jasmin drive thing before doing another formal release, but for anyone building directly from the repository, multi-sync display support is in. So if you switch to 60Hz then the virtual display should detect it and react.

Notable side effect: in 60Hz mode, there are fewer lines in total, so the Oric's display is taller. But since the Oric doesn't do anything with its border, my emulator has always cropped it. It switches to a different cropping rectangle in 60Hz mode, zooming out further to get the full height of the display. Same width + taller -> zoomed out to eliminate 'taller' = thinner. So the 60Hz display looks thinner.

The multi-sync thing, like everything else, is calculated by the CRT with no ability to look inside the Oric (nor, indeed, any specific awareness that the thing producing a video signal is an Oric). As a result it takes a short while to catch on when the output frequency switches. This is consistent with real displays. So any game-esque 'animate an explosion by quickly switching into and out of 60Hz mode' effects will still work.

EDIT: and if you're using composite video, it'll be PAL 60, not NTSC. The Oric doesn't change its colour encoding when it changes frequency. But that's nice, because PAL has a higher colour bandwidth amongst other benefits.

Screenshot:
Screenshot 2020-01-23 at 22.12.19.png
Screenshot 2020-01-23 at 22.12.19.png (195.3 KiB) Viewed 10051 times
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

Cool! Tested with macOS and works, but any chance to have SDL fixed too? ;)
Now RGB mode freezes with black window and both composite modes issue "Segmentation fault".

EDIT: Maybe the log below will help, but it's strange why clksignal stopped to work - I don't see changes related SDL.

Code: Select all

[WD FDC] Idle...
[WD FDC] Idle...
[WD FDC] Idle...
Constructing scan target with OpenGL 4.5 (Core Profile) Mesa 19.1.8; shading language version 4.50
Couldn't enable vertex attribute startCompositeAngle
Couldn't enable vertex attribute endCompositeAngle
Couldn't enable vertex attribute lineCompositeAmplitude
Changed output resolution to 400 by 300
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

iss wrote: Sat Jan 25, 2020 1:49 am Cool! Tested with macOS and works, but any chance to have SDL fixed too? ;)
Now RGB mode freezes with black window and both composite modes issue "Segmentation fault".
I wasn't able to reproduce, but I did scratch my head the other day while rereading the SDL main.cpp as to why I couldn't see any overt thread safety mechanisms outside of the audio stream. I think I got away with this in the past because the primary contested bits of memory were things like key up/down flags where reading the wrong value for a moment has no substantial negative effect.

Nowadays, the SDL thing that draws status indicators, like the drive lights, manipulates a bunch of std::sets. Which potentially means memory allocations, and collection mutations while iterating.

So I've tightened things up there. Which hopefully was the problem?
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

Hm, this will be not easy to fix - sorry to bother you!
Here is a list with commits in back order with status of the SDL issue:

Code: Select all

https://github.com/TomHarte/CLK/commit/e7fff6e1236f48d805bde8db13ea6c922f13a600 - not working
https://github.com/TomHarte/CLK/commit/4de121142bdf6363476a1ad92673ff9456733d1a - build fails
https://github.com/TomHarte/CLK/commit/290db67f093d04bd30962bc746c22238029f7ce8 - not working

https://github.com/TomHarte/CLK/commit/8adb2283b58252c30726b49d8171f3264f63d614 - no RGB, both composite OK

https://github.com/TomHarte/CLK/commit/cb61e8486826b10c1c5b7939a6aae4664d8d6dd9 - OK
https://github.com/TomHarte/CLK/commit/a2847f4f8ebd6aab91965e279da3231fe7f033f3 - OK
https://github.com/TomHarte/CLK/commit/add3ebcb44eb3d605eec0ae0332472a899475cb9 - OK
https://github.com/TomHarte/CLK/commit/f02759b76b98af75bf4f6dd62d7d6cc2fc32372d - OK
Unfortunately the "OK" commits are prior recent Jasmin/BD500 improvements.
I don't want to push you but clksignal really helps me as testing and bench-marking target.
Meanwhile I'll use the macOS but my development loop slowdowns (i.e. coding-compiling-transfer_to_mac-testing-goto_begin :)).

BIG FAT EDIT:

Code: Select all

https://github.com/TomHarte/CLK/commit/c398aa60c11bd0d51abda07d078985f9ebc83ac7 - current HEAD
In current HEAD/master branch both composite are working, just RGB is black rectangle!
So, no hurry from me I can do my coding on high gear :).
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

No, I'm immensely grateful for the feedback. If the emulator isn't working, that's top priority. I'm far too lazy with testing, to be honest, I build for SDL on the Mac and test there, and I have an automated Linux/SDL build performed on every build request to make sure that the code still builds but things like accidentally relying on undefined behaviour such that the code works on one platform's SDL but not on another's is something I test in a very ad hoc fashion.

Hopefully I can figure it out before the weekend is out.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

Thanks for your effort!
One more thing but only related to myself: RTFM - there is difference between this two calls:

Code: Select all

./clksignal --quickload --output=composite test.dsk
and

Code: Select all

./clksignal test.dsk --quickload --output=composite
Only the second works!

EDIT again: More tests and it works fine in RGB with no options !
There is something strange when called with relative paths... will test more and report back with collected results.

EDIT2: It seams that the '--quickload' option used alone or in combination with '--display=rgb' prevents clksignal to run.
No problem with both '--display=composite(-mono)'. Another wired thing for which I don't find explanation is: if the DSK is symlink '--quickload' works but if I use the absolute path to the same DSK file it doesn't :o Tested with elevated user (i.e. root), so it's not a permission issue. Anyway, this is minor and maybe only by me - don't waste your time on it.

With the last updates maybe there is new issue with WD1770 but I need to test more to be sure and not report fake bugs. Thanks!
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

There must be more undefined behaviour at play, since there is no reason why command-line argument order should make a difference; the parser just steps through argv. Anything that begins with a hyphen is checked for an equals sign and, if present, is split on the equals sign and recorded as an option to which a string is assigned, or if absent is noted as an option to which true is assigned. If no hyphen is present then the argument is copied into a fixed slot for the supplied file name. The options are inserted into a std::set so their input order isn't retained and in should make no difference.

At a guess, I've probably got a buffer overrun somewhere. I'll keep throwing the Clang address sanitiser at it in different combinations — I wasn't previously aware that command-line order makes any difference, so that could be a useful clue.
Post Reply