Converting from FLOWcode to C code

[mytekcontrols]

I have attached a FLOWcode V4.5 macro I call POKEYcntr that is called by a Timer2 interrupt at a 31,250Hz rate based on a PIC16F1847 running at 32Mhz. It's a macro that creates a shadow counter register which is synced to a real 6-bit key scan counter. The routine looks at the lowest and highest bit of the real counter to use as the clock and the reset for the shadow counter. It all works, except I think it's right on the edge of not working, perhaps taking too long to process and sometimes missing something. Reason I say that is if I go into my program which is quite extensive (only 13 words free of program memory), and I manipulate anything (add/subtract other content) and then recompile, I will experience glitches in the shadow counter vs. the real counter.

I've tried running the Timer2 interrupt at a higher rate by changing the roll-over value in the Timer2 properties from 256 to either 128 or 64 which doesn't appear to improve reliability, in fact it can actually hurt things in this regard.

So I was thinking that maybe what might work better is to code this macro in C and use a 'C Box' to contain that within the macro. Problem is that I don't know C, so it would be a great help if someone could give me some example code to work with.

Thanks

[mytekcontrols]

I figured out how to do a read of a single port bit in a C Code Block, saving that value into a FlowCode variable. Not sure if what I did is the most efficient way to code it, but it works! Link to screenshot of POKEYcntr2.

Code: Select all

if (test_bit(porta, 0))
{
//RA0 Set
FCV_PCLK = 1;
}
else
{
//RA0 Clear
FCV_PCLK = 0;
}

I did a C Code Block of this for both bits of interest (RA0 and RA5), replacing the original FlowCode Port Input icons.

This alone has fixed the erratic behaviour of the previous macro, and also given me back some more free space in program memory.

[mnf]

Hi Michael,

Slightly more efficient would be:

Code: Select all

FCV_PCLKA = test_bit(porta, 0)

..

Are you running out of RAM? - Is memory tight? Can you post some more of the program (or PM if sensitive) / I (and I suspect many others) can't open the FC - later versions aren't backward compatible perhaps Benj or Leigh could do some conversion...

The image of the interrupt handler shows some things that could be changed (or could be problems) for example:
Real counter high bit (if ptmp) - then tests HB (how is this set - and it is tested in both branches - so maybe should be moved before the if ptmp?)

Martin

[mytekcontrols]

Hi Martin,

I tried your C code, and although it compiled just fine (after I added a semi-colon at the end), when the application was run it was once again very erratic.

What was the erratic nature I was seeing?

Dropped keys and/or wrong character would be seen on screen.

A little background

The application was first created back in 2015 to allow a PS/2 keyboard to be used on an Atari 8-bit computer. Hence the reason for the older FlowCode version in use. In the early versions, the 6-bit key scan counter of the Pokey chip was being compared to a decoded key byte, and when there was a match, the key response line on the Pokey chip would be momentarily toggled from High to Low, thus pretending to be the scanned matrix stock keyboard.

Recently I decided it would be cool to add an Arrow Key to Joystick feature, but to do so required having some spare I/O lines from the PIC, which there were none. So to free up 4 I/O lines, I created the shadow counter in software, and clocked it as well as synced it to Pokey's hardware counter using only 2 bits of that hardware counter (bit0=shadow counter clock, bit5=shadow counter sync). To allow better granularity, the shadow counter is reset at two conditions. One being when the 6-bit hardware counter overflows (bit5 transitions from High to Low), and the other when we are at the middle of the count (bit5 transitions from Low to High). So this means the shadow has to be stable and in sync for only 32 counts of the total of 64.

As for the HB flag not being initially set. That's only in the very beginning (following first power-up). Once things get rolling, then it gets constant update. Since this macro is executed each time Timer2 overflows, it's only briefly in limbo.

You asked if I'm constrained for program memory. The answer is yes. At this point I only have about 40 words left.

The interesting thing was before I implemented the C code blocks to retrieve the bit states, any change in my FlowCode could and often would break reliability. Now that I have the C code blocks in place I can freely change things in the program without issues. Perhaps using the FlowCode equivalent to checking a port bit didn't like being run within a macro that was being called by an interrupt. Or the code produced by compilation was being skewed depending upon how much program space was in use. I really don't know the answer to that. But like I said the present implementation as shown in my last post is working flawlessly.

[mytekcontrols]

Streamlined the last part of the macro. Now only uses one decision block to determine if the clock bit (Pclk) is low before proceeding with any changes related to the high bit (Pbit5 - changed name from Ptmp).

[mnf]

Hi Michael,

Sounds an interesting project - I'll have a look at the 'pokey' docs of I can find any? (Wikipedia has some info)

It might be a timing issue - or a memory issue. Program size shouldn't affect things (if it fits in ROM) but variable space (RAM) might if you use a lot of globals or loops (FC uses globals for these unless you use a variable - and this might be different in early versions?)

As another option - how about a PIC with more pins

Martin

[mytekcontrols]

Yeah a PIC with more pins certainly would have made things easy. Except this is an established design that is already built into many other projects, all based on the PIC16F1847 chip. Take a look HERE to see what I'm talking about.

The problems I ran into could definitely be a timing issue, and/or RAM usage (I have a bunch of variables in play). But for the time being, it appears to be well behaved after my last change.

Here's a good online data sheet for the Atari Pokey chip: LINK

[mnf]

Look like some interesting kit...

Seen details of PokeyOne - nickname of a bedsit I stayed in for a while...

Are you up and running now - or is it still temperamental?

Martin

[mytekcontrols]

Look like some interesting kit...

Seen details of PokeyOne - nickname of a bedsit I stayed in for a while...

Yeah the journey began back in mid 2015, when I kind of got sucked back into the retro 8-bit computing scene. At first it was just an opportunity to create a re-imagined version of something I had built and sold back in 1990 called TransKey. Back in that time period PICs didn't even exist, and micro-contollers were in their infancy. So I essentially built a single board 6504 computer to translate an AT keyboard into something that would mimic an 8x8 matrixed keyboard. Years later I stumbled upon the PIC at an embedded systems conference, and began working with it in some of my own designs, always thinking that if I had only had one of these in 1990.

Pokey's got used in a multitude of systems starting in the 80's, game systems, computers, and arcade machines to name a few. It was a great chip back in the day, handling the keyboard, paddle controllers, sound, and serial I/O. But due to all the sources drying up, buying a Pokey will set you back at least $40 now days, thus making an FPGA replacement like the PokeyOne a more viable proposition.

Are you up and running now - or is it still temperamental?

Yep that last iteration appears to be rock solid.