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.Peter wrote: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.Dave wrote:This means the CPU never has to wait for video to be drawn, and it also separates the CPU clock from the 8301 clock.
The more people confirm this, the happier I feel about the decision.Peter wrote:Good. I can only second that from my own Qx0 and (S)GC experience.Dave wrote: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.
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.Peter wrote: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!
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.
No, the positions have changed. However....Peter wrote: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.
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.
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.Peter wrote:Personally, I'd also like the 68008 socket available, was this planned?
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.