exxos's Atari, Amiga & retro forum

Are you getting bombs when it doesn't boot?

On the mega I have with the floppy problem and your old 2.2 booster it bombs on 206 but not on 104. Either 2, 4 or 11 when a disk is in. It's not related to the floppy problem again is it? And rember you had 104 altered ever so slightly for the drive and men readout.

Forgottenmyname wrote: ↑Sun Jan 06, 2019 10:41 pm Are you getting bombs when it doesn't boot?

On the mega I have with the floppy problem and your old 2.2 booster it bombs on 206 but not on 104. Either 2, 4 or 11 when a disk is in. It's not related to the floppy problem again is it? And rember you had 104 altered ever so slightly for the drive and men readout.

TOS206 will bomb when the floppy drive isn't connected... But never had any issues with the 2.2 booster and floppy..

It doesn't even try to boot with TOS102 or TOS206.. I did see a couple of ROM_CE going low with several DTACKS on my scope, so its trying.. but there should be no difference between TOS104 and TOS102 for boot up.. its just a jumper swap on the ROM board.. and the ROM board works fine without the booster, so its not the ROM board.

I guess program TOS104 twice in a new ROM and see what happens...

EDIT:

TOS104 & TOS104 both boot up.. so again its not the ROM board..

Even tried TOS162/206 out of my STE and neither of those booted.

TF suggested I try 8MHz.. actually a good point... So formatting and TOS206 boots up at 8MHz!

My only theory currently is GLUE sets BR high before setting BGACK low.. So by the time BGACK comes, BR has gone high and DMA cycle tries to start when the CPU is has not released the bus as it sees BR goes high...

I would have thought BR from GLUE wouldn't go high until GLUE sees BG going low.. where if its seen BG going low, BGACK should go low about the same time..

But if there is a "Gap" in any of the bus grant signals, then the SEC CPU will screw up as its 2 wire arb and the ST uses 3 wire arb... With the SEC CPU, you have to keep BR low the entire time... So if there is any "gap" in between BR and BGACK, then the GLUE will be trying to start a DMA cycle, when the CPU has "exited" DMA mode.. and causes a bus conflict between DMA and CPU causing these issues

Have to actually go work this morning So will try and investigate when I get home a little later.

I have been scoping out the BR,BG,BGACK lines..

YELLOW = GLUE BR
BLUE = GLUE BGACK

YELLOW = CPU BR
BLUE = GLUE BGACK


So as suspected, GLUE doesn't keep BR low. Though my PLD logic does keep CPU BR low the whole time which is how its supposed to be. So all the bus grant stuff does seem to be working as expected.

So back to trying to think what can be up with the thing again... So strange...

Been messing with this thing all day.. A while ago it started acting up big time where now it only works at all if I keep spraying the CPU with freezer spray It does seem happy at 8MHz though... I have been running at 50MHz, but dropped to 40MHz and made no odds.

So far it seems if GLUE does the ROM decoding, and I control the ROM also from the PLD, I use PLD generated DTACK, and only works with 3xCLK8 delays. If I stop the GLUE from decoding, the floppy format starts acting up again.

So something happens when GLUE is disabled, or ROM decoding is done to fast.

exxos wrote: ↑Mon Jan 07, 2019 8:17 am My only theory currently is GLUE sets BR high before setting BGACK low.. So by the time BGACK comes, BR has gone high and DMA cycle tries to start when the CPU is has not released the bus as it sees BR goes high...
I would have thought BR from GLUE wouldn't go high until GLUE sees BG going low.. where if its seen BG going low, BGACK should go low about the same time..
But if there is a "Gap" in any of the bus grant signals, then the SEC CPU will screw up as its 2 wire arb and the ST uses 3 wire arb...

GLUE doesn't deassert BR before asserting BGACK. GLUE waits for BG from CPU, one cycle later after receiving BG, it asserts BGACK, and yet one cycle and a half later it deasserts BR. That's the correct behavior and it follows Motorola specifications. The reason that BR is is not kept asserted all the time during the whole DMA transaction is to allow other parallel bus masters to request the bus.

This does break with CPU models as the SEC that doesn't have a BGACK pin. There is a note somewhere from Motorola with the extra logic required to adapt 3-wire to 2-wire bus arbitration. I don't remember if it is just an AND gate (BRout = BRin and BGACK), or if there is a delay flip flop as well. I just mention this for completeness, you might not needed if the PLD is in full control of the signals.

Edit: cycle and a half, and BR/BG typo

At some point I dropped the scope probes onto the ROM board.. long story short, I've killed A15 on the CPU No worries I thought, I got 2 other SEC boards.. neither of those work at all. So I changed the CPU on my original board, meters out OK, doesn't work either

One problem I have found is the CPU footprint seems a tiny bit smaller than the CPU which isn't helping.. its also possible as the PLD is under the CPU, heating up the CPU might have upset the PLD.

I will take another look at the other 2 boards tomorrow. Though its looking like I really need a PCB with both chips on one side of the board so I can solder them up easier. Will have to flip the bottom chip (PLD) and autoroute the hell out of it and hope it can squash into 4 layers. I also want to route a couple more pins to the CPU..

I did have TOS206 booting in 8MHz mode earlier, but I think the A15 short was causing the crashes.. I've not been able to make any progress as to why PLD ROM decoding causes the thing to go loopy. I don't get these problems with the vanilla 68000... I must have spent 50+ hours on it these past few days and I really have no idea why its acting up.

One thing which may fix the issue, is to switch to 8MHz when its accessing the bus, which is what I was doing before in the hope that solves the problem. Though as it seems to be some odd issue relating to fast-rom, I am not confident that will solve it. Its also possible the "as was" working SEC booster might have only worked due to fluke hardware tolerances. I have had it running months ago all day at 50MHz without crashing, but that was with GLUE decoding ROM. So "slow ROM" was in action there. I never thought "fast rom" would cause so much trouble with the SEC design.

All I can really lean to, is there is some odd bus conflict between ROM and DMA and the GLUE is in the middle of it all. While GLUE issues BR to the CPU, the CPU if its doing a fast-rom access, will tell the glue pretty much right away it can have the bus, and for some reason it causes the DMA to act odd. But its not just that as TOS206 fails to work at all, along with TOS102. So there seems to be multiple issues going on. I have tried delaying and re-syncing all the bus grant stuff, but I just find more and more spectacular ways to crash out doing that.

It begs the question if its even worth going with these SEC CPU's if the are going to be problematic like this. The PLCC 68000's can run almost 40MHz, while the SEC is 50MHz.. It might be time better spent abandoning the SEC series and go back to progressing with the V2.X series of booster with the normal 68000. BUT as there seems to be a GLUE issue with fast-rom, a 40MHz STFM V2.X series booster might not even work. Its actually put a huge spanner in the works

The only thing I can think of doing currently is making a DIP to PLCC 68000 adapter so I can plug the STE booster into the STFM and see what happens... saying that.. the STE booster should plug into the STF remake socket.. So I guess if that works, it would be a direction to continue in at least.

ijor wrote: ↑Tue Jan 08, 2019 12:40 am This does break with CPU models as the SEC that doesn't have a BGACK pin. There is a note somewhere from Motorola with the extra logic required to adapt 3-wire to 2-wire bus arbitration. I don't remember if it is just an AND gate (BRout = BRin and BGACK), or if there is a delay flip flop as well. I just mention this for completeness, you might not needed if the PLD is in full control of the signals.

The scope images do and show just that happening, the 3 to 2 wire arb. It actually all works fine as long as GLUE decode ROM as normal. But decode ROM in the PLD, and all hell breaks loose.

The only thing which really seems to work, is delaying DTACK by 3x CLK8 cycles. The ROM can decode in about 40ns (as it does on the STE booster) so the ROM is ready very quick.. however, something screws up which needs those 3 8MHz clock cycles.. which basically slows ROM down to stock speeds making it impossible to actually have fast-rom access

So with a fresh tired mind today, I got one of the other SEC boards working..

So the point it is at, is GLUE does ROM decoding, in parallel with the PLD. The PLD actually drives ROM_EN. GLUE still issues DTACK to the CPU. So this all acts like a stock 8MHz machine basically. TOS104 works fine that way.

So adding in DTACK to drive TOS206, it doesn't even try to boot up. So when GLUE is taken out of the mix (it won't decode TOS206 address) it goes a bit nuts.

I'm also remembering on my STE booster I HAD to drive the CPU into 8MHz on BR,BG,BGACK for it to work reliable. In which case what would likely happen is during a ROM access, the CPU would get slowed down to 8MHz because it will see BR going low.

So I guess the equivalent logic to this, is when I issue DTACK to the CPU on ROM access, if any of the bus grant lines are low (basically BR) then I need to wait 3x CLK8 cycles before I let the CPU see DTACK for that ROM access. Doesn't make much sense, but will try it.

I guess the likely issue is GLUE for some reason expects to see EXACTLY the proper timings for bus grant stuff. Even so I have added in various delays to emulate that, and any delays seem to make things worse

EDIT:

Thinking about it a bit more, the bus grant stuff shouldn't matter anyway as the CPU will run as a 68000 does at 8MHz, So shouldn't be any reason why TOS206 doesn't boot.

So I have now working TOS104 & TOS206 at 8MHz. So it seems, even if I disable GLUE during TOS206 access (which GLUE doesn't decode anyway) it refuses to boot up.. So the plot thickens... I'm going to assume GLUE thinks it can start a BR as nothing is using the bus because it never sees /AS going low.

EDIT:

So it seems that idea is on the right track... What I do now is...

ST_BG = CPU_BG # !CPU_AS ;

I actually do that in the V2.X series of booster as well

So GLUE seems to think it can do something, when it can't, basically because its not seeing /AS go low anymore.. and I have to disable GLUE and stop it from decoding ROM as its DTACK control is terrible and not fast enough for fast-rom.

So the work-around, is to simply wait for the CPU to finish with the bus, then send BusGrant to the GLUE...

So next up I need to go back to the 50MHz osc and start working on those changes again