MTX Paged Roms

About original Memotech hardware.
Post Reply
Martin A
Posts: 799
Joined: 09 Nov 2013 21:03

MTX Paged Roms

Post by Martin A »

As most MTX owners are aware the there is 24k of ROM on board the basic system, squeezed into 16k of memory space by paging of the ROMs in the 8k to 16k area.

The 3 ROMs were given the names OS, Basic and Assem back in 90's when I first copied them to the Acorn Risc System I was writing my Emulator on. (I let them loose on the internet sometime around 1998 and they've spread from there)

It's only recently that thanks to the listings on Andy's site that I've started paying proper attention to what's in each ROM.

I've got a machine generated disassembly that I've been working on to add in the original labels. In its current state,on my home assembler, it will assemble an accurate copy the full 24k. Though for most other assemblers the label format will need changing from the Acorn .label to the more conventional label: format.

As part of that process, I've noticed that the built in assembler lies across the join between "OS" rom and "assem", and in fact the "assem" rom seems to be split between the assembler and the VDU driver code, with around 3.5k of it being the assembler and 4.5k VDU.

OS and Assem probably should be considered as one unit, a 16k OS. Which is as it is on a 2 rom motherboard. The code flows across the 8k mid instruction, and that's the way the attached file will assemble it, with the 8k basic ROM following.

Does anyone know why it is though that Basic is in ROM 0, and the upper part of the OS is in ROM 1. Somehow the other way round seems more logical to me.
Attachments
DisAss.zip
ROM Source code
(47.73 KiB) Downloaded 470 times
Martin A
Posts: 799
Joined: 09 Nov 2013 21:03

MTX Paged Roms

Post by Martin A »

Following up the above, I've run some experiments to try and establish how much ROM paging goes on.

With basic and the VDU code occupying the same space, it's evident, that the ROMs must be paged every time basic does any output.

In order to test this, I tweaked a copy of !MTX on the Acorn to count all cycles emulated and the number of times the rom is swapped, from that I could calculate how often the ROMs are paged. (using 4,000,000 emulated cycles as a second)

The sequence basic to vdu to basic would be recorded as 2 swaps. Any attempt to change the paging register that doesn't result in a change isn't recoded. The odd number of paging events on each test could be a fluke, but I think is probably down to the boot code testing each ROM in turn for the auto start sequence.

Test 1: Type in and run:
10 CLOCK "000000"
20 FOR X=1 TO 1000
30 CSR 0,0
40 PRINT X
50 NEXT X
60 PRINT TIME$

which takes 22 seconds to run

Total Run time 60.9 sec
Page changes 30557
501 changes a sec

Test 2:Load "Escape from Zarcos" and play long enough to collect 1 block
Run time 33.4 sec
Page changes 2069
62 changes per sec

Test 3: Start up and just leave it a while
Run time 50 sec
Page changes 6367
127 changes per sec

Final test: Start up, load Tapeworm play a bit
Run time 60.8 sec
page changes 28545
470 changes per sec.



Zarcos is pure assembler and doesn't page, so I figure most of the 2000 pagings occurred on startup and while typing in the load instruction.

There's no real difference in basic between text and graphic mode as to the amount of ROM swapping going on.

Given the amount of ROM swapping going on, FDXB which is ram resident on the FDX system, ought to run faster than ROM basic, though whether it's measurable or not I don't know.

Typical paging code
LD A,(PAGE)
AND 070H
LD (PAGE),A
OUT (00),A

takes 44 cycles, the code in the OS is more involved than this but even assuming a saving for 80 cycles per call, the 500 paging events per second recoded by highest result in the tests would only amount to 1% of the processor time.
User avatar
1024MAK
Posts: 757
Joined: 24 Dec 2012 03:01
Location: Looking forward to summer, in Somerset, UK

Re: MTX Paged Roms

Post by 1024MAK »

Astonishing :shock:

I suppose time during development was a problem, so arranging the code in the ROMs so that ROM switching would be minimal was not a high priority.

Mark
:!: Standby alert :!:
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer in Somerset later in the year :D

Not as many MTXs as Dave! :lol:
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: MTX Paged Roms

Post by Bill B »

I have been thinking for some time about the opposite situation.

When in CP/M mode, the entire BIOS is copied into high memory and then executes from there. The system never swaps except for accessing the RAM disk.

It is possible to imagine an alternate BIOS, that, whenever a BIOS call is made, swaps the CP/M ROM back in, and executes the BIOS code from there. Clearly there would still need to some data structures in high memory, and a bit of code to handle the page swapping. But it would make the BIOS effectivly smaller, giving the potential for a larger TPA and user programs.

Yet another item on my to-do list.
Martin A
Posts: 799
Joined: 09 Nov 2013 21:03

Re: MTX Paged Roms

Post by Martin A »

Bill B wrote:It is possible to imagine an alternate BIOS, that, whenever a BIOS call is made, swaps the CP/M ROM back in, and executes the BIOS code from there. Clearly there would still need to some data structures in high memory, and a bit of code to handle the page swapping. But it would make the BIOS effectivly smaller, giving the potential for a larger TPA and user programs.
Paged memory is a CPM 3 feature.

Typical TPA is around 62K I beleive.

We just need someone to port it to our hardware....
User avatar
AndyKey
Posts: 74
Joined: 12 Aug 2012 01:29
Location: Southampton, UK
Contact:

Re: MTX Paged Roms

Post by AndyKey »

I think that fitting it all in was a bigger concern than minimizing paging.

The 127 page switches per sec when idling is consistent with one of the interrupt service routines being called 64 times a second,
which switches to ROM page 1, runs a small piece of code (which often does very little), then switches back.
I describe this in LOADMTX at http://www.nyangau.org/loadmtx/loadmtx.htm, under "How it works".

The CP/M 3 thing was done. I believe I saw it.
There was a prototype made, which looked like my SDX or a Memotech Business/2, only even slimmer, with a single floppy.
It ran CP/M 3, which implied a big TPA.
I'm not sure (this was 30 years ago), but it may even have had some kind of task switch feature too.
If this ever appears on eBay, I'll be bidding.
Interestingly, there was a post on a bulletin board by someone in the US mentioning CP/M 3 and Memotech.

{{{ Andy
{{{ Andy
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: MTX Paged Roms

Post by Bill B »

Yes, CP/M 3 supported page switching at a BDOS/application level. However providing the BIOS restores everything before returning, I see no reason why even for CP/M 2.2 the BIOS cannot page swap. The only thing that might break is application level interrupts.

Many years ago I obtained the ZCRP3 source from the CP/M User Group. I believe that this includes an enhanced BDOS as well as CCP. I mentioned my to-do list ... :roll:
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: MTX Paged Roms

Post by Bill B »

Andy,

On the subject of LoadMTX, I have wondered whether another approach is possible.

You mention the interrupt that occurs 125 times per second. As you know, it is possible to define a user routine that is called in response to that interrupt. I have wondered whether it would be possible to write an interrupt routine that examines the stack and determines the value of PC when the interrupt occured. It uses that to identify when InOut is being executed, and when it observes that, it branches to a routine to load the data from disk instead of tape. It would require a certain amount of stack manipulation to ensure the correct return.

What may cause that idea to fail is if InOut disables the user interrupt. I have not got around to checking the code.

Bill.
User avatar
AndyKey
Posts: 74
Joined: 12 Aug 2012 01:29
Location: Southampton, UK
Contact:

Re: MTX Paged Roms

Post by AndyKey »

Alas INOUT (=0AAEH) reprograms the CTC so as to interrupt whenever an edge occurs on the cassette interface.
I suspect the ISR simply sets the carry flag.

Cool idea though.
{{{ Andy
Post Reply