Sure, but the magic of the IRQ version, in this use case, is that it saves you an extra 40 pin DIP.

The IRQ technique is a very clever way to make this thing fit on a "badge" by reducing chip count.

Plus the idea of driving the IRQ directly by the serial line, vs going through an "I/O chip" is clever and I think eye opening to folks who resist wiring I/O directly to the CPU.

Oh, I agree that it is clever in this usage. I was trying to understand the limits of the approach.

Lee's designed some 1802 computers where this sort of bit banged I/O is standard, as the 1802 has built in I/O pins. It never occurred to me to try something like this with a 6502.

You could always hang any normal IRQ devices off NMI instead with a little tweaking to the relevant routines.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Unfortunately not. It is all about timing the bits in a 10-bit frame and any tampering with the interrupt system including NMI will cause errors in the received data. While an NMI is processed, the delay loops for the bit timing cannot function properly.

It is an impressive showcase what you can do on a 65C02 with minimal hardware, especially for us cycle count nerds. It is not a solution for your everyday communication problems. The soft UART requires no other interrupts to be present and no excessive or prolongated use of SEI ... CLI. Even standalone the soft UART would trash its serial output if a frame is received at the same time. As long as you don't type faster then 4800 Baud this is not a problem, but if you copy large chunks of data into your terminal window, you should better make sure that there is a delay after each character. The built in xmodem protocol does not echo data and therefore does not have that problem (as far as I know).

It would be possible to use this as a quick and dirty debug interface switching off all currently running interrupt sources while in use. However, for myself I found a better solution using a homemade I2C to UART adapter. The I2C protocol allows interruptions at any time for any period of time. The downside is that you need 2 open drain output & input ports to make it work. If your project implements an I2C master anyway this is already present at no extra cost.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I am weak and after resisting, I finally succumbed to the urge to by the basic badge kit.

I hope you enjoy it Martin! Lee has had several HUNDRED orders, so you may experience a little delay while he gets caught up. Apparently, Chuck Peddle contacted Lee and requested a kit as well. Long live the 6502!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Does anyone have any fun code for this little SBC, I'm working on some BASIC libs now to control the LEDs like a video buffer

I have some (Broken) Basic that will look up ASCII in the font table and spit them out, the LED Driver doesn't like me doing it this fast, need to find a good way to slow these loops down to keep the LED refresh rate going while I POKE things into the main buffers.

BADR is the main buffer for the LCD
BF is the starting address for the font table
$FD4B is the LCD_Scan function called by everything to update the display.

I just got home... give me a few hours to come up with a few ideas.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Ok, try this out:



You do not need to clear $00E6. You will bypass the built-in delay of the LED_scan routine and call $FD4F (at the PHA instruction). This allows the refresh to happen at a decent rate.

You can also update all the digits at once before refreshing them, as done above. There are ways to streamline this and allow for more code in between refresh calls if needed.

I hope this helps!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I wrote this just to test the XMODEM transfer in EhBASIC. It resets the text to the default message and turns the Knight Rider effect into a binary counter. This just fills the two buffers with new data. It relies on the OS's LED_scan to refresh the display.



Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

(Welcome to our world, jrwr!)

@biged, Its been great so far

@8Bit, I love your code, The ASM is super easy to read!

My main project is to have the badge play chess with it self (badly) and say witty things after it wins/loses to it self

Interesting side effect, you cannot update the LED $00E3 buffer, it just sticks on the second green LED while in the loop

Not sure what $00E3 buffer is, but if you mean the Discrete LED's, that pattern is stored in the LDBuff @ $02C0 (32 bytes). It will refresh when LDig = 7. it will normally scroll through the 32 characters as the display scrolls, but since you have the scrolling disabled, the LED's stay fixed.

Here's the bit pattern for the discrete LED's:



So the LED's get a bit weight of:

You can update it with POKE $02C7, $80 + sum of bit weights to turn on. Example, to Turn on G _ G _ Y, the bit weight is $1A ($08+$02+$10). Add that to $80 (that keeps the serial port Idle) and a POKE $02C7, $9A will set those LED's.

Kind of odd, but it does work.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/