Copy program to eprom and run, what form?

[beginner_max]

If I want to store a program for e.g. a Z80 processor on a Sram or
Eprom that is ordered from several files, e.g. .bin files.
files.
If I want to run them directly on the Z80, do I have to convert the
probably convert them to asm before?
And then? is it then only one file?
And if not, how do you convert it to a "file"?
Or do I have to convert it like a disk image into a .DSK format
which would be only a file and then transfer this content to the eprom?
to the Eprom?

Translated with www.DeepL.com/Translator (free version)

[james_s]

I'm confused, what exactly is it that you're wanting to do?

Typically a .bin file will be intended to write to an eprom, one file per eprom. Sometimes you need multiple files because the total amount of space required is larger than can fit in a single eprom, at least at the time the device was designed. It's possible to concatenate multiple .bin files into a single file for a larger chip.

In the simplest form you would write a program in assembly, then assemble it and the result would be a .bin or .hex file ready to be written to an EPROM and then the microprocessor will execute it from there.

[pcprogrammer]

Yes this is something that does not make much sense. Either deepl is garbage or beginner_max has no idea what he is doing.

In old style microprocessor setups you write a program specific for being written into an eprom and for this you need an eprom programmer, This programmer can often load the data from different file formats like binary or intel hex, etc.

And yes often assembler was used, but C compilers have been available for these old microprocessors for a long time, so there is the option of a higher level language.

For loading a program to SRAM on such a system you need some sort of an operating system on the target to be able to do that. Without power an SRAM looses its data. The older systems from the eighties used mostly DRAM by the way.

So @beginner_max please be more specific when asking a question, and if English is a problem for you post both the original text and the translated text. Maybe someone can grasp the intent from it then.

[SL4P]

And don’t forget… images for these older processors were usually linked for a specific address in memory.

[eutectique]

And don’t forget… images for these older processors were usually linked for a specific address in memory.

Since then, not much has changed.

[james_s]

The only thing that has changed is that small embedded systems typically use microcontrollers instead of microprocessors. The ROM, RAM, IO and peripherals are mostly integrated so the addressing will always be the same. In the old days the designer had complete freedom to determine the addressing of all the peripherals.

[AndyBeez]

The answer depends what the platform is. $10 jelly bean embedded systems are far too diverse for one jelly bean answer. Is it a simple 8 bit processor running a blink program in 10 bytes of assembler code or, a whole system on chip with an embedded Linux Kernel?

[james_s]

Well the OP did say a Z80, so probably not anything involving a Linux kernel.

[Chat GPT (2)]

If you have a program for a Z80 processor that is stored in several .bin files, you can combine them into a single binary file using a program called a linker. A linker takes the individual binary files and combines them into a single file that can be loaded directly onto the Z80 processor.

You don't need to convert the binary files to assembly language before linking them, as the linker works directly with binary files. However, you may need to provide a linker script that specifies the memory layout of your program and how the different binary files should be combined.

Once you have a single binary file, you can load it onto an SRAM or EPROM chip using a programmer. The programmer will typically have software that allows you to select the file you want to load and then transfer it to the chip.

If you want to use a disk image format like .DSK, you would need to write a program that reads the disk image and loads the contents into memory on the Z80. This could be more complex than simply loading a single binary file onto the processor, but it might be necessary if your program requires access to files on a disk.

[macboy]

EPROM contains machine code not assembly code. Assembly is the (sort of) human readable form. Machine code is instructions in raw binary form. A program called an assembler can assemble the assembly code into machine code. A disassembler can do the opposite, with caveats (variable names and other labels are lost).

On the development computer, the contents of the EPROM are likely stored as a bin file, which is raw binary data, essentially a byte stream, or some text based format like Intel Hex or Motorola S-records (for Z80, likely Hex). The text based formats are just for convenience, the EPROM will be programmed with the data specified within the file, not the actual raw file data per se.

When a CPU comes out of reset, it loads the first instruction from a specific address (called the reset vector). So the hardware needs to be designed so that some valid data is given to the CPU when it accesses  that address. Typically this means that a ROM, EPROM, FLASH, etc. is permanently set up at that address.  Some CPU like Motorola 68000 will load from address 0 at boot. By contrast, the (32 bit) PowerPC loads from address 0xFFF00100, which is 256 bytes higher than 1 megabyte below the top of memory. Anyway, the CPU executes instructions starting at that address. Often one of the first (or actually the first) instruction is a branch, which causes the CPU to load the next instruction from a very different address. And the CPU continues to just do what it always does: executes instructions one after the other, sometimes branching to some different instruction based on some condition. The role of the code at the rest vector is to bootstrap the system; it needs to configure enough hardware (RAM, storage device, maybe a serial console) so that the next chunk of code (bigger and more complex, maybe a kernel)  can be loaded and executed. But a purely embedded system often has no kernel and no bigger more complex storage devices (disk, SD card, etc) to worry about, and all code lives in, and is executed directly from, that same little ROM/EPROM.

If you want to know more, find a good book on microcomputer architecture.