I've just got the EWoz Monitor(https://gist.github.com/BigEd/2760560) running on my system, and I realised that I wasn't getting the backslash prompt like I'm supposed to. I suspect that my hardware may be somewhat to blame here, as I'm using a serial LCD, and it's got a few quirks. One of those is that it's text resolution is 21x8.
Is the monitor sensitive to width? As in, does it make any assumptions about the width of the display it's attached to? (Or am I barking up the wrong tree here?)
The other idea I had was to alter the monitor so that it used low ASCII. Do you think this would be a problem? I'm not concerned with compatibility with old programs.

Low ascii sounds like a good plan
ESCAPE LDA #$DC ;"\"
JSR ECHO ;Output it.
GETLINE LDA #$8D ;CR.
That top bit set seems very non standard to me.

WozMon doesn't care about the display width, but it does assume HI-ASCII and a keyboard input buffer of 128 chars or less. If you switch it to lo-ASCII, be keenly aware that Woz liked to use coding tricks and flag side-effects to save a few bytes, so you may want to leave his code alone and just mask off the high bit in your COUT routine. San has a nice description here, if you haven't seen it already.

Mike B.

Thanks for pointing me to that page, Barry. I was looking for that. The EWoz monitor already masks in/out the high bit(as it is in the gist, it's been altered to use an ACIA), so it does work as-is. I'll still take a shot at it, I think, but I'll keep that in mind.

Like I said, I'm not getting the backslash, so I was thinking of removing conversions to see if that fixed it.

As for display widths, given that the wiz mon is not sensitive to width, I'll have a look at the read memory routines, if I can identify them. Those are putting out a few too many bytes per line for the display's width.
One of the annoying things about the display I'm using is that it wraps text around instead of scrolling. That ends up making things very hard to read. Since it uses an ATMega as a driver chip, I plan to change its firmware so that it handles scrolling, because it will be annoying trying to do it as it sits.

Oh, the memory dump looks best with 40 columns, because it dumps up to eight hex bytes (plus address) per line. So maybe you could edit the line:toin MOD8CHK to limit your dump to four bytes maximum per line.

Mike B.

That's exactly the effect I was thinking of! Thank you, sir!

It appears that that does not work... I gather that in the original Woz monitor, it output 8 bytes per row. EWoz outputs 16 bytes by default, and if I change the appropriate value in MOD8CHK to anything other than $0F, it does a wierd thing with the output. I'll put up a photo sometime later, probably in the morning(it's late as I write this).

An annoying thing about the display I'm using is that it doesn't implement any kind of scrolling; it just wraps text around to the top left when it hits the bottom right. I'm considering modifying the firmware to implement the scrolling(since I appear to be the first person on the internet to want that functionality on this display). I also want to change the command prefix value to a nonprinting ASCII character(why they did that is beyond me) and implement form feed, if it isn't already.
As to why a display has firmware, this one is a graphical LCD that is otherwise a fairly dumb display, with a second board soldered to the back with an ATMega on it that implements a serial interface and drives the LCD.

Can you link us to your EWoz source, or just attach it here? Maybe by comparing it to the original we can help you develop an alternate plan of attack.

Mike B.

[Edit: Oh, I think I found it:

https://gist.github.com/BigEd/2760560

]

That's where I found it. I have modified that to work with my hardware(a 28L92), so I'll wind up my dev pc and upload it in a bit.

I've attached my modified EWoz source(the one where the readout still works correctly).

I haven't attached a screen because I'm now having trouble with the keyboard. I altered the firmware on that so it'd work more the way I want, and it's now sending shifted characters where it shouldn't be. The alterations I made don't touch that area, either. I could revert it to the default firmware, but then I'd lose backspace, and I think a couple of other things, too.

I'll wind up putty later(*sigh*)...

This is what I got over PuTTY. The wraparound(set to 4 bytes) and the backslash appear to be working perfectly for some reason.

There are a whole bunch of spurious resets in here. Basically everything after the first dump is nonsense. When the welcome message appears to go insane and where it says PUTTY, I was wiggling the reset circuit.

Trouble is, it now usually fails completely when I try to use the display. It's possible that it's drawing too much current via the backlight. I'll try turning that down.
Edit: Turning the backlight down to minimum didn't fix the problem, and I suspect that I'm getting spurious resets.
I'm also noting that the voltage coming out of the regulator is just a touch under 5V. I know that the LCD backpack board has a LDO regulator on it, and that I'm powering it from the 5V rail. This is highly undesirable, but I don't know if I can simply bypass it or not.

It surely sounds as if you're facing a hardware problem (in addition to the question of software). But it seems premature to focus on the LDO regulator, unless there's a reason you think it might respond to wiggling. I suspect the best advice is to back off and take a broader look at the hardware. Can you tell us more about your system?

-- Jeff

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

The original WozMon loaded #$7f into Y in the reset sequence before falling into getline. You don't do that, and you should.

Mike B.

[Edit: Oh, nevermind. The LDA #$9B takes care of that. I'll keep snooping around for potential software errors.]

Dr Jefyll:
The construction of this computer("Ittiara" is it's silly little name) is wires soldered to the underside of a large pad-per-hole breadboard, and it's a mess under there.
The DUART is right at the other end of the board from the 6502, about 10-11cm away.
The keyboard is an RC2014 Universal Micro Keyboard in the serial configuration, with slightly modified firmware(I added a backspace to a spare spot on the keymap).
The display is a Sparkfun 128x64 Serial Graphic LCD.
All the silicon on Ittiara is in sockets. The ROM is in a ZIF socket, the RAM and Phase 2 oscillator are in wiper sockets, and the VIA and 16V8 are in machined sockets. The main voltage regulator is in a 3x1 socket of the kind that accepts dupont cables, and the reset circuit is in a 3x1 of machined socket strip. The baudrate oscillator is in four single machined sockets that I cut from a strip thereof.
I have small capacitors across the ROM, 6502, 16V8, oscillators, and DUART.
I use schottky diodes to turn fill-driver IRQ\ outputs into open-collector ones.
Raw power comes from a 9.9V, 2100mAh LiFePO4 battery pack.
The system specs are: 32KB ROM, 20KB RAM, VIA, 65SPI, 28L92, W65C02 at 1MHz.
The reset circuit and regulator come off the board and go into a zip-lock bag when I put it away.

Apologies for the wall of text. If there's anything more specific you want to know, ask me. I'll also see if I can find the current circuit diagram.

Every time a new line is started the monitor only sends crYour display may need lf or cr & lf.

cr = carriage return ($0d)
lf = line feed ($0a)

_________________
6502 sources on GitHub: https://github.com/Klaus2m5