Page 1 of 1

EhBASIC on W65C02SP based CPU card - Overflow Errors?

Posted: Mon Sep 20, 2004 7:58 pm
by philpem
Hi,
I've just finished building an EhBASIC ROM for my homebrew 6502 CPU card/backplane/UART system. RAM is 32Kbytes starting at $0000, ROM is 16Kbytes (27128) starting at $C000 with I/O in between.
The problem is, although EhBASIC will (sometimes) boot to the point of giving me the "Memory size?" signon message, it never manages to run actual code - if, for example I type in the following program:

Code: Select all

10 FOR I=1 TO 5
20 PRINT I
30 NEXT I

RUN
I either get an "Overflow Error" message or, in some rare cases, seemingly random numbers (e.g. 3, then 2, then 4 and so forth, one number per line). If I RUN the program again, it always results in an Overflow Error.

Can anyone shed some light on this problem? Bad RAM logic?
My monitor ROM is based on the one on the ehbasic website, except I've rewritten the UART access routines (I'm using a 16C550, not a 6551).

Thanks.

Posted: Mon Sep 20, 2004 8:20 pm
by 8BIT
Phil,

For my SBC-2 to run EhBASIC, besides setting up the I/O pointers in page $02, I had to modify the Ram_base constant to $0400 and the Ram_top constant to $7F00. (My I/O page is at $7Fxx.)

I also added a "STX Ibuffs" to initialize the input buffer pointer:

Code: Select all

LAB_2D13
	LDA	PG2_TABS,Y		; get byte
	STA	ccflag,Y		; store in page 2
	DEY				; decrement count
	BPL	LAB_2D13		; loop if not done

	LDX	#$FF			; set byte
	STX	Ibuffs		; *** Added by Daryl Rictor for SBC-2 compatibility
	STX	Clineh		; set current line high byte (set immediate mode)
	TXS				; reset stack pointer

	LDA	#$4C			; code for JMP
	STA	Fnxjmp		; save for jump vector for functions

; copy block from LAB_2CEE to $00BC - $00D3
Daryl

Posted: Mon Sep 20, 2004 9:23 pm
by philpem
8BIT wrote:
For my SBC-2 to run EhBASIC, besides setting up the I/O pointers in page $02, I had to modify the Ram_base constant to $0400 and the Ram_top constant to $7F00. (My I/O page is at $7Fxx.)
Nope - just changed the RAM_BASE and RAM_TOP constants - no dice. RAM_TOP is set to $8000, RAM_BASE is set to $0400. I've just ended up reprogramming the address decoder GAL, which has provoked EhBASIC into booting. The test program (10 FOR N=1 TO 20 / 20 PRINT N / 30 NEXT N) still produces an "Overflow Error in line 10" though. EhBASIC is reporting 31743 bytes free.
I've uploaded my code (monitor.asm is the monitor, basic.asm is ehbasic, make.bat is the makefile, tass.exe is the assembler) to http://www.philpem.me.uk/6502comp/ehbas.zip, just in case you want to have a look. If nothing else, the UART routines are worth stealing if you're using a 16550-class UART :D
The logic equations I'm using are the same ones that are on the website (http://www.philpem.me.uk/6502comp/.

Here's another bug - if I type "PRINT 12345", EhBASIC returns "1234.5". Very odd... This seems to apply to any number I use - 1234 returns 123.4, and so forth.


Thanks.

Posted: Mon Sep 20, 2004 10:48 pm
by 8BIT
philpem wrote:

Here's another bug - if I type "PRINT 12345", EhBASIC returns "1234.5". Very odd... This seems to apply to any number I use - 1234 returns 123.4, and so forth.
Thanks.
Did you set ibuffs also? As I recall, before I fixed that, I also got strange results.

Code: Select all

10 A=10
20 Print A
would return a different number. Also, direct mode did the same.

Code: Select all

>A=10
>PRINT A
20
I'll check out your code when I get a chance.

Daryl

Posted: Mon Sep 20, 2004 11:55 pm
by philpem
8BIT wrote:
Did you set ibuffs also? As I recall, before I fixed that, I also got strange results.

Code: Select all

10 A=10
20 Print A
would return a different number. Also, direct mode did the same.

Code: Select all

>A=10
>PRINT A
20
I've just added the "STX Ibuffs" which seems to have gotten EhBASIC to run code properly (i.e. no overflow errors), but it does seem to be producing some odd results more-or-less at random - they seem to be rounding errors. For instance...

Code: Select all

10 FOR N=1 TO 24
20 PRINT N
30 NEXT N
produces...

Code: Select all

 1                                                                              
 2.00002                                                                        
 3.00002                                                                        
 4.00002                                                                        
 5.00002                                                                        
 6.00002                                                                        
 7.00002                                                                        
 8.00002                                                                        
 9.00002                                                                        
 10                                                                             
 11                                                                             
 12                                                                             
 13                                                                             
 14                                                                             
 15                                                                             
 16                                                                             
 17                                                                             
 18                                                                             
 19                                                                             
 20                                                                             
 21                                                                             
 22                                                                             
 23                                                                             
Running the program again gets the same results; entering the "CLEAR" command, then re-running the program produces a different set of results.

Still, at least I know the CPU is behaving itself - saves dragging out the logic analyser again, only to find that the CPU and the logic are fine...

Thanks.

Posted: Tue Sep 21, 2004 5:31 am
by 8BIT
I'm glad its running now. Check Lee's site. He may have some hints as to the other trouble.

I tried your code on my SBC and simulator and did not have the rounding error.

Daryl

Posted: Tue Sep 21, 2004 7:01 am
by philpem
8BIT wrote:
I tried your code on my SBC and simulator and did not have the rounding error.
Wonderful. I guess that means there's some problem with the RAM, CPU or (more likely) the RAM/ROM select equations. :-(
I'll try loading a RAM tester into the EPROM later. Hopefully it's something simple that can be fixed easily. I suppose the other option is to drop the clock speed to 1.8432MHz for testing, then gradually increase it (assuming it's a problem with the RAM timing).

Thanks.

Posted: Tue Sep 21, 2004 9:24 am
by philpem
YEEEEEAAAAGHHH!!!!
It would appear that both of my "older" W65C02SP chips, datecode SA9942A, are faulty in one way or another. Chip #1 will boot EhBASIC, but causes rounding errors and random crashes - 2 becomes 2.002, etc.
The second chip boots EhBASIC, but instead of the normal "31743 Bytes Free" signon message, I get:

Code: Select all

6502 BIOS (C) Philip Pemberton, EhBASIC (C) Lee Davison                         
(C)oldstart/(W)armstart? C

Memory size ?

ªªªªªªªªªªªª Bytes free

Enhanced BASIC 1.10

Ready
Swapping the CPU for a W65C02SP-14 with a datecode of SA0250A seems to have gotten EhBASIC to work - no rounding errors or bugs at all.

These chips (the 9942s) were from the original 6502.org bulk-order back in '00 and have been stored in their antistatic tubes ever since. How two chips have ended up zapped is a mystery. Yes, I followed the usual ESD precautions.
Has anyone else had trouble getting EhBASIC to run on 65C02/SA9942A silicon?

Thanks.

Posted: Tue Sep 21, 2004 10:19 pm
by 8BIT
8BIT wrote:
I also added a "STX Ibuffs" to initialize the input buffer pointer:

Code: Select all

LAB_2D13
	LDA	PG2_TABS,Y		; get byte
	STA	ccflag,Y		; store in page 2
	DEY				; decrement count
	BPL	LAB_2D13		; loop if not done

	LDX	#$FF			; set byte
	STX	Ibuffs		; *** Added by Daryl Rictor for SBC-2 compatibility
	STX	Clineh		; set current line high byte (set immediate mode)
	TXS				; reset stack pointer

	LDA	#$4C			; code for JMP
	STA	Fnxjmp		; save for jump vector for functions

; copy block from LAB_2CEE to $00BC - $00D3

Oops! That should be STX Ibuffs-1 !!!!!

Code: Select all

LAB_2D13
	LDA	PG2_TABS,Y		; get byte
	STA	ccflag,Y		; store in page 2
	DEY				; decrement count
	BPL	LAB_2D13		; loop if not done

	LDX	#$FF			; set byte
	STX	Ibuffs-1		; *** Added by Daryl Rictor for SBC-2 compatibility
	STX	Clineh		; set current line high byte (set immediate mode)
	TXS				; reset stack pointer

	LDA	#$4C			; code for JMP
	STA	Fnxjmp		; save for jump vector for functions

; copy block from LAB_2CEE to $00BC - $00D3
I added this based on Lee's notes for the Ibuffs declaration:

Code: Select all

; Ibuffs can now be anywhere in RAM just make sure the byte before it is <> $00
; also ensure that the max length is <$80

Ibuffs		= $0223	; start of input buffer
Ibuffe		= Ibuffs+$47; end of input buffer

Daryl