SpectROM - Speccy emulator for the Pi co-pro

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Fri Jan 12, 2018 4:52 pm

Following Lardo's suggestion in the ZX81 emulator thread, I decided to have a go at a ZX Spectrum emulator.

After a lot of squeezing of code, I managed to fit an extra attribute mode into VideoNuLA that can mimic the Spectrum's display.

Over Christmas I started to write an emulator for the Pi co-pro and have now got it to a point where it'll run games. I've always wanted to play Skooldaze on the Beeb :D:
IMG_20180112_162414.jpg
Skooldaze on the Beeb!
The emulator is in two parts: a ROM for the Beeb/host and an application for the co-pro.

I haven't put the border in yet and need to sort out the sound as my initial attempt at emulating the beeper with PCM isn't working at all well.

Also, the display refresh routine is very naive and needs to be improved as it is too slow when the screen is being scrolled. (I've got some ideas that should improve things but wanted to get it working first.)

dominicbeesley
Posts: 576
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by dominicbeesley » Fri Jan 12, 2018 9:02 pm

Excellent work rob...another triumph

User avatar
sydney
Posts: 2143
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by sydney » Fri Jan 12, 2018 9:12 pm

Well done! =D>

User avatar
marcusjambler
Posts: 361
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by marcusjambler » Fri Jan 12, 2018 9:41 pm

This is very cool.... Woohoo Gauntlet will be my first game =D>

User avatar
mlouka
Posts: 47
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by mlouka » Fri Jan 12, 2018 9:57 pm

Very nice. Will this require the VideoNuLA or will it run without with “interesting” colours?

I’m also a little curious about how you are doing this. I guess you are using gcc to cross-compile to ARM from Linux (or are compiling on a Pi running Linux?) but what C library are you linking with to run it (and where can I get hold of it?!). Any chance of you sharing a minimalist “hello world” Makefile to print to the console, or is this more complicated to build than I am imagining?
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Fri Jan 12, 2018 10:30 pm

Thanks for the encouragement.
mlouka wrote:Will this require the VideoNuLA or will it run without with “interesting” colours?
It needs VideoNuLA, as apart from the colours, it uses a new attribute mode that's able to mimic the Spectrum's display. I had to modify the VideoNuLA VHDL to implement this so there's currently only one board in existence that can support it! However, if I get this working properly, I'll upgrade existing boards for free and new boards will ship with it.

Having said that, for those without VideoNuLA, it should be trivial to modify the emulator to ignore attributes and generate a black and white mode 4 display. Also, the Pi is probably quick enough to convert the Spectrum's display into 4-colour mode 1 display or an 8-colour mode 2 display without too much loss of speed.
mlouka wrote:I’m also a little curious about how you are doing this.
I'm using gcc under Bash for Windows and a minimal newlib implementation that I've pieced together from various places and added to. The two main resources I got information from were the PiTubeDirect source tree and the Valvers bare metal programming guide:
http://www.valvers.com/open-software/ra ... g-in-cpt1/

I'm happy to put together a "Hello World" example and share what I've done but am concentrating on sorting out the emulator at the moment...

User avatar
mlouka
Posts: 47
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by mlouka » Fri Jan 12, 2018 10:40 pm

Thanks for the reply and the link. Will check it out.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
tricky
Posts: 2548
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by tricky » Sat Jan 13, 2018 1:57 am

Well done Rob, more great work.

Is the Pi fast enough to look for small areas of shifted/scrolled graphics and send a scroll command for an area?

It could probably be optimised along th lines of a frame rate converter, but apart from paperboy, horizontal and vertical 1,2,4,8 pixels should cover it, but there are many people on here who know way more about speccy games than me.

Is there enough room for two beeb screens, or does that require a master?

Is your speccy attribute mode 2 bits per pixel? 1 byte for 16 foreground and 16 background colours then one for the 8 pixels?
If so, I make that 12K and you could fit two which would make copying block much simpler and no flicker ;)

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 8:50 am

tricky wrote:Is the Pi fast enough to look for small areas of shifted/scrolled graphics and send a scroll command for an area?
I would think so. My current screen refresh routine is very simple as it just sends the address and value for every byte of pixel data that needs to change as a set of triplets. Attribute data is sent in a similar way but the Beeb writes 8 copies so that one byte covers an 8x8 block. So, there are loads of things I could do to speed things up by sending data as rectangular blocks rather than lots of address/value pairs.

Also, I'm using some bespoke OSWORD routines to pass the data as I don't think there's a way to access the Tube registers directly from the native Pi co-pro. Adding a couple of SWIs to read and write directly to the registers would also help things.
tricky wrote:Is your speccy attribute mode 2 bits per pixel? 1 byte for 16 foreground and 16 background colours then one for the 8 pixels?If so, I make that 12K and you could fit two which would make copying block much simpler and no flicker
That's exactly how it works and I am currently using a 12K screen. I'd thought about double buffering but I'd also like to add the border which will need more RAM. My idea was to have the border in colour 0 or 8 (as the Spectrum only has one black) and then modify it via the palette but, unless I make the border very small, there won't then be enough RAM to double buffer on an ordinary Beeb.

User avatar
BigEd
Posts: 1891
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by BigEd » Sat Jan 13, 2018 10:00 am

RobC wrote:
tricky wrote:Is the Pi fast enough to look for small areas of shifted/scrolled graphics and send a scroll command for an area?
Also, I'm using some bespoke OSWORD routines to pass the data as I don't think there's a way to access the Tube registers directly from the native Pi co-pro. Adding a couple of SWIs to read and write directly to the registers would also help things.
Interesting... I just checked to see how Dave managed to extend the Tube protocol for the second processor Life. It turns out - and now I do remember this - he extends the VDU protocol. It would be possible to do that in a highly compatible way, by accounting for the lengths of each of the existing VDU multi-byte sequences, but we took the cheapest approach and just use an FF byte to introduce a zero-terminated sequence of data bytes which we handle specially. (Once the extended VDU driver is installed on the host, this would then break if some program wrote an FF or used an FF in a VDU command.) A nice side-effect of using the VDU channel is that it has the deepest FIFO buffer, so you get some parallelism for free.

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 12:56 pm

BigEd wrote:Interesting... I just checked to see how Dave managed to extend the Tube protocol for the second processor Life. It turns out - and now I do remember this - he extends the VDU protocol.
Thanks for that Ed - I hadn't seen it so it was interesting to look through the code.

I chose to extend OSWORD so that I could send blocks of 120-odd bytes from one SWI call. I assumed that this would be quicker than doing multiple VDU/OS_WriteC calls but must admit that I haven't done any investigation yet as this is my first cut. Ideally, I'd like to have been able to roll my own protocol so that I could send larger blocks (as JGH does with his OSWORD FF here: mdfs.net/Software/Tube/ ) but don't think it's currently possible to access the Tube registers directly from the native Pi core.

In truth, I've been pleasantly surprised by the performance from my simple implementation as it seems to work well apart from when the screen scrolls. I'm wondering whether doing something with sending rectangles of pixels (rather than sending an address for each individual pixel) will give enough of a boost to improve things sufficiently...
Last edited by RobC on Sat Jan 13, 2018 1:10 pm, edited 1 time in total.

User avatar
BigEd
Posts: 1891
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by BigEd » Sat Jan 13, 2018 1:02 pm

As the copro runs ridiculously fast, overhead on that side of the Tube mightn't amount to much - I'd guess overhead on the host side is the case to worry about. But it might well be better to experiment than to theorise...

This is an excellent new development though!

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 2:28 pm

BigEd wrote:As the copro runs ridiculously fast, overhead on that side of the Tube mightn't amount to much - I'd guess overhead on the host side is the case to worry about. But it might well be better to experiment than to theorise...
Yes - I wanted to avoid handling lots of calls on the host. I think there probably wouldn't be much difference on the copro side once you've taken in to account the management of the blocks of data (and it's so fast as to be irrelevant as you point out).
BigEd wrote:This is an excellent new development though!
Thanks. The Pi co-pro really does open up lots of possibilities - although my wife is now asking if we can get rid of my Spectrum and any other machines :( !

User avatar
BigEd
Posts: 1891
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by BigEd » Sat Jan 13, 2018 2:40 pm

Looking again at Dave's host-side VDU handler, I see that it doesn't mess about - and the data transferred is not zero-terminated as I said, it's (up to) a screen's worth of updates where each block of pixel updates is zero-terminated. So, it's compressed fairly well, and uncompressed directly into screen writes (actually bytewise EOR operations in this case.) Whereas the full VDU handler presumably has overhead, once the new handler sees an FF it starts to pull data directly from the Tube chip - and as it's host side, that's a fairly justifiable thing to do. Overall, the full VDU stack penalty is paid once per screen.

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 3:35 pm

BigEd wrote:Whereas the full VDU handler presumably has overhead, once the new handler sees an FF it starts to pull data directly from the Tube chip - and as it's host side, that's a fairly justifiable thing to do. Overall, the full VDU stack penalty is paid once per screen.
Many thanks for that - I understand what it's doing now. I should have read it more carefully :oops:

So the parasite just needs to issue VDUs/OS_WriteCs and the host does direct reads from FEE0 and FEE1. That should improve things: I can bundle all the data up into one block, get rid of the OSWORD block decoding and it won't need any new SWIs on the parasite side :D

I'll rewrite my ROM code later today and see how it performs.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by crj » Sat Jan 13, 2018 4:14 pm

Isn't the defined - and quickest - way to do this stuff for the Parasite to provoke the Host into initiating a memory transfer? 256-byte blocks can be transmitted at the rate of 100Kbytes per second, because of the reduced handshaking overheads. And the Beeb end can do what it wants with each byte it receives... provided it takes 20 cycles or fewer including the LDA &FEE5. (-8

User avatar
hoglet
Posts: 7232
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by hoglet » Sat Jan 13, 2018 4:20 pm

crj wrote:Isn't the defined - and quickest - way to do this stuff for the Parasite to provoke the Host into initiating a memory transfer?
That's true, if what's being transferred is uncompressed screen data.

But in the Life example that's being discussed, what's actually being set is effectively compressed, because only changes are being send.

You can see here they are being EOR'd into the screen:
https://github.com/hoglet67/6502Life/bl ... er.asm#L31

This is what made it much more efficient.

Dave

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 4:34 pm

crj wrote:Isn't the defined - and quickest - way to do this stuff for the Parasite to provoke the Host into initiating a memory transfer? 256-byte blocks can be transmitted at the rate of 100Kbytes per second, because of the reduced handshaking overheads. And the Beeb end can do what it wants with each byte it receives... provided it takes 20 cycles or fewer including the LDA &FEE5. (-8
I haven't looked through the code in detail but I'm not sure it's currently possible to implement a 256-byte transfer on the native Pi core. I couldn't see any use of Tube register 3 (but I didn't spend too much time looking at it).

User avatar
hoglet
Posts: 7232
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by hoglet » Sat Jan 13, 2018 4:39 pm

RobC wrote: I haven't looked through the code in detail but I'm not sure it's currently possible to implement a 256-byte transfer on the native Pi core. I couldn't see any use of Tube register 3 (but I didn't spend too much time looking at it).
Currently only type 0 and 1 are implemented, but the framework is there for them all to be added:
https://github.com/hoglet67/PiTubeDirec ... isr.c#L388

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by crj » Sat Jan 13, 2018 5:35 pm

hoglet wrote:But in the Life example that's being discussed, what's actually being set is effectively compressed, because only changes are being send.
As I said:
crj wrote:the Beeb end can do what it wants with each byte it receives
Having initiated a memory transfer from the Parasite, it needn't simply drop the bytes into Host memory as they arrive; it can instead do anything which fits in the time available.

Something much like what you're actually doing could be done by sending pairs: byte to EOR then number of bytes to advance:

Code: Select all

  \ Initiate transfer
  LDY #0 : STY ptr
  LDA #&58 : STA ptr+1
  LDX #128
  \ Idle for remainder of setup time
.loop
  LDA &FEE5  \\4
  EOR (ptr),Y  \\5 
  STA (ptr),Y  \\6
  LDA &FEE5  \\4
  CLC  \\2
  ADC ptr  \\3
  STA ptr  \\3
  LDA #0  \\2
  ADC ptr+1  \\3
  STA ptr+1  \\3
  DEX  \\2
  BNE loop  \\3
By complete coincidence, I hit exactly 40 cycles per loop, 20 cycles per byte, 10us per byte, on my very first try. (-8

For the odd data left over after transmitting a whole number of pages, you could then use the byte-pair mode: 26us per byte pair. Stick in 7us of delay, and change the final DEX:BNE loop to a BPL loop, and it will stop at the end of screen memory.

Yours, assuming the parasite drives it at full speed, takes 34 cycles per loop within a line, 54 cycles per loop that crosses a line. I admit that's closer than I expected - yours is faster if there are five or more bytes to change per line - but even so is that enough to justify hacking around in OSWRCH rather than using the official, supported, mechanism?

If you are going to hack around in OSWRCH, isn't it more efficient to keep a copy of screen memory on the Parasite and send actual values rather than values to EOR, by the way?

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by crj » Sat Jan 13, 2018 5:43 pm

hoglet wrote:
RobC wrote: Currently only type 0 and 1 are implemented, but the framework is there for them all to be added:
https://github.com/hoglet67/PiTubeDirec ... isr.c#L388
Gosh. I'd have expected filing systems to use the page-based reads and writes for bulk transfer. If PiTubeDirect in native mode works without supporting them, I guess none do.

This is an important thing to know, given I was intending to write a filing system which does; I guess contributing an implementation to PiTubeDirect is probably easier than providing a workaround!

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 5:54 pm

crj wrote:If you are going to hack around in OSWRCH, isn't it more efficient to keep a copy of screen memory on the Parasite and send actual values rather than values to EOR, by the way?
This is how I do it with my emulators (ZX81, Ace and Spectrum).

I've now implemented the equivalent of hoglet's OSWRCH mechanism and it has made a big improvement. There's still some tearing when Skooldaze scrolls the screen but it's not too bad and it's quite playable. Putting in rectangle transfers should make things better still.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by crj » Sat Jan 13, 2018 6:06 pm

If you're writing to the tube from emulated hardware, i.e. directly within the PiTubeDirect code, maybe you can be certain of keeping the FIFO from becoming empty? If so, you could go a little faster by not polling the status register.

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 6:11 pm

crj wrote:If you're writing to the tube from emulated hardware, i.e. directly within the PiTubeDirect code, maybe you can be certain of keeping the FIFO from becoming empty? If so, you could go a little faster by not polling the status register.
Good point - I'll give it a go...

User avatar
BigEd
Posts: 1891
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by BigEd » Sat Jan 13, 2018 6:14 pm

Would I be right in thinking that the 256-byte transfer could be useful, providing it's not too tacky or inefficient to pad updates into 256 byte blocks? (The data could still be compressed or encoded, but a 257 byte update or a 1 byte update would be rather inefficient.)

[Edit: I see now the suggestion to use byte-pair mode for smaller updates, which could be a win]

Anyhow, glad to hear that the SpectROM is now running better!

User avatar
hoglet
Posts: 7232
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by hoglet » Sat Jan 13, 2018 9:48 pm

Hi Rob,

This looks really cool.
RobC wrote: It needs VideoNuLA, as apart from the colours, it uses a new attribute mode that's able to mimic the Spectrum's display. I had to modify the VideoNuLA VHDL to implement this so there's currently only one board in existence that can support it! However, if I get this working properly, I'll upgrade existing boards for free and new boards will ship with it.
At a register level, how is this mode enabled?

I'm I right in guessing that you have expanded Control Code 7 from a 1-bit param to a 2-bit param?

00 = text mode
01 = enable 8-colour attribute text mode
10 = enable 16-foreground/16-background "spectrum" mode
11 = reserved

Dave

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sat Jan 13, 2018 10:16 pm

hoglet wrote:This looks really cool.
Thanks Dave - it wouldn't be possible without the Pi co-pro :D

It's a lot of fun running a Spectrum on my Beeb but I'd forgotten just how many keywords were crammed onto the keys and it's really hard when the keys only have the letters on them. However, my six-year-old daughter has really taken to it and spent this afternoon drawing coloured circles on the screen. She even came to get me to report a bug in my snapshot loading routine!
hoglet wrote:At a register level, how is this mode enabled?
Using a value of 2 with control code 6, so writing &62 to &FE22 enables it. This was put in without much thought as I just wanted a way of invoking it. Your scheme seems more logical so I might change it if there's room.

It's more of a hack than the other attribute modes as I was very tight on space and the top two bits of the attributes have specific purposes (BRIGHT and FLASH). I'd have liked to make it more generic but couldn't find the space. The trickiest part was making sure that it latches on to the correct phase for attribute or pixel data and this took up more logic than I'd expected...

User avatar
Lardo Boffin
Posts: 1093
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by Lardo Boffin » Sun Jan 14, 2018 7:19 am

Wow, wow and wow! From pun to reality in a very short period of time. Amazing!

When will I be able to play Bards Tale? :D
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, Viglen twin 40/80 5.25" discs, acorn cassette, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master

RobC
Posts: 2213
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by RobC » Sun Jan 14, 2018 10:25 am

Lardo Boffin wrote:Wow, wow and wow! From pun to reality in a very short period of time. Amazing!
Thanks - the idea was all yours though :) . Progressing from the ZX81->Jupiter Ace->Spectrum helped.
Lardo Boffin wrote:When will I be able to play Bards Tale?
I'm going to try to get something usable out in the next week or so. I'm also hoping to make up some VideoNuLA boards with the revised functionality. As I've said above, I'll upgrade existing boards for free for anyone who wants it done.

User avatar
mlouka
Posts: 47
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: SpectROM - Speccy emulator for the Pi co-pro

Post by mlouka » Sun Jan 14, 2018 4:24 pm

RobC wrote: It's a lot of fun running a Spectrum on my Beeb but I'd forgotten just how many keywords were crammed onto the keys and it's really hard when the keys only have the letters on them.
When trying out your ZX81 emulator, I ended up using a real ZX81 as a "keystrip"! :P

Michael
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

Post Reply