1 The Am29F010-90PC product has been used to test the software and hardware
2 design described here.
3
4 Using the Software
5 ==================
6
7 First of all, to use the Arduino-based programming solution, the Arduino needs
8 to have a program transferred to it. The program is compiled using the
9 Makefile provided, using the simple command...
10
11 make
12
13 To upload the program, the "upload" target is used as follows:
14
15 make upload
16
17 It is likely that this will fail unless appropriate permissions are available
18 on the device through which the Arduino is accessed on the host machine. Thus,
19 a privileged invocation is likely to be necessary:
20
21 sudo make upload
22
23 Testing the Program
24 -------------------
25
26 With the program uploaded, it should now be possible to communicate with the
27 Arduino. Unless the programming circuit has been constructed, however, there
28 will not be any effect of communicating with the Arduino, other than to check
29 that the program is operational. Running the upload.py script as follows will
30 permit such a test:
31
32 ./upload.py -i
33
34 Again, it is likely that this will need to be run in a privileged fashion as
35 follows:
36
37 sudo ./upload.py -i
38
39 The script should act as a terminal, showing a ">" prompt that can accept
40 various commands. Merely getting the prompt should be enough of an indication
41 that the program is functioning on the device.
42
43 Issuing read commands permits the testing of addresses in the device:
44
45 location sector
46 R0000 0x0000 0 (the first location in the device)
47 R00000 0x0000 0 (all 17 address bits indicated)
48 R7fff 0x7fff 1 (the final location in sector 1)
49 R07fff 0x7fff 1 (all 17 address bits indicated)
50 R10000 0x10000 4 (the first location in sector 4)
51 R1ffff 0x1ffff 7 (the final location in the device)
52
53 Uploading and Testing Images
54 ----------------------------
55
56 Once the programming circuit has been constructed (see "Arduino Interfacing"
57 below), the upload.py script can be used to upload data to the Am29F010
58 device. For example:
59
60 sudo ./upload.py jungle.rom
61
62 This will take jungle.rom and write it to the first sector of the Am29F010. To
63 verify the operation, the following command can be used:
64
65 sudo ./upload.py -v jungle.rom
66
67 To write to other sectors, an option can be specified. For example:
68
69 sudo ./upload.py -s 1 junglecode.rom
70
71 Again, the operation can be verified as follows:
72
73 sudo ./upload.py -s 1 -v junglecode.rom
74
75 Note that the -s option must appear first.
76
77 The upload.py script can accept multiple files and will write each of them to
78 consecutive sectors. However, it can be more prudent to write files
79 individually, especially if the circuit is behaving in a less than completely
80 reliable fashion.
81
82 A Note on Sectors
83 -----------------
84
85 Each sector is 16 kilobytes long, which corresponds to a 14-bit address range
86 (0x0000 to 0x3FFF). The Arduino interface described below supports 17-bit
87 addressing (A0...A16), permitting access to eight sectors (at 0x0000, 0x4000,
88 0x8000, 0xC000, 0x10000, 0x14000, 0x18000 and 0x1C000). The simple mapping from
89 a ROM cartridge to the device leaves A16 grounded and thus unable to access the
90 upper four sectors in the device. However, A16 could be connected to VCC to
91 access the upper four sectors.
92
93 Device Compatibility
94 ====================
95
96 For use with an Acorn Electron ROM cartridge or other board providing a ROM
97 socket, the compatibility of the Am29F010 needs to be assessed in the context
98 of the ROM sockets likely to be provided.
99
100 Original ROM Pinout Am29F010 Pinout
101 ------------------- ---------------
102
103 1 \/ 32 VCC
104 A16 2 31 WE#
105 1 \/ 28 VCC A15 3 30
106 A12 2 27 A14 A12 4 29 A14
107 A7 3 26 A13 A7 5 28 A13
108 A6 4 25 A8 A6 6 27 A8
109 A5 5 24 A9 A5 7 26 A9
110 A4 6 23 A11 A4 8 25 A11
111 A3 7 22 OE# A3 9 24 OE#
112 A2 8 21 A10 A2 10 23 A10
113 A1 9 20 CS# A1 11 22 CE#
114 A0 10 19 D7 A0 12 21 DQ7
115 D0 11 18 D6 DQ0 13 20 DQ6
116 D1 12 17 D5 DQ1 14 19 DQ5
117 D2 13 16 D4 DQ2 15 18 DQ4
118 GND 14 15 D3 GND/VSS 16 17 DQ3
119
120 Superimposing the Am29F010 onto a ROM socket would provide compatibility for
121 all pins from A12 to GND/VSS and from A14 to D3/DQ3.
122
123 Pin 1 in a ROM socket would correspond to A15 but is not necessarily
124 connected, nor, perhaps, is A14 since only 14 bits are required to address 16
125 kilobytes, although there may be 32 kilobyte sockets connecting A14 and using
126 15 bits to address 32K. A16 and A15 would probably be connected to ground to
127 ensure correct operation, but could also be wired to a selection mechanism so
128 that the entire contents of the flash memory might be exposed.
129
130 Pin 28 is a ROM socket would provide power, but the corresponding pin 30 on an
131 Am29F010 is not connected. Thus pin 30 would need routing to pin 32 for the
132 flash device socket.
133
134 Pin 31 for the Am29F010 would need to be asserted. Thus pin 30 might also be
135 routed to pin 31, so that the device would remain read-only at all times.
136
137 Dual ROM Adapter Usage
138 ======================
139
140 A single Am29F010 device could be wired to two ROM sockets in order to provide
141 data to both. The above wiring guide would be employed, with connections from
142 both sockets being connected to the Am29F010, but additional logic would be
143 required for the CS# signals originating from the sockets in order to expose
144 the appropriate region of flash memory. ROM #1 would be served by a "lower"
145 16K region; ROM #2 would be served by an "upper" 16K region; A14 would be used
146 to switch between these regions.
147
148 When ROM #1's CS# signal is low, an attempt to read from ROM #1 would be
149 occurring, and thus A14 would be held low. And when ROM #2's CS# signal is
150 low, an attempt to read from ROM #2 would be occurring, and thus A14 would be
151 held high.
152
153 Meanwhile, the CS# signal for the two ROM sockets would need to be combined to
154 produce a resultant CE# signal for the Am29F010.
155
156 ROM #1 CS# ROM #2 CS# Am29F010 A14 Am29F010 CE#
157 ---------- ---------- ------------ ------------
158 0 0 Not defined Not defined
159 0 1 0 0
160 1 0 1 0
161 1 1 Not defined 1
162
163 It might therefore be possible to connect A14 to ROM #1's CS# signal. And the
164 resultant CE# signal could be the product of an AND gate:
165
166 Am29F010 CE# = ROM #1 CS# AND ROM #2 CS#
167
168 Wiring Details
169 --------------
170
171 ROM #1 ROM #2 74HC08 Am29F010
172 ------ ------ ------ --------
173 CS# 1A A14
174 CS# 1B
175 1Y CE#
176 OE# OE#
177
178 ROM (Common) 74HC08 Am29F010
179 ------------ ------ --------
180 VCC VCC
181 GND GND
182 VCC VCC
183 VCC WE#
184 D0 DQ0
185 D1 DQ1
186 D2 DQ2
187 D3 DQ3
188 D4 DQ4
189 D5 DQ5
190 D6 DQ6
191 D7 DQ7
192 A0 A0
193 A1 A1
194 A2 A2
195 A3 A3
196 A4 A4
197 A5 A5
198 A6 A6
199 A7 A7
200 A8 A8
201 A9 A9
202 A10 A10
203 A11 A11
204 A12 A12
205 A13 A13
206 GND A15
207 GND A16
208 GND GND
209
210 Note that A15 and A16 are left grounded, effectively exposing only the first
211 two sectors of the device. By connecting either or both of these to VCC, other
212 pairs of sectors can be manually selected. A mechanism could also be devised
213 to allow selection using logic, but this is not explored here.
214
215 Arduino Interfacing
216 ===================
217
218 Arduino can employ at most 14 digital pins (plus 5 switchable analogue pins),
219 whereas the Am29F010B requires 17 address pins, 8 data pins, plus 3 control
220 pins to be utilised.
221
222 One solution is to map the 3 control pins directly to the Arduino, then to
223 channel address and data via 8 common pins to latches, and then employ two
224 remaining pins to control the latches. When neither latch is selected, the
225 data pins will be used to read or write data from the flash memory.
226
227 In this scheme, A16 must be directly controlled by an additional pin, separate
228 from the latch-based mechanism. As a result, only 14 pins are needed on the
229 Arduino.
230
231 74HC273 Pinout
232 --------------
233
234 MR# 1 \/ 20 VCC
235 Q0 2 19 Q7
236 D0 3 18 D7
237 D1 4 17 D6
238 Q1 5 16 Q6
239 Q2 6 15 Q5
240 D2 7 14 D5
241 D3 8 13 D4
242 Q3 9 12 Q4
243 GND 10 11 CP
244
245 Arduino 74HC273 #1 74HC273 #2 Am29F010
246 ------- ---------- ---------- --------
247 A5 CE#
248 A4 OE#
249 A3 WE#
250 2 CP
251 3 CP
252 4 D3 D3 DQ3
253 5 D2 D2 DQ2
254 6 D1 D1 DQ1
255 7 D0 D0 DQ0
256 8 D4 D4 DQ4
257 9 D5 D5 DQ5
258 10 D6 D6 DQ6
259 11 D7 D7 DQ7
260 Q0 A0
261 Q1 A1
262 Q2 A2
263 Q3 A3
264 Q4 A4
265 Q5 A5
266 Q6 A6
267 Q7 A7
268 Q0 A8
269 Q1 A9
270 Q2 A10
271 Q3 A11
272 Q4 A12
273 Q5 A13
274 Q6 A14
275 Q7 A15
276 A2 A16
277 5V MR# MR#
278 5V VCC VCC VCC
279 GND GND GND VSS
280
281 Set Address
282 -----------
283
284 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
285 74HC273 #1 D[7...0] = A[7...0]
286 74HC273 #1 CP = 0; 74HC273 #2 CP = 1
287 74HC273 #2 D[7...0] = A[15...8]
288 Am29F010 A16 = A[16]
289
290 Write Data
291 ----------
292
293 Configure pins as D[7...0]
294 WE# = 0
295 74HC273 #1 CP = 0; 74HC273 #2 CP = 0
296 74HC273 #3 D[7...0] = D[7...0]
297 WE# = 1
298
299 Read Data
300 ---------
301
302 Configure pins as Q[7...0]
303 OE# = 0
304 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
305 Q[7...0] = 74HC273 #0 Q[7...0]
306 OE# = 1
307
308 Pins
309 ====
310
311 A0-A16 17-bit addressing
312 DQ0-DQ7 8-bit data transfer
313 CE# chip enable
314 OE# output enable
315 WE# write enable
316 VCC 5V
317 VSS ground
318 NC (not connected)
319
320 Low-Level Operations
321 ====================
322
323 CE# high standby
324 CE# low read, write or output disable
325
326 OE# high, WE# high output disable
327 OE# low, WE# high read
328 OE# high, WE# low write
329
330 Thus, for reading and writing:
331
332 OE# = not WE#
333
334 Timing
335 ======
336
337 According to the datasheet, addresses are latched on the falling edge of the
338 latest of WE# and CE#, data is latched on the rising edge of the latest of WE#
339 and CE#.
340
341 Strategy:
342
343 1. Start with CE#, OE#, WE# high (standby, output disable)
344 2. Bring CE# low (output disable)
345 3. Set addresses
346 4. Bring WE# or OE# low for operation (write or read)
347 5. Read or write data
348 6. Bring WE# or OE# high (output disable)
349
350 Operation Modes
351 ===============
352
353 By default, the device is in read mode, meaning that merely bringing OE# low
354 will produce data for the asserted address.
355
356 To issue commands to change the mode involves write operations with specific
357 address and data arguments.
358
359 Sectors
360 =======
361
362 A[16...14] selects each 16KB sector and is referred to as the sector address
363 or SA in the documentation.
364
365 Commands
366 ========
367
368 Reset (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$F0)
369
370 Autoselect (manufacturer) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
371 (A=$X00; read)
372 => D=$01
373
374 Autoselect (device) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
375 (A=$X01; read)
376 => D=$20
377
378 Simple reset (A=$XXXX; D=$F0)
379
380 Sector erase (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$80);
381 (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=SA; D=$30)
382
383 Program (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$A0);
384 (A=PA; D=PD)
385
386 Progress
387 --------
388
389 Programming and erasure commands employ data pins as follows:
390
391 Programming Erasure
392 DQ7 On completion: DQ7-out On completion: 1
393 DQ6 During: toggling value During: toggling value
394 DQ5 On failure: 1 On failure: 1
395 DQ3 Sector erase begun: 1
396
397 A read operation is required to obtain these outputs, typically with the same
398 address used to initiate each operation.
