log.txt

2020-08-14:
- the serial issue turns out to be a problem with the crystal for the serial chip.  It is outputting an inconsistent signal around
  100kHz when powered through USB or power supply.  When powered by the arduino, you have to unplug and replug the serial usb cable to
  make it work, which seems to reset the oscillator.  Connecting a 22pF capacitor across the crystal jumpstarts it, but the output is
  a lot lower on the scope with it connected.  The datasheet says to use 15 and 5pF which is pretty low, and I don't have caps that
  small.  I have to play with it more, but this seems to be a cap issue more than anything
- [2022-01-08: this turned out to be the caps.  Using the correct cap sizes as listed in one of the MC68681 documents of 5 and 15pF
  fixed the issue, and I haven't had any trouble with the serial since]

2021-02-04:
- I found the cause of the gap in between the text segment and the data segment only when .data.rel.ro is included.  There are
  two different values for the page size (common-page-size and max-page-size).  Setting both to be 0x10 removes the gap.  The
  code in the default linker script causing this is: `. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE))`

2021-01-21:
- I've narrowed down a strange bug that affects running the shell (with integrated programs) as a standalone executable.  There
  are two different results, and the appear to be different bugs.  The one where the computer locks up completely is caused by
  an access to non-existent memory, and forcing a bus error would force a fatal exception which gives the address where it
  occurred.  It occurs when doing a strcmp when finding a command in the command list.  I noticed the command list size was
  smaller than the number of commands, but I'm not sure if that was the cause of the actual lockup.  I haven't been able to
  reproduce it, but I've had trouble reproducing it in the past, so I'm not sure it's fixed yet

  The other result that occurs with similar attempts at reproducing causes a "Line 1010 Emulator" fault.  The exception is caused
  by executing an instruction starting with hex A (this exception is not documented apart from the name in the user manual for
  the 68000/68010).  This fairly reliably happens after the following commands are entered separately:
    ls; ./sh; ls; exit; ./sh; ls

  After adding more information to the user error dump, and fixing the process memory map so the text segment data is accurate,
  I was able to get the exact offset into the text segment that the exception occurs at, so I can follow along in the object
  code.  The text data in memory at that address is clearly overwritten with data, which is being executed as code, causing the
  exception.  The data written to the text segment is a series of what look like addresses; 42 x 32bit addresses where the
  addresses are either between 0011ABED-0011AD1E or 001183DC-0011913A and alternate between an A series and 8 series address,
  and the last two 32bit numbers are 0.  The program data is correct before and after that chunk, so it's just that bit that
  gets overwritten.  I'm not sure yet what's causing it, but it's something memory-related.

- I put some debug statements in the kmalloc/kmfree functions, but nothing stood out there.  So I took a break and as I was
  getting ready for bed, realized the pattern in the data.  It's probably the command list being initialized on startup.  Each
  command has two pointers (the name, and the function address).  There are 20 pairs of addresses, plus two 0 entries terminating
  the list, and all the addresses are within the text segment.  The question now is why the address of the list itself is pointing
  into the text segment.

- The issue turned out to be incorrect loading of elf binaries.  The code was assuming a single program segment but the shell is
  has 2 load segments, with the second one containing the .bss section (which wasn't included in the memory map), and when the
  strftime() function's static names are included, it adds a large gap between the end of .text and the start of .data.rel.ro
  which would account for why the command list address was well beyond the allocated block


2021-01-05:
- I'm not sure how I'd like to implement drivers in general.  The conventional unix way is to have 3 different types of drivers,
  tty devices, block devices, and network interface drivers.  I tried to implement the tty and serial drivers separately, with
  their own driver entry points, instead of doing it the conventional way.  I'm not really happy with the specific way it's
  implemented at the moment, but it works for now.  The plan is to use the serial for both the tty and the network interface,
  which is why I'd like to make the serial driver independent of the tty driver subsystem.


2022-02-07:
- for the past two days I've been trying to fix a problem with the k30 board that came about all of a sudden.  I was working on
  the compact flash issue, and in the process had gotten the monitor to properly program the onboard flash so I could update the
  the interrupt handler to get better debugging info.  For some unknown reason, the board suddenly stopped working, no serial
  data, no booting, no nothing.  A quick check with the oscilloscope showed the CPU was running and executing instructions, but
  clearly it was malfunctioning in some way
- checking around at signals and everything seemed correct except for the RAMSEL signal, which was unusually low.  The signal is
  produced by the output of an AND gate, which takes two inputs from the 3-to-8 selector.  One of the driving signals rung out
  but the other didn't and I tried resoldering the lines, to no avail.
- I've now noticed that things seem to be working, but and the output at the chip is close to 5V, but its first stop is an
  inverter gate, and at that point it's dropped to 3V or so (the exact same level as at the 40 pin connectors, since I had a
  probe on each).  The measured resistance between those two points is in the megaohms when every other signal is close to 0.
  I also tried measuring one of the signals from the selector to the AND gate input and it's 300 ohms, which is also suspicious.
- I have a hot air station on order, so with that I will be able to get the chip off entirely to inspect underneath.  I'm not
  sure what might be causing the electrical issue, since the joints seem fine, but the traces run under the chips (the HC08 and
  the HC14 for the AND output).  Everything seems fine from the selector until the via before it goes into the HC08, hence why
  I'm thinking there might be something under the chip...

- hooking a logic analyzer up to the RAMSEL, ROMSEL, AS, and the upper address lines shows that the RAMSEL line is going low
  sometimes at the same time that ROMSEL is low, so I think that's what causing the conflict, but I have no way to test further
  without getting that chip off.  The address lines are different (and kind of bizzare) when the SEL lines are both low, which
  kind of seems weird even for the ROMSEL to be low, but either way, I think the RAMSEL going low is incorrect based on the
  address lines, rather than the ROMSEL being incorrect.  The DS3-0 lines are always active for all requests, so it's only the
  RAMSEL line that controls whether the RAM chips will respond or not.  The RAMSEL also triggers the DSACK1 line, turning the
  request into a 32bit one, which could also corrupt the transfer

2022-02-10:
- after getting a hot air rework station, I managed to get the 74HC08 off and there is no connection between the traces and
  the pads.  It looks like it's solid, but there is a slight dip at the edge of the pad, and there's continuity in the traces
  just up to the pad but not on the pad itself.  Having the traces enter from the other side would definitely help because I
  could more easily bridge them, but being under the chip makes it very difficult and even putting solder on the joints with
  the chip off still wasn't enough to bridge the gap.
- it's possible that there was some kind of unintended bridge between some of the traces which causes the traces to overheat
  and that was likely the weakest point in the trace, since it was coming out of the pads at a sharp 45 degree angle (no real
  turn length, just straight out at 45 degrees).  I think having at least a short trace coming out of the pad before going
  45 would have helped here.
- I ended up fixing it by making sure those pads were disconnected and then soldering a wire from the RAMSEL pin on chip 74HC14
  to the SEL1 trace that would have gone into 74HC08 as one of the inputs.  This means I'm limited to only 1 MB of memory, but
  it seems to work now.

- I noticed there was also an issue when pressing the reset button, where RAMSEL and also ROMSEL (but not the others) having a
  strange high frequency signal on it while the button is pressed.  I'm not sure what's causing it.  It could be some kind of
  interference from the clock signal, but I didn't investigate further

2022-02-20:
- finally took another look, and the wire for DSACK of the ATA device came off, so I have to resolder it.  Before that happened,
  I was able to confirm that the DSACK lines are working correctly according to the oscilloscope, but any measuring devices on
  that DSACK line can upset things.  It doesn't even appear to change on the logic analyzer because it doesn't go high enough
  before the CPU detects it.  The dips switches were also all ON instead of OFF, and after switching that, I was able to confirm
  that the timeout is working (4 cycle setting takes about 0.2uS while 16 cycle setting takes about 0.8uS), but the numbers on
  the data bus roughly seem to correspond to the data being read (0x0B and 0x15).  I confirmed that the data on the card is
  not what's being read in, so there's something else going on.
- Once I get the DSACK-ATA line reconnected, I should check to see that the CS lines on the flash card are changing correctly
- line seems ok, although it stays low after it tries to go high, maybe something else is trying to drive it low because
  of a short?
- I could try hooking up the compactflash to IDE thing to see if I can get it working offboard (I'm not sure if it's a design
  or construction related fault)
- could the logic levels be an issue?  The 68030 might be producing lower outputs than the 68010

2022-02-21:
- finally some progress.  I hooked up the CF-to-IDE adapter to an arduino and was able to confirm that reading from the card
  works, even with a request that lasts less than 200ns.  I hooked it up to the k30 board and at first it didn't work, but
  tying /CE0 to ground and /CE1 to +5V resulted in the data being read!  Those lines are normally connected to the address
  lines A4 and A5, but for some reason, that isn't good enough for the CF card
- it might be possible to fix this by permanently cutting those wires and tying them high and low.  It worked to have /CE1
  connected to A5 and tying /CE0 low, but after cutting the trace and holding a ground wire to it, that didn't work.
- There   may still be some kind of fault with the IORD and IOWR lines still.  They didn't seem to change state when the card
  wasn't in the slot, and they seemed to recover slowly when I tested it a few days ago, so I'm not certain
- trying to load the kernel failed because for some reason it was trying to read sector 2-3 instead of 0-1, and a few bytes
  seemed to drop out, but I didn't look through the code so it might be a mistake from when I was last testing

2022-02-22:
- soldered in the jumpers for /CE0 and /CE1, cutting the traces to the address lines and!... it fails, either illegal
  instruction or it hangs when setting 8-bit mode.  This problem hasn't quite happened before.  No idea what's going on
- looking at some other designs, there's an RC filter on the IORD line and resistors on the data lines.  I could try using that
  for the external card reader.  It would be kind of tricky to put on the board CF socket though...

2022-12-20:
- I built the hardware the day before in about 4 to 6 hours this time, much faster than last time.  I used the flat tip to solder
  the logic chips first, then the big SMT chips.  I'd get a small bit of solder, almost none, on the tip, tack a corner of a chip,
  and then just touch the tip to all the pins without applying any additional solder.  I almost never needed to take up excess
  with the solder wick, which sped things up quite a bit.  I had the logic chips done in less than 2 hours, which was the majority
  the work.
- I used a cpu with a couple pins bent up to see if it would be an issue to solder, but i was able to push them down with the flat
  tip of the soldering iron.

- It didn't work at first, and so I checked the power and clock.  The clock was not quite right, although my oscilloscope was also
  set incorrectly.  I had taken the clock chip from the dead board and put it on the new board, but changing it for a new crystal
  fixed the issue, so maybe the problem on the old board had been the crystal all along and not the 74HC14.

- With the clock sorted out, it was giving the monitor screen, but booting from what I thought was the boot loader in rom didn't
  work, and loading the kernel over serial didn't work (hanging).  After some playing, I found that that boot loading could be
  sent and booted over serial and it loaded the kernel on the compact flash first try, everything working!
- more experimenting with the fact that commands didn't work in the monitor when it was loaded over serial, I was able to find that
  printing numbers with printf was what caused a hang or something.  More playing found that it was strlen itself that wasn't working
  correctly, because commenting it out made it work incorrectly but without hanging.  Putting a putchar in the loop fixed it, so
  obviously the difference must be an optmization.  Using volatile for the counter in strlen fixed that issue, and now the kernel
  can be loaded over serial, boot, and mount the compact flash drive.

2023-05-28:
- I pulled out 68k-SBC Rev.2 again because I'm trying to confirm some test cases on real hardware, and the SBC board is the only one
  that can take a 68000.  I only have DIP-64 ones.  I've bought some 68HC000s in PLCC form that I can use in the SMT board.
- I played around with the flash, writing a newer monitor to other parts of memory, but it was reading back incorrect data when I
  power cycled the board.  They did sort of work, but I didn't trust those chips.  They were AMIC A29F040s (recycled).  I tried
  replacing them with SST29F040s but they actually need a different address to erase and program the chips, so rather than change
  that, I just swapped in some clearly relabelled AM29F040s, and used the 68kSupervisor Rev.2, with the mods but using the
  68kSupervisor arduino sketch instead of the k30FlashWriter.  It all seemed to work without issue, which I was surprised by given
  that it's been a while since I last touched this board.  I think the firmware was from 2021
- I updated the arduino programs a bit, and should update the monitors
- Now, in order to run tests, I need to be able to write to the lower memory, which means mirroring the ram to bank 0 instead of the
  flash, which I can't do using the jumpers, I guess because it's too fast, so I'll need to make some external circuitry to switch
  between them.  I can even trigger it through software by hooking it up to OP2 on the bus connector

2023-07-06:
- I hooked up the k30 to Fidget and got nothing out of one USB, and all "D"s out of the other.  I should have verified which was
  which sooner, because the one with the "D"s I thought was computie but was actually Fidget.  That was the data coming out, but
  actually I had the wrong speed, so it was actually a string of 0s with 1s occasionally, which is also wrong... The verilog is
  probably still buggy and wrong, but that means the USB serial with nothing is computie.
- I realized it was probably related to DSACK, but at first I was thinking it was related to a logic error on fidget, where instead
  of using separate I/Os to control the control signals transceiver, I used a single invertor gate, which meant Fidget would have
  been driving those signals when trying to receive on the others (problem...)
- I took off the logic gate and soldered a bodge wire to the pad and wirewrapped the other end to one of the pins on the extended
  I/O headers, so I can at least control, but that didn't fix the fact that it wasn't booting
- I put the scope on the DSACK0 line and saw some of the normal weird sawtooth signal, but it only lasted a few cycles until it went
  high (stopped).  Taking the ribbon cable off on the fidget side made computie run but fill the screen with garbage input.
  Removing it from the computie side made it work normally, so just having the wire connected is enough to increase the capacitance
  or something enough to make DSACK fail
- I had this problem with the arduino I think, where it wouldn't run when the arduino was connected, so I had to remove it.  I need
  to somehow figure out how to fix that.  I'm not sure if it's interference with the serial chip's DSACK, because it's otherwise
  some HC logic gates driving that pin, which shouldn't be slow to rise.  It could be related to the pull up resistor size though.

- After doing some more testing, if I put a 1k resistor across the pull up for DSACK0, it will work fine with the ribbon cable
  connected to computie but not fidget.  Connected to Fidget I had to put the resistor on DSACK1 to make it work, and then it would
  boot fine.  So definitely, for future versions of computie, I must use smaller pullups for DSACK0/1

2023-07-09:
- I installed two 2.2k ohm resistors across the 10k ohms resistor network for DSACK0 and DSACK1, on the underside, in a way that
  doesn't add height beyond the pins of the resistor network.  It's showing about 1.7k on both pins now, and with the wires
  connected for DSACK0/1 to Fidget, it's working without hanging the computer, so I think 2.2k would be fine for the next revision.

2025-02-08 [from gloworm log.txt]
- I brought out the k30 and 68k-SMT boards to test the builds on those. [...]
- the k30-SBC just wouldn't do anything, and then it would print the welcome message but not the prompt, and then it would print the
  prompt but not accept characters, and then it would accept characters but hang when enter was pressed.  Finally I tried a
  different USB port instead of the one on the monitor stand, I used the on connected by the USB3 type-A extension cable and it
  worked
- I was eventually able to get both builds of the kernel and monitor running on them with the ATA drivers using the CONFIG_ATA_BASE
  select as the only difference, so the new build system should work with those boards

2025-02-16:
- I tried getting the k30-SBC board working again, and had the same issues as above, but I didn't read it until now, and realize I
  found a fix of sorts.  I thought it might have been flux damage, and there is some.  I cleaned it off but I'm sure resoldering
  some of those connections will help too.
- but yeah, it works on the other USB port.  I wonder if it's voltage or something.  I honestly didn't check voltages (thou shalt
  always check voltages), but I didn't...  The clock worked fine and CPU was running and executing code, but was having trouble with
  serial communications, possible due to dtack problems.  I maybe didn't clean the flux off well enough from my DSACK mod
- it's not booting off the CF card.  Not sure if this was also a problem earlier or not.  It hangs after reading the ram disk
- maybe I did, but I had to add back in the ATA_DELAY(10); line in the ATA read sector code?  Maybe something else because that
  didn't work
- adjusting the timings to what they were before doesn't seem to fix it and I didn't record whether I got it booting or not.  I 
- Oh, I'm using the wrong base address for the CF card because I'm using the wrong config.  I even noted that in the other log.  I
  have now copied over that line as well.
- 30th's time's the charm, got it boot when I finally had the correct ATA_BASE
- and interestingly enough, it's doing the same thing as it does on the k30p-VME when it's running at 25MHz... so maybe this is a
  software issue and not the k30p's logic

[from retroverse logs]:
- I'm kind of getting sidetracked now, I tried to compile the kernel without -O3 in order to test if the optimizations are causing a
  problem, after reading in the computie logs that I had to add a volatile to strlen in order to get the monitor working previously
  because otherwise it was hanging.  It's very possible a similar thing is happening here with the kernel, so I thought it would be
  quick to check, but then I ran into a problem with undefined fwrite, which is almost certainly related to the wrong object files
  being added to the lib because it compiles both versions of libc.  The only place that fwrite exists that would cause the
  undefineds is in fputs, which is used by fputs in os/ but not in none/
- I compiled it with just the kernel and it worked without errors because it was monitor that had the problem
- trying to load it over serial caused the k30 to reset and run the monitor and start printing out the data instead of reading it
  in.  It was working before I used the unoptimized kernel.  *sigh*  I feel like I had this recently with one of the 3 boards I've
  been playing with
- ok I just checked and it's 100% because the kernel overflows the size that the load script handles (16-bit length) so it loads the
  first ~0x1800 bytes and then boots, but there's more data to send, so I need to keep that in mind now that I have such a big
  kernel.  I could modify the format to use a 4 byte number instead, but I guess I'd have to upgrade the roms on the other boards?
  I'd rather not use a backwards compatible mechanism.