DDE28

I just wish it was open sourced and free to download

It’s the old Codemist compiler, that translates C into “jopcodes”, then a backend that makes ARM code from that. Once upon a time, there will have been back ends for other processors. Therefore there may be licencing and intellectual property issues, so perhaps they simply can’t make it open source.

Perhaps you might like to consider this bounty? You’ll get access to the compiler, a grand and a half in cash, and everybody will benefit…

because the code output doesn’t appear to be fully ARMv7 compatible.

It’s ADDFS compatible with low vector ROMs? :-)

If not, it would seem reasonable to offer existing owners generous, non time-limited discounts for upgrades.

That would seem reasonable, it’s not as if the DDE is updated weekly…

Edit: as Jeffrey points out, this is the current offer.

Even in this case the change logs are incomplete. I posted parts of the text file change logs above, but you will note that Sprow mentions a change that doesn’t appear to be noted in the DDE release info.

Let me assist on this matter, by quoting a post by Rick Murray:

Fixed a CSE bug where the 2nd result from a built in function (such as div/rem) was needed and where the function could be evaluated at compile time. The compiler would instead keep track of the 1st result so a later use of the result would incorrectly substitute some earlier value. Note that run time evaluated functions were not affected.

No source code or tinfoil hats needed, just a clean pair of glasses.

There’s a six month time restriction on the “half price” offer, but I don’t believe updates come out within that timeframe, so it’s a bit cheeky really.

I think the original version of the offer was that, but they’ve updated it since then. The current rules are:

• If you bought the DDE in the past 6 months, you get the upgrade for free.
• If you bought the DDE over 6 months ago, you get the upgrade for half-price.

https://www.riscosopen.org/content/sales/dde

No source code or tin hats needed, just a clean pair of glasses.

Thanks for the clarification, but it assumes – I suppose – that one knows what a CSE bug is and how it applies to modulo, and not some CSI spin-off show. ;-)

I think the original version of the offer was that, but they’ve updated it since then. The current rules are:

If you bought the DDE in the past 6 months, you get the upgrade for free.
If you bought the DDE over 6 months ago, you get the upgrade for half-price.

Which, for a cash poor organisation, is probably about as cheap as they can currently afford.
The only thing that stopped slowed me ordering a new copy was the information about the bug in v28 which is now fixed but I wanted to allow time for things to settle into a known good.

Thanks for the clarification, but it assumes – I suppose – that one knows what a CSE bug is and how it applies to modulo, and not some CSI spin-off show. ;-)

Actually it was the exam that people who couldn’t manage GCE would take. They combined the two as GCSE and if you can count all your digits and spell your name it’s a pass. :)

I can upgrade for £25 then? Cool…it’s now on my Christmas list 😉

It’s ADDFS compatible with low vector ROMs? :-)

Slightly off topic, but yes, ADFFS (ADF File System…one D, two F’s) is fully compatible with Low Vectors. I haven’t however supplied a compiled version for game support in Low Vector on ARMv5+ because quite a few games will fail due to bugs. That said, I’ve fixed every bug I’ve spotted, so a lot more will now work, but Lemmings 2 still has an issue.

Obviously the StrongARM version handles games with low vectors and I’m planning on reinstating the Low Vector 32bit build with the next release…with the caveat that there’s no support for any games that fail under it. Ironically I was going to include that in the public beta I released yesterday, but ran out of time so either over the weekend, or next week.

Cool…it’s now on my Christmas list

And you too can have the fun of rolling your own RISC OS with custom features…

ADFFS (ADF File System…one D, two F’s)

Aha, so that’s why Google wasn’t my friend. :-)

because quite a few games will fail due to bugs.

Yes, you have talked about game bugs a lot – it makes me wonder how the hell they managed to work in the first place!
Just out of interest, what would you rank as the most memorable facepalm-worthy bug that you have come across?

I’m planning on reinstating the Low Vector 32bit build with the next release

Nice. I will look forward to Cannon Fodder and Magic Pockets.

with the caveat that there’s no support for any games that fail under it.

Are the two versions that different? It’s not just a matter of reading whether vectors are high or low and pasting in the appropriate addresses of stuff (that isn’t readable via OS_ReadSysInfo)?

Does ADFFS support the use of cheat modules? Back in the day, I used to use little cheats with Magic Pockets and Cannon Fodder because, well, because I’m absolutely crap…
I like GTA Liberty City (PS2) because if you don’t pick up the guy, you can wander off and explore and cause mayhem and the police don’t notice (that only happens once the guy has been taken to the safe house – intentional or game bug? I don’t know). Plus there are a billion not-so-secret codes for stuff. Fancy a katana? A chainsaw? :-)
I don’t like Resident Evil Codename Veronica (PS2) because there are no cheats. I barely make it out of the opening room before I’m zombie fodder. So much for exploring the foggy world…

If you’re interested, I have dropped copies of the cheat modules for those games at http://heyrick.ddns.net/files/cheats.zip

Nice. I will look forward to Cannon Fodder and Magic Pockets.

And HOMM2 too :)

And you too can have the fun of rolling your own RISC OS with custom features…

I’ve yet to figure out how to compile RISC OS, I have so many projects on the go I doubt I’ll ever get the time to figure it out.

Right…this is the last response from me about ADFFS in this thread. The JASPP forum is a more appropriate location to ask questions, or make requests for features/releases.

Yes, you have talked about game bugs a lot – it makes me wonder how the hell they managed to work in the first place!

Most failed safe on RO2/3, so were never detected. There were a few more public ones where the games couldn’t be completed, I believe Pandora’s Box or Carnage Inc possibly fall into that category going by the bugs.

Just out of interest, what would you rank as the most memorable facepalm-worthy bug that you have come across?

Just about every C based game touching Page Zero. The compiled game as a general rule of thumb have a lot more bugs than the hand coded games.

Are the two versions that different? It’s not just a matter of reading whether vectors are high or low and pasting in the appropriate addresses of stuff (that isn’t readable via OS_ReadSysInfo)?

Supporting games under High/Low vectors is radically different. The issue is one of how to detect if code running natively is trying to read from Page Zero. With Low vectors, the JIT emulates every LDR/LDM the first time it sees the instruction, to see if it touches Page Zero; if it does, its emulated and left as a hypercall instruction. The obviously issue here is when a memory read doesn’t touch Page Zero on its first execution, but subsequently does in which case it’s running natively and will succeed, more than likely with the wrong result.

With High vectors, the Abort handler handles all reads/writes to Page Zero and redirects them to the appropriate emulation, depending on which OS version response is being emulated.

Very few games actually use RISC OS variables in Page Zero, the majority of the accesses are bug related.

Does ADFFS support the use of cheat modules?

ADFFS supports 26bit Modules, so yes, they should work. You just need to added them to the boot script after its started the JIT (the first GOARM3JIT).

I have dropped copies of the cheat modules for those games

Thanks, Magic Pockets will be useful as I’m rubbish at it and have yet to record a gameplay video.

And HOMM2 too :)

HOMM2’s been working for a while but I’ve yet to finish tweaking CDFaker so the audio streaming doesn’t cause noticeable mouse stuttering. Installing will be an issue though, you’d need to install it under emulation, ZIP it up, copy across to your Pi (other incompatible machines are available), create a CUE/BIN of the music CD, create a FAT partition if necessary as the 2GB partition isn’t big enough to fit CD images on, mount the CD with CD Faker (when I release it), and finally create your own script to run it under ADFFS….you get the idea.

It’s not a game the project has rights too, so you’d be on your own I’m afraid.

I’ve yet to figure out how to compile RISC OS, I have so many projects on the go I doubt I’ll ever get the time to figure it out.

There’s a page for that – actually it’s several.

I actually fiddle a bit and modify a module or maybe two as stand alone items rather than part of a build.

Or if you want a guide to actually building RISC OS… https://www.heyrick.co.uk/blog/index.php?diary=20131105

Some of the links are outdated (I believe the unbzip in $.Utilities ought to do the job), and if you have a GB of memory, make the biggest RAMdisc you can and extract there (it’ll fly) and then copy to SD card (unless you just want a one off in which case try building from RAMdisc?).

Here are the mods I make (except the localtime one, which is now fixed in CLib): https://www.heyrick.co.uk/blog/index.php?diary=20160326

Namely:

• Low vector (I didn’t like the necessity of running ZeroPain and it’s plentiful logging; however I believe more recent versions have given a choice of behaviours so I’m open to reconsidering this)
• CET and CEST timezones baked into the UK territory (don’t get me started on Territory deficiencies)
• The above is incomplete and needs a Messages file tweak to tell the OS when the time changes, but even then the bloody thing doesn’t want to switch times automatically… Grrrr…
• Ignore the localtime thing, it’s been sorted.
• Adjust click on Switcher runs the config tool.
• Code for larger RAMdisc removed; it doesn’t work like that anymore (thanks to PMP)
• Get rid of stupid 100kHz IIC and, on the Pi, switch to 400kHz instead. This was contemporary in the early 90s, and any IIC device running at 3.3V should support that as a minimum. 100kHz? That’s Beeb era speed…
• Bake in support for a 1280×1024 monitor and use that by default (instead of 1920×1080). Obviously you can replace that with the dimensions of your own monitor.
• Ignore the BootFX mod, it’s been changed since then (and only fills half the screen so I guess it can’t cope with non 16:9 ratio screens?).
• And a one line tweak to hardwire the Next slot to 4096K as a 640K default on a hundreds of megabytes machine doesn’t make a lot of sense…

All the solutions to building RISCOS that I’ve to date either involve manually downloading the tar, or mutli-platform with a mixture of Linux/Windows/RISCOS. I did try the RISCOS version of CVS a few years back, but couldn’t figure it out. A Windows/RISCOS combo appears to be problematic if it doesn’t handle the file extensions during extraction, so Red Squirrel/RPCEmu get the filetypes/names correct.

Call me lazy, but I’d like a [free] turn-key solution to both synchronise the code and/or compile it that would need to run on RISCOS due to it requiring DDE. I could probably live with it only building the whole ROM – provided it only took a few mins, but optionally building individual Modules would be useful for quickly testing changes.

I do keep a copy of the RISCOS source on my Windows dev machine, but updating it is a pain as there’s always duplicates when you extract it, not to mention the filetype issue. I have to manually delete all the binary files from it as I only use it to grep functions or variables because there’s no search function on the web based source files. In fact it’s such a PITA, I only update it about once a year!

Once I find the code I’m looking for, I’ll switch to read it on the web based source files, as the multi versioning makes it impossible to follow in a text editor. It’s also why you quite often see me asking “where’s the code for X”, as grep doesn’t always help locate what I’m looking for.

It’s also why you quite often see me asking “where’s the code for X”, as grep doesn’t always help locate what I’m looking for.

Chunks of obscurely/irrationally labelled code and a bit of a dearth or commenting probably add to the fun.

but updating it is a pain as there’s always duplicates when you extract it,

That’s why I only build ROMs periodically. Not to mention deleting a billion files and extracting fresh copies really hammers the filesystem.

I did try the RISCOS version of CVS a few years back, but couldn’t figure it out.

Ditto. I ended up with a bunch of empty files with names like “/cvstag” but no actual content.
Given that CVS is supposed to be able to pull content, it’s a shame the weekly/monthly update archives are in some strange CVS format instead of regular files that could be merged into an existing installation of the sources.

In fact it’s such a PITA, I only update it about once a year!

I aim for 1-2 times a year to update. But in the past deleting older copies has left me with “Map inconsistent with directory tree” so I also need to factor in to power down the Pi and image the SD card before doing this….

It’s also why you quite often see me asking “where’s the code for X”,

Hehe.. Wimp02, Wimp03, Wimp04…

Hehe.. Wimp02, Wimp03, Wimp04…My usual way, if I know roughly where a function ought to be, is to drop all of the applicable sources into Zap and search all (StrongEd can do this too ;-) ).

Textile has done a new one.

I wrote the “Hehe.. Wimp02, Wimp03, Wimp04…” line once. It’s only present once if I go to edit the message.

But in the viewer? Twice…

I wrote the “Hehe.. Wimp02, Wimp03, Wimp04…” line once.

You know those pull out quotes you see in some forums, news articles etc?
Well I suspect that a letter-plus-two-dot and then a later three-dot marker is the way to do it.

Less logical than that, Steve – see “Oddity” in Tests.

Less logical than that, Steve – see “Oddity” in Tests.

OK, next dot seems adequate.

If you want use cvs to maybe download part of the sources the following TaskObey file will do the trick. It needs alias$cvs to point to the cvs program.

wimpslot -min 16m
dir <obey$dir>
| DDEUtils stops zeropain error
RMEnsure DDEUtils 0.00 RMLoad system:modules.ddeutils
set UnixEnv$cvs$sfix ""
set alias$roolcvs cvs -z9 -d :pserver:anonymous:@riscosopen.org:/home/rool/cvsroot %%*0
echo "Started"

x cdir Sources
dir Sources
roolcvs export -r HEAD mixed/RiscOS/Sources/HWSupport/USB

echo "Finished"

The example above will download the USB sources into a ‘Sources’ directory in the same folder as the taskobey file.

Just point the roolcvs line to the code you want.

Using ‘export’ instead of ‘checkout’ in the rool cvs line avoids the creation of cvs management folders/files

If you want to download specific complete products via cvs eg OMAP3Dev or TungstenDev etc. I have a script and basic file to do that too if you are interested.

If you want to download specific complete products via cvs eg OMAP3Dev or TungstenDev etc. I have a script and basic file to do that too if you are interested.

I’d be interested if it meant I could incrementally download the Pi build, and not need to deal with “everything” each time.

I think you always have to deal with everything. To synchronise a local copy cvs has to go through every file in your local copy to work out what is updated then send the updated files. It should work – just like it works for a local repository – but not sure that rool would like the extra workload put on their server of people updating their copies. Perhaps they would like to comment.

If you want to minimize file deletions you could download the rom sources to ramdisc and use !syncdiscs to merge them with your existing copy. You should be able to automate the whole process

and use !syncdiscs to merge them with your existing copy

I thought about using a copy with Newer, but I suspect that the files may have timestamps of when the file on RAMdisc was created? I’ll need to play around and see.

Use gdiff to generate a file containing a list of the files/directories that are different and parse the resulting file to make the update to the original sources. Shouldn’t take to long to update. A quick test on my armx6:

cvs rom download to ram disc 2min 43 secs
gdiff new rom sources, old rom sources 32 secs (288 differences)