Here's a question for you. If I manage to map it as system RAM, would it be just as easy/beneficial/efficient to use a RAMdisk utility to convert some of it to a RAM disk, as it would be to have code/firmware that directly allocates some portion as a RAM disk?

Click to expand...

If it's mapped so it shows up to the system as available memory, just using an existing RAMdisk solution would be the way to go. It looks to me like System7 RAMdisk from the Memory control panel stores the settings (presence, size) in PRAM, and on boot the driver loads the settings, builds a disk, initializes and mounts it. Mapping as available memory would be the most versatile and easiest to use out of the box.

Click to expand...

Okay. Thank you. I think I can get it all into memory space. I'll need to read up on the MMU, I guess. How many segments can the MMU remap is the question I need to explore. The Super Slot space is 256MB per slot. So to remap 1 GB of RAM address space into slot space, I'll need to cover four slots. I guess I can do that as one contiguous segment if I use four slots with contiguous address space. The problem is, I don' t think there are four usable slots with contiguous space. I don't want to use slots 9, A, or B because the SE/30 has interrupts for those and treats them as real slots. That leaves 6, 7, 8, ... , C, D, E.

Of course, 768 MB of RAM address space is probably good enough. And I may only use a 512 MB DDR2 DIMM anyway.

However, if for whatever reason not all of it was able to be mapped, but it could be accessed through a mapped register set, then we could make a driver that managed the transfers and present the RAM as a RAMdisk. This is how the Commodore REU's worked. They provided ram, but it wasn't able to be mapped as directly addressable memory due to address space limitations, so there was a register set you banged on to read/write. They also had a few other functions to handle memory copies on the device to avoid going device -> bus -> CPU -> bus -> device, although I'm not really sure a disk driver would be able to utilize that due to File Manager abstraction. In this case, I believe we could potentially boot from the added RAM, if the driver were in the declrom.

Click to expand...

Well, that's interesting/cool. And may be needed, if I end up using a 1 GB DIMM. All kinds of ideas come to mind from your description above. Of course, dreaming is easy; implementing is work. Your mention of booting from the added RAM, suggests the idea of putting a large Flash on the board and storing the OS in it. Have the card copy it to a section of the RAM at power-on, declare the RAM as a RAMdisk, and voila...

Whether to use 512 MB vs. 1 GB depends on whether there are single rank 1 GB DDR2 DIMMs. I'm not going to try to implement multiple ranks, when a single rank is already overkill. But, the price difference between 512 MB and 1 GB is negligible, so if single rank 1 GB DIMMs are available, why not?

As for a development card, I completely agree that throwing more on the card would make it more useful. I was thinking of keeping it simple initially, just to reduce the number of things to debug when something goes wrong, since this is all a learning process. Baby steps and all that. If there was a way to compartmentalize things, that'd satisfy everything I think. A simple flash for the declrom, a register for basic LED and maybe some GPIO accesses, and then the rest for more complex features.
Personally, I'm not terribly familiar with or setup for FPGA dev, and a realistic assessment of my available time would put coming up to speed on that further into the future than I'd like to commit to. On the other hand, I have had some experience with several types of uControllers, like 8051's and ARM (specifically the NXP LPC family), so my bringup time on that would be a little better.

But, that's just me, if other folks are more familiar or up for tackling that side of it, I don't want to hold anything back!

Click to expand...

At this point, you're way ahead of most everyone else, for having done some actual coding. So you're certainly not holding anyone back.

If we could have as many boards as we want, then I would not hesitate to agree that a simple board should be first. However, every revision of the board will represent a fair bit of design effort and probably about $200 in cost. If it could be done on a two-layer board, the cost would be less than half that, but I think I should use four-layers for this and there just isn't a really cheap proto-typing offer for four-layers, as far as I know.

I'm not in any danger of developing either simple nor a complex board in the immediate future so I can just decide when I get there.

I think that it would actually be simpler to design an adapter board to FPGA Starter Kit than it would be to design a "simple" board with address decoding circuitry which will let one read a Flash or EEPROM and light LEDs and maybe read and write an array of flip-flops standing in for a register.

The disadvantage to the adapter board is that then I'd have to program the FPGA for the functionality that would have been on the simple board. But that should be straightforward and allows debugging one thing at a time. Another disadvantage is that the FPGA Starter Kit costs $200. That may be the bigger issue, but if one is going to develop any kind of peripheral, one is going to need something like that eventually. So in the long run, I don't see how spending that money can be avoided. Unless...

Personally, I think that FPGA is a better route to go than uC, because of performance. But, all my adapter board is going to do is connect the PDS pins to the FPGA pins. And something like 40 of those are going to have to travel the remaining distance on twisted pair wire with .1" headers/connectors. The same adapter can probably be made compatible with a uC development board.

So -- do you have a favorite uC development board? If so, what kind of connectors does it have for I/O? I might be able to work something compatible onto an adapter.

I'm used to the 9S12 myself but I think I'd do anything new on ColdFire because it really doesn't cost more than 9S12 except in the teeny tiny realm where I'd probably use an ATTiny anyway. But I'm not going to do any uC development, so I am happy to look at whichever uC you favor.