Das FrankenDac

Managed to rewrite the sprite ordering AND put in flipping for both sprites and background. The good news is that it’s all in, the bad news is that it causes problems when the worst case scenario happens, i.e. everything is flipped horizontally. With a sprite line-limit of only 128 pixels and the worst case sprite ( 8 pixels ) taking up a whopping 100 cycles, there isn’t much time left to much more.

Anyway, managed to re-wire my R2R-DAC tonight and cleaned up the code a bit now that all the pins are connected properly. Was hoping to be able to run it directly off the board, but staying under 4ma just doesn’t do the display justice. The plan then, is to add my (t)rusty 244’s back in which should fair a heck of a lot better! After that, I’ll put the code up and see if I can get a proper PCB made…

Back For More

Back from a (well deserved?) family vacation. Forgot how nice Vancouver was in the summer…

Anyway, looks like I’ll have some time this weekend to revisit some of the code. Enabled tile flipping for backgrounds and hope to be able to rejigger the sprite-renderer to allow both X- and Y-flipping there too. So far it looks like I have enough time to do background flipping and at least Y-flipping for sprites. Need to overhaul the sprite code this weekend to have an ascending draw-order instead of a descending one. In other words, sprite #0 should always be drawn and should also be drawn on top, otherwise there’s no guarantee the player will always be visible.

During my vacation I started thinking about what to do next after this core. There are a number of things I can think of to extend it, but I’m leaning more and more towards doing an NTSC driver first. Would allow me to reduce the number of pins used for a port as well..

First things first: flippage!

Top & Bottom, Foo & Bar

Guh!

Spent yesterday trying to figure out why all cores allocated the same amount of memory. Quick post on xlinkers resulted in me adding ‘top and bottom’ linker directives, which fixed that problem. Thanks Sam!

All of the original ‘demo’ code is now using channels, with the VDP running on core #3 and the demo on core #0. Unfortunately, I stumbled into another problem which only seems to manifest itself when I run it on my XC-2 board. Posted another question ( surely they must get sick of me by now ) on xlinkers. Since they’re in the UK, I hope to have some clarification on this tomorrow morning…

Time will tell.

Separation Anxiety

Re-organized code and properly separated out the VDP- and main core. All communication now goes through a single channel, with a server ( or whatever you want to call it ) as a 3rd thread on the VDP core. Kinda torn whether or not I want to go ‘register-based’ approach or go with full-fledge functions.

It’s a bit of a step back visually, but hopefully things will be back to normal tomorrow. Once it’s cleaned up I’ll see if I can squeeze a couple more cycles out of the inner loops and get sprite flipping back in.

Quick post on xlinkers and I’ll call it a day…

It’s Alive!!

Well, sort of…

Bit of elbow grease this evening and some sleuthing allowed me to get the above demo up and running. Spent about 30 minutes trying to figure out why my new DAC wasn’t working properly, only to find out that I reversed the MSB / LSB on all the components. Nothing you can’t fix with a bit of software

In case anyone’s interested, here are the specs:

1024 tiles of 8×8 pixels, 16 colors per tile for a total of 32K
16 palettes of 16 colors for a grand total of 256 colors on-screen out of 32768.
2 independently moveable backgrounds, pixel scrollable on both X- and Y
32 sprites ranging from 8×8 to 64×64 pixels
Horizontal and vertical flipping for background tiles ( hopefully sprites soon too! )

Currently the whole thing runs on a single core, in only 2 threads and memory to spare. The ‘plan’ is to clean it all up and add audio at some point, but we’ll cross that bridge when we get to it.

w00t!

Another Blog?

Yup! And this one will be dedicated to creating turn-key ’soft-cores’ for XMOS’ quad-core processor.

Never heard of it? Yeah, neither had I until about a month ( and a bit ) before. I like to tinker with ‘constrained’ devices although you couldn’t really call this a constrained device. In a nutshell, you have:

4 processors on a chip, each capable of running up to 8 hardware threads, running at 400mhz. That last figure is a bit misleading as each thread runs at 100mhz, as long as you run 4 threads or less. Go more than 4 and it starts time-slicing the others. It’s not that big a deal though. In order to get cycle-accurate timing, they’ve added a lot of goodies! Timers, Timed ports, communication channels, single cycle MAC, and lots of other of good stuff..

Anyway, I should have some more info on my first core in the next couple of days. Stay tuned!