BCP: a BBC Micro printed circuit design program

Got a programming project in mind? Tell everyone about it!
Post Reply
julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

BCP: a BBC Micro printed circuit design program

Post by julie_m » Tue Aug 06, 2019 9:07 pm

For some reason, I thought it might be an interesting exercise to see if it might be possible to write a program for the BBC Micro to design printed circuit boards. I gave myself a simple brief: Accept input in the form of a wiring list (schematic capture can wait .....) and turn this, and user input, into Gerber and Drill files that can be used for manufacturing. (It probably helps that I've had professional experience with such software, and know the structures of CAM files.) There is also, of course, a canonical format for wiring lists: the SPICE deck. We simply append an extra field to the end of each line, delimited by a star -- which the SPICE interpreter treats as a comment marker, so it does not even spoil the validity of the file! -- to indicate the (initial) footprint for the component.

So far I am targeting the Model B for a "cut-down" version, with everything kept system-legal so it will run fine as-is on a Master 128 but also, by simply re-assembling the code, run from a different region of memory allowing the use of shadow screen memory and hence the better graphics modes. I'm also avoiding self-changing code, so it can run from sideways ROM. (All variables are stored in the same page of RAM.)

BCP should be able to handle boards up to 520 * 480mm., with a resolution of 0.127mm., up to 32 different footprints per design (0.0254mm. resolution within footprint, 0.0508mm. for the silkscreen outline) and up to 51 pins per component. (Maybe 256 footprints, 255 pins and a 0.0254mm. resolution in the Master enhanced version .....) Designators can consist of one or selected pairs (IC, VR, ZD .....) of letters, and a number up to 999 -- this fits into just 2 bytes (6 bits for one of 26 letters or 32 pairs, plus 10 bits for the number which in practice can fit up to 1023).

Done so far: The graphics library and most of the database. Drawing selected parts (silkscreen, boundary, topside pad, underside pad) of selected footprints. Read wiring list and seed database tables. Place parts on screen, store and retrieve positions, draw relevant layers. Report generation (not just human-readable reports such as parts list; Gerber and drill files are also reports by definition) can be done in BASIC; most of necessary code already written as part of test suite, just needs collating together.

Currently working on: Drawing traces.

The name really stands for "Back of Cigarette Packet", and it's pure coincidence that this also spells PCB backwards and is short for "BBC Circuit Program". :D
Last edited by julie_m on Tue Aug 06, 2019 9:43 pm, edited 2 times in total.

User avatar
tricky
Posts: 3677
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by tricky » Tue Aug 06, 2019 10:05 pm

What a great project :)
If there is actual drawing, I guess it is keyboard, but do you think that you might want to support joystick/bitstick or even mouse/trackball?

User avatar
roland
Posts: 3311
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by roland » Tue Aug 06, 2019 10:28 pm

Can you also post some screenshots of this project?
256K + 6502 Inside
MAN WOMAN :shock:

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Tue Aug 06, 2019 11:04 pm

Alternative input devices are something that will have to wait until I can get my hands on some actual Beeb hardware but there is certainly nothing stopping it from working in principle. Even with something like my primitive home-made "Etch-a-Sketch" controller.

I started from the constraints and worked from there: 24 apertures on the wheel (of a really obsolete photoplotter, but one might turn up on eBay); let's say ten for flashing pads, ten more for the same pads rotated 90 degrees (so we can place components in any of four orientations, there may be duplication in the case of round and square pads, which is regrettable, but the trade-off is everything can be rotated) and four for drawing traces and silkscreen outlines. That fits into a 16-row table; we can specify different pads on each side of the board (or no pad on one side, if it is surface-mounted), and the specifications for both will fit into a byte. 12-bit co-ordinates will allow for a grid up to 4096 points by 3840 (the forbidden zone allowing an alternative use for the co-ordinate entry ..... more later :wink:) and a 0.127mm. (5 thou) resolution is fine, allowing a board up to 520 by 480mm. If each component can be rotated 0°, 90°, 180° or 270°, and placed on either side of the board, that needs 3 bits; this allows for up to 32 footprints in any design and each footprint can belong to several components.

Then it's mainly just co-ordinate manipulation -- the screen is a viewport into an absolute co-ordinate system, which can handle up to 65536 by 65536 points; in practice only ever holding values from -10240 to 10235, and relative co-ordinates within this viewport are scaled to the BBC's screen co-ordinates, chain PLOTting and database table manipulation.

At some points, I need to know if the currently-selected rotation is even or odd so I can select the horizontal or vertical variant of a pad style. I've used a vectored jump table which depending on the rotation angle processes the co-ordinates of each pad relative to the component centre in various ways with the co-ordinates of the component centre to get the absolute co-ordinates. These subroutines are carefully positioned so the even rotations have bit 7 of their entry address = 0, while the odd rotations are positioned so as to have entry addresses with bit 7 = 1. Then we use

Code: Select all

LDA rotv
BPL no_rotate
LDY padW \ exchange length and width
LDA padL
STA padW
STY padL
.no_rotate
to test if or not we need to draw the shape as given in the table, or rotated by swapping the length and width.

An early screenshot. This is done using a BASIC test suite to prove the assembled machine code, written in parallel with it; basically just providing access to subroutines through BASIC PROCs and FNs. Note the co-ordinates are being entered manually, although they are being transformed for the viewport. (0,0) is at the centre of the IC (in case you can't tell what it's supposed to be; in which case there is no hope for one or the other of us :wink:) and it's cool with negative numbers:
bcp001.png
bcp001.png (5.27 KiB) Viewed 722 times
A more recent screenshot. This is now taking everything from the database. The outline is a component being moved (just a simple box, with a pin-one mark, to save redrawing):
bcp002.png
bcp002.png (6.61 KiB) Viewed 722 times
I now have to make sure I can still assemble the machine code from scratch (on a freshly-started BeebEm instance, not reloading a .uef file -- if I've manually changed the contents of a memory location from what the BASIC source set it to, something will go horribly wrong ..... I've not hot-patched the code, but there are plenty of variables I could have altered. Absolute worst case, I save a .uef in the not-working state and compare it bytewise with the working state .....), write some notes and it will be ready to post to GitHub.
Last edited by julie_m on Tue Aug 06, 2019 11:30 pm, edited 1 time in total.

User avatar
myelin
Posts: 723
Joined: Tue Apr 26, 2016 9:17 pm
Location: Mountain View, CA, USA
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by myelin » Tue Aug 06, 2019 11:20 pm

Sounds excellent! Do post in-progress screenshots; I'm really looking forward to seeing this :)
SW/EE from New Zealand, now in Mountain View, CA, making BBC/Electron hardware projects for fun.
Most interesting: Arcflash, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Sun Aug 11, 2019 10:31 pm

Gah! I was trying to set up a Github for BCP. Now, trying to replicate the build process from scratch, I've hit a bit of a snag with it.

Same story as ever ..... Basically, I cheated a bit just to get it to work, intending to fix it later ..... and now, later has arrived.

The beauty of developing in an emulator is, you can save an entire machine state. So when you have a huge BASIC source file that assembles code eventually to be run from a location in the middle of the source, you don't have to go through the whole business of saving the source,running it, saving the code and then loading and running a separate test suite every time; you only need to do that faff when anything changes. You can just save the machine state, which will already have exactly what you want where you want it in RAM.

The Graphics Library and Database Subroutines have to be assembled separately. Graphics first; it generates a variable dump ready to export into another program, with the workspace locations and entry addresses. There is a test suite for the graphics library, which generates a footprint data file. (These functions are actually separate; generating the data file does not require any graphics library routines. Next revision probably will have the footprint generator separated out. Visually editing footprints is a suggestion for future work.)

Then there is the database section, and this is where it got murky. Because this is used to generate the parts list table and wiring table from a modified SPICE deck (here, ). And the BASIC source file is too big to fit in memory with the code in its rightful location.

Reading the code again, and racking my brains to remember how I did it, it looks as though I must have run the source once, assembled the code using OPT 0 and then OPT 3 to run from wherever it fell, and called it from there to generate the parts list and wiring table. Then changed it to assemble the code to run from its intended location using OPT 4 and OPT 7; and supplied the fourth argument to *SAVE to specify a reload address. This sort of tallies with how the graphics library grew; until the Source Code got too big to keep the machine code in memory with it, the test code was integrated into the same file with the source code. It needs a bit of updating to include some workspace variables I have since added, and then making sure it builds.

While I'm fettling it for release, I will try to make this complex build system work with a single variable to specify whether we want to build the "temporary" version just to use for generating the wiring database, or the "permanent" version to save and use with the main program.

I'll be back soon with a link to the Github page!

User avatar
tricky
Posts: 3677
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by tricky » Mon Aug 12, 2019 9:09 am

BITD, I used to set page to the beginning of what would be the screen when the game was running and chain the basic builders together to assemble into where they would run from with the last program *SAVEing the executable.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Mon Aug 12, 2019 10:31 am

That's not a bad idea for MODE 2 games, but this app will be running in MODE 4 (or MODE 5 if you're working double-sided).

I should really tidy everything up with one big jump table, so the entry points never change. Could never do that before, as I was always adding new bits!

User avatar
roland
Posts: 3311
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by roland » Mon Aug 12, 2019 11:04 am

Why don't you convert the source to beebasm? You can use your favourite editor on your Linux host and assembling the code is much faster and easier. Beebasm can produce disk images that you can access from the emulator. See viewtopic.php?t=1667 for more information.
256K + 6502 Inside
MAN WOMAN :shock:

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Mon Aug 12, 2019 7:32 pm

That sounds interesting, although I was planning on keeping the build process entirely to the target side. It's supposed to be an emulation-friendly BBC application, after all, not a PC/Mac app that depends on a special runtime library which happens to be a BBC emulator. (Otherwise, I would go straight to SDL and SQLite or MariaDB .....)

I don't think it's too unwieldy just yet, with only 2 code blobs to build. But I'll investigate it anyway!

cmorley
Posts: 969
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by cmorley » Mon Aug 12, 2019 7:52 pm

If part of the fun is making it build on the period hardware you could still consider using a 6502 second processor for the build. With HIBASIC you get a lot more available RAM so you can have bigger BASIC/assembler chunks.

So don't change your target, keep that a B or Master but change the build to B+copro for the extra RAM. (And 3Mhz CPU raw power! :D )

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Sat Aug 24, 2019 3:18 am

My little project has a GitHub page all to itself at last! https://github.com/JulieMontoya/BCP_design

I am using the Wiki there to document the project.

I have actually followed my own build instructions, starting with a pristine disk image containing naught save the files as presented on the site, and ended up with a working test program; which of course means I must also have working graphics and database libraries. And writing about the bits that don't work (and glossing over one real howler, just to see which of you are paying attention at the back there ;) ) is already giving me ideas how to fix them .....

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Sat Aug 31, 2019 3:35 pm

Well, that's an annoyance. Looks like I set that page up in the nick of time; because this week my laptop decided it has had enough of going through POST and booting and just wants to sit there in a cycle of keyboard lights coming on, fan spinning, spluttering and dying.

Fortunately, I managed to plug a monitor into my old laptop with the busted screen, and I also have a fairly recent backup of BCP development files -- not to mention my original sheets of graph paper with my handwritten notes. But, just to prove it all works, I built the test version so far according to the instructions I wrote, and it assembled and ran fine.

Next I've got to see about getting the laptop sorted. It's still under warranty, so I haven't dared open it up. I suspect the SSD may be dodgy anyway, but am not 100% convinced that is what's causing the POST loop fault. I will contact the supplier and see what they say to do with it.

I also thought of a possible alternative packing schemes for trace vertices, which might require a bit of investigation.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Wed Sep 11, 2019 10:12 pm

The latest version of the graphics library (and its test suite) adds proper support for topside silkscreen, underside silkscreen, topside copper and underside copper layers; with a palette to indicate the colour to be used on screen for each layer, and a mask to indicate which layers to draw.

The order of drawing is fixed: underside then topside. Silkscreen outlines are only ever drawn on one layer, but pads have a style on the mounted side and the opposite side.

I haven't yet integrated this with the database library and main test program; it was enough for tonight just to get it working. I only just managed to squeeze the silkscreen layer selection into the space available (ended up 27 bytes shy of a page boundary and managing to eliminate a JMP to get the silkscreen layer select logic down to 25); by when the Source Code was now too big, necessitating some editing on the host side to get it to fit into the Model B target. (Thanks to the beauty of BeebEm, though, I was able to do some quick pre-tests on a Master 128 target. And it's looking very nice in MODE 1. I might even grab a few screenshots of that, because I can. The 128 is a nice machine .....)

And unfortunately, this has actually broken the main test program. The "W" key behaviour will not work anymore, as the graphics library is doing its own GCOL. But that's something we can fix another day.

User avatar
tricky
Posts: 3677
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by tricky » Thu Sep 12, 2019 9:13 pm

Sounds like more great progress and screenshots are always appreciated.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Thu Sep 12, 2019 9:51 pm

Sure, I'll remember to grab a few pictures next time I'm working on it

The current state of the Work in Progress is on my Github page linked above, if you fancy having a try yourself in the meantime and don't mind the sight of other people's code. I can't remember if or not I updated the "building" page on the Wiki, so you may have to make a few mental substitutions (just grab all the latest files) -- but if you can handle coding on a Beeb, you probably can handle that ;)

I know there are bits of explanation that I've missed out (it's a trait I inherited -- and indeed, I probably am only here in the first place because someone missed out an important step in some instructions once) so feel free to ask away here.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Sat Sep 14, 2019 10:07 pm

Screenshot 1 is the graphics library being assembled. Spot the trick here :)
SPOILER: (drag mouse over to read) If bit 1 is set, we branch to an LDA instruction; but that LDA is also the two-byte operand of a BIT instruction, with und_silk falling through to it if bit 0 of the accumulator is set. The BIT instruction doesn't change anything we are actually interested in; whichever route the execution follows, we wind up at &512D which is JSR get_colour .
bcp_36_assembling_640.png
Screenshot 2 is (going to be) a very simple transistor amplifier. This is the latest evolution of the placement test program, running in MODE 1 on an emulated Master 128. For no good reason except "because I can", three of the resistors are surface-mounted on the underside of the board. MODE 1 allows us to use yellow for underside copper, white for topside silkscreen and red for underside silkscreen (not that there probably would be silkscreen printing on the underside of a single-sided board, but still .....) Topside copper is turned off here; it would have to share a colour in the event all four layers were visible together (which you probably wouldn't want anyway). Nonetheless, it properly supports separate palette entries for each layer, and they can also be switched on and off individually. It's just a shame I messed up the footprint for one of the parts .....

It was hard work squeezing the layer and palette stuff into the graphics library, but I have since spotted a way to grab some space back by replacing some inefficient (but necessary, because I couldn't see any other way to do it at the time .....) code I have spotted.
bcp_mode1_640.png
Anyway, now I have a circuit that all fits on one screen at this scale (1 physical pixel = 4 logical pixels = 0.127mm.; other scales are available ;) ), that should make it easier to test the next, "search for all the pins connected to a given circuit node" subroutine I have to write! Because if you're going to lay down any copper tracks, then it helps to know at least where they are going to start and finish .....

User avatar
tricky
Posts: 3677
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by tricky » Sat Sep 14, 2019 10:19 pm

I only have one side of silk showing at once as both confuses me! But I do like to see both copper at once, but I guess if its configurable you might just please everyone.
Oh yes, just a bit of a trick. :lol:
I've only used that once I think in about 100k of 6502 instructions.
PS can you choose outlines for components/tracks?

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Sat Sep 14, 2019 11:29 pm

tricky wrote:
Sat Sep 14, 2019 10:19 pm
I only have one side of silk showing at once as both confuses me! But I do like to see both copper at once, but I guess if its configurable you might just please everyone.
The drawing order is (at present) fixed; silkscreen on whichever side the component is mounted, underside copper, topside copper, so pads disappear on through-hole parts (and take twice as long to draw). So unless a design is pure SMD, one copper layer at a time probably is better.
tricky wrote:
Sat Sep 14, 2019 10:19 pm
Oh yes, just a bit of a trick. :lol:
I've only used that once I think in about 100k of 6502 instructions.
It's a little bit dirty, but it actually uses only one extra CPU cycle compared to a BEQ leapfrogging the LDA #1. And in my defence, any disassembler that has correctly latched onto the first byte of an earlier instruction is going to display the BIT instruction correctly, with a BNE into its second byte just a few lines above it. So it's not entirely unmaintainable even if the Source Code got lost.

Anyway, it's probably not that much worse than where I read bit 7 of a jump vector to determine whether the rotation angle is an even or odd multiple of 90°and therefore in which orientation to draw a pad! (the entry points to perform rotations 0 and 180 are deliberately chosen so both are in the early half of a page with low addresses, and similarly those to perform rotations 90 and 270 are both in the later half with high addresses.) Yes, it's contrived code ..... Still not quite as egregious as self-modifying code.
tricky wrote:
Sat Sep 14, 2019 10:19 pm
PS can you choose outlines for components/tracks?
Every footprint definition includes a bounding rectangle, and this is what actually is shown -- with a dot at pin 1 -- when you are placing a part. Tracks aren't coded yet, but I'm certainly going to include the option to render them as one-pixel lines, irrespective of actual width, for speed. Pads as outlines could be a possibility worth investigating in future, if my planned graphics library tidy-up saves enough room. (I might even get to use an actual BIT instruction for its rightfully-intended purpose, if I am doing that!)

My "search_node" code is currently written out longhand on squared paper with a propelling pencil, ready for typing in .....
Last edited by julie_m on Sat Sep 14, 2019 11:43 pm, edited 1 time in total.

julie_m
Posts: 36
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: BCP: a BBC Micro printed circuit design program

Post by julie_m » Mon Sep 16, 2019 10:21 pm

Alright, here's a teaser of good stuff to come .....
bcp_38_search_node.png
bcp_38_search_node.png (4.82 KiB) Viewed 75 times
What's going on: The machine code at search_node expects a circuit node number in A; and searches through the wiring list until it finds a pin connected to that node, or it runs out of parts. The carry flag indicates a pin was successfully found and selected; its co-ordinates will be found in absX, absY (thou) and scrX, scrY (screen pixels) and A will contain the pad styles for the mounted (high nybble) and opposite (low nybble) sides of the board. If the carry is clear, there are no more pins connected to that node. The BASIC PROCplotscr(K%) simply takes an argument K% and uses this as the mode for a PLOT command with the contents of scrX,scrX+1 and scrY,scrY+1 as the co-ordinates. The machine code at sn_resume continues the search from the next pin.

Post Reply