More than 16k RAM in BASIC?

Anything Sinclair ZX Basic related; history, development, tips - differences between BASIC on the ZX80 and ZX81
alowe
Posts: 19
Joined: Sun Aug 26, 2012 2:58 pm

More than 16k RAM in BASIC?

Post by alowe »

Hi, this is my first post, (skip to questions below if you're timestrapped),

Tried a quick search for the answers which I'm sure have been covered a million times, but no luck, so...

I'm writing a program in BASIC for the ZX81 on the EightyOne emulator.
The problem, as you've probably guessed, is I've hit a block by being out of memory.
The options in emulator take the ZX81 up to 16k, 32k and 48k RAM.

I've found that peeking at RAMTOP from 16k and above, doesn't change RAMTOP. It stays at 32k.
There's also an option to not shadow the ROM in the 8k-16k range, releasing it for use I'm guessing.

Tried the emulators homepage but it no longer exists. There's a independant, volunteered mirror but not really open to questions.
So, I can set the memory to 48k but can currently only access it as if I have 16k in BASIC.

My questions are:
1) Can the extra 32k RAM be accessed from BASIC for the purposes of BASIC (data only is fine)?
2) Ditto for the 8-16k RAM range? What problems can this cause, if any?
3) If only data can be stored in these memory spaces, can someone provide an example in BASIC?

I'm happy to do a little reading, just lack knowledge on how to properly access >32k memory in
BASIC using peeks and pokes.
http://nocash.emubase.de/zxdocs.txt seems to have some useful info, but I'm still not sure.

I'm not an assembly programmer so just need the code to access the other memory areas so that I can finish my program.
Then maybe I'll consider going medieval on the ZX81 :geek:

Thanks for any help,

Aaron


PS I've got and fully read the BASIC manual.
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: More than 16k RAM in BASIC?

Post by Andy Rea »

Hi Welcome to the forum...

in a nutshell yes you can use more than 16K with basic but some precautions need to be taken.

to enable the memory you need to manually raise RAMTOP

i think it is all pretty much covered in the memopak 32K instructions

Linky: http://www.zx81stuff.org.uk/zx81/genera ... ak32K.html

HTH Andy

P.s should of read the whole post first LOL, The 8 to 16K is used by some programs for a Hi-Res buffer, some external hardware used that space for Firmware program ect... but other than Peek and Poke it can't usefully be used from basic.
what's that Smell.... smells like fresh flux and solder fumes...
User avatar
1024MAK
Posts: 5102
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: More than 16k RAM in BASIC?

Post by 1024MAK »

Sinclair only used partial decoding for the memory map.

Code: Select all

0000 hex to 1FFF =   0 to  8k = BASIC ROM
2000 hex to 3FFF =  8k to 16k = "echo" of BASIC ROM
4000 hex to 7FFF = 16k to 32k = RAM (if only the internal 1K is fitted, this 1k of RAM is "echoed" 15 times)
8000 hex to BFFF = 32k to 48k = "echo" of 0000 hex to 3FFF 0 to 16k area (BASIC ROM)
C000 hex to FFFF = 48k to 64k = "echo" of 4000 hex to 7FFF 16k to 32k area, used by the system for the display
Now, real RAM expansions can over ride the internal address decoding of the ZX81 and allow RAM in the range 2000 hex (8k) to FFFF (48k). However the ZX81 BASIC was not designed for any more than 16k so it has to be tricked.
The top of RAM C000 hex to FFFF = 48k to 64k is used by the system to generate the display (regardless if there is RAM there or not). As a result no machine code can be run from this area, but data can be stored there.

Have a read of the instructions for a 64k RAM expansion: text file here
or scanned image files here

Mark

Edited 2016-06-20 to update broken link.
Last edited by 1024MAK on Mon Jun 20, 2016 11:12 am, edited 1 time in total.
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: 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 later in the year.
alowe
Posts: 19
Joined: Sun Aug 26, 2012 2:58 pm

Re: More than 16k RAM in BASIC?

Post by alowe »

Thanks guys. Yep that did the trick.

Through for anyone else in this situation I recommend doing this before you write your program.

After raising the RAMTOP, I tried loading my program (from tape) and checking that RAMTOP was still higher, only to discover that loading tapes on the EightyOne resets the RAMTOP back to the lower value again. Huh... :roll:
And raising RAMTOP after the program loaded didn't help because NEW is needed to get the new value recognised.

So, spent 2 hours re-typing the whole program again, which isn't a bad exercise to be honest. Found a few bugs.
Once retyped with the raised RAMTOP, everything was fine and I was cooking with gas again :)

So many thanks to you both :D


PS In hindsight I'm guessing addresses are fixed upon writing of the BASIC, not decided upon running, or is it that programs saved to tape also save system variables, hence why RAMTOP was being changed on load?
User avatar
Paul
Posts: 1511
Joined: Thu May 27, 2010 8:15 am
Location: Germanys west end

Re: More than 16k RAM in BASIC?

Post by Paul »

alowe wrote:PS In hindsight I'm guessing addresses are fixed upon writing of the BASIC, not decided upon running, or is it that programs saved to tape also save system variables, hence why RAMTOP was being changed on load?
Yes, system variables starting from 16393 are saved to tape (P-File) so on reloading they will also be set correct. Those before 16393 are not saved.
See chapter 28 of the manual
In theory, there is no difference between theory and practice. But, in practice, there is.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: More than 16k RAM in BASIC?

Post by PokeMon »

1024MAK wrote:Sinclair only used partial decoding for the memory map.

Code: Select all

0000 hex to 1FFF =   0 to  8k = BASIC ROM
2000 hex to 3FFF =  8k to 16k = "echo" of BASIC ROM
4000 hex to 7FFF = 16k to 32k = RAM (if only the internal 1K is fitted, this 1k of RAM is "echoed" 15 times)
8000 hex to BFFF = 32k to 48k = "echo" of 0000 hex to 3FFF 0 to 16k area (BASIC ROM)
C000 hex to FFFF = 48k to 64k = "echo" of 4000 hex to 7FFF 16k to 32k area, used by the system for the display
Now, real RAM expansions can over ride the internal address decoding of the ZX81 and allow RAM in the range 2000 hex (8k) to FFFF (48k). However the ZX81 BASIC was not designed for any more than 16k so it has to be tricked.
The top of RAM C000 hex to FFFF = 48k to 64k is used by the system to generate the display (regardless if there is RAM there or not). As a result no machine code can be run from this area, but data can be stored there.
I just wondered why my 32k RAM extension can not be addressed in area $8000-$BFFF.
After several tries I compared content with memory above $8000 with ROM content ($0000).
And that did the trick.
I just wonder why ROM is mirrored at this address.
Just lazyness or needed for any purpose ? :roll:

And it seems that the ROM has stronger output than my RAM. I am sure it tries to deliver data.
After thinking about this problem I saw the resistors and so it is, the CPU tries to write maybe $00 into memory and selects the ROM automatically which causes the ROM content to be written in RAM automatically. So this is a nice feature, writing $00 or any other value will copy ROM content into a new area. This is quite convenient, maybe Clive didn't know / planned that. Easy and fast. :mrgreen:

So disabling /ROMCS when A15 high would do the trick ?
I think the ROM never have to be addressed in area $8000-$FFFF, right ?
User avatar
1024MAK
Posts: 5102
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: More than 16k RAM in BASIC?

Post by 1024MAK »

I recommend disabling all the ROM echos by pulling the /ROMCS line high whenever [ A13 OR A14 OR A15 ] are high.

So that the ROM still works for 0000 to 1FFF, do not drive the /ROMCS when A13 and A14 and A15 are all low. The ZX OS / BASIC does not address the ROM at any of its echoed locations.

You could use diodes between the address lines and /ROMCS, or use logic gates driving an transistor that connects collector to +5V and emitter to the /ROMCS. Use a pull up resistor for the base to ensure the emitter voltage is a proper logic high.
PokeMon wrote:I just wonder why ROM is mirrored at this address.
Just lazyness or needed for any purpose ? :roll:
Cheap (low cost) and basic design :mrgreen:

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: 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 later in the year.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: More than 16k RAM in BASIC?

Post by PokeMon »

1024MAK wrote:I recommend disabling all the ROM echos by pulling the /ROMCS line high whenever [ A13 OR A14 OR A15 ] are high.
So in my simple low cost extension I will just simply block the $8000-$BFFF area (when A15 high).
I don't do full address decoding, not more than needed.
That's my strike back. :mrgreen:

But I think I will use the internal memory test to copy ROM content to a FLASH without any line of own code due to found out feature above.
That's for my executive memory board which is planned for next year.
User avatar
1024MAK
Posts: 5102
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: More than 16k RAM in BASIC?

Post by 1024MAK »

Yep, pulling the /ROMCS line high whenever A15 is high will prevent ROM echoes in the upper half of memory.

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: 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 later in the year.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: More than 16k RAM in BASIC?

Post by PokeMon »

So have to do other way, pushing it always high with a 820R resistor and pulling down when needed (A15 low and A14 low of course).
This is needed because LS gates can power only 0.4 mA and is not able to overdrive the /ROMCS without external help. :mrgreen:
Okay that works now.

Now I want to have it capable with HIRES programs.
Found at some internet pages that people just connected /RFSH and /RD with two diodes so that either /RD or /RFSH forces the RAM to output data.
When I try this my Zeddy is not working any more.

My RAM is enabled from address area $4000-$FFFF (/CE) at pin 20 of a 32k RAM , using A15^A14 (one of both high) and /MREQ low.
/WR is connected to pin 27.
/RD is connected to pin 22.
This works fine with 32k RAM from $4000-$BFFF.

When trying to connect /RD and /RFSH to /RD of RAM (using an and gate LS08 instead of two diodes) it should work, shouldn't it ?
Any idea what's maybe wrong ?
Any condition missing ?
I get no picture when enabling read simply during (all) refresh cycles. :?
Post Reply