Welcome, Guest. Please login or register.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - TomH

Pages: [1]
Very minor: I've added Enterprise emulation to the emulator that I write, Clock Signal, for macOS and other Unixes.

GitHub; macOS binary releases; Linux binary releases via Snapcraft.

On macOS it's a fully-native, signed application using Metal and the native UI. Elsewhere it is available both as a Qt GUI application and as an SDL build that's more useful for command-line invocation and for file associations.

Probably its most interesting feature is that it can simulate composite video by generating and then decoding the actual composite video stream. No post hoc blur-it-up-a-bit filters here. It also does audio by sampling internally at a sensible native rate for the emulated machine and then low-pass filtering down to whatever your host machine can output. So e.g. on any garden-variety Mac from the last decade or so you can listen to your Enterprise at 96 kHz.

That all being said, Enterprise support is very provisional and known to be imperfect. So tolerate it only as far as you can.

  • it supports IMG files only, there's presently no other way to load software; and
  • something is definitely off in terms of timing.

Notable software issues of which I'm aware include the conversion of the CPC version of Chase HQ playing its sampled sound (like 'Let's go, Mr Driver!' way too quickly, but then weirdly slowing way down every time it would make a sound effect that the Spectrum would use its toggle speaker for; and SIDBASIC reporting a 3MHz CPU And then just not playing any audio. Like, no Dave writes at all, not like I'm processing the audio incorrectly.

Any other feedback would be greatly appreciated. Some screenshots are attached. Alternatively, here it is on YouTube.


Some random technical details, in case they're interesting:

In this implementation Nick runs 40434603/11360000ths as fast as the CPU, which is currently always 4Mhz. So I've clocked Nick at around 14.2375Mhz.

If the Z80 performs a Nick access it must wait to start the final clock cycle of its machine cycle until it is in the first two Nick cycles of the six-cycle block allocated for Z80 access. I should read mode on this. I observed that the entire six-cycle window is only around 1.68 Z80 cycles long, but of course the Z80 is paused in half-cycle increments so the maximum it could depend upon getting is 1.18 cycles of clear space. Hence fitting the final cycle into that window.

Nick's interrupt output is adjusted immediately after reading that byte of the mode line.

I wasn't clear on the correct way to transition between noise polynomials on Dave, so that's probably inaccurate. But the LFSRs all use IstvanV's documented polynomials, at least.

lgb.hu mentions that "There is some odd behaviour that you can read the (Nick's) bus state on these I/O ports. In theory it can be used for some video effects. I can't say I can understand that very well though :)"; through a lack of further information reads from my Dave return the last byte fetched, if any, otherwise 0xff. That's permitting for the fact that I haven't read up on how the refresh addresses are generated though.

As per my reading of the documentation, column 10 is the first one output in composite mode. The colour burst covers columns 8 and 9. Output starts at column 8 in RGB mode, even on lines in which a mode line isn't read.

There's a simulated spinning platter for disks, so floppy access should be approximately real time.

Because the simulated CRT runs a couple of phase-locked loops to track discriminated syncs, you'll get some screen bouncing during phase-breaking display transitions.

It's likely I'll add tape image support before figuring out a way to bridge to the local filing system, though for the latter I'm thinking of maybe implementing an IDE drive and mapping FAT back and forth. That'd be more reusable with other machines I implement, e.g. the MSX and Atari ST both also use FAT12 and FAT16.

I forgot I hadn't yet implemented the 8/12MHz Dave divider. It'll be in the next release. I don't think it factors into any of the known incompatibilities.

Apologies; this'll probably just reveal that I've misread or misunderstood documentation. But here we go. These are a couple of demos that superficially appear to be doing nonsensical or incorrect things, to this observer.

The relevant parts of my understanding of a single Nick line are:
  • slots 0–9 are unusable for pixel output because that's where sync and the colour burst occur; and
  • mode line parameters are fetched during slots 0–7.

So then can anybody explain how Scroll Demo is acting correctly in defining its vertical sync mode line as being two scan lines long, with a left margin of 0 and a right margin of 63? That's given that the mode line is entered from a region of the border colour.

To my understanding that should produce only a single line of the sync level. By the time the left margin has been read from the mode line, Nick is in column 1. Therefore at no point on the first line will the current column be equal to the left margin, so sync output won't begin. It'll begin at the start of the second line but then end slightly less than a line later when the next mode line is read in, with a different mode byte.

Therefore total sync time will surely be less than a line, not enough to trigger vertical sync on most screens? The PAL standard is 2.5 lines.

My question for The Time's Hand is somewhat more straightforward: it defines a left margin of 9. So am I correct to conclude that its first column simply isn't visible on composite and RF connections? That column should be occupied by colour burst.

I guess an underlying question is whether the numbers given for Nick above were true in production. In theory you could have moved up the sync to overlap the three slots at the end of each line reserved for refresh, and then have finished the colour burst before the mode line is even done. Which would explain Time's Hand, albeit make the problem slightly worse for Scroll Demo. Though an alternative explanation for the former could just be that the developer used an RGB connection, and that route gets pixels from slot 8 onwards, having no colour burst to include?

Apologies; the subject line has a character limit to ensure brevity — I hope that doesn't come across as aggressive.

So I'm limbering up to write an emulator, after a few years of casually reading documentation from time to time, with Enterprise.iko.hu being the best source that I've yet found. But the published information on DAVE in particular seems to lack some detail so I was curious as to whether the community has filled in the blanks?

In particular there are quite a few references to polynomial counters, both for distortion and for noise generation, including mentions of 4-, 5-, 7-, 9-, 11-, 15- and 17-bit counters. Has anyone ever determined which polynomials are in use? Even at 17-bit it looks like there are only 7,710 possible polynomials that give the full 2^17 - 1 range, so it feels like if you had a sample from the original machine you could do a brute-force search?

There's also the high-pass filter (and, for noise, a low-pass) and the ring modulator. Is anything known about the on-chip implementation of those? E.g. the SID performs ring modulation by a simple MSB substitution, is there any known similar smoke-and-mirrors stuff going on here?

If these things are currently unknown then fair enough; sorry for the barrage.

Programming / Once more on timing
« on: 2018.July.17. 15:48:10 »
Hi, sorry — I've collected notes from miscellaneous sources and am curious as to whether I've understood what I'm reading. Is the below an accurate summary of the timing behaviour of an Enterprise 64?

In PAL there are 283.7516 colour cycles per line. An Enterprise outputs slightly longer lines than spec, each one being exactly 284 colour cycles long. So it outputs 283.7516/284 * 15625 = 15611.3336268 lines per second.

In each of those lines there are 171 RAM access windows. Two out of every three are occupied by Nick. So only one out of three is available for the Z80.

The Z80 is ordinarily clocked by a separate crystal at 4Mhz. If it wants to access RAM, or a Nick IO port, it has to be aligned to the next available access window. This is performed by stopping the clock. The clock will always be stopped for an exact number of 4Mhz clock transitions, i.e. half cycles.

So, as awkward as it turns out to be, I make that 121303809/363520000 RAM access windows per Z80 clock transition. So it is very nearly true that three clock transitions, or 1.5 cycles, is the length of an access window, but not quite. It's actually slightly less — more like 1.498.

In addition to this there is a WAIT generator, which can be disabled, enabled only for M1 cycles, or enabled for all memory access cycles. When enabled it will pad the relevant cycles out by holding WAIT for a single 4Mhz cycle.

Dave accesses don't require alignment to an access window, ROM accesses don't require alignment. On an Enterprise 128, accesses to the additional 64kb don't require alignment, and neither does access to the contents of any RAM expansions. It's only the 64kb of RAM that Nick can access that require arbitration.

So then Nick has bandwidth for two-thirds of 171 bytes per line = 114 bytes, which break down as LPB fetch for 16 bytes, graphics fetching as defined, then six bytes to effect RAM refresh.

I have to admit to not yet knowing whether the mode line is fetched afresh every scan line or whether Nick just does busy work in the more common case when a mode line is longer than a single scan, but either way the slots don't become available for the Z80 or for anything else.

Pages: [1]