6502.org

So, I grafted a handful of 8153 onto my version of Grant's minimal chip count 6502 - assuming a 65c02, a couple of 32k rams, 6850, and no prom/eeprom. I doubt it will fit onto the same size 80x100mm board, though: there are four more chips and I might do a double footprint for DIP/SOIC rams.

The same serial line does both for the initial memory load and for terminal comms thereafter. There doesn't look like a risk of corruption as the 8153 are held in with their outputs disabled and stay there until the reset key is pressed. Let's ignore the crap reset circuit for now... I've used a fourth 8153 because I had a concern about the outputs being stable during the load sequence: the data sheet doesn't mention this.

It will need some software writing on the host side, to properly package the target address and the two halves of the data packet. I envisage something which can grab an intel hex file one line at a time, extract the line address, and spit it out - just need to watch whether the high byte increments during a line or it can be loaded at two writes per byte (three bytes if I need to specify the high byte address, such as at the start of each line). That gives a 33% speed up on the load, and it allows for sparse files.

Neil

Nice. Did you consider getting rid of the fourth receiver U11, and instead connecting UART_in to U4A's D pin and ~reset to U4A's C pin instead of S? Then you can send a reset pulse with the data line low to start the process, and another with the data line high to end it, and avoid needing the extra IC U11.

If I did that, I'd need to manage the serial line to be in a break at the appropriate moment, no? I'd like it just to see serial data at a suitable rate after a manual reset and let it get on with it.

Neil

(a minor confusion: I've recently rebuilt this system on a larger drive, and the library for 6502 has changed somewhat... Kicad doesn't mind cut'n'paste from an older drawing, but meant that the drawing has changed slightly. I haven't updated it above yet.)

Ah I assumed you were already pretty well in control of that line as these devices don't speak the standard serial protocol.

Another option is to just invert your ~reset signal to form the CPU nRESET and BE instead of using flipflop U4A - I think that would work too and remove the need for U11.

By the way if you want KiCad to draw a bar over a label these days you need to use {..} after the ~ to tell it which characters to draw it over - since version 6 or so, ~ on its own no longer works.

It depends how you look at it: I think they do if you look hard. They're an 8 bit, one start, one stop with the normal polarities, with the low bits first and with bit 0 always 1. See diagram. But you have to be careful to ensure that you have all the bits in the right order and right sequence Using the flip flop requires a physical reset before the chips' outputs are enabled again. Otherwise there would be a risk of accidentally receiving something that caused memory unpleasantness. Thanks for that; it's nice to know though it wasn't my intent; I've used ~ to negate a signal since forever.

Neil

A render of the proposed board. I think I'll get this one off to JLCPCB along with the STM board - also romless, but implemented in a different way. Both need some code writing and I haven't decided which I like better yet.

(hurriedly check that Mouser have some of the 8513 parts in stock!)

Neil

A minor change to make the reset work: reset on the lv8153 forces all the outputs low, which would have immediately released the reset line as originally drawn. Now, the manual reset forces BE and ~RST low, and a write of any data to the lv8153 at 0x3 writes a zero to the latch, taking BE and ~RST high (and disabling the outputs on the lv8153 chain).5

Oops!

Neil

edit: and that unconnected pin should be taken high, too...

It may be desirable for the ROM-less board to have a socket for flash device and a mode to boot from the flash. This way it may serve as a flash programmer and a way to test the programmed flash.
Bill

One could perhaps wish TI's doc were more forthcoming about this less-than-obvious point.

I didn't "get it" at first, either. And later when I posted about the 8152 I forgot to mention that it does apparently respond to pretty much the standard serial protocol. I'd better go back and edit that post now.

Nice to see a new project in the works, Neil! Should it perhaps have its own thread (with links back and forth to this thread)?

-- Jeff

Bill, this is really just a proof of concept - feel free to take the concept and run with it!

Jeff, I dunno about a separate thread, in that it's a design using something that came up here, but if you think so... I'll start something new in the morning.

I just realised I sent the gerbers off to have the PCBs made with the 8153s all misidentified as 8152... oh well

Neil

Back on the original subject, sort of: another idea for this 8153 just struck me: seven segment display driver. Two chips drive eight displays with no more than current limiting resistors and a timer multiplexor... I haven't shown the details but the upper chip should be in totem pole and the lower chip in open collector outputs.


Of course, it does rather rely on having either a 19k2 serial port going spare, or bit-banging it...

Neil

I like it. Another idea that could reduce the baud rate requirement could be to use just one 8153 to drive the digit selectors, and use a 74HC595 to cycle which segment is being addressed, shifting it along each time the 8153 is written to. One bit of the 8153 could supply the "serial in" input on the 74HC595 to ensure only one bit is set at any time, then there's still seven bits left for many digits in the display. I don't think any additional glue would be needed.

Actually, on that, you could use the SOUT pin to drive the 595...

That's what I had in mind, to shift it once per byte sent, but I think you'd still need to use a data bit to control the serial-in pin of the 595, unless you have a better way to do that?

Use a CD4017?