Oops, my mistake - I think I confused your code with that of another recently posted BASIC implementation. The instruction I was referring to appeared in a floating point implementation, which of course your Tiny BASICs do not support.

Neat! Thanks for contributing it.

I notice that at one point you use an instruction that is technically not part of the original 65C02 instruction set. It is one of those Rockwell extensions that is included in the W65C02S instruction set, though. It would only be an issue if the processor in use ...

It's not just a question of removing leading spaces; with the requirement that labels start in column one, if it starts in column one, it's a label. Otherwise either you have to first check that it's not a mnemonic or a pseudo-op and only then assume it's a label, or you have to insist on, and test ...

I agree. It took me a second to understand that final INY, but only a second. Very straightforward and quite handy.

Judging from the names you've given the state functions, I assume you've already noticed that the current state needs to be scaled by two in order to access the dispatch table. But just in case...:)

If you are using a 65C02 processor, note that there is a JMP (ABS, X) instruction. It would be a bit ...

Have you perhaps considered using a state machine for your main logic? That way you have to worry about only one thing, the current state. That state "knows" what it needs to pay attention to and what it doesn't. Plus of course how to transition to a successor state depending on what happens while ...

Expanding slightly on drogon's answer, you could also use RTS to make the jump this way:

;SWITCH:
;A:X (lo:hi) = adr, OFS:OFS+1 (lo:hi) = ofs
;jump to address stored in MEM[adr+ofs]:MEM[adr+ofs+1] (must actually be address-1 of target)

SWITCH CLC
ADC OFS ;A <- lo(adr + ofs)
STA TMP ;TMP <- lo ...

There's a lot in favor of "first get it to work", but as long as I'm in a "premature optimization" mood, in for a penny...


check_directory:
ldy #dir_attrib
lda (fs_dir_ptr),y
and #attr_dir
beq fcp1:
txa
file_char_out:
sta (put_ptr)
inc put_ptr
bne fcp1:
inc put_ptr+1
fcp1:
rts


Then ...

I ended up incrementing put_ptr so often it saved space to make it a subroutine; I may include that in my bios.asm as a permanent object

You've probably already noticed, but you can go a little further with this and store your output char as well:


file_char_out:
sta (put_ptr)
inc put_ptr ...

In addition to what Big Ed and BDD have already said, I'd have added that the JSR to the CRTC init code was placed before the init of the PIA in the first listing. If something in the init of the CRTC depended on the PIA being initialized first, then that wouldn't work.

Then I noticed that in ...

t would need a special editor for it.


You could also use the regular screen editor and treat that as being a 1/4 size (40x25) starting point for the "whole" (80x50) screen. Basically the same program, just with more room to "evolve". Might cost a few more bytes to do the translation, though.

Someone once said, "The best kind of experience is someone else's."

"Learn from the mistakes of others. You can't live long enough to make them all yourself." - Eleanor Roosevelt (disputed)

"Only a fool learns from his own mistakes. The wise man learns from the mistakes of others." – Otto von ...

There will be some PRNs whose bytes will fall into the ASCII control range $01-$1F and a $00 may sneak in there as well. Also, for filenames, it’s best to avoid characters that aren’t alphanumeric, other than the underscore and tilde. So I will have to formulate some rules on how to translate ...

An old trick was simulating character input through expression evaluation:

10 Y=1
20 N=0
30 PRINT "OK? (Y/N)";
40 INPUT A
50 IF A=Y THEN PRINT "YES"
60 IF A=N THEN PRINT "NO"


This isn't quite what I was thinking of. In this example 'A' is simply a numeric variable; there is no expression ...

It might be possible to allow a "feature" such as INPUT being able to evaluate expressions, but why? Doesn't PRINT already offer this same capability in a way much less likely to cause trouble?

Is there some code savings to be had this way? Possibly in the form of reduced error-checking, which ...