Request for advice: programming a TASK (not a JOB) in C68...

Anything QL Software or Programming Related.
martyn_hill
Gold Card
Posts: 437
Joined: Sat Oct 25, 2014 9:53 am

Request for advice: programming a TASK (not a JOB) in C68...

Postby martyn_hill » Tue Jul 03, 2018 4:26 pm

Dear gurus...

Question: Is it practical to program a 'task' using C68 on the QL, as opposed to creating a standalone QDOS 'job'? If so, what advice do you have?

Background:
In my on-going effort to bring the QLUB adapter to life (QL Net to USB device - for QL emulators to talk directly to real QLs) beyond my earlier proof-of-concept in SBasic, I've been battling for many months with writing the interface between a standard QDOS device (at the m/c level) in to what I've chosen to call the "MQSvr" or 'Message Queue server', which will probably be written as a Job.

According to this design, it is the job of the MQSvr to sit between the low-level device driver and whatever physical channel is deployed to deliver/receive messages with the adapter itself running on a micro-controller (via a virtual serial/USB port in this case.)

The interface to the MQSvr job however needs to be at the register or m/c level, to allow existing QDOS device drivers - like the QL NET device - to be tweaked to talk to the MQSvr instead of physically pushing data down the wire.

There's quite of bit of (simple) data-structure processing carried-out by this interface layer which is proving very tedious to write directly in assembler - especially as I am contuning to tweak the data-structures as I go - having to re-write the assembler each time I recognise a change to the data-structures.

So, I'd like to take a step-back and explore whether a task-like program implementing this interface between the device driver and the MQSvr job could instead be written in C (C68) which, from what I've researched to-date, is more suited to developing stand-alone applications as a QDOS job.

Thoughts?


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

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby tofro » Tue Jul 03, 2018 6:04 pm

In Tebby-speak, a task is a piece of code which is called by an interrupt, the poll timer routines or the scheduler loop - Typically part of a device driver.

If that's what you want to write, it is perfectly possible to do that (I have been writing a device driver in C68 for a while now, and it works) - with a few caveats:
  • Supervisor stack is small and C is a stack-heavy language. It is best switching to a private supervisor stack when entering C routines
  • You need to write the entry points into a device driver in assembler - this can be very short routines that switch the stack and put the values of registers into C variables. Most of your code can then be in C
  • C (C68, at least) is not able to create position-independent code. There is an option for PIC in the compiler, but it doesn't seem to work for me (Compiler crashes with an internal error). Thus, C68 code is not ROMable. Lattice C (Metacomco or PDQL) can, but that is not even ANSI-C, so no fun to write.
  • C68 comes with specific startup code for RESPRable programs. Make sure you use that, the standard startup routines are not very suitable

If you want some example code, send me a PM, please. I have written a number of half-baked GST-Asm Macros to exchange data between C and Assembly code in a device driver that can show the principle.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Gold Card
Posts: 437
Joined: Sat Oct 25, 2014 9:53 am

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby martyn_hill » Tue Jul 03, 2018 10:12 pm

Hi Tobias!

Thank you - yes, task in the TT sense - although not as a result of an interrupt or schedluler loop call, but more a shared extension to an existing device driver or other non-job code.

In fact, I anticipate making the interface layer into a callable Thing - or atleast to allow the code entry points to be looked-up from a Thing Use call.

Very helpful guidance - I would very much appreciate reading an example, so will PM you.

M.


Martin_Head
Gold Card
Posts: 353
Joined: Tue Dec 17, 2013 1:17 pm

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby Martin_Head » Wed Jul 04, 2018 6:28 pm

martyn_hill wrote:So, I'd like to take a step-back and explore whether a task-like program implementing this interface between the device driver and the MQSvr job could instead be written in C (C68) which, from what I've researched to-date, is more suited to developing stand-alone applications as a QDOS job.

Thoughts?

If I understand from things you have said in the past. Is that your QLUB adapter connects to the PC via USB, but appears to Windows as a serial (COM) port. And you want the QL emulator to manage the processing of the data (in the background) that the QLUB adaptor sends out, or receives back. So that the (NET) device driver can access that data through a SER channel.

How about having a separate Windows program as your message server, that on one side is connected to the PC's COM port. And on the other side a TCP connection. With this side acting as a server.

On the QL emulator side you don't have to worry about low level drivers, or background jobs or tasks. You just have to open a TCP channel to the Windows program when you install your new Network driver. You could probably lift most the code you need from my IP Network driver.

Depending on how your QLUB adaptor works, you might be able in the Windows program to arrange the data so that my IP Network driver can talk to it directly. And you need to do nothing on the QL emulator side.


martyn_hill
Gold Card
Posts: 437
Joined: Sat Oct 25, 2014 9:53 am

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby martyn_hill » Wed Jul 04, 2018 11:42 pm

Hi Martin!

That's a interesting approach you outline and makes a lot of sense.

As you know, I have studied your IPNet code and concept and have given some consideration to how the QLUB adapter and your QLNet over IP might co-exist and bridge between the two 'worlds'. That's something I'll pick-up again in due course.

Remodelling the QLUB around a Windows-based IP to COM 'message' server poses one major bottleneck for me - namely, learning to program for the Windows platform rather than in QDOS/SMSQ!

For now, therefore, I shall proceed with the current, native QDOS/SMSQ approach and continue to think how to bridge to an IP network using your great work later :-)

M.


Martin_Head
Gold Card
Posts: 353
Joined: Tue Dec 17, 2013 1:17 pm

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby Martin_Head » Thu Jul 05, 2018 1:49 pm

martyn_hill wrote:Remodelling the QLUB around a Windows-based IP to COM 'message' server poses one major bottleneck for me - namely, learning to program for the Windows platform rather than in QDOS/SMSQ!

The message server could be a dedicated, stand alone copy of QPC2. As I did with my IPRouter program.

I don't know if you have speed issues, But could you write it in SBASIC, or compile it. You could use the IPBAsic routies to access the TCP ports.

I've thought about rewriting my IPRouter program as a Windows program, but my Windows programming is not up to it either.


martyn_hill
Gold Card
Posts: 437
Joined: Sat Oct 25, 2014 9:53 am

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby martyn_hill » Mon Jul 16, 2018 12:05 pm

Just to close the loop on this topic...

Tobias has kindly shared with me an example assembler macro that can form the basis of a 'bridge' between assembler and support C routines.

Like all the best solutions to a problem, it is simple and elegant (once you factor-in the couple of documented caveats) - thank you Tobias!

Martin - thanks again for our earlier suggestions; for the time being, I shall continue to pursue the native QDOS/SMSQE Net to USB bridge, rather than a direct integration with IPNet/Router - not because your idea is less superior, but rather to avoid the need to re-design my existing approach :-)


User avatar
NormanDunbar
Super Gold Card
Posts: 545
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby NormanDunbar » Mon Jul 16, 2018 1:36 pm

Martyn/Tobias,

any chance that you could share said method of bridging between assembly and C68 stuff as it could be the basis of an article in the next (exciting?) installment of the Assembly Language eComic thing that I occasionally produce.

Thanks.

Cheers,
Norm.


Why do they put lightning conductors on churches?
How come Tarzan never grew a beard?
If at first you don't succeed, don't take up skydiving!
If you think your job is pointless, remember, there's a man in Germany who fits indicators on BMWs.
martyn_hill
Gold Card
Posts: 437
Joined: Sat Oct 25, 2014 9:53 am

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby martyn_hill » Mon Jul 16, 2018 2:35 pm

Hi Norman

I must leave that request with Tobias as the author, but agree that, if he's willing to, it'd make a very interesting article to augment your already highly interesting periodicial :-)

M.


User avatar
NormanDunbar
Super Gold Card
Posts: 545
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Request for advice: programming a TASK (not a JOB) in C68...

Postby NormanDunbar » Mon Jul 16, 2018 5:25 pm

Thanks Martyn.


Why do they put lightning conductors on churches?
How come Tarzan never grew a beard?
If at first you don't succeed, don't take up skydiving!
If you think your job is pointless, remember, there's a man in Germany who fits indicators on BMWs.

Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 2 guests