Hey, you, Reptons!

[ThomasHarte]

Although it's not yet especially good at doing so, my emulator Clock Signal now also emulates the 26-bit Archimedes. In addition to the Electron it already had in its oeuvre.

Mac releases here; Linux is currently back to build-from-source because I've broken the Snap. Snaps are not a good way to distribute software.

As yet:

• very little assistance in auto-launching software or auto-configuring hardware to software being launched;
• no hard disk support whatsoever; and
• probably none of whatever else you actually wanted from an emulator.

But on the plus side: setup is trivial:

1. download emulator;
2. download interesting ADF, HFE or similar;
3. launch emulator, either directly or by file association from your preferred ADF, HFE or similar;
4. when the dialogue appears telling you to drag and drop a RISC OS ROM image onto it, do so;
5. enjoy, and in future never again think about step (4).

And ditto it does the usual stuff:

• arbitrary window sizing, with appropriate filtering;
• launch as many simultaneous machines as you like;
• feel slightly less insecure because the application is sandboxed and signed; and
• if you're using it on the Mac, enjoy a fully-native app using the standard built-in widgets and all Apple's currently-preferred APIs.

I worked on this because I had an unexpected surplus of time. I'm now back to my usual deficit. So even though I'd really prefer to have done more in terms of user friendliness — until it's true that you can double click an ADF in the Finder and have the emulator automatically take you all the way to having the software on it running, I'm not happy — my punch list of titles that has to work non-embarrassingly has been satisfied. Therefore here it is.

Standard comments apply, i.e. I'm sure everybody who wanted an emulator already has one so if the way to make this thread interesting is to be more technical about the specifics of one particular implementation then let's go for it. No code was reused from any other emulator so I'm sure it's different in a bunch of probably-weird ways.

---

Screenshots, assorted:

[tricky]

Sounds like another great addition to your stable

[ThomasHarte]

Sounds like another great addition to your stable

It is immediately the most sophisticated machine in my little roster, both in terms of quality of software and — taking it as given that simplicity is the ultimate sophistication — in hardware.

Upcoming questions:

• do I just implement a SCSI card and pretend the other hard disk interfaces don't exist, since my emulator already speaks SCSI?
• do I implement Econet and a filestore as a means to share local folders, since that would also map to the Electron?
• can I figure out which SWIs are appropriate to automate application launch (as I don't really want to do a virtual F12 and then a typed launch, for fear of giving a false impression to people who don't know the machine), which probably primarily means figuring out where on screen one should click to launch something without pixel-parsing (though that's also an option, I guess)?
• should I first tackle the long-term terrible performance of the way I emulate spinning disks, or hit up the low-hanging fruit in audio filtering?

Know puzzles yet to solve:

• I've yet to spot where and how disk change (one of the versions of RDY, clearly, but wired to where I've yet to discern) presents itself to the machine, so some multidisk titles don't work;
• both James Pond titles seem to position some display events too early — see below for greater exposition;
• I don't currently draw the cursor over the border, for very emulator-specific reasons to do with how a video stream is most-compactly serialised; and
• the startup chime is playing at the wrong frequency even though most in-game audio sounds fine.

On James Pond, e.g. these are the leftmost hardware scroll parameters as my VIDC receives them:

Code: Select all

  period = 255
  sync_width = 18
  border_start = 56
  border_end = 207
  display_start = 45
  display_end = 205
  cursor_start = 397
  cursor_end = 0

So, ignoring any concerns about on-screen positioning in general, a 256-cycle line, with (i) the display area starting a solid 22 pixels before end-of-blank (/"start of border"); and (ii) the display are ending four pixels before start-of-blank (/"end of border").

So pixels start so early that James' energy and lives graphic is slightly cropped by the blank area (as in the screenshot above), and then they end before the blank area restarts, giving a slither of (cyan) border. Which the cursor isn't appropriately placed to mask, although I guess that would be one potential use of it.

I kind of wonder whether there's something about how display type is detected that I've failed to spot, the inconsistency of which is causing James Pond to pick slightly inconsistent framing, but it's probably more prosaic than that.

(EDIT: maybe it’s doing something weird with DMA placement deliberately to delay pixel data? But I can’t think of a reason why it would. But it’d be an easy detail to get wrong in a new emulator, so…)

Scrolling is otherwise smooth, gameplay fully functional, etc. Hence the must-function punch list threshold being reduced to "not embarrassing". Though I also need to do a bit more in terms of expected-hardware autodetection to resolve things like Zarch running way too quickly.

Addendum: it's also possible there's still an obscure bug in my ARM, of course, since I didn't find any existing unit tests and therefore am still little beyond the level of testing that things do what I intended them to do, rather than what Acorn intended them; any faults in documentation likely survive as faults in implementation and not only may ambiguities have been resolved arbitrarily, but they may unwittingly have been so.

[steve3000]

Oh wow, a new Archie emulator well done!!!

Just a suggestion, you might get more responses to questions if you maybe change the title of this post, because the last thing I expected to see when clicking on the thread "Hey, you, Reptons!" was the announcement of a new Archie emulator

Have you looked at how the online port of Arculator auto-boots straight into software? eg. https://archi.medes.live/#disc=https:// ... eset=a3020

I suspect the James Pond issue just an artefact of how to implement hardware horizontal scrolling on the Archie. You use the border to cover the edges of the displayed screen area, reducing the actually displayed width, then shuffle the screen display start/end and border start/end as you move left/right, to scroll?

[ThomasHarte]

Just a suggestion, you might get more responses to questions if you maybe change the title of this post, because the last thing I expected to see when clicking on the thread "Hey, you, Reptons!" was the announcement of a new Archie emulator

My thinking was: this doesn't yet strongly represent my preferred model of an emulator*, and emulation is already covered on all its potential target platforms, so I should probably mention it but it's not worth making a big grand announcement.

I think it's possibly the only neat, turnkey solution for Mac users but that feels kind of weak.

(* that it should be invisible; the software you want to use sits on your computer exactly like any other piece of software and launches exactly like any other piece of software. That it just so happens to be thirty-year old software for a different computer is by the by.)

Have you looked at how the online port of Arculator auto-boots straight into software? eg. https://archi.medes.live/#disc=https:// ... eset=a3020

I have not; I wonder whether it's something to do with the custom filing system and the ability to insert a custom boot script? Probably I'll check it out. For now I'm more interested in automating UI interactions until such point as the application is loaded, which possibly brings in an SWI angle because it'd be a lot easier to be able to spot that the icon for '!RoboCod' or whatever is currently on screen at (x, y) by observing the SWI that caused it to be drawn up there than it is to search for that text on screen — even if the standard font makes that much less than an OCR problem.

I suspect the James Pond issue just an artefact of how to implement hardware horizontal scrolling on the Archie. You use the border to cover the edges of the displayed screen area, reducing the actually displayed width, then shuffle the screen display start/end and border start/end as you move left/right, to scroll?

No, it's definitely off in my implementation. Video here. The content is too far to the left in general, and the pixel content is too far to the left within the un-blanked area. But it's all being drawn correctly according to my understanding of the meaning of the numbers posted above, which are definitely what's being posted to my VIDC. So I think the problem is at least mildly obscure.

I'm definitely going to check up on that FIFO/DMA timing thing; it's certainly something I've only glossed over so far. But that's almost the full justification for my suspicion.

---

EDIT: no, wait, it's just that I've clearly failed to ingest the advice underneath horizontal display start and end registers that:

The value programmed here depends on the screen mode in use. If M pixels are required in this time, then:
in 8 bits per pixel mode, value (M-5)/2 should be programmed ...
in 4 bits per pixel mode, value (M-7)/2 should be programmed ...
in 2 bits per pixel mode, value (M-11)/2 should be programmed ...
in 1 bit per pixel mode, value (M-19)/2 should be programmed ...

i.e. in 4bpp mode (as used by the games in question), the display start and end values actually indicate the location 7 pixels ahead of the start of pixels.

So in the sample given:

Code: Select all

  border_start = 56
  border_end = 207
  display_start = 45
  display_end = 205

That actually means that pixels are being generated — whether they reach the display or not — between locations 45*2+7 = 97 and 205*2+7 = 417, whereas the blank region extends to 56*2+1 = 113 and then starts again at 415. So clearly the pixels do fully cover the visible area.

... and I've been happily clicking around RISC OS regardless because it just so happens that the cursor start delay is 6 pixels, exactly halfway between the 8bpp 5 pixels and 4bpp 7 pixels, so in the usual modes the cursor is only off by a non-obvious 1px. If I switch RISC OS to Mode 0 or Mode 8 to try 1bpp or 2bpp mode then the cursor much more obviously doesn't align with the pixels underneath.

This is the sort of I-didn't-read-it-very-well nonsense that probably makes this emulator currently uninteresting.

[sirbod]

No, it's definitely off in my implementation. Video here. The content is too far to the left in general, and the pixel content is too far to the left within the un-blanked area. But it's all being drawn correctly according to my understanding of the meaning of the numbers posted above, which are definitely what's being posted to my VIDC. So I think the problem is at least mildly obscure.

James Pond 2 scrolling relies on very specific timing for the calculated screen geometry, which I covered in this thread. Namely:

the geometry for the next frame is determined at VDER, prior to the VSync IRQ

In other words, get the next frame's geometry at VDER, then raise IR.

[geraldholdsworth]

I think it's possibly the only neat, turnkey solution for Mac users but that feels kind of weak.

That's the winner for me. Us macOS users sometimes appear to have been forgotten when software is developed.
It's nice to finally have a native Archie emulator for the Mac again.

[ThomasHarte]

No, it's definitely off in my implementation. Video here. The content is too far to the left in general, and the pixel content is too far to the left within the un-blanked area. But it's all being drawn correctly according to my understanding of the meaning of the numbers posted above, which are definitely what's being posted to my VIDC. So I think the problem is at least mildly obscure.

James Pond 2 scrolling relies on very specific timing for the calculated screen geometry, which I covered in this thread. Namely:

the geometry for the next frame is determined at VDER, prior to the VSync IRQ

In other words, get the next frame's geometry at VDER, then raise IR.

As a quick hack last night I did a bipixel approximation of the proper colour-depth-dependent output delays yesterday (hard-coded to 4bpp, very hacky, diagnostic stuff) and all issues were resolved with those titles.

Though I’m not treating geometry as something that’s latched; all registers are used live as the display progresses. Vptr is read once as flyback goes low (i.e. on the first vertical line with pixels) though.

[sirbod]

If it's any use, the titles I use to check VIDC geometry emulation are:

Caverns (1991) (Minerva) - has an oversized mouse pointer the contains the highscore and ship
Grievous Bodily 'ARM (1992) (The Fourth Dimension) - timing specific horizontal scrolling
James Pond II Robocod (1993) (Eclipse) - timing specific horizontal scrolling
Manchester United (1990) (Krisalis Software) - checking the the match-play resolution is correct
Rockfall (1991) (Eterna) - checking the main title screen isn't clipped

And to check video timing, I use:

Gribbly's Day Out (1992) (Coin-Age) - checking the copperbars in the starting level are correct
James Pond (1990) (Krisalis Software) - checking the waves on the starting level are the correct colour
Lemmings (1991) (Krisalis Software) - checking the palette changes just above the lemming choices menu
Lotus Turbo Challenge 2 (1992) (Krisalis Software) - checking the palette changes at the transition between mountain/sky and land
S.W.I.V. (1992) (Krisalis Software) - has a palette swap that moves as the screen scrolls vertically, which should smoothly follow the scrolling

If they all work, it's a fair bet everything else will work. The complete list of games that mid-frame palette swap can be found here, if you're being thorough with checking timings.

[ThomasHarte]

If it's any use, the titles I use to check VIDC geometry emulation are:

...

And to check video timing, I use:

...

If they all work, it's a fair bet everything else will work. The complete list of games that mid-frame palette swap can be found here, if you're being thorough with checking timings.

Those will be of use, as I've tested essentially none of them. I already know Robocod and the original James Pond will be fully fixed when I take into account the different output delays for each color depth — you can see from the video above that I was already most of the way there — and the Lemmings and Nebulus palette swaps are correctly placed. They actually weren't for a while because initially I'd failed to notice that Acorn uses 'flyback' with a very atypical meaning, even though it's right there and clear on the VIDC data sheet.

That all being said, I'm putting due care and attention into the VIDC and IOC side of things while — for now — still just handwaving away the ARM side and, correspondingly, the bus realities. If I'm trying to be flattering I might agree that's because the Archimedes is a range of machines so I can tell myself the pleasant story that, yes, relative timing and placement of timer and VIDC events is well-defined for the platform as a whole and therefore is something large proportions of software will rely upon but, no, instruction tallies aren't... but more honestly it's because I'm historically unfamiliar with the underpinning of the Archimedes and I needed an entry point.

Biggest area of surprise: the CAM-style backwards-by-modern-standards MMU. Although clearly it makes sense as an optimisation of silicon and engineering risk, but a lot of things are easy to agree with when somebody smarter has already posited them.

Substantial error that persisted the longest: failing to think hard enough to realise that because LDM can opt to use user registers regardless of CPU mode, that means that simply checking whether a corresponding bit is set for the base registers is insufficient to decide whether write-back is implicitly ineffective.

[Sophira]

• can I figure out which SWIs are appropriate to automate application launch (as I don't really want to do a virtual F12 and then a typed launch, for fear of giving a false impression to people who don't know the machine), which probably primarily means figuring out where on screen one should click to launch something without pixel-parsing (though that's also an option, I guess)?

Launching an app (at least on RISC OS 3+) is pretty easy; a single star command will have the exact same effect as double-clicking it in the Filer:

Code: Select all

*Filer_Run <file/app path>

For example:

Code: Select all

*Filer_Run :0.$.!MyApp

However, there are two problems with this:

1. The *Filer_Run command only works on RISC OS 3+, as mentioned. While this will be fine for 99% of games, there may be very occasional outliers that only work on RISC OS 2. I can't think of any at the moment, but I'm sure they exist. You may be able to get around this using the *Run command instead, but it's not guaranteed to work, particularly for games that interact with the WIMP in any way.
2. Some games - mostly multitasking ones, but occasionally even some full-screen ones like Elite - won't immediately show their interface upon launch, but will add an icon to the iconbar instead, which you need to click on to actually start playing. That said, there are normally very good reasons for this - for example, to use Elite as an example, the only way to save your progress permanently to disc is to quit out to the desktop, then use the icon's menu to save the file. (You can temporarily save progress by pressing HOME when docked at a station, but you'll still want to permanently save occasionally.)

I'm not very experienced with RISC OS development, but my understanding is that mouse automation via APIs is possible as long as you're in a setting that can multitask, like the WIMP (a module that communicates with the emulator and issues OS_Word 21,3/OS_Byte 138 SWIs should probably work, though I don't have any experience with the latter, which I believe you'd want to use to insert a click into the mouse buffer).

However, I imagine that as soon as you enter a single-tasking game, that all goes through the window thanks to the fact that RISC OS is cooperative multitasking and not preemptive multitasking, and the game's not going to hand control over to you. (Though note that I'm not certain; I know for a fact that there must be some interrupts that modules can hook even in the command line, since various tracker modules can still play music in the background there.) Fortunately, you probably won't need to worry too much about that given that you probably already have what you want by that point, but it's something worth considering.

For games like Elite, my guess is that your best bet would be patching the game to do what you want - probably not the easiest of tasks.

[paulb]

Biggest area of surprise: the CAM-style backwards-by-modern-standards MMU. Although clearly it makes sense as an optimisation of silicon and engineering risk, but a lot of things are easy to agree with when somebody smarter has already posited them.

This is briefly discussed in "MEMC and RISC iX" with other discussions referenced. When the ARM6 came around, the MMU architecture had changed to something more conventional/contemporary. Dick Pountain notes the following about it, which might be worth some reflection/revision:

The most radical aspect of the ARM610 is its MMU, which combines a sophisticated conventional virtual memory controller with a novel scheme for partitioning memory along object-oriented lines. This aspect of the chip’s design is the subject of a patent held by Apple Computer and licensed to ARM.

"A Call to ARM", Byte, November 1992.

(Pountain goes on to discuss applying the MMU's permission controls so that only code residing in certain memory regions can access data associated with private members or attributes of objects or instances in object-oriented languages. Since I don't follow low-level ARM development topics, I don't know whether tools and systems conspire to implement such approaches or whether it is just another aspect of the architecture there to catch the unwary by surprise, judging from various forum posts.)

[TobyLobster]

I think it's possibly the only neat, turnkey solution for Mac users but that feels kind of weak.

That's the winner for me. Us macOS users sometimes appear to have been forgotten when software is developed.
It's nice to finally have a native Archie emulator for the Mac again.

Seconded, nicely done!

[sirbod]

Acorn uses 'flyback' with a very atypical meaning, even though it's right there and clear on the VIDC data sheet.

If you want to check flyback is implemented correctly, or more specifically that the IOC IR pin is high at the correct times. Two Eterna games rely on the IR PIN for syncing:
Ballarena (1990) (Sisteme) - check the animation is correct on the highscore loop
Tactic (1990) (Eterna) - check the animation on the title sequence

From memory, the animation in both game will freeze if IOC IR isn't going high/low correctly.

[ThomasHarte]

Launching an app (at least on RISC OS 3+) is pretty easy; a single star command will have the exact same effect as double-clicking it in the Filer: ...

I'm trying to avoid that if I can so as not to risk giving a false negative impression about RISC OS to people who aren't otherwise aware, but it is a better option than doing nothing so is on the candidate list.

I also don't tend to know what the best solution is until I actually spend some time taking a real shot at it, so right now all I could offer is fluffy bromides. But with regard to the range of ways that titles integrate with the OS, I think probably the objective for autolaunch is:

• for any software that doesn't expect the user to interact with the icon bar (e.g. StarFighter 3000), just launch it;
• for anything which puts only the boilerplate Info and Quit into the icon bar, launch it and then hit select on its icon;
• for anything beyond that, launch, head down to the icon bar and hit menu.

If you want to check flyback is implemented correctly, or more specifically that the IOC IR pin is high at the correct times. Two Eterna games rely on the IR PIN for syncing: ...

Thanks again, I'll add them to my list, though it looks like I'll need to get over the non-media-image hurdle for a lot of them, both Manchester United Europe and Lotus Turbo Esprit II seemed to work exactly as well as reasonably expected*, and SWIV either did palette change correctly or else my terrible playing means I didn't get to it.

So I'm going to get to the VIDC changes, all being just "observe the documented diferences between programmed values and their effects", whenever time next permits. They're all relatively easy, low-hanging stuff.

* Manchester United was slightly cropped because of the particular 90% of the PAL area that I display, but that's just a post hoc crop so I'm not worried right now; Lotus Turbo Esprit's palette changes were a line late but I also hadn't heeded the '+1' advice from the VIDC sheet on vertical timing so my 'flyback' area is a line short owing to the whole frame being a line short.

This is briefly discussed in "MEMC and RISC iX" with other discussions referenced. When the ARM6 came around, the MMU architecture had changed to something more conventional/contemporary. Dick Pountain notes the following about it, which might be worth some reflection/revision: ...

The surprise here, was definitely subjective; I've just never really done anything with the ARM hardware beyond the usual pass through in 32-bit ARM assembly that probably anybody who passed through university in the last twenty years shares. And even then since I'm only doing the ARMv2 and ARMv3 I got to keep things simple with only the four operating modes and no separate status registers to juggle (modulo appropriate care about when R15 is the PC only and when it's PC+PSR).

[paulb]

The surprise here, was definitely subjective; I've just never really done anything with the ARM hardware beyond the usual pass through in 32-bit ARM assembly that probably anybody who passed through university in the last twenty years shares.

That makes me feel old: I was dabbling in ARM2 code before university, but our assembly language module at university involved the 68000 on a bunch of Atari STs, probably retained purely for that purpose. Contrary to the impression people like to communicate now, at the time (more like thirty years ago) I imagine that ARM was something that no-one was sure would stick around. It could easily have slotted into computing history alongside the Am29000 or i960 or maybe some of the microcontrollers that persist but no-one outside certain sectors would even be able to name.

I've noted already that it was odd that we didn't just run assemblers on the Unix workstations. That wouldn't have been bare metal coding, really showing off the power of assembly language in its native habitat, but we weren't exactly doing anything strenuous on the STs, either. And as previously noted, MIPS, SPARC or PA-RISC assembly language would have been "current", x86 assembly language more annoying but also more annoyingly attractive to employers.

And even then since I'm only doing the ARMv2 and ARMv3 I got to keep things simple with only the four operating modes and no separate status registers to juggle (modulo appropriate care about when R15 is the PC only and when it's PC+PSR).

Yes, I imagine that it has become a real mess, given various impressions I have received through different channels.

Back on topic, I did manage to compile Clock Signal on Debian, needing an adjustment to the CMakeLists.txt to add the following:

set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(clksignal PRIVATE Threads::Threads)

I'd consider packaging this for Debian if anyone showed any enthusiasm for my existing packaging efforts. Otherwise, I should explore the configuration issues such as changing the keyboard layout. It reminds me of the good old days with ElectrEm!

[ThomasHarte]

That makes me feel old: I was dabbling in ARM2 code before university, but our assembly language module at university involved the 68000 on a bunch of Atari STs, probably retained purely for that purpose. Contrary to the impression people like to communicate now, at the time (more like thirty years ago) I imagine that ARM was something that no-one was sure would stick around. It could easily have slotted into computing history alongside the Am29000 or i960 or maybe some of the microcontrollers that persist but no-one outside certain sectors would even be able to name.

If I do the actual arithmetic, then I finished that degree 21 years ago but, yeah, even by then ARM was on the roster only because it's a relatively pure RISC of the few that had made a commercial impact* and by then had just about found a second life in mobile phones.

* by which I overtly mean: in contrast to PowerPC, probably the more successful RISC of the era.

Back on topic, I did manage to compile Clock Signal on Debian, needing an adjustment to the CMakeLists.txt to add the following:

set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(clksignal PRIVATE Threads::Threads)

I'd consider packaging this for Debian if anyone showed any enthusiasm for my existing packaging efforts. Otherwise, I should explore the configuration issues such as changing the keyboard layout. It reminds me of the good old days with ElectrEm!

Oh, for the SDL target, presumably? Qt is also an option, essentially only for X11 because I found Qt's native keyboard API to be insufficient and decided to ignore it wherever possible. So it can build with pure Qt but probably doesn't work that well. Actually, the whole OpenGL side of things needs a substantial refresh — the Apple-specific Metal side of things is essentially version 2 of that subsystem and there are a whole bunch of improvements I could roll back. I keep telling myself I'll just get one more big improvement that I want to make to the composite side of things on Metal, then worry about the more arduous task of an an OpenGL implementation, and I'm sure that one day I will.

Anyway, quick hacking notes:

This was my [re]learn C++ project when it first began, so code quality still varies greatly. That accepted, the main thrust of it is a bunch of freestanding machines which implement relevant `MachineTypes` interfaces, usually at a minimum `MachineTypes::TimedMachine` and `MachineTypes::ScanProducer`.

The former just means you need to keep calling int to run the machine for whatever quantities of a second is appropriate for you.

The latter means that if you supply a host-appropriate subclass of `Outputs::Display::ScanTarget` then it'll serialise video output to there, which means it'll receive a bunch of rasters — a pair of (x, y) coordinates indicating start and end plus a PCM sampling of the data to fill that space with in one of currently eight pixel formats. As practical concerns it'll also get notified of detected horizontal and vertical syncs. and get the user's selection for display type and what colour space and colour subcarrier that'd be if it's composite. It is also involved in allocation of the storage for that PCM data, so that it can be in shared GPU/CPU space if available.

There's a couple of ScanTargets implemented, one for OpenGL and one for Apple's Metal. Both just calmly enqueue data as they receive it and need separate calls actually to paint it outward; both permit those things to happen simultaneously. So hosts can run the machine runs on one thread and video output on another, and normally they just do video output whenever makes sense. The metaphor is supposed to be that the host machine has a camera pointed at the screen of the client so you can snapshot it whenever you like. There is some feedback that allows mild warping of time to try to pull host and client retraces into sync where that's sensible, but that's not the default. The idea is that if you've spent your money on a 144Hz monitor or whatever because you care about latency then the emulator will give you 144 independent frames per second with minimised latency. Whatever works.

The Archimedes also implements `MachineTypes::AudioProducer`, which allows the host to provide a callback and preferred buffer size, and negotiate a good output sample rate for audio. Then `MachineTypes::MouseMachine` is how the machine canvasses for mouse input, and `MachineTypes::MappedKeyboardMachine` is probably the one that's interesting if you want to look at keyboard mappings.

There are supposed to be two things going on there:

1. the machine provides the stuff in `MachineTypes::KeyActions` by which a host that knows the specific emulated machine is supposed to be able just directly to set specific keys up and down; and
2. it also provides a `MachineTypes::MappedKeyboardMachine::KeyboardMapper` which will map from a normative PC/Mac 102-key layout to the particular keys recognised by `MachineTypes::KeyActions`. So a host that doesn't want to invest in per-machine mapping doesn't have to; it can just work with 102-key presses, and map them through that.

In practice I've not yet pulled out any standard defines for the Archimedes so there's kind of an assumption that you're just going to use the default mapping. But check out the Archimedes' KeyboardMapper.h — the Arc-side key mappings are just row and column combined into a byte, so at least provisionally you can work from there if you want to skip the mapper.

And, to mention it, the other big tool for hosts that want to support the emulator's entire array of machines is the static analyser, which takes some media and spits out a list of potential targets for it (almost always only one), then can also provide an instance of a machine for any given target. Probably not worth getting too invested in at first, just be aware that's how all three of the current OS bindings for the emulator — SDL, Qt and macOS — are concluding that they need to create an Archimedes if asked to open a relevant ADF, HFE or similar.

As per above, the ARM is currently only implemented as a high-level emulation, it doesn't yet even attempt bus accuracy, and that flows into the current Archimedes chipset decisions, though video, timers and audio run at the proper precision as if they were bus accurate, they just get all DMA instantly and without cost. There is work to do here.

Oh, and the emulated monitor attached to the emulated Arc isn't yet multisync so expect synchronisation to be lost if you pick a VGA mode. I'm going to fix that. Click to witness:

[Sophira]

Launching an app (at least on RISC OS 3+) is pretty easy; a single star command will have the exact same effect as double-clicking it in the Filer: ...

I'm trying to avoid that if I can so as not to risk giving a false negative impression about RISC OS to people who aren't otherwise aware, but it is a better option than doing nothing so is on the candidate list.

Just to be clear here, I wasn't suggesting that you do this by pressing F12 automatically and typing the command; I was mentioning it as you'd be able to do stuff like putting the command into a !Boot file (of type Desktop, &FEA), and having the computer boot from an emulated hard disc.

Unless I'm misunderstanding what you're thinking of doing?

[ThomasHarte]

Launching an app (at least on RISC OS 3+) is pretty easy; a single star command will have the exact same effect as double-clicking it in the Filer: ...

I'm trying to avoid that if I can so as not to risk giving a false negative impression about RISC OS to people who aren't otherwise aware, but it is a better option than doing nothing so is on the candidate list.

Just to be clear here, I wasn't suggesting that you do this by pressing F12 automatically and typing the command; I was mentioning it as you'd be able to do stuff like putting the command into a !Boot file (of type Desktop, &FEA), and having the computer boot from an emulated hard disc.

Unless I'm misunderstanding what you're thinking of doing?

Since I don't yet support hard disks, it would indeed need to be piped in via the keyboard.

The emulator as a whole already speaks SCSI for the benefit of the Electron, Apple II and Apple Macintosh so that's probably the path of least resistance but it's still in the future.

EDIT: or I guess I could patch the inserted disk, but that'd run up against copy protection and possibly disk size issues, so maybe a second disk in an alternate drive but in terms of edge cases that's starting to be no easier than just being able to detect and decode the built-in font and manipulating the mouse cursor from afar.

[Sophira]

Oh, that's fair. I hadn't thought about that! I apologise.

[ThomasHarte]

Acorn uses 'flyback' with a very atypical meaning, even though it's right there and clear on the VIDC data sheet.

If you want to check flyback is implemented correctly, or more specifically that the IOC IR pin is high at the correct times. Two Eterna games rely on the IR PIN for syncing:
Ballarena (1990) (Sisteme) - check the animation is correct on the highscore loop
Tactic (1990) (Eterna) - check the animation on the title sequence

From memory, the animation in both game will freeze if IOC IR isn't going high/low correctly.

Actually, minor follow-up on this since I've actually found definitive information hard to come by: do you happen to know exactly when the flyback signal goes active in horizontal terms? I currently have it purely as part of the vertical state machine, so it goes active at the end of the final line with pixels on it, but it strikes me it could just as easily be right after pixels cease, or indeed somewhere else entirely.

[SKS1]

Acorn uses 'flyback' with a very atypical meaning, even though it's right there and clear on the VIDC data sheet.

If you want to check flyback is implemented correctly, or more specifically that the IOC IR pin is high at the correct times. Two Eterna games rely on the IR PIN for syncing:
Ballarena (1990) (Sisteme) - check the animation is correct on the highscore loop
Tactic (1990) (Eterna) - check the animation on the title sequence

From memory, the animation in both game will freeze if IOC IR isn't going high/low correctly.

Actually, minor follow-up on this since I've actually found definitive information hard to come by: do you happen to know exactly when the flyback signal goes active in horizontal terms? I currently have it purely as part of the vertical state machine, so it goes active at the end of the final line with pixels on it, but it strikes me it could just as easily be right after pixels cease, or indeed somewhere else entirely.

For VIDC, see the original ARM data book:
"Vertical Flyback (CMOS level output) - This signal is driven high when the display is in vertical flyback (retrace). Specifically, it is set high at the start of the first raster which is not display data, although this may be border, (at the bottom of the screen), and is cleared down at the start of the first raster which is display data (at the top of the screen)."

[ThomasHarte]

If you want to check flyback is implemented correctly, or more specifically that the IOC IR pin is high at the correct times. Two Eterna games rely on the IR PIN for syncing:
Ballarena (1990) (Sisteme) - check the animation is correct on the highscore loop
Tactic (1990) (Eterna) - check the animation on the title sequence

From memory, the animation in both game will freeze if IOC IR isn't going high/low correctly.

Actually, minor follow-up on this since I've actually found definitive information hard to come by: do you happen to know exactly when the flyback signal goes active in horizontal terms? I currently have it purely as part of the vertical state machine, so it goes active at the end of the final line with pixels on it, but it strikes me it could just as easily be right after pixels cease, or indeed somewhere else entirely.

For VIDC, see the original ARM data book:
"Vertical Flyback (CMOS level output) - This signal is driven high when the display is in vertical flyback (retrace). Specifically, it is set high at the start of the first raster which is not display data, although this may be border, (at the bottom of the screen), and is cleared down at the start of the first raster which is display data (at the top of the screen)."

Oh, what do you know, I must actually have read that (eventually), obeyed it, and then near-instantly forgotten. Cool. That's exactly what my implementation does (given that the end of one line exactly is the start of the next).

Mild ambiguities I've definitely taken a guess at:

• current display address is latched from Vptr at the start of the first line with pixels, i.e. the latest it possibly can be before DMA requests start; and
• in the flyback case I've applied the same interpretation as of horizontal events: display end is taken to define "the first raster which is not display data" regardless of whether vertical blank (i.e. "end of border") actually means that rasters without display data have already happened.

Almost everything else is read live as the display progresses, albeit that the rule of "set display end before display start to disable the display" has made me interpret state in general as two flags, did start and did stop, rather than merely one. So no matter how good your raster racing you can't create a discontinuous display.

[SKS1]

Actually, minor follow-up on this since I've actually found definitive information hard to come by: do you happen to know exactly when the flyback signal goes active in horizontal terms? I currently have it purely as part of the vertical state machine, so it goes active at the end of the final line with pixels on it, but it strikes me it could just as easily be right after pixels cease, or indeed somewhere else entirely.

For VIDC, see the original ARM data book:
"Vertical Flyback (CMOS level output) - This signal is driven high when the display is in vertical flyback (retrace). Specifically, it is set high at the start of the first raster which is not display data, although this may be border, (at the bottom of the screen), and is cleared down at the start of the first raster which is display data (at the top of the screen)."

Oh, what do you know, I must actually have read that (eventually), obeyed it, and then near-instantly forgotten. Cool. That's exactly what my implementation does (given that the end of one line exactly is the start of the next).

Mild ambiguities I've definitely taken a guess at:

• current display address is latched from Vptr at the start of the first line with pixels, i.e. the latest it possibly can be before DMA requests start;

How about that "The Vinit register contains the address to which Vptr will be initialized just before the new display frame begins (denoted by a high-to-low transition on FLBK), and is thus the address of the first byte of video data for the new frame."

[ThomasHarte]

For VIDC, see the original ARM data book:
"Vertical Flyback (CMOS level output) - This signal is driven high when the display is in vertical flyback (retrace). Specifically, it is set high at the start of the first raster which is not display data, although this may be border, (at the bottom of the screen), and is cleared down at the start of the first raster which is display data (at the top of the screen)."

Oh, what do you know, I must actually have read that (eventually), obeyed it, and then near-instantly forgotten. Cool. That's exactly what my implementation does (given that the end of one line exactly is the start of the next).

Mild ambiguities I've definitely taken a guess at:

• current display address is latched from Vptr at the start of the first line with pixels, i.e. the latest it possibly can be before DMA requests start;

How about that "The Vinit register contains the address to which Vptr will be initialized just before the new display frame begins (denoted by a high-to-low transition on FLBK), and is thus the address of the first byte of video data for the new frame."

I'm the worst.

What I really need to do at some point is grab an appropriate RasterMan, translate it to ADF and see how it goes. I'll probably learn a lot, since eyeballing a few select titles obviously only does so much to verify.

If I had to guess? I'll bet there's something wrong not-quite-exactly-right in my timers, most likely their phase and whether it is fixed or determined by CPU interactions. Even when I've fixed my minor VIDC transgressions I'll still be a way off declaring confidence.

[ThomasHarte]

Noting belatedly that I've added a processing delay between pixel data being enqueued for output and it actually being transcribed; I've yet to hit upon either a meaningful mental model or documentation about what causes the differing per-bpp latencies and, relatedly, what would be expected to happen if there were a colour-depth change mid-line, and I wouldn't currently handle the change-of-clock-rate possibility properly either as a side effect of the way I happen to serialise video data in my particular implementation — that's entirely a self-inflicted wound.

But if you were to change colour depth partway along a line then, broadly, you'd get some incorrect output for a while before correct output resumed. With the current just-do-something implementation, you could even e.g. switch from 8bpp down to 1bpp shortly after the end of the nominated display period and get a discontinuous island of 1bpp output just after the end of 8bpp content because the 1bpp latency is an extra 14px.

Regardless, the improper clipping of both James Pond titles is resolved, and the cursor is where it's supposed to be on the desktop in four- and two-colour modes. And as a bonus I've fixed the issue that caused the border to clip the cursor. And one I overlooked about border colour changes within the border and proper serialisation thereof.

On Lotus Turbo Esprit Challenge the colour change is still improperly placed, usually occuring mid-scanline, so I probably need to look harder at that. I notice the sky gradient palette changes in Robocod are also partly mid-line but that could easily be expected.

I've also adjusted my crop so that if you were to select one of the wide modes, it'd all fit. So that's about 95% of the entire PAL area. I keep meaning to implement dynamic automatic cropping, as a whole-emulator feature, but haven't yet.

Still missing: multisync support, and honouring the interlaced flag. Though the latter shouldn't be too heavy a lift, as it works in my code exactly as it would on real hardware — I just need to delay the start and end of long sync by the programmer-supplied amount in one field and insert an extra blank line into the other. Though I'll admit I've yet to spot how a programmer is supposed to differentiate odd/even frames and therefore how you're supposed to build an interlaced output that isn't just the standard height.

So I guess I'll warm up to a new release sometime soon; I've a few other things I want to look at first. But the above is already checked in.

[sirbod]

Noting belatedly that I've added a processing delay between pixel data being enqueued for output and it actually being transcribed; I've yet to hit upon either a meaningful mental model or documentation about what causes the differing per-bpp latencies

I believe the differing HDSR/HDER values are a side-effect of the eight word DMA buffer and how VIDC steps through it depending on the bpp. You can probably completely mess that up by altering the CR DMA request bits.

Although it's not specifically stated, the geometry register values appear to be zero based so are all M-1. I'd also guess VIDC either processes two pixels at a time or pipelines two, so horizontal values have to be divided by 2.

what would be expected to happen if there were a colour-depth change mid-line

I'm not sure that's possible, I believe bpp is fixed at Flyback along with the geometry.

Steve can probably correct me here, but I believe only the palette can change mid-line. It might also be possible to get multiple cursors on screen if the DMA FIFO is observed, although I've never tried.

[ThomasHarte]

I believe the differing HDSR/HDER values are a side-effect of the eight word DMA buffer and how VIDC steps through it depending on the bpp. You can probably completely mess that up by altering the CR DMA request bits.

I haven't yet come up with a completely-valid mental model in part because, prima facie:

• at 19 pixels latency, 1bpp mode is 2.375 bytes 'behind';
• 2bpp @ 11 pixels = 2.75 bytes;
• 4bpp @ 7 pixels = 3.5 bytes;
• 8bpp @ 5 pixels = 5 bytes.

So, I've just hard-coded the latencies and let it be. Possibly that's even fully sufficient, especially if mid-line colour-depth changes aren't effective — though then my current implementation is in the wrong because it will try to do those, but it's also separately in the wrong because it doesn't properly support mid-line clock-rate changes. So I'm not at a more-global 'sufficient' yet.

I'm not sure that's possible, I believe bpp is fixed at Flyback along with the geometry.

Steve can probably correct me here, but I believe only the palette can change mid-line. It might also be possible to get multiple cursors on screen if the DMA FIFO is observed, although I've never tried.

Firstly: I had completely misunderstood your earlier comment — for absolutely no reason other than my own issues, based on review — about latched geometry to be in terms of "if you're writing an emulator and cheating like this, do it at this time". I had not understood that real hardware really latches geometry. So I've also got that wrong. Geometry still isn't latched.

I'm a bit confused by the cursor comment though; I thought the MEMC determines whether a VIDC DMA request is cursor or video merely by whether sync is active? Though even with that said, in my implementation you could trigger the same mouse sprite multiple times by raster racing and altering the start position.

[sirbod]

I've just hard-coded the latencies and let it be. Possibly that's even fully sufficient, especially if mid-line colour-depth changes aren't effective

Mid-line palette changes are possible, although I'm not aware of any games that go to that level of accuracy. They generally change palette across a couple of lines where you'd not notice it, which avoids the issue of IRQ/FIQ delaying palette changes.

Rasterman is the only thing I'm aware of that goes for pixel accurate timing.

it doesn't properly support mid-line clock-rate changes.

I don't believe that's possible given my testing indicated VIDC locks everything in, except the palette, just prior to IR going high.

I'm a bit confused by the cursor comment though; I thought the MEMC determines whether a VIDC DMA request is cursor or video merely by whether sync is active?

To clarify my comment, I was not referring to how the VIDC/MEMC DMA handshake works, but that it might be possible to get the pointer to appear more than once on screen by "chasing the beam" so to speak, provided the VIDC pointer position registers are updated before the pointer FIFO hits a refill...ie by observing the pointer FIFO DMA fill timing.

[ThomasHarte]

I've just hard-coded the latencies and let it be. Possibly that's even fully sufficient, especially if mid-line colour-depth changes aren't effective

Mid-line palette changes are possible, although I'm not aware of any games that go to that level of accuracy. They generally change palette across a couple of lines where you'd not notice it, which avoids the issue of IRQ/FIQ delaying palette changes.

Rasterman is the only thing I'm aware of that goes for pixel accurate timing.

I've yet to look into the appropriate packaging tools that would allow me to try RasterMan given that I currently support only disk images and am not sufficiently short of known defects to need to go searching for more.

Knowing that almost everything is locked in from the end of one flyback to the next also means that I can move to much-more straightforward code than I currently have, so that'd also be smart before getting into further issues.

it doesn't properly support mid-line clock-rate changes.

I don't believe that's possible given my testing indicated VIDC locks everything in, except the palette, just prior to IR going high.

I don't currently support any Archimedes with latch C, which appears to change the VIDC clock speed externally rather than merely setting an internal divider, so I can indeed strike that from the list too.

Otherwise, on the emulator in general: I need to experiment around my current guess at floppy disk RDY, having not found concrete documentation on exactly which form of it the floppy drives produce*, but otherwise I'll probably gear up for a release soon. Besides VIDC improvements I've also added provisional dynamic logic automatically to clock the emulated Archimedes down if an early title such as Zarch is obviously running amok, but haven't yet started looking seriously at automatic software launch. A better dynamic analyser will follow.

I also found that I was accidentally always doing opcode fetch as if running in non-user mode, which I guess might theoretically have led to the wrong results if the MEMC were configured with differing memory maps for user and supervisor but I'm not aware of any concrete problems that caused.

\* I've decided it's probably modified-Shugart, i.e. RDY goes active if two index holes pass after motor on, and then stays active until such time as the disk is ejected. That's as contrasted with classic Shugart where RDY would go inactive again as soon as the motor stopped, and with IBM's version where RDY would require a head step with disk present to go active.