Next step is the loader program. It will be a Z80 program, running on Isetta, that uses the console char I/O, so now it is controlled from the RPi console but in the future it can be controlled from PS/2 and VGA.
This loader program will be in the microcode ROMs, and some microcode will download the loader into the RAM soon after reset, and then start the Z80 loader.

What must the loader do ?
 - download program files from RPi into the Isetta memory, through the 'keyboard interface'
 - start a program
 - inspect memory and change bytes in memory
 - read a file from serial flash (to automatically start software in the future)

Need an assembler !

I found a nice online Z80 assembler:  https://asm80.com
Written by Martin Maly, Prague: https://hackaday.io/adent

It can also assemble for the 6502, that can also be useful in my project.

The assembler generates Intel format binary (.HEX), like this:  (spaces added)
: 10 E000 00 31FEFFC325E04FD3317928FAC9DB3128 2F
: 10 E010 00 FCC97EB7C8CD06E02318F7CD0DE077FE 2A
.....
: 10 E0E0 00 20202020202020202F72756E20617420 97
: 10 E0F0 00 68686868000D4973657474612070726F 98
: 0E E100 00 6772616D206C6F61646572002A00     A9
: 00 0000 01 FF

So the structure is: <:><nr-of-bytes><address><record-type><byte-sequence><checksum>
See: https://en.wikipedia.org/wiki/Intel_HEX

The Javascript microcode generator has now the ability to read this intel hex format, in order to include the loader/monitor in the microcode.
Another change to the Javascript simulator was giving it char I/O according to new KB, TX standard.

Now came File transfer from RPi to Isetta, to load the Isetta memory with a Intel Hex file. In the Isetta loader you have to type a "Load File from Host" command, "F" followed by filename. Isetta then sends %Dfilename%  (D is the command: download). So '%' is used to introduce the file name and start the download. For just sending a plain '%' to be displayed, it must be doubled to "%%".

The data has to travel over the link to Isetta, and that is not very fast. So I did a simple change, replacing every two hex digits by a single byte. In this new format, it uses '=' instead of ':' at the beginning of a line.

RPi will now send the file.  Since the values 00 and FF can not be transported over the link, they are escaped with '['. And because values 00 and FF can occur quite often in machine language, all bytes are first XOR'ed with 0x40, so:
Sending from RPi:
  - xor with 0x40
  - if 00 replace by <[><A>, if FF replace by <[><B>, if [ replace by <[><[>
  (send it)
Receiving at Isetta:
  - if [, get another byte, if A then -> 00, if B then -> FF, if [ then -> [ 
  - xor with 0x40
This transformation does not apply to the '=' at the start of the line. and to the 0x0D at the end.

The record type, 0 for a normal record and 1 for the end, has many unused values, so that can later on indicate if the bytes must be loaded into another memory bank. TBD. 
And the recordtype could be used to store target cpu 6502/z80/... (but it is more practical to define that every program is a Z80 program. A program for 6502 should simply start with an instruction that switches to 6502). Recordtype 0x99 indicates 'file not found'.

During transfer, Isetta transmits readable progress messages on the console: at every 128 transferred bytes it displays the current address. It can also terminate the transfer with a special %X sequence (in case of error).

So, now it is possible to assemble Z80 programs online, send the binary to Isetta, and execute it there !