I'm brainstorming a project for after I finish the PS2 to pre-ADB & ADB adapter. While working on that, and particularly when using the stm32f4discovery board, these cortex-m4 chips with internal clocks in the low hundreds of MHz and GPIO response times of 100MHz, bit banging these old macs should be entirely reasonable.
I've been contemplating the best way to go about working on some of this. My thought is to create a passive development board that has some TTL logic for address decoding that generates a single signal indicating the card has been addressed, and some breakout headers for the bus. The card wouldn't have an MCU on it, just facilitate the development with a separate MCU dev board. Processor agnostic, if you will. It would only support the normal 24/32bit normal slot space, no superslot address range. That only indicates the card has been addressed, if the card needs to decode the specific address within its address space, it will need to do that its self. This is just a signal to indicate the card needs to pay attention to the bus, and can be connected to an interrupt pin on an MCU.
First, Nubus or 030 PDS? I'm kind of thinking 030 PDS, just because that's what I'm familiar with. It seems easier than Nubus in terms of signaling and interfacing, but 1) is faster (more timing requirements), 2) pretty much limits usefulness to the IIsi. The card will in theory fit in an SE/30, but that's not a very good dev machine just due to formfactor.
Second, is there any additional features required for a dev board? The other things I'm thinking that would be nice are: tristate buffers, to assist in keeping the MCU off the bus when it is idle. I'm not sure this is necessary, since the MCU will need to keep the data pins as inputs anyway in order to read data off the bus. The other thing I was thinking of is level converters to do 5V to 3.3V for interfacing with 5V intolerant MCUs. These converters might make tristate buffers a necessity.
For the moment, the MCUs I'm thinking of using are all 5V tolerant, so I'm kind of thinking the initial revision of the card would just include the address decoding logic, and breakout headers. Future revisions could include the level converters and/or tristate buffers depending on interest and future directions.
Is this project along the lines of the one you started a while back with communicating to the 030 PDS? So you would basically be able to tap into the MCU to be able to add extra functionality such as flash storage (emulated SCSI), networking, etc?
Yeah, it would be building on what I did before. With the pre-ADB, ADB, & PS2 adapter, I've learned a little more about PCBs and might be willing to give it another shot. My previous project involved putting a bunch of EPROM storage on the card, and ultimately the routing of all the address and data lines to each of the EPROMs was a problem for me. This would be just the TTL logic from that, and a header.
Depending on other people's interest and whether other people will want to use different MCUs, I was kind of thinking of arranging the headers into two rows of 2, such that you could just plug an stm32f4discovery board onto this one. The headers would still be generically useful for other MCUs, and but it'd be pretty convenient to be able to just plug in this board.
As for what you'd do with it, the intention is to just be a prototyping board for whatever anyone wanted to do with it. Obviously the audience of people interested in hooking stuff up to the internal busses of these machines is fairly small, so if there's anyone else actually going to hack on one and there's something you want to see, speak up!
My thoughts are to first just get a declrom image stored in the MCU showing up to the mac host. This is pretty much the first step of any card, since the ROM will not map the slot space unless a valid declrom is detected. No declrom == bus error whenever accessing the slot. Once that's showing up correctly, start presenting other interfaces. The stm32f4discovery has USB OTG, and there's sample code for a mass storage device, so maybe a bootable USB disk interface.
Once something is connected to the PDS/Nubus, possibilities are kind of endless. It could act as a bridge to a modern desktop, or a raspberry pi (an HDMI video interface for a 68k mac would be interesting).
But that's all pretty far out. This would just be a fairly simple board to facilitate development of things like that. Ideally, having a hobby hackable board would lower the barrier to entry on this stuff, and encourage more people to participate. If not, it's kind of a stepping stone for my personal projects I guess.
That sounds great! I like the idea of leveraging an existing dev board. It would be fairly inexpensive and flexible enough to play around with different ideas. Only thing I am wondering is are there other boards in the family that may have more power or IO that are available in case more features are desired in the future?
I'm not aware of a higher end board in ST's discovery series than the F4. It is unfortunate that the F0 and F4 have different formfactors for their "shield" cards, but the F4 does have about twice the pin count.
I've got a couple raspberry pi's and beaglebone blacks as well. The rpi is neat for some things, has pretty decent linux support, but has limited GPIO pins, and only one PWM pin. The big problem when integrating these with these old systems is they are not 5V tolerant (connecting a 5V signal will toast them), and running linux makes some of the tight timing of these signals difficult to accomplish. Probably the best way to integrate these systems with older macs is either to use something like rs232, or have a bridge interface, like one of the stm32's.
I would love to see a development oriented expansion card. That would be awesome, as I would have this card do numerous things, such as ethernet (using a wiznet chipset, lots of drivers and libraries out there in C.) Maybe even feed back into the sound and on-board MP3 decoding. possibilities are endless?
But as for as mapping the card into address space, I would use PAL/GAL, or at the very least, CPLD, 74 seires logic would work too but you would have quite a bit of it. latches, decoders, etc..
That will allow you to memory map the card to the address bus, and allow the main processor to the STM32.
Now, I know I am way out in the wind now, but imagine if your cortex was running a 68K emulation and had it tied into the bus as an accelerator. that damn machine would fly. 68k at a few hundred mhz. Now of course your limited by bus, but the CPU would cook
A CPLD would definitely be an improvement. I currently just have 74 series logic working with just an EPROM (single 8bits, valid declrom, but that's it), and I was just going to reuse that logic for the time being. The main disadvantage is board space.
And yeah, I have thought about doing an accelerator with emulation. I'm a ways off on making something like that happen, so far I've just got simple data reads & writes, not even IRQ or DMA. There's a lot more for CPU replacement though... It would be neat, and it seems like a simple dev board would be the first (tiny) step in that direction.
So, I can see this thread has been dormant for a while. Is there anything happening offline with this dev board idea?
While I know I'm well out of my depth, I'd like to drop a thought or two here for your consideration. Shoot them down or run with them as you see fit.
IMO, the ideal general-purpose dev board would be one that can be used across all varieties of 68k PDS and Nubus. This would give everyone a chance to work on their favourite platform, bringing in more developers: and being able to spread the cost of the dev card across more users would help with pricing. Both of those factors would work together - cheaper cards, more devs: more devs, more cards sold: more cards sold, more development happening.
With a CPLD on board, this might just barely be possible:
If the card edge has 120 (40x3) solder holes, it would be possible to physically connect to Nubus and all the EuroDIN-96 varieties of PDS. Possibly also, with the right socket/plug, or card-edge design, to those that don't use a EuroDIN like the Quadra PDS.
(1) Power and ground lines could be physically re-mapped with jumpers: address and data lines via the CPLD. In this way, one card fits all.
(2) Or, alternatively, a simple adapter made up which remaps each PDS's pinout to an arbitrary "platform neutral" configuration, like the old Daystar cache adapters to the IIci pinout.
A board just big enough to remap the lines, mount a fine pitch double sided card-edge socket (040 or 601 PDS pinout maybe?) on the upside for mounting the dev card, and a EuroDIN 96 / 120 on the downside.
If the CPLD is on the dev card, rather than said adapter, only power and ground lines would need to be physically remapped.
(1) is probably cheaper overall, while (2) is probably more disaster-proof, in that you're not running the risk of your power/ground lines being cross-patched by accident.
I haven't messed with any of this in a while, but one could consider the board I made for SE video a step in this direction. Basically there's nothing application specific there, it's really just a PDS to stm32f4discovery adapter board.
My next step was to start playing with CPLD's. I did a bunch of looking at them a while back, and there's not many that are 5V tolerant. After looking at the different options, I think I had settled on the same CPLD family bmow uses on the floppyemu. Basically anything 5V tolerant is pretty much legacy at this point, but the manufacturers that continue to produce the legacy parts seem to have consolidated down to a couple long-life families.
Hi...i am a new user here. As per i think the idea of leveraging an existing dev board is great. It would be fairly inexpensive and flexible enough to play around with different ideas. Only thing I am wondering is are there other boards in the family that may have more power or IO that are available in case more features are desired in the future?