4MB Upgrade & 16MHz Booster progress

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4337
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby DarkLord » Fri Dec 05, 2014 2:47 pm

Interesting reading here, about Fast Techs version of an '030 accelerator board:

http://www.stcarchiv.de/ace/50/fast-68030

Also, since you're going doing accelerator stuff, you might find this interesting
as well:

Fast Technology GENie conference:
fastec15.asc


Docs for the T28/36 control ACC:
HBS640(English).txt
You do not have the required permissions to view the files attached to this post.
Last edited by DarkLord on Fri Dec 05, 2014 3:06 pm, edited 1 time in total.
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4337
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby DarkLord » Fri Dec 05, 2014 2:50 pm

exxos wrote:damn, I'm sure I have got one of those exact same CPUs here somewhere, but I checked my drawers and can't see it anywhere :(

25mhz is probably possible with the DIP CPU, do you know if there was a top speed for the DIP type CPU's vs the PLCC type CPUs, like did they only make a T25 with the DIP CPU ?


Not a clue, sorry! :(

Oh, did find an old Atari Forum post where someone (Gunther Thorsten?) mentioned that the T36's used especially factory tested "stressed out" CPU's for the over-clocking to higher speeds.
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Fri Dec 05, 2014 3:47 pm

DarkLord wrote:Oh, did find an old Atari Forum post where someone (Gunther Thorsten?) mentioned that the T36's used especially factory tested "stressed out" CPU's for the over-clocking to higher speeds.


That site on your previous post mentions the blitter, sounds like they speeded that up also. Though 16mhz blitter doesn't give a huge boost in speed as ST-RAM bottlenecks it. Though I guess if there is a cache, then 16mhz blitter would be awesome.

Sounds like the CPU is hinting towards a speed problem there then. I have ordered a Toshiba DIP 16mhz CPU, I can swap it for the one in my current board to see if there is any difference there. Though I think the DIP's top speed limit is going to be more like 24mhz for the 16mhz part. Fingers crossed the PLCC will do better.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
Zogging Hell
Atari Super Hero
Atari Super Hero
Posts: 882
Joined: Sat Apr 29, 2006 12:08 pm
Location: Bristol, UK
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby Zogging Hell » Fri Dec 05, 2014 4:29 pm

This article in Atari Explorer suggests the T28/36 sports 64kb of cache.

http://www.atariarchives.org/cfn/12/05/03/0486.php
Firebee, Falcon CT60, Milan 040, Falcon MkI, TT, Mega STe, Mega ST + Lots of STs of various flavours

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Fri Dec 05, 2014 5:07 pm

Zogging Hell wrote:This article in Atari Explorer suggests the T28/36 sports 64kb of cache.

http://www.atariarchives.org/cfn/12/05/03/0486.php



Yeah it looks that way. Cache isn't a easy thing to add unfortunately. Its why ultimately I want to speed up ST RAM instead. We really need a new version of the MMU, but can use SRAM instead. Though I have double clocked the entire motherboard using 70ns DRAM so its doable that way, but same old problems with DMA, Shifter etc, but I hope to investigate that at some point next year.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: 4MB Upgrade & 16MHz Booster progress

Postby SteveBagley » Fri Dec 05, 2014 5:36 pm

exxos wrote:Yeah it looks that way. Cache isn't a easy thing to add unfortunately. Its why ultimately I want to speed up ST RAM instead. We really need a new version of the MMU, but can use SRAM instead.


I'm interested in the reasons why you consider cache hard to add, because I'd have thought it somewhat simpler to implement than reengineering the MMU, especially since the GAL code and circuit diagram for the MegaSTE's cache is available.

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Fri Dec 05, 2014 5:40 pm

For one you need TAG RAM which seems hard to find, but even so, the code involved for cache hits and misses looks pretty complex. Where did you find the GAL code ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: 4MB Upgrade & 16MHz Booster progress

Postby SteveBagley » Sat Dec 06, 2014 9:02 pm

exxos wrote:For one you need TAG RAM which seems hard to find, but even so, the code involved for cache hits and misses looks pretty complex. Where did you find the GAL code ?


They were on the Atari HQ iso that is floating about the net (hiding under /Documents/Atari/TECHDOCS/MSTE/PALS -- along with all sorts of other goodies, including what looks like schematics for the microbox) although looking at them they don't seem to contain the definition for every PAL…

I guess you could recreate the TAG RAM by using a normal SRAM package and then use 16 XOR gates to compare the output and synthesize the MATCH that way.

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Sat Dec 06, 2014 10:03 pm

SteveBagley wrote:
exxos wrote:For one you need TAG RAM which seems hard to find, but even so, the code involved for cache hits and misses looks pretty complex. Where did you find the GAL code ?


They were on the Atari HQ iso that is floating about the net (hiding under /Documents/Atari/TECHDOCS/MSTE/PALS -- along with all sorts of other goodies, including what looks like schematics for the microbox) although looking at them they don't seem to contain the definition for every PAL…

I guess you could recreate the TAG RAM by using a normal SRAM package and then use 16 XOR gates to compare the output and synthesize the MATCH that way.

Steve


Seems the link is broken :(
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Sun Dec 07, 2014 11:40 am

Rodolphe found a bug in the PAL code...

Code: Select all

CAV   =   A23 * A22 * /A21 + A23 * A21 * A20 + A32 * /A22 * A21


Wondering if that error went into production machines ??

Thanks for people who reporting back tome that their boosters are working :) I am wondering if I setup a new section on my site, if people would like post images of their upgraded machines there ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: 4MB Upgrade & 16MHz Booster progress

Postby SteveBagley » Sun Dec 07, 2014 1:59 pm

exxos wrote:Rodolphe found a bug in the PAL code...

Code: Select all

CAV   =   A23 * A22 * /A21 + A23 * A21 * A20 + A32 * /A22 * A21


Wondering if that error went into production machines ??

Thanks for people who reporting back tome that their boosters are working :) I am wondering if I setup a new section on my site, if people would like post images of their upgraded machines there ?


Yea I spotted that last night…

I suspect these are work in progress versions because I saw a few other typos (I doubt it would compile since there is no A32 pin defined for that chip :-))

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Sun Dec 07, 2014 2:16 pm

SteveBagley wrote:
Yea I spotted that last night…

I suspect these are work in progress versions because I saw a few other typos (I doubt it would compile since there is no A32 pin defined for that chip :-))

Steve


Yeah, probably wasn't final versions, at least I hope not ;)

Though I am wondering about just replacing something like 128K-1024K of ST ram with Sram instead. Cache is ok, but its only normally 8K-64K and of course only mirror some address in STram. Though if the bulk of STram, is replaced with Sram, then it shouldn't get in the way of the Shifter, or DMA access etc. It really would/should act like 896k cache. only no problems with "hit or miss". Of course need to get thinking about all this.

My initial idea was that most machines have 512K ram, but direct 512K-1024K to Sram instead, just bypass MMU. I don't know if it would work, but its same idea what we did to bypass GLUE decoding ROM to our own decoding logic. So the idea to replace STram with Sram , at least in part, is doable, though have to be careful about other bus devices accessing STRAM, such as Video, DAM, blitter etc. Of course this always would assume video is located in first first 128K section of STRAM, that part would work as normal with video. But If blitter tried to access anything outside of the 128K STram then it would cause a bus error. AFAIK DMA is high up in the memory map and just uses single registers there. Might be possible to remap DMA to Sram instead of STram I have no idea.

Though the speed gains would be huge, STram would run (mostly) at 200% speed at 16mhz. Plus the CPU speed would increase as it is spending less time waiting for STram via MMU. Of course things always look easy in my head at first ;)
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: 4MB Upgrade & 16MHz Booster progress

Postby SteveBagley » Sun Dec 07, 2014 4:58 pm

exxos wrote:
SteveBagley wrote:
Yea I spotted that last night…

I suspect these are work in progress versions because I saw a few other typos (I doubt it would compile since there is no A32 pin defined for that chip :-))

Steve


Yeah, probably wasn't final versions, at least I hope not ;)

Though I am wondering about just replacing something like 128K-1024K of ST ram with Sram instead. Cache is ok, but its only normally 8K-64K and of course only mirror some address in STram. Though if the bulk of STram, is replaced with Sram, then it shouldn't get in the way of the Shifter, or DMA access etc. It really would/should act like 896k cache. only no problems with "hit or miss". Of course need to get thinking about all this.

My initial idea was that most machines have 512K ram, but direct 512K-1024K to Sram instead, just bypass MMU. I don't know if it would work, but its same idea what we did to bypass GLUE decoding ROM to our own decoding logic. So the idea to replace STram with Sram , at least in part, is doable, though have to be careful about other bus devices accessing STRAM, such as Video, DAM, blitter etc. Of course this always would assume video is located in first first 128K section of STRAM, that part would work as normal with video. But If blitter tried to access anything outside of the 128K STram then it would cause a bus error. AFAIK DMA is high up in the memory map and just uses single registers there. Might be possible to remap DMA to Sram instead of STram I have no idea.

Though the speed gains would be huge, STram would run (mostly) at 200% speed at 16mhz. Plus the CPU speed would increase as it is spending less time waiting for STram via MMU. Of course things always look easy in my head at first ;)


I think this is likely to fail very badly since you wouldn't be able to stop TOS and/or programs putting the screen into SRAM over ST RAM, unless you treat it as ALT-RAM (at which point you may as well locate it well past the 4MB limit of STRam), or doing DMA transfers into ST RAM (the MMU wouldn't be able to address your SRAM so the CPU wouldn't see the new data -- remember that the MMU chip handles DMA as much as the DMA chip in the ST design, the DMA chip is only responsible for converting 16bit words into 8bit sequences, all the address generation is actually handled by the MMU).

I'm not entirely sure how the MegaSTE gets around the DMA issue (the Shifter is a non-issue with cache because writes always hit ST RAM, and the shifter can't modify memory) but my best guess is (from reading the schematic, TAG RAM datasheets and PAL code) is that it uses the BGACK signal to invalidate the whole cache by asserting the reset pin on the TAG ram.

Short of reimplementing the whole MMU, ALT-RAM and/or cache is probably the simpler option once you get your head around the principles behind a cache, which isn't exactly straightforward. It's interesting that the MegaSTE even had to replace some of the MCU functionality (such as generating the VPA signal) to get it to work correctly (but I'm not sure why!).

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Sun Dec 07, 2014 10:03 pm

Yeah, its seeming like a bad idea to re-map STram :( Though I already tried double clocking the MMU a couple years ago, which works with 70ns DRAM. So I just need to build on those tests. Really just need to double clock CPU & MMU when RAM is accessed from the CPU only. There is a /RAM line which I assume GLUE sets MMU mode to talk to CPU. Thats the only hope in using the /RAM line as a 16/32mhz MMU clock switch. Then when GLUE issue Shifter, or DMA request MMU time, The MMU will still run at default speeds.

If the /RAM line isn't just for RAM <> CPU time, then not sure how else to determine if the CPU is talking to RAM or something else on the bus. Though how it looks, the GLUE is mostly telling the MMU whats going on, so hopefully that will be a good starting point.

With the current booster basically finished by design now, starting to work on something like cache will really put delays on getting this project completed. I put a "spanner in the works" already with experimenting with 32mhz speeds which is further complicating the design.

I'd really like to find out how upgrades like the T36 etc actually sync the clocks. We have a simple switch over, so no delays and perfect timeings, but its limited to 8,16,32mhz speeds. I have experimented with fipflops which can work really well to sync clocks, but those always take a few cycles to work. Jumping from 32mhz to 36mhz becomes a little pointless if I have to waste a few cycles in re-syncing the clocks.

There seems to be some clue about running some pins from the CPU via GAL logic to sync the clocks. But the guy I was talking to last year can't remember what lines or what he did at all. The only other possible solution would be to simple stall the CPU clock and hold it LO until the next clock cycle does a full cycle, though that is basically what the flip flops do, only if you switch with flipflops, and want to switch from 16mhz to 8mhz, then the flipflop will switch a few more 16mhz cycles before it switches to 8mhz again, so it won't work. The only way to instantly change the clock speeds is to have them in sync to start with.

Id really like to figure that sync problem out, this way it would be far easier for debugging if I can set the speeds manually form say 16mhz to 40mhz. Though it does not seem so simple.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: 4MB Upgrade & 16MHz Booster progress

Postby mc6809e » Mon Dec 08, 2014 8:49 pm

Forgive my ignorance here, but can you tell me what it is that prevents you from simply running the 68K at 16MHz nearly all the time (except during I/O possibly) and simply letting *AS and *DTACK control the transfers asynchronously?

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Mon Dec 08, 2014 9:25 pm

mc6809e wrote:Forgive my ignorance here, but can you tell me what it is that prevents you from simply running the 68K at 16MHz nearly all the time (except during I/O possibly) and simply letting *AS and *DTACK control the transfers asynchronously?


That is exactly what the V1 Booster does ;) Problem is when using unrelated clocks, even if you swap 16mhz line for a external 16mhz clock, it totally screws things up.

I am tweaking the V1 logic to work with unrelated clocks, its not perfect, but the glitches always happen lower than the top frequency used. So if anything the glitches will actually add a tiny speed boost to things, now that's what I call a good cock-up ;)
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

rpineau
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby rpineau » Mon Dec 08, 2014 10:23 pm

I think mc6809e is more asking if the clock could be always running at 16MHz and have the CPU just wait for DTACK (inserting wait state).
We tried and as far as I remember this was not working. I too though it should work and that the CPU would wait but we saw bus error and what not happening. This is may be because we never got back to 8MHz when talking to the ACIA and other thing that use the E clock and when the CPU is at 16MHz the E clock is at 1.6MHz which is to high for standard ACIA (you need 2MHz version like on the Falcon). The MFP has its own clock so that shouldn't be an issue (4MHz). Same thing for the PSG (2MHz).
So may be we could indeed try to keep the CPU at 16MHz on all access and wait for wait state and just get back down to 8Mhz when accessing the ACIA.
The issue is that it's harder to run everything at 16MHz and figuring out what doesn't work then starting with what works at 16MHz and slowly adding other things.
Now that on the new card we're using a bigger CPLD in which we route the whole address bus we can do more address range decoding and use internal signals (aka buried nodes) to try things like that.

Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Mon Dec 08, 2014 10:43 pm

It is also still assumed that anything else on the bus can react to a fast /AS & DTACK times. As CPU clocked at double speed, time /AS will be halved. At 32mhz, time half again. Possible /AS would only be low for 100ns instead of more like 500ns. Slow chips on 8mhz may "miss" /AS going low all together. A single 8mhz clock cycle is 123ns.

The only other thing to try was to drive the CPU at 16mhz during CPU read cycles from the bus. The CPU could pick up data from the bus a fraction faster *maybe*. But have to be careful about DTACK there also maybe. If CPU drive DTACK to fast, the other chips on the bus may simple miss the signal. We don't know all the delays and timing requirements for every chip on the bus.

Also when I first tried blitter (and when GadgetUK tried it) The blitter did not like being run at 8mhz while the CPU was at 16mhz. It did not work. It worked for GadgetUK when blitter clock was linked to CPU clock (16mhz) . When both ran at 16mhz it was fine. So now we have a evolution of this in the new CPLD logic to switch CPU and blitter to 16mhz. OR if blitter does not work at 16mhz, the CPU slows to 8mhz when talking to the blitter.

Of course if someone has time to investigate all this then why not :) Like Rodolphe mentioned, we are start off with 8mhz ST bus access, then working though things one by one to see if we can gain anymore speed, like the ACIA circuit. If we can push that to double speed, then the CPU finish the cycles faster and CPU gets a head start on the next instruction.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: 4MB Upgrade & 16MHz Booster progress

Postby mc6809e » Mon Dec 08, 2014 11:35 pm

Interesting. *DTACK should completely control the progress of the cycle. Any read or write should have wait states inserted as long as *DTACK is delayed. The CPU will stretch *AS accordingly.

I wonder if there's something in the logic that's asserting *DTACK too early.

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby exxos » Mon Dec 08, 2014 11:55 pm

If DTACK comes late then the CPU will wait for it, that was the problem we had with TOS running slow as DTACK was a cycle late. If CPU expect DTACK on S4, then this would be S8 at 16mhz. Where the CPU would wait for it. That isn't a problem. There are more signals at work than just DTACK though. If it was easy to run the CPU at 16mhz all the time then I am sure it would have been done by now. If it was just the E signal on the CPU, it would be easy enough to change the ACIA or slow the E clock down. I can easily get some faster ACIA to rule that problem out, but I can't see it being that simple. The blitter did not like a 8/16 clash, and you can't run the CPU at 16mhz constantly even without a blitter. There is too many unknowns for all of this. This is why we are going to look into each thing one at a time on a default 8mhz bus, its easier to see what single thing broke than trying to diagnose every chip on the motherboard at once.

Though how things stand now, I think the main priority is to see what the top clock speed is for this board. The board is basically completed, its just waiting on my new CPUs to come so I can do faster clock speed tests. Once this is completed I plan to take a look at STram overclocking. But this in itself is taking up much time. Code changes can be done like rodolphe mentioned at a later date. Though I really want to get this project wrapped up as its taking a lot longer than I had planned :roll:
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

ctirad
Captain Atari
Captain Atari
Posts: 278
Joined: Sun Jul 15, 2012 9:44 pm

Re: 4MB Upgrade & 16MHz Booster progress

Postby ctirad » Tue Dec 09, 2014 8:39 am

I think the mc6809e qustions are perfectly valid. The 68000 BUS is asynchronous and thus CPU should allways wait for the DTACK signal. Also I hink the clock E should be allways divided to the correct value identical to the 8MHz device.

BTW, did you looked in the PAK68/3 schematics? The PAK is clocked asynchronously to the ST clock and there is an additional card called Pupla http://www.wrsonline.de/pupla.html that manages some additional clock syncing and singnal caching. I'm not sure the GAL listing is publicky available, but there are some technical info on the page above.

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: 4MB Upgrade & 16MHz Booster progress

Postby SteveBagley » Tue Dec 09, 2014 9:38 am

ctirad wrote:I think the mc6809e qustions are perfectly valid. The 68000 BUS is asynchronous and thus CPU should allways wait for the DTACK signal. Also I hink the clock E should be allways divided to the correct value identical to the 8MHz device.


It's not DTACK per se that is the problem, but AS. Having read the relevant pages of the 68000 user manual, I think the problem is likely to be that the CPU responds (correctly) to DTACK going low, by moving into S7 and taking AS high. I think it then probably tries to start the next bus cycle and takes AS low again -- if this happens too soon it is quite possible that the ST never sees AS go high so keeps DTACK low (the manual suggests that it should take DTACK high when AS goes high). It's also possible that the ST is using a synchronous design and so expects DTACK to be low for n cycles?

The E clock stuff is definitely a problem as well… As will the read-modify-write cycles (where AS stays low but DTACK is expected to respond to changes in UDS and LDS)

Steve

ctirad
Captain Atari
Captain Atari
Posts: 278
Joined: Sun Jul 15, 2012 9:44 pm

Re: 4MB Upgrade & 16MHz Booster progress

Postby ctirad » Tue Dec 09, 2014 11:01 am

SteveBagley wrote: I think the problem is likely to be that the CPU responds (correctly) to DTACK going low, by moving into S7 and taking AS high. I think it then probably tries to start the next bus cycle and takes AS low again -- if this happens too soon it is quite possible that the ST never sees AS go high so keeps DTACK low


I agree. That could be the real source of the problem.

It's also possible that the ST is using a synchronous design and so expects DTACK to be low for n cycles?


I wouldn't be surpriesed at all if the ST would be a mixed bag of sync/async timing.
It asks for a several hour long session with a logic analyser. Or ask someone who already did that. Perhaps the author of Suska?

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: 4MB Upgrade & 16MHz Booster progress

Postby mc6809e » Tue Dec 09, 2014 10:04 pm

This has probably already been worked through but let me see if I understand.

68000 bus cycles can be completely asynchronous, with the system taking *DTACK low only when the data is actually ready. This works, but isn't the fastest way to move data in and out of the CPU. If the system waits to lower *DTACK only when the data is ready, the CPU will use one additional cycle to latch the valid data. For maximum speed, *DTACK must be made low early so that the 68000 can quickly latch the data a cycle later and end the current cycle to begin a new one. This causes trouble at 16MHz because there is only half the normal amount of time between lowering *DTACK and when the system actually has valid data on the data bus.

Below A=*AS goes low, D=*DTACK made low, E=end *DTACK low, C=begin cycle completion, V=time valid data is latched, I=possibly invalid data latched. The numbers are the states of a 68000 bus cycle. w=wait state. EDIT: B=address on address bus.

Code: Select all

     0   1   2   3   4   w   w   w   w   5   6   7   0   1   2   3   4   w   w   
    ___     ___     ___     ___     ___     ___     ___     ___     ___     __
___|   |___|   |___|   |___|   |___|   |___|   |___|   |___|   |___|   |___|
        BBB A                  D       C       V   E    BBB A

     0   1   2   3   4   5   6   7   0   1   2   3   4   5   6   7   0
    ___     ___     ___     ___     ___     ___     ___     ___     ___
___|   |___|   |___|   |___|   |___|   |___|   |___|   |___|   |___|   |
        BBB A        D C       V   E    BBB A        D C       V   E

        0 1 2 3 4 w w w w 5 6 7 0 1 2 3 4 w w w w w w w w 5 6 7 0 1 2 3 4
_   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _
 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
          B A         D  C   I    BEA                 D  C   I    BEA
                                   
        0 1 2 3 4 w w 5 6 7 0 1 2 3 4 w w w w w w w w 5 6 7 0 1 2 3 4
_   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _
 |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
          B A       DC   I    B A  E                DC   I    B A  E



The top is a completely asynchronous cycle on a hypothetical system that waits for valid data on a read cycle before lowering *DTACK where the data takes slightly more than two CPU cycles to be ready. It lasts 6 CPU cycles.

The second is a faster 4 CPU cycle bus cycle as on the ST with early *DTACK with DRAM data valid and latched one CPU cycle after *DTACK being recognized at the end of S4.

The last two are what might happen when running at 16MHz on an 8 MHz system that expects the faster cycle rather than the pure asynchronous cycle. Notice that the processor latches the data too early and that lowering *DTACK during what is normally S4 creates a race condition which might allow *DTACK to extend into the next cycle as has been suggested already. Conceivable *DTACK could be lowered even earlier by the MMU or lengthened by the MMU(has anyone used scope to see?) which would virtually ensure that the processor gets confused and assumes the old *DTACK is the *DTACK for a new cycle.

The cycles are aligned to *AS since that is when the MMU sees a bus cycle begin.

EDIT: One more issue might be the length of time the address is on the bus before *AS.

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4337
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: 4MB Upgrade & 16MHz Booster progress

Postby DarkLord » Tue Dec 09, 2014 11:30 pm

ctirad wrote:BTW, did you looked in the PAK68/3 schematics? The PAK is clocked asynchronously to the ST clock and there is an additional card called Pupla http://www.wrsonline.de/pupla.html that manages some additional clock syncing and signal caching. I'm not sure the GAL listing is publicly available, but there are some technical info on the page above.


The PuPla/2 board, according to Holger Zimmerman, helps when you are trying to use higher than 32mhz speeds, and the clock signal gets "noisy". As long as you are running the Pak 68/3 board at the normal/designed speed of 32mhz, you don't need it.

You don't *always* need it at higher speeds either. It just depends on your hardware. For example, I'm running my STacy at 40mhz without the PuPla/2 board, but I've not been able to run it at 50mhz without random software crashes, so there ya go.
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests