Weeknight 'Virtual' Dev session #15, Thursday 8th April 2021, 7pm - 10pm (GMT)

[Arcadian]

As the new games and demo coding sections of the forum are currently very active, we are now hosting weeknight "Dev sessions" on Zoom, that are primarily focused on the development of new games and graphics/music demos for Acorn computers as well as development tools, emulators and debuggers.

They take place the week in-between the 2 x Tuesday night 'general' sessions on the Thursday evening, between 7pm and 10pm.

The sessions are intended for developers to share progress updates and request/offer help and feedback. We hope that these sessions will help motivate and encourage developers to see projects through to completion.

Just to be clear - these sessions are open to everyone: programmers, graphics artists and musicians, even if you've just got an interest/appreciation of - or ideas for - new games and demos, please come along for moral support - there may be opportunities to beta-test new versions of upcoming projects . There really isn't a limit to the number of places available - well, the maximum we can host in a Zoom meeting is 100 but it's unlikely we'll ever get anywhere near that figure!

If there are any issues you'd like help with - or would like to demonstrate something - please leave details in the thread and we'll add them to the lists of items to be covered.

If you are new to Zoom, forum member JudgeBeeb has written a handy guide to getting set up and logged in.

I've already sent invites out to most of the Dev Night regulars, but should anybody else want to attend - or if you haven't received the Zoom logins - please post in this thread and I will issue a calendar invite email that contains the logins.

Note: by requesting a place at this event, you consent to receiving the Zoom logins in the form of a calendar invite sent via the ABug Google account to the email address you have associated with your Stardot account. If you have a different email address associated with your calendar (e.g. a Gmail account) please PM me to let me know the email address you'd like us to use. Alternately, we can issue you with the Zoom logins via PM if absolutely necessary, though this is non-preferred as it does add to the admin process.


Attended

biged
tricky (richard)
robc
kecske bak (dave jeffrey)
chrissawer
dp11 (dominic p)
pernod
leonardo vettori
dudleysoft71 (james w)
chrisn
oss03 (kees)
spaceflightorange (James)
androidC (Andrew C)
dominic (dominic b)
elk1984 (trevor)
cardboardguru (steve)
arcadian present in spirit

[tricky]

Last night, I was asked if I could have done the R-Type demo five years ago, and I said yes.

Well, I knew all of the techniquest except how to have a stationary score panel back in the mid 80s.

What I didn't have back then was plenty of experience using them, not the debugging capability to debug them when they broke!
Creating a "large" game back then was very hard work!

Before I got a floppy drive, it was spend 5 minutes loading a BASIC program, change a few lines of assembler, wait five minutes saving it, run it. After it crashed, spend five minutes loading it again and stair at the code for an hour - maybe print out the section to paw over some more.

Now, I set the emulator to break on undocumented op codes and maybe set some data breakpoints to stop if various area are written and when it goes wrong, dump the last 1/4 million instructions, register values etc and look where things went wrong.

I also have a mechanism for setting addresses as uninitialised and break if any address is read before being written - usually catches self modding code gone wrong!

I had lots of time and practically no debugging facilities back then; now I have lots of debugging features and no time

[BigEd]

Thanks Tricky, I love these development stories.

[Arcadian]

So, this is tonight - who would like to chat a little about their projects?

Anyone after a bit of advice with their coding or development?

[chrisn]

I'd like to ask some advice on converting VGM music to play on the Beeb.

[dudleysoft71]

I've got a follow up from my project from last time, I wont need a lot of time, just want to show progress.

[cardboardguru]

There was a point in the discussion last night when I said I didn't understand what was being talked about. I can't remember if it was during the chat about DOOM or the one where we were setting the screen start address to zero to see blinkenlights. But I think there was something about setting "linear addressing".

I found this snippet with Google. Is this what it was about? Setting a 2Kb buffer for Mode 7?

MODE 7
The 6845 is programmed with a start address between 0x2000 and 0x23FF to display data from 0x3C00 to 0x3FFF or with a start address between 0x2800 and 0x2BFF to display data from 0x7C00 to 0x7FFF. These address always have the top bit set.

Real memory address = (MA & 0x800) << 3 | 0x3C00 | (MA & 0x3FF)

This handles wrapping at 1K by ignoring the 0x400 bit. The scan line number RA is ignored so the same memory addresses are repeated for every scan line in a character row.

If the 6845 is programmed with a start address of 0x2400 it accesses memory from 0x3C00 to 0x3FFF then 0x7C00 to 0x7FFF giving a 2K linear buffer.

http://beebwiki.mdfs.net/Address_translation

[BigEd]

Thanks for the reference. I think this was in the discussion where we noted we can point the CRTC at low memory, and see things going on in zero page and on the stack, and yet when we're in Mode 7 and we do that, it looks like JSBeeb is doing something odd. We couldn't quite see how the SAA5050 could do that. Although maybe it can.

See for example this program, compared to this one.

[BigEd]

BTW thanks everyone for a good session yesterday: we had about 16 people there, and a fairly wide-ranging discussion including two or three project-specific bits.

I hope everyone was happy with the way it worked and was able to chip in if they had something to say (even though not everyone did speak, which is fine.)

I also hope the meeting didn't get auto-closed at the point I ran out of steam and had to make my exit.

[RobC]

Thinking about it last night, I remembered that I'd come across a discussion of the linear addressing stuff before: http://modelb.bbcmicro.com/tech-chunky.html

There's a discussion around it on the BBC Micro Mailing list: http://lists.cloud9.co.uk/pipermail/bbc ... 12012.html

From a quick re-read, I think this misses the bit tricky mentioned that you can wrap around on a B to get a 2KB linear buffer (or use shadow RAM on a Master as suggested).

[tricky]

There was a point in the discussion last night when I said I didn't understand what was being talked about. I can't remember if it was during the chat about DOOM or the one where we were setting the screen start address to zero to see blinkenlights. But I think there was something about setting "linear addressing".

I found this snippet with Google. Is this what it was about? Setting a 2Kb buffer for Mode 7?

MODE 7
The 6845 is programmed with a start address between 0x2000 and 0x23FF to display data from 0x3C00 to 0x3FFF or with a start address between 0x2800 and 0x2BFF to display data from 0x7C00 to 0x7FFF. These address always have the top bit set.

Real memory address = (MA & 0x800) << 3 | 0x3C00 | (MA & 0x3FF)

This handles wrapping at 1K by ignoring the 0x400 bit. The scan line number RA is ignored so the same memory addresses are repeated for every scan line in a character row.

If the 6845 is programmed with a start address of 0x2400 it accesses memory from 0x3C00 to 0x3FFF then 0x7C00 to 0x7FFF giving a 2K linear buffer.

http://beebwiki.mdfs.net/Address_translation

I know I have posted this at least twice around here somewhere, so this is copied from the bbc mailing list:
On the model B, setting R12R13 in mode 7:
Code:
&2000..&23FF displays &3C00+R12R13 wrapping after &3FFF to &3C00
&2400..&27FF displays &3C00+R12R13 wrapping after &3FFF to &7C00
&2800..&23FF displays &7C00+R12R13 wrapping after &7FFF to &7C00
&2B00..&23FF displays &7C00+R12R13 wrapping after &7FFF to &3C00
This does not work on beebem, b-em, jsbeeb or a master.

Tricky.

I think this is now supported in the emulators, but I haven't checked.
For the Master and Compact, you would need to use &7C00..&7FFF twice with an interrupt half way down the screen to toggle shadow ram to get 2K linear memory on screen.

[cardboardguru]

to get 2K linear memory on screen.

But for what purpose? Is this so you can increase the number of rows and columns in Mode 7?

[RobC]

But for what purpose? Is this so you can increase the number of rows and columns in Mode 7?

I think the idea is to use a graphics mode rather than mode 7 so the bigger the buffer, the more pixels you can get on screen.

[tricky]

Because when you set the 6845 up like this, instead of using addresses:
0, 8, 16, 24,...
1, 9, 17, 25,...
...
7, 15, 23, 31,...
it uses:
0, 8, 16, 24,...
0, 8, 16, 24,...
...
0, 8, 16, 24,...
Which combined with say only showing the first four scan lines of a character row means that you can have 4 scan line high pixels.
Combine this with MODE 8, a made up mode like MODE 2 but stretched horizontally to double width, that is each pixel is 4 MODE 1 pixels wide.
You get pixels that are 4x4 MODE 1 pixels in 16 colours, which is 64x64 - similar to MODE 7 graphics, but each pixel can be any colour.
I think that someone (who isn't me) could do a great fighting game with massive sprites

You could do full colour versions of Arcade Action or something more demo like, like Colour Space.
My idea was to use it or some variant to display a chess board, so there could be as much memory as possible for the chess game.

[cardboardguru]

Got you! Interesting concept!