officer960's H5 C1 build

[exxos]

It is just the syncscroll and related sync effects which are breaking. That looks like a misaligned CPU clock.

The cpu clock may be like 10ns delayed even on the 8mhz clock just down to PLD delays.

If that's enough to break syncscroll stuff then that sucks. It's probably not fixable in that case @officer960 . Timing sensitive stuff is a given things will break when something changes. You generally have no choice but to use a stock machine for such demos. IIRC such things don't always work on stock machines either, depending on what waitstates the system powers up with.

You could carefully bend the booster CPU clock pin out of the booster socket and solder a wire to a 68k socket clock to feed 8mhz to the CPU directly. It would prove the CPU clock is the issue or not.

But even so, IIRC there's some slight timing differences with bus grant logic as well. It's unavoidable also as you have to route signals via the PLD as part of the booster logic.

Should be fixable by adding some buffers or other delays on the clock arriving from the shifter, to get it realigned.

You mean the 16mhz? That's not even used in 8mhz mode. The cpu is driven from the system 8mhz, but delayed slightly via the PLD. I wouldn't have thought that would be enough to break things, but it seems so.

[dml]

The cpu is driven from the system 8mhz, but delayed slightly via the PLD. I wouldn't have thought that would be enough to break things, but it seems so.

Ok so its the system 8mhz clock getting slightly delayed then. Yep - is probably adding a permanent, unexpected wakestate to the system, which is enough to break the syncscroll things which already know about some 'normal' builtin wakestates - but not this new one which must be different.

Its probably still fixable by artificial delay - but seems like it would need almost a whole 8mhz cycle delay to get the normal alignment back? Not sure what that would involve. How many 74xx buffers is that? :)

[exxos]

Its probably still fixable by artificial delay - but seems like it would need almost a whole 8mhz cycle delay to get the normal alignment back? Not sure what that would involve. How many 74xx buffers is that? :)

Such a thing already exists because of DMA issues on the STE booster..

viewtopic.php?p=108061#p108061

viewtopic.php?p=114633#p114633

https://exxosforum.co.uk/atari/last/V1STE/index.htm#DMA

But such things need a lot of trial and error.. And of course time.. Though I discontinued the booster some time ago. Like most things, just not enough demand to keep working on the projects. Plus again lack of time to work on multiple projects all the time..

EDIT:
It could be tried I suppose on the STFM version but it be a bit of a hack job in wiring it up. Probably not really worth all the hassle.

[officer960]

OK - so bearing in mind that I can solder but my understanding of the technical side of how things work together is elementary at best... can you briefly and in layman's terms explain:

1. Is this a chipset issue i.e. my particular GLUE/MMU, DMA chip are probably to blame or is this an issue with the Exxos booster? Seriously no offense meant Chris please don't take that as me complaining - I do understand the ST has noisy bus and many many issues due to all the revisions and patches Atari did to hack these things to run back in the day.

EDIT: This is an IMP chipset - would a non-IMP GLUE/MMU/Shifter possibly resolve timing issues?

2. My old school accelerators (HBS240 and AdSpeed) will work/will not work correctly in this machine?

Frankly, if most things are working with no acceleration at 8MHz maybe I should just accept that the ST isn't an Amiga where any half ass accelerator running 68000-68060 with extra fast RAM, Map ROM, IDE etc. is virtually plug and play. When Atari engineers designed the ST in three months to be as cheap as humanly possible with no foresight to expandability, what could possibly go wrong? :lol:

[exxos]

I'm not the best to explain it entirely but different chips have different wake up states which means the timing what they have is basically random. It is possible for example WS1 and WS4 don't work well because the booster changes the timings just enough to break stuff. WS2 is most common and more forgiving of timings I think. WS3 is rare but likely also ok. There was a wait state detection program somewhere which may give some clues.

The problem is different chipsets have different timings and all the over scan screen and sync scrolling is basically exploiting hardware bugs in the chipset. It's very timing sensitive and a lot of stuff can break very easily. Things are a bit more mature these days with more modern coding to detect the wait states more accurately with all the stuff like spectrum 512 suffered more from this type of problem

If you look at the original Spectrum 512 manual, it does say somewhere if the screen is garbled then turn the machine off for a few seconds and turn it back on again as this changes the wait state and often things will start working again. Similar problem that the chips themselves can change timing as well as the boost to change timing.

As to what's ultimately to blame, the demo coders for exploiting unreliable bugs in the hardware in the first place ;)

But these type of problems are why we are doing the FPGA chipset replacements so we can just fix everything and then work on higher speeds. So then weird bugs and accelerators are not even needed then.

WS detect.
download/file.php?id=10089

[officer960]

This is an IMP chipset - would a non-IMP GLUE/MMU/Shifter possibly resolve timing issues? Guess it's going to come down to testing these (and possibly other) chips with that wake up state software you mentioned. I can possibly scrounge together some non-IMP chips but I don't know how much farming of working old boards I want to do. If I can obtain some non-working boards maybe worth a shot but that introduces a whole other set of potential problems as the chips I'd be farming could very well be bad.

I know you (and others) are working on FPGA implementations of some of the chips. Maybe that can someday resolve some of these 40 year old issues. I know my MiST/MiSTer basically runs everything - I just have a thing for the real hardware.

[officer960]

Think I figured out how to use that software by Troed/SYNC. Get your phone ready to record the result because it flashes the result on the screen for less than a second.

1. Copy the contents of the zip to a floppy/.st Gotek image
2. Run WSDWRITE.TOS which will write info to the boot sector of the floppy
3. Start recording the screen
4. Reboot the machine with the floppy inserted
5. Review video and get the info

IMG_2018.jpeg

[exxos]

Thanks.. WS3 I'm not even sure I have seen before.. Would have thought it would be OK.. but maybe not then..

You could change the main ST chips one at a time to see if the WS changes and see if it fixes your problem..

[officer960]

I just checked my H5C5B and it's the same as the H5C1 (WS3). It's also mostly IMP chips.

The H5C5B has an AdSpeed. I ran Enchanted Land, and when set to 8MHz the intro (the scene with the water drops run down the screen with Thalion logo) is color correct/synced as are the subsequent "demo" screens, but when the game is started it has the glitch where the right quarter of the screen is shifted over to the left side. Very weird. I'm guessing something about the AdSpeed (probably has buffers to account for chipset variances?) makes timing closer.

Anyway, I will probably try to swap some chips and see what I can accomplish but it may be a while before I can source GLUE/MMU/Shifter/DMA from boards that I don't actually care to preserve. I think buying these chips on eBay to test would be an expensive fool's errand.

[exxos]

I'm not familiar with adspeed but the chip timings were only really figured out in recent years anyway. It may be like 1ns different on the clock, that's all it takes.

The wrap around pixel problem can happen when clocks are slightly out of sync, I have seen that before when I tried to buffer the glue clock I had the same issue and it's documented somewhere.

I have chips in my store but not cheap either unfortunately.

If you wanted to gamble "cheaply" you could hack on the STE sync board and see if it improves your luck. I cannot guarantee results because it would literally be an experiment. But that shaves off about ten nanoseconds off the clock timing, which may be enough.