Skip to content

Whoah That’s Slow! – Just How Bad Was My Blinker

August 17, 2018

A while ago I perpetrated a LED blinker under MVS. The MVS program was writing to an emulated printer on unit 30F. Hercules was piping the output to a program called leder.c that would write the passed data to a raspberry pi LED via the file system. I figured it would be too slow for practical use but i didn’t really know. I tried it today and found that it took 10+ seconds to cycle the LED 1000 times. To avoid a startup effect i tried it 2000 times and it took 20 seconds. I got the same sort of timing when i directed the output to a real file without the pipe and even when i sent it to /dev/null. If I change the MVS JCL to DD DUMMY(the MVS equivalent of /dev/null) the time goes to near zero which is more what i would expect. It’s actually pretty stunningly slow. I’m not sure whether the time is being spent emulating 370 instructions or just running hercules I/O on the Pi.

It’s not really straightforward to access the GPIO’s from C code on the Pi. One option is wiringPi which implements an arduino type environment.

I’m able to build hercules from source although it’s not the version used by the TK4- turnkey MVS setup. I can run simple code in it from the console but i haven’t tried to bring up MVS.

As an experiment i’ve goobered the SVC instruction to blink my LED using wiringPi. I’m hacking at hyperion/general2.c changing code around line 1335 as below:

/*-------------------------------------------------------------------*/
/* 0A   SVC   - Supervisor Call                                 [RR] */
/*-------------------------------------------------------------------*/
DEF_INST(supervisor_call)
{
BYTE    i;                              /* Instruction byte 1        */
PSA    *psa;                            /* -> prefixed storage area  */
RADR    px;                             /* prefix                    */
int     rc;                             /* Return code               */

    RR_SVC(inst, regs, i);
//following 18 lines per wjr 18-07-28
#if 1
//printf("bingo! i=%x, regs->GR_L(0)=%x\n",i,regs->GR_L(0));
/* if we have an SVC 255 and R0 is set to a magic number, then
we have ignition */
if ((i == 255) && (regs->GR_L(0) == 0x00000042))
	{
	//printf("bango! i=%x, regs->GR_L(0)=%x\n",i,regs->GR_L(0));
	if (~wiringPiIsSetup){
 		printf("Setup() sez %d\n",wiringPiSetup ());
                wiringPiIsSetup=1;
	}
  	pinMode (1, OUTPUT) ;         // aka BCM_GPIO pin 18
	digitalWrite (1, 1) ;       // On
	delay(5000);
    	digitalWrite (1, 0) ;       // Off
    	PERFORM_SERIALIZATION (regs);
    	PERFORM_CHKPT_SYNC (regs);

    	RETURN_INTCHECK(regs);
	}
#endif

To get that to compile and link i had to manually edit build/cmakecache.txt changing line 83 to CMAKE_EXE_LINKER_FLAGS:STRING=”-lwiringPi” Then in the build directory the usual cmake –build . did the rest. Changing the cache caused a full rebuild but i’ve made a couple of simple changes since and they just rebuilt the affected modules.

This is pretty workable although it means goobering code that would be used by mainline MVS and it takes it out of the I/O realm altogether. It’s not completely clear to me whether my one-time initialization test is working or not but it doesn’t blow up, so that’s something.

I guess to continue this path I would need a little protocol and a “safe” svc – also a way of only compiling this for the raspberry Pi architecture.

I guess pinMode, digitalWrite, digitalRead would be a start.

From → Olduino/370

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: