I've been wondering if your USB interface could be jigged up somehow to solve the Sym's fundamental serial coms problem, that it does not hold up serial input while it is processing a previously input character leading to serail data loss. This is the one problem that stops serial file transfers and multi character producing keystrokes like arrow keys from being easy.

It's pretty easy to put a patch for the serial input in supermon to have it assert a control line when it accepts a character for processing and reset it when it's waiting for input and if your hardware could hold up serial data while that line is asserted then it should remedy the problem.

Perhaps another idea I'm not so sure about because I'm not well up with hardware, but perhaps if your PLD can fire up a control line when it decodes the $8a58 address that is the get character entry point and the USB port will let 1 character through when that happens.

That might be a crazy Idea I don't know. Maybe you've got some ideas of your own, maybe you've already solved the problem.

Oh yes, and another symbiosys command that is good for testing as it doesn't need the disk is the hex dump.

# hex 9000 9fff

to dump the symbiosys kernel.

actually that only leaves another few intrinsic commands rm, fetch, rae and 6000.

# rm *
deletes files in the current directory, it will ask for verification before deletion and like all the file commands that process wild cards the possible inputs at the verify prompt are

return to accept this file
tab to skip this file and go on to the next matching filename
and ctrl c to abort and go back to the symbiosys command prompt.

#rm 2:*
deletes files in user area 2.


# fetch *
loads file into memory at the load point saved when the file was stored. (I must change that so you can load the file in anywhere).

# rae
executes the warm entry into the resident assembler

# 6000
executes a binary loaded into $6000, which is just a kludge to mae it execute whatever I'm developing at the time.

The cp command to copy files is the first of the external executable command so I'll have to put that online so you can download it. It copies files to any user area now and batch file copying too.

The USB interface is based on a FTDI chip, which basically converts USB to TTL, which I then feed into the Sym via the K Connector.

It does support handshaking, so theoretically it could be jigged so that there is no data loss. However it would probably still require some kind of Hardware or Software handshaking at the SYM end.

A couple of ideas come to mind. Maybe to patch Supermon to maintain a small receive buffer and send Xon Xon commands via the comms as needed.

Alternatively a couple of IO lines could be used on the A or AA connector to establish CTS RTS handshaking.

I will give this some thought.

the cp binary is now online as a papertape. time to get the uploading and creation of an executable binary down.

http://b5.net/sym1/cp.bin.ptape

now you'll get to see how the serial file transfer with work with your USB by trying to load this papertape over it. On3ce you get it to the Sym it will be sitting at $6000 to $6280 so issue the command...

# store * cp 6000 280

you chould then be able to execute

# cp

then try something radical like

# cp * 2:

and perhaps

# cp cp :1

to copy cp itself into the common searched bin area ( area 1:) so you can call it from any user area.

it's still under development so it prints out diagnostics which slow it down and confuse everyone. And when I just did a batch copy here is copied the last file twice so that would be a boundary issue. It also overwrites files with no warning.

So lets see if this procedure works and we can start distributing software.

So far all the problems we've had, could have been much worse.

ok that goes into a loop copying single files. I must have introduced a bug last time I was working with it. Oh well as an academic exercise it's still good. I'll get onto that problem later.

here is the bugfixed cp binary. I think I've fixed the serious issues completely

http://b5.net/sym1/cp.bin.6000-62cb.ptape
the command for saveing this as an executable would be..

# store * cp 6000 2cb

and here is the calculate PI programme from another thread on this forum.

http://b5.net/sym1/calc.pi.bin.6000-610e.ptape

# store * calc.pi 6000 10e

that cp fix was not easy. taken all night. If you downloaded the previous version I pointed you to don't use it. It was corrupting directories, very nasty. I think it's safe now. No sign of failure here.

Another point I thought of, when you are making your filesystem you MUST make a user area 1 as well as user area 0 , or it will hang or do something horrible when it searched for an unrecognised command so always do a mkdir 1 0 0 as well as the mkdir 0 0 0 when you make an new disk.

here is an expedited release of the symforth package. I have fixed the binary to use the latest kernel , but I have to update the making of the FORTH block files with the new capabilities of symbiosys. Almost certain if you followed the instructions within you would get it fully working But here it is anyhow, it will run if you just upload the paper tape of the binary, just wont have files.

http://b5.net/sym1/symforth

Full source code, example screens, python script that uploads the forth screens on the House Harris system and the papertape of the executable binary.

But I was thinking, while looking at the uploading script, how it wouldn't work for you if you didn't have the same tcp/serial setup as here, at House Harris. So I wondered if you had a way to upload paper tapes to your sym ?

Im experimenting with papertape uploads as we speak. Theoretically it should be possible via the USB.

A lot will depend on the comms package being able to upload text files.

you should be able to do it, I use ser2net which hooks the serial port you define to a network socket. So then I just telnet into that from my xterm. but yes some serial coms programme should well do it. You'll find you get errors, you'll have to try different baud rates, think 4800 works best.

here is an expedited release of the micro-chess package. I havn't remade this and I think the ptape is the last version that I am running on my development sym, where it works. no OS interaction so no porting was needed. So it's sort of untested.

http://b5.net/sym1/uchess

Great work on Forth and Chess. I havent tried them yet but will look forward to playing with them once I get the Papertape commands working via USB.

Can you refresh my memory after some 30 years... at what baud rate did the Syms papertape commands work at? I was thinking it occured at the synced terminal Baud rate, after pressing the Q button, post rest.

I can execute the SP command and save to the PC, via my expansion boards USB interface. However, executing the LP command is a different story.

When trying a couple of comms utilities, as soon as I try to upload or paste a previously saved papertape file, I get gibberish, akin to the incorrect BAUD rate being selected.

Needless to say, the SYM just locks up, requiring a reset.

It definitely happens at the speed the sym synced at , and I'm suspecting that might now be locked in by your usb modification to be flat out 9600 baud, and that probably will loose dreadfully on the upload due to the fundamental serial problem with the sym.

Yes I have ser2net to use 4800 N8 1 for serial and that would be optimised for papertape uploads.

what we need is an xmodem utility for the sym.

I wonder if setting the sym to noecho would help, sounds like something I should have tried in the past, but I cant remember if it helped. The sym shouldn't lock even if it does end up with a load of bad ptape data but it might. try entering ;00 when your transfer is finished and see if the sym comes back.

After a bit of experimenting, I can can successfully Load Papertape through the USB interface.

The trick is to use a comms package that allows for the insertion of transmit delays between characters. In my case, I have used the comms utility "Tera term". A few mS between characters was enough to load files at 4800 baud.

I see yes that would do it. So now we can exchange software in papertape format, this is great. Anything could happen now.

Here is an expedited release of EhBASIC ported to Symbiosys done some time ago by cjb it is an older version but it seems to be fully operational.

http://b5.net/sym1/ehbasic

Upload the ptape and make the executaebale with this command

# store * ehbasic 600 2860

when in EhBASIC return to symbiosys command prompts with the command

CALL $9003

it has no OS interactions so it would also run on any SYM-1 without symbiosys as long as it has a full 32k of ram in the lower bank.

I'll get a port of the latest EhBASIC together for you in a short time, might even get enthusiastic and put file load and save happening too.

So, what do you reckon. SYM-1 now with disk operating system, forth and basic? I would have liked to have had this back in 1978.(Actually I'm pretty happy about having it now)