Jump to content
IGNORED

9938 High Speed Block Move


9640News

Recommended Posts

I was trying to create a demo this past week and was using one of the Video XOP's on the Geneve that does a high speed block move.  At the moment, I do not know of any Geneve programs that use the Video XOP Opcode >0012 call.  The call did not work as expected during the fill operation after the block is moved.  The move works, it is just the fill that has the issue.

 

It is the subsequent paint/fill operation of the area left behind that is not working as expected.  The V9938 manual, and the Programmer's Reference Manual show the block move always to the right and down so that none of the horizontal and vertical rows overlap.

 

However, what if one moves a large block down by a few pixel rows and over to the right a few pixel rows.  Then, you need to paint two rectangles to fill the space.  Now, add the complexity of also moving the block up and to the left, or any of the 4 potential directions, and the code to do all the fills can be challenging.

 

I have thought about the use of the extra 64K of expanded ram as a buffer, or buffering the screen in CPU ram, but that starts to negate the use of the high speed block move.

 

Is there something obvious I may be overlooking where this should be simpler than it appears?

Link to comment
Share on other sites

I did not use the MDOS XOPs, preferring to write the registers myself. 
 

For an animation, I first put all the source graphics in VDP, offscreen. I tried 4 approaches to the move. 
 

1. For example, erasing the prior area (blank fill , or restore background) then copying the object from its definition offscreen, to the screen.  (with the transparency mode, I forget what it’s called.)

 

2. Alternately, use double buffering. Draw on one page, set it to show. Draw on page two, then flip to it. 

( You need to track where things were two steps ago)

 

3. I also played with XOR copies. Copy from offscreen to new location with XOR, then copy to old location with XOR. There is flickering where they overlap. 

4. I think the fourth was XOR with a double buffer. 
 

I did these tests with a 32x32 graphic , I think. The speed was I think fine for just one object. 
 

Multiple objects, its perhaps easiest to erase them all first, then move all the new areas using offscreen source.  
 

But when erased /drawn in random order, XOR can give correct results where they overlap. If you have the background empty. 
 


 



 


 


 

 

  • Like 1
Link to comment
Share on other sites

22 minutes ago, FarmerPotato said:

I did not use the MDOS XOPs, preferring to write the registers myself. 
 

For an animation, I first put all the source graphics in VDP, offscreen. I tried 4 approaches to the move. 
 

1. For example, erasing the prior area (blank fill , or restore background) then copying the object from its definition offscreen, to the screen.  (with the transparency mode, I forget what it’s called.)

 

2. Alternately, use double buffering. Draw on one page, set it to show. Draw on page two, then flip to it. 

( You need to track where things were two steps ago)

 

3. I also played with XOR copies. Copy from offscreen to new location with XOR, then copy to old location with XOR. There is flickering where they overlap. 

4. I think the fourth was XOR with a double buffer. 
 

I did these tests with a 32x32 graphic , I think. The speed was I think fine for just one object. 
 

Multiple objects, its perhaps easiest to erase them all first, then move all the new areas using offscreen source.  
 

But when erased /drawn in random order, XOR can give correct results where they overlap. If you have the background empty. 
 

Yeah, if you have any source, it would be appreciated to see various examples.  I had not thought about the use of XOR.  What you do propose rules out the use of the second page of memory and may be a necessity to use this particular opcode call.

 

 

 

Link to comment
Share on other sites

1 minute ago, dhe said:

@9640News are you saying your code is messed up, or the XOP code is messed up?

I am saying this is an opcode call in the VID XOP that I do not believe has been used anywhere by anyone, and does not function as it should or at least how I would expect it to respond. 

  • Like 1
Link to comment
Share on other sites

6 hours ago, 9640News said:

Yeah, if you have any source, it would be appreciated to see various examples.  I had not thought about the use of XOR.  What you do propose rules out the use of the second page of memory and may be a necessity to use this particular opcode call.

 

 

 

Digging around... all I found so far was code that uses the HMMC to put images called 'FIG's into a VDP (offscreen) and copy them with LMMC.

 

I suspect it's an untested rewrite of the code I'm looking for, certainly its missing 3 of the routines it declared!

 

Stress UNTESTED.

 

I've looked through my disk catalog twice, and not seen the filenames.  Alas, they would probably be among the 'unreadable DSDD' pile of floppies. 

(worst case: Myarc 16 sector format!)

 

 

Here is ani.asm for GPL mode and 9938, and a copy on DSK (object file is useless but I made sure it assembles)

Here is also a weird file 'cmd38.asm' that I dunno if I wrote or got somewhere. It's missing a few lines at the top (CMDWS should be there), so maybe I got it from Compuserve and didn't capture it right.   It is supposed to do a LINE command. 

 

 

ani.asm ani.dsk

cmd38.asm

  • Like 2
Link to comment
Share on other sites

14 hours ago, FarmerPotato said:

I would test it / rewrite it , but I can't get MAME to run with any floppy images.

Why? Maybe you should post the error message; this may help to solve the problem in an instant. Sounds as if you did not plug in a disk controller.

Link to comment
Share on other sites

1 hour ago, mizapf said:

Why? Maybe you should post the error message; this may help to solve the problem in an instant. Sounds as if you did not plug in a disk controller.

Hmm.  I configured an HFDC. 
It boots GeneveOS 7.30 from the MFM image. Works ok. 
 

I’m using ooeyGUI on MacOS. So the launcher by  @Shift838  has put in four floppy buttons and their Open dialog  gets the file name… it defaults to show a directory “disks” under my MAME configuration folder, so I’m putting mine there along with the disks @Shift838 supplied. 

I pick the choice 525DSDD there. Though  the disks are mere SSSD or DSSD. 

 

With  the floppy configured, I launch MAME and the console immediately logs something like:

 

—floppy1: /Users/eolson/MAME_path……/disks/EditorAssembler_Disk_A.dsk

File not found

 

The file is definitely there and readable by me. I copy paste the path from the error and I can access it as is. No spaces or anything weird in the pathname. 
 

I wonder if MAME is returning the actual file error (like Unix C strerror ) or always File Not Found for everything. 

 

 

I get the error with my dsk or with any of the supplied disks. They are all the simple V9T9 format, plain 90K of disk sectors. I just created mine with xdm99.py. Along with my collection, they all  work in Classic99 or js99er.net. 
 


 

Just now it occurs to me to wonder what directory has the MFM image. Since MAME obviously reads that. Maybe the disks folder is something else not readable by MAME after all. 

Edited by FarmerPotato
Link to comment
Share on other sites

I’m sorry to have hijacked this thread about 9938 programming… just reply to me privately with MAME talk. 
 

I have deduced that my code written in 1988 is a first draft. Because I was mainly working on animation in January 1989.  And I think that  code is among the unreadable disks. 


 

 

Link to comment
Share on other sites

44 minutes ago, FarmerPotato said:

I’m sorry to have hijacked this thread about 9938 programming… just reply to me privately with MAME talk. 
 

I have deduced that my code written in 1988 is a first draft. Because I was mainly working on animation in January 1989.  And I think that  code is among the unreadable disks. 

 

OK.  I had not started trying to animate anything yet, but that was a direction I was starting early testing with some code.

Link to comment
Share on other sites

53 minutes ago, FarmerPotato said:

Hmm.  I configured an HFDC. 
It boots GeneveOS 7.30 from the MFM image. Works ok. 
 

I’m using ooeyGUI on MacOS. So the launcher by  @Shift838  has put in four floppy buttons and their Open dialog  gets the file name… it defaults to show a directory “disks” under my MAME configuration folder, so I’m putting mine there along with the disks @Shift838 supplied. 
 

I had issues with the ooeyGUI for Windows and could never get it to work as I needed with MAME emulation of the Geneve.

 

Also, I think all my DSK and hard drive image files are in the same directory as MAME.

 

I ended up resorting to running everything from *.bat files with all my command line arguments.

Link to comment
Share on other sites

@FarmerPotatoWe can clarify this in a private discussion if you like. As Beery said, and as I prefer to do, it is often easier to write a simple script file that contains everything you need. I don't have a macOS computer here, and I am not familiar with the details of OoeyGui. We should include @Shift838 on that topic.

Link to comment
Share on other sites

Concerning the performance of the V9938 commands, remember by benchmarks at https://www.ninerpedia.org/wiki/V9938_Video_Data_Processor#Benchmarks

On 10/19/2022 at 5:32 PM, 9640News said:

However, what if one moves a large block down by a few pixel rows and over to the right a few pixel rows.  Then, you need to paint two rectangles to fill the space.  Now, add the complexity of also moving the block up and to the left, or any of the 4 potential directions, and the code to do all the fills can be challenging.

Ehm ... yes? ... I'd say so. What was the question?

 

move.png

Link to comment
Share on other sites

2 hours ago, mizapf said:

Concerning the performance of the V9938 commands, remember by benchmarks at https://www.ninerpedia.org/wiki/V9938_Video_Data_Processor#Benchmarks

Ehm ... yes? ... I'd say so. What was the question?

 

move.png

Was originally looking for a way to do the high speed move with the pixel fill area done very simply.  Whatever the modifications needed to be, there were < 60 bytes of free space to incorporate the extra code due to memory restrictions in the video XOP.

 

I was hoping there was something obvious that I overlooked for the Vid XOP >12 routine.

Link to comment
Share on other sites

3 hours ago, mizapf said:

Concerning the performance of the V9938 commands, remember by benchmarks at https://www.ninerpedia.org/wiki/V9938_Video_Data_Processor#Benchmarks

Ehm ... yes? ... I'd say so. What was the question?

I looked at your benchmarks  at V9938 Video Data Processor - Ninerpedia and it was indeed very informative.  I've printed out the page for a reference as I know I will find it useful.


Beery

  • Like 1
Link to comment
Share on other sites

9 hours ago, FarmerPotato said:

Hmm.  I configured an HFDC. 
It boots GeneveOS 7.30 from the MFM image. Works ok. 
 

I’m using ooeyGUI on MacOS. So the launcher by  @Shift838  has put in four floppy buttons and their Open dialog  gets the file name… it defaults to show a directory “disks” under my MAME configuration folder, so I’m putting mine there along with the disks @Shift838 supplied. 

I pick the choice 525DSDD there. Though  the disks are mere SSSD or DSSD. 

 

With  the floppy configured, I launch MAME and the console immediately logs something like:

 

—floppy1: /Users/eolson/MAME_path……/disks/EditorAssembler_Disk_A.dsk

File not found

 

The file is definitely there and readable by me. I copy paste the path from the error and I can access it as is. No spaces or anything weird in the pathname. 
 

I wonder if MAME is returning the actual file error (like Unix C strerror ) or always File Not Found for everything. 

 

 

I get the error with my dsk or with any of the supplied disks. They are all the simple V9T9 format, plain 90K of disk sectors. I just created mine with xdm99.py. Along with my collection, they all  work in Classic99 or js99er.net. 
 


 

Just now it occurs to me to wonder what directory has the MFM image. Since MAME obviously reads that. Maybe the disks folder is something else not readable by MAME after all. 

I have a mac (intel version) I can test if you like.  PM me

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Hello there,

 

Being a complete noob when it comes to MAME, I'm kind of lost right now. I got it running with the boot ROM's, but I can't find any information on how to configure it with a HFDC and an MFM image...?

 

Is it possible to export files from MAME's "hard drive" to it's native parent environment (i.e. copy files to/from Windows)?

Edited by Brufnus
Link to comment
Share on other sites

Hi,

 

Back on the HMMV topic:

 

@9640News Do I understand right, that you expect VID 0012 to erase the parts of the src rectangle? And you were/weren’t able to fix it?
 

And there is no more space left in this page to add more code?

 

While reading very old VIDS source starting at the beginning:  in opcode 0 there were opportunities to optimize space. Maybe you’ve already optimized it, but  for example, two ANDI instructions in a row (same register). I’m also wondering: in variables like XMN, XMX, (min max coordinate bounds) are these 0-based? (no negative coordinates ever) If so there’s redundancy in there..

Link to comment
Share on other sites

51 minutes ago, FarmerPotato said:

Hi,

 

Back on the HMMV topic:

 

@9640News Do I understand right, that you expect VID 0012 to erase the parts of the src rectangle? And you were/weren’t able to fix it?
 

And there is no more space left in this page to add more code?

 

While reading very old VIDS source starting at the beginning:  in opcode 0 there were opportunities to optimize space. Maybe you’ve already optimized it, but  for example, two ANDI instructions in a row (same register). I’m also wondering: in variables like XMN, XMX, (min max coordinate bounds) are these 0-based? (no negative coordinates ever) If so there’s redundancy in there..

I made one adjustment to the opcode so that it would work as long as there was no overlap of the move.  I tested this moving vertical down.  Haven't tested up, left, or right.

 

There is something like less than 64, and maybe less than 48 bytes of free memory left to the XOP limit of >7FFF.  We can't map another page in the >8000 to >9FFF range because task page 0 is mapped at that address when an XOP is called.

 

There has been no optimization of the video XOP code.  I had that one fix, and I think (??) somewhere @InsaneMultitasker had another update on one of the opcodes to address an ABasic issue.  Myself, I do not have a well enough handle with the video calls to get too deep into trying any optimization.

  • Like 2
Link to comment
Share on other sites

2 minutes ago, 9640News said:

There has been no optimization of the video XOP code.  I had that one fix, and I think (??) somewhere @InsaneMultitasker had another update on one of the opcodes to address an ABasic issue.

Clint Pulley is the last person to have reviewed the video XOPs and work through updating/fixing bugs.   I haven't done any optimizations except for a few fixes that you mentioned, and the "play" version of the TTYOUT XOP that added terminal output/input so that you could interact with the command line and command line programs via the RS232 port. 

  • Like 2
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...