[Sinclair ZX81] extension mémoire ZX81-32K

[Papy.G]

C'est le maximum de RAM que puisse adresser un ZX-81?

[Patrick]

Il existe des extensions 64 ko externes, mais je ne me suis pas penché sur le sujet.
En interne, je ne sais pas si c'est possible.

[hlide]

Extrait de https://problemkaputt.de/zxdocs.htm#zx8 ... systemarea

ZX80/ZX81 Memory Mirrors and Expansions

Memory Overview
RAM is originated at 4000h, for 1K RAM: at 4000h-43FFh; 48K: at 4000h-FFFFh, the area below 4000h is used only when more than 48K are installed.
In the ZX world, memory accesses can be split into three categories: data read, data write, and opcode read. Opcode read is sensed by the CPUs /M1 signal, and behaves different than normal data read in case that A15 is HIGH, ie. for addresses in range from 8000h-FFFFh.
address code read write
0000..1FFF ROM ROM --- ;all ZX81's
2000..3FFF RAM4 RAM4 RAM4 ;ZX81 with 56K only
4000..7FFF RAM1 RAM1 RAM1 ;ZX81 with 16K or more RAM
8000..BFFF VRAM2 RAM2 RAM2 ;ZX81 with 32K or more RAM
C000..FFFF VRAM1 RAM3 RAM3 ;ZX81 with 48K or more RAM (*)
(*) That, for the RAM3 part, VRAM1 is of course found in all ZX with 16K
The memory region 8000h-FFFFh cannot be used to execute machine code programs; any opcodes in that region with Bit 6 cleared are treated as video output (and are executed as NOPs).
Opcodes/video data at C000-FFFFh are read from memory at 4000h-7FFFh - the software should usually write video data into memory at 4000h-7FFF, and 'execute' the data in the mirrored region at C000-FFFF.

1K RAM
Default ZX81 includes only 1K RAM at 4000h-43FFh. However, the default RAM and ROM select signals are mirroring ROM across 0000h-3FFFh and 8000h-BFFFh, and RAM at 4000h-7FFFh and (including 'data read' accesses) at C000h-FFFFh.
The ZX81 mainboard provides space for either two 1K x 4bit SRAM chips, or one 1K x 8bit SRAM chip (with L1 jumper closed).

2K RAM
The american 'ZX81' (Timex TS1000) appears to have been delivered with 2K internal memory. The socket for 1K x 8bit SRAM on the ZX81 mainboard may be used (by closing L2 jumper) for a 2K x 8bit SRAM chip.

16K RAM
Even though above described 1K RAM signals are providing memory space for up to 16K RAM, the Memotech expansions (not sure about Sinclair or other expansions) are supplying their own RAM and ROM select signals; ROM is then located at 0000-1FFF only, and RAM at 4000-7FFFh only, all other areas are unused, typically 'FFh filled'. Except that, video memory opcode reads (but not data reads) from C000h-FFFFh are mirrored to 4000h-7FFFh as usually.
Timex TS1500 has been delivered with 16K built-in RAM.

The 16K RAM configuration may be more or less treated as standard configuration - programmers should recurse that below expansions of 32K or more RAM haven't been very popular - thus any programs that require more than 16K memory won't work on most ZX computers.

32K RAM
RAM is located at 4000h-BFFFh, whereas the upper half may be used to store data and/or to 'execute' video code, but not for normal machine code program code.
Note that the BIOS memory detection ends at 8000h, the BIOS will detect only a maximum of 16K RAM - and the stack pointer will be then initiated at 8000h. Thus, loading large cassette files will overwrite the stack. When using more than 16K RAM, the RAMTOP identifier in the system area must be changed manually by POKE instructions, and then applied by a NEW instruction (or by a short program that moves stack data and stack pointers to the new addresses).
Care should be taken that video memory may not cross the 7FFFh/8000h boundary; Video data at 7FFFh is executed by addressing FFFFh, and thus the next address will be 0000h instead 8000h! Ie. video memory may be located in either one of the two 16K blocks, not in both.

48K RAM
RAM is located at 4000h-FFFFh, same restrictions as for 32K RAM apply. The memory at C000h-FFFFh can be used as data storage only, but not for machine code execution, and not for video data 'execution'.
When patching the RAMTOP value use the maximum of FFFFh (indicating 48K minus one byte), as video memory must be below C000h, BASIC program code is restricted to less than 32K as well, BASIC variables may use the additional memory though.
Some 16K expansions can be combined with 32K expansions to gain a total of 48K RAM.

64K RAM
Even though called "64K" expansions, most or all of these expansions do not seem to support bank switching which'd allow to switch RAM into the 8K BIOS ROM area at 0000h-1FFFh, so only 56K of RAM at 2000h-FFFFh can be used.
As for 48K RAM, the highest RAMTOP value would be FFFFh, the 'RAMBASE' is fixed at 4000h, so that the additional memory at 2000h-3FFFh cannot be used by the BIOS/BASIC interpreter.

On voit qu'au delà de 16 Ko, on n'est plus en mesure d'exécuter du code sur toute la RAM disponible (>= 8000h). Il faudrait un système de bank pour aller au-delà de 56 Ko.

[Xavier_]

Salut,

Le décodage mémoire du Zx81 est à l'image de sa … simplicité.
donc, 8k de ROM Basic, 8k de ROM/RAM, 16k RAM… le reste en RAM jusqu'aux 56k adressable.
Il faut se dire que le pointeur mémoire commence à h2000, donc il reste hFFFF-h2000 (56k) de mémoire à adresser)

En interne, sans décodage, on ne peut monté qu'a 32k, car au delà il y a conflict avec un bit d'affichage utilisé en interne.
On peut stocker des données dans la dernière partie de la RAM haute, mais on ne peut pas executer des routines assembleur et du basic.
Probablement à cause du pointeur PC du Z80 qui ne peut exploiter cette partie de mémoire.
Pour le Basic, c'est le pointeur du D_File (mémoire vidéo flottante après le programme basic) qui ne doit pas monter trop haut, sinon ça coince.
On peut naturellement rediriger le D_File en début de programme, mais le moniteur Basic ne sera plus visible...

Il faut savoir que Sinclair n'a jamais eu l'idée d'utiliser des mémoires supérieures à 16k.
En effet, la ROM scan ses 1k ou 16k en ROM... et le reste n'est pas pris en compte.
Il faut donc initialiser manuellement la balise haute de la mémoire en variable système.

Dans les faits, la zone supérieur en h8000 est rarement utilisée.
Je ne connais que "intercepteur Cobalt" qui utilise 24k... et pourtant, cette mémoire, si bien utilisée, aurai pu donner de bon jeux.
Les raisons… la vitesse de chargement et le coût de ma mémoire, plus chère que l'ordinateur lui-même.

Dans ces conditions, l'extension "64k" est un abus de language, car dans les faits, on comble les "trous" libres dans la mémoire du Zx81.
On a bien 64k de RAM, mais un système de décodage de blocs, permet d'assigner les 56k avant le basic en h4000 et après les 2x16k pour le basic.

[hlide]

Probablement à cause du pointeur PC du Z80 qui ne peut exploiter cette partie de mémoire.

Non, c'est lié à l'interaction entre ULA et le Z80. Le Z80 n'a aucun problème à exécuter sur la plage de 64 Ko.

Le fait est que que ULA (ou le circuit équivalent) intercepte le bus Z80 pour vérifier si on tente d'exécuter en $C000-$FFFF : il guette un /M1 = 0 (opcode fetching), si A15 et A14 = 1 alors il comprend que l'on est dans l'espace vidéo. Il scrute également D6 pour savoir quoi faire de l'opcode à retourner au CPU sur le bus de donnée : selon la valeur de ce D6, il retourne soit l'octet se trouvant à l'adresse RAM indiquée (avec le bit A15 et A14 mis à 0, je crois sinon on va avoir des soucis avec les extensions >= 16 Ko) - c'est le cas du HALT - soit il retourne l'octet NOP et le ULA se sert de ce qui est lu dans la RAM pour afficher le caractère. C'est couillu quand même. Je suis quand même assez admiratif de l'astuce.

[Xavier_]

Ha, ok !
C'est pour cela qu'il y a une mention du WRX (affichage haute résolution) pour la mémoire haute.

[hlide]

Au vu du schéma je vois que le bus de donnée D0..7 est partagé entre ULA, le Z80 et la mémoire. A ceci près qu'il il y a une résistance sur la ligne de donnée entre la paire ULA-Z80 et les mémoires.

Vu que c'est ULA qui décode l'adresse, c'est lui qui devrait initier l'accès aux mémoires (on me reprendra si je me trompe) et c'est donc lui qui est le maître. Il doit forcement lire la donnée sur le bus de donnée pour savoir si l'opcode est à faire exécuter par le CPU ou lui passer NOP sur ce même bus. Mais comment fait-il ça ? en forçant ses broches D0..7 à 0 et en relâchant le /CSRAM avant que le CPU puisse valider l'opcode sur le bus de donnée ?

[Xavier_]

En fait, l'ULA prend les 16 premiers kilo-octets pour de la ROM (\CSROM) et les 16 suivants pour de la RAM à partir de h4000 (\CSRAM).
Les résistances entre la RAM et la ROM permettent de faire le basculement ROM/RAM via l'ULA.

Pour l'affichage, l'IR du pointage de l'affichage des caractères ne pouvait ce faire, car la bascule étant en CSROM, les données mémoire n'étaient pas lues (csram non actif).

Donc pour éviter un conflict entre les deux blocs ROM/RAM de 16k (basse et haute), il faut une résistance de seuil qui désactive temporairement la mémoire.

zx_csrom.JPG (135.9 Kio) Consulté 4746 fois

D'où la particularité, pour le ZX81, d'avoir les annotations D0',D1'... sur la sortie BUS !
C'était du travail partagé...

[Fred_72]

Le système vidéo du ZX est assez compliqué et très bien pensé. Tu trouveras pleins d'info ici : http://searle.x10host.com/zx80/zx80.html
C'est le schéma annoté du ZX80 (le ZX81 ajoute simplement un générateur NMI et intègre tout ce petit monde dans l'ULA)

[Xavier_]

Cyber-Papy avait d'ailleurs évoqué le fait qu'à l'époque, pour faire une carte d'adaptation vidéo sans "fil volant" pour repiquer la sortie vidéo, ils avaient été obligé de reconstruire le signal avec le schéma de la partie électronique de la vidéo du Zx80.
Tout ça pour éviter aux utilisateurs d'ouvrir la machine...

[hlide]

J'ai vu le schéma du ZX80. Pour que je comprenne bien, les résistances de 470 ohm sur le bus de donnée ont un rôle à jouer dans l'affaiblissement du bus de données de la RAM au regard de la sortie du générateur de NOP ? j'ai aussi vu le schéma d'oscilloscope de la génération du NOP. Si A15 et D6' sont flottants, que deviennent les sorties des inverseurs qui génèrent les NOP ?

Sinon je lis bien :

DATA BUS ISOLATOR
The NOP generator will force "00" (NOP) onto the CPU data bus during display causing the CPU to run NOP code sequences while the address bus changes. However, RAM is also active during this time, so these resistors allow the CPU data bus to be forced low while the RAM is also outputting data.

[Fred_72]

D6' est rappelée au +5V par une résistance de pull-up et une entrée TTL en l'air voit un niveau 1. Les inverseurs qui pilotent le NOP sont à collecteurs ouverts donc lorsque leur sortie est à "1" ils sont à l'état haute impédance.
Les résistances permettent de limiter le courant circulant entre les 2 bus. Si les sorties des inverseurs sont à "0" et les données présentent sur l'autre bus (RAM, ROM) à "1", le courant dans chaque résistance n'est que de 0.5mA (moins d'une charge TTL) donc la tension aux bornes des résistances est de 5V et la valeur de chaque bit Dx et Dx' n'est pas affectée.
Comme ça pendant que le Z80 voit NOP, l'ULA voit la valeur donnée par la ROM (ou la RAM) traduisant les points constituant les caractères.

Edit: En fait c'est faux, les résistances entre les 2 bus font 470 ohms et pas 10k donc le courant fait 10mA ce qui est trop pour maintenir un "1" à la sortie d'une porte TTL, ça permet juste de ne pas l'endommager mais les 2 bus sont à "0".
L'astuce est que le NOP n'est maintenu que durant le cycle T1 et les données image sont lue après.

[hlide]

Merci pour l'explication, @Fred_72.

[hlide]

@Patrick, j'ai bien reçu le paquet. Merci. Mais quel emballage ! il faudrait vraiment que ça passe sous les roues d'un camion...

[gti]

Bonjour, est ce que dispose encore d un kit complet ou juste le pcb au pire. Merci d avance. Cordialement