The RB65 project

[Ruud]

Hallo allemaal,

André had the smart idea to start his own thread for his own project. Being a good idea, I decided to do the same.

So far you have only seen words from me. Please visit http://www.baltissen.org/newhtm/rb6502.htm where you'll find some links to the real hardware I use.

As said once before, I want to replace the 8088 of an IBM-XT (compatible) with the Godil. One of the reasons I choosed for the Godil was its 5 Volt compatibility. (AFAIK FPGAs big enough to be interesting are 3V3 or lower)
Cleaning my room a bit for the ziilionth time, I found an upgrade set for your PC: you can replace a 80486 with a 133 MHz AMD 586. And suddenly I realised that newer 486s and Pentiums run on (about) 3V3 or lower. Which means that 1) André's processors can be realised with less hardware then I expected and 2) we immediatly have various motherboards to our disposal that can be used by these processors.

[BigDumbDinosaur]

Ruud wrote:

One of the reasons I choosed for the Godil was its 5 Volt compatibility. (AFAIK FPGAs big enough to be interesting are 3V3 or lower)

What is "3V3"?

[Nightmaretony]

3.3V methinks...

[kc5tja]

European-style schematics often use the unit as the decimal point indicator because it solves two problems:

1) Can you even *SEE* the dang decimal point?

2) Do you use . or , for the point?

Using the base unit indicator ensures full legibility without having to worry about periods versus commas, particularly when your schematic is a photocopy of a photocopy of a photocopy of a magazine reproduction of someone's hand-written scribbles.

[BigDumbDinosaur]

kc5tja wrote:

European-style schematics often use the unit as the decimal point indicator because it solves two problems...

I'm not European and I can definitely tell decimal points from commas.

[kc5tja]

On a clean schematic, sure.

That still doesn't solve the 7.3 versus 7,3 issue.

BTW, American schematics rarely use I for symbols (e.g., it's rare to refer to "pin I", at least without further qualification). That's because, again, on dirty schematics, it's hard to discern I from 1.

Also, on schematics captured as bitmaps (instead of PDFs or other scalable format), I DO have a hard time discerning decimal points.

[BigEd]

Hi Ruud
nice collection of re-used hardware there. The DIL with the hole in is a new idea for me!
I have a motherboard for a pentium 75 - it hadn't occurred to me to use that as a host. I think I've got x86 and 8-bit in different parts of my brain.

Cheers
Ed

[Ruud]

Rewriting my core

I started to rewrite RB65. I have RB6502, RB6510 and RB6588 (6502 for XT) in the mean time, three seperate files. An error found in an opcode means I have to edit three files. So I decided to lift out that part that is completely hardware independant, called RB65. RB65 is now to be embedded into RB6502, RB6520 etc. RB6502 etc. from now on handle th hardware part.

This means I need an universal interface between RB65 and the higher level cores. If we agree on a general interface, it would mean we can exchange cores in seconds. For example this would mean I could load my Godil with RB6502 but with André's basic 6502 core. Or T65 or Free_6502, as long as the interface is the same.

At this moment my interface looks like this:

Code: Select all

entity RB65 is
  Port (
    A		: out	std_logic_vector(15 downto 0);
    Din		: in	std_logic_vector(7 downto 0);
    Dout	: out 	std_logic_vector(7 downto 0);
    IRQ		: in	std_logic;
    NMI		: in	std_logic;
    RDY		: in	std_logic;
    PHI0	: in	std_logic;			-- input single clock 
    PHID	: in	std_logic;			-- input double clock 
    RESET	: in	std_logic;
    RW		: out	std_logic;			-- Read/Write line
    SO_n	: in	std_logic;
    SYNC	: out	std_logic;

    SSB		: in	std_logic;			-- Single Step Busy
    SSC		: in	std_logic;			-- Single Step Clock

    OpcC	: out	std_logic_vector(4 downto 0);	-- Opcode step counter
    Version	: out 	std_logic_vector(7 downto 0)
  );
end RB65;

The nice thing is that one can define as many OUTs as he wants: if the upper level doesn't need them, you won't have to define a counterpart for them.
INs is a different story. I thought I needed SSB and SSC for debugging but writing this I realised they can be moved up a level and be combined with RDY.

PHID needs an explanation. I already mentioned my "double clock", enabling me to perform two actions every clock, like the real 6502 does. But it also enables me to execute some 1-byte opcodes in one clock cycle, something T65 cannot (like ASL A).
A core not using this feature, like T65, accepts it as input but then doesn't use anything with it.

I would like to write more but I have to go now to the church. But I hope I gave you enough material to discuss.

(TAB does work quite correct in CODE mode I just noticed in preview mode)

[OwenS]

Why not pick an already standard SOC bus, like Wishbone or AMBA AHB? Then, not only can you easily switch cores, you can also easily drop in other components from other developers

[Ruud]

OwenS wrote:

Why not pick an already standard SOC bus, like Wishbone or AMBA AHB? Then, not only can you easily switch cores, you can also easily drop in other components from other developers

To give you a quick answer: to be honest, I never heard of them. Any help, explanation or what ever is welcome!

[kc5tja]

I already posted a link to the Wishbone spec elsewhere on this forum. You'll find that Wishbone is very similar to the 6502 native bus interface, though enhanced with features suitable for 16-bit or wider buses.

http://en.wikipedia.org/wiki/Wishbone_% ... ter_bus%29

[Ruud]

kc5tja wrote:

http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29

Thank you for the link. First I have to understand this information before I can implement it. Have a look at my next message, please.

[kc5tja]

Understood -- Wishbone has a lot of stuff in the specification, but it's like PCI in the sense that out of the hundreds of signals available, you need only a small subset to make something useful. It's good to read up about, though.

I've considered making Kestrel's expansion bus an externalized form of Wishbone.

[Ruud]

Rewritten cores

I said I would split up my cores. So here are the URLs:
http://www.baltissen.org/vhdl/RB65.vhd
http://www.baltissen.org/vhdl/RB65_tb.vhd
http://www.baltissen.org/vhdl/RB6502.vhd
http://www.baltissen.org/vhdl/RB6502_tb.vhd
http://www.baltissen.org/vhdl/RB6510.vhd
http://www.baltissen.org/vhdl/RB6510_tb.vhd
http://www.baltissen.org/vhdl/RB6588.vhd
http://www.baltissen.org/vhdl/RB6588_tb.vhd
http://www.baltissen.org/vhdl/ROM.vhd
http://www.baltissen.org/vhdl/Oho_Dy1.vhd
http://www.baltissen.org/vhdl/OhoPack.vhd

Explanation:
RB65 is the bare core. It needs both PHI0 and PHID as clock input. PHID has to be generated from PHI0. See the TestBench file how I did it.

In RB6502 I used the 49 MHz clock to generate the delayed PHI0 and PHID. FPGA is so fast nowadays that it is possible that some older 6522s, 6520s etc. can read the wrong data at the falling edge of PHI2. I use the 49 MHz clock to delay it with about 50 ns. Maybe it is unnecessary but it certainly won't hurt.

RB6510 is meant to replace the C64's 6510.

RB6588 is meant to replace the 8088. Here I used the fact that the 8088 needs four clock cycles for every CPU cycle. These 4 clock cycles enabled me to create my double clock PHID and single clock PHI0. No delay here, but I'll find out ooner or later if that it is needed here as well.
FYI: I handled the extra address lines using a simple little MMU.

With RB6588E (E=Expansion, still under construction) I'm playing with the idea to drop the 8288. This IC generates the various memory and I/O signals. Still having enough free pins left on my Godil, I'm thinking of generating these signals my self. My reason: I hope to run RB6588E at least twice as fast as RB6588, maybe, maybe four times. (dreaming keeps you young :)

I added the OHO files because you need them (for the moment) to run the other VHDL's.

Next steps:
- to test at RB6502 in real (it's the only interface I have soldered yet)
- 16 bitters

[Ruud]

kc5tja wrote:

http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29

I had a good look at the PDF but I think that it is much much more then I need. If you forget the 65816 parts, EF, MF and XF (which I don't understand at all), the interface of T65 is almost the same as the one of RB65. So I'll keep the interface as it is. But I'm always open for good arguments.