log.txt

2022-11-??:
- during PCB design
- actually, you can use the single 16-bit flash chip, the 29F800, because you can't write data to it without the special
  programming sequence, so using all 16-bits all the time is fine because it'll only be for reading...  [so long as you can write
  16-bits at once, which is possible here]


2022-12-23:

- The CPU sort of seems to be working, and fetching what it should sorta, but the arduino is a bit too slow I think to respond in
  time, and the attempt at setting the timing config on reset doesn't seem to work
- I've got the memory on, and the CPU out, and there's a problem accessing memory addresses.  It seems like the A4 line is stuck
  to something.  It can't be pulled low or high, and instead wants to float around 1V

2022-12-24:

- I somehow rotated the footprint for the flash chip, and mounted it the wrong way around when I soldered it, which would explain
  why it was heating up a huge amount, and also why A4 was stuck.  Wire A4 is connected to pin 22, which is labelled A3 on the
  pinout for the M29F160F chip.  With it rotated, that pin is actually Vss, and power is probably reversed or something.  I'll
  have to take the chip off and rotate it to fix it, but I'm not sure if I'll try to reuse the chip or not
 
2022-12-26:

- I rotated the flash chip and resoldering it, and it seems to work.  It hasn't been 100% stable but I think that might be the
  solder connections not being entirely perfect, and not damage in the chip.  It seems to hold its memory.

- I now have an issue with the arduino resetting when I press the reset button on the board...  It seems to be related to touching
  the resistor beside it.  If I use a pencil to hit reset, it isn't a problem

- It seems the latch enable input is not inverted, and I somehow didn't see that when designing, and if I had, I would have needed
  an extra 74HC14 or a single extra inverting gate, to invert /AS to get the latch input... It's going to be a bit tricky to bodge
  in a fix.
- without this, it tries to access an address where the lower byte is the data it's supposedly reading in, and not the latched
  address.  I found this by writing all 0x76 to flash, which is the HALT instruction.  When running, it would indeed halt
  after reading in two bytes.  I'm assuming the second byte read in was caching or something?  It might have even read the wrong
  first byte, before reading in the second as 0x76.  I then jumped /DS to /WAIT so that it would wait immediately when fetching
  the first instruction, and leave the address on the bus, and data on the data bus.  But 0x76 is on both the bottom of the
  address bus and the bottom of the data bus, and the latch enable line is high (/AS is not asserted), but that means "LOAD", so
  it's acting as a transparent buffer for the data bus...

2022-12-27:

- I cut the trace from /AS to the LE pins of the latches, and soldered a wire to one of the latch pins, with the other end soldered
  to the unpopulated alternate clock crystal and resistors.  I'm reusing one of the currently unused inverter gates that was for
  that alternate clock.  It provides a much easier place to solder onto.  The other side of the gate is wired to /AS by directly
  coming off the throughhole PLCC socket's /AS pin, and going to the other crystal throughhole pad.
- It seems to work correctly now.  I used the hack of connecting /DS to /WAIT to pause on the first instruction, and the address
  bus has 0 on in now, and the data bus has 0x76 (since I still have all 0x76 in memory).
- I then tried loading a proper program into memory and run with the logic analyzer.  It seems correct so far.  The program is
  supposed to jump to 0x80 from 0x00, and then execute the 0x76 halt instruction.  It performs two memory cycles to get the first
  jump instruction (0x9 non-cacheable transactions instead of 0x8 for some reason).  It then performs a refresh followed by two
  0x9 memory cycles, and then halts with 0x03 and everything after that is refresh cycles (0x1).  For whatever reason, when
  previously executing the halt on boot, it was also fetching twice before halting.  The main difference here is that it executes
  a two-byte jump instruction.  Now to try some more complicated programs, although I still don't have access to RAM because of
  the MMU and the 64KB limit

2022-12-28:

- Ok, so yesterday I tried putting a big delay in the code and moved it around, and found that it seemed to execute, and there was
  likely the "fatal condition" (section 6.6 of the technical manual for the Z280) occurring at some point before the normal
  end of the program.  I had a bunch of issues wrong with the MMU initialization code, which I mostly resolved
- I noticed the instruction hex I expected to see wasn't there, for `LD C, 0xF4` to load the I/O address, and long story short it
  seemed to be the assembler, z80asm, which wasn't generating the correct opcodes, so I switched to sdcc's asxxxxm (sdasz80), which
  produces more accurate code it seems
- with the new assembler, it seems to be executing as expected, and running into the fatal condition around the time the MMU is
  enabled, but when I commented out the actual OUTW instruction to enable the MMU, it didn't halt right away, but also didn't keep
  issuing bus requests the way it normally does when running the delay loop that was after the MMU init.  It instead had a bunch
  of refresh cycles only, and then halted.... so I'm not entirely sure if it ran the delay or not

- Ok, what if I can make some other status condition appear to distinguish where I'm at in the code from the logic analysis alone.
  I can make an EPU instruction which has it's own status codes for EPU transfers, and to do that I need to enable the EPU bit in
  the Trap control register.  It seems to work, in that I get a status of 0xD twice, but according to the docs I shouldn't get that
  code twice, I should get a 0xD followed by a 0xC.  Maybe the status 0 bit is stuck on?  It pretty much always stays on except for
  some glitches
- turns out channel 0 of my logic analyzer is busted.  Good thing I had a spare.  They are just cheap 24MHz ones

- with some fixes to the MMU initialization code (the word needs to be backwards in HL, because the byte order is reversed when
  writing it to the I/O port), it now passes the MMU enable and runs to the normal halt
- Since it seemed to get to the UART code, and I know I need to initialize the timer to get it to work, I took a look at the docs and
  got some values to set for the three Timer1 registers, and checked some signals with the scope.  There wasn't anything on the
  timer1 pins, no surprising because it was set to use an internal gate and trigger, so I looked at the RX pin on the serial
  port (which is the host rx, device tx), and saw a blip of data!
- the waveform looked right, so I set the scope's decode, but what I thought should be 115200 was closer to 38400, but not quite.
  I adjusted the timer counter value to 27 instead of 26, and that seemed to get it working pretty well at 38400.

- I got it to print "Welcome to Bread80!"!!!! I used the existing loop, but it was writing too fast, and there is no FIFO on the
  UART, so I added some code to wait and check for the buffer empty flag before writing the next character, and it worked!
  Now I have serial

- many issues with the MMU.  I tried going over things to find errors, and tried a `ld hl, #BBE0` instruction to initialize the MMU
  control register instead of two instructions with h and l separate, and that seemed to change something, but it would instead run
  and never print the message or halt, so I figured something was up with the page table.
- I tried initializing the table manually, and that seemed to work.  It turns out I only had 15 entries in each table instead of 16,
  so when it wrote the end of the user page table, it would be off by one starting the system page table, which messed everything up.
  Adding the missing entry now puts ram exactly where I expect it, and data can be written to it

2022-12-30:

- UART is working for sending, seemingly without glitches, but receiving seems to cause glitches.  With the parity set, it mostly
  detects the errors as parity errors, but there are still some undetected glitches, which I don't know the cause.  The crystal isn't
  quite right, but it's within four 9s which seems to be withing the 50ppm for the crystals, and I get glitches fairly often, one in 50
  characters or so.  I'm not sure what's going on with that.

- I got it compiling C, and copied most of the monitor code and some libc code from Computie to get a basic firmware working.  Loading
  doesn't work, nor does boot/jump, which are the most critical features.  But I can dump data from the CPU
- that said, dumping the rom shows FFFF FFFF for the first 4 bytes of ROM pretty reliably, even though the arduino reads it correctly
  (albeit with 2 NOPs inserted), and it seems to boot fine, although I guess it might still work since the rest of the code until the
  proper start is just NOPs so it might still work...
- that is indeed what's happening.  I put a halt instruction at 0x7F, just before the normal start, and it halts without printing
  anything, so it is likely reading the first 4 bytes as Fs.

- from what I can gather with the scope, the scope itself is having trouble interpreting the bits correctly when probing anywhere along
  the rx line, but works perfectly when disconnected, and just the computer is transmitting.  It also seems to work perfectly when
  the characters aren't being echoed, but when it's transmitting and receiving at the same time, it gets garbled...
- is it crosstalk between the tx and rx lines?  an electrical fault?  Or is it something in the uart?
- there's no electrical continuity, but I suppose there could still be capacitive coupling

2022-12-31:

- testing the Rx line with nothing connected didn't show the interference, but connecting the USB cable, without it connected to USB
  did show the interference!  Even if only GND, TX, and RX are connected there would be interference, but it didn't seem to do that
  when only one of TX or RX were connected at the same time.
- I tried a USB to serial adapter without a cable, and the crosstalk mostly disappeared, but the glitches in the data are still there,
  so maybe it's not an electrical fault after all...
- I tried not echoing the data being typed in, but printing the whole line when enter is pressed.  That avoids any interference when
  sending and receiving at the same time, and still shows what data was actually read in.  Since the data send back is still glitchy,
  it's not receiving it correctly, and the data that is transmitted doesn't actually get decoded by my scope correctly!  That implies
  that the transmitter (and thus receiver as well) is not timed correctly or something.  I did have an issue with the stop bit being
  set to 2, but changing that back doesn't seem to fix the issue

- ok, after a bunch of playing with settings in serial and the scope, and checking the clock pulses, I'm pretty sure the preload
  value for the timer should be 71, which produces almost the exact frequency, off by 3Hz or something... but I'm still getting errors,
  despite the electrical looking rock solid...  The data coming out or doing in looks like, especially when they are done one at a time,
  and even then there are errors.  The data being sent out is exactly the form of a detected error, (0xF5 which is a parity errors, and
  some 0xF9 and 0xFD which is frame error, and both parity and frame error.  Never overrun error though.  At the moment I'm pretty
  stumped

2023-01-01:

- so I started to dig into trying to use an external clock source for the serial, and there now seems to be a new problem related to
  memory access or something...  I spent quite a bit of time trying to debug the serial issue and it was printing garbage instead of
  the welcome message, but it turns out there's some issue with using the stack.  Everything seems to work fine if the stack isn't
  using, but using the stack is now causing values to be read that aren't what was written, and I can't yet rule out if it's the
  compiler or something else
- In order to isolate the serial issue, so I could put that to rest, I modified the welcome.asm file to loop between reading a
  character and writing a character using jump instructions to switch between them, so as to avoid using the stack.  I was able to get
  a simple echoing program working, although I had to fiddle with serial settings a bit.
- I tried connecting a clock with a 3.6864MHz crystal, which if divided by 32 (UART config = 0xE4) will equal 115200 baud.  I have
  two clocks, a series and parallel circuit.  The series one was a bit slow at 3.6862MHz and the parallel one was a bit fast at 3.6869MHz
  The error on both of those clocks is more percentage-wise than the main board clock, which runs at 22.1166MHz when it should be 22.1184
- surprisingly, the external clock worked perfectly.  I could copy a large chunk of text and have it transfer without a glitch!  So it's
  something to do with Timer1 I guess.  It's just not reliable.
- I tried various configurations and verified that at 115200 baud using Timer1 from the CPU clock would still glitch, so an external
  clock source is seemingly the only way to make this work.  That would be easier to patch into the board if I hadn't already patched in
  the fix for the latches that uses the inverter gate of the alt clock =/


- now to figure out this stack/ram issue... It seems remarkably consistent as if data isn't being written when it should, and the same
  values are read out of ram... A flakey wire would likely produce a different message every time, but it's identical, just complete
  nonsense.  It seems to even be consistent across power cycles, so maybe it's even a compiler error

- I was able to compile the welcome.asm file with the current serial settings, and it actually worked fine, the message printed
  successfully.  It seems to be an issue with the monitor only at this point, although it might also be because the welcome program,
  while it does require the stack to call functions, it only needs the top of the stack, whereas the monitor program writes a fair
  amount to the stack.
- I tried the previous commit's monitor code and it also prints garbage instead of the message, so I feel strongly this is a hardware
  problem, although that could include a problem with the flash chip not storing its program
- There is definitely data written to the stack by the monitor, and it seems correctish, but there still could be a stuck address line
  still, which only affects the program after using more than 32/64 bytes or something (I still suspect A4 a bit)
- one of the easier things to try would be to resolder the memory chips.  It could be the flux that I didn't clean off which has
  corroded something, or flexing the board when removing the 40-pin connectors.  I might as well resolder the arduino shield while I'm
  I've been having a lot of flakyness with power supplied through the arduino

2023-01-03:

- Well resoldering the memory chips didn't fix the problem.
- There were generally some problems with the arduino not reading data correctly from the rom chip, and holding the address/data
  connector down seemed to help, so I resoldered a lot of the pins on the shield, and that seemed to fix the issue where it wouldn't
  write because it thought the rom wasn't erased, or the erase command didn't work properly
- the symptom was a bit odd though in that it showed mostly 0xFFFF but with some values that matched the original rom values in their
  expected places, as if it didn't erase everything, but it did erase most of the rom.  I'm not sure what would cause that behaviour

- as for the serial printing issue... it seems to print a consistent message instead of random data each time it's reset, or power
  cycled, so I suppose it's still reading data in ROM, but it has the wrong memory location.  But I can't seem to find the sequence
  of data in ram.
- at the moment, the sequence is 0x16, 0x17, 0x18 to 0x2B, then 0x13 followed by a space, and 0xD7, 0xD8.  This is oddly specific
- the first sequence up to but not including the 0x13 is exactly the same characters as the welcome message, and it's printed using
  puts, so that last 0x13 is the extra linefeed character (should be 0x0A) that's printed with putchar().  The space and the two 0xD7,
  0xD8 characters are the "> "prompt, so they should be 0x3E, 0x20.  So it's as if everything is working correctly except for putchar,
  which is a naked inline function, but the disassembled code all seems correct
- it's as if either the arguments passed to putchar are not fetched or passed properly (which doesn't seem to be the case from the code),
  or there's a test mode enabled on the serial where it prints sequential characters, but it seems like only a FF or 00 code can be sent
  as a test parameter

- It turns out the calling convention is through registers, so the value I was taking off the stack wasn't right.  It could have been
  related to changing putchar and getchar to use `int` instead of `char` but it was working before then
- Using the registers for putchar fixes the printing of the welcome message, so it uses the correct characters, but getchar is still not
  working, and there definitely seems to be another glitch because it will either constantly reboot and print that welcome message, or
  just start printing garbage... it's very strange and still feels like a hardware issue

- I forgot I had upgraded my computer on the 31st, and that upgraded SDCC from 4.0 to 4.2, which might somehow explain something??
- I tried downgrading the compiler and that didn't seem to fix the issue.  It was still producing garbage, and now it seems to keep
  printing junk, as if there's a hardware glitch =/

- ok, so it was totally not working and dumping screenfuls of garbage through serial, but when I disconnected the arduino and powered it
  through the serial converter, it prints the welcome message correctly and reads in data seemingly correctly, but if I enter a command,
  it resets back to the welcome prompt... maybe that's another error
- welp... it seems to work now.  I had forgot it was running because it's powered through serial atm, and noticed it was still sittng where
  it had been without new data coming in, so pressed enter and said Unknown Command and gave me a prompt!  It seems to be working now,
  at least `help` and `serialtest` work properly.  No idea why it didn't work when I first tried it, and why it was resetting constantly.

- it's mostly working, as long as it's not through the arduino.  It occasionally glitches when the wire for the clock is bumped, so I
  should maybe do something about that.  That said... if I had an ATF chip to install, I could derive the serial clock from the cpu clock
  possibly?  Well the CPU clock changes sometimes which might be what causes the issue.  I'd need to take an output directly from the
  main clock

- there is now an issue with printing numbers, possibly a C type or optimization issue

- it's back to acting up.  It prints the welcome message but if you press enter, it's as if it resets, and prints the welcome message
  again.  If you run `help`, it prints a line of garbage and then the command list.  The hardcoded test command works but every other
  command causes a reset.  Didn't I have this problem earlier?
- Nope, I just forgot again that I need to disconnect the arduino from the board or else it crashes, maybe undervoltage, because I get
  low voltage from the arduino unless I press on the board, which works for a bit until it doesn't.  This has been a persistent issue
  and I'm not yet sure if it's the arduino's pins or the shield's pins, but just using power through serial without the arduino is a
  workaround for now


2023-01-04:

- I managed to get the ATF1504 programmer working, but I just noticed on the schematic that the CTIN1 pin is connected to an input-only
  pin, when I need it to be an output, in order to feed in the input from ALT_CLK.  That said, I think I could possible leave that pin
  disconnected, and just patch a wire on the bottom of the PLCC socket from ALT_CLK to CTIN1.  I still have to use an external clock
  because I'm still reusing the clock's inverter, and I didn't add the latch enable signal to the CPLD because it was just AS.  It's not
  that easy either to get the LE pin from the top of the board to the PLCC pin on the bottom.  I could maybe install it when I put the
  socket in, but then I won't be able to fix it if the wire breaks =/
- oh, as it turns out, I have a header pins connector for CTIN1, so I can at least hook up the serial clock with the CPLD in place, so
  I don't need to patch the board.  I don't know what I'd use the CPLD for though either...

- if you had an FPGA board that could interface as a device, it could provide the RTS/CTS signals, or even just be a whole serial
  controller

2023-01-05:

- interesting, when I hooked it up for the first time this morning, directly to serial without the arduino, and without resetting first
  I pressed enter in the terminal and it printed the welcome screen.  Pressing enter again showed Unknown Command, but a few more presses
  and it showed the welcome screen again, and a few more times.  After about 10-20 enters it's only showing Unknown Command now.  That's
  a bit worrying that it can sometimes reset.  It seems to be related to warming up, or something, but either way, there's still a
  hardware glitch lurking in here somewhere

- I left it on for a while, and it sat there happily not doing anything, until I pressed enter again and it started printing the welcome
  message and prompt over and over again as if it was immediately resetting after each print.  I couldn't get it to stop at all until
  I started touching around the latch enable bodge wire and the left side of the left most latch, where the high byte of the data bus
  is connected.  I could get it to sit at the prompt, but pressing enter would make it loop again, until eventually holding my finger on
  the data bus side of the latch and pressing reset, and then pressing enter finally got it to stop and actually execute commands (print
  Unknown Command).  Pressing enter again puts it into a loop, but holding the latch will fix it
- I resoldered the databus (left) side of the high byte (left latch), and that seems to have fixed the glitches.  It now always prints
  Unknown Command, but I need to give it some time to see if it starts glitching again.
- the pins didn't look cracked or disconnected or thin on solder.  They were a bit dull, but otherwise looked pretty good, so I'm not sure
  why it was a problem.  Again, it's a bit disconcerting that things can look fine, but still be glitchy =/
- after a few hours, it's still stable and working properly

- It should be possible to write some code to erase the flash and rewrite the monitor to flash, but the CPU can only access 64K at once,
  so it's cumbersome to write the whole chip, and besides, the serial doesn't seem to like it going too fast, so it's slow to copy data
  over.
- that said... if I used the interrupts, that might speed up serial enough to be somewhat useable
- but really, I separate serial controller would be best, one with RTS/CTS and a FIFO
- the CPLD is kind of pointless with the I/O assignments its has, other than to just test ISP of an ATF chip