Got a question about EPROMS at the ZX81.
Would it have been possible to have a wee EPROM board added to the '81 with seperate EPROMS with your favourite software burned on them. Eg
ZX-Assembler (Artic) - I think I saw this was about 6-7k
Tasword etc etc
Vu-File
Vu-Calc
What would have been the K limit for a individual EPROM?
I guess what I am getting at is it would have been quite cool having a assembler, word processor etc all available to be selected from with instant load.
cheers
Daryn
Question about EPROMS
Re: Question about EPROMS
Amongst the items I sent to Bruno recently was an instruction leaflet on how to make an EPROM upgrade for the Z80 to allow you to use EPROMs as well as the Z80 processor (at least I think that was it).
We just need that scanning in and someone to make the board!
Not sure what the limits on EPROM size would be
We just need that scanning in and someone to make the board!
Not sure what the limits on EPROM size would be
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module
Also Involved in:
Icephorm
Re: Question about EPROMS
Hi All
Your suggestion is a good one Palmheads, I use an 8k memory board with battery backup, loaded with zxas assembler for speed of loading, or sometimes just to save work in progress. I also use a toolkit spread over two 2k eproms which can be used with 4k of the ram, but in the absence of a eprom programmer I find battery backed memory boards a more useful addon.
Regards Moggy
Your suggestion is a good one Palmheads, I use an 8k memory board with battery backup, loaded with zxas assembler for speed of loading, or sometimes just to save work in progress. I also use a toolkit spread over two 2k eproms which can be used with 4k of the ram, but in the absence of a eprom programmer I find battery backed memory boards a more useful addon.
Regards Moggy
???????????????????????????PIINKEY$?????RND????????????????????????????????????????????????????????PI????????
- BrunoFlorindo
- Posts: 290
- Joined: Sat May 10, 2008 2:46 am
- Location: Anaheim, CA, USA
Re: Question about EPROMS
While I wait for my friend José Leandro to take a look at it, it might be worth mentioning that my TS1510 (a cartridge player for the TS1500) can be used with custom made cartridges. My TS1510 has been reverse-engineered by a friend and all the documentation on how to build a clone and how to make your own cartridges will be available soon. The TS1500 is a.f.a.i.k. a ZX81 with internal 16K and a "better" keyboard. Maybe the interface can be used on the TS1000 and ZX81 too? If this is the case, the interface would be a lot better than having to open the computer. Cartridges can be custom made, each one with its own Eprom, or you can build one with a socket so you can exchange the Eprom every time you want. I will probably start a new topic once I have all the details.
Re: Question about EPROMS
Wilf made a superb contribution called autobasic. http://www.user.dccnet.com/wrigter/inde ... oBasic.htm This relies on having a large battery-backed memory expansion and a replacement ROM.
Any battery-backed memory would be sufficient, although if you wanted executable code to be stored then you'd need to have the 8-16k area mapped or the m1-not mod performed - you can't run code above 32k.
Another option is to have an external ROM to replace the internal one. You can overwrite the character data with code, as the ULA can only ever access the internal ROM when producing a display. Arrange the mapping so that you have some more eprom, or even better EEPROM and you will have most of a solution. All that would be required is some kind of loader though this would be trivial.
Alternatively, get some kind of high density storage attached alongside your RAM expansion and you have the best of both worlds. This is
the reason I've been messing with the ROM - I want to have an always-present driver for my MMC design.
C
Any battery-backed memory would be sufficient, although if you wanted executable code to be stored then you'd need to have the 8-16k area mapped or the m1-not mod performed - you can't run code above 32k.
Another option is to have an external ROM to replace the internal one. You can overwrite the character data with code, as the ULA can only ever access the internal ROM when producing a display. Arrange the mapping so that you have some more eprom, or even better EEPROM and you will have most of a solution. All that would be required is some kind of loader though this would be trivial.
Alternatively, get some kind of high density storage attached alongside your RAM expansion and you have the best of both worlds. This is
the reason I've been messing with the ROM - I want to have an always-present driver for my MMC design.
C