XRoar wish/patch info?

[paul]

Hi, I have a strange-ish requirement and I'd love to make XRoar help me

My plan is to create a hardware 'addon' for a D32/64 with extended memory/MMU, extra I/O etc. Obviously for the hardware I have to use real hardware, but I'll be wanting to write OS9 drivers for it, and that's where it gets tricky.

In the 'old days', I'd write the driver and then test it, let the D64 crash, go back try to work out why, re-assemble, try again, and so on.

As far as I can see, I should be able to use XRoar with GDB to do something better nowadays

The problem is that I'll have custom hardware. The aim is that it'll be in a cartridge port, but I'll be triggering DSD to disable the SAM's memory map handling, and providing some RAM & I/O via the cartridge port (covering the whole address space, not just the 'cartridge' area).

Ideally, XRoar would have some way to do this already, but I don't think it currently supports the DSD line. Am I right that I'll need to hack something into the 'read_byte' and 'write_byte' functions in machine.c to do what I want?

Any chance of XRoar supporting user-created cartridges and the DSD line?

[sixxie]

It certainly can do - only reason I've not put it in so far is that nothing's needed it. Also it involves an extra function call each cycle.

I guess the way the hardware would work is that you'd pull EXTMEM(DSD) low on Q rising (at which point A, R/¬W should be valid).

In terms of code it's not broken down to fractions of a cycle, but the order is important here so I'd pass R2 as well as P2 to the cart's read() and write() routines, then call them *first* with neither set - cart code then has the opportunity to assert EXTMEM which read_byte() and write_byte() could recognise and skip device selection.

Your own cart code would then "subclass" (inasmuch as anything is classes around here) struct cart in the same way as dragondos.c, etc. and should work.

Maybe now's the time to do the work and use libdl so carts can be external dynamically linked .so files... Or maybe this can just be kludged

[robcfg]

It would certainly be nice to be able to emulate cartridges like jcb's speech and sound ones.

Also to emulate the touchmaster tablet would be a hit!

[paul]

It would be cool if the cart code was able to assert EXTMEM/DSD, but I do realise it's probably not widely needed and it could affect performance. I don't know how tight performance is - I guess it depends on host PC's performance. If it affects it too much, I guess you could always have conditional compilation, so the normal download doesn't allow it, but you can build from source if you do need it.

It would be best if you supported dynamic libraries (ideally DLLs on Windows too) for carts.

What I was actually thinking of for myself is to allow the cart code to be written in Lua, so it'd allow customisation without recompiling. If you support dynamic libraries, then I could make one which supports Lua. I've integrated Lua with the software I write as my day job, so I'd be up for this

I don't know if Lua would be performant enough, but a quick test with a Lua script calling a Lua function 1,000,000 times and doing a bit of logic testing in the function takes about 0.1 seconds on my PC, so it may not be too far off, and given I'd be using it for development & debugging, I'd be OK with a slight slowdown. Lua is designed as an embedded language and is written in C, so it should work with XRoar AFAICS.

[jedie]

I would suggest Python

[paul]

I would suggest Python

Ugh.

See: these benchmark results

Lua is almost the fastest interpreted script language - Python is almost the slowest (only Bash is slower)

Also, Lua is tiny, written in C, and specifically designed for embedding - Python isn't

There's a reason games like WoW use Lua internally, not Python.

[sixxie]

In lieu of lua, if you're ok with git, have a shuftie at the last commit in the "extmem" branch of the repository...

Code: Select all

git clone -b extmem http://www.6809.org.uk/git/xroar.git

Edit: as for Lua itself, I've considered this before. I see the most recent version supports integers and bitwise operators, so it now looks eminently suitable (apart from its historical mad choice - you know the one...).

[tormod]

I am very interested in an extmem feature too. I made a quick and dirty patch* for emulating my memory cartridge for Fuzix but something more clean and modular would be nice. Anyway, the patch can serve as an example of what is needed for a quick hack, and there is no speed penalty to speak of.

*) https://github.com/EtchedPixels/FUZIX/b ... nx32.patch