So the hardware of my SBC is finished and now I want to transfer programs or files via xmodem. The xmodem implementation is from this forum under 'Code' http://6502.org/source/io/xmodem/xmodem.htm but I can't get it to work. I have modified it to work with Brian Phelps SyMonIII which has interrupt driven input.
When you start xmodem transfer with minicom you select a file you wish to send and then it asks you to start the SBC's receive routine. But you can't because minicom wont allow you to send a command to your SBC as it is waiting for the SBC to start receiving data.
So how do you send a file to an SBC when you only got one serial port?

I had a similar problem with my setup. I switch the SBC into xmodem receive before I use minicom to do the transfer (making sure I don't press any keys in the mean time). Minicom will eventually try the send after a few seconds. It is all a bit rubbish, but I suspect it's a minicom limitation and not a fundamental flaw. I can't see why you shouldn't be able to switch to disable normal keyboard input, send the xmodem data without a pause, and then switch back.

I'm not familiar with the code you are using; I wrote my xmodem handler myself, since it's so simple.

Maybe someone with experience of other terminal software could jump in.

_________________
8 bit fun and games: https://www.aslak.net/

Yes, start the xmodem receive on the SBC before you start the xmodem send in the terminal. I should have included that in the text file.

Hope it works for you!

Daryl

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

I'm using ExtraPutty as a terminal program for my 65C02 system. My Xmodem loader allows an offset for the load address to be entered, then goes to a 5 second delay before starting the transfer which allows time to setup the file send on the terminal program. As per Xmodem protocol, a "C" is sent from the 65C02 system to signal ExtraPutty to begin transfer. It also loops back every 250ms or so and repeats sending the "C" until the transfer starts.

I've also found that not all terminal programs respond properly to the Xmodem commands so it's always possible that you might need to make some changes depending on the terminal program you're using to send data. I posted my monitor/bios code before but have a newer version should your care to take a look.

_________________
Regards, KM
https://github.com/floobydust

If the link between the Linux box and your SBC is hardwired there is no need for use of Xmodem. Short links (under 50 feet) are HIGHLY unlikely to develop errors. When I transfer code from my Linux development machine and my POC unit I send Motorola S-records. At the Linux end it's a simple exercise of writing the file containing the S-records to the serial port linked up with the POC unit. I run the link at 115.2Kbps with hardware handshaking and have never had a transfer fail with an error.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

For me, I wanted xmodem so I could transfer straight binary files vs. encoded files such has Intel-hex or S records. I was not concerned with error detection or correction as I always use short cables, as you mentioned.

Daryl

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

I opted for Xmodem as it's supported by the terminal program (ExtraPutty). My 65C02 system only has a single port, so I needed something that could work with that and support file transfer. I also added S-record sense/support to the loader so I can download the S-records generated by the WDC linker. I agree it's overkill for a short direct connection, but it's easy to manage with a single serial port.

_________________
Regards, KM
https://github.com/floobydust

Well, for now I've given up on minicom and xmodem so I wrote a small program that translates the binary file to ASCII hex and use SyMonIII original download code. It works just fine. I will probably revisit xmodem in a future date but right now I would like to start experimenting with a Dallas 1511Y+ RTC/WatchDog and 65C22 interrupts.
Hence the need to be able to upload code.

Thanks all of you for your suggestions though.

I've been through the SymonIII code extensively and made a lot of modifications to it initially. The default ISR handler in SymonIII processes a null character as a program break, so any binary transfer wont pass the character receive routine. I've since written a complete BIOS for the 6551 and 6522 with an ISR that handles the 6551 and both timers of the 6522. It also handles the BRK opcode and a null character. I added an Xmodem flag to the BIOS so it will accept all characters into the buffer which is a requirement for any binary transfer routine. The Xmodem loader uses this flag when receiving a block from the terminal program.

_________________
Regards, KM
https://github.com/floobydust

Huh, didn't notice that. Perhaps that's why the download routine is handling ASCII hex and not binary files.


Well, to write my own BIOS is a long term goal. Right now I'm learning how program the chips and getting something out from them. The bin to ASCII hex program I wrote seems to work just fine so every time I assemble the makefile will also produce the ASCII hex file.
But right now I'm battling 65C22 IRQ's (or rather I'm learning how they work).