Electron cassette i/o scope trace

[hicks]

Hi all.

I'm in the process of creating an Acorn Electron core for the FPGA Replay board. Between forum posts, the advanced user guide and various sites with info on the ULA I've managed to reach the point where I just have the cassette interface and audio to go and this is where I've run into a bit of a wall.

Before I work out a virtual interface via SD card, I want to really understand what the current hardware interface is doing. From the AUG I've a reasonable understanding of how the registers work but it's what lies between shifting in/out of the register and the CAS I/O pins that remains a mystery. I read a post by hoglet earlier that linked to his implementation of the Electron and confirmed some of my guesses as to how the ULA might work internally cassette i/o wise, however it left a few questions.

I'm still not really all that clear on what kind of signal the CAS IN and CAS OUT pins see which makes it difficult to gauge what the ULA may be doing internally.

I'm intending to pick up an Electron+tape deck off of ebay (if I can manage to grab a bargain that is), which will allow me to answer this question (and check my assumptions on various others) but until then, does anyone already have/know of a scope trace of those pins during load/save operations?

In addition, CAS RC. Any clues as to its purpose? From the schematic it looks to be tied only to CAS MO, +5 and GND. I'm wondering if it might be a time delay such that when the motor starts for playback, CAS RC doesn't go high for a short time to allow the tape to settle in for playback and avoid any I/O during that brief start-up period?

[hoglet]

I have casIn and casOut working in ElectronFpga.

Here's how casOut is implemented:
https://github.com/hoglet67/ElectronFpg ... A.vhd#L707

And here's how casIn is implemented:
https://github.com/hoglet67/ElectronFpg ... A.vhd#L603

I don't know how faithful the implementation of casIn is to the original ULA, as we haven't (yet) been able to yet hold of the original schematics. I'believe that one of the original developers (Harry Barman) still has a copy, but he didn't respond to a request for information when I tried last year.

Dave

[hoglet]

This post has a scope trace of the ULA cassette output signal:
viewtopic.php?p=150521#p150521

Dave

[hicks]

Thanks dave, especially for the scope trace post, that's just what I was looking for.

I guess this could be generated from a Xilinx using two outputs and a ladder DAC with a couple of carefully chosen resistors. I haven't done that yet, so it's just a simple square wave.

That clears up my confusion over your cas out code. I couldn't see where the pseudo sine wave was generated, it looked like you were just outputting a square wave at 1200 or 2400Hz but I'd convinced myself there had to be more to it

Does the square wave appear to work well for saving and loading back in via a physical tape deck?

It'd be nice if I can get away with using square wave as that'll make the i/o pins suitable for use both by my virtual interface or exposing to the aux output pins for a real cassette deck to use. Although adding an extra path to get closer to the sine wave wouldn't be too much hassle.

[hoglet]

Does the square wave appear to work well for saving and loading back in via a physical tape deck?

It does work, but to be completely honest it's not been extensively tested.

Dave

[hicks]

I'm looking at FE06, the general counter and how that ties into the zero crossing count and whilst I believe I understand your code, something doesn't quite add up, pun intended

There's a div13 pin on the ULA (other docs mention this is related to baud rate) which given a 16MHz signal would clock at 1.231MHz which made me think at first there'd be a 10 bit counter inside the ULA which would allow 512 and 1024 to be used along with the div13 to determine a 1 or 0 based on the 2400Hz or 1200Hz pulse frequency.

However the AUG lists FE06 as an 8 bit register with only the first 7 bits in use. If the general counter is limited to 128, the ULA must be doing more to detect zero crossings?

I may end up using a 16 bit counter like you have, but it feels like there may be more to the ULA in this case and since FE06 can be written to by programs during a tape read, that "more" maybe has an impact outside the ULA? If internally the ULA uses a larger than 8 bit register to count crossings, it makes me wonder what happens when a FE06 write occurs. Do just the lower 7 bits get altered, are the upper bits left alone or zero'd.

If only we had those ULA schematics I have a feeling this may be a mystery that only the schematics or reversing of the die will actually solve, but then I assumed that about most of the ULA and it's amazing what people have managed to deduce Maybe it's worth reaching out to Mr Barman again?

If you or anyone else has any thoughts on this, I'd be interested to know. For now I'll probably also go with a larger counter and come back to this later.

[danielj]

Steve Furber did say he was happy for his brain to be picked about anything to do with the electron ULA and he'd see if he could remember?

d.

[hicks]

That'd be great if he's able to shed any light on the above or any part of the cassette interface within the ULA in general.

[hoglet]

Maybe it's worth reaching out to Mr Barman again?

I agree it is worth another try contacting Harry Barman:
http://www.stardot.org.uk/forums/viewto ... 7791#p7791

BigEd tried last year, but I think got no response.
http://www.stardot.org.uk/forums/viewto ... 49#p150649

I've just sent him another email, so let's see if there is any response this time.

Dave

[hicks]

The more I look at the cassette implementation, the more questions seem to crop up.

* How CAS RC fits into it. As it only looks to be connected to motor/+5v/gnd yet service manual states this is to detect high tone.
* When saving to tape, how is the high tone of consecutive bits written out if there's always a start bit (0) before the 8 data bits and stop bit(1). (edit: I believe I understand this one now, the default to write out is 1's unless there's a write to FE04 to trigger a byte output)
* Then there's uncertainty over the use of the counter register.

Hopefully one of you has some success reaching out and we can start to clear up some of these unknowns

[*]: I really need to get a hold of an Electron on Ebay, hopefully I'll manage to get a bid won before too long

[crj]

Out of interest, do we have any idea who owns the design of the Electron ULA nowadays? Do we know who physically has the design data?

This sort of thing would be inestimably simpler if we had access to the source!

[hoglet]

Out of interest, do we have any idea who owns the design of the Electron ULA nowadays? Do we know who physically has the design data?

Like most 8-bit Acorn things, I don't think anyone official owns it any more (or cares), and most of the original design data is likely lost forever.

This sort of thing would be inestimably simpler if we had access to the source!

As mentioned above, the only known copy of the schematics are allegedly in the the possession of one of the ex-Acorn engineers, a chap called Harry Barman, who we are trying hard to reconnect to.

Dave

[danielj]

Broadcom, at a guess. The design data is long gone though I suspect...

"I’ve looked through my archives, but I’m afraid I haven't come across any Electron ULA details.
The physical layout of the ULA was done using software on a BBC Micro, largely by John Cox,
if I remember right (all previous ULAs were done using hand drawing!)."

d.

[crj]

Well, if John Cox is the person who might be able to help, I know his boss. (-8

[hicks]

Just wanted to say a quick thanks to Dave for providing the cassette scope traces and code link. My implementation was along similar lines although I've gone about it in quite a different way, it was reassuring to see someone elses implementation was conceptually the same and had being confirmed to work.

I was a little unsure of how to approach this at first as the ULA would be receiving frequency based data when used with a real cassette but also regular bytes when running from the FPGA Replay's SD card. I didn't like the idea of two code paths within the ULA so in the end decided to complicate the SDCard -> ULA path a little.

I added a "translator" over the weekend that takes regular bytes out of a FIFO that the FPGA Replay library provides and then treats that as a tape bitstream and converts from '0' and '1' to a frequency representation before passing it onto the ULA. It might sound a little weird but it allowed me to make the ULA not care about whether data is coming off of a real tape or SD card, it gets the same input signal. The path was now

raw file on SD Card -> ARM -> [regular data bytes] -> FPGA FIFO -> Translator -> [square wave frequency encoded ] -> ULA

and hopefully once hw has been built and connected that matches the Electron's cassette hardware the path will be

aux cas_i pin -> ULA

There'll be a small quirk with saving if I implement the pseudo sine wave (I've not looked into saving yet) as I think the ULA will need to output square wave to the translator and pseudo sine for an actual cassette, a config flag would solve that though. Like with loading this is where there's a need to choose between dual code path with ULA just outputting the full byte on a separate signal, or keeping ULA mostly one code path and complicating things with translator again. I'd like to keep the ULA as simple as possible really though. It just feels a little redundant to go digital -> frequency -> digital again

Anyhow, the result of this is last night I finally got to *LOAD and *RUN something (which failed due to forgetting that the stop bit is two pulses and I needed to eat the 2nd ) and here's the result

To say I was pleased is quite an understatement, my face is aptly represented by Also 2 for 2 on docking, I used to die way too much doing that, must be like riding a bike

[1024MAK]

Nice .

Can you also post a photo of the hardware please

Mark

[hicks]

=D> Nice .

Can you also post a photo of the hardware please

Mark

This is a photo of the hardware before I moved it into the mini-itx case shown in the first photo. I didn't have a suitable RS232 straight through cable at the time either, so there's quite a few jumper cables from the serial port to serial cable

It's running on the FPGA Replay, I've got a small review of that on my blog.

[hicks]

I'm working on adding save support now with CAS OUT and have a question regarding hoglet's implementation and notes in the AUG.

The AUG states a high-tone is 10 successive 1's, presumably because 9 successive 1's is the longest sequence of ones whilst still being valid data due to a start bit of 0 so 10 couldn't ever exist in normal data.

In my read implementation I have a state that detects those ten 1's then moves to waiting for a start bit, effectively eating any further 1's in the unlimited duration high-tone sequence. I noticed hoglet's version only looks for the first 1 in the sequence before moving to waiting for a start bit. I didn't think much of this at the time, but bear with me (especially as it's a long winded question)..

Writing

For writing, once the TX Empty interrupt is cleared signifying someone wrote a new byte to the FE04 for output, that byte can be shifted out, TX Empty set and then a '1' stop bit written out. This is where my confusion begins as I can see two possible scenarios:-

1) during the time the stop bit is being output, new data is written to FE04 and TX Empty cleared. Thus as soon as the stop bit has finished being output, the ULA can move straight to outputting a start bit and the next byte's data + stop bit. all is good and the cycle can repeat...
2) IF however the stop bit is output and no new data has been written to FE04, TX Empty is still set and the ULA is out of bits to write, then what?

The case I'm interested in is #2. I presume as long as the motor is engaged the ULA needs to output something? does the real electron switch to outputting 1's so that there's a high tone output ready for when the next byte is finally written to FE04? If so, my implementation has a problem which hoglet's does not.

Problem Example

For example, suppose the ULA runs out of data to write and switches to outputting a sequence of 1's. It outputs 5 of them then FE04 has data written to it (as TX Empty was set). If the ULA jumps straight in to outputting a start bit+data+stop bit, there'd be a short sequence of 5 ones that during read-back would not satisfy the high tone detect rule and the following (otherwise valid) data in turn would not be read in.

If the real ULA does require ten one bits for hightone, how does it handle this? Is it possible that once the ULA runs out of bits, it will always finish what it starts, i.e write out 10 bits of 1's at a time and only switch to outputting the new contents of the data shift register once it has finished outputting the current batch of high tone bits?

Or is the AUG wrong and even just one '1' is sufficient to count as a high tone as in hoglet's implementation?

I expect the answer will be "we don't know" which is fair enough In that case, do you think it sounds feasible that it will output a high tone fully anytime it began? Has anyone observed anything that would suggest this is not the case?

I know we have gained access to the schematics, "go look at those" I hear you say. I have and I need to learn more and spend a great deal more time with them before I think I could answer this question, but I did look and will look more even when I have a working implementation

[hoglet]

The implementation I ended up with is a bit like a UART, where the quiescent level ('1') is the high tone, and arbitrary size gaps are allowed between the bytes.

It might be possible to do an experiment on a real electron to test this. Such as opening a channel and using BPUT to write some data with carefully controlled gaps between the bytes. I would expect that very short gaps would be allowed, which would equate to short (<10) runs of '1's.

Dave

[hicks]

If short gaps are allowed, any idea where the suggestion that a high tone would be a 10 bit sequence came from in the AUG? It's in red which I assume means a recent addition in the draft 3 version so possibly due to a discussion on this forum or another?

The Electron test is a good idea, although I've yet to manage to win a bid for a reasonably priced one so that will have to wait I guess another option would be to analyse some of the UEF files and see if any have an ending section of data punctuated by high tones of less than 10 bit multiples. I might have a look at that later.

For now I think I'll just switch my reading FSM to looking for a single high tone bit instead of 10 as yours does. Then saving doesn't need to worry about how many 1's are output. Until anyone can provide evidence to suggest it worked differently that is

[hoglet]

I did wonder if the "10 bit high tone detect" is only used to generate the high tone detect interrupt, and not by the receiving state machine.

There might be some clues in understanding what the MOS actually does with the high tone detect interrupt.

Jonathan has a disassembly of the Electron MOS here:
http://mdfs.net/System/ROMs/AcornMOS/El ... ELK100.zip

Dave

[davidb]

As you suggest, it may be that 10 consecutive 1-bits is given as a way of indicating and guaranteeing that the audio is not data, because 10 1-bits could not represent valid data. With my experiments with a real Electron I tried to reduce the leading high tone before a data block and found that the Electron didn't respond unless there was a certain length of leading tone. To be conservative, I would generate 60 1-bits at the start of a data stream.

I would experiment further but the Electron I'm using is going through one of its "deaf" phases with respect to cassette input.

[hicks]

Assuming 10 bits at least is an actual requirement the ULA enforced, and having thought on this some more, #2 may not be a real problem.

When the ula signals TX Empty there's a reasonable amount of time for the 6502 to push out the next byte if it's doing a write to tape sequence. So perhaps #2 never occurs.

The other possibility is, writes occur in one big batch and that's it, done, disable motor. Although observing a load sequence this seems unlikely as each block the loading counter shows, appears to be proceeded by a high tone period. Perhaps the OS provides a delay when bulk saving between blocks to allow high tone to be written.

Some time with the disassembly above might shed light on that.

It's interesting how many ways the tape load/save could actually be done and the possibilities for when interrupts are raised/counter used.. Mysteries we'll hopefully be able to solve (or confirm previous assumptions) with the schematics now

[davidb]

In case it turns out to be useful, though it covered slightly different things, I thought I'd mention this other thread about cassette I/O.

[hicks]

One extra question, did any of you notice what CAS OUT did when the electron was just at the basic prompt so neither loading or saving? Was it constant high, low or outputting one pulses? Also same question but during a load operation?

I'll check out the other thread in the morning, just about to head to bed

[hoglet]

I'm pretty sure that when the motor is on it outputs a continuous high tone; I can check that today.

Dave

[hicks]

I'm pretty sure that when the motor is on it outputs a continuous high tone; I can check that today.

Dave

Is that regardless of comm mode setting and whether it's actively reading via CAS IN?