First documentation for the SL Appliance build

Building your first 6502-based project? We'll help you get started here.
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: First documentation for the SL Appliance build

Post by BillO »

Wow, I hope this does not [defend] (s/b offend) anyone, but this seems to have gotten complicated beyond reason. Why are we even talking about bit banging and interrupts?

Read a character from memory, send it out the UART. Correct me if I'm wrong, but this is the task, right?

If so, use a non-WDC 65C51, and use it in a simple poling mode.

Code: Select all

Start Simulation:
     While there are characters to output:
          Read character from memory
          Loop:
               Check UART Transmitter
               If not busy then Exit Loop
          End Loop
         Send character
     End While
Repeat Simulation as required
End
The actual assembly code would probably have less characters, including the initialization procedure.

Since the CPU has no other tasks to deal with, implementing interrupts or bit banging seems like an unnecessary complication. Personally I think it's best not to teach Engineering students to implement unnecessary complications. Unless, of course, if they intend to work for BMW.

This could be done with as little as 5 chips if you are willing to use a GAL or something like that. That might be an idea, to show students how to use programmable logic to reduce complexity in the hardware.

Of course I could be mistaken :?
Last edited by BillO on Wed Jan 08, 2020 10:20 pm, edited 1 time in total.
Bill
User avatar
cjs
Posts: 759
Joined: 01 Dec 2018
Location: Tokyo, Japan
Contact:

Re: First documentation for the SL Appliance build

Post by cjs »

BillO wrote:
Read a character from memory, send it out the UART. Correct me if I'm wrong, but this is the task, right?
Yes.
Quote:
If so, use a non-WDC 65C51....
Which is suggestion #1 in my previous post. However, this conversation is actually split across three threads, and it's in this post in the first one that CaptainCulry settled on the W65C51:
CaptainCulry wrote:
I did consider a lot of other UART options. The older 6551 chips that don't have the bug, but they are kinda pricey used chips that take a month to ship from a recycling yard in china. I considered that DUART board that is on one of the hobby pages, and maybe putting an xbee on one of the UARTs. I thought about using a 6522, and an SPI MAX3100. But being that this is just going to be an appliance on a solder-less breadboard for now, all these options just seem to add unnecessary complexity that the project doesn't need, and I maybe don't need to have on my first build. The memory map is already bizarre enough.
Curt J. Sampson - github.com/0cjs
CaptainCulry
Posts: 30
Joined: 31 Dec 2019

Re: First documentation for the SL Appliance build

Post by CaptainCulry »

BillO wrote:
Wow, I hope this does not defend anyone, but this seems to have gotten complicated beyond reason. Why are we even talking about bit banging and interrupts?

Read a character from memory, send it out the UART. Correct me if I'm wrong, but this is the task, right?

If so, use a non-WDC 65C51, and use it in a simple poling mode.

Code: Select all

Start Simulation:
     While there are characters to output:
          Read character from memory
          Loop:
               Check UART Transmitter
               If not busy then Exit Loop
          End Loop
         Send character
     End While
Repeat Simulation as required
End
The actual assembly code would probably have less characters, including the initialization procedure.

Since the CPU has no other tasks to deal with, implementing interrupts or bit banging seems like an unnecessary complication. Personally I think it's best not to teach Engineering students to implement unnecessary complications. Unless, of course, if they intend to work for BMW.

This could be done with as little as 5 chips if you are willing to use a GAL or something like that. That might be an idea, to show students how to use programmable logic to reduce complexity in the hardware.

Of course I could be mistaken :?
You are absolutely right Bill. Actually I'm even going to use the chip with the very serious hardware bug, because in my application that bug isn't even a big deal at all. Mostly the discussions have just been needless rambling about the hardware bug and various options people could use to avoid it.

Even with the bug, in my simulation the code will be much like you described, just with a delay instead of checking the transmit flag. Not a big deal.

Code: Select all

Start Simulation:
     While there are characters to output:
          Read character from memory
         Send character
         Delay for long enough that the character sent
     End While
Repeat Simulation as required
End
And the delay in this application is trivial to calculate, implement and test.
Post Reply