Issue 8 discussions...

Nagging hardware related question? Post here!
User avatar
Gold Card
Posts: 372
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: 337
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.

User avatar
Posts: 849
Joined: Sat Jan 22, 2011 8:47 am

Re: Issue 8 discussions...

Postby Peter » Wed Aug 21, 2019 11:18 am

Dave wrote:See you when the nights get shorter!

Sounds like 21st of December... until then, nights will only get longer. ;)

My wish would still be an available board simply re-using 68008, ZX8301, ZX8302 and 8049 from existing QLs. Dave could then finish the hardware himself without dependencies, saving so much time.

Stability, signal integrity, hardware bugfixes, power supply efficiency, and compatibility for internal QL add-ons would be of great use, even without new features.

I currently have QL mainboards in poor condition, where 68008, ZX8301, ZX8302 and 8049 could be recovered. And I guess this is not an untypical situation.

User avatar
Gold Card
Posts: 372
Joined: Thu Oct 12, 2017 9:54 am

Re: Issue 8 discussions...

Postby Pr0f » Wed Aug 21, 2019 11:22 am

Did someone not have a 'recreated PCB' for the issue 5 or issue 6 board as a bare pcb - i am sure I haven't dreamt that...

I could use one as I have a QL that's got some damaged tracks under the memory, and as a fix I am contemplating a piggy back board lifting the ZX8301 onto the board with a single 8bit wide DRAM of sufficient capacity, RAM has all been unsoldered and removed.

QL Wafer Drive
Posts: 1429
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Issue 8 discussions...

Postby Derek_Stewart » Wed Aug 21, 2019 10:46 pm


Really disappointed about the lack production of the issue 8...

Maybe I should ressurect my olde modular QL project, or there was an idea to reproduce the Aurora from the Gerber files I have.


User avatar
Posts: 2414
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX

Re: Issue 8 discussions...

Postby Dave » Tue Sep 03, 2019 9:37 pm

Sorry guys. I don't work in the summer. Nasta finished the design. I'll be back on it when it cools down.

Who is online

Users browsing this forum: No registered users and 5 guests