Well that's not right.

Well, it's 14 before it starts visibly slowing down. It can actually get to 15 or 16 before the counter increments. This is a hand-written assembly routine. The reason it's leaving trails is because this is using REP MOVSW instead of XOR. And now that I think about it, that means each one is being drawn twice. So that should more than account for any kind of fix to the trails being drawn here.

I'm calculating the offset into the array of sprite data (one for each X offset in the character cell) using a regular old MUL, so there' s probably some performance left on the table there. I could precompute those offsets and do a table lookup. Anyway, that's good for tonight.

@bytex64

Is it really a sprite if it's not in hardware? Otherwise it's just sparkling pixels

Well, it's 14 before it starts visibly slowing down. It can actually get to 15 or 16 before the counter increments. This is a hand-written assembly routine. The reason it's leaving trails is because this is using REP MOVSW instead of XOR. And now that I think about it, that means each one is being drawn twice. So that should more than account for any kind of fix to the trails being drawn here.

I'm calculating the offset into the array of sprite data (one for each X offset in the character cell) using a regular old MUL, so there' s probably some performance left on the table there. I could precompute those offsets and do a table lookup. Anyway, that's good for tonight.

17, and no trails!

This has the pointer table optimization (every shifted version of the sprite is pointed to from a table instead of being calculated via MUL). I created a whole second routine to blank sprites, which is the same thing except it does STOSW instead MOVSW. It took me longer to get that working than the sprite draw routine because I misunderstood the documentation. I thought it referenced DS for the target and not ES because Intel's manual didn't specify either.

This is still a very bad draw routine because it just overwrites the entire 16-pixel word instead of doing proper masking. That'll probably drop the performance by 30% because it can't use the 8086's fast string instructions.

@bytex64 What if you used the old Apple2 trick of XORing the sprites instead. Gives you draw and erase without destroying the background (at the cost of some corruption, but it's generally ignorable )

17, and no trails!

This has the pointer table optimization (every shifted version of the sprite is pointed to from a table instead of being calculated via MUL). I created a whole second routine to blank sprites, which is the same thing except it does STOSW instead MOVSW. It took me longer to get that working than the sprite draw routine because I misunderstood the documentation. I thought it referenced DS for the target and not ES because Intel's manual didn't specify either.

This is still a very bad draw routine because it just overwrites the entire 16-pixel word instead of doing proper masking. That'll probably drop the performance by 30% because it can't use the 8086's fast string instructions.

We've maxed out the CPU, but the Apricot has another trick - the 8089. It's a dedicated I/O coprocessor, and theoretically it can push bytes even faster than the CPU. If... I can get it working.

I've discovered the hard way that Turbo Pascal is really picky about what it can link with. It _only_ wants to link with external functions. If the OBJ file you're linking with has _any_ data segment symbols, it flat out refuses to deal with it. At first I thought this was a subtle bug in how asm89 generates OMF files, but it does the same with a C file compiled with Turbo C. And since asm89 defines the 8089 machine code symbols as data (which I think is correct from the POV of the CPU), it just doesn't work.

So I guess I'll just have to copy the machine code into the Pascal source as raw data. That sucks.

#Aprilcot

But anyway, with that worked around, invoking the 8089 from Pascal seems to work. The code here is very simple:

MOVI GA, 1
ADD [PP].4, GA
HLT

It just adds 1 to the word at offset 4 in the parameter block. The first two words point to the code itself, so the third one is where parameters live. The Pascal code that invokes it just sets that to 0, and the output below shows that it has been changed, and then dumps the state of the 8089 Channel Control Block.

#Aprilcot

I should probably explain a little bit about the interface to the 8089. Early in the system initialization, the CPU tells the IOP to read the address of a System Configuration Block from the top of ROM. That address is right next to the 8086 reset location at FFFF8h, so if you've ever wondered what those unused bytes were, that's what they're for! This sets up the Channel Control Block, which defines the locations and parameters for executing Channel Parameter Blocks, which define a pointer to the 8089 machine code and parameters to the task. When the 8089 gets a "channel attention" (on the Apricot connected to I/O ports 70h and 72h), it re-reads the CCB for the signaled channel and starts/stops any tasks defined there.

#Aprilcot

So it's a little convoluted, but it does make it simple to interleave lots of 8089 programs running under the supervision of different parts of the system. You just wait for a channel to not be busy, load the CCB with the address of your own CPB, and let 'er rip. If a higher priority task needs a channel but one is not available, it can pause a running task, save the CCB info, swap in its own task, run that, swap the old one back in, and continue it. AFAIK nothing in the Apricot system does this, and it's probably moot anyway since the way the 8089 is implemented shares the bus with the CPU, so the 8086 can't make much progress while the 8089 is running, anyway.

Apricot typically uses channel 1 for the floppy drive controller. I've read somewhere that channel 2 is used by the Winchester controller, but as far as I've seen in the emulated system, that's not the case. I've also read that the system will run without an 8089, so probably there are some Apricots out there without them.

#Aprilcot

@bytex64

Is it really a sprite if it's not in hardware? Otherwise it's just sparkling pixels

So it's a little convoluted, but it does make it simple to interleave lots of 8089 programs running under the supervision of different parts of the system. You just wait for a channel to not be busy, load the CCB with the address of your own CPB, and let 'er rip. If a higher priority task needs a channel but one is not available, it can pause a running task, save the CCB info, swap in its own task, run that, swap the old one back in, and continue it. AFAIK nothing in the Apricot system does this, and it's probably moot anyway since the way the 8089 is implemented shares the bus with the CPU, so the 8086 can't make much progress while the 8089 is running, anyway.

Apricot typically uses channel 1 for the floppy drive controller. I've read somewhere that channel 2 is used by the Winchester controller, but as far as I've seen in the emulated system, that's not the case. I've also read that the system will run without an 8089, so probably there are some Apricots out there without them.

#Aprilcot

I want to do some more stuff with Apricot graphics. See, the thing is, these computers don't really _have_ graphics. What they have is a character mode with 16x16 pixel cells. Every pixel is addressable, but every pixel exists inside redefinable character memory, so you have to know where the particular character is in memory to modify its pixels. Which means there's different ways you can map the "characters" to the screen.

I had originally set this up in the usual way, with each cell following the next in rows and columns. But I realized much later that if you arrange the character cells in columns, every column becomes a contiguous region of 16-bit words. The math becomes simpler, and the whole thing runs faster.

#Aprilcot

@bytex64

Is it really a sprite if it's not in hardware? Otherwise it's just sparkling pixels

I want to do some more stuff with Apricot graphics. See, the thing is, these computers don't really _have_ graphics. What they have is a character mode with 16x16 pixel cells. Every pixel is addressable, but every pixel exists inside redefinable character memory, so you have to know where the particular character is in memory to modify its pixels. Which means there's different ways you can map the "characters" to the screen.

I had originally set this up in the usual way, with each cell following the next in rows and columns. But I realized much later that if you arrange the character cells in columns, every column becomes a contiguous region of 16-bit words. The math becomes simpler, and the whole thing runs faster.

#Aprilcot

@bytex64 as i understand it, this is quite similar to how the DSP in the N64 gets shared between pixel rasterising of triangles and mixing sound samples: every 5ms (that is, more than once a frame) the regular "pixel blatting" microcode in the DSP gets replaced with "audio mixing" and run.

@bytex64 is there some place where I can read the operations you're doing? or the source code? thanks!