Scor­pio News

Yes – let’s disassemble clones.

Dear Sir,

On the general point of whether to move the mag. to support the IBM PC world, as Dave Hunt suggests, I would agree with him, though I should state my bias as an owner of both close and Gemini/​Nascom hybrid.

The expertise of the early group of enthusiasts who built their own machines and managed to squeeze programs into 1k of memory is still valid, and perhaps more so in the clone world where information is sadly lacking – no circuit diagrams or port maps in the Taiwanese PC world (or even with the Greenock real ones), or very expensive – the technical reference manual cost a staggering £70 or thereabouts. The skill of the average MultiBoard enthusiast, most being hardware-software hybrids, should, put together, rapidly disassemble the hidden store of information on these machines.

Finally, beloved 8 bit CP/M machines are long in the tooth, and through superior 16 bit machines when dealing with text applications, we will have to admit they are coming to the end of their golden age.

Doug Taylor, London.

Ed. – some “compatibles” DO come with circuit diagrams, see the review in the last Scorpio News, although I understand that most do not. As to your beloved machine coming to the end of its age, perhaps the new product information in this issue will change your mind?

A few points

Dear Sir,

I thought I should write to inform you (and the readership) of a few points which have come to my notice, but before I start moaning I must say how mech I enjoy reading Scorpio News. It must be just about the only computer / electronics related magazine which dows not send me barmy with technical errors.

I have had a rather funny week since receiving the Scorpio Systems SVC-03 disk that I ordered. During the week I found bugs in MLINKS, PCB and finally in my newly aquired copy of HiSoft C, and all this with my untrusty old GM809 FDC board giving up on me. No doubt you will be glad to know that the MLINKS bug is very easily fixed. It relates to the PCI and GPS commands which, on my copy at least, write and read garbage. This is because they assume the default CP/M DMA at 80h without checking that MBASIC has not moved it. MBASIC, of course, has moved it. The solution is quite simple, just use the BDOS function “Set DMA address” (cods 26). This cam be done at the end of the disk commons routines thus only needing to be written once.

Find “discom:” , move dons to “endlin:” and find the “ret” instruction at the end (3 lines down) and insert:

This occupies extra space, but the space can be recovered by removing two unnecessary BDOS calls in PSI. Shortly after creating the new with:

you will find: