Messages

Its not the BIOS.

I checked with a program...
- but I'll try it on a different Vectrex... might be that my test vectrex is a bit "special"...

It behaves a bit differently on occasions (thats why it is my test Vectrex :-) ).

Cheers

Malban

I only tested it with my "work" Vectrex -- there (as in the Video) it works.
I can test it (later today) with some other Vectrex.

I used Vectrex32 firmware 1.20 - didn't put a test in front.

If you have a very "dim" vectrex - perhaps you only need to regulate the brightness a bit?

Anyways.. the result of the peek = 129?
That would be $81.

Which is a strange value. The function writes (on success) the "which" value - which is 3.
And before the function call, I explicitly write a 0 to it (pokeRAM(0, $c880)).

So... I have no clue on how that value could be put into that location.

best guess on my part is the firmware?

See proof of concept:

http://forums.vectrex32.com/index.php/topic,99.msg541.html#msg541

Proof of concept:

http://vectrex.malban.de/tmp/Lightpen.mp4

Code Select Expand


' Define display configuration.
scale = 80
intensity = 100
frame_rate = 50

' Define various UI configuration.
instructions = { _
   {-50, 100, "LIGHTPEN TEST"} _
}
picked = { _
   {-10, -50, "PICKED"} _
}

call initRAMSub()
DIM peekdata[2]' Send a message to the Vectrex to peek at memory

wasSelected = 0
pickResultAddress = $c880

repeat
   call IntensitySprite(intensity)
   call SetFrameRate(frame_rate)
   call ScaleSprite(scale)

   ' Display instructions.
   textSize = {60, 3}
   call TextSizeSprite(textSize)
   call TextListSprite(instructions)

   if wasSelected = 3 then
   call TextListSprite(picked)
   endif


   call pokeRAM(0, $c880)

   call draw_LP_Line(50,0,3)
   call draw_LP_Line(0,50,3)
   call draw_LP_Line(-50,0,3)
   call draw_LP_Line(0,-50,3)


   wasSelected = 0
   CALL Peek(pickResultAddress, 1, peekdata)

   ' Get user input
   controls = WaitForFrame( JoystickDigital, Controller1 + Controller2, JoystickX + JoystickY )

   WHILE   peekdata[1] = 0
   ENDWHILE

   wasSelected =peekdata[2][1]

   call ClearScreen()

until controls[1, 6]
stop

' draws line with current scale etc
' when a lightpenPick was done, than
' Peek $c880 = which
' (after WaitForFrame...)
sub draw_LP_Line(x,y, which)
' all values must be FORCIBLY bytes
' negative values (e.g. -50, must be written as 205
if x<0 then
  x = 256 +x
endif
if y<0 then
  y = 256 +y
endif
   drawLineWithPick = {$CC, y, x, $bd, $c9, 0, $27, 5, $86, which, $b7, $c8, $80}
   call CodeSprite(drawLineWithPick)
endsub
   
sub pokeRAM(what, where)
   if what<0 then
    what = 256 +what
   endif

   poke_RAM = {$86, what, $b7, (where/256) MOD 256, where MOD 256}
   call CodeSprite(poke_RAM)
endsub

sub initRAMSub
initDrawPickLineDSub = { _
$20, $27,  _
$b7, $d0, $01,  _
$7f, $d0, $00,  _
$86, $ff,  _
$7c, $d0, $00,  _
$f7, $d0, $01,  _
$b7, $d0, $0a,  _
$7f, $d0, $05,  _
$cc, $00, $40,  _
$f5, $d0, $0d,  _
$27, $fb,  _
$1e, $11,  _
$b7, $d0, $0a,  _
$b6, $d0, $0d, _
$84, $02,  _
$39,  _
$1f, $51,  _
$30, $88, $d7,  _
$ce, $c9, $00,  _
$ec, $81, _
$ed, $c1, _
$11, $83, $c9, $27, _
$25, $f6 _
}

   call CodeSprite(initDrawPickLineDSub)

   controls = WaitForFrame( JoystickDigital, Controller1 + Controller2, JoystickX + JoystickY)
   call ClearScreen()

endsub

'copies a lineDrawWith Pick subroutine to $c900
' which is called with the coordinates in D
'
'                          |;***************************************************************************
'  0056                    |copy
'  0056  20 27             |                    bra      start
'                          |
'  0058                    |draw_vector_with_pick_check:
'  0058  b7 d0 01          |                    sta      >VIA_port_a                  ; Set rel y position.
'  005b  7f d0 00          |                    clr      >VIA_port_b                  ; mux sel = integrator Y, mux enabled
'  005e  86 ff             |                    lda      #$ff                         ; pattern = $ff -> full line
'  0060  7c d0 00          |                    inc      >VIA_port_b                  ; mux off
'  0063  f7 d0 01          |                    stb      >VIA_port_a                  ; Set rel x position.
'  0066  b7 d0 0a          |                    sta      >VIA_shift_reg               ; Set line pattern.
'  0069  7f d0 05          |                    clr      >VIA_t1_cnt_hi               ; start t1 timer (scale)
'  006c  cc 00 40          |                    ldd      #$0040                       ; bit 6 = t1 timer interrupt
'  006f                    |timerCheck_loop:
'  006f  f5 d0 0d          |                    bitb     >VIA_int_flags               ; check if scale has run out
'  0072  27 fb             |                    beq      timerCheck_loop              ; if interrupt not set -> timer still running
'  0074  1e 11             |                    exg      x,x                          ; delay
'  0076  b7 d0 0a          |                    sta      >VIA_shift_reg               ; shiftreg = 0, pattern = 0, light is off
'  0079  b6 d0 0d          |                    lda      >VIA_int_flags               ; Check for a lightpen pick
'  007c  84 02             |                    anda     #$02                         ; bit 1 = ca1 interrupt
'  007e  39                |                    rts     
'                          |
'  007f                    |draw_vector_with_pick_check_end
'  007f                    |start
'  007f  1f 51             |                    tfr      pc,x
'  0081                    |here
'  0081  30 88 d7          |                    leax     <(draw_vector_with_pick_check-here),x
'  0084  ce c9 00          |                    ldu      #$c900
'  0087                    |copyOn
'  0087  ec 81             |                    ldd      ,x++
'  0089  ed c1             |                    std      ,u++
'  008b  11 83 c9 27       |                    cmpu     #$c900 +(draw_vector_with_pick_check_end-draw_vector_with_pick_check)
'  008f  25 f6             |                    blo      copyOn



More on the lighten subject (+ assembler sources, that might be added/changed to codeSprites) "within" Vide: http://vectrex.malban.de/preliminary/7fc4fa15.html

Trying out the Bezier thingy.

Loaded the program and it runs well.
The textsize does not display to well on my vectrex, so I wanted to draw smaller text.

The instruction is defined as:
instructions = { _
   {-50, 100, "INSTRUCTIONS"}, _
   {-80, 90, "PRESS BUTTON 1 TO +1 BEZIER STEPS."}, _
   {-80, 80, "PRESS BUTTON 2 TO -1 BEZIER STEPS."}, _
   {-80, 70, "MIN STEP IS 1 - MAX STEP IS 20."}, _
   {-80, 60, "USE JOYSTICK TO MOVE CURSOR."}, _
   {-80, 50, "PRESS BUTTON 3 TO (UN)SELECT."}, _
   {-80, 40, "PRESS BUTTON 4 TO EXIT."} _
}


and called later with

   ' Display instructions.
   textSize = {25, 2}
   call TextSizeSprite(textSize)
   call TextListSprite(instructions)

However the smaller size given (with the second parameter "2") is only used for the first line, not for the complete text:


Shouldn't the size be used for all the text?

Malban

Thinking further about my last reply to the lightpen post.

I again would like to ask the question, do you use (besides the BIOS area and possible a little bit of the stack) any Vectrex RAM?

If not.
Crazy idea...

To possibly enhance the BASIC with commands (accesses to Vectrex HW etc...) that are not implemented yet...

One could design a couple of code sprites that
a) first step
setup assembler routines in (Vectrex) RAM

b) second step
use "in game" code sprites to call these routines

c) use specific RAM locations to transport values if needed.

Perhaps there are not MANY usages - but some exotic ones come to mind, like:

- Access lightpen
- Access VecVox/VecVoice

... just some thoughts...

Malban

Hi,
I haven't used Vectrex 32 in a while - so forgive me if I reply some nonsense ...
Actually I think it should be possible to use a lightpen in BASIC.

In theory - I haven't tried it.
And you do not have to use interrupt routines.

BUT - I dunno how - but you need to pass some information from a CodeSprite back to the "caller". Perhaps some reference pointer to a variable or so. Is that possible?

If so you could:

Build a codeSprite that clears the CA1 interrupt flag
Build a codeSprite that checks the CA1 interrupt flag and sets a return code.

Than you could "wrap" a draw with the above...

And if the return code was set, than the drawn vector was "Picked".

If the above is possible in BASIC, than you can do all lightpen work that is needed.

The three most used lightpen situations
a) pick a vector
b) move a vector
c) find a position

Can be implemented in BASIC.
a) is actually the above

b) draw a "web" like in Artmaster, but with a BASIC subroutine

c) Find a position - implement as a BASIC subroutine, but unlike Artmaster...
Artmaster draws 122 horziontal lines and the line that is picked is the "Y" position.
Artmaster than uses an interrupt routine to calculate the X position.
BUT instead of that, you might as well draw 122 vertical lines and see where the pick occured - that would be your X position.
It is a bit slower - yes, but that shouldn't really matter.

Cheers Malban


PS
Just read about the Code Sprite.
You said it is "live" data (and as such in RAM).
Could a code sprite therefor change itself?
Set e.g. the first byte of its own code to:  "1" or "0"?
And could than from BASIC the live data be accessed with (in your example words):
if (machineCode[0] = 1) then ...

If so - would the CodeSprite regenerate in the next round? Or would one use a byte that is otherwise ignored, so not to destroy the assembler code?

PPS
Ahhh... reading further...
Above (live array) probably will not work...
But possible using the PEEK function. Does Vectrex32 use any RAM that is not used by the BIOS? If not than any address between say $c880 and $c900 will work to be used as a result byte...

Thomas did two approaches:
1) via the above mentioned serial cable. There a connected computer runs MAME and "pumps" vector information to the VecFever which in turn displays the vectors via a "proxy"program on the vectrex. Here you need a computer and a serial cable connected to the vectrex (vecfever)

2) via static binary compile
These are "translations" of the original arcade ROMs to "C". These C programs are compiled for the ARM chip the VecFevers hosts. Input/vector drawing and sound are passed to the vectrex. So basically these emulators (which is what they are) are running on theVecFever and using the Vectrex as input and output.
These emulators are on the VecFever and no additional hardware is needed.
These  emulators are all build by Thomas (with help of diverse others, e.g. Graham Toal) and have NOTHING todo with MAME. They only use the same ROMS - as do the original arcade version.

Malban

Hi,
Actually - there is a small checkbox next to the "Vectorlist export button" - Draw_VL_mode.

If that checkbox is checked - the outbut is done in Vec32 BASIC syntax.

But having a script is certainly more versatile...
Malban

[NO]

Hi,

while I think it is a cool suggestion, I also think it would be very difficult to do...!

Reasoning:
- the Vectrex 32 has NO direct access to the PSG, it goes thru the vectrex
- therefor on the vectrex side a program has to poke all pcm values to the amplifier logic
- in order to do that with a reasonable sample quality it must do so regularily
say you want to achieve 10000 kHz sampling rate (which is quite good - but far from fantastic).

You have to output the samples values to thru the DAC every 150 cycles.

The actual output (by code generated by Vec32) would look something like:

Code Select Expand

                   
                    LDA      #SAMPLE                          ; load the next sample_byte to A
                    STA      VIA_port_a                       ; store in reg A in 6522 (DAC)
                    LDA      #VIA_TO_DAC_OUT          ; load the calculated VIA B
                    STA      VIA_port_b                        ; write back to reg B in 6522
                    LDA      #RESTORE_VIA                  ; load the calculated VIA B
                    STA      VIA_port_b                        ; write back to reg B in 6522


Optimized that is about 30 cycles, so that leaves 120 cycles to do other stuff, like drawing vectors.

The above has to called quite regular - as said about every 150 cycles, so each of the used other routines like:
- query joystick
- draw vectorlists
- wait for frame to finish
- move to position
etc

Has to be reprogrammed, that it can be "interrupted".

"Interrupted" in marks - since an interrupt would not work,
a) it takes alone very many cycles (pushing and popping) )
b) accessing via in vectrex ->  it is in general a very bad idea to interrupt

While other programs have proven that PCM output does actually work - it is very hard to do so in a "general" way.
If I were bob - I would put that on the backburner for version V5.0 of Vectrex 32 :-).

Also:
For third generation vectrex, PCM output done the "usual" way does not work at all (or only very very quietly).
(ah, well vectrex32 does not work on noBuzz machines anyway...)

I may offer an alternative suggestions:

a) a native vectrex32 lharc unpacker, you can probably find the corresponding "C" sourcecode around any corner of the internet. With that and an additional few lines (really - few lines), you could provide support for play back ym files directly (directly as in unpack it on the vec32 side, and provide the vectrex with only the register values it needs for its update round - which at maximum would be 13 bytes)!
e.g. A nice ym file of Ben Daglish might be 6kb which is nothing for Vec32 but unpacked it is about 180kb) - which can not nearly be used by vectrex. 

Malban

@Bob:
You can take that as a challenge and prove me wrong!

No worries :-) - I have many other things todo :-).
I know that one can not test all facets of a new product prior to launching.

Thats what error reporting an forums are about...

Regards
Malban

[LOAD]

Hi,
I must confess at the moment I am extremely frustrated.
IMHO the smart card behaves a little erratic. The attached BASIC file is supposed to play YM-Data. The code is most probably correct. My smartcard quits loading with "out of memory" (I especially used a small YM file).

If you delete some of the data statements (so that the file is about 100 lines shorter) the music plays alright.
There is NO definite point where the memory error disapears! Sometimes at 150 lines, sometimes at 170... etc.
(In the manual it says Strings can be up to 4GB - is there a limit on line lengths? I am pretty sure 150 lines of data does not come near 4 GB - but I have not found a limit on line length, or how else to enter large quantity of data)

Once an out of memory error occurs, the smartcard does not react in any way any more - only switching vectrex off/on helps - which I did the last hour about 50 times - I will stop that now! My poor vectrex.

Since for the last couple of years I have been programming other languages than BASIC - while editing programs there are bound to be mistakes, some wrong thinking - some plain syntax errors.

However the error descriptions the BASIC provides are most of the time (or at least with the errors I make - very often) not helpfull.
Little example of a small stupid mistake:
instead of writing:

Code Select Expand

function initYMData()
return  { _  MUCH DATA_
}
endfunction

I accidently wrote:

Code Select Expand

function initYMData()
return = { _  MUCH DATA_
}
endfunction

The program does not LOAD anymore, the loading quits with the message:
"Invalid expression"

I had a couple of other (once you found them stupid) errors/error messages. However I have not kept a log and the errors are now gone ofter enough trial and error.

Forgive me - but for now I will rest doing BASIC stuff.

Malban

Hi,
I recently tried to use the "huge" memory of the Smartcard to my advantage (and tried vide support for that...) and write an YM-Player.
The advantage would be, that YM-files do not need to be packed in any way, and as such there would be no huge cycle impact on playing them.

Said and done, I did a BASIC output (unpacked) of an YM-file.
And the first thing I was greeted with was:
    Error creating file: /Volumes/VECTREX 32/Popcorn.asm

Well data statements in BASIC tend to be large - the file at that stage was about 350kb.

Is it right that the "RAM" of the device and the USB storage area are the same?

Or is it just coincidence, that the USB drive only has 430kb memory?
I mean - apart from storing generated data - how can I use the 512kB RAM for my vectrex programs, if the BASIC (ASCII) representation of the data already uses so much space, that I can't even get the data to my vectrex?

Perhaps I am thinking totally the wrong way.

@Bob:  Would you care to set me right or elaborate?

Thanks
Malban

Last on the subject matter :-)!

New Vide zeroing emulation, takes into account, that integration WHILE zeroing is possible.

Regards
Malban

Ok,

It is the "zeroing" - the attached screenshot is the result of the program below:

Inserting a:

Code Select Expand


LDA     #$CE            ;Blank enabled, zero disabled
STA     <VIA_cntl


gives correct results.

The delay is most of the time not necessary only in extreme fast/direct situations. If you want to be on the save side you can additionally insert a:

Code Select Expand

JSR Delay_3
(after anything BIOS related that finishes with a Reset0Ref)

Code Select Expand


;***************************************************************************
; DEFINE SECTION
;***************************************************************************
; load vectrex bios routine definitions
                    INCLUDE  "VECTREX.I"          ; vectrex function includes

;***************************************************************************
; Variable / RAM SECTION
;***************************************************************************
; insert your variables (RAM usage) in the BSS section
; user RAM starts at $c880
                    BSS     
                    ORG      $c880                ; start of our ram space

;***************************************************************************
; HEADER SECTION
;***************************************************************************
; The cartridge ROM starts at address 0
                    CODE     
                    ORG      0
; the first few bytes are mandatory, otherwise the BIOS will not load
; the ROM file, and will start MineStorm instead
                    DB       "g GCE 1998", $80    ; 'g' is copyright sign
                    DW       music1               ; music from the rom
                    DB       $F8, $50, $20, -$80  ; hight, width, rel y, rel x (from 0,0)
                    DB       "NEW PROG", $80      ; some game information, ending with $80
                    DB       0                    ; end of game header

;***************************************************************************
; CODE SECTION
;***************************************************************************
; here the cartridge program starts off
main:
                    JSR      Wait_Recal           ; Vectrex BIOS recalibration
                    JSR      Intensity_5F         ; Sets the intensity of the
                                                  ; vector beam to $5f
                    LDU      #hello_world_string  ; address of string
                    LDA      #$10                 ; Text position relative Y
                    LDB      #-$50                ; Text position relative X
                    JSR      Print_Str_d          ; Vectrex BIOS print routine

                    LDA      #$40                 ; scalefactor
                    STA      VIA_t1_cnt_lo
; HERE HERE HERE
                    LDX      #vData               ; address of string
                    JSR      Draw_VL_mode         ; Vectrex BIOS print routine


                    BRA      main                 ; and repeat forever

;***************************************************************************
; DATA SECTION
;***************************************************************************
hello_world_string:
                    DB       "HELLO WORLD"        ; only capital letters
                    DB       $80                  ; $80 is end of string
;***************************************************************************

vData = VectorList
VectorList:
DB $00, -$40, +$20 ; mode, y, x
DB $02, +$40, +$00 ; mode, y, x
DB $02, +$40, -$20 ; mode, y, x
DB $02, -$40, -$20 ; mode, y, x
DB $02, -$40, +$00 ; mode, y, x
DB $02, +$40, +$40 ; mode, y, x
DB $02, +$00, -$40 ; mode, y, x
DB $02, -$40, +$40 ; mode, y, x
DB $01 ; endmarker (1)


Ok, now I have to enhance Vide emulation again - to show exactly that behavior.



Malban