Would seem so.sporniket wrote: 19 May 2022 17:29 It looks like accessing a1+2 does trigger the error handler then ?
REMINDER - Stay logged in for at least 2 hours a week to get whitelisted.
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Bus error handling problem
-
exxos
- Site Admin

- Posts: 28601
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Bus error handling problem
-
mrbombermillzy
- Moderator

- Posts: 2347
- Joined: 03 Jun 2018 19:37
Re: Bus error handling problem
From that wording, I would hazard a guess that by using a long, your assembly variable space is stepping into an odd boundary (if compiling on a 68000, which I guess you are?) causing an odd address/bus error. This would require the STOS variables to be words/evenly aligned to avoid this.exxos wrote: 19 May 2022 16:33 There is still something odd going on :roll:
I can peek a byte or word in STOS and I get a number back, but a LONG I get BERR.
It's possible that STOS only uses 16 bit words for its data handling...I wouldn't know.
-
exxos
- Site Admin

- Posts: 28601
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Bus error handling problem
@mrbombermillzy I was only peeking byte or word in STOS. The assembly code was checking for a long. Indeed I confirmed that long failed in STOS as well. Flashyclock registers are 16bit so it wouldn't respond to long access. So now the asm code checks for words, it's all fine now :)
-
mrbombermillzy
- Moderator

- Posts: 2347
- Joined: 03 Jun 2018 19:37
Re: Bus error handling problem
:thumbup: Glad you got it sorted.
Who is online
Users browsing this forum: ClaudeBot and 0 guests