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