SpectROM - Speccy emulator for the Pi co-pro

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
RobC
Posts: 2184
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 4:32 pm

mlouka wrote:When trying out your ZX81 emulator, I ended up using a real ZX81 as a "keystrip"!
Good idea :D I've now setup my Spectrum next to the Beeb!

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Sun Jan 14, 2018 6:15 pm

A good yrdt would be running z80 BBC basic for the spectrum on it.
Ytft??? Yedt. No t4sy
Gtrr
Tedy
5esdt
Test
God, they font make these thing in any way eassy to type on do they?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
KenLowe
Posts: 283
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

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

Post by KenLowe » Sun Jan 14, 2018 6:41 pm

This looks really cool! Waiting patiently for the release. Can we update VideoNula ourselves, or do we have to send them back to you?

RobC
Posts: 2184
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 7:18 pm

jgharston wrote:A good *test* would be running z80 BBC basic for the spectrum on it.
Great idea - I'll try it as soon as I can. The emulator can only load snapshots at the moment but I can add ROM loading.
KenLowe wrote:This looks really cool! Waiting patiently for the release. Can we update VideoNula ourselves, or do we have to send them back to you?
Unfortunately, the CPLD (Max II) will need to be reprogrammed. I can send out the file for anyone who is able to do it themselves or I'm happy to do it. It's only a two-minute job so there'll be no charge.

I've made some progress on the sound today - it's still not great but is now producing something recognisable. I'm currently counting the number of times the Spectrum's speaker is being flipped and turning that into a tone to feed to the Beeb's sound chip. If anyone has any other ideas around this, I'd be grateful to hear them... (I tried flipping volume between full on and off with one of the tone generators set to the highest frequency but that produced terrible results!)

I want to try another couple of speed improvements and to do some serious testing before deciding on whether to implement double buffering (as it'll impact on how I do the border and file operations). Any suggestions for Speccy games that have a lot of scrolling or that do clever effects would also be appreciated.

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

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

Post by tricky » Sun Jan 14, 2018 9:29 pm

Batman the movie
Beach buggy simulator
More tea vicar (lots of particles)
Repton 1 and 2 ported by Gil who wrote Jeltron with me in the 80s.
No scrolling, but what does bomb Jack look like ;)

RobC
Posts: 2184
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 9:57 pm

tricky wrote:Batman the movie
Beach buggy simulator
More tea vicar (lots of particles)
Repton 1 and 2 ported by Gil who wrote Jeltron with me in the 80s.
No scrolling, but what does bomb Jack look like ;)
Thanks tricky.

Haven't tried Bomb Jack yet but I played the Spectrum version on an emulator when I was looking at the Beeb port and wasn't impressed. The sprites are quite small and so I suspect that the non-scrolling parts of Skool Daze are more of a test.

I tried The Great Escape tonight and that worked pretty well. I also tried Ant Attack but it wouldn't run so there's a flaw somewhere in the emulation :(

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

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

Post by hoglet » Thu Jan 18, 2018 5:44 pm

Rob,

Is there any possibility you could save a sample screen of a game running on the emulator?

i.e. literally just somehow pause the emulator and save the contents of the screen memory to a file.

I'd like to add the Speccy attribute mode to the BeebFpga VideoNuLA implementation, and it would really help to have a couple of test screens.

Also, does this mode piggy back on one of the existing modes, or have you had to re-program the 6845 (I suspect the latter, as none of the existing modes are 12KB)

Cheers,

Dave

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

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

Post by RobC » Thu Jan 18, 2018 7:25 pm

Hi Dave,
hoglet wrote:Is there any possibility you could save a sample screen of a game running on the emulator?
Sure - I'll just have to add a function to dump out the video memory and attributes. It'll probably not be until tomorrow though as I'm looking at speeding up the keyboard handling tonight. (Annoyingly, OSBYTE &79 works differently on a B/B+ than it does on the Master I've been using for testing...)
hoglet wrote:Also, does this mode piggy back on one of the existing modes, or have you had to re-program the 6845 (I suspect the latter, as none of the existing modes are 12KB)
I'm using a shrunk mode 0 (512x192). As the raster moves across the screen, the first byte contains the attributes and the second contains the pixel data.

Here's the Beebasm setup code for the screen mode:

Code: Select all

\\ Setup screen (Mode 0, 64 x 24)
LDA #22
JSR OSWRCH
LDA #0
JSR OSWRCH

\\ Display 24 rows
LDA #6
STA &FE00
LDA #24
STA &FE01

\\ Adjust vertical position for 24 rows
LDA #4
STA &FE00
LDA #41
STA &FE01

\\ Set horizontal displayed to 64
LDA #1
STA &FE00
LDA #64
STA &FE01

\\ Adjust horizontal position for 64 columns
LDA #2
STA &FE00
LDA #89
STA &FE01

\\ Set up "Spectrum" attribute mode
LDA #&62
STA &FE22

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Thu Jan 18, 2018 8:00 pm

There's a handful of screen dumps here as within Spectrum SNA snapshots. The screen data starts at byte 27 and continues for &1B00 bytes. GrabScrn will extract the screen data from a SNA or SNP shapshot, and ZXDisp will display the screen memory from within a SNA or SNP snapshot.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Thu Jan 18, 2018 8:10 pm

RobC wrote:(Annoyingly, OSBYTE &79 works differently on a B/B+ than it does on the Master I've been using for testing...)
Which issue is that? The only difference is that the Master keyboard has 16* columns to the Beeb's 10 columns.
(*ok, technically 13 columns)

RISC OS (and I think the Elk) don't implement testkey>&7F for 'any key from this scan number', but I've just checked, and the Master does do this.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

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

Post by RobC » Thu Jan 18, 2018 8:34 pm

jgharston wrote:Which issue is that? The only difference is that the Master keyboard has 16* columns to the Beeb's 10 columns.
(*ok, technically 13 columns)
The Master always returns the lowest key found provided it's greater than the start key given in X (as described in the Master reference manual). So, I was chaining OSBYTE &79 calls to detect simultaneous key presses (as you might need to detect something like up, right and fire say) by setting X to one more than the last key returned (starting at 16).

OS1.2 on the B and 2.0 on the B+, don't. Keys are searched in increasing row order but decreasing column order.

On a Master, pressing 'L' (internal key code &56) and 'N' (internal key code &55) returns &55, on a B and B+, it'll return &56.

I've now written something based on the Master routine and, as a bonus, it's more efficient than running multiple scans :D

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Thu Jan 18, 2018 8:48 pm

Just caught up with this thread. Great stuff Rob!

On the subject of double buffering - I'm not sure it would be necessary, as I would have expected it to be possible to reflect the emulated screen state on the host in real time, as the emulation runs. You might need to make a few different cases for speed though:
  • A common trick on the Speccy to do fast scrolling or sprite blitting was to set SP to a screen address and do PUSH <register pair>, in just 11 T-states. So some way of indicating that a packet represented "write d1 at addr, write d2 at addr+8" would give you a bit of a speedup (would still need to send two single byte packets where the resulting Beeb screen addresses were discontinuous). When this trick is used to present the back buffer by quickly copying it to the screen, the most registers in a block you could have writing consecutively is 4 pairs (44 T-states) where the host could fall behind. This has to be followed by more reloads afterwards though, which would give the host catchup time.
  • LDIR can do a block copy in 21 T-states per byte. Seems a bit slow, and I'm not really sure if it was used much (I think they tended to prefer an unrolled bunch of LDIs, 16 T-states each - still a bit slow). You could still optimise this on the host by outputting packets where the Beeb screen memory it touches is every 8 bytes.
I can imagine writing attributes is a bit slower, but luckily it's not done as much as writing to bitmap memory.

I'm guessing you're using the HALT instruction to force a wait for VSync on the host?

As for games with lots of scrolling and that kind of thing: try R-Type (chugs a bit), Operation Wolf and Stormlord as examples of pixel-by-pixel scrolling. Character-block scrolling: Gauntlet (which almost certainly uses the SP trick to present the back buffer as quickly as possible). And Chase HQ was just a fantastic implementation on the Speccy, basically the entire screen updated each frame, again probably using a back buffer.

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

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

Post by RobC » Thu Jan 18, 2018 9:12 pm

Thanks Rich - that's really useful. I've read a little bit on Spectrum games but don't really do Z80 so it's all new to me.

At the moment, I'm just running a set number of t-states per frame (~70,000) and then doing the host stuff with wait for vsync in the screen refresh. So, the Z80 core is effectively running a halt.

I've currently implemented four types of packet: write pixel data at individual addresses, write block of pixel data from a single address and their equivalents for attribute data. However, the parasite code is currently only using the individual address packets but I've nearly completed a version that can make use of the block transfers.

Games that don't scroll already seem to run really well with no obvious flickering (Sabre Wulf, Bomb Jack, Underwurlde). Ant Attack and Great Escape are pretty good.

I'm still thinking about double-buffering - it'll fit (even under ADFS) but wouldn't leave any room for a border. One idea I had would be to implement a small border down the side in VideoNuLA but I'll have to see if there's enough room left.

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Thu Jan 18, 2018 9:29 pm

I would think that your flicker is mostly caused by not syncing VSyncs on the host with your emulated HALT on the parasite. I would expect most games to use that to avoid flicker as much as possible, even those which have to present the back buffer via the SP or unrolled LDI techniques (as this can be done in just under 1/50th of a second). You can tell the games that don't use HALT, like R-Type, which just go blatting data on-screen continuously, and to hell with the tearing!

I don't think you're going to need any other kind of clever heuristics for detecting more complicated screen manipulation like rectangular block copies or whatever. You're lucky in that the Speccy has a fixed screen address layout, so you can always detect screen writes on the parasite, and also know if a 16 bit write or a LDIR block copy is going to straddle the discontinuous 256 byte blocks or not. I reckon your approach is probably great, though you might want to make a special case for 2 byte transfers as they're quite common (and save needing to send a count byte for that packet).

Double buffering will make your life easier and not require you to be careful about syncing, but my instinct is that you probably don't really need it. I'd go for a big border instead using a regular sized MODE 0, and your idea of the spare black!

By the way, how are you doing FLASH?

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Thu Jan 18, 2018 9:37 pm

Just to add, for purposes of timing, it might be worth knowing that the Spectrum ULA didn't output interlaced video. It was just 312 lines each field, or exactly 69888 T-states.

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Thu Jan 18, 2018 9:45 pm

Just a further brain dump as I think of stuff.

You might actually want to build in some delays on the parasite emulation so that you stay roughly in sync with real time at the end of every 8 lines or so. That would further mitigate flicker/tearing problems due to the host writing to the screen too soon.

I reckon a worthwhile extra heuristic would be to detect blocks of adjacent LDI (or LDD) instructions which are aimed at screen memory, and package them into a single packet where they don't cross a 256 byte boundary. From reading around on Spectrum forums just now, it looks as if this was done quite a bit as an optimization (because normally you *know* how big the sprite is, so it's better to unroll it than to use BC as a counter).

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

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

Post by RobC » Thu Jan 18, 2018 9:47 pm

Rich Talbot-Watkins wrote:I would think that your flicker is mostly caused by not syncing VSyncs on the host with your emulated HALT on the parasite. I would expect most games to use that to avoid flicker as much as possible, even those which have to present the back buffer via the SP or unrolled LDI techniques (as this can be done in just under 1/50th of a second). You can tell the games that don't use HALT, like R-Type, which just go blatting data on-screen continuously, and to hell with the tearing!
Ah - that makes sense. I'll give it a try.
Rich Talbot-Watkins wrote:I don't think you're going to need any other kind of clever heuristics for detecting more complicated screen manipulation like rectangular block copies or whatever. You're lucky in that the Speccy has a fixed screen address layout, so you can always detect screen writes on the parasite, and also know if a 16 bit write or a LDIR block copy is going to straddle the discontinuous 256 byte blocks or not. I reckon your approach is probably great, though you might want to make a special case for 2 byte transfers as they're quite common (and save needing to send a count byte for that packet).
Yes - I was surprised by how well the individual byte approach worked but I'll look at putting in double byte transfers.
Rich Talbot-Watkins wrote:Double buffering will make your life easier and not require you to be careful about syncing, but my instinct is that you probably don't really need it. I'd go for a big border instead using a regular sized MODE 0, and your idea of the spare black!
I've held off doing it as I would like to put the border in and because it would hide issues like the halt thing above!
Rich Talbot-Watkins wrote:By the way, how are you doing FLASH?
The VideoNuLA Spectrum mode implements the attribute bytes exactly as the Spectrum does. So, apart from having to write 8 copies on the host (one for every scanline rather than row), there's no extra work.
Rich Talbot-Watkins wrote:Just to add, for purposes of timing, it might be worth knowing that the Spectrum ULA didn't output interlaced video. It was just 312 lines each field, or exactly 69888 T-states.
Thanks - that's the value I'm using but I didn't know why!

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Thu Jan 18, 2018 11:36 pm

Rich Talbot-Watkins wrote:[*] LDIR can do a block copy in 21 T-states per byte. Seems a bit slow, and I'm not really sure if it was used much (I think they tended to prefer an unrolled bunch of LDIs, 16 T-states each - still a bit slow). You could still optimise this on the host by outputting packets where the Beeb screen memory it touches is every 8 bytes.
JetSetWilly is a good test of LDIR as it uses two screen buffers: sets up buffer 1, LDIRs it to buffer 2, writes sprites to it, then LDIRs it to the screen. A common emulation of LDIR is to do it atomically within the emulator, so to the CPU it looks like it's instant. The symptom of this is things like JetSetWilly become unplayable.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Fri Jan 19, 2018 8:14 am

I have another thought about synchronising screen writes on the host with those on the emulator. This is still based on the assumption that the host will always be able to process packets from the parasite, on average, in real time.

The issue is that we want to ensure that actual screen writes on the host are done at the same raster position as emulated screen writes. My idea is to set up a free-run VIA timer set to interrupt every 4 scanlines (256us); all the interrupt does is increment a counter (which is reset on VSync). Now, you have a special packet type which says which emulated scanline (scanline/4) we're on. If you receive that then you just wait until the counter matches that before continuing to process packets. Of course you only need send that packet prior to the first screen write on that scanline.

This way you don't need to do any careful timing on the parasite - the only synchronisation you need is for VSync, which comes from the host. The emulation can run as fast as it wants, between VSyncs.

Might improve sound emulation too!

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Fri Jan 19, 2018 8:40 am

jgharston wrote:JetSetWilly is a good test of LDIR as it uses two screen buffers: sets up buffer 1, LDIRs it to buffer 2, writes sprites to it, then LDIRs it to the screen. A common emulation of LDIR is to do it atomically within the emulator, so to the CPU it looks like it's instant. The symptom of this is things like JetSetWilly become unplayable.
I think you'd only implement LDIR like that if you wanted your emulation to go as fast as possible. For games, it's pretty normal to keep track of cycle counts, scanlines, etc so you can synchronise everything. Also, for accuracy, it's better to implement it as a repeated LDI so interrupts can occur before it ends.

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

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

Post by RobC » Fri Jan 19, 2018 9:46 am

Rich Talbot-Watkins wrote:The issue is that we want to ensure that actual screen writes on the host are done at the same raster position as emulated screen writes. My idea is to set up a free-run VIA timer set to interrupt every 4 scanlines (256us); all the interrupt does is increment a counter (which is reset on VSync). Now, you have a special packet type which says which emulated scanline (scanline/4) we're on. If you receive that then you just wait until the counter matches that before continuing to process packets. Of course you only need send that packet prior to the first screen write on that scanline.
Thanks again. I'd thought to try a similar idea for the sound but didn't really think of it for the video. When I started writing this, I thought that I'd need to handle all the screen updates in one go but it may well be quick enough to do them in real time.

I may just finish off the version I'm currently working on and then look to change things.

On the LDIR thing, the Z80 core is from Ian Collier's xz80 as that was used in xAce. I'm pretty sure it's doing the right thing (21 tstates) but will test it with JSW.

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

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

Post by Lardo Boffin » Fri Jan 19, 2018 10:24 am

I have one of these for my Spectrum. And it is awesome - emulator quality output! I believe it works by ‘listening’ for writes to the screen RAM in order to produce its picture but am not 100% sure.

http://www.fruitcake.plus.com/Sinclair/ ... erface.htm

The guy who developed it clearly knows a lot about Spectrum displays etc. and may be able to offer advice? He has always come across as very helpful.
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

User avatar
Rich Talbot-Watkins
Posts: 1281
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Fri Jan 19, 2018 10:32 am

RobC wrote:Thanks again. I'd thought to try a similar idea for the sound but didn't really think of it for the video. When I started writing this, I thought that I'd need to handle all the screen updates in one go but it may well be quick enough to do them in real time.
The only thing I can think of that the host would struggle to keep up with is a screen clear routine using the stack. So something like:

Code: Select all

    LD B,C0h      ; screen size / 32
    LD DE,0000h
    DI
    LD HL,0000h
    ADD HL,SP     ; store current SP in HL
    LD SP,5800h   ; end of bitmap screen
loop:
    PUSH DE       ; repeat 16 times (push 32 bytes)
       ...
    DJNZ loop
    LD SP,HL
    EI
    RET
Each of those PUSHes can be completed in 11 T-states, meaning you only have 3 6502 cycles per byte. The DJNZ gives you a 13 T-state respite, but that's just not enough to catch up, so a screen clear like this will always run too slowly. So, heuristics-wise, you could probably mitigate this a little by spotting runs of PUSH with the same register pair and create yet another packet type to handle that.

That said, I'd be very surprised if any game needs to do this kind of screen clearing each frame, as this takes 162 scanlines to run. If anything, it will be clearing a back buffer and then using a stack trick, but interleaved with loads, to present the back buffer. The loads are where your host can play catch up, so I still think that, where it matters, you can do this in real time.

Edit to add: A nice little trick which comes for free though, is only output a packet at all if the byte being stored is different from the byte that's already there. That could even help a routine like this enormously.

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Sat Jan 20, 2018 1:53 am

Rich Talbot-Watkins wrote:Edit to add: A nice little trick which comes for free though, is only output a packet at all if the byte being stored is different from the byte that's already there. That could even help a routine like this enormously.
I believe (without going back to Sheffield to check) that's what Speculator on RISC OS does. Any store-to-memory operations to &4000-&5AFF only update the emulated screen if the byte written to memory is different.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

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

Post by RobC » Sat Jan 20, 2018 8:46 am

Lardo Boffin wrote:I have one of these for my Spectrum. And it is awesome - emulator quality output! I believe it works by ‘listening’ for writes to the screen RAM in order to produce its picture but am not 100% sure.

http://www.fruitcake.plus.com/Sinclair/ ... erface.htm
Thanks - I'd not seen that before. It's a great idea.
jgharston wrote:
Rich Talbot-Watkins wrote:Edit to add: A nice little trick which comes for free though, is only output a packet at all if the byte being stored is different from the byte that's already there. That could even help a routine like this enormously.
I believe (without going back to Sheffield to check) that's what Speculator on RISC OS does. Any store-to-memory operations to &4000-&5AFF only update the emulated screen if the byte written to memory is different.
That's also what I'm doing - I keep a copy of the screen from the end of the last frame and output runs of bytes that have changed.

I've been sending a screen's worth of attribute changes across before the pixel changes as it saves sending multiple control codes. I'm pretty pleased with how it's working but I'm going to try sending all the changes a row at a time so that the pixel changes stay closer to the raster.

As a quick break from the video stuff, I've added Kempston joystick support and will look at improving the sound after I've tried the row-based video change.

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

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

Post by hoglet » Sun Jan 21, 2018 1:18 pm

Hi Rob,

I've now corrected the Speccy attribute implementation in BeebFpga.

I wonder if you could possibly run my test program on the real hardware and see if you get the same results as I do.
493.ssd
(200 KiB) Downloaded 14 times
It should look like this:
IMG_1187s.JPG
All you should need to do is CHAIN "SPECTST"

The rather hacky image conversion program is there as well, called "SPECCY".

I assumed the numbering of the logical colours follows the spectrum order, so that the emulator doesn't need to do any conversion. So normal blue would be colour 1 and normal red would be colour 2. Is that convention correct?

The only other thing I noticed was your 6845 settings (posted earlier in this thread) seemed confused my VGA monitor, because the VSync frequency changed from 50Hz to 47Hz. This seems to be down to:

Code: Select all

\\ Adjust vertical position for 24 rows
LDA #4
STA &FE00
LDA #41
STA &FE01
Register 4 is the vertical total. Is that an oversight?

This worked better for me:

Code: Select all

\\ Adjust vertical position for 24 rows
LDA #7
STA &FE00
LDA #30
STA &FE01
I can't wait to try the SpectROM emulator on the Pi.

Dave

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

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

Post by RobC » Sun Jan 21, 2018 8:05 pm

Sorry for not testing this sooner Dave but it's my sister's birthday today and we've been doing some family stuff...
hoglet wrote:I assumed the numbering of the logical colours follows the spectrum order, so that the emulator doesn't need to do any conversion. So normal blue would be colour 1 and normal red would be colour 2. Is that convention correct?
Unfortunately not as I arbitrarily chose to keep the logical colours in the Beeb order with the darker colours followed by their bright equivalents. So colour 1 is dark red and colour 9 is bright red etc. Therefore, the palette index is formed from the attribute byte as:

Code: Select all

b6 b0 b2 b1 (Br|Ib|Ig|Ir) when displaying foreground or background with flashing operating
b6 b3 b5 b4 (Br|Pb|Pg|Pr) when displaying background or foreground with flashing operating
So, the good news is that your picture displays correctly if I disable the setting of the palette from line 300 onwards and define it as it's done in SpectROM.
hoglet wrote:The only other thing I noticed was your 6845 settings (posted earlier in this thread) seemed confused my VGA monitor, because the VSync frequency changed from 50Hz to 47Hz. This seems to be down to:

Code: Select all

\\ Adjust vertical position for 24 rows
LDA #4
STA &FE00
LDA #41
STA &FE01
Register 4 is the vertical total. Is that an oversight?
Thanks - it's a mistake by me. I copied the code from my BombJack prototype so it's possibly just a typo - I'll check the original code.
hoglet wrote:I can't wait to try the SpectROM emulator on the Pi.
Shouldn't be too long now before I get it to the point where I can release something. The row-by-row update stuff is in and has improved the scrolling - Skooldaze isn't perfect but I don't think the original is either (I need to setup my Spectrum alongside the Beeb to compare them...).

However, I've introduced a bug that I'm yet to find. My daughter heard me talking about it earlier and then told my wife that she's worried that my computer will make me ill :D

EDIT: Bug now fixed!
Last edited by RobC on Tue Jan 23, 2018 9:44 am, edited 1 time in total.

User avatar
1024MAK
Posts: 7432
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

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

Post by 1024MAK » Mon Jan 22, 2018 10:48 am

RobC wrote:However, I've introduced a bug that I'm yet to find. My daughter heard me talking about it earlier and then told my wife that she's worried that my computer will make me ill :D
She's not wrong. Computers are like a drug addiction... :lol:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
jgharston
Posts: 3060
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Tue Jan 23, 2018 2:39 am

hoglet wrote:I assumed the numbering of the logical colours follows the spectrum order, so that the emulator doesn't need to do any conversion. So normal blue would be colour 1 and normal red would be colour 2. Is that convention correct?
BBC hardware colours and API colour numbers are %BGR (ie red, green, yellow, blue...).
Spectrum hardware colours and API colour numbers are %GRB (ie blue, red, magenta, green...).
If you're using something that expects to call an API with BBC colour numbers your API must translate them, as the BBC BASIC host does on the Spectrum (link). Similarly, you're using something that expects to call an API with Spectrum colour numbers your API must translate them, as a theoretical implementation of ZXBasic on the BBC would have to do.

In software, BBC->Spectrum colour numbers can be changed:
* in Z80 code with: CP 4:CCF:ADC 0:AND 7
* in 6502 code with: CMP #4:ADC #0:AND #7
Spectrum->BBC colour numbers can be changed:
* in Z80 code with: SRL A:BCC P%+4:OR 4
* in 6502 code with: LSR A:BCC P%+4:ORA #4

Edit: (I had to check the code for this) and in BASIC, Spectrum to BBC can be done with:
attr%=((attr%AND1)*4)+((attr%AND6)DIV2) + ((attr%AND8)*4)+((attr%AND48)DIV2) + (attr%AND&C0)
which rotates the INK and PAPER bits of the %FIgrbGRB of the Spectrum attribute byte into %FIbgrBGR.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

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

Post by crj » Tue Jan 23, 2018 4:39 am

jgharston wrote:BBC hardware colours and API colour numbers are %BGR (ie red, green, yellow, blue...).
It's probably more intuitive to think of them as little-endian RGB.

Post Reply