DigicoolThings Forum

Hello,

I can't seem to get a file to load successfuly into Tutor using minicom.

Is it correct that just the "LO" Tutor command should be used to put it in "receive mode" ?

Then, on the minicom side :
is it correct that "ascii" mode should be used (not kermit, x/y/z modem modes) ?

In a post in 68008 card thread, I saw Emil mentioned adding delays helped
(which I guess confirms ascii mode should be used, since ascii-xfer commands has options for that).
Any idea how big character and line delays should be ? I tried many values ranging from 1 to 100 milliseconds...

Also, which options for the ascii-xfer program used by minicom should be used ?
About the same story, tried many combinations with or without -e, -d and -n...
Usage: ascii-xfr -s|-r [-dvn] [-l linedelay] [-c character delay] filename
-s: send
-r: receive
-e: send the End Of File character (default is not to)
-d: set End Of File character to Control-D (instead of Control-Z)
-v: verbose (statistics on stderr output)
-n: do not translate CRLF <--> LF
Delays are in milliseconds.

Generally, it looks like the 2 or 3 first lines are not taken as "file content" to be loaded but as Tutor CLI input (and says "WHAT" )

Hi Vincent, sorry to hear you are having problems. Although minicom seems to be the default linux terminal emulator and works very well, I find it a PITA to use its user interface. I much prefer GTKTerm as it has some advantages for me, it lets me know when the USB serial adapter isnt conected and even automatically reconnects when it becomes available. tio is another handy terminal emulator for Linux.

Sometimes when transferring plain ascii files I find having a new line at the beginning helps to get things started if in case there is some garbage in the buffer before you start the transfer. I'm not familiar with the sequence of options needed on your board with its monitor though so I cant be much help there.

With comms delay times, I find 100ms is usually more than enough for end of line delay and a much smaller delay between characters.

BR David.

Hi David, thanks again for your reply !

Using other apps provided in Fedora, like SerialTest and moserial,
I can see that Tutor sends TIMEOUT a little while after the LO command in all cases,
even when transfer is already finished, or in progress (e.g. due to line delay setting).
Also built GtkTerm from source and result is the same.

I wonder if it's a problem with my IO card, since :

• there's some grainy buzz when I plug an headset on the IO board jack
• I had to cross RX and TX between the USB TTL (provided by Greg) and the header on IO board
  (while most posts or video mention that TX should be plugged on TX, RX on RX, etc.)
  But maybe 68008 card is different on that compared to 6809 ones ? It's not clear to me...

But having correct Tutor prompt and response to my commands (HE, DF, BA, MD, etc.)
I'd think it's okay and shouldn't expect problems with file transfers ?

Vincent wrote: Sat Oct 10, 2026 12:22 pm I can't seem to get a file to load successfuly into Tutor using minicom.

Hi. I'm not familiar with minicom. I mostly use Tera Term (Windows platform).

My first thought is to ask what baud rate you are using?

As I recall there is no handshaking in use, and I do recall making a "future project" note to have a look at re-writing (or, optimising) the Tutor serial routines to better suit my needs.

I do know that I need to drop the baud rate whenever using Tutor for file transfers (as compared to when using ASSIST09 with the 6809, to do the same thing).

Could this be the issue you are experiencing? Given that you are getting the correct prompt and other command responses (so not a Rx/Tx connection issue).

Hi Greg !

My setup was at 38400, I lowered it to 9600 but it still fails with timeout...

Vincent wrote: Sat Oct 10, 2026 9:02 pm My setup was at 38400, I lowered it to 9600 but it still fails with timeout...

My apologies. I’ve been buried in the 6809 world for the last few months, so my memory of TUTOR use had become a bit faded.

38400 baud works fine.

The main issue is that (in Tera Term), I need to set it's minimum 1ms delay per character.

Looking back at your original post, I suspect the issue is likely in your referral to using the “LO” command.

The command to use is actually: LO1

Note that “LO1” specifies to load from the Terminal port (Port 1). “LO” specifies the default Port 2 (on the original “Educational Computer Board”), which I also note just issues an eventual “TIMEOUT” (as you’ve described).
EDIT: As it’s now clear that I’d overlooked this important detail in my original Motorola 68008 CPU Card blog / video, I’ve now added a section to my blog post to cover this (for future reference). Thanks for bringing this to my attention!
You can find the added section here: Loading our .S19 Assembled Program File

Hi Greg, thanks for your reply !

It seems "LO1" was crucial to making it work, and those were minicom/ascii-xfr params I setup in minicom for ASCII transfer :
ascii-xfr -s -dv -c 1 -l 1
I'm not sure which parameters are really required (maybe -l 1 could be left out), but for now I'm happy.
[EDIT : it seems " -l 1 " is required for correct file transfer]

Also I notice that after transfering xmasl_oled.s19 and running it with "G 4000" (even without an OLED board)
the sound plays, and after it ends, there's no buzz anymore.

So basically it's working, thanks for that !

wrt. the sound buzzing, I tried a few things :

• I just removed the SN76489 chip from Motorola IO card : no effect, still buzzing
• I replaced the SN76489 chip with a working-here-on-another-card one : still buzzing
• I unplugged the 68008 CPU card from backplane (leaving just the Motorola IO card plugged on backplane) : no more buzzing

Now that loading xmas_oled.s19 and running it works, and that it sounds fine and there's no buzzing after it ends,
I'm not sure what it proves (I guess lack of initialization/reset on some lines), but at least I'm happy for now

Vincent wrote: Sun Oct 11, 2026 8:36 pm Hi Greg, thanks for your reply !

No worries. Glad I could be of help, and Thank You for alerting me to my blog oversight on the TUTOR Load command use!

Vincent wrote: Sun Oct 11, 2026 8:36 pm Also I notice that after transfering xmasl_oled.s19 and running it with "G 4000" (even without an OLED board)
the sound plays, and after it ends, there's no buzz anymore.

As regards the buzzing you refer to. It’s simply due to lack of initialisation, prior to use.

The SN76489 has no hardware Reset pin or function.

Therefore, it’s necessary to code an update to the SN76489 “Attenuation Control” to force each of the 3 sound channels, and the noise generator to be “Off”.

This is done in the “silenceSound” routine of my 6809 Christmas demos (or the “psg_stop” of the MC68008 Xmas demo).

On a commercial product this would be done post reset in the ROM system initialisation code.

However, since our MECB systems are for experimentation / learning, the various plug-n-play I/O Card peripherals are generally not initialised, until you execute your own code (unless specifically utilised by the CPU Card monitor program that's being used).

Also, removing the SN76489 chip would also result in buzzing / hum, as this would leave C8 (on the Audio output) unterminated, so you would hear noise / mains hum when connected through your amplifier.

Thank you for the thorough explanation.
I was mostly worried that my soldering job was so bad it introduced some defect.

This led me to my first 68008 "program", with mecb.inc, tutor.inc and psg.asm include files from Emil at :
https://github.com/epaell/MECB/tree/mai ... 008/SW/src
Built the S19 file with the include files in inc/ subdirectory and this command :
vasmm68k_mot -Fsrec -s19 -I inc/ -o psg_silence.s19 -L psg_silence.lst psg_silence.asm

This indeed shuts off the hum/buzz when loaded ("LO1") and executed ("G 4000") from Tutor.
(Adding all these details for future reference, in case it helps someone)

Vincent wrote: Mon Oct 12, 2026 8:39 pm (Adding all these details for future reference, in case it helps someone)

Awesome! A great example for anyone getting started with the 68008 CPU Card.