Serious proposal: accelerator and peripheral expansion system

[ZaneKaminski]

So the next step is to get Lattice's tools for their FPGAs and implement at least the Control Glue to see how many resources it will require.

Now I've implemented lots of little state machines in FPGAs, along with a VGA video generator + wavetable synthesizer, but this state machine implementation stuff is not an area where I have the most experience. So it will be a little hard. Maybe I will wait until my finals are over lol

 

[gobabushka]

Hell yea id buy one!

 

[Trash80toHP_Mini]

661-0674 Daughterboard PowerBook 100
Don't remember if the processor was on it or not. If it's not on the moobo, stands to reason it must be on the daughterboard.

edit: see below [] ]'>

 

[Trash80toHP_Mini]

Does the PB100 have a PDS? I can't find the 68000 on its motherboard. Is the 68000 on a card?

 

[Trash80toHP_Mini]

Confirmed: p.12 of the PowerBook 100 DevNote has a diagram labeling the Daughtercard as a Processor Board.

 

[ZaneKaminski]

The daughterboard is cute lol. Someone oughta make a card that goes on there. Might be hard because of space constraints though.

Here are the pieces of the software:

Define structure to store the MC68000 internal state

Instruction decoding algorithm (written in T32 assembly, purpose is to assign type code and parameters to 68000 instruction word)

Memory tree structure (classifies references and translates to appropriate action)

Interpretation algorithm (written in T32 assembly, accepts decoded instruction and changes MC68000 state struct accordingly)

Translation algorithm (written in A64 assembly, produces A64 assembly)

In writing the decoder and interpretation algorithm in T32, or, as they used to call it, Thumb-2, we achieve portability to ARMv7-M microcontrollers. So that's good.

 

[ZaneKaminski]

Implementing the interpretation algorithm is straightforward enough, I would say. The key is to sensibly decode each instruction, that is to say define good classes of instructions to reimplement as operations against the MC68000 state structure.

The decoding scheme has to ensure that there are enough different classes of instruction so that each can be implemented with just one pathway through the implementing code (i.e. the implementation must be implemented with Thumb-2 conditional instructions unless the instruction is an M68k conditional instruction). At the same time, there can't be too many classes of instruction, probably 256 at the most.

The same decoding scheme can be used for the translation algorithm, but instead of choosing, based on instruction class, routines implementing the instruction as a transformation of the MC68k state structure, the translation engine would write some ARMv8-A code implemennng the instruction.

 

[ZaneKaminski]

the implementation must be implemented with Thumb-2 conditional instructions unless the instruction is an M68k conditional instruction

*must NOT be implemented with Thumb-2 conditional instructions.
To be clear, the purpose of writing the decoder and interpreter in Thumb-2 assembly is to ensure that they can run on a cheap ARMv7-M microcontroller. If the interpreter could be written in A64, then it could be faster, but there is little point. The only purpose of the interpreter, when paired with the emulator running on an ARMv8-A processor capable of executing A64, is to eliminate latency of the emulator while waiting for a translation to complete. So using Thumb-2 is fine and gets us greater compatibility from the same code I have to write.

 

[Trash80toHP_Mini]

The daughterboard is cute lol. Someone oughta make a card that goes on there. Might be hard because of space constraints though.

That just gave me a thought: I wonder if using a PowerBook 100 mobo's interconnect might be the best way to test your design for the Portable or even the SE. By replacing the CPU on a target system you might be able to begin feasibility testing long before developing an INIT to shut the mobo's processor down under acceleration?

 

[ZaneKaminski]

Nah, I'm confident I can get it right in just one or two prototyping iterations. I think it would be hard to fit the whole system on the PB daughtercard too.

I've found that there actually is a single cheap FPGA that can do all of the bus operations. Not enough pins for 68020 bus but it will work for 68000. It's $6. So that saves cost over having three FPGAs.

But thinking about the PowerBooks has given me another idea. I was considering using a fast microcontroller to run some 68000 emulation software. It would be much slower than doing it with the Snapdragon, but these microcontrollers are like $10, compared to $79 for the Snapdragon module.

Since the Snapdragon is so expensive, it might be good to add a footprint for a fast (300MHz+) ARM microcontroller and SDRAM. Its implementation would cost an extra $15 or so. It would basically be an upgraded System Controller. You could then upgrade by purchasing the Snapdragon module for $79 if you want.

I think in this configuration, the Snapdragon would offer faster emulation, broader USB peripheral support, video output, and internet connectivity. Without the Snapdragon it would just be an accelerator that can do virtual disks and a few types of USB peripherals (probably just keyboard, mouse, mass storage in FAT32 format for disk images).

Is this a good idea?

 

[ZaneKaminski]

And then if anyone ever does a PowerBook or Portable accelerator, it could have just the microcontroller, no connector for the Snapdragon module. I don't think a design with the SD module could fit into the PB100, for example.

 

[Trash80toHP_Mini]

I wasn't suggesting you make a board in the form factor of the 100's daughterboard. Plugging an adapter for your full size board into the daughterboard interconnect to use a naked PB 100 logic board and LCD only breadboard setup might be a helpful approach. No pesky CPU in the mix to begin with for initial testing.

 

[ZaneKaminski]

No pesky CPU in the mix to begin with for initial testing.

Ah, I understand. Maybe but that's not work I really wanna do. No point making a state machine to work with a system without another 68000. I just wanna make one state machine. In choosing the MachXO1200, I've basically solved the FPGA capacity problem I was having before, and it's cheap, so I can continue with the schematic and board design. Can't use the MachXO1200 for 68020 PDS though, need more than one IC for that application.

 

[Trash80toHP_Mini]

Ah, now I understand  .  .  .  sort of, that kind of thing is way over my head. I mostly look for workarounds/ways to cheat to make things easier. Necessity may be the mother of invention, but creative laziness is the crazy uncle nobody in the family talks about who's actually more productive! [] ]'>

 

[Bunsen]

using a fast microcontroller to run some 68000 emulation software. It would be much slower than doing it with the Snapdragon, but these microcontrollers are like $10, compared to $79 for the Snapdragon module.

/ add a footprint for a fast (300MHz+) ARM microcontroller and SDRAM. Its implementation would cost an extra $15 or so. / You could then upgrade by purchasing the Snapdragon module for $79 if you want.

/

Is this a good idea?

IMO, absolutely.  Anything that brings the end cost to the purchaser down is going to expand your market.  Having a powerful but optional upgrade for later on only makes it more attractive - and, obviously, the larger the potential market, the better the chance of economies of scale. 

The speed penalty may not be as bad as you think, if the micro is relieved of the burden of also running a Linux kernel.

bbraun's existing work with interfacing the sub-$20 Discovery boards (~180MHz) to the SE PDS may be illuminating here.

Without the Snapdragon it would just be an accelerator that can do virtual disks and a few types of USB peripherals

Honestly, I think this (with the SDRAM you mentioned) is all that 90% of people would really want in a accelerator [1], especially if it means we're talking about a sub-US$100 end price, rather than US$150-200 and counting. 

Speaking of keeping costs down, I really think your best approach might be to continue focusing on a single, small SE PDS type card.  It's always tempting to add another $1 feature here and another $15 feature there, but as you've already seen, these all quickly add up.  Re-focusing down on the simplest possible board that allows for later expansion seems like a wise move. 

Adaption to other, CPU socket machines can be implemented as a second card. Yes, that brings the cost up somewhat for anyone with a different machine, but I think the economy of scale - and the saving in development time and PCB area - on the main card will probably even that out, perhaps even so far as to make it cheaper for everyone.  And it means you start off with a reasonable market for the simple, cheap SE PDS accelerator, which can start the ball rolling and bring in funds and interested developers for future widening of the market and applications.

It doesn't seem necessary to me to make a different, huge card for every machine type, and obviously the larger the card the more expensive.  Make it as modular as possible - a single, standardized Killy-type connector for all DIP 68000 machines (for example), and ribbon cables or other readymade connectors from that to a convenient mounting location for the standardized SE PDS breakout board.  Any wide span to reach mounting points could be made up with a plain sheet of plastic.

The CPU-PDS adapter card/s should be relatively simple, at least in the fact that you're not dealing with the high speed signalling on the accelerator.  Picking a standard expansion interface (SE PDS) means that you have a fixed target to develop towards - each machine's adapter assembly can then be developed individually, one at a time, by you or by whoever.  And if you decouple the electrical-mechanical interface from the internal machine layout (using the modular approach), you can re-use as many subassemblies as possible across different machine types.

----

[1] Ethernet or WiFI via USB or a NIC IC might be a nice add-on, but probably optional rather than standard, as other options for networking already exist.

 

[Bunsen]

Sidenote: it seems to me that modularizing is going to also make developing and (perhaps more importantly) debugging much less of a headache for you - in that once one module (the accelerator) is known to be functional, any problems that crop up in adapting to second or third machines can be isolated to the adaption sub-assembly, rather than debugging an entire new board layout.

 

[Trash80toHP_Mini]

It doesn't seem necessary to me to make a different, huge card for every machine type, and obviously the larger the card the more expensive.  Make it as modular as possible - a single, standardized Killy-type connector for all DIP 68000 machines (for example), and ribbon cables or other readymade connectors from that to a convenient mounting location for the standardized SE PDS breakout board.

Haven't seen an SE board in years, is the 68000 in the same Killy Klip friendly DIP package as the other Compacts? In that case the processor's legs would be the equivalent to the PDS and  only a single design would be required for 128k through SE.

At this point in the PCB design process, it's probably counterproductive to switch gears. On top of that, the SE PDSs is properly buffered as a dedicated expansion interface. Using an adapter based on the dual interface MicroMac design for the earlier compacts could be very inexpensive.

 

[EvieSigma]

Judging by the pictures of SE motherboards I've seen, yes, the 68000 in the SE is the same as the one in the 128 through Plus.

 

[ZaneKaminski]

Honestly, I think this (with the SDRAM you mentioned) is all that 90% of people would really want in a accelerator [1], especially if it means we're talking about a sub-US$100 end price, rather than US$150-200 and counting.

Yeah, I should ditch the Snapdragon entirely for 68000 systems. On these, I am eyeing the (not yet in production) STMicroelectronics STM32H7, which is related to the STM32F4 that bbraun was using. The STM32H7 is a 400 MHz ARM Cortex-M7, basically the fastest microcontroller around. The FPGA shouldn't be necessary unless the microcontroller doesn't have enough pins to talk on the bus.  I have to study the manuals for the STM32F4, -F7, and -H7 and also bbraun's work more thoroughly.

The STM32H7 also has an LCD controller, so, if there are enough pins available, I can break out LCDD[15/7..0], HSYNC, and VSYNC so someone can make a VGA interface or Mac SE grayscale upgrade or something. Just 8 bits of color are enough, maaaaybe 16. I think 24 bits certainly would be too much. So that makes external video easier, which was basically bbraun's project.

I think design, with the STM32H7, could be priced at $100. It would be somewhat faster than the SE, but certainly not 50x faster. Maybe 10x faster. It could have USB mass storage support, with a little FAT32 and USB work. This was what I was hoping to avoid by using Linux, but it shouldn't be too bad. Same for USB keyboards and mice. I'm sure it couldn't be too hard. Maybe I will also drop the onboard SD card in favor of a bit of fixed flash memory. The SD slot is frustrating since it sort of requires a $1 electrostatic discharge protection IC.

As for 68030 systems, anything without a good chunk of a Gbyte of RAM is basically not powerful enough to accelerate a 68030 system, since the emulator would have to support the full 128 Mbytes of RAM for these systems, and then the MMU stuff requires more memory bandwidth as well. So that's where the Snapdragon will be required, that is if I ever get around to that.

Haven't seen an SE board in years, is the 68000 in the same Killy Klip friendly DIP package as the other Compacts? In that case the processor's legs would be the equivalent to the PDS and  only a single design would be required for 128k through SE.

At this point in the PCB design process, it's probably counterproductive to switch gears. On top of that, the SE PDSs is properly buffered as a dedicated expansion interface. Using an adapter based on the dual interface MicroMac design for the earlier compacts could be very inexpensive.

Nah, it's not too late in the process. I'm still exploring the options. The process of doing that half of the SE board helped me to get acquainted with the expansion interfaces, etc. There are lots of mistakes in my boards and schematics, by the way. I am a very hungry beginner at this, so the design process is not going to be perfectly smooth, but that's all good. I'll redo whatever I have to until I'm satisfied.

Macintosh SEs all have the 68000 in DIP-64, so I could try and do a board that works on both Plus and SE, leaving the SE's expansion slot open (would work too, for non-DMA cards). Let me do some more schematic design with the STM32H7 first though before deciding where to go with it.

 

[cb88]

http://experiment-s.de/en/<- this guy has 68030 emulation code working for Atari for his Suska series of boards... he seems to not be updating much lately but he does cool stuff like most people around here.

Personally I think emulating the cpu on an ARM is self defeating, and probably not practical.... if you are going to do that you may as well run an emulator on a PC.

Other options might be a Zilinx Zynq ... those are around $60 but smash a speedy FPGA + decent ARM chip together. So you could do something like use a VHDL 68k core while using the ARM for accelerating other things like SSL, or providing configuration for the framebuffer output etc... or handling USB peripherals for expansion like wifi etc... Acutally I think that would be a quite workable solution.