Rob Napier's Acorn Computers Biography: VOICES FROM A FUTURE PASSED
VOICES FROM A FUTURE PASSEDHow the BBC, Acorn Computers & the ARM chip changed the world.
This is what happened when a group of really clever people found themselves in the right place
at the right time, and had the courage to take advantage of opportunities.


For an introduction to the book, more details of the campaign to donate part of each sale to your
favourite computer or technology museum and for pre-order details, please visit www.doitonce.net.au.
Publication planned for early March

65816 + DE0Nano + Tube project notes

discuss both original and modern hardware for the bbc micro/electron
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

65816 + DE0Nano + Tube project notes

Post by dominicbeesley »

I'm about to start experimenting with my own tube stuff - much inspired by reading through most of the matchbox mega-thread.

A quick stupid question before I start. I'd like to install my own TUBE software at the beeb end...is there a way to stop the tube software detecting the co-pro at boot. How does it detect it?

I'm guessing it senses a +5v on one of the pins? I'm using a DE0 nano as my starting point through a JK tube silencer.

I know I could hack/remove the DFS ROM but I'd like a way of doing this without constantly bending the pins on my ROMS...

Cheers

D
Last edited by dominicbeesley on Sun Sep 13, 2015 1:07 am, edited 1 time in total.
mm67
Posts: 138
Joined: Tue Feb 28, 2006 4:44 pm
Location: Derbyshire, England
Contact:

Re: Tube detect code

Post by mm67 »

The OS detects the 2nd proc, and issues service call &FF.

Search for "tube" in JGH's disassembly: http://mdfs.net/Docs/Comp/BBC/OS1-20/D940
mm67
User avatar
jgharston
Posts: 6197
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield

Re: Tube detect code

Post by jgharston »

dominicbeesley wrote:A quick stupid question before I start. I'd like to install my own TUBE software at the beeb end...is there a way to stop the tube software detecting the co-pro at boot. How does it detect it?
The usual way is when Service 1 goes past change the TubePresent OSBYTE variable to 'absent':

Code: Select all

.Service1
PHA:LDA #0:STA &27A:PLA:RTS
This is also the way most *TUBEON/*TUBEOFF commands work.
Edit: The Master only sends Service 1 on Ctrl-Break, so you should do it on Service &25, which appears to be the only call that's constantly made before ob Hard/Soft Reset and before any Tube calls are made.
Edit: Edit: But the Master has *CONFIG. TUBE/NOTUBE, so you don't need that anyway. ;)

At a hardware level there is a 'disabled' link on most CoPro boards.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
User avatar
hoglet
Posts: 13355
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube detect code

Post by hoglet »

A low-level answer to your question is that the Tube code in the OS reads the first tube register at FEE0. If the Tube is not present this with return 0xFE. If it is present, then bit 0 will be '1'. This is I think what the Tube code looks for.

I had to fake this in ICE-T65 otherwise the Beeb just hung.

Once the tube is detected, it will wait indefinitely for the Co Pro to send the startup message, terminated by 0x00.

Dave
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Thanks everyone,

It was the electrical side of things that was puzzling me.

I was asking as I'd plugged in the de0nano unpowered and it hangs or with just the tube silencer it prints a few garbage characters and then hangs.

A CTRL break does the same but a warm reset prints rubbish then either hangs or prints the Acorn DFS / BBC Basic banner then hangs.

With a powered DE0 it works fine and I can disable it with a jumper as per the manual.

Funnily the DE0 will not start up on host power but will happily continue after the parasite power is removed...

So it looks like the tube silencer is holding D[0] high? It would be nice to have a schematic for the silencer to see if I could somehow fix this...

I've not got *TUBEON/OFF commands on my BBC B. I'm still not sure which Tube ROM I should be using. I'm using a superMMC for storage at the moment. I'm half tempted to dig out my master which has a hard JGH hard drive it's just me desk is already full!

I'm going to have a go at playing with this on the DE0 nano. I've been inspired by the matchbox thing, I've been trawling through the code and there looks to be quite a bit that is Spartan Specific (i.e. FIFOs) and plenty that I don't understand (Verilog! and timing constraints) so I will no doubt get stuck fairly quickly.

Next up I've ordered a load of parts to make up a simple co-pro board which will consist a 65816 two 128k SRAM chips a Flash RAM and some level shifters to connect to JP1 of the nano. Then I'll use the nano to do chipselect, clocks etc of the co pro and my own attempt at the ULA - no doubt I'll end up cribbing a lot from the matchbox.

Anyway should be a good learning experience.

My other experiment of a 65816 straight into the 6502 socket is on hold for now...I've sort of got it working but it is very unreliable. I suspect this is due to noise/ground bounce/timing issues....the board is a mess of home-made PLCC to DIP daughter boards and wirewrap. I'm carefully starting to read through pages 23 onwards to see how you lads got the matchbox to be more reliable.

Thanks again and well done to hoglet and JGH on the whole epic Matchbox voyage...

D
User avatar
hoglet
Posts: 13355
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube detect code

Post by hoglet »

dominicbeesley wrote: So it looks like the tube silencer is holding D[0] high? It would be nice to have a schematic for the silencer to see if I could somehow fix this...
It's a weak aspect of the design by Acorn. The reason the default value is FE is because of stray capacitance. i.e. The final byte of the instruction that reads the value is FE, and this just hangs around on the data bus when nothing else is there to drive them. The tube silencer uses 74LVC4245A level shifers (as does the LX9 Matchbox board. I suspect when un-powered, these are leaking just enough current to act as weak pull-ups. A possible work around would be to hack the board to put a switch in data line D0.
dominicbeesley wrote: Thanks again and well done to hoglet and JGH on the whole epic Matchbox voyage...
And don't forget Jason (flynnjs) who designed the LX9 board, and then laboriously built up the ones everyone is using. =D> =D> =D>

And all this wouldn't be possible at all with the folk who re-implemented the CPU cores and chose to open source their work. =D> =D> =D>

Dave
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Sorry, yes and Jason...

I think I have a way to go to catch any of you guys up...its taken me the past half hour to not get the LEDs on my DE0 nano to turn on and off...I do hate Quartus.

The FE thing makes perfect sense now...I do love the way that Acorn do so many things properly (OS etc) and then do such carefree overloading of the poor databus...poor thing - no wonder none of my designs works, nothing to do with my stupidity, honest!

D
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Well, after a lot of messing around I have some sort of progress on my own DE0nano/TUBE experiments.
DSC_0315-s.JPG
So far it is a T65 core and my own attempt at a TUBE - so far only reg1.

It's taken me a lot of messing around to get this far, I got "something" working almost immediately which ran in the simulator fine but had missing letters from the banner when fired up for real.

Turns out it was the 2MHz clock from the beeb must have some nasties on the rising edges - I was using the 2MHz clock to run everything including the parasite cpu. As soon as I switched to a 5MHz on clock derived from the on board 50MHz one it worked. Looks like my VHDL was ok all along...

Now to implement the other registers...I shall be cribbing from the Matchbox code no doubt though I'll probably use an opencore fifo.

I made my own 1 deep reg1 which consists of a single register protected by a "flancter"....

Time for bed.

D
You must be logged into view and download the files attached to this post.
User avatar
1024MAK
Posts: 14342
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Tube detect code

Post by 1024MAK »

Making progress... =D>

Keep going :D

Mark
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Cheers Mark,

I've quickly implemented all the other registers and now have a more or less functioning copro.

I'm still having a few problems with loading/saving basic programs. Sometimes loading twice works with "bad program" the first time then ok the second. Sometimes not. That might be due to R3 being only 1 byte deep but I thought that that was just for econet stuff....I shall have to do a bit of digging to see what is going wrong. I've just spotted that R3 transfers also need to meet timing requirements so maybe it's this client rom that needs a tweak...

I've tried it at a variety of different speeds. 50MHz seems to be about the limit for reliable operation.
DSC_0316-s.JPG
Mandelbrot set is still taking about 40 minutes...
DSC_0320-s.JPG
But at least its not crashing...
You must be logged into view and download the files attached to this post.
User avatar
hoglet
Posts: 13355
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube detect code

Post by hoglet »

Hi Dominic,

Excellent progress =D> =D> =D> =D> =D> =D> =D> =D> =D>

Things that caused unreliability in the some of the Matchbox Co Pro designs were:
1 - incorrect synchronization of FIFO flag logic between the two clock domains
2 - neglecting to synchronize IRQ and NMI (for some CPUs, I forget which)
3 - the NMI routine being marginally too slow
4 - insufficient decoupling

How are you tacking (1)?

Dave
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Thanks Dave,

I'm using a "flancter" that gets set at the end of the write to the "fifo" - they're all just single registers at the moment. It _should_ be ok across clock domains but after I've fed the family I'll try putting a 1 cycle delay in the available flag and see if that fixes it. I've yet to work out how to make the flancter not cause a shed-load of failing paths in the timing analyzer - I have to admit that that is a black art to me!

The NMI routine is standard and the same problems present themselves at all clock speeds though seem to be "least bad" in the 2MHz-5MHz range.

I'll have a look at NMI and IRQ too - at present they're not synchronised at all.
User avatar
hoglet
Posts: 13355
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube detect code

Post by hoglet »

For anyone wondering what a Flancter is, here are the gory details:
http://www.floobydust.com/flancter/Flan ... p_Note.pdf
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Thanks Dave, you seem to have nailed it with point 1.

I just added a quick-n-dirty one clock delay on the full and available signals and that seems to have fixed it. I can now load, save and play Elite.

Tomorrow, I'll be starting on the second part of the project and make a 65816 process, ram and rom board to plug into the other end of the nano...would be easier if I could just find a 65816 core but so far I've not found a complete one. And its about time I got the soldering iron out.

D
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Here's my attempt at a copro board. It's a bit of a cheat as the idea is to have the nano's fpga do a load of the ancillary stuff like address decoding and other stuff and clock production etc..

Its taken a lot more routing and faffing due to all the level shifting and so is a bit of a mess...there's a lot of vias to drill and solder...

Can anyone see a fatal flaw in my plan? I'm going to print it out and double check it this afternoon...
You must be logged into view and download the files attached to this post.
User avatar
1024MAK
Posts: 14342
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Tube detect code

Post by 1024MAK »

From your comments, I'm guessing this is going to be a DIY home made board.

If you were going to have it professionally made, a lot of the vias could be replaced with connections to through hole plated component holes... But if you are etching your own board and using IC sockets, soldering the top side is tricky.

Myself, I would fill unused space as ground areas as much as possible.

Bit difficult to check the details on a iPad mini :?
If I have time later tonight, I will have a look on my PC.

Not that I think it will help much here, but with SRAM chips, you can connect any CPU data line to any SRAM chip data pin, same with the address pins. As long they all get connected up of course :mrgreen:

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

Re: Tube detect code

Post by 1024MAK »

Which side is your Tube connector going on? Only all the connecting tracks are on the component side.

Mark
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Thanks for taking a look Mark,

I'll fill in ground / power zones when I've double checked everything and probably add a few extra vias between top and bottom ground planes.

As you guessed, I added most of my vias to avoid soldering both sides around the through hole pins - I've done it in the past but its a bit bodgy and usually ends up with melted ic sockets.

Good point about the D and A lines - luckily everything lined up more or less ok.

The 2x20 way connector is to go on the back of the board and should plug straight into the other side of the de0nano to the tube silencer...I even remembered to leave room for the screws to miss tracks but I bet I mess that up before I've finished! It took me 4 goes to get that the right way round of course! (In the end I had to print it out and mate it to the DE0 to get my head the right way round).

I was considering sending this off as my first attempt at using Eurocircuits but getting started with that seems a bit over-facing to me...I could do with watching over someones shoulder who is doing it.

I've bought a load of PCB drills and I'm going to re-grease my pillar drill this evening in preparation (the faster it goes the better and a bit of grease seems to make it run truer and snap fewer bits).

I'm waiting for a sheet of glass to arrive to hold down my transparencies and I'm going to try and cut the PCB one evening this week. It will be the most complicated / delicate one I've done so far. I did my first double sided one a few weeks ago and it came out ok except for my lack of concentration when drilling causing . This will be a bit more challenging!

I'll be trying to make this in a frying pan (for my reflow oven) again, that has worked on small boards in the past but might be pushing it for larger boards.

Thanks

D
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

Impressive! How are you making your transparencies out of interest?
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Hi George,

I'm using a HP LaserJet P2035, I just print straight to some random inkjet transparencies I have in the cupboard. The laserjet doesn't seem to print as densely as my old inkjet but feeding the same slide through several times does seem to work so long as I'm really careful with the guide rails on the paper feed. I've found some extra "hidden" settings on the printer to up the density so hopefully I might be able to get it to print in one pass sufficiently densely to work.

I expose with a UV LED which is meant for setting dentist's fillings. I've just mounted it on the inside of an old computer PSU case with some heatsink tape and a series resistor. I usually make smaller boards and a few minutes exposure does the trick. This is a bigger board so it will need the LED to be 2x further away. Also, normally I just tape the slide onto the pcb and weight it down with a few nuts and bolts but this time there's no room for that so I've got a piece of 10mm thick glass coming...no idea how much that will let the UV through so it may take a bit of experimentation to get exposure right.

On the plus side the PCB developer seems fairly forgiving so I'm hoping it will work. More likely lining the two sides up and my drink addled hands working the drill are likely to cause bother.

After etching I usually cover the board in a good dose of plumber's flux then run a big chisel tip iron over it whetted with a bit of solder to tin the tracks before drilling...they seem to behave better. Then I go over the pads for smd's with a bit of solder braid to get it dead flat. Then give it a good wash. Then apply solder paste and heat up to 150 in the frying pan for 5 minutes before turning the juice up until the solder melts, then turn off the gas. The hardest part is judging how much paste to apply, only a little too much ends up in bridged pads, too little and you get pads that test ok when you prod them but break when the board heats up!

All good fun but it would probably be quicker and cheaper to send to a proper pcb service...but every time I read their sites I come away a bit overwhelmed!

D

A bit more from a few years ago http://www.vintage-radio.net/forum/show ... hp?t=49975 I've now come round to the idea of glass!
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

Interesting.... I've used that method a few times (using a Mega Electronics UV exposure box) but due to the limitations with printing on OHP slides the density has always been a problem. I tend to find thin tracks particularly end up "ragged" or even "broken". Larger areas end up rather "mottled" due to the lack of solid black.

I've thought about using a proper "litho-film" print service, but then it gets towards the cost of just sending it out to a PCB shop to do the whole thing.
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

I have to admit some of my tracks are patterned but usually the patterning is enough to hold enough tin to make a connection.

I will try to send a "proper" pcb off to a pcb house in the next few months but it seems like being at work whereas messing with chemicals in my cellar is more fun!

D
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

dominicbeesley wrote:I have to admit some of my tracks are patterned but usually the patterning is enough to hold enough tin to make a connection.

I will try to send a "proper" pcb off to a pcb house in the next few months but it seems like being at work whereas messing with chemicals in my cellar is more fun!

D
I tend to find getting the exposure right can be tricky. Get it right and it works great, but the lack of contrast means getting good results across the whole board can be very hit and miss - . Worth trying certainly, but careful examination of the board immediately after etching and washing is highly recommended. Saves potential hours wasted later due to etching issues.

Love to see the results! :wink:
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

Just thought I'd post a couple of example PCBs etched using laser printed transparencies, which I made a few years ago. Might help with what to look for.

On the first notice the patterning, particularly down the left power rail and the missing tracks upper right:
P1150359.JPG
This one (an interface/PSU board for the above) that I got reasonably good:
P1150360.JPG
Probably helped by avoiding fine tracks and/or spacing.

Finally a close up of the patterning due to the poor toner adhesion to the OHP and lack of contrast:
P1150357.JPG
You must be logged into view and download the files attached to this post.
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
hoglet
Posts: 13355
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube detect code

Post by hoglet »

Still slightly off topic on the subject of home PCB making.

I can recommend LaserStar film, which is like a translucent drafting film. The toner sticks very well, and the material seems very resistant to the kind of heat inside a laser printer. I use an ancient HP LaserJet 2000 printer, which cost me £5 at a computer fair a couple of years ago.

Dave
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

I think I made both of those using LaserStar. It's an inherent limitation of laser printing onto plastic.

Definitely worth a go with this great project! :wink:
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Thanks lads, I'll look at the LaserStar thing next time.

I do get patterning but not that bad. I suspect that my "soft" UV light is a bit more forgiving of light leakage as my boards tend to be a bit underexposed (leading to long etch times / too much resist left). I do get patterning like that though it tends not to etch all the way through...

I've also ordered one of these....http://www.ebay.co.uk/itm/2in1-898D-Sol ... 41907a267d I fully expect it to be a load of crap but might be worth a punt...anyone got any better ones for when this one goes on fire?

I've also ordered some SOIC 4245 buffer chips and will do a bit of relaying out of the board this afternoon. After looking at the TSSOP chips I can't see that ending well!
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

65816-TUBE--brd.png
Quick update, I've modified the schematics for the larger '4245A chips and made space around the rom socket to suit the zif socket I've found to go there...

I might have a go at etching this tomorrow...
You must be logged into view and download the files attached to this post.
User avatar
george.h
Posts: 1033
Joined: Wed Apr 13, 2011 6:32 pm
Location: Chelmsford Essex

Re: Tube detect code

Post by george.h »

Looks good! I would a make a couple of suggestions though - I'm not sure if anyone else etching their own boards has found this.

I would make the pads for component pins and vias a bit thicker (i.e. the outside diameter somewhat larger than the inside, or hole, diameter). I've found the default "thin" pads a bit tricky to use for three reasons so I always "fatten" them when etching my own:

1. They have a tendency to "lift" a bit too easily when soldering, particularly if they end up undercut due to slight over etching.
2. Depending upon how accurate your drilling is going to be, it gives you just that bit more room for hole misalignment without eating too much into the pad itself.
3. On double sided it gives just that very slightly (and it is VERY slightly) more tolerance for misalignment between the two sides.
Pic Caption: "Now now boys stop annoying your sister..."
User avatar
dominicbeesley
Posts: 2564
Joined: Tue Apr 30, 2013 12:16 pm

Re: Tube detect code

Post by dominicbeesley »

Yes, I was thinking the same myself - I usually do bigger pads, vias and thicker tracks. I've tried enlarging the pads and vias this morning but there just isn't room. I'll give it a go with the skinny pads and vias fully prepared to have to start again!

I'm more concerned about whether the idea will work at all, I've probably got something stupid like the level shifters connected backwards!

If this board doesn't come out I may well go back to the tried and tested but slow method of wire-wrap...at least then I can fix mistakes

D
Post Reply

Return to “8-bit acorn hardware”