Melkhior’s Mansion – Project Update #19

Welcome to project update #19 for the conversion of Melkhior’s Mansion Spectrum Next!

Continuing March’s ‘good news, bad news’ theme – Don’t panic! it’s not all doom and gloom.

So Death came calling on Friday evening for my main PC’s monitor. The evil entity only wanted one capacitor but that was enough to grind the project to a halt! We’ll get revenge as you can kill him in the game!

I was lucky it didn’t fry the video card as the displays had snow and my Kenwood amp was crackling. It smelt bad too!

I’d prefer to replace the same 19″ Acer model I’d been using for the last 15 years as I’m used to the color balance for Photoshop and my eyes throw their dummies out every time I mess with displays. The Acer monitor case is sealed. It would have to be broken open even if I could find a new cap or mainboard. It’s not worth the trouble. eBay time!

So what’s the problem? I had to steal the Next’s monitor to keep my main PC running… OOPSIE!

There’s not much desk space but I’ll try and find a replacement display for the TBBlue 2A dev board ASAP.

Good news…

I went a little crazy on the front end, adding most of the original PC version’s content. The bill came to 768K lol. The plan was to design a new front end for the Next version but it didn’t feel right without the original aesthetic. I rolled with the original design by Richard and Craig. For the record, the original team have really helped with the Next conversion and deserve a massive thank you.

Surprisingly at this stage, the intro, title screen, main menu and ending are all done. I’ve made some changes for the Next version as the original 480×270 resolution front end didn’t fit on the Next’s 320×256 display. This gives the Next version its own identity. The ending is also unique but official canon.

That bill I mentioned…

There was lots of chatter about memory after my last update so I can talk a little more about that subject.

I hit a brick wall after completing the front end as I had stored all of the assets in the source code as binary include files. The RS232 link is legacy 115,200 baud so the data is compressed to save transfer time, BUT even with compression, the turnaround time to make a change was taking up to 30 seconds. This was not good. I was also out of memory.

Time to bite the bullet and finish the internal file system. It turned out to be easier than I expected so it wasn’t long before the game ROM was back down to 2-3 seconds transfer time to the Next hardware. Ideally, the development game ROM should be tiny, with all assets stored on SD card and loaded on demand given the amazing 1.5MB/s data rate.

As a bonus, bare-metal code is able to stream multiple assets in parallel from the SD card BUS as seek time for flash memory is minuscule. Mechanical storage… gone, but not forgotten!

I modelled my file system API on open_file, load_file, load_data and so on as those are standard functions a developer would expect to use to access data. The file name is in the form of a number – an EQUATE in the source code; LD A,FILE_TITLESCREEN. I can live with that as it’s compact.

File seek and other bells ‘n’ whistles were also added and those features have paid off as it’s very easy now to add ‘child’ container files within the main ‘parent’ container – I didn’t want hundreds of tiny separate files clogging the system. The smaller container files are contained within the master .NEX file for distribution to keep things tidy and together.

The file system can also act as ‘read-only’ virtual memory and snapshots which I find extremely convenient to load ‘black box’ modules, execute them and re-allocate the SRAM. The ending sequence is a black box mini-app within the game, fitting nicely into the SRAM space the game sprites will use.

To note, I’ve partitioned the Next’s 1 megabyte of SRAM into large sections with a design to avoid memory fragmentation. Keep it simple!

The internal ‘WAD’ file system is finished, debugged and fully functional and there’s lots of memory left.

WAD’s this all about…

If you’ve read my previous updates, you may know that the development system SD card is not NextZXOS based. It’s RAW with a small boot partition containing a custom TBBLUE.FW. It cold starts the Next within 2 seconds (around the same time the project takes to build), installing my RS232 link and debug client into SRAM during power-on/reset.

The game data has to be written RAW to the SD card. That’s an easy task using my RS232 transfer tool but it does become a problem when the data doesn’t compress well or runs into megabyte quantities. Sending small amounts of data to the SD card down the RS232 link doesn’t slow down the workflow for most cases. Transfer speed to the TBBlue 2A dev board is the same for both SRAM and SD card.

So far, 6 megabytes has been allocated for the main game data WAD which should be enough for now. MANSION.WAD is currently 1.5 megabytes but there are also ROOMS.WAD at 22 megabytes and PCM.WAD at 32 megabytes. Transfer time for MANSION.WAD from PC to SD card is around one minute, but it only needs to be refreshed when I add a new batch of assets. The room WAD takes around seven minutes to send. I only refresh the SD card room data a couple of times a week so it’s not a deal-breaker.

PCM.WAD was finalised early on in the project as audio doesn’t compress well so it’s a job for the faster Windows hosted USB SD card image writing tools. I did plan ahead and coded a command-line tool to gather all of the data for the project to build the multi-partition .IMG file for times when I need to do a full SD card refresh.

I finally have an optimal storage/transfer solution to move the conversion forward as the game is a huge data gobbler!

Control freak!

As I coded the main menu, I needed to write the control device driver so to speak. I think most gamers will be happy with my decision to allow you to redefine all keys and joystick directions/buttons.

I prefer North-West as UP and South-East as DOWN. It would be rather unfair to force that compass orientation on other gamers, so you can redefine the joystick/joypad directions to match your own tastes.

Melkhior’s Mansion requires two buttons so if you use a single-button button joystick, you can choose the pickup/drop key which would be the space bar. There’s also a pause key. All inputs are fully configurable.

Summary…

I’m getting very close now to starting the game sprite/isometric engine stage of the conversion. I prefer to build solid foundations for my projects and that does take time.

The WAD file system has allowed me to claim back most of the memory I had wasted as the front end can be dumped when the game is running. I linked up the main menu to test the module loading and it worked perfectly. I was able to start the game from the front end and return back to the main menu after reloading the front end WAD.

I’m still unsure at this stage about 1 megabyte compatibility but it is looking very likely I will compress the sprites. This won’t cause problems as most of the other assets are also compressed in some form or other. The conversion won’t ever be compromised to try and fit the game into 1 megabyte Nexts.
Thanks again guys for the support and positive feedback.

KevB aka 9bitcolor.

https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
https://twitter.com/alberto_mcalby

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.