• Please review our updated Terms and Rules here

How to exchange data with a very simple computer?

Ruud

Ruud

Veteran Member
Joined
Nov 30, 2009
Messages
1,861
Location
Heerlen, NL
Just for fun I created a very simple 8088 computer. An 8088, ROM, RAM, UART and some glue-logic. I want to exchange data/programs with an external storage/computer, but how? While writing this, a thought popped up: about a zillion years ago I exchanged data I exchanged data between an Elektor EC65 (6502 machine) and a PC using Kermit. But that would mean I would need to write a Kermit compatible program for my new computer, but how? Another solution: write both parts. Disadvantage: a lot more work and probably incompatible with everything else.
Advice, ideas, etc. are welcome!
 
kermit requires writing a basic communications client. Are you able to dump raw serial data to memory from say, paper tape?
 
Probably you could take a DOS version of such a program and port it - change the DOS and BIOS calls for whatever your computer's got...
 
I would start with XMODEM. When I was building my Z280 board, before it had it's own keyboard and monitor, I accessed it from a PC terminal program. I made a simple XMODEM receiver for it (didn't even bother with the code to restart after errors), and I could send programs right within the terminal. The only tricky part is that I had to have a time delay on the Z280 program to begin the handshake, allowing some seconds for me to enter the menu and choose a file at the other end.
 
Do you have a monitor that can perform functions like read/write bytes in memory? Since you already have a UART, so you could write a script on a PC to automate sending the command and each byte, one by one.. Slow but should work for small binaries..

EDIT: Oh I see this is basically the same idea as Kelly mention above
 
Last edited:
On page two of this article is the schematic for a very simple microcomputer, the Electronics Australia Mini-Scamp from 1977:
https://www.chookfest.net/computers/files/MiniScamp.pdf

It shows how the input data bits are written directly to memory through a bunch of switches in series with NAND gates. A Deposit switch goes through a couple of flipflops to pulse the 2112 memory chip selects, write, and simultaneously the NAND gates of the switch register. It goes without saying that the output is just some LEDs. Perhaps the same idea could be used for your simple computer?
 
Last edited:
Ruud said:
I want to exchange data/programs with an external storage/computer, but how?
Click to expand...
First, you need to have a client running on that thing - which runs from ROM at power-up. It is that client which decides how you communicate with the computer. Can be a simple hex file loader, an XMODEM receiver, a Kermit implementation, or even a full monitor program (which may or may not include an assembler/disassembler). The sky and your ROM size are the limit, basically.

As far as hardware goes, you have a UART.

Ruud said:
But that would mean I would need to write a Kermit compatible program for my new computer, but how?
Click to expand...
Yes, that would be one option. Although I would recommend starting with something simpler, for example Intel HEX or XMODEM.

For the practicalities, I would recommend doing the bring-up step by step:
  • Find yourself a suitable emulator. Many eons ago, I toyed with emu8086. It does not emulate a full PC, but is aimed at students, comes with some IDE, and should be a good fit for what you are trying to do. Testing your ROMs in emu8086 should be your main focus until you can generate runnable ROMs. Trying to debug code which does not even run is a huge waste of time.
  • Then you use NASM (or some other assembler) to write some ROM code which configures your UART and echos the input back. No interrupts. At this stage, I normally add one to the received bytes, just to make sure that my code actually runs. A plain echo can be generated by shorting Rx/Tx or the terminal program, but a +1 won't.
  • If you have functional UART communication, you can write a simple loader for Intel HEX or XMODEM. Write a message to the UART, read the data until it is finished, then just run it. This does not require a lot of code, so you can write it in assembly, but see below.
  • At that point, you can write more complex code, test and debug it, and turn it into better ROM code when it works.
If you are more comfortable with C, I have written an XMODEM receiver [here]. As it is, it receives a floppy image via XMODEM and writes it to a floppy. It is written for bcc (Bruce's C compiler), which is a simple C compiler provided in Debian/Ubuntu, but also shipped with FreeDOS.

What makes it useful to you is that it contains its own startup code and does not use any library, not even the C library. Execution starts in crt0.s, xmodem.c is fully self-contained, and uart.c is where your UART code would go.
 
I built a simple 8088 SBC a few years back. I wrote a simple monitor program (in PROM).
My ROM includes Intel hex load and save. Most PC terminal programs include serial capture and send.
Intel hex code is only a few hundred bytes and not difficult to write.
It works well enough to load and run code on the SBC.
 
jlang said:
Intel hex code is only a few hundred bytes and not difficult to write.
It works well enough to load and run code on the SBC.
Click to expand...
And as for serial communications, the first step is to get handshaking to work, ideally hardware, but XON/XOFF works for HEX dumps (just not so well for binaries).

The primary goal of serial comm software is error correction over noisy lines. The faster the baud rate, the more chance of noise. When the computer is 2 feet away from your other computer, noise is less of an issue. 1200 baud is 120 characters per second. Sending over a 4K hex data set would take 30s.

That's not bad! And you likely can handle higher baud rate (9600, say) without worrying about a noisy serial path. You're not moving megabytes of information.

A simple CRC can be used to verify what you get without having to get XMODEM or Kermit or anything else running, especially not right away.

Finally, on the KERMIT site, there's a simple Kermit client written in BASIC. It demonstrates a very simple subset of the Kermit protocol, and you could likely use that readily, even in assembly, and then use a Kermit host to move data.

But, truely, your probably don't need anything. Open the serial port, 'cat' a hex dump, and it'll likely just work, IF you have handshaking working.
 
Assuming you are communicating serially for only few feet apart where noises are not an issue, you can just send the raw binary program, no error checking nor complicated handshakes; a small serial bootstrap to initialize the serial port then copy incoming serial binary data into memory and jump to starting address once the expected number of bytes are received. Such bootstrap serial loader can be tiny, 32-64 bytes. In many cases I don’t bother with ROM, but fit the small bootstrap in the logic matrix of programmable logic like CPLD or 22V10.
Bill
 
The big issue with raw binary is detecting the end of transmission and the entry point. Although there is no harm in hard-coding the program size and entry, and using it to load a more capable loader program.
 
The transporter had a very elegant bootstrap design.

Assuming a single hardware UART serial port, the initial loader could support PEEK, POKE and BOOTSTRAP commands.

Peek specifies an address and returns the data.

Poke specifies an address and data.

Boot specifies a number of bytes to load at a base RAM address followed by the bytes themselves. After loading the bytes into RAM, they are executed.

This is similar to a PDP-11 processor running ODT, and PDP-11 GUI.

Dave
 
Svenska said:
The big issue with raw binary is detecting the end of transmission and the entry point. Although there is no harm in hard-coding the program size and entry, and using it to load a more capable loader program.
Click to expand...
I agree.
I've downloaded S-rec files to upgrade various telecoms cards. The use of hex means with half decent coding of the monitor program you can effectively ignore whether the data comes with a CR, CR+LF or LF line terminations.
The worst case scenario is that the "send text file" function finishes, and the monitor is sat waiting for a CR.
All you do there is either hit return (human), or if automating, send the file then send an additional CR.

Another advantage of some hex formats is that you can specify the loading address for the data - relative or absolute, also allows for "sparse" data where one file can be used to load data into separate areas of memory. This can be exploited to allow the creation of patch files that can be loaded over whatever is currently in RAM.

My personal choice would be to use Motorola S-rec. There's more than one tool to convert binary to S-rec or vice versa. (http://www.s-record.com/ is a good place to start, I use bin2srec and srec2bin).
 
You must log in or register to reply here.
Back
Top