H4 16mhz modification

Topic for users to share their building progress.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: H4 16mhz modification

Post by troed »

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
User avatar
PhilC
Moderator
Moderator
Posts: 6012
Joined: Fri Mar 23, 2018 8:22 pm

Re: H4 16mhz modification

Post by PhilC »

looking forward to seeing the results guys.
If it ain't broke, test it to Destruction.
User avatar
PaulJ
Posts: 1568
Joined: Sun Apr 08, 2018 1:14 am
Location: USA

Re: H4 16mhz modification

Post by PaulJ »

@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:
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: H4 16mhz modification

Post by exxos »

troed wrote: Sat Jul 04, 2020 10:55 am 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
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: H4 16mhz modification

Post by troed »

exxos wrote: Sun Jul 05, 2020 1:16 am 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
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: H4 16mhz modification

Post by exxos »

troed wrote: Sun Jul 05, 2020 2:03 am 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
kodak80
Posts: 370
Joined: Sat Oct 21, 2017 1:14 am
Location: Brisbane,QLD Australia
Contact:

Re: H4 16mhz modification

Post by kodak80 »

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-16hzModBoard.jpg
GemBench-16hzModBoard.jpg (262.04 KiB) Viewed 4461 times
GemBench test results EmuTOS 0.9.12:
GemBench-16hzModBoard-test2.PNG
GemBench-16hzModBoard-test2.PNG (974.17 KiB) Viewed 4461 times
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:
KODAK80-TEST01.png
KODAK80-TEST01.png (109.43 KiB) Viewed 4461 times
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.
Atari Falcon 030 | Atari 1040 STE | Atari 1040 STFM | Atari 1040 STF | Kryoflux & Supercard Pro Flux boards
Creator of the Atari ST Review magazine archive: https://www.chillichai.com/atari-st-review
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: H4 16mhz modification

Post by troed »

kodak80 wrote: Tue Jul 28, 2020 2:41 pm 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
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: H4 16mhz modification

Post by troed »

PaulJ wrote: Sat Jul 04, 2020 3:32 pm @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
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: H4 16mhz modification

Post by exxos »

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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “MONGREL H4 USER BUILDS”