Jump to content

Photo

Assembly on the 99/4A


714 replies to this topic

#701 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,665 posts
  • Location:Denmark

Posted Sun Mar 25, 2018 12:56 AM

Here's a bit of (untested) assembly code for writing attributes for a sprite to VDP that both supports EC and adjusts the y coordinate. This is assuming that the VDP write address been set up in advance.

       MOVB @COLOR,R0       ; Get sprite color
       MOV  @X_POS,R1       ; Get X coordinate
       JGT  NO_EC           ; Skip if x > 0
       ORI  R0,>8000        ; Set EC bit in color "TAG"
       AI   R1,32           ; Shift 32 pixels
NO_EC  SWPB R1              ; Swap to MSB
       MOV  @Y_POS,R2       ; Get Y coordinate
       DEC  R2              ; Adjust y for screen
       SWPB R2              ; Swap to MSB
*      Write to VDP
       MOVB R2,@VDPWD       ; Write y
       MOVB R1,@VDPWD       ; Write x
       MOVB @PATTERN,@VDPWD ; Write pattern
       MOVB R0,@VDPWD       ; Write color and EC


Edited by Asmusr, Sun Mar 25, 2018 1:00 AM.


#702 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,052 posts
  • Location:Germany

Posted Sun Mar 25, 2018 8:29 AM

Q7: What is “TAG” in Fig 2-20 of the data book? The fourth byte in the screen attribute table was early clock + color code? How’s that “TAG?”

 

Lack of a better name. How would you call a data element that contains a color and another function bit unrelated to color?



#703 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Sun Mar 25, 2018 11:20 AM

Here's a bit of (untested) assembly code for writing attributes for a sprite to VDP that both supports EC and adjusts the y coordinate. This is assuming that the VDP write address been set up in advance.


Thanks for clarifying the pseudocode example this this Assembly code example Rasmus. The fog is starting to lift regarding the Early Clock bit.

What I think (hope) I’m beginning to understand is:

A. A sprite’s horizontal x-coordinate can only be described in the table’s range 0-255, since it’s that’s the limit of that second byte of storage in the Sprite Attribute Table. The limit is simply a function of the structure of this table which allows only one byte for horizontal position. That byte being byte #2 of the sub-block describing the Sprite position.

B. Since the Sprite origin is the top-left corner, the programmer may wish to use the Early Clock bit ON, to allow the hardware to subtract 32 from the horizontal descriptor (in the Sprite Attribute Table), so sprites can blend in from left to right, as they emerge from the left side of the screen.

**** The 32-bit shift is performed by hardware.

C. Your code can manage horizontal ranges from -32 to 255, test for x<o, and then invoke the early clock until the Sprite is fully visible (x>=0). At which point you would turn the early clock off for that Sprite.

So....

If I wish for a 16-bit wide Sprite to have only its right 8-bits showing on the left side of the screen, I need to do the following:

Setup Screen Attribute Table like this:

Byte 1 : any (Y) horizontal position 0-255 (except 208)

Byte 2 : vertical position X = 24 ( since 24-32 = -8 )

Byte 3: any name

Byte 4: MSB = 1000 (EC on); LSB = color code

That’ll do it right?





Sent from my iPad using Tapatalk

#704 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,665 posts
  • Location:Denmark

Posted Sun Mar 25, 2018 12:10 PM

Byte 4: MSB = 1000 (EC on); LSB = color code

That’ll do it right?

 

This part is wrong, it's only one byte so there isn't a MSB and LSB. The bits are like this EXXXCCCC where E is the early clock bit, X doesn't matter and C is color. In hex the value of the early clock bit is >80 and the second hex digit is the color. [edit: that's probably also what you meant!]


Edited by Asmusr, Sun Mar 25, 2018 12:21 PM.


#705 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Sun Mar 25, 2018 2:36 PM

Right. I was thinking B as in Bit. I understand the EC is set by the most significant bit in the fourth byte. Perhaps, my bad for using the wrong phraseology. Yes. Besides this, I must have it correct?


Sent from my iPhone using Tapatalk Pro

#706 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Sun Mar 25, 2018 2:37 PM

I should have said most significant Nibble, least significant nibble. I’ll move along to a few sprite test programs now...

Edited by Airshack, Sun Mar 25, 2018 2:39 PM.


#707 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,466 posts
  • Location:Castaic, California

Posted Sun Mar 25, 2018 2:48 PM

Q2: On to the Sprite Attribute Table... Why is the top ROW of y-pixels located a -1 when the leftmost COLUMN of x-pixels are located at 0?

The top left pixel position is (-1y,0x)? Why not 0y,0x?

 

This has to do with time and memory access.  The 9918A is a scan-line based device, i.e. it only figures out what needs to be displayed on the screen one scan line at a time.  Without going into the gory details of it all, there is a lot going on during a scan line to get the picture drawn on the screen.  Figuring out what sprites to draw on a scan line takes quite a bit of time, and so the VDP does a lot of the sprite processing *during* the current scan line, which means the sprites appear on the following scan line.

 

For example, during scan line 0, the sprite list is processed and sprites with a Y-coordinate of 0 are remembered, up to a limit of 4-sprites since that is the max number of sprites the VDP can put on a single line (there are only four sprite shift registers).  During the horizontal blank period, the pattern data for any of the sprites found on that scan line (scan line 0 in this example) are loaded into the sprite shift registers.  The shift registers are used during the next scan line (which would be scan line 1 in this example) to provide the pixels that make up the sprite.  So during scan line 1, the sprites for scan line 0 are shifted out, while sprites for scan line 1 are being determined.

 

Thus, spites always show up one line after their specified Y-position.  So to get a sprite on scan line 0, it needs to be processed on line -1, which is the same as a Y-position of 255.  Higher level languages can hide this from you, but when working directly with the hardware you have to deal with it yourself.  Also note that the collision flag will also be off by 1 line compared to a sprite's Y-position as well.  That is because collisions are detected by the VDP during scan-out of the pixel data from the sprite shift registers.

 

Q9: Lastly, is the EC something I need to manage (endlessly setting and clearing and setting...) throughout my code? Is this normal or is it either set or cleared upon initialization of the VDP registers at startup?

I think you are realizing this.  You have to manage the early-clock bit in your own code, and update the sprite table if you want to have sprites that can move in from the left of the screen.  It is a pain, but that is just how it goes on the old systems.  Lots of limitations.  The 80's era of coin-op arcade machines were similar, since most of them were 8-bit machines but the screen resolutions were consistently more than 256 pixels wide.  So they had to deal with a 9-bit X-position on an 8-bit computer.  In a sense, the early-clock bit is just like that.  You are dealing with X-positions that are greater than 255, so you have to manage that yourself.

 

The easiest way to deal with it is to keep your sprites confined to the visible display and don't "slide in" from the left.  You don't have this problem in the Y direction because there are only 192 visible lines, and that easily fits into the range of a single byte, with enough range left over to slide in and out from the top and bottom of the active display.

 

As for a default setting for the bits, there is none.  The sprite attribute table is in VRAM (not VDP registers), which is made up of DRAM chips, and the contents of DRAM at power on or reset is going to be random.  It is up to you, the programmer, to initialize all your VDP table data, as well as the VDP registers.  Don't assume anything and you won't have any surprises.
 

**** The 32-bit shift is performed by hardware.

 

Everything dealing with the 9918A is done in hardware.  It is a task-specific IC and does not have a CPU or any kind of "processing" capability in the general sense.  It consists of a bunch of counters, shift registers, fixed state machines, and random logic.  Also, technically, in the case of the 32-bit shift of the early-clock, no shift of the data actually happens.  It is literally allowing the clock signal to the sprite shift registers to happen early in the scan line, hence the name "early clock".  If the sprite shift registers start shifting early, then the sprite appears sooner during the scan line.

 

You can also just think of it in the logical sense without knowing the technical details about how it works.  You have one byte for a sprite's X-position, so 0..255, and you also have 0..255 visible screen positions.  With the early-clock bit set to 0, the X-position has a range of 0..255, i.e. an unsigned byte.  With the early-clock bit set to 1, the X-position is partially signed and represents X-positions from -32..223.  The visible screen is always 0..255, so just map accordingly.



#708 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Sun Mar 25, 2018 8:46 PM

Thanks again guys for helping me stumble through this material. I’ll have to write a few routines to test what I’ve learned from your valiant efforts at instructing me.

Edited by Airshack, Sun Mar 25, 2018 8:47 PM.


#709 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Mon Apr 2, 2018 12:46 PM

How does one test on real metal once a program is assembled and running in Classic 99 via the E/A cart?

 

Specifically: How do I port a file from a Classic99 FIAD and/or DSK image to my TI-99/4A?

 

My RS-262 isn't modded so there's no physical connection between my TI and PC, at the time. What do you guys do in your workflow?

 

I have a nanoPEB as well as a full-up PEB with Lotherek SD based floppy emulator, which uses .hfe. Also, I'm FlashGROM99 capable. In the past I programmed with XB256 & Harry's compiler; created a .bin with Module Creator 2.0; copied the .bin to FlashGROM99 SD. Worked great! Things are different with assembly...

 

Any and ALL suggestions appreciated.

 

My attempts at creating a .bin with Asm994a yield "ADDRESS ERROR: Relocatable address not allowed in cartridge object!" I'm guessing everything has to be fixed in a cartridge binary...which is something I'm also working on understanding.

 

Also, I played around with both TI ImageTool and TI99dir...couldn't figure anything out.?

 

Thinking the nanoPEB is currently my best option but not sure of the steps necessary to get this done. I'm probably overthinking something easy.



#710 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 265 posts

Posted Mon Apr 2, 2018 3:33 PM

Isn't there software for the Lothartek Drive that converts from DSK to HFE? I haven't done it for a while but I did it when I was trying out some XB programs on real iron



#711 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Mon Apr 2, 2018 3:41 PM

Isn't there software for the Lothartek Drive that converts from DSK to HFE? I haven't done it for a while but I did it when I was trying out some XB programs on real iron


Like you, I haven’t Lotherek’d in a good while. I vaguely remember doing something like this via a Lotherek download HFE manager?

Lotherek’s site is low on TI documentation.


jjs

#712 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,052 posts
  • Location:Germany

Posted Mon Apr 2, 2018 3:50 PM

Also, I played around with both TI ImageTool and TI99dir...couldn't figure anything out.?

 

If you want to create a HFE image for Lotharek, all you do is create a new floppy image in HFE format, then copy your desired files on that new image.

 

(File->New->Floppy image, Image type: HFE image)

 

If you come from a DSK image, open that image, copy-paste the files into the HFE image. If you have TIFILES, drag and drop the TIFILES into the HFE image.

 

[Edit: Using TIImageTool]


Edited by mizapf, Mon Apr 2, 2018 4:04 PM.


#713 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Mon Apr 2, 2018 4:04 PM

Using.....TI Image Tool! Thanks!

I was having little success with a nice constant mix of DISK ERROR 16s and a few DISK ERROR 6s until I got the .hfe formatted properly: DSSD, 80tracks.

I believe my problem was with attempting to create Double Density disks. Apparently the TI disk controller didn’t like that?

Anyway, thank you for getting me across yet another learning bridge!

04194e7a35bac9b0ae80720ff162355d.jpg

Progress!

Edited by Airshack, Tue Apr 3, 2018 10:47 AM.


#714 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 11,643 posts
  • Location:워싱턴 주

Posted Thu Apr 5, 2018 9:28 PM

                sml_gallery_35324_1027_3246.png

sml_gallery_35324_1027_923.pngLooks GREAT!



#715 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 643 posts
  • Location:Phoenix, AZ

Posted Thu Apr 5, 2018 10:51 PM

...

Edited by Airshack, Sun Apr 15, 2018 9:19 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users