Page 3 of 3

Re: 74HCxx vs 74LSxx

Posted: Thu Sep 26, 2019 12:01 am
by Dave
The red CPU sockets Sinclair used in QLs are really terrible. They will not reliably support any sort of daughter card at all. More than half of the problems with intyernal memories that used that socket were because of the socket.

It would definitely be more reliable (and easier!) to put the CPU and co-pro on an expansion card with through connector...

Re: 74HCxx vs 74LSxx

Posted: Thu Sep 26, 2019 8:07 am
by tcat
Hi,

Studying now FPU instruction encoding, 16 bit field constists of
1111 - $F
bbb - Coprocessor ID
bbb- Instruction Type
bbbbbb - <ea>, CC, ... type dependant

I can see some interesting points here.

$Fxxx, F-Line instructions, emulating co-pro on the systems w/o FPU, or propagating directly to the real co-pro on systems with FPU in the socket.

There could be up to 8 co-pros in the system, does this imply some parallel computing, with the main processor being a sort of instruction dispatcher?

Never heard of such parallel machines though.

P.S. should really be changing subject to DIY Fpu Unit

Tomas

Re: 74HCxx vs 74LSxx

Posted: Thu Sep 26, 2019 10:59 am
by Pr0f
That;s just 8 FPU's !

They never did seem to extend this co processor functionality beyond memory manger and FPU - a graphics GPU co processor would have been a useful addition ;-)

Re: 74HCxx vs 74LSxx

Posted: Thu Sep 26, 2019 3:14 pm
by tcat
a graphics GPU co processor
ATARI had this idea with their BLITTER chip, offering raster operations and graphics primitives. These instructions are encoded as $Axxx, A-Line instructions so to speak. Providing emulation under TOS, and some 600-700% boost on systems with the chip fitted in the socket.

There are no $Axxx machine instructions, unlike $Fxxx that exist on MC68020 and higher, or emulated on earlier models.

Tomas

Re: 74HCxx vs 74LSxx

Posted: Fri Sep 27, 2019 3:28 pm
by Pr0f
I believe some QL emulators use the A-line instructions as a form of trap to replace I/O routines in QDOS with code that looks after the host OS functions

Re: 74HCxx vs 74LSxx

Posted: Sat Sep 28, 2019 9:22 am
by Silvester
Dave wrote:The red CPU sockets Sinclair used in QLs are really terrible. They will not reliably support any sort of daughter card at all. More than half of the problems with intyernal memories that used that socket were because of the socket.

It would definitely be more reliable (and easier!) to put the CPU and co-pro on an expansion card with through connector...
Agreed! :evil:

I once had one disintegrate as I tried to prize out the 68008. After tediously removing the remaining pins I fitted turned pin strips.

Re: DIY Fpu Unit for STFM

Posted: Mon Sep 30, 2019 8:23 am
by tcat
Hi,

Cannot help thinking more about $Fxxx and $Axxx.

The emulation can be achieved through exception trap vectors. As on plain MC68000/8 $Fxxx and $Axxx machine code instructions simply do not exist. So the attempt excecuting them leads to an exception that can be caught by a handler.

The respective exception handler then just inspects parameters relative to PC, and runs emulated code for unsupported instructions.

I believe the idea was to provide binary code upward compatibility with higher processors and future h/w.

With FPU and Blitter fitted, the exception handler diverts execution to the add on h/w. While on MC680020 and higher models $Fxxx are already part of the instruction set.

And $Axxx seems to have never become a part of Motorola family, i.e. future GPU, correct? I wonder if there were any plans for it?

Tomas

Re: DIY Fpu Unit for STFM

Posted: Tue Oct 01, 2019 8:20 am
by Nasta
tcat wrote:Hi,

Cannot help thinking more about $Fxxx and $Axxx.

The emulation can be achieved through exception trap vectors. As on plain MC68000/8 $Fxxx and $Axxx machine code instructions simply do not exist. So the attempt excecuting them leads to an exception that can be caught by a handler.

The respective exception handler then just inspects parameters relative to PC, and runs emulated code for unsupported instructions.

I believe the idea was to provide binary code upward compatibility with higher processors and future h/w.

With FPU and Blitter fitted, the exception handler diverts execution to the add on h/w. While on MC680020 and higher models $Fxxx are already part of the instruction set.

And $Axxx seems to have never become a part of Motorola family, i.e. future GPU, correct? I wonder if there were any plans for it?

Tomas
Tomas,
I think your software may not recognize a FPU fitted because it needs a software FPU handler to do the CPU-FPU communication that the higher 68k members (020+ but NOT 040 and 060, they only do internal co-processors) already implement. This handler is hardware specific as it has to know at which address the FPU is decoded.
Also, yes, there were some rather obscure systems that used multiple FPUs to get high FPU performance, and these had mostly to do with signal processing, before DSPs became more popular - hence the format's ability to use up to 8 co-processors.
Finally, as far as i remember (and I remember I read it in some Motorola literature) the E-line exception was not to be used by Motorola and instead was intended for user 'instruction expansion'. All co-processors in the 68k family always use F-line. Please note that you can't interface older co-processors to 68040 and 060 unless it's as a regular peripheral, like in your 68000 case. The co-processor interface has been replaced by direct F-line instruction execution for on-board FPU and MMU - and NOT all of the old instructions are implemented either, especially on the 060.

Re: DIY Fpu Unit for STFM

Posted: Tue Oct 01, 2019 12:02 pm
by tcat
Hi Nasta,

Thank you for taking your interest, it's just fun and toy albeit for `non-QL' platform.
Currently working on FPU tests with the aim to get this completed.

[a] Inline assembly macros - based on Motorola AN947
F-line emulation trap - ditto
[c] FPU Library linkable against "math.h"

software FPU handler to do the CPU-FPU communication

Yes, the idea of CPU-FPU communication may be like this, I have learnt.

Code: Select all

FMOVE    equ       $00       ;move
FINT     equ       $01       ;interger part
FSINH    equ       $02       ;sinh
FSQRT    equ       $04       ;square root
FLOGNP1  equ       $06       ;logn (1+x)
FETOXM1  equ       $08       ;[(e**x)-1)]
FTANH    equ       $09       ;tanh
FATAN    equ       $0a       ;arctan
FASIN    equ       $0c       ;arcsin
FATANH   equ       $0d       ;arctanh
FSIN     equ       $0e       ;sine
.... all dyadic/monadic instructions may follow pls see AN947

mc68881  equ       $fffa40   ;mc68881 base address
resp     equ       $00       ;response register
comm     equ       $0a       ;command register
oper     equ       $10       ;operand register

        .macro  MEMREGD         ; double precesion memory to reg
        move.w #$5400+(\3<<7)+\1,mc68881+comm  ;mem. to reg. operation
.nulca\~: cmpi #$8900,mc68881+resp  ;read response register
         beq.s .nulca\~         ;reread until evaluate <ea> and transfer
                                ;data
         move.l \2,mc68881+oper ;high order long word
         move.l 4\2,mc68881+oper  ;low order long word
.nulrel\~: tst.b mc68881+resp   ;is response null release?
         bmi.s .nulrel\~
        .endm

        .macro  REGMEMD         ; double precesion reg to memory
         move.w #$7400+(\2<<7)+\1,mc68881+comm  ;reg. to mem. operation
.nulca\~: cmpi #$8900,mc68881+resp  ;read response register
         beq.s .nulca\~         ;reread until evaluate <ea> and transfer
                                ;data
         move.l mc68881+oper,\3 ;high order long word
         move.l mc68881+oper,4\3  ;low order long word
.nulrel\~: tst.b mc68881+resp   ;is response null release?
         bmi.s .nulrel\~        ;branch until null release
         .endm
To call e.g. SIN(x) double precision

Code: Select all

        lea     result,a0       ; result
        lea     arg,a1          ; argument
        MEMREGD FMOVE (A1),FP0
        REGREG  FSIN,FP0
        REGMEMD FMOVE FP0,(A0)