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...
DIY Fpu Unit for STFM
Re: 74HCxx vs 74LSxx
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
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
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
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
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.a graphics GPU co processor
There are no $Axxx machine instructions, unlike $Fxxx that exist on MC68020 and higher, or emulated on earlier models.
Tomas
Re: 74HCxx vs 74LSxx
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
Agreed!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...
I once had one disintegrate as I tried to prize out the 68008. After tediously removing the remaining pins I fitted turned pin strips.
David
Re: DIY Fpu Unit for STFM
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
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
Tomas,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
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
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"
Yes, the idea of CPU-FPU communication may be like this, I have learnt.
To call e.g. SIN(x) double precision
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
Code: Select all
lea result,a0 ; result
lea arg,a1 ; argument
MEMREGD FMOVE (A1),FP0
REGREG FSIN,FP0
REGMEMD FMOVE FP0,(A0)