Zero glue logic 6502 SBC?

[gfoot]

This is what I did in my ARM2 project - on reset, the CPU is held in reset state while a counter ticks up driving the address bus, and ROM is copied to RAM. Then after that the CPU is let out of reset and runs from RAM only.

It's essentially a DMA operation, and it's very fast (one copy per clock cycle). The overall complexity on a 6502 would be something like a pair of flipflops, an 8-bit counter or two, and maybe a tiny bit of glue logic - I showed a possible circuit diagram for that cut-down version here: https://youtu.be/gA_D3plgqgI

Edit: adding a black and white copy here, sorry for the quality as I only have a low resolution snapshot now.

Schematic for 6502 memory preloading circuit

[plasmo]

tokafondo wrote:

My two cents about what would be the contents of a small ROM that would be copied to RAM before booting is a small bootloader that would load the rest of the code from a storage device to a fixed location and then jump there. That way the use would not need to update the ROM itself but the contents of the storage device.

Instead of 65C51 as ZG6502 I/O device, a 65C22 may be a better choice. This way it can be configured to interface to compact flash or SD disk and load & run more sophisticated software. 65C22 is also a more versatile I/O that can even do serial I/O in bit-banging fashion. I believe zero-glue logic approach is still possible with 65C22.
Bill

[fachat]

Sorry, but I'm not sure I got how the Zero-Glue 6502 works....

On Reset I understand that the ROM is always active, in all the 64k, while RAM is active in the low 32k.
So, I can read without bus contention in the ROM area, but when I write to the RAM area, the CPU will have bus contention with the ROM output, doesn't it?

So, my guess is - and I've probably missed it in the discussion above - that the ROM in its lower 32k already contains a copy of the data that is copied to from the upper ROM area? Then CPU and ROM would output the same value, and not generate contention (depending on output voltages etc), right?

That also means that during this coexistence phase the lower 32k must not be read before it is written or otherwise the RAM and ROM outputs have bus contention, right?
After copying to the RAM, both RAM and ROM have the same value, and no contention occurs, right?

Very cool design!

[plasmo]

fachat wrote:

Sorry, but I'm not sure I got how the Zero-Glue 6502 works....

On Reset I understand that the ROM is always active, in all the 64k, while RAM is active in the low 32k.
So, I can read without bus contention in the ROM area, but when I write to the RAM area, the CPU will have bus contention with the ROM output, doesn't it?

So, my guess is - and I've probably missed it in the discussion above - that the ROM in its lower 32k already contains a copy of the data that is copied to from the upper ROM area? Then CPU and ROM would output the same value, and not generate contention (depending on output voltages etc), right?

That also means that during this coexistence phase the lower 32k must not be read before it is written or otherwise the RAM and ROM outputs have bus contention, right?
After copying to the RAM, both RAM and ROM have the same value, and no contention occurs, right?

Very cool design!

Yes you are exactly correct. So let me explain in my own words which should match what you've said.

The EPROM data is duplicated in upper 16K as well as 16K from $4000-$7FFF. RAM's active-high chip select is tied to 6502's clock so when EPROM is copying data from its upper 16K to RAM from $4000-$7FFF, the same data already existed in EPROM. So it is true that EPROM is always enabled and driving the data bus while reading and writing, the data it wrote to RAM in the range of $4000-$7FFF is exactly the same data as already existed in EPROM. Another word, for the write operation both 6502 and EPROM are driving the same data out to the bus so there are no contention. The RAM is disabled until high phase of the clock where 6502's RWB force RAM's output buffer in tri-state mode, so again there is no contention caused by RAM.

One the 16K copying operation is done, program jumps to RAM area where both RAM and EPROM are driving the bus but with the same data. The program spin for enough time for reset supervisor to timeout and disable EPROM at that point RAM is solely in charge of the bus.

Bill

[plasmo]

plasmo wrote:

Instead of 65C51 as ZG6502 I/O device, a 65C22 may be a better choice. This way it can be configured to interface to compact flash or SD disk and load & run more sophisticated software. 65C22 is also a more versatile I/O that can even do serial I/O in bit-banging fashion. I believe zero-glue logic approach is still possible with 65C22.
Bill

After 3-1/2 years, I finally got around to design another version of zero-glue 6502, this time with W65C22S. I was disappointed with the top speed of ZG6502 rev0 limited to 7.37MHz. I've thought the CMOS W65C51 should be able to run to at least 14MHz. So rev1 replaced W65C51 with W65C22S and I hope to run it to 14MHz. Half of the board is prototype area and serial port is not even hooked up. My first challenge is developing a bit-bang serial port using W65C22S.

Bill

[BigDumbDinosaur]

plasmo wrote:

My first challenge is developing a bit-bang serial port using W65C22S.

Depending on what you are going to connect to the other end of the serial line, maybe you could leverage the C22’s serial shift register and thus avoid the timing hassles with a bit-banged port.

[Michael]

Nick Gammon's G-Pascal operating system may be worth a peek as it includes interrupt driven VIA serial drivers. I tested it on a little 8-MHz RAM-only board (below) that doubles as an EEPROM / Flash ROM programmer and it works quite well.

[plasmo]

The problem with bit-bang serial port is the tedious cycle counting to get the bit time correct. That's a real pain when bit-bang serial port is the primary communication interface. So after reprogramming the flash a number of times, I decided it is lot easier to add a mezzanine board with a serial port that acts as the communication interface so I can load and debug bit-bang program for W65C22. Fortunately ZG6502 has a RC2014-like bus interface to accommodate a CPLD board with proven serial port design. Here is my software development platform. Since CPLD serial port is fast, I've also tested out ZG6502rev1 is operating correctly at14.7MHz.
Bill

[drogon]

plasmo wrote:

The problem with bit-bang serial port is the tedious cycle counting to get the bit time correct. That's a real pain when bit-bang serial port is the primary communication interface.

I have successfully written bit-banging serial code for my 6507 project that works reliably to 38400 baud with a 2Mhz clock. (and I can select 9600, 19200 or 38400 at built time).

Going faster at 2Mhz needs more work, but for now I don't need to. It's good enough.

The one down-side is that it's half duplex, so "hitting Ctrl-C" to stop Basic running isn't a reliable thing, but sending a break condition is reliable.

I'll post the code at some point.

-Gordon

[plasmo]

My CPU clock is 7.37mhz, so I can do 115200 with 0.4% error. It is half duplex like you’ve said, so I use 2 stop bits to give the receiver more time. Raising CPU clock to 14.7mhz should give me more precision with bit timing at 115200 and handle receive more reliably.
Bill

[drogon]

plasmo wrote:

My CPU clock is 7.37mhz, so I can do 115200 with 0.4% error. It is half duplex like you’ve said, so I use 2 stop bits to give the receiver more time. Raising CPU clock to 14.7mhz should give me more precision with bit timing at 115200 and handle receive more reliably.
Bill

Just to give you more hope There is a project for the BBC Micro that handles receiving at 115200 baud on a 2Mhz 6502... I only had a brief look at it as it's essentially a very long unrolled loop... I don't have a link but you ought to be able to find it over on stardot.org.

The limitation (one of them) in my code on going faster (and it's fine with a single stop bit) is the timing loop granularity - the jsr/rts starts to count, so inlining it would be the way to go reliably faster, but it's in my TinyBasic system where every byte counts, so hard to justify. Another limitation is the time it takes to process each character and each line by the input code in TinyBasic - with a hardware UART it can be clocking in the next character while you are dealing with the current one, but in software, as I'm sure you know, you literally only have 1 bit time (the stop bit) to store the character - those 2 stop bits will help there - assuming you can make sure the sender can do it.

I found 38400 baud or about 3.5KB/sec was fast enough though - it's not as if I'm going to be sending a 32KB file into the system - especially as it only has 4KB of RAM!

-Gordon

[Michael]

plasmo wrote:

Raising CPU clock to 14.7mhz should give me more precision with bit timing at 115200 and handle receive more reliably.

Is the W27C512 ROM fast enough to run with a 14.7-MHz clock during that short period during start-up when you're copying ROM to RAM?

[plasmo]

On paper W27C512 is 45nS access, so no, not on paper. In practice, it is faster than spec and furthermore its chip select and output enable are grounded, so the access is from valid addresses to valid data out. W65C02 addresses are valid significantly earlier than the rising edge of clock, so I’m able to run successfully. My guess is it can run close to 20mhz.
Bill

[BigEd]

drogon wrote:

...There is a project for the BBC Micro that handles receiving at 115200 baud on a 2Mhz 6502... I only had a brief look at it as it's essentially a very long unrolled loop... I don't have a link but you ought to be able to find it over on stardot.org.

Some pointers: the UPURS page and downloads and hoglet's repo and the Wires? Pah... megathread on stardot.

[plasmo]

I’m successful implementing a bit-bang serial port using W65C22. Port B data[0] is serial transmit and port B data[7] is serial receive. The bit rate is 115200 at 7.37mhz or 230400 at 14.7mhz. The board can run at 16mhz, but won’t run at 18.4 mhz. It is half duplex so for file upload to work, the terminal emulator needs to set to 2 stop bits. The current consumption is 50mA at 14.7mhz, but about half of the current is consumed by the oscillator (22mA). I only need to bodge 2 wires; transmit and receive from W65C22 to serial port connector.
The simple monitor is derived from rev0 of ZG6502 which had W65C51 serial port. The W65C51 serial in and out routines are replaced with corresponding W65C22 bit-bang routines. It is a basic 4-function monitor that can display, modify memories, load Intel Hex file, and execute from user specified address.
Only 2 I/O lines of W65C22 are used for the serial port function, so there are lots of I/O lines available for experimentation.
Bill