Where to place machine code on a 128K machine

[PeterJ]

I'm clear on where to store machine code on a standard 48K Spectrum, but where do I store it on a 128K model? I'm aware memory is paged.

I'm creating a BASIC program with lots of data arrays (hence the need for 128K), and I want to use the 42 column routine that @TMD2003 has previously used.

Thanks

Peter

https://spectrumcomputing.co.uk/entry/2 ... pectrum/42

[XoRRoX]

Hi Peter.

Basically from 49152 upwards. Be mindful though to read what the layout of the several banks are when paged in, bank 2 and 5 appear at 2 places at the same time. And the contention differs between the several models; over all models, uncontended are only bank 0 and 2.

I use this information as a reference: https://worldofspectrum.org/faq/referen ... erence.htm

To keep ROM 0 paged in when switching a memory bank, add 16 to the banknumber you are switching to with:

Code: Select all

POKE 23388,16+b : OUT 32765,16+b

In my BASIC loaders for mc games, I use a sub-routine:

Code: Select all

# ----------------------------------------------------------------------------
# Subroutine to switch memory bank while preserving ROM1
# In: bank n
#
# Note: @ line number 1 to save mem when calling each time
# ----------------------------------------------------------------------------
1 LET b=b+VAL "16":POKE 23388,b: OUT VAL "32765",b: RETURN

And then call it like this:

Code: Select all

LET b=VAL"1": GOSUB SGN PI

Where b is the bank number to switch to. I place it at line 1 to save memory when calling it.

[deanysoft]

Hi. Well if it's a standard BASIC program that just calls some code I don't think you need to worry about where you put it too much. I think you can treat it like a 48K machine and place the code high up in RAM, even where the banks are swapped as the ROM takes care of switching things around. I might be wrong but I don't think you can have say larger data arrays simply because you're using a 128 but you can use the RAM disk and store / recover data that way.

[PeterJ]

Thanks both. Much appreciated.

[TMD2003]

If there's lots of arrays, and they're all the same dimension (or can be crowbarred into the largest dimension and then filled with blanks), then the RAM disc is absolutely perfect for that.

Say, if it was crossword data in a 15×15 grid, with 9 crosswords each held in an array. (This wouldn't take up anywhere near enough memory to invoke the RAM disc but it's to show what I mean.)

DIM c$(15,15) to start the "save the arrays" program. Define each array into c$, then SAVE !"cwd1.car" DATA c$() or SAVE "m:cwd1.car" DATA c$(), Overwrite the array c$ with the next set of data, save "cwd2.car" and so on up to "cwd9.car".

And in the main program, DIM c$(15,15), LOAD ! (or LOAD "m:") each crossword as necessary. With the numbering system as it is, INPUT i, LET a$="cwd1"+STR$ i+".car" and LOAD !a$ DATA c$() (or leave out the ! and put the "m:" inside a$).

I must be one of the few people who uses saved arrays, but that's because it took 33 years to break out of pure BASIC...

Also, I'd put the 42-character routine as high up as possible so that the last byte is bashing right against RAMTOP.

[AndyC]

The tricky thing is that BASIC mostly pretends the extra memory doesn't exist, except as a RAMdisk. So any arrays and such get stored in the main RAM. And the only way to safely store executable code.is to lower RAMTOP to below 0xC000 so you can page the RAM as needed. But then you've removed all the space you wanted for your arrays.....

Sadly it was a common issue on 8-bit machines, once they went past the 64K barrier they mostly ignored BASIC coders. The SAM being one of the few examples that did a good job.

[1024MAK]

Don’t forget that most of BASIC on a 128K machine is EXACTLY the same as BASIC on the 16K/48K/+ models (in fact, the same ROM code is used).
Hence most of BASIC is mostly complete unaware of there being more than 48K of RAM.

To preserve compatibility, there was no easy way round this, unless double (as in double compared to that in a 128K) the amount of ROM was provided with some changes to syntax.

The other design limitation is the size of the memory blocks that are paged/switched. If they were 8K bytes in size, you could have kept the machine code in the top 8K and then switched the next 8K below. But alas, this is not how they made it.

One other option, is as XoRRoX says, that is to use the machine as a 48K/+ model (USR 0), without locking the paging register. Reduce the area available to BASIC down to below with 49151 (minus whatever your machine code needs) using CLEAR. Then you can store whatever you like in the RAM banks above 49152 (except those that also appear lower down in the memory map). BASIC when used after USR 0 has absolutely no knowledge of bank switching/paging, so your BASIC program can do what it likes. But you may want to use a machine code routine to copy memory chunks backwards and forwards for speed reasons.

Mark