log.txt

2023-07-12:
- for the case, there is a 63HP and a 42HP, and a 271mm and 331mm (the 391mm is way too big)
- the 331mm is also kind of big if I wanted to put it under my oscilloscope on the shelf.  271 would fit more comfortably without
  sticking out.  Hopefully it's big enough
- the 63HP (364mm) is just a bit too wide to fit in the spot next to the book, it's a squeeze but possible
- the alternative is the 42HP (257mm) is too narrow for the oscilloscope =/
- the 42HP is a bit big but would fit below the books on the middle shelf, but that shelf already has a lot on it

- It seems like CompactPCI systems are designed with a single system slot, and the rest are peripheral-only slots.  There are some
  dual system slot designs that I can't find much documentation on, but generally they seem to be single-system (single-CPU card).
- the only thing I can figure that requires the distinction is the SMBus which I don't need, and mainly the request/grant lines,
  which it's using for resolving which card can gain the bus.  PCI *usually* has each peripheral's request/grant lines connected to
  an arbitrer that can do whatever priority encoding it wants, but I have seen mention of using daisy chained resolution like VME
- the question is, is there another reason in the protocol layer or something that needs to be able to arbitrate differently?

- for VME I've seen it said that the CPU card usually has both the interrupt controller and the arbiter and must be plugged into
  slot 1 because of the daisy chaining
- I would either put the arbiter on the backplane, or put it on a separate card in slot 1, and then multiple CPU cards should be
  possible

2023-07-30:
- The more I think about this, the more I feel VME is the right option to choose for this iteration because it's more adaptable.  It
  can use different bus widths, and different bus timings, so it can more easily support mixed devices with easier interfacing
  requirements, possibly even without the need for a CPLD, which would be ideal
- the main issues is the connectors to use, or whether to multipex the bus
- If I choose to multiplex, I might as well redesign it and make it "inspired by VME" instead of VME specifically.  If I keep it
  otherwise the same and match the spec except for the connector, I can still call it VME [and use the spec as source of truth]

- PCI not only takes a lot more hardware, but it's supposed to be fixed to 33MHz or 66MHz, neither of which I can adhere to without
  wait states.  It doesn't seem to allow wait states

2023-07-31:
- thinking about it some more, I think larger connectors are the way to go
- for starters, a lot of peripheral devices won't actually need bus transceivers, or if they do, they'd only need them on the data
  bus.  I had been thinking I would need them on every card because I was thinking about the controllers and the possibility of
  FPGAs and microcontrollers connected to the pins, requiring transceivers to re-multiplex the bus due to limited inputs, which is
  still something to consider, but if most people would be making simple peripheral cards, then it's much easier to use a separated
  A/D bus
- if the connector is the same but with an extra row, then it'd be possible to use the same backplane with the 3-row connectors
  soldered into 4-row holes on the backplace PCB, and the cards could use 3-row connectors and be 16/24-bit cards instead of 32-bit
  cards.  So there's some flexibility there
- 3U cards over 6U cards means they're 100mm tall, and if length is not a concern, other people could order and make 100mmx100mm
  boards for cheap, again making it more accessible to other hobbyists

- but actually that "transceivers required for microcontrollers" one is not the best, but I guess there's no way around that, with the
  exception of a secondardy bus...  VMX and VSB were mentioned, as was VMS the serial protocol for the backplace
  [Ed: it seems the STM32 has 5V tolerant pins
- a secondary bus is overkill.  It doesn't seem to be mentioned on modern VME equipment

- I keep glossing over this every time I come across it, and it's so poorly documented, so I'm raising attention here
  !!!!!!!!!!!!!!!!!!!!!!!!!!
  VME64 (not VME64x which introduces the grounded connectors) has provision for an A40 address space, which is capable of 40-bit
  address transfers using only the P1 connector (3U).  It does this with a special AM number, and using the DS lines to do two data
  requests while continuing to hold the AS line asserted.  I'm not sure if it can also do a 32-bit data transfer on the P1 connector
  alone but this is at least an improvement, and I could possibly even hax it to do that
- the spec actually has user-defined AM codes! I could use those to create extended cycles. 32-bit cards are probably going to have
  ATF1508 CPLDs, or FPGAs, or ARM microcontrollers, and really simple peripherals would only be 16/24-bit

2023-08-01:
- What should I name the OS:
    ComputOS, ComputieOS, ... ?
    - uwunix
    - Hobbes
    - Tinkers
    - GloOS (glo-worm)
    - PotatOS (Mr Potato Head)
    - Gloworm <--- chosen
- What should I name the multiboard computer:
    Thinking about "Industrial Computer", "VME", "VersaModule Eurocard", "Laboratory Computer", "Modular Computer",
    "Modular Test Bench", "Laboratory Test Equipment", "Industrial Automation", "Retro Industrial", "Hobbyist"

    - Indie
    - Indiverse
    - VooMiE
    - Vroomie
    - Ivie
    - Ivy
    - Vindie (VME)
    - Versie
    - Versus
    - Inverse
    - Vertibie (vertebrete)
    - Vervie
    - Labbie (labratory computer)
    - Modulo
    - ComputieVME/computie-vme
    - Industrie (because it's an industrial computer)
    - Industro
    - Controllie, Compo...
    - Laboratory, Laboratorie

   Not going with PCI
    - ComputiePCI/computie-pci
    - Pieces (PCI), Pooki (PCI)

  - Parts:
    IVA for bus arbitrator/interrupt controller
    IVB for backplane
    IVC for CPU
    IVD for device (or IVP for peripheral)

2023-08-09:
- I got the connectors I ordered
- boy are those 5 row DIN 41612s chonky boys
- the press fit pins on the TE/Amp sockets look the same as the ones on the Hirose, which only said through-hole and not solder or
  press fit.  Either way, they look like they could be soldered
- the 4-row TE/Amp socket one that was specifically for soldering have very shaped pins that would give a much stronger connection
  I'd think but they're $31 (the Hirose was $29, but the pressfit TE was only $16 each)
- the TE/Amp 4-row headers look nicer, with a plastic protective shield around the pins, and cost $22 instead of $25 for the Hirose

- the 4-row headers can connect to the 3 row sockets without an issue, but not the other way around, unless you cut the plastic
  shroud, so a fancier card could plug into a slower 3-row socket, but a slow 3-row card would need a dedicated 3-row socket to
  work
- the VME64x connectors can fit 3-row and 5-row but cost $52 and $39 for the connectors
- it might be easy to make the backplane fit 3-row, 4-row, or 5-row sockets, in which case the 4-row socket would plug into the
  right most 4 rows of holes, and the 3-row would plug into the middle 3 rows of holes.  I could maybe make that clearish on the
  silkscreen

2023-08-12:
- So I'm pretty sure Mouser's website has the wrong information on the TE connectors.  It says that 216415 has solder termination,
  but it looks like what press fit should be.  The drawings show that the holes should be 1.15mm which the largest part of the pin-
  is about 1.20mm, so it would be a rather tight fit.  Infuriatingly, the TE website doesn't actually say if those connectors are
  press-fit or solderable!!!  It's missing so much information
- looking up the same part number of digikey lists it as being press-fit, and the other one, 254977-E is listed as solderable.  It's
  the one with thin flat pins.  So they're backwards between digikey and mouser, and I think digikey is correct.  They're also
  cheaper at digikey

2023-08-20:
- I need to figure out how the bytes are transferred on the bus relative to what the 68030 expects (and other CPUs), to see if you'll
  need to move bytes around using transceivers =/  That might be needed for 16-bit and 8-bit data reads, because the 68030 expects
  them to use the upper part of the data bus, but the VME specs seems to say they'll be on the lower 16-bits (makes sense)
- but yeah, I might need some complex transceiver stuff, hopefully not too much or that there's something that will do it in one
  package.  I can't bring all the I/O pins in and out of a CPLD

2023-08-24:
- I'm trying to think through the various transactions.  Firstly, it's important to remind myself that when the cpu receives a DSACK
  that signals it's a 32-bit port, it will always read the data bus as if it was 32-bits wide, which means not as much moving around
  is needed.
- the possible transactions are:
    D08(Odd)
    D08(Even)
    D16
    D32
    MD32 (multiplexed on 3U/P1)
    MBLT (64-bit multiplexed on address lines)
    (also unaligned reads)

- D32 cycles are handled correctly with direct bus connections
- D16 cycles are fine for byte 2 and 3, but reading/writing bytes 0 and 1 won't work without transfering them to the upper bus, either
  to make them be on the upper bus where they're expected for a 32-bit memory port access, or to put on the upper bus and return as
  if a 16-bit port access
- D08 O/E will also be correct as the D16 cycle, so they need that extra cross-bus transceiver

- MD32 requires a transceiver between the upper CPU data bus to the lower BUS address lines, and the upper CPU address bus to the
  lower BUS data lines
- MBLT is not really supported for 32-bit CPUs so I don't need to cover it

- I think I'll need the usual 4x16 transceivers for the address and data buses, plus 1x16 transceiver to support D16/D08E/D08O, and a
  final 2x16 to support MD32 accesses for a total of 7

2023-08-27:
- I was looking at https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:mpu302 and just happened to look up DS12365, which is
  a MicroManager Chip.  The datasheet says it halts and restarts an out of control cpu, and resets the cpu during power
  transients.  That particular chip probably wouldn't do much useful for this project, but it got me thinking about a monitor
  circuit, possibly even an optional microcontroller that can operate across a wide range of voltages that could monitor and reset
  the CPU, and if it halts, then reset it.  This would be useful for things like the 68k test runner where a successful tests
  results in a reset.

2023-12-10:
- It's been a while since I've updated.  Work has been stupid busy, and its been similar to this project, so I slowed down and
  then stopped entirely.  Now it's almost my Christmas break and I decided to start a new avenue towards this project, by making a
  ARM microcontroller-based board that can interface to VME.
- before I stopped this project entirely in October/November (so in September and early Oct), I started a bunch of different
  versions of cards: I started a sytem card to act as the bus arbitrator with mostly just a CPLD (very prelim), a backplane, a
  breakout card that just has signals that can be hooked up to a logic analyzer
- and then I also started a 68k card with the idea of making it use only DIP chips, but I had trouble fitting them all in a single
  3U card, which is a bit of a problem.  I'd either need to cut features, reduce the logic a lot by using PALs (which kind of
  defeats the accessibility of the project, or use the PLCC versions of some chips for space reasons, which is probably the lesser
  compromise because the point is for others, who might not have all the tools I have, still build a working a card/system.
  Only using through hole (not SMT) and not requiring a special programmer for PALs seem like the most important constraints, so
  through hole PLCC sockets can still work, but if the CPU is not the big DIP, it's harder for people to find them.  It's already
  become pretty difficult to find vintage 6502s now, and the 68000 and 608010 PLCCs are more rare than the DIP64s
- that said I could also use a different CPU that's still available new, like a 6809 or something
- a quick look shows that only Z80s are available from digikey new and in stock in through hole packages unfortunately.  There is
  an 8088 from Renesas for $82 (yikes), and some 80C186/88s and some MC68302 coldfires from NXP, but only in SMT components


- THAT BRINGS ME TO: the current subproject, IVC-STH7 (renamed BigBoy)
- fidget didn't work out as well as I had hoped.  I did get it sort of working eventually, but the transceivers got fried because they
  wrote into each others because of a logic mistake I made early on.  The chips were scortching at one point, and then they seemed
  stuck on certain values (or my bus interface logic was broken beyond what I've been able to fix).  I've taken some of the chips
  off and was going to see if the data transceivers are also broken and need replacing, but I just haven't gotten to it, and am
  tired of fighting verilog right now
- so I thought I might as well try the idea of a microcontroller to interface to the bus like how the arduino used to, even if
  it's only a stop gap card, and it would be great if I didn't need the transceivers, so is there a 5V chip available that can do
  what I need:
    - ATSAMC21N (100 pin)
    - Renesas RA4M1 (used on Uno R4)
    - NXP Kinetis E-Series, KE1xF
    - NXP S32K-Series
    - Toshiba has some newish Cortex M3s (despite being an old cord)
    - PowerPC-based e200z7 cores from NXP and others have hundreds of I/Os that are supposedly 5V

- it turns out, at work we used the ATSAMC21N for some early boards, and then switched to the S32K3 because it can more easily be
  safety certified when that's needed.  I ported the atsamd rust crate to the ATSAMC21N at work, and then when the chip was
  changed, I wrote a rust HAL for S32K3 from scratch, so I have some experience with those two chips.  I haven't yet done much
  with the arudino R4 that I have, so I don't know much about the Renesas, but I hear odd mixed comments about Renesas products in
  general, no idea if there's any truth to that.  I also don't know the KE1xF series, but from a cursory look, it's probably
  similarish to the S32K which is also made by NXP

- comments from my todo list app, after doing a second look:
    For ARM based microcontrollers with high I/O counts, the S32K is the only real option.  Infineon has some that are much more
    expensive (turns out they only have a small subset of pins that are 5V tolerant or something, so not an actual option).  Toshiba
    has some old M3s that seem alright, but kind of an unknown.  Renesas doesn't have many options.  And the KE1xF from NXP maxes out
    at 89 I/Os which matches the SAMC's 84 I/Os max.  If you need anything less than 84 I/Os, then there are options to choose from,
    but above that, the S32K1 is the likely choice, despite it not having true open collector I/Os

- so the S32K is really the only option, and it's not (yet) open sourced by the company I work for, and I'd rather not recreate
  all that work, or to have to use C, and it's way too close to work stress, so bad news all around
- the SAMC is nice, and the atsamd crate is nice, and we're not using it anymore at work, and it wasn't that hard to port, so I
  could feasible recreate that porting work, and thus get 84 I/Os, which isn't bad... but I'd still need to multiplex the address
  and data buses for the VME project, which requires 4 transceiver chips.  Is it really worth it

- so this lead to looking into what's the chip with the most I/Os I can get?
- there are some PowerPC chips, some H850s from Renesas (Hitachi), so various random chips, aaaand the the S32Ks *facepalm*
  they have 208 I/Os for the BGA package, but the highest pin count they're available in is the 172-HDQFP (high density quad flat
  pack) with 141 I/Os.  It's a weird package that still requires hot air to solder, it has PLCC like pins bent under the package,
  and also normal QFP pins, alternating to crame more pins in.  I don't want to use the S32K...
- the highest pin count part, *that is also a ARM-based chip, *that is is also in a hand solderable QFP package, is the STM32H7xx
- it comes in a QFP-208 pin package, with 168 I/Os, and most of those I/Os are 5V tolerant
- I'm still thinking of using transceivers for level shifting, even though I could maybe get away with directly using I/O pins to
  the bus, just to be safe, and to drive the bus in the same way that other cards will do (allows me to test the transceivers
  first)
- It has ethernet, it's 480MHz, it comes in a single and dual core version (M7+M4 in dual core config), it has a Rust HAL already
  available for it, (it comes in a Discovery kit from ST, with an LCD screen and all sorts of things, so I can start writing
  software for it when that arrives in a couple days), it's perfect (I hope)
- it also comes in BGA packages (although unfortunately none with more I/Os), but I could make a second version with the BGA to
  learn to solder such a big BGA package, with the only change from the simpler to solder version being the one chip and no other
  circuitry
- and that brings me back to the current moment, when I'm working on the schematic for this board


- so for the IVC-STH7 project:

- after looking more closely at the schematic, which clearly labels which lines need to be length matched and differential,
  particularly for the ethernet and USB signals, I'm thinking maybe I shoud only use the full speed simple USB interface instead
  of the high speed phy chip since I know I can make FS work (ie. for the bootloader in Fidget), and the safety of USB working the
  first time is more important.  The Ethernet will be the experiment with a high speed PHY interface and differential signals

2023-12-13:
- reading through the datasheet for the TXS0108 "8-bit bi-directional level shifter for open drain", it mentions tying the OE pin,
  which is active high, to ground via a pull down resistor, so that during power up and power down, the output will be disabled!
  I should have done that on Fidget to ensure the transceivers didn't write into each other, which damaged them, although in that
  case they were both OE-active at the same time

2023-12-14:
- looking at the signals on the VME backplane that I bought, it looks like all the signals except the IN/OUT signals are held at
  about 2.74V, including SERCLK, SERDAT, and SYSCLK, but with the exception of IACKIN which is Vcc on the second and last slots,
  and on the first slot it's 2.74V
- the STM32H7's 5V tolerant inputs should accept 2.3V+ as a logic 1, and being 5V tolerant, it should be fine to directly connect
  the open collector inputs to I/Os on the chip, instead of going through a buffer.  I'll still go through a buffer for the
  address and data lines to be safe.  Not yet sure about the rest

2023-12-20:
- I'm already feeling pretty fatigued by this project.  It just doesn't have much of a unifying concept, and it's too closely tied
  to industrial electronics, which while kinda cool sometimes in a retro industrial sort of way, are still pretty boring and
  stress-inducing to think about.  I'm not even sure about the name anymore.  I need to think about this a lot more

2023-12-23:
- I still have some fatigue, but reorganizing and rethinking a bit has helped somewhat.  It still doesn't have enough purpose,
  which I still need to think about.
- the board design for BigBoy is a slog so far.  I partly intetionally didn't try to carefully select I/Os, so that instead they
  matched the dev kit for things shared between them, and used logic port pins for the address and data lines, but that has meant
  there needs to be wires all over the place, and reshuffling themselves with vias for things like the VME bus connector, which
  has established pinouts.  I'm not sure if there's an easier way, but if the transceivers aren't needed, that would go a long way
  towards simplying the board

2024-01-07:
- the boards arrived two days ago, and yesterday I built up the board enough to try programming the chip.  At first, it worked but
  didn't run as expected, and there were some weird things going on, but I had forgotten to put the boot jumper in place, so it
  was booting into the bootloader sometimes (input was floating).  Now it seems to program just fine, and I can get debug logs,
  but the LEDs don't seem to be changing as expected
- [Ed] I had soldered the rest of the board up, including the ethernet chip, and it worked pretty much first try with a ping
  responder firmware.  I used hot air, but a lot of the pins stubs on the sides didn't seem to be connected.  I went over them with
  my soldering iron afterwards, on the edges, and they now seem fully connected on the sides, so that might be why it worked more
  than the hot air work.  I'm going to need a lot of practice still to get it right, and a thermocouple!   I saw a video by
  Shawn Hymel in which he used a thermocouple positioned over the chip to know how long to preheat the board for, and how long to
  hold it on the chip so that the solder will likely be melted.  My multimeter has a connector for one, so I should get one

2024-01-13:
- I've verified that basic I/O is working on the connector, and the transceviers are outputting, but I did accidentally swap the
  AL/AH transceiver control signals with the data DL/DH ones on the schematic, so the address and data buses can't be split
  correctly (as 16/16 for data and 24/8 for address). They are outputting logic 5V with quite a high spike, but I think that's
  because it's unloaded.  When I hooked it up to the VME standard backplane that I have, both the transceivers and the I/Os
  in push pull or drain mode can drive the signals in a way that's seen by the other slots, so that's no problem from the looks
  of it.
- that said, it is drawing a fair amount of current.  It's taking 12mA in some cases, 8mA in others to drive the bus, and while
  that's within spec for individual pins, there are also limits on the max current per port/device for both.  The transceiver
  pins can source/sink 50mA per I/O (I think), but 100mA max per Vcc line, and there's one per Vcc per 8 pins.  The microcontroller
  maxes out at 25mA per pin, and I don't know what the port-total is

2024-01-14:
- the 74LS645-1 transceivers come up a lot when talking about VME and high current supply.  They are often cited as needed instead
  of '245s because the 245s can't sink or source enough power.  The 645-1* specifically is required and only those have 48mA outputs
  (with a total 70mA supply when all outputs are HIGH).  The regular 645s only have 24mA output.  I've been worried about needing 64mA
  for all I/O signals at once, according to a forum post, but looking at the spec, it's only required for the some signals: BBSY and
  SYSCLK, AS, DS0, DS1, and DTACK.  The rest require 48mA with the exception of the push-pull IN/OUT signals, which only require 8mA.
- it's only sinking current too; sourcing current only needs to be 3mA, because the rest of the power would likely come from the
  backplace?
- one thing I need to find out is if there's an issue with driving the signals high, or if that burns more current than is
  necessary, and all I/O should be open collector and rely on the pull up resistors/active termination of the backplane

- also active termination seems easy if you only need 2 - 4 opamps.  I saw mention of 4, but then the examples show one on each end
  of a large set of signals, so I'm not sure if they need to be in two banks of signals or what

- there are also specialized chips like SN74VMEH22501

2024-02-04:
- I plugged the card into the backplace I have, as well as the counter card that I bought, and measure the various loads to roughly
  approximate how much power it's drawing per pin due to the pull up resistors on the backplane.
    backplane only: 1210mA
    big boy only: 170mA
    big boy + backplane: 1530mA
    big boy extra current: 150mA more when card is seated vs only power supplied
    timer card only: 1040mA
    timer + backplane: 2250mA
    all three: ~2600mA which is only slightly higher than 2570mA calculated from the other numbers, but it was also slowly coming down
- big boy didn't seem to draw much more current with the timer card in, but they also weren't talking to each other.  Big boy was
  putting data on the address and data lines, but all the control lines were high.  I guess I should try that next

2024-02-04:
- measuring the current per pin, I'm getting around 25mA draw per pin when it's outputting a 0, and about 18mA when it's outputting
  a 1.  According to some rough calculations, I should be seeing as much as 30mA when a pin is pulled low, so I think the measured
  value is about right.  This is taken from the transceiver outputs.  It's about the same for direct pin outputs too, so I think
  that's what the bus current should be for the given terminating resistors.  The 30mA comes from an effective 165 ohm resistance
  pulling up to 5V, with a 50 ohm bus impedence and 330 ohm pull up resistor.  With a thevanin equivalent of 194 ohms, it comes to
  25.8 mA, which is almost exactly what I measured.  Perhaps I could double the terminating resistor values, and effectively halve
  the amount of current draw per pin, which would likely be good enough to protect the direct inline outputs.
- what if I used sockets for the 200 ohm terminating resistors in an active terminated configuration, such that I could swap them
  out for 400 or even 600 ohm per-signal resistors, which should knock the current draw down [Ed: not needed because 330/470
  dividers or 200 ohms when the divider is connected as two resistors in parallel]

- I still don't understand why the required pull down current is 48 mA - 64 mA when a system with one card is only going to pull
  26 mA from the bus.  Is it assuming that other cards might be outputting high signals that each card needs to be able to overcome?
- it looks like the schroff backplane is using an L272M opamp for active termination, which can output 1A

2024-07-01:
- this project needs a new name, one that emphasizes that it's a modular computer, and that is its primary purpose

    - modgie
    - modjie
    - modge
    - vero
    - veuro
    - modulator
    - modularator
    - modulo
    - modjupter
    - modjupiter
    - modbox
    - modeuro
    - mauve
    - maudulator
    - maudie
    - maudgee
    - modblox
    - eurowack
    - versahack
    - versaknack
    - versapack
    - versarack
    - versawack
    - modverse
    - moduverse
    - hackiverse
    - hackyverse
    - juxtaverse
    - wackyverse
    - rackyverse
    - compuverse
    - computieverse
    - compieverse


- you could make it interoperable with eurorack modules, or at least it should be possible to put eurorack modules into a 3U desktop case, but you
  might not be able to put 160mm cards into a normalish eurorack case because they're too deep, but you should be able to manage
  100mm, which is a standard eurocard width, even though it's not really used for VME.
- You can make 100mm cards with a 60mm adapter board that just extends the bus wires
- also they'd both be cheaper to print, even though the connectors are more expensive than it's worth probably ($3-$10 a connector x
  2 additional connectors)

2024-07-14:
- sooo much going on and all over the place.  I'm trying to sort out active termination, and also automatic daisy chaining, so that
  I can make a backplane board, and I'm also trying to get the software for bigboy working
- for active termination, I've searched everywhere for a schematic I once saw that had an opamp buffer (1:1 amplification) with the
  standard 330/470 resistor network feeding the + terminal as a voltage reference, and the output going through 200 ohm resistors
  to each of the backplane signals, with a mirror version on the other end of the bus wires.  So one opamp on each side of the board
  driving all the bus signals (or a subset of 32 or so signals), with a 200 ohm resistor on each end for each signal (64 resistors
  for 32 signals).  The thevenin equivalent is a 194 ohm resistor through a 2.94V source, which is what it's trying to match.
- I can't for the life of me find the source schematic where I saw that, so I don't know if I'm remembering it correctly!

- Tom Storey's backplane has the same circuit.  At first I didn't realize how it's working because it's using split 330/470 ohm
  resistor networks for passive and active termination, but (now it seems obvious), if you connect the 330 ohm and 470 ohm resistors
  in parallel, you get 194 ohms!  So when selecting active termination through the jumpers, the resistor networks are wired together
  differently to either use the resistors as voltage dividers or in parellel as a single resistor.
- it turns out the resistor networks for 8 signals of 330/470 dividers is a bit cheaper than 8 signals of 200 ohm bussed resistors,
  so I might as well do the same, making it selectable, and populatable either way.  That settles the resistor network circuit

- the next thing is the opamp vs a voltage regulator.  Most of the docs for active termination, like
  https://web.archive.org/web/20210310063304/http://www.interfacebus.com/Design_Connector_VME.html#e
  show a voltage regulator instead of an opamp, as does this backplane: Kaparel 3700x Backplane User Manual
  https://pixustechnologies.com/assets/Datasheets/VME64x9U-User-Manual.pdf
- the types mentioned there, and in a backplane manual, and are as follows
- UC564: VME bias regulator, 500-600mA output for 32 signals lines
- ML6554: Bus Termination regulator, 3A output, doesn't say how many signals because it's not for a particular standard
- the opamp on Tom's board is TCA0372 or L272M, which are 1A power opamps and are used for all signals it looks like (one on each
  end of the backplane, with two spare unused opamps)
- the standard 3U backplane has 72 signals.  The 6U or 3U-extended backplane has 96 signals.  If the UC564 official regulator has
  500mA for 32 outputs, adjusted for 72 signals it would need 1.125A and for 96 would need 1.5A, which is close to the outputs of
  the opamps listed, although I think if I went with power opamps, I'd want to find one with a bit higher current output
- I found a regulator that can do 3A variable voltage output, 2MHz response, TPS628303BDRLR, $2.50 at digikey
- the TCA0372 is about the same price
- bigger opamps are much more expensive from the looks of it, so using more of the same would be better

- the other issue is automatic daisy chaining.  The backplane manual above has the circuit used, but I'm not sure how it works yet
  there is something related to slot 0 and the system controller, but ignoring that for now...
- the OUT from the previous slot goes into the IN of the current slot, as well as an OR gate input. The OUT from the current slot
  goes into the other OR gate input, with an 82kohm resistor pulling it to ground.  The output of the OR gate then goes to the IN
  of the next slot
- since it's active low, the OR gate is acting like an AND gate in inverse logic.  If no card is present in the slot, one input
  will always be low because of the pulldown resistor, and the other input is whatever the previous slot's output was, which will
  then pass through to the output of the OR gate unchanged.
- if the card is present, and it *disallows* the signal to go through, it will be outputting a high, so the output of the OR gate
  will always be high, which prevents any downstream cards from responding (high means no-grant or no-iack).  If the card outputs
  a low on its OUT, then it's a bit interesting... if the previous card is outputting high and the current card is outputting low
  then the next card will still see high (disallow) instead of low (allow), so that must be why there's a 0 ohm resistor on the
  schematic connecting the OUT directly to the output of the OR gate, bypassing it entirely.
- first slot's IN is always tied low, then it will always grant-allow and it will work as normal, but if you want to daisy chain
  backplanes, then you'd have an OR gate on slot 0 as well, and you'd need a jumper (or 0 ohm) that bypasses it for slot 0

- IACK works a bit different though, doesn't it? so you might want to think about that


- the MVME167 board that I have has M27C4002 rom chips
- signs of capacitor leakage, but there's only 4 electrolytics, and the corrosion is minimal

2024-07-22:
- I'm starting in on the board design for the SystemBoard, and have part of the backplane schematic done

2024-08-04:
- I almost finished the SystemBoard PCB a few days ago, and have been putting the final touches on recently.  I'm not sure whether
  I'll get the board made with 4 layers or 2 layers, but I've managed to get all the power connected with just 2 layers, so at least
  others could get it printed like that if that was a concern.  JLC offers 100mm x 100mm boards in 4 layer for like $6 or something,
  so I might as well get 4 layers.  I mainly just want to test the ATF1508 to make sure it will work as I expect, and that I can
  program it in circuit.
- I'm still debating whether to rush to finish the backplane, or order Tom Storey's backplane design.  I think I should order one of
  them since I'll be paying the import duty either way, and getting Tom's printed would be another point of reference for his
  design, but if I make my own, I can get a revision in the works, and I'll at least have the option of using the 4 row connector.
  I'm also going to add automatic daisy chaining to my design, and I'll have a chance to change the footprint of the op amp or
  regulator, which is proving to be harder to find that I was hoping.  I might have to either get old new stock TCA0372s in 8-DIP or
  L272M is the same footprint to make Tom's work, assuming I can't find a generic 8-DIP that matches the pinout and has the same
  specs.  There is a TCA0372 at digikey, but it's 16-SOIC I think

2024-08-09:
- I'm looking at Schroff cases again, and can't decide between the PropacPRO and CompacPRO.  The Propac has aluminum sides I think,
  and looks nicer, cleaner design, but doesn't have handles to lift it up on the sides.  There are straps that can be bought for the
  sides though.  The Compac doesn't look quite a nice, but has integrated handles in the sides (a lip or each side), which on the
  one hand will collect dust, but on the other, acts like a handle.  It's also symetrical front and back, so it could have cards
  hanging out the back.  The  Propac can probably still have cards mounted on the rear, but it just doesn't look as nice when
  backwards, which is ok.
- I don't think I'll get the 84HP/6U case and instead if I grow out of this 3U/63HP case, I can upgrade.  It's $444 for the full
  size case, and $240 or $305 for the 3U/64HP case, only 50% more to get the larger one, but who knows if I'll use it, and the
  smaller case is what I really wanted because of the cute factor

2024-08-30:
- still need to order parts and the SystemBoard, after redesigning it for the TQFP, which is much smaller.  That will help with the
  k30-VME16, which is space constrained.  I'm trying to tie up some loose ends with the k30 schematic design.  I need to figure out
  what signals the CPLD will need, and how to connect the serial interrupt and interrupt acknowledge, in a way that also works with
  the bus.
- as far as I can tell, the MD32 cycle can only be initiated with an A40 cycle.  An A40 cycle can be a byte or word access using the
  normal databus-only transaction, but if you try to do a 32-bit/4 byte transaction with an A40 address, it will always be an MD32
  cycle using the address bus.  If it's an A32 access using both P1 and P2 (the full 32-bit address bus), and it's a 32-bit size,
  then it will be a D32 cycle.  So there's no other special signal to know to do an MD32
- the names VME16 and VME32 aren't the best if you could also make a 32-bit 3U 3Row card.  It could be a 16-bit 3U 3R, 32-bit 3U 3R,
  or 32-bit 3U 4R (or 32-bit 6U, or 64-bit 6U)
    - 16bit 3U 3R - 3 tranceivers (4 if you want A40 16-bit transfers)
    - 32-bit 3U 3R - 6 transceivers
    - 32-bit 3U 4R or 32-bit 6U - 5 transceivers excluding A40/MD32, 7 transceivers with A40/MD32

- so basically, if you want to stick to 3R standard size, it's 3 for 16-bit and 6 for 32-bit

2024-09-02:

- I've got the SystemBoard, and now SystemBoardSMT designed, and I'm waiting on parts to confirm the measurements for the 60mm
  extender card before I'll be ready to order the boards.  I've already done a lot of work on the k30p-VME, but I realize I should
  work on the logic design to ensure I have the right signals I'll need to make it work.
- I found https://github.com/hoglet67/atf15xx_yosys and installed it with ease to compile a counting example, and loaded it onto the
  devkit I have with the ATMISP7 programmer, using its software.  I had to run the programming software in virtualbox with the USB
  extensions to make it work, but the yosys thing used wine and ProChips binaries to actually produce the .jed file I needed for the
  programming.  I tried compiling a previous example in WinCUPL but I couldn't even get it to compile before making it work in
  yosys, so that's almost the nail in the coffin for WinCUPL, but!
- now I need to figure out if I can do open collector outputs/tristate using yosys.  If I can't make it work, and I can't make
  anything else work that can make the bus output pins go high impedence, then I'll need to add buffer chips to *all* bus signals.
  I have no buffers on the SystemBoard design, and I only have then on the data and address lines for the k30p, I'd need at least 2
  more 16-bit buffers I think, to make it work, possible some extra independantly controlled buffers.  Given how little board space
  I have, I think at that point I'd need to abandon the A40/MD32 cycles

2024-09-05:

- got the digikey order:
- Vector CM10, $17 - adapters and handles kit without aluminum front panel
    - I'm not sure how it goes together, but it requires a specific aluminum front panel
    - would need to purchase it with parts that digikey doesn't seem to stock, so buy direct if possible
    - it's the fancy ejector handle, but it's probably not worth $17 + probably $15 for the panel
- Wakefield-Vette 3606330, $17 for 10 - plastic pcb-to-front panel bracket and screws
    - it's not the best quality
    - since it goes across the bottom edge, it interfers with the USB connector
    - comes with screws though
- Schroff 60807011, $4.12 - red plastic pcb-to-front panel bracket only (no screws or anything else)
    - it's much better quality
    - doesn't come with screws, which make it about the same price as the Wakefield ones
    - despite going across the front, it doesn't interfer as much with the USB connector
- Wakefield-Vette 3685198, $22.31 for 10, $4.46 per pair - metal PCB holder adapter
    - bit bulky, need more clearance on the board around the mounting holes, but works fine
    - no screws, so they're extra
- Vector HD102, $6.80 - full kit with small plastic right angle adapters for pcb-to-front panel
    - contains everything
    - plastic, so not as good as the metal ones
- Vector FP52B8HP-4, $28 - Front Panel Assembly, 3U 8HP
    - total waste of money
    - it's for a rear panel, so not a front panel
    - it has a cutout in the lower corner, but it doesn't seem to be able to take the ejector handles
    - it's basically just a cover plate, albeit a nicer one

- the metal ones are probably the least inspiring but best ones to use, next to maybe 3D printing similar ones
- the skookum kit with the ejector handles is really nice, but it's too expensive, so an alternative would be
  necessary, and it doesn't have the front panel.


2024-10-13:
- I'm getting close to the schematics for k30p-VME being done, but I have a few niggly bits.  I'm *just* short a pin or two for the
  CPLD.  I kind of need both the DS3-0 signals *and* the RAMSEL signal to make the ram work, or else I'd need an extra logic chip to
  AND together the DS1 and DS0 signals, and the DS3 and DS2 signals to provide the /CE signal for the chips.  That means getting rid
  of a signal, and I'm looking to get rid of the VME /BCLR signal because it's not necessary if the board only holds the bus for
  short periods.
- I also need to figure out what to do about the /RESET signal.  If you could make it so that system reset resets the boards but
  button reset only resets the one board, and if that didn't require the CPLD, then you could avoid needing a pin you don't have.
  I think it *might* be possible with a diode connecting VSYSRST to the capacitor-side of the Power-On-Reset circuit
- just thought that I need to look up whether it's the bus arbitrator or the board requesting the bus that asserts the /BBSY signal
  it's the bus requester that drives /BBSY so it's necessary for that to be connected to the CPLD (and I've removed it from the
  systemboard logic)

2024-10-14:
- I'm starting to lay copper and finalize the part's positions for k30p.  I have 4 bypass caps for the CPU on the opposite side of
  the board, behind the CPU.  It might save me board space for use?  Well not really in the sense that the backside could also be
  used as a single solid surface for copper traces, but typically they move vertically on the bottom layer, and horizontally on the
  top since the SMT parts are on the top and their pads are usually horizontal (easier to enter horizontally than vertically).  The
  buses that need to move horizontally are benefitted by the caps on the bottom instead of the top, but the traces going vertically
  would be on the backside, so caps on the front would be better...

2024-10-23:
- an important issue came up when laying out the board.  A0 doesn't exist on the VMEbus, which means I don't need to use that bit of
  the transceiver at all, but also, for the MD32 cycle, there's only 15 bits and not 16 on the address bus for the upper 16 data
  bits.  I've come across this before but I don't seem to have it in my notes yet.  The spec sort of covers it, but not in an
  entirely clear way without referencing a couple different tables.
- it uses LWORD to transfer one of the bits.  Rule 2.70 states this but only references the one of the bytes in the transfer.  It
  takes table 2-29 to see the bytes relative to the address and data signals
- it's not clearly stated, but the LWORD signal is only needed during the address phase potentially, so it might still be possible
  to use it to do an A40/D16 or A40/D8 operation, I hope, (I mean I can do it non-standard anyways since it's mainly the memory card
  that will use A40 cycles).  I'm trying to figure out if the A40 address modifier is always paired with the MD32 cycle.  I don't
  think it matters in either case because the CPLD will control the buffers

  Rule 2.70:
    When accessing Byte(0-7), LWORD* MUST carry the least significant bit of Byte(3)
    and A7 MUST carry the most significant bit of Byte(3). When accessing Byte(0-3) in
    MD32 Mode, LWORD* MUST carry the least significant bit of Byte(1) and A7 MUST
    carry the most significant bit of Byte(1). (See Table 2-29.)

- the table showing bytes mapped to buses matches what the MC68030 manual Figure 7-4 shows as the bytes to data bit mapping
  (basically, big-endian)
- So LWORD carries the least significant bit of Byte(1), which is D23-D16, so LWORD carries D16.  A7 must carry the most significant
  bit of Byte(1), which is D23, so A7 will carry D23.  A15-A8 will carry Byte(0), which is D32-D24

2024-11-02:
- I need a memory card, and I'm not sure if I should try using dynamic ram.  If I have a CPLD anyways, I should be able to do the
  refresh cycle, but it might take more work to bring up, and without it, I couldn't have two CPU cards coordinating, but it might
  be a while before I get there anyways

2024-11-16:
- k30p-VME is ready to be ordered more or less.  I should do final checks
- bigboy's front panels should be ordered
- I've modified the COMET CF Card to include the the additional AM[5:3] pins, and the card slot that I have (3M N7E50-Q516RB-40)
- I've ordered the Schroff PropacPro 3U 63HP 266D case from digikey, as well as some front panels with handles, should arrive in January
- I need to order parts soon


- for MemBird, the memory card, I was looking into memory and the 72-pin memory sticks I have don't fit the cards well.  They can't go
  vertically in the 100mm direction because they're too long, and they fit horizontally, but with less clearance to the connector than
  I have for the transceviers on the bigboy, so I'd have to put the transceivers below the sticks, and I really only have enough space
  with that for 2 to 4 sticks
- So I looked into DRAM on digikey, and there's basically not much older stuff.  The SRAM is pretty expensive, at least $20 for 8Mbit
  There is Pseudo-SRAM which is some DRAM inside the chip with a controller.  It's just on the verge of being possible, with the largest
  sizes of 32MBit and 64MBit.  For 128MB of ram on the card, it would take 16 to 32 chips, which would cost $80 to $160 in chips alone.
- Beyond that density, you get into SDRAM, which is available with parallel interfaces for $3.63 per chip for 256Mbit.  It would take
  4 chips to get 128MB for $14.52 total!  That then makes it possible to consider 256MB or 512MB, which would still be under $60
- the problem is that DRAM is harder to interface to with the clock and commands, and I'm not sure if I'll need more than just a latch
  for the data signals.  If I need a FIFO, I'd almost certainly have to go the FPGA route instead of an ATF1508, but that would also
  give me a PLL and the ability to read and write the ram faster than the VME bus timings.  Even the ice40hx4k with 107 I/O pins would
  be stretched to cover one RAM chip, and the VMEbus alone
- I could also make 2 boards, a big one and a small but fast/simple one with SRAM or PRSAM?

2024-11-17:
- Ok, so the more I think about it, the more I think I should make at least two memboards: one that's big and has all the features,
  which means needing programmable logic, and one that's completely static so it doesn't require a programmer to get started, at the
  expense of not have a lot of features or a lot of memory.  That means it would use SRAM and PSRAM for the small board, and no
  programmable logic chip.  I'd still like to support the A40/MD32 cycle, but D8OE + D16 would be enough, which are actually really
  simple to implement.
- I'll design the SDRAM + iCE40 board later because it will be decently complicated, but I could design the other one now
- I was thinking of naming them MemBird, with Raven being the biggest one using SDRAM.  The smallest one I could name either after
  the American Woodcock, which is also called a Timberdoodle, or I could keep with the Corvid theme and call it Magpie, Nutcracker,
  Crow (even though they're still kind of big), or after one of the Jays, even a Blue Jay being pretty small

- for the static logic board, I'd need to derive a chip select signal from the bus, using a comparitor for selecting the board from
  the address.  Technically I'd need a 16-bit comparitor if I wanted to support the A40 cycle, but I could get away with only
  populating 8 bits of that.
- I'd need bus transceivers, and for the 8 and 16 bit cycles there's no need to move data around, but if you support 32-bit
  accesses, then there would have to be a way of getting the upper two bytes onto the lower bus when doing a 16-bit operation
- the 32-bit cycle would require a latch for the address as well
- maybe you should make one without the A40/MD32 because it's going to require a lot of extra.  But maybe it's possible to have
  space on the board for both, with the ability to populate only part of it for people who might want to build it for a 16-bit
  computer that doesn't use 32-bit addresses

2024-11-24:
- I designed a 16-bit, 3.3 or 5V, SRAM or PSRAM, VME bus memory card.  It doesn't support the A40/MD32 cycle because I'm trying to
  make it quickly for the christmas break.  It won't support unaligned accesses either.  Only A24
- the VME spec says that dtack must not be asserted if the card doesn't support qword or unaligned operations, so I'll have to make
  sure to exclude those somehow
- what I'm not sure about is whether DTACK needs to be on a timer.  I definitely need to fix the fact that it's not
  3-stated/open-collector

2024-12-02:
- ordered 5 boards, k30p-VME, Aluminum frontpanel for it, MemBird - Woodcock, Alum. frontpanel for BigBoy, and Tom Storey's CF Card

2024-12-15:
- [writing a couple days later] I started the k30p-VME build this day.  It went alright, but there were issues with filming and
  issues with the board too.  The filming issues I'll comment about elsewhere, since it's not really related (sound issues with
  pulseaudio causing stuttering that affected the whole 4h stream).  The power issue was because the CPLD was unprogrammed and the
  /OE signals to the transceivers were therefore low, which caused them to write into each other, particularly the address
  transceivers since they are hardwired for the output-to-VME direction, and U15 and U11 will write into the same 16-bit address
  lines.
- I tried powering the board at first, and it immediately hit the current limit.  I tried increasing the limit bit by bit but I
  probably shouldn't have gone all the way to 1.8A because I knew that was way too much for the board to be drawing, and that might
  have fried something
- I felt that some of the transceivers were really hot to touch, so I tried resoldering those but it didn't help
- I also noticed that the clock was the wrong frequency, 16.66MHz instead of 50MHz.  I also touched up the solder connections on the
  CPLD, and that fixed the clock, but it broke again when I tried aligning the crystal a bit better.
- I realized that the transceivers were probably outputting into each other since the /OE signals coming out of the CPLD were low
  when it was unprogrammed.
- When I went to program the chip, it was giving an error that the chip was missing or not responding.  I tried programming the
  other SystemBoard that uses the same chip to verify that my setup was working, and I had the jtag connected right, but it still
  wouldn't work
- I tried resoldering the CPLD connections to see if that changed anything, and it then worked fine to program, so that was a
  relief.  I guess I just didn't have it soldered right, or had a pin bridged without it being noticable to visual inspection.  I
  might still have a faulty pin, but that will be harder to verify without rigorous testing
- with the chip programmed, the current draw dropped to 350mA which was still a bit high.  I figured it might be caused by water
  from washing the flux off, so I'll leave the board to sit for a day or two and check again

- I definitely need some better flux because the tacky stuff is annoying when debugging the board.  It's sticky and gets all over my
  fingers, which then makes my fingertips chapped and broken
- I need to find a better soldering technique too.  It took way too long to get the TSSOP-48s soldering right when going slow.  I
  had a bit better time when I loaded it with solder and then took it off with wick instead of trying to avoid the wick, but even
  then I wasn't sure about there being solder underneath.  Maybe I should instead do the sloppy solder and then follow up with hot
  air to make the solder flow better, or even just doing it all with hot air
- that said, I found the chips actually aligned quite well into the solder pads, such that they were somewhat captive in the up/down
  direction, and slid left and right a bit within the pads so I could get the chips in the middle-ish, without much difficulty

2024-12-17:
- powering on the board again, it's only drawing 250mA instead of 350mA
- I went through some of the logic and found a mistake with the dsack signals and a few others, where it's treating them as outputs
  instead of as open drain
- so I wrote a new CPLD program and the current draw dropped to 150mA, and at times is as low as 100mA.  That's much more in-line
  with what I'd expect, so again, I might have fried some inputs on the CPLD if they drew too much current
- there is still a problem where the transceivers start burning up when I program the CPLD due to those /OE signals not having
  pull-ups.  It would be nice to somehow reduce the number of CPLD signals needed, so I can do other things with them, but I'd still
  need to be able to turn all the outputs off (bus-off/high impedence) in addition to preventing them from both being on at the same
  time
- now I need to go through all the transceiver I/Os and check that each bit of each transceiver is working correctly

2024-12-20:
- I managed to bodge in some pull up resistors for 3 of the 5 transceivers, which should be enough to avoid conflict between them
  as long as the board isn't plugged into the backplane when re-programming the logic chip.  Luckily it went alright, but I didn't
  want to push it and try to get all 5 pull-ups in.  I got the rest of the things on the board, and tried it with chips in, and of
  course it didn't work first time.  The address strobe seems to be low during a reset, and then goes high for a bit before going
  low again, where it seems to stop, as if it's not getting the DSACK signals, even though those appear to be pulled low by the
  CPLD.  It's possible the logic is wrong, or it could be an issue with the pullups for the DSACK not being strong enough, although
  since they are actuating, I would have expected them to execute but incorrectly instead of locking up completely, so it could be
  a different issue.  I'll have to debug it more in detail, now that the board is cleaned

2024-12-22:
- So I plugged in the FTDI to USB and initially I had the board unpowered and that wasn't responding at all.  The connector looked
  soldered properly, so it wasn't that.  I looked more into USB-C and found a bunch of issues with how I wired up the connector.  I
  was expecting to be able to just connect the connector as if it were a USB 2.0 or something, but supposedly you're supposed to
  connect to both the A and B differential pair (jumping them together) which I had assumed would be done in the connector.  I also
  needed to add two pull-down resistors on the CC lines
- but I think powered the board and it enumerated fine *headsmack*.  Looking up the circuit I used from the FTDI manual, I wired it
  as a self-powered device, so once it was powered it worked.  Maybe reflowing the chip and letting it dry afterwards fixed it, but
  it seems to be fairly reliable now
- that said, when it's powered down, it loses connection, and miniterm doesn't close the session, which is annoying.  I should look
  into how to power the FTDI from the bus while still being able to power the rest of the board from its own supply.  With the other
  boards, I was powering them entirely from USB anyways, so I never had the issue of them disconnecting

- in testing the logic, I put resistors into the sockets to pull AS and DS high.  The DSACK signal were not changing state, and the
  chip select lines were low.  The logic was checking the request lines for high instead low as active, but it still didn't work
  when I changed it.  I used an interposing assign statement for the DSACK signals and that worked.  Yosys was giving warnings about
  the unworking logic.  It might have been caused by the fact that I had an always block, but the `inout` IO wasn't reg.  That
  seemed to make it work
- then the request signals weren't changing state as I expected.  The rom select was working, but the ram select wasn't.  It turned
  out to be a silly mistake.  The request signals were not routed to pins, so they were just internal regs.  The mapping was there
  but the top block didn't declare them
- with that, I put the CPU in, and could see it trying to fetch the first 8 bytes (the stack and reset vectors) from rom.  It
  stopped after that.  I would have expected it to run on for a bit
- I might have been touching the board at this time, which might have caused extra problems
- I put the ram and serial chips back in, and played around more.  It wasn't seeming to work and also the probe I had seemed to not
  be reliable anymore, but after a time, I saw that the A2 address line was changing, and then checking AS I could see it asserting
  a whole bunch.  I saw garbled output on serial, but then remembered that I was using 115200 baud, and these boards can only go
  38400 max, so I switched and it printed the Welcome message!!!  It still wasn't responding to inputs
- it seemed to be resetting or locking up.  It would print the welcome message and respond enough to echo 20 or so characters typed
  rapidly, but then it would lock up and not respond for a second or two, and then print the welcome message again.  The reset
  button responds when the chip is running, but when it's not, the reset button doesn't do anything.
- The reset lines is not changing state and the power is not sagging.  It's clearly not a momentary glitch that causes the CPU to
  reset because the reset button is not able to reset the chip sooner, and the boot message prints right away when it's reset while
  the CPU is running, so it's not the case that it just takes a while for the message to print.  The CPU is locked up somehow.  It's
  also likely not an exception since the reset would respond in that case
- another interesting observation is that the CPU doesn't seem to run on first powering up.  It doesn't print anything to serial.
  The tx LED comes on at the start, but nothing shows up, and it the tx LED doesn't flicker peroidically, so I don't think the CPU
  is resetting in a loop like it does otherwise.  I don't know how I got it running the last time, but maybe it's related to the
  lockup
- I'm not sure it's related but the first time this happened, removing the jtag for the CPLD fixed it, but this time that didn't
  work and the FTDI was behaving oddly.  Bypassing the 4-port usb hub I was using seemed to make it work.  I think it might be
  identified as a high speed device instead of a full speed device because of the lack of the necessary pull up/down resistor, which
  according to the manual should be controlled by the vsense line of the FTDI, but since the GPIO isn't programmed for that by
  default, I didn't hook it up.  That might cause the FTDI enumeration issues, but isn't likely to be causing the reset issue
- but that said, it doesn't reset loop otherwise

- touching the jumpers makes it glitch... do I need a jumper somewhere?
- jumping the jumpers doesn't seem to have an effect but touching around that area is causing it to reboot.  It's hard to tell what
  I'm touching.  When I try to just touch the jumpers or just touch the jtag connector or just touch the edges of the CPLD, it
  doesn't do it.  Touching near the 74HC14 seems to be doing something, the right side of it
- if I touch around the clock, it resets a lot and cuts off the welcome message, so that's not surprising.  Glitching the clock is
  making it reset of course
- by touching the right side of the 74HC14 seemed to make it work.  I can type things and the monitor responds with unknown when I
  enter garbage... why is it working now without touching the board.  I'm sure this is short lived
- if I put my finger on C19, it's more likely to work.  I'm not touching the CPLD, but I wonder if it's just not soldered well.
  It's the only chip besides the small logic chips that I didn't reflow
- it's really inconsistent.  Sometimes even just touching the board area between C19, the HC14, the jtag connector and the CPLD is
  enough to make it glitch.  It could be a solder joint somewhere, but since it's not consistent, I'm not positive of it
- when I had the issue with the RAM on the 68k-SMT, I was able to find the place where I could consistently make it work fine, and
  that was touching one of the RAM chips, but here it seems less consistent, and even if it's the board itself (which seems less
  likely because that spot was not exposed to heat), it's still not consistent even there

- I found the problem!!!  I think at least.  I looked up what pins were on the sides of those logic chips, and in looking at the
  schematic, I saw that the reset signal was wired to more than one gate, and I knew that there were two HC05 outputs that go to the
  reset and halt, but those were accounted for and on the left side.  There was a trace was going across the chip to another gate on
  the other side, and looking at the schematic, I saw that there was another reset input from the VME bus!  I had added that later
  in the process to ensure that a bus wide reset signal would reset all the CPUs, but since it's not plugged into a bus, that input
  to the invertor gate is floating
- at first I couldn't get the card to start.  I don't know what was going on.  I powered it up with a pullup for the VRESET signal,
  but the FTDI wasn't even enumerating.  I tried a bunch of things, but nothing seemed to work.  Touching the board, flexing the
  board, changing the usb port on the computer end.  Sometimes the FTDI tx light would be on solid, and sometimes it would not come
  on at all, but it wasn't enumerating.  I think a power down and up might have fixed it, but I don't know for sure.
- either way, now that the board is running again, if I pull up VRESET to high, it runs fine and never resets.  Even if I power
  cycle the board, it comes up working

2024-12-24:
- yesterday, I got the memory working by changing only the base state of the ram_ds signals, which should have been all 1s but was
  all 0s, and that got the ram working and the monitor running commands, seemingly without issue.  I tried loading data over serial,
  but the monitor wasn't running properly.  It was printing out all of memory essentially (ie. it looked like the problem where the
  null terminator check never passes, so it keeps printing characters past the end of the welcome message).  This problem happened
  with clang's experimental 68k support which doesn't correctly account for the fact that the MOVEA instruction is treated like
  MOVE, even though MOVEA will not update the flags register.  I assume it's compilation issue because the monitor in rom works
  perfectly fine, and the monitor I compiled and loaded over serial was from the gloworm repository that I last used to test clang,
  so I expect it's just something wrong with the compilation
- I tried to add the logic for the VME bus and get that loaded so I can at least test it, and at first I loaded an image into the
  CPLD that drew 500+mA, so something was clearly wrong, and the CPU wasn't running.  It took a while to figure out what was wrong,
  commenting out code and writing it until I finally noticed that it was having a fitting problem, and instead of giving an error,
  it just completely ignored my pin mappings, so it probably had two outputs driving into each other! *AAARGH*
- it turned out to just be the pin assignments were from the devkit and I hadn't fixed them, so there were overlapping pin
  assignments that caused the fitter to complain
- after fixing that, I was able to get the logic written, but didn't test it that much because nothing is being pulled up

- so I was going to solder on the VME connector, which I did eventually do before packing up, but I thought I'd test the FTDI change
  that I was planning to make to the next revision.  I cut the power trace to the FTDI and soldered a wire up to the ferrite bead to
  power the FTDI from the VBUS of the USB instead of from the board's power supply.  My hope was to prevent it from disconnecting
  when I powercycle the board.  I powered the board, and the TX light came on solid, and it wouldn't enumerate with the computer.  I
  tried resoldering the chip and restoring the power to VCC and I just couldn't for the life of me get it working again.  I have no
  idea what went wrong.  I might have fried the chip, or soldering the pins might have caused the problem.  I previously had an
  issue with it not enumerating, and I think reflowing the FTDI chip was what fixed it the last time, so maybe it just doesn't work
  properly when it's hand soldered with an iron, or I need more temp or something.  It was really disappointing.  I was so close to
  being done with soldering, but I guess I'll need to fix it somehow.  Worst case I have to put the headers on, pull the FTDI off,
  and just use an external one, but I'd like to avoid that if possible

- I'm starting to get burned out with this project.  I pushed myself to stream yesterday, and I was only going to do an hour, but I
  ended up doing like 4 hours in total, and not stopping until 10pm.  I should take a break, but I'm also just... compelled to
  continue futzing with the code side of things

2024-12-29:

- I streamed a couple days ago and tried to reflow the FTDI chip and resolder it to no avail, so I removed it and put the the header
  on, and am using the external one which more or less works fine without losing connection every time I power cycle, which is a
  lot.  I didn't bother putting those streams on youtube, partly because it was broken into two separated by dinner, with one
  session only 10 or 15 minutes, and I didn't want to put them up as two and didn't want to make a combined version. I guess in
  future, I can pause the recording and stop the stream to take a dinner break

- today I've been testig the logic and adding the systemboard to the mix.  Most of it has been minor things to make the bus cycles
  work properly, but they were already sort of working.  I have the logic analyzer on the control pins of the bus, and the scope as
  is out as well.  After loading a new logic into the CPLD, I can reset the CPU and load a monitor program that makes some VME
  accesses after printing the message, but before the prompt shows.  I later made a command to run the test so I can pre-load it and
  run the command at the same time I start a logic analyzer sampling
- I had various issues with signals not being tri-stated, and the bus arbitration not working because I had disabled it in multiple
  places and forgot that, so just tracing the whole pin from usage, through the top level block, pin assigment and schematic if
  necessary, which caught a few minor things
- I previously had found that I had the logic wrong for combining active-low request lines.  I was ORing them but I should have
  ANDed them instead, so request_vme was never going low (active)

- I was able to verify that the address on the bus during the access is correct, and initially the data bus was empty, but the CPU
  bus had the data, so the transceiver was off.  I changed some things and got the data to appear on the bus, but now it won't
  terminate the cycle ever, when it should...  I also notice sometimes when resetting or running the tests that it doesn't reliable
  enter a known good state (some accesses are flakey and sometimes it seems to access when it shouldn't).  I have the system board
  acting as a simple dummy peripheral, and between the two there's something wrong with the logic it would seem

2025-01-01:

- the systemboard's logic with the additional dummy peripheral had a bunch of problems, including reusing the same `state` register
  for two different state machines, which well could have caused my problems, but I might also have an issue with flip flops and
  timing of the state machine such that it was really inconsistent.  I replaced it with just `assign` logic instead of a clocked
  block, and it's working quite reliably on the peripheral side, but it still locks up sometimes which I suspect is an issue with
  the k30p's logic.  Given that the simple logic peripheral is working better than the state machine one, I'm more confident that
  the MemBird Woodcock card will work, since it uses simple logic.  I'm glad I added that DTACK timer too, so I have that in my back
  pocket

2025-01-02:

- I streamed the build of MemBird - Woodcock rev.1 and the soldering went really well, quick and straightforward.  I was expecting a
  lot of struggle, but it seemed to go together in about 2h or so, maybe less.  I didn't have a lot of bridging, only a bit, and I
  was able to fix it quickly with solder wick.  I was using the new No Clean liquid flux (instead of the tacky stuff), and it worked
  great.
- I did have issues getting the board working though, that I still haven't resolved.  It did seem to work the first time, writing a
  value read back the same value, but as I tried playing with it more, it seemed to not be working quite right.  One issue was
  definitely a mis-soldered chip, where it was raised up and a bunch of pins on the right side (of the top 74HC32) was not
  connected, and fixing that change the behaviour a bit, but it still isn't working as expected.  Sometimes data would read back as
  0xAAAA or 0x5555 from locations that weren't supposed to have been written, when I was trying to write 0xAA55, and I was expecting
  the unpopulated chip areas to read back as 0xFFFF or 0x0000, but that wasn't always the case, although random data could be
  expected from those unpopulated areas.  But I was sometimes getting 0xAAAA or 0x5555 from those locations, which really doesn't
  make sense.  It could be bugs in the k30p that's reading and writing though
- I also noticed that BERR and DTACK were both being asserted when only DTACK should be asserted.  The k30p is ignoring BERR from
  the bus at the moment, so it wasn't causing problems, and trying to inspect it specifically didn't seem to reproduce the issue, so
  I'm not sure if it's a problem.  I'll have to maybe get BigBoy to control a transfer to inpect it more closely

2025-01-12:

- I've been looking into my RAM issue where it seemed to hang when accessing the upper part of RAM, but after fiddling with it on
  and off for the last week, I finally figured out nothing is broken and I forgot that the ramtest is using words, so the ram size
  is words, not bytes.  I changed the ram test to shift the ram size used in the loops so that I don't have to re-remember again
- in the process of debugging, I thought I could assert BERR to find the actual address where the fault occurred, but that didn't
  work because the VME A40 request was active for anything that wasn't addressed locally, but since the A40 request is ignored by
  the VME logic, it didn't start a request and the status LED didn't light, so I thought it was something else blocking
- since the CPLD doesn't have access to the upper address lines, it can't know if the 00xx_xxxx space is being accessed.  It can
  only know about the FFxx_xxxx space, which it assigns to the A24 address space.  If any other request is issues, if it's
  xx0x_0000, then it will always access ROM, and if it's xx1x_xxxx or xx2x_xxxx, then it will always access RAM.  Any spaces in that
  memory map will access A40.  This is a pretty significant design flaw

2025-01-13:

- just a note from previously, I tried increasing the clock speed to 25MHz and it seemed to run and printed out the welcome message
  but whenever I pressed a key, it read in two NULL characters instead of the correct key, so something is not quite right with it.
  It's still dividing the 50MHz clock down to 25MHz, and since it's going through the CPLD, I was hoping that would clean it up a
  bit, but maybe not.  I'll have to look into it more.  The 50MHz clock is not very clean, but 12.5MHz clock from the CPLD looks
  decent.  I feel like I had the same issue with computie k30 when I swapped the crystal, but I don't know what the fix for it was
  at the time.  Hopefully I wrote notes about it (looks like I didn't)
- if you put a right angle toggle switch for power on the front of the board (I guess bottom frontpanel would be easiest), then you
  could power off the board when it's in the slot, and pull it out without powering off the whole backplane.  It's probably only
  useful for CPU cards and might be more hassle in routing than it's worth, but would be a nice feature

- it turned out removing the request_vme_a40 signal in the logic made it not correctly assert DS[1:0] on the bus.  It was stopping
  shorting after the DTACK signal was asserted rather than waiting until CPU_AS *stopped* asserting.  I'll have to look further into
  the cause
- also, with this cpu card, a jumper between b5 and a9 (bg0out pulled to ground) is enough to make bus arbitration work without the
  system card in place, which is convenient because I can program the CPLD with little extra current draw if the system board is not
  connected, but it draws *1.7A* if I have it in.  It must be something with the logic on the system card because having the memcard
  in doesn't draw that much more

2025-01-14:

- after investigating the "code won't run from membird card" issue, I looked at the fatal error code and found that it was pushing
  all the registers on the stack, which pointed me to the real exception number, and it turned out to be a Line A exception, so it
  executed an 0xAxxx instruction, but there isn't code like that in the monitor I tried to run from ram
- the logic analyzer traces looked fine
- I went back to the vmebus test in the monitor which just copies a counter number into ram where the number stored corresponds to
  the address, and then had a check function that tested the ram after.  It worked fine with 16-bit transfers, so I tried writing as
  8-bit transfers and read it back as 16-bit transfers, and after a bunch of minor mistakes I made in the code, I was able to
  confirm that the bytes were swapped
- I looked closely at the logic analyzer traces.  I looked at the schematics for the memory card, hoping it wasn't an error there
  because it's harder to fix than if it's in the CPLD.  The LDS and UDS signals look correct on the schematic, and looking at the
  traces shows DS0 was going low, and the byte being written to was the odd byte, and that's correct according to the spec and to
  what the 68000 does, so it seemed all good there
- I tried making the test program only write the even bytes, and looking at the traces, and the printed words read back, it was
  writing the odd bytes, so looking at the vme_interface.v logic, I saw that when address bit 0 is "true", it will assert DS1 and
  not DS0, but that's backwards, so I made it `vme_address_0 == 1'b0`, and everything's working now
- I can run code directly from the VME card.  It acutally seems to run at a decent speed, albeit with the CPU clocked down quite a
  bit.  It also takes about 1A instead of 500mA when it's running off the memory card, which is quite a bit of power in signaling,
  but it seemed pretty stable...  I need to try it at a faster speed now