exxos's Atari, Amiga & retro forum

BlankVector wrote: ↑Wed Jan 09, 2019 10:38 pm I have just tested the very same setup with Hatari and it works fine.
It also worked fine on my real STe (TOS 1.62 + EMUTOSFR.PRG)

There is a similar error message in the latest Steem SSE.
EmuTOS shows only "Panic: Bus Error" message:
https://sourceforge.net/p/steemsse/foru ... d020b9da4/

BlankVector wrote: ↑Wed Jan 09, 2019 11:22 pm Does this mean that your hardware doesn't trigger proper Bus Error when expected? That matters for EmuTOS, because it uses Bus Error much to detect optional hardware (Blitter, TT & Falcon hardware, etc.).

GLUE isn't issuing BERR, no idea why. A stock CPU works fine... But I don't know how a booster could effect GLUE generating BERR.. Unless it tests some address which for some reason generates DTACK..

BlankVector wrote: ↑Wed Jan 09, 2019 11:22 pm BTW, on all your pictures, I see that SR=$27xx, which means that interrupts are masked.

Hmm.. What does that mean exactly ?

BlankVector wrote: ↑Wed Jan 09, 2019 11:22 pm And the PC value is surprising low, this is why I suspect a bad jump to low memory.

Possible.. There is some odd address error going on somewhere as TOS206 can't start up. BUT TOS206 can start up in 8MHz mode with the booster.

BlankVector wrote: ↑Wed Jan 09, 2019 11:22 pm Now I need to sleep a bit. Maybe new ideas will come during the night.

Same here... I'm out of ideas for this really now.

I think there is some odd bus conflict causing wrong address somewhere, but don't know where. Unless something on the DMA side is causing A1 to become corrupted on the CPU bus.. But As CPU is not bus master at that time, then shouldn't matter of anything CPU is doing.

I even waited up to 6X CLK8 cycles after BGACK goes high before releasing BR.. Giving DMA lots of time to finish using the bus. But nothing I try makes any difference.

I need a sanity check here...

If I isolate ST_AS like this...

ST_AS.OE = ST_BGACK;

Of course it works... BUT... When something is in control of the bus other than the CPU, it has to request the bus, as such, the CPU enters tristate and all signals are isolated.. So if thats the case, why doesn't removing .OE from ST_AS work ?


So I think something else is using the bus, which isn't a bus master...

EMUTOS now gives a new error...

AS on the CPU will go to Z, but not your ST_AS as it's an output of the CPLD unless you tell it to set it to Z ... by using ST_AS.OE
SEC CPU AS -> CPLD -> ST_AS
CPU_AS = Z -> CPLD -> ST_AS is either 0 or 1 depending on internal pull-up config and how the CPLD behave when a signal is driven by an input that goes tri-state.

rpineau wrote: ↑Thu Jan 10, 2019 6:56 pm AS on the CPU will go to Z, but not your ST_AS as it's an output of the CPLD unless you tell it to set it to Z ... by using ST_AS.OE
SEC CPU AS -> CPLD -> ST_AS
CPU_AS = Z -> CPLD -> ST_AS is either 0 or 1 depending on internal pull-up config and how the CPLD behave when a signal is driven by an input that goes tri-state.

Ah yes of course, ST_AS is going via PLD.. so outside of CPU going trisate..

Been trying most of today again to get to the bottom of these issues and not getting anywhere. I need to try switching the CPU into 8MHz during BGACK as that is what I do on the STE boosters... Then if the SEC booster works, then I know where the problem is..

I think this is more final V2 now...


Will do a bit of tidying up and likely send it off to fab tomorrow...

PCBs ordered They been manufactured already and awaiting courier pickup

I was reading though some suska code for the GLUE. There seems to be a lot of "chaos" over bus request timings in there. Seems its relating to syncing to DTACK with the MMU because of RAM interleaving.. This would actually seem to make sense as when I use GLUE decoding and GLUE DTACK, Things seem to work fine, well for 8MHz anyway. Even TOS206 behaves. Oddly though, GLUE doesn't drive DTACK of course for 206, but it seems to still work fine. So its possible /AS is being monitored as well by GLUE and/or MMU. Its not just relating to BGACK if something is using the bus or not.

It makes me wonder if GLUE's "slow" DTACK control is by design. Problem has always been that GLUE sets DTACK low pretty much at the same time /AS goes low. This isn't a problem for the CPU normally as it doesn't see DTACK until much later. BUT, GLUE also keeps DTACK low right up until the next bus cycle in S2. So DTACK is still low right up until the point the CPU sets /AS low again. Which means its low a LOT longer than its supposed to be. But now I am thinking this is deliberate. In that DTACK is kept low for some other reason, like mentioned in the suska code relating to RAM interleaving.

This would make sense as well why I have to switch to 8MHz on BR also. As if the CPU is accessing ROM, it would slow to 8MHz and decode ROM at 8MHz (not 50MHz) Then all the bus grant stuff is timed as per 8MHz. I don't think its just relating to bus grant timings, I have tried 100's of variations and methods relating to it all. So I think DTACK has to be kept low to mimic the GLUE timings when its about to do do a DMA cycle.

Delaying any signals doesn't do a darn thing. So even trying to mimic the timings of 8MHz simply doesn't work. Problem being I can't drive DTACK ST-side from my current board design (I can in the new one). So I need to prove this idea next. Failing that, I will switch to 8MHz mode during DMA stuff like I do on the STE booster. So either way, the problem *should* get fixed.

EDIT:

Another oddity I ran into a few times on boot up, is the screen is white border and black screen, but with a few random corruption lines running across the screen. BUT, the machine does boot up as I can hear the floppy drive loading GB6 up!

Isn't the black screen thing memory related?

So even if you have to switch to 8mhz more frequently, there us still going to be a large increase in speed. Might be worth trying it the STe way and then see if you can improve on things after you've got the basics working?

The STE booster is pretty much the same design as this SEC booster. Only the sec needs a bit more work. The STE booster switches to 8mhz during DMA stuff. But its also a more forgiving design so its easier to get running than the STFM. Also the STE booster uses the STEs ROM decoding so its basically "bypassing" some issues that the stfm has as of course it doesnt decode tos 206 space.

I think the odd screen issues is something going out of sync in terms of ram and the shifter. I'm just saying its data corruption in the bus and its the same reason ROM isn't working because of corruption on the bus.

There is "Slots" between the ram access to cpu and shifter. Dtack to the CPU is held high and the data bus is isolated so the CPU waits its turn for ram access. So I think this "switching" is going out of sync causing the issues. By the looks of it it might be using dtack as reference points to the sync itself. So when that signal is missing things start going out of sync and chaos happens. Its just my best guess as its not relating to bus masters thats for sure.