Image Map Image Map
Results 1 to 8 of 8

Thread: ZX81/TS1000 Basic programs loading from shadow ROM

  1. #1

    Default ZX81/TS1000 Basic programs loading from shadow ROM

    Hi

    I originally posted this up on the https://www.sinclairzxworld.com/ forum, but am not really getting any usefull advice, so I thought I would see if anyone in here can help.

    Anyhow while I am wating for some spare parts for my 8032 PET to arrive, I have turned my attention to my old ZX81.

    I am currently doing a little project where I want to pimp my trusty ZX81. I am doing an internal 16k static RAM upgrade, so there is no need for that wobbly blue tacked fizzing RAM pack anymore.

    I am also replacing the ROM with a 27C512 with a simple I/O switched latch circuit to give me 4 banks of 16k blocks sitting $0000- $3fff

    I need a bit of help and or guidance on how to load programs up to RAM from images stored in the lower memory areas.
    Using machine code, I am currently at the point where I am can copy down programs from the RAM into the shadow ROM area at $2000 and then bringing them back up into RAM by calling little machine code copy routines. I have got this working fine after initialization, but feel that I need to get my head round how to do things a bit better, as until now it has been a bit hit and miss.

    Ideally what I want to do it replicate a load command under machine code that will load a p file or similar from memory, and then run in the same manner that it was saved, and from where it left off. I am having trouble working out the entry points in the old ROM after copying the saved files into RAM.

    I am not wanting to get into the world of the ZXpand, RAMDOS and the like, I just want to hard code a few programs to load at boot via a simple menu.

    Can anyone assist me please with the entry and exit point in the standard ZX81 ROM. I am stumbling a bit as the stacks both at CPU and OS level seem to be causing me problems.

    Cheers

    -Pip

  2. #2

    Default

    Just in case anyone finds this thread by a search at some time in the future, I thought I would post a conclusion to my problem.

    I finally got to the bottom of my problem of insatiability when loading a file from memory and returning control to ZX BASIC. I was having trouble on exiting my code and giving back control to the normal running of the ZX81

    I looked at the Z80s stack in a monitor and could see the number of items were pushed on at any one time.

    It would appear that when the ZX81 is in SLOW mode, the stack holds information related to the screen display, because when I went FAST the stack decreased in size by 8 bytes.

    Therefor it is important to be in FAST mode when copying the system variables into storage, and the same when bringing them back into RAM. It is also important not to have PUSHed anything onto the stack at the point of copying the program/data, else this would screw up the return address. If you think about it, when the ZX81 is loading or saving, it will be in FAST mode by default.

    This is not so much an issue if you are just copying the basic program on its own into a newly initialized ZX81. It only seems to be a problem when loading in system variables that are included in a tape save, such as a .P or .TAP file

    In the end I used CALL 3875 to go fast, at the start of my code, did the coping about of the programs,then I re-entered basic via slow with a JP 3883,
    or for those who only speak hex CALL f23h to go fast, then I re-entered basic via slow with a JP f2bh

    I will now have to experiment with the ZX81 with the ROM paged out altogether, making sure that the NMI and INT are both disabled. I am hoping that I will be able to use the lower block of ROM for data storage, thus removing the need to have multiple copies of the original ROM in the lower 8k of various ROM banks.

    If by chance anyone is interested in the project, then let me know, I will post some pictures and maybe set up a blog.

    -Pip

  3. #3

    Default

    What I've done on one of my machines for a shadow ROM. When it boots, the reads are disabled on the RAM. Only the writes are not disabled. Which device that reads is controlled by a 7474 flop. There is code to read and write the data from the same address. When done, it does a read or write to one of the I/O address. This toggles the 7474 from the reset state, enables reads of the RAM and disables read of the ROM. When done there is no ROM, only RAM. One can modify code on the fly or destroy it self. At reset brings things back to a starting point.
    One does need a fully qualified I/O address. For that look at the timing diagrams in the processor specs.
    Dwight

  4. #4

    Default

    Quote Originally Posted by Dwight Elvey View Post
    What I've done on one of my machines for a shadow ROM. When it boots, the reads are disabled on the RAM. Only the writes are not disabled. Which device that reads is controlled by a 7474 flop. There is code to read and write the data from the same address. When done, it does a read or write to one of the I/O address. This toggles the 7474 from the reset state, enables reads of the RAM and disables read of the ROM. When done there is no ROM, only RAM. One can modify code on the fly or destroy it self. At reset brings things back to a starting point.
    One does need a fully qualified I/O address. For that look at the timing diagrams in the processor specs.
    Dwight
    Hi Dwight

    I have built a few shadow ROM/RAM systems with paged memory in the past. In this case I intend to do a simple latch using a 74LS74 to provide 2 IO mapped address lines to the 27C512 with a primitive address decoder using a couple of OR gates something along the lines of inputs from A7, IOREQ and WR so that an out(127) command can select 1 of 4 16k ROM pages occupying 0000h-3FFFh

    If anyone has a way of decoding 3 address lines all active low to latch 2 data lines in a single IC then I would love to know how to do this, because at the moment I am having to use 2 chips . I could use a 74LS138, but then would need to invert the non inverted enable with a transistor, and combine the outputs with diodes which is messier than using 2 chips

    Also I am slightly concerned about the EPROM I am going to use, as I have read in places that some people have had problems using 27Cxxx varieties of EPROMS in the ZX81. We will see what happens.


    -Pip
    Last edited by Pipcicle; June 2nd, 2020 at 10:55 AM.

  5. #5

    Default

    Actually thinking about it the 74LS138 wouldn't work as I was envisaging, as the outputs don't latch, so I would still need 2 chips anyhow.

  6. #6

    Default

    A registered PAL or GAL would be a one chip solution.
    Dwight

  7. #7

    Default

    Quote Originally Posted by Dwight Elvey View Post
    A registered PAL or GAL would be a one chip solution.
    Dwight
    Yes I guess so, but as it is not a stock item, if people wanted to duplicate this project, it would make it more difficult for them.

    -Pip

  8. #8

    Default Retro 2114 RAM chip tester

    Just for context, here it is.

    I used this to check the 2114 memory chips when repairing the 8032 in CBM 8032 Resurrection Project

    IMG_1979 - Copy_c.jpg

    I have just added a video conditioning board to get a good composite signal out rather than using a now obsolete RF modulator. When I was testing the 2114s it could hardly see the K cursor on the tuner. With the video conditioner I am getting really solid picture now.

    I built http://zx.zigg.net/misc-projects/ZX8...nditioning.pdf

    JoulesperCoulomb circuit uses a 555 timer to generate a back porch, which is a nice way of doing things as other circuits I have seen out there tend to use transistor mono-stables, with trimmers to set up. With the 555 version, the timings area all implicit within the capacitor values. So just build it and go! Joules has also worked out the strip board layout that fits neatly inside the old modulator box, so no need for a PCB


    -Pip

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •