ST536 STE EDITION

[Methanoid]

is anyone selling built ones either STE edition or ST edition?

[troupe86]

Just to echo the reply above, I'm declaring my interest in buying a TF536 for my STE. If anyone can point me in the right direction, it would be appreciated! Thanks!

[exxos]

Just to echo the reply above, I'm declaring my interest in buying a TF536 for my STE. If anyone can point me in the right direction, it would be appreciated! Thanks!

is anyone selling built ones either STE edition or ST edition?

You can register your interest in the buyers interest thread on the link below

viewtopic.php?f=94&t=7133

[exxos]

I've been thinking when I eventually get around to fixing my ST motherboards and doing more testing, that the bus resistor pullups are going to be a huge unknown with this accelerator and how things will behave, in particular as there are different values which can cause different faults hence why changing them in the first place. So I really need to test multiple different values.

Before I have used sockets for simply changing the resistor packs, but I generally just end up losing them or mixing them up or plugging them in backwards! So the idea popped in my head last night that why don't I just simply make a switchable resistor bank!

If I have 10k resistors on one side, 4.7 K on the opposite side, and have a switch each side I can switch to different values, also can have both on together for about 3.3K. A little higher than the 2.2K I have been suggesting, but it "should" be fine.

I've also realised that there is a slight "problem" with the IDE interface, because the buffers are enabled all the time, technically if a IDE device is "blown" or whatever, it could actually "short out" the system bus preventing the machine from booting etc. The problem is that because the PLD is full, and there are basically no free IO pins left, and actually routing the extra wire would be a nightmare... I thought I would just go with a simple AND gate on the CS lies to trigger the IDE databuffers. It is very simple logic that if the IDE device is selected, the data buffers are enabled. No need to overcomplicate it in any other ways.

I also added the Trudie IDE reset fix onto the STE536 as that was known to cause problems with some cards and it was simple add that as well.

Originally there was an issue with the CPU clock. It seemed to have bad ringing despite it being very close to the PLD, causing odd crashes etc. Generally adding something like a 33pF cap on it solved the issue. But the new boards now have a series resistor and pads for a cap if needed. So hopefully that will solve that issue as well.

@Badwolf also noticed I had the ROM bank numbers backwards

[exxos]

Myself @coonsgm and @Badwolf have been puzzling over some resetting issues over the past couple of weeks. Its a bit of a odd one because it would work perfectly fine on my STE, but it would not work reliably on the other guys machines I did have this problem originally on my machine which I thought I had fixed the problem, but obviously not.

I'm leaning towards there is a, for lack of a better word, "bug" in the DTACK control logic on the original TF536 firmware which the ST doesn't seem to like. This "bug" was carried over to the ST536 and the STE536. To my knowledge nobody reported any bugs with the ST536.. But the "bug" would actually still be there.

It was a bit of a strange one, because I could run the blitter demo all day without issue. But running GB6 would randomly reset the machine. It would also sporadically reset about once a minute even just sat idling at the desktop. It seemed to be linked with the floppy "polling" as the blitter demo seems to disable that, like with GB6 tests.. GB6 seem to mostly reset on the main window rather than doing a actual test.. This is when the floppy polling was enabled, well interrupts that is.

So currently we are testing out various firmware's to clamp down on the issues and hopefully fix it of course... I have also been doing minor tweaks to the PCB and some minor circuit changes as well.

[Cyprian]

it sounds similar to my issue with Mega ST and GB6 (PM from Dec 18, 20230. GB6 "Loop Tests" can freze the Mega ST and my blitter test works great for hours.

[exxos]

it sounds similar to my issue with Mega ST and GB6 (PM from Dec 18, 20230. GB6 "Loop Tests" can freze the Mega ST and my blitter test works great for hours.

I remember the conversation. I assume it was never resolved.

GB6 will trigger all sorts of hardware faults if its malfunctioning somewhere. It can fail repeatedly on a single test. In my early booster days it would always fail on something like VDI scroll text every single time.

The new firmware on the STE536 has been running all day just fine now in GB6. Next I need to investigate why the TTram is failing on 8bit accesses..

[exxos]

TTram was doing this before...

IMG_2852.JPG (81.84 KiB) Viewed 586 times

IMG_2855.JPG (89.2 KiB) Viewed 586 times

TTram "fixed"..

IMG_2856.JPG (96.67 KiB) Viewed 586 times

So now running more tests..

IMG_2857.JPG (106.05 KiB) Viewed 586 times

[Steve]

Hey Chris

Nice work. I didn't even realise there was this bug (I'll have to run yaart on mine this weekend to check) but I suppose I should be able to update my STe536 when you're ready to release a new firmware? If there are any hardware fixes you've made to the PCB would I be able to implement on mine through bodge wires?

Cheers

[exxos]

Nice work. I didn't even realise there was this bug (I'll have to run yaart on mine this weekend to check) but I suppose I should be able to update my STe536 when you're ready to release a new firmware? If there are any hardware fixes you've made to the PCB would I be able to implement on mine through bodge wires?

The hardware mods are "non=critical" and can't really be done anyway. They might make things worse yet

TTram is stable but running slower than it should... its very confusing to whats going on.