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)

Bus error handling problem

News,announcements,programming,fixes,game patches & discussions.
User avatar
exxos
Site Admin
Site Admin
Posts: 28601
Joined: 16 Aug 2017 23:19
Location: UK

Re: Bus error handling problem

Post by exxos »

sporniket wrote: 19 May 2022 17:29 It looks like accessing a1+2 does trigger the error handler then ?
Would seem so.
User avatar
mrbombermillzy
Moderator
Moderator
Posts: 2347
Joined: 03 Jun 2018 19:37

Re: Bus error handling problem

Post by mrbombermillzy »

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.
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.

It's possible that STOS only uses 16 bit words for its data handling...I wouldn't know.
User avatar
exxos
Site Admin
Site Admin
Posts: 28601
Joined: 16 Aug 2017 23:19
Location: UK

Re: Bus error handling problem

Post by exxos »

@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 :)
User avatar
mrbombermillzy
Moderator
Moderator
Posts: 2347
Joined: 03 Jun 2018 19:37

Re: Bus error handling problem

Post by mrbombermillzy »

exxos wrote: 19 May 2022 20:54 it's all fine now :)
:thumbup: Glad you got it sorted.

Return to “SOFTWARE PROGRAMMING & DISCUSSION”

Who is online

Users browsing this forum: ClaudeBot and 0 guests