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

Designing a portable RAM card

techknight

Well-known member
Nope. I need the AN994/D. 

Closest I come was a post in the Freescale forum, but the attachment is long gone. 

Scavenging around with that search, I found an amiga 68020 accelerator, and its associated PAL code in a document from the 80s. This document also refers to that same application note, which is how it hit on the search engine. 

Problem is, I dont understand CUPL so i dont know how to convert CUPL into discrete logic. 

But from what I gather so far, attaching a 68020 to the system bus, might as well go with 030, little difference. Seems relatively streight foward. 

Just have to have the logic to break it down to 16 bit cycles, and then you need the Syncronous generation logic becuase its missing in the 020. Basically the E, VPA, etc.. signals. 

Then the bus mastering logic. 

As long as we have these 3 logic blocks, everything else pretty much just works. The Amiga they were converting the 7Mhz bus signal to the async 16Mhz so the guy had to create a whole bunch of extra logic to keep DSACK happy, and other things happy. Whereas in my case, the bus is already at 16Mhz, and I will keep the same for the CPU. So i can cut out that extra logic. 

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
Is there a reason you want to go with the 68020 instead of the '030 specifically?
 

The 68030 user manual goes into pretty extensive depth about how the bus sizing mechanism works. The manual includes some example PAL equations for the byte select logic needed for smaller bus sizes, which I think is pretty much what you'd get out of that application note. There are some minor differences in how the bus sizing works for the 68020 (said differences are mentioned in the manual) but you may be able to use the hardware design mostly unchanged anyway.

(EDIT: Downloaded and skimmed the '020 manual and it looks like it has the same material in it. You might want to sign up to the Motorola support forum and ask for the app note there. Google points to a discussion there where someone found it and gave it to someone else via an attachment, but the attachment doesn't seem to be available anymore, at least without a login.)

EDIT again: I assume you found this PDF already, about interfacing a 68020 to an Amiga?

 
Last edited by a moderator:

techknight

Well-known member
I think an 030 can directly replace the 020. Cant remember though. I thought 020 because its on hand. But 030 is more plentiful.

That application note is exactly what I needed.

 

techknight

Well-known member
Now I just have to figure out how to arbitrate the 68000 so the 020 will take over. Done.

Gorgonops: yes I did. Another document that refers back to the application note I needed.

 
Last edited by a moderator:

techknight

Well-known member
Doubt it. The 170 is 32-bit throughout.

Best I can do is LC. As itll be 32 bit shoehorned on a 16 bit bus.. however... there is a however.

I can fill the rest of the new address space as RAM, 32 Bit RAM.

Then if I can figure out how to tell Mac os to use the RAM at the end of address space instead of the beginning, it should increase the performance immensely.

Nothing I can do about exception and interrupt vectors which reside on low ram. But eh. Just got to tell the mac memory manager where "ram" is.

Im sure itll be some sort of extension or system enabler coded to do it. Leave interrupts and exception in low ram. Move heaps and system into high ram.

Bbraun would know more than I about this part.

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
I can fill the rest of the new address space as RAM, 32 Bit RAM.

Then if I can figure out how to tell Mac os to use the RAM at the end of address space instead of the beginning, it should increase the performance immensely.
68020 and greater Macs need a hardware widget to remap their RAM into a contiguous block (be that the special stripped-down remapping chip in the Mac II, the version of that built into the LC, or the onboard MMU in the '030 and later systems.) and the memory maps for the two modes are substantially different. (I/O gets shoved to the top of the 32 bit address space, etc.) This is why even "real" Mac II family systems can't use more than 8MB of RAM in 24 bit addressing mode, and why accelerators for 16 bit Macs that include onboard RAM sockets are generally limited to using anything above the 4MB mark for RAMdisks, etc.

I do recall reading about some software for Mac II's with full MMUs that would let you get up to 14MB of RAM in System 6 by doing some really, really horrible things; IE, copying the MacOS ROM up to RAM destined to be mapped at the 15MB mark, patching it so it worked there, and using the MMU to map RAM on top of the 24 bit address spaces for the NuBus slots. (I believe to use this software you actually had to rearrange your NuBus cards so they counted down from the top slot, and each card you used knocked 1MB off the maximum RAM you could have.) In principle I suppose you could do something akin to that and relocate the Portable's ROMs upward, but you'll still need an MMU.

(Edit: Someone undoubtedly knows what this software is; again, I read about it *ages* ago and am undoubtedly misremembering details.)

 
Last edited by a moderator:

olePigeon

Well-known member
Virtual Compact from Connectix created a RAM disk, then assigned the Virtual Memory to the RAM disk.  It's a feature they took out of RAM Doubler, which would have been really nice.  There's no option to set which disk as the source for virtual memory, Virtual Compact is the only software I know that does that.

 

Gorgonops

Moderator
Staff member
I stumbled across an Apple KB article that mentions the software I was thinking of: "Connectix Maxima". I gather from related googling that it didn't actually relocate the ROM, it stayed at the 8MB mark, but, depending on how many Nubus cards you had, gave you a second block of up to 6MB of RAM, with the proviso that a single program couldn't use more than 8MB-minus-system-overhead. (You could, for instance, load Photoshop or something into the bottom 8MB with a maximum allocation and then use the multifinder to load some smaller programs into the extended space you'd carved out.)

The fact that this exists does suggest that mapping another, say, 4MB onto a PDS card and using it to run MOAR programs might just be feasable. (Since unlike the compact Macs the Portable actually crams its I/O into a compact space, instead of smearing it all over the top half of the address bus.) You'll need something like a patched version of Maxima to do it, and I'd still say there's likely to be formidable problems with going over the 16MB mark for anything but a RAMdisk. (Unless miraculously the Portable's ROMs are 32-bit clean, as would have to be any software you'd like to run.) If you're *really* dreaming big I suppose you could talk about going with a 68030 (you'll need the MMU) and soft-loading a custom Mac II-caliber ROM, essentially converting the Portable into a PB140-class machine when the accelerator is enabled. I'm sure grafting the drivers from the Portable's ROM into a 32 bit clean ROM image is something BBraun could do over a long weekend. Go for it! :)

 

techknight

Well-known member
Yea, i thought about adding 32-bit RAM past the end of the 16MB bus. Problem is, the ROM obviously isnt 32-bit clean so i dunno how well it would handle a number past 16MB, it obviously wouldnt. So even if I did patch the OS with an extension to include RAM located past the 24-bit address space. 

it would probably barf. 

the Portable's ROM is the macintosh SE rom with portable specific addressing and drivers. Such as the .Backlight, etc.. 

I guess another idea is just like what was mentioned before, Add a GB of RAM, and use it only for a RAM Disk, put a coin cell battery on it so technically it becomes a "pseudo-physical" disk at that point. So in theory, what we have here is an SSD. 

But eh now we are getting all convoluted. 

First things first, get the RAM boards produced and sold. Right now there really doesnt seem to be a whole lot of interest in the RAM, but I havent extended the market to ebay either. 

Once those are sold, i will start work on the 020/030. Start off simple. clock doubled CPU/FPU only for now. 

 
Last edited by a moderator:

techknight

Well-known member
I think its as good as its going to get, I decided to fill the entire RAM as a RAM disk, outside of 2MB. so 7MB RAM disk. and installed system 7.1 onto the RAM disk. 

running perfect, and its keeping on power-off so that means at least I designed the RAM card properly, and its booting system 7.1 really fast off RAM. 

 

trag

Well-known member
, and its keeping on power-off so that means at least I designed the RAM card properly, and its booting system 7.1 really fast off RAM. 
Does the Portable assert that Standby signal that you mentioned?   It may not be worth the power savings, but the SRAM can maintain contents on 1V or something like that (mentioned in the datasheet).  It would require another voltage regulator and a three more CPLD pins and maybe a couple of switching transistors, but you could set the thing up to supply 1V to the RAM when the Standby signal is asserted.  That would reduce the power consumption while the machine is off.  Might also  need a largish capacitor to smooth over the transition between power supplies.

 

techknight

Well-known member
Not worth the effort. I was powering the card on my bench supply alone, and the ammeter was 0.00 so its power consumption at 3.3v is miniscule

 

wilykat

Well-known member
So one cap and a diode would be all you need.  Place a large cap (like 1 farad 5v) across SRAM 5v and ground and a diode from 5v source to the cap/SRAM to prevent cap from discharging through the entire Portable.

 

trag

Well-known member
Not worth the effort. I was powering the card on my bench supply alone, and the ammeter was 0.00 so its power consumption at 3.3v is miniscule
Suspected that might be the case.  SRAM really uses tiny amounts of power.   Still, can't help thinking of unnecessary "optimizations".  :)

Also, not sure if running them on a 1V Vreg would save much power even if the chips used more current.   Since simple Vregs lower the voltage in part by dissipating power resistively to get to a lower voltage, switching from 3.3V to 1V might just move the power consumption from the SRAM chips to the 1V voltage regulator.

 
Top