An easier way to implement peek and poke would require a reserved variable as the address pointer used. At first I thought I could take double quote as it is already used for sys calls (greater than). However, that does not allow for later increments like "="+1 as it would be decoded as a string on the right side of the equation.

To implement one just has to copy the behavior of $ after labels exec1 and getval2. Instead of jsr outch and jsr inch you need to implement an indirect store or load with the designated address variable.

So one can poke some address with its own low address byte (assuming + as the address variable) :
10 +=512
20 @=+
30 +=++1
40 #=20*+<520

or peek and print the same range:
50 +=512
60 ?=@
70 +=++1
80 #=60*+<520

Poke the high byte: @=A/256
Peek the high byte: A=@*256 ...or if low byte was already read: A=@*256+A

I will put it on my todo list, which already has "put VTL02 on GitHub" as discussed with Ed in private mails. But this will have to wait at least one month until I return home from Greece.

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

Thank you for the excellent idea, Klaus! I will attempt to implement your suggestion and my ;A) idea, and see which one feels right. As long as the interpreter code doesn't exceed 1KB, either could do the job with minimal fuss.

Ed has added my original source into the6502.org source code repository, and I will be keeping in touch with him if I need to request any significant updates there (dclxvi's suggestions are being incorporated as well, but progress is slow, due to my limited spare time).

Mike B.

[Edit: I'm starting to lean toward a @A) notation, to allow backwards compatibility with standard VTL-2 programs that may use ; as a simple variable (like my Super Star Trek port in the works):

The & | ^ operators are so easy to add, I'm going to do that as well, keeping the 1KB limit in mind. To support legacy keyboards and displays that may not be able to support the | character for bit-wise OR, I will add an assembly-time equate to change it to \ or !
]

Well, you could just go "=1+" since the ?=" check only looks at the character directly after the =

I really want to try my @A) notation (see edit of my previous post) first, but I will give your proposal serious consideration.

Mike B.

P.S. I'm also considering allowing the interpreter to ignore space characters inside expressions, to allow more aesthetically pleasing program listings, at a slight cost in memory usage and execution speed. This would prevent using the space character as a variable name, but that would be a very small price to pay.

The variable used to represent the peek and poke address can still be used as a normal variable if neither peek nor poke will be used. So your Super Star Trek port would still work.

Remember, that the @ in your original version is still assigned as a line erase. I replaced it in my version with 0x1b (escape key). I also replaced _ with 0x08 (backspace) and 0x7f (delete). But this may cause a problem for people with a true teletype printer or a simple terminal.

Disallowing space as a variable is a good move (invisible operators and variables at the end of a line) and sets it free for internal use.

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

Good points, Klaus. I think I would like to target the Apple 1 as my "lowest-common-denominator" target. It can accept the full 7-bit ASCII set as input, but can only display codes 32 through 95 (and 13). I have already added the & | and ^ operators, at a total cost of 45 bytes. I'm still experimenting with the PEEK/POKE equivalents, but I should have something to show before you get back from Greece, with a bit of luck. Disallowing space (as a valid user variable and default operator) will be my final enhancement attempt for VTL02B, but I have set a hard size limit of 1024 bytes for the interpreter, and it's going to be tight.

Mike B.

Update: my @A) enhancement is certainly doable, but is more expensive than Klaus' suggestion to use @ as a special memory access variable and another variable like < for the access pointer (which can be used as a normal variable if the @ feature is avoided). I'm going to back-track a bit and implement Klaus' proposal instead, then work on neutering the space character. I am cautiously optimistic that both of these enhancements (and & | ^) will still fit inside 1KB.

Source coming soon, I hope!

Mike B.

P.S. I have also moved all of the I/O subroutines to the end, to prevent any out-of-range branch hassles for those of you who need some extra code space to deal with systems having no built-in monitor I/O support (my interpreter does a lot of internal code sharing with unstructured branch instructions, to save space).

P.P.S. I have to test it out on AppleWin, but it looks like the VTL02B Apple 2 version will come in under 1KB, with 48 bytes to spare, allowing enough space to tweak the terminal I/O subroutines and port it to most 6502 systems.


P.P.S. Er ... 45 bytes to spare, and I still have a significant bug to squash. Has anyone here used AppleWin's debug feature? How steep is the learning curve? I debugged the first one through detailed run-time observation and a few carefully-selected break-points, but I might try something different this time ...

Ooh ... if you weren't so awesome, I would have a few choice words to say to you ... that's supposed to be BCS CVBIN3 !!

Anyway, I have the source ready to share with y'all. It's still set up for sbasm, but I took some extra time to make the source file a bit easier to translate to other assemblers. I hope you guys enjoy it!



Cheers,

Mike B.

Tried this today, the formatting is nice and indeed only required minor changes to work. Pretty neat for under 1K, nice job.

Perfect timing. I have some days of free time to convert and test the new version. It will be featured in my tech-talk at the Vintage Computing Festival Berlin next week.

Mario.

_________________
How should I know what I think, until I hear what I've said.

Combing through the source again, I found four more bytes to squeeze, but I've definitely reached the point of diminishing returns with the NMOS instruction set. I estimate that at least 20 bytes could be saved by using 'c02 extensions, and at least 80 bytes could be saved with 'c802/816 extensions, but I'm content with playing to the lowest common denominator for now, which is the NMOS Apple 1 (although a patch for the multiply routine would be necessary for ROR-bug specimens).

Chores and many other projects await ... I need to move on, but I appreciate your patience, feedback, praise, camaraderie and critique. What an awesome little community we have here!

Cheers,

Mike B.

Brought over from the prime number challenge thread:



Initially it was the zero page allocation - the Beeb allows the first half for the "current language", initially Basic but would be VTL once CALLed. But... I think there's some mixing of values and locations, and I'm not sure if relocating the workarea was working. Plus, I think there are some assumptions about Apple's ASCII having the high bit set - perhaps linked to the zp locations in a cunning way. So, probably needs a thorough sweep of uses of bytesize values and what the value of the top bit should be.

(Minor things like connecting I/O and switching the line-end convention seemed straightforward - I feel as if I've done that before!)

VTL02 and 02B work with the high-bit clear ASCII internally, and only "translate" for terminal I/O, as necessary.

You should check out the following subroutine:

I am almost certain this is where your problem lies, especially the ASL ORA #$80 BMI sequence. Although it is not well commented (sorry), this is where the named variable is translated from ASCII to a zp address. 'A' translates to $82, '!' to $c2, etc., which matches my zp equates at the beginning of the source. If you want to use $00 to $7f, just change that critical sequence to ASL AND#$7f BPL, and make sure that 'A' corresponds to $02, '!' to $42 etc. in your equates.

Mike B.

Thanks - that makes sense. I'll give it a go...

I found your video here. I must say that you are a very handsome geek! It's a pity that I don't speak more than a dozen words of German, but I enjoyed it as much as I could, under the circumstances. It's also a pity that your copy/paste was dropping characters at the beginning of each line, spoiling your VTL02 presentation a bit.

Mike B.

The visuals helped quite a bit, plus some technical words in German are similar enough to their English equivalents for me to figure out.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!