Over the past weeks I’ve been working on adding sensors and other peripherals to MINC. One of those, an 8 channel D/A converter, needed another MNCAA module – since each of those deals with ‘only’ 4 channels. So instead of adding just one, I decided to make the number of MNCAA modules configurable – like so many things in PDP2011 are. And then, just for fun, I did the same for MNCDO and MNCDI too.
And while testing that last one, I found some peculiarities. First of all and easiest to fix the vector address – already a while ago, I noticed that the VMNB test program complained about the interrupts coming from an unexpected vector, but I decided that that was probably a weird error in the test. But now, with 4 modules, it complained about all four modules – and worse, the vector address of the 4th module clashed with the vector for the RK controller. Not impossible of course, since ‘real’ MINC systems would not likely have an RK. But still.
The first thing that came to mind of course was to skip the RK vector – and yes, that worked. But also, I kept wondering where I had found that MNCDI should use 130 for the first module – and while looking through all documentation, it seems that the only place where this is mentioned is in the XMNB listing. Maybe things were changed some time in between those two tests were written? who knows…
So, after some thought I decided to change the vector addresses to what the test program said they should be – occupying all vectors 120 through 154, for four modules. Not clashing with RK at 160, but instead with DEUNA at 120. But DEUNA is a lot less likely even than RK in a MINC system. Unsurprisingly, the VMNB test now ran cleanly, and also everything else I could think of. But instead of adding more sensors, I thought to take some time and just play with the MINC.
Then, while playing around with the MNCDI related BASIC statements, I noticed something else weird. I was trying a test program with the DIN_EVENT statement and hoping to use that to signal a change on the input lines on the module. That sort-of worked, but not exactly how I hoped it would. And the manual was really confusing me too – Book 6 – MINC Lab Module Programming. Where it deals with the DIN routine, on page 126 where it describes the trigger value, it gives a list which appears to be in order of priority, and on the top and thus the highest priority is when the data length is 1 – and two paragraphs lower, it deals with DIN_EVENT. So, by implication, if you want to use DIN_EVENT and DIN to monitor for changes on the lines, you can only do that by setting up a multiple value read? But… how would you then monitor for a single value change?
Well, I’m not sure if I have the definitive answer or if there are other – easier – ones. But from the ‘Animal Tracking’ example in the same book on page 67, it follows that for DIN/DIN_EVENT, you would set up a continuous reading loop for DIN. And then suddenly the minimum data length of 2 makes sense. And besides that, when I copied the relevant statements from the example and tried it out, it actually sort of worked. Except it didn’t notice all changes.
That prompted me to take a long look at the logic in the module, and especially the statement that should detect changes in the input and match that to the lines enabled via DIN_EVENT. Except that that didn’t really detect changes at all, it just detected bits that were set. Easy enough to fix – and the BASIC program now works as I think it should. And VMNB also runs without complaining – but then again, it also did with the previous logic.
For completeness, here’s the program I’m running to test the MNCDI with:
10 DIM S%(3)
20 DIN_EVENT
30 DIN('continuous',S%(),2)
40 WAIT_FOR_DATA(S%(),Q)
50 SCAN_BIT(R,S%(Q))
60 PRINT R;S%(Q)
70 GO TO 40
And sure enough, on every change of a line, the statement on line 60 prints out. Not necessarily the last change though – SCAN_BIT only shows the least significant bit in the word (and also it resets that bit). So things go slightly wrong if multiple bits are set at the same time. That’s why I added the ‘S%(Q)’ to the printout, to show if bits were left after SCAN_BIT. Maybe this is also why in the description of the example, the book says ‘For the sake of simplicity … the sensors resolve the problems arising when the animal straddles zone boundaries.’
I’ll put up a new version in the coming weeks – after I’ve done everything on the list of sensors and peripherals to add. Probably a week or so, depending on the weather!