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.

My understanding of the problem with disk images, even now that a lot of very clever people have a very thorough understanding of all the analogue issues and emulator authors tend to talk to one another, is that they can either be very large or not completely descriptive. Where 'very large' is large enough to be problematic for devices like floppy emulators to stream in real time from an SD card. Capture devices like the Kryoflux will provide the big versions if you want them, but the summarised forms have the critical mass.

I'm hoping to work up to adding a 16-bit floppy-based machine to my emulator at some point, as I think that'll really help me to figure out how well my handling of this stuff works; there's a lot more there to test with in terms of protection schemes. Not in the immediate future though.

Re: potentially attaching real hardware, I think the main constraint as currently arranged would be timing. Most of the machines work similarly, but e.g. in the Oric specifically you've got the function that receives a complete clock-cycle of activity from the 6502 in one fell swoop. Which is the processor telling you what it did for the last clock cycle to get up to now, when it expects either to sample the bus again or else is currently actively loading something that somebody else could sample. So for real hardware you need to then replay the whole bus cycle, possibly sampling the real bus to supply back to the virtual one. Then the emulation processing needs to happen very promptly to get to the next cycle, ideally in zero microseconds.

You'd also need to add the video accesses into what you communicate outward, I guess, as they're surely observable. Which would make the emulator a little less efficient because it currently does that stuff just-in-time — unless and until you write to an area within the video range, no video processing occurs. When you write it runs the video quickly for as many cycles as it should have run, then does the write. But it can do cycle-by-cycle processing if needs be, so I guess that's no big deal. Either the emulation would be fast enough to provide the real bus or it wouldn't be.

Those notes of caution all being sounded, I read recently that somebody has reimplemented the C1541 as a bare-metal Raspberry Pi program (for hard real-time scheduling) so that you can wire it up to a real C64 via the Commodore serial bus and the C64 can't tell the difference. The C1541 has a 1Mhz 6502 and two 6522s, can signal the serial bus at any time, and can be used to run user programs so you can't make any further assumptions than that. So a full Oric wouldn't be too much more processing than that.

EDIT: re the Clock Signal changes on internal modified disk representation, I don't think it'll take much longer. Then I can see what the Disk II speed test says. Which will be really helpful since the complete set of all feedback I've received on the Apple II emulation is: it seems to load slowly.

Something to not forget, is that many of the disk image file formats we are using today have been inherited from the first emulators written in pre-pentium time, when people considered a 486DX66 to be the fastest thing around.

Clock cycle accurate emulation was not doable for the processor, the video or anything else really

Agreed; and besides the available processing, here in 2018 we have a much greater range of documentation, and: hindsight.

Meanwhile, see attached image for progress. 196ms rather than exactly 200ms suggests a minor outstanding issue somewhere, which I'll look into, but I don't think it's a big deal. So more testing to do, but then hopefully a new release.

Wow, this is great, Thom!
BTW, maybe there is no issue in your code - I ported the code from Apple and it's possible that the time-measuring routine gives wrong result because of clock difference (i.e. 1.000MHz vs 1.025MHz), let me check tonight with real hardware and I'll post the result asap.

Cool. I'll keep trying to come up with a rational way to handle NIBs as I push towards a new release. I see that the Apple II emulator microM8, which is another that has tried to support NIB while having a real hardware emulation, has rolled back its attempt to make NIBs look like real disks and just implemented a not-really-hardware path for them.

I've got a few more strategies to try before I have to contemplate that seriously, and it's not really something I'd actually do so fingers crossed!

Confirmed! The problem is in the ported code.
In my test I used one very good floppy with perfectly tuned 300 rpm (i.e. 200.0 ms period).
I will add code that uses VIA's timer to measure the rotation period too.

Just for information and to be precise, Apple II's clock is 1.0205 Mhz (not 1.0250) (according Jim Sather's "Understanding the Apple II", THE reference.)

My understanding is that there's 14.31818Mhz master crystal, which divides by four to give the standard NTSC 3.579545Mhz. For the CPU it's divided by 14 but for colour output reasons the CPU takes a 1/7th of a cycle pause at the end of every 65th cycle.

So that's (14.31818/14) * (65 / (65 + 1/7)) = 1.02048432017Mhz. Since the emulator treats machine clock rate as a double, I think my Apple II actually runs at only 1.020484Mhz. I think in principle it means I'm an extra cycle behind only every 36-and-a-bit days but it's probably a bit worse than that because of rounding errors that result from using that sort of precision.

On the 1/7th: it's to ensure that every line of pixel output has the same phase relative to the NTSC colour subcarrier. 1/7th is exactly half a colour cycle, and NTSC is supposed to have every other line be 180 degrees out of phase, but that's a bit awkward if you have the programmer directly involved in artefact colours so the machine just takes the brief pause so that every line has exactly the same colour generation rules.

If you had truly golden ears then I guess you should be able to hear the pause when the CPU is generating audio, but I'd be surprised. Also I guess it needs to be factored in to maximum Disk II density calculations. The emulator includes the pause.

So, anyway, I agree!

Also: I'm dithering this way and that on exactly what to tackle next but expect a release before the weekend, because I'm going away. If you're building from source, this won't affect you either way.

Last edited by ThomH on Thu Jul 05, 2018 9:04 pm, edited 1 time in total.

For the record, I decided that I probably wouldn't have time to do much more before my upcoming trip, so I just pushed a new release. Therefore if you use the prebuilt Mac port, the various changes discussed above are now available to you; primarily the emulation of Pravetz 8DOS writing is much improved.

I naturally want to get away from having a disk drive with a perfect motor at some point in the near future, but for now here it is.

Thanks for the release, ThomH!
I will try it definitely because I'm unable to create usable executable with XCode.
Actually everything is compiled without errors/warnings, but when I try to start it I have just blank window.
Maybe I have problem with missing ROM images at the right place...

Oh, yes, the Mac version doesn't display an error if it can't find its ROMs because there should be no way for it not to find its ROMs. But they're not in the repository.

Unofficially, since they're in the releases, just grab the ROMImages folder from inside the application bundle and use it to replace the one in your downloaded copy of the repository. Then builds should work fine.

There is something of a logic behind this: anything I put in the repository will obviously then remain available for all time. But things I put only in the 'Releases' can be deleted. So supposing I ever cross the line with regard to including ROMs that I shouldn't, this arrangement increases the probability that the error can be rectified.

It barely warrants the thread bump, but just to say: after pursuing that "it loads slowly" Apple II comment as referenced above I have come across the wisdom that asking a Disk II to disable the drive motor does so with a one-second delay. For now I've taken that to be a controller feature rather a fact of physical momentum.

The relevant net effect is: Pravetz emulation will now see that delay in spin-down. I don't actually know whether that affects 8DOS but it is relevant for various Disk II-based DOSes on the Apple II because it that the motor is still spinning can be detected by watching the shift register, and many (including Apple's DOS 3.3) decide whether they need a spin-up delay based on observation of whether there still seems to be any spinning going on. So previously they always delayed, now they don't if accesses are reasonably adjacent.

Great progress, ThomH!
After I copied ROM related files to the proper directories everything work under macOS+Xcode.
Attached you can find my updated (actually newly rewritten) rotation speed tester for Oric+DISK][ interface in DSK/NIB/WOZ format.
(NIB doesn't work for me in Clock Signal).

Now speedy-1.01 is not destructive - it requires normal DOS3.3/DOS-8D formatted disk.
It measures the time between two consecutive occurrences of one particular sector using VIA's T1.
And result in Clock Signal is exactly the expected one:

What is totally surprising for me is that the result in Oricutron is the same

Else on real hardware I have ~218ms with SDFloppy emulator and ~200ms with well known good calibrated real floppy drive.
Thanks for your work it helped me lot in playing with DISK][ !

BTW, is it possible somehow to load both drives in Clock Signal with 2 different image files (i.e. to boot from drive A and test drive B) ?

I am still having the same problem with NIB that has obstructed everybody that ever tried to come up with a disk to write them out to a real disk: the file format is just too much of a fiction. From an original disk it (i) removes all the sync bits; then (ii) adds a whole bunch of padding so that each track is exactly 6656 bytes. Which are the padding bytes is not recorded.

At the minute I'm just trying to guess where the sync bits should go, and leaving the padding in. Which leaves me a tight budget for sync placement. I guess I'm either overblowing the budget, which would compress each bit window to too small a size so that none of the track is readable, or being too conservative.

Possibly you really, really do need to do something other than hardware emulation to support NIBs, but I've so far declined to do anything other than real hardware emulation. So I don't know. I'm going to keep trying for a while longer.

Re: putting disks into the second drive; I need to figure that out too. I'm getting pulled ever further from my ideal form of an emulator — select a piece of media, be presented with the software that was on it — but so be it.