<![CDATA[I want to do some more stuff with Apricot graphics.]]>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.

]]>https://board.circlewithadot.net/topic/39932283-2515-4f98-a4d3-28dad3f21e07/i-want-to-do-some-more-stuff-with-apricot-graphics.RSS for NodeFri, 15 May 2026 07:46:29 GMTSat, 18 Apr 2026 17:20:51 GMT60<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Wed, 29 Apr 2026 00:19:33 GMT]]>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. 😐

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116485126459347734https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116485126459347734Wed, 29 Apr 2026 00:19:33 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Wed, 29 Apr 2026 00:09:55 GMT]]>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
hlt

The 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!

Link Preview ImageLink Preview Image
]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116485088560812263https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116485088560812263Wed, 29 Apr 2026 00:09:55 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 17:05:32 GMT]]>@bytex64 nice! It kind of reminds me of the VIC20 hires mode.

]]>https://board.circlewithadot.net/post/https://mastodon.sdf.org/users/davbucci/statuses/116483419862383514https://board.circlewithadot.net/post/https://mastodon.sdf.org/users/davbucci/statuses/116483419862383514Tue, 28 Apr 2026 17:05:32 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 16:14:09 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483217765569704https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483217765569704Tue, 28 Apr 2026 16:14:09 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 16:09:46 GMT]]>@sverx Not at the moment, but I’ll try to publish the source at the end of the month.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483200519244332https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483200519244332Tue, 28 Apr 2026 16:09:46 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 16:06:25 GMT]]>@drj Oh that’s interesting. 🙂

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483187350111433https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116483187350111433Tue, 28 Apr 2026 16:06:25 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 10:12:05 GMT]]>@bytex64
I am always tickled when column graphics, like wallpaper, are rediscovered.

]]>https://board.circlewithadot.net/post/https://sunny.garden/users/spodlife/statuses/116481794068579414https://board.circlewithadot.net/post/https://sunny.garden/users/spodlife/statuses/116481794068579414Tue, 28 Apr 2026 10:12:05 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 08:55:25 GMT]]>@elithebearded Sparkling sugar water or pixels, that's the question.
@bytex64

]]>https://board.circlewithadot.net/post/https://todon.eu/users/menos/statuses/116481492623103056https://board.circlewithadot.net/post/https://todon.eu/users/menos/statuses/116481492623103056Tue, 28 Apr 2026 08:55:25 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 08:27:53 GMT]]>@bytex64 is there some place where I can read the operations you're doing? or the source code? thanks! 😄

]]>https://board.circlewithadot.net/post/https://mastodon.gamedev.place/users/sverx/statuses/116481384338014608https://board.circlewithadot.net/post/https://mastodon.gamedev.place/users/sverx/statuses/116481384338014608Tue, 28 Apr 2026 08:27:53 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 08:25:32 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://typo.social/users/drj/statuses/116481375081450414https://board.circlewithadot.net/post/https://typo.social/users/drj/statuses/116481375081450414Tue, 28 Apr 2026 08:25:32 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 08:21:05 GMT]]>@elithebearded @bytex64 "hardware sprites" is a term of art, so i'm gonna go with Yes.

]]>https://board.circlewithadot.net/post/https://typo.social/users/drj/statuses/116481357599126713https://board.circlewithadot.net/post/https://typo.social/users/drj/statuses/116481357599126713Tue, 28 Apr 2026 08:21:05 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 07:10:10 GMT]]>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.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116481078761922850https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116481078761922850Tue, 28 Apr 2026 07:10:10 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 06:58:45 GMT]]>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.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116481033894540645https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116481033894540645Tue, 28 Apr 2026 06:58:45 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 06:49:38 GMT]]>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.

Link Preview Image
]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480998008775617https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480998008775617Tue, 28 Apr 2026 06:49:38 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 06:35:51 GMT]]>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.

Link Preview Image
]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480943842902310https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480943842902310Tue, 28 Apr 2026 06:35:51 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 28 Apr 2026 06:24:39 GMT]]>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.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480899778941398https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116480899778941398Tue, 28 Apr 2026 06:24:39 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 21 Apr 2026 07:58:17 GMT]]>@bytex64 exceedingky cute axoloinvaders!

]]>https://board.circlewithadot.net/post/https://mastodon.gamedev.place/users/poetaster/statuses/116441631802024336https://board.circlewithadot.net/post/https://mastodon.gamedev.place/users/poetaster/statuses/116441631802024336Tue, 21 Apr 2026 07:58:17 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 21 Apr 2026 07:37:35 GMT]]>@tursilion That’s what I did initially in the naive version. It does work, but it also can’t take advantage of REP STOSW for fast copies, so it’ll be slower.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441550394163951https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441550394163951Tue, 21 Apr 2026 07:37:35 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 21 Apr 2026 06:50:42 GMT]]>@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 🙂 )

]]>https://board.circlewithadot.net/post/https://furries.club/users/tursilion/statuses/116441366007570662https://board.circlewithadot.net/post/https://furries.club/users/tursilion/statuses/116441366007570662Tue, 21 Apr 2026 06:50:42 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 21 Apr 2026 06:46:49 GMT]]>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.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441350779487049https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441350779487049Tue, 21 Apr 2026 06:46:49 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Tue, 21 Apr 2026 06:40:23 GMT]]>17, and no trails!

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441325464017422https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116441325464017422Tue, 21 Apr 2026 06:40:23 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Mon, 20 Apr 2026 17:04:31 GMT]]>@elithebearded Hah. 🙂 I’d say it’s arguable. The word gets thrown around in a lot of ways to describe everything from the image itself to the particular rendering path.

For a particularly confusing example, uxn/Varvara “sprites” are rendered by “hardware” but because it’s an emulation-only platform it’s actually a fixed function software blitter.

]]>https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116438117374798193https://board.circlewithadot.net/post/https://awesome.garden/users/bytex64/statuses/116438117374798193Mon, 20 Apr 2026 17:04:31 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Mon, 20 Apr 2026 16:44:06 GMT]]>@bytex64

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

]]>https://board.circlewithadot.net/post/https://fed.qaz.red/users/elithebearded/statuses/116438037072027020https://board.circlewithadot.net/post/https://fed.qaz.red/users/elithebearded/statuses/116438037072027020Mon, 20 Apr 2026 16:44:06 GMT<![CDATA[Reply to I want to do some more stuff with Apricot graphics. on Mon, 20 Apr 2026 16:40:54 GMT]]>@bytex64

That's winning at solitaire

]]>https://board.circlewithadot.net/post/https://fed.qaz.red/users/elithebearded/statuses/116438024456986332https://board.circlewithadot.net/post/https://fed.qaz.red/users/elithebearded/statuses/116438024456986332Mon, 20 Apr 2026 16:40:54 GMT