|
| Author |
Message |
|
Stoppers
|
 Posted: Sun Oct 17, 2010 4:16 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
|
Updated title with a name, 29/11/2011.
Hi,
I know this is a fairly well supported area, but I had this ARM code emulator and nothing much to do, so...
The emulator (it hasn't got a name yet) is x86 Linux and RISC OS 4.02 only and will provide a VNC server to act as the input/output.
I think the unique aspect of the implementation is that it uses files for the physical RAM and ROM and replicates the ARM MMU by mapping sections of the files into memory as needed. Access to memory mapped I/O is handled within a SEGV signal handler which interprets the x86 instruction that caused the problem.
This is either going to turn out to be a really good, or a really bad idea, I think.
Any thoughts?
Last edited by Stoppers on Sat Jan 29, 2011 6:27 pm, edited 1 time in total.
|
|
|
|
 |
|
Stoppers
|
Posted: Mon Oct 18, 2010 8:15 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
Suggestions on a postcard.... It probably couldn't be worse than ROLF  Does it make you think of (a) a bearded Aussie, (b) a typo of a common internet acronym, or (c) the sound of someone being sick?
|
|
|
|
|
|
|
TomWalker
|
Posted: Sat Dec 11, 2010 2:52 pm |
Joined: Fri Jan 14, 2005 4:56 pm
Posts: 736
|
|
Something looks horribly wrong with the values processed in command 91 (-1338894612 sectors per track, -1338894596 heads per cylinder?).
However, main problem is that disc error 10 is not a valid IDE error but _is_ a valid floppy error (seek error I think). Ergo, I suspect you're inadvertantly accessing the floppy drive there...
|
|
|
|
|
|
|
Stoppers
|
Posted: Sat Dec 11, 2010 3:38 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
TomWalker wrote: Something looks horribly wrong with the values processed in command 91 (-1338894612 sectors per track, -1338894596 heads per cylinder?).
However, main problem is that disc error 10 is not a valid IDE error but _is_ a valid floppy error (seek error I think). Ergo, I suspect you're inadvertantly accessing the floppy drive there... Thanks for that; I'll have a look at the floppy emulation.
|
|
|
|
|
|
|
Stoppers
|
Posted: Sat Dec 11, 2010 7:05 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
TomWalker wrote: Something looks horribly wrong with the values processed in command 91 (-1338894612 sectors per track, -1338894596 heads per cylinder?). That comes down to me uncommenting old log lines and not looking at the warnings from the compiler: the values are actually 63 and 16 (not the addresses of the arrays containing the values). Sorry about that, this should be better: IDE: Read data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f ..............._ IDE: Read IDE 000001F7 039C17B8 00000002 IDE: Over! packlen 0 512 IDE: Read IDE 000003F6 039C1B88 00000002 IDE: Write IDE 000001F6 AF 039C1BA0 02107CF4 IDE: Read IDE 000003F6 039C1BB4 00000002 IDE: Write IDE 000001F1 00 039C1BD0 02107CF4 IDE: Write IDE 000001F2 3F 039C1BD8 02107CF4 IDE: Write IDE 000001F3 07 039C1BE0 02107CF4 IDE: Write IDE 000001F4 00 039C1BE8 02107CF4 IDE: Write IDE 000001F5 00 039C1BF0 02107CF4 IDE: Write IDE 000001F6 AF 039C1BF8 02107CF4 IDE: Write IDE 000001F7 91 039C1BFC 02107CF4 IDE: New IDE command - 91 0 0 039C1BFC IDE: Read IDE 000001F7 039C1F84 00000002 IDE: 63 sectors per track, 16 heads per cylinder IDE: Read IDE 000003F6 039C1B88 00000002 IDE: Write IDE 000001F6 AF 039C1BA0 02107CF4 IDE: Read IDE 000003F6 039C1BB4 00000002 IDE: Write IDE 000001F1 00 039C1BD0 02107CF4 IDE: Write IDE 000001F2 3F 039C1BD8 02107CF4 IDE: Write IDE 000001F3 07 039C1BE0 02107CF4 IDE: Write IDE 000001F4 00 039C1BE8 02107CF4 IDE: Write IDE 000001F5 00 039C1BF0 02107CF4 IDE: Write IDE 000001F6 AF 039C1BF8 02107CF4 IDE: Write IDE 000001F7 91 039C1BFC 02107CF4 IDE: New IDE command - 91 0 0 039C1BFC IDE: Read IDE 000001F7 039C1F84 00000002 IDE: 63 sectors per track, 16 heads per cylinder
|
|
|
|
|
|
|
TomWalker
|
Posted: Sat Dec 11, 2010 9:23 pm |
Joined: Fri Jan 14, 2005 4:56 pm
Posts: 736
|
|
Fair enough. I still reckon you're accessing the floppy drive by mistake - the current read log looks like what RISC OS does when initialising the drive, not when it's being mounted.
|
|
|
|
|
|
|
Stoppers
|
Posted: Sat Dec 11, 2010 11:15 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
|
I'd not been calling callbackfdc at all (I had been hoping to be able to ignore floppy code altogether with zero floppies configured), and that seems to be making a difference. Thanks for the help, I'm a little further on, now.
|
|
|
|
|
|
|
Stoppers
|
Posted: Sun Dec 12, 2010 10:18 am |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
TomWalker wrote: You should be able to ignore floppies altogether. Bet you've got Drive configured to 0 though  How much? I've updated the blog entry with a new image; now the error is "Bad free space map (Error number &108A9)" on "ADFS::IDEDisc4.$ Option 2 (Run)".  http://ro-lookandfeel.blogspot.com/2010/12/stalled-for-months.htmlIncidentally, I looked at moving my UI from a VNC base to plain Xlib (which I hadn't done before because the distribution I'm using to develop with, Knoppix, doesn't seem to want to let me apt-get any -dev packages). Turns out I needed a total of exactly one (count it: one)* header file: X11/Xlib.h to get it to work. It also turns out that ROLF's image library plays quite well with XImage. Edit: * Turns out (unsurprisingly) that that's complete rubbish; my system had lots of X11 headers installed already, just not Xlib.h (which, of course, includes others). Serves me right for not actually reading the header. 
Last edited by Stoppers on Thu Dec 16, 2010 8:52 am, edited 1 time in total.
|
|
|
|
|
|
|
Stoppers
|
Posted: Sun Dec 12, 2010 5:53 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
Found it! LDRB lr, [r0], +r1 wasn't storing r0+r1 in r0! That's the first proper bug I've found in the ROLF emulator for ages; mostly the changes have had to do with handing interrupts and aborts. I thought it was working! 
|
|
|
|
|
|
|
TomWalker
|
Posted: Sun Dec 12, 2010 10:10 pm |
Joined: Fri Jan 14, 2005 4:56 pm
Posts: 736
|
|
Oof! That's quite a nasty bug, and I'm surprised that the RISC OS desktop starts with that.
|
|
|
|
|
|
|
Stoppers
|
Posted: Mon Dec 13, 2010 8:00 am |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
|
I know!
A quick grep through a disassembly of the RO4 ROMS only comes up with about 45 occurences, though, ignoring lots which look more like data than instructions (e.g. ldrcct r9, [r2], -r8).
(It was only register offsets that were affected, btw.)
|
|
|
|
|
|
|
Stoppers
|
Posted: Mon Jan 03, 2011 12:02 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
Stoppers wrote: The emulator (it hasn't got a name yet) is x86 Linux and RISC OS 4.02 only and will provide a VNC server to act as the input/output. OK, that's now changed to a small Xlib based program instead (although the VNC version could be resurrected fairly easily). Stoppers wrote: I think the unique aspect of the implementation is that it uses files for the physical RAM and ROM and replicates the ARM MMU by mapping sections of the files into memory as needed. Access to memory mapped I/O is handled within a SEGV signal handler which interprets the x86 instruction that caused the problem.
This is either going to turn out to be a really good, or a really bad idea, I think. Unfortunately, it's starting to look like the latter. Is it possible that RISC OS 4.02 makes blocks of memory that are referenced by the first level translation table (as second level tables) available for general use? It looks as if something (InitHBlocks, in FileSwitch) is making a set of 128-byte blocks ready for allocation through some of them (although it could be a symptom of a mapping error in my code). That probably doesn't affect the real MMU, because it will only walk the table when a new memory area is entered, but I'm (currently) trapping writes to the second level tables and mapping the memory in (or out) then. I could try just unmapping the associated pages whenever a second level table is written to and mapping it in when the memory is accessed...
|
|
|
|
|
|
|
sack
|
Posted: Fri Jan 28, 2011 11:41 am |
Joined: Thu Jan 13, 2011 11:12 am
Posts: 4
|
|
'acorn RISC system emulator' perhaps?
oh wait...
|
|
|
|
|
|
|
Stoppers
|
Posted: Fri Jan 28, 2011 1:12 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
sack wrote: 'acorn RISC system emulator' perhaps?
oh wait... Brilliant! ARISE, it is!
|
|
|
|
|
|
|
Stoppers
|
Posted: Sat Jan 29, 2011 11:58 am |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
Samwise wrote: AROSE - Acorn RISC OS System Emulator? That could work, but it does have slight zombie/vampire overtones.
|
|
|
|
|
|
|
Stoppers
|
Posted: Sat Jan 29, 2011 1:33 pm |
Joined: Sat Oct 16, 2010 4:45 pm
Posts: 59
|
Samwise wrote: Obvious alternative: RISC OS System Emulator (ROSE) Why not, indeed. OK, we have a name; now all we need it for it to work!
|
|
|
|
|
|
|
sack
|
Posted: Mon Jan 31, 2011 10:52 am |
Joined: Thu Jan 13, 2011 11:12 am
Posts: 4
|
This thread just proves what I always say - if you blurt out 2 or 3 really bad ideas someone will combine bits of them, polish them off and you'll end up with something good. My partly written emulator (which I might attempt to finish when work allows) was called 'Novia'. Novia being the logical upgrade to an amiga 
|
|
|
|
|
|
|
|
