ST MACHINE EXPANSION BOARD IDEA

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
Greenious
Hardware Guru
Hardware Guru
Posts: 1462
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Greenious » Wed Feb 27, 2008 8:59 pm

Nyh wrote: You will have to intercept the address lines going to the GLUE chip, otherwise the GLUE chip will generate a bus-error when you try to access RAM or ROM that is not there according to the GLUE. That is why most upgrades to TOS 2.0 or 3.0 are done by putting the processor on a daughterboard: then you can intercept address signals to the new ROM without the GLUE generating an address error.


No, nothing needs to be intercepted. Buserror is generated as a timeout function of GLUE if no dtack is generated. As long as you generate DTACK, GLUE do nothing.

We had this discussion in an earlier thread, where Ijor also conducted some experiments that confirmed this.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Wed Feb 27, 2008 9:10 pm

simbo wrote:it is capable its just that not all signals for this are used from the mmu {the pins were never connected on ste} and im sure it can address the whole 16mb {definatly positivly for sure!!!}
provided the extra bank select and control signals get used or generated from the address lines themselfs

And how will you solve the problem of the video and DMA address counter that are inside the MMU? The MMU itself can only address 4 Mb.

simbo wrote:however addressing it via dma is a bad idea anyway
but if it was fitted inside and fully replaced the current ram then im sure it will speed up the access to it
the problem comes from access to hdd etc at the same time as ram
so reusing the dma is a bad idea as it causes bottlenecks and data loss would occur anyway
as the dma die has the problem inherint to its die arrangement a known issue with older machines

I think you will need DMA to be floppy disk compatible. I am not sure whether potential users are willing to loose floppydisk and ACSI access.

simbo wrote:later ste can definatly do 16mb addressing it as the control signals are there and sort of connected

Even the GSTMCU has only MAD0 to MAD9 thus a maximum size of 4 Mb chipram.

simbo wrote:attached is the 16mb upgrade path for st machines

taken from atari forever as i cant find marpets designs {i have the schematic somewhere}

IMHO you attached a TOS upgrade project, not a 16 Mb upgrade, but I could be wrong here.

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Wed Feb 27, 2008 9:12 pm

Greenious wrote:
Nyh wrote: You will have to intercept the address lines going to the GLUE chip, otherwise the GLUE chip will generate a bus-error when you try to access RAM or ROM that is not there according to the GLUE. That is why most upgrades to TOS 2.0 or 3.0 are done by putting the processor on a daughterboard: then you can intercept address signals to the new ROM without the GLUE generating an address error.


No, nothing needs to be intercepted. Buserror is generated as a timeout function of GLUE if no dtack is generated. As long as you generate DTACK, GLUE do nothing.

We had this discussion in an earlier thread, where Ijor also conducted some experiments that confirmed this.

Ah, that is interesting, I didn't know this.

Hans Wessels

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Wed Feb 27, 2008 10:12 pm

so... reading all that people have said
it is fair to say that indeed the mmu also needs an fpga upgrade
however ive seen and fitted and used 16mb ram in st level machines
and interplirated physical lines are just the very same as physcial ones with respect to time...

so your coments about the mmu are total rubbish !!!

and yes the mmu has physical counters but this is unimportant
and not litteral becouse the ram speed access and transfer isnt changed by address last in use interpliration only the layer the data gets written a read from
when it is
infact when you use a fpga lattice connected accross the address bus and data bus with ras cas inputs

and outputing to other layers whilst in control by the system ras and cas

its fully possible to interplirate (16blocks of 16layers of (16 bits * 16 bits )) = {(((16*16)*16)*16)/1024=64mb total
but a time's 2 is easy so its 128mb total avalible within the same time frameing when interplirated cas ras is used for banking


many people over the years have used built themselfs and installed this type of 16mb expanssion
and none i know anyway complain it didnt work ?? anyone heard other ???
so where does this leave this debate ... :megaphone: not relevent

so i beleve looking at the chip type and its substrate composition
its to the max 16mb that can be allocated before the mmu needs overclocked or it spits the dummy and you would require seperate bus counters
and a set of shift registers allocated in gates to move the blocks on each sussesive layer address request
but to be safe 32mhz and direct ttl counter from all lines to get upto 3 sets easily
so... the simple solution is to over clock it alone as its not even slightly warm it will take a count cycle more
then,,,,, simply count a new set of outcomes on cas an ras relative to refresh
and bingo 6 more uniqure timed fully ranges and sharper ram access for fast page etc {edo needs more addressing}
however i agree this area needs more screwteny....however its not hard to even replace the mmu with a better custom fpga
as its just a latice chip blown to suite
then alligned to suite and buffered where needed

using the addon i propose many others things become possible like swap file usage but in ram not hdd based



hans .... now if again you read !!! the post i made and this step is simple
copy out all the posts i made on page 1 highlight key areas you wish input from out to output too
make them a different colour and arrange them in blocks and prioritise them

then take the time to write down key points you noted and ive qualified
{and the germans were good at this the dutch at rolling the splifs and cracking the beers :P }

....now i said that the whole dma access to this unit {expanssion} is done via a acsi lun on the dma asci
above the top physical lun in use and is masked from the onboard atari dma !!! at boot sequence time !!!!by any device connected to the acsi port

this is done before even any floppy is checked and the FLOPPY will still take priority anyway followed by lun 0 {default acsi }
followed by lun1 {grabbed from the address bus on intercept and redirected from onboard dmaif a hdd controller card is on acsi lun0 if not lun0 as its a controller card }

ie the fpga chip or chips simply reroutes the access lines on qualification
that the dma access to the expannsion card/s is on

{ physcial drive +1 actual real atari controller address +0 new controller is then +2 }
you see?? lun is simply the controllers memory address range id +1 so its a layer of the controller and the controller
treats it with parenthasis

say it lives on lun 0 {physical lun} or address 1 dma
as the controller is address 0 address 0 being always occupied by the poo onboard thing
{that took also mips to make with all respect}
the same dma chip i have modeled in c++ code for proteus in dsimm to see how it works

so .. the actual access to asci hdd and for that matter
any bootable floppy is FULLY and with the respect to the bios boot sequence....
page 273 atari st internals abacus software rev 3 feb 1986 rev tos 1
.... fully preserved
!!!! unless you have tepid booted it from the lcd panels transfer snapshot and reboot choice menus
with respect to the menu your in in the lcd {controlled by the micro as it controlles and supervises this}

then it will instant load over that slot you selected together with a snap byte
{a word containing key chipset settings this is loaded first to init the chipset to state}
so...

and transfers can only occur from the card to the machine via dma
happen only when the hdd driver
be it rom ram or sdram loaded occurs
on a simple check {if no hdd load sdram from lun 0{as no hdd unitation is there }

the ram and rom will still be fully seperated but shadowed {and masked fully}
so the rom becomes the ram with just one enable and clocked cascade ... AT boot -1
ie the ram is the rom +the program at that instance so will be the same when reloaded

no need to boot even from a cold boot... execpt hans who need to wake up...
just load the init byte {word dword etc .. can be packed} for the chipset ...basic settings nothing special
as this occurs to all devices every app refresh anyway

then the ram and its all there


:contract:

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Wed Feb 27, 2008 10:57 pm

simbo wrote:so... reading all that people have said
<SNIP>
then the ram and its all there


Does ANYONE understand what Simbo is trying to tell us here?

I am totally lost.

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Wed Feb 27, 2008 11:08 pm

Simbo,

No doubt I am a very stupid boy without any understanding from hardware. Can you please explain me how the shifter is going to display data from a memory address above 4 Mb?

Which chip stores the video address?

Which chip reads the data from memory?

Hans Wessels

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Wed Feb 27, 2008 11:28 pm

hans

just say nothing then

your input is wasited

its best to input stuff and not to raise points in quotes its cheeky to do this and makes no point atall
make a list

dma video address counters
are there as a super position

i think you mean video super position counters

they are there to time dma transfers to the shifter
so there is no bus colussions its called a data transfer masking system and is controlled by cpu interrupts as well as timers
the timers run from memory access address in ranges each counter is set to yield a range for the virtual address of physcial unitation{devices periffs etc}
that is bound in time to the actual pins of the chip it talks to


take a powder i know all this
the dma and mmu shifter etc transfers i intended to remain irrelevent and this system remains fully untouched anyway

appart from two maybe three or four borrowed signals

adding another dma access node is super easy
you simply borrow the switches from the physcial dma chip
and 'replace it virtualy' but with physical switching but with respect to it
so it controls the access rights but not the actual access its done direct to ram when the physical lun above any allocated is choosen
and gets serviced

so basicaly the card loads its own hdd etc driver from sdram and captures the data flow without the dma influence
when it selects the lun above any hdd on asci
you see
controller >> lun0 {if no hdd allocates to card}
if acsi connected lun 1 selected as acsi will use lun 0
its automatic capture of lun
the dma chip remains unloaded and enabled during this capture
and its only enabled if its needed
floppy transfer will work fine also never touched its on a different address and isnt the same layer no where near it
however shares the lame dma chip


read and learn and talk :P im your pal really

even if people feel happier with 4mb total avalible side loadable system ram to st

and 128mb sideways ram layers of 4mb {-4mb side loadable system layer }
and 128mb rom / 4mb slots and maybe cloned cartriges also side loadable to any of the system layering ram

this can all be loaded from a card in 300ms or less i calculated it at .25mb per second from sdcard
to load this whole card takes about 1-2 secs
so once it up and running its self loading and with lcd slot loadover menu etc etc features its a great tool

i think that usb and vga is easily possible with some borrowed signals and another dma routine in force
to a pc the atari will be a hard disk of 4mb ram {where everything lives } then it can flash the atari
the pc to an atari can be ram also and flash its address ranges with init and data so controlling its hardware

you see ram to ram is easy
you load it to the ram fpga buffer and you shift it right and address system ram in the whole to flash it with the new registers worth of 4mb data
working the whole 128mb memory as a fifl first in first loaded system but with bypassing on load block over
the structure of fpga code vhdl is simple

easy stuff really... just a matter of some strong minds friendly debate and good lists of q and a topics
and less quotes of passages from the last log or two
then others would be able to q a the original lists people posted
1} 2 points etc

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Thu Feb 28, 2008 12:06 am

vga
-----

i thought hard about vga and svga both monitors and what to use

so i think just capture the video ram areas {even the shifter and blitter data is reflected in ram usualy at masked ranges }
so redirection at memory controller fpga level and to a video chip for display is a matter of loading to seperate video ram
{address range + masking data and settings table} all the time or interrupt that the shifter can supply so keeping tick with video refresh
at known settable address ranges that always are physical addressed to the vga controller then to video dac then the socket
and reinterprit the settings like hires low res and med res
i think this way mono would be easier to handle at 72hz or 75hz refresh
and med low res could be a fixed 75hz for all of us {world standard freq to avoid flicker is 82hz so this can be included and a choice in a .acc etc

i think take a leaf out the minimig project here
and ask the guy if he would like to handle this module

so someone point him to this topic

... ill send him an email :P

ill draw a chip unit diagram now

back soon

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Thu Feb 28, 2008 1:06 am

ok

attached is the proteus design file for the layout i mean... youll see where im going now

also a picture {a little big so download from one of my backups sites to view }

i think adding as original design a 8mb eprom or sdcard access routine for the tos loading from 0ram state and no hdd backup
reading some vga chips note there...
the vga clock just needs to float and need not be in sync with the system
to allow shifter transistions to be mimiked in refresh of vga
just some shifter signals are needed and the vga controllers resolution control dirived from video ram {video control word in ram } can be also selected from the lcd menus
the foot print of the main board can be as small as 20cm by 15cm double sided
and still retain all accepts inc the expanssion bus as mini dtypes
that connect to normal vga connector and or boards etc
and lets or the vga board /vram etc be located above the metal case
and a ribbon up to it is easy {maybe 20 way X2 is enough to feed it}
ill work out exactly what dma signals are needed next
and start to build a flow chart from bootup and various senarios

but i see very few issues with this now we are all happy with 4mb system ram
and the rest of the waffles is eaten

still lots of issues in methods to get the best from it at this point
sosome feedback please is cool :cheers:
sorry i was a bit gruff but its like this when people dont see the same thing

like i think adding all expanssion plugs and sockets above the metal is best
and a central board is the best with just fpga ram /rom lattice dma and expanssion bus's
and all others like smart ide and network on external mini d types to above the metal
as its nice and easy to cut holes same goes for the lcd but its just 4 wires + - and rx tx data to it's module

so a common coms routine like jookie used between the bridge in his design and the smart chip
can be used for all devices on the cards dma schedule as each lun can have upto 7 devices
{easily addressed via simple tsr drivers and grouped and setup by a .acc icon pallet }
and maybe a resident copy of a custom ide lun driver for inter bypass dma coms
a simple dma transfer could also supply data to an mp3 codec and also a sound card or fm oscillator maybe reuses the sound chip psg data
modules like this will allow people to add what they want to use
with the main card still able to do any or all and maybe adding a bus board above for all perifs attached {board with seven sockets for perifs on default lun
and dma + any flaging signals leed down to the main board

could have a floppy power connector socket on it to allow it to power all the perifs witout a mess of cables going up and down then its just vga interlink and power to it
and it can go where the psu was or still could be
and the vga added next to the card or plugged to it and a socket added beside the cart.port


http://uk.geocities.com/mayaka2001/atari_st_expanssion_design.jpg picture here......

file attached is proteus design file {www.labcenter.co.uk to get a demo that opens it}
You do not have the required permissions to view the files attached to this post.

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Thu Feb 28, 2008 5:05 am

incidently

the dma transfers too and from the common control bus
can be fully 16 bit wide and not 8bit to the acsi >scsi controller normaly used
so im sure the speed will be a bit faster and far far more relaible and flexable

maybe ppera or jookie can give a view to this
and what speed is reconed using say fpga dma 16 bit to 16bit hdd width in one cycle direct transfers >???
in effect the board would take the onboard dma prisoner when the boards dma calls or is called for service

alexh what can you add on the fpga core for switching and lattice control
the lattice is as said just a set of shift register arrays masking and buffering of ram blocks

also i have looked at a few lattice some around 90i/o would be aok
so any views on this

i have no problems to program anything
got a top2049 lately and found a usb to printer port {new board no ports arg.... :roll: } so double sided pcb is back on the cards

any help from others greatly appreciated !!! by one and all :thumbs:

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Thu Feb 28, 2008 6:19 am

http://www.microtronix.com/products/?product_id=97

looks like a good design starting point for vga has it all and then just export the core

£100 +import tax i recon maybe about 130 quid as a one off for the development board

a nice choice for sure :cheers:

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Thu Feb 28, 2008 8:24 am

simbo wrote:dma video address counters
are there as a super position

i think you mean video super position counters

No, I said video address counter so I mean video address counter.

I think someone with knowledge about Atari ST hardware knows what the video address counter is.

Google: "Atari ST video address counter"

First answer:

Code: Select all

The Atari ST Internals
Screen Display

$FFFF8201  r/w  |xxxxxxxx|          Video base high
$FFFF8203  r/w  |xxxxxxxx|          Video base medium
$FFFF8205  r    |..xxxxxx|          Video address counter high (r/w on STe)
$FFFF8207  r    |xxxxxxxx|          Video address counter med (r/w on STe)
$FFFF8209  r    |xxxxxxx.|          Video address counter low (r/w on STe)


Hans Wessels

ppera

Re: ST MACHINE EXPANSION BOARD IDEA

Postby ppera » Thu Feb 28, 2008 1:05 pm

This starts to be painful :(

I don!t think that anything above 14MB in ST is good idea (here I will not discuss about how to solve it).
There is no SW what can use it. Or if it will be solved it will be too slow.
Machine should be harmonized so that no component which is too slow for entire system.
16MHz 68000 is not for 128MB RAM. And RAM itself must be faster - it means faster bus in first place.

We saw here some more prespectivic solutions (almost complete) to get ST compatible machine with lot of features, peripherals.

User avatar
earx
Captain Atari
Captain Atari
Posts: 353
Joined: Wed Aug 27, 2003 7:09 am

Re: ST MACHINE EXPANSION BOARD IDEA

Postby earx » Thu Feb 28, 2008 2:47 pm

I'd like to have the following additions to the ST hardware: LAN, CF, 12+ MB RAM, 16 MHz +, etc etc..

But suffice to say this would require massive amounts of soldering. I saw Simbo wrote something like "only" 20 soldering points and cutting some pins. Whenever I read such things I get cold shivers. Most ST users can't solder to save their lives (except some adapters and a single resistor, or so, like me).

A CT2 accelerator installation on a Falcon was already too much for most users (12 wires IIRC). Some people argued that making a complete 060 TOS clone from scratch would have been less work than the work performed on the CT60. Maybe except for the casing, which always seems to be a problem in small scale projects.

My vote is for a complete remake of the ST. Much like Minimig, Suska, or the DTV. An expansion board is just too much fuss and the chance of crippling standard hardware is large. There would also need to be Mega, MegaST, and plain ST versions, which would further complicate matters.

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Thu Feb 28, 2008 7:18 pm

it seems hans is still bleeting about ram locations and this and that
all irrelivent {known info and not relevent to vga and direct vram addressing as this is all handled by the main vga controller and passed to vdac }
the shifter simply shifts 256k blocks so can the vga controller to vram and it can have mimik mode or real vga {someone will write a software for its core to do this for sure}
i mean why does the shifter do this and why and when you know this as i do you realise how to use 'another' control signal to give you what you need in vga
you dont need to scan double anything
the minimog just does this for conformity to the ataris shifter {its shifter is there as code} i mean to redo the data thread but with respect it the higher refresh rate... of 75khz or 82
its easy to streach a smaller resolution out
by over sampling it in fpga and first makeing a frame holder inside the vga frame that does the maths for you.... to resize and preserve the dot width
first it upsamples then downsamples to allow a kind of quantise ... you see???

the shifter system mmu timings and all literal addressed shifter data is untouched
its simply tapped from ram and the data bus.. and redirected complete with the video control word to the video ram
this data is then interprited by the fpga to output to svga or vga direct
if you use real mode youll get a pal or rgb sized picture within vga
the interpriter for it would take some skill and judgement but is easily done
the data is there as a single block in ram
why read 256k blocks other than to satify the shifter chips struct ....
just block transfer the whole frame as it fills {over sample this area and you get a moving picture and a high frame rate }


ppera notes that in priciple an expanssion like this is a good idea and something about 128mb
or even just to hold prisoner the onboard dma to get direct access for a perif chain
maybe he wants to make a separate board just for this???lots of people would just like this alone

other's still want to process faster when 16mhz is fast enough for everthing made

others look for a falcon clone boards like minimog and to send hundreds of st machine to the landfill
spending several lifetimes to debug its highly complex cores
the cores here are simple 50 -80 lines of c max...
1} this unit is 4mb as bashed out as needed and unless interpliration of layer is used its the max the mad0-8 in st level with yield
however mad 9 pin is there ....on the mmu disconnected in st
while mad 0-9 in ste land will happily run 16 mb with no people pissed off i wonder why ??? so.. st level is fixed with all st machine to 4mb and layers thereof
2} soldering isnt an issue as the cables should be measured and supplied made up and tailed /tinned so its a matter to easily solder it on
mostly to the if blank blitter smd pads
3} machines can always be sent to have it fitted
4} st mega and mega st and ste will all {or should use} the very same upgrade board with only the cores changed where needed
this is why you use fpga
5} this unit only has ever avalible 4mb as a single slot
thats not to say the slots themselfs cant be simply addressed by hardware dma bridge to allow them to appear as a ram partition {ram drive }
6} swap file becomes easy and this will bring many other uses to all st level regardless of fast ram etc
if this is wanted also then it can be added and just in the same ram chip different addressed block {the lattice can eaisly direct this }
7} full support for people who wish to fit it themselfs can be given
8} lan is ethernet earx my pal .....cf is ide, 12+ram we have already discussed this re-read the post 16mhz??? what??? cpu mmu dma ? what do you mean
if you want more cpu speed then im sorry even a falcons 16 bit bus is the same 16mhz max ste or st games and app will use and they
would all need retimed/compiled again from source to work on faster bus in falcon the 32bit isnt really used for much and also isnt avalible
all extra chipset speed in clock cycles does is make it think fast the software still things in realtime or abstime or should!!!
9} like any hardware you cant make a golden egg from the ass of a battery chicken no matter how much emf you expose it to
so limits need set
10} faster hardware doesnt mean a faster app or game they have timed in realtime or abstime {absolute time } event structurte so they interact properly
11} ct60 cards etc cool stuff but the falcon already has all the perfiferals and fast 16{14mb} ram
i think the ct60 and 63 pretty much covers all need for it
maybe its dma can be held prisoner and also the not so used scsi port used with the same device chain as the st {nice idea i suppose} just a simple change to the chains dma controller and ill tell you know this whole system will never be synthetic in fpga as its far too complex so forget falcons in fpga and a clone of it becouse any ct63 fitted falcon will them compete with any clone so its better to buy a falcon {still lots around}

as a unit design you can buy it in stages and add with just a plug in {plug and play}
apart from nothing at all but people's unwillingness to sheel out on the main board add in
what would be a really usefull addin and allow instant {almost} boot to a game gem or app
i see no problems in making it work fully
vga and shifters are also irrelevent i also fully modeled this chip in proteus and can synth even a core for it by exporting it fly compile

so..
more please .....
:mrgreen:
You do not have the required permissions to view the files attached to this post.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Fri Feb 29, 2008 12:11 am

simbo wrote:the dma and mmu shifter etc transfers i intended to remain irrelevent and this system remains fully untouched anyway appart from two maybe three or four borrowed signals

This could make sense. It is very wise to leave this system intact because it is the heart of the ST. Modifying it will almost certainly result in incompatibilities.

simbo wrote:attached is the proteus design file for the layout i mean... youll see where im going now
also a picture {a little big so download from one of my backups sites to view }

Simbo has been working hard and he has drawn for us some nice diagrams.

simbo wrote:i think adding as original design a 8mb eprom or sdcard access routine for the tos loading from 0ram state and no hdd backup reading some vga chips note there... the vga clock just needs to float and need not be in sync with the system to allow shifter transistions to be mimiked in refresh of vga just some shifter signals are needed and the vga controllers resolution control dirived from video ram {video control word in ram } can be also selected from the lcd menus
the foot print of the main board can be as small as 20cm by 15cm double sided and still retain all accepts inc the expanssion bus as mini dtypes that connect to normal vga connector and or boards etc and lets or the vga board /vram etc be located above the metal case and a ribbon up to it is easy {maybe 20 way X2 is enough to feed it} ill work out exactly what dma signals are needed next and start to build a flow chart from bootup and various senarios but i see very few issues with this now we are all happy with 4mb system ram and the rest of the waffles is eaten

For some reason Simbo has dropped his idea about breaking the 4Mb memory limit. Good idea! Reading his design it think it would be possible to get it to work. He is getting all the necessary signal from the MMU and the processor. Only the shifter data bus is omitted. I think the wire count to the board is a bit larger then he planned but the higher count is necessary to get a working project.

Well done Simbo! :cheers:

simbo wrote:the shifter system mmu timings and all literal addressed shifter data is untouched its simply tapped from ram and the data bus.. and redirected complete with the video control word to the video ram this data is then interprited by the fpga to output to svga or vga direct if you use real mode youll get a pal or rgb sized picture within vga the interpriter for it would take some skill and judgement but is easily done the data is there as a single block in ram why read 256k blocks other than to satify the shifter chips struct .... just block transfer the whole frame as it fills {over sample this area and you get a moving picture and a high frame rate }

Simbo is on the wrong track here. He is overlooking all the nastiness demo coders do with the video subsystem of the Atari ST. I am thinking about rasters, overscan and syncscrolling. I think it is better to sample the AD converters of the sifter and feed that data to the VGA system.

simbo wrote:1} this unit is 4mb as bashed out as needed and unless interpliration of layer is used its the max the mad0-8 in st level with yield however mad 9 pin is there ....on the mmu disconnected in st while mad 0-9 in ste land will happily run 16 mb with no people pissed off i wonder why ??? so.. st level is fixed with all st machine to 4mb and layers thereof

Here once again he Simbo breaking the 4 Mb limit showing he doesn't do his math or doesn't understand memory organization of the ST.
The math:
1 memory addressing is done by the MMU with MAD0-MAD9, that are 10 addres lines. With the RAS (Row Address Strobe) and CAS (Column Adress Strobe) lines the MMU can addres 2^20 bits = 1 Mbit per chip.
2 there are 16 chips per memory bank, giving us 2 Mbyte in a bank.
3 there are two memory banks giving us a grand total of 4 Mb.

Hans Wessels
Note: serverely cut down version. Was in a bad mood last night. Shouldn't post then.
Last edited by Nyh on Fri Feb 29, 2008 12:01 pm, edited 3 times in total.

User avatar
earx
Captain Atari
Captain Atari
Posts: 353
Joined: Wed Aug 27, 2003 7:09 am

Re: ST MACHINE EXPANSION BOARD IDEA

Postby earx » Fri Feb 29, 2008 10:47 am

i'd better leave this thread as there is nothing of interest for me.

some communication in simbo mode:

!!! {{{bye}}} ..

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Fri Feb 29, 2008 12:49 pm

the memory hans will be 4mb in one bank interleaved by the lattice
each successive 4mb block is simply moved into place again by the lattice
the lattice simply moves the in use address ranges pysicaly to address the next range up

this can be a simple lookup table affair in c and of no real deal

your right and wrong in some ways about the video
i know what coders do the boarders of ataris
this can be preserved at ram level simply by encoding it to that format and this can be done in i think for an fpga chip is easily capable at 33mhz of reworking it to the pal standard size frame
this can be displayed in svga 800/600 with very little loss of frame size
the problem is to just switch the monitor to 800/600 mode as they default to 640/480 and much up the avalible sync ranges so this info will need added to the design of the vga card

if you look at the frame guide above then pal sits nicer there

again your right it should be done by capture of the data on the shifter
however the last project board i spawned for replacement video amp and data i/o from it got washed out by too much disagreement
so i made one for myself and use it in an ste machine give a much fresher picture with much less noise
although i didnt attack the i/o to vga part as im not sure about it
so yes taking the data from the shifters d-a and reworking it via fpga to a new set of outputs
and a similar vdac to the one in the project board i pointed out some posts ago for vga development
so this is an extra 4or 5 pins of data per colour channel

good
now we are getting somewhere and maybe not
becouse as i said the very same data in ram is just clocked and counted for sync generation purposes
and can be reinterprited by placing it to vram as a stream and controlled vga dirrived
however the expanssion bus is there and if someone wants to to it and add a board then fine
but i didnt plan to handle this bit anyway i just want ram tos sideways loading and fgpa masked extra dma
as a data i/o bus inside


so ill rejig the designs to remove the vga card unit and simply make it a possibility
or add the pins i/o ??? what one
tell me ....

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Nyh » Fri Feb 29, 2008 1:34 pm

simbo wrote:i know what coders do the boarders of ataris
this can be preserved at ram level simply by encoding it to that format and this can be done in i think for an fpga chip is easily capable at 33mhz of reworking it to the pal standard size frame

You will have to differentiate between a lot of data going to the shifter. It might be palette changes or overscan data. You wull have to monitor the current shift mode too. I even don't want to think about all the glitches you get with fullscreen timing. I think monitoring the shifter output will be a lot easier. No worries about the fullscreen tricks and modeling the internal shifter state. The shifter will do that for you. Keep in mind there are mixed resolutions possible with low and medium resolution on the same line. I think it is best to do always a 800x600 resolution. You can fit all overscan resolutions in this format (ST LOW and ST MED fullscreens exists, in high resolution it is possible to remove the lower border).

simbo wrote:so i made one for myself and use it in an ste machine give a much fresher picture with much less noise
although i didnt attack the i/o to vga part as im not sure about it
so yes taking the data from the shifters d-a and reworking it via fpga to a new set of outputs
and a similar vdac to the one in the project board i pointed out some posts ago for vga development
so this is an extra 4or 5 pins of data per colour channel

This part has only to be done if someone wants VGA output. Although an interesting project it is not a major factor in the RAM project and can be done in a separate project, either before or after the RAM project.

simbo wrote:so ill rejig the designs to remove the vga card unit and simply make it a possibility
or add the pins i/o ??? what one
tell me ....

Good idea to remove the VGA for now. It can be added later.

Hans Wessels

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Fri Feb 29, 2008 2:30 pm

ok.... all done

and images changed

now ... to decide on what fpga devices and lattice to use

input from other here would be good for the correct choice at this stage to be made

and also please any other ideas to add in not yet covered that can be added ???

http://www.latticesemi.com/products/cpl ... rce=topnav
and another 1 of the same ic's to perform ram and rom switching

and something a little smaller for the dma
perhaps the same cpld chip jookie used for his smart controller bridge ...

for lcd and menu system... a pic onboard the lcd controls it and acts as a menu system
another pic onboard the card
can allow ide and smart access to it so maybe handy
at the same time controlling what ram rom slot is in use or to use or to save
and the size of the ram {some fixed settings made once }
all pic parts can be backed up on first start and saved as a hidden menu
within eithers internal ram

most interfaces module addons like spi i2c and others can be handled by cheep dil pic's
as they will all share the same bus its sensible to allow a common routine set to be formed for all unitation
this way a whole set of file's can be compiled at once
to form the external units cores
or worked on seperately and add a .lib or include a class with this driver
and easily built in c using sdcc or a comercial compiler

for the ram
we have some choice for sdram
28164 = 8Meg x 16 (128Mb chip):
2844 = 32Meg x 4 (128Mb chip):
2884 = 16Meg x 8 (128Mb chip):

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1462
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: ST MACHINE EXPANSION BOARD IDEA

Postby Greenious » Fri Feb 29, 2008 6:54 pm

I don't want to shoot you down simbo, but imho, mixing the mmu into the expansionboard is no good idea, or adding more than 8mb of ram.

First of all, most ppl are quite happy with "only" 4mb of ram on ST. I've seen plans for expanding this to 14mb, that apparantly works (they did sell it) cheating mmu/glue. I looked at that solution for myself, but decided it was a waste of time. First of all, once you mix the mmu into the mix, you will not get fastram. the mmu will divide reading slots between shifter/cpu. for a 8mhz 68000 it does not matter, but for a 16 mhz 68k cpu it will. And still you can't use that extra RAM with the shifter, or DMA.

4mb STram is more than enough, FastRAM is already supported in TOS 2.0x, all you need to do is tell it that it is there. No need to replace the mmu with a fpga.

The cache chips needed to make a worthwhile booster for ST/STE is impossible to find today. Without a cache and with only ST-ram to rely on, you get maybe 20% boost from a 16 mhz 68k. With Fastram you can utilize every hz of those 16 mhz with existing halfdecent written software... And I think most ppl are more interested in getting a faster computer than adding an absurd amount of ram.

As for bankswapping memory, maybe you can adapt MiNT to handle it, but it is probably not interesting to most people. And for it to be a reliable solution, you will also need a half decent mmu, with the ability to protect ram from accidental overwriting, OS that supports memory protection and page swapping etc, etc. I don't think you will find any coder that wants to do that work.

I suggest you go for a 8mb FastRAM solution, and reserve the remaining 2mb in the memory map for a gfx solution.

Forget about more memory than the 68k can address directly, those in need for that probably already have a TT or F030 with CT60/CT63.

As for a multitos switcher, why not, flash memory is fast and cheap, you don't need to copy it to faster ram, just add a decent sized flash chip, and people can add/remove TOSes at will.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Fri Feb 29, 2008 7:35 pm

look ill say this only one more time for the benfit of all

the unit as stands now WILL ONLY!!!! have access to 4mb RAM only !!!
avalible to the system at anyone time

as slots of 4mb blocks fill the space above in the ram section BUT ARE FULLY MASKED
in the rom section there can be upto 128mb / 4mb blocks avalible for tos and rom units
or forinstance saved rom cart version of games as it WILL when set to only boot the roms above tos after tos loads and detects loaded roms just use them after loading tos as a menu is easy to add
infact the bios provides one


youll not need anything other than tos to use this no mint or multikernal
as for fast ram fine ill add tos 2.06 into the mix as i intended to anyway


i repeat 4mb system ram the ram is only 4mb this unit is 4mega bytes
4mb is the limit the system can use
4mb man
i say old chap 4mb

i hope its sunk in

when you bank select a ram area
the machine first warm resets then its loaded accross at no time now does the tos roms need to run in

its already in the ram flash and active
this is selected and loaded by the lcd panel

for crying out loud its not that hard to grap surely
:coffe:

jd
Captain Atari
Captain Atari
Posts: 355
Joined: Thu Nov 09, 2006 12:38 pm
Location: Ruislip, UK

Re: ST MACHINE EXPANSION BOARD IDEA

Postby jd » Mon Mar 03, 2008 8:44 am

So it's got 4Mb RAM then?

:D :D

sorry couldn't resist.

ijor
Hardware Guru
Hardware Guru
Posts: 3823
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST MACHINE EXPANSION BOARD IDEA

Postby ijor » Tue Mar 04, 2008 2:53 pm

Greenious wrote:No, nothing needs to be intercepted. Buserror is generated as a timeout function of GLUE if no dtack is generated. As long as you generate DTACK, GLUE do nothing. We had this discussion in an earlier thread, where Ijor also conducted some experiments that confirmed this.


Indeed, GLUE never generates an "active" bus error. Bus error is always a timeout.

So there is no need to intercept GLUE for "blocking" bus error. But you need to connect all the addr lines (plus other control signals, like FC) for decoding because GLUE won't generate chip select.

simbo

Re: ST MACHINE EXPANSION BOARD IDEA

Postby simbo » Wed Mar 05, 2008 12:37 am

the ram is all
if you fly replace ram
by fly redirection of a ram starting block
then the ram /chipset on no boot will just carry on to refect the same settings
ram any instance has if it has the same bios and tos
it will just carry on to re-reflect the same tos and rom and the new ram as it already has
so reset is a bit harsh so dtack wont need to alter


4mb ram as a solid location in ram cross loaded with the same bios and tos = the same machine +new ram data
next itteration the new chipset data is loaded
and the machine carries on as is but the last event

maybe tos expanssion and above 4mb ram is a bit bad and needs external chips
but really this data can be interpliated in new ram blocks

and signals intensiated to cope

i think added multi tos to experiment and fpga core / lattice as ram
and some keen programmers

and a few added bus
and lots of st and mega get saved in the long run by simple multi unitation addons
for realtime work

flash and run !!! flash means just add to address ranges to make the new ram address it run in !!!

ram chipset is all that exists at any given point

even a simple capture to ram of crytical setting can be made for each location and fly saved as a single byte or word {ffff etc}


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: Timnaber and 13 guests