Yet Another

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.
User avatar
Chema
Game master
Posts: 1919
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Yet Another

Post by Chema » Wed Nov 09, 2016 9:06 am

Great!

It is good to see it is improving!

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Wed Nov 09, 2016 3:25 pm

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.
My emulator timer.png
My emulator IRQ.png
My emulator BRK.png

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Wed Dec 07, 2016 1:25 am

Updated again.

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.
Caveat though: something about Fabrice's routines demonstrates a flaw in my disk handling. So every demo I tried, anything that uses Sedoric or any of the other OSes I tested works fine but none of the recent Oric renaissance titles works properly. I'm stuck as to why. Is source code available for the loaders of any of 1337, Space: 1999, etc?

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.

User avatar
iss
Flight Lieutenant
Posts: 439
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Yet Another

Post by iss » Wed Dec 07, 2016 9:00 am

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.
copy.dsk
(500.25 KiB) Downloaded 19 times
copy.jpg

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Wed Dec 07, 2016 1:10 pm

iss wrote:This looks cool. What about the colors - they seams to be very different from the real Oric?
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.

There's also a SCART mode that causes the RGB to appear unfiltered.
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 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.
The attachment copy.dsk is no longer available
The attachment copy.jpg is no longer available
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.

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.
Screen Shot 2016-12-07 at 07.00.25.png
* 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.

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Wed Dec 07, 2016 10:01 pm

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?
Attachments
Screen Shot 2016-12-07 at 09.21.32.png
Screen Shot 2016-12-07 at 09.21.06.png
Screen Shot 2016-12-07 at 09.20.39.png
Screen Shot 2016-12-07 at 09.20.39.png (129.46 KiB) Viewed 1413 times

User avatar
Dbug
Site Admin
Posts: 2299
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Yet Another

Post by Dbug » Thu Dec 08, 2016 9:26 am

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 :)

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.

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Thu Dec 08, 2016 5:26 pm

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.

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Sat Dec 31, 2016 10:31 pm

I've made a further release. Highlights are:
  • disks are now writeable;
  • original colour ROM values are used for composite colour generation.
Caveats are:
  • 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.
I intend to round out the WD before turning my attention back to composite video; but tonight being New Year I expect a temporary break in work. So here's what I had. Happy New Year!

User avatar
Dbug
Site Admin
Posts: 2299
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Yet Another

Post by Dbug » Sun Jan 01, 2017 2:27 pm

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.
Technically, how is read track working compared to read sector?
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?

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Sun Jan 01, 2017 6:27 pm

Dbug wrote:
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.
Technically, how is read track working compared to read sector?
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?
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.

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
So anywhere in your sector that you have the nine-bit pattern 0001 0100 0 — e.g. you encoded the bytes $18 $00 — there's a spurious sync and read track will align itself improperly for the bytes it returns subsequently.

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.

User avatar
Symoon
Archivist
Posts: 1051
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Yet Another

Post by Symoon » Sun Jan 01, 2017 7:46 pm

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!

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Sun Jan 01, 2017 9:15 pm

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'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.

I'll read the thread properly and comment there if it doesn't already contain that conclusion.

ThomH
Pilot Officer
Posts: 68
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Mon Jan 02, 2017 3:14 am

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.

User avatar
Chema
Game master
Posts: 1919
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Yet Another

Post by Chema » Mon Jan 02, 2017 10:38 am

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!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest