That's very exciting work bbraun. I see the limitations you mentioned, but that's still a lot further at programming low level stuff than any of the rest of us have gotten. It's cool you actually did the programming.
NuBus and PDS do look the same from the Slot Manager's point of view -- or they do as long as PDS hardware uses the correct interrupt for the slot address space it is decoding.
From a hardware point of view, it is much easier to interface to the PDS slot than it is to the NuBus uh, bus. With PDS the address and data buses each have their own signal lines. NuBus sends both addresses and data over the same 32 signal lines, so some intelligence and muxes are needed to route the signals on the DA (AD?) signal lines to the address or data circuitry on the expansion card.
DDR2 memory is so cheap, it's cheaper than a usable quantity of any other kind of memory one could use at this time. And in it's cheapness, it comes in a 512MB or a 1GB chunk.
So, there will be hundreds of MB of DDR2 RAM running at a data rate of 250 MHz - 400 MHz (hoping for 333MHz) sitting there unused after the Frame Buffer gets its allotment.
I think the easiest thing is to map the excess as system RAM.
But it had occurred to me to devote some chunk of it to a RAM disk.
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?
I don't know enough about how RAM disks are created to even know if I'm stating the question clearly. If that doesn't make sense, let me know and I'll try to be more clear about what I'm asking.
Going this route is a tradeoff.
Option 1) Having a simple board which just maps a Flash (for declaration ROM) to a fixed address and maps some LEDs to various fixed addresses would be very simple and easy to use and require very little background on the user's part.
However, it is also of limited utility. You can only do the things that you've already designed into the board. Write to addresses on the card and make the LEDs light or go off, etc.
Option 2) Having an FPGA Development Board interfaced into the PDS (or NuBus) slot would be extremely versatile because all of the resources on the Development Board could be made available to the host Mac's address space, and reconfigured as needed. However, it would be more complicated to use and would require the user to have some knowledge of a Hardware Definition Language (typically VHDL or Verilog).
Option 2 would be more expensive than Option 1, but much more useful. But not immediately useful to someone who isn't familiar with FPGAs...
Anyway, I've touched on some of the things you've discussed. I could write a bunch more, but I don't want to hijack your thread too far.
Excellent work!
NuBus and PDS do look the same from the Slot Manager's point of view -- or they do as long as PDS hardware uses the correct interrupt for the slot address space it is decoding.
From a hardware point of view, it is much easier to interface to the PDS slot than it is to the NuBus uh, bus. With PDS the address and data buses each have their own signal lines. NuBus sends both addresses and data over the same 32 signal lines, so some intelligence and muxes are needed to route the signals on the DA (AD?) signal lines to the address or data circuitry on the expansion card.
It could go a number of directions. First, I just want to get it working as a video frame buffer -- actually first I just want to get to the point where I build some hardware... I still have a few other projects in the way -- like the PEx ROM. All the stuff I've posted here has been the early concept/design iterative loop.
DDR2 memory is so cheap, it's cheaper than a usable quantity of any other kind of memory one could use at this time. And in it's cheapness, it comes in a 512MB or a 1GB chunk.
So, there will be hundreds of MB of DDR2 RAM running at a data rate of 250 MHz - 400 MHz (hoping for 333MHz) sitting there unused after the Frame Buffer gets its allotment.
I think the easiest thing is to map the excess as system RAM.
But it had occurred to me to devote some chunk of it to a RAM disk.
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?
I don't know enough about how RAM disks are created to even know if I'm stating the question clearly. If that doesn't make sense, let me know and I'll try to be more clear about what I'm asking.
As for a simple Mac development card, we could whip up something which maps certain bits at certain addresses to some LEDs or some such. However, I think the easier and more useful thing would be to create an adapter board from PDS (or NuBus) to one of the FPGA Development Boards. The FPGA Development Boards (Starter Kits) typically have a bunch of LEDs on board (e.g. 8) , some pushbutton switches, serial ports, parallel Flash, serial Flash, ethernet PHY and often a small LCD display.
Going this route is a tradeoff.
Option 1) Having a simple board which just maps a Flash (for declaration ROM) to a fixed address and maps some LEDs to various fixed addresses would be very simple and easy to use and require very little background on the user's part.
However, it is also of limited utility. You can only do the things that you've already designed into the board. Write to addresses on the card and make the LEDs light or go off, etc.
Option 2) Having an FPGA Development Board interfaced into the PDS (or NuBus) slot would be extremely versatile because all of the resources on the Development Board could be made available to the host Mac's address space, and reconfigured as needed. However, it would be more complicated to use and would require the user to have some knowledge of a Hardware Definition Language (typically VHDL or Verilog).
Option 2 would be more expensive than Option 1, but much more useful. But not immediately useful to someone who isn't familiar with FPGAs...
Anyway, I've touched on some of the things you've discussed. I could write a bunch more, but I don't want to hijack your thread too far.
Excellent work!