Yeah, it's still not doing anything. I've attached the source(for SB-assembler), with the I/O routines it uses in the same file. I tested that, and it seems to exhibit the same behaviour of not appearing to do anything.

I'm going to take a look at the IO routines I use here. It occurs to me that one of them might going into an infinite loop.

I hear what you're saying here, and I do sympathize. But the solution is to narrow your focus. Pick one program that doesn't work and see if you can verify an action that's supposed to occur near the beginning or partway through. Then, depending what you find, go ahead or go further back and narrow the focus further. Eventually you'll probably discover a single bus cycle that isn't doing what it should -- due to a wiring error, perhaps, or a fault in address decoding... any number of things can trip you up.

If you end up spinning your tires it's OK to set that program aside and try another, but still the idea is to drill down until you can see what's really happening -- or not happening! You can even contrive a variant of the program that's optimized for troubleshooting.

(Oops, I see I overlooked your most recent post. But the advice still stands. Good luck, and keep us posted!)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yeah, I second Dr Jefyll.

You urgently need a stable reliable base (aka monitor) from where you can explore step by step the remaining system!

Currently I get a bit confused about what happens. AFAIR your hardware seems to work - basically. Address decoding was correct. You find and circumvent the CS1 bug. You stated that you can print and receive characters via the UART, a while you had have a running WOZmon. So something must work as it should. And then more should be possible, e.g. writing bytes into your EEPROM.

I don't use your assembler, so I don't know whether its output is reliable. As I have learned to code the hard way (I still know what "A2 00 CA D0 FD" means) I would verify (or disassemble) the output of the assembler. Even today I sometimes key in a few instructions to verify something. If the result is what I expect I can go on. Usually this isn't difficult. Of course this is not "beautiful" nor efficient but at first: it runs. Later when using all these snippets gets clumsy I reorganize that, likely using an assembler (so getting a documentation on the fly) to streamline the code ... and continue exploration


Arne

Remembering my own adventures, running untested software on untested hardware might be "the highest degree of difficulty".
My advice would be to stick with Occam's razor.

It's a good idea to check if your assembler generates binary machine code as intended.
Many years ago, I had used an identical name for a variable and a macro by accident, and the assembler went confused enough
to produce garbage without telling me about it...


I'll second Dr Jefyll and GaBuZoMeu: having a monitor program inside that computer would simplify testing a lot.
Any chance of getting a monitor program running inside a 6502 emulator on the PC, then porting it to your hardware ?

Does it need to be EWOZ, or could you try tinkering with other monitor programs too,
like for instance Daryl's SBC-2 monitor or MOS TIM ?

SB-Assembler has been pretty solid, in my experience. Mind you, my experience is quite limited.

I grabbed onto EWOZ pretty much solely because it looked easy to port. I'll take a look at the SBC-2 monitor first(nicer documentation), but even TIM looks like it has plenty more features than EWOZ.
I probably won't be converting either to SBasm. I suspect that's part of the reason Tali Forth didn't run when I tried it.

Starting to remember: the assembler I had used was the AS. Maybe I had a few battles too many...


Previous thread about EWOZ seems to be here.

Just trying to help:
Say, did you check your I\O routines by making the computer just echo a received character through the UART ?

Didn't follow the thread... but somewhere up:

So you tried to replace $0D (CR) by $0A (LF) ?
You happen to have the code shortly before and shortly after the modification ?

When I ported VTL-02 to the Badge (a little gadget where Daryl (aka 8BIT) did some wizardy) I used the assembler from sbprojects that Mike B. (aka barrym95838) recommends. It simply works. (Well, I have do wipe out some AppleII oddities until it runs flawless )

I checked the 65SPI by putting them out on the VIA. I'd had it blocked on WAI so I could see it.
I think I checked the DUART via loopback. I'm not sure though. I'll check it again.

The sbprojects assembler you mention is the one I use. And I probably still have the code before and after. The old ROM it's in is spread across a bunch of source files, though.

If there's a monitor that can be made to run reliably then that might be helpful. But it's not what I had in mind -- maybe I wasn't specific enough. I was thinking the focus would be narrowed even further, down to a single program such as the simplified loader that only loads 256 bytes, and always to $0200.

Of course you do need to get information back about what's happening, and there are at least two ways to do that without a monitor. Either single-step the CPU partway into the program then stop at various points and verify results by probing the address/data pins. For example, stop and verify the reads and writes of the SPI chip to see whether they're as expected. The other way to get information back is to use a test program that's so simple that even its final result reveals low-level detail.

I'm not opposed to using a monitor but I do worry it may be a case of what Dieter mentioned: untested software on untested hardware. That's not a good recipe for narrowing your focus.

Good luck and have fun, regardless of which approach you take

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(Hmm, machine code monitor vs bus monitor - possibly we have two different ideas here?)

The primitive loader is the 256 bytes to $0200 program. I uploaded that. I'm willing to do a machine code monitor. I haven't really got any better ideas. I'll also try that test program I had that dumped the SPI eeprom out the VIA. One byte per NMI press(I have a pushbutton and reset circuit on it).

The bus monitor/debugger is probably a sledgehammer to a nut, but I hope it will reveal something out of the ordinary. If it's a timing issue, it won't, because the Arduino can't keep up with the 'C02, so I'd have to master the clock from the Arduino. But if it's some kind of program or incorrect access issue, it will show up on the trace.
In any case, I've ordered the shift registers and pin strips for it. I'm hoping that aliexpress is nice to me for the first try.

Can you please upload "IttiaraStandardHeaders/MemoryMap.asm" as well?

edit/append:

and this too ?

A while ago, I actually put those files in version control, and backed them up to GitHub. All of the include files can be found here: https://github.com/TheTrueForce/IttiaraStandardHeaders. They look a bit odd there because I have my editor set to display a tab as four spaces wide instead of the eight that GitHub uses.

I wish that Pluma was easier to write syntax highlighting files for. Every attempt I've made at it has failed in short order.

This is the code that is playing up. It's the whole ROM, so it does include a lot of code that doesn't get used (Those routines were intended for later programs to make use of).
I've also modified it so that it works on the current hardware. It is still exhibiting the same problem: The line-feed goes right through to the display, so it looks correct, but EWOZ does not respond to it.

I suspect I may have found the problem with it, though. On line 76 of EWOZ.asm, it compares against the line ending($0A), but on line 73 of the same file, there's an ORA #$80, and A is not altered in between(it is saved and restored in ECHO). I think that the BNE on line 77 will never be taken, because it is comparing against a true ASCII character, and not an Apple ASCII one. I will test this, and report back.

EDIT: Well, I had it set the top bit in that place, and it's now accepting input lines. An odd thing is that now it does a spurious readout of a different location if you tell it to read, but it's not consistent.

In your EWOZ.asm, that CMP at line 85 looks suspicious, too.





Hmm.... don't know where in your code 'LineEnding' is defined...
...but try what happens when defining it as $8A instead of $0A just for the fun of it.