exxos's Atari, Amiga & retro forum

Thanks!

I'm out of the loop what the original 16MHz PCB does. My intention is to connect up a GAL running (some version of) my doubleST code and see what happens.

https://github.com/troed/DoubleST/blob/ ... ublest.pld

/Troed

looking forward to seeing the results guys.

@troed , out of quriosity what program do you use to create the jed file? The opal programs require dos and dosbox which isn't optimal.. :coffee:

troed wrote: 04 Jul 2020 10:55 I'm out of the loop what the original 16MHz PCB does. My intention is to connect up a GAL running (some version of) my doubleST code and see what happens.

IIRC it was just a clock divider with a AND gate for the DE line. Problem is 2 of the clock edges are to close for it to even boot. This was hacked with a small cap to load and delay one of the clocks. Obviously that's not a good solution.

Somewhere, I added images of clock skew which gave a 1 in 4 chance of booting. Which are down to the wake up states . this was future made problematical as the glue would have a 1 in 2 chance of being able to display the video properly. Again down to wakeup states.

My second sync board I designed , which will be mentioned somewhere nodoubt, I inverted one of the clocks and added in a adjustable delay line to resync the clocks. Trick would be finding a delay sweet spot so the clock skew would be 50% on WS2. So other wake states would be either side of that skew, like 25% or 75%. I don't remember exactly as it was months ago when I talked about that project. But like WS0 wouldn't work as the clock skew wasn't enough. So forcing a delay would correct that, hence the sync board I designed.

Even so, I abandoned the idea as it would be a lot of trial and error, and still may not work anyway. Plus the glue problem with the video would still have to be solved. But really it all needs investigating more. Which I just don't have time to do. If the MMU had a reset line this would have all been done and dusted ages ago. There is a possibility that holding some lines on the MMU may reset it as outline in the suska code. But again, nothing I have time to try .

Having seen all the issues on the alpha mod, I just don't see it as a good solution . nothing pains me more to give up on the 16mhz mod. But it is still a dead end road, this is why @Icky and I have been working with the suska cores. They won't be 100% compatible, but that may change in the future with firmware updates. But we can ramp to a 32mhz system or higher with the suska cores. We would lose compatibility at higher speeds anyway. Suska glue has TOS206 decoding built in, plus other cool stuff can be added and fixed.

This also brings me back to why I was saying about doing a legacy board which will basically be a cut down H4 motherboard to replace failing original boards. And the FPGA direction which will be a full 32mhz system at least. So that is the system I opted to invest time into.

Edit:
This seems to be where i talk about issues somewhat,
https://www.exxosforum.co.uk/forum/viewt ... 945#p22951

exxos wrote: 05 Jul 2020 01:16 Somewhere, I added images of clock skew which gave a 1 in 4 chance of booting. Which are down to the wake up states . this was future made problematical as the glue would have a 1 in 2 chance of being able to display the video properly. Again down to wakeup states.

Thanks - I didn't have those issues on my doubleST (regular 1040STF modified) so I want to replicate your findings first.

BTW, if it's all due to wakestates that might be possible to solve. Remember the TEST pin on the GLUE that does affect these - used in the wakestate-nudger I did on my Mega ST.

https://blog.troed.se/projects/atari-st ... te-nudger/

/Troed

troed wrote: 05 Jul 2020 02:03 BTW, if it's all due to wakestates that might be possible to solve. Remember the TEST pin on the GLUE that does affect these - used in the wakestate-nudger I did on my Mega ST.

Yeah I remember that. If you get it to boot it would be interesting to try to see what the glue wakeup effects.

Though I think its likely the MMU is to blame for most of the problems. You could try the reset idea. If the machine could just boot with the same wake up states , at least its a consistent point to try fixes on. But fixes are harder when there is a random wakupstate. As how can you fix something which is random..

I think my chips favoured WS2 and WS4 according to your test program. Though not sure if The glue wakeup is a factor.. Again would be interesting to see if the glue changes that number.

I only saw 4 wakup states.. There should really be 4 on the MMU and 2 on the GLUE. Making 8 possible wakeup states. But I don't think more than 4 were even proven ?

Could be the MMU is responsible for 2 wakeup mode and the glue 2 more. Or maybe there is 8 wakup states, but the overall combination only ever results in 4 detectable.

I guess if you boot into WS2 for example, then use the wakeup nudger on the glue and see what WS number you can get afterwards. Then power on/off your machine until it boots with WS4 and repeat the test with the glue nudger. Might be harder to get the machine to boot in WS1 but again repeat the glue nudger and see what WS numbers you get.

Of course also checking my findings as I mention in my blog for the 4 wakuip modes I saw. If the glue is responsible for some of them, then you should be able to replicate at least 2 of my findings, such as boots fine or loss of video etc.

Just a small update on my testing using the Exxos 16mhz PCB mod board.

The 16mhz mod works apart from unstable video output. GemBench shows that the performance improves and is consistent (when you can see the screen output). So the 16mhz boost works as expected. Just need to address the unstable video output. The unstable video is linked to the DE feed to the MMU which is fed from the mod board pin 3(grey wire).

GemBench test results TOS 1.04: GemBench test results EmuTOS 0.9.12: If I only wire up the wires from the mod board to the DE and MMU DE pins with no other clock changes, the video output becomes unstable. If I feed the 2mhz input on the mod board from either the 2mhz pin on the mod board or the H4 2mhz jumper pin, the video output is corrupted and unstable.

Here is what I wired up as per the image:
H4 jumpers 6,7,3 and 12 removed to allow the mod board to be wired in as shown above.

I fed 32mhz from the mod board into the MMU jumper pin (blue wire) which then feeds 16mhz to the CPU, Blitter and EXP sockets - I left the jumpers on the H4 board in place for this.
8mhz from mod board connected to System Bus jumper pin (orange wire).
4mhz from mod board connected to MFP IC jumper pin (yellow wire).
Mod board pin 3 was wired to MMU DE jumper pin (grey wire)
Mod board pin 1 was wired to DE jumper pin (red wire)
The Shifter clock was still connected to the H4 onboard 32mhz XTAL for this testing.
5v and GND to mod board was wired to one of the H4 floppy header pins.

Note, I removed the Blitter chip for testing and set the H4 Blitter jumpers to show chip was not present. This was to simplify my initial testing.

The video output generally got worse the longer the H4 was running even with pressing the reset button.

kodak80 wrote: 28 Jul 2020 14:41 I fed 32mhz from the mod board into the MMU jumper pin (blue wire) which then feeds 16mhz to the CPU, Blitter and EXP sockets - I left the jumpers on the H4 board in place for this.
8mhz from mod board connected to System Bus jumper pin (orange wire).
4mhz from mod board connected to MFP IC jumper pin (yellow wire).
Mod board pin 3 was wired to MMU DE jumper pin (grey wire)
Mod board pin 1 was wired to DE jumper pin (red wire)
The Shifter clock was still connected to the H4 onboard 32mhz XTAL for this testing.

Running the Shifter and MMU off different oscillators is a sure way to get strange video effects when they desync. Other than that the above should work - but I would probably also drive the CPU from the mod board to start with, and then see if running it off the MMU works better (I've seen that when I started with doubleST).

/Troed

PaulJ wrote: 04 Jul 2020 15:32 @troed , out of quriosity what program do you use to create the jed file? The opal programs require dos and dosbox which isn't optimal.. :coffee:

I'm sorry - I completely missed your question before. I use WinCupl, which is working perfectly fine under Wine.

/Troed

I think the slow rise and falltimes of the MMU clock outputs are a big issue. The new board I was working on inverted them, then added a adjustable delay to re-sync the clocks and buffer them. This way you get a proper clock output and can even advance or retard it if necessary.