stardot.org.uk

(As a total aside, I also notice that time_t is 32-bits so will fall foul of the Y2038 bug...) Apparently that's a common limitation - POSIX defines time_t as an "unsigned long", and there's been no real consensus on how to fix it for platforms where long is 32 bits. So different OSes have been goi...

Which version of GCC? I don't think I've run into any problems like that (but, I'm not sure if I've ever compiled anything that uses complex numbers)

The "negative pitch correlates to frequency in Hz" is a feature of the Sound_Control / Sound_ControlPacked SWI that SOUND is just a wrapper around (and really the key thing is for the lower 16 bits of the pitch to be between &8000 and &FFFF) http://www.riscos.com/support/developers/prm/sound.html#40...

though I struggle to be convinced that getting a correct answer than a wrap-around is a bug! True - without a proper specification for the BBC BASIC language this is all conjecture, and different implementations are free to do as they please. BASIC VI will quite happily allow me to add 2 integer co...

Due to the way Brandy works, I can't make it precisely match BASIC VI's behaviour, either it wraps for immediate integers and integer variables, or it doesn't, I can't separate them into wrapping on integer variables but not immediate integers. I think that's one variation I'm just going to have to...

&CC00000 is an approximation of 2^31/10 (&CCCCCCC), chosen because &CC00000 can be used as an immediate value in the CMP instruction. It's checking to see if the next digit will cause an overflow Oh, so it's only used in decimal to binary comversion? That's not at all the area of code I thought you...

So at some point during the code conversion process the &CC00000 threshold was added, and the logic for coercing the number into an integer was removed. Can you explain how this threshold works? I don't know about Brandy but there's nothing similar in my BASICs: I allow an integer overflow to occur...

OK, let me rephrase: It was a conscious choice to change the code, but it wasn't intended for it to change the arithmetic behaviour. Wouldn't the minimum-effort solution have been to leave the parsing code substantially unchanged when updating from 40-bit to 64-bit floats, or was that impossible for...

That Acorn modified it in BASIC VI may suggest they felt the same. I don't think it was a conscious choice to modify the behaviour. It's all down to whether the expression parser decides to classify the number as being integer or floating point (and thus whether the subtraction is integer or floati...

A link to the demo would be useful.

Nice use of animated GIFs

Yes. There are a couple of kernel workspace locations which the routine writes to (which will generally be read-only from user mode), and on Archimedes machines if the screen is scrolled then some of the screen may be inaccessible from user mode.

The OS's horizontal line routine should work - I've used it myself under RISC OS 5 (and I'm fairly certain the OS will be using it itself). Can you share your code?

That's the first I've heard of that approach as well. I can't find any explanations for why some of the solutions work (I guess it's just a slightly dodgy electrical connection for the pixel?), but it's good to know that there are a few tried-and-tested solutions available. https://www.wikihow.com/F...

When getting my A3010 to work with the monitors I start with a 'power on delete'. This sets the monitor type to Auto and mode to be VGA. Most LCD monitors will work with this setting and show a desk top. It's been a long time since I've touched an Archimedes, but if you're setting the monitor type ...

You didn't hallucinate it (unless it was a shared hallucination!). I think it was distributed via magazine cover disc back in the day (mid to late nighties). I'll track it down when I get home tonight (unless someone else beats me to it).

Correct, RISC OS BASIC is still written in assembler. ROOL converting it to C++ would be an odd choice, since the compiler that's used for ROM builds has abysmal C++ support (it's reliant on cfront!). C would be more believable, but even then it would be an odd choice since there are other component...

Detecting Archimedes vs. newer machines is easy - the MRS & MSR instructions are NOPs in ARMv2, so you can do something like: MOVS R0,#0 MRS R0,CPSR CMP R0,#0 ; NE = IOMD-era, EQ = IOC-era (I'm using MOVS for the first instruction instead of MOV just to guarantee that one of the PSR bits is set - ju...

IIRC "generate 4 different copies of the sprite at different pixel offsets" is the basic approach that was used by FastSpr sprite plotter used by Asylum and Oddball. It's also the approach that I used myself back in the day (not sure exactly where I discovered the approach - probably I just copied w...

(That said, http://armconverter.com/hextoarm/ decodes the EAE00069 instruction as "b #FF8001AC" (I guess b #0x38001AC when you mask out everything above bit 26) when executed at 0, and "b #0x30001AC" when run at 0x3800000, so maybe it will only work when run from 0.) Yeah, B and BL encode the addre...

I was going to link you to the (textless) PDFs that Usborne released a while ago - but on reviewing the thread here on *., it looks like someone's already sorted out a BBC version of Dungeon of Doom:

viewtopic.php?p=131258#p131258

When goto's become ugly/confusing I tend to try and restructure the code into a subroutine, so that the goto's become return's: static inline int cat_name_cmp(const char *nam_ptr, const char *cat_ptr) { const char *cat_nxt = cat_ptr + 16; do { char cat_ch = *cat_ptr++; char nam_ch = *nam_ptr++; if (...

If that's how you choose to interpret it, then I guess it's up to you. Seems you read the first two sentences you quoted but not the third - which clearly (I thought) explained that it was a different focus. I think that wasn't as clear from your last post. I took your "retro OS" comment from one o...

So I'm wondering, what would the development focus be for a "retro" hobby OS version of RISC OS? Are they incompatible with the above, or have I misunderstood you and your "retro" hobby OS is actually my "modern" hobby OS? I think this has been answered already above but just to be direct: It's not...

It would be great if the contributors to this thread could step back and take a breath. Normally the atmosphere here on StarDot is positive and encouraging. Apologies if I brought things down a bit. I know I have been part of "the problem" at times, and in the long run that's never likely to work o...

The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC. Do ROOL accept GCC code? I was under the impression OS ROM code must use ...

For someone to sponsor a bounty of that size would mean that you'd have to have some sort of viable business model to give you a sizeable ROI that was critical for that bounty to be completed AND be something only RISC OS could do. I can't think of any situation that would make that a long term via...

It was the ROOL talk (or perhaps both talks?)

https://youtu.be/110El6TbMY0?t=1000

Remember that there are still a few closed-source components (at least MbufManager, Resolver and ShareFS). They're on ROOL's list of things to sort out, but until that happens you're going to be left a bit short if you're interested in a fully open-source OS.

I'd be interested in seeing a summary of the differences between MEMC and MEMC1A. It looks like some of the differences are: Improved performance (mostly due to implementing proper fixes for some bugs that MEMC used workarounds for?) Support for chaining multiple MEMC's together to allow for >4MB of...

Nice!

One easy optimisation: Move line 130 down to 165 (or just get rid of the pp variable completely, since it's only used once)