Floating a thought to understand the issues...

[Artificer]

Andrew wrote :
but we need more software for what we already have - and especially expanded QLs (including Q68)

Yes I agree, there is a lot of interest in possible hardware developments but basically you buy the hardware to run the software you want so what software needs are driving these hardware discussions?

My guess is at the bottom line as has been for ever is communications, QL to QL, QL to other computers and the holy grail is to connect with the internet. But as ever the connundrum is that if the hardware does not exist to support whatever then the software will not be written. But the Q68 now exists.

Cheers

[Andrew]

1. To allocate "blocking" tasks like large file transfers on their own CPU. This suggests four CPUs - one for blocking tasks, one for non-blocking tasks, one for jobs and one dedicated to handling windows/screen transfers.
2. To increase the proportion of jobs happening inside cache memory. This provides a handy performance boost.
3. Large memory doesn't get used because it has never been available. If it were available, we'd start using the QL as a tool to handle large data-sets.

4. Getting a faster CPU is very expensive, both in cost and in design effort. Using multiple £3 CPUs is MUCH cheaper from the design point of view, and multiple copies of a simpler thing. Four 68EC030s will outperform a 68060 for 1/4 the cost.

It strikes me that if you accept a machine will use SMSQ/E and not be Qdos/Minerva compatible. the OS was almost written with this jump in mind.

I seems to me that you did not quite understood my Why
From technical point of view I understand what you are saying - and I am confident that you and others from the QL world have the technical know-how to build it. And in another 5 years maybe create a full-functional new OS
And then what ? What programs would you run on it ? What multiple jobs ? What software would handle those large data-sets that you talk about ?
It seem so me that, in the retro-computing world, the QL could not compete with his older sibling, the Spectrum - and we dream to compete with PCs.
We need new software.
And maybe creating some packages like Spectrum's Adventure Games Creator and Arcade Games Designer would do much more in attracting new people in the QL world.

[Dave]

It seems to me that you did not quite understood my Why [...]
And then what ? What programs would you run on it ? What multiple jobs ? What software would handle those large data-sets that you talk about ?
It seem so me that, in the retro-computing world, the QL could not compete with his older sibling, the Spectrum - and we dream to compete with PCs.
We need new software.
And maybe creating some packages like Spectrum's Adventure Games Creator and Arcade Games Designer would do much more in attracting new people in the QL world.

Yes, that's all well and good, but this thread is all about understanding the issues of implementation; not for lamenting the dire situation with regards to software and OS development, where the OS is maintained by effectively two people and their only source of feedback is bug reports for obscure bugs from the 80s. It's assumed to be a basic understanding that with so much existing software, it would have to run on this revised system with no changes, and no awareness that anything was different.

The software and OS situation are peripheral to this whistful musing. It's a thread about what is theoretically possible, not a roadmap, and definitely not a place for negative dismissals. They do nothing to move the conversation forward - and it is ONLY a conversation.

The mentality of it is so typically British. I mean, why imagine what an old car would be like if it was running? It's not, and there's rust, and it's got a flat tire, so why bother imagine? Why muse about interesting possibilities and see what ideas come out of it that we CAN apply, when instead we can focus on all the crappy things?!

The hardware people do not have to wait for the software people, or nothing will ever get done. The software people do not have to wait for the hardware people, for the same reason.

[Dave]

My guess is at the bottom line as has been for ever is communications, QL to QL, QL to other computers and the holy grail is to connect with the internet. But as ever the connundrum is that if the hardware does not exist to support whatever then the software will not be written. But the Q68 now exists.

I agree.

One area I had discussions with Peter many years ago was that I strongly disagreed with his choice of ethernet chip. It's a dumb device, so the stack, encryption, everything had to be handled by the system, and at the time I felt like this was an insurmountable hurdle. It would take years to develop the code to make it all work, and I felt that even then it would provide a minimally satisfying solution.

What I didn't take into account was Peter's focus and determination.

I don't know where we would be now if he'd chosen the Wiznet 5300. Maybe better off, maybe not. The ESP32 changes the equation somewhat and if he had it to do over, maybe he would choose that? I don't know.

The thing is, ESP32 options have been available for the QL, but sales have been surprisingly slow. No killer app has shown up. A multiplayer online game would be.... AMAZING. As long as it kept its bandwidth needs down low, around 500-1000 bytes/sec, we could have serious multiplayer game.

I've been writing one. It *needs* 4 players, but is better with 6 or 8. I'm not a programmer, though, so....

Runs quite quick on the Q68 though.

[Peter]

I've been writing one. It *needs* 4 players, but is better with 6 or 8. I'm not a programmer, though, so....
Runs quite quick on the Q68 though.

Any screenshots? In which language is it written?

I picked the CP2200 ethernet controller for the Q68 because I wanted the software on SMSQDOS side, as a principle. Offloading everything to a different CPU/OS like the emulators or the chips you mentioned is far easier, but it tends to move software development away from our wonderful 68K architecture.

Another point for the CP2200 was that it can directly and efficiently interface the QL, because of its parallel 8 bit 5V tolerant bus. This allows a trickle-down effect from possible Q68 developments.

[Dave]

I've been writing one. It *needs* 4 players, but is better with 6 or 8. I'm not a programmer, though, so....
Runs quite quick on the Q68 though.

Any screenshots? In which language is it written?

It's just blocks at present, so I'm quite embarrassed by it. Sorting out the basic functional game-play. Just working out the NPCs that fill in when there's a shortage of real players has been.... interesting.

Essentially, if 4 people play, three are assigned "zombie" status and the fourth "survivor" status. So it's a bit like Pac Man except the people chasing you are actually PEOPLE. Also, the environments aren't just blank maps, but rich graphical environments, and you have missions.

In each round, the zombie that catches the survivor plays the survivor in the next round. They get to continue with their story.

You have to make it out of your house to the supermarket. Through the parking lot. Through the store shelves. Out through the back. Through the warehouse. Countryside. Farm. Army base. Secret lab. To make it interesting, the zombies can only see the survivor if he's moving and has line of site, and for a few steps after that. More steps if the survivor is running, less if they are walking or stopped. Also, the survivor has stamina which wears out, so he can outrun a zombie *at first* but if he continues running he gets tired and slows. So sometimes hiding is a better strategy, and for the zombies (who can always see each other) spreading out and actually searching is the best strategy - IF they decide to co-operate. If 6 people pay, 2 are survivors. If 8, 3 are. They can either team play and get everyone through by tun use of running and distraction/leading away. SHIFT arrow makes for running. CONTROL arrow is "making noise" to lead the zombies a certain direction. The zombies do not know how many survivors there are. I might mix it up a bit more and make it so the survivors and zombies are semi-random and don't know how many of the other side there is.

When it's a bit further along, I'll public beta it, but it is written for the ESP32. There can be plug-ins for other ethernet chipsets or serial bridges.

Between rounds, there is a telnet-based chat facility so players can chat between rounds. This gives time for people to join/leave, and something to do if they join while a game is in progress. It requires a server, which is a QL. The server does the intercommunication (which is UDP)

I picked the CP2200 ethernet controller for the Q68 because I wanted the software on SMSQDOS side, as a principle. Offloading everything to a different CPU/OS like the emulators or the chips you mentioned is far easier, but it tends to move software development away from our wonderful 68K architecture.

Another point for the CP2200 was that it can directly and efficiently interface the QL, because of its parallel 8 bit 5V tolerant bus. This allows a trickle-down effect from possible Q68 developments.

I think the CP2200 choice is pure. My inner conflict is the same as Andrew's. Who is going to develop the drivers and any software to use it? It's a catch-22. My frustration is that I am facing the same catch-22 daily with the lack of driver for the serial card. I know I sound bitter - it's just really hard to develop hardware and not be able to go any further with it because it doesn't work due to weakness in an area where I am quite inadequate. I'm a brute force programmer, limited to BASIC for the most part. I have a couple of hand-coded assembly bits in my game that just do screen draws. Everything's word-aligned so the burden is quite light.

Just saying, I understand the decision a lot better now I have been on the receiving end of it, and I empathise!

[Peter]

My frustration is that I am facing the same catch-22 daily with the lack of driver for the serial card.

You can find a nice standalone serial driver here:
https://github.com/janbredenbeek/QL/blo ... M/ser3.asm
It is for the historic ACIA 6850, but should be relatively easy to adapt to other chips. Which chip do you use?

[Dave]

That's really old school.

SC28L92 or SC28L94, both pin compatible with the 68681 but support much higher rates. I'm working on a ROMable driver, but it's a bit like a monkey trying to build a rocket.

[Peter]

That does not sound like something compatible has been used before. So the work to read the data sheet and find the right configuration values and register locations can not be avoided.
But that does not require high programming skills, just diligence and time. I can not see why Jan's driver would not provide what you need, if you adapt register/bit locations and init values.

If that is more work than you want to invest, you could look if you find something 16550 compatible, where drivers for the Q40/Q60 exist (but not as nicely isolated for standalone usage as the one from Jan).

[Pr0f]

I think Jan's driver has some mileage with those enhanced 68681 derivatives, but that old serial chip had quite simplistic interrupt logic. It raised the interrupt condition, then you had to get the interrupt status from a register in the acia to determine what caused your interrupt and jump out to the relevant part of the handler.

Those DUART chips still have the same kind of ISR built in, but for those that are Motorola Interrupt mode, they are expecting to use the vectored system that has basically been disabled on the QL platform.

EXTINTL still allows external hardware to flag the interrupt, so it should be possible to 'cripple' the DUART and make it work in the same old school fashion. I got stuck at the breadboarding stage, so never got beyond linking a ROM in and seeing the hardware - perhaps it's time to get back in the saddle, now that things at home and work have calmed down a little...

My end goal was to see if a faster dedicated interrupt could be used, effectively bypassing the QL linked interrupt scheme, and only using it to flag that data was in the serial queue if any program wanted. The vectors would have to be overlayed when an interrupt was processed, so that the custom vector could be used. Messy but the only option I could see for an unexpanded QL (dodges rocks and abuse coming my way)...