Lee is reading adverts from old magazines and noticed that some games are advertised as Model A compatible. He would like to reflect this in the website, along with games that are incompatible with a model B.

Taking this a step further I think that we could do the following:

Add 3 columns to the game table for compatability with the Model A, Model B, and Master.

Lee will then change the Model B compatibility to N for the few games that only run on a Master, populate Model A compatibility as he finds them, and probably leave the Master field alone (I think he tests on a Model B).

There is a hardware comments field for games which need or benefit from sideways RAM, or need 1770 DFS, etc (It is a free form field) e.g. Astroblaster, so we don't need to drill down anyfurther.

Does anyone have any thoughts on this? Some half formed thoughts are that some games "kind of" work on a Master but with graphics corruption etc, some don't work at all and some work fine, so maybe this should be reflected. Does anyone have a list of Master compatibility? I don't think Lee does.

What would you suggest here joachim?
If this feature gets implemented, my first task will be to add all the Model 'A' games that I find in the old magazines, then highlight the few games we have that don't work on a Model 'B', or REQUIRE a Master.
I would be hoping for help with the 'Master compatible' field...

(My other job at the moment is compiling lists of every game that appeared in the magazines such as Micro User, Electron User, Acorn User, Beebug etc. And cross referencing this with the games we have on the site.
I have recently sent Mick every missing game from Micro User and Acorn Computing... so we have plenty to be getting on with... )

pau1ie wrote:I suspect I have slightly disappointed Sweh by being a database developer.

Not at all; database dev's typically build multiple columns because it allows them to create efficient select statements. It's a consequence of the technology they use. Old school devs use bitmaps for space efficiency (an 8bit integer can store 8 booleans).

If you're a C programmer then "if (field && MASK_DATA1) {...}" is a common paradigm. If you're a SQL programmer than "SELECT ... WHERE data1 is TRUE" is common.

Different technologies, different solutions.

But in both cases, multiple flags is how I would have solved the problem