I want to do some more stuff with Apricot graphics.
-
Is it really a sprite if it's not in hardware? Otherwise it's just sparkling pixels
@elithebearded @bytex64 "hardware sprites" is a term of art, so i'm gonna go with Yes.
-
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.
@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.
-
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.
@bytex64 is there some place where I can read the operations you're doing? or the source code? thanks!
-
Is it really a sprite if it's not in hardware? Otherwise it's just sparkling pixels
@elithebearded Sparkling sugar water or pixels, that's the question.
@bytex64 -
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.
@bytex64
I am always tickled when column graphics, like wallpaper, are rediscovered. -
@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.
@drj Oh that’s interesting.
-
@bytex64 is there some place where I can read the operations you're doing? or the source code? thanks!
@sverx Not at the moment, but I’ll try to publish the source at the end of the month.
-
@sverx Not at the moment, but I’ll try to publish the source at the end of the month.
@sverx Oh, I do also have some code up for the game I made last year: https://git.bytex64.net/where-is-owl/
No sprites or complex graphics, though. That one’s just character cell manipulation.
-
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.
@bytex64 nice! It kind of reminds me of the VIC20 hires mode.
-
Part of the magic of what's happening in the assembly above is upon task start, the address of the Channel Parameter Block gets loaded into the PP register in the 8089. It makes it very handy to reference any of those parameters, and the 8089 code doesn't need to know ahead of time where your parameters are. IIRC all the call/jump instructions are signed displacement, so the code is fairly naturally position-independent as well.
Guess who found a bug in MAME? Getting my ducks in a row here, this is just doing a pointer load so I can get the address of the pixels I want to copy, then copying something from that memory to the X and Y parameters.
lpd ga, [pp].8
mov gb, [ga].4
mov [pp].4, gb
mov [pp].6, [ga].6
hltThe first one is done by MOVing into the GB register first, then from GB to memory. The second one uses the 8089's memory-to-memory MOV. And it turns out MAME's 8089 core doesn't implement mem-mem MOV correctly, leaving zero in the Y parameter instead of 7. I thought I was going mad!
-
Guess who found a bug in MAME? Getting my ducks in a row here, this is just doing a pointer load so I can get the address of the pixels I want to copy, then copying something from that memory to the X and Y parameters.
lpd ga, [pp].8
mov gb, [ga].4
mov [pp].4, gb
mov [pp].6, [ga].6
hltThe first one is done by MOVing into the GB register first, then from GB to memory. The second one uses the 8089's memory-to-memory MOV. And it turns out MAME's 8089 core doesn't implement mem-mem MOV correctly, leaving zero in the Y parameter instead of 7. I thought I was going mad!
It's honestly kind of weird that this doesn't work, because MAME also includes an emulation for the iSBC 215 disk controller, which also uses the 8089. Maybe it doesn't work either.
-
R relay@relay.infosec.exchange shared this topic
