System Variables - what are the rules...

Anything QL Software or Programming Related.
User avatar
Pr0f
Gold Card
Posts: 287
Joined: Thu Oct 12, 2017 9:54 am

System Variables - what are the rules...

Postby Pr0f » Wed Apr 25, 2018 11:30 pm

I know I am probably opening a contentious topic here, but in considering writing a serial driver for the QL, I need to use one or two variables in the system variables area.

There seems to be 2 purpose built variables for serial 1 and serial 2 read queues, but for a ring buffer I need one read and one write pointer for each queue, so for 2 serial ports that's 4 pointers, And that's only for reading.

I see that in the system variables area there are 'spaces' - are these left blank for a reason, as in future expansion capability, or are these in fact not really blank?

How does one go about playing nice in this critical area?


User avatar
mk79
Trump Card
Posts: 209
Joined: Sun Feb 02, 2014 10:54 am

Re: System Variables - what are the rules...

Postby mk79 » Thu Apr 26, 2018 6:45 am

Variables in the system area must be avoided if possible. Why would a serial driver need them, why can‘t those variables live in the DDB of the driver?

Marcel


User avatar
tofro
QL Wafer Drive
Posts: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: System Variables - what are the rules...

Postby tofro » Thu Apr 26, 2018 7:30 am

Any memory you anchor in the system variables is not going to be maintained by the system - A pure serial driver should easily be able to put any pointers into PDB and DDB, where the memory is to a large part maintained (allocated and freed) by the system. Leave dynamic memory in the places the system designers intended it, for your own mental sanity.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Pr0f
Gold Card
Posts: 287
Joined: Thu Oct 12, 2017 9:54 am

Re: System Variables - what are the rules...

Postby Pr0f » Thu Apr 26, 2018 9:03 am

so that begs the question, why are there 2 pointers in the system variables for serial receive queues for ser1 and ser2?


User avatar
tofro
QL Wafer Drive
Posts: 1423
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: System Variables - what are the rules...

Postby tofro » Thu Apr 26, 2018 10:58 am

Because the system designers owned the System variables. So they could, and they did. You don't ;)

Some of the blank spots in QDOS SV definitions have already been filled with SMSQ/E extensions, so in order to stay compatible, you should at least look into these. And in the last 35 years, quite a number of developers of arcane hardware, drivers and other software, might have used and have actually used some of the other spots for their own purposes, some documented, some not. If you can, stay away from using these spots, you might open up a can of worms.

And you can: The interrupt service routine of a driver receives (together with the system variable pointer) a pointer to the device driver definition block, so it's about as easy to retreive a pointer from there than it is to use system variables without polluting that public space. The DDB is something you define and allocate yourselves in the driver initialisation, so you are free to put whatever you like there. You might even want to consider putting your actual queue storage in there in order not to spread your data all over the place.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Pr0f
Gold Card
Posts: 287
Joined: Thu Oct 12, 2017 9:54 am

Re: System Variables - what are the rules...

Postby Pr0f » Thu Apr 26, 2018 11:15 am

tofro wrote:Because the system designers owned the System variables. So they could, and they did. You don't ;)


That's not really a good answer - that's a bit like this page intentionally left blank. If someone is adding to the infrastucture of the machine, or it's operating system - such as with SMSQ, then provided rules are followed not to step on others toes, then extensions in the area must surely be allowable. It's probably more the fact that there is no longer an active comittee or body to police it...

tofro wrote:Some of the blank spots in QDOS SV definitions have already been filled with SMSQ/E extensions, so in order to stay compatible, you should at least look into these. And in the last 35 years, quite a number of developers of arcane hardware, drivers and other software, might have used and have actually used some of the other spots for their own purposes, some documented, some not. If you can, stay away from using these spots, you might open up a can of worms.

And you can: The interrupt service routine of a driver receives (together with the system variable pointer) a pointer to the device driver definition block, so it's about as easy to retreive a pointer from there than it is to use system variables without polluting that public space. The DDB is something you define and allocate yourselves in the driver initialisation, so you are free to put whatever you like there.

Tobias


Good point - and indeed if I was using the standard linked service routine I can use that mechanism. That provides for external interrupt and polled interrupt. Using another interrupt level is not so straightfoward. The trick with such a ISR would be to keep it's activity as short lived as possible, so as not to unduly upset the standard schedules amd interrupts. Most of a fast serial routine can be handled using the standard device driver and scheduler, but to optimise receive traffic from hardware to queue the code needs to be kept to the absolute minimum. I suspect that's why there are 2 receive queue pointers in the system variables. But that begs questions like - what if I have 4 serial ports and not 2, and what if I provide additional serial ports rather than replace the existing 2 (although this is less likely as they have some massive limitations for what I want to do with them).

It also brings up issues with regard to any attempt to provide usb support - which is a significant extension to the driver system.


User avatar
janbredenbeek
Gold Card
Posts: 271
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: System Variables - what are the rules...

Postby janbredenbeek » Thu Apr 26, 2018 1:42 pm

Pr0f wrote:so that begs the question, why are there 2 pointers in the system variables for serial receive queues for ser1 and ser2?

These are for the internal SER ports, and are handled by the internal interface and transmit interrupt handler. This handler also expects the transmit queues to start at fixed offsets from the receive queues, since the queue size of the internal SER ports is fixed at 81 bytes. That's why there are no transmit queue pointers in the SV area.
As has been pointed out here, if you build your own SER port and driver you will probably need to build a definition block which contains pointers to your own interrupt handler before linking it in. When your handler gets called, A3 will point to the start of the definition block so you will be able to pick up any pointers and other variables stored there. There is no need to use the SV area for that.

Jan.


User avatar
Pr0f
Gold Card
Posts: 287
Joined: Thu Oct 12, 2017 9:54 am

Re: System Variables - what are the rules...

Postby Pr0f » Thu Apr 26, 2018 2:40 pm

Thanks Jan.

So my thoughts are that if I create my pointers for the serial devices at the time the driver definitions are linked in, but leave the pointers empty, only filling them in when the devices are used - this way I can have any size buffer I want to have for the receive / transmit and request memory for it then, and only then assign the pointers to the queue's. No reception needs to be done until the device is pressed into use. Those pointers can be tucked away in a bit of memory assigned for my devices.


User avatar
mk79
Trump Card
Posts: 209
Joined: Sun Feb 02, 2014 10:54 am

Re: System Variables - what are the rules...

Postby mk79 » Thu Apr 26, 2018 10:14 pm

Pr0f wrote:That's not really a good answer - that's a bit like this page intentionally left blank. If someone is adding to the infrastucture of the machine, or it's operating system - such as with SMSQ, then provided rules are followed not to step on others toes, then extensions in the area must surely be allowable. It's probably more the fact that there is no longer an active comittee or body to police it...
In the 20 years I've been developing SMSQ/E I've added exactly two system variables, in all other cases I found a different way.
Good point - and indeed if I was using the standard linked service routine I can use that mechanism. That provides for external interrupt and polled interrupt. Using another interrupt level is not so straightfoward.
Actually it is if you use a similar trick to the one DV3 does: you allocate your memory block and then create trampoline code (within the memory block) on the fly that looks like this (just make sure to clear any code caches on 68020+ afterwards):

Code: Select all

        move.l  a3,-(sp)
        move.l  #[ddb],a3
        jmp     isr_code
This code is then registered as the IRQ service routine. This is in principle faster than using the system variables because clean code does not assume that they live at $28000, so you'd need to call code to detect their location first anyway.
It also brings up issues with regard to any attempt to provide usb support - which is a significant extension to the driver system.
Could be a job for a "thing" then. Though I don't think I'll ever see working USB support on SMSQ/E.

Fun fact, I once got a decent offer to port SMS2 to some modern hardware but ultimately declined mostly because I had the feeling that working USB support was expected then. The offer was nowhere decent enough for that.

Marcel


User avatar
mk79
Trump Card
Posts: 209
Joined: Sun Feb 02, 2014 10:54 am

Re: System Variables - what are the rules...

Postby mk79 » Thu Apr 26, 2018 10:17 pm

By the way, no SMSQ/E serial driver uses the mentioned system variables (but they do get initialised on the Gold card for compatibility reasons).

Marcel



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 1 guest