Wish list for 8-bit (and 32-bit) emulation ?

[garfield]

Below is a "pseudo-amalgamation" of many common feaures of emulators. "Our" crop of Acorn 8-bit and 32-bit emulators cover some... but not all of these items.

Is there any emulator capability that is on your personal wishlist?

( My wishes are CRT shaders and monitor barrel distortion.

Code: Select all

FILE	->	HARD RESET
	->	SOFT RESET
	->	LOAD STATE
	->	SAVE STATE
	->	AUTOSAVE STATE SETTINGS
	->	LOAD PREFERENCES
	->	SAVE PREFERENCES
	->	QUIT



EDIT	->	SAVE SCREENSHOT	->	NATIVE SIZE
				->	SMOOTHING
				->	FORMAT

	->	RECORD VIDEO CAPTURE	->	NATIVE SIZE
					->	SMOOTHING
					->	FORMAT
	->	STOP RECORDING VIDEO
	->	SAVE AUDIO	->	FORMAT
	->	PATHS
	->	CONFIGURE KEY SHORTCUTS
	->	PRINT TO FILE
	->	PRINT TO CLIPBOARD
	->	PASTE TEXT



DISC	->	AUTOBOOT FLOPPY 0
	->	AUTOBOOT FLOPPY 1
	->	INSERT FLOPPY 0
	->	INSERT FLOPPY 1
	->	EJECT FLOPPY 0
	->	ELECT FLOPPY 1
	->	NEW BLANK FLOPPY 0
	->	NEW BLANK FLOPPY 1
	->	WRITE PROTECT 0
	->	WRITE PROTECT 1
	->	EDIT CATALOG 0
	->	EDIT CATALOG 1
	->	IMPORT FILE TO DISC 0
	->	EXPORT FILES FROM DISC 0
	->	IMPORT FILE TO DISC 1
	->	EXPORT FILES FROM DISC 1



TAPE->	LOAD TAPE
	->	RECORD TAPE
	->	EJECT TAPE
	->	REWIND TAPE
	->	SPEED	->	NORMAL
			->	FAST



VIDEO	->	FULL SCREEN
	->	HIDE HOST MOUSE POINTER
	->	MONITOR CRT TYPE	->	STANDARD
					->	MULTISYNC
					->	VGA
	->	CRT SHADER
	->	BARREL DISTORTION
	->	SHADOW MASK
	->	ADJUST PALETTE
	->	BLEEDING
	->	FRAME PERSISTENCE
	->	MONITOR CHROMATICS	->	RGB
					->	GREEN SHADES
					->	AMBER SHADES
					->	GREY SHADES
	->	BORDER SIZE 	->	NO BORDERS
				->	NATIVE BORDERS
				->	FIXED BORDERS
	->	SCANLINE EFFECT	-> BLACK GAPS
				-> LINE DOUBLING
	->	RENDERER	->	SOFTWARE
				->	OPENGL
	->	SCALING		->	INTEGER x1
				->	INTEGER x2
				->	INTEGER x3
				->	INTEGER x4
				->	INTEGER x5
				->	INTEGER x6
				->	INTEGER x7
				->	INTEGER x8
				->	DYNAMIC AVERAGING
	->	PIXEL ASPECT RATIO	->	SQUARE 1:1
					->	PAL	16:15
					->	NTSC 10:11
	->	OVERLAYS	->	AUTOHIDE OVERLAYS
				->	SHOW COMPUTER LEDS
				->	SHOW PERIPHERAL DEVICE LEDS
				->	SHOW VIRTUAL MONITOR CRT SURROUND
				->	SHOW FPS
				->	SHOW SPEED PERCENTAGE
				->	OVERLAY VIRTUAL KEYBOARD->	OPAQUE
								->	50% TRANSPARENT



SOUND	->	STEREO
	->	VOLUME	-> FULL
			-> 75%
			-> 50%
			-> 25%
			-> OFF
	->	EMULATE FLOPPY DRIVE SOUNDS	-> FULL
						-> 75%
						-> 50%
						-> 25%
						-> OFF
	->	EMULATE CASSETTE DECK SOUNDS	-> FULL
						-> 75%
						-> 50%
						-> 25%
						-> OFF
	->	EMULATE HARD DISK SOUNDS	-> FULL
						-> 75%
						-> 50%
						-> 25%
						-> OFF
	->	EMULATE KEYBOARD SOUNDS		-> FULL
						-> 75%
						-> 50%
						-> 25%
						-> OFF
	->	EMULATE JOYSTICK SOUNDS		-> FULL
						-> 75%
						-> 50%
						-> 25%
						-> OFF



HARDWARE	->	BASE MODEL
		->	CPU	->	TYPE
				->	WARP SPEED
				->	OVERCLOCK 6400%
				->	OVERCLOCK 1600%
				->	OVERCLOCK 400%
				->	OVERCLOCK 200%
				->	SPEED 100%
				->	UNDERCLOCK 200%
				->	UNDERCLOCK 400%
				->	UNDERCLOCK 1600%
				->	UNDERCLOCK 6400%
				->	ADVANCE FIELD
				->	ADVANCE FRAME
				->	PAUSE
				->	MAGIC REWIND 20 SECONDS
				->	MAGIC REWIND 5 SECONDS
			->	VIDEO CHIP
			->	SOUND CHIP
			->	MAIN RAM SIZE
			->	RAM/ROM BANKS
			->	OS VERSION
			->	HARD DRIVE 0	->	SIZE
						->	HOST MOUNT POINT
			->	HARD DRIVE 1	->	SIZE
						->	HOST MOUNT POINT



CONTROLS	->	KEYBOARD->	MAP KEYS
				->	USE PHYSICAL MAPPING
				->	USE LOGICAL MAPPING
		->	JOYSTICK 0->	CALIBRATE
				->	AUTOFIRE
		->	JOYSTICK 1->	CALIBRATE
				->	AUTOFIRE
		->	SWAP JOYSTICK 0 AND 1
		->	MOUSE	->	X MOVEMENT SCALING
				->	Y MOVEMENT SCALING
				->	MAP MIDDLE MOUSE BUTTON



MISC	->TOOL ASSISTED SPEEDRUN	->	RECORD P1
					->	PLAY BACK P1
					->	RECORD P2
					->	PLAY BACK P2
		->SYNTHESIZE INPUT	->	VIRTUAL P1->	PLAY BACK KEYBOARD P1
							->	PLAY BACK JOYSTICK P1
							->	RECORD INPUT P1
							->	RANDOM P1	->	TRUE RANDOM
										->	SEED PRNG
										->	PRNG
					->	VIRTUAL P2->	PLAY BACK KEYBOARD P2
							->	PLAY BACK JOYSTICK P2
							->	RECORD INPUT P2
							->	RANDOM P2	->	TRUE RANDOM
										->	SEED PRNG
										->	PRNG



NET	->	JOIN NETPLAY
	->	HOST NETPLAY SETTINGS
	->	DISCONNECT FROM NETPLAY



DEBUGGER	->	ENABLE
		->	SET BREAKPOINTS
		->	LIST BREAKPOINTS
		->	EDIT BREAKPOINTS
		->	REMOVE BREAKPOINTS
		->	SEEK TO
		->	RUN TO CURSOR
		->	BREAK
		->	RUN
		->	NEXT STEP
		->	SHOW STATUS FLAGS
		->	DISASSEMBLE RANGE
		->	MARK AS DATA
		->	SHOW STATUS FLAGS
		->	MEMORY WATCH
		->	SHOW STACK
		->	ADD ADDRESS BOOKMARK
		->	NAME ADDRESS BOOKMARK
		->	DELETE ADDRESS BOOKMARK
		->	IMPORT SYMBOLS
		->	EXPORT SYMBOLS
		->	TRACE TO FILE
		->	SHOW PROCESSOR REGISTERS
		->	SHOW MEMORY-MAPPED REGISTERS
		->	SYNTHESIZE RASTER BEAM



COMMAND LINE SWITCHES	->	HELP
			->	VERSION

[Pernod]

( My wishes are CRT shaders and monitor barrel distortion.barrel.jpg

You can already do this in MAME, and have been able to for many, many years.

[Coeus]

Is that accurately representing the technology of the day, or is that a bit like the Mercator map projection where a globe is forced into a flat plane?

Yes, CRTs have a convex curve to the front of the screen in one or both directions, depending on the type, but because we view them in 3D, I don't believe we would be aware of barrel distortion to the extent shown here. What is shown here is what a camera would see.

[joachim]

Why not "magic rewind frame"?

[BeebMaster]

Yes, emulating known faults with hardware, as I first proposed here 364 days ago.

[tnash]

I'd like the Owlet editor or similar in a little side window alongside b-em, operating directly on the program in the emulated beeb's memory, but with all the nice modern highlighting and mouse-driven editing functions. *BE is fine but this would be better.

(Someone will likely tell me this is possible already... if so, brill)

[garfield]

Yes, emulating known faults with hardware, as I first proposed here 364 days ago.

Interesting idea.

[garfield]

Why not "magic rewind frame"?

In addition to these? Actually, yes, you're right, that would make sense too!

[joachim]

In fact there's a few things you could do if you can put together the memory and data structures for an efficient rewind feature. For example "step backwards 1 instruction" and "rewind until breakpoint".

[frankc]

Some mechanism to communicate with external hardware.

That IMHO the singular characteristic of the BBC was its ease of interfacing to the real world. The Tube, 1 MHz bus, ADC x 4, user port etc.
All this is lost in the world of emulators.

The only thing that came close to having similar "feel" was the Arduino (I accept that your feelings may differ!) Having used Arduino extensively over the years has convinced me, that they do offer the possibility of "emulating" the original BBC hardware.
With suitable libraries on the Arduino, a solid communication protocol, and the necessary libraries internal to the emulator, a level of functionality could be restored.

Of course I speak from a position of ignorance as the level of expertise required, on the emulator side, is beyond me.

Anyone got an opinion pro or con.

Thanks
Frank C.

P.S. perhaps this has already been proposed and I have been asleep at the wheel. That often happens.

[paulb]

Some mechanism to communicate with external hardware.

That IMHO the singular characteristic of the BBC was its ease of interfacing to the real world. The Tube, 1 MHz bus, ADC x 4, user port etc.
All this is lost in the world of emulators.

The only thing that came close to having similar "feel" was the Arduino (I accept that your feelings may differ!) Having used Arduino extensively over the years has convinced me, that they do offer the possibility of "emulating" the original BBC hardware.
With suitable libraries on the Arduino, a solid communication protocol, and the necessary libraries internal to the emulator, a level of functionality could be restored.

The Arduino does provide very direct access to the hardware, but there is no reason why you couldn't have a more sophisticated computer offering similarly low-level access to things like input/output pins without having an Arduino involved. With boards like the Raspberry Pi, there is an emphasis on exposing various pins on the board as general-purpose input/output pins that high-level software can use. Such mechanisms should be available to emulators running on those boards.

The situation is slightly more awkward with traditional desktop and laptop personal computers. Although these might also have interfacing pins available, you might need to dig around to find out what they are, and then there would be an exercise involved in exposing them via the operating system. Here, I could imagine an Arduino being useful as a kind of interfacing accessory, which seems to be what you are suggesting. You might drive it over the serial connection with a program on the Arduino interpreting read and write commands, maybe even providing interrupt notifications to the emulator.

A few months ago, I extended Elkulator to support serial communications. The motivation for this was to simulate serial interfacing to other computers, with the host computer being connected to the emulated Electron via a Unix socket. The host computer then ran a server that invoked /bin/login for any incoming connections from the Electron. It was also able to communicate with a special filing system ROM on the Electron to serve files and provide printing capabilities.

Such serial support could be repurposed more generally. Instead of connecting the emulator to a Unix socket, it could connect directly to a serial device. And instead of intercepting accesses to page FC, interpreting these as operations using the SCN2681 serial/DUART chip, and then issuing reads and writes on a serial connection, such accesses to page FC might themselves be encoded and sent across the serial connection. There would be a protocol encoding writes, reads and results that the Arduino software (or something running on the host) would act upon.

Quite what the Arduino would do when being asked to, say, read from &FC28 would be defined by the Arduino program. Maybe it would interpret that in the context of the circuit it is attached to. Perhaps the simplest interfacing would involve the parallel port, with accesses to &FC71 associating various bits with input/output pins on the Arduino. That would closely model what you get with a real Electron and Plus 1.

In summary, what you are asking for is already being done to an extent, but specific interfacing with an Arduino would probably require specific programs. It sounds like a fun project!

[Coeus]

That IMHO the singular characteristic of the BBC was its ease of interfacing to the real world. The Tube, 1 MHz bus, ADC x 4, user port etc.
All this is lost in the world of emulators.

I think you're right that this area has received little attention. Usually, emulation of old machines is done to be able to run the software that was written for them, rather than enable a modern PC to fully take the place of the original hardware in interfacing to other external devices. That means that, while emulators usually do something to emulate the various interfaces, they do it not by bringing that out of the PC exactly as it woud have been BITD, but doing something that makes sense from a software point of view. So, for example:

• The printer port. An emulator is likely to capture whatever is written here and forward it to the host OS for printing , or maybe capture to file that can be processed first, for example to convert Epsom escape codes to Postscript.
• The ADC. Joysticks were often connected here so an emulator is likely to provide some input linked to a PC device that can behave in the same way, such as a USB-connected game controller or the mouse.
• The 1Mhz bus. Rather than emulate the bus, emulators will tend to emulate things that sit on that bus, like a SCSI controller that accesses a hard disc image file or a Music 5000 emulation that feeds the host sound system so you can hear what a real Music 5000 would have played without having one.
• The Tube. B-Em, at least, emulates the tube processor (any of them) as well so you can run software written for a BBC Micro + 2nd processor without needing either the BBC micro or the relevant 2nd processor.

For doing things with real, external hardware, I get the impression that there are reasonable solutions out there for writing programs directly on a device which has external I/O capability. The Arduino and Raspberry Pi are obvious examples but I believe there are others. Some of these devices come with a USB implementation so it would also be possible to do a minimum in firmware on the device and then write the more complex part of the software on a PC. One example of this kind of USB device is the teensy - I have one as a keyboard protocol converter which talks the PC/XT KB protocol to an old IBM Model F keyboard and the modern USB keyboard protocol to the PC but these devices seem quite flexible and could do many other things.

If you particularly want to have a BBC micro emulator access the external world, one of these USB devices is one way to do it. I also think some of the FTDI USB serial converters are capable of a bit more than just serial communication or at least can be pressed into service for other things and have the advantage that, to the PC, they look like a serial device so there is no need to mess with customer drivers.

[frankc]

Just a few added thoughts:
Whilst I don't want to get locked into waving the flag for any particular approach I do believe that a usb connection, being universal, does represent a good approach and it is for that reason I zeroed in on the Arduino. Its generous I/O capabilities - parallel, AtoD & Serial are already there & extremely flexible. All the physical aspects of a programmable I/O platform are done, they already exist. Writing native Arduino code is straightforward with AVR C for the more adept. Based on my own experience I can easily visualise what need to be done on the Arduino side.

Two main areas then remain
1) a messaging protocol for communicating between emulator and the Arduino I/O platform and
2) the more difficult task of reengineering the areas of the (emulated) BBC OS that deals with the I/O issues, transforming from their existing memory mapped paradigm to a new paradigm of commands issued to the I/O hardware via the USB connection.

Successfully done you then have a solution that is independent of the hardware running the Emulator. If a I/O box is plugged in to a USB port then the Emulator has access to the I/O functions - and the Beeb is whole again.

I have no idea what the scale of the task, in the rewrite I mention, would be and I have glossed over many details but I do believe it would be a worthwhile endeavour.

FC

[paulb]

Two main areas then remain
1) a messaging protocol for communicating between emulator and the Arduino I/O platform and
2) the more difficult task of reengineering the areas of the (emulated) BBC OS that deals with the I/O issues, transforming from their existing memory mapped paradigm to a new paradigm of commands issued to the I/O hardware via the USB connection.

You wouldn't need to change the OS at all. Instead, memory accesses to I/O addresses like those in page FC would be encoded and forwarded across the serial connection to the Arduino. Let us say that you had an Arduino shield that provided a traditional parallel port connected to various I/O pins. The Arduino code would listen for writes to &FC71 and then present the output on the appropriate pins. As far as the OS is concerned, it would be writing to &FC71 as normal.

I have no idea what the scale of the task, in the rewrite I mention, would be and I have glossed over many details but I do believe it would be a worthwhile endeavour.

For Elkulator (and so not one of the Beeb emulators, but the principles are the same), I've probably done most of the work to provide the low-level serial communication. Clarifying/correcting what I wrote earlier, what I made Elkulator do was to bind to a Unix socket and act as a server. Then, a client connects to Elkulator to interact with it.

For my serial emulation, I have a client that merely connects to provide a kind of interactive console (remote login for the Electron!), but another acts as a relay, sending data from Elkulator to a login session and sending the responses back to Elkulator, allowing the Electron to act as a Unix terminal. But what such a relay could do instead is to connect to the Arduino (using /dev/ttyUSB0 or whatever) and interact with that using the data being produced by Elkulator.

Code: Select all

Elkulator -- (Unix socket) -- relay -- (serial device) -- Arduino

Elkulator could be made to connect to directly to the Arduino via the serial device, but there might be some benefits in distributing the functionality. Keeping the support minimal in Elkulator has its advantages, not least the ability to avoid doing a lot of work in a lower-level language.

I am inclined to prototype this, just to demonstrate that it can be done, but I can't commit to any timescales!

[Nerdilicious!]

As a user of front-ends like Retropie/Emulation Station and Launchbox, some quality of life additions would be very useful…

All systems
Consistent joypad mapping, with general and per-game configurations that can be loaded alongside a game file when invoked on the command line. Crucially, allow a button or combo to quit the emulator returning control to the front-end.

RISC OS
Most BBC games are available as shift-break bootable disk images which means starting them from a front-end works pretty well. However on RISC OS, with the possible exception of Arthur-era and some RISC OS 2 games, they can't be auto booted meaning the user has to click on a disk icon, find the game and double-click on that, possibly followed up with another click on the game's icon on the icon bar. Not a great experience if you just want a quiet game of mashing gerbils in Hamsters sat on your sofa with your controller in hand.

Could a possible way around this is to implement some sort of scripting language support, which could implement those manual steps (insert disk image, click on disk icon, double-click on game, set correct MODE, etc.)? If that were possible maybe also an option to blank screen output until the game starts, with the emulator running as fast as possible up to this point, where on game load the speed reverts to that of the emulated computer?

[Grasshopper]

If someone created a set of Libretro cores based around the already existing BBC Micro, Electron, and Atom emulators, then a lot of the features being asked for in this thread would automatically become available as part of the Libretro framework.

Admittedly, that would involve quite a lot of work. However, it would still presumably be less work than recreating all of the new features from scratch. There's no point in reinventing the wheel.

As a bonus, it would also enable the Acorn emulators to be better integrated with emulation platforms such as Batocera and Retropie, as many of those platforms are based around RetroArch/Libretro.

https://docs.libretro.com/meta/core-list/

The one exception is interfacing with the real world. But if you want to do that, then I think it's probably better to use FPGA based emulation as your starting point.