silver@cup.portal.com (Jim B Howard) (04/24/89)
I have been having trouble with the following asm code that is
driving me NUTS. The code works perfectly, as long as it is
not in CHIP mem. If its in any form of FAST mem, it functions.
But if its in CHIP mem, it crashes and burns. I cant think of any
reason that this could happen, so maybe some of you could come
up with some reasons. I've never had this happen in any of my
programs before.. When I step through the program with a debugger,
it crashes when it calls the _LVOClearScreen routine, but
_only_ when its in CHIP mem.
WHY ???
***********************************************************************
start
jsr _getintbase
jsr _getgfxbase
jsr _openscreen
wait
btst #6,$bfe001
bne wait
rts
screendata:
dc.w 0,0 ;screen XY origin relative to View
dc.w 320,200 ;screen width and height
dc.w 2 ;screen depth (number of bitplanes)
dc.b 0,1 ;detail and block pens
dc.w 0 ;display modes for this screen
dc.w $f ;screen type
dc.l 0 ;pointer to default screen font
dc.l 0 ;screen title
dc.l 0 ;first in list of custom screen gadgets
dc.l 0 ;pointer to custom BitMap structure
_openscreen
lea screendata(pc),a0
move.l intbase,a6
jsr $ffffff3a(a6) ;openscreen
move.l d0,screen
add.l #$54,d0
move.l d0,screenrast
move.l screenrast,a1
move.l gfxbase,a6
jsr -$30(a6) ;clearscreen
rts
_getintbase
movea.l 4,a6
lea intname(pc),a1
moveq #0,d0
jsr -408(a6)
move.l d0,intbase
rts
_getgfxbase
movea.l 4,a6
lea gfxname(pc),a1
moveq #0,d0
jsr -408(a6)
move.l d0,gfxbase
rts
intbase
ds.l 1
intname
dc.b 'intuition.library',0
cnop 0,2
gfxbase
ds.l 1
gfxname
dc.b 'graphics.library',0
cnop 0,2
screen
dc.l 0
screenrast
dc.l 0ugkamins@sunybcs.uucp (John Kaminski) (04/26/89)
In article <17545@cup.portal.com> silver@cup.portal.com (Jim B Howard) writes:
=>
=> I have been having trouble with the following asm code that is
=>driving me NUTS. The code works perfectly, as long as it is
=>not in CHIP mem. If its in any form of FAST mem, it functions.
.
.
.
=> btst #6,$bfe001
As I undestand it, ANY of the 680x0 instructions that expect to be in full
control are in serious trouble, and if I recall (from long ago) correctly,
"btst" is one such instruction. Very simply, the 680x0 is NOT guaranteed
RAM access at any time. Therefore, when working in CHIP memory, all sorts
of DMA can be performed which the 680x0 did not expect. Also, is it really
necessary to be waiting in such a tight loop? Cannot the process sleep
while waiting for whatever?
---
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
In the jungle
The silicon jungle
The process sleeps tonightgay@elde.epfl.ch (David Gay) (04/26/89)
>As I undestand it, ANY of the 680x0 instructions that expect to be in full >control are in serious trouble, and if I recall (from long ago) correctly, >"btst" is one such instruction. No. The only instruction that causes trouble is TAS. David Gay GAY@ELDE.EPFL.CH
mph@behemoth.phx.mcd.mot.com (Mark Huth) (05/05/89)
In article <5482@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: > >As I undestand it, ANY of the 680x0 instructions that expect to be in full >control are in serious trouble, and if I recall (from long ago) correctly, >"btst" is one such instruction. Very simply, the 680x0 is NOT guaranteed >RAM access at any time. Therefore, when working in CHIP memory, all sorts >of DMA can be performed which the 680x0 did not expect. Also, is it really >necessary to be waiting in such a tight loop? Cannot the process sleep >while waiting for whatever? On the 68000/68010/68012/68HC000 only the TAS instruction uses the Read-Modify-Write cycle. They do this cycle by holding ~AS asserted for both memory cycles. On the 68020/68030/68040? in addition to TAS, there are CAS and CAS2 instructions which do read-modify-write operations. However, they do it by holding a signal called ~RMC asserted and toggling ~AS normally. Additionally, the 68851 PMMU chip can perform RMCs during certain page descriptor updates. An examination of the 2620 schematic makes me reasonably sure that RMCs to the onboard memory cause no problems. However, not having the PAL equations, I cannot tell for sure what happens off board. I'll examine the other schematics tonight to figure out what really happens with the chip memory when RMCs are performed to that address space. Mark Huth