Jump to content

Recommended Posts

 This makes an average of 7.8125 cycles per byte.

 

I think we have a winner.  :) And it's not just a theoretical exercise - this code can be used when drawing vector graphics to a CPU RAM buffer before sending it to the VDP. Each frame you have to clear the buffer.

Share this post


Link to post
Share on other sites

Too bad everyone is in such a hurry to add layers and get as far away from the CPU as possible these days.

 

If you mean that apparently only a few will know what's going on at lower levels, then yes.

 

Otherwise I think it's only a natural productive process to build layers (to abstract) and to build upon what others have built.

 

Even an assembler is moving away from entering hexadecimal values etc.

 

There's the danger of us ending up not knowing what the machines actually do with all the layers, and eventually the machines can plot to take control. Well, they will probably fight each other. Someday the 9900 will rule. Behind the innocent MIPS was a sleeping tiger.

 

;)

Share this post


Link to post
Share on other sites

Since STST doesn't do a read before write, would clearing CPU RAM using STST overrun the VDP?


(Clearing VDP RAM) Absolutely and by a long shot. You need 8 microseconds between writes, that's 24 cycles. Our assertions that you can't overrun the VDP were based on moving data. STST is only 8 cycles, targeting the VDP would make it 12. Even CLR at 10 cycles is too fast - targeting the VDP makes it only 18.

Of course you can use it while the VDP is in blank - either vertical blank or display blanking enabled.

(edit: the fastest data move, assuming you could change a register dynamically, MOVB R1,*R2 is 14 for the opcode, 4 for the indirect, and 8 for the wait states, making 26 cycles. More commonly it'd be MOVB *R1+,*R2, which adds another 8 cycles for the indirect auto-increment and makes 34 cycles. But you could use the former for a direct-to-VDP clear, if there was a reason that was useful (or you had custom hardware, which was something I wanted to try ;) ) Edited by Tursi

Share this post


Link to post
Share on other sites

(Clearing VDP RAM) Absolutely and by a long shot. You need 8 microseconds between writes, that's 24 cycles. Our assertions that you can't overrun the VDP were based on moving data. STST is only 8 cycles, targeting the VDP would make it 12. Even CLR at 10 cycles is too fast - targeting the VDP makes it only 18.

Of course you can use it while the VDP is in blank - either vertical blank or display blanking enabled.

 

Excellent. Great news. So, until proven otherwise, we still, after so many years, find new ways to improve performance.

 

:thumbsup:

Share this post


Link to post
Share on other sites

(Clearing VDP RAM) Absolutely and by a long shot. You need 8 microseconds between writes, that's 24 cycles. Our assertions that you can't overrun the VDP were based on moving data. STST is only 8 cycles, targeting the VDP would make it 12. Even CLR at 10 cycles is too fast - targeting the VDP makes it only 18.

Of course you can use it while the VDP is in blank - either vertical blank or display blanking enabled.

(edit: the fastest data move, assuming you could change a register dynamically, MOVB R1,*R2 is 14 for the opcode, 4 for the indirect, and 8 for the wait states, making 26 cycles. More commonly it'd be MOVB *R1+,*R2, which adds another 8 cycles for the indirect auto-increment and makes 34 cycles. But you could use the former for a direct-to-VDP clear, if there was a reason that was useful (or you had custom hardware, which was something I wanted to try ;) )

 

I've found you can write bytes to the VDP at 24 cycles per byte with this method:

LWPI >8C00   ; Set the workspace pointer so that R0 is at VDP Write Data register
LI R0,>1200  ; Write >12 to VDP
LI R0,>3400  ; Write >34 to VDP
LI R0,>5600  ; Write >56 to VDP
LI R0,>7800  ; Write >78 to VDP
; etc
LWPI >8300   ; Restore the default workspace pointer
RT           ; Return

When running in 8-bit RAM or cartridge ROM, each LI takes 24 cycles.  At the expense of 4 bytes for each instruction per byte written to the VDP.  By my estimates you could load about 2KB per 60Hz frame using this method, although the instructions would take up 8KB.  If performance is critical, the tradoff might be worth it.  Might also be a good use case for taking advantage of SuperAMS memory.

Share this post


Link to post
Share on other sites

Seems we need a DSR and Device that uses RAM instead of VDP for Buffer I/O of data.

 

I thought the SCSI card still set up a buffer but on board RAM is used instead?

 

So the VDP buffer is there but just to make the OS happy, nothing is really taking place other than the PAB is updated.

 

The buffer address in the PAB is just not used, but instead that address in PAB  is where to put it in RAM from the Device.

Edited by RXB

Share this post


Link to post
Share on other sites

 

I've found you can write bytes to the VDP at 24 cycles per byte with this method:

LWPI >8C00   ; Set the workspace pointer so that R0 is at VDP Write Data register
LI R0,>1200  ; Write >12 to VDP
LI R0,>3400  ; Write >34 to VDP
LI R0,>5600  ; Write >56 to VDP
LI R0,>7800  ; Write >78 to VDP
; etc
LWPI >8300   ; Restore the default workspace pointer
RT           ; Return

When running in 8-bit RAM or cartridge ROM, each LI takes 24 cycles.  At the expense of 4 bytes for each instruction per byte written to the VDP.  By my estimates you could load about 2KB per 60Hz frame using this method, although the instructions would take up 8KB.  If performance is critical, the tradoff might be worth it.  Might also be a good use case for taking advantage of SuperAMS memory.

 

Cool. It could be useful if you want to, for instance, upload sprites patterns to the VDP on the fly.

 

It reminded me of this video where the 3D frames are stored as code instead of data in order to squeeze the maximum speed out of the MSX.

https://www.youtube.com/watch?v=wXxisSPAZhk

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...