Electron ULA Documentation Updates

[hoglet]

As suggested by Dave H here, this thread is to try to collate documentation about the Electron ULA, with a view to eventually updating the chapter in the Electron Advanced User Guide.

I'll start with a list of the references material I'm aware of:

• The Advanced User Guide for the Acorn Electron - Adrian Dickens and Mark Holmes (Chapter 14)
• The Advanced User Guide for the Acorn Electron - second edition - Adrian Dickens and Mark Holmes (Chapter 14)
• Acorn Electron Service Manual
• Electron Technical Information - Jonathan Harston
• The Acorn Electron ULA - Paul Boddie
• Acorn Electron Technical Documentation - Thomas Harte
• Acorn Cassette Format - BeebWiki

Please let me know if I've missed anything.

Dave

[hoglet]

Attached is an updated Chapter 14 from the EAUG from here:
http://www.8bs.com/othrdnld/manuals/ess ... ickens.zip

14INSIDETH.PDF

(34.65 KiB) Downloaded 143 times

This already has improved diagrams, notable Figure 14.6 (&FE07 bits) has been corrected.

We should probably use this version of the chapter as a starting point.

Errors / omissions I'm aware in this chapter:

• In figure 14.1 the receive data full and transmit data empty interrupts (bits 4 and 5) have been transposed.
• When talking about &FE00 it should be made clear that even when an interrupt is disable, the respective bit can still be set, it's just that it doesn't affect the Master IRQ bit (bit 0), or actually cause an interrupt.
• More detail could be given on each interrupt, including the method to clear it.
• The diagrams and description of &FE04 indicate the data is shifted right to left (i.e. bit 7 is transmitted first). This is wrong. Data is shifted left to right (i.e. bit 0 is shifted first). In practice I believe the implementation of this registers is as a 10 bit shift register, and the high tone detect interrupt fires if all 10 bits are 1.

Dave

[hoglet]

Reserved for something else.

[1024MAK]

I presume your search took you by way of here and that the "updated" one is the version that the linked thread talks about?

Mark

[hoglet]

I presume your search took you by way of here and that the "updated" one is the version that the linked thread talks about?

Mark

Actually I hadn't seen that thread.

I found the various versions here:
http://www.8bs.com/othrdnld/manuals/ess ... tron.shtml

The "Updated" one is attributed to John Simpson (== jms2 ???)

Dave

[paulb]

I found the various versions here:
http://www.8bs.com/othrdnld/manuals/ess ... tron.shtml

The "Updated" one is attributed to John Simpson (== jms2 ???)

Yes, I think that's the one I'm using, although I have one where the chapters are broken out into separate files, and I'm not sure if that one has been revised. In the "updated" one, there's a list of revisions at the end, and I think it uses a different "edition" number too, potentially not corresponding to any officially published edition.

[hoglet]

See also:
viewtopic.php?f=3&t=1869&p=12565#p12565

[ThomasHarte]

Ugh, I almost can't take the pain of that clearly-by-a-teenager document of mine. I'm going to get the red pen out immediately.

[hoglet]

Ugh, I almost can't take the pain of that clearly-by-a-teenager document of mine. I'm going to get the red pen out immediately.

It's been a very valuable reference - I'd love to see it maintained and back on the "live" web.

In the other thread you said:

From memory, from writing ElectrEm, a decade and a half ago:

• a hardware quirk causes the 'receive data' (the real one; this isn't a comment about mislabelling) to be triggered if the tape hardware is put into output mode and appropriate data is sent to look like a stop bit. Joe Blade uses that like a programmable interrupt counter — analogous to those other platforms where you can say "give me an interrupt in 32 lines" — in order to trigger its palette change; possibly Northern Star and Southern Belle do too;

I've been wondering about the code necessary to reproduce this quirk, even if it wasn't used by Joe Blade.

Here's another test program:

Code: Select all

   10  FOR I%=0 TO 2 STEP 2
   20  P%=&2000
   30 [OPT I%
   40  SEI
   50  LDA #&00    \ clear counter
   60  STA &FE06
   70  LDA #&B4    \ set tape output mode
   80  STA &FE07
   90  LDA &FE04   \ clear RXFULL int
  100  LDA #&AA
  110  STA &FE04   \ transmit a character
  120  LDX #&00
  130  .LOOP
  200  LDA &FE00   \ save the int status
  210  STA &2100,X
  220  LDY #100    \ delay for 500us
  230  .DELAY
  240  DEY
  250  BNE DELAY
  260  INX
  270  BNE LOOP
  280  CLI
  290  RTS
  300 ]
  310  NEXT
  320  CALL &2000
  330  FOR I=0 TO 23
  340  PRINT I,~I?&2100 AND &70
  350  NEXT

This code is putting the ULA in tape-output mode, sending a character, and then sampling the interrupt status flags every 500us.

On my real Electron, I get:

Code: Select all

         0         0
         1         0
         2         0
         3         0
         4         0
         5        10
         6        10
         7        10
         8        10
         9        10
        10        10
        11        10
        12        10
        13        10
        14        10
        15        10
        16        30
        17        30
        18        30
        19        30
        20        30
        21        30
        22        30
        23        30
...

You would expect the point at which the Tx interrupt (bit 5) fires to be about 9 bit times (7.5ms) after the byte is written to &FE04. Each row in the above table is ~500us. So row 16 (8ms) is about right.

What's interesting is the point at which the Rx interrupt (bit 4) fires is somewhat random. More specifically:
- it doesn't seem to depend on the character being sent
- it does seem to depend on the tape input (but not 100% consistently)
- sometimes it never fires (especially when the tape input is disconnected)
- sometimes it fires as soon as row 1 (especially when you touch the tape input)

Based on this experiment it seems:
- the Tx interrupt could be used as a fixed 7.5ms timer (117 lines)
- the Rx interrupt is less use, because it's doesn't seem to depend on the data being sent

Does this match your understanding?

Dave

[jms2]

Yes, it was me who produced the unofficial Issue 2 EAUG. I would be only too pleased to produce an Issue 3.

One of the things I tried to do with Issue 2 was retain the existing pagination, and thus avoid needing to redo the index. However I think that maybe this is now unavoidable.

[jms2]

Just noticed that Chris Dewhurst has made a version with fully redrawn diagrams. If he agrees, these ought to go in Issue 3 as well.

[hoglet]

Yes, it was me who produced the unofficial Issue 2 EAUG. I would be only too pleased to produce an Issue 3.

That would be awesome. I was kind of hoping you would volunteer.

Just noticed that Chris Dewhurst has made a version with fully redrawn diagrams. If he agrees, these ought to go in Issue 3 as well.

Agreed.

Dave

[hoglet]

I guess this thread is as good as any for exploring some of the fine details of the Electron ULA operation.

I've been trying to understand the use of the Tape interrupts in Southern Belle, as this is currently not working properly in the ULA reimplementation.

This is ground others (Thomas and Sarah) have trodden in the development of the Electron Emulators.
http://www.stardot.org.uk/forums/viewto ... 6756#p6756

What Southern Belle does is to use interrupts (display and tape) to create a MODE 4 screen with 40x23 characters (instead of 40x32) that occupies &5800-&74BF. It blanks the other 9 lines using palette changing.

In the other thread, Thomas said:

a hardware quirk causes the 'receive data' (the real one; this isn't a comment about mislabelling) to be triggered if the tape hardware is put into output mode and appropriate data is sent to look like a stop bit.

and

I believe Southern Belle to be another good example of the tape interrupts all always being evaluated. It sets the tape to output mode but expects interrupts to be triggered by receive data full.

I've always been a believer in gathering as much data at possible, and trying not to make premature assumptions about how things work.

To this end, I've try to capture all the writes (using ICE T65) to the ULA during a complete frame.

Code: Select all

========                                              ;; 10ms passes

09.099118: Ex Watch hit at DAE7
09.099152: Mem Rd Watch hit at 0EFF reading FE00 = 95 ;; Read Int Status (10010101) 
09.099195: Mem Rd Watch hit at DB55 reading FE00 = 95 ;; RxFull and Display
09.099660: Mem Wr Watch hit at 0EE3 writing FE07 = 24 ;; Set mode to tape output
09.099666: Mem Wr Watch hit at 0EE8 writing FE00 = 1F ;; Enable RxFull interrupt
09.099672: Mem Wr Watch hit at 0EED writing FE08 = FF
09.099676: Mem Wr Watch hit at 0EF0 writing FE09 = FF ;; Blank screen
09.099680: Mem Wr Watch hit at 0EF3 writing FE04 = FF ;; Write to data shift register
09.099722: Mem Wr Watch hit at DBC5 writing FE05 = 10 ;; Clear Display interrupt
09.099901: Ex Watch hit at DAE7
09.099925: Mem Wr Watch hit at 0F12 writing FE04 = 13 ;; Write to data shift register
09.099968: Mem Rd Watch hit at DB55 reading FE00 = 91 ;; Read Int Status (10010001) 
09.100408: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.100422: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.100490: Ex Watch hit at DAE7
09.100514: Mem Wr Watch hit at 0F12 writing FE04 = 12 ;; Write to data shift register
09.100557: Mem Rd Watch hit at DB55 reading FE00 = 91
09.100997: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.101011: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.101079: Ex Watch hit at DAE7
09.101103: Mem Wr Watch hit at 0F12 writing FE04 = 11 ;; Write to data shift register
09.101146: Mem Rd Watch hit at DB55 reading FE00 = 91
09.101586: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.101600: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.101668: Ex Watch hit at DAE7
09.101692: Mem Wr Watch hit at 0F12 writing FE04 = 10 ;; Write to data shift register
09.101735: Mem Rd Watch hit at DB55 reading FE00 = 91
09.102175: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.102189: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.102257: Ex Watch hit at DAE7
09.102281: Mem Wr Watch hit at 0F12 writing FE04 = 0F ;; Write to data shift register
09.102324: Mem Rd Watch hit at DB55 reading FE00 = 91
09.102764: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.102778: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.102846: Ex Watch hit at DAE7
09.102870: Mem Wr Watch hit at 0F12 writing FE04 = 0E ;; Write to data shift register
09.102913: Mem Rd Watch hit at DB55 reading FE00 = 91
09.103353: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.103367: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.103435: Ex Watch hit at DAE7
09.103459: Mem Wr Watch hit at 0F12 writing FE04 = 0D ;; Write to data shift register
09.103502: Mem Rd Watch hit at DB55 reading FE00 = 91
09.103942: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.103956: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.104024: Ex Watch hit at DAE7
09.104048: Mem Wr Watch hit at 0F12 writing FE04 = 0C ;; Write to data shift register
09.104091: Mem Rd Watch hit at DB55 reading FE00 = 91
09.104531: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.104545: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.104613: Ex Watch hit at DAE7
09.104637: Mem Wr Watch hit at 0F12 writing FE04 = 0B ;; Write to data shift register
09.104680: Mem Rd Watch hit at DB55 reading FE00 = 91
09.105120: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.105134: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.105202: Ex Watch hit at DAE7
09.105226: Mem Wr Watch hit at 0F12 writing FE04 = 0A ;; Write to data shift register
09.105269: Mem Rd Watch hit at DB55 reading FE00 = 91
09.105709: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.105723: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.105791: Ex Watch hit at DAE7
09.105815: Mem Wr Watch hit at 0F12 writing FE04 = 09 ;; Write to data shift register
09.105858: Mem Rd Watch hit at DB55 reading FE00 = 91
09.106298: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.106312: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.106380: Ex Watch hit at DAE7
09.106404: Mem Wr Watch hit at 0F12 writing FE04 = 08 ;; Write to data shift register
09.106447: Mem Rd Watch hit at DB55 reading FE00 = 91
09.106887: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.106901: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.106969: Ex Watch hit at DAE7
09.106993: Mem Wr Watch hit at 0F12 writing FE04 = 07 ;; Write to data shift register
09.107036: Mem Rd Watch hit at DB55 reading FE00 = 91
09.107476: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.107490: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.107558: Ex Watch hit at DAE7
09.107582: Mem Wr Watch hit at 0F12 writing FE04 = 06 ;; Write to data shift register
09.107625: Mem Rd Watch hit at DB55 reading FE00 = 91
09.108065: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.108079: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.108147: Ex Watch hit at DAE7
09.108171: Mem Wr Watch hit at 0F12 writing FE04 = 05 ;; Write to data shift register
09.108214: Mem Rd Watch hit at DB55 reading FE00 = 91
09.108654: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.108668: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.108736: Ex Watch hit at DAE7
09.108760: Mem Wr Watch hit at 0F12 writing FE04 = 04 ;; Write to data shift register
09.108803: Mem Rd Watch hit at DB55 reading FE00 = 91
09.109243: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.109257: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.109325: Ex Watch hit at DAE7
09.109349: Mem Wr Watch hit at 0F12 writing FE04 = 03 ;; Write to data shift register
09.109392: Mem Rd Watch hit at DB55 reading FE00 = 91
09.109832: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.109846: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.109914: Ex Watch hit at DAE7
09.109938: Mem Wr Watch hit at 0F12 writing FE04 = 02 ;; Write to data shift register
09.109981: Mem Rd Watch hit at DB55 reading FE00 = 91
09.110421: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.110435: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.110503: Ex Watch hit at DAE7
09.110527: Mem Wr Watch hit at 0F12 writing FE04 = 01 ;; Write to data shift register
09.110540: Mem Wr Watch hit at 0F1B writing FE00 = 0F ;; Disable RxFull interrupt
09.110546: Mem Wr Watch hit at 0F20 writing FE08 = 44 
09.110552: Mem Wr Watch hit at 0F25 writing FE09 = 04 ;; Un-blank display
09.110593: Mem Rd Watch hit at DB55 reading FE00 = 90
09.110997: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.111011: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.111176: Mem Wr Watch hit at ED8C writing FE05 = 08
09.111242: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.111256: Mem Wr Watch hit at E3A5 writing FE05 = 0B
09.112475: Ex Watch hit at DAE7
09.112509: Mem Rd Watch hit at 0EFF reading FE00 = B9
09.112519: Mem Wr Watch hit at 0F08 writing FE07 = 26 ;; Set mode to undefined
09.112557: Mem Rd Watch hit at DB55 reading FE00 = B9
09.112598: Mem Wr Watch hit at DBC5 writing FE05 = 20 ;; Clear RTC interupt
09.112871: Mem Wr Watch hit at ED8C writing FE05 = 08
09.112937: Mem Wr Watch hit at E3AC writing FE05 = 0C
09.112951: Mem Wr Watch hit at E3A5 writing FE05 = 0B

========                                              ;; about 10ms passes

09.122674: Ex Watch hit at DAE7
09.122708: Mem Rd Watch hit at 0EFF reading FE00 = B5 ;; Read Int Status (10110101) 
09.122751: Mem Rd Watch hit at DB55 reading FE00 = B5 ;; TxEmpty and RxFull and Display
09.123216: Mem Wr Watch hit at 0EE3 writing FE07 = 24 ;; Set mode to tape output
09.123222: Mem Wr Watch hit at 0EE8 writing FE00 = 1F
09.123228: Mem Wr Watch hit at 0EED writing FE08 = FF
09.123232: Mem Wr Watch hit at 0EF0 writing FE09 = FF
09.123236: Mem Wr Watch hit at 0EF3 writing FE04 = FF
09.123278: Mem Wr Watch hit at DBC5 writing FE05 = 10 ;; etc etc etc

This did indeed look like it was sending characters and using receive interrupts as a programmable timer.

But then I put the scope on the IRQ pin, and captured this:

It seems that instead of lots of short interrupts (one per character), the RxFull interrupt is asserted for the duration of the period the screen is blanked.

And looking at the trace, maybe that is to be expected, because the RxFull interrupt is never explicitly cleared.

Maybe I'm confused here, but this looks to me like a very expensive and complex way to have written this code.

I *think* based on this, all I need to do to get Southern Belle working is have the RxFull interrupt fire immediately when tape output mode is entered.

Thoughts?

Dave

[hoglet]

II *think* based on this, all I need to do to get Southern Belle working is have the RxFull interrupt fire immediately when tape output mode is entered.

So I did this, and it did mostly work, but the screen was spilt in the wrong place (much lower down).

After a bunch more debugging, the cause of this was identified as the two additional ROMs (MMFS and Jafa) in my system, extending the time the OS takes to service an interrupt.

After disabling these ROMs, Southern Belle is working perfectly.

This does seem quite fragile!

Dave

[ThomasHarte]

This does seem quite fragile!

Dave

To confirm: most of what I "know" is from working backwards from the software available, not forwards from the hardware, as per the timeline of ElectrEm and since: started while at my childhood home, with my childhood Electron, then continued after I started university, no longer with any access to a real machine.

So the implementation I have is completely different from yours and, per your electroscope, clearly wrong. I've got a single ten-bit shift register which is clocked either (i) by the system; or (ii) by the audio; and which triggers received data full when a sequence of ten bits begins with a stop bit and then a start bit, and it's been at least ten bits since the last trigger, and data empty is triggered nine shifts after the register was last loaded.

I shall adjust accordingly.

Also potentially of interest re: when does the display end interrupt fire within a scanline, I've once again transcribed the only piece of software I know that might test that, as below, and decided it's probably after the back porch. But have you taken any measurements to figure that out?

Code: Select all

10 REM Vertical split modes
12 REM By R.Henderson
14 REM (c) Electron User
20 FOR X%=1 TO RND(4)+1+4
30 *FX19
40 NEXT
50 *KEY10 OLD|MRUN|M
60 ?&FE07=164
70 MODE 4
80 VDU 23,1,0;0;0;0;
90 P%=&900
100 [OPT 0
110 LDA #19
120 JSR &FFF4
130 .kkk
150 LDA &71
160 LDY &70
170 STA &FE07
180 .call
190 STA &FE07
200 LDX #4
210 .l DEX
220 BNE l
230 STY &FE07
240 JMP call
250 .dddd SEI
260 RTS
270 ]
280 VDU 19,1,1;0;
290 ?&360=3 : ?&361=3
300 ?&355=5 : ?&34F=16
310 FOR A%=0 TO 30 STEP 2
320 PRINT TAB(3,A%);"Mode 5..."
330 NEXT
340 ?&FE07=164
350 ?&360=0 : ?&361=0
360 ?&355=5 : ?&34F=8
370 B$=" THIS IS MODE NUMBER FOUR"
380 FOR X%=1 TO LEN(B$)
390 PRINT TAB(31,X%);MID$(B$,X%,1);" *";TAB(0,X%);"* ";MID$(B$,X%,1)
400 NEXT
410 ?&70=164 : ?&71=174
420 CALL dddd
430 *FX19
440 CALL &900

[hoglet]

So the implementation I have is completely different from yours and, per your electroscope, clearly wrong. I've got a single ten-bit shift register which is clocked either (i) by the system; or (ii) by the audio; and which triggers received data full when a sequence of ten bits begins with a stop bit and then a start bit, and it's been at least ten bits since the last trigger, and data empty is triggered nine shifts after the register was last loaded.

I think it's premature to discount any particular implementation yet.

It's really hard to figure this out from the outside - many possible designs (including a 10 bit shift register) do seem to fit.

I'm hoping in due course we will either get the original Electron ULA schematics (from Harry Barman), or be able to reverse engineer the ULA from some high res microscope photos.

Also potentially of interest re: when does the display end interrupt fire within a scanline, I've once again transcribed the only piece of software I know that might test that, as below, and decided it's probably after the back porch. But have you taken any measurements to figure that out?

This one might be relevant:
http://www.stardot.org.uk/forums/viewto ... 09#p134109

From the scope picture, it looks like the display end interrupt is co-incident with the start of the HS pulse.

Dave

[jms2]

I've made a start on incorporating the changes into a new "Issue 3" EAUG!

Inevitably this means I'm going to start asking questions about changes that I don't understand. First up is this one...

When talking about &FE00 it should be made clear that even when an interrupt is disabled, the respective bit can still be set, it's just that it doesn't affect the Master IRQ bit (bit 0), or actually cause an interrupt.

I don't follow this. If an interrupt is disabled, it's bit will be zero. If you set the bit to 1 it re-enables the interrupt. Surely it's obvious that re-enabling an interrupt doesn't actually generate that interrupt? Or have I misunderstood?

More detail could be given on each interrupt...

Whilst I could make something up, it'd probably be rubbish! Can you suggest some words here?

...including the method to clear it.

Isn't this covered under &FE05?

[jms2]

and...

Is this what you mean regarding the shift register? Ie, when writing a byte, do the incoming bits drop into the top 8 bits, or the lower 8 bits?

Similarly, for 14.3a (reading from the shift register), do we read from the top 8 bits?

[hoglet]

When talking about &FE00 it should be made clear that even when an interrupt is disabled, the respective bit can still be set, it's just that it doesn't affect the Master IRQ bit (bit 0), or actually cause an interrupt.

I don't follow this. If an interrupt is disabled, it's bit will be zero. If you set the bit to 1 it re-enables the interrupt. Surely it's obvious that re-enabling an
interrupt doesn't actually generate that interrupt? Or have I misunderstood?

It's important to understand that:
- when writing, bits 6-2 of FE00 are interrupts enable bits
- when reading, bits 6-2 of FE00 are interrupt status bits, indicating whether or not the event that causes the interrupt is currently present (even if not enabled!)

So in many respect FE00 is two registers - a write-only interrupt enable register and a read-only interrupt status register - that co-exist at the same address.

When I said "the respective bit can still be set" that was really confusing. What I mean was the event that causes the interrupt can still be present, and so the status bit seen when reading FE00 can still be at "1", even if the corresponding interrupt enable bit is "0".

The interrupt enable bits only affect the master interrupt bit (bit 0), and whether the IRQ line out of the chip is asserted (active low).

More detail could be given on each interrupt...

Whilst I could make something up, it'd probably be rubbish! Can you suggest some words here?

I'll draft something tomorrow. Please prod me if I forget!

...including the method to clear it.

Isn't this covered under &FE05?

FE05 only allows three of the interrupts to be cleared (RTC, Display End and High Tone Detect).

Rx Full is cleared as a side effect of reading the data shift register (FE04)

Tx Empty is cleared as a side effect of writing the data shift register (FE04)

Dave

[hoglet]

and...

Is this what you mean regarding the shift register? Ie, when writing a byte, do the incoming bits drop into the top 8 bits, or the lower 8 bits?

Fig 14-3b.jpg

Similarly, for 14.3a (reading from the shift register), do we read from the top 8 bits?

This diagram looks better, although I would be inclined to remove the two blank bits on the right.

For the receive diagram, the bits are fed in to bit 7, and again shift right-to-left towards bit zero.

[jgharston]

[*]Electron Technical Information - Jonathan Harston

I didn't write that, Thomas Harte wrote it, I just plonked it there because I couldn't find the original online anywhere.

[jms2]

This diagram looks better, although I would be inclined to remove the two blank bits on the right.

I put those in to represent the 10 bit shift register. Is that too much detail to include?

[hoglet]

This diagram looks better, although I would be inclined to remove the two blank bits on the right.

I put those in to represent the 10 bit shift register. Is that too much detail to include?

If you do want to represent it as 10 bits, then it would be best to put the start bit on the right hand side (and indicate in the box a value of 0), and the stop bit on the left hand side (with a value of 1)

My (slight) reservation about including this detail is it still is rather speculative. It's very hard to tell from the outside that this really is implemented as a single 10-bit shift register, versus an 8-bit shift register and a couple of hardware state machines. All you ever see through &FE08 is 8 bits of data. It could even be two separate 8-bit shift registers.

I think on balance I would include it, because indicating the position and value of the start/stop bits is very useful, even if it turns out that the actual implementation takes a slightly different form.

Dave

[jms2]

OK. That makes sense - I can also add some words to explain that it is a functional representation rather than literal.

How about in the read diagram? Are there similar start and stop bits to indicate there as well?

I understood your earlier explanation of FE00 as well, but I just want to clarify my understanding of the Master IRQ bit.

1. Writing to it does nothing. It's value is set by the contents of the other bits. If so, would it be fair to say it isn't writable?
2. When reading, its state indicates whether one or more interrupt conditions is enabled.

Is that right? If so, it's not actually possible to test whether a specific condition is enabled to generate interrupts, except by waiting for an interrupt and then checking the register to see if it was that one. Just trying to make sure I've got it!

[hoglet]

How about in the read diagram? Are there similar start and stop bits to indicate there as well?

I think for consistency I would show them as well.

I understood your earlier explanation of FE00 as well, but I just want to clarify my understanding of the Master IRQ bit.

1. Writing to it does nothing. It's value is set by the contents of the other bits. If so, would it be fair to say it isn't writable?

Correct. Only bits 6-2 are directly writeable.

2. When reading, its state indicates whether one or more interrupt conditions is enabled.

Just to be very precise, when read bits 6-2 of &FE00 indicate whether the interrupt condition is present (regardless of whether it is enabled).

Is that right? If so, it's not actually possible to test whether a specific condition is enabled to generate interrupts, except by waiting for an interrupt and then checking the register to see if it was that one. Just trying to make sure I've got it!

That's correct - there is no way to directly read back the interrupt enable bits.

Even trying to infer their values indirectly is hard. Imagine an interrupt happens and reading &FE00 returns &B1 (10110001). This indicates two interrupt conditions are present (bit 5 is TxEmpty and bit 4 is RxFull), as is Master IRQ (bit 0). (Bit 7 is always set). All you can say for sure is that at least one of the corresponding interrupts enable bits must have been set (otherwise Master IRQ would be clear). But you don't know for sure which, or whether both are set.

Dave

[jms2]

2. When reading, its state indicates whether one or more interrupt conditions is enabled.

Just to be very precise, when read bits 6-2 of &FE00 indicate whether the interrupt condition is present (regardless of whether it is enabled).

Ah, so reading a "1" in bit zero indicates that "one of the interrupt conditions has occurred" - effectively it's all the other bits ORed together. It doesn't indicate that any are necessarily capable of triggering an IRQ.

So in summary, writing = used for enabling interrupts (bits 6-2 only); reading = used for checking which potentially interrupt-causing conditions have occurred (bits 6-1), and ORed summary in bit 0.

If that's the case then I can't help thinking that bit 0 is kind of redundant.

[ThomasHarte]

2. When reading, its state indicates whether one or more interrupt conditions is enabled.

Just to be very precise, when read bits 6-2 of &FE00 indicate whether the interrupt condition is present (regardless of whether it is enabled).

Ah, so reading a "1" in bit zero indicates that "one of the interrupt conditions has occurred" - effectively it's all the other bits ORed together. It doesn't indicate that any are necessarily capable of triggering an IRQ.

So in summary, writing = used for enabling interrupts (bits 6-2 only); reading = used for checking which potentially interrupt-causing conditions have occurred (bits 6-1), and ORed summary in bit 0.

If that's the case then I can't help thinking that bit 0 is kind of redundant.

Bit 0 is a logical mirror of the IRQ line. So it is set if at least one interrupting condition has occurred for which the interrupt enable flag is set.

So it's redundant if you already know the values for both control and status but you can't read control and, being interrupt stuff, they probably thought it would be helpful to be able to get the conclusion quickly?

[hoglet]

John,

It might be helpful to look at the logic equations for this part of the ULA reimplementation:

Code: Select all

    master_irq <= (isr(6) and ier(6)) or
                  (isr(5) and ier(5)) or
                  (isr(4) and ier(4)) or
                  (isr(3) and ier(3)) or
                  (isr(2) and ier(2));

    isr_data   <= '1' & isr(6 downto 2) & power_on_reset & master_irq;

    ula_irq_n  <= not master_irq;

When you read &FE00, the value that is returned is isr_data.

Dave

[jms2]

Yes, that does help. VHDL is great!

[jms2]

Here's where I'm up to with Chapter 14. Red text is new, and yes I realise that the PDF process has ruined the diagrams (they are fine in Word).

The yellow highlighted bits are where I'm not happy.

EAUG - Issue 3D1 Ch14.zip

(162.74 KiB) Downloaded 87 times

Any comments/suggestions welcome!