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: 178
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » Mon Jan 06, 2020 5:23 am

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 251 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
Squad Leader
Posts: 965
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Mon Jan 06, 2020 9:25 am

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: 178
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » Mon Jan 06, 2020 1:41 pm

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: 178
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » Thu Jan 16, 2020 6:15 am

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
Squad Leader
Posts: 965
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Fri Jan 17, 2020 1:23 am

@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 116 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 116 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) Not downloaded yet

ThomH
Flying Officer
Posts: 178
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » Fri Jan 17, 2020 4:53 am

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: 81
Joined: Sun Nov 24, 2013 9:58 pm

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

Post by christian » 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.

ThomH
Flying Officer
Posts: 178
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » Fri Jan 17, 2020 3:53 pm

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.

Post Reply