BASIC with character LCD

[GARTHWILSON]

Ok, take out the word "bus" in "bus contention." If the LCD is being interfaced through a VIA so it's not on the processor's own bus, you could have a situation where software is telling the LCD to output data to the VIA while the VIA is also trying to output data onto the same lines. Since it's going through the VIA, it will be staying that way a lot longer than just a half a phase-2 cycle. It will be there for at least a few cycles, possibly a lot longer than that. If the power supply isn't strong enough (evidenced by the dimming), the bypass cap.s get drained, and the voltage gets low enough that something doesn't work right. I don't know what the drive strength of the LCD is, but a W65C22S can do 50mA per pin when shorted.

[GaBuZoMeu]

If you are using the primers scheme #1 then
+ (EP)ROM is from $8000..$FFFF and there is no contention possible.
+ RAM is from $0000..$3FFF and there is no contention possible.
IO-space ranges from $4000 up to $7FFF.
The IO devices are 'seperated' from each other by tying A13, A12, A11, ... and so on to their CS (active high) input. The active low /CS is tied to the coarse $4000..$7FFF selector signal.

Say you have a VIA-1 tied to A13 and a VIA-2 tied to A12. To access VIA-1 the address bus has to look like 011x.xxxx.xxxx.yyyy (x = 0 or 1 will work, y = tied to RS lines of VIA).
VIA-2 responses to 01x1.xxxx.xxxx.yyyy

As A13 is not checked by VIA-2 access to 0111.xxxx.xxxx.yyyy would select BOTH VIAs. Writing to $7xxy would push data into both VIAs - no technical but likely a logical problem. But reading would cause bus contention with more or less high current demands, likely to drop Vdd below RESET threshold.

So it is very important to use addresses with bit patterns that select only one device. In this case $600y for VIA-1, and $500y for VIA-2.

The 74HCT132 is OK.

[barrym95838]

NickH93 wrote:

... Reading 4000, for example, the memory there just reads "40" from $4000 to $40FF, 41 at $41FF, and so on.

I'm not a hardware expert, but that sounds like a harmless floating data bus situation, where the third byte of the LDA abs instruction is persisting.

Mike B.

[Dr Jefyll]

[I see Mike posted while I was typing this. Here's a more detailed explanation.]

NickH93 wrote:

Reading 4000, for example, the memory there just reads "40" from $4000 to $40FF, 41 at $41FF, and so on.

Hm, could be a serious problem here. This tells us no device at all is selected -- no memory, and no I/O. Is that what you planned? (I haven't been following this thread closely.)

The explanation for this behavior has to do with the 65xx's cycle-by-cycle bus operation. For example, LDA <absolute> takes four cycles -- three program fetches (possibly from EPROM) then the data fetch from the desired device; IOW we fetch the opcode, then the two operand bytes (ADL then ADH), then the actual data from the ADH:ADL address. If during the last cycle no device drives the bus then it can (due to its own capacitance) still have the value from the previous cycle -- ie, the 2nd operand byte, which is the ADH. That's why you invariably get "40" from $4000 to $40FF. You're getting the last operand byte -- ADH, the $40 -- not the data you expected.

LDA <indirect> will show the same behavior. The sequence of bus cycles differs; but, as with absolute mode, the next-to-last cycle fetches the ADH (from zero-page in this case). This can remain present if there's nothing to replace it during the final cycle.

HTH,
Jeff

[NickH93]

So just a few updates. The keyboard interface broke (flimsy PS/2 socket), so I've since ported the monitor and basic to run off of my ACIA in the meantime (I have more sockets coming. I'm going to find a way to make it stronger). After finding out I had one with the TXE bug, I've got it displaying through a terminal. So now I have a full display. I've got different behaviors, but I wonder if this would help clear anything up. I've also went over all of my wiring and checked that it was okay for the whole board. I also changed the RAM chip, just to rule out bad RAM. I can read and write from this new RAM as well, just like before.

So, I see the memory count changing based on what I dictate for Ram_base and Ram_top. It seems to be counting the memory correctly.

Sometimes when I do a list command, it lists some random nonsense program even if I've typed nothing.

One time I typed in a program with lines 10 and 20. When I listed, it came out with the line numbers as like "10.xxxxxxxx" with, the x's being a bunch of random numbers. The program was then garbled after the line numbers too. This is weird, as with my old setup, it WAS listing programs correctly.

There are also some builds where everything gives me a syntax error.

Now though, when it crashes from doing a "PRINT A" command, it just freezes. It doesn't reset or anything. I've also confirmed my memory layout works in the Kowalski simulator

EDIT: Also, I forgot to mention. I noticed the mini_mon.asm for the simulator has a CLD command before running BASIC. I hadn't been putting one in for my board. Just resetting the stack. Would this cause issues?

[BigDumbDinosaur]

NickH93 wrote:

EDIT: Also, I forgot to mention. I noticed the mini_mon.asm for the simulator has a CLD command before running BASIC. I hadn't been putting one in for my board. Just resetting the stack. Would this cause issues?

Possibly. When in decimal mode the MPU has a markedly different behavior in processing the ADC and SBC instructions.

It's best not to make any assumptions about the MPU's state, including whether it is in binary or decimal mode. This is especially important with the NMOS parts, which do not initialize the D bit in the status register to any particular value following a reset or hardware interrupt. So what I would do would be:

Code: Select all

;SIMPLE 6502/65C02 HARD RESET PREAMBLE
;
HRST     SEI                   ;disallow IRQs
         CLD                   ;ensure binary mode
         LDX #$FF              ;initialize...
         TXS                   ;MPU stack

	...carry out other initialization steps as required...

         CLI                   ;allow IRQs...

	...program continues...

Use the top-of-stack value required for your application.

The order in which this is carried out is important. The initial SEI is there to take care of the case where the HRST routine is called from software. A hard reset would automatically mask IRQs, but jumping to HRST would not without the SEI. Only after all initialization steps are carried out would you enable IRQs.

Unlike the NMOS parts, the 65C02 will clear decimal mode following any kind of interrupt, hard or soft (asserting reset is seen as a hard interrupt). Hence the CLD in the above would be redundant, but should be retained for the same reason that the SEI is present.

[whartung]

You'd think if the Decimal flag was that important to the BASIC, they'd conspicuously clear it in the COLD START section.

(Not saying it's not important for it to be clear, just saying that BASIC should take responsibility for it's environmental requirements.)

[leepivonka]

Quick check: what is A14 of the RAM connected to? Left floating would be bad.


Here is a sample memory test. It's currently packaged to run standalone, but you could integrate
it into your monitor. Fix the **FIXME** parts for your system.

Code: Select all

; setup for ca65 from cc65.org
	.list on
	.listbytes unlimited
	.pc02	;select CPU

	.org $10 ; direct page
MtStart: .res 2		;test memory starting address
MtEndH:	.res 1		;test memory ending address page
MtPass:	.res 1		;pass #
MtPtr:	.res 2		;current test memory address (lo byte is zero while running)
MtPat:	.res 1		;expected byte value
MtDif:	.res 1		;difference between expected & read byte value

	.org $ff00 ; ROM
Reset:	ldx #$ff
	txs

	lda #<$0020	;Start=$0020
	ldy #>$0020
	ldx #>$4000	;End=$4000
	; call MTest (we'll just fall into it, since it's the only thing this sample does)


MTest: ;--- memory block test --------------------------------------------------------
	; Doesn't use the 6502 stack (check "show we're still running") so we can check $0100..$01ff
	sta 0+MtStart		; store parameters
	sty 1+MtStart
	stx MtEndH

	stz MtPass		;for(MtPass=0; ;MtPass++)
@Pass:

	; initialize test memory with pseudo-random sequence
	lda MtPass		;  initialize LFSR
	ldy 0+MtStart		;  for each page of test memory
	ldx 1+MtStart
@21:
	stz 0+MtPtr		;    MtPtr=base of page
	stx 1+MtPtr
	eor 1+MtPtr		;    shuffle LFSR on each memory test page
				;    for each byte in page
@22:	lsr a			;      cycle LFSR to gen next #
	bcc @23
	eor #$b8
@23:	sta (MtPtr),y		;      store in test memory
	iny			;      next byte in test memory page
	bne @22
	inx			;    next test memory page
	cpx MtEndH
	bne @21

	; verify test memory with pseudo-random sequence
	lda MtPass		;  initialize LFSR
	ldy 0+MtStart		;  for each page of test memory
	ldx 1+MtStart
@41:
	stz 0+MtPtr		;    MtPtr=base of page
	stx 1+MtPtr
	eor 1+MtPtr		;    shuffle LFSR on each memory test page
@42:				;    for each byte in page
	lsr a			;      cycle LFSR to gen next #
	bcc @43
	eor #$b8
@43:	sta MtPat		;      save #
	eor (MtPtr),y		;      compare with test memory
	bne @Err
	lda MtPat
	iny			;      next byte in test memory page
	bne @42
	inx			;    next test memory page
	cpx MtEndH
	bne @41

	;show we're still running
	lda MtPass		;  make up a char from MtPass
	and #$3f
	ora #$40
	.byte $02,$fd		;  **FIXME** write a char to the console

	inc MtPass		;  next MtPass
	bra @Pass


@Err:	;verify found an error - save detail
	sty 0+MtPtr		;MtPtr is the failing test memory address
	sta MtDif		;MtDif is the difference between computed & read test memory byte
				;MtPat is the computed value
	lda #'E'
	.byte $02,$fd		;**FIXME** write a char to the console
	bra *			;get stuck (maybe go back to monitor instead)



	.org $fffa ; 6502 vectors
	.word Reset	;NMI
	.word Reset	;reset
	.word Reset	;IRQ & BRK

On EhBasic 2.22:
It does reinitialize the 6502 stack pointer the way it likes.
I don't see it clearing the D flag - oops, better clear it before entering EhBasic.

At viewtopic.php?f=5&t=4564 there is more discussion
also https://github.com/Klaus2m5/6502_EhBASI ... quirks.txt

[NickH93]

Thanks a million everyone for the help. I'm out all weekend so I can't try these fixes atm, but that linked forum thread duplicates my issues with my same kind of setup. So I'm going to try the fixes in the other post, see if they work.

I'll also implement this Mem test and clear decimal before starting.

[Klaus2m5]

whartung wrote:

You'd think if the Decimal flag was that important to the BASIC, they'd conspicuously clear it in the COLD START section.

(Not saying it's not important for it to be clear, just saying that BASIC should take responsibility for it's environmental requirements.)

It is cleared in the reset vector of min_mon.asm which is the environmental wrapper for EHBasic.

Code: Select all

; reset vector points here

RES_vec
	CLD				; clear decimal mode
	LDX	#$FF			; empty stack
	TXS				; set the stack

Then it goes on to copy some vectors, provide a signon message and allow you to select cold or warm start. If you decide to omit parts of the min_mon wrapper you must know what you are doing. A monitor should start EHBasic by JMP RES_Vec, not by jumping to EHBasic directly. Once EHBasic is running it is save to assume the D-flag is clear. It is only set and cleared again in HEX$(). Custom interrupt vectors should have CLD if ADC or SBC is to be used.

[NickH93]

I know we're a few months removed here, so I apologize for the bad form. I had to pack up and move and have only recently got the thing set up again. I didn't think I should make a whole new post just to tackle the same issue. I've tried all of the suggestions to no avail. I've made a single stepper and will step through the program.

At any rate, I've noticed anybody using EHBasic hasn't used the memory map in the first example of the primer (none that I could find, anyway). Is there some sort of issue with EHBasic and this memory map setup? I was under the impression that EHBasic was pretty flexible with this.

So to recap. It runs, counts the memory available correctly, and can even write and list programs in memory. However, when you do anything such as "PRINT 2+2" everything dims and restarts. A regular PRINT statement with nothing after it works correctly. I've also used two different RAM chips, both brand new with no change.

I've also changed over to using the ACIA to drive my display, just because it was easier for the time being. With the Tellymate Tiny I have a nice monitor to use as a display. Same symptoms even with that as the display.

EDIT: Clarification

[NickH93]

After a marriage and finally settling into a new place, I've FINALLY had time to sit down and debug this thing.

So everyone, I've finally found the problem.

I narrowed it down based on some other strange behavior on my monitor program. I noticed when I put code in certain locations in the monitor's code, it would crash the computer, but if I put that code at the end of the monitor and just did a JSR do it, it would work.

It was a defective 65C02!

I borrowed the one from my Apple IIe, since it is out of commission for the time being...lo and behold EHBasic runs perfectly now!

This board went through so many revisions, starting from when I didn't have ANY clue what I was doing. It is likely in those days that I connected it wrong and broke something.

Hopefully this helps anyone else. If EHBasic seems like it should work but just refuses...it could be the processor!

[whartung]

NickH93 wrote:

After a marriage and finally settling into a new place

Going on the crass assumption that it's your marriage, congratulations!

[NickH93]

whartung wrote:

NickH93 wrote:

After a marriage and finally settling into a new place

Going on the crass assumption that it's your marriage, congratulations!

Ha, I should have clarified, yes I got married.

Thanks so much!

[Dr Jefyll]

NickH93 wrote:

It was a defective 65C02! [...]
I borrowed the one from my Apple IIe [...] and behold EHBasic runs perfectly now!

If you haven't already, can I suggest you try reinstalling the original CPU to verify that the problem returns? Crap happens, and it's possible to be misled. Just one example: I've seen cases where a problem disappeared after removing then reinserting the very same IC -- in other words not a swap. But all the fussing around disturbed something. Maybe removed some tarnish from the socket, although that's not the only possibility.

J