dml attempts a Raven

[dml]

@dml your partition size is probably far too big and I believe it needs to be fat16? Try a partition under 500mb IIRC.

I thought it was supposed to be fat32 :-/ will try again with fat16. In any case, I did repartition it to 500MB on the Falcon with TOS/Win+byteswapping and it seems to be have partitioned ok - but doesn't list as drives on the Raven.

I'm also getting more and more frequent LineF (FPU?!) crashes on the Raven just clicking on stuff or moving the mouse around. e.g. see attached image. This is getting in the way of trying to set up a disk as the RAM drive gets wiped out every time.

Have reduced the machine to 1 memory stick and the ET4000AX card and nothing else - but the problem persists.

crashes.jpg

[edit]

Reformatted the CFlash to fat16, repartitioned into 4x 500MB partitions as TOS+Win+byteswapping. Still not recognised by the Raven.

...and the machine is crashing a lot, I think always LineF exception. I think it is actually getting worse. The installed clock is 40MHz and I tried two different 68150s but no change. Swapped the RAM board over, no change. Might try swapping the clock to 48MHz but not expecting it to improve.

[agranlund]

I wouldn't use HDDriver on Raven unless you have an adapter to transform the interface into a bog standard Atari big endian interface.

Afaik the only hardware banging stuff that understands little-endian interfaces, sometimes called "twisted cable" in the Atari world, is EmuTOS and ppera's stuff. HDDriver, Atari TOS, MagiC, all other misc drivers and their utilities does not.


I thought I was clever putting a little endian interface on the board, optimising for what I though was the common use-case of partitioning on PC and only using EmuTOS. But in practice that was a horrible idea and the next board rev has a big-endian interface just like Falcon etc.
Software byteswap doesn't seem to make any measurable impact on throughput, and being able to say "it works just like any other Atari" makes it a lot easier to point someone at generic HDD documentation rather than "it works just like on an Atari where you are using a twisted-cable. Or an Atari with a TF536", which can cause no end of confusion :)

And for MagiC it is required to have a normal Atari interface (with TOS partition). Porting Atari TOS 3.x is somewhere down there on the want-to-do list as well and that has the same requirements.

(I too am using a disk-on-module and did it exactly the way you tried by transferring HDDriver over with Parcp to be able to partition it, but that only worked by using a hardware byteswap adapter)


If you can, I would try to partition the drive on a PC. At least your first partition needs to be FAT16 since EmuTOS does not understand FAT32.
(FAT32 and ext2 works in MiNT though).
I'm pretty sure EmuTOS supports larger FAT16 partitions but I usually keep them at around 500MB out of habit.
Making FAT16 partitions can be a challenge in itself but GParted, or Diskpart if you're on Windows, should work.

But it does sound like something else is tripping up, wether or not EmuTOS can read the partitions shouldn't trip up the machine like what you are seeing.

[dml]

Thanks for the extra info on the partitioning - I've been overcomplicating things trying to use HDDRIVER... will prepare the disk on the PC tomorrow as fat16 with a couple of small partitions and see what happens.

The crashing though - not sure what to make of it. Regular LineF exceptions is kinda weird (versus a buserr or illegal or something else you might expect from a bus fault or overclocked something...). It's a full 060 too - so it's not like it is hitting actual FPU opcodes and failing - and I would not expect EmuTOS to be using it anyway as it would rule out LC use...

So either the CPU is failing/faulty or there's something external causing it to throw LineF - spuriously fetching instructions with $Fxxx.... hmm.

I can try the LC CPU and see what happens. It might at least do something different.

[dml]

I swapped out the 060 for an LC chip and it seems similarly flaky - not LineF exceptions this time but freezing while doing various things e.g. while scrolling the .txt files on the ROM disk, it will randomly stop half way through writing a line of text.

It also has more trouble booting with the LC chip installed. I got a series of no-video-signal bootups before I got to the desktop.

So this might be some kind of 'good' news as the full 060 is not something I wanted to be replacing. But it's not clear what else might be wrong.

Another experiment I can try is to flash the second ROM card which has the debug monitor (the one with PLCC chips) with the same TOS image and see if anything changes, in case there's an issue with the SMD ROM chip I used... it wasn't the recommended one but was on the 'should also work' list...

[PhilC]

@dml have you tried a slower oscillator? Also just wondering if the 68150 is causing you issues, so might be worth swapping that as mine gave me some odd issues when the 68150 was failing.

[dml]

@dml have you tried a slower oscillator? Also just wondering if the 68150 is causing you issues, so might be worth swapping that as mine gave me some odd issues when the 68150 was failing.

I have tried 2x 68150s so far (Freescale FN33, Mot FN40) and cleaned the pins on both - I have one more Mot FN33 to try but I'm not expecting any change.

I also re-seated all the chips and swapped the MFPs for different ones.

It has been running with the slower 40MHz clock all along. I tried briefly with the 48MHz (before trying the LC) but was certiainly not better, maybe worse.

[edit]

Tried the 3rd 68150, no change.

I notice the crash dump has some consistency (which actually is LineF again even on LC - it wasn't always showing the dump).

The PC is always reported at $602e0206. That doesn't look normal.

I can get it to crash fairly easily by repeatedly double-clicking the .TXT files in the ROM disk on M. Do that enough times and it throws the Line F Emulator crash dump with that PC.

[edit]

Huh. Seems like a coincidence that $602e,$0206 happens to be the longword header on a TOS 2.06 ROM image? A branch followed by version then pointers.... huh? Why would the PC have the value of the first ROM entry?

Is that 'panic' dump showing the PC value itself or the value at the PC address?

[edit]

Another weird fact - with the 40MHz clock, the LC chip won't boot 70% of the time. When it does boot, it is quite crashy. With the 48MHz clock, it boots nearly every time. Seems like it might be less crashy too - it appears to works a bit longer but still crashes after a bit of use.

[dml]

Beginning to realise I don't remember seeing these crashes before I changed the power supply. I was using a really old ATX for testing the board standalone, but now it is in a case with a brand new, non-cheap ATX........ hmm.

Something else to check tomorrow, although only a 5% chance that's involved at all.

[PhilC]

@dml try and get a genuine 68150fn40 if you can as even 40 mhz oscillator is a 7mhz overclock for the fn33, let alone 48.

Does the ATF1508 get overly hot? Mines a 10ns one that I've put a heatsink on maybe HS the 68150 too?

Definitely worth checking the power, especially the 3.3v with the new PSU. It also goes through the three diodes near the Eiffel and on my board they do get pretty warm also.

[dml]

@dml try and get a genuine 68150fn40 if you can as even 40 mhz oscillator is a 7mhz overclock for the fn33, let alone 48.

I got the FN40 from a decent source that has always sent me genuine parts (and so, not the cheapest source but reliable). I suppose they could still be remarked but having tried 3 chips from different sources with no real change in results, I'm not sure it is the root cause.

I saw more of a change by swapping the crystal and the CPU. Didn't fix anything but the behaviour is clearly not the same. The LC has trouble booting at 40 - the full 060 didn't have that problem and worked at both clock speeds.

Does the ATF1508 get overly hot? Mines a 10ns one that I've put a heatsink on maybe HS the 68150 too?

It's a 7ns device from Mouser. I didn't try to save money on that one :) especially the postage (!). The ebay one I tried before that was complete garbage and wouldn't even flash.

I'll check it tomorrow but I don't think it gets warm. Maybe *not* getting warm is suspect?

Definitely worth checking the power, especially the 3.3v with the new PSU. It also goes through the three diodes near the Eiffel and on my board they do get pretty warm also.

It might be a power thing but the consistent LineF exception thing bothers me. $Fxxx instructions. Why is it always that? And why that same, suspicious PC value that looks like a TOS 2.06 boot header? o_O I should check what EmuTOS has in the header...

The Raven doesn't seem to have much in the way of rail capacitance compared with PC boards, which often have rows of electrolytics near the ATX connector. I'm wondering if this new ATX supply just assumes the board can manage local regulation & filtering. That would be really crap, but at the same time, not a huge surprise. I'll try with the old ATX tomorrow and see how it behaves....

[luciodra]

I got the FN40 from a decent source that has always sent me genuine parts (and so, not the cheapest source but reliable). I suppose they could still be remarked but having tried 3 chips from different sources with no real change in results, I'm not sure it is the root cause.

Can I ask you who your dealer is?
Thank you.