exxos's Atari, Amiga & retro forum

@Badwolf I hooked up my mono monitor, its run GB6. Not sure how I am supposed to trigger the fault ?


I've copied C: to D: on IDE (fills the drive with about 512MB of crap) it's done that fine.


Also, I assume your STE has the updated 74F257 ? The older S257 I believe causes some issue with mono detect.


MONO bit is low as expected.

New patch register seems to be behaving now.

exxos wrote: 29 May 2025 11:18 @Badwolf I hooked up my mono monitor, its run GB6. Not sure how I am supposed to trigger the fault ?

In my case, try to load anything at all from IDE. Will reboot about 2/3rds the time.

Also, I assume your STE has the updated 74F257 ? The older S257 I believe causes some issue with mono detect.

No idea! Which chip are we talking about?

BW

Badwolf wrote: 29 May 2025 12:08 In my case, try to load anything at all from IDE. Will reboot about 2/3rds the time.

I've loaded STOS, GB6, HDDRIVER, copied lots of files from one partition to another, no resets or failures.

No idea! Which chip are we talking about?

U405 at the back of the STE (under the PSU)


Ignore the wire, image was from the V1 STE booster thread.

Though it may not be a issue if you are using my ST2VGA adapter as it sets the proper voltage on the MONO pin. Some cables etc leave it floating which causes issues. Though Atari changed to the F-series later on. Also solves some clock issues as well.

Got the register now to disable TTram.. but annoyingly I'm starting to get slight video corruption again :roll:

The issue seems to happen when the CPU is just entering 50MHz mode. So I've added ST_DTACK and some other bits into the RAM decoding line to make sure DTACK is high before any TTram decoding is done.. So far it seems to be working..

Need to start doing some thorough testing again now...

Current11 is now up. Loads of changes and fixes.

BIT0 in $DF0000 when set 1 will disable TTram , But I may have to do a hardware reset is things can start crashing because effectively the RAM is removed while the system is running.. Also the MMU reg (forget which one currently) needs to be cleared so TOS re-dtects (or not) the new TTram state.

I'm also starting to think all the delays I was putting on the SDRAM controller thinking it was address corruption somehow, its basically half true I think..

I went about things from the opposite end... Rather than delaying the control, delay before anything even decodes RAM.

What I mean to say is, while could still be low from the previous bus cycle, and I do believe this was part of the problem, I don't think the bus is actually "free" yet, and thats whats causing conflicts on the SDRAM controller. The CPU ramps into 50MHz and the ST bus is saying "to fast for next cycle" and screws up.

The current code I'm working on is "almost" stable.. its working out how long this delay needs to be...

Sorry no chance for any work last night. I did manage to quickly confirm it's a 74F257 at the back of the mobo, however.

I'll give the new firmware a go when I'm able and if I still see reboot on IDE, I'll try scoping the mono detect pin.

BW

Badwolf wrote: 30 May 2025 09:32 I'll give the new firmware a go when I'm able and if I still see reboot on IDE, I'll try scoping the mono detect pin.

Yeah probably a good idea to cover the bases just in case...

I need to try the firmware on all the other boards I have got here currently next , but there isn't really much else I can do at the moment now..

Just tried @Steve's board and past few versions of the firmware other than current7, TTram isn't found :roll:

Is rather perplexing how 2 basically identical boards can behave completely differently :roll:

EDIT:

I tried my first rev board (same as steves) and that "finds" TTram but just XXXXXXXXXXXXXXXXXXXXX it all. The later boards do have some "minor" fixes.. But not simple to do on the first rev boards :roll:

I seem to have a new lead now.. :hide:

I'm not sure that BURST is working right. In fact not sure it's even possible to BURST with SDRAM with the 030 CPU.. memspeed tests always seem erratic to tell anything from, but in GB6, speed has actually gone up from 847% to 853%. with burst on, I cannot get TT ram to even be found on the original boards, but it will work happily fine all day on the revision boards. However if I turn burst off, everything works fine..


Write burst I don't think has ever been fixed in the 536 codebase. But I don't think burst read is working right.. or at least its aggravating what problem I have at least.