CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[exxos]

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 (45.34 KiB) Viewed 4569 times

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

2.jpg (43.73 KiB) Viewed 4569 times

Then if I press spacebar...

3.jpg (75.88 KiB) Viewed 4555 times

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

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

[exxos]

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 (83.01 KiB) Viewed 4519 times

2.jpg (87.75 KiB) Viewed 4519 times

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

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

[exxos]

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 (71.42 KiB) Viewed 4502 times

2.jpg (74.59 KiB) Viewed 4502 times

One test bus error came up first but I forgot to take screenshot, but above shows bus error after pressing spacebar anyway..

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

[exxos]

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.

[exxos]

Tried again, bus error this time on boot..

2.jpg (50.91 KiB) Viewed 4495 times

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

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