CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
User avatar
Cyprian
Posts: 387
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by Cyprian »

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/
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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 ?

1.jpg
1.jpg (65.4 KiB) Viewed 3759 times

So I think something else is using the bus, which isn't a bus master...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

:WTF:

EMUTOS now gives a new error...

2.jpg
2.jpg (54.83 KiB) Viewed 3746 times
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by rpineau »

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.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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...

2f3c1e46bffa1c027bbdee9aa84c6552.png
2f3c1e46bffa1c027bbdee9aa84c6552.png (83.4 KiB) Viewed 3703 times
183a27410e79ea47d49d053a486fdc6d.png
183a27410e79ea47d49d053a486fdc6d.png (51.25 KiB) Viewed 3703 times
ad829df8b49f593bdff3626239150b06.png
ad829df8b49f593bdff3626239150b06.png (102.62 KiB) Viewed 3703 times
b088766c76da6d46764be7c8265044c5.png
b088766c76da6d46764be7c8265044c5.png (82.86 KiB) Viewed 3703 times

Will do a bit of tidying up and likely send it off to fab tomorrow...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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!
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
PhilC
Moderator
Moderator
Posts: 6014
Joined: Fri Mar 23, 2018 8:22 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by PhilC »

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?
If it ain't broke, test it to Destruction.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “SEC 64MHZ BOOSTER”