Clock Signal — an Oric emulator for macOS and Linux
Re: Yet Another
Great!
It is good to see it is improving!
It is good to see it is improving!
Re: Yet Another
Oh! And! I forgot to make my boast! Screenshots as below. As I am emulating an unexpanded Atmos, I'm assuming I'm supposed to compare my "Normal ORIC boot with IRQ" to that of the Atmos screenshot rather than to the Pravetz. If that's a correct understanding and not a desperate cherry-picking then I appear now to be spot-on for VIA timing. I was merely off by one, by accidentally performing a decrement in the same cycle as a programmatic load.
Also I realised that I haven't spoken as to disk drives. I already have something of an implementation of a WD1770, but I've failed properly to isolate the data request and interrupt signals owing to a misreading of the data sheet and the only current user of the code having neither of those pins attached. So that's not top priority. But it's also not like I've nothing implemented whatsoever.
Sound is also definitely off, I just can't figure out exactly how. Something in the mixer, possibly, as the main issue seems to be volume. But the various bits of sampled speech I've tried, plus quite a bit of inspection, imply it's not as obvious a mistake as I might have liked. Oh well.
Also I realised that I haven't spoken as to disk drives. I already have something of an implementation of a WD1770, but I've failed properly to isolate the data request and interrupt signals owing to a misreading of the data sheet and the only current user of the code having neither of those pins attached. So that's not top priority. But it's also not like I've nothing implemented whatsoever.
Sound is also definitely off, I just can't figure out exactly how. Something in the mixer, possibly, as the main issue seems to be volume. But the various bits of sampled speech I've tried, plus quite a bit of inspection, imply it's not as obvious a mistake as I might have liked. Oh well.
Re: Yet Another
Updated again.
New features of note:
EDIT: actually, I'm pretty sure my problem is just something in the Microdisc interrupt request register — the one at 0314. I have it implemented to provide the same value as the Microdisc is placing onto the interrupt line. So if you disable Microdisc interrupts via bit 0 then it doesn't report. That seems to be consistent with Sedoric's requirements. But e.g. 1337 writes a control value of 10000100 and then issues a restore and gets stuck in a perpetual LDA $0314 / BMI loop. So it's expecting the top bit to clear itself, even though it has requested that the FDC's interrupt line not be fed to the CPU. I'm finding the documentation a little unclear, so I guess I just need to try a few more combinations and/or disassemble a few more things.
EDIT2: scratch that, fixed. I had the WD interrupt line directly wired as the inverse of the busy line, which isn't accurate since status reads should reset the former without affecting the latter. Then the comment in this document that INTRQ state is returned "only if bit 0 above has been set to 1" is incorrect. So I did away with that. All disks now appear to work. Binary replaced.
Here's a video for you.
New features of note:
- Microdisc emulation, intended to be timed accurately;
- better file analysis — should make a pretty good fist of deciding automatically between whether to launch a tape with the original ROM or the Atmos. This is based on a partial disassembly and inspection of the outward jumps. It's assumed that disks don't care because the Atmos predates the Microdisc, so they're always loaded against the Atmos ROM.
EDIT: actually, I'm pretty sure my problem is just something in the Microdisc interrupt request register — the one at 0314. I have it implemented to provide the same value as the Microdisc is placing onto the interrupt line. So if you disable Microdisc interrupts via bit 0 then it doesn't report. That seems to be consistent with Sedoric's requirements. But e.g. 1337 writes a control value of 10000100 and then issues a restore and gets stuck in a perpetual LDA $0314 / BMI loop. So it's expecting the top bit to clear itself, even though it has requested that the FDC's interrupt line not be fed to the CPU. I'm finding the documentation a little unclear, so I guess I just need to try a few more combinations and/or disassemble a few more things.
EDIT2: scratch that, fixed. I had the WD interrupt line directly wired as the inverse of the busy line, which isn't accurate since status reads should reset the former without affecting the latter. Then the comment in this document that INTRQ state is returned "only if bit 0 above has been set to 1" is incorrect. So I did away with that. All disks now appear to work. Binary replaced.
Here's a video for you.
Re: Yet Another
This looks cool. What about the colors - they seams to be very different from the real Oric?
... and about the disk, because now I'm trying to make some speed optimizations of FloppyBuilder
(which is used in the new games and demos) when it works with real floppies - I meet problems
with transfer DSK images to diskettes, so I created simple copy program based on FloppyBuilder.
It's a "wanna-be" Copy][Plus for Oric
and can copy (for now) only 2/17/40 DSK images.
The copy seams to work perfect with HxC floppy-emulator, but not with real diskettes.
It wold be very helpful for me if you test it on your emulator. Attached are screenshot and the image file.
... and about the disk, because now I'm trying to make some speed optimizations of FloppyBuilder
(which is used in the new games and demos) when it works with real floppies - I meet problems
with transfer DSK images to diskettes, so I created simple copy program based on FloppyBuilder.
It's a "wanna-be" Copy][Plus for Oric
![Smile :)](./images/smilies/icon_smile.gif)
The copy seams to work perfect with HxC floppy-emulator, but not with real diskettes.
It wold be very helpful for me if you test it on your emulator. Attached are screenshot and the image file.
Re: Yet Another
The video was taken in composite mode. But I don't know the signal specifics of the Oric so it's using a generic RGB -> composite encoder. So I might not be hitting the exact original colour encodings, but only because I have no information about them.iss wrote:This looks cool. What about the colors - they seams to be very different from the real Oric?
There's also a SCART mode that causes the RGB to appear unfiltered.
Slight problem: my floppies are read only for now. That's because the way they're exposed to the floppy controller is very low level — it's "n/m of a rotation, then a flux transition, then another p/q of a rotation, then a flux transition" — and I've yet to put any effort into figuring out the best way to go in the converse direction. I need either to come up with a clean way of doing a dual channel "these are the flux transitions but, off the record, it's because I'm writing these bytes"-type thing, or just to accept that the price is using a generic MFM decoder over in the file class to convert from real MFM format to no-clocks-Oric "MFM" format.iss wrote:... and about the disk, because now I'm trying to make some speed optimizations of FloppyBuilder
(which is used in the new games and demos) when it works with real floppies - I meet problems
with transfer DSK images to diskettes, so I created simple copy program based on FloppyBuilder.
It's a "wanna-be" Copy][Plus for Oricand can copy (for now) only 2/17/40 DSK images.
The copy seams to work perfect with HxC floppy-emulator, but not with real diskettes.
It wold be very helpful for me if you test it on your emulator. Attached are screenshot and the image file.
Though, side question: does that image switch into 60Hz mode? My emulator (in SCART mode this time) loses synchronisation as depicted below. For Oric purposes it's configured as a 50Hz display* so that's correct if the output is 60Hz. Otherwise I might need to look for some other issue.
* adding a little automatic switcher — just if it hasn't managed to maintain synchronisation for more than, say, half a second, then try switching to the other configuration — is on the to do list. The emulated CRT can be configured to expect a 60Hz signal. So there'll be 60Hz support eventually.
Re: Yet Another
Separately, while looking into the "colours aren't right" issue, I've been grabbing some original television images from Youtube. It seems to vary from title to title but looking at the Manic Miner and Doggy as attached, there seems to be quite a lot of noise in some areas. If it's something the original hardware does, it's something an emulator should do so: does anybody know the source of that noise, or its magnitude? I hate doing these things by eye.
I note that the Harrier Attack shot doesn't seem to exhibit the problem. Perhaps the interference was fixed at some point? Does the Telestrat rearrange anything on the board? It could just be from the RGB output rather than the composite, I suppose — there's some fringing on the score at the top but I can't tell whether that's simply the video compression.
EDIT: for the record, I count 91 stripes on the Manic Miner image. Admittedly I may have miscounted but it'll likely be close to that. Given that PAL has 283.7516 colour cycles per line and the pixel region is 40µs, and the noise doesn't seem to start until a column in, it doesn't look like a subcarrier phase issue, like a variation of the Spectrum's dot crawl. For that you'd expect (slightly) fewer stripes, across the entire display. More likely noise somewhere in the pixel generator? I notice it also seems to vanish immediately before the house in the top left of the Manic Miner shot and after the big tree on Doggy, so those might be the spaces with attributes, on which pixel generation is suppressed?
I note that the Harrier Attack shot doesn't seem to exhibit the problem. Perhaps the interference was fixed at some point? Does the Telestrat rearrange anything on the board? It could just be from the RGB output rather than the composite, I suppose — there's some fringing on the score at the top but I can't tell whether that's simply the video compression.
EDIT: for the record, I count 91 stripes on the Manic Miner image. Admittedly I may have miscounted but it'll likely be close to that. Given that PAL has 283.7516 colour cycles per line and the pixel region is 40µs, and the noise doesn't seem to start until a column in, it doesn't look like a subcarrier phase issue, like a variation of the Spectrum's dot crawl. For that you'd expect (slightly) fewer stripes, across the entire display. More likely noise somewhere in the pixel generator? I notice it also seems to vanish immediately before the house in the top left of the Manic Miner shot and after the big tree on Doggy, so those might be the spaces with attributes, on which pixel generation is suppressed?
Re: Yet Another
What I can say is that in SCART mode there's zero artefacts, the image is unfortunately crisp and flamboyant, which makes the palette and resolution limitations quite obvious ![Smile :)](./images/smilies/icon_smile.gif)
As a rule of thumb, French people mostly used RGB/Scart/Peritel mode, and uk people mostly used the aerial connection, that probably explain the different look of games from the two countries.
![Smile :)](./images/smilies/icon_smile.gif)
As a rule of thumb, French people mostly used RGB/Scart/Peritel mode, and uk people mostly used the aerial connection, that probably explain the different look of games from the two countries.
Re: Yet Another
I've hatched off a different thread to enquire further about video generation. It looks like there's a lookup ROM involved and fairly limited precision on the colour subcarrier but I don't have a real machine or any idea how I would dump the thing even if I did so possibly that's a dead end.
Being the bigger omission and a definitely soluble problem, I guess I'm going to focus on figuring out how to do disk writes within the barriers that I have constructed for myself next. Then it might be time to say that my Oric emulation is 'done'. In the sense that time might be more effectively spent improving some of the other machines in my roster. I think the Oric's the cleanest yet so there are lessons to transfer.
Being the bigger omission and a definitely soluble problem, I guess I'm going to focus on figuring out how to do disk writes within the barriers that I have constructed for myself next. Then it might be time to say that my Oric emulation is 'done'. In the sense that time might be more effectively spent improving some of the other machines in my roster. I think the Oric's the cleanest yet so there are lessons to transfer.
Re: Yet Another
I've made a further release. Highlights are:
- disks are now writeable;
- original colour ROM values are used for composite colour generation.
- I've yet to implement the WD177x type 3 commands — read track, write track and read address, or most of the type 4s. So all that immediately gains is write sector. There's a whole bunch of work underneath to make that work as I insist on using a reasonably accurate model of drive mechanics and the disk surface.
- which caused a beat frequency with my power-of-two signal sampling rate. Making it not a power of two is the proper fix but as a quick hack I just used a larger power of two. So GPU cost is up, but hopefully only temporarily.
Re: Yet Another
Technically, how is read track working compared to read sector?ThomH wrote:[*] I've yet to implement the WD177x type 3 commands — read track, write track and read address, or most of the type 4s. So all that immediately gains is write sector. There's a whole bunch of work underneath to make that work as I insist on using a reasonably accurate model of drive mechanics and the disk surface.
When you do read sector, you get 256 bytes to read, how does that work with read track?
Could read track be used to load stuff faster?
Re: Yet Another
It's a little weird, being officially included for debugging and data recovery purposes because it doesn't necessarily return the bytes that are part of a sector as they were written, owing to spurious synchronisation values. The read sector command ignores any sync patterns it sees during the body of a sector; read track obeys them anywhere on the track. And, annoyingly, they can crop up by coincidence.Dbug wrote:Technically, how is read track working compared to read sector?ThomH wrote:[*] I've yet to implement the WD177x type 3 commands — read track, write track and read address, or most of the type 4s. So all that immediately gains is write sector. There's a whole bunch of work underneath to make that work as I insist on using a reasonably accurate model of drive mechanics and the disk surface.
When you do read sector, you get 256 bytes to read, how does that work with read track?
Could read track be used to load stuff faster?
That said, I see I'm in good company as neither Euphoric nor Oricutron appears to implement read or write track.
On MFM: one of the sync words is $5224, usually reserved for the soft index hole. $5224 is the MFM encoding of $C2, with a missing clock. But it's the pattern 0101 0010 0010 0100. Which is a valid MFM encoding for:
- data bit of a 0: 0
- clock plus data of a 0: 10
- clock plus data of a 0: 10
- clock plus data of a 1: 01
- clock plus data of a 0: 00
- clock plus data of a 1: 01
- clock plus data of a 0: 00
- clock plus data of a 0: 10
- clock of a 1: 0
Looking beyond the Oric world, not implementing read track for a very long time seems to be quite common. I guess because it's not all that useful.
EDIT: and this, by the way, is why I'm not a very big fan of the Oric MFM_DISK file format. Its problem is that it doesn't distinguish between A1 and C2 encoded properly and A1 and C2 encoded with missing clock bits so as to form a synchronisation mark. If you don't put missing clocks in then a controller is never going to find sectors. If you put them in everywhere then the emulated controller is going to post CRC errors and act oddly on read address versus the real thing, as it'll sometimes think that the middle of a sector is meant to be an ID or sector data mark. Therefore for an emulator to use MFM_DISK it basically still has to decompose the file into regions that are sectors and regions that are not outside of the machine emulation. You're gaining over the older DSK in that a track can have differently-sized sectors, with arbitrary declared addresses, and can have deliberate CRC errors, but you're nowhere near freeing the file format itself of being a bunch of bits of data delineated as sectors, and you're a long way from being able to cover the whole range of potential protected disks. Though in Oric land I guess it doesn't matter very much because there just isn't a lot (any?) of protected software.
Re: Yet Another
I think there were a few protected software, for instance XL-DOS is a well known one. IIRC a few games / utilities were too, but I forgot which.
About Read Track, maybe this topic will bring some (depressing) information!
About Read Track, maybe this topic will bring some (depressing) information!
Re: Yet Another
I'm on my phone so possibly skimming more than is respectful to the original authors but, yeah, it sounds like the problem described is simply spurious sync patterns. Which is an implicit flaw of the WD's process. That plus inaccurate emulation by Euphoric throwing the author off track.Symoon wrote:I think there were a few protected software, for instance XL-DOS is a well known one. IIRC a few games / utilities were too, but I forgot which.
About Read Track, maybe this topic will bring some (depressing) information!
I'll read the thread properly and comment there if it doesn't already contain that conclusion.
Re: Yet Another
I've now posted a new version with implementations of read track, write track and read address. So all I'm skimping on now WD-wise is most of the force interrupts. I want to read a little more to make sure I know what I'm doing before I do anything.
The XL-DOS tip was really helpful in the end, as I hadn't even tried it before, and it uses read track. Read track now being implemented, it loads correctly. Damned if I spent enough time to figure out exactly what it's doing, but it looks like it's just checking that some of the gap bytes have meaningful data in them? It issued a read track, waited until the first region of sector data was reached, receiving the expected A1A1A1FB, then stopped paying any attention, causing the controller to set data lost and terminate the command shortly thereafter. I found that if I omitted the A1s from the stream, it declined to load.
The XL-DOS tip was really helpful in the end, as I hadn't even tried it before, and it uses read track. Read track now being implemented, it loads correctly. Damned if I spent enough time to figure out exactly what it's doing, but it looks like it's just checking that some of the gap bytes have meaningful data in them? It issued a read track, waited until the first region of sector data was reached, receiving the expected A1A1A1FB, then stopped paying any attention, causing the controller to set data lost and terminate the command shortly thereafter. I found that if I omitted the A1s from the stream, it declined to load.
Re: Yet Another
Just wanted to drop by to say how impressed I am with your work, here and in the rest of the threads. You brought to light many interesting and unknown (at least by me) information and ideas.
Thanks indeed!
Thanks indeed!