Peter wrote:While multitasking is good for the QL operating system, it makes most (male) humans terribly inefficient. Many good QL projects died or were delayed for years because of multitasking.
This is my experience too. It takes me about 10-15 minutes to effectively switch tasks. My conflict is that after 5-6 hours of doing the same thing my concentration starts to fade. So I do 'other items' in 2 hour blocks with 30 minute breaks between them, and the Issue 8 in 4 hour blocks with an hour break. This maximizes efficiency.
I can do 8 hours of work on one thing, but then I see stars - and I do need that 1 hour break in the middle.
Today I am trying to resolve a structural issue that I have with Issue 8:
Nasta decided that the video system should be replaceable/upgradeable, which means putting it on a small "video card". I leaned more towards leaving it tightly integrated, so if a video upgrade for original QLs comes along, it will also work on Issue 8 without changes. We ended up with a hybrid system where the two huge dual port SRAMs are on the QL mainboard, with the A ports connected to the CPU bus, and the B ports connected to headers. This is quite neat, but I found it also problematic because I have a really hard time placing and routing around a connector between the two DPRAMs. There is some VERY tight PCB trace work in there, and putting a connector there makes it *hard* and placing it somewhere else doesn't make sense
to me. Also, if the DPRAM is on the main board, you're committed to it forever.
My proposal is to move the DPRAM onto the daughter card, so ALL the video elements are replaceable. This would allow the system to benefit from a Nasta-made upgrade, or a generic "All QL" upgrade in the 8301 socket. This also means the memory associated with the video system could be changed too, without having to change the mainboard.
This really implements a full internal expansion header across 80 pins or 120 pins (you'll see why this is important later) on two or three 2x20 2mm headers. You could put video, memory, a CPU upgrade, anything there that could go on the extension bus.
I think this is more interesting, because doing this frees up enough room on the board to have
two of these extension ports. So one could be the basic video system, the other a 16M expansion, or a CPU and memory expansion, or... or...
It also leaves plenty of room for a small IDE interface to be placed onboard, with a CF slot under one of the boards.
My dilemma is, this gets well away from the original spec of
a simply reworked Issue 7 QL fixing the obvious things... Once you know you're placing the video system on a daughter card, you either have to not do it, or do it properly and completely.
Let's circle around to the two or three connectors for each daughter card. IF we made sure enough pins were available, we could have D0-31 and A0-31 on there as a private bus between the two cards. This would allow a -for example- 68030 upgrade to talk to a video card in 16 or 32-bit bus widths, the QL subsystem in 8-bits, and everything is idealistic and wonderful.
The trap in all of this is that you either don't do anything and keep it really straightforward, or you split off the video subsystem, and once you do that you can get a lot of miles from a little extra investment, so where do you stop?
And we all knew from the start that feature creep was the enemy of getting things done.