Electron ULA Documentation Updates

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 8:46 am

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:
Please let me know if I've missed anything.

Dave
Last edited by hoglet on Tue Oct 04, 2016 9:15 am, edited 4 times in total.

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 8:47 am

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 49 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
Last edited by hoglet on Tue Oct 04, 2016 9:10 am, edited 2 times in total.

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 8:47 am

Reserved for something else.

User avatar
1024MAK
Posts: 6721
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Electron ULA Documentation Updates

Postby 1024MAK » Tue Oct 04, 2016 9:56 am

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
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 10:11 am

1024MAK wrote: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
Last edited by hoglet on Tue Oct 04, 2016 10:17 am, edited 2 times in total.

paulb
Posts: 769
Joined: Mon Jan 20, 2014 9:02 pm

Re: Electron ULA Documentation Updates

Postby paulb » Tue Oct 04, 2016 10:14 am

hoglet wrote: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.

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 10:17 am


ThomasHarte
Posts: 340
Joined: Sat Dec 23, 2000 5:56 pm

Re: Electron ULA Documentation Updates

Postby ThomasHarte » Tue Oct 04, 2016 1:22 pm

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.

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 2:34 pm

ThomasHarte wrote: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:
ThomasHarte wrote: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

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Tue Oct 04, 2016 4:45 pm

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

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.

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Tue Oct 04, 2016 4:49 pm

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.

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Tue Oct 04, 2016 5:35 pm

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

That would be awesome. I was kind of hoping you would volunteer.
jms2 wrote: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

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Thu Oct 06, 2016 10:25 am

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:
ThomasHarte wrote: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
ThomasHarte wrote: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:
IMG_0701.JPG

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

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Thu Oct 06, 2016 7:04 pm

hoglet wrote: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
Posts: 340
Joined: Sat Dec 23, 2000 5:56 pm

Re: Electron ULA Documentation Updates

Postby ThomasHarte » Thu Oct 06, 2016 7:51 pm

hoglet wrote: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

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Thu Oct 06, 2016 8:26 pm

ThomasHarte wrote: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.
ThomasHarte wrote: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

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Thu Oct 06, 2016 9:31 pm

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

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

hoglet wrote: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?

hoglet wrote: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?

hoglet wrote:...including the method to clear it.


Isn't this covered under &FE05?

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Thu Oct 06, 2016 9:42 pm

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?

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Thu Oct 06, 2016 9:44 pm

jms2 wrote:
hoglet wrote: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).
jms2 wrote:
hoglet wrote: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!
jms2 wrote:
hoglet wrote:...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

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Thu Oct 06, 2016 9:49 pm

jms2 wrote: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.

User avatar
jgharston
Posts: 2723
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Electron ULA Documentation Updates

Postby jgharston » Thu Oct 06, 2016 10:44 pm

hoglet wrote:[*]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.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Thu Oct 06, 2016 11:14 pm

hoglet wrote: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?

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Fri Oct 07, 2016 6:48 am

jms2 wrote:
hoglet wrote: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

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Fri Oct 07, 2016 7:25 am

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!

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Fri Oct 07, 2016 8:57 am

jms2 wrote: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.
jms2 wrote: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.
jms2 wrote: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).
jms2 wrote: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

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Fri Oct 07, 2016 12:01 pm

hoglet wrote:
jms2 wrote: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
Posts: 340
Joined: Sat Dec 23, 2000 5:56 pm

Re: Electron ULA Documentation Updates

Postby ThomasHarte » Fri Oct 07, 2016 12:23 pm

jms2 wrote:
hoglet wrote:
jms2 wrote: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?

User avatar
hoglet
Posts: 6471
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron ULA Documentation Updates

Postby hoglet » Fri Oct 07, 2016 1:57 pm

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

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Fri Oct 07, 2016 4:29 pm

Yes, that does help. :D VHDL is great!

User avatar
jms2
Posts: 1830
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Electron ULA Documentation Updates

Postby jms2 » Fri Oct 07, 2016 8:18 pm

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 23 times


Any comments/suggestions welcome!


Return to “hardware”

Who is online

Users browsing this forum: mlouka, rune and 12 guests