ZXpand firmware improvements

[sirmorris]

I've revisited the firmware after receiving a number of emails from people who are in the process of developing new software. The emails generally go along these lines:

'Hi I am making a new game but the code in the manual doesn't work B/C xyz'

Someone is reading the manual

So sure enough I think maybe it's time to sweep away the mists of time and see what is going on.

Changes around the time of "dragon" meant some kind of code efficiency boundary was crossed, and things were just not quite as fast as they once were. Methods with critical timing constraints were starting to fail.

So I got out the old logic analyser and had a peek at a few bits n pieces.

[sirmorris]

The main issue is that I am using a PIC peripheral called the parallel port. It acts like a single byte of RAM with a read/write and select line. There is a data register which holds the byte, and flags which tell you when the port has been accessed and whether a byte is present in the register.

The code looks something like:

clear buffer full flag
clear access register
wait for access register
is buffer full?
If so:
decide whether its data or a command, and store the byte or process the command as necessary
If not:
this must have been a read. whatever was in the data register is now in the zeddy, so re-fill the data register if necessary

So far so good.

The expected workflow is that the zeddy writes a command, then reads the result and then reads/writes data.

The PIC will take some time to detect the command, some time to process it and some time to collect the data. Exactly how much all depends on what you're doing. Some commands simply fetch a status - like joystick state or config byte. Some fetch a block of bytes such as a directory entry or block of P.

When I first wrote the manual I'd made up some suitable general timings for single bytes, and implemented a wait mechanism around return codes for the longer operations.

The latter mechanism has stood the test of time. You wouldn't be able to load monster maze otherwise. The former however was subject to a problem caused by the way in which I'd implemented the command handler.

The command handler was an if-else chain, so every new item added to the chain would increase the amount of time taken to search the chain for the right answer to the current question. D'oh! This is why the joystick and zxpand-present tests were failing, the amount of time taken to prepare the data and present it was longer than expected, so the zeddy wasn't able to process the results. This is now fixed, and the data is now ready for zeddy in good time.

Next up I looked at the burst read mode that I implemented for Jim's version of Dragon's Lair. I'll document changes to this in a short while. The garden needs some attention

[sirmorris]

But in the mean time:

3dmm-faster.jpg

(175.43 KiB) Downloaded 295 times

[Moggy]

I understood everything you said there Charlie.

(The pictures look just like my MIDI sequencer)

[1024MAK]

The garden needs some attention

At 9:18 in the morning

Or are you still in the pub garden?

Mark

[sirmorris]

I wish - though I do have a beer now!

So the image above shows the zeddy loading 3D monster maze, naturally. It was the first ever program - certainly in my experience, quite possibly in the world - to be loaded from SD card. It is a composite of three different zoom levels on the same data. The top row is the overview, the entire program loading. You can clearly see a number of 256 byte blocks being read. There is a distinct pattern of bursts, with two blocks in quick succession and then a gap. SD cards in general operate with 512 byte sectors. This is why you see bursts in pairs. It's quicker to obtain the second 256 byte block because it's already cached.

Zooming in a level to the middle image we see the magnified view of the region in the first image. It is 256 bytes being grabbed by the zeddy. There is a small pre-amble then a stream of pulses.

Zooming in further you finally get to see a single byte request. The top row is a diagnostic output from the PIC which goes high when an IO request is detected from the zeddy. It goes low when all the processing of the request is complete and the next request is anticipated. The middle row is !RD from the z80. I didn't include read as it is very detailed and detracts from the picture. Just be assured that if write is high when picen is low, then it's a read Talking of picen... The third row is the PIC's select logic. It is quite acceptable to think of this as framing the Z80's IO request. The period bounded by the markers is the time taken from the start of the IO request to the time the PIC has completed processing. Unfortunately I didn't snap the timings but you can trust me when I tell you that it's about 6.5us - that is 6.5 microseconds or 6.5 millionths of a second. Quite nippy.

You'll see that the PIC doesn't wake up and start processing the next data until a hair after the IO request completes - that's just as well otherwise we'd be losing bytes because we'd write new data before the last was finished reading. Now remember - the first post hinted at the fact that we operate with 'one in the pipe' because the parallel port acts like RAM. If it didn't then we wouldn't necessarily have time to react to the request, find the data and store it. So you stuff the data ahead of an anticipated read and wait to be told it's been taken before caching the next one.

So. Dragon's Lair. I added code which had one job, to deliver 256 bytes as quickly as it could. It was a tight loop that could respond quickly enough to stuff bytes as fast as the z80 could take them - using an INIR opcode. IN with increment and repeat. A bit like LDIR but for data off the bus rather than RAM. The trouble was that it came with some usage constraints.

Which I'll tell you about after supper.

[sirmorris]

Burp. Sorry.

Being hard-coded for delivering 256 byte packets the 'dragon' functions weren't really suitable for general purpose block reads, some blocks just aren't 256 bytes wide and without kludges or breaking changes to the software interface there wasn't much I could do. All reading functions should benefit in an ideal world.

So while I had the logic analyser soldered onto the ZXpand I thought I'd look at what I could do. I needed to move the data output closer (in terms of instructions) to where the IO requests were being handled. It turns out that wasn't too hard So now all data passed from zxpand to zeddy can benefit from the zippier transfers. This bodes well for more data intensive applications like AY streaming.

Writing data _to_ the zxpand is slightly trickier but I think that reading data is the main course, so I don't think I'll be complicating matters for myself and be content with a 33% faster load

My aim with ZXpand+ is to maintain software compatibility with original ZXpand and because the base hardware is so similar both boards should benefit from these improvements. Look out for a 2.6 release as soon as I've thought of a snappy name for it lol.

[nollkolltroll]

Sounds very promising! I have a bad apple just waiting to be released

[sirmorris]

I'm there for you. What do you need?

[nollkolltroll]

Anything that raises the throughput of data, specifically the time between the 256-byte bursts is positive. I've got code that works with the 'dragon' version of zxpand, but more speed means higher resolution video
Would it be better to have a read-sector-mode instead of file-system reads in terms of quickly fetching the next 256 bytes?
I do agree that writing to the sd-card is not at all as speed sensitive.