CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[exxos]

Not much progress today as only just got home.

Still confused why TOS206 refuses to work at 50MHz. Its not even setting 50hz on boot, so its not even trying to start up. Oddly, at random points TOS206 did boot and even ran GB6. Then next reset, nothing again. So its like its not getting the start address in ROM for some reason. But again, it works at 40MHz, and TOS104 works at 50MHz.

Tomorrow I will try route BERR via PLD so I can see if it removes the I7 error I see with diagnostics cartridge. I think when CPU runs 50MHz, it sees BERR, completes bus cycle, but then GLUE still has BERR active, so CPU "sees" BERR again and repeats the cycle which is now invalid.

I am hoping if I can fix the BERR issue, then maybe TOS206 will start to behave better. Though it doesn't make much sense why TOS206 doesn't even try to boot a lot of the time.

Oddly as well, I have been seeing the whole address and databus including /AS & /DTACK seem to be "stuck" in a loop. Its like all signals are running a squarewave which never changes in duration. Like the CPU is reading address zero, and its telling the CPU to jump to address zero kind of thing, so its stuck in a loop. hard to actually diagnose without a LA hooked up, but thats the thought there anyway.

I'm also sending a PCB to holger. He has debug tools, but for xlinix stuff, but he will write his own code which shouldn't take him to long as its almost the same as 020 code. Then at least if he runs into same problems, then at least I have someone who knows what the hell I am talking about so we can work to fixing the issues together..

[PaulJ]

Exxos your your first issue is real similar to the Chinese 6809 chips I tried to use in years past. The thing would boot fine and run fine once in a great while. I would hit the reset and nothing.. and it would remain in that state for a day no matter what I did, then out of the blue it would successfully boot and run fine until re-power or reboot. Went back to chips that were made at a reputable fab facility and no issue. Its enough to make ya crazy. Maybe debug with a know good chip getting everything to run solid and then plug in Chinese chips until one works every time.

[exxos]

Its possible the CPU's might be iffy, though at 8MHz they all work fine. They even work fine at 40MHz. Its possible 50MHz can't work stable, as they are indeed being overclocked. Though they do work at 50MHz with TOS104, just not TOS206. So I think its timing problems with the ST rather than the CPU itself.

Normally these type of screwy faults are because of more than 1 problems. So it causes conflicting information making it hard to figure out. So I will try and solve the bug I know is there with BERR and see what happens.

[exxos]

This wasn't fun..

Unsoldered and bent up 2 PLD pins so I could solder some wires on to route BERR via the PLD..

Note to self - add aux IO pads next time!!

wb2.JPG (78.02 KiB) Viewed 3979 times

[exxos]

I now have BERR routed via the PLD. First power up, everything was same as before as expected. I added in some BERR delays.. and no boot at all... I removed the delays.. nope still no boot.. put back (with berr edits) my previous 8MHz test code.. nope.. so something has died which is fraking typical

So looks like I will have to build up another board. Though if I am going to have to do that, I will get the revised board made with the BERR line routed via the PLD. So this means I am going to have to wait at least 2 weeks before I can get back to testing stuff again

[ijor]

I think when CPU runs 50MHz, it sees BERR, completes bus cycle, but then GLUE still has BERR active, so CPU "sees" BERR again and repeats the cycle which is now invalid.

I'm not sure something like this could happen without something else intervening.

BERR is deasserted asynchronously by GLUE as soon as AS is deasserted. It is open drain, so it will be a little slow depending on the pullup. And running at 50MHz, the CPU would probably see BERR deasserted a few cycles later. But this shouldn't be fatal. By design the CPU won't start a new cycle while BERR is still asserted. Even internal micro cycles are stopped.

A late DTACK might be more problematic as well as BERR combined with DTACK and/or HALT.

This is all assuming the SEC behaves identical in all aspects as the "standard" 68K, which might be not. You might try a stronger pullup on the BERR signal, but it might draw too much current? It is also possible that since you are overclocking the CPU, you might need to synchronize the signals better. Really difficult to know what's going on without a LA.

[exxos]

Whats confusing me is the diagnostic cart is saying buss error isn't detected at 50MHz. But when its running 8MHz its all fine. So something is tripping up relating to BERR.

Its like GLUE issues BERR, but the CPU doesn't see it, but that can't happen as it works at 8MHz. So rather than the CPU not seeing BERR, something else is stripping up causing the appearance of it not working. I am/was also assuming BERR stays active for a enture CLK8 cycle before deaserted and the CPU running faster is re-reading BERR causing the issue. Though its also possible it could be seeing DTACK when its not supposed to be causing the issue.

I am pretty much guessing at this as no idea what its acting like that. The only way forward is to route BERR into my PLD so I can control the timings better with it.

EDIT:

So I scoped out BERR on a previous SEC board, and GLUE doesn't seem to be issuing BERR.. The only possible way is if the CPU saw DTACK and terminated the cycle before GLUE had chance to issue BERR

[exxos]

I went back to my working 8MHz code and isolated /AS to GLUE during ROM access and used the PLD to decode ROM and issues DTACK. Thing is, the BERR thing is back!!

I can only assume that GLUE doesn't like /AS being isolated, and/or GLUE is testing BERR in a ROM location which is being terminated by my DTACK control

So I put back allowing GLUE to see all /AS activity, but still allowing the PLD to decode ROM and issue DTACK... and it still failed to see BERR. So I think my code is issuing DTACK when the CPU should be waiting for BERR from GLUE

I really need to know what address the diagnostic cartridge is decoding at...

[ijor]

I am/was also assuming BERR stays active for a enture CLK8 cycle before deaserted and the CPU running faster is re-reading BERR causing the issue.

No. As said, BERR is deasserted asynchronously with AS. But the output is open drain, so the raising edge is slow. But again, the CPU will wait for BERR to clear anyway.

So I scoped out BERR on a previous SEC board, and GLUE doesn't seem to be issuing BERR.. The only possible way is if the CPU saw DTACK and terminated the cycle before GLUE had chance to issue BERR

Might be DTACK, but could also be VPA.

I really need to know what address the diagnostic cartridge is decoding at...

I'm not very familiar with the diagnostic cart. It should be possible to check this under emulation. But I understand there are several versions of the diag cart. And it might also attempt to issue a bus error on multiple addresses.

[exxos]

Might be DTACK, but could also be VPA.

I disabled VPA totally, cartridge went a bit nuts, but the bus error was still there, so must be DTACK related.