-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Feeler: Mac Portable max-out RAM upgrade
- Thread starter techknight
- Start date
techknight
Well-known member
5 Meg total.
That explains the logic ICs near the 8 PRAM ICs on the backlit portable, that logic circuitry decodes the 1 Meg of onboard memory, plus it handles the DTACK and 0-wait state response.
So, with that said, in order to max out the backlit with 9MB, I would need to run 2 wires off of the expansion card, and plug them into the ROM slot. that is the /AS, and DTACK.
The non-backlit portable, will generate a DTACK anywhere in the 9MB address range when accessed for read/write. And it will toggle the Delay.CS signal to the RAM card as well. (selecting RAM card). the backlit only generates a DTACK for the first 5MB and thats it.
Now, the only difference in the GLU is the DTACK line is not used on the GLU. its unhooked, and routed over to the logic block near the on-board RAM.
Either way I can unlock the backlit portable full RAM by using just 2 wires, and the non-backlit doesnt have this limitation.
I am seriously thinking about supporting the ability to override the on-board RAM with the expansion card. This way, the performance will increase slightly over the slow-ass onboard RAM.
the way apple designed thier expansion RAM, the decoding actually happens in the GLU. the chip-select for the correct chip happens on the card with a VLSI, but its simply configured as a binary-to-decimal converter.
My card will be a full decoder.
That explains the logic ICs near the 8 PRAM ICs on the backlit portable, that logic circuitry decodes the 1 Meg of onboard memory, plus it handles the DTACK and 0-wait state response.
So, with that said, in order to max out the backlit with 9MB, I would need to run 2 wires off of the expansion card, and plug them into the ROM slot. that is the /AS, and DTACK.
The non-backlit portable, will generate a DTACK anywhere in the 9MB address range when accessed for read/write. And it will toggle the Delay.CS signal to the RAM card as well. (selecting RAM card). the backlit only generates a DTACK for the first 5MB and thats it.
Now, the only difference in the GLU is the DTACK line is not used on the GLU. its unhooked, and routed over to the logic block near the on-board RAM.
Either way I can unlock the backlit portable full RAM by using just 2 wires, and the non-backlit doesnt have this limitation.
I am seriously thinking about supporting the ability to override the on-board RAM with the expansion card. This way, the performance will increase slightly over the slow-ass onboard RAM.
the way apple designed thier expansion RAM, the decoding actually happens in the GLU. the chip-select for the correct chip happens on the card with a VLSI, but its simply configured as a binary-to-decimal converter.
My card will be a full decoder.
Last edited by a moderator:
techknight
Well-known member
I got the CPLD development breakout board on the way along with the JTAG. Once I get the RAM from trag, ill mount those up on a TSOP to DIP Adapter then I can make a simple wire-wrap board for testing purposes.
techknight
Well-known member
And this is the reason why. So they can decode the entire address space and use up all 9MB.
But I wont need to do that. all the address/data lines are broken out at the RAM connector. I just have to borrow the /AS and DTACK line from the adjacent ROM slot.
the /AS signal tells the peripherals there is a valid address on the bus. /DTACK tells the processor there is valid data on the bus.
Also this thing has 4 Megs of ROM space. Perfect for a "doug" modification and have a boot image in ROM, or maybe even the serial disk driver.
But I wont need to do that. all the address/data lines are broken out at the RAM connector. I just have to borrow the /AS and DTACK line from the adjacent ROM slot.
the /AS signal tells the peripherals there is a valid address on the bus. /DTACK tells the processor there is valid data on the bus.
Also this thing has 4 Megs of ROM space. Perfect for a "doug" modification and have a boot image in ROM, or maybe even the serial disk driver.
Last edited by a moderator:
techknight
Well-known member
I am not aware of anything ever using the PDS slot on a portable.
. Hap has oneJust checking to see if I understand this.
On one Portable type (non-backlit) there's an ASIC which does house-keeping for RAM accesses. When the RAM address space is accessed, after some amount of time, probably based on expectactions for the 100ns RAM, the ASIC asserts DTACK to let the 68000 know that the RAM should have the data on the bus.
Is DTACK used on writes to let the 68000 know that the data has been acquired?
On the other Portable type (backlit) the DTACK signal is not handled by the ASIC, but by some separate logic chips. They handle it the same way, except that they will only assert DTACK for the first 5 MB of RAM address space and not the rest.
So you will want to build a logic circuit that detects RAM accesses, waits an appropriate amount of time, somehow, and then asserts DTACK. It might be interesting to make that circuit adjustable, at least at first, and see how fast you can tune the DTACK response.
Is that correct?
On one Portable type (non-backlit) there's an ASIC which does house-keeping for RAM accesses. When the RAM address space is accessed, after some amount of time, probably based on expectactions for the 100ns RAM, the ASIC asserts DTACK to let the 68000 know that the RAM should have the data on the bus.
Is DTACK used on writes to let the 68000 know that the data has been acquired?
On the other Portable type (backlit) the DTACK signal is not handled by the ASIC, but by some separate logic chips. They handle it the same way, except that they will only assert DTACK for the first 5 MB of RAM address space and not the rest.
So you will want to build a logic circuit that detects RAM accesses, waits an appropriate amount of time, somehow, and then asserts DTACK. It might be interesting to make that circuit adjustable, at least at first, and see how fast you can tune the DTACK response.
Is that correct?
Last edited by a moderator:
techknight
Well-known member
Well the backlit has a timing requirement of 0-wait states. Meaning the DTACK has to be handled almost instantly upon a chip select or address strobe. When I am outside of the 5MB window, then these timing constraints do not apply.
However, if I ignore the on-board decoding and handle DTACK and my own decoding on my own, then this timing requirement does not apply. the processor will wait how ever many states I require it to wait. But the data speed of the newer RAM is faster than the processor anyway, so it doesnt even matter. I can assert DTACK as fast as I strobe the address.
The internal gate of the CPLD is roughly 5 to 10ns propagation delay. If i string enough gates together internally, i can increase DTACK delay if I need to.
DTACK is used on both reads and writes. DTACK is always an input to the processor. it gets asserted when the RAM is putting the data onto the bus, or its retrieving the data and writing into the device.
However, if I ignore the on-board decoding and handle DTACK and my own decoding on my own, then this timing requirement does not apply. the processor will wait how ever many states I require it to wait. But the data speed of the newer RAM is faster than the processor anyway, so it doesnt even matter. I can assert DTACK as fast as I strobe the address.
The internal gate of the CPLD is roughly 5 to 10ns propagation delay. If i string enough gates together internally, i can increase DTACK delay if I need to.
DTACK is used on both reads and writes. DTACK is always an input to the processor. it gets asserted when the RAM is putting the data onto the bus, or its retrieving the data and writing into the device.
Last edited by a moderator:
techknight
Well-known member
the UDS/LDS data strobes go low after valid data is on the bus to be written. So when these lines get toggled, and address strobe gets toggled for a write, I know then that the data is valid before the write even takes place.
techknight
Well-known member
I found the designing cards and drivers for macintosh family online.
It appears BOTH the portable and backlit portable GLU will only decode and DTACK 5MB of address space. So for full expansion, I have to pick off the DTACK line myself and decode everything myself.
I did find a discrepancy. the book I think is incorrect on the pin diagram of the expansion slot for RAM. the board itself if you look at a picture, shows a staggered 1, 2 like normal IDC pin numbering system.
Well the book shows the pin numbering as linear and is way different than what I measured with a DMM. odd....
It appears BOTH the portable and backlit portable GLU will only decode and DTACK 5MB of address space. So for full expansion, I have to pick off the DTACK line myself and decode everything myself.
I did find a discrepancy. the book I think is incorrect on the pin diagram of the expansion slot for RAM. the board itself if you look at a picture, shows a staggered 1, 2 like normal IDC pin numbering system.
Well the book shows the pin numbering as linear and is way different than what I measured with a DMM. odd....
Last edited by a moderator:
Thank you for satisfying my curiosity. I guess the immediate DTACK makes sense. 16MHz is what? 62.5 nanoseconds. Plenty of time for the SRAM to get the data out there while the CPU 'sees' DTACK and waits for the next clock edge to access the data bus.
techknight
Well-known member
That was fast... RAM is already here. Looks like most suffered pin damage though, so well see.
Now I am just waiting on the CPLD stuff. Coming from china so thats going to take a century.
Now I am just waiting on the CPLD stuff. Coming from china so thats going to take a century.
Dog gone it. Well that packing method is no good then. My apologies. Will you be able to use those?
Any suggestions, lacking spare trays or proper tubes? Individual little anti-static packets, maybe?
How bad was the pin damage?
Hmmm. I wonder if there are tubes for 48 pin TSOP chips.
techknight
Well-known member
I have a velcro strap rack designed for shipping TSOPs.
it has 26 I think AM29LV320 FLASH TSOPs in it.
Those TSOPs I cant use, maybe I can ship the carton to you and you can figure out what to do with those chips.
the carton can be used to truck TSOPs back and forth once I get these expansions working.
As far as these, I think I can use them. Just have to fix the pins.
it has 26 I think AM29LV320 FLASH TSOPs in it.
Those TSOPs I cant use, maybe I can ship the carton to you and you can figure out what to do with those chips.
the carton can be used to truck TSOPs back and forth once I get these expansions working.
As far as these, I think I can use them. Just have to fix the pins.
Last edited by a moderator:
aplmak
Well-known member
Hey TechKnight… So I've got a Kingston 4MB card for a 5126 and three.. yes that is three weird RAM upgrades that bring my 5120's and 5126's up to 7MB.. I haven't figured out how to get them to 9 but I am sure it's possible.. These are stackable RAM chips that go in the PDS slot.. I forgot the manufacturer name.. I have the original boxes for the RAM too.. It doesn't use the RAM slot like I said.. it uses the PDS slot.. I've posted about them before.. The have little dip switches on them and I have the instructions on how to set them if you add more stackable cards.. I will take some pics of them tomorrow and email them to you.. I would be very interested in more RAM upgrades for my others… I have a 2MB and already got a quote on the chips for the vacant spots that uni did on his from a bad board.. I think I found them for like 3 bucks.. or so.. I have the company that sells them's info.. They are almost exactly the same.. And this is for the 5126.. I haven't looked into the 5120 RAM board yet… I'll get you the info tomorrow...
Last edited by a moderator:
techknight
Well-known member
the only way to expand it past 5MB is to use the PDS slot.
Well, I got other ideas....
Well, I got other ideas....
