Neolithic Tiny Basic

[barnacle]

If you view the page source, you can see an awful lot of non-breaking-spaces where tabs used to be. It looks like three spaces per tab, but it doesn't align on tab boundaries.

I've updated the rough guide (above) to reflect current changes.

Neil

[barnacle]

New and improved memmove.

barrym95838 wrote:

I've been really busy lately, so I didn't have time to test this, but it's based on Bruce Clark's code, so I know it started out tight and fast. It's still tight and fast, and hopefully correct, if I didn't mess something up adapting it.

Thanks Mike, at first tests that seems to work, and it's thirty-two bytes shorter!

Neil

Previous buggy version of tiny.asm removed; check newer posts.

[BigDumbDinosaur]

BB8 wrote:

anyway the <pre> - </pre> tags have existed since the very early versions of Html: they are meant for preformatted monospaced texts, especially valid for displaying source code; with those tags any spaces or tabs are rendered as they were entered.

Unfortunately, the forum software doesn’t process any HTML embedded in a post.  The only way to get monospaced font is by using the code tags.  Tab rendering is not part of the HTML standard, so it’s anyone’s guess how tabs will appear in a browser.

[BB8]

BigDumbDinosaur wrote:

Unfortunately, the forum software doesn’t process any HTML embedded in a post.  The only way to get monospaced font is by using the code tags.  Tab rendering is not part of the HTML standard, so it’s anyone’s guess how tabs will appear in a browser.

true

[BigDumbDinosaur]

barnacle wrote:

If you view the page source, you can see an awful lot of non-breaking-spaces where tabs used to be. It looks like three spaces per tab, but it doesn't align on tab boundaries.

That is probably the forum’s PHP code doing that.  I've written a lot of PHP code and have not been able to conclusively determine what happens when a tab gets processed by an echo command in PHP.  The logical thing would be for PHP to expand the tab into a bunch of   entities, but there is nothing in the php.ini configuration file that deals with tabs.  I’m guessing the forum code has something that watches for tabs and expands them—string manipulation in PHP is painless.

[barnacle]

That makes sense, and matches what I'm seeing. Slightly frustrating for _me_ since I use four-space tabs but I'm not going to lose sleep over that.

Anyway, since NTB seems to do what I want, I'm going to spend a little time on the pi pico 2040 as a memory mapped peripheral; something I was doing when I got distracted by this. At least, I now have something to run on it so I can prove it loads and runs... beyond that, I'm still thinking about a variant of NTB that would be completely line-number-free, but that requires at least a minimum text editor, in or closely associated with the basic, or an external editor and some sort of operating system. That's also on the road map, but a long way down...

There's an issue with developing an editor: the Symon emulator doesn't appear to understand any control codes other than backspace; I haven't even found a way to clear the screen or to move the cursor. Maybe it incorporates VT codes; I haven't tested any of those yet.

Feel free to play with NTB; bug reports gratefully accepted, particularly if they come with fixes

Thanks,

Neil

[barnacle]

Another couple of bugfixes: one accidentally re-introduced into son-of-memmove, and one courtesy a cut'n'paste error while rejigging compare.

tiny.asm

(75.79 KiB) Downloaded 223 times

It happily runs Gordon's Mandelbrot code, with slight syntax modifications mentioned elsewhere.

Incidentally, I can't help feeling there must be some easier way to generate an enum list that the horrible way I did in that code (and which was indirectly the cause of my compare issues).

I haven't played yet, but I wonder about a macro to set the first value, and the subsequent macros to increment that set value.

Neil

[GlennSmith]

barnacle wrote:

Anyway, since NTB seems to do what I want, I'm going to spend a little time on the pi pico 2040 as a memory mapped peripheral; something I was doing when I got distracted by this.
Neil

Hi Neil,
Have you looked at the implementation of RP6502 by "rumbledthumps" ? I fell instantly in love with the idea, and I'm working on my own implementation/interpretation of it. In it's most simple form (ie without the 2nd pico that's used as the VGA device), it gives you a free memory map up to $FEFF, with UART, USB, fileio, and sound all thrown in. The only real downside is that it's running everything at 3.3v, so you can't get breakneck speeds out of the 65C02. But it's so simple and reliable that I've been using it to write a whole suite of programs (compiler, editor, etc.in PLASMA) and no longer worry about the stability of the underlying HW. My current work is now adding the HW bells & whistles that I had designed into my SBC into the RP56502 design.
Well, my penny's worth. Great work on the tiny basic.

[barnacle]

Yes, I've seen his stuff; I'm not sure I fully understand it but in concept, yes.

My plan is to include the vga and serial port (via usb) with a pair of memory mapped address: one address to read status and write commands, the other to read and write the associated data. The pico will also supply an initial program load and manage the processor clock. I can live with 3v3

But probably better that I discuss that on its own thread, rather than clutter this thread more than it already is - as usual with any thread I start, it's tended to drift! Here: viewtopic.php?f=4&t=8116

Neil

[barrym95838]

barnacle wrote:

Another couple of bugfixes: one accidentally re-introduced into son-of-memmove, and one courtesy a cut'n'paste error while rejigging compare.

In memmove it looks like you forgot to push x and y at the top, and using bmi for an unsigned compare of addresses is not advised in the general case. I previously left your quirky address compare alone because I didn't understand it and assumed that it "just worked".

[barnacle]

Regarding enums, I am being hampered a little by my assembler... but I have something that works, with a little work. Here's the macro, a couple of enum definitions, and some assembled code using them.

Code: Select all

ENUM 		macro p1
p1			equ	enum_cnt
enum_cnt	set enum_cnt+1
			db 0
			endm
	
	bss
enum_cnt	set 0		; set value of first enum
	org 0x0000
	ENUM FIRST
	ENUM SECOND
	ENUM THIRD
	
enum_cnt	set 1		; let's number from 1-7
	ENUM MONDAY
	ENUM TUESDAY
	ENUM WEDNESDAY
	
	code
	org $e000
main:
	lda #FIRST
	lda #SECOND
	lda #THIRD
	
	lda #MONDAY
	lda #TUESDAY

It's a bit annoying: attempting to complete the macro without an assembled opcode before the 'endm' caused it to segfault. Eventually I discovered that defining a byte (and probably a word) there works; perhaps the parser is expecting to see some actual code generated.

I don't want that code in my executable, obviously, but setting it to the BSS segment means it doesn't generate code. I have to remember to reset the origin of BSS when I actually start using it. Setting enum_cnt allows setting an initial value for the first enum.

In main, or anywhere thereafter, those enums remain global and constant. If you try to use a name in a different enum, you get a redefinition error. There's also no way to set random values, as you might with C; it's not that flexible. But useful, I think.

So:

• Include the macro
• Before defining any ENUMs, set the origin to zero, and set BSS
• Define the value of the first enum, using

  Code: Select all

  enum_cnt	set 0		; set value of first enum

• Add ENUMs as desired, ensuring that you do not share names
• Reset the BSS origin to zero (I didn't show that in the example) before you assign variables with DS or DW
• Switch to code and code as normal.

Here's the generated code:

Code: Select all

                        ENUM 		macro p1
                        p1			equ	enum_cnt
                        enum_cnt	set enum_cnt+1
                        			db 0
                        			endm
                        	
                        	bss
0000 =                  enum_cnt	set 0		; set value of first enum
0000 =                  	org 0x0000
                        	ENUM FIRST
0000 =                 >FIRST			equ	enum_cnt
0001 =                 >enum_cnt	set enum_cnt+1
0000 =                 >			db 0
                        
                        	ENUM SECOND
0001 =                 >SECOND			equ	enum_cnt
0002 =                 >enum_cnt	set enum_cnt+1
0001 =                 >			db 0
                        
                        	ENUM THIRD
0002 =                 >THIRD			equ	enum_cnt
0003 =                 >enum_cnt	set enum_cnt+1
0002 =                 >			db 0
                        
                        	
0001 =                  enum_cnt	set 1		; let's number from 1-7
                        	ENUM MONDAY
0001 =                 >MONDAY			equ	enum_cnt
0002 =                 >enum_cnt	set enum_cnt+1
0003 =                 >			db 0
                        
                        	ENUM TUESDAY
0002 =                 >TUESDAY			equ	enum_cnt
0003 =                 >enum_cnt	set enum_cnt+1
0004 =                 >			db 0
                        
                        	ENUM WEDNESDAY
0003 =                 >WEDNESDAY			equ	enum_cnt
0004 =                 >enum_cnt	set enum_cnt+1
0005 =                 >			db 0
                        
                        	
                        	code
e000 =                  	org $e000
e000 :                  main:
e000 : a900             	lda #FIRST
e002 : a901             	lda #SECOND
e004 : a902             	lda #THIRD
                        	
e006 : a901             	lda #MONDAY
e008 : a902             	lda #TUESDAY

The hex file generated started as expected at $e000.

Neil

[barnacle]

barrym95838 wrote:

In memmove it looks like you forgot to push x and y at the top, and using bmi for an unsigned compare of addresses is not advised in the general case. I previously left your quirky address compare alone because I didn't understand it and assumed that it "just worked".

I did indeed forget to push x and y; since I pull them at the end I don't know why it worked... they're in there now, though.

The address compare is courtesy of BB8 who has been most helpful; it's possible I've copied his suggestions incorrectly. I need to look in more detail. Originally I was using a signed comparision; some lines may have stayed, or I may be jumping to the wrong place.

Thanks! Who'da thunk memmove could be so tricky?

Neil

[barnacle]

I put it to you that

Code: Select all

; token enums
	bss
	org 0
enum_cnt	set $80 
	ENUM 	LET
	ENUM	REM
	ENUM	PRINT
	ENUM	LIST
	ENUM	NEW
	ENUM	RUN
	ENUM	INPUT
	ENUM	IF
	ENUM	ENDIF
	ENUM	FOR
	ENUM	TO
	ENUM	NEXT
	ENUM	WHILE
	ENUM	ENDWHILE
	ENUM	GOTO
	ENUM	GOSUB
	ENUM	RETURN
	ENUM	END
; these comparisons _must_ be in this order
	ENUM	LTE
	ENUM	GTE
	ENUM	EQUAL
	ENUM	NEQUAL
	ENUM	LT
	ENUM	GT
	ENUM	POKE
	ENUM	LAST_KW

FIRST_COMP	equ LTE
LAST_COMP	equ GT

is somewhat neater, and a lot less error-prone when adding, removing, or moving entries, than

Code: Select all

; token enums
LET		equ	0x80
REM		equ	LET + 1
PRINT	equ	REM + 1
LIST	equ PRINT + 1
NEW		equ LIST + 1
RUN		equ NEW + 1
INPUT	equ RUN + 1
IF		equ INPUT + 1
ENDIF	equ IF + 1
FOR		equ ENDIF + 1
TO		equ FOR + 1
NEXT	equ TO + 1
WHILE	equ NEXT + 1
ENDWHILE	equ WHILE + 1
GOTO	equ ENDWHILE + 1
GOSUB	equ GOTO + 1
RETURN	equ GOSUB + 1
END		equ RETURN + 1
; these comparisons _must_ be in this order
LTE		equ	END + 1
GTE		equ LTE + 1
EQUAL	equ GTE + 1
NEQUAL	equ EQUAL + 1
LT		equ NEQUAL + 1
GT		equ LT + 1
POKE	equ GT + 1
LAST_KW	equ POKE + 1
FIRST_COMP	equ LTE
LAST_COMP	equ GT

Neil

[BB8]

barrym95838 wrote:

using bmi for an unsigned compare of addresses is not advised in the general case

you're right, that was my mistake, BCC has to be used there:

Code: Select all

memmove:
	lda mm_size
	ora mm_size+1       ; not much point if size is zero
	beq mov_done
		lda mm_from+1    ; check high bytes
		cmp mm_to+1
		bne memo_nz
			lda mm_from   ; high bytes were equal, check low bytes
			cmp mm_to
			beq mov_done  ; done if the source and dest is the same
memo_nz:
	BCC mov_dec

[barnacle]

Thanks for the confirmation, BB8. I've fixed that in my local copy.

I'm probably out of circulation for a couple of days, so I'll not post the latest version (which incorporates that change and also the New Improved[tm] enums for the token values) until I'm back. I'd like to confirm that it runs on actual silicon first!

Neil