You will not be able to post if you are still using Microsoft email addresses such as Hotmail etc
See here for more information viewtopic.php?f=20&t=7296
BOOKMARK THIS PAGE !
https://www.exxosforum.co.uk:8085/IP_CHECK/
You can unban yourself if needed. It also sends me reports to investigate the ban.
DO NOT USE MOBILE / CGNAT DEVICES WHERE THE IP CHANGES CONSTANTLY!
At this time, it is unfortunately not possible to whitelist users when your IP changes constantly.
You may inadvertently get banned because a previous attack may have used the IP you are now on.
So I suggest people only use fixed IP address devices until I can think of a solution for this problem!

CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: 29 Jan 2019 17:59 Damn. We will have to investigate that. I hope it's not an EmuTOS bug. However, I have never see such thing before.
Tested again just..

First time..
1.jpg

2nd and 3rd time I got this one...
2.jpg

Then if I press spacebar...
3.jpg

I've been running GB6 on it past few hours and not crashed once. Even did some tests RAM,ROM,floppy,timing etc in the diag-cart and all tests pass. So no errors reading ROM or RAM.

Is there anyone any good with steem debugger who could somehow set a breakpoint on the program counter value in my image ? If we knew what code was running around that point, it may give some clues...

EDIT:

I did try SELTOS to run TOS from RAM, tried 104 & 206, but just get a row of flickering bombs on screen :shrug:
You do not have the required permissions to view the files attached to this post.
User avatar
BlankVector
Posts: 93
Joined: 15 Sep 2017 22:51

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by BlankVector »

Thanks for your tests, Exxos!
Every time, pc=very low value, which seems abnormal to me. I still suspect a jump to a bad address.
Also, there are strange values in A0: last picture contains the soundchip address, previous one MFP... stuff related to hardware, every time.
I still have big suspicion about validity of Bus Error on your hardware. Atari TOS doesn't use much Bus Error. But EmuTOS uses it a lot to detect presence of extra hardware. If Bus Error handling was bad on your hardware, that could very likely explain what you see.

Anyway, let's stop blind assumptions, and do concrete tests. I attach a special EMUTOSUK.PRG with some debug output to the screen. It should display the progression of BIOS initialization, then show the EmuTOS welcome screen.
Please show us what happens with this one.
You do not have the required permissions to view the files attached to this post.
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Display a color pixel in assembly language on Atari ST.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: 30 Jan 2019 21:45 Anyway, let's stop blind assumptions, and do concrete tests. I attach a special EMUTOSUK.PRG with some debug output to the screen. It should display the progression of BIOS initialization, then show the EmuTOS welcome screen.
Please show us what happens with this one.
OK thanks!

I got these..

1.jpg

2.jpg

It mentions ACIA that time... My ACIA code isn't "normal" as I speed up and overclock the ACIA.. But I did try slowing all that down in many tests yesterday even.. It seems to come up that error the most...

BERR I am still suspect.. Ijor thinks its not possible for error for BERR in my setup... Though Things to seem to point in that direction..
You do not have the required permissions to view the files attached to this post.
User avatar
BlankVector
Posts: 93
Joined: 15 Sep 2017 22:51

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by BlankVector »

OK.
NB: You don't need to go past the first panic(), because it is not supposed to crash at all. I'm still very puszzled that it can continue the boot after pressing a key at the panic screen... Very strange.
So it crashes during snd_init(), which writes initialization data to the YM2149. Mainly, it initializes the PSG ports A and B for I/O. Interrupts are still disabled at that time, so theoretically nothing could happen externally.

Anyway. I post here a very different test. It is just a standard EmuTOS (without debug traces), but *without* any Bus Error checks. Let's see if something different happens.

NB: I test all those versions with Steem, without any trouble.
You do not have the required permissions to view the files attached to this post.
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Display a color pixel in assembly language on Atari ST.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: 30 Jan 2019 22:26 Anyway. I post here a very different test. It is just a standard EmuTOS (without debug traces), but *without* any Bus Error checks. Let's see if something different happens.

I tried a couple of fresh boots and I get these type of errors..

1.jpg
2.jpg

One test bus error came up first but I forgot to take screenshot, but above shows bus error after pressing spacebar anyway..
You do not have the required permissions to view the files attached to this post.
User avatar
BlankVector
Posts: 93
Joined: 15 Sep 2017 22:51

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by BlankVector »

Apologies, those low PC addresses are normal for EMUTOS*.PRG. Such EmuTOS-RAM lives at $1c04. I'm looking at disassembly right now with the addresses of your screenshots.
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Display a color pixel in assembly language on Atari ST.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: 30 Jan 2019 22:39 Apologies, those low PC addresses are normal for EMUTOS*.PRG. Such EmuTOS-RAM lives at $1c04. I'm looking at disassembly right now with the addresses of your screenshots.
I just tried again, power off first, reboot, illegal instruction again. Similar address, 6Fe2.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

Tried again, bus error this time on boot..

2.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
BlankVector
Posts: 93
Joined: 15 Sep 2017 22:51

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by BlankVector »

As I understand from pictures: EmuTOS without Bus Errors has the same problems. So Bus Error behaviour on the hardware doesn't seem to be the cause.

Let's focus on the last picture.
sr=2700 means that interrupts are disabled, so the problem is very unlikely to come from interrupts.

pc=0000c7c0: This is indeed inside snd_init(). Again!

Disassembly is:

Code: Select all

0000c7ba: 42b9 0004 2464             clr.l $00042464
0000c7c0: 23fc 0000 c880 0000 05ac   move.l #$0000c880,0x000005ac
opcode=42b9: Indeed. Exception is reported to the next line (offending or next line, depending on exception type. While previous line, causing the exception, is indeed $42b9.

Note that the offending instruction "clr.l $00042464" is completely harmless, it just puts 0 to an address just above 256 KB of RAM.
And see the error message: addr=77472464. The low word is OK (same low word as $00042464), but the high word is completely different.

Some possibilities:
- Hardware is completely broken and triggers Bus Error when writing at $00042464. I don't think so.
- EmuTOS code in RAM has become clr.l $77472464. Very possible, as that would indeed cause a Bus Error. Question is how could that be possible ?
Again, some ideas:
- Maybe the hardware has some floppy/DMA issue, and some words of EMUTOSUK.PRG are randomly trashed. (????)
- Maybe EmuTOS trashes itself in RAM at startup, due to a bug. But why does not that happen on other machines?
- Maybe some DMA access randomly trashes the RAM after EmuTOS is loaded. Would that even be possible?

Surprisingly, this happens precisely after writing to the YM2149 to initialize the I/O ports. Is this a clue of something?
Or maybe some random parts of EmuTOS are trashed, and this time the random innocent victim is YM2149 I/O initialization?

Code: Select all

0000c7a2: 7087           	moveq #$87,%d0
0000c7a4: 11fc 0007 8800 	move.b #7,$ffff8800
0000c7aa: 11fc ffc0 8802 	move.b #$c0,$ffff8802
0000c7b0: 11fc 000e 8800 	move.b #14,$ffff8800
0000c7b6: 11c0 8802      	move.b %d0,$ffff8802
Or maybe just bad RAM at $c7bc ??
Or some weird issue on the address bus with high word or some addresses? I can't believe that, as GB6 couldn't run.
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Display a color pixel in assembly language on Atari ST.
User avatar
exxos
Site Admin
Site Admin
Posts: 28217
Joined: 16 Aug 2017 23:19
Location: UK

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

EMUTOS boots fine on 16MHz, so I don't think its bad RAM.. I have run diagnostic cart RAM test and is fine.. but will try YAART just in case..

GB6 can load and run all tests fine all day with TOS206.. diagnostic cart passes floppy access tests, it writes and reads..

I was wondering if BERR wasn't been generated.. I do isolate GLUE on ROM access, but it shouldn't matter I think... But if that was the case, EMUTOS would never work on a STFM.. But isolating GLUE during ROM could be a issue, indeed it was with the diagnostic cart.. Even so, I didn't see any issues relating to that anyway..I think BERR would only be from a device, not ROM itself anyway. If ROM did BERR, the machine wouldn't boot up at all anyway.

So it writes to YM chip then error.. strange...

EDIT:
I did auto test on diag-cart, I can hear audio... so test is ok...

Return to “SEC 64MHZ BOOSTER”

Who is online

Users browsing this forum: CCBot and 2 guests