Printable View
I'm still wondering if it is possible to add the A501 as 512kb slow-RAM to an 1Mb equipped A500 (1Mb on the motherboard).
So while tinkering with the schematics, I noticed some undocumented jumpers on the A501.
Wonder if they can be hacked to fix the addressing to slow-RAM area. Any helpers? Zetr0?
@rkauer
Good evening my friend, I just love the possibilites with the A500 - so much hackery its enough to make one giddy =D
Now, I believe that its certainly possible BUT we are going to need to do some muxing with A20 from Agnus + A21 and or EXRAM from GARY.
GARY[pin 32]EXRAM
[pin 37]A21
[pin 38]A22
its also worth noting that Gary's A20 [pin 36] will be in use with Agnus.
So the trick here would be to isolate the A501 when A0-A20 is being access and then BANK over to the A501 when A21[pin 37] is being used - I suspect we could use the EXRAM signal [Pin 32] - but I am still stuck on how to isolate the port -
.... ponders....
we could look and see which of the following from the Memory Expansion port is NOT connected in series with the onboard RAM
Now on the Expansion port we have
MEMORY EXPANSION[pin 35] - _BCASL(1)Its quite likely we will need to modify the A501 to use one (or more of the above CAS/RAS addresses) - infact that might be all we need to do - but I suspect that we will still need to mux A21 / BCAS / BRAS and possibly A20.
[pin 36] - _BCASU(1)
[pin 38] - _BRAS(0)
[pin 37] - _BRAS(1)
I am pretty sure it could be done with one small IC.. but which lines will need some more thought and probing..
I am quite confident thinking about it now that the A501 will have to be modified - or it will just shadow the extra 512KB thats on the motherboard.
I still thinking on a simpler mod: make the board respond only to 0x00C00000 address onwards.
Notice this RAM will be only available to Workbench running from a modified boot floppy or HD as no autoconfig code is done on ROM.
Simply asserting the memory at C0000 will trigger the A21 line (IIRC) and so only doing a small re-routing of the signal instead A20 to the right spot may do the trick.
After that is just a matter of calling the memory by an addmem utility.
Of course, modifying the A500 ROM code can easy the task a lot. I'll send you a code made by Jeff to modify the memory pool to reserve an address range at boot time.
@rkauer
That would be awesome my friend - I would like to have a lookie at the code indeed =D
now, the problem with the trapdoor port and the A501 - is going to be getting it to assert A21 for its use.... as it stands the A501 is pretty passive and relies on the Trap-door port for its address (which as you know is defaulted to C0000 on the A500)
however by performing the JP7A modification we remove that assertion
the problem is now, the Motherboard (extra) 512KB RAM and the trapdoor port are linked, how do we sever that link so that the trapdoor port doesn't just shadow whats in the upper half of chip ram?
I was thinking of modifying the port to respond to different RAS/CAS signals - thus keeping it relatively dumb and not just shadow the upper 512KB of CHIP ram, but without futher reading it would only be a guess at this point
Thing is: the expansion is dumb as a brick, but it "knowns" its size and it have a fixed relative address range. From x00000 to x80000.
My approach is sever the A20 line from the board and route the A21 line to its place to check if the board start responding at the new address range after a software mount.
That sounds like a great plan my friend =)
I was chewing on the idea of doing this some time back then concluded it would require quite a few mods so opted for the MegaChip route (REM: faulty DBK.)
I did start documenting from what reference material I had to see how much change was needed, but like rkauer, I wanted something simple and concise that anyone could easily implement without exhaustive hackery.
http://lh3.ggpht.com/_lD5TbYVyyUI/TH...k/Agnus2MB.jpg
It was an extension idea to my original 1MB A500 project: http://jetsetskippy.blogspot.com/201...-chip-ram.html
Hiyas Skippy
thats an interesting project, how do you generate Address 19 ? the 8370 Agni is a 512K CHIP Address Generation Unit, to go any higher and you would need atleast A19 - which it doesn't have.
I had this crazy idea a while back of multi-plexing Agnii together to get the full 2MB from two 1MB 8371's... then I went off to dream land and thought of multiplexting two 2MB agnii for a 4MB chip address generation unit... ... and I didn't get anything done as I was too busy in day dream land accepting my nobel prize for 4MB chip on an A500!
funny thing dreams =D
Now, I must comment on your site - skipps.. ;)
I like it.... its good, clean (in terms of not cluttered) with lots of info, but the biggest boon is that you are honest - if only there were more about like yourself =)
What's the actual issue here? I thought that the Slow-Fast and the extended Chip were at different address ranges? Is the problem that if you configure the second half of on-board RAM to be Chip then the trapdoor is shadowed to the same place?Quote:
Originally Posted by rkauer
@Andy
with the A500 Rv6A - the trapdoor port is pathway linked (RAS/CAS/ADR) with the motherboard space for the extra 512KB of RAM - so in populating the motherboard and aserting A20 (JP2) and disabling EXRAM (JP7A) we force the location of the trapdoor socket to the Upper half of 1MB CHIP RAM space.
the same would the case if this was on the Trapdoor port (in the flavour of an A501)RAM upgrade.
So as it stands, buy putting any Adapter on the trapdoor port the memory would be shaddowed by both the card and the upper 512KB of the 1MB on the motherboard.
Rkauer is thinking of changing the address of the Trapdoor port - to do this he needs to isolate the trapdoor port from the motherboard -
This can be done by disabling A20 from the trapdoor port (not the motherboard)
Then jump wire A21 in its place on the trapdoor port.
from this rkauer should be able assert the extra ram of the trapdoor port using a simple AddMem call at such and such range.
Should that this work this would provide a basis for the addition of a lot more memory =)
okay.... now I am having Déjà vu!!!
@Zetr0, those mapping notes were only to give me a pictorial overview. As you rightly pointed out that's a 512k (A1000), as I lacked schematics for other variants of the Agnii that one had to do.
Basically my blog site is there for everyone with an interest, as I learn I share my findings with others who are more than welcome to contribute, correct, etc.
I would say, as you've pointed out above, I do struggle with getting the information from my brain into a blog, so please double check everything! hehe - I get side-tracked by other projects so errors creep in on the literature. On reflection I do find what was in my head hasn't translated too well to text.
I do definately think that it's possible to achieve this goal, I simply didn't have enough information available.
As for dreamland, best place to be sometimes..
Not stating the obvious, but that shadowing of 512K simply gives the YELLOW error when you make both the onboard and trapdoor simultaneously available.
Where's those Oracles Zetro and rkauer, bet they're in the Matrix... :cool:
The trapdoor is currently disabled via JP7a for 1MB motherboard; trapdoor addr$ assertion removed.
* ADDMEM call the necessary multiplexed RAM address.
* RAS1 and CAS1 [Expansion Port] w/ multiplexed RAM Addr$ HOOKED to "new allocated addr$ assertion" assigned to TRAPDOOR.
* Listen for access [A21] Pin 37 GARY and point to TRAPDOOR ONLY IF address of new assertion ELSE upper CHIP RAM.
(As RAS1 is tied in with the motherboard via JP7a it will be pointing to the upper CHIP RAM onboard.)
(You won't be able to use the EXRAM signal as that is routed to the upper CHIP RAM onboard so again an assertion is needed.)
RAS1+CAS1+Multplexed addr$-->MUX (listen/hook with pin37/EXRAM)-->TRAPDOOR.
Metering the signals with an oscilloscope would be useful too.
As you've mentioned the need to isolate and HOOK the requested address and the theory would be use a suitable (decoder/ demultiplexer / PIC)
that listens for these requests to be re-routed.
At the moment I'm wondering at how this modification affects the synchronous and asynchronous mode signals from the 68000 and its relationship with the External Address Decoder/Valid (peripheral) Address/Bus, but as the modification is addressing $C00000 and it's within the hierarchy layout it should be ok after all it should be seeing and addressing it a FAST RAM.
An obvious disadvantage of this mod is the trapdoor 'Slow Fast RAM' access time is slower as it's done through the Custom chip data bus. (Unless you want to go completely nuts and bolt on a DMAC and addr$ the trapdoor as $200000, but that renders the side expansion useless for memory access.)
It would be nice to find a solution as this would allow both the upgrade mod of a 1MB CHIP RAM onboard and utilisation of the trapdoor
expansion, that is currently made redundant.
Who the hell meters an A500 at this hour - heheh :D
I'm wondering if the best option would be to replaced/modified U35 [74F244N] as this acts as the gateway between the onboard RAM/Trapdoor determined by the CAS/RAS signals. It would also give greater control and flexibility when addressing memory. :blink:
Be quite a feat though mapping out the logic gates... oh is that my bed calling me - :run:
Again: why going nuts with autoconfig for 512kb of RAM? Making a programmed controller can be awesome, but not intrinsically necessary.
A simple cut & solder plus asserting the line via software will do the trick nicely, as that ¹/2Mb will be used only for WB/WHDLoad.
The slow-fast address (C00000 to C7ffff) is only used by this kind of expansion, anyway.
Making it available to all Amiga programs then will involve more serious hackery (like calling the memory from ROM, another easy hack).
Thats some good reasearch Skippy!
I think in terms of multi-plexing a simple 74F138 would do when using the right signals.
so - lets look at the latching RAM controller of the A500 - U35
@rakuer / skippy
If you notice there are 2 inputs and 2 outputs not in use on the F244 (U35)
I suspect with a little play one could route these as extra RAS lines - RAS 2 and RAS 3 - thus routing outputs of 1Y2 and 1Y3 to the RAS 0 and RAS 1 of say an A501 (and or A501+)
you would
1. need to pickup/generate a RAS signal - pump it to U35 1A2 - pickup the result 1Y2 and then throw it at MEXP (Memory EXpansion Port) RAS0 and RAS1 - you will need to make sure that these signals (RAS0 and RAS1) are isolated from the motherboard though.
the best way to look at this is like just adding another block or bank of RAM - I have an idea - if I get time I will scribble it down.
Ohhhhhhhhh. :)
The plot thickens!
http://i12.photobucket.com/albums/a2.../b16078381.gif
@Zetr0: Would you do me a favour when you've got time, as I lack alot of the schematics, and show me where A20 is on the trapdoor and how this works.Quote:
Originally Posted by Zetr0
@rkauer " Again: why going nuts with autoconfig for 512kb of RAM?" - I just thought it seemed a nicer idea :unsure:
"Making it available to all Amiga programs then will involve more serious hackery (like calling the memory from ROM, another easy hack)." - I'm a bit rusty but don't Libraries take care of that? Now I'm waiting for a :hammer:
I think we have two concept ideas running parallel at the moment.
Right, I'm having my Asda Branflakes and a cuppa tea :lol:
I'm currently working from these Rev 5 motherboard schematics found at the back of the A500 User Manual.
Those JPx seem to be only on the Rev6 board, I'd be interested to know what they do, but I don't want to remove the RF shield from mine.Quote:
Originally Posted by rkauer
http://amiga.resource.cx/photos/phot...es=med&lang=en
JP2 and JP3 seem to be tied in with the Logic Gates to Memory Banks and JP9 (SIL) resistor RP903. JP1 looks as though it's connected to Pin 15 of trapdoor which is DRD-15 to DATA Paths U10-13.
Do you expect me to talk? No Mr Bond, I expect you to die!
When you're accessing the trapdoor address you will still have to aherd to the multiplexing schemes through a DMAC/RAM controller/"our new assertion", you can't just hardwire straight into the FAST RAM otherwise you'll end up with Bus Contention as there is only one data and one address bus that both processor and DMA need to share, not forgetting when you're software is calling addr$ on/off the STACK and PC (68000) and say blitting with Agnus to CHIP RAM it would crash. :wooha:Quote:
Originally Posted by rkauer
Amiga A500+ (REV 8a) has 1MB CHIP RAM onboard and an accessible trapdoor for FAST. Populating U32 with 74F139 chip as seen here: http://amiga.resource.cx/photos/a500,7 asserts 2MB Chip RAM w/ JP2.Quote:
Originally Posted by Zetr0
Based on that principle modifing U35 [74F244N] (Rev 6a) as the gateway perhaps adding 74F139 or [74F138] as you mentioned might be the way to go. :thumbsup:
@Skippy
ahh my friend, but here is the thing the A500 is just enough of a different bread of animal that you physically cannot add 2MB of CHIP via the trapdoor -
all we can make use of is the DRD and DRA - its our benefit and our bane.
Its the "lack of" controll lines that are the problem - we need a few more to really make it that matters - and these "few more" will have to be latched / multiplexed with U34, U35 with the primary requester being GARY A21
Although a 512KB (SLOW) fast ram upgrade would be possible with a little bit of work. I remember a fellow EAB'er (Chain) actually tried exactly what we are discussing here, he had mixed results - and remembering it now - it vaguely - the more I think about it the more I remember the faults in inherent instablility that he was plauged with - I suspect that this was the "race conditions" that the DMA / CPU were fighting over.
---------- Post added at 17:54 ---------- Previous post was at 17:36 ----------
the proble we have is keeping the motherboard upperhalf of the 1MB chip silent as the RANGER ram is enabled - and vice versa.
because the RAS / CAS lines are tied to the EXPMEM port and A500 - I beleive this is the bigest problem - the moment we attempt to latch the ranger RAM there will be the shaddowed memory of the upper 1MB CHIP to lock out or the returned data will be junk from bothe chips.
Had the ram been popluated on an adapter card we can then "independently" shift banks (each bank being 1MB) pending on a little logic and GARY -
the first *(primary bank)* would be the 512KB on the motherbard and the 512KB on the adapter card.
It's the principle differences between the two REV I'm referring to Grand Master Z. It's how the developers have approached having 1MB CHIP onboard with the option of having FAST via the trapdoor. U32 - [74F139]Quote:
Originally Posted by Zetr0
The idea is to see if this approach can be adapted to the REV6a to include the U32 with U35 to open the trapdoor back up as a workaround the JP7a mod.
"and these "few more" will have to be latched / multiplexed with U34, U35" - hence the idea of incorporating U32.
Certainly plenty to consider.
@Skippyar: I'm starting to understand what you are saying. And sounds like a plan.
The real problem is the EX_RAM signal on Gary, that cannot be asserted without loosing the upper half of the 1MB CHIP RAM, rendering this hack dead on the water.
Now, creating the possibility to inform the Amiga via other way about the ranger memory (without issuing the EX_RAM signal) is the main problem.
I ditched the idea of hard-wiring, but patching the expansion.library (creating a "new" ROM, for example) is a affordable possibility.
Anyone here with a flashROM-equipped A500?
---------- Post added at 22:14 ---------- Previous post was at 22:08 ----------
I'll check the JP2/3 jumpers traces and to where they go.
We will have a surprise if the logic is already on the board.
as an idea my friend, you could
1. Seperate EXRAM from the motherboard at GARY
2. Jump wire EXRAM from gary to Adapter in trapdoor port
3. feed exram signal to motherboard from adapter.
4. adapter muxes EXRAM / RAS / CAS via A20 and A21
kinda a rudimentary idea, but - looking at it, you can either remove the 512KB bank from the board and run it from the adapter - hence controll over if EXRAM is to be used or not.
On a basic level -
Gary asserts A21 - EXRAM is enabled - RAS and CAS are set - data is fetched from motherboard DRA and data is sent back from DRD(15:0) -
now if the extra 512KB was on the adapter (say a 1MB adapter) you would just switch banks on the baord to reply to the request..... however because its on the motherboard we cannot switch it as its hardwired - so we need a way to shut it up from responding.
hmmmmm
hmmm its also late... and I have to admit this little one had been teasing my brain a little - in a good way =D
"however because its on the motherboard we cannot switch it as its hardwired - so we need a way to shut it up from responding."
* If it's a REV6A populated 1MB onboard to disable the upper 512KB - short pin 2-3 (JP7a) opening the trapdoor/disabling UPPER 512K.
But then you're regressing the computer.
"remove the 512KB bank from the board and run it from the adapter - hence controll over if EXRAM is to be used or not."
1. Hypothetically speaking if you mounted 1MB on the trapdoor you'd sacrifice 512KB onboard CHIP just to have 1MB trapdoor FAST. It would surely be better to have the full potential of 1MB CHIP onboard and open access trapdoor for FAST.
2. Connecting EXRAM to the trapdoor RAM (??) in series isn't gonna work. All EXRAM does is acts as a strobing signal to GARY [pin32] to inform that a card in present. (The alternating of EXRAM "present" signal via JP7a (JP7b->Agnus) simply re-routes the accessing of RAM from the Trapdoor to the populated UPPER 512KB RAM onboard).
Besides hot-wiring EXRAM on a trapdoor >between< GARY Pin32 {RP101} and (RESET pin18 68000|RESET pin16 AGNUS) would probably generate a BusERRor trying to insert "whatever" into the Chip Control which goes against the grain of the whole address/data bus control architecture.
Hypothetically solution: In a way you're trying to split EXRAM into performing two tasks: (REV6a)
1) JP7a (short pin 2-3) - 1MB onboard RAM
2) JP7a (open) - Access TRAPDOOR.
But you can't because in order to use the TRAPDOOR, EXRAM needs to work with XRDY (GARY pin31) and amongst others, NDTACK, for the (de)asserted of processor waits (bus lines/AGNUS) ELSE system hangs plus the prevention of accessing non-existence MEM locations (BERR-Bus Errors).
Which is why I thought perhaps using U35 as a gateway and expanding from there would make more sense.
But the more I think about it the more I feel like bashing my head against a wall :banghead:. Because you almost need some sort of on-access alternating "switch-mode" EXRAM or a {demux line} to 'switch banks' like on the A1000 [DRA8]
"(say a 1MB adapter) "
If ERAM $C00000 - $C7FFFF is only 512K how exactly do you begin tackling the task of asserting larger amounts of RAM; or are you creeping into the
REAL-TIME CLOCK allocation area?!? or more switching techniques?!?
Ironically what makes the trapdoor so complicated to expand on is because it's design concept is so simple! It limits what you can actually do with it. Which is leading me to think this is becoming too complicated to achieve than worth bothering with.
When I've cleaned the concrete out of my hair I might read the schematics to the A500plus and the A501plus for more clues. :coffee:
Skipster.
(I hope I don't sound negative and skeptic.)
@Skipps
looks like you suffer the insomnia monster too LOL.
okay a small incorrect assumption - the EXRAM signal can be controlled (ignored / exploited) via the adapter on the trapdoor port - this is connected ONLY to the trap door - cutting this means you can add the extra 512KB to the trap-door and have it be asserted as CHIP ram - as normally an A501 would assert the EXRAM signal - GARY would then shift the assertion of A20 to RANGER memory space.
Now as the ram is populated on the motherboard it might be an idea to see what happens with the EXRAM signal being re-instated and no card in the trap door socket.
Personally I think you will find it wont assert A20 to RANGER RAM space - since there is nothing to pull the EXRAM signal Hi or Low - its just floating - like it is when you cut it..
I used to own a 4MB baseboard - that attaches to the Trapdoor on the A500 - it had only a couple of IC's - nothing to hard in terms of logic.
http://amiga.resource.cx/photos/photos/baseboard.jpg
(stock photo thanks to amiga.resource)
Now the intersting thing is - the manual (I have it here and will upload when I can)
With the 1MB Agnus - the manual states that you should preform the JP2 A20 modification if not already done, but more interestingly to correct the JP7A back to default - on the card you then select the first 512KB to be used as CHIP ram and the remainder (3.5MB) will be asserted as RANGER RAM.
The manual is quite big and surprisingly indepth for a user manual - and a very VERY interesting read - when i find the PDF I shall link it.
you know thinking about it - a small GARY adapter that asserts A21 instead of A20 in regards to the EXRAM signal being pulled - might do the trick here.
Of couse I think any more than another megabyte (i.e. 1MB of RANGER RAM) wont be possible without some clever "CPLD" logic to generated more RAS/CAS signals and bank switching.
@Z: the most RANGER memory an Amiga can have is 1.8Mb, "normal" expansions that use this memory area are 1.5Mb, as it's illogical to use 2Mb to get only 1.8 (at that era).
I think the BaseBoard add the exceeded memory as FAST RAM.
Ranger mem is from C00000 to D7FFFF, so it is 1572864 bytes long (1.5Mb). But a bit more can used before hitting the system real time clock at DC0000.
So usable RANGER memory space is from C00000 to DB7FFF: 1802239 bytes (1760kb).
People don't remember the time when a single 1Mb RAM SIMM costs as much as near US$100!
@rkauer
morning my friend =)
Thnking about the BaseBoard - its more than likely the BaseBoard used the memory space address reserved for FAST ram and not RANGER ram, alas with DRA and DRD stuck on the chip ram path - the Base Board could only ever be SLOW FAST ram =(
The Base Board unit is also upgradeable to another 2MB (total 6MB) through the addition of the XRAM board - alas I cannot find any more info on that adapter - its likely that this is a true FAST MEM adapter.
-
it might be an idea to download the software - this should give an idea as to where the ADDMEM is happening and what range its asserting.
I don't imagine that the speed of the RAM and the address range are related. I understand that there are one or two A1200 FastRAM cards that allocate a meg or so into the RANGER address space, but surely it's accessed as fast as any other (proper) Fast RAM on the same card.
@Andy
It cannot be accessed as FAST only as Other Mem - because of the chip-path it shares - but it can use the same memory location in the Z2 space
Real FAST RAM can only accessed by the CPU
I suspect that in the BasBoard's case its asserting some of its memory in RANGER space and the other in Z2 space - as this card has a the option to select the FATTER agnus it can (if you jumper it) Mux-up with A20 to give you another 512KB of CHIP ram via bank switching.
This gives you 1MB chip and 3.5MB Other ram - how that other RAM is organized and where its location is asserted - downloading the software might give some clues =)
LOL!!! It's eating at me Zetro, it's eating at me!! :lol:Quote:
Originally Posted by Zetr0
There is no right or wrong just good input for us all to mull over :thumbsup:
I've got an A500 on the bench ready for dissection.
I'm just throwing a few ideas about hoping some bright spark will chime in with a solution; then maybe I'll have a decent nights sleep.
All the best.
LOL - I have to admit this little conundrum is teasing me too -
insomnia however.... well I think I was cursed with that way back when I was a nipper of 9 years old..... which co-insides neatly when I got my first computer!
(that 1KB + 16KB Rampack + Currah Speach unit and Kempston interface!)
see... I vaugely remember this thing call sleep up untill that point so many (25) years ago!!!
to be fair though my friend I made the same assumption with EXRAM and was hitting the books on this thread I discovered otherwise - it makes better sense to make a 1MB+ addapter and bank switch the 512KB for CHIP / (SLOW) Fast
because the RAM is populated on the motherboard I honestly dont think we can shut it up - even with adding extra controll via the nexus of U35 - Although this would be interesting to see what would happen if we did add extra controll signals.
Looking at the EXRAM port and the motherboard documents - the memory is broken up to multiple banks of 512KB with a 16bit data-path (256x16) the trap door is an expansion of this construct - so if we want more ram we need to look at adding in banks of 512K.
As long as the address from GARY and the logic is there to muliplex / swap banks you could use the full CHIP / RANGER and 24bit RAM reserved spaces - that would be an additional
512KB CHIP
1.8MB RANGER
8MB (SLOW) Fast
total of 10.3MB addressable - using a 16MB SIMM - this would mean not using 5.7MB o the SIMM.
Although this will be a huge benefit in terms of RAM (1MB CHIP 9.3MB Other) this other would still be slow - it would be better to lump on an 8MB Adapter to the 68k moto =)
so this means we can have some fun with the 1.8MB Ranger RAM area.
I propose a small adapter board to the trapdoor socket (with a 4MB SIMM) would provide a nice 0.5MB (512K) extra chip + (1.8MB) (SLOW) RAM - alas the rest (1.7MB) is not used / wasted.
we can use the controll lines from the trapdoor, and bank-switch in and out the 512KB bank of ram as needed by the address multiplexing circuit.
In fact, the memory is added in increments of 256kb. Or it is in 128kb increments?
The "1.8Mb" Ranger is in fact 1.76Mb, so 1.5Mb + 128kb.
@rkauer
my friend, I would hazzard a guestimate that you have hit the nail right on the head with your first idea - (256k banks) the blocks would be arranged so that it would be 128K*16bit
that would be 4 address lines - thus for 256*16 (i.e. 512k) would be 8 address lines - which is what the A500 actually has - it also pics up another address line from U35 giving it 9 address lines - this would be enough for 1MB or 512*16
The 256*16 bank structure is more plausable the more you look at the A500 specs - with this you could get 7 banks in RANGER ram - total of 1792K = total ranger ram allocation I believe.
Now the reason I think its 7 banks and not 8 is because one bank (or better put: address line) is reserved for CHIP RAM allocation.
I believe the designers of the A500 designed it for 1MB chip from the outset and commodores epic cheapness won over - although the A500 was incredibly expensive back in the day - so 1 whole MB of memory was considered excessive.... 640k was all the world needed back then LOL
Might amuse you Gents.
@skippy
what have you got there - I cannot make it out
looks like 512K chip and 512K OTHER (SLOW) FAST
what have you jiggied?
Running through some practical tests of the notes I'd made. I wondered how come with EXRAM on gary removed the trapdoor was still asserted, turned out the Action Replay cartridge was doing the role via XRDY / NDTACK on the side expansion. (External Device present generates processor state) Remove the ARA and the system (CPU) hangs up.Quote:
Originally Posted by Zetr0
I've put this together for you; it's (hopefully) every combination of Jp2 and Jp7a w(w/o) A501 and the results - the tests at the bottom with EXRAM pin removed are false positives from the ARA cart being present.
http://lh5.ggpht.com/_lD5TbYVyyUI/TM...otos%20009.jpg
Back to the schematics, then.:banghead:
@skippyar: you notice there are high-resolution schematics for all Amiga range on Aminet (courtesy of Cosmos)?
Quote:
Originally Posted by rkauer
Good Lord, what an effort!! :bowdown: Thanks to Cosmos :bounceBoingBall:Dedication indeed.
Thanks for the tip rkauer. :thumbsup:
Here's an appropriate tune for Cosmos: http://www.youtube.com/watch?v=6jzWRYr-b_Y :rainbow:
Great work Skippy!
I believe that you have prooved my hypothesis of the upp-half tied bank
I have placed your hand written report into a table (of sorts lol)
[please let me know if I have copied a test incorrectly]Quote:
Originally Posted by Skippy-Tests
Summary of presented testsokay... its coffee time, great work skippy!
In all test cases where there was an A501 and onboard memory: the onboard memory shadowed the location of its assertion and what is stored on the A501 512KB of memory expansion.
In all tests where JP2[1-2] and the EXRAM signal is not asserted (ie. Open or no A501 installed) result in 1MB of CHIP RAM
JP2 Summary Hypothesis
JP2 allows A20 to be used by Agnus to Generate a 10bit address for chip ram - this means that it would not work on an 8370 Agnus
JP2 Status - 2-3 (default)
Allows the AGNUS to generate upto a 9 bit address for CHIP RAM (maximum of 256k*16) 512KB total
JP Status: 1-2 (modified)
Allows the AGNUS to generate upto a 10 bit address for CHIP RAM (maximum of 2x (256k*16)) 1MB total
To obtain 2MB of CHIP a 2MB Agnus would need to be added and A21 multiplexed to asert an 11bit address for CHIP RAM (more on this later)
JP7A Summary Hypothesis
JP7A Status: 2-3 (default)
Enable Trapdoor Sense
JP7A Status: Open (NC)
Disable Trapdoor Sense
To prove the fact that JP7A is just a Trapdoor Sense - examine the A501 - and see where the EXRAM is pulled high or low (I suspect high) - disconnecting this will disable the sense and report only 512KB with JP2[2-3] and 1MB with JP2[1-2].
Trapdoor Sense (EXRAM JP7A) asserted informs Gary to assert the RAM at $C0000 - however when JP2[1-2] is set - it no longer has the address line to access it as A20 is taken up by Agnus to address 2 banks of (256*16) 1MB
Now is when fun begins again: how about using a simple multiplex port to re-enable the A501 using the A21 line to make the board act as Ranger mem?
Leave the f-word EX_RAM signal where it belongs: doing nothing.
LOL, that was an absolutely hilarious comment. Love it!! :lol:Quote:
Originally Posted by rkauer
@Zetro: Awesome work creating a table.
I'm sort of between things at the moment, but when I get time, perhaps towards the weekend I'd like to sit down and see if I can work the schematics for the A500plus [Rev 8a] (mainly U32 U34 U35) back into the schematics for the Rev 6a A500. :blink:
The objective/challenge is to "knit" the developers changes from 8a into 6a with the hope of getting a better understanding of how to establish having 1MB onboard Chip and our FAST trapdoor. [If I've understood the Rev8a specs correctly.]
Hopefully working from the ground up will give a better overview of the 6a and if I'm confident try and crudely implement the differences to see if they work, then look at a simplified approach of say 'piggy backing' an 'adaptor mod' onto U35 and a few trace cuts to board. (famous last words) :unsure:
I briefly metered in this area this morning.
This ornamental cat has been providing all the above information telepathically.. it makes me do things :-?
I have done some more research in memory mapping and the Gary -
First up is Memory Maps
Tested System(s)Code:Tested this with WinUAE
The A500 has 8x 2MB banks ranging from 000000 - FFFFFF
(16MB total address space - 24 bit address)
Bank 0 is 2MB in size
Bank 0: 000000 - 1FFFFF ( Asserted as CHIP ONLY)
Bank 1 to Bank 8 are 2MB each
Bank 1: 200000 - 3FFFFF Public FAST
Bank 2: 400000 - 5FFFFF Public FAST
Bank 3: 600000 - 7FFFFF Public FAST
Bank 4: 800000 - 9FFFFF Public FAST
Bank 5: A00000 - BFFFFF < What is this area for? >
Bank 6: C00000 - DFFFFF < RANGER RAM C00000 - DBFFFF (DC0000 - DF0000 ?) >
Bank 7: E00000 - FFFFFF < F80000 512K Kick ROM>
Ranger RAM is 1.75MB in size (1792K)
ERAM: C00000 - DBFFFF
-----------------------------------------
1MB - OCS Agnus: (1MB CHIP) / 2MB - ECS Agnus (2MB CHIP)
8MB - Z2 FAST RAM
1.75MB - (SLOW) ERAM (Ranger)
Its clear that ERAM ocupies the address space of Bank 6 - however only 1792KB - instead of 2MB - I suspect that the only way it would do this is if the address area multi-plexed seven 128K by 16bit areas (256KB each)
ROM Address
The 256KB ROM is in the last 256K region of Bank 7 "FC0000"
The 512KB ROM is in the upper quarter of Bank 7 "F80000"
More ROM space reserved
If I remember the conversation right, a while back on EAB, doobrey prooved that both the A600 and A1200 have the ability of a 2MB Kick ROM space - I suspect that this map would also exist for the A500 - hence this would co-inside with the full USE of Bank 7 E00000 - FFFFFF, of course this would mean that exec would have to be re-written to actualy use 2MB, at the moment there is a modified exc that can use 1MB, space but not 2MB
So as an educated guess - would Bank 7 be specifically for Kick ROM ?
Speculicious!
Acording to the A500 spec-sheet there is an 18bit Address line available at the Kickstart ROM, thats 18bit address with 16bit data - 2 Megabytes
The A500+ on the other hand has a 20 bit addressable (A0-A19) ROM socket its weird because that many address is HUGE - like 8MB HUGE!!!
I suspect that there are some - minor differences between the spec-sheets and physical product - in some negatable areas like the ROM were the last original commodore exec library (thats the loader of the Kickrom) could only see 512KB!
next up some GARY notations.
---------- Post added 27th October 2010 at 00:55 ---------- Previous post was 26th October 2010 at 23:42 ----------
The GARY (Gate ARraY)
Whats it do?
Gary contains various control circuitry to provide an interface and control for custom chip set and a 68000 CPU
What does it look like?
Physically GARY is a 48pin DIP with the following net structure
http://www.amibay.com/picture.php?al...&pictureid=340
Pinout and Description
http://www.amibay.com/picture.php?al...&pictureid=339
GARY in Operation
Address lines A17-A23 are connected to the processor address bus and are used to generate the various device decodes.
Expansion Ram signal is externally pulled up. The expansion ram card grounds (pulls down) this line. This signal is used in the generation of NRAME.
68000 bus timing:
NAS (Not Address Strobe)
indicates the start of a bus cycle and remains asserted for the duration of the cycle. Processor addresses (A1:23),
status FC0:2 and PRW are valid while NAS is asserted.
NUDS/NLDS (Not Upper/Lower Data Strobes)
indicated data is valid during a write or enable read data to drive the data bus. NUDS indicates valid data on D7:15 and NLDS indicates valid data on D0:7.
PRW (Processor Read/Write)
indicates the direction of data buss transfer. PRW =0 is a processor write.
NDTACK (Not Data Transfer ACKnowledge)
is an open collector or tri-state output drives the CPU NDTACK input. The 68000 requires NDTACK=0 to complete either a read or write cycle. This signal sets up to the end of processor state S4. If NDTACK=0, the cycle will complete normally.
If NDTACK=1, the processor will add wait states until NDTACK=0 before advancing to S5 and then completing the cycle. If NDTACK is never asserted (=0), the processor will hang up. This circuit provides NDTACK generation for all internal memory accesses and is available for external device use (via XRDY) if desired.
If the external device desires to control NDTACK directly, the NOVR signal can be asserted which tri-states (or forces one in the case of open collector) the NDTACK output.
XRDY (eXternal ReaDY)
input is used by external devices to control the internal NDTACK generation in the case where NDTACK is needed to cause processor wait states. If XRDY is not asserted by an external device, the internal circuit will generate an NDTACK which does not generate any processor wait states. Since XRDY can only de-assert NDTACK, this circuit will prevent the system from hanging up in the event that non-existant memory locations are accessed.
NOVR (Not OVeRide)
input directly disables the internal generation of NDTACK and internal device selects. This pin allows external devices to map themselves in place of existing devices (such as ROM). In this case, the external device must assert it's own NDTACK. The timing of this circuit IS NOT RELIABLE FOR REPLACING VIDEO RAM (NRAME) OR VIDEO REGISTERS (NROME).
OVL (OVerLay)
input causes ROM to be accessed at memory location 0. This signal is typically driven by a port line so that ROM is mapped to the memory 0 at RESET time.
NDBR (Not Data Bus Request)
input indicates that the Amiga custom chips are performing a video bus DMA. The circuit delays generation of NDTACK, thereby delaying the CPU if it attempts to access the video bus address range while NDBR is asserted.
NBLS (Not BLitter Slowdown)
output drives the custom chip blitter slowdown input. When the CPU address in BANK6 area, NBLS is asserted.
NBGACK (Not Bus Grant ACKnowledge)
input indicates that an external DMA devices has taken control of the processor busses.
NRAME (Not RAM Enable)
output indicates that the CPU is accessing video bus RAM (this includes expansion RAM).
NRGAE (Not RGA Enable)
output indicates that the CPU is accessing Amiga custom chip register space
NCDR (Not C Data Read)
output enables the output buffers of the video bus data latch to drive the CPU data bus.
NCDW (Not C Data Write)
output enables the video data buffers to drive the video data bus.
C4 (Clock 4)
output is used to latch data on the video data bus.
NVPA (Not Valid Peripheral Address)
output indicates that the CPU is accessing an 6800 type peripheral (such as the 8520) and causes the CPU to perform a 6800 compatible cycle.
NROME (Not ROM Enable)
output is the chip select for the internal 2Mb ROM.
NRTCR/NRTCW (Not Real Time Clock Read/Write)
outputs are the read/write enables used for data transfers to and from the the real time clock circuit.
Address Decoding - The address decoding generates internal memory bank signals.
QUAL decode qualification is true only when NAS is asserted and both NDTACK and NOVR are de-asserted. Used to qualify RAM, RGA and ROM selection.Code:Address Range Bank
000000-1FFFFF BANK0
200000-9FFFFF BANK1, 2,3 and 4 (1 through 4)
A00000-BFFFFF BANK5
C00000-DFFFFF BANK6
E00000-FFFFFF BANK7
C00000-C7FFFF ERAM (expansion RAM, qualified by GO)
D80000-DB0000 NNAC (non auto config for RTC)
E00000-E7FFFF NROM
FB0000-FFFFFF NROM
000000-1FFFFF NROM if OVR asserted
ROME is asserted when NROM is decoded and:
1. Bus cycle is a read (PRW=1)
2. NAS is asserted
3. OVR is de-asserted
The NDTACK circuit has to generate NDTACK for all onboard devices and also for expansion space (to avoid system hangs). ROM, RAM and custom chip registers are special because it is necessary to synchronize them top a specific phase of the C1,C3 clocks.
GARY Switching Characteristics / Waveform latching
Switching characteristics are specified for input waveforms switching between 0.4V low level and 2.4V high level with 10%-90% rise and fall times of 10ns.
Outputs are loaded at the rated interface conditions with 130pf total capacitive load (including fixturing). All time measurements of driven signals are referenced to 1.5V on inputs and outputs.
(1) - NTDACK is a potential system problem -Code:Output Input(s) Delay Limit
------ ------------ -------------------
NDTACK- AS-,C3+ 45ns max
NDTACK off(1) XRDY- 35ns max (w/o rise time)
NOVR- 20ns max (w/o rise time)
NROME AS- 50ns max (2)
NRAME Addr,NEXP,C3- 60ns max
NRTCR AS 50ns max (2)
NRTCW+ UDS/LDS+ 30ns max
NCDR- C1+ 50ns max (2)
NCDR+ UDS/LDS+ 50ns max (2)
NCDW- PRW- 50ns max (2)
NCDW+ C1+ 50ns max (2)
C4- NCDAC- 25ns max
C4+ NCDAC- 50ns max (2)
NVPA AS 50ns max (2)
HALT RESET 50ns max (2)
DKWEB DKWE 50ns max (2)
MTR0D NSEL0 50ns max (2)
MTRXD NMTR 50ns max (2)
DKWDB NDKWD 50ns max (2)
NBLS- C1+ 50ns max (2)
NBLS+ C3- 50ns max (2)
In the case where NOVR is activited after AS- (S2) has already asserted NTDACK. In this event, NDTACK can not be guaranteed to be pulled high before S5 because of the pullup resistance and node capacitance.
(2) - Many signals are not critical timings. 50ns was selected as a convenient, non-critical value
Another small information: the area from DBFFFF to DFFFFF is only used by the real time clock. So invading this area with RAM will mess the hell out of the Amiga (aka Mr Guru).
May we can "route" the A501 to the 2 to 1Mb before ROM area (E00000 to E80000) instead this pesky C80000 area?
@rkauer
hmmm, my friend, I dont think its location that the problem only in accessing the memory once its there.
If we return the A500 Rev6a back to 512KB on the motherboard - we will be in a better position in controlling what ram is asserted and to where.
I am thinking of a modified A501 -
0. CE is disabled on the Card
1. Piggy backed with another 4 chips - 1MB 8 chips total on Card
2. Piggyback RAM CE is not connected to the bottom chips
3. Piggyback RAM CE is connected across on the top CHIPs
With this we now have full controll of the CHIP ENABLE now we can let seperate which bank will do the talking.
So when Agnus is looking for the upper 512KB of CHIP we can assert the CE of the bottom chips, when GARY is looking for memory above $1FFFFF and below $28FFFF we can use the extra asserting address as a means to enable the CE of the piggy backed chips.
This would *technically* use up 512KB of 24bit space reserved for FAST RAM, and it would need to be ADMEM allocated.
Sounds like a plan, and simple enough. Now which RAM area to choose?
From my POW, the higher the better. Testing the E00000 address can be an exciting new Amiga world: one more Mb to cram inside the Amiga!
This way we can attach a true FAST RAM card/sidecar later without inviting Mr Guru for a tea.
I have to admit.... I am a little excited about $A00000 - $DFFFF
(4MB of addressable space)
I suspect this is how the BaseBoard works in giving you 4MB of RAM - or 3.5MB or RAM and 512KB of extra CHIP
$E00000 is also an interesting area - theres atleast 1.5MB of available space there before we hit 512 Kick ROM space