Experimental IO (including usb LPT ports) on the modern PC

[barnacle]

Thirty or so gpio and you can actively drive any address in a 65c02 space including the processor control; completely romless operation? In fact, I think beyond the address and data bus you'd only need reset and bus_enable (maybe not even that? Bus disabled in reset?) and RnW to fill the ram as required. Which gets you awfully close to the Arduino/Nucleo plug and go approach.

LQFP (0.2mm wide pins, 0.5mm centres) is just about manageable with a hot air gun (I've done it with a soldering iron but it's a bit hit and miss) but QFN is a pain in the rear.

Neil

[Dr Jefyll]

barnacle wrote:

LQFP (0.2mm wide pins, 0.5mm centres) is just about manageable with a hot air gun (I've done it with a soldering iron but it's a bit hit and miss) but QFN is a pain in the rear.

To be clear, the intriguing FT4232H multi-IO chip mentioned in my previous post is available in LQFP. And BTW I edited that post to add some extra info. In particular, forumites may be interested in the pre-assembled FT4232H-56Q Mini Module!

barnacle wrote:

Thirty or so gpio and you can actively drive any address in a 65c02 space including the processor control; completely romless operation? In fact, I think beyond the address and data bus you'd only need reset and bus_enable (maybe not even that? Bus disabled in reset?) and RnW to fill the ram as required.

As you know, there'd also need to be a clock signal supplied, or at least a means to pause the on-board clock. But certainly there are some compelling advantages to pre-filling RAM this way!

On the subject of pre-filling RAM, the so-called "blind" loader espoused by forum member Michael and others offers a different tradeoff, in that it's slower but requires substantially fewer IOs. The forum Search function can help one find references to this. The address bus is not taken over nor even monitored by the host; only the data bus and the usual clock and control signals. Stepped a single cycle at a time, the CPU reads all its instruction bytes from the remote host... but when a write occurs the write propagates to RAM. Here's the gist. The "program" spoon-fed by the the host consists of a series of repetitions of the following pattern:

Code: Select all

LDA # thisbyte
STA thisaddress

... with each repetition individualized to contain the actual address and the actual byte that's desired.

(Taking things to extremes, there's an unrelated scheme that reduces the number of IOs even further. See my own Ultra-minimal 3-wire Interface boots up 65xx CPU's. )

-- Jeff

[Dr Jefyll]

Here's another intriguing chip useful for experimental IO. This one accepts serial bytes from a UART or USB/UART equivalent and outputs them in parallel format. The speed is somewhat limited, but -- remarkably -- no clock or crystal is required.

The outputs can tri-state and are capable of fairly high voltage and high current. They also have an optional Open Collector mode suitable for loads such as LEDs and small solenoids and relays.

Up to eight chips (total 64 bits of output) can be fed by a single serial line because there's an address matching scheme; each chip has three pins that are tied high or low to tell it its unique address.

Seems to me the SOUT strobe would come in handy if you wanted to use one or more 8153's to drive the bits of a small-ish, output-only data bus and address bus (and bus in turn could drive who-knows-what).

Edited to add: at first glance, it might appear that this device won't respond to the standard async serial protocol. And indeed the text mentions "two start bits," which is definitely unusual. But the two start bits are followed by only 7 data bits, so it's only necessary to adjust one's thinking. Just proceed as if it's one start bit and 8 data bits... and be sure the first of the data bits is always high (satisying the 8153's need for a 2nd start bit).

Also: there's a somewhat obscure point regarding the SOUT pin (which in many scenarios will go unused). Although the 8 data outputs clearly get tri-stated when the /OE input is false, it's unclear whether the SOUT pin is also affected. Thanks go to barnacle for reporting that SOUT is active at all times, regardless of /OE.

-- Jeff

sn74lv8153 smart shift-reg.pdf

(586.61 KiB) Downloaded 81 times

[barnacle]

That's a sneaky chip and not too expensive, though apparently only available in DIL or TSSOP. I like the way it's massaged the standard UART format to include the address (and note the baud rate has a minimum, too...)

I suspect an ambiguity in the datasheet, where it states that the SOUT outputs a pulse (only?) where the data has changed but the timing diagram implies that it happens every time data is loaded (i.e. every two 10-bit groups) - the latter I suspect is more likely, and a lot more useful.

A four-chip rom-less boot loader solution looks easy: two for the address, one for the data, and one to hold reset, clock, and BE (or hardware equivalent thereof for NMOS) disabled. Or perhaps just three if you didn't want all the address range...

24kbps for three chips would be 1k addresses per second... as you say, not speedy, but liveable with for a smallish bootload.

Thanks, Jeff. Nice find.

Neil

[Dr Jefyll]

Yes, I feel the same, Neil -- it does have a certain sneaky cleverness!

Here's a rough rendition of one possible version of the bus scheme I mentioned. Such an approach won't often be needed, but the potential scope is very broad.

-- Jeff

[plasmo]

I think ROM-less boot loader can be build with one 74LV8153 withTTL glue logics by feeding instructions for 6502 to execute and use SOUT to control 6502’s RDY. What I really hoping for is a transmit/receive serial device with status output and data port and operational without prior initialization. This way the serial port can both bootstrap ROM-less computer as well as serving as a serial interface. I’ve actually found and purchased such device, but misplaced it nor can I even remember the part number, sigh!
Bill

[barnacle]

Renesas 6402? https://www.renesas.com/us/en/document/ ... -datasheet

Neil

[plasmo]

Yes! Thank you. The two I bought were Harris D3-6402
Bill

[barnacle]

Here's my first cut at a remote boot: reset to this block forces things into boot mode, activates the uarts, and sets BE (probably should set nRESET low at the same time). Write an address - with the top bit set - to address 0x1 and 0x2, then write data to 0x0 which writes it to memory. Rinse and repeat, until you clear the top address bit which resets the latch and enables the 6502.

Not shown, because I just thought of it - as you'll always want to write to the top of memory, just include A15 in the collection. It'll need the processor RnW gating with the RnW from here so either can cause a write, and a bit if logic to reset the 6502 once it's released. Perhaps a reset chip with a switch input would work there.

Neil

[gfoot]

Interesting plasmo, do you know where you got it? I built my own circuit for similar reasons, to have a serial I/O channel that doesn't require configuration - I didn't find any off-the-shelf chips to do that at the time, I guessed it was because most people need more control over things like baud rates and byte formats while I was happy for that to be fixed in the electronics.

[gfoot]

barnacle wrote:

Here's my first cut at a remote boot: reset to this block forces things into boot mode, activates the uarts, and sets BE (probably should set nRESET low at the same time). Write an address - with the top bit set - to address 0x1 and 0x2, then write data to 0x0 which writes it to memory. Rinse and repeat, until you clear the top address bit which resets the latch and enables the 6502.

It's very neat. In a similar circuit I connected BE to nRESET, and had my circuit hold both of them low until it had finished initialising the RAM, which worked very well.

Is there a benefit to being able to write arbitrary addresses? It might be easier to just use counters instead of two of the 8153s.

Quote:

Not shown, because I just thought of it - as you'll always want to write to the top of memory, just include A15 in the collection. It'll need the processor RnW gating with the RnW from here so either can cause a write, and a bit if logic to reset the 6502 once it's released. Perhaps a reset chip with a switch input would work there.

I didn't understand what you meant here, could you explain that more?

[plasmo]

gfoot wrote:

Interesting plasmo, do you know where you got it? I built my own circuit for similar reasons, to have a serial I/O channel that doesn't require configuration - I didn't find any off-the-shelf chips to do that at the time, I guessed it was because most people need more control over things like baud rates and byte formats while I was happy for that to be fixed in the electronics.

I believe mine was purchased on eBay from some random seller. I should’ve tested them so I can return if they don’t work, but it is too late now.
I’ve designed serial port in CPLD so it doesn’t need initialization and status/data are accessible. However, once I’ve designed with CPLD, I can also have a small bootstrap ROM in CPLD so bootstrap becomes simple. I want to try serial bootstrapping without programmable logic so something like 6402 may work out.
Bill

[plasmo]

barnacle wrote:

Here's my first cut at a remote boot: reset to this block forces things into boot mode, activates the uarts, and sets BE (probably should set nRESET low at the same time). Write an address - with the top bit set - to address 0x1 and 0x2, then write data to 0x0 which writes it to memory. Rinse and repeat, until you clear the top address bit which resets the latch and enables the 6502.

My approach would not involve BE. I would tie SOUT to 6502’s RDY and parallel output to data bus. So after reset, 6502 is waiting for SOUT asserted to execute one instruction loaded into the serial-to-parallel device. This way, 6502 slowly executes instructions provided by the serial port to assemble a small program in RAM, and then jumps into RAM when bootstrap program is all loaded.
Bill

[barnacle]

gfoot wrote:

barnacle wrote:

Quote:

Not shown, because I just thought of it - as you'll always want to write to the top of memory, just include A15 in the collection. It'll need the processor RnW gating with the RnW from here so either can cause a write, and a bit if logic to reset the 6502 once it's released. Perhaps a reset chip with a switch input would work there.

I didn't understand what you meant here, could you explain that more?

Because I wanted to keep the top bit available to disable the outputs (via the d-type used as s-r) I didn't include it in the output address. I had some vague idea of controlling the memory halves separately (which you could still do) But it occurred to me that you'd always want to write to the top half of memory because of the reset vectors, and that probably you'd be wanting to write a top-of-memory image. So including A15 as the eighth output from the address is fine; when you address something below 0x8000 then the d-type is reset which enables BE and disabled the drive outputs on the serial chips.

You'd then want to reset the 6502, which I thought might involve some logic, but using one of those power-on reset chips with an external drive ought to do the job - or even just a monostable triggered by that A15 low output.

The advantage to the uarts rather than counters is that you're not constrained to a linear load of the complete addressable space; the same hardware works just as well with a 32k program occupying all of the top half of memory as an 8k basic living at 0xc000 and then a big hole up to the reset vectors.

@Bill: that's basically what my STM bootloader will do, though it does it by cheating the databus and clock so the processor always sees what it's told rather than what it might think it's doing... because it's getting a string of lda # and sta xxxx instructions, it's also a sparse loader. For example, you might have a hex file with all sorts of odd chunks in it; the loader wouldn't care.

Neil

Edit: but yes, if BE is attached to ~RESET then the problem of reset goes away: two null cycles and then it reads the newly installed reset vector.
If you want to use the full address space then you just use another serial chip at 0x3 and use it to control the flip-flop. You only need to write to it twice, so it doesn't slow things down - and you don't need to write to the high address block anyway except every 256 addresses if you're being linear, so you'd need to send only four bytes per address most of the time.

[barnacle]

@gfoot - there are a handful of flavours of the Harris 6402 available at only mildly obscene prices, though they ain't cheap. However, it looks like you need to buy in small bulk from Rochester. Jameco have a handful in stock and will sell singles.

Neil