Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

[bieling@terra.es (Jorge Chamorro Bieling)]

mdj <mdj.mdj@gmail.com> wrote:

> Jorge Chamorro Bieling wrote:
> 
> > 1.- Think of page 0 addresses as registers, you should put them where
> > they belong: inside the processor, not in memory.
> 
> There's a couple of problems here. For one, page 0 is still addressable
> memory so you'd have to implement the other load/store functions in a
> pretty funky way to avoid issues here. Two, Any Apple II after the ][+
> has at least two zero pages (Auxiliary memory) and in the case of
> extended memory cards, many many more.

It could be that only the first, "main" zero page was inside the
processor, and the (seldom used ?) remaining zero pages (those in
extended memory cards) mapped to regular ram, and these would take an
additional memory cycle ?

Conceptually, I believe it is better to think of two separate blocks:

-a "processor"
-a "memory management unit"

The processor has a custom bus design, not necessarily close nor similar
to the 6502 bus. The bus needs to have whatever signals are required to
co-laborate efficiently with the MMU.

The MMU is the block that manages to interface properly and in sync with
the (fast) RAM, the (Apple II) ROM, the (Apple II) I/O space, the slow
(Apple II) RAM writes, etc:

-Given a RAM read request, fetch 4 consecutive bytes from memory in a
single cycle and present them to the processor bus. 
-Given a $C000..$cfff read/write request, sinchronyze to the Apple II
bus.
-Given a RAM write request, determine whether it has to write trhough to
Apple II onboard ram.
-Etc.

The MMU design may probe to be nearly as complicated as the processor.

In the end, I think, the memory address bus can be thought of as 16 bits
wide plus some more address bits that reflect the settings of the
extended/language memory bank softswitches.

> 
> > 2.- The same goes for the stack. Can it be a set of 256 registers ?
> > PHA would take 1 cycle instead of 2.
> 
> Ditto the stack...

Could the stack be made 16bits deep? I've been thinking about it lately,
and I'm not sure. The question is that *maybe* the S register could be
seen as 8 bits (the lsb 8 bits of a 16bit S register) by the 6502 code
(so as to remain compatible with existing code), but be in fact a 16bit
register, so that when you PHA beyond the 256th byte, even though the S
register "rolls", in fact you'll get back the correct data when you PLA
back. The problem here arises when the stack is manipulated "by hand",
not by PHA/PLA. Well, this is something to think about. If such a thing
can be done, it should.

> 
> > 3.- If the memory bus was three bytes wide, a single cycle can present
> > to the processor both the opcode and the data in a single cycle. This
> > alone is a 2X,3X speedup, or no speedup at all if the instruction was 1
> > byte long... And it's quite easy to implement. It is left to the reader
> > as an exercise :-)
> 
> This would be a cute optimisation for acceleration mode to have,
> effectively providing prefetch, however it would need to be disabled
> for the C000-CFFF region or machine IO would behave very strangely.

This has to be the job of the MMU. 
The MMU has to take care of these things.

> 
> I wonder whether it's worth it in the end. If it were me, my approach
> would be to drop a DRAM controller on the FPGA, add 16meg via an
> appropriate SIMM. 

Yes, but it's a pity, somebody is going to re-design this 30 years
later, just by sitting comfortably in front of an blank page of paper.
All he has to do is *think* until the design seems ok, *translate* into
vhdl and *simulate* the thing. No solder nothing. No power supply noise.
No shorts. Connect a 32 bit bus by the click of a mouse... It's a pity
not to take some extra *thinking* to get the most out of it. I'm not
saying that this idea is the best, though. It's only a idea I had. But
if it's true that this can make it run 2x or 3x faster, then it should
be done, I believe. The difference between doing it and not doing it, is
not hundreds of hours of soldering or tens of additional components,
it's a more complex circuit design, but it's not more complex to
produce.

> I'd stick with cycle accurate reimplementation of the
> 65C02 and implement the Apple II peripheral bus at 1mhz timing. The
> actual DRAM would run as fast as the core can cope with (50Mhz should
> be easy) and 1mhz 'emulation' would be handled by waiting at the end of
> instruction completion. The RAM would behave as does a RamWorks card,
> eliminating the need for the clone to have an auxiliary slot.

Absolutely, there has to be a "6502 compatible" mode, with 100% speed
and cycle accuracy. After all, this is an Apple II, isn't it ?

> I'd
> possible integrate USB host support via a core swiped from the
> opencores project, and use that to implement high-speed storage via
> memory sticks. It'd live in pseudo slot-7 using a similar scheme that
> the IIGS uses to allow both internal devices and slots.

I believe that USB is more a software problem than a hardware problem. 
The same goes for ethernet.

> 
> This whole thing would live on a board form factor compatible with a
> standard Apple IIe case and power supply, by reprogrammable via a
> simple cable and have lots of additional header pins in unclaimed board
> space so that over time, more peripheral cards could be replaced with
> FPGA logic.

Yes, that's what I think too.
> 
> I would think that the speed achievable using FPGA with the RAM
> subsystem operating at the 'accelerated' speed would be more than
> adequate. I'd consider anything more than 16Mhz to be a bonus, because
> really, ALL Apple II software would absolutely scream at this speed,
> especially as it's a lot faster than any accelerator has ever achieved,
> and for the most part, nobody is going to write software that depends
> on the performance anyway.

But remember. This is year 2006. 30 years later. Only 16MHz ? Come on !
ZIPCHIPS ran at 8Mhz 20 years ago !. We should do it better...
> 
> Of course, if someone manages to hit 50Mhz or more I'd be most
> impressed, and be first in line to purchase a couple of these things so
> I can finally retire my aging and very difficult/expensive to replace
> 'production' Apple IIe

This will always be a "capricho".

--
Jorge Chamorro Bieling