Morning all,
I'm doing a bit more work on the next exciting episode of QL Today's
LibGen utility. I have spotted a huge pair of bugs in my code, viz:
li_libfile equ $03
...
li_unav move.l #$11111111,ws_litem+li_libfile(a1)
bra.s li_rdrw
...
li_avail move.l #$01011101,ws_litem+li_libfile(a1)
li_rdrw moveq #-1,d3
jmp wm_ldraw(a2)
The idea was to set 4 consecutive loose item status bytes to unavailable
(#wsi_mkun) in the first case, and to set three of them to available
(#wsi_mkav) and one to unavailable (#wsi_mkun) in the second case.
The code above is a huge problem because li_libfile is odd, A1 is even
as is ws_litem at $40. I would expect an address exception at the very
least.
Running the code under QMON2 shows that I'm attempting to store a long
word at $43(a1) where a1 is $4ABBA6. That works out at $4ABBE9 which is
most definitely odd.
In QPC, version 3.33, the above works without any exceptions. PRINT
PROCESSOR gives 20, I must assume that either a 68020 doesn't barf at a
long word access to an odd address or something is not working correctly
any more!
I've checked and rechecked my paper and pdf copies of the Motorola
processor manual, and there is no mention that you can do a long move to
an odd address.
I'm not running any "monitor" code that would intercept the address
exceptions and quietly swallow it.
I have stepped through the code for both, and it works, the MOVE.L is
carried out, after executing the code at li_avail, I can see the
following results at $43(a1) in QMON2:
QMON> d $43(a1) 4
4ABBE9 0101 0101 004E FF6F .....NV.
Is it any wonder I'm confused?
What am I missing?
Cheers,
Norm.
--
Norman Dunbar
Dunbar IT Consultants Ltd
Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL
Company Number: 05132767
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
