Bitshifters - Ode to Mode 7 Competition

These forums are for community collaboration on archiving, magazine scanning etc. to avoid work duplication and agree conventions / define standards
User avatar
simonm
Posts: 164
Joined: Mon May 09, 2016 2:40 pm
Contact:

Bitshifters - Ode to Mode 7 Competition

Postby simonm » Sun Sep 11, 2016 2:08 pm

Hi all,
As some of you may know, myself and Kieran have put together a new site to celebrate & encourage home brew developments of "cool stuff" for the Beeb (https://bitshifters.github.io/). Our goal is to provide a repository for source code, and also encourage new developments, creations or projects that showcase what the beeb is/was capable of. We see this very much as a community thing, so anyone who'd like to join in with running it is very welcome.

Anyway, we thought it'd be pretty fun to setup a competition to spark imaginations, so we've launched a Mode7 challenge - what cool stuff can you do with Mode7?!
Any contributions, be it art/demos/games/whatever, basic or assembler, will be accepted, just needs to be a bootable SSD file. We are happy to also host source code to contributions within the bitshifters GitHub repository for others to benefit from.

Obviously, we realise everyone has real lives and stuff that gets in the way of precious beeb-fun time, so we're setting January 2017 as the closing date for entries. Will try and get some kind of voting thing up at some point, and we can hopefully announce the finalists at the January ABUG meet.

Linky is here:
https://bitshifters.github.io/posts/com ... mode7.html

Facebook page is here:
https://www.facebook.com/bitshiftrs

Have fun guys! Hope it gets yer juices flowing!
Cheers
Simon

User avatar
sPhilMainwaring
Posts: 239
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby sPhilMainwaring » Sun Sep 11, 2016 2:48 pm

I've had a version called 6847Invaders on the go (for Atom's Clear 0) for a few years now but never got round to really getting my teeth into it ...

64x48 "pixel" resized teletext

Image

Acorn Atom "CLEAR 0" 64x48 semigraphic version

Image

Splash screen

Image

Relocate-able, Reassemble-able disassembly of Acornsoft Invaders source code for resizing teletext version

http://phils-place.co.uk/transfers/inva ... ctions.txt

Disk Image

http://phils-place.co.uk/transfers/my_invaders.ssd

I know this isn't 100% germane to the teletext but the disassembly may be useful

Feel free to use/abuse :)

User avatar
sPhilMainwaring
Posts: 239
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby sPhilMainwaring » Sun Sep 11, 2016 3:03 pm

p.s. (Question for bit-shifters)

I've done lots of art that's compatible with MODE 7. How many full MODE 7 images can you save on the non-modified BBC Micro double sided disk using that double sided sector read - I could work it out but you probably know off the top of your head and allow for boot and software

I'd like to do a slowed down version of the teletext film as a slideshow ... and maybe some MODE 7 wipes/dissolves as transitions

p.p.s Do you have a .DSD version of the MODE 7 film for BeebEm that was running at the Centre for Computing History meet?

User avatar
simonm
Posts: 164
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby simonm » Sun Sep 11, 2016 3:24 pm

Mode 7 screens are 1k a pop Phil so you will be able to fit loads on a dsd. Add a bit of compression like exomiser and you can probably double capacity.
Would be brill to get a Teletext art reel.
Kieran is your man for mode 7 video ;)

User avatar
sPhilMainwaring
Posts: 239
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby sPhilMainwaring » Sun Sep 11, 2016 3:36 pm

Thanks Simon ... I saw the movie running at CFCH, Cambridge but

a) Couldn't remember sectors/track and tracks/side - think it was about 240KB both sides
b) Wasn't sure if you/kieran used 23/24/25 line teletext standard x 40 = 920, 960 and 1000 bytes per side

re the movie I don't think they're compressed as it only has enough time to read the sectors to display in real time but yes for a slow slideshow I could use some compression :)

OK I've looked things up and, according to ...

http://chrisacorns.computinghistory.org ... icros.html

The floppy discs were single or double sided and 40 or 80 track giving:

Single sided 40 track = 100K
Single sided 80 track = 200K
Double sided 40 track = 200K
Double sided 80 track = 400K

400 * 1,024 = 409,600 / 1000 === 409 Frames

I seem to remember Kieran saying there was about 3 minutes for the unmodified / standard setup

3 * 60 * 25 = 4,500 frames

This would indicate (for example at 24fps instead of 25fps_ that a double sided 80 track disk is used and stores about 400 frames :)

User avatar
kieranhj
Posts: 481
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Bitshifters - Ode to Mode 7 Competition

Postby kieranhj » Sun Sep 11, 2016 9:44 pm

As mentioned on FB we can provide you with the Exomizer exe for compression on PC side and then a ready to rumble 6502 decompression routine in BeebAsm format. Our goal is to encourage more people to make fun + cool stuff to show off what the Beeb is capable of and celebrate its heritage. We'll be sharing every bit of code on GitHub and making it all freely available including our general libraries and framework etc. There's no "aren't I clever" secrets here - it's all open collaborative development. :)

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby tricky » Mon Sep 12, 2016 5:44 pm

I put a demo on RetroSoftware which displays a piece of memory as mode 7 pixels, they are stored as mode 7, but 8 pixels per byte.
It decodes the whole screen every frame, not sure what it might be used for, but the demo moves the start of memory down one pixel each time, giving a scrolling display which just keeps wrapping around memory.
If you look carefully, apart from getting mesmerized, you can see bytes which are changed by interrupt change as they scroll.
Description: http://www.retrosoftware.co.uk/wiki/index.php?title=VerticalScrollingMode7
Discussion: http://www.retrosoftware.co.uk/forum/viewtopic.php?f=73&t=635
Demo with source attached.
Attachments
mode7decoding4scrolling.zip
(2.01 KiB) Downloaded 22 times

User avatar
jms2
Posts: 1803
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK

Re: Bitshifters - Ode to Mode 7 Competition

Postby jms2 » Wed Sep 14, 2016 7:29 pm

As your demo hadn't attracted very much attention, I downloaded it and had a play. It's interesting, but it kind of does what it says on the tin, so maybe that's why nobody posted any comments! :lol:

I wasn't quite sure what you meant about "8 pixels per byte" - are these 8 pixels arranged horizontally, over 4 characters? Or are there 6 in one character the next 2 spilling over into the following character?

While we're on the subject of Mode 7 trickery, I've got two questions (for anyone):

1) It was recently suggested in the "New Adventures" thread that it would be cool to have a split screen with (say) Mode 5 at the top and Mode 7 at the bottom. I presume this is impossible though, because whilst it would be very useful I have never seen it done. Has anyone ever tried this?

2) I was always very impressed by the widescreen Mode 7 in the Firetrack intro sequence. How easy is this to recreate? I presume not very easy, otherwise more people would have done it. Any ideas?

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby tricky » Wed Sep 14, 2016 11:10 pm

I don't know the answer to either, but I would guess that 1 might be possible with vertical rupture, which wasn't well known/understood bitd.

2 sounds easy enough, but to use more than 1024 bytes per screen means having it split 16k apart.

I can't think why, but I have memories of extra restrictions on mode 7 on a master.

My mode 7 bitmap display has 4 rows of 2 pixels per byte, but allows a vertical offset of 0, 1, 2 or 3 pixels, allowing vertical scrolling in mode 7 pixels, while taking up less space than pure mode 7 graphics.

SarahWalker
Posts: 1036
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby SarahWalker » Thu Sep 15, 2016 5:20 pm

tricky wrote:I can't think why, but I have memories of extra restrictions on mode 7 on a master.

Two differences I can think of, firstly you can't place the buffer at &3c00. You can put it in shadow memory, so you do still have the same 2-page functionality, but obviously it's not compatible with the B.

Second is mostly relevant when using widescreen or other non standard display sizes, on the Beeb you can replace the OS row address lookup table to compensate for a non-standard display width, meaning you can use the OS routines on such a display. On the Master this isn't possible. I would assume this is why Firetrack doesn't use the widescreen intro on a Master.

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Thu Sep 15, 2016 7:08 pm

Just tried to knock up a quick demo. it looks like beebEm and jsbeeb don't really expect me to play so much with the 6845.

Might have to try it on real hardware

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby Rich Talbot-Watkins » Thu Sep 15, 2016 7:48 pm

What are you doing? jsbeeb should be pretty faithful, although it is conceivable that its Mode 7 support still isn't perfect.

User avatar
lurkio
Posts: 1142
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby lurkio » Thu Sep 15, 2016 8:25 pm

simonm wrote:we thought it'd be pretty fun to setup a competition to spark imaginations, so we've launched a Mode7 challenge - what cool stuff can you do with Mode7?!

Shame it's probably too late for Rock-Race by BungeeBill to be entered!

Maybe it can get an honourable mention or something?

:?:

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Thu Sep 15, 2016 8:29 pm

I'm trying to use vertical rupture but half way down swap to mode 7 by setting the bit in FE20 and setting the screen address.

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby Rich Talbot-Watkins » Thu Sep 15, 2016 8:45 pm

Looking at the jsbeeb video emulation, it seems like it should work to do that, but it'll need a bit more than just changing &FE20 - you'll also need to program the CRTC with interlaced sync and video, change the number of scanlines per character row, and set up R12/R13 with chunky addressing before the split. Also note that there's a 2 character delay when displaying Mode 7 so you'd need to change R2 as well in order to align the screen. I have no idea whether this even works on real hardware, but I reckon there'd be some screen distortion as the hsync relocks to the new phase during the switch. It'd also need impeccable timing as a lot of those CRTC registers need to be changed on the exact first scanline of the Mode 7 screen area.

This is one of those things that I'd try on real hardware first to see if it's actually feasible, then if it is, we can try and fix up any issues with jsbeeb so the results match.

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Thu Sep 15, 2016 9:01 pm

I've done those things as well. I agree I need to try it on real hardware. jsbeeb and beebem have different results.

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby Rich Talbot-Watkins » Thu Sep 15, 2016 9:30 pm

BeebEm doesn't emulate Mode 7 properly at all, in fact it renders the characters glyph at a time, instead of scanline-by-scanline! It's treated as a whole different rendering mode by BeebEm.

jsbeeb attempts to do it properly, including emulating the delays in fetching character data and so on. The chunky addressing mode is a bit simplistic but I'd still expect it to do more or less the right thing. There are still some subtle video emulation bugs in jsbeeb though, so it may still need a bit of sorting out!

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby tricky » Fri Sep 16, 2016 6:44 am

And there is that slightly odd 6845 in some of the masters that causes the corruption on the last line of my frogger.

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby hoglet » Fri Sep 16, 2016 8:12 am

dp11 wrote:I've done those things as well. I agree I need to try it on real hardware. jsbeeb and beebem have different results.

I'd love to test this on BeebFPGA as well, when you are ready to release some test code.

Dave

User avatar
kieranhj
Posts: 481
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Bitshifters - Ode to Mode 7 Competition

Postby kieranhj » Fri Sep 16, 2016 9:43 am

This reminds me I need to check out Tom's "chunky mode 7" code snippets that he posted on RS a while back. Hmmm, does this count as MODE 7 for the purposes of our compo? :-k

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Sat Sep 17, 2016 3:48 pm

This is very much a quick hack and needs work. This has not been tested on real hardware and the timing is off.

I've been using jsbeeb . Get the zip from here http://www.retrosoftware.co.uk/wiki/ind ... _scrolling

Then use the following beebasm to replace the vrupt.6502 and build.

Code: Select all


\\ This is source code to accompany the Vertical Rupture wiki article by Richard Talbot-Watkins
\\ found at http://www.retrosoftware.co.uk/wiki/index.php/How_to_do_the_smooth_vertical_scrolling

\\ The code is adapted from the BBC micro ssd disk image:  http://www.retrosoftware.co.uk/wiki/images/2/25/Rupture1.zip
 

\\ The original code was in BBC asm and largely uncommented.

\\ The code below is for use with BeebASM (http://www.retrosoftware.co.uk/wiki/index.php/BeebAsm)

\\ All I have done is to restructure the code very slightly
\\ and comment it by pasting in excerpts from Richard's wiki article.
\\ I found that this made the code easier to follow and aided
\\ my understanding of the wiki article.  I hope that it helps you too!

\\ For completeness, the zip file you've downloaded
\\ contains a (BUILD.bat) batch file which assembles the code below and merges the output ssd disk image
\\ with the accompanying template.ssd.  The template.ssd contains the BASIC
\\ program which changes to MODE 2 and plots the boxes/text as seen in the wiki article screenshot.

\\ jbnbeeb. July 2015.


ORG &70

  .addr       SKIP 2
  .vsync       SKIP 1
  .whichtimer    SKIP 1
 
  timerwait1=5*8*64
  timerwait2=16*8*64 - 64*6

 
 
ORG &2000
.start

;--------------------------------------------------
.Main
;--------------------------------------------------
   jsr InitIRQandCRTC
   
   .loop
   \\Wait for VSync
      LDA #0
      STA vsync
   .fx19
      LDA vsync
      BEQ fx19

   JMP loop
RTS



;--------------------------------------------------
.InitIRQandCRTC
;--------------------------------------------------
\\ ** We disable unwanted interrupts
\\    and enable vsync, and Timer 2 System VIA interrupts only.
\\ This code is only called once.

   SEI
      LDA #&7F   ; disable all System VIA interrupts
      STA &FE4E

      LDA #&A2   ;enable vsync, and Timer 2 System VIA interrupts.
      STA &FE4E

      LDA #255
      STA &FE48
      STA &FE49


      LDA #0
      STA &FE4B
      LDA #4
      STA &FE4C
      LDA #15
      STA &FE42

      
      

      \\set hard coded wrap around addr for 10k screen mode
      LDA #12
      STA &FE40
      LDA #13
      STA &FE40

      \\set interrupt vector to address of our irq handler below
      LDA #irq AND 255:STA &204
      LDA #irq DIV 256:STA &205

      \\Store initial value of screen address.
      \\5800 = start addr for 10k wrap around scr mode
      LDA #0
      STA addr
      LDA #&58/8
      STA addr+1
   CLI
RTS




;--------------------------------------------------
.irq 
;--------------------------------------------------
\\** This is the IRQ handler **
\\ It is called each time an interrupt is generated.

   LDA &FE4D ;IFR
   AND #2
   BEQ timer
      \\** If we're here, it's a vsync interrupt.**
      
      STA &FE4D
      STA vsync
      STA whichtimer
      
         
      \\Set T2 timer with  wait1 value
      LDA #timerwait1 AND 255
      STA &FE48
      LDA #timerwait1 DIV 256
      STA &FE49

            \\ load new screen start addr in R12,R13
      LDA #12
      STA &FE00
      LDA addr+1
      STA &FE01
      LDA #13
      STA &FE00
      LDA addr
      STA &FE01
      
      LDA #&C4  \\ mode 5
      STA &FE20

   
      LDA #8
      STA &FE00
      LDA #1
      STA &FE01         
      
      LDA #9
      STA &FE00
      LDA #7
      STA &FE01
      
      LDA #2
      STA &FE00
      LDA #49
      STA &FE01
      
      LDA #6
      STA &FE00
      LDA #32
      STA &FE01
      
      LDA #7
      STA &FE00
      LDA #34
      STA &FE01   

      \\Now we must wait until the new CRTC cycle has started. We already know this to take 5 character rows (remember?!).
      \\5 character rows
      \\= 40 (5*8) scanlines
      \\= 2560 (40*64) 1MHz clock ticks
      
      
      LDA &FC ; when an interrupt is generated, content  of A register
            ; is put in addr &FC. We therefore restore this value to A
            ; before exiting interrupt handler.
RTI

.timer
      \\** if we're here, it's a timer interrupt. **
      LDA whichtimer
      BEQ secondtimer
      
      
      \\We are now into a new CRTC cycle. The CRTC has taken its internal address pointer from R12/R13 and is currently refreshing the screen from somewhere between &5800 and &8000 (whatever we specified - we are choosing this address for our scrolling after all!)
      
      \\ Next we do a few cunning things:
      
      \\(See P.359 of Advanced User Guide for explanation of CRTC registers)
      
      LDA #4 ;We set R4 to 15, specifying a total CRTC cycle length of 16 rows. (for the top half of screen)
      STA &FE00
      LDA #14 ;
      STA &FE01
      
      LDA #7 ;We set R7 to anything greater than 15. This ensures that VSync will NEVER be generated during this cycle. This is what we want, as we know from the PAL standard that we must have 39 rows in a refresh, and generating VSync every 16 rows will clearly cause the TV to barf! Let's set R7 to 255 just to make a point :)
      STA &FE00
      LDA #255
      STA &FE01
      
      LDA #6 ;We set R6 to 16: this ensures that we see all the rows of this CRTC cycle; this is what we want - they are all valid after all. Of course we could equally set R6 to anything higher than 16; it won't display any more because there are only 16 rows in the whole CRTC cycle!
      STA &FE00
      LDA #15
      STA &FE01
      
      
   
      LDA #12;  We set R12/R13 to look at &3000. As we know, the CRTC has already cached its internal address pointer from R12/R13 this update and changing them mid-update won't affect its screen address pointer. However, as we know, this update is only going to last 16 rows, at which point its cycle will start all over again, and its screen address pointer will be re-cached, this time using the NEW values in R12/R13, i.e. &3000!
      STA &FE00
      LDA #(&7c-&74)EOR&20
      STA &FE01
      LDA #13
      STA &FE00
      

      
      \\Now we need to wait for the new CRTC cycle to begin - this will of course be in 16 character rows time from the last cycle:

      
      \\..wait 16 character rows
      \\= 128 (16*8) scanlines
      \\= 8192 (128*64) 1MHz clock ticks


      \\At this point, the TV will be starting to rasterise the physical bottom half of the screen, and the CRTC will be sending screen data from addresses &3000 onwards to the TV.

      LDA #0
      STA &FE01
      
      STA whichtimer
      
      \\Set T2 timer with  wait2 value
      LDA #timerwait2 AND 255
      STA &FE48
      LDA #timerwait2 DIV 256
      STA &FE49
      
      LDA &FC  ; when an interrupt is generated, content  of A register
             ; is put in addr &FC. We therefore restore this value to A
             ; before exiting interrupt handler.
   RTI

   .secondtimer   
      LDA #&20
      STA &FE4D
      \\ swap to mode 7
      LDA #&4B
      STA &FE20
   
      LDA #2
      STA &FE00
      LDA #52 ; should be 51 ???
      STA &FE01

      LDA #8
      STA &FE00
      LDA #&93
      STA &FE01         
      
      LDA #9
      STA &FE00
      LDA #18
      STA &FE01   
      
      \\ If we're here,
      \\ we've begun refreshing static bit of screen (from &3000)
      \\ so...
      \\....The trick now is to restore normal conditions again. We have 23 more rows left in the PAL refresh to make up. So:
      
      
      \\(See P.359 of Advanced User Guide for explanation of CRTC registers)
      
      LDA #4 ;We set R4 to 22 to give us 23 rows.
      STA &FE00
      LDA #22 ; WAS 22 in mode 2
      STA &FE01
      
      LDA #6 ;We set R6 to 16 to ensure that we only plot 16 rows.
      STA &FE00
      LDA #10 ; was 16
      STA &FE01

      LDA #7 ;We set R7 such that VSync is generated at the same point relative to the end of the CRTC cycle as a normal MODE 2 refresh. As we remembered earlier (you remember?), we had 5 rows left following a VSync. So, if we set R7 to (23-5)=18, we get the VSync in the same place.
      STA &FE00
      LDA #18
      STA &FE01
      
      \\And that's pretty much it! The VSync generated then takes us back to the beginning of this loop, upon which we do the same thing all over again.
      

      LDA &FC  ; when an interrupt is generated, content  of A register
             ; is put in addr &FC. We therefore restore this value to A
             ; before exiting interrupt handler.
   RTI
.end

SAVE "VRUPT", start, end


Add the following lines to the runme program

Code: Select all

20MODE5
145 FOR A%=65 to 120 :?(&7c00+40+A%-65)=A%:N.


As I say this is very much an early proof of concept. start and end of memory need sorting etc.

Edit some improvements
Last edited by dp11 on Sat Sep 17, 2016 5:22 pm, edited 3 times in total.

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Sat Sep 17, 2016 4:43 pm

Capture.PNG

User avatar
simonm
Posts: 164
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby simonm » Sat Sep 17, 2016 4:53 pm

lurkio wrote:Shame it's probably too late for Rock-Race by BungeeBill to be entered!

Maybe it can get an honourable mention or something?

:?:

I'm thinking about adding some kind of blog to the site, so might be fun to have a section to detail a list of existing teletext based games (with Rock race mentioned of course). I personally remember the acornsoft invaders/breakout compilation quite fondly! I reckon theres plenty of opportunity for some cool Mode7 graphics based gaming.

In other news, I've added a page to our site for submitting competition entries. Just zip up your entry in SSD format, with a screenshot PNG and a readme.md file, send us a link to the zip and we'll grab it and post it up.

I just need to write some website code to show all the entries now!

User avatar
simonm
Posts: 164
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby simonm » Sat Sep 17, 2016 4:55 pm

^^ dp, that is awesome! I've never seen split mode 7 on a beeb before.

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Sat Sep 17, 2016 5:23 pm

Capture.PNG

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby Rich Talbot-Watkins » Sat Sep 17, 2016 6:17 pm

Has anyone ever considered a 41x25 Mode 7 screen, where the leftmost column contains the graphics control codes so that you have 80 proper blocky pixels across?

It'd be a 1025 byte screen, so there'd presumably be wraparound, but it just means the last character block would be a mirror of the first, in this case a 'blank' graphics control code (which could probably be designed around, e.g. a blank line for score and status). Don't know if it would actually work or not on real hardware, but I don't see why not.

@dp11: awesome work! I'm happy it works as expected on jsbeeb. The question is, what does real hardware do with this CRTC witchcraft?!

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Sat Sep 17, 2016 6:20 pm

I have done a wider and taller mode 7 in the past with memory swapping in IRQ half way down the screen.

dp11
Posts: 670
Joined: Sun Aug 12, 2012 8:47 pm

Re: Bitshifters - Ode to Mode 7 Competition

Postby dp11 » Sat Sep 17, 2016 6:24 pm

jsbeeb confused me as at one point I had the vsync pulse in the wrong place so the lower half of the screen never got written too. So jsbeeb just displayed what was previous in its display buffer even though the real beeb screen would be blank. This is such a corner case I wouldn't worry about it.

Is there a simple way to get out of jsbeeb what my refresh rate is ? as I know I have mucked that up .

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

Re: Bitshifters - Ode to Mode 7 Competition

Postby Rich Talbot-Watkins » Sat Sep 17, 2016 7:29 pm

It's on the to do list; it needs to blank the remainder of the screen both horizontally and vertically if the horizontal / vertical totals don't match the expected PAL sizes. Not really a biggy but just haven't got round to it. Matt will be able to tell you if there's a way to get the refresh rate out of it, as it certainly attempts to match the canvas update rate to the real emulated update, rather than fixing it at 50Hz regardless.

User avatar
lurkio
Posts: 1142
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Bitshifters - Ode to Mode 7 Competition

Postby lurkio » Sat Sep 17, 2016 7:44 pm

@dp11: very impressive!

Haven't a clue how it works, really, but as others have said, I don't think this has been done before -- or at least not widely publicised, hence my impressedness!

In simple terms, then, would this technique be a practical way to create the sort of split-screen mode that Dethmunk could have used for his graphical text adventure game? Does it save memory?


Return to “community projects”

Who is online

Users browsing this forum: No registered users and 2 guests