So, sending a burst of NUL bytes might be a good plan, during the changeover. Or perhaps other characters with few ones - or few falling edges, like perhaps BEL.

Not sure if this Q&A is as helpful as it might be, but it concludes

To avoid ambiguity with 8N1 you'd need every 0 in your byte to follow another 0 on the wire - as if the preceding bit was a 1 then its repeat in the next byte could look like a valid stop bit.

So the only place you can have zeros is in a solid block at the least significant end. I think that means no printable ASCII characters are really suitable unfortunately!

This is the problem with any serial async 8n1 signal that's coming too fast: it's ambiguous where the start bit is in many cases.

Waiting for a period - even using a break - would allow the receiver to synchronise, even if it reads an initial garbage from line noise (unlikely); the problem I have is that the signal is already belting out at full speed when the receiver is initialised. Waiting for an incoming signal to say, hey, here we are now, is a simple protocol that should handle this. Simply waiting doesn't guarantee the receiver is ready.

I'm thinking of things like the default MS basic which starts by asking for a cold or warm start - that message is going to be lost during the rate change, and without a response it can understand it's not going to do anything... The on-board UART is probably confused by the slow speed stuff prior to the processor starting, too, so I start by resetting it rather than just leaping straight in with a config as Grant did.

Neil

I think this is the reason for the DTR and DSR signals in the 232 standard. They would indicate when the transmitter and receiver in each respective direction were properly set up and ready to communicate. Transmissions should not begin until both of these signals are in the active state.

Absent DTR and DSR being connected and checked, you could use RTS and CTS the same way. On the PC end, these signals are under purely software control, because the 8250/16450/16550 do not have automatic hardware flow control. If you negate RTS at the PC end until you've set up the new baud rate, and wait for CTS to be asserted at the SBC end before transmitting (I forget whether the 6850 does that for you, but the 6551 does), then you should start off nicely in sync.

The space character is ASCII 32, or 0x20. On the wire in 8N1 format, this would look like ______^__^, of which the first _ is the start bit and the final ^ is the stop bit. A continuous sequence of these could conceivably sync up in two phase orientations, corresponding to a stream of 0x20 or 0x02 characters being received. If the receiver encounters a space character when aligned to any of the other 8 possible phases, then it will get into a "frame error" state due to seeing a _ state where a ^ stop bit should be; it will then look for the next ^ and treat that as a stop bit, but about ⅔ of the time that will still be the wrong phase. I think a sequence of spaces and asterisks would eventually get into phase though.

A NUL character will definitely get into sync straight away, because the only part of a NUL that can possibly be interpreted as a stop bit is the actual stop bit.

I would be cautious of putting the 8153 on the same serial line that you use to normally communicate with the SBC. Although the 8153 "requires" the first bit received after the start bit to be high, that is only for its autobaud feature. If you send characters without that special feature, it will interpret the signal at a different, likely lower, baud rate. Because bytes are sent least-significant-bit first, about half the characters you send (the ones with even ASCII codes) will run into this. To say nothing of what it may or may not interpret from a signal at a faster baud rate than it can properly decode.

Yay! The world is temporarily the mollusc of my choice:

This simply includes a short string at the end of the minimal string output - it's about a millisecond and a quarter according to the scope. That's odd; I think it should be about half of that: five clock cycles times 542ns ought to be around 700us, and phase0is definitely 1.8432MHz. Strange.

The ACIA reset is temporarily removed but I think it should go back.

So anyway, more work to do but this proof of concept has shown that data can be transferred, that both of the ram chips are working, that the reset works as expected, and that serial data can be output.
Bearing in mind that this is a proof of concept, it's obviously got some issues:

• You can't reload the data if you don't hit the reset button first!
• If you hit the reset button. you must send some data to load.
• Separate buttons to load and to reset would be a good idea.
• Chromatix' point about the serial line and the loading line being the same is valid, but once the load finishes, the outputs from the 5813 are disabled. Snag is, this doesn't disable the data received output, which would at present cause an unexpected write to a random address. I think if the two inputs are sharing a line, then the SOUT pin needs to be better isolated from RnW

Neil

edit: fixed the delay length - I intended to replace a subroutine delay with an inline delay in case the return was breaking somewhere, but managed to leave both in. The ACIA reset is restored now, too.

Would an @ and a space, as a pair, perhaps twice, always be enough to force sync? Or space and backspace, which might be better yet? Things with a single 1, in this case $08, $20, $40.

Great! Something I've considered for my system is using breaks to prefix control sequence outside of the regular tty stream. E.g. making my 6502 system reset on a long enough break (at the hardware level), and making it send a break back to the PC during reset, that can put the PC back in bootup server mode. I haven't thought it through in detail yet though.

Well I guess that's why break was invented, no?

Meanwhile:

echoes terminal data back to the terminal. Nothing exotic, it just waits for the first received character and because of the delay in firing up minicom the outgoing data is synchronised.

Neil

The simplest sequence that always syncs up is a single NUL character, which will cause a framing error in a mis-synced receiver, which will then sync up to the stop bit. Another possibility is an 0xFF byte, which will not cause a framing error, but the latter part of the byte and the real stop bit will be seen as line idle, so the receiver will sync to the following start bit.

If we restrict the possibilities to printing characters, @ then space is a good choice. This would produce the sequence: …which, if we assume it sees the middle of the @ as a frame error, causes a mis-synced receiver to sync either with the correct stop bit of the @ or the set data bit of the @. In the latter case it will see a framing error on the space, and sync with the correct stop bit of the space. All subsequent characters are then guaranteed to be in sync, so the sequence does not need to be repeated.

Yet another possibility is to transmit using 2 stop bits (8N2) but continue to receive using 8N1 - if it's initially out of sync, that means it'll move towards sync by at least one bit position per byte. On the 6850 this would be word-format selector 100 rather than 101. This would also cause the 6850 to expect 2 stop bits on data sent by the PC, but the datasheet suggests that the 6850 checks only for the first stop bit.

So, modified rapture...

The load takes 15 seconds, which is probably quicker than paper tape; it waits for a '+' from the terminal before it does the BASIC cold/warm start.

Unfortunately, it looks like the interpreter interprets not... don't yet know why not. I had to port the code from Grant's listing to compile on the AS65 (Kingslake) assembler, so it's possible I killed something along the way. It's also possible that some combination of characters at the terminal is causing errant writes to random memory locations...

I think that for safety, a minor change about the RnW signal is required; perhaps to change U6D (hc00) for a single-gate hc157 controlled by the BE/RST signal, which would definitively isolate the 5813s from the memory once the load completes. (Obviously, a couple of blinkenlights would help the general look of the thing - one on BE/RST and one on the serial input )

But, I think that this has proved that the basic method works and that the program to translate a hex file into a binary loader file also works. Once the potential issue with unexpected writes is fixed, it provides a nice easy and fast way to prototype code on an SBC, with no need to program an E(E)PROM every time.

Woohoo!

Neil

edit: just checked; I don't have a 157 of any flavour in the house.

You probably have a different problem, but perhaps see this thread from last year:


A fairly common problem is for the user-supplied read or write character routines to fail to preserve registers.

Indeed, thanks. A lot of information there to digest... as mentioned, I'm using Grant's assembly theoretically unchanged (i.e. one stonking great source file) but with a lot of .byte -> db; .word -> dw; .org -> org; := -> equ; and a couple of tiny disguised instruction pairs, JCC and JEQ.

As I mentioned, I use AS65 not the CC65 toolchain (largely because it matches what I learned 40 years ago, and because it works to provide a nice intel hex file output). I wonder if I killed something in the bss/code line?

With the exception of the initial echo and wait for a +, the rest should be entirely Grant's version. Investigation proceeding...

Neil

Grant's rom.hex listing is assembled to run at 0xc000 but built with an offset of 0x0000. After manually editing (cut'n'paste) the load addresses I run that through my loader conversion (which ignores the checksum bytes at the end of the line) and I can send that to the board.

I don't usually see the 'Cold or Warm start' message, but hitting C behaves as expected; a simple loop enters and runs correctly.


However, attempting to type '100PRINT"MANDELBROT...' locks up the board every time. So it looks as if there is an issue from the random writes (or maybe it just doesn't like Mandelbrot )

So, to do:

• definitely disable the RnW signal from the 8513 once the load is complete (using whatever is in the bits box!)
• find out why Grant's binary is so different from mine.

Neil

So, fixed (hopefully) the extra writes: an OR gate excludes writes from the 5813 when it's output is disabled.

Slightly modified to fit on the screen:

And the result, some minutes later:

Neil

Oh interesting that that fix worked. I was going to say that, looking back at the schematic from your first post, it strikes me that when BE is low, the 6502 won't drive RWB, so it may float. This could cause unwanted writes while the address bus is changing during program loading, I think. Maybe a pull-up resistor would help there, as you don't have any spare high tristate outputs to feed in - or sacrifice an address line to gain a tristate output you can use to drive RWB (and then maybe you wouldn't need the NAND gate either).