Sideways RAM Utilities

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Sideways RAM Utilities

Postby fordp » Wed May 03, 2017 8:03 pm

As part of my MaxRAM project I will need some sideways RAM utilities and wondered what was already out there to use as a basis for a ROM for the project.

My 6502 assembler is poor. The only 6502 assembler I ever wrote was actually a small routine to load a ROM from disc in to Sideways RAM (2 x 6264 I think) on a RAM/ ROM board I no longer have. That was in 1986 however. I will have a go of course.

I have never made a ROM. I have had a great contribution of code that should allow writing to the flash chip on my project after a few tweaks.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
hoglet
Posts: 6597
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Sideways RAM Utilities

Postby hoglet » Wed May 03, 2017 8:22 pm

Ford,

FYI, Steve (Coeus) has just submitted a pull request to MMFS with some simple SRAM Utilities:
https://github.com/SteveFosdick/MMFS/commits/sf/sram

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Wed May 03, 2017 8:23 pm

Check out https://github.com/SteveFosdick/MMFS/bl ... m/sram.asm

This is a module intended to go into the Bootstrap version of MMFS, i.e. the version that copies itself into sideways RAM and maybe other version too, which adds some sideways RAM utils. This is a simpler version than than on the Master/B+ from Acorn. All that is missing, because the bootstrap module, bootstrap.asm, provides it, is the ROM header and dispatching the service call to oscmd or help.

I also have, though not on-line, a disassembly of the Acorn B+/master SRAM, i.e. that bundled into later version of DFS. I have 1.03 (DFS 2.23) and 1.05 (DFS 2.26) in which I have started to put names to the subroutines. This also includes a table giving corresponding addresses for the two version. Let me know if you want to look at that.

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Wed May 03, 2017 8:45 pm

Further to my last message, some thoughts on the difference between the implementation I am proposing for MMFS and the Acorn one supplied as part of the B+/Master DFS. I mentioned that the Acorn implementation is more complex. It also has the following cons:
  1. It is bigger - it wouldn't fit in the spare space in MMFS Bootstrap
  2. It assumes the sideways RAM is in the slots used on the B+/Master.
  3. It is limited to tracking four banks.
  4. It assumes it can use some of the DFS workspace.
  5. It refuses to save ROMs.
It also has some advantages:
  1. It provides an OSWORD call to load/save from sideways RAM.
  2. It provides an OSWORD call to copy from/to main ram to/from sideways RAM.
  3. It provides commands (SRREAD/SRWITE) to copy from/to main ram to/from sideways RAM.
  4. It supports loading files into sideways RAM at an arbitrary start address, not just at the beginning (&8000) and saving an arbitrary piece of sideways RAM to a file.
  5. The default mode doesn't use the main RAM from OSHWM to HIMEM as a buffer. Instead it uses either OSGBPB and some DFS workspace to load the file in chunks or, if the filing system doesn't support OSGBPB, falls back to OSBGET/OSBPUT (which is almost universally slow.

The Acorn implementation also has an elaborate scheme whereby you can designate a ROM as either a ROM image or data and then, on top of that, implements a pseudo-addressing scheme, i.,e. you specify an address between 0000 and FFFF and it will count through the ROMS marked as data to find the one corresponding to the address.

I personally have never had a use for all this extra complexity. I'd be interested to hear any comments about this.

cmorley
Posts: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: Sideways RAM Utilities

Postby cmorley » Wed May 03, 2017 8:46 pm



It looks like you use page 1 (stack) for the "low" code in your routines... why start at 0x102 and not 0x100?

(cute write protect btw ;))

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Wed May 03, 2017 9:03 pm

cmorley wrote:


It looks like you use page 1 (stack) for the "low" code in your routines... why start at 0x102 and not 0x100?


The code also builds an OSFILE control block starting at 0100, of which the first two bytes are the address of the filename. The code that finds, and skips over, the filename when parsing the command stores the address of that filename at 0100 ready to form part of that OSFILE control block but then I found I needed to run some low code, to test if a bank is RAM, when parsing the ROM ID, before I finish building the control block so rather than store the filename address temporarily somewhere else and then put it back to 0100 after I just moved the low code up two bytes to leave the filename address untouched.

cmorley wrote:(cute write protect btw ;))


Well, as I intended to use this myself and I have two of your sideways RAM modules, it made sense to implement your write protect scheme. It is conditionally compiled because I don't know how many different write protect schemes are out there and whether things would get out of hand if we tried to support them all.

duikkie
Posts: 2689
Joined: Fri Feb 07, 2014 3:28 pm

Re: Sideways RAM Utilities

Postby duikkie » Thu May 04, 2017 4:22 am

i have somewhere written the begin code of making a ROM . was is not something like making a rom
it is the header that all roms have. the rest is assemble code you must add for your routine.

User avatar
Rich Talbot-Watkins
Posts: 1111
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Sideways RAM Utilities

Postby Rich Talbot-Watkins » Thu May 04, 2017 9:59 am

Here's the stub code I use for the most tedious part of sideways ROM authoring - handling *-commands and *HELP! Plus a few utility routines to print strings, generate errors, etc. Been a while since I tried it, but it seems to work OK.

Not sure if that's what you're looking for, but it here it is anyway (BeebAsm format).

ROMGeneric.txt
(6.19 KiB) Downloaded 40 times

User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Sideways RAM Utilities

Postby fordp » Thu May 04, 2017 12:53 pm

Thanks everyone for your help so far. The chips for my MaxRAM project arrived today, so progress is being made ;)
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Thu May 04, 2017 3:39 pm

Coeus wrote:I personally have never had a use for all this extra complexity. I'd be interested to hear any comments about this.

I think this comment might have been made already, but FWIW...

I have never used 99% of the complexity, and IMO the OSWORD etc stuff is particularly useless as by using it you rule out compatibility with various third party SWRAM modules on the BBC B.

However, I think it would be nice if your *SRLOAD was Acorn compatible, both to allow some chance for a !BOOT file to be cross platform and for the sake of 'finger macros' when moving between different machines as a user. It's practically burned into my brain to do '*SRLOAD MYROM 8000 Z Q' and I like that it works on a B+128k or Master without me remembering the physical bank number. I appreciate it adds code, but if you could accept but ignore the address and 'Q' and (ideally) turn Z into 'the highest RAM bank on this machine' or (almost as good) 'any RAM bank on this machine' it would be nice. If you can't squeeze this in, better to have even a non-standard SRLOAD than none.

(Disclaimer: I may never use your code, I'm just shoving my oar in. :-) There is a slim chance I might try creating a version of the B+12K MMFS with your utils in the workspace area of the ROM, to make it more palatable to have it installed as the sole filing system, but I may never get round to it.)

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Thu May 04, 2017 5:06 pm

Random "since it's not me doing the work" thought :-) : could the bootstrap MMFS ROM contain a compressed copy of MMFS (using e.g. tricky's algorithm with fast decompression code) to free up space for more goodies?

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Thu May 04, 2017 8:17 pm

SteveF wrote:Random "since it's not me doing the work" thought :-) : could the bootstrap MMFS ROM contain a compressed copy of MMFS (using e.g. tricky's algorithm with fast decompression code) to free up space for more goodies?


That might require a little more work than it first appears. The bootstrap also contains code to compare the SWRAM copy of MMFS with the embedded copy and report a mismatch. So after each break either the copy to SWRAM is done or the comparson is done (and then a copy if it fails). These were all noticably slow on the Electron so hoglet spend some time optimising it - it now copies a page from ROM to low RAM, switches RAM banks, and copies the page back to sideays RAM and then does the next page. There is also some loop unrolling.

So, I don't know how well this will work with compression, or whether decompression would add a noticable delay. Is there a description of the algorithm or any code published?

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Thu May 04, 2017 8:27 pm

There may be some more recent tweaks to the code on stardot itself, but the original thread was on Retrosoftware and can be seen here: http://www.retrosoftware.co.uk/forum/vi ... f=73&t=999 I'd guess that will give you the basics anyway.

Could the comparison on BREAK be replaced by calculating a checksum instead and comparing that against a known good value? That might be faster than decompressing in order to compare. But I appreciate this is all just piling on the complexity. :-)

User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Sideways RAM Utilities

Postby fordp » Thu May 04, 2017 8:48 pm

I think MaxRAM will have no need for compression as it has 32 flash pages.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Thu May 04, 2017 8:58 pm

fordp wrote:I think MaxRAM will have no need for compression as it has 32 flash pages.


We had kind of drifted into a discussion of SRAM utilities in the context of MMFS, perhaps because this is where I had publicly anounced what I had been working on. Originally I posted this as a comment on a GitHub issue for MMFS but there was obviously some crossover.

If you have the space to devote a whole ROM image you'd have no problem of space - you'd have loads to spare. But, that doesn't mean a sensible set can't be provided in much less space. As the Acorn utils are part of the DFS ROM and as the bootstrap version of MMFS allows you to have OSHWM down at E00 but only provided you don't have another ROM in, like DFS, that pushes it up that was the obvious canidiate in the MMFS suite to have SRAM utils - you could then remove DFS.

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Thu May 04, 2017 9:05 pm

SteveF wrote:There may be some more recent tweaks to the code on stardot itself, but the original thread was on Retrosoftware and can be seen here: http://www.retrosoftware.co.uk/forum/vi ... f=73&t=999 I'd guess that will give you the basics anyway.

Could the comparison on BREAK be replaced by calculating a checksum instead and comparing that against a known good value? That might be faster than decompressing in order to compare. But I appreciate this is all just piling on the complexity. :-)


Ok, so if I was writing this for the BBC, i.e. not trying to solve the performance issue on the Electron, it would be simple enough to make the decompressor the bit that runs in low RAM for transferring from the compressed image in the ROM to the uncompressed version in RAM. It would just need to have ROM switch code added at the appropriate points.

It may be more complicated to do this and solve the electron issue but, if the the copy was only done on power-on or on ctrl-break if the checksum is invalid, maybe the performance wouldn't be so critical.

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Thu May 04, 2017 10:07 pm

Coeus wrote:
fordp wrote:I think MaxRAM will have no need for compression as it has 32 flash pages.


We had kind of drifted into a discussion of SRAM utilities in the context of MMFS, perhaps because this is where I had publicly anounced what I had been working on. Originally I posted this as a comment on a GitHub issue for MMFS but there was obviously some crossover.


Yes, sorry - I may have accidentally hijacked the thread.

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Thu May 04, 2017 10:50 pm

SteveF wrote:However, I think it would be nice if your *SRLOAD was Acorn compatible, both to allow some chance for a !BOOT file to be cross platform and for the sake of 'finger macros' when moving between different machines as a user. It's practically burned into my brain to do '*SRLOAD MYROM 8000 Z Q' and I like that it works on a B+128k or Master without me remembering the physical bank number. I appreciate it adds code, but if you could accept but ignore the address and 'Q' and (ideally) turn Z into 'the highest RAM bank on this machine' or (almost as good) 'any RAM bank on this machine' it would be nice. If you can't squeeze this in, better to have even a non-standard SRLOAD than none.


I did wonder how widespread the pratice of relying on this syntax was, though there is also that having, never owned a master, and therefore having never got into the habbit of specifying the 8000 start address, it is more convenint for me for the command not to require it. The two need not necessarily be exclusive, though. One option would be skip an 8000, if present, before the ROM Id. Space permitting it would be good to give a warning if a value other than 8000 was given. So how should the letters to identify RAM banks work - start with Z as the highest numbered bank and work backwards through the alphabet? If I was to add code to count RAM banks another option that might be useful is to be able to miss off the ROM ID completely and SRLOAD would just choose the first bank that doesn't seem to already have a ROM in it. So much depends on time and space but I'll have a think.

And, I hope this more nearly back on topic because it is discussing what would be useful features of a sideways RAM utils implementation.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Sideways RAM Utilities

Postby sweh » Fri May 05, 2017 12:13 am

fordp wrote:As part of my MaxRAM project I will need some sideways RAM utilities and wondered what was already out there to use as a basis for a ROM for the project.

My 6502 assembler is poor. The only 6502 assembler I ever wrote was actually a small routine to load a ROM from disc in to Sideways RAM (2 x 6264 I think) on a RAM/ ROM board I no longer have. That was in 1986 however. I will have a go of course.

I have never made a ROM. I have had a great contribution of code that should allow writing to the flash chip on my project after a few tweaks.

Check out my RAM Manager; https://sweh.spuddy.org/Beeb/2M128/

I've attached a relatively generic version with the following commands:

Code: Select all

>*HELP MANAGER

RAM Manager 2.0
  BYPASS <rom> <command>
  FILECOM <command>
  FILESYS
  HARDBREAK
  NLE
  NOROM <rom>
  PROMS
  RAMCLEAR <bank>
  RESET
  RINSERT <rom>
  ROUTE <rom> <command>
  SRLOAD <fsp> <address> (bank) (Q)
  SRMENU <1 / 0>
  SRREAD <mem st> <end> <swr> (bank)
  SRSAVE <fsp> <start> <end> (bank) (Q)
  SRSTATUS
  SRWIPE <bank>
  SRWRITE <mem st> <end> <swr> (bank)
  STANDARD
  TESTRAM
  TUBEON
  TUBEOFF
  UNPLUG <rom>
  YESROM <rom>
Attachments
GENERIC_ROM.zip
(7.67 KiB) Downloaded 14 times
Rgds
Stephen

User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Sideways RAM Utilities

Postby fordp » Fri May 05, 2017 6:47 am

SteveF wrote:
Coeus wrote:
fordp wrote:I think MaxRAM will have no need for compression as it has 32 flash pages.


We had kind of drifted into a discussion of SRAM utilities in the context of MMFS, perhaps because this is where I had publicly anounced what I had been working on. Originally I posted this as a comment on a GitHub issue for MMFS but there was obviously some crossover.


Yes, sorry - I may have accidentally hijacked the thread.


Your work on a RAM based version of MMFS are very relevant as I am guessing most people who want MaxRAM will also want MMFS.

I will continue to mix things up here with a question for Hoglet (Dave).

Could MMFS fit in to 12K (0x3000) say if the tube code was removed and transferred to the ROM manager?
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Sideways RAM Utilities

Postby fordp » Fri May 05, 2017 6:54 am

sweh wrote:Check out my RAM Manager; https://sweh.spuddy.org/Beeb/2M128/

Thanks for this I will add it to Github in the sweh folder if that's OK.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Prime
Posts: 2345
Joined: Sun May 31, 2009 11:52 pm

Re: Sideways RAM Utilities

Postby Prime » Fri May 05, 2017 8:27 am

Hi all,

If this is any use it's the source to the RAM utils I wrote for the original SWR board, and also what is included with the Electron Plus 3 RAMROM which does the bootstrap from ROM to RAM on that board.

To assemble you will need BeebAsm, and a make utility, though you could of course look at the Makefile and replicate it in a batch file if you don't have Make :)

RamUstilsV0990-2017-05-05.zip
(123.16 KiB) Downloaded 10 times


Cheers.

Phill.

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Fri May 05, 2017 9:51 am

Coeus wrote:
SteveF wrote:It's practically burned into my brain to do '*SRLOAD MYROM 8000 Z Q' and I like that it works on a B+128k or Master without me remembering the physical bank number. I appreciate it adds code, but if you could accept but ignore the address and 'Q' and (ideally) turn Z into 'the highest RAM bank on this machine' or (almost as good) 'any RAM bank on this machine' it would be nice.


I did wonder how widespread the pratice of relying on this syntax was, though there is also that having, never owned a master, and therefore having never got into the habbit of specifying the 8000 start address, it is more convenint for me for the command not to require it. The two need not necessarily be exclusive, though. One option would be skip an 8000, if present, before the ROM Id. Space permitting it would be good to give a warning if a value other than 8000 was given. So how should the letters to identify RAM banks work - start with Z as the highest numbered bank and work backwards through the alphabet? If I was to add code to count RAM banks another option that might be useful is to be able to miss off the ROM ID completely and SRLOAD would just choose the first bank that doesn't seem to already have a ROM in it. So much depends on time and space but I'll have a think.

Thanks for considering this anyway! I agree the 8000 should be optional; your syntax is nicer.

Converting letters to numeric banks could be done in multiple ways and I wouldn't have any really strong feelings - Z as highest working backwards just seemed natural to me. I don't think the ordering is that 'logical' on the B+ anyway (but I could be wrong). You'd maybe want to ignore the MMFS bank of sideways RAM in this mapping though; I could see arguments either way. I'd suggest that however it works that the letter-number mapping should be stable on any particular machine, but I imagine this will just happen automatically.

It would be a very nice feature to be able to omit the bank altogether and have it automatically chosen.

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Fri May 05, 2017 10:25 am

SteveF wrote:...You'd maybe want to ignore the MMFS bank of sideways RAM in this mapping though; I could see arguments either way.


Interesting point. Actually that has reminded me of a couple of other subtleties. At the moment the SRWIPE command clear the ROM type bye on the OS table to prevent service calls but SRLOAD doesn't. Perhaps it should to stop a crash if the ROM being overwitten is used in the background.

The bootstrap code searches for the highest numbered ROM bank to put MMFS in and re-checks it is still there on break so there is no point i trying to load something else there and expect it to stay. Not that this is a promise of implementation but it just occurred to me that the bootstrap code could record the bank it choose in the "workspace" byte for the bootstrap ROM (the one in an OS table that most ROMS use to store the start of their private workspace) and the SRAM code could search for RAM starting with the next bank down because we already know there is none in any higher bank.

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Sideways RAM Utilities

Postby SteveF » Fri May 05, 2017 10:40 am

I think you're talking about the byte at IIRC &2A1+bank, and that makes sense, but does it also make sense to zero the private workspace byte at &DF0+bank on SRLOAD? I haven't checked what your code or Acorn's code does, I just thought I'd ask.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Sideways RAM Utilities

Postby sweh » Fri May 05, 2017 4:44 pm

fordp wrote:
sweh wrote:Check out my RAM Manager; https://sweh.spuddy.org/Beeb/2M128/

Thanks for this I will add it to Github in the sweh folder if that's OK.

Let me work on a clean up of the build process. At the moment some of the code is duplicated from the HostFS:UPURS project (my Makefile literally copies the files over); it'd be good to have these things properly organised :-)
Rgds
Stephen

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Fri May 05, 2017 5:49 pm

sweh wrote:
fordp wrote:
sweh wrote:Check out my RAM Manager; https://sweh.spuddy.org/Beeb/2M128/

Thanks for this I will add it to Github in the sweh folder if that's OK.

Let me work on a clean up of the build process. At the moment some of the code is duplicated from the HostFS:UPURS project (my Makefile literally copies the files over); it'd be good to have these things properly organised :-)


Stephen,

Thanks for reposting this. I remember that I tried it previously, but didn't manage to work out which version I should use or how to build it, though I admit I was not very patient at the time. But tidying up the build process would probably help.

This also raises the point about having a number is small things share a ROM. It would be great to have some standard way in which such things as command tables and help strings could be extracted from separate modules and built into a piece of common code and everything combined in a ROM. I know Martin B has done something similar and it looks like JGH may have too but I have not had a chance to look in any more detail.

BTW, thanks for the excellent "beeb" utility I used to work with SSD images and the BEEB.MMB file for MMFS.

User avatar
fordp
Posts: 917
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Sideways RAM Utilities

Postby fordp » Sat May 06, 2017 11:19 am

Looks like there is already lots of great code out there. Thanks everyone.

It would be great if we can get a project going on Github to make a great ROM.

I would like to then make a build option that suits the extra capabilities of MaxRAM.

I am happy to supply boards to people who would like to help with a ROM when I have them working. I only have three on order at the moment. Once the design is working and proven I will make some more.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Coeus
Posts: 458
Joined: Mon Jul 25, 2016 11:05 am

Re: Sideways RAM Utilities

Postby Coeus » Sun May 07, 2017 12:04 pm

SteveF wrote:Random "since it's not me doing the work" thought :-) : could the bootstrap MMFS ROM contain a compressed copy of MMFS (using e.g. tricky's algorithm with fast decompression code) to free up space for more goodies?


The gain from compressing is marginal. Initially the compression tool reports a small but worthwhile decrease in size but when I remove the block of zero bytes (padding) from the end of the MMFS SWRAM ROM I get very little compression:

test.bin 13808 96% 13287 test.equb

so that saves 521 bytes. Some of that will be eaten by the decompressor so it is a case of whether there is still enough after making the other necessary changes to be worthwile. There is a currently a comparison to detect corrupting of the MMFS SWRAM copy - if compression was used this may need to be a checksum instead so much would depends on how much space the checksum takes up.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Sideways RAM Utilities

Postby sweh » Sun May 07, 2017 3:42 pm

sweh wrote:
fordp wrote:
sweh wrote:Check out my RAM Manager; https://sweh.spuddy.org/Beeb/2M128/

Thanks for this I will add it to Github in the sweh folder if that's OK.

Let me work on a clean up of the build process. At the moment some of the code is duplicated from the HostFS:UPURS project (my Makefile literally copies the files over); it'd be good to have these things properly organised :-)

OK, I have the code in https://github.com/sweharris/ROM_Sources - hopefully this will be a good starting place for you.
Rgds
Stephen


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 2 guests