STe - Bad DMA Chip

[czietz]

My MegaSTE currently has a HC CPU. I can test next week, if you like. Or is there a known incompatibility with the MegaSTE in general with the demos mentioned above?

[joska]

The bombs after the initial opening texts really does sound like the disk content hasn't been read properly by the bootsector TOS floppy sector read code.

The demo starts (well, startED ) correctly with the original CPU, so I believe the disk and drive is OK.

Besides that, that's also the point in time where the demo does all the nifty initialization stuff (checking wakestate, syncing to HBL etc). There's definitely room for strange failures there.

Sounds like this is where it crashes.

Just to be sure that the disk indeed is OK I tested it on my other STE (which - BTW - is original and will not see any modifications or hacks) and I saw this:

https://atari.joska.no/MOV_0323.mp4

I had to powercycle to get it to display it correctly. Strange, I have watched this demo a few times on this machine and never seen this before. I don't think it's related to the HC vs TTL CPU issue.

[joska]

My MegaSTE currently has a HC CPU. I can test next week, if you like. Or is there a known incompatibility with the MegaSTE in general with the demos mentioned above?

I believe {closure} doesn't work on the MSTE. Atleast it didn't a couple of years ago, maybe troed has released a fixed version?

[czietz]

As for your STE, I suppose you already checked yourself, but just in case: look closely at the contacts of the CPU socket. I once managed to bend a contact while swapping CPUs causing the STE to stop working as well. Fortunately that was fixable.

And just nitpicking: the original 68000 is not TTL (which would imply bipolar transistors) but NMOS, the 68HC000 is CMOS.

[ijor]

https://atari.joska.no/MOV_0323.mp4
I had to powercycle to get it to display it correctly.

That sounds like a SHIFTER wakeup issue.

[troed]

My MegaSTE currently has a HC CPU. I can test next week, if you like. Or is there a known incompatibility with the MegaSTE in general with the demos mentioned above?

I believe {closure} doesn't work on the MSTE. Atleast it didn't a couple of years ago, maybe troed has released a fixed version?

Nope. v1.1, which is MegaSTE compatible, sits happyily unreleased on my drive since more than a year

[troed]

I had to powercycle to get it to display it correctly. Strange, I have watched this demo a few times on this machine and never seen this before. I don't think it's related to the HC vs TTL CPU issue.

That's quite uncommon seeing that Shifter wakeup issue on STE actually. On ST in wakestate 2 it's a hit'n'miss depending on temperature. The "stabilizer-less" fullscreen scanlines I developed for Closure aren't as stable (hah) as the Level 16 ones ...

[joska]

As for your STE, I suppose you already checked yourself, but just in case: look closely at the contacts of the CPU socket.

Yes, it's most likely the CPU socket. I found a crack and a small piece was broken off.

[czietz]

My MegaSTE currently has a HC CPU. I can test next week, if you like. Or is there a known incompatibility with the MegaSTE in general with the demos mentioned above?

OK, I could also swap the HC CPU into the 1040STE. This requires some effort, though (the 1040STE is currently stored away and I would need to disassemble it); so I'd only like to this if you think some information can be gained from such a test.

Otherwise: is "We Were" known to run on a MegaSTE? Then I could test that one with the HC CPU.

[joska]

Not sure if you can figure out what's happening with only a binary, but I guess /troed can easily figure exactly where {closure} crashes on the HC. It would be extremely interesting to find out what's happening, and how/if it can be worked around.

[joska]

Yes, it's most likely the CPU socket. I found a crack and a small piece was broken off.

Yes, it was the CPU socket, and yes, it has been fixed

[czietz]

That's quite uncommon seeing that Shifter wakeup issue on STE actually.

My 1040STE also had these black bars (mind you, still with the original NMOS CPU, I'll swap to CMOS later). It took me several power cycles to get to the wakestate in which Closure displays correctly. Maybe my STE is "special"...

[czietz]

OK. Here are the results: On my 1040STE using a 68HC000 (CMOS) both "Closure" and "We were @" run without any noticeable difference compared to the original 68000 (NMOS). In particular, apart from the black bars / wakestate issue in Closure (that occurs with both CPUs) I did not notice any graphic artifacts or glitches.

Thus, I cannot confirm that there are systematic differences between NMOS and CMOS 68000s. And to be a little on-topic: Therefore swapping the CPU is still a viable option for people affected by the seemingly "bad" DMA issue.

PS: Anything else someone wants tested before I switch back to the original CPU later today?

[joska]

Odd... What revision is your STE?

[czietz]

Where is revision on an STE board? The board is date-coded 44/(19)89 and it's labeled CA4003290 "Action". In fact, it looks mostly identical to this board: https://temlib.org/AtariForumWiki/image ... fan_jl.jpg

[joska]

My STE's PCB is also labelled CA4003290, dated 0291. The revision field is blank.

[ijor]

Yes, it was the CPU socket, and yes, it has been fixed

If you can run more tests and may show a video or some pics, it could be interesting. But so far, and after czietz test, it doesn't seem like an incompatibility of the CMOS CPU.

It is possible that the disk and/or the drive is not 100%. It might load on one machine but not on the other. troed mentioned it already happened to somebody else, and it seems it relates to some non optimally reliable loader on his first version of the demo.

[joska]

I must remind you that this happens on two different STE's. Same problem on both - works fine with original CPU, does not work with HC CPU. Two different machines, two different drives (or three to be more precise, as I have recently replaced my drive with an original one) and two different disks.

[czietz]

But you did all tests with the same HC CPU? Maybe it's the CPU. Not the fact that it's CMOS, but this one CPU.

As for diagnosing this further: If I understood it correctly, Closure crashes. Any chance you could retry this with EmuTOS so that troed would get a more detailed crash dump? Or -- assuming the STE boots to the Desktop after the crash -- can you display the crash information recorded by TOS with a program such as POSTMORT.PRG (http://www.umich.edu/~archive/atari/Uti ... stmort.arc)?

[joska]

The other computer is not mine, so there's two different CPU's as well. And a different tester

[troed]

The HC loads the DMA bus differently - that's why it "solves" the bad DMA issue. That could of course also affect the 1772.

The v1.1 image might be interesting to test then, since it is more fault proof regarding floppy loading.

[joska]

A couple of videos when using a HC CPU:

https://joska.no/closure_ste_hc_1.mp4
https://joska.no/closure_ste_hc_2.mp4

In the first video there is no display after the crash, but you can hear noise from the crashed music player. In the second video you see how it crashed the second time I tested it.

Same STE/drive/disk but original CPU has no problems with this demo.

Edit: With TOS 1.62 I usually get a blank screen after the crash, occasionally there are bombs. With 2.06 there are always bombs. This supports the load error theory I think.

[ijor]

I must admit I never saw multicolor bombs. That must be troed and his magic demos!

[troed]

French flag ... or just a one bitplane displacement

This does look like the floppy load issue. joska - I'll get you a link to a v1.1-prerelease image if you want to help me test.

[joska]

Yes please

Edit: We Were @ - another recent trackloader - does not load with an HC installed either. It does run from harddrive (IDE), but it apparently does some crazy stuff because my LCD TV does not like it at all

we_were_ste_hc.jpg

I remember some issues with the syncscrolling parts even on my CRT, if there's enough time I will dig the CRT out of storage and test it again.