Electron User Port & Rom/Ram board

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Electron User Port & Rom/Ram board

Post by MartinB » Fri Jun 08, 2012 9:28 pm

Looking good for Elk hardware add-ons of late :D

As per the thread title, I’ve spent the last few months putting together a design for an Electron User Port interface. For my part, the project is unashamedly motivated by enabling the UPURS system to be used on an unmodified Elk ( :D ) but the design is in no way bespoke to UPURS and offers a generic 6522 implementation as per the Beeb. (I should point out that despite my initial resistance, I was cajoled into a ‘proper’ interface by my erstwhile UPURS support team of Paul, t’other Martin and Hugh :wink:)

The spec for the board is a full 6522 VIA implementation giving two User Ports, both identical in performance and connectivity to that of the Beeb. (More on that compatibility later.) The board also has a single 28 pin socket which supports rom and ram chips up to 32k x 8 such as 2764, 27128, 27256, 6264 and 62256. For 32k devices, the single chip is hardware partitioned into 2 x 16k and each 16k will respond as a unique rom/ram id therefore being equivalent in functionality to the standard two-chip rom cartridge as commonly used on Elks and Masters.

The project will follow my BeebSID mould with the final product being a Plus 1 (or Slogger Rombox) cartridge-based add-on built on a professional single PCB so I’ll design the PCB, canvass interest on here and then procure an appropriate number of boards. I should say at this early stage that it is not my intention to offer fully assembled units, just PCB’s so there’ll have to be some support from solder-savvy forum members if there’s a lot of interest.

Below is a photo of the complete and fully functional prototype – it might look a little Heath-Robinson but hey, it works just fine as advertised. The odd two-part construction is because I didn’t have any suitable edge connector development board to hand and I was too lazy & impatient to start hunting some down so I took advantage of a left-over Pegasus PCB which was otherwise unusable due to its being littered with track manufacture faults. There were several of these which really were beyond reasonable recovery but whose edge connectors are ok so I could isolate the latter and then parasitically pick up the required cartridge interface connections.
EUP fitted.JPG
EUP fitted.JPG (51.11 KiB) Viewed 3133 times
EUP not fitted.JPG
EUP not fitted.JPG (60.46 KiB) Viewed 3133 times
The schematics for the 6522 and rom/ram aspects are shown below. For the 6522, the circuitry is fairly standard in terms of NPGFC clean-up and address decoding to $FCBx but there is some clock trickery going on in the centre.
EUP(2).png
EUP(2).png (38.43 KiB) Viewed 3133 times
EUP(2a).png
EUP(2a).png (10.42 KiB) Viewed 3133 times
It is possible (and I’ve seen it done) to have a minimalist design which simply clocks and selects the VIA using the Elk’s phi2 unmodified and this will basically work. However, this method, whilst providing 6522 transactions at 1MHz through the Elk’s inherent clock-stretching, actually clocks the VIA internal timers at (mostly) 2MHz which is double the Beeb rate and would limit compatibility with the latter. The next obvious route would be to simply divide phi2 by 2 and use this to clock the chip and, whilst this gives a nominal 1MHz clock for the VIA timers, the persistent and regular clock-stretching which takes place in an Elk even when the VIA is not being accessed, means that timer accuracy is adversely affected and this again reduces Beeb compatibility. Thus, after a multitude of experimental designs, I have settled on a system which very accurately clocks the 6522 at 1MHz when it is dormant to allow maximum timer accuracy but also provides Elk-compatible 1MHz read/write transactions during VIA access.

Basically, I use a 393 to divide the fixed 16MHz clock by 16 and then multiplex this clock with Elk phi2 to the VIA clock input, the active source depending on whether the 6522 is being accessed or is dormant. The simple clock-switch I have used can be prone to glitches during transition but these are eradicated during phi2_to_1MHz by my resetting the 393 during VIA access and the 1MHz_to_phi2 glitches only occur, if at all, during reads. Should such a glitch occur, it is always outside of the 6522 active CS period and in fact, if one were ‘seen’ by the VIA it would simply increment by the internal timers by a count of 1 which actually compensates for the one lost ‘tick’ during a stretched-clock access. Either way, not an issue 8)

For the interest of those who care, I’ve added some annotated scope shots to illustrate some of the above design points.
clock at C2.PNG
clock at C2.PNG (7.75 KiB) Viewed 3133 times
example switched clock access.PNG
example switched clock access.PNG (7.93 KiB) Viewed 3133 times
example glitch.PNG
example glitch.PNG (7.8 KiB) Viewed 3109 times
(Apologies to Daniel btw - I didn't intend to undermine your project but I was desperate to get UPURS onto the Elk! In deference to your gadget though, I did stay away from a '1MHz Bus' interface :wink:)

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by davidb » Fri Jun 08, 2012 11:48 pm

It looks very promising! I've been hoping to make progress on a simple ROM cartridge board of my own, but it's the usual story of trying to do too many projects at once.

Perhaps naively, I wanted to use flash memory in place of ROMs. What are the chances of having these devices working on the board?

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Electron User Port & Rom/Ram board

Post by paulv » Sat Jun 09, 2012 1:19 am

MartinB wrote:Looking good for Elk hardware add-ons of late
Looking good indeed, a second processor that should make the Elk a much faster proposition and a user port expansion with 2 user ports and a 32K ROM socket :D I've now got the need for more expansion slots than the Plus 1 provides as I've already got a Peg400 board taking up one slot... :evil: What to do, what to do...
MartinB wrote:I should point out that despite my initial resistance, I was cajoled into a ‘proper’ interface by my erstwhile UPURS support team of Paul, t’other Martin and Hugh
Hopefully for good reason :D I should explain that Martin's original solution was very elegant and quite straightforward using the printer port on the Plus 1, but we all felt that people would probably not want to implement it as it required a track cut and some soldering on the Plus 1 board itself. Whilst this was a transparent change leaving the printer port functional as a printer port, we all convinced Martin it was a step too far for most people when making the mod.

Given all the effort our cajoling led too I sincerely hope our original reaction to making the mod in that way was the right one. Either way, the community gets to benefit from a dual User Port/ROM Elk expansion, hmmm... I believe Dupree is a name in some parts of the world.... :twisted:
MartinB wrote:I should say at this early stage that it is not my intention to offer fully assembled units, just PCB’s so there’ll have to be some support from solder-savvy forum members if there’s a lot of interest.
I for one would be happy to help out with the solder work. As I don't do it that often I find it therapeutic although at the moment, the thought of making up multiple VIDC Enhancers makes me wonder if it'll still feel therapeutic after the first two or three...
MartinB wrote: - Technical Info and screenshots -
Martin, I couldn't hope to fully understand everything that you cover in your post here. As I've been privy to your intermediate thoughts via e-mails and I've tried to understand as much as I can in both those mails and this post. What I can say is that I know enough to appreciate how tricky the Elk clock can be so all I can say right now is GREAT WORK =D> =D>

Can't wait to see the board layout :D

Paul

User avatar
retroclinic
Posts: 3022
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Electron User Port & Rom/Ram board

Post by retroclinic » Sat Jun 09, 2012 10:42 am

Hi Martin.

Good work there. Just a suggestion - put the 9 pin serial connector and any other components the cables has on the main board as well as the user port connector, that way you've pre-built the cable into your hardware, so anyone just needs to plug the serial cable directly into it.

Mark.
Image

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sat Jun 09, 2012 1:24 pm

Thanks as ever for the encouragement Paul :D

David - I guess you're looking at an NVRAM capability? I have previously used various Maxim devices but they're internally battery-backed and not true flash ram. I've seen references to FRAM chips on here and I think Mark H has some experience with such devices but I recall folk implying that they're prone to corruption in retro-applications? Maybe Mark can shed some light for me.... :wink:

I had actually already proposed off-line the possibility of my including battery back-up via a trickle-charged cell as per a multitude of other applications, but this will depend on my having the real-estate on the PCB :-k

Mark - Thanks for the input, that's actually not a bad idea. I did originally move from a Plus 1 mod to a bespoke UPURS interface (which didn't use a 6522) but finally settled on the generic VIA-based User Ports as described. In truth, I didn't want it to look like I was pushing UPURS on folk but I guess your suggestion would be a good half-way house in that you still get the generic User Port but have a very straighforward option on UPURS :-k

I wonder then, would people still want to have two User Ports and an UPURS connector or should I just totally commit one port to UPURS so that we have one 20-Way IDC (standard User Port) connector and one 9-Way D-Type (UPURS) connector? I guess there shouldn't be an issue with having all three (again apart from PCB real-estate) other than the fact that one port would have clipping diodes permanently sitting across a couple of the Data I/O lines.

Thoughts anyone?

User avatar
Advance
Posts: 362
Joined: Fri Jan 29, 2010 5:22 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by Advance » Sat Jun 09, 2012 2:09 pm

Excellent news Martin, that's a major milestone passed although you wouldn't think so given the poor response here which has greeted it.

Mark's idea is a very sound one in my opinion and hopefully you'll get more interest and suggestions. I wouldn't be too sensitive about UPURS. First of all, you don't make any money from it and, secondly, the Elk project grew directly from UPURS and I for one see it as a continuation of that valuable work.

I've re-sent that email as you requested.

Hugh

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by davidb » Sat Jun 09, 2012 3:33 pm

MartinB wrote:David - I guess you're looking at an NVRAM capability? I have previously used various Maxim devices but they're internally battery-backed and not true flash ram.
Actually, I was looking at the 29F010 part as a straightforward ROM/EPROM replacement, possibly with some kind of page selection since it can hold up to 128K of data.

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sat Jun 09, 2012 3:54 pm

Thanks Hugh, I guess these things either tickle one's fancy or they just don't :wink:

David - Ah, ok, it was capacity you were looking at too. The initial problem with these devices as legacy replacements is that they are 32-pin devices as opposed to the 28-pin packages we are used to. That doesn't prevent them from being used on a purpose-built board but they would be tricky to cater for as free-fit alternatives without (a) fitting a 32-pin socket and (b) because the high-order address lines get a little jumbled when compared to a 28-pin package, there would likely have to be a few movable links involved.

Beyond that, a closer study of the relative timing dependancies would be needed to ensure that the requirements could be met by legacy 8-bit architecture. They are also 'semi-intelligent' devices that have to be written and erased through a resident command set rather than by direct addressing so a little software would be needed to 'drive' their initial and subsequent configuring. Reading would be more straightforward but you'd still need some sort of page select circuitry to present the device as multiple roms.

All entirely doable I suspect but in the context of my topic board, I think it would be a little stretching.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by davidb » Sat Jun 09, 2012 4:08 pm

Yes, it was capacity I was partly interested in, and just having something that could potentially be used with the legacy hardware. Also, I had the idea that it might be easier to use the command set to erase/write them than get a dedicated programming device for that.

Anyway, I'll get back to that at some point, I hope. In the meantime, I'll be keeping an eye on developments here. :)

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Electron User Port & Rom/Ram board

Post by paulv » Sat Jun 09, 2012 6:12 pm

I vote for making one of the user ports into a UPURS port. It makes a lot of sense to provide the 9-pin serial port on the board and a single user port too and for Elk users that don't have a Beeb with UPURS already, it makes for an all in one solution :D

Paul

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

Re: Electron User Port & Rom/Ram board

Post by 1024MAK » Sat Jun 09, 2012 8:11 pm

Well done Martin B. =D>

Interest, hell yes :!: Once you have the PCB sorted I will want at least one, but more than likely two.

If there is space on the PCB I would prefer two user port IDC connectors plus the 9-way D connector. However if there is a lack of room and you can only include one user port IDC connector, can you route as many I/O lines to the 9-way D connector as possible (I realise that some pins cannot be used as I presume Mark's idea was the people can use "off the shelf" "standard 9 pin serial" cables).
Or maybe route the spare I/O lines to a simple pin header.

I would forget about having a rechargeable battery on board. If there is space a better idea would be to use a 3V Lithium coin cell holder and cell. The cell should be protected by a diode and a "emergency current limiting" resistor (in case of diode failure).
For example this is what Rapid have:
Coin cell holders - Keystone
20mm Single Vertical Holder
Energizer Lithium Coin Cell Batteries
Uniross Lithium coin cells

On the subject of FLASH memory, I understand from others (but have not researched it myself) that some types can be used as a plug in replacement for EPROMs. Of course you cannot program / write to them on the target board. They would still have to programmed in a programmer (does cut out the UV cycle though).
I believe that most FLASH memory has to be written in blocks, the block size depending on the actual type of FLASH chip used.

Mark K.

P.S. do you intend publishing the mod that can be carried out to a Plus 1, only I have killed one output line of the printer port on one of mine so have to open it any way to change the LS TTL chip (and I have no problem with track cutting, kinda a required skill when PCB's were designed and made by hand years ago before computers made it easy-ish :mrgreen: {not that I would know :oops: } ).

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

Re: Electron User Port & Rom/Ram board

Post by jms2 » Sat Jun 09, 2012 8:37 pm

Looks superb Martin - and quite scary at the moment with all those wires!

So far I've tended to ignore UPURS because I have a nice old PC with a floppy drive and Omniflop, and this works fine for me. However being able to use UPURS on BBC or Electron certainly makes it a more interesting proposition...

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sat Jun 09, 2012 9:29 pm

Thanks for the feedback everyone :D

Given that there's already a difference in opinion about port options, I'll probably therefore aim at two standard User Port connectors and a UPURS 9-way D-Type socket. I've just done some tests and the presence of the diodes have no adverse effect on the characteristics of the standard User Port. I was only trying to keep the board size down to minimise unit PCB cost but I doubt we're talking big bucks and a third connector will only equate to a small delta. The slight increase in board size will probably sit well with the addition of a battery anyway.

Mark K - Thanks for the battery thoughts, I think you're probably right in that a vertically mounted button cell may well be the optimal solution. Regarding the Plus 1 mod, I had only taken it as far as enabling one programmable input line and one programmable output line. My initial focus at that time was simply to show that UPCFS was viable on the Elk and whilst it would also have supported either UPSSD/UPDSD or UPXSSD/UPXDSD, it wasn't a full 8-bit bi-di port mod. If this very basic functionality is of any use to you I can supply the details but given that we now have a full (twin) User Port solution on the horizon, maybe it's not really worth the effort?
Mark K wrote:Interest, hell yes :!: Once you have the PCB sorted I will want at least one, but more than likely two.
That's what I like to hear :D
John wrote:...and quite scary at the moment with all those wires!
My exact off-line phrase to Paul and company! Thing is, even though the schematic looks relatively simple, just one single rom socket requires most of the address bus and all of the data bus - 23 wires before you start :shock:. Despite appearances, the good thing about high density multi-strand PVC wire construction is that it's incredibly robust. The whole assembly has been roughly handled (no exaggeration) for weeks and weeks as I repeatedly tried different designs and configurations and not a single wire has ever broken or become detached :D
and wrote:So far I've tended to ignore UPURS...
How very dare you... [-(

Lol, the board is not intended to be exclusively UPURS. Indeed, I keep looking at all the tasty Beeb User Port add-ons I have lying around and would love to see which could be made to work on an Elk :wink:

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sat Jun 09, 2012 10:47 pm

Since I've already got the scope shots, I'll provide a little more detail on the VIA clocking issue...

The shot below shows the Elk native phi2 in yellow and in blue is the 1MHz clock produced from the 393 by dividing down from 16MHz. It can clearly be seen that even when the Elk is not accessing the VIA, phi2 is being regularly stretched to >1us as the Elk ULA goes about it's routine housekeeping. Thus, if we were to divide phi2 by 2 and use this to clock the VIA in the background, at regular intervals we would lose at least one 'tick' of the 6522 counters typically producing a +15% error.
phi2 versus 1MHz.PNG
phi2 versus 1MHz.PNG (8.92 KiB) Viewed 2955 times
To visualise the need for accuracy, the 6522 can be programmed to automatically countdown and toggle PB7 (output data bit 7) when the counter reaches zero. Once activated, this process will continue ad-infinitum without any further intervention by the CPU. For example, if we run the code below just once on the Elk (with a 6522 fitted of course :wink:) or on a Beeb (with $FCBx changed to $FE6x), PB7 will start to toggle at the slowest possible rate.

Code: Select all

10 ?&FCB2=&FF:?&FCBE=&7F:?&FCBB=&C0
20 ?&FCB6=&FF:?&FCB7=&FF
30 ?&FCB4=&FF:?&FCB5=&FF
The code sets the countdown timer to $FFFF which is 65535 decimal and this equates to 65536us or 65.536ms when 'ticking' at 1MHz. The scope shot below shows this function in action when used with my board. Of note here is that if we used a design where the VIA was clocked via a phi2 derivative, the 65.6ms 'pulse' shown could erroneously extend, potentially by as much as 10ms.
Max time interval (65ms).PNG
Max time interval (65ms).PNG (7.28 KiB) Viewed 2955 times
Finally, during development I found that the most reliable performance test to prove correct access and functionality of the 6522 was to directly ROL an output register since this requires back-to-back reads & writes to the VIA on consecutive CPU cycles. Thus, using the following code...

Code: Select all

SEI
LDA#&FF
STA&FCB2
LDA#&55
STA&FCB0
SEC
.loop
ROL&FCB0
JMP loop
We should see the following output (blue) on PB7...
ROL the port.PNG
ROL the port.PNG (7.56 KiB) Viewed 2955 times
It was immediately apparent during development if anything was amiss with 6522 access timing because this test would fall over and there would corruptions (missed transitions) of the 110101010 repetetive pattern.

(Curiously, I found that one out of the 4 random Beebs I was using for reference measurements showed transition corruptions during the equivalent test even though the port nominally functioned ok - not investigated that yet, maybe a noisy 1MHz clock or sub-standard 6522 on that particular unit :-k)

User avatar
retroclinic
Posts: 3022
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Electron User Port & Rom/Ram board

Post by retroclinic » Sat Jun 09, 2012 11:31 pm

MartinB wrote:....Thing is, even though the schematic looks relatively simple, just one single rom socket requires most of the address bus and all of the data bus - 23 wires before you start :shock:. Despite appearances, the good thing about high density multi-strand PVC wire construction is that it's incredibly robust. The whole assembly has been roughly handled (no exaggeration) for weeks and weeks as I repeatedly tried different designs and configurations and not a single wire has ever broken or become detached.....
Have you still not warmed to the idea of using a CPLD? Doing so would mean you only have to wire things once, then any changes to gates, timings etc can be done with a simple code change, upload and it's there.

Mark.
Image

User avatar
mga1103
Posts: 184
Joined: Mon Jan 24, 2011 4:00 pm
Location: Galway, Ireland
Contact:

Re: Electron User Port & Rom/Ram board

Post by mga1103 » Sat Jun 09, 2012 11:46 pm

It's great to see this make it to the wider audience. A really fantastic piece of work, and of course, your detailed posts are as informative as ever. Well done, Sir! =D>

Roll on the PCB's...(...I'm probably stating the obvious here, but put me down for one two units!)

Thanks again for your huge effort and dedication.

-Martin.

User avatar
Slo
Posts: 413
Joined: Sun Mar 20, 2011 11:02 am
Location: Worksop Notts
Contact:

Re: Electron User Port & Rom/Ram board

Post by Slo » Sun Jun 10, 2012 9:34 am

Oh WOW! The man has done it again, talk about skills - very impressive, I shall definately be following this/wanting a couple of these pcb's/kits/anything at the end of it.

Excellent work Martin =D>

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sun Jun 10, 2012 8:40 pm

Cheers t'other Martin :wink:
Slo wrote:The man has done it again, talk about skills - very impressive
Thanks Andy but to be honest, it's not really a complex example of it's kind, especially if you 'do' this stuff. I think the real 'skill' is just getting off one's fat crack and making the effort to see these things through to completion. I'm fortunate in that respect because I have my enthusiastic UPURS back-room boys to spur me on :D (In the constant "are we there yet?" sense :wink:)

Mark - Despite my apparent resistance, I don't dislike CPLD per se, I just prefer not to use it in the context of these forum projects. Firstly, I really do prefer the authentic look of a handful of discrete IC's on a retro add-on and secondly, using CPLD immediately prevents 99% of hobbyists from just taking the schematic and building their own - simply, programmable logic tends to force a dependancy on the author.

In this case, a CPLD wouldn't reduce the bulk of the wiring which is mostly accounted for by the data and address bus connections. True, an appropriate programmable device would probably replace the five discrete IC's but there wasn't really a huge amount of work involved with those, it was the two 'big' chips that took most of the time :roll:

Perhaps perversely, one of the interesting challenges for me was keeping the support chip count down to five because (and I'm surprised Alan D hasn't been on to say so :wink:), the Acorn recommended way for Elk expansion is always to 're-build' a synchronous 1MHz clock. Trouble is, their clock regeneration uses 3-4 chips before we start on the main circuitry and so in this case, I wanted to find a simpler method using a pseudo-synchronous clock and hence requiring fewer chips. All good fun :D

User avatar
AlanD
Posts: 241
Joined: Fri Jan 09, 2009 8:30 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by AlanD » Sun Jun 10, 2012 10:36 pm

Hello Martin

i take it the signal you have called phi2 is actually the Phi1 signal on the plus one cart connector
this clock rises and fall about 64 - 125 ns to early to use for decoding see the 6502 datasheet
(this is why so many old elk plugin dodads had an rc delay on this line)
effects it will make the system unreliable for reading the addressed device although writing will be fine
it needs to be delayed by about around 64 - 125 ns i think

something along these lines a couple of d-types to delay the clock
elk phi delay to phi2.png
elk phi delay to phi2.png (3.41 KiB) Viewed 2865 times

AlanD

PS i see you noticed the elk clock stopping take a look at how long it happens for in mode 0,1,2
the worst one takes the RAM offline for 40us out of every 64us


CPLD is still the best solution but thats only my humble opinion :-)

User avatar
danielj
Posts: 6688
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Electron User Port & Rom/Ram board

Post by danielj » Mon Jun 11, 2012 7:52 am

MartinB wrote: (Apologies to Daniel btw - I didn't intend to undermine your project but I was desperate to get UPURS onto the Elk! In deference to your gadget though, I did stay away from a '1MHz Bus' interface :wink:)
Good work! :D - absolutely no worries, I've been utterly snowed under with new job so all interesting projects have been back-burnered at the moment. It will re-emerge soonish I hope... I'm liking the pictures :)

d.

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Mon Jun 11, 2012 4:51 pm

Hi Alan, nice to hear from you :D
Alan wrote:i take it the signal you have called phi2 is actually the Phi1 signal on the plus one cart connector
:shock: According to all the tech info I have (e.g. the Elk Cart App Note), A8 is Phi2. I am aware that Phi1 would need tweaking but surely it would be a bit stange of Acorn to distribute Phi1 in a system? The signal from A8 certainly looks and behaves like Phi2 and reads work just as well as writes. What makes you think it's Phi1 :-k

Ok Daniel and thanks for the encouragement :D

User avatar
AlanD
Posts: 241
Joined: Fri Jan 09, 2009 8:30 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by AlanD » Mon Jun 11, 2012 6:37 pm

Hello Martin

good to see someones still playing with elk

on the ELK schematic pin37 of the 6502 (PHi1) comes out on the rear edge connector pin14
in the plus one schematic it shows this tracked straight through to pin A8 on the cart slots

I have buzzed this out and followed the track and it really is PHi1 that comes out of the cart.
Congratulations You have now found one of the mistakes on app note 14 ,
it says it is phi2 but on the electron this is not true.

'it is phi1 on the Electron.'
'it is phi2 on the Master.'
this potentially presents a headache for a unversal elk/master cart.

i discovered this the hard way .It manifests itself in really unpredictable and unrepeatable ways.

Also you could just buzz pin 37 on the 6502 to cart A8 and this will reveal itself to be true.

hope this helps

ATB

AlanD

P.S.
As it is working at the moment i suspect you must have carefully crafted you layout in you prototype
to delay the clock just enough :-)

User avatar
danielj
Posts: 6688
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Electron User Port & Rom/Ram board

Post by danielj » Mon Jun 11, 2012 7:07 pm

AlanD wrote: I have buzzed this out and followed the track and it really is PHi1 that comes out of the cart.
Congratulations You have now found one of the mistakes on app note 14 ,
it says it is phi2 but on the electron this is not true.
Suddenly some strange behaviours of my enamel wired beauty make sense, as do some of the design decisions made in the AP5!

d.

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

Re: Electron User Port & Rom/Ram board

Post by 1024MAK » Mon Jun 11, 2012 7:32 pm

AlanD wrote:on the ELK schematic pin37 of the 6502 (PHi1) comes out on the rear edge connector pin14
in the plus one schematic it shows this tracked straight through to pin A8 on the cart slots
I have buzzed this out and followed the track and it really is PHi1 that comes out of the cart.
Congratulations You have now found one of the mistakes on app note 14 ,
it says it is phi2 but on the electron this is not true.
'it is phi1 on the Electron.'
'it is phi2 on the Master.'
this potentially presents a headache for a unversal elk/master cart.
So does this mean carts that need this "clock" signal and which are intended to work in either machine will need a user selectable (eg pin header type jumper or DIP switch) to select a bit of logic to "delay" or "not delay" the available signal (with the slight problem that every logic gate delays the signal a little more)?

Mark K.

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Mon Jun 11, 2012 8:40 pm

Alan wrote:I have buzzed this out and followed the track and it really is PHi1 that comes out of the cart.
Good enough for me :D
and wrote:I suspect you must have carefully crafted you layout in you prototype to delay the clock just enough :)
I use it through a single gate for VIA CS1 and that would be fine with Phi 1 or 2. For the VIA clock, Elk Phi1 (as we now know it) passess through 4 gates before hitting the 6522. These won't add anything like the 64-125ns you suggest but seemingly it's enough. There's one spare AND gate left so it can have that too and I'll do some more read-intense testing just to be sure. (I'm away at the moment so it won't be tonight.) Thanks for pointing this out though Alan :D

@ jms2 : John, you need to update your Elk AUG Iss.2 again.... :wink:

@ Mark K : Technically yes if the cart uses Phi (they don't all of course) but most Master stuff would probably be perfectly ok with an extra handful of nanoseconds.

User avatar
AlanD
Posts: 241
Joined: Fri Jan 09, 2009 8:30 pm
Contact:

Re: Electron User Port & Rom/Ram board

Post by AlanD » Mon Jun 11, 2012 9:08 pm

Hello Martin

At least you are now aware it is phi1 on cart A8 if you start getting problems when you go to a PCB or different batches of logic chips.

Myself I would fix it with flip flops and syncronously delay the clock or you could just add an R & C to delay the clock a little, this is the approach most plug ins used back in the day.
Untitled.png
Untitled.png (26 KiB) Viewed 2731 times
how many Elk thingys have we seen this on a clock or select line?


i really think this was a mistake on Acorn's Part why they bought out Phi1 to the edge connector instead of Phi2 is anyones guess.

ATB

AlanD

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Wed Jun 13, 2012 7:16 pm

Hi again Alan and thanks for the info :)

Sorry, just returned from 'away' so not had chance to look any further into the Phi_n issue but will do so as soon as I can. Almost unbelievable that Acorn should goof in this way but as you say, the fact that so many third-party add-ons have employed a CR delay is very telling. I'll do some scope checks and see how content the 6522 is with my configuration. If further delay is necessary, I may go for a simple CR myself if since it's easy enough to re-sharpen the clock with an LS gate after said delay.

We shall see... :wink:

EDIT : Would you expect the test I've been using where I directly and repeatedly ROL the output register (code above) to work so reliably (it does, 100% with Rockwell, Synertek and MOS VIA's) if there was a read issue? At low level, it performs a read and a write on successive cycles and at great iterative speed so it ought to fail at least occasionally if there were any marginal read issue? :-k

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sun Jul 29, 2012 7:56 pm

Definitely not forgotten about, I've just returned to this project after an enforced break and to catch-up, I first repeated all my previous testing where sure enough, it all works fine as before. However, as we were discussing before the break, when I originally schemed this I was assuming that I was dealing with phi2 and not the CPU raw clock - an Acorn Elk design flaw to which Alan D has duly enlightened us all =D>. So, even though everything currently works as designed, it could well be on the timing edge for different configurations and hence for robustness I've added a CR delay on top of that already provided by the existing gates. Using a CR slug means I don't need another chip and by using a spare AND gate to 'sandwich' the discretes, the clock is kept clean and sharp.
EUP(3).png
EUP(3).png (18.2 KiB) Viewed 2570 times
For visualisation, the scope shots below show the delay provided by the CR plus one gate (~70ns) and the total delay between original phi and delayed 'phi2' as supplied to the 6522 (~90ns).
phi CR delay.PNG
phi CR delay.PNG (7.83 KiB) Viewed 2570 times
phi CR + gates delay.PNG
phi CR + gates delay.PNG (7.64 KiB) Viewed 2570 times

User avatar
MartinB
Posts: 5024
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Electron User Port & Rom/Ram board

Post by MartinB » Sun Aug 12, 2012 9:21 pm

For the BeebSID PCB, I used DipTrace but after playing with a few different packages I think I'd be better to conform in the future and use Eagle. To that end, does anyone have a 65xx component library? (For this project I obviously only need a DIP 6522 but for the future who knows :wink:)

Also, how does one do the edge connector for an Elk catridge-style board? Is it just a case of manually laying out the strip connections to the right size and with the right spacing or again, does someone have something ready-made? When having such a PCB made, are these edge connections just left as bare copper or specified as tinned or something else....?

Any help welcome :)

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

Re: Electron User Port & Rom/Ram board

Post by 1024MAK » Sun Aug 12, 2012 10:31 pm

Edge connectors should at the very least be "tinned".
Better still is gold plated. But this does push the price up a bit.

I have never produced my own edge connectors. However you may find this interesting Exposed_conductor_plating_and_coating.

Mark K.

Post Reply