Electron ULA Documentation Updates

[jgharston]

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

"Power on reset: Clears automatically"

I think I found that that bit is cleared by reading &FEx0. A quick prod of my Electron suggests this is so, it is read as part of the RESET startup code, so at any point after that it will always be zero. (cf other thread with Elk version of *FX151,78,127)

[jms2]

Thanks for that Jonathan, I've included that now.

The other bit I don't like is the following sentence from the original authors: "Enabled interrupts can get the 6502 to look at them if they generate a suitable signal. " I'm not quite sure what that means. My understanding was that if you enable a particular interrupt and IRQ is triggered and the code can then confirm the reason by examining &FE00 and then take appropriate action. There is no other "suitable signal"... is there?

I think I just need to reword this bit.

And - Dave you were going to offer some words explaining what the various interrupt conditions mean. I don't think what I've written really covers this as yet.

Moving on from Chapter 14, I'm working on updating the FRED allocation list based on the one published on here a while back by Mark. I'm going to update Appendix G to include all the new hardware expansions in the list, and hopefully to include some very brief details of how they work (where possible). Also, I have another question: In the original manual, *FX178 was completely missing. Are there any other *FX calls that are missing?

[hoglet]

And - Dave you were going to offer some words explaining what the various interrupt conditions mean. I don't think what I've written really covers this as yet.

On the Electron there are five interrupt conditions, each of which has a status flag in &FE00.

- High Tone Detect (Bit 6) - this interrupt indicates that 10 successive bits of high tone (i.e. 20 cycles of 2400Hz) have been detected on the tape input. It's cleared by setting bit 6 of &FE05. The high tone detection circuity is only enabled when the Motor Control bit in &FE07 is set. For correct operation it also requires the counter mode in &FE07 to be "tape input" and the counter value in &FE06 to be 0 (or close to 0).

- Tx Empty (Bit 5) - this interrupt indicates a byte has been sent to the tape output and the data shift register is empty and ready for the next byte to be written. It's set immediately after bit 7 of the byte has been sent, and prior to the stop bit being sent. This interrupt is cleared when the next byte is written to the data shift register. It's worth emphasising that the normal state of this interrupt is set, and only whilst a byte is being sent it is ever clear.

- Rx Full (Bit 4) - this interrupt indicates a byte received from the tape input and is available in the data shift register (&FE04). It's set as soon as bit 7 of the byte has been clocked into the shift register. It's cleared either by reading the shift register, or when the start bit of the next byte is clocked into the shift register. This gives a window for reading the shift register of two bit times, or approximately 1.66ms. This interrupt can be occur spuriously in other counter modes. For example, when switching to tape output mode. Unlike the high tone detect, it's not dependent on the setting of Motor Control bit in &FE07.

- RTC (Bit 3) - this interrupt occurs at 50Hz and is used (in conjunction with Display End) to implement a 100Hz system clock. It occurs
when the video output reaches line 99 of the active display, but the position within the line varies actually between the odd and even fields. More specifically, the ULA generates this interrupt exactly 8192us after the end of the 160us vertical sync pulse. The interrupt is cleared by setting bit 5 of &FE05.

- Display End (Bit 2) - this interrupt occurs when the video output reaches the falling edge of the horizontal sync pulse after the last active line of the display. It's cleared by setting bit 4 of &FE05.

Both RTC and Display End occur at 50Hz (every 20ms), but they are staggered by 10ms, and together they are used to generate a 100Hz system clock (used for TIME, etc).

The exact timing of the RTC and Display End interrupts can be seen in the scope pictures in this post, which would be great to include:
http://www.stardot.org.uk/forums/viewto ... 09#p134109

Dave

[jms2]

Superb! All that's going in, along with the scope shots. I might redraw them as diagrams, got to think about that...

[hoglet]

Superb! All that's going in, along with the scope shots. I might redraw them as diagrams, got to think about that...

Nah, they'll loose their "retro" authenticity

Actually, scoop is circa 2000, so not that retro.

[jms2]

Production of the third edition is going well. Apart from the timing diagrams, which I'm thinking might need to go into a different chapter, chapter 14 is done. So far, the changes are:

1. ULA register descriptions updated, and improved FRED allocation table.
2. Moved Plus 1 specific material into Appendix G, which is intended to contain technical details for all Elk hardware expansions in one location.
3. Added details of the bug in the Plus 1 whereby the phi2 signal is actually phi0.
4. Added 6502 instruction set table.

I'm going to look around for basic hardware descriptions of recent add one to go into App G, but if anyone fancies contributing their own words, that would help! I am after descriptions of what memory locations are used etc, similar to the existing style.

[davidb]

This all sounds very useful. Thanks to all of you for putting in the effort to make a new edition!

[jms2]

OK, here's draft 1 of the whole book!

Everything is in there, except I have not updated the contents page numbering or the index. Also, just realised I have not included the scope shots above...

If anyone thinks that there is something else which ought to be included, or deleted - please let me know. I have made a lot of reference to JGH's excellent list of FRED addresses and included those which I think are relevant to the Electron. I might have gone a bit far with this - does BeebSID actually work with the Electron, for example? I can't see why it wouldn't.

In the section on interrupt handling I have highlighted a sentence from the original manual which I think is nonsense and I propose to delete it, unless it has some hidden meaning that I've not been able to figure out!

EAUG - Issue 3D1.zip

(2.28 MiB) Downloaded 33 times

[daveejhitchins]

I think we should expand the Memory Map! JGH (again ) has a quite comprehensive one here. This does reference some/all (?) Electron differences. >> Just a suggestion: Maybe we could also add the usage (hardware) by third party hardware! E.g. By my own ABR/ATI/AP7/AQR etc. and, more importantly any clashes with BBC/Master hardware e.g. Mark's (RetroClinic) DataCentre clashes with the AQR usage! These need not be added immediately but as and when they are found . . .

Dave H

[1024MAK]

I posted an Electron Memory Map here in April this year

Mark

[jms2]

I posted an Electron Memory Map in April this year ]

I looked at that one Mark, but I thought I'd managed to include all that content.

The JGH memory map looks a bit more detailed than the one in the AUG so I will try to extract those additional details.

Dave H - can you have a look at my potted descriptions of your hardware creations in Appendix G?

[1024MAK]

I posted an Electron Memory Map in April this year ]

I looked at that one Mark, but I thought I'd managed to include all that content.

Ah, okay, being busy at work this week has left me playing catch-up.

Mark

[daveejhitchins]

Dave H - can you have a look at my potted descriptions of your hardware creations in Appendix G?

I was half way through reading the AUG when life came along and distracted me . . . So missed a whole bunch of additions/changes. Here's what I've noticed (I'll add more as I come across them):

This input is nominally should be the host computer's Phi2 signal. However, owing to what appears to be a design fault in the Plus 1 Electron unit, this pin actually carries Phi0 on the Electron.

These two expansion units provide hardware-lockable battery backed sideways RAM. The ABR is in cartridge format, whereas the AP7 is in a form that can be installed internally in an one or two of the original AP6 rom slots.

The Advanced Tube Interface provides the functions of an ABR* along with a BBC Micro equivalent tube connector for the Electron, but with the Tube ULA mapped to the following addresses in page &FC:
* Note that the highest cartridge slot numbered 16K bank of RAM can be relocated to the high priority sideways bank number 13.

PRES Advanced Quarter Meg RAM
This unit provides 256k of RAM in the form of 16x sideways RAM pages. The page can be selected by writing to the paging register. The unit can be locked or unlocked (all banks together) by writing any value to either the ‘unlock’ or ‘lock’ registers.
&FCFC Paging Register
&FCFD Unlock Register
&FCFE Lock Register
Note: The above addresses clash with RetroClinic's DataCentre.

RetroClinic DataCentre
&FCF8 VNC1L Data Port
&FCF9 VNC1L Control Port
&FCFA NVRAM Data Port
&FCFB NVRAM Data Direction Register
&FCFC NVRAM Clock
&FCFD NVRAM Write Protect
&FCFE Paged RAM MSB
&FCFF Paged RAM LSB
Note: See the PRES Advanced Quarter Meg RAM, above, for address clashes.

A full specification for producing suitable add-ons is available from Acorn Computers Limited.

Should this information be added, as it's unlikely that Acorn will be able to supply it now! It could be cut-and-pasted from the Beeb AUG . . .

General interface units
PRES / Retro Hardware AP6 up to 6/7x ROM/RAM slots
Retro Hardware ATI Tube Interface and 32K RAM

Disc interfaces - - -
PRES AP3 ADFS 1D00
               DFS E00

There's a better Schematic Diagram, of the electron, courtesy of C.Dewhurst (we may need his permission to use this?). This could be arranged to be a 'fold-out' sheet!

17APPXF.PDF.zip

(54.67 KiB) Downloaded 38 times

The other major component is the computing centre of the system, which is the Synertek SY6502A central processing unit (CPU).

Are ALL Electron fitted with Synertek parts?

Dave H

[jms2]

Superb, thanks for all those comments Dave! They'll keep me busy for a bit, plus I'm going to review against the jgh memory map.

[1024MAK]

Good work so far

Not having had a chance to properly read the draft document, but is there anything about the "option" components on some versions of the Elk board? And hence the "link" settings (or PCB tracks across what was originally a "link")?

Only a fairly common question that people ask, is "can I use the spare ROM position?"
The answer is, not for sideways ROM or RAM.

Mark

[jms2]

Good work so far

Not having had a chance to properly read the draft document, but is there anything about the "option" components on some versions of the Elk board? And hence the "link" settings (or PCB tracks across what was originally a "link")?
E
Only a fairly common question that people ask, is "can I use the spare ROM position?"
The answer is, not for sideways ROM or RAM.

Mark

Nope, there's nothing about any of that. I doubt the Service Manual would be much help either, because it's based only on Issue 4. I think a section on differences between machine versions would be useful.

Regarding the spare ROM slot, wasn't that to allow Acorn to split OS and Basic into two discrete 16k packages rather than a single 32k item?

[jms2]

Just wanted to give this thread a bump to say that I'm still working on this - it's just that real life has got in the way for a few weeks.

I've incorporated all Dave's comments, and I'm looking at the circuit diagram. Dave's right - the Chris Dewhurst vectorised version is clearer. However, it's not perfect. I don't know how Chris created it, but it almost looks as if he's used some kind of "OCR" type approach, but for diagrams. Consequently there are various areas which look kind of OK but in reality are quite messy. I'm tidying everything up, but it will take a while.

[jms2]

I've got the schematic all fully cleaned up now, just need Chris Dewhurst's permission to use it. I've emailed him via his address at "draganddrop" magazine.

I've also been checking against JGH's "allmem" file of memory location usage (found on MDFS.net). I'm glad I did - because it appears to show that the EAUG is wrong in at least two areas:

1) The location of the two stored TIME values is offset by one byte compared to the BBC (and the values following, including the ROM table, are also moved by one byte). I've checked this and the JGH information does seem to be correct. One thing though - why are the TIME values stored MSB first, LSB last (as appears to be the case?)

2) The BBC has locations &2B6-&2BE for ADC conversion results, and the EAUG repeats this detail. However the Allmem file seems to suggest completely different usage for this area on the Electron, which begs the question of where the ADC conversion data goes. Or am I misreading this?

[jgharston]

1) The location of the two stored TIME values is offset by one byte compared to the BBC (and the values following, including the ROM table, are also moved by one byte). I've checked this and the JGH information does seem to be correct. One thing though - why are the TIME values stored MSB first, LSB last (as appears to be the case?)

It makes updating them easier with a DEX:BNE type loop.

2) The BBC has locations &2B6-&2BE for ADC conversion results, and the EAUG repeats this detail. However the Allmem file seems to suggest completely different usage for this area on the Electron, which begs the question of where the ADC conversion data goes. Or am I misreading this?

The Electron shuffles loads of stuff around in page 2, really annoyingly. I think I've got them all. It's as though they cut out lines from the source instead of just not referencing the locations. The ADC conversion data is stored in &2F7-&2FF - scroll down the document a little.

[jms2]

Thanks Jonathan, that confirmation that I am reading it right is what I was looking for. It just seemed really odd that Acorn would (a) change lots of things for no obvious reason and (b) document it wrongly.

Although, point b could be my fault - I do remember adding some detail to this section when I produced the Second Edition, but I'm pretty sure that I used Electron User as the source (rather than copying from the BBC AUG). I've got all my notes so I'll be able to formally point the finger at whoever introduced the mistake, including at myself if necessary!

EDIT: Ah, OK, so it was my fault. My notes indicate that I copied the memory map stuff from the BBC Micro AUG. Still don't see why they felt the need to move stuff around though - as you say, it was probably accidental.

[jms2]

Anyone have an up to date email address for Chris Dewhurst? I've tried contacting him at Drag and Drop, but without any success.

[davidb]

One suggestion I would make is to renumber the bits in figures 14.3a and 14.3b. The bits are recorded to cassette in little-endian order, so what I would call bit 0 is the first bit after the start bit.

I'm currently trying to understand this part of the Electron a little better, so any more information about how the shift register is filled and when it can be read is most welcome.

[jms2]

I'll have a look at that David (the figure that is, I can't promise to unravel the mysteries of the shift register!)

Your suggestion is the prompt I needed to get on and finish this draft. It is 90% done, but I got stuck with trying to contact Chris Dewhurst over the diagrams, and since then the project has lapsed!

I think what I will do is go ahead anyway and just use Chris's figures with a credit to him. It's not as if I've just nicked them anyway, most have been extensively tweaked by me so they aren't the same as his versions.

[jms2]

I see what you mean about the figure, but are you sure your understanding is correct? It clashes with what hoglet said previously, and also with this remark which was present in the original AUG:

"If the byte is not read within about 2ms, the data will be lost forever as bit 7 falls off the end of the register when the next bit comes in!"

This is consistent with the data coming in at bit 0 initially (ie, from the right hand side of my diagram) and shifting left, as I'd drawn it.

[hoglet]

I've just checked what I did in the Electron ULA VHDL:
https://github.com/hoglet67/ElectronFpg ... A.vhd#L641

That's also suggesting the bit order is:
<start bit> <bit 0> <bit 1> <bit 2> ... <bit 7> <stop bit>

What exactly did I say earlier that contradicts this?

[davidb]

Just to clarify, I'm looking at the figures in the 3D1 issue of the EAUG. In particular, 14.3b looks like this:

Code: Select all

data out <- 0 X X X X X X X X 1
              7 6 5 4 3 2 1 0

However, looking at the waveform of data on a cassette, you see a 0 (start) bit then bits in ascending order. For example, the 0x2a byte at the start of a block is read from left to right as this:

Code: Select all

data: 0 1 0 1 0 1 0 0
bits: 0 1 2 3 4 5 6 7

So bit 0 was the first bit written to the cassette and bit 7 was the last. This would mean that the figure should look like one of these two diagrams:

Code: Select all

data out <- 0 X X X X X X X X 1
              0 1 2 3 4 5 6 7

            1 X X X X X X X X 0 -> data out
              7 6 5 4 3 2 1 0

The second representation is perhaps slightly more familiar to people.

When reading from cassette, I would imagine that the bits are read into bit 7 of the shift register and shifted right, so that the least significant bit ends up in the corresponding bit in the register, at least conceptually.

Does this make things any clearer?

[jms2]

I've just checked what I did in the Electron ULA VHDL:
https://github.com/hoglet67/ElectronFpg ... A.vhd#L641

That's also suggesting the bit order is:
<start bit> <bit 0> <bit 1> <bit 2> ... <bit 7> <stop bit>

What exactly did I say earlier that contradicts this?

I've just re-read your posts above (it gets confusing when there's both a 'read' diagram and a 'write' diagram!) and I realise that you've been consistent throughout. I think what's confused me is the original text of the AUG, which is wrong. I thought it was just the diagrams, and I'd tried to create some diagrams which accorded with what I thought you'd said, as well as the existing words.

It says that, when reading, you must avoid bit 7 dropping off the end of the register whereas if I understand correctly this risk applies to bit 0.
It later says "Bit 7 is written out first (so that it is the first in when the tape is played back)." - which is the exact opposite of what both you and davidb are saying.

I've re-adjusted the diagrams already, but I need to adjust the words to match. This is what I propose:

Data is input to the Electron from a cassette recorder. Each byte is prefixed with a ‘0’ start bit and terminated with a ‘1’ stop bit. Functionally, the shift register behaves as if it has ten bits, of which the central eight bits are readable. This data shifts into the most significant bit of the register, then shifts right until the whole 8 bits of a byte are in the ULA’s receive data register. At this point, data can be read out and stored in memory somewhere.

... Finally, the receive data full interrupt should be enabled. This will ensure that the 6502 knows when a byte can be read. If the byte is not read within about 2ms, the data will be lost forever as bit 0 falls off the end of the register when the next bit comes in!

Writing to this register causes data to be output to the cassette (assuming that the cassette output mode has been set by writing to &FE07). Bit 0 is written out first (so that it is the first in when the tape is played back). When the last bit has been written out, a transmit data empty interrupt is generated. This tells the 6502 that it can put the next byte to be sent into the register.

[davidb]

That looks good to me!

Aside: The reason I'm looking into this more closely is that I'm currently trying to write interrupt routines to read and write data without the overhead of the OS's routines and have managed to write data successfully. I didn't set any interrupts (TX Empty) explicitly in FE00 to achieve this. It seems that this interrupt is constantly being generated.

Similarly, I have tried to write a routine that reads data, and it seems that I can just check for the RX Full interrupt (even though I didn't set it). However, I don't seem to be able to read FE04 correctly, so it may well be that I need to set the appropriate bit in FE00, but I'm unsure how to do this. I imagine I can't just do this (or can I?):

Code: Select all

lda #$10    ; bit 4 is RX Full
sta $fe00

If this isn't correct, what would the correct bit pattern be?

[hoglet]

David,

I'm sure you know this already, but to setup tape input you need to:
- Set bits 2..1 of FE07 to 00 (to select tape in mode)
- Set FE06 to zero (I think this is needed as well, but not 100% sure)

Dave

[jms2]

That looks good to me!

Excellent, thanks for the feedback David (s)!