6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Apr 18, 2024 3:57 pm

All times are UTC




Post new topic Reply to topic  [ 123 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next
Author Message
PostPosted: Tue Sep 05, 2017 9:00 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Gradius2000 wrote:
Klaus2m5 wrote:

Still confusing, where in the code does it insert data to $02 on my github page?
https://github.com/GradiusLover2000/JudyOS/blob/master/vtl02/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"

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 06, 2017 12:24 am 
Offline

Joined: Thu Aug 31, 2017 1:37 am
Posts: 32
Klaus2m5 wrote:
Gradius2000 wrote:
Klaus2m5 wrote:

Still confusing, where in the code does it insert data to $02 on my github page?
https://github.com/GradiusLover2000/JudyOS/blob/master/vtl02/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...


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 8:21 am 
Offline
User avatar

Joined: Tue Mar 21, 2017 6:57 pm
Posts: 81
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:
              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.


Last edited by mvk on Mon Jun 24, 2019 8:36 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 8:36 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1395
Location: Scotland
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:

Attachment:
cbm2.png
cbm2.png [ 11.29 KiB | Viewed 2784 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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 2:55 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1922
Location: Sacramento, CA, USA
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:
              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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 8:11 pm 
Offline
User avatar

Joined: Tue Mar 21, 2017 6:57 pm
Posts: 81
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 8:35 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10789
Location: England
Do there have to be 64 unique variables? Must be possible to drop one?


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 24, 2019 9:00 pm 
Offline
User avatar

Joined: Tue Mar 21, 2017 6:57 pm
Posts: 81
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 25, 2019 5:10 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1922
Location: Sacramento, CA, USA
Well, here's a suggestion that might work:
Code:
; 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:
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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 25, 2019 7:19 am 
Offline
User avatar

Joined: Tue Mar 21, 2017 6:57 pm
Posts: 81
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 26, 2019 7:19 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1922
Location: Sacramento, CA, USA
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 ...)

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 27, 2019 9:00 am 
Offline
User avatar

Joined: Tue Mar 21, 2017 6:57 pm
Posts: 81
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 7:53 pm 
Offline

Joined: Sat Jul 06, 2019 8:20 am
Posts: 9
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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 10:11 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 16, 2019 3:27 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1922
Location: Sacramento, CA, USA
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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 123 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: