mac portable accelerator

[bigmessowires]

What functions do you need to implement inside that CPLD? 144 macrocells is not much by today's standards, but if it's purely for address decoding it should be more than enough. 

You might also consider using a level converter chip and a more modern 3.3V-only CPLD. The XC9500XL series is kind of old and crusty, and not the cheapest if you're worried about costs. The chips run at 3.3V but have 5V tolerant inputs (supposedly), but the 5V tolerance only applies once the supply voltage has reached some minimum level. I use the XC9572XL in the Floppy Emu, and it's the chip Uniserver has managed to fry like 10 times with his experiments. If I were doing it all over again, I'd use some kind of buffer or level converter chip, rather than connecting 5V anything directly to the CPLD. 

A chip like the 74LVC244 is a cheap and easy way to convert 5V incoming signals to 3.3V outgoing signals. For 3.3V to 5V, you might actually be able to drive 5V parts directly if the parts you're driving have a Vih threshold below 3.3V. Or use something like a 74LS244 to convert 3.3V to 5V.

One thing that's never been clear to me about accelerator design - how do you deactivate the old CPU, assuming it's not physically removed? Would you use the 68K's bus request input to gain control of the bus, then just never give it back?

 

[techknight]

Basically the CPLD is going to be performing 3 functions, Well 4. 

1. Setup A0,A1,SIZ0,SIZ1 to tell the CPU that its working with 16-bit bus cycles. 

2. Handle VPA/VMA/E Sync for synchronous bus accesses. 

3. Handle decoding for the FPU, Decoding FC0/FC1/FC2 for CPU space, and decoding a couple address lines to determine that its the primary co processor, as the 68K can address multiple coprocessors. 

4. Handle bus-mastering, gaining control and turning off the primary processor. 

5. Adding propogation delay via flipflops/AND gates to fix the bus-cycle pipelining. the 68020+ is a 3 clock period bus cycle whereas the 68000 is 4. So a 1 clock cycle delay needs added to step1 for the DSACK/AS/DS. 

For getting control of the bus, its like this: 

First you toggle and hold the Bus Request line. The CPU then returns back a Bus Grant. The device that requested bus access, Then recieves the bus Grant. Once the Address/data strobes have returned to an idle state with the main CPU clearing the current bus cycle, the Bus Grant Acknowledge line is then toggled and held by the device requesting the master. it continues to hold it, along with Bus Request until its ready to give up control. 

When your finished, you release bus request, and bus grant acknowledged. The main CPU then looks at the bus state before releasing Bus Grant. And once its fine, the processor latches back in and takes over. 

So CPLD toggles bus request, waits for Bus grant. CPLD gets bus grant from CPU. CPLD then checks bus states with a decoder (make sure current cycle is complete), then CPLD latches and hold Bus Grant Acknowledge until its done with the bus. This is to prevent bus contention, to prevent the bus mastering device from taking over before the CPU is finished with the current cycle. 

Electronically, bus grant would be ANDed with the DSACK/UDS/LDS/AS, output of the AND would then be going into a flipflop which would latch onto the BGACK, and hold it until the flipflop is cleared. Its cleared when bus request or bus grant goes into inactive state. 

Inactive state happens when the accelerator gives up control to another bus master device (which the SE/portable doesnt have so not important), or the system is power cycled or reset. Multiple bus masters would need another chip on board to handle arbitration prioritization. such as a DMA controller. So if for example the SCSI controller is DMA capable, and is a bus master (add in card) and wants the bus, the arbitrator would get the request from that slot. This would cause BGACK to get released and then the SCSI takes over the bus until its finished. Then the CPU card tries to take back over when it goes inactive again. This can get complicated. 

But again for the portable, or any other low power 68K mac, there is no other bus mastering that I am aware of. The video generation circuit remains in question though, especially for SE as its constantly pulling from the RAM for its framebuffer, without the CPU. 

If you want to get really clever, you could attach the bus mastering logic to another address-decoded register. So the CPU accelerator is not doing anything, or running until you write the register via a poke. 

So, like sonnet, you load an extension which sees and turns on the card, card then takes over the bus and assumes control. So in a situation where you need to save battery life, or a program is unstable with the accelerator, you can turn it off via a control panel. 

As far as CPLDs are concerned, I want to stick with xilinx as thats who I have a programming cable for. Knock on wood, I havent blown up 1 CPLD in my RAM card project, But I did use 74 series level shifter style buffers, And, I used resistors between any CPLD lines that didnt route through the buffer. 

 

[techknight]

I got some documents that I will have to dig up, but I have schematics of an accelerator with FPU that is discrete logic, and I have a couple sheets on an accelerator that uses PALs with PALASM. 

And of course there is the motorola Application Note AN944 which explains how to use a 68020 in a 68000 system. it was located and posted in my RAM thread. 

There is also a working accelerator out there that uses a large scale FPGA with 68K softcore

 

[techknight]

Take a peek here:

http://microprocessor68000.tripod.com/

Under bus arbitration it gives a good explanation. 

Also, I attached my library of documents I have. Just with these alone, an accelerator could be built inside a CPLD and real CPU easily.

Oh, if you do jump into making one for an SE, might be worth it to toss a SONIC chip on there and get ethernet too! and maybe even address selection for flash ROM to do netbooting. haha. now I am getting carried away. 

PAK68 Accelerator Schematics - c't 1987.pdf

AN944.pdf

LUCAS-11.pdf

 

[trag]

Oh, if you do jump into making one for an SE, might be worth it to toss a SONIC chip on there and get ethernet too! and maybe even address selection for flash ROM to do netbooting. haha. now I am getting carried away. 

<in quiet voice>  and add a micro to USB chip at some unused memory space and wait for someone to write drivers for it...

 

[CC_333]

<in quiet voice>  and add a micro to USB chip at some unused memory space and wait for someone to write drivers for it...

Yes! And add WiFi while you're at it!

And how about SATA? SATA I is fine, since these Macs (especially the SE/Portable) will never come even close to maxing it out.

c

 

[techknight]

LOL. Sure I can cobble any hardware I like to any memory address I want ....

But.. I cant write drivers, so its pointless? 

Sure I can write a realbasic program to peek/poke at the physical addresses where the hardware is located and talk to the USB that way. But thats not very useful or effective. And... it wont run on a Base SE as realbasic apps use CFM-68K which requires 020+

But there are ATmega ICs that have USB stacks built in, and there are Ethernet/Wifi modules that use SPI, which can be adapted to the same Micro. 

 

[TheWhiteFalcon]

Pfft. Wifi? Add Thunderbolt 2 and FW800! And an HDMI out.

 

[techknight]

ok, just stop... lol. Now the vibe is starting to feel a bit sarcastic. 

 

[unity]

Well I dunno, if this thing does not have anti-gravity added there really is not way to move it around anyway...

I wonder how many companies have been down this road before by the way. The long lived SE certainly had its fair share of CPU upgrades. Daystar loved to hit up all the headless boxed Macs. There has to be some protos that were made at some point while it was on the market for a year.

 

[techknight]

Maybe because apple really didnt allot any extra power to the PDS slot, and the fact that the market might have been too limited to profit from. 

 

[techknight]

Damn... .Just lost out on an auction that had a handful of processors, Looks like this project will have to be put on the backburner until I can catch up with another one. 

 

[hyperneogeo]

Kinda a necro bump, but in this case wouldn't it just be easier to create the card with sockets for the CPU/FPU and have the customer/buyer provide them? That way you can bypass the biggest charge of the project and all the buyer has to do is stick theirs into a socket.

 

[aplmak]

I'd buy it without the cpu and co processor!! I've got a few hanging around!

 

[Macdrone]

I agree if you can make the card and let people find the processor you should have less of a hassle.

 

[hfrazier]

^bump^

I'd buy one! Although, I'd rather have some sort of networking capability...

 

[LaPorta]

This never happened, did it, @techknight ?

 

[techknight]

This never happened, did it, @techknight ?

Sadly, no. Way too many projects, and not enough time nor motivation.

 

[LaPorta]

Drat. Perhaps someone will pick up the ball someday.

 

[360alaska]

Maybe someone could adapt a Pistorm: https://amigastore.eu/853-pistorm.html

 

[Trash80toHP_Mini]

Rather than supplant the Portable altogether by all but turning it into a Pi case, the same could be done using Apple tech from the period. The Achilles Heel of the Portable is its stone age LCD.

I'll say it once again, a Portable LCD interface converter would be the Holy Grail. If the digital inputs of the OEM LCD can be converted to digital output with LVDS (or TTL?) adaptation, Portable hybrids would be wide open. An LCIII or SE/30 board in Portable form factor seems fair game/classically correct to me as opposed to Amiga shenanigans.

You'd have the equivalent of the Portable's contemporary Colby/30 competition with its limitation of mains power.

Alternately, developing an hybrid Portable mobo based Sony's reinterpreted PowerBook 100 model you could remain untethered. With its first ever CPU Card implementation, you'd blow acceleration prospects wide open. But again, the missing link remains the mythical Black Box of LCD conversion. I wonder how similar the two panels might be?


Edit: new notion, almost directly on topic! Reworking the Portable Logic Board to 030 PGA socket form factor would sidestep the Mythical Black Box requirement. Such would be a new home for failed OEM board components. The 030 socket would remain a 68000 interface with that processor on a stock "CPU Card." Still a Portable, but a bit different.

PGA socket would be a firm foundation for further developments on the acceleration front.