No current plans or desire to program the EEPROM in circuit.

That clarified, a simple wire tying WE HIGH is what I want, right?

I'm way too early in the process to add the complexity of in circuit programming. I can happily fish it out and put it in an external programmer for now!

That is exactly what you want, in your (newly-clarified) situation.

Adding the ability to write to the EEPROM insitu is zero complexity... just use a jumper, either tie to Vcc or to WE. It's also a very simple bit of coding, I use the toggle bit sense for byte-write mode with the Atmel EEPROM. My monitor code supports it and it's integrated with the memory operations routine.

_________________
Regards, KM
https://github.com/floobydust

Another question. I'm getting close to the next major test phase. I have both buses, the memory, and the decoding logic just about complete. I kinda want to test all that before I start talking to the VIA. I figure I need to hand enter something really simple into the ROM that does something with the data bus that I can confirm on my Arduino terminal connection.

Since I'll be entering this thing in machine code, it needs to be super simple. Any ideas for what I can tell the thing to do that basically tests RAM and ROM?

Also, what is the standard easy to code a delay? Some sort of loop full of NOPs? I was thinking a simple test would be to blink some LEDs. I can clock the CPU with my function gen to slow it down, but when it's running on the crystal oscillator, I'll need some delay if things are to blink at human speeds.

Tying /WE high is save.

Just to explain the jumper/pushbutton idea:
If you are using a true EEPROM (not a flash type EPROM), you can alter any memory location individually without prior erase or so. There is only a small amount of time you have to wait until you can access the EEPROM again.
Once you start writing programs - perhaps directly in machine language - you may wish to save your work. If you could then "copy" it to a free place within your EEPROM ...

Yeah, it would be like a poor man's harddisk. I can definitely see the advantage. It's the big picture plan, but my attitude is as little plumbing, no matter how trivial, until she's running.

You can cram a lot into a 16KB ROM. My POC V1 unit only has 8KB of ROM, yet has a BIOS supporting two TIA-232 channels, timekeeping and SCSI I/O, along with a full-featured machine language monitor. There are about 100 unused bytes left in the ROM.


Why a "simple" one? You might as well have a full-featured monitor, with code assembly and disassembly, memory search, copy and fill functions, etc. A monitor's value is in how easy it makes it to debug software. The more the monitor can do the easier it will be for you to develop and debug code.


Are you talking an absolute assembler or a symbolic macro assembler? Big difference between the two.


EhBasic would be a good choice. It was developed by the late Lee Davison for use with 6502 systems. There is plenty of documentation and discussion on it around here.


Your M/L monitor would have that.


I don't see why not, although it will ultimately depend on how much "creeping featurism" occurs as you develop your code.


Yes, but why limit yourself in such a way?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

There is another way to inspect digital circuitry without having a scope:

A switching transistor and a small loudspeaker.

Tie a 5K resistor to the base of a NPN transistor (BC547 o.e.) and a small speaker in series with another resistor from collector to +5V. The sum of the speaker impedance and the resistor should be >= 5/50mA = 100 Ohm. The transistors emitter should be connected to ground.

Try it. You will hear your computer working and with some experience you can even distinguish between various duty cycles.

(If the frequencies are going into the ultrasonic region, you may add something like a 74HC4040)

Yup, that would work pretty neat!

I have three scopes and a logic analyzer though.

then your only problem is selecting a proper trrigger signal and another dozen of wires

I'm actually hoping to use the same set up I used for the NOP test, with some appropriate tweaks to the code. I'll spy on the data bus with the Arduino, using the terminal.

As with the NOP test, I'm afraid I'll have to use my function generator as a clock in order to get slow enough to read what's going on. I'm also thinking of tweaking the Arduino code so that it only displays changes on the bus, instead of constantly polling and printing.

I dunno though. A guy could get sucked into surging too much time on a temporary tool!

Add a pushbutton to your arduino (well debounced of course) or simply wait for a key press (terminal) before you toggle the clock twice. This will effectively be a single stepping.
Once you know your hardware is working properly and aome minimal monitor will work too, you can omit these tools. When the programs becomes more complex, single stepping is usually not helpful.

KISS should always apply where possible. A good logic probe, such as the BK DP21 I have owned for some 27 years, more than enough to debug most digital problems. This probe was the only troubleshooting tool I used used to track down a hardware bug I had in POC V1.0.

This particular probe can also be used to diagnose automotive electronics problems, as it can operate on up to 15 volts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I forgot to mention that well before all these fancy toys (Arduinos, etc.) existed, people such as Garth and me were designing and debugging digital circuits with basic tools. I've had a logic probe of one sort or another since the early 1980s and worked through all sorts of complex problems using that and a DVM. Only rarely did anything fancier, e.g., a scope, get into the picture. I never found a use for a logic analyzer, even though there are many who feel they can't debug a circuit without one.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yeah, but the "toys" are sort of a subset of the hobby. Most of my testing so far has been with a DVM checking for ones and zeros. But watching things on the scope from a fun standpoint is a pretty neat thing. I know my learning curve skyrocketed when I started using one. Everything I'd ever read was right there to be seen!