I have a bit of time now so I thought I resume works on the Generic RetroComputer, GRC, and tackle the 6502 version. GRC is my attempt at one-function-per-module à la RC2014. There are 3 goals for GRC:
1. Accommodate 5V processors of 1970's and early 1980's by changing the CPU module but reuse the memory & I/O
2. Standalone computer with its own keyboard and monitor
3. Designed for a specific enclosure, PACTEC CM5-200

I have mostly finished the Z80 edition of GRC here: https://www.retrobrewcomputers.org/foru ... 3&start=0&

I'm starting on the 6502 edition. Beside Z80 and 6502, I also have plan for 8085, 6809, and 68008. The real challenge is keeping them straight in my head.

The backplane is six 2x25 female sockets plus a disk-on-module connector (I have a CF disk version, but it is too tall to fit in PACTEC enclosure). Each module is 1.5" tall, 4" wide. It is not very much room thus one function per module. One aspect of the design that's slightly unusual is the backplane is a decoded bus, i.e., chip selects for disk, RAM/ROM, and 4 other I/O are defined on the bus and a module with programmable logic is responsible for generating these chip selects. It is the programmable logic module that interfaces to various processors and accommodate different timing requirements; the RAM/ROM, disk, I/O, video/keyboard are processor agnostic. The basic concept is not very different than the CPLD trainer but with different form factor and accommodate more processors and I/O. In fact I'm reusing earlier designs of CPLD trainer to bring up GRC-6502.

GRC-6502 is now 3-module computer running memory diagnostic at 7.37MHz. The picture shows backplane (left), processor (top right), CPLD (middle right), and 512K RAM/ROM (bottom right). The end point for GRC-6502 is standalone computer running DOS/65.
Bill
Edit: the next picture shows 6502, CPLD, RAM/ROM installed on GRC backplane but the remaining members of the family that are not yet tested on the side. DOM is at the bottom; top right is VGA/PS2 and bottom right is quad-serial.

Looks like a nice idea. So what is the bus pinout and the breakdown of your address space done by the address decoding? And in particular, when moving from Intel to Motorola bus, how do you handle losing 256 (or, for Z80, technically 65536) bytes of address space (the I/O address space)?

_________________
Curt J. Sampson - github.com/0cjs

Looks very nice Bill. A lot of overlap with my own design goals. Your backplane looks similar to the Planck 6502 computer. What made you decide to have the chip selects on the bus?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Select signals on the bus can be useful for separating the decoding from the peripherals themselves. I was just having a chat with a friend about a modular system a bit like this one, with optional emulation of existing systems (Apple II, PET, C64, etc.) if you have the right peripherals, and then I realised that to make that work well you really want the address decoding to be modular as well: in essence you'd want a "personality" card that supplies the address decoding and ROM of a particular system, as well as any other unique parts (e.g., the half-PIA of the 6510 in the C64).

One major difference is that I'm looking at the CPU board containing RAM, EEPROM, and a USB FIFO, and having its own simple address decoding that can be disabled, so that it can also run as a stand-alone SBC. So to make that work I guess I need RAMSEL, ROMSEL and CONSEL on the bus so that the CPU board can use the bus versions or its own versions, and then a bunch of additional lines to support all the potential peripheral devices (video, sound, PIAs, etc.) of the emulated systems that would not be on the personality board.

_________________
Curt J. Sampson - github.com/0cjs

That looks great!

And to try and add a bit more to the conversation than just that it looks great (I mean it does but I'm not adding much by commenting that). What I was thinking of doing (but haven't done since the last redesign) was having chip address lines rather than a chip select line for each device connector. For example: 4 address lines for 16 devices and then on the back-plane add a 74'20 quad NAND gate wired to signal a single chip select per connector. If the address lines match the connector number then only that connector chip select goes active.

And then to go a bit further it would be possible for each device in a connector to identify what it is by using, say, address 0 (A0...7 == 0) that returns a hardwired byte when read that is meaningful to the OS.

Just a thought,
Andrew

This is the signal definition of the 2x25 bus. CPLD is responsible for generation of CS1-CS5, CSRAM, CSCF, RDCF, WRCF, BANK0-3, WAIT, and NMI. However, every bus signals go into CPLD so it can also act as small ROM, serial port, timer, and discrete I/O. CPLD can redefine the memory map and assign I/O to small address ranges. The video function took 4K of Z80's I/O space but in 6502 it will be 4K memory somewhere in 6502's memory map. The 4K may be in banked memory, but I have not worked out the details.


Memory and most peripherals are designed to work with most processor families. The address and data interface are the same, it is chip select, read/write that need to be tailored to specific processor timings. So with chip selects generated by programmable logic, different processors can be accommodated without redesigning the memory or peripheral modules.
Bill

The backplane is fairly small (100mmX100mm). Beside CPU and CPLD modules, the backplane can only accommodate 5 other devices (CF, RAM/ROM, VGA/PS2, multi-channel serial, and one more module TBD). Each device reside on a small pc board, so there are not much room for additional circuitries. This is why I settled on the fully decoded chip selects approach.
Bill

I like it Bill. I'm quite fond of backplane/bus computers.

I've designed two of them myself and have built a compatible bus for the OSI Superboard II as well. I was going to do a version for the KIM/SYM/AIM too but have been distracted for the last few years with learning more about instrumentation.

Anyway, a backplane/bus allows the computer to be easily configurable for whatever needs you have.

If the bus is kept short and uncomplicated and 4-layer boards are used (with voltage planes) considerable speed can be maintained.

I use slot selects as well as device selects plus 4 address lines. So without having to generate further chip selects each slot can have 4 devices with up to 16 registers. If registers are not involved you can put in some simple logic to address more devices. My plug-in boards are 100mm x 100mm. One system is a motherboard configuration with CPU, memory, console and 3-slot bus. The other is a Arduino style system that contains the CPU, memory and console on a small board that can plug into a backplane, a stack of boards or any other system that needs computer control.

Buses and backplanes are the way to go (my opinion).

Images below.

_________________
Bill

A quick way of checking out the hardware and running DOS/65 on GRC6502 is to port the CRC65 CPLD design to GRC's CPLD. The setup requires DOM, CPU module, CPLD module, and RAM/ROM module. Since CPLD has a small boot flash to load program from DOM to RAM, no flash is needed. These set of hardware have successfully emulated the functionalities of CRC65 to the point of running DOS/65 ver 3.2. The only difference is 6502 can only run at 7.37MHz due to the slow RAM. Adding VGA/PS2 module to GRC6502 should allow it to reach the goal of standalone 6502 computer running DOS/65.

Picture shows GRC6502 with DOM, CPLD, 6502, RAM/ROM, and VGA/PS2 mounted in PacTec CM5-200 enclosure.
Bill

This is the first time I'm seeing this, great work so far Bill!

I see your VGA/PS2 module has 2x of the 64 macrocell CPLD's. I'm sure you distributing the logic between the two, with most of it dedicated to the VGA side of things I'm guessing. What are you doing specifically with the PS/2 Keyboard functionality though? Is it compiling the serial data into an 8-bit parallel chunk? Is there an interrupt sent back to the 6502 when data is ready? Are you using the CPLD as a type of FIFO for multiple key codes such as "release" and "extended" or doing something different?

Neat project indeed, thank you for sharing!

Chad

One CPLD is for text VGA and the other CPLD is for PS2 interface. The text VGA is based on VGA6448, a monochrome 64 cols by 48 rows text-only display with 8x8 pixel characters. The PS2 CPLD converts PS2 data and clock to 8-bit data and associated status. It does not require interrupt but relying on pulling PS2 clock low to queue up incoming data on PS2 keyboard's type-ahead buffer. It does have interrupt capability but the source is 60Hz VGA vertical sync. While video is text only, the font table can be user-programmed to display pseudo graphic with resolution of 128x96, not great resolution but sufficient to do 20 frame/sec video. (I thought I have a video demo of BadApple! on 6502.org using text VGA, but I can't find it. I'll have to implement BadApple! on GRC6502).
Bill

Ah! Very cool, good idea using the bi-directional PS2 clock/data signals.

I would love to see HOW you implement BadApple! at all. It's a complete mystery to me

Chad

I did have BadApple for 6502 on CRC65, but it is for I2C interface. The original video was down sampled to the correct format for 128x64 OLED display. So the software running in CRC65 is just a player that bitbang each frame of data (1K bytes) to CRC65's I2C port every 50mS.

I can do the same for text VGA display except I'll down sample the original video to ensemble of 128x96 binary pictures offline; store the picture on DOM disk; and every 50mS, read a 128x96 image from DOM disk and transform into 64x48 text using font table lookup. I can write the transformed data directly to video memory so it should be faster than bitbanging data out to I2C port.

OK, this sounds like a good project for GRC6502...
Bill

I was hoping to run BadApple video under DOS/65, but I ran into file size limitation of DOS/65 which is 512KB per file. BadApple video is 4.7MB so I can only run about 15 seconds of BadApple with 1/2meg file. Here is a solution to that problem: Since DOS/65 file is compatible with CP/M, I used XMODEM in CP/M to load 4.7meg video in DOM as one contiguous file and wrote a program to read the image file and display them on text VGA monitor.

The video resolution is 128x96 so to display that as 64x48 text I need to represent 2x2 pixels as one text character. This is done by define 16 fonts, 0x0-0xF with every possible permutation of the 2x2 pixles. The program scan the image 2x2 pixels at a time and find the corresponding font and write to video memory. This can be done fairly quickly, about 20mS to read a 128x96 image from DOM, process it and write to video memory. I added 30mS delay per image to achieve 20 frames per second.

The black lines in the image is artifact of text VGA. To maximize the readability of 8x8 pixel font, I added two blank horizontal lines per line of text so there will always be 2 lines of separation between lines of text. It is possible to redesign the VGA circuitry to eliminate the two blank lines, but unfortunately there are not enough logic in CPLD to make it switchable.
Bill