Claude .

[paulca]

Tried claude code.

Uploaded the full project code in a zip.  Asked it with about a 200 word prompt to create a UI for a use case.

Claude generated a full "reply zip" in 100 seconds with code, tests, documentation.

Trouble.  It missed a nuance in the design and miss placed the functional code.

I corrected it and it generated another full release zip.

Unfortunately, while useful it again missed a small but critical detail making the design not quite there.

I explained at some length, finally got it to understand the requirement and how it properly fitted into the architecture... I ran out of session limit.

You see, writing code has NEVER been the hard part, it is not how I earn my salary.  Turning human requirements into code, in light of existing muddy, evolved "brown field" systems is.  This is where AI struggle.

However I believe this is a limitation of "context" size.  Which is a function of time, complexity and hardware costs.

[paulca]

Honestly it behaves exactly like a junior engineer.  Keen to produce output but not keen to ask, "But... what if." or "do the requirements even make sense?"

Resulting in just as much delay when that happens with real "ape" juniors.

In a tech lead role.  If I assign a task to an engineer and do not field a dozen questions, I think something is wrong.

[Siwastaja]

The strength is exactly in that it does not require perfect formal specification (writing that it colossally hard - if you had that, you would be more than halfway done anyway!), but is like a super-inspired trainee who has good imagination, never says no, doesn't know how to ask the right questions, and does whatever they want filling in gaps.

... and that is also the main weakness.

[paulca]

The strength is exactly in that it does not require perfect formal specification (writing that it colossally hard - if you had that, you would be more than halfway done anyway!), but is like a super-inspired trainee who has good imagination, never says no, doesn't know how to ask the right questions, and does whatever they want filling in gaps.

... and that is also the main weakness.

LOL  Indeed.  When Claude opened the chat with "getting to know you".

I stated my intent for it.

"I have chosen you as my new yellow duck that can talk back.  May we create well together."

Just to test it could still reason and chat.

I treat it like that, like a VERY knowledgeable peer who I can run ideas by, get valuable input and then still choose to completely ignore or more often, reform their output into something that works.

EDIT:  Tangent -  I'm trying to explain to the cat right now that if she could just use the toilet then she wouldn't need to go out or ask to be let out.  Somehow this relfected back on my experience with AI.  Communicating the concept is the hurdle, not her ability to understand or execute it.

[paulca]

On a similar reflection...

AI understands code just as it understands English... or rather, it understands neither.  However code is FAR more unambiguous than English and between developer and AI code is the better common language.

This is why I choose Claude on multiple recommendations and was encouraged to see that it seems very quick to talk to me IN code and we mutually understand faster.  This is the "talk code back to me" interface I wanted.  I just need to tell it not to attempt to generate "full" solutions as I will likely ignore them.

[paulca]

Another observation.  When it has the full code and still repeatedly makes the same contextual error.

It's not it's fault.  It suggests that your code is ambiguous or hard to follow.

In my code case the "responsiblity" of monitoring temperature and deciding whether a "Request" for heating is required kept being lost.  That "action" also associated meta data which can be used by downstream services to help decide, however, those down stream components NEVER decide on temperature and only decide on valid "ON" verus "OFF".

The code it gave me for "Override zone temp via a UI for a period", resulted in it raising a "request" for that period and adding a "target_temp" to the message.  The net result would be the same as, "I want the heating explictly ON in Zone X for period".  Not the same as tracking a temperature for a period.

It took a while to draw it to reality, that the metadata is the "I have decided", not the "You will decide" information, it's after the fact, not input logic.  The downstream prioritises to deconflict based on the requests intended target, such that a higher target over rules a lower one for METADATA.  The request for "ON" is still a request for "ON" no matter if you say it was targetting 20C when the actual is 23C.  It's only informative that the request was already raised off the back of Target > Actual.

In my code this is very "implicit" and hard to follow.  Not it's fault, but the code in there is deeply nested in polymorphism and bi-directional abstraction, so no... a new comer to the project would not immediately see it.

There is a lesson there already.

[Siwastaja]

Another observation.  When it has the full code and still repeatedly makes the same contextual error.

That is totally typical to AI. They are as stubborn and fixated as the most stubborn and fixated human beings ever. Like top-0.01% in fixation. I sometimes use AI to help with problems outside my core expertise (e.g. SQL) and sometimes they nail the right solution easily for a complex problem, and sometimes when I need just a little bit syntactical help in a trivial matter they get initially a totally ridiculous answer and no matter how much I point out it's incorrect and just for fun, try to point them in the right direction, the answer is just along the lines "You are totally right, let me fix this... <insert same bullcrap slightly modified in some irrelevant place>"

This fixation is probably one of the biggest issues still in vibe coding. If you happen to get a right solution, then good for you. If it has issues in small details, AI will easily fix them with a few iterations and it can feel like fun. But when it gets fundamentally lost, you can't fix it even if you are able to spot the mistake and know well how you would guide a human being in the right direction.

[DimitriP]

Tried claude code.

Uploaded the full project code in a zip.  Asked it with about a 200 word prompt to create a UI for a use case.

Claude generated a full "reply zip" in 100 seconds with code, tests, documentation.

Trouble.  It missed a nuance in the design and miss placed the functional code.

I corrected it and it generated another full release zip.

Unfortunately, while useful it again missed a small but critical detail making the design not quite there.

I explained at some length, finally got it to understand the requirement and how it properly fitted into the architecture... I ran out of session limit.

You see, writing code has NEVER been the hard part, it is not how I earn my salary.  Turning human requirements into code, in light of existing muddy, evolved "brown field" systems is.  This is where AI struggle.

However I believe this is a limitation of "context" size.  Which is a function of time, complexity and hardware costs.

It could have been worse.
You didn't have to wait a long time , and you only run out of session time.
With a human you would have to wait a lot longer and run out of money 

In the early days of web search engines, some people could zero in into "good results" better than others because of their choices of keywords and some sort of intuitive method of picking the good links instead of having to click on each one.
Those people could "speak search engine" .

With AI chatbots, something similar is going on, the phrasing of what you want seems to matter , although it shouldn't , but I also believe it's how it works in real life.
So I came to the conclusion that some people can "speak AI" better than others.

Just like @paulca mentioned

Turning human requirements into code, in light of existing muddy, evolved "brown field" systems is.  This is where AI struggle.

.  Some humans do it better than others.

[Siwastaja]

With AI chatbots, something similar is going on, the phrasing of what you want seems to matter , although it shouldn't , but I also believe it's how it works in real life.
So I came to the conclusion that some people can "speak AI" better than others.

Maybe a bit but... I don't think I agree with this, generally. What AIs are surprisingly good at is understanding poorly formed questions and guessing your true intent from horrible explanation. It seems like magic. And, if they get it wrong, it is very hard to get on a right track by forming the question differently, which I think is indicative that the quality of the response is not limited by understanding the question, but actual capability in knowledge and deduction required to construct a good answer.

I think what you say is more like a response from AI fanboys as an easy argument when the almightiness of AI is questioned. It is similar to, if one is using newest ChatGPT and getting bad results, fanboys say "oh you need to use this older version, it was better!", and if you are using older version, fanboys are saying "Oh you need to use the newest version", or maybe you need to use Claude, or if you use that, you need to use Grok instead. In the same vein, if your productivity is not increasing 20-fold with AI assistant and you question the idea of that being realistic to begin with, you are just being a grumpy old technology hater who doesn't know how to write good AI prompts.

I have seen absolutely no evidence or examples that there is a significant art of "prompting AIs right" to utilize them better. Of course with any tool how it is being used matters, but this is obvious. But with LLMs I think this is less of a case than with most traditional tools - also a strong good point for them!

[DimitriP]

I didn't use the phrase "write good prompts" because examples that I've seen feel too superficial to me.
Maybe it's because metaphorically speaking, I'm using all its powers to open jars and clean up the kitchen afterwards rather than asking it what I should eat and have it cook me a meal.

[dobsonr741]

Paulca — did you actually use Claude Code (https://www.claude.com/product/claude-code), or was this a single “ask Claude” prompt?

The Claude Code CLI can do far more than what you’re describing. It doesn’t just generate code — it can compile it, run it, diagnose build/runtime errors, install missing tools, and generally bootstrap and maintain a working dev environment.

The role shift for software engineers is real: the work moves toward clearly specifying what needs to be done, with which tools and environments, what tests should exist, and what success/failure looks like. You can drive Claude to do this top-down: make Claude to start with a project plan, break it into sub-components, design each piece and document it, implement and test them independently, and only move forward once builds are clean and tests pass.

For MCU projects, it can even monitor the serial port and react to runtime output. How far you push this depends on how strong you are as the domain expert. If you are the expert, you can drive it very hard; if you’re not, it will still guide you toward best practices.

Context size on the latest Sonnet models is up to 1M tokens, so yes — expect some token cost. Using OpenRouter gives you pay-as-you-go flexibility and lets you experiment across models without heavy commitment. In my experience, Anthropic models are currently the strongest tools for serious coding work.

[KE5FX]

Exactly... which model are we talking about?  Opus 4.5 is a big step forward, but I don't know what to expect if you just hand it a zipfile.

[Siwastaja]

The role shift for software engineers is real: the work moves toward clearly specifying what needs to be done, with which tools and environments

(emphasis mine)

So we have increased complexity of tools and environments for the past 20 years to the point it is really difficult and slow to "bootstrap" a project in nearly any given "best practices" workflow / framework / environment.

And we have reached a point where helper tools are not helping but making managing these processes even more difficult, to the point we need an AI assistant to now get us past the setup and maintaining of the tools, to doing the actual work. (And of course, we ask it to do the actual work as well.)

I find it ironical that now that we have the AI which supposedly can do pretty much anything, why would we still prefer to specify it needs to use those certain tools and environments we cannot manage anymore (but think should be used for, maybe, social reasons)? Why not let AI choose? Or, specifically, if vibe coding anyway (iteratively prompting for more work), why not ask for a solution with least amount of dependency to external libraries, tools, frameworks or best practices, and instead ask for, say, C code, or maybe even better, target assembly? So could we maybe use AI also to simplify our workflows instead of adding yet another new layer of complexity?

[tggzzz]

Response 1: don't be so sensible.

Response 2: wait 5 years, and there will be such a wealth of LLM generated content inhaled by the next versions of LLMs that it will all have sorted itself out. Won't it?

Most people realise that current LLMs aren't good enough to replace you at your job, but that is irrelevant. LLMs only have to be good enough to convince a C-level manager that LLMs can replace you.

If that sounds like "LLMs are the revenge of the incompetent", you may well be right

[SiliconWizard]

As I said recently, the more problematic part is not whether LLMs will replace you, but whether you'll be able to afford any kind of electronics device in the coming years at all, except maybe the most limited ones, due to the wide semiconductor hoarding triggered by "AI". I know you said it was probably just temporary and a bubble, but I'm not sure about that. When big investors have thrown billions at something, they're not keen to just let it go even if it turns out to be bad investment. And, since you are showing concern about longer-term consequences of LLMs, then that tends to show that you're not so much convinced the bubble is going to burst anytime soon.

[paulca]

I had a non-code session with claude, using it to free form design my 68000 CPU board.

I like how you can tell it you are along for the journey and discovery, not reference and copy what others did.  It played along for several hours until I was narrowing in on some solutions. 

The primary topic was "ROM Shadowing" at boot.  It was only when "we" had gone around many different options and back again did I let it give me a quick summary of what other 68k systems did.

It turns out that didn't help me at all.  It was just a list of the same options we'd gone around and in some cases (Amiga) way more complicated miss-mash of different shadowing/overlaying and address rewriting.

As I mentioned "Verilog simulation" as a test method I employ for these things, it just started describing the logic gates in Verilog syntax which sped things up quite a bit.

We bascially got through design and allowed me to make some decisions for a change.  The only thing I still can't "see in my head" yet is the ROM shadowing flipflop gating.  I can read what we discussed and Im sure what is there will work, but I can't "see it my minds eye", can't hold the solution and rotate it, turn it inside out and back to front yet.

I might need to breadboard it first to do that, don't know.

[tggzzz]

As I said recently, the more problematic part is not whether LLMs will replace you, but whether you'll be able to afford any kind of electronics device in the coming years at all, except maybe the most limited ones, due to the wide semiconductor hoarding triggered by "AI". I know you said it was probably just temporary and a bubble, but I'm not sure about that. When big investors have thrown billions at something, they're not keen to just let it go even if it turns out to be bad investment. And, since you are showing concern about longer-term consequences of LLMs, then that tends to show that you're not so much convinced the bubble is going to burst anytime soon.

Timing is everything w.r.t. investing, and I'm not good at that.

Analogies from the past: touchscreen controls in cars. Clearly a dimwitted and dangerous idea for controls that need to be adjusted while driving, but it has taken a decade or so for car manufacturers to start trumpet that newer cars won't have those.

[Siwastaja]

Analogies from the past: touchscreen controls in cars. Clearly a dimwitted and dangerous idea for controls that need to be adjusted while driving, but it has taken a decade or so for car manufacturers to start trumpet that newer cars won't have those.

It's also that listening to consumers is really difficult. The thing is, every time something a little bit disruptive is done, people complain in masses. And yet, sometimes it just needs pushing the thing down the throats for a few years, people stop complaining and start actually liking it. Touchscreen smartphones are an excellent case study, for the first 1 year or so there was near consensus they are total crap and will never replace tactile phone buttons. ... and yet, nowadays almost no one, not even me, thinks that way anymore.

But, it is now turning out that car manufacturers went way too far with touchscreening everything, and all those consumers and car journalists with near-100% consensus that it's total crap turned out to be right anyway, and don't start liking that. So manufacturers are finally giving in.

But it was hard to be sure. If you have been doing the aggressive touchscreen design for many years already, are you sure you want to give up now? In some ways, it is "safer" (for the business) to keep doing that for a while until you are both sure people didn't want that, and also that the novelty is gone, so that you can introduce traditional controls as something fresh.

[paulca]

Obviously touchscreens are cheaper than tactile knobs and buttons.

So while consumerhood rejects them and I agree with them as I have touchscreen in my car.  They will now also pay a higher price or have many less controls.

Worse, I expect they may go to "shuttle wheels" and the like "One control does everything and you STILL have to stare at the screen, not the road to operate them.

[tggzzz]

Analogies from the past: touchscreen controls in cars. Clearly a dimwitted and dangerous idea for controls that need to be adjusted while driving, but it has taken a decade or so for car manufacturers to start trumpet that newer cars won't have those.

It's also that listening to consumers is really difficult. The thing is, every time something a little bit disruptive is done, people complain in masses. And yet, sometimes it just needs pushing the thing down the throats for a few years, people stop complaining and start actually liking it. Touchscreen smartphones are an excellent case study, for the first 1 year or so there was near consensus they are total crap and will never replace tactile phone buttons. ... and yet, nowadays almost no one, not even me, thinks that way anymore.

But, it is now turning out that car manufacturers went way too far with touchscreening everything, and all those consumers and car journalists with near-100% consensus that it's total crap turned out to be right anyway, and don't start liking that. So manufacturers are finally giving in.

But it was hard to be sure. If you have been doing the aggressive touchscreen design for many years already, are you sure you want to give up now? In some ways, it is "safer" (for the business) to keep doing that for a while until you are both sure people didn't want that, and also that the novelty is gone, so that you can introduce traditional controls as something fresh.

It was in the manufacturers' interests to look the other way (ho ho) and to avoid being sure. Manufacturers sold "new shiny", and journalists could get paid for writing about "new shiny", and punters neither thought nor knew history.

s/touchscreen/LLM/ and s/punter/C-level executive wanting a bonus/ and the same is happening with LLMs.

[paulca]

I was bored, so I cloned a 68k softcore (fx86k) and used claude CLI.

I ended with "> can you summarise our session and put it into a session1.txt file? "

Here it is - note.  I did nothing except tell it what I wanted and poked it occasionally with hints.  Asides the PCB test bench seeming to take 1000s of seconds, to run, it looks like it works.  Time will tell.  This took an hour and I think I can now use it for more detailed architectural proving and experiment.

Code: [Select]

fx68k APIO Integration - Session 1 Summary
==========================================
Date: 2025-12-25

GOAL
----
Get the fx68k (68000 soft core) running in APIO for open-source FPGA development,
with simulation support and memory chip models for PCB-level simulation.

ACCOMPLISHMENTS
---------------

1. APIO Setup
   - Created Python venv with APIO installed
   - Installed OSS CAD Suite toolchain (Yosys, nextpnr, Icarus Verilog)
   - Downloaded sv2v tool to convert SystemVerilog to Verilog
     (required because Yosys/Icarus don't fully support SV structs)

2. SystemVerilog Conversion
   - fx68k uses unpacked structs not supported by open-source tools
   - sv2v converts the SV to plain Verilog successfully
   - Fixed sv2v output issue: wire->reg for task output ports (subResult, subCout, subOv)

3. Synthesis Results
   - iCE40-HX1K: Too small (4850 LCs needed, only 1280 available)
   - iCE40-HX8K: SUCCESS - 63% utilization (4850/7680 LCs)
   - Max frequency: 57 MHz (passes timing at 12 MHz target)

4. Simulation
   - Basic testbench (fx68k_tb.sv) working with `apio test`
   - Test program executes NOPs and BRA loop
   - Added write cycles to verify RW signal transitions

5. PCB-Level Simulation
   Created memory chip models:
   - mem/sst39sf040.sv : 512Kx8 NOR Flash (for boot ROM)
   - mem/as6c4008.sv   : 512Kx8 SRAM (for working RAM)

   Created PCB module:
   - pcb/cpu_pcb.sv    : Top-level board with CPU + memory + address decode
   - pcb/pcb_tb.sv     : Testbench for PCB simulation
   - pcb/rom_hi.hex    : ROM initialization (high byte)
   - pcb/rom_lo.hex    : ROM initialization (low byte)

   Memory Map:
   - $000000-$07FFFF : ROM (512KB via two SST39SF040)
   - $100000-$17FFFF : RAM (512KB via two AS6C4008)

   Address Decoding:
   - A20=0 selects ROM
   - A20=1 selects RAM
   - UDS/LDS select high/low byte chips

6. Build System
   Created Makefile with targets:
   - make build     : Synthesize for iCE40-HX8K
   - make test      : Run basic CPU testbench
   - make sim       : Run test + open GTKWave
   - make pcb-test  : Run PCB simulation with memory
   - make pcb-sim   : Run PCB sim + open GTKWave
   - make clean     : Remove generated files
   - make setup     : Initial environment setup

7. Git Configuration
   - Renamed origin to upstream (github.com/ijor/fx68k)
   - Set new origin to git@git:fx68k.git (local server)
   - Created .gitignore for generated files

FILES CREATED
-------------
.gitignore
Makefile
fx68k.pcf              (pin constraints for iCE40-HX8K)
fx68k_tb.sv            (basic testbench)
mem/sst39sf040.sv      (NOR Flash model)
mem/as6c4008.sv        (SRAM model)
pcb/cpu_pcb.sv         (CPU board module)
pcb/pcb_tb.sv          (PCB testbench)
pcb/rom_hi.hex         (ROM high byte init)
pcb/rom_lo.hex         (ROM low byte init)

GENERATED (in .gitignore)
-------------------------
venv/                  (Python virtual environment)
sv2v-Linux/            (sv2v tool)
fx68k_all.v            (converted Verilog)
fx68k_tb.v             (converted testbench)
hardware.json/asc/bin  (APIO build outputs)
*.vcd                  (waveform dumps)
pcb/pcb_converted.v    (converted PCB module)
pcb/pcb_sim            (PCB simulation executable)

TEST PROGRAM
------------
The PCB testbench runs this program from ROM at $000100:

    MOVE.L  #$12345678,D0      ; Load immediate to D0
    MOVE.L  D0,$102000         ; Write to RAM
    MOVE.L  $102000,D1         ; Read back from RAM
    ADDQ.L  #1,D0              ; Increment D0
    BRA.S   *-20               ; Loop back

This exercises:
- ROM reads (instruction fetch)
- RAM writes
- RAM reads
- Address decoding between ROM and RAM regions

NEXT STEPS
----------
- Refine address decoding/glue logic
- Add peripheral models (UART, timer, etc.)
- Create more comprehensive test programs
- Add interrupt handling tests


[paulca]

It got so far before it let me down.

It's seemingly has difficult understanding a memory IC can be both 1M x8 at the same time as 512k x16.  Even when I gave it the datasheets.

This kinda screws up the next question I had for it.  "Do I need/want to bother with UDS/LDS (or BYTE mode) supported on the ICs so that the CPU "8bit mode" works.

If it's going to be convinced that the AS6C8016 is a 1Mx16bit chip that aint going to work.

What I'm going to try ... having a solid rollback point...  ask it to update the Verilog PCB simulation with those RAM chips.  Part of me expect it to try and fail and then see why.

EDIT:  I see the issue it's having.  The tokens like "MB", "Mb", "M" are highly likely to get confobulated with "A byte is 8 bits".  Especially as it tells me: "Tokens remaining before compression 0%".  I might change the termonology to "word" and see if that helps.

Might need to pick a smaller ask of it and lead it in smaller more confined scopes, especially when RAG'ing datasheets.

[paulca]

I think this might work.  Ask it to start with a verilog module for the datashseet, which it looks like it got right this time.

Now for the Flash chip and then the memory decode module.

Code: [Select]

User approved Claude's plan
  ⎿  Plan saved to: ~/.claude/plans/stateful-whistling-swan.md · /plan to edit
     Plan: Create AS6C8016 Memory Module

     Summary

     Create mem/as6c8016.sv - a 512K x 16 bit SRAM simulation model based on the existing mem/as6c4008.sv structure and the AS6C8016 datasheet.

     Key Differences from AS6C4008

     | Feature      | AS6C4008         | AS6C8016          |
     |--------------|------------------|-------------------|
     | Organization | 512K x 8         | 512K x 16         |
     | Data bus     | 8-bit (DQ0-DQ7)  | 16-bit (DQ0-DQ15) |
     | Address      | A0-A18 (19 bits) | A0-A18 (19 bits)  |
     | Byte control | None             | LB#, UB#          |

     AS6C8016 Truth Table (from datasheet)

     | Mode            | CE# | OE# | WE# | LB# | UB# | DQ0-7 | DQ8-15 |
     |-----------------|-----|-----|-----|-----|-----|-------|--------|
     | Standby         | H   | X   | X   | X   | X   | Hi-Z  | Hi-Z   |
     | Output Disable  | L   | H   | H   | X   | X   | Hi-Z  | Hi-Z   |
     | Read Low Byte   | L   | L   | H   | L   | H   | DOUT  | Hi-Z   |
     | Read High Byte  | L   | L   | H   | H   | L   | Hi-Z  | DOUT   |
     | Read Both       | L   | L   | H   | L   | L   | DOUT  | DOUT   |
     | Write Low Byte  | L   | X   | L   | L   | H   | DIN   | Hi-Z   |
     | Write High Byte | L   | X   | L   | H   | L   | Hi-Z  | DIN    |
     | Write Both      | L   | X   | L   | L   | L   | DIN   | DIN    |

     Implementation Steps

     1. Create new file: mem/as6c8016.sv
     2. Module interface:
     module as6c8016 #(
         parameter ACCESS_TIME = 55,
         parameter INIT_FILE = ""
     ) (
         input  wire [18:0] A,      // Address A0-A18
         inout  wire [15:0] DQ,     // 16-bit data I/O
         input  wire        CEn,    // Chip Enable (active low)
         input  wire        OEn,    // Output Enable (active low)
         input  wire        WEn,    // Write Enable (active low)
         input  wire        LBn,    // Lower Byte control (active low)
         input  wire        UBn     // Upper Byte control (active low)
     );
     3. Memory array: reg [15:0] mem [0:524287] (512K x 16 bits)
     4. Read logic:
       - Drive DQ[7:0] when CE#=L, OE#=L, WE#=H, LB#=L
       - Drive DQ[15:8] when CE#=L, OE#=L, WE#=H, UB#=L
       - Apply ACCESS_TIME delay
     5. Write logic:
       - Write DQ[7:0] to mem[A][7:0] when CE#=L, WE#=L, LB#=L
       - Write DQ[15:8] to mem[A][15:8] when CE#=L, WE#=L, UB#=L
       - Trigger on rising edge of WE# or CE#
     6. Initialization: Support INIT_FILE parameter for hex loading

     Files to Create

     - mem/as6c8016.sv - New 512Kx16 SRAM model


[paulca]

So. All I had to do for a while was press enter.

It figured out the intent and just kept offering next steps.
* Adding a test_bench for the module.
* Fixing the bugs that found.
* Integrating the RAM chip into the PCB level hardware module.
* Updating the address decoode modue
* Updating tests, configs, readmes
* Finding more bugs.
* Fixing bugs.
* Adding tests coverage for the bugs.
* Making tests pass.
* Commiting and pushing changes to the branch.

I asked it to repeat the process with the NOR Flash chip, which also worked.  So then I asked it about whether I needed to support the "8 bit" mode from CPU through to hardware.  We debated a whlie and decided that, "not really".  Leave the upper/lower data selects on the RAM, but don't both supporting it on the NOR Flash.  Which it based on the CPU never writing "normally" to the ROM, but via the (unsimuated JEDEC standard sequences).  That's fair.

So I let it go off and make those changes.  Then write tests. 

It took it 15 minutes because it kept finding verilog bugs with timing and sequencing.  It did fix them and get all tests to pass.

However, it also drained my premium account down to 3% until 4pm.

Gives me plenty of time to review, test, understand and modify it myself, maybe write some ASM code to test the ROM/RAM swap still works.  I fear it has forgotten about it.

[tggzzz]

Clearly all that is necessary is for one LLM to send the occasional "enter" character to the other LLM, only stopping when the first LLM is satisfied the second LLM has got it right.

Or should "first" and "second" be swapped around?

Next step: get one LLM to send "enter" characters to itself, and retire the other LLM.