comp.sys.acorn.programmer Google Group

Re: Available Program memory

n...@rjek.com (Rob Kendrick) — Mon, 10 Oct 2008 22:22:47 UT

On Mon, 06 Oct 2008 23:13:15 BST
Have you considered using an off-the-shelf interpreted language such as
Lua or IO for this? They're both very easy to embed in C applications,
and may be just as quick or faster than your emulator, due to the many
years of research that has gone into them.
K&R Small C? I thought Small C was a subset of C from the 80s. I'd be

Re: Available Program memory

mi...@orpheusmail.co.uk (Mr John FO Evans) — Mon, 10 Oct 2008 22:13:15 UT

In article <3a5b05e94f.mar...@bach.planiv erse.com>, Martin Wuerthner
No in this case memory is not emulated because the emulator is embedded in
a host program and needs access to its own and to the host's memory. In
order to simplify and speed up the code the emulator uses the same memory as
the host. Alternative solutions tended to waste time transferring data

Re: Possible future directions

n...@druck.freeuk.com (druck) — Mon, 10 Oct 2008 21:30:00 UT

[snip]
Sorry to be disparaging, but talk of sound internals, adding VM and
just popping it on a microkernel suggest very little understanding of
the state of RISC OS.
Like any large software project that was initially knocked up in a
hurry as an a deperate plan B when the orginal OS design didn't work

Re: Possible future directions

n...@rjek.com (Rob Kendrick) — Mon, 10 Oct 2008 08:22:17 UT

On Sat, 04 Oct 2008 09:30:37 +1300
Actually, it all needs a huge overhaul. Memory handling,
multi-tasking, file system access, hardware abstraction, IP stack,
resource handling, IRQ routing, system call implementation, etc etc
etc. Microkernels are cute. But unless you can find one that already
supports all the hardware we want to use, it's going to be a lot of

Re: Possible future directions

asg...@inspire.net.nz (Keith Hopper) — Fri, 10 Oct 2008 20:30:37 UT

In article <20081002195837.55275...@trite .i.flarn.net.i.flarn.net>,
Ah! I must admit that I had had that horrible suspicion.
If proprietary I would regretfully have to agree with you!
My thinking suggests that the principal problems facing the viability
of a RISC OS solution for the longer term future are the need for the

Re: Spritefile & BASIC OPENOUT (PRINT#) internal file format...

n...@rtrussell.co.uk (Richard Russell) — Sun, 10 Oct 2008 20:30:43 UT

If it's only ever integers you are concerned with then the PRINT# &
INPUT# file formats for the two platforms are as follows:
'Acorn' BASICs (including ARM BASIC): &40 b3 b2 b1 b0
'Russell' BASICs (including Windows): b0 b1 b2 b3 &00
where 'b0' is the least-significant byte and 'b3' is the most-
significant byte of the 32-bit signed integer.

Re: Spritefile & BASIC OPENOUT (PRINT#) internal file format...

j...@arcade.demon.co.uk (jgharston) — Sun, 10 Oct 2008 17:45:42 UT

No they don't. BPUT# calls, well, the hint's in the name, OS_BPUT,
BGET calls OS_BGET.

Re: Possible future directions

invalid-em...@invalid-domain.co.uk (Paul Vigay) — Sun, 10 Oct 2008 13:52:58 UT

In a dim and distant universe <6krrf7F8t5n...@mid.individual .net>,
David Holden <Spam...@apdl.co.uk> enlightened us thusly:
What sort of difficulties? Was this with VRPC itself, or was it problems
with end-user support?

Re: Possible future directions

n...@rjek.com (Rob Kendrick) — Sun, 10 Oct 2008 12:51:39 UT

On Sun, 5 Oct 2008 12:49:37 GMT
Perhaps it's time to abandon the commercialness of the emulator, then?
B.

Re: Possible future directions

spam...@apdl.co.uk (David Holden) — Sun, 10 Oct 2008 12:49:37 UT

Yes, and the difficulties this produced were what convinced Aaron that it
was not a viable commercial proposition.

Re: Possible future directions

cfer...@freeremoveuk.com.invalid — Sun, 10 Oct 2008 10:45:15 UT

In message <230aa4e84f.dr...@druck.freeuk .net>
Wasn't there a demo Linux version of 'VRPC' at a 'RISC OS' show?
Were there any testers out there?

Re: Spritefile & BASIC OPENOUT (PRINT#) internal file format...

a...@adamshome.org.uk (Alan Adams) — Sat, 10 Oct 2008 20:49:23 UT

In message <de24869d-d4a6-4906-ba54-1b053 1e84...@s50g2000hsb.googlegro
ups.com>
My experience differs here. I had a system (part of my slalom results
system) which stored config data using PRINT#, and I found debugging
it too messy. Switching to using BPUT# at fixed positions in the file
allows debugging using a text editor, so for a start I can tell

Re: Available Program memory

spamt...@mw-software.com (Martin Wuerthner) — Sat, 10 Oct 2008 14:21:22 UT

In message <48dff6b5$0$512$5a6ae...@news. aaisp.net.uk>
... of one particular version of RISC OS. It is fundamentally
different in other versions of RISC OS, so there is no point in
relying on it unless you want your program to work on exactly one
version of RISC OS only.
Martin

Re: Available Program memory

spamt...@mw-software.com (Martin Wuerthner) — Sat, 10 Oct 2008 14:16:27 UT

In message <na.319cdb4fe6.a903c0mi...@orp heusmail.co.uk>
But surely, you are emulating the memory of the emulated device as
well and therefore, the address the user code accesses is just a
logical address in emulation context and has to be mapped to the
adress of the emulated memory anyway? At that point you will

Re: Spritefile & BASIC OPENOUT (PRINT#) internal file format...

use...@garethlock.com — Sat, 10 Oct 2008 11:16:53 UT

Nah... What I need is the technical details of the two internal
formats so I can write the whole shebang as a DLL for .NET...
The reason for using PRINT# & INPUT# is so that I don't have to mess
around converting ints to strings before writing them to the file.
This may or may not be necessary, but I've had nightmares trying to