Issue 8 discussions...

Nagging hardware related question? Post here!
User avatar
Gold Card
Posts: 366
Joined: Thu Oct 12, 2017 9:54 am

Re: Issue 8 discussions...

Postby Pr0f » Wed Aug 14, 2019 12:48 pm

Nasta put a good explanation in the ZX8301 thread, it's to do with I/O access being subjected to the same delays as RAM access when it need not be. In the Issue 6, the HAL does the decoding for the ZX8202, and it can provide DTACK.

Gold Card
Posts: 331
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Issue 8 discussions...

Postby Nasta » Wed Aug 14, 2019 4:54 pm

The 8302 does not have any significant impact on the speed of the whole machine as it's usually accessed in short bursts and, compared to RAM, infrequently. That being said, several pieces of code that access various parts of the 8302 are quite timing critical. Having the 8302 connected to the RAM bus makes it subject to the same slowdown as the RAM, and this, from the standpoint of the code using the 8302, happens quite unpredictably. The corresponding timing inaccuracy is not huge but may also not be completely irrelevant in things like NET and microdrive access.

There is, however a hardware bug that is present on boards that do not have a HAL chip, which just happens not to affect the machine literally by pure accident. This has to do with how interrupt acknowledge is handled. On the QL, autovectored interrupts are used, which means an interrupt acknowledge cycle must be detected as usual (the QL uses a very simple method of just checking for FC0=FC1=High) but the cycle must be terminated by VPAL going low, rather than DTACKL going low. In pre-HAL versions, both go low, which is, according to the 68k user manual, an illegal condition which may result in unpredictable operation of the CPU. As pure luck would have it, because of the way the signals are generated, VPAL goes low before DTACKL and the CPU recognizes that, rather than the undefined condition that immediately follows.
The HAL corrects this by supressing DTACKL going low on interrupt acknowledge. Since some signals are re-used, it was a fairly simple matter to add decoding logic for the 8302, that has to have it's data bus connected to the CPU data bus, rather than RAM data bus - as this simplifies said logic, and at the same time makes the 8302 access time completely uniform and zero wait state.

In ISS8 we decided, logically, to implement the same fix, especially since the CPU is changed to a 68SEC000, which implements autovectoring using a dedicated pin to signal it, and also requires that DTACKL does not occur simultaneously with that signal.
The added benefit is that the 8302 appears to be able to operate much faster than the traditional QL bus speed, which makes ISS8 much more flexible when it comes to how fast the CPU can be clocked - even though it still uses an old Sinclair ULA.
Basically, the opportunity to have this all fixed and making it more flexible, presented itself at no extra cost in money and time, so why not implement it.

Now, the somewhat sad part of this story is that the HAL could have been implemented from the very start, and one consequence of that is, the PCENL pin on the 8301 (which is used as a select signal for the 8302) would not be needed. Also, the DSMCL pin on the 8302 becomes redundant as well. Meaning, both ULA chips could have had one pin to be used for an additional function, and I am sure whatever it was, it would have come in handy.

Who is online

Users browsing this forum: No registered users and 9 guests