As an alternative to to having 50+kB of ROM, it might be possible to compress the data and decompress on the fly. See, for example, https://lz4.github.io/lz4/, which conveniently has 6502 and 65c02 code for decompression.

floobydust


oooh that looks pretty good. I think I ran across it a couple days ago but it got lost in my 1000 browser tabs that I have open now. Thanks!

Rwiker, that LZ4 compression looks interesting.

If you're venturing into compression, you're making the software task a tad more involved in order to make the hardware task a tad less involved. That might be worth it - or it might not.

If you're looking at compression, consider what is the simplest scheme to be worthwhile. It might be run-length, or it might be indexes into stock phrases. It might just be packing eight 7 bit values into 7 bytes! Or it might be simplest to re-use an existing library, like the one given. But I think it's worth giving five minutes thought to the tradeoffs you're making.

You might save two chips if you could fit your data into 32k. Is that worth it? It might be. You'll have more software to debug, and a little less hardware.

I don’t think I’m going to go the compression route. I’m confident I can get the two rom chips working. More confident in that than I am with what is going to be much more complicated code on an unfamiliar platform. I think I need more practice with the idioms used in these 8 bit machines before I tackle using more complicated software routines. Knowledge of such compression might come in handy in the future though if this appliance generates any interest in projects.

So... Let me get this right. You want a 6502 to type 'sl' into a Pi at regular intervals so you can make an animated train on the screen of the Pi?

Like this one:




If so, then I'm somewhat confused. firstly you can get a Pi (or any Unix system) to do this on it's own, and secondly you don't need a 50KB ROM full of 'sl' commands. You just do it once, in a loop...

Now don't get me wrong - I'm all for using a 6502, but sometimes maybe it's not the best thing... Or am I just confused as to what you're really doing?

-Gordon

Ps. for those who may not be aware, the 'sl' command was created to hopefully 'help' poor dyslexic people like me who type sl rather than ls into Unix systems

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

No, that's not the story. It's explained in the first thread: the display device is a 'terminal' - hopefully a CRT device from the 70s!

No. I’ve captured the ascii sequence produced by sl and that is the data array I’m storing in ROM. Just calling sl on the pi is too simple. I want the 6502 to do a little more than that. The only reason the pi exists is because we don’t have any old serial terminals left on campus. The only one I found was a SunRay that was too new. It only has Ethernet as far as I can tell. It is a thin client instead of a serial terminal. so the pi is just the interface to our modern hdmi computer monitors. That part is simple.

The usage of the sl train animation sequence was to produce a terminal output that is at least somewhat interesting or eye catching without me having to spend much time coming up with something and determining the ASCII sequence to make it happen. I’ll be hiding the pi behind the monitor. The pi/monitor setup is just the replacement for the dumb serial terminals that were disposed of a long time ago.

The purpose of the device is to produce some sort of output that may be eye catching enough to generate questions and interest. It will sit in a glass display case in the hallway in our ECE department where it will be seen mostly by ECE and CS students. A demographic that in theory should have an interest in hardware and software design. The primary draw should be our ECE students as they learn the low level logic design, and low level assembly programming. But for some reason our ECE students have rarely taken on any special interest projects outside of class work. All of the very top students we have had have done ungraded special interest projects to learn outside of class. I’m trying to encourage more of that. Maybe some of the higher level and more complex things I’ve put out aren’t hitting the mark so I’m trying a retro computer test to see if that sparks interest. I do not want to spend 4000 man hours building something myself that does everything under the sun, and I already know something that presents itself as a fully running commodore isn’t going to cut it either. That seems too finished and refined. This is something I can challenge an interested student with. Asking them what they want to see it do. What hardware do we need to change? What software do we need to write? I’ll put more of my time into it to go beyond being a train appliance if a student(s) are going to put their time in it too. If no interest, I’ll pull it from the case and try something else. Sure if I just wanted a train I’d just use the pi and have it do that on it’s own. This isn’t about the train. The train is because that was an easy and interesting looking ASCII capture that I didn’t have to write or design.

Sounds good to me. It has to be fair game to take a pi and put it into a dedicated role, such as being a serial terminal. Otherwise the pi becomes a black hole which just ingests all the interesting implementation work and the 6502 fan has nothing left to do.

And having built this thing, if you do find a serial terminal, you have something to hook it up to!

Exactly. I will be putting the commented assembly code in the case too so that would be a serious buzz kill to see it just calling sl to run on the hidden pi. Need a little more code than that to show.

I’ll also be putting the schematic in the case as well, broken up into sections that make sense. This is why I probably won’t go with a CPLD for now either. Our Undergrads have worked with gates way more than with CPLD. They usually jump right to FPGA after 7400 logic gates.

And if an old serial terminal shows up in some forgotten cold storage on campus then I can always swap that in with probably just the addition of something like a max232 to drive the lines.

OK. Understood now.

And I might just be up for a bit of a challenge too

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'm going to agree with what Dr. Jefyll said and suggest you look a little more into bit-banging the serial output, because (though I'm a bit of a noob) it really does look to me easier overall for this application than dealing with all the extra stuff using a W65C51 brings in.

My reasoning is this: the "manual" delay you need to do because of the W65C51 transmit flag bug is about the same level of difficulty as bit-banging. But if you bit-bang via an SR latch:

1. Debugging will be easier because the connection between the instructions you execute and the output produced is simpler and more clear. You don't need to reason about the internal behaviour of the W65C51 (and all its configuration): you just look at the output of the latch, which presumably should correspond exactly to a bit from the data bus when it was written (and should be easily debugged if it doesn't).
2. You probably make address decoding a bit easier because there's only one "output register" to decode.
3. All the complexity of UART configuration, and some of the complexity related to interfacing the UART, is gone, leaving less to learn and fewer places for things to go wrong.

dsmc showed some code for bit-banging.¹ This is actually simpler than it looks because all you really need is a subroutine to shift out one byte. That sample code tries to get exact inter-character spacing for maximum transfer rate, but this isn't actually necessary.

The key thing to remember here is that the "stop bits" in this kind of serial data stream aren't actually bits: the 1, 1.5 or two stop bits actually define the minimum inter-character spacing. The link starts high and this is considered an idle condition; when the link goes low that indicates a start bit. The start bit and subsequent data bits need to have the specific timings for the particular bits-per-second rate, but after transmission of a character you bring the link back to high (idle state) and wait for at least 1, 1.5 or 2 bit times and at most forever. The link can stay idle for as long as you need or care to.

So basically all you need is a subroutine that loads the character to send (the loop1 section of the sample code), loops through shifting and transfering the bits (the bit1 section of the sample code) with the appropriate amount of delay between setting/resetting the latch for each bit, and then it sets the latch to idle value and exits. If you might be calling it again almost immediately with another byte, it could delay for the appropriate amount of time for the stop bits.

You do not need to do anything like having the loop2 etc. sections right after the initial loop to get perfect timing; I am fairly certain that that having slightly longer delays at various points in the data stream won't be a big issue. (It's not as if your output appears at precisely constant speed anyway; differences in the terminal codes needed as the train moves across the screen will mean that each "frame" will be a different number of bytes transmitted, anyway.)

I think that this would also help with your goals of this as an educational project for your students: instead of all the mysterious magic going on inside a UART this design exposes exactly what a serial link is and how simple it is. After all, we don't use UARTs because bit-banging is so hard to do or because the link protocol is terribly complex; we use them just because it's a lot more efficient to have a second "processor" banging out the bits than doing it ourselves.

__________
¹This was originally misattributed to CaptainCulry. Thanks to rwiker for the correction.

_________________
Curt J. Sampson - github.com/0cjs

That was actually dmsc, not CaptainCulry. dmsc also suggested using just a flip-flop and a NOR gate for implementing the serial output, and dispensing with RAM altogether.

I still like the idea of using LZ4 compression. I tested with output from the sl command (which I haven't come across before, but I'm now going to install it everywhere I can), and LZ4 compressed ~49kB down to 8926 bytes. Sooo, it should be possible to implement this with a 65(c)02, a 32kB eprom, a flip-flop and a single NOR gate. That does not make for something immediately useful for anything else, of course.

One might try for least hardware, or for easiest project, or for maximum educational value.

I'm not sure, in fact, whether a system with a UART doesn't have more educational value than a system which bit-bangs. Systems thinking is a good skill, and a UART is a good level of system component. A completely separate skill is understanding everything top to bottom, which is where bit banging comes in.

BigEd has hit the nail on the head. The UART is the appropriate level of abstraction/system level for this application. I need to draw students in and generate interest. There are no students already interested that are signed up to do anything. I know from experience that as soon as someone says "bit shift" to a sophomore that their eyes are going to glaze over and you lost them.