Issue 8 discussions...

[Dave]

This means the CPU never has to wait for video to be drawn, and it also separates the CPU clock from the 8301 clock.

I'm sure you are aware this can easily cause flicker, and working out synchronization methods. Still my opinion as one of your hopeful cutomers: I have zero interest in speed improvements for this board! If keeping the clocks together can reduce work or risk, please do it.

There won't be flicker problems. As far as the 8301 is concerned, nothing has changed. It never has to contend for memory with the CPU as they are on separate and isolated buses, on either side of dual port RAM that allows both sides to access the same address simultaneously without conflict. I'll be prototyping the new video system in the expansion port in the coming weeks and will post photos/videos. I have 8+ different types and eras of monitors to check for compatibility. There will be a difference in RGB output - it will now be buffered 0.7V p-p legal RGB, ideal for plugging directly into a GBS82*0 without any resistors or other esoteric mods.

We've decided that socketed 74-series logic, the socketing causes more problems than component failures do, so we'll be using SMD parts where possible.

Good. I can only second that from my own Qx0 and (S)GC experience.

The more people confirm this, the happier I feel about the decision.

RAM expansion header... megabytes... video expansion header... ROM expansion header... speed improvents... I know myself that such things are tempting. But my taste for this board remains: Better not here. I prefer this one as close to the original as possible.
Keep in mind that a really fast system would not benefit from all proposed expansions and optimizations. Whether it plugs into this board like SGC or replaces it - it would have it's own. Only saying because you want opinions. Always wishing best luck Issue 8 will ship!

RAM expansion header: as this requires address lines not present on J1 and we do not want to change the J1 pinout, expansion RAM will have to go on an internal header. We placed this alongside the ROM port header, so that's what we called it. This means there's an internal header with all ROM pins, additional address lines and write capability. The ROM port will go away on future systems. The extension bus will change on future systems to increase capability and control costs.
Video: one of the few areas where there's still discussion. We're drawing back from lofty goals. I think people will just be happy with faster video that doesn't overscan, and the cautious addition of a small pin header will bring out any needed signals in the event a VGA-format output card does become available.

Expansions: if it works like a 6800 device, it likely won't work. QEPIII will not work, for example. All other expansions should work natively at 7.5 MHz and will probably work happily up until their individual limits. If they have 80s DRAM on them this will probably be 10MHz. If not, they might go to 12 or 16MHz. Who knows. We'll find out. If you want to be sure your expansions work, run the QL at 7.5MHz or 8MHz.

Another thought: Will the sockets for the main QL ICs be at their original place?
For retro purism (the only reason why I want Issue 8) it would be important that traditional internal add-ons fit nicely. At least all Minverva and (Super)Hermes variants, QIMI, QL-SD.

No, the positions have changed. However....

We have retained the guard spaces around the 8302 for SuperHermes and around a ROM slot for Minerva. the relationship between the 8302 and 8049 has changed, so QIMI will not fit. There will be a compatible solution either onboard or on the first expansion card.

Personally, I'd also like the 68008 socket available, was this planned?

We are leaving the 68008 socket behind. It is huge, and it will be a nightmare for signal quality. The entire CPU bus except /VPA and E will be brought out on the extension bus, because these do not exist on 68SEC000. If it proves sensible to bring /AVEC out where /VPA was, we will do so.

One of the areas of the QL that bugs me is only having 3 levels of hardware interrupt instead of 7. I don't fully understand the implications of separating /IPL0 and /IPL2 - but in later systems this might give some more granularity to the interrupt scheme so that service requests could be handled more efficiently. It would be nice if keyboard/mouse IO were handled at a different priority to storage IO, for example. It never made sense to me that keyboard is polled when it could have been interrupt-driven - it is literally not doing anything 99.99999% of the time the machine is on.

[Peter]

It never has to contend for memory with the CPU as they are on separate and isolated buses, on either side of dual port RAM that allows both sides to access the same address simultaneously without conflict.

This is the problem I meant. When the CPU is writing, while by chance the asynchronously clocked video controller is reading, bits are in unpredictable toggle state, and groups of pixels can flicker with wrong colours or even flashing in MODE 8. The more "action" on the screen, the higher the likelyhood. You need special logic to avoid this, i.e. create CPU waitstates, to synchronize. E.g. on Qx0 with dual-port RAM I also kept the CPU from accessing video lines while they were read.

There will be a difference in RGB output - it will now be buffered 0.7V p-p legal RGB, ideal for plugging directly into a GBS82*0 without any resistors or other esoteric mods.

Very good idea.

We are leaving the 68008 socket behind. It is huge, and it will be a nightmare for signal quality.

For QL speed (which I would prefer) it is no problem at all - IIRC you go for multilayer. In summary of all changes and add-ons, the board is no longer what I personally had hoped for, which was a pure retro board, just a rock solid, top quality, final QL. I would leave add-ons and speed upgrades to other projects and keep this board "pure". But it is just a matter of taste.

One of the areas of the QL that bugs me is only having 3 levels of hardware interrupt instead of 7. I don't fully understand the implications of separating /IPL0 and /IPL2 - but in later systems this might give some more granularity to the interrupt scheme so that service requests could be handled more efficiently.

We have bigger issues when it comes to OS and drivers, than lack of interrupt levels. Like mass-storage buffering methods that can block the whole machine for seconds. And for general drivers, the OS does not support different interrupt levels anyway.

[Dave]

It never has to contend for memory with the CPU as they are on separate and isolated buses, on either side of dual port RAM that allows both sides to access the same address simultaneously without conflict.

This is the problem I meant. When the CPU is writing, while by chance the asynchronously clocked video controller is reading, bits are in unpredictable toggle state, and groups of pixels can flicker with wrong colours or even flashing in MODE 8. The more "action" on the screen, the higher the likelyhood. You need special logic to avoid this, i.e. create CPU waitstates, to synchronize. E.g. on Qx0 with dual-port RAM I also kept the CPU from accessing video lines while they were read.

So they're just visual artifacts? When the screen is already busy changing? I don't think I'm too worried about that. They would exist on one line, for one frame, just as little sparkles to the end of the line. We already have those with the cursor.

For QL speed (which I would prefer) it is no problem at all - IIRC you go for multilayer.

The marginal cost of using 4-layer boards is low, but the effect it has on signal quality and EMI is quite dramatic.

We have bigger issues when it comes to OS and drivers, than lack of interrupt levels. Like mass-storage buffering methods that can block the whole machine for seconds. And for general drivers, the OS does not support different interrupt levels anyway.

Indeed. We should have a Kickstarter and trick Tony Tebby into coming out of retirement.

[Dave]

Today's component delivery for Issue 8.

100x 74HCT574
100x 74HCT30
100x 74HCT541
100x GAL22V10

aaaaaaand...

100 68000 cpus.

Let's check the countdown!

[Nasta]

It never has to contend for memory with the CPU as they are on separate and isolated buses, on either side of dual port RAM that allows both sides to access the same address simultaneously without conflict.

This is the problem I meant. When the CPU is writing, while by chance the asynchronously clocked video controller is reading, bits are in unpredictable toggle state, and groups of pixels can flicker with wrong colours or even flashing in MODE 8. The more "action" on the screen, the higher the likelyhood. You need special logic to avoid this, i.e. create CPU waitstates, to synchronize. E.g. on Qx0 with dual-port RAM I also kept the CPU from accessing video lines while they were read.

This is already an issue with 8301 as it reads 4 bytes of RAM at a time and lets the CPU only write one byte at a time, yet uses a bitmap layout where 2 bytes must be accessed to alter one pixel. So a condition may occur where the 8301 reads the two mid-ways between the CPU altering them, and gets only half of the pixel data right - sometimes this can be seen on the cursor flash. This sort of thing can't be avoided even with DPRAM unless the CPU side bus is made 16-bit.
However, what is discussed here is that with DPRAM the CPU can LITERALLY be modifying data as it's being read from the 8301 side of the DPRAM, resulting in indeterminate data being read by the 8301.

Fortunately, the DPRAM already has a contention detecting mechanism, it has an internal address comparator that is triggered using chip select on either side, and is internally timed and presented as a /BUSY output to both sides. Since the 8301 has no way of waiting for the data, the main CPU has to wait for the contention condition to pass. It is easy to wire the /BUSY output into the transfer acknowledge logic of the CPU and postpone the CPU side access while the 8301 is trying to read the same address.

Let me emphasize: the CPU then gets slowed down ONLY if it is accessing the exact same address as the 8301, and that's done on a address by address basis, the address is addressing bytes. So, the 'reading a word mid way between updating both bytes of that word' problem is not solved because this is really an underlying problem of the bitmap organization, but the simultaneous read-write contention is easily solved.

That being said, it is actually possible to (very carefully) construct a scenario where the (faster clocked) CPU can hit a contention condition, be slowed down, only to follow 8301 accesses and be slowed down again, etc. to a point where it would actually be slowed down to 8301 reading speed. The CPU would have to run at 20MHz or more (which in fact it could on this board) and would then be slowed down to an equivalent of 'only' 10MHz zero wait... which is about 3x as fast as 7.5MHz 68008 trying to do the usual dance with it's 8301 on a regular QL motherboard. So, just for that rare eventuality and in case the problem ends up not being much of a problem, there will probably be a jumper to disable the contention mechanism.

Then again, when the VGA compatible 8301 replacement comes, it may well need to be re-enabled as that reads about 7x faster than the 8301 so the problem can occur 7x more often and become annoying.

We have bigger issues when it comes to OS and drivers, than lack of interrupt levels. Like mass-storage buffering methods that can block the whole machine for seconds. And for general drivers, the OS does not support different interrupt levels anyway.

I guess a driver can be written to support an extra interrupt level (5) on it's own but I find that even 3 would be just fine. There is the minor issue that hardware has been somewhat... mishandled, so it's not easy to implement a proper NMI (to similar advantage as it was on the Spectrum, to get snapshots of games that could then be stored on a disk). I did think about this and every time something like a motherboard replacement was on the table, I've been tempted.

But back to the point - YES YES and YES, I am all for mass storage buffering, and not only that, although it's not as important as it used to be, even serial ports and NET will bog down the machine due to the bit-banged nature of either one or both ways the data flows. The one big culprit are the floppy drives - for those who still use them.
Most mass storage devices equivalent to a hard disk (which also includes all sorts of flash based storage) do indeed buffer, but then the drivers usually do a software poll to read them. The best that could be done is poll them in the scheduler loop but once there are a few non-trivial jobs running, that can become way to slow (like 25k bytes a second..., actually 1 sector, typically 512 bytes, at a 50Hz rate).
Q40/60 and 68 I guess have the advantage of providing a fast poll interrupt. I wanted to implement just that on the GF, for the exact same purpose - and I explained the fast poll idea in a related thread just recently. In fact, this would be the only reason why I would support the idea of one more higher priority interrupt, which would be level 5 on the QL, but with some clever OS trickery (which I believe has already been done) even the one level we have now will do, BUT that does benefit from a faster CPU.
Another mechanism was already discussed, as an idea to replace 8302+IPC with something more capable. Really fast uCs are almost dirt cheap today, and can interface to the QL through a small DPRAM. That pretty much solves the problem, hardware-wise. But as always, it's the software development that is the real problem.

[Peter]

Q40/60 and 68 I guess have the advantage of providing a fast poll interrupt. I wanted to implement just that on the GF, for the exact same purpose - and I explained the fast poll idea in a related thread just recently.

This can be done by setting bit 0 of the Frame Rate Register:
$FF00 0038 on Q40/Q60 and $1C038 on the Q68.

It changes the Level 2 "Frame interrupt" request rate from 50 Hz to 200 Hz.
(BTW it does no harm to POKE, one will just notice the faster blinking cursor and keyboard repeat.)

I much agree with Nasta that a higher poll interrupt rate would be helpful for typical QL situations, where hardware either produces no interrupts, lacks hardware-side bufferspace, or the drivers are too primitive to support device specific interrupts. Common polling reduces the stack operations overhead, which can lead to a good compromise. However, the 50 Hz rate was too "sacred" to ever be touched by any QL OS and is only used by Linux on Q40/Q60. Otherwise, I'd have provided even more frequency options.

I used the faster polling a lot during Q68 ethernet testing. Reducing things to 200 Hz polling would have made things easier and more efficient than the mix of 50 Hz poll and individual network IRQ I had to implement.

Note: The Q40/Q60 also provide a 20 kHz higher level interrupt, which I do not recommend for machines slower or equal to Q68. The overhead is just too high.
Therefore, the Q68 hardware buffers for sampled sound have 2 KB size - large enough so they can be be filled only every 20 ms = 1/(50 Hz).

[Dave]

4M card coming along. This is the previous version, but it boots. Mostly

The blurry ICs in the background are probably the most exciting element of the photo, but let's just save that for another day.

[Derek_Stewart]

The blurry ICs in the background are probably the most exciting element of the photo, but let's just save that for another day.

Is it a virtual memory Interface or protected memory system?

[Dave]

The blurry ICs in the background are probably the most exciting element of the photo, but let's just save that for another day.

Is it a virtual memory Interface or protected memory system?

No.

[Dave]

So here's the state of play on Issue 8.

We're looking at shortening the QL mainboard. If you don't use the ROM port, you can gain 7cm of your desk back, by having expansions move 7cm further inside.

A 7cm spacer/memory expansion would be included that implements the ROM port, and could come with 0, 4 or 12MB of RAM. If you have good SMD skills you can upgrade the card yourself and save a bit of money.

The last things to be sorted are:

Whether to include 1 or 2MB of SRAM onboard. This puts the memory expansion boundary at either 1MB or 2MB, and since I'd be using 2MB DRAMs for the external expansion it makes sense to start them on the 2MB boundary. It makes the address decoder a little simpler and quicker. Having one DRAM be mapped in for a low and a high 1MB is a pain. Also, 14MB is a friendlier RAM amount than 13MB, especially given a 2MB device is planned to slot into the top 2MB later.

We're suppressing /DS if the address is anywhere above the 1MB original address range, so expansion cards will not alias themselves throughout the entire 16MB address range. Is anyone aware of a card that might be badly behaved about this?

We'd like to extend Minerva to include the SMSQ/E feature of auto-correcting timings for CPU speed. Also, make sure it works happily with memory over 4MB.

Finally, I am working hard on the serial card. The hardware is quite clear-cut. I have found exactly the changes I need to make to the existing 6850 UART driver written by Jan Bredenbeek. Unfortunately, I don't know assembly well enough to make a competent job of it and I also do not have the tools to compile 68000 because I'm a SuperBASIC luddite! I plan to post the details on QL Forum in a week or two, and if anyone would like to take it up, I and all the future fast serial users would be eternally grateful. Mostly, the existing driver supports SER3, and I'd need to extend it for SER4. It has a different init routine. Finally, the device I chose has 16-byte FIFOs so if it could do more than single character transfers it would really lower the service requirement of this card. The IO area of this UART would be in the internal IO area, as I plan to build the device into a future board and that's where it belongs.