Ultra-fast output port using 65C02 illegal instructions

[BigDumbDinosaur]

Dr Jefyll wrote:

The question is, what would it do when the time comes to "execute" the undefined opcode? Can anyone help us with this?

The Kowalski simulator will not execute an illegal opcode. Furthermore, unless a line such as:

Code: Select all

	.opt proc65c02

is at the start of the source code, the simulator may refuse to execute any 65C02-unique instructions (Rockwell ones, not WDC) at all.

[VinCBR900]

Appreciate its been a while, but is there something similar for the NMOS 6502 family?
I am looking for a 1 bit output port for bit bang serial to put Tiny Basic on a 28pin 6504, with serial input using the IRQ pin.
There is this neat hack by c0pperdragon but it requires ML pin, which the 28 pin devices don't have
https://github.com/c0pperdragon/SingleB ... /mainboard

[Dr Jefyll]

Hmmm, 6504. So... a 28-pin package, which lacks A15 - A13, /NMI, /RDY, PHI1OUT, MLB and -- two of my favorites! -- /SO and SYNC!

I'm sure there are still some good options, but the best choice will be one that doesn't add much to your existing design. Is the design at all fleshed out yet, or is it still very much a work in progress?

For example, is there any other I/O in the system, or will it only have bit bang serial? Also, how much RAM and ROM will be present? Will you require all of the thirteen address lines? (Just checking; very likely you will... )

Congratulations on your first post, VinCBR900! And BTW I like c0pperdragon's trick which you linked us to!

-- Jeff

c0pperdragon wrote:

Serial output

This CPU provides the MLB pin that is intended to implement multi-processor systems. By using some specific CPU instructions (all with a read-modify-write functionality), this pin can be driven low for 2 clock cycles at a time. While this is not enough to directly implement a serial output, it is one part of the solution.

The other part is to use the two unused NAND-gates to implement an RS-flipflop which has the MLB pin as its R input and the A15 address line as its S input.

The overall result of this circuit is that the CPU can drive the flipflop to its low state by executing one of the read-modify-write instructions on a ROM address. And it can drive it high again by doing any access to the RAM. This is enough to drive a serial output signal in software

[VinCBR900]

Dr Jefyll wrote:

Is the design at all fleshed out yet, or is it still very much a work in progress?

Definitely not fleshed out, not even 12% of a plan - more a concept. Just for a fun challenge, the idea is to push the boundaries of the breadboard computer for the lowest cost Tiny Basic system that we could have made in 1976 using period parts.

So, this is where the lower cost 28 pin NMOS 6502 CPUs which addresses 4-8kbyte with varying pins bonded out come in, coupled with a 2716 EPROM - we might need to cheat a little on dates for the SRAM with a Mostek MK4801 or MK4802.

This leaves an async serial solution that forgoes an expensive (in the 1970s) UART - after many years the IRQ pin has been programmed for RX input with a memory mapped D type FF for TX output, but it would be cooler to do an unused opcode hack like you suggested with the 65C02, if technically possible.

I think this is still on topic for this thread - so is there an pair of benign NMOS unused opcodes we can trivially decode as above, but instead of using SYNC can we use ROMENable, RD and maybe PHIx and feed a latch e.g DB5 with 1A/3A, 5A/7A, DA/FA?

Edit: Oh wait, I get it now. This only works on an instruction fetch with SYNC pin. The 28pin devices don’t have this, so any rom access with the magic byte would trigger the IO bit.

[Dr Jefyll]

VinCBR900 wrote:

any rom access with the magic byte would trigger the IO bit.

Yes, I was gonna ask you if you'd anticipated the challenge of avoiding spurious triggering. BTW I like how you and c0pperdragon seem inclined to think outside the box!

And maybe there's a solution to the challenge, but without SYNC you'd have to detect some other condition or behavior that acts as a message saying, "Yes, this is the cue to say that occurrences of the magic byte (ie, undefined opcode) aren't spurious and should be recognized."

After playing with that notion for a while, it struck me that, for something as simple as a Bitbang Serial Output, recognizing the magic byte is actually overkill. It would be sufficient to simply detect some other condition or behavior!

Given that they respond to program activity, address lines are to some extent under our control. But to set an address line high or low and have it stay high or low means the program's activity would be very drastically constrained.

For example, it seems A12 will be unused, so you could use A12 as your Bitbang Serial Output, and set it and keep it high by jumping to an address that contains a one in that bit position. But the code at that location couldn't access zero page, because that'd cause A12 to go low for one or two cycles then return high.

So... instead of simply looking at an address line's present state, would it be better to look at a few samples of its recent history? A moment ago I said it'd be normal for A12 to go low for one or two cycles, and we know that's a very common event. But for A12 (or any other address line) to go high then return to its original state after three cycles seems like a rather uncommon event (although it could be produced at will).

And I seem to have hit on a nice, simple circuit to detect that event and remember its occurrence. But the details are too half-baked for me to share tonight!

-- Jeff

[Michael]

Anyone know what the following items cost in 1976? Was SRAM available (affordable?) in 1976?

R6504 CPU
MC6850 ACIA
74LS139
2716 2Kx8 EPROM
2732 4Kx8 EPROM
6116 2Kx8 SRAM

[Dr Jefyll]

This sounds like great fun! But to preserve the focus of this thread I have created a new one to host the challenge VinCBR900 has posed. Please direct your comments and suggestions here:

DESIGN CHALLENGE: lowest cost Tiny Basic system for 1976

-- Jeff