A new Warlords emulator for the beeb (was Writing a ...)

[tricky]

I've been thinking about a Warlords emulator for the beeb.
Warlords uses the same (or very similar) hardware to Centipede and a few other games and not too different to Sprint and the Exidy games that I have already written beeb emulators for.
For the software developer, the machine looks like a 256x224 240 pixel 32x28 30 character display, where each character is one of 64 that can be flipped or mirrored. There is a second set of 64 8x8 pixel tiles that can be used as one of the 16 sprites, again each can be flipped or mirrored.

These are the characters (top) and tiles (bottom) that Warlords has.
The hardware also supports a palette for each sprite and some sort of attribute map for the characters.
The sound is handled by a POKEY, which is quite a flexible 4 channel sound chip which also handles ADC (8 channels), timers and a keyboard matrix.
With routines to flip the sprites and flip and mirror the tiles, 10kB 12kB (11 sprites and 1 tiles) is needed for the gfx data, 12kB 13kB if I skip the flipping code for tiles (can't really skip the sprite flip code as that would add 8kB 22kB+tiles).
So the memory budget looks like:

Code: Select all

 1kB Warlords RAM
 1kB Warlords character map + sprite info (X, Y, tile etc)
15kB emulator display
 1kB emulator copies of character map + sprite info (X, Y, tile etc) 
? kB emulator code
12kB Warlords game ROM
12kB expanded sprites and tiles
~4kB unrolled code to draw the sprites and tiles

So it looks like one bank of sideways RAM will be needed.
The game also has 8 sound effects:

Code: Select all

soft boom : bat hit fire ball / start game timer
lazer boom: fireball hit edge of screen / wall
soft boom : fireball hit edge of screen
explosion : player died*
fanfair   : game over
laser shot: shoot fire ball*
chink boom: ball hit crenelation*
zip boom  : fireball hit crenelation
*all started together

Since it looks like all the POKEY channels can make "noise", and most of the effects use "noise", I will have to swap some out, so I will probably write beeb replacements for them instead of simulating the POKEY.
The final thing is that Warlords is a four player game, with each player having a "paddle" and "fire" button.
After chatting with flynnjs, it looks like there is a fairly simple and cheap way to allow four fire buttons and after checking the wiring on Atari VCS/2600 paddles, it looks like they can be modified very simply to work on the beeb (unfortunately, not the joysticks though).

PS There is also the problem that six colours are used per scan line, the fireball itself is red, yellow, white/cyan and a black background.

[FourthStone]

Looks interesting Tricky, are you planning on doing a beeb version or a whole emulated system? Not sure what you meant by 'Warlords emulator for the beeb'

Keep posting updates, love getting insight into your development process.

[tricky]

I am planning on doing a similar thing to my emulators for circus, ripcord and sprint.

The original arcade ROMs are loaded into the beeb along with some code to pretend to be whatever hardware the original arcade cabinet other than the 6502 (input, sound, sprites, LEDs etc).

I then load a simple basic programme to patch the original ROMs to divert the code or point it to different addresses so that it thinks it is still running on the original hardware.

And hey presto, after some "tricky" bits of disassembly and coding you have a complete game with all the boring bits done for you

A bit like a single game version of MAME.

[FourthStone]

...

[tricky]

I've been doing a few timing calculations and it looks like 16 8x8 pixel mode 1 sprites is about the limit for the routines I have lying around.
The character routines are pretty much straight out of my other "emulators" and are fine as long as not too much is changing per frame (player dies!).
I haven't checked if Warlords uses hardware collision detection (most games never bothered) but if it does it might be tricky (in a bad way).
From looking at the code not all of the sprites are used all of the time and when they are, they are not all moving (I will only draw them when they move).
If everything is moving, there is less than 2ms left for emulation and the game, so I am hoping Warlords doesn't use much CPU!

[tricky]

OK, I got some time last weekend to start disassembling the ROMs and trying to workout how the game works. Since I got the characters and sprites decoding correctly this morning, I thought I would put up this "first look" video.

MAME is a great resource for doing this type of thing, as you can look at the "driver" to workout where the hardware is memory mapped (dip switches, controls, sprites and screen etc) and also where the ROMs are mapped and it also allows you to save a decoded version of the ROMs if the originals were encrypted in some way (mine are packed in a box somewhere so I haven't checked).

I usually start disassembling with the NMI and IRQ vectors as this gives two addresses where code definitely starts (usually!). When I get stuck or think I am getting somewhere, I move back to the debugger in MAME and try to work out what the game does and how the hardware is accessed. What I am really looking for is somewhere that I can put my code to update the display etc at a point where the game would usually wait for VSYNC.

I still have lots of work to do, but I have the character mapped display and sprites working as well as some of the inputs.
The memory mapped hardware is usually in inconvenient places and has to be patched to new addresses:

Code: Select all

; memory map
;
;    0.. 3ff game ram - &200..&3FF don't seem to be referenced
;  400.. 7bf game screen
;  7c0.. 7ff game sprite control
;  800.. bff emulator copy of screen and sprite attributes
;  c00.. cff SPARE
;  d00.. dff RTI (for NMI) and remapped hardware
;  e00.. fff sound data
; 1000..11ff SPARE - may be needed for screen or sound
; 1200..4fff emulator display
; 5000..7fff game ROM
; 8000..8eff emulator sprite and tile drawing code
; 8f00..8fff mirror table
; 9000..bfff expanded sprite and tile data

with code like:

Code: Select all

   94 REM DATA &28  , &56A4 : REM audio_index
   95 REM DATA &29          : REM audio_index
   96 REM DATA &2A          : REM audio_index
   97 REM DATA &2B  , &7547 : REM audio_index (check if still playing: 7547)
   99 DATA &FC  , &513E, &520D, &5211, 0 : was_at_FC
  100 PROCpatch8(F%, 1)
  105 DATA &07F0, &7ECC, &7F1E, &7F2E, &7F40, 0 : REM PotChange (ASL/LSR ROM)
  106 PROCpatch16(T%, 1)
  110 DATA &1000, &56A6, &7CDA, &7F17 : REM st POKEY_BASE_W_AUDF1
  130 DATA        &7CDF, &7CE7, &7F0F : REM st POKEY_W_AUDC1
  140 DATA        &56AE               : REM st POKEY_W_AUDCTL
  150 DATA        &7ED2               : REM st POKEY_W_POTGO (start ADCs)
  160 DATA        &5670, &569D, 0     : REM st POKEY_W_SKCTL
  170 PROCpatch16(Z%, 16)
  180 DATA &1000, &7EB4, 0 : REM ld POKEY_BASE_W_AUDF1 (first 4 pots)
  200 PROCpatch16(K%, 4)

I simulate the 32x30 character mapped display by having my own copy and each frame checking if anything has changed and updating my copy and the screen. It should be possible to patch the code to directly draw the characters, but my method is much less work, although much more CPU (not like me I know).

The sprite attributes are stored in the remaining 64 bytes of screen memory: 16 sprites, each with X, Y, bitmap (inc flipped and mirrored bits - same as character screen) and a fourth set of attributes for palette and maybe collision (I haven't got that far yet). I do a similar thing to the characters, keep a copy and then update any sprites that have changed.


URL:https://youtu.be/xZWz13gyGH8
Watch in 720p to get 50Hz from youtube.

[Arcadian]

[marcusjambler]

Just had a quick play with single player on MAME
Looks like a good game

[tricky]

[tricky]

I didn't get any more time on it yesterday, but after watching Avengers Assemble and listening to the Broken Token Podcast for a while this morning, I worked out why things weren't going quite right!
It turns out that the POKEY random returns 0xFF for a while at the start and maybe later and without this the game doesn't work, so more work to do on the POKEY simulation.
If it just returns &FF the game seems mostly OK, see attached video. If it just returns various numbers or psudo random numbers then you get no shields, no score, the fireball sticks to the shields and a number of other strange effects!

URL:https://youtu.be/cMpAMyAsfcQ
Watch in 720p to get 50Hz from youtube.

[oss003]

Great job Tricky, looks nice already ...
Did you reduce the number of colours by switching mode or isn't palette swapping installed?

Greetings
Kees

[tricky]

I haven't added any pallet swapping yet, I was thinking about how it could work.
Top/bottom would work, but I think to get it working left/right, will need "some nasty effects".

[tricky]

I have added some sound effect, still a couple to sort out and the fanfare/tune to add.
Getting the paddles wired up correctly might be good too as I think the buttons and ADC channels aren't in the same order as the beeb.
The stuttering isn't in the game, but either the recording or youtube conversion.
I know how bad I am at sound effects, I might end up having to write some kind of POKEY to beeb converter, but that would be quite a bit of work.
Next I think I should try it on a real beeb, as currently it has all been emulation and then I need to work out how to distribute it.
I'm very conscious of not getting stardot or its members in any trouble, so I may publish the emulator without the Warlords ROMs and let those people who own them add them to their own disc.

URL:https://youtu.be/KuuLwZ1aM74
Watch in 720p to get 50Hz from youtube.[/quote]

[Dave Footitt]

Fantastic work fella, looking really good!

[tricky]

I spent a couple of hours trying to get it to work on a real been before I realised that I was checking the wrong address for how many sideways banks has been found and then realising that the beeb which I had got it to "fix" didn't have any sideways ram!
I've been in too much back pain to do any more this week, but tonight I added some sideways ram and it worked first time (a testament to the quality of the emulators). Unfortunately the beeb was in a bit of a sorry state and although the fire buttons work, the a2d does not - pictures to follow.

[tricky]

Here is the pretty much finished Warlords emulator for the BBC Micro, I still need to check 4 paddle and fire button support (but I haven't finished building it yet) and check that there is no flicker when the game is at its busiest.
I ended up writing a program to convert the POKEY sound to beeb sound and it isn't 100%, but I think it fits. The sound is in a separate file, so it could be replaced by anyone who really wants to.
I now have the same problem that I had with my Sprint emulator, that is that I don't want to ship the arcade ROMs as I haven't got permission from Atari!
I feel OK shipping the rest and letting anyone with a legit copy of the ROMs add them to the disk.
Sorry the sound goes out of sync, but I think that is a know issue recording with beebem with interlace off. There are also a couple of hick-ups in the recording, they are my PC playing up!

URL:https://youtu.be/yCnRqDsB8p4
Watch in 720p to get 50Hz from youtube.

[kieranhj]

Great job Tricky! Nice & fast & smooth. I'm not familiar with the original game but it looks fun. Asteroids next?

[tricky]

Thanks, It's on the list, but maybe one more sprite game first - especially if I can find one with distributable ROMs.

[tricky]

I've also been working on an adapter board to support two pairs of Atari paddles and their four fire buttons (Thanks to flynnjs for the idea).
My prototype will break out the joystick port in to two beeb compatible ports and two (sort of) Atari compatible ports.

The Atari paddles don't work quite out of the box, but they are fairly easily modified and then only require a 9 to 15 pin converter.
There is a black wire which connects to the fire button, I connect a second wire to this (white here) and then connect that to the spare terminal on the potentiometer. I think I have them backwards in the picture and will have to swap the white and yellow wires over.
I have seen Atari paddles with the yellow on either end and in one case, soldered across two terminals with the signal (red or purple) on the other end. My plan is to add a small dip-switch inline with the extra wire, so that it can be switched between Atari and beeb mode (no other changes necessary).

The beeb ports on the box will allow single joysticks to be connected, where each can have either one fire button or two. The extra software required to support the extra buttons is tiny and so, should easily be added to an existing utility ROM or tucked into RAM.
I will add a switch so that either joy0 has fire 0 and 1 with joy1 having fire 2 and 3 or joy0 has fire 0 and 2 with joy1 having fire 1 and 3. This second option probably isn't necessary, but allows two single button sticks to be used as if they were a pair.

The extra fire buttons do require an extra couple of chips, but these are very basic/cheap and there are already several used in a beeb.
I was planning on making up some PCBs as more compact versions of the prototype box, but now I am wondering who other than myself and maybe Arcadian might want such a thing!

NB These adapters will NOT work with Atari joysticks.

[tricky]

And if anyone fancies a little intellectual exercise, I was wondering if it was possible to create an atari joystick to beeb converter with only resistors.
On the analogue port you have 0v, 1.8v (analogue VREF IIRC) and 5v, if that is correct and games do what I do and use the top two bits of an ADC conversion to choose left/centre/centre/right, you need a way to connect common and each direction which only short to common to make a voltage below 0.45v when one direction is pressed and over 1.35v when the opposite is pressed and around 0.9v the rest of the time (in case the deadzone is small).
The resistors values listed might have to be scaled a bit, but I'm no expert .
The diagram is from http://www.tinkercad.com which I think is from the same people as autocad.

[dp11]

you would find the circuit much simpler if you make the top two bits as follows

11 : nothing pressed
10 : nothing pressed
01 : Left
00 : Right

So by testing top bit you know if a button is pressed . The next bit describes which button is pressed .

This now needs just two resistors
R1 =10K ( VREF to ADC channel )
R2 = 6.8K (ADC channel to R2 then to left button, left button to ground)
ADC channel to right button, right button to ground

[dp11]

actually you can do want you want with two resistors too.

R1 = 10K Vref to adc channel
R2 = 10K adc channel to ground

joystick common to adc channel .

left button to vref
right button to ground.

[tricky]

You can't do that as there is one common for the four switches for the two directions. The recoding is a nice idea, but the aim is to be compatible with existing software, like the two resistor design of you have two commons.

[dp11]

In Idea 1 the common is to ground.

In idea 2 the common is to the ADC channel so a you can't use Up and without extra resistors, but as you only need left and right it shouldn't be a problem. Common to the ADC channel shouldn't causes any issues.

[tricky]

I have wired up my prototype, but haven't checked the wiring yet!
I think it would have been quicker to just order some PCBs.

[tricky]

This is the sort of project that I would have expected to see in beebug BITD and as all the bits were cheap and readily available back in the late 70s, it is a beeb friendly project.

The idea of this breakout box is to allow two pairs of Atari paddles (NOT joysticks) to be connected and have access to all four fire buttons for four player Warlords. This require the use of a trick suggested by flynnjs, which I will put up with code once I have checked what tweaks I made to the wiring when I finally checked it.

The reasons that I added the two BBC sockets were to allow two single fire button joysticks to be plugged in together and appear to existing software as a single joystick pair. Another reason for the BBC sockets is to allow two joysticks, each with two fire buttons to be connected and allow all four fire buttons to be read individually. The final reason is to allow two pairs of BBC paddles to be connected for four player Warlords.

* The white wires are what I had to add to make the paddles BBC compatible and connect to the black wires that connect to the fire buttons. I am planning to add DIP switches to "break" this wire to make them back to Atari compatible. I also had to swap the yellow, purple and red wires around to make the POTs "rotate" the same way as the BBC ones, but these should be fine for Atari use. I believe that the C64 paddles are identical except that they use 10k ohm instead of 1M ohm POTs, but I don't have one to try.

** The switch is needed to allow the first joystick's second fire button to be swapped with the first fire button of the second joystick.

It should be very easy to make simple adapters for BBC to a pair of Atari paddles that aren't much more than a couple of connectors back to back.

Would anyone be interested in a small PCB with the two Atari paddle sockets fitted and the beeb ones/switch optional?
Is there any interest in an adapter to plug a single pair of Atari paddles into the ADC port?

[Arcadian]

If you'd be willing to build two full interfaces (in cases etc) then I'd like to order two please!

P.S. Shocked at the seeming lack of interest in these! Can only assume that most Stardotters have never experienced the magic that is four-player Warlords!

[tricky]

Doing the wires version takes a very long time, but I will try and get a small batch of PCBs ordered once I have got home and checked the design.
Would dual Atari paddle only be OK, or at least paddle only?
I was planning on making them so that they are flush with the back of the beeb and the Atari plugs lie on top on the beeb side by side.
I don't know if this would fit between a beeb and its monitor or dual floppy stand or even if the master is the same distance from the top to the ADC connector. Maybe one that has the paddle plugs under the back of the beeb might be better.
I will do some more investigation when I get home, but will make up a few 2 paddle Atari adapters as they shouldn't take long.

If anyone has any comments or suggestions, I would be very happy to consider them as I want these to be as useful as possible.

[dp11]

What is the NAND gate doing ?

[tricky]

The nand gates are to allow the light pen strobe (thanks Flynnjs) to be used to select between two sets of fire buttons so that a total of four fire buttons can be supported to go with the four paddles.
There is probably an easier way of simulating a dual gang two way switch controlled by CB2 (iirc), but it was the first thing that came to mind and I like the fact that it is from the appropriate time.