tiny serial bootloader with support for remote debugging

[tius]

My small serial bootloader is now published on Github (https://github.com/tius/tinyload65).

It allows convenient bootloading and debugging and places very small requirements on the target system (~220 byte code for full version and 2 i/o lines). Should be relatively easy to integrate into the ROM of current and historical systems. The host component for debugging is not yet implemented, but perhaps the software is already useful for someone.

It would be great if someone would be able to customize a vscode debugger extension for it. This is still a bit beyond my current skills.

[BigEd]

looks good - thanks for sharing!

(I suppose there's very little time cost to reducing the packet size from 256 to say 64 or even 32? I'm thinking the whole loader and buffer could live in page 1.)

I take it 57600 baud is for a 1MHz 6502? That's impressive! (We've previously seen 115200 on a 2MHz 6502, equally impressive.)

[tius]

BigEd wrote:

I take it 57600 baud is for a 1MHz 6502? That's impressive!

Thank you very much! It took me some time to get that right

[BigDumbDinosaur]

tius wrote:

BigEd wrote:

I take it 57600 baud is for a 1MHz 6502? That's impressive!

Thank you very much! It took me some time to get that right

At 57,600 bits per second (N.B. “baud” is not the same as bits per second), there are only 17.36 µseconds between successive incoming or outgoing bits.  At that speed, the MPU would be virtually saturated trying to serialize/de-serialize the data flow.  I’m not trying to throw water on your campfire, but I’m having some doubts that such performance can be sustained via bit-banging...if that is what you are doing.

BTW, I haven’t looked at your code (I don’t do Github), so there may be another aspect to this of which I am unaware.

[tius]

BigDumbDinosaur wrote:

At 57,600 bits per second (N.B. “baud” is not the same as bits per second), there are only 17.36 µseconds between successive incoming or outgoing bits.

This is absolutely correct and means that the interval for sampling the input signal must be varied between 17 and 18 cycles, depending on the bit position.

An additional difficulty arises from the fact that the detection of the start bit is associated with large jitter. This is particularly true if a timeout is also to be implemented.

When sending data, the timing is much easier to maintain.

BigDumbDinosaur wrote:

At that speed, the MPU would be virtually saturated trying to serialize/de-serialize the data flow.

That is correct. Traditionally, this only works if the inner bit loop is unrolled. Thanks to a rather neat trick (not by me), it often also possible to do it with a loop. However, the remaining time for processing the data is then minimal. If a deviation in the baud rate of 2.4% is to be tolerated on reception, the reception and processing of a byte may require a maximum of 170 cycles in total. This is just about feasible for receiving a block of variable-length with a maximum of 256 bytes.

[BigDumbDinosaur]

tius wrote:

...However, the remaining time for processing the data is then minimal. If a deviation in the baud rate of 2.4% is to be tolerated on reception, the reception and processing of a byte may require a maximum of 170 cycles in total. This is just about feasible for receiving a block of variable-length with a maximum of 256 bytes.

A real UART is a lot easier.    Jus’ sayin...

[barnacle]

Or even a handful of 74hc: viewtopic.php?f=4&t=8020

Neil

[dmsc]

Hi!

tius wrote:

My small serial bootloader is now published on Github (https://github.com/tius/tinyload65).

Great to see the optimized software serial code

In the "optimized tx_byte for bit 0" you can chop two bytes by using ASL instead of ADC:

Code: Select all

    sta _tmp                            ; 3
    lda #_OUT_LO                        ; 2
    sta SERIAL_TX_PORT                  ; 4     start bit
    sec                                 ; 2     end of byte marker
    ror _tmp                            ; 5     _tmp = $80, c = 0
    DELAY4                              ; 4     
    lsr                                 ; 4     
                                        ; 22    

    ;   repeat 8 times          
@l0:        
    rol                                 ; 2
    sta SERIAL_TX_PORT                  ; 4     
    lsr                                 ; 2
    lsr a:_tmp                          ; 6     use absolute addressing (!)
    ASSERT_BRANCH_PAGE bne, @l0         ; 3/2   zero after last data bit
                                        ; 17    total 135 = 17 * 8 - 1

The same can be used if TX pin is bit 7:

Code: Select all

    sta _tmp                            ; 3
    lda #_OUT_LO                        ; 2
    sta SERIAL_TX_PORT                  ; 4     start bit
    sec                                 ; 2     end of byte marker
    ror _tmp                            ; 5     _tmp = $80, c = 0
    DELAY4                              ; 4     
    asl                                 ; 4     
                                        ; 22    

    ;   repeat 8 times          
@l0:        
    ror                                 ; 2
    sta SERIAL_TX_PORT                  ; 4     
    asl                                 ; 2
    lsr a:_tmp                          ; 6     use absolute addressing (!)
    ASSERT_BRANCH_PAGE bne, @l0         ; 3/2   zero after last data bit
                                        ; 17    total 135 = 17 * 8 - 1

In the RX_PKG code, you can use any bit for input by reusing your "CPX" trick to check the start bit. I would prefer to use CMP, to make the code compatible with the original 6502, like this:

Code: Select all

    lda SERIAL_RX_PORT
    and #255-SERIAL_RX_BIT
    ldy #0                              ; 0.72 s initial timeout

@loop:    
;------------------------------------------------------------------------------
;   wait for start bit with timeout (0.72s with Y=0)
;
;   7 cycles minimal + 11 cycles jitter (12.5 cycles average)

@wait_start:    
    cmp SERIAL_RX_PORT                  ; 4
    ASSERT_BRANCH_PAGE bcc , @read_byte ; 3/2
    dex                                 ; 2
    bne @wait_start                     ; 3/2       
                                        ; 2815  total (11 * 256 - 1)

    cmp SERIAL_RX_PORT                  ; 4
    bcc @read_byte                      ; 3/2
    dey                                 ; 2 
    ASSERT_BRANCH_PAGE bne ,@wait_start ; 3/2       
    on_timeout

You can construct the comparison value at the start and store into a ZP location, so you can reuse it in the code to read the bits.

Have Fun!

[tius]

Hi dmsc,

thank you very much! That looks very good. it's always really good when someone else looks at my code

I will install and test everything.

Have a nice weekend!

[tius]

I have taken up dmsc's suggestion to optimise tx_byte. A total of 4 bytes can be saved if ddr is set to $01. This is guaranteed at system startup.

If the bootloader is also used for debugging, it may be necessary to switch to the safe version of tx_byte.

[tius]

dmsc wrote:

In the RX_PKG code, you can use any bit for input by reusing your "CPX" trick to check the start bit.

I think that's a good idea. The prerequisite is, of course, that the state of the other bits is known or at least does not change during reception.

However, I have not yet found a way of accommodating the additional cycle for loading the compare value from zero page without the total time for a byte exceeding 170 cycles.

However, I have made a note of this for later improvements.

[plasmo]

I have a very similar bit-bang Rx ant Tx for Muntz65. I will study your code and see if I can optimize my code further. Muntz65 is a barebone design that uses a 22V10 for serial port and program storage which has space for about 50 bytes. At powerup, the bootstrap code needs to receive monitor program from the serial port and store it in RAM, so most of the 50-byte code is for serial receive. The bit-bang transmit code is loaded serially so it does not need to be particularly efficient. The 6502 is running at 7.37MHz, so 115200 is readily achievable. However, the serial port setting has 2 stop bits to give the program more time to process incoming data (the receive protocol is Intel Hex format). To save hardware, transmit is a latch implemented in 22V10, receive is just a 2K resistor between serial in and 6502 data7.
Bill

[barnacle]

For curiosity, Bill, do you use the parity bits in the intelhex data stream? I usually take the view that they're effectively pointless, since the data transfer (e.g. to an eeprom programmer) is most likely local and from something like a USB-ttlserial adaptor and therefore effectively bombproof.

I treat each intel line as a single entity, from the leading : to the final CR (which is a bit naughty since strictly the CR doesn't have to be there, but I've never seen a file in which it isn't.

Neil

[tius]

plasmo wrote:

I have a very similar bit-bang Rx ant Tx for Muntz65.

Thanks for the pointer to Muntz65, Bill. Great concept, I like it very much!

[plasmo]

barnacle wrote:

For curiosity, Bill, do you use the parity bits in the intelhex data stream? I usually take the view that they're effectively pointless, since the data transfer (e.g. to an eeprom programmer) is most likely local and from something like a USB-ttlserial adaptor and therefore effectively bombproof.

I treat each intel line as a single entity, from the leading : to the final CR (which is a bit naughty since strictly the CR doesn't have to be there, but I've never seen a file in which it isn't.

Neil

Neil,
I do check the checksum of the Intel Hex. While transmission from my desktop to work bench is error free, any error with the checksum indicates there are other issues not related to transitory transmission error. It tells me to investigate the issue instead of shrug it off as trasient errors.

tius wrote:

Thanks for the pointer to Muntz65, Bill. Great concept, I like it very much!

The same concept of bare-bone computers with bit-bang Rx code in 22V10 was implemented in Z80 as well as 68008. I think it should work for other retro computers.
Bill