Unused Citadel bits

reminisce about classic bbc micro and acorn electron games here
Related forum: adventures


User avatar
scarybeasts
Posts: 608
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: Unused Citadel bits

Post by scarybeasts »

Diminished wrote:
Fri Oct 16, 2020 8:54 am
This is interesting.

From memory, it does something like reprogram the CRTC to limit the visible screen area to the first few lines (the ones that contain the header text and inventory sprites) while it invisibly redraws the room. Then it switches it back to full screen afterwards. I'm not sure why this might cause different behaviour on an LCD compared to a CRT -- any theories, anyone?
I'm pretty sure there's a race condition in the way it reprograms the CRTC. If you look at my "beebjit turbo collage" video here:
https://www.youtube.com/watch?v=Fr-IZAb5Gj8

Citadel is in the top left and you can see the top of the screen getting corrupted regularly. The framing of the corrupted screens looks pretty wild -- perhaps vsync is firing in the middle of the displayed data.


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

Re: Unused Citadel bits

Post by Rich Talbot-Watkins »

That's weird. From Diminished's disassembly, I only see it setting CRTC R6 (vertical displayed) to 2 while it redraws the screen - nothing there which would affect VSync, or have that kind of strange effect. It also plays with R5 (vertical adjust) during gameplay, to shake the screen when the player falls from a height, but I don't think that would be getting invoked during the attract mode.
User avatar
scarybeasts
Posts: 608
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: Unused Citadel bits

Post by scarybeasts »

Rich Talbot-Watkins wrote:
Sat Oct 17, 2020 7:13 am
That's weird. From Diminished's disassembly, I only see it setting CRTC R6 (vertical displayed) to 2 while it redraws the screen - nothing there which would affect VSync, or have that kind of strange effect. It also plays with R5 (vertical adjust) during gameplay, to shake the screen when the player falls from a height, but I don't think that would be getting invoked during the attract mode.
This is speculating wildly (i.e. I've been too lazy to trap the condition in the debugger).
But you'll get weirdness if the vertical counter is >2 and <R6 at the time R6 is set to 2. For the rest of that CRTC frame, display will remain enabled. When R7 (vsync) hits, display will still be on so you'd get rendering at the top of the CRT area.

For most transitions, there's no weirdness -- so perhaps an attempt is made to set R6 at a sane juncture, but some IRQ or other race condition knocks it out from time to time.


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

Re: Unused Citadel bits

Post by Rich Talbot-Watkins »

Hmm, true. I don't think there's any synchronisation with vsync at all, so it could indeed happen at any moment and result in the occasional frame without vertical display disable. Perhaps some monitors expect no signal during vsync, and won't sync if there is.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

Hmm... As well as the two explicit OSBYTEs (one before update_player and the other associated with firing the cannon), there is also the master_speed_wait function, which checks num_irqs_counter, a variable which I think is incremented on vsync?

The main game loop and the attract mode are distinct, too. The main loop explicitly syncs before update_player. The attract mode loop never does, but it does invoke master_speed_wait.

I'd guess the two game modes would cause corruption in different ways.

Eyeballing it, the main game process for a room change is like

- 42f8: P_main_main, top of loop
- 4394: explicit vsync wait before update_player
- entire frame's worth of logic happens; let's assume the player moves offscreen
- 43d5: master_speed_wait called, which waits for multiple frames based on num_irqs_counter, which I think is incremented on vsync? so sync happens here too?
- 43d8: animate_a is called
- 43e5: jump to P_main_main
- 42f8: P_main_main (again)
- 434a: room change detected at top of main loop, jump to before P_main_main, to P_main_roomchange
- 42ab: P_main_roomchange
- 42d3: calls super_draw_room
- 42f5: calls blit_player_anim to redraw player
- 42f8: falls back through to P_main_main (yet again)

The attract mode does

- 426d: { P_attract_inner, calls master_speed_wait, syncs here?
- 4270: calls animate_a
- 4281: keep jumping to P_attract_inner until room has expired }
- 4283: once room has expired, jump to P_attract_outer instead
- 424d: P_attract_outer
- 4266: calls super_draw_room

I dunno. Presumably animate_a takes a variable length of time depending on how much stuff there is in the room, and in both cases that seems to be the routine which splits master_speed_wait and super_draw_room.

The implication by j6wbs (or perhaps just my inference) was that the corruption seen was happening on every room change, though, rather than just periodically.
j6wbs
Posts: 14
Joined: Tue Feb 02, 2016 8:11 am
Contact:

Re: Unused Citadel bits

Post by j6wbs »

Hi,
Yes, it does seem to happen on every room change.

Thanks for looking so deeply into it, I imagine the issue is more to do with the HDMI scaling that the TV/MiSTer is doing or something similar, however in the interests of completeness I have posted a short video of the issue as a much better description than my words can ever be....
https://www.youtube.com/watch?v=Ygha48sWG7k
Filmed using a recent BBC Micro core on the MiSTer, using HDMI into flat panel TV.

As I mentioned, the CRT display from the MiSTer is rock solid on each room change, so I think it is probably scaler related.
Weird behaviour though...

Cheers

Jez (j6wbs)
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

j6wbs wrote:
Sat Oct 17, 2020 11:34 am
...
Oh, that's cool. Not what I expected!
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

  • stars fixed (stupid scoping mistake)
  • doors are done (command-line switches for locked, unlocked or open)
  • items can now be placed on item pads (fixed some bugs in branch B of the tile drawing routine; coded some hitherto unimplemented entrypoints which adjust the plot position based on the size of the item in order to align it to the pad)
  • pillars done (had to fix another stupid bug in reading MODE 2 style pixels from the new chunky collision buffer)
STALAGTITES AND STALAGMITES
Ropes, pillars and ladders are similar in certain ways, but ultimately different in others. All three are drawn procedurally to permit a variable length without bloating the room data.

Ropes and pillars don't have a length associated with them. They are placed at a coordinate and then just "grow" until they encounter some nonzero collision, whereupon they stop. A pillar's origin is at its top, and it grows downwards until it hits something. A rope's origin is at its base, and it grows upwards until it hits something. This behaviour makes sense, since you want ropes to be able to dangle in mid-air, but for them always to be attached to something at the top. So, you can't place a rope that isn't attached to anything!

Ladders are different; they seem to use an explicit length parameter. They grow upwards, like the ropes do. At first I wondered why they weren't made to grow downwards and stop on collision, since I believe all ladders in the game rest on a floor -- there aren't any "rope ladders" whose bottom rung is in mid-air. This would obviate the need for the length parameter. However, I'm guessing the idea is that you can use a ladder to automatically cut a hole through a wall you've already drawn, whereas a rope would just halt on the collision in this case. Hence, although a rope and a ladder work the same way from the player's point of view, they are not equivalent.



I've reached an interesting juncture with this code now. All of the static elements of the rooms are implemented and seem to draw correctly. This doesn't mean I have the room format completely implemented yet, because of course the room bytecode also defines all the various animations that are cycled during gameplay, which are dealt with by the subroutine I called animate. Implementing these doesn't seem to make much sense yet, since the code just spits out a single image file; there is no way to output multiple frames. It could be modified to do this, but there's not a lot of sense in it, since certain animations (e.g. the creatures which chase the player) are modulated by the player's current position.

There is a lot of cleanup work to be done, and I want to try to "decouple" as much of the code as I can. Data flows are performed through simulated zero-page variables used by the game itself, which was a deliberate choice to guarantee that the thing would work. Many of these are "foo/bar"-style variables which are used for different purposes depending on which routine is currently executing. I want to get rid of those, to rename everything logically, and to try to rework everything in a more functional style in which routines have well-defined input and output parameters, which was really the whole point of doing this in the first place. Fortunately this should now be easy, because I have a reference implementation, and so any change which breaks something will be trivial to detect.

The question is where to go with it after that. Originally I was thinking about doing an enhanced reimplementation for modern OSes in C. Now I am wondering if making something that runs in a browser instead might be a more interesting route, when you consider possibilities like level editing, or animated, real-time, pictorial demonstrations of how things are drawn.

Dunno!
6502
Posts: 41
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: Unused Citadel bits

Post by 6502 »

davidb wrote:
Fri Oct 09, 2020 3:29 pm
Now we know what the layout looks like, we can imagine where all those passages down the well could lead to. :)
Diminished wrote:
Fri Oct 09, 2020 5:12 pm
I would dearly have loved to have found an unreachable room somewhere. Of course, it would already have been found by hackers decades ago.
God knows how many hours I must of spent as a kid trying to find hidden rooms, that we now know was never there anyway.

Trying to raise the drawbridge to access the water underneath.
Trying to get over the mountains to find out what was on the other side.
Trying out if any other of the cannons fired the cannon ball.
That intriguing empty space on the right hand side of the well at room 133.
Those passages in the well just had to lead somewhere else surely.

No, none of these...
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

6502 wrote:
Mon Oct 26, 2020 1:08 pm
Trying to raise the drawbridge to access the water underneath.
Trying to get over the mountains to find out what was on the other side.
Trying out if any other of the cannons fired the cannon ball.
That intriguing empty space on the right hand side of the well at room 133.
Those passages in the well just had to lead somewhere else surely.
Yeah, I wondered for days on end about all of those things, too.

The other one was when I discovered that the 'C' symbol on the Central Tower battlements led to you a secret room with a crystal in it -- you couldn't help but wonder whether the same was true of all the other 'C' symbols scattered around the map.

That was part of the beauty of it, though, I suppose -- it gave you this feeling that you hadn't seen all of it, which made the game world seem bigger than it actually was.
6502
Posts: 41
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: Unused Citadel bits

Post by 6502 »

Diminished wrote:
Mon Dec 11, 2017 4:46 pm
There's a master table of room names in one page at 0x2400. This makes sense, since many room names are used several times (The Desert, The Well, The Pyramid, The Temple etc.), and the room data references these. However, rooms whose names are not in the master table have them inlined into the room data itself, immediately after the initial length byte. And this is also why the names are backwards -- since there are two possible sources for the room names, the game stages them on the stack before they're printed. And since stacks are LIFO, they have to be stored backwards.

Code: Select all

.global_room_names
  EQUB &00                                                     \ ??? 
  EQUB &a0                                                     \ <space>
  EQUB &e4,&69,&6d,&61,&72,&79,&50,&00                         \ The Pyramid
  EQUB &e5,&63,&61,&6c,&61,&50,&00                             \ The Palace
  EQUB &f2,&65,&77,&6f,&54,&20,&6c,&61,&72,&74,&6e,&65,&43     \ Central Tower
  EQUB &f2,&65,&77,&6f,&54,&20,&74,&73,&65,&57                 \ West Tower
  EQUB &f2,&65,&77,&6f,&54,&20,&74,&73,&61,&45                 \ East Tower
  EQUB &e5,&6c,&74,&73,&61,&43,&20,&66,&6f,&20,&70,&6f,&54     \ Top of Castle
  EQUB &e7,&6e,&69,&57,&20,&74,&73,&65,&57                     \ West Wing
  EQUB &ee,&65,&68,&63,&74,&69,&4b,&00                         \ The Kitchen
  EQUB &e5,&7a,&61,&4d,&20,&6e,&72,&6f,&68,&54                 \ Thorn Maze
  EQUB &e7,&6e,&69,&57,&20,&74,&73,&61,&45                     \ East Wing
  EQUB &f4,&72,&65,&73,&65,&44,&00                             \ The Desert
  EQUB &e5,&67,&6e,&65,&68,&65,&6e,&6f,&74,&53                 \ Stonehedge
  EQUB &e4,&6e,&61,&6c,&65,&74,&73,&61,&57,&00                 \ The Wasteland
  EQUB &e5,&73,&75,&6f,&48,&20,&73,&27,&68,&63,&74,&69,&57     \ Witch's House
  EQUB &d2,&65,&5a,&65,&45,&72,&46                             \ FrEeZeR
  EQUB &e5,&6c,&74,&73,&61,&43,&20,&6c,&61,&72,&74,&6e,&65,&43 \ Central Castle
  EQUB &ec,&65,&65,&68,&57,&20,&6c,&6c,&65,&57,&00             \ The Well Wheel
  EQUB &e4,&6e,&61,&6c,&73,&49,&00                             \ The Island
  EQUB &ec,&6c,&61,&48,&20,&6e,&69,&61,&4d                     \ Main Hall
  EQUB &ec,&6c,&65,&57,&00                                     \ The Well
  EQUB &ee,&6f,&73,&69,&72,&50,&00                             \ The Prison
  EQUB &e8,&63,&61,&65,&42,&20,&65,&68,&54,&20,&6e,&4f         \ On The Beach
  EQUB &ee,&61,&65,&63,&4f,&00                                 \ The Ocean
  EQUB &f2,&61,&6c,&6c,&65,&43,&00                             \ The Cellar
  EQUB &f4,&72,&6f,&50,&20,&72,&61,&74,&53                     \ Star Port
  EQUB &ee,&69,&61,&72,&44,&00                                 \ The drain
  EQUB &e2,&61,&6c,&00                                         \ The lab
  EQUB &e5,&6c,&70,&6d,&65,&54,&00                             \ The temple
  EQUB &65,&68,&54,&00,&00,&00                                 \ <junk bytes>
  
  
Have been looking at the room names in the master lookup table at &2400.

It appears to me that first &00 byte does nothing, it's just skipped over, unless it corrects some 1 off error in the loop.
There's junk bytes at the end that spell "The" backwards. Perhaps this is an artifact left over before Michael decided to optimise the "The" part separately.
Strange that a few weren't used as inline names instead of here. "Main Hall", "The Prison" and "The drain" are only used in one room each.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

EDIT: deleted my previous post on this, since I looked at it again, and I was talking nonsense.

Here's the relevant code:

Code: Select all

3489:                     ldy #$ff                          
                          ; find pointer to the room name of the Xth room in master table; count the terminators
348b: P_find_room_name    iny
348c:                     lda GLOBAL_ROOM_NAMES,y
348f:                     bpl P_find_room_name
3491:                     dex
3492:                     bpl P_find_room_name
                          
3494: P_push_room_name    pha
3495:                     inx
3496:                     iny
3497:                     lda GLOBAL_ROOM_NAMES,y
                          ; again, if the following byte is zero, end with a The
349a:                     bmi Lroomname_push_done
349c:                     bne P_push_room_name
As for the names that are only used once, it's likely that due to limitations of the linking process, MJ intended to reserve exactly one page of RAM for the main room table. He probably just filled up the spare space with names that were only used once, until the page was full.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

I actually have no idea why that zero byte is there at the start of the room table. Got myself very confused over it. I was convinced it was somehow necessary to make things work, but I don't think it is.

I'm getting reasonably close to a point where I can share a preliminary version of the PHP script I've been using. I went down a bit of a rabbit hole with the teleporter and Star Port dish rooms, since it turns out that the human planet and alien planet versions of these are slightly different, and those differences are actually implemented through hard coded routines in the assembly. They seem to be working now.
6502
Posts: 41
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: Unused Citadel bits

Post by 6502 »

Diminished wrote:
Sun Nov 08, 2020 1:26 am
I actually have no idea why that zero byte is there at the start of the room table. Got myself very confused over it. I was convinced it was somehow necessary to make things work, but I don't think it is.
I tested it out, I just simply shifted the ".global_room_names" label down one line skipping that zero byte and the game runs fine.
Just some left over unused byte I guess. In fact, the more I look around the code, there's quite a few wasted bytes hanging around.
Of course it's easy to forget I'm viewing it on a 24" monitor, fast assembling, multiple tabs, mouse wheel scrolling etc.. which MJ didn't have the luxury of.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

Credit where it's due: This post in another thread reveals that an alternative (and more thorough) disassembly of Citadel may be found here.

It looks (from Wayback) like it was uploaded sometime in the first half of 2019, so I guess it wasn't available when I originally started looking at this.

Which is, in some ways, a relief. :lol:
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

Against my better judgement, I went in to refactor some stuff, and broke absolutely everything.

But the results are fun.
208.png
208.png (3.87 KiB) Viewed 1092 times
6502
Posts: 41
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: Unused Citadel bits

Post by 6502 »

Diminished wrote:
Mon Nov 09, 2020 11:36 am
Credit where it's due: This post in another thread reveals that an alternative (and more thorough) disassembly of Citadel may be found here.

It looks (from Wayback) like it was uploaded sometime in the first half of 2019, so I guess it wasn't available when I originally started looking at this.

Which is, in some ways, a relief. :lol:
Nope, never seen that.
Looks like Palace of Magic has been documented as well. I'll take a look.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

From Acorn: A World in Pixels:
jakobsen.jpg
I think we need to try to make this happen, don't we?

I have zero social media presence by design. I don't know whether anyone else has a way of reaching Mike Jakobsen, or maybe it could be done via the people who published the book?
6502
Posts: 41
Joined: Sat Mar 17, 2018 1:04 pm
Location: London
Contact:

Re: Unused Citadel bits

Post by 6502 »

Diminished wrote:
Fri Dec 25, 2020 6:17 am
From Acorn: A World in Pixels:

jakobsen.jpg

I think we need to try to make this happen, don't we?

I have zero social media presence by design. I don't know whether anyone else has a way of reaching Mike Jakobsen, or maybe it could be done via the people who published the book?
Let me guess..

You got the book as a present Christmas day.
You had a flick through, but too busy to read it properly yesterday.
But found time to look at the Citadel section.
Saw that paragraph and thought "ah ha, that sounds interesting..."
Took a photo of it on your phone and posted it on here, hoping to get the ball rolling on it.

Exactly the same thing I did yesterday.
Except you beat me on the photo part. =D>

By the way, I've no way of reading old disks, or contacting Michael, so I won't be much help.
markoceans
Posts: 19
Joined: Thu Jan 02, 2020 10:06 pm
Contact:

Re: Unused Citadel bits

Post by markoceans »

Here's a picture of Michael Jakobsen taken today ....

https://twitter.com/idesine/status/1343 ... 24416?s=20

If someone who has decent disk reading kit would like to DM me, happy to see if Michael can be persuaded to send you his source disc(s).

Mark
dave_stacey
Posts: 2
Joined: Sun Nov 03, 2019 10:22 pm
Contact:

Re: Unused Citadel bits

Post by dave_stacey »

markoceans wrote:
Sun Dec 27, 2020 10:13 am
If someone who has decent disk reading kit would like to DM me, happy to see if Michael can be persuaded to send you his source disc(s).
I can't send you a DM - maybe I'm too new here. I have a Kryoflux that I'm using to read my old Beeb discs. I'm not sure I'd want the responsibility of handling the original Citadel source discs though!

Dave.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

I did cross-post about this in the archives section, in the hope that someone who has experience dealing with vintage discs in unknown condition might volunteer for the job. I know there are people here who have done this before.

I would love to do it myself, but I can't be trusted not to screw it up. Were it not for this stupid pandemic, I might even have been prepared to go and collect the discs personally, since it is sadly a matter of record that Matthew Atkinson's Repton 3 original sources were somehow eaten by the postal system, and are presumably lost forever. :x
User avatar
archie456
Posts: 60
Joined: Sat Sep 07, 2019 4:22 pm
Location: Chelmsford
Contact:

Re: Unused Citadel bits

Post by archie456 »

Its interesting to play Crypt Capers - a game by the same author:

http://bbcmicro.co.uk//jsbeeb/play.php? ... ssd&noseek

It looks very much like Citadel was Crypt Capers 2 - many of the sprites look very similar...
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: Unused Citadel bits

Post by Diminished »

archie456 wrote:
Wed Dec 30, 2020 10:01 pm
Its interesting to play Crypt Capers - a game by the same author:

http://bbcmicro.co.uk//jsbeeb/play.php? ... ssd&noseek

It looks very much like Citadel was Crypt Capers 2 - many of the sprites look very similar...
I played this a little bit in the past. It is interesting.

On the long list of "interesting things to do that I'll probably never be sufficiently motivated to tackle" would be disassembling this game and examining the sprite routines to compare them to Citadel's.

If we're lucky, though, we might just get handed the code to this game, too.
markoceans
Posts: 19
Joined: Thu Jan 02, 2020 10:06 pm
Contact:

Re: Unused Citadel bits

Post by markoceans »

Hi, I am still looking for someone from the Acorn community to help with this disk extraction project for the Citadel source code. If anyone has any recommendations, please do get in touch via DM. I think this is a pretty unique opportunity!

Thanks.
User avatar
Arcadian
Site Admin
Posts: 3800
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Unused Citadel bits

Post by Arcadian »

markoceans wrote:
Sun Jan 03, 2021 9:57 pm
Hi, I am still looking for someone from the Acorn community to help with this disk extraction project for the Citadel source code. If anyone has any recommendations, please do get in touch via DM. I think this is a pretty unique opportunity!

Thanks.
Do you know roughly how many discs there are altogether? Are we talking 5, 15, 50, 100?
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk
Post Reply

Return to “8-bit acorn software: classic games”