RUM source discussion zone

[gauze]

this has been up for a while
roadsidethoughts.com/vectrex/the-rum.htm

and is considered the authoritative source now.

while I have found oddities in the taft/tompin/etc disassemblies before some seemed like they might be typos in the translations, this is the same in this RUM and decades old disassemblies:


this is Print_Str: here:
vectrexmuseum.com/share/coder/DIS/TOMLIN/NEW/BIOS.ASM

Print_Str:      STU     Vec_Str_Ptr     ;Save string pointer
               LDX     #Char_Table-$20 ;Point to start of chargen bitmaps
               LDD     #$1883          ;$8x = enable RAMP?
               CLR     <VIA_port_a     ;Clear D/A output
               STA     <VIA_aux_cntl   ;Shift reg mode = 110, T1 PB7 enabled
               LDX     #Char_Table-$20 ;Point to start of chargen bitmaps
LF4A5:          STB     <VIA_port_b     ;Update RAMP, set mux to channel 1


and RASTER/RASTUR in the rum above:

RASTUR   STU       MESAGE         ;IF U REG POINTS TO STRING <----
RASTER   LDX       #ASCII-$20     ;FOR STANDARD ASCII <----
        LDD       #$1883         ;ALPHA-NUM USING ASCII CODES <----
        CLR       DAC
                                 ;SUPPORTS CODES $20-$6F. $20-$5F ARE STANDARD.$80=DELIM
        STA       ACR            ;MINIMUM 3 CHARS. CODES $60-$6F=GRAPHIC CHARS, SEE DATA
        LDX       #ASCII-$20     ;DECODE TABLE 5X7
TOFWD    STB       PORT           ;START ZEREF UPDATE


Why is it doing that LDX line twice?!?!? this has to be a typo right? I can't think of any side effect that would change X between those two assignments, so the first one is superfluous.
OR explain, slowly, what is going on there (maybe a X cycle NOP before that STB?)

[Peer]

Have you, or has anyone else, checked which of the LDX is truly there by "disassembling" the BIOS of a real Vectrex console? A simple peek at the corresponding addresses should tell, i.e. just write a small program which checks this and let it run on a real Vectrex. Just an idea. I would try this myself, but I am away from my console right now.

Cheers,

Peer

[gauze]

Dec 1, 2021 11:06:27 GMT -5 Peer said:

Have you, or has anyone else, checked which of the LDX is truly there by "disassembling" the BIOS of a real Vectrex console? A simple peek at the corresponding addresses should tell, i.e. just write a small program which checks this and let it run on a real Vectrex. Just an idea. I would try this myself, but I am away from my console right now.

Cheers,

Peer

Well, the Tompin/Taft disassemblies are just that.

[gauze]

Print_str is $F495

looking at hexedit view of BIOS.BIN from Vide:

00000490   C8 24 7E F3  4F FF C8 2C  8E F9 D4 CC  18 83 0F 01  .$~.O..,........
000004A0   97 0B 8E F9  D4 D7 00 0A  00 CC 80 81  12 0C 00 D7  ................


to get our placement ...
STU extended addressing opcode is $FF
$C82C is Vec_Str_Ptr/MESAGE

LDX extended is $8E
$F9D4 is (Char_table $F9F4- $20)
...
if you look further in at $F4A2 that instruction and operands are repeated.

[Peer]

Ah, ok, I guess I misread or misinterpreted your initial post. I thought that by typo you meant a typo in the transcript of the disassembly, but now I see that you suggested a typo done by the original bios designers? Sorry, I was rather in a hurry, when I read your post.

[gauze]

Dec 1, 2021 15:48:12 GMT -5 Peer said:

Ah, ok, I guess I misread or misinterpreted your initial post. I thought that by typo you meant a typo in the transcript of the disassembly, but now I see that you suggested a typo done by the original bios designers? Sorry, I was rather in a hurry, when I read your post.

I originally assumed the old disassembly was a typo but then seeing the original source it's there too, which I guess makes sense since it'd throw the positions off of the entry points etc if it wasn't.

Anyway I was wondering if there could possibly be a legit reason to do it that way, as I sure don't see one.

I have another RUM discussion to start concerning CURVY in the RUM source but I'll save it.

[gauze]

ok messing around with the CURVY function from the RUM that is Commented out so is not a built in function but uh I could draw some stuff I am still not entirely sure how to use it:

;; from RUM commented out;
CURVY:              LDD      #$8118                       ;DRAW CURVED LINE FROM UPDATE TABLE <----
                   STA      VIA_port_b
                   STB      VIA_aux_cntl                 ;U - REG IS POINTER
                   BRA      RAINY

JELLO               STB      VIA_port_b                   ;FORMAT- Y,ON/OFF,X,X,X
                   STA      VIA_shift_reg                ; 0 GOES TO NEXT Y, ADDIT. 0 ENDS
JALLO               LDA      ,U+
                   BEQ      BRAINY                       ;UPDATING X-VALUES
                   STA      VIA_port_a
                   BRA      JALLO

BRAINY              LDB      #$81                         ;RAMP OFF
                   STB      VIA_port_b
                   STA      VIA_shift_reg                ;VID OFF
RAINY               LDA      ,U+                          ;NEXT Y
                   BEQ      JFIN                         ;IF DONE
                   STA      VIA_port_a                   ;IF GOOD Y VAL
                   DECB    
                   STB      VIA_port_b                   ;BEGIN S/H
                   LDD      ,U++                         ;A=VID ENBL, B=NEXT X
                   INC      VIA_port_b                   ;Y S/H DONE
                   STB      VIA_port_a
                   LDB      #$01
                   BRA      JELLO

JFIN                LDA      #$98
                   STA      VIA_aux_cntl                 ;PUT BACK
                   RTS

; cart header section removed
main
                 jsr Wait_Recal  
                 jsr Intensity_7F
                 clra
                 clrb
                 jsr  Moveto_d
                 ldu  #Shape_69
                 jsr  CURVY  
                 jmp main

;;
Shape_69 ; test CURVY shape(s)
fcb -127, %00000001 ; Y start, "on off" I think only 1 bit counts?

fcb 127,-127,127,-127,127,-127,127,-127,127,0  
fcb -127,-127,127,-127,127,-127,127, -127,127,0
fcb -127,-127,127,-127,127,-127,127, -127,127,0
fcb 127,-127,127,-127,127,-127,127,-127,127,0
fcb 10, 33 , -10, 36 ,40, 1,60,70,1,90,100, -90,-1,-90,-95,-1,-20, -10, 127, 0 ; 0 = end




any ideas on the list format??

[Malban]

You might look in Vide/codelib/Snippets/Malban/CLINES

There is a "demo" of this with commented source.

Regarding your question:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;                         draw_curved_line
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; taken from "RUMCHIP.ASM" file, found somewhere...
; corrected, commented and renamed labels (by )
;
; subroutine for printing curved lines
; expects pointer to update table in U
; expects DP pointing to $D0
;
; update table has following format:
;                   DB  Y_update, VIDEO_enable, X_update, Xupdate,... ,0
;                   DB  Y_update, VIDEO_enable, X_update, Xupdate,... ,0
;                   DB  ...
;                   DB  0       ; 0 end of update list
;
; VIDEO_enable is a SHIFTREG poke
; this means $ff             == solid line
;            $00             == invisible line
;            everything else == somewhat dotted line
;
; Note: smoothest curved lines with X slopes
;       Y slopes tend to have some edges (since the integration must be
;       stopped for Y updates)
;

Don't you trust Vide anymore ?

[gauze]

I sure didn't know that was in there, I notice it's altered because Video_enable doesn't set shift register in the original, but in your version it (in VIDE anyway) doesn't effect output except for 0 (beam off) and non-zero values (on), dashed lines for Video_enble, do not work.
Also scale doesn't appear to effect drawing at all in either version.

I looked at the example That's a lot of curve coordinates what tools did you use to figure all that out?

[Malban]

Hm, not sure what you are talking about, the sources are 100% the same, except for the names of the lables, the comments and a few NOPs (the first "D"-register is swapped also, this is a correction, since the "81" SHOULD be in "B" as it is decremented later and again stored to via_b, I am pretty sure that this is a bug in the original source).

So Video_enable DOES set the shift register!

That being said - I was young and unexperienced. The "VIDEO_enable" should be either 0x00 or 0xff, there is no "dotted" line here...

For to be "dotted" the shiftreg must be updated every 18 cycles, this is not the case.

As how to figure out... trial and error...

[gauze]

ah right sorry, I guess I didn't mean it doesn't set it I mean it doesn't USE IT like you expect shift reg to be used (to draw bit pattern lines) it's just 0 or nonzero to enable. How my mind processes things sometime is not always right :S

[minsoft]

Nov 30, 2021 23:53:40 GMT -5 gauze said:


RASTUR   STU       MESAGE         ;IF U REG POINTS TO STRING <----
RASTER   LDX       #ASCII-$20     ;FOR STANDARD ASCII <----
        LDD       #$1883         ;ALPHA-NUM USING ASCII CODES <----
        CLR       DAC
                                 ;SUPPORTS CODES $20-$6F. $20-$5F ARE STANDARD.$80=DELIM
        STA       ACR            ;MINIMUM 3 CHARS. CODES $60-$6F=GRAPHIC CHARS, SEE DATA
        LDX       #ASCII-$20     ;DECODE TABLE 5X7
TOFWD    STB       PORT           ;START ZEREF UPDATE


Why is it doing that LDX line twice?!?!? this has to be a typo right? I can't think of any side effect that would change X between those two assignments, so the first one is superfluous.
OR explain, slowly, what is going on there (maybe a X cycle NOP before that STB?)

I noticed this recently. I have a few routines which are based on Print_Str, and I just removed one of the LDX's (the first one). Works fine as far as I can tell...but I've only got 2 Vectrexes to test on.