My current QL accelerator project

[XorA]

thats fixed it!

Looking awesome!

[Derek_Stewart]

Hi Will,

Great pictures and video.

Really good progress on the QL Pistorm.

[Will James]

Hehe! - I appear to be on a roll at last. Reprogrammed the CPLD to handle !DS correctly. Change QLbuptest to set up the QL display register and got the QL PiStorm V3 copying data to the QL Screen properly now. The gaps in the picture must have been poor soldering on my V2 board or something... after a bit more testing next step will be to get the 68K emulator running.

[napsternds]

Great news!! Your pictures look great

Keep pushing!!!!

[Will James]

So, now the hardware is done, I'm starting to work on getting the emulator going. I'm thinking of using Musashi as it runs under Linux which will make RTG and SD hard drive etc a lot easier. It's not as fast as EMU68 which hits the bare metal of the Raspberry Pi. I thought someone else might develop that if people want it. I'm not sure whether I will use the PiStorm emulator and cut out the Amiga Stuff or start with Musashi and add the QL stuff... I'm hoping to get it able to access Microdrives, and I'm tempted to add a FDD interface to the card as there is already an SD card on the Pi that I want to make into a QL HDD. I suspect I am going to need quite a lot of advice developing all this

[Will James]

I've got some timings for the QL PiStorm writing directly to QL screen memory... it did 800 screen fills in 29.5 seconds... feels a bit slow but I'll need to do the same thing on a normal QL to find out...
would help if I had a working keyboard. Obviously the emulator wouldn't be accessing the QL bus all the time as it will be mirroring the system RAM and ROM in it's own memory the other side of the bottleneck. Still, like Public Service Broadcasting - I believe in progress...

this was the test code;

int QLfillScreen(int colour){
int16_t colourMask[8] = {0x0000, 0x0055, 0x00AA, 0x00FF, 0xAA00, 0xAA55, 0xAAAA, 0xAAFF};
write8(0x18063,0x08);
int16_t c = colourMask[colour & 0x0007];
for (int i=0x20000; i < 0x28000; i=i+2) write16(i, c);
}

clock_t start = clock();
for (int x = 0; x < 100; x++){
for (int i = 0; i < 8; i++) QLfillScreen(i);
}
clock_t end = clock();
double elapsed_time = (double)(end - start) / CLOCKS_PER_SEC;
printf("Elapsed time for 800 screen fills: %.6f seconds\n", elapsed_time);

[martyn_hill]

Hi Will!

A bit of back of the envelope arithmetic and your accelerator seems to be pushing just under 900KB per second to screen memory.

Compare that to the (nominal, uncontended) max bus rate of a 7.5MHz QL of less than 2MB per sec - about half that to contended screen memory - and your accelerator is actually only a little under that.

Theres not much that can be done in the standard QL architecture to increase the throughput to screen memory as it's really under the control of the 8301 'master-chip' ULA.

As you'll read elsewhere on this Forum, the most effective way to increase the - observable - screen drawing performance is to 'shadow' write to screen/contended memory, and then read back from faster external memory - a simple but effective technique used by some memory expansions, relying on the fact that, for (approx) 60% + of time, screen drawing involves as many memory read cycles reads as it does write-cycles. And of course, any instructions fetches from contended memory can also come from faster external memory.

So, in short, your figures are probably as expected and reflect a bottleneck in the QL's neat, but comparatively sluggish video memory handling (32KB of linear address space dedicated to video, without 'blitter' or other DMA like support on an 8-bit bus with slowish DRAM.)

Keep heart!

[Will James]

Thanks Martyn... that analysis is good to hear. I'm intending on creating an HD screen on the PiStorm and mapping the QL video writes to it which should improve the speed no end.

Will