Here's a great opportunity for all those "closet Mcoders" to go public and show up their prowess to the world, or to dust off those thinking caps if your old MCODE skills are rusty...

Problem Statement:

You just plugged a module (Clonix, Standard, or "virtual" on the CL / MLDL) and your trusty 41 starts acting up when you try to execute any function. You of course suspect the amateur programmer who put it together and didn't do enough testing (er, never happened to me!) but on second thought you wonder if there could be any XROM conflict in the current configuration.

The Challenge:

Your mision is to write a routine in MCODE to determine whether such a conflict really exists. There are three leves of implementation, in growing difficulty (and usefulness), as follows:-

Level 1: show a OK/BAD statement to assess the status

Level 2: if BAD, show the conflicting XROM number as well, then issue the BAD message.

Level 3: if BAD, sequentially show ALL conflicting XROM numbers if multiple offenders, ending with the BAD status message.

Restrictions:

None. The beauty of MCODE is that there are literally hundreds of ways to skin the cat. So it's ok to use calls to the OS routines, or even assume it's the CX OS. Not that this particular exercise requires lots of internals knowledge - save perhaps the display message routines.

This is not a contest, every part-taker is automatically a winner for participating. And sorry, no prizes - other than your sheer enjoyment while you crack the nut.

A jump start:

Here's a crude sketch in basic to help define the context and get you going. The idea is to check the first byte in pages 3 to F, checking for duplicates.

FOR J= 3 TO 14

W = FETCH(J)

FOR K=J+1 TO 15

V = FETCH (K)

IF V=W THEN -> BAD STUFF

NEXT K

NEXT J

A refinement would check for the first TWO bytes to discard "false positives" caused by 8k-ROMS with just one single FAT...

I'll post my version on Sunday in an article. I use it all the time on my CL - for obvious reasons - where I´m changing the configuration very frequently, and now that I have it I can´t live without it. It´s a very handy tool, I´m surprised nobody has done it before.

Until then, happy MCODING !!

ÁM.

Well, no solution here, just some comments. IMHO the problem of conflicting XROMs comes up with emulators or RAM-Box options. The original HP41 has only 4 ports and in those days ROMs did cost a lot. So before the acquisition of a module you planned it in every aspect.

Using the HP41 on "virtual" hardware you have the chance to solve conflicts by changing the XROM No. That is quck'n'dirty as your programs will do no good when accidentally using the original ROMs.

For my 'NutEm' (simulation of the NUT CPU using FORTRAN, only implementation yet on VM/ESA) I tested for ROM conflicts when defining which ROM to load on which page, so _before_ running the
emlator/simulator. Alas this does _not_ prevent running programs with the wrong module. There would help a test of the required ROM-ID/XROM correlation for a program. Or a documentation of the prerequisites.

Nevertheless is Angels XROM conflict checker a big help for RAM-Box, Clonix, or MLDL user.

Ciao.....Mike

Edited: 16 Mar 2012, 5:27 a.m.

The article is posted:

HP41 Configuration Check

obviously a strong candidate for the best-seller contribution of the month :-)

ÁM.

Edited: 18 Mar 2012, 3:29 a.m.

Thank you.

Ciao.....Mike