forums.jaspp.org.uk

I'll be giving a talk about the project and how the software works at ROUGOL on the 16th of June.

Here's the PowerPoint presentation I used on the day:

The site has been restored from last weeks backup following database corruption this morning, any posts since the 25th May have been lost.

https://forums.jaspp.org.uk/release/F10038/Art/Cover/cover.png Battle Chess (1993) (Krisalis Software) ID: 10038 Version: Unknown Developer: Interplay Genre: Board Game RAM: 2048 CPU compatibility: ARM2 ARM250 ARM3 ARM610 ARM700 ARM710 ARM7500 StrongARM ARMv5+ OS compatibility: 3.11 3.5x 3.6x 3.7x ...

This is now coded and v2.43 modules are on the dev site for testing. I've performed brief testing on RO3.71 StrongARM (emulated) and RO5.21 on the Pi, leaving Battle Chess playing itself and 2067BC running the demo for several hours. I've not however tested any existing known working games yet. Batt...

I've put them back online after uploading them all again. I'd advise only downloading the "full archive" and not the individual floppy images, as I'm not in a position to try and fix the underlying corruption issue. At least the ZIP will tell you it's corrupt when you try to extract it.

I'm afraid all downloads are offline until further notice. I'm not in a position to try and resolve the ongoing corruption issue for a while unfortunately, I'm going to see if there's something I can do remotely over the weekend, so check back on Mon to see if there's an update. I can only apologise...

All attachments are lost and downloads offline following the latest corruption episode. It's looking like Linux is the issue, as I've already replaced the hardware.

Whilst coding this, I've realised some SWI codelets need to remain allocated once the original instruction has been overwritten. In hindsight, SWI codelets that contain veneers should probably have been using private memory outside of codelet space for the veneer, but that would have made things mes...

Its looking like (1) is the only workable option. Although (3) will work, there is a slim possibility that an IRQ will occur during an IRQ if they're reenabled by an IRQ handler - Acorn's original advice on IRQ handlers is to switch to SVC and reenable IRQ's as soon as possible if they're going to t...

At the moment, memory allocated to codelets is leaked (until the JIT is reset) when the original instruction they implement is overwritten by either self-modifying code or by loading data/code over them. Its not an issue for most games, ones that continually self-modify however run out of codelet sp...