STe booster v 1.5 36Mhz

[nemox]

hello,
I tried 390 pF on 2pin on DMA and nothing

can i try this http://www.exxosforum.co.uk/atari/last/DMAfix/index.htm "2014 STFM FIX (possibly obsolete)"?

[exxos]

You can try, but i that was issues with gigafile so its unlikely to help. Swapping the 1772 or DMA chip from another machine may help. But seems you have some odd fault I not seen before..

[exxos]

You could also try 2.2K pull ups on DTACK, AS, BG,BGACK.... But thats really scraping the ideas box there.

I don't get why the DMA resistors did not solve the issue... issue like this are normally bus issues with noise and the DMA databus is the most unstable one causing a lot of issues.

It really does beg the question that ultrasatan may might ultra sensitive to noise issues. I never had any issues, but my ultrasatan is very old version.. but I do have the same one as you I got at xmas time, but not had chance to try it yet.

[exxos]

I tried my old ultrasatan, and it is not even recognised at 36MHz. Obviously something is unhappy somewhere on the STE. But there is not much I can do with the current GAL chip.

The only possible solution I can see is to go back to the old V1 firmware and maybe use the STE's 32MHz clock again, but will see if I can do something in the firmware first on 36MHz.

[rubber_jonnie]

Just to drop in what happened to me last night that I've been talking to exxos about. In all scenarios the CosmosEx was running as an external ACSI device, and was using IDC Pro as the driver.

Hardware: 32Mhz V1 STE, 4MB RAM, Gotek and CosmosEx (So effectively Ultrasatan)

Worked fine with this configuration, either 32Mhz or 8Mhz, TOS 1.62 or 2.06.

Hardware: 8Mhz 1040 STF factory config, TOS 1.04 and CosmosEx

Worked fine.

Hardware: 40Mhz V1 STE, 4MB RAM, Gotek and CosmosEx

CosmosEx booted and launched its network and config drives (O: and P:). The SD card disappeared from sight, and never came back.

So after the 40Mhz test, my SD card seems to have been corrupted beyond recovery. I will try and rebuild using the new drivers I have from PP on a mostly standard 1040STFM with Gotek and try @40Mhz again once I have a process to recover quickly sorted out.

[exxos]

Something is really unhappy with 36MHz

So far I have created a new firmware which uses more like the V1 switching firmware. The problem is the ROM access drops dramatically from 309% to 233% and there is no way to speed this up any further. The simple GAL doesn't have enough IO pins or LA's to do anything complicated. I have not tested this on the hard drive yet.. But I really do not want to go backwards in terms of speed, so likely I will abandon that version.

But I have started porting the V1 firmware over fully which uses the STE's 32MHz line like the V1 booster. So we do not get the speed drop and we should not get the hard drive issues because there was no issues with the V1 firmware.

[exxos]

One hardware modification which seems to be needed is a 1K pull-up resistor on /AS..

IMG_3798.JPG (246.52 KiB) Viewed 3710 times

I'm still working on the firmware but seem to have a small stability issue which I am looking into. It may be a bad connection somewhere..

But so far I have managed to copy files from the floppy to the hard drive, and hard drive to hard drive without issues, but I need to do more testing yet.

[rubber_jonnie]

My question would be, on machines with U101 installed, is that pull up still a requirement?

I ask because my 40Mhz STE has U101 in place.

[exxos]

My question would be, on machines with U101 installed, is that pull up still a requirement?

I ask because my 40Mhz STE has U101 in place.

I don't know, I don't have a working board to try it... But the same signal is on top of the GAL (/AS) PIn 3, so just put 1K on top of the GAL pin 3 to pin 24 (5v).

The problem seems to be that while the booster is stable, and the floppy drive is stable, the hard drive does not even boot for me. Then when I get the hard drive working and the booster is stable, the floppy drive stops working. Then when I get the hard drive and floppy drive working, the booster is then unstable. So I have literally been going around in circles drive myself mad with this. I have literally spent every second of yesterday looking into this issue. I have literally gone through several hundred code changes and been going around in circles drive myself mad with this.

I have to have code which synchronises signals which inherently adds delays. It is just a side effect of having a asynchronous oscillator on the PCB. Even if I speed up the ROM access, the figures still do not change in the scores anyway.

What seems to be part of the issue is that when a DMA cycle is done and BGACK goes high, the CPU will immediately start the next bus cycle and I believe likely DTACK still low from that cycle. So the CPU immediately reads DTACK and completes the cycle with invalid data and it becomes unstable and crashes mostly.

The fix I do this was to add in BGACK into the DTACK code. This really does not make sense anyway. But if BGACK is low, the CPU isn't allowed to see DTACK. This seems to fix the floppy drive issue.. The CPU should not be accessing the bus when BGACK is low anyway.. But this definitely is part of the problem. I even tried delaying DTACK by various amounts and it did not make any difference at all.

I was doing some comparisons between running the CPU at 36MHz constantly, and switching to 8MHz when accessing the bus. Code which works is the one which switches to 8MHz on bus access. But DTACK is synchronised so the speed of the CPU should be irrelevant. So I do not know it is different between the two versions of the code other than the CPU is running at 36MHz all the time.

As Ijor pointed out with the slow SND DTACK issues on the STFM, he says this issue was fixed on the STE. But this could be another problem or something like this on the STE which is causing things to trip up. Considering using a 1K pull-up resistor on /AS seems to make things more stable, it can only be that it is helping release DTACK a fraction faster because /AS is rising faster.

In terms of the switching code, the CPU will run faster sooner when it sees /AS high. So as something is tripping up, technically this issue should theoretically get worse. But it actually goes better. So I think this is a slow release on DTACK somewhere. I will spend a little more time today to see if I can work out anything more..But I am not going to investigate this fully as it would take likely months of investigation and it is not work I want to invest time in anymore.

Basically I have some code which now works with my test board which is 36MHz. This is partly based on the V1 booster code. The ROM access overall is slower than the 32MHz board, but this is just unavoidable. So if anyone has these issues, send me a PM and I will send the JED file , you will have to reprogram the GAL which means unsoldering it from the board (at your own risk!). Though I would suggest cutting out the GAL removing pins one by one and programming a new GAL. I can always send you guys a programmed GAL to change if needs be. But please only use Atmel GAL's as I have noted there are lots of weird issues with GAL's from China (lattice stamped chips). If there is physical room under the metal shielding, I would suggest soldering in a socket.

[rubber_jonnie]

Ok, I'll have a look through my parts bin, whilst I definitely have some GALs around, I couldn't say one way or the other if they are suitable, so may have to order some. I almost certainly have a socket I can install though, and I definitely have 1k resistors.

Also had my SD cards arrive today, so I can certainly try and get the CosmosEx up and running on a stock machine and take it from there. I have already imaged the two cards, one with PPs driver, the other with an ICD Pro base image that should be good for testing.

Not training tonight, and my other half is at work until 21:00, so I should be able to at least have a good bash at at least restoring HDD access in some way, shape or form.