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

SE and SE/30 accelerators--discussion of new hardware development

ZaneKaminski

Well-known member
In this first post, I will articulate my vision of accelerator cards for the SE and SE/30. What follows is a bit verbose, but hopefully this proposal will lead us to a finished product. I plan to start developing this thing in a few months. Right now, I'm trying just to gather more information.

Anyone with a suggestion for functionality or implementation, please supply it. I want to make the right thing the first time haha.

Function of an Accelerator

An accelerator holds the main CPU in reset (puts it to sleep) and supplies another (faster) CPU, which I'll refer to as the "accelerated CPU." Now, the main hurdle to overcome with these accelerators is that even with a faster CPU, the rest of the board can't handle the increased clock speed, and moreover is impossible for a PDS card to change the system clock or processor bus clock. The way to do so would be to change the onboard crystal oscillator, and except in special cases (e.g. IIsi), that would not work. As well, on the 128k through SE, the same oscillator drives the video and the CPU, so changing it would screw up the display timing.

So we have established that the original processor bus and accelerated CPU must reside in separate "clock domains." Therefore there must be some synchronization logic that allows a faster processor to interface with a slower bus while also providing an increase in performance. This synchronization is to be implemented in some "glue logic" residing in an FPGA or CPLD (basically a programmable piece of hardware) sitting "between" the new CPU and processor bus/PDS.

Now, the simplest way to achieve the requisite synchronization between the accelerated CPU and the stock processor bus would be to, when the accelerated CPU accesses memory (to fetch an instruction or to load/store data), perform that access at the speed of the stock bus, forcing the processor to wait until the slow access has been completed. This is all fine and good, but with a 68000 (which has no onboard instruction or data caches), this strategy wouldn't yield an increase in performance! Indeed, if the accelerated clock is not a whole number multiple of the bus clock, it will actually slow the computer down! Doing this with an '020 or '030 would yield a slight increase in performance, since these chips have (small) onboard caches, but this approach would not nearly be fast enough. So there must be a cache of main memory on the accelerator board, so that most of the time, the accelerated CPU does not need to access system memory, and instead can pull the data at high-speed from its onboard cache.

Now, all vintage accelerator boards have some cache, usually implemented as 64k or so of high-speed SRAM. This is all well and good, but at some point, there will be a "cache miss," i.e. the data requested will not be present in the cache, and so the CPU must wait for the access to be performed at low-speed. And then, if the cache is full, some data must be "evicted," and maybe your program was just about to use that data, and then it would have to wait again... So an effective caching strategy must be implemented. The situation is similar for writing, with one notable exception. Every instruction must be fetched from RAM (ignoring onboard caches of the '020+), so the effect of slowing the writes would not be as bad, since it would not affect every instruction executed. Still, we can do better.

So in order to design an effective caching strategy, we must understand which devices in the Macintosh can act as a "bus master," i.e. access RAM, and we must also note that there are peripheral devices which have control registers mapped into the address space. The values in these registers cannot be cached. Okay, in the 128k through SE, there are basically two bus masters: the CPU, with R/W access, and the "Burrell logic" servicing the sound and video, which only reads from memory, never writes. For the SE/30, the only bus master is the CPU. The video is fetched by an independent circuit that ticks along in phase with the 16 MHz pixel clock and fetches data from the "read side" of some dual-ported VRAM. (Though how is the sound data fetched? Maybe I'm wrong about the SE/30.)

Caching Strategy

Firstly, when 128 Mbytes of DDR2 or DDR3 costs 5 or 6 bucks, there is no reason not to cache the entire main memory of the Mac as well as the ROM. We could spend a long time developing and tuning a cache eviction strategy that works well for Macintosh, or we could just cache the whole memory and be done with it.

So when reading, we can refer to the high-speed cache of main memory/ROM, but not for the peripheral registers. Those cannot be cached, since they change with the state of the peripherals, so the accelerated CPU must wait for them to be accessed at low-speed. No big deal. Only thing is that the at first, reads of the ROM (and maybe RAM too) would be considered "cache misses," in that when the Mac and accelerator card are booted, the card's cache is empty. So the cache would need to be filled first with at least the contents of ROM. No point maintaining a table of which cache entries are valid; just make sure the cache is correct when the accelerated CPU begins operating. Only gotcha is that I think the Macs rearrange the memory map during boot, so the cache logic must be sensitive to that. Or we can maintain page tables and valid bits and that sort of thing to keep track of which cache entries are meaningful, but I prefer the entire cache to be valid at all times. 

Writing follows a similar reasoning but is more complicated. The 128k through SE store their framebuffers in main memory, so writes to this area must occur at low-speed. However, for the SE/30's entire main memory, and for all of the rest of the memory of the 128k through SE, writes don't even need to be stored in RAM. As long as the data stored by the accelerated CPU is maintained in the cache, it doesn't matter if that data is duplicated in the main memory, since nothing can access it. This isn't true of the SE/30's VRAM. Obviously if we want the display to ever change, we must actually write to the onboard VRAM. The peripheral registers must be written to as well. Now, we can perform a further optimization when writing to video memory and peripheral registers. We can queue one or more writes to the peripheral registers and VRAM, so that the processor doesn't have to wait for the operation to be completed unless the write queue is full. Therefore several write operations to video or peripherals can be performed serially with no penalty, and then the accelerated CPU can go on to do some arithmetic or logical operations while the values are actually being written. The only catch is that, when reading the peripherals, it must be ensured that all pending write operations have completed. VRAM can be cached and only the CPU can change it, so we can refer to the cache when reading VRAM immediately after a VRAM write operation has been queued for. This functionality about the write queue should be somewhat configurable, in terms of the size of the queue and whether it is enabled at all.

Hardware Implementation

For the SE, the best solution is an FPGA implementing the cache/glue and a 68000 soft core. This will provide the lowest cost, unless you insist upon an authentic 68k series chip. The ao68000 project is apparently is fully tested and runs in an Altera Cyclone II (somewhat of an older model) at up to 82 MHz. It's pretty easy on the FPGA resources, too! The creators note, however, that some instructions take longer to execute in their core than a true 68000. Whatever, with the accelerator card, the CPU doesn't have to contend with the "Burrell logic" making the processor wait (that would only slow down video/peripheral writes), so I'll call it 10x faster. Maybe the newer Cyclone V series can run it at an even higher clock speed, I dunno exactly.

For the SE/30, I think we want a 68030 at 50 MHz, and maybe a 68882 FPU (though it's not necessary; the existing one can be used, albeit at low speed, or we can try and get a soft core for it). An FPGA would still implement the cache and glue logic, but a physical 68030 would be more readily doable than a soft core, which I'm not sure about the existence of. We could do an '040, but I believe the 68040 accelerators for '030 machines have some software compatibility issues. (Maybe relating to the larger cache of the '040? Or something relating to the pipelining? I can't remember.) The other option is to try and utilize this new Apollo "68080" core. I dunno if they'll let us have it, but that would certainly make for the fastest SE/30 ever. And if they let us use their core, that would certainly lower the cost of the card. Here's the link for the Apollo: http://www.apollo-accelerators.com/files/Apollo_datasheet.pdf

Software Compatibility

Plug and play. There's nothing more to say. A well-designed accelerator like I have described is completely transparent to the peripherals and the video logic and all that. It's like running your emulator of choice at 8x speed. The system is completely usable. Animations are (well, should be) rendered during the vertical blanking interval, which still will occur every 1/60 seconds. The difference is that a lot more instructions can be executed between each frame. Go try it in Mini vMac if you have any doubts. The original Macintoshes had deterministic instruction execution timing, but with the caching architecture of the 68020+, routines with exact timing are basically impossible. So we don't need to worry about software compatibility too much.

More Cool Stuff

Well, we oughta choose an FPGA with some resources to spare, and integrate some other useful features onto the board as long as it will not be too costly: USB (mass storage, human interface device), VGA, stuff like that. VGA in particular is trivially easy with an FPGA. We can figure out how to make it work later. Driver software will have to be developed for the Mac OS in order to support these features. Talked about also was the possibility of an open-source reimplementation of the Micron Xceed.

Another benefit of this approach is that we can change out the contents of the ROM whenever we like.

With the caching strategy I have described, we can max out the memory of the machine, even when only the minimum is installed.

Aaaaand we can also switch between the accelerated CPU and the stock one at will, though the stock one would be bound to use the installed ROM. I will leave the algorithm for that as an exercise for a savvy reader; it is possible by hooking into the vertical blanking interrupt (in software) and reset vector of the processors.

 
Last edited by a moderator:

Reasons.

Well-known member
I'm really interested in these types of projects. There are a lot of high-value accelerator, video, or ethernet cards that are very rare and expensive for the non-obsessive collector. I'd love to have a reliable and well-researched method of creating new expansion cards for older Macs. Anything to end the shortage of SE/30 accelerators and video cards. A question: what's the price range we'd be looking at on these, do people think? I'm sure there's a fair number of Amiga-world analogs, but I'm not down that particular rabbit hole yet. 

 

techknight

Well-known member
I skimmed through your novel but I didn't read it all (too long!). Please keep it short and simple, ive got old floater-ridden eyes.  

The Accelerator card puts the bus into a mastering state. it handshakes with the on-board CPU and tells the CPU that it is now the bus master. the CPU will tri-state, as far as I am aware, the macintosh is always in this state when the accelerator is installed and operating. 

As far as the bus speed is concerned thats not important. The CPU will allow a certain number of wait states during bus transactions. But since the RAM, and ROM and all other peripherals are on the same slow bus, a high speed CPU will have no purpose by itself because its spending all of its time in bus wait states waiting on the bus. 

So, an accelerator usually has to have instruction cache on board to speed things up, and some accelerators even have the RAM on board which is full width and high speed. it would even be a good idea to cache ROM as well and override the ROM's address location with the shadow copy in accelerated RAM. How to do this I dont know. logic? 

Also, the 32-bit CPU will be speaking on a 16-bit bus (68000 only), and therefore you'll spend alot of time sending 32-bit longwords with 2 bus cycles on each fetch. the old LC and LCII did this and was super slow because of it. it wasnt until the LCIII came along when they introduced full bus width. Anyways. 

Oh and also, on a 68000 based system, there is the synchronous bus (E/VPA/VMA) system thats used to talk to VIAs and other peripherals. so when accelerating the SE, you need to implement this in pure logic replacement. 

The macintosh portable is a hybrid in which it implements half of it in the GLU, but its still using VPA/VMA somehow on the main CPU, which is where I stalled in development of an accelerator for that. 

I really want an accelerator of some sorts for the Mac portable. 

 
Last edited by a moderator:

techknight

Well-known member
You know, if you could make a fast accelerator with on board ethernet/wifi, and maybe even a DSP of sorts for web acceleration that would be cool as hell. Render the modern day internet from a browser on an SE/30 by using the FPGA to render the HTML/Scripting. 

 

Anonymous Freak

Well-known member
You know, if you could make a fast accelerator with on board ethernet/wifi, and maybe even a DSP of sorts for web acceleration that would be cool as hell. Render the modern day internet from a browser on an SE/30 by using the FPGA to render the HTML/Scripting. 
Where is the "favorite" button when you need one?!?

I would pay $100 easy for accelerators like this for the SE/30, LC PDS, and PowerBook 5x0 series!

Hell, NTC just came out with the "CHIP" single-board computer that has 4 GB storage, 512 MB RAM, WiFi, and Bluetooth - for $9.  If they can make such an SBC for $9, building the 'glue' to connect such a system to a Mac should be possible for $90, I would hope.  

 

ZaneKaminski

Well-known member
I'm really interested in these types of projects. There are a lot of high-value accelerator, video, or ethernet cards that are very rare and expensive for the non-obsessive collector. I'd love to have a reliable and well-researched method of creating new expansion cards for older Macs. Anything to end the shortage of SE/30 accelerators and video cards. A question: what's the price range we'd be looking at on these, do people think? I'm sure there's a fair number of Amiga-world analogs, but I'm not down that particular rabbit hole yet.
Some costs depend on quantity, while others don't. I can't say exactly how much it will cost, but I'll break it down:
  • PCB (printed circuit board): 6+ layer PCBs of good quality can be a bit costly in small volumes. To produce 10 6-layer boards of the right size might be $60 each. In quantities of 100 or so, the cost might be only $20.
  • 68030 and 68882: 50 MHz 68030? sounds costly, no volume discounts either. Could be $100 for both.
  • FPGA: In single quantities, something quite capable would be $30 or so.
  • DDR2 SDRAM: $5 for 128 Mbytes. Maybe we actually need 256, I dunno.
  • PDS slot (male and female): does anyone even make it anymore?
  • lots of other little crap: decoupling capacitors, misc resistors, inductors, ferrite beads, buffer ICs, voltage regulators, external connectors... quite a bit more cost lies here, maybe even $50.
  • Assembly: might be difficult to do yourself. Expensive to have done robotically unless you're producing 100+.
So unfortunately, it may be cheaper just to buy one a DiiMO 030 card for 200 bucks haha. I am gonna attempt this because I want to implement an FPGA in a design, and what cooler to do than an SE/30 accelerator? I'm a senior studying mathematics and computer science at The Ohio State University, and I'd like to add some more EE-type stuff to my resume and portfolio. So a well-designed PCB with an FPGA and some other neat stuff fits the bill.
I skimmed through your novel but I didn't read it all (too long!). Please keep it short and simple, ive got old floater-ridden eyes.

The Accelerator card puts the bus into a mastering state. it handshakes with the on-board CPU and tells the CPU that it is now the bus master. the CPU will tri-state, as far as I am aware, the macintosh is always in this state when the accelerator is installed and operating.

As far as the bus speed is concerned thats not important. The CPU will allow a certain number of wait states during bus transactions. But since the RAM, and ROM and all other peripherals are on the same slow bus, a high speed CPU will have no purpose by itself because its spending all of its time in bus wait states waiting on the bus.

So, an accelerator usually has to have instruction cache on board to speed things up, and some accelerators even have the RAM on board which is full width and high speed. it would even be a good idea to cache ROM as well and override the ROM's address location with the shadow copy in accelerated RAM. How to do this I dont know. logic?

Also, the 32-bit CPU will be speaking on a 16-bit bus (68000 only), and therefore you'll spend alot of time sending 32-bit longwords with 2 bus cycles on each fetch. the old LC and LCII did this and was super slow because of it. it wasnt until the LCIII came along when they introduced full bus width. Anyways.

Oh and also, on a 68000 based system, there is the synchronous bus (E/VPA/VMA) system thats used to talk to VIAs and other peripherals. so when accelerating the SE, you need to implement this in pure logic replacement.

The macintosh portable is a hybrid in which it implements half of it in the GLU, but its still using VPA/VMA somehow on the main CPU, which is where I stalled in development of an accelerator for that.

I really want an accelerator of some sorts for the Mac portable.
I admit, I have not studied the 68k series in depth, so I don't know exactly how to handshake with the CPU (I assumed the 68000's reset pin was just broken out in the PDS header), but I've built a wavetable synth with VGA video output in an FPGA before, so this couldn't be too hard. There is some discussion in my original post about what I figure would be the optimum caching strategy.
My thought was to just have a cache of the entire RAM and ROM. Why not? It's cheap.

Also, just to clarify, I decided against trying to get an '030 or '020 into an SE. An FPGA soft core replacement would be much faster and more straightforward.

Are you saying that the 68000 peripheral bus doesn't have the concept of wait-states, so I have to emulate the peripherals? That's annoying but probably not a deal-breaker.

You know, if you could make a fast accelerator with on board ethernet/wifi, and maybe even a DSP of sorts for web acceleration that would be cool as hell. Render the modern day internet from a browser on an SE/30 by using the FPGA to render the HTML/Scripting.
I thought about adding ethernet to the Mac system itself, but I figured it would be best to allow the user to put a second card in. Ethernet driver sounds like a big impenetrable problem. Same with the DSP. Neat in theory but the software work required would be massive to make it useful.
However, you could get an FPGA with an ARM processor and run a browser on that, rendering it to memory that a quick and dirty Macintosh program can display. The 512-wide display would work well with mobile sites.

 
Last edited by a moderator:

ZaneKaminski

Well-known member
So in sum, my desire to make a halfway affordable (for me and everyone else haha) accelerator is in strong competition with my desire to over-design it and give it WiFi, Bluetooth, USB, fast ARM coprocessor, etc. Ain't nobody got time to implement all that anyway! Haha another CS or EE student who wants to prove their mettle by contributing something could volunteer

 

bdurbrow

Well-known member
The thing about FPGAs is that they take a substantial amount of time to start up - not enough for a human to notice, but very much enough for a CPU to notice (so, your main Logic Board is going to be part way through it's boot process when the FPGA comes online). Also, most of them run at 3.3v these days.

CPLD's, because of their internal design, are "instant-on"; and are also still available in 5v compatible versions. So, I'd probably look at using a CPLD as the bus interface.

FPGAs with built-in ARM processors are expensive... so what I would probably be looking at is an optional outboard processor if one wanted to go that route... perhaps one of the Raspberry Pi versions or a competitor.

I would leave some extra footprints for adding an additional FPGA as well, cross-connected to the main FPGA with a high-speed serial link.

Likewise, any unused IO should be routed to a header, that could be connected outside the case.

For ease of development; I'd also make sure that the programming headers (JTAG, etc) were accessible with the case closed.

The PDS card interface is a Euro-DIN standard connector; and is still available.

You will need the 68000 processor manuals (currently available from NXP):

http://cache.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf

https://www.nxp.com/files/archives/doc/ref_manual/M68000PRM.pdf

http://www.nxp.com/files/32bit/doc/ref_manual/MC68030UM-P1.pdf

http://www.nxp.com/files/32bit/doc/ref_manual/MC68020UM.pdf

You will also need the full Inside Macintosh set; and Designing Cards and Drivers for the Macintosh Family.

http://www.macintoshrepository.org/1235-designing-cards-and-drivers-for-the-macintosh-family

The second edition can also be found here:

http://dec8.info/Apple/Designing_Cards_and_Drivers_for_the_Macintosh_Family_2ed_May90.pdf

This manual also has information on how to create a video device that QuickDraw will see.

I am monkeying about with trying to get an ESP8266 to relay IP packets via a SLIP link; if you leave a pad for one and connect up it's IO to the FPGA one could, in principal, create a serial port in the FPGA and send packets out that way (otherwise, one would have to tie up either the modem or printer port).

:)

 

techknight

Well-known member
Are you saying that the 68000 peripheral bus doesn't have the concept of wait-states, so I have to emulate the peripherals? That's annoying but probably not a deal-breaker.
I am not certain where you saw that in my post? the 68000 by itself has wait states, using the DTACK. as with any 68K CPU. 

But the 68000/68010 have a Synchronous bus as well as the Async bus. the 020 on up does NOT. so a base 68000 system would need E clock and VPA/VMA (Valid Peripheral Address/Valid Memory Address) Emulation in logic if you were to use a 68020+ Core. This has been done already with some schematics of accelerator boards out there. 

But I am sure if your using a softcore, someone hasnt already "added" a syncro bus to the 020+ softcores to make things easy. The mac decided to use the Syncro bus for the VIAs, maybe SCC so it is required. All other peripherals as far as I am aware of do not. 

Also another thing to make note: The 68000 and 68010 have Upper and Lower Data strobes. As they are a 32-bit CPU that uses a 16-bit BUS. (UDS/LDS). the 68020+ does NOT have this. they have A0, A1, SIZ0, SIZ1 control lines. 

So to use a 68020+ on a 68000 bus you need to build converting logic that converts the CPU to use a 16 bit bus. youll need decoder logic to build UDS/LDS from A0/A1/SIZ0/SIZ1. It also must compensate for Even/Odd alignment offsets. Again I think this was discussed in an accelerator document. 

I have a thread somewhere here on building an accelerator for the macintosh portable, and the documents that explain everything you need were linked in there. 

Sure the easier route would be just use a faster 68000. Problem with this approach is software that requires the 68020+ which in my case, is the CFM68K which needs an 020+ :( This is the reason why I wanted to shoehorn an 020/030 in a base 68000 mac portable. 

The ultimate approach would be a mutated softcore. a 68020 instruction ALU, with a 68000 compatible bus. Which technically what I stated above when using a real CPU, would do that. but in FPGA/VHDL it would probably be far far easier just to mod the softcore. 

For pre-existing 68020/68030 systems like the SE/30, then the softcore-to-bus attachment is pretty much direct at that point. as its identical. 

 
Last edited by a moderator:

techknight

Well-known member
The thing about FPGAs is that they take a substantial amount of time to start up - not enough for a human to notice, but very much enough for a CPU to notice (so, your main Logic Board is going to be part way through it's boot process when the FPGA comes online). Also, most of them run at 3.3v these days.
That doesnt matter. the RESET line is broken out to the PDS slot, so you can just hold the system in RESET until the FPGA comes up. Then release the RESET line, and go into bus mastering mode from that point. 

 

ZaneKaminski

Well-known member
Yes, I see now, techknight, after looking at some of the 68k timing diagrams. It doesn't look very hard to implement the synchronous bus. I meant that the synchronous peripheral bus seemingly cannot be stalled by the slave not asserting /DTACK like the asynchronous memory bus can be.

I think I'll start with the SE/30 accelerator; my SE is very screwed up and awaiting (an attempted) restoration. My SE/30 needs work but is much closer to the proper condition for such a project.

Thanks for the tip about using CPLDs, bdurbrow. I forgot to consider the 3.3 V to 5 V level shifting necessary when using 3.3 V glue logic... man, what a pain. That's a ton of lines that must be shifted, and then the shifting for the data bus has to have some bidirectionality. The problem with using a CPLD, however, is that none embed a hard DDR2 controller. I'll think about how to have a CPLD running at 5 V handle the bus interface, and then an FPGA can do the RAM/ROM cache and embed any soft cores. That should halve the amount of level shifting that must be done.

I think I will make a card that will go in the back panel of the SE (/30) and break out JTAG, VGA, USB, and some GPIO usable for USART, etc. I may also try to clone the back panel card for the SE/30 ethernet card onto it as well if space allows. Like I said, I can't implement all of this stuff, but hopefully someone else will make use of my work.

Looking at the "designing cards and drivers" document (very helpful, thanks), I see that the SE and SE/30's architecture encourage DMA transfers by peripheral cards. I've gotta make sure the glue logic is sensitive to DMA transfers occurring on the main bus, to ensure that any additional peripheral cards work well. That may also make it difficult to max out the ram using the DDR2 cache.

Edit: actually scratch that about cloning the "easy half" of the ethernet card. It would be better to just figure out the SLIP link, as long as configuring System 6 for that is easy.

 
Last edited by a moderator:

techknight

Well-known member
I wish you luck on your project, I would love to see this come through! because mainly the macintosh portable, someway to adapt to that system would be the most awesome nerdgasm for me. lol. 

as far as DMA, very little uses it on these machines. I dont recal anything using it on the SE/30, or Portable as they have separate video hardware. But just in case (external peripherals), just follow the bus mastering rules of the 68K you will be fine. Once someone or something toggles BREQ, you have to drop control until it becomes available again. Just tristate the softcore bus connections. the RAM/ROM on the card will always stay connected on the bus as accessable as another device may access it. its the CPU that lets go. 

On the portable, it has a base 1MB of RAM. Cant override that with an accelerator unless you removed the transceiver buffers otherwise you would have bus contention. Which makes me wonder how they do it on the SE, or SE/30. if the RAM isnt installed I guess it doesnt matter as there are no D buffers for SIMM cards as far as I can tell. 

if you can override the entire RAM map with the accelerator's DDR, that would make things way way faster. But things could get nasty because now you have to pay attention to overlay. First powerup, ROM sits where RAM normally does. Once a bit is set in an SFR, the RAM/ROM Swap back. Exactly how that works I dont honestly know. Steve Chamberlin (bigmessowires) who made the plus clone in an FPGA could probably tell you exactly how, and when it does and comes into play. 

 
Last edited by a moderator:

ZaneKaminski

Well-known member
Well, the issue with PDS cards using DMA is that I wanted to max out the ram of the machine using the DDR2 cache. Cards designed for an SE/30 won't be able to operate at the 50 MHz bus speed of the accelerated CPU, so they need to go onto the main bus. But then there will be a problem if the cards try to address memory that exists in the accelerator memory domain but not in the machine itself. I could add another CPLD to establish a third 16 MHz bus, in addition to the 16 MHz and accelerated ones, but I'm already afraid this project will be way too expensive.

I wanted to use the ethernet card in addition to the accelerator, but working out the issues with supporting another PDS card strikes me as more troublesome than just sticking a $10 WiFi module on the board and getting the Mac OS to relay the packets as you described. No second PDS = cheaper board. Maybe I can even get it done in 4 layers then, but DDR2 with only 4 layers would be difficult.

I'll refine my ideas about exactly how to do it and then write up a more formal proposal/spec for an SE/30 card in the coming months.

 
Last edited by a moderator:

olePigeon

Well-known member
I have a question, though.  If you design it specifically to work with an SE/30, will it also work (with an adapter) in a II, IIx, IIsi, IIcx, and IIci?  I know that the DayStar accelerators were compatible with most of the Macintosh II line of computers, but required an adapter on anything other than a IIcx or IIci.

 

bdurbrow

Well-known member
Although it might be possible to create an adapter for use on a machine other than a SE/30, it would probably be easier to just modify the board layout to interface to the other types of PDS slots.

Trying to do a NuBus interface adapter however, would be quite tricky... and likely have some incompatibility issues (for example, way back when, we had a Radius Rocket in a Mac II which was a 68040 accelerator in a NuBus slot; and anything that used sound tended to be buggy). It would be much easier, I think, to modify the FPGA/CPLD programming for the accelerator card to interface natively across the the NuBus, rather than trying to adapt a PDS interface to the NuBus.

:)

 

ZaneKaminski

Well-known member
I have a question, though.  If you design it specifically to work with an SE/30, will it also work (with an adapter) in a II, IIx, IIsi, IIcx, and IIci?  I know that the DayStar accelerators were compatible with most of the Macintosh II line of computers, but required an adapter on anything other than a IIcx or IIci.
Not immediately, I don't think so. The caching strategy I articulated earlier was created with the SE/30's memory map in mind... I didn't consider NuBus, for example. I do know that the SE/30 PDS differs slightly from the PDS on other 68030 machines. However, only some '030 machines have a PDS--not the entire Mac II series. So it's unclear how applicable my work would be to other machines.

Also the card would probably be too tall for the Mac II series. Maybe I will be able to do it with just a soft core in the FPGA. That'd be good in terms of cost, and then it could be short and possibly fit into the Mac II series as well as the SE/30.

Although it might be possible to create an adapter for use on a machine other than a SE/30, it would probably be easier to just modify the board layout to interface to the other types of PDS slots.

Trying to do a NuBus interface adapter however, would be quite tricky... and likely have some incompatibility issues (for example, way back when, we had a Radius Rocket in a Mac II which was a 68040 accelerator in a NuBus slot; and anything that used sound tended to be buggy). It would be much easier, I think, to modify the FPGA/CPLD programming for the accelerator card to interface natively across the the NuBus, rather than trying to adapt a PDS interface to the NuBus.

:)
Well, the "PDS interface" you speak of is really just the processor bus, used to interface with RAM and peripherals. So no matter how you slice it, there has to be some logic for adapting that to NuBus that seems like it would be very similar either way. The difference would be in the packaging, whether it was in the main FPGA, a separate unit on the accelerator board, or a separate adapter card.

 

Elfen

Well-known member
I have a question, though.  If you design it specifically to work with an SE/30, will it also work (with an adapter) in a II, IIx, IIsi, IIcx, and IIci?  I know that the DayStar accelerators were compatible with most of the Macintosh II line of computers, but required an adapter on anything other than a IIcx or IIci.
That adapter went on to the machine's '030 CPU Socket, which most had. There were a few that had the CPU soldered in, so you were out of luck on those systems. My Original SE\30 Logic board is socketed but, its replacement board has the CPU soldered in. My Original SE\30 I could not bring back to life (Jail bars and so on) after a recap so its on the side until I get the energy (or money) to fix it.

Some older Mac 512/Plus/SE 68K Accelerators had a 68K in either 12MHz or 16MHz that plugged into the 68K (which had to be removed and a socket put in or use a "Kelly Clip". There was some support circuitry, but it seemed that the clock signal was at the higher speed for the CPU and not the rest of the board.

Higher End Accelerators for these machines using the '020 or '030 was basically a Second Mac with its own ROM and RAM and talked to the Mac and swapped the VRAM Information between the machines. There was no direct take over the 68K with these Accelerators as the 68K was needed to run with the Accelerator to swap information with. This is why there was a Control Panel to turn on/off the Accelerator by software.

 

olePigeon

Well-known member
They DayStar 040 used the PDS slot.  I am aware of other accelerators that used the socket as you described, though.  They're pretty rare.

 

ZaneKaminski

Well-known member
Wow, look at this: http://www.digikey.com/product-detail/en/freescale-semiconductor-nxp/MC68030FE16C/MC68030FE16C-ND/1167296

166 MHz 68030! !!!! I didn't know one existed that fast. Now that would make for a mean SE/30. '040s never went faster than 40 MHz. I still think that the soft-core route would be best though. Hard '030 => twice the amount of 3.3V-to-5V level-shifting circuitry and requires a larger FPGA with more I/O. Smaller board means a cheaper product.

The Apollo folks seem to be able to get their Amiga accelerators out the door for under 150 Euros

 
Last edited by a moderator:
Top