VTL02 (VTL-2 for the 6502)

[Klaus2m5]

Gradius2000 wrote:

Klaus2m5 wrote:

see here: viewtopic.php?f=2&t=2612&p=55861#p48132

Still confusing, where in the code does it insert data to $02 on my github page?
https://github.com/GradiusLover2000/Jud ... /vtl02.asm

Nowhere! But if you are trying to debug a spurious write to a memory location, you can do so by using the memory protection feature of the Kowalski simulator. Ctrl-E, select simulator tab, specify memory range and select "Detect write attempt"

[Gradius2000]

Klaus2m5 wrote:

Gradius2000 wrote:

Klaus2m5 wrote:

see here: viewtopic.php?f=2&t=2612&p=55861#p48132

Still confusing, where in the code does it insert data to $02 on my github page?
https://github.com/GradiusLover2000/Jud ... /vtl02.asm

Nowhere! But if you are trying to debug a spurious write to a memory location, you can do so by using the memory protection feature of the Kowalski simulator. Ctrl-E, select simulator tab, specify memory range and select "Detect write attempt"

Thanks. I don't know why it wrote there at first; it was my task switching routine that did such...

[mvk]

barrym95838 wrote:

BigEd successfully ported VTL02 to the Beeb, which reserves the top half of zero-page. So, although VTL02 must claim 128 bytes of zero-page, it can be modified to something other than $80 .. $ff. The only changes necessary are in the equates and in the convp: subroutine ... perhaps Ed could share his mods here.

Also, since VTL02 only expects to use the top half of page 1, it should be possible to move the line input buffer to $0100, at least in my versions.

Before porting to the Gigatron v6502 as proposed in this thread, I like to confirm my understanding:

1. Is the hardware stack the only usage of page 1? page 1 is reserved for a video table and it will be a great pain to relocate it.
2. My stack works in page 0 instead of page 1. Is VTL02 making any assumptions on where the stack dumps its values, or is all through PHA/PLA/JSR/RTS etc.?
3. $00-$2f and $80 are reserved ([$80] holding the constant 1, and [$00]=0). If I run the user variables from $81 up, will I get away with it? I suppose ASCII 126 `~' can be a variable name, but ASCII 127 `DEL' won't? (*)
4. I plan to run the stack from $7F down. Any VTL02 zero page variables then go from $30 up. Will that work?
5. I have to learn a new assembler. Unless there's a ca65 version for VTL02C available somewhere already. Am I lucky?
6. Any other advice before the journey begins?

(*) $FF:$00 can still act as a pointer variable into zero page, and $7F:$80 can act as a pointer in page 1. I don't know if that's useful.

For completeness, this is my memory map:

Code: Select all

              0 1          47 48     127 128 129         (vSP)       255
             +-+-------------+-----------+-+-------------+--------------+
page 0       |0| System vars | User vars |1| User vars <-| Stack/Loader |
             +-+-------------+-----------+-+------+------+--+-----------+
page 1       | Video table                        | vReset  | Channel 1 |
             +------------------------------------+---------+-----------+
page 2       |0                                239 240   249| Channel 2 |
             |                                              +-----------+
page 3       | User vCPU code and/or data                   | Channel 3 |
             |                                              +-----------+
page 4       |                                              | Channel 4 |
             |                                              +-----------+
page 5-6     |                                               250     255|
             |                                                          |
             |                                                          |
             +----------------------------------------------------------+
page 7       | Sound tables                                             |
             +--------------------------------+-------------------------+
page 8-127   |0                            159|160                   255|
             | 120 lines of 160 pixels        |  Extra space for user   |
             | Default video memory           |  code and/or data       |
             =                                =                         =
             |                                |                         |
             +--------------------------------+-------------------------+
page 128-255 | Not used in the 32K system: mirror of page 0-127         |
             +----------------------------------------------------------+
              0                                                      255

I haven't decided yet where I will put the interpreter and user code. In fact I might borrow some from screen memory, because I'll need to do something similar with MS BASIC later on.

[drogon]

mvk wrote:

I haven't decided yet where I will put the interpreter and user code. In fact I might borrow some from screen memory, because I'll need to do something similar with MS BASIC later on.

ehBasic would be the "canonical" BASIC to port, however if you want MS Basic 2.0 in the guide of Commodore Basic 2.0, then get in-touch:

cbm2.png (11.29 KiB) Viewed 7318 times

It plays nice with my Ruby system which is very Beeb-like in it's current form - so zero page$00-$7F is all it needs, along with stack. However I didn't use it's input mechanism, but the one the RubyOS provides, so you might need to write a "getline" type function.

(I also changed the Easter Egg code - originally it poked screen at $8000 which is where it lives in my system, now it just calls osWrch)

-Gordon

[barrym95838]

mvk wrote:

Before porting to the Gigatron v6502 as proposed in this thread, I like to confirm my understanding:

1. Is the hardware stack the only usage of page 1? page 1 is reserved for a video table and it will be a great pain to relocate it.
2. My stack works in page 0 instead of page 1. Is VTL02 making any assumptions on where the stack dumps its values, or is all through PHA/PLA/JSR/RTS etc.?
3. $00-$2f and $80 are reserved ([$80] holding the constant 1, and [$00]=0). If I run the user variables from $81 up, will I get away with it? I suppose ASCII 126 `~' can be a variable name, but ASCII 127 `DEL' won't? (*)
4. I plan to run the stack from $7F down. Any VTL02 zero page variables then go from $30 up. Will that work?
5. I have to learn a new assembler. Unless there's a ca65 version for VTL02C available somewhere already. Am I lucky?
6. Any other advice before the journey begins?

(*) $FF:$00 can still act as a pointer variable into zero page, and $7F:$80 can act as a pointer in page 1. I don't know if that's useful.

VTL02C needs 1KB of "ROM", exactly 128 bytes of page zero, about 128 bytes of stack and about 128 bytes of page 2. The stack is only accessed with PHA/PLA/PHP/PLP/JSR/RTS.

The subroutine convp: maps the ASCII value of each variable name to two consecutive bytes of zero page, and there are exactly 64 unique variables. Variable names with ASCII values of $20 to $5F fill up that space, so the use of control characters and "lower-case" letters for variable names will not be rejected by convp: but will quickly foul up the works ... long story short ... I don't recommend using '~' or DEL.

Since the line editor is the largest consumer of the stack and the line buffer is the only consumer of page 2, if you limit your input lines to 80 chars (or any other number < 128), stack usage and page 2 usage will be reduced accordingly.

Klaus2m5 has successfully ported VTL02 to a couple of different assemblers and environments here, making him the resident expert on the subject.

Quote:

For completeness, this is my memory map:

Code: Select all

              0 1          47 48     127 128 129         (vSP)       255
             +-+-------------+-----------+-+-------------+--------------+
page 0       |0| System vars | User vars |1| User vars <-| Stack/Loader |
             +-+-------------+-----------+-+------+------+--+-----------+
page 1       | Video table                        | vReset  | Channel 1 |
             +------------------------------------+---------+-----------+
page 2       |0                                239 240   249| Channel 2 |
             |                                              +-----------+
page 3       | User vCPU code and/or data                   | Channel 3 |
             |                                              +-----------+
page 4       |                                              | Channel 4 |
             |                                              +-----------+
page 5-6     |                                               250     255|
             |                                                          |
             |                                                          |
             +----------------------------------------------------------+
page 7       | Sound tables                                             |
             +--------------------------------+-------------------------+
page 8-127   |0                            159|160                   255|
             | 120 lines of 160 pixels        |  Extra space for user   |
             | Default video memory           |  code and/or data       |
             =                                =                         =
             |                                |                         |
             +--------------------------------+-------------------------+
page 128-255 | Not used in the 32K system: mirror of page 0-127         |
             +----------------------------------------------------------+
              0                                                      255

I haven't decided yet where I will put the interpreter and user code. In fact I might borrow some from screen memory, because I'll need to do something similar with MS BASIC later on.

[mvk]

Ah of course. But that means it won't fit, because I have just 127 consecutive zero page bytes available max. Address $80 is simply not available, and can't be made to either.

[BigEd]

Do there have to be 64 unique variables? Must be possible to drop one?

[mvk]

BigEd wrote:

Do there have to be 64 unique variables? Must be possible to drop one?

I hope, that's why I queried. (My '~' vs DEL remark is based on a miscount on my part, please ignore.) So VTL has ASCII $20 to $5F as variable names, or SPACE to '_'. And we have to drop one of those two on the Gigatron (or do something complicated with non-consecutive mapping). I have no clue if these two are important to the interpreter, or to user programs that are out there.

The 80-byte line input doesn't sound like a true limitation. But there I have no idea either what is common in user code out there.

VTL looks like a really cool language to me BTW, a real gem.

[barrym95838]

Well, here's a suggestion that might work:

Code: Select all

; VTL02C variables occupy RAM addresses $0040 to $00bf,
;   and are little-endian, in the 6502 tradition.
; The use of lower-case and some control characters for
;   variable names is allowed, but not recommended; any
;   attempts to do so would likely result in chaos, due
;   to aliasing with upper-case and system variables.
; Variables tagged with an asterisk are used internally
;   by the interpreter and may change without warning.
;   {@ $ ( ) 0..9 : > ?} are (usually) intercepted by
;   the interpreter, so their internal use by VTL02C is
;   "safe".  The same cannot be said for {; < =}, so be
;   careful!
at       = $40      ; {@}* internal pointer / mem byte
; VTL02C standard user variable space
;                     {A B C .. X Y Z [ \ ] ^ _}
; VTL02C system variable space
space    = $80      ; { }  Starting with VTL02B:  the
;                       space character is no longer a
;                       valid user variable nor a
;                       "valid" binary operator.
;                       It is now only significant as a
;                       numeric constant terminator and
;                       as a place-holder in strings
;                       and program listings. 
bang     = $82      ; {!}  return line number
quote    = $84      ; {"}  user ml subroutine vector
pound    = $86      ; {#}  current line number
dolr     = $88      ; {$}* temp storage / char i/o
remn     = $8a      ; {%}  remainder of last division
ampr     = $8c      ; {&}  pointer to start of array
tick     = $8e      ; {'}  pseudo-random number
lparen   = $90      ; {(}* old line # / begin sub-exp
rparen   = $92      ; {)}* temp storage / end sub-exp
star     = $94      ; {*}  pointer to end of free mem
;          $96      ; {+ , - . /}  valid variables
; Interpreter argument stack space
arg      = $a0      ; {0 1 2 3 4 5 6 7 8 9 :}*
; Rarely used variables and argument stack overflow
;          $b6      ; {;}* valid user variable
lthan    = $b8      ; {<}* user memory byte pointer
;        = $ba      ; {=}* valid user variable
gthan    = $bc      ; {>}* temp / call ML subroutine
ques     = $be      ; {?}* temp / terminal i/o
;
nulstk   = $00ff    ; system stack grows down from here

Code: Select all

simple:
    asl             ; form simple variable address
    ora  #$80       ;
    sbc  #$3f       ; mapping function is (a*2)|128-64
    bne  oper8d     ; (always taken)

Changing the equates as shown, inserting the sbc #$3f and changing the bmi to bne will map {@} to $40, {space} to $80, and {?} to $BE. {@} and {?} are used, but {space} is not used (except optionally in VTL02A), so that shouldn't clash with your special location $80. You are left with only 64 bytes of stack from $C0 to $FF, but that shouldn't break too many existing VTL02 programs.

Give it a go and let us know if it crashes! If you decide that you really like it, it shouldn't be super difficult to make a "native" Gigatron version.

[mvk]

barrym95838 wrote:

Give it a go and let us know if it crashes! If you decide that you really like it, it shouldn't be super difficult to make a "native" Gigatron version.

Thanks, I can see how that will work! A small setback is that I developed a fever and was hospitalised yesterday (not completely unanticipated complications of earlier surgery), and the mind can't stay too focussed. It was hallucinating that my stay here is just a JSR waiting for its RTS. That's completely wrong of course (it's an NMI racing towards RTI).

Adding VTL02 is the right next step for maturing v6502 and doing cool new stuff on the system. I expect it uncovers page crossing bugs in the emulator. Wozmon doesn't expose those for obvious reasons. Keep you posted on progress.

[barrym95838]

It looks like you might be able to get a nice looking MicroChess working on your system with minimal effort, if that kind of thing floats your boat.
(I'm not sure how much stack MicroChess needs, though, and those TSX and TXS instructions sprinkled about may cause headaches ... superficial evidence suggests that you could make do with $70 stack bytes, so maybe it wouldn't be so bad ...)

[mvk]

barrym95838 wrote:

It looks like you might be able to get a nice looking MicroChess working on your system with minimal effort, if that kind of thing floats your boat.

Yes! MicroChess was indeed already on the radar in the emulation thread: viewtopic.php?f=8&t=5666 In fact, the author already gave his blessing earlier this month.

I'm also looking for Usurpator II, a Dutch 6502-based chess program from ~1979. But the author doesn't know if he can find the code.

[monsonite]

Hi Mike. B

Having discovered the 6502 via Mike Chambers C-code emulation which runs on many cpus including a 400MHz ARM - it would be great to try out VTL02.

Is there a ROM listing of VTL02 which could be patched into Mike Chambers' cpu.c code?

Please forgive me if this is already well trodden ground. Forums are great for the here and now - but difficult to search for older threads from a few years ago.

regards

Ken

[DerTrueForce]

I do know we have a VTL-02 interpreter running around on the site. If you go to 6502.org proper, fun go to the source code repository, you should find a "compilers and interpreters" section, and if memory serves, VTL-02 is in there, in assembly form. I believe it's written for the Apple II, but all that needs changing is the IO routines.

As to the searching, I actually find the forums relatively easy to search. It can get a bit time-consuming if what I'm after is quite old, and mentioned a lot, but it's not particularly difficult.

[barrym95838]

I'm not certain what you mean by "ROM listing". Are you looking for a traditional .LST file or a comma-separated raw hex dump that you can patch into the C source as an initialized byte array, like "{ 0xA9 , 0x00 , 0x85 , 0xCC , ... }"? I could custom-assemble a version for you, but I would have to know about your character I/O (output and blocking input and non-blocking input) and your zero-page allocations. Klaus2m5 has done significant work on porting VTL02C to a few different targets, and may be able to assist as well.