Search results

I have wondered about this. The main limiting factors on the clock speed achievable with a faster oscillator are the maximum speeds of the 68030, Apple "GLU" chip, the asynchronous DRAM latency, and the peripherals. The processor and DRAM can be upgraded to higher speed grades, but the...

Someone asked a few weeks ago about a schedule for the project. I think I can now say that The Macintosh SE and Plus accelerators will be completed in one and a half to two years. Hopefully, I am hoping that once I make more progress on the software in particular that other developers will be...

The STM32H7 isn't up to dynamic translation of blocks of code (i.e. group of instructions following a jump target). It's just not powerful enough to translate while also interpreting at a good speed. Multiple cores are helpful for this. The penalty for not translating is an indirect jump per...

Does CFM68k work on this machine?

That's helpful. I'll look into it, but I've gotta get some official Apple references on this stuff... I still can't find the Volumes IV-VI of Inside Macintosh. Maybe it's in there.

What do you mean? I meant DDR qSPI (to talk to the MCU), not DDR SDRAM. I didn't plan to connect any external RAM to the iCE40. Or do you really think I can't fit a DDR qSPI in interface with 1000 LUT4s? I have to defer to others' expertise on this FPGA state machine stuff, but I think 1000...

I think that we can avoid needing an INIT or special boot floppy or anything else like that by constantly hogging the bus, and never letting the 68000 get a chance to fetch an instruction. The Bus Glue FPGA, if it has nothing to do, will have to constantly issue meaningless reads to addresses...

I'd rather do it with DDR since that's less demanding in terms of clock signal bandwidth. Y'know, in SDR, the clock oscillates at double the frequency of alternating (1010...) data bits. Whereas in DDR, the frequency of alternating data bits is the same as the clock frequency. But then again...

The qSPI interface of the STM32F7 supports SDR operation up to 100 MHz and DDR operation up to 80 MHz. Specs for the -H7 are not available yet but they'll surely be the same or better. The -H7 is built on a new 40nm process. I think the -F7 is built at 65nm or something. Now the qSPI clock...

I've gotta figure out how the CFM works, just as an exercise in better understanding the OS. Are you sure it doesn't require an MMU though? It's functionality seems like it would benefit from the existence of an MMU

Well the problem I'm seeing is with the ROM. If you emulate the same CPU as in the machine, just faster, then you can use its ROM and everything works since all of the chipset hardware expected to exist by the software in ROM is present in the machine. You could run the Portable from its stock...

Well maybe it wouldn't be too hard. There are still unsolved problems though. Let me explain. The differences between the 68000 and 68020 in terms of the programmer's model are an extra 8 address bits, longword ALU operations, and the cache control registers. So all that needs done to add 68020...

There could be a cheaper product with only a (more capacious) FPGA, but like I said, I wouldn't be great at making one. I'm a programmer.

I'm just not a CPU designer is the thing. I designed a toy CPU this semester for my computer architecture class. Not something I really wanna do again. My strength is mainly as a programmer. The key problem in making this kind of low-cost, high-performance, eccentric thing is choosing which...

Haha I'm way ahead of you on caching the ROM. The STM32H7 has a "scattered memory architecture," with a bit over 1 Mbyte of SRAM but split into different banks and sizes to optimize throughout. And then there's the 32 Mbyte external SDRAM. Firstly, the emulator software has to be stored in the...

Honestly, a PB170 accelerator sounds so cool to me. Active-matrix screen, and the slim (at least in comparison to the Portable) first-gen PB design I can understand if you have a soft spot for the Portable, though.

Nooo, unfortunately I never planned for that. Emulating a different CPU complicates things. I planned to use the ROM from the machine as-is, and the software in the ROM only works under the assumption of the presence of some particular chipset. 68030 systems all have, for example, the Apple...

Yeah, that's easy with /RESET. In the old design, I had the System Controller in charge of pulling reset low, and it would time the boot sequence between the FPGAs and Snapdragon. Actually, it turns out that the Lattice iCE40 series of FPGAs does have internal configuration flash, but is more...

The little WiFi dongle approach seems easy, but it's only easy when we run Linux, since the dongle probably has a Linux driver. But for my latest design, which is not supposed to run Linux, it's going to be too hard to develop a driver for the dongle. So we need something easier to work with...

I say, for Ethernet (and WiFi), with this design, leave internet connectivity out. The way I see the peripheral expansion is that breaking out more interfaces is hard, so I wanna break out just USB 2.0 HS, the LCD interface (basically digital parallel VGA), and then a UART or two for debugging...