Troed's H4 build

[troed]

Yeah that worked out nicely, took out that bodge and brought the two DTACK sides up top :) Been playing with a test board today and have the H4 running off the GAL with 32MHz pass through. Feeding the MMU the 16MHz off the GAL instead of from the Shifter doesn't work though. Will need to use the LA or scope to see why.

If this works plausably well on a test board I'll have some PCBs made. Antenna wires with lots of MHz are problematic.

124DD046-A348-42D4-8808-0ACB96937A7D.jpeg

/Troed

[troed]

Hmm. So all development I did on the old STF used Lattice 16V8 and 20V8. The H4 is the first time I've gone with (still Lattice) 22V10 - and now I'm confused. The LA did show a strange duty cycle from the GAL which differs from what the Shifter produces - but it doesn't make sense. Or I'm misunderstanding a difference between the 22V10 and the others.

Code: Select all

/* huh? On the 22v10 this looks like it's HHHLHHHLHHHL instead of HHLLHHLLHH*/
 
/* 32, 32, 16 */
MMUCLK.D = !MMUCLK;

I clock the GAL with 32.08MHz, so my expectation is that this registered .D should be 50/50% duty cycle - and it was true on the other GALs. But on the 22V10 this code produces a 16MHz clock where the duty cycle is 75% high and 25% low, which apparently is no good for the MMU.

/Troed

[czietz]

Check the signal on the scope. E.g., if for some reason you have very slow edges, and depending on the threshold voltage setting of your LA, you would see an uneven duty cycle.

[troed]

Check the signal on the scope. E.g., if for some reason you have very slow edges, and depending on the threshold voltage setting of your LA, you would see an uneven duty cycle.

Agree - but the same code worked fine on 20V8. I can compare the GAL generated 16MHz with the one from the Shifter and the clock pulse frequency and timing are correct, so I assume it's the difference in level (duty cycle) which would then be an effect of the 22V10.

Sort of fishing for knowledge on whether I should be doing something else than .D = ! ...

/Troed

[exxos]

The code should give a simple clock divider. You not got noise on the clocks or bad grounding have you ?

[troed]

With the LA probes rearranged it started booting. I'll make a somewhat casual try getting this to work with a test board but will make and order some PCBs that should hopefully not suffer from signal problems.

Basically all I'm after now is to see whether I can replicate wakestate-dependant boot issues or not. The actual doubleST function I consider to have been validated on my previous STF build.

/Troed

[troed]

Something like this. Would sit right on top of the jumper row, so female header downwards for JP6-JP12 and pin header upward for DTACK, PWR, mode switches (S0/S1) etc.

(post updated with "final" PCB. Doing some visual sanity checks now then sending away for production)

Screenshot from 2020-08-05 16-46-05.png

Assumptions:

• "8 MHz system bus" is GLUE
• EXP_CLK is the "CPU clock pin" on the 68000 sockets

I've connected my GLUE clock output to this system bus and expansion clock. I've connected CPU clock (intended to be 16MHz then) and Blitter clock.

jumpers.png

[exxos]

Looking good :thumbup:

[troed]

Looking good :thumbup:

Thanks! As you know, making hardware is still quite new to me ;) Post updated with final PCB and my assumptions about what the jumpered clocks are. Will soon go and measure to make sure my assumptions are correct :P

/Troed

[DoG]

Do you remove the osc from MB and put it on your board and add a 64Mhz as well?