Hardware programmable timers

[Peter]

Maybe connecting a Raspberry Pi or Pico to the Q68 expansion bus could achieve this, just then got write the SMSQ/E device driver and the Pi code to send data from the GPIO pins attached to the Q68 expansion port to the Pi USB connector.

A directly connected FDC controller as Dave suggested would certainly be easier.

But it is only 8 but transfers, might be slow?

Easily fast enough for floppy.

[Derek_Stewart]

Hi

Floppy Disks were a great enhancement to the QL in 1990s with a Trump card and 4 Double Density drives, then the Gold Card and Super Gold card gave access to High Density disks made the QL an excellent computer.

But over 30 years on, a 1.44Mb or 3.2Mb disk has some limitations on size and access.

I mentioned a USB Floppy just an idea on what to connect the Q68 Expansion port.

Maybe a RPI 2W could have WIFI implemented on the Q68, but the Q68 has Ethernet, QL NETwok access to other QL, QXL and QL emulators via QLUB and the Spectrum Next QL Joy2Net adapter.

Much faster as easy to setup than floppy disks.

[Dave]

Having settled on a counter-based system, I have some subtleties to address.

I think this question will get its most qualified answer from Peter or Nasta.

Can an interrupt be too frequent? Even in the fastest system? Is there any case where an interrupt over, say, 8096 Hz is useful?

I ask this very cautiously because the creation of registers is expensive in terms of logic if the logic is to remain in scope of a modest CPLD. In an FPGA this is not a concern, but at this stage an FPGA is an excess.

The issue is I would like a divider to be set, but also an interrupt number associated with that interrupt. The flip flop cost of a 16 bit counter, a 3 bit IRQ number and an up to 8-bit vector is expensive. Limiting the system to 16 expansion cards maximum does allow a limit of 16 vectors within the possible range to be used.

This creates a conflict because it is stated that Minerva starts at the top of the autovector table and doesn't leave room for the manual vector table that would reside right above it. QDOS certainly doesn't. This makes it likely I am limited to using alternate interrupts but restricting myself to autovector.

This leads into the second fork in the road:

This is disappointing because it limits the number of different cards that can uniquely interrupt to 4. Past that, alike cards would need to share an interrupt. I am sure if two identical cards in different slots share an interrupt, the person who develops them can write the handler to query the cards and have only the relevant one respond. This does mean only one card in the group can issue an interrupt at a time. The other card would have to be held up until the first card is acknowledged and negates its own interrupt request. You can see why this isn't ideal.

So, passing the buck to the programmers, what approach would close the fewest doors to accessibility in managing interrupt generating hardware?

[Pr0f]

I've been looking at that bit of code in Minverva quite a lot - After the Autovectors - there is basically a block of code to do the redirection of the vectors that are supported in Qdos, then the code to display the logo. I think it might be possible with some careful thought and adjustments to free up the vectors area and move 'rd' to 400Hex.

Thre other option is to use the FC lines to decode the interrupt handling and place the vectors in parallel memory.

[Dave]

Good thoughts.

I don't know if anyone would do the work on Minerva. If they did, I don't know that it would benefit others. It creates a need for a custom Minerva fork for one family of compatibles.

I'm also wary of anything that requires hardware that existing clones don't have and can't get. I have no experience with using the FC0..2 codes to have different parallel memory at common addresses. The idea of system and user data in aliased/overlaid addresses is just *weird* to me. If it's something that 68K systems to all the time and it's an assembly coder common skill, sure.

I'll force my mind to keep open and read up some. My unfamiliarity/discomfort isn't a reason things shouldn't happen. I'm not here to make a lowest common denominator system.

[tofro]

Can an interrupt be too frequent? Even in the fastest system? Is there any case where an interrupt over, say, 8096 Hz is useful?

Of course it can. Interrupt handling is expensive, on a 68k it's 44 cycles, which is roughly 2-3 instructions (not counting the handler and the rte, and this is for auto vector interrupts. When the device provides the vector, its even worse - remember, for a 6502 its 13 cycles...). All in all, I would assume you can't write even a do-nothing interrupt handler (other than the bare necessities) using less than 200-300 cycles. With a cyclic interrupt, you're taking away these cycles from the rest of the system, effectively slowing it down.

I ask this very cautiously because the creation of registers is expensive in terms of logic if the logic is to remain in scope of a modest CPLD. In an FPGA this is not a concern, but at this stage an FPGA is an excess.
The issue is I would like a divider to be set, but also an interrupt number associated with that interrupt. The flip flop cost of a 16 bit counter, a 3 bit IRQ number and an up to 8-bit vector is expensive. Limiting the system to 16 expansion cards maximum does allow a limit of 16 vectors within the possible range to be used.

Reminder: Jumpers are the cheapest registers.... And would even be "period-correct" considering what PCs did after the QL had died.

This is disappointing because it limits the number of different cards that can uniquely interrupt to 4. Past that, alike cards would need to share an interrupt. I am sure if two identical cards in different slots share an interrupt, the person who develops them can write the handler to query the cards and have only the relevant one respond.

That shouldn't be much of a problem. Note the driver needs to know where in the address space the interrupting card is anyways - and detecting which of several cards triggered it is not much more work. But remember, the QL system architecture has no concept of "multiple cards the same" to occupy one single ROM space. I guess the simplest (maybe dumbest) approach would be to load two identical drivers into non-shared address space and two separate interrupts. I feel that's a waste.

This does mean only one card in the group can issue an interrupt at a time. The other card would have to be held up until the first card is acknowledged and negates its own interrupt request. You can see why this isn't ideal.

Well, that is a problem if the device provides the vector, and that is why auto vectoring is so much simpler. I'm not sure a system with a QL background justifies the effort of supporting vectored interrupts.

[M68008]

Interrupt (level 2) on the QL is slow as it calls the QDOS handlers. I think it also slows down the CPU while it's pending since it asserts the VPA signal.
If you can avoid both, and on faster CPU, it could run much faster.