Eprom Programming (Amstrad Computer User)
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

Phil Craven investigates

In the last issue we had a look at each of the eprom programmers made for the CPC and, now that we've had a few weeks to rush out and buy one, we are all no doubt poised with Arnold powered up, our programmers plugged in and our minds pregnant with anticipation (huh?) at filling our very first eprom with all our carefully prepared pieces of code. But just a minute. You can't go bunging loads of machine code into eproms any old how and expect them to work. Arnold has an excellent system for using extra roms, but that isn't it. On power up and resets, one of the first things that the computer does is look for external roms and it initialises any that are found. For this to happen certain, data must be in certain places within the eprom. It's all very simple but it needs to be accurate, so here we have a quick tutorial on what to put in, and where.

First, a short word for those readers who are not familiar with Arnold's expansion roms system. "Hi." OK then, we begin. Most external roms are accessed, when needed, via a bar command (shift @) from the keyboard or program whilst at other times they are dormant. There are called Background roms and are recognised by the computer as their first byte is always &01. Other types are Foreground (&00), which replace Basic and take complete control of the computer, and Extension (&02), which are accessed from within a Foreground ROM. The most useful and therefore the most common type is the Background ROM.


If you have a disc drive with its rom, then you already have one such background type. Let us assume that we are designing a ROM which needs its own private chunk of RAM as a workspace, announces its presence on screen and also needs to react to a number of bar commands.

Every time the computer is powered up or reset the operating system will enter our ROM at address &C006. This address is set by the system and it must contain a jump instruction. In fact it is the first entry in the jump-block, which we will examine later. The address to jump to must be in &C007/8 and it must be the start address of our rom's initialising routine, e.g. &C3 &D000 = jump to &D000, although any suitable address within the ROM would do. A return instruction at the end of the routine would hand control back to the computer. At this point the Z80 registers, DE and HL, contain the addresses of the lowest and highest bytes of free RAM respectively. To reserve some for our own use we must alter one or both of them before returning control to the computer. When we hand back, these registeres must contain the new addresses of free RAM.


Now for the ego trip. We'll announce our rom's presence on the screen. Any machine code programmer worth his salt could go to town with the display but the more you put on the screen, the less ROM you have left for actual programs. A one liner such as 'Auntie John - a rumour in his own time' is probably best. That done, a return instruction will hand back to the computer, having made sure that DE and HL are correct for it to complete its own initialising. We have done only two operations in our routine, but you can do a great deal more at this stage as installing firmware jumpblock intercepts, installing your own ran routines, etc.


You will notice that I didn't mention the bar commands in the initialising stage. Preparations in the RAM may need to be made for some of them at that time but mostly they will be either stand alone routines or they will modify the RAM as theu are called. Having found our rom, the computer has placed it on the list of possible bar command receivers and each time such a command is issued, from keyboard or program, our ROM will be included in the search for it.

The pathway to each bar command's ROM routine is very exact and must be implemented precisely. Somewhere in the ROM must be a table of all its bar command names and &C004/5 must contain the start address of this table. Also a jumpblock must be included which starts at &C006 with the initialising routine jump. These two relate to each other in that the first name table applies to the first jump in the jumpblock, the 2nd to the 2nd, and so on. Up to 16
characters can be used for each command name but bit 7 of the last character of each name must be set to 1 (add 128 decimal). They are stored in the table without gaps. The end of the table is marked by a nul (0) in the byte following the last name. Obviously a name cannot have 0 as its first character. The bar command |PROG would be stored in the table as:

G&a7199 (71+128)

The bar (shift @) is not stored with the name and only ASCII characters from 0 to 127 can be used. This raises an interesting point. We have seen that, since the initialising routine must have a name in the name table associated with its jump in the jumpblock, it would be accessible from the keyboard. This would usually be undesirable, so the inclusion of a space (ascii 32) in the name, which will not be accepted by Basic, will prevent any accidental re-initialisation.


The jumpblock is a series of jump instructions and addresses, one for each command name, which must start at &C006 with the initialisation jump. When a bar command is issued, the system searches the command name table for a match. If a match is found at, say the 4th entry in the table, then the system will go to the 4th entry in the jumpblock and jump to the address it finds there. No terminating byte is needed.


The second, third and fourth bytes of the ROM (&C001/1/2) are reserved for your own version numbers. If they contained 1, 2 and 3, for example, then our previous one line announcement would read 'Auntie John - a rumour in his own time 1.23' which, coincidentally, is a pretty accurate estimate of his mental age, in years.

That completes the parts of the ROM which the system insists must be exact. Now you're on your own. What programs you put in, and where, is entirely up to you. You could even store a Basic program in an eprom along with a routine to download it when called by a bar command.


A return instruction at the end of any ROM routine will get you back to the place from where you entered it. i.e. the keyboard or a Basic program.
Rom 'slots'or 'numbers'are taken care of by the romboard. You don't need to include anything in your roms for this purpose.

The computer will search all possible bar command receivers for a name. These are all roms and RSXs and the first name it finds will be used, so take care not to duplicate any.

To erase an eprom without an eraser, find yourself a friendly hairdresser with an ultra violet sterilising unit. Half and hour in one of those will clear its memory.

I keep repeating this but it is worthwhile. Don't handle chips by the pins. Some of them can be killed off by static so err on the side of caution and touch no pins.

ACU #8905

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 119 millisecondes et consultée 1248 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.