To be 100% compatible, or not, that's the question.

[RetroTechie]

As some of you will know I've managed to get an ULA replacement working stand-alone, and now that I'll clean up some of the logic in it, I'm wondering:

Should I strive for 100% compatibility with original ZX81, or is it okay to make some improvements that you wouldn't notice with regular ZX81 software? For example:

• Right now I have a 32KB SRAM wired up to occupy 16KB in 4000-7FFFh area (and AFAIK mirrored at C000-FFFFh), with the other half unused. This to minimize required logic (entire mod is just a few track cuts and <10 cm. wiring in total!). But I'd like to use that entire 32K, for example in 2000-9FFFh area.
• ZX81 system ROM uses just a few I/O ports, but hardware responds to many mirrors of those. I'd like to cut that down, so you could use other I/O ports freely without affecting NMI enable/Vsync circuitry.

For most standard ZX81 software it wouldn't matter, but I can imagine there's some programs (hi-res stuff, demo's etc) out there that use these ZX81 specifics to work - either on purpose or by accident. For myself I don't care as long as software I use, works the same as on a real ZX81. Problem is I wouldn't know in advance which software. Whatever I use as test set, is always a limited cross-section of what's out there. So if I make a change now, I could download a ZX81 proggie tomorrow that doesn't do what it would do on original ZX81.

FWIW: I don't care much for the hardware side of things, if I need an extra signal to connect to my 'ULA', that's OK. I'm interested solely in the software side of things.

On a related note: do you know some programs/demo's, that are good for testing specific ZX81 hardware features? I'm thinking about programs that access such non-standard I/O ports, mirrored ROM/RAM area's, play with hsync/Vsync timing, etc. In short: the kind of programs that let you quickly determine whether your ZX81 behaves like the real thing. Preferably short proggies...

[Andy Rea]

Hi

for the Memory modification, it is possible to map the 32K over the $2000 - $9FFF region without much problem.

As for IO i think it is best to stick with the lower 3 bits A0-A2 used as partial decode only as in the original ULA, you will note that A2 doesn't acutally drive anything in the ULA but it is used by the ZXprinter. other IO's you choose to use yourself can of course be fully decoded if you wish.

here are 3 programs that i used to test.

CLCKFREQ.P - nicked from the german forum, it does a serires of tests that are known to take a predetermined number of 'FRAMES' to execute.

REZ4K.P - rezzurection demo, does some funky stuff with the display, one of few programs that caused me trouble, i would get display corruption in the top part of the screen.

ZXTEST2.P - A small test program that alters the display timing (i discovered this by mistake) on a real Zeddy the display bobs up and down by 1 pixel line, on Eightyone the characters get corupted...

Regards Andy

zxtest.zip

3 files useful for testing.

(4.32 KiB) Downloaded 469 times

[RetroTechie]

Thanks for those! I'll check 'm out...

As for IO i think it is best to stick with the lower 3 bits A0-A2 used as partial decode only as in the original ULA, you will note that A2 doesn't acutally drive anything in the ULA but it is used by the ZXprinter. other IO's you choose to use yourself can of course be fully decoded if you wish.

No that's what I meant - if ULA responds to an I/O address with A0=0, then it will respond to any I/O address with A0=0 (not just FEh). Sure you can fully decode an I/O yourself, but to not interfere with above mechanism you'd have to stick to uneven addresses. Similar story goes for I/O writes. It's exactly this I'd want to prevent, so that you can use any I/O address (outside a small reserved range) in any way you like. Internal to ULA or otherwise (circuit board mod, homebrew external add-on, whatever).

Same thing with printer - it might be a problem if printer only decodes A2 and you have something else that uses an I/O address conflicting with that. But as long as system software / applications all use the same I/O address(es) to access the printer, you could just unplug the printer when using your homebrew add-on (the reverse should be fine as the add-on wouldn't respond to I/O ports used for the printer).

Basically I'm wondering if there exist applications that use those mirrors of normally used memory or I/O addresses. (and if so, how rare / common those applications are)

[Andy Rea]

OH yes any io write with A0 = 0 will or should turn on the NMI gen, as will any write with A1 = 0 should turn off NMI gen.

i have 2 r/s latches (well equivalent) for the NMI gen, and Vsync.
and the logic is along the lines of :-

NMIset = !iorq & !wr & !A0 ;
NMIres = !iorw & !wr & !A1 ;

Which feed into the latch, the output of with is 'ANDED' with hsync to produce the NMI train that goes to the CPU.

OH one more thing, $FF or indeed any IO write will cause the latched Vsync to reset ending the Vsync that should not be decoded just : - !iorq & !wr ; will do.

HTH

Andy

P.s i suppose you could go with the full decoding of $FE and $FD, since as $FB is an external device not much you can do about that, i'm unaware of any programs that deliberately use alternative port addresses for $FE and $fD. but that doesn;t mean there isn't any.

[sirmorris]

I think no-one can be sure about what software does what. With that in mind I'd say stick to the original scheme - it's not really any hardship to decode IOs at addresses with the bottom 3 bits set.

Otherwise, should the weight of opinion tip the scales in the other direction, I'd say not to worry either - a the software isn't going to run one way or another on a machine with a busted ULA..!

If for example there is a program that someone _simply cannot live without_ then a few minutes with EO and a hex editor should set things right


C

[1024MAK]

You may be interested to know that a circuit exists for the ZX Spectrum to increase the number of usable I/O ports to 128.
The ZX Spectrum ULA /IORQ input can be forced high via a connection on the edge connector (known as /IORQGE). The Z80 /IORQ and the /IORQ (IORQGE) on the ULA are separated with a resistor. Some extracts from some posts about this are here:

ZX Spectrum 128 IO ports circuit.zip

(2.17 KiB) Downloaded 388 times

(view with a fixed width font...)
How many people have done this, I don't know. The ZX Spectrum ROM only uses a few addresses so does not have a problem with it...
As to software using different ports, well it is again a big unknown.

Maybe you could implement an arrangement so that the full decoding -v- partial decoding could be switched on/off?

As a certain creative person says above, the software can be always be "fixed".

Good luck

[Thommy]

What sort of incompatibilities are we talking about? While testing my emulator I've not yet found anything that makes assumptions that would break with your suggested 32kb RAM scheme, presumably because some of the 64kb boards have a similar effect. As for port IO, is there any justification for a change?

EDIT: I can make these sort of changes to my emulator pretty trivially if it'd help with trying anything out. Check out https://github.com/TomHarte/Clock-Signa ... ineState.c for the evidence — that stuff from line 400 and the various llz80ula_observe functions above it.

In contrast to Andy's post, if it's relevant at all, I seemed to find that the ZX81 ROM behaved incorrectly if any IO write ends vsync rather than only those with the low three bits set — specifically the line counter ends up off by one. Similarly the Fruitcake ZX80 flicker-free games acted incorrectly. Though there's always the possibility of some other latent bug.

[RetroTechie]

You may be interested to know that a circuit exists for the ZX Spectrum to increase the number of usable I/O ports to 128.

Not really... I have designed & built many logic circuits like these in the past, so I'd know what to do & how to do it, no need for an example. In my current design, such a change would be trivial.

As for port IO, is there any justification for a change?

Very simple: with the standard ZX81 I/O ports confined to a small number of I/O addresses, you can use the remaining I/O addresses in any way you like, with 0 worries about affecting the ULA's circuitry (NMI's on/off, Vsync etc).

So you're trading the very small chance that some odd demo or game uses I/O ports FDh, FEh etc on a non-standard mirror of those, versus free choice in what I/O address to use for add-on hardware, and how (and less worries doing so).

When no-one can come up with examples of such 'odd' software, I'm tending to just configure things that way & see if I can find any software that has a problem with it. As things stand now, it looks like that's a very small chance (and the chance that I'll sooner or later hook up something that uses I/O ports, is pretty big).

Make it selectable would be a nice testing option, but frankly I don't think it's even worth dedicating an I/O pin on the CPLD to (or the extra gate to make it selectable). An emulator would be a better platform to hunt for such 'odd' software...

[Andy Rea]

In contrast to Andy's post, if it's relevant at all, I seemed to find that the ZX81 ROM behaved incorrectly if any IO write ends vsync rather than only those with the low three bits set — specifically the line counter ends up off by one. Similarly the Fruitcake ZX80 flicker-free games acted incorrectly. Though there's always the possibility of some other latent bug.

Might i refer one to Grants excellent page namely...
http://home.micros.users.btopenworld.com/zx80/zx80.pdf

At the bottom right above keyboard, OR gate marked 17, pins 4,5,6 and NAND gate marked 11, pins 8,9,10 form the reset half of the Vsync RS latch, as you can see the OR gate is driven only by IORQ and WR, meaning any IO WRITE will end the Vsync... However without testing it i can't be sure if the Vsync on ZX80 ends right then or on the next M1 cycle, Grant is your man for that

It is how i have always done it in any of my clone Zeddy or ULA.

Fruitcake games eh? I'll look them up and give them a spin in the Downgraded ZX81 see what happens. the few flicker free ZX80 games i tried worked ok, space invader, kong, and a pacman type game.


@RetroTechie, for your personal use go with whatever you feel best about, but if your going to allow others to use your ULA then i would strongly stick wih the status quo, it's upto the software and hardware designers to comply with what sinclair gave us in the first place.

Regards Andy

[Thommy]

Very simple: with the standard ZX81 I/O ports confined to a small number of I/O addresses, you can use the remaining I/O addresses in any way you like, with 0 worries about affecting the ULA's circuitry (NMI's on/off, Vsync etc).

I guess that is justification, but the contrary argument is that you're splitting the ecosystem if you're getting to the position where you're designing external hardware that works only on a machine with modified internals. So, realistically, you're probably going to end up finding some way not to clash with the original ZX81's ports anyway.

With the Z80 port address being 16 bit (irrespective of syntax), surely there are 8192 unused addresses even on unmodified hardware?

When no-one can come up with examples of such 'odd' software, I'm tending to just configure things that way & see if I can find any software that has a problem with it. As things stand now, it looks like that's a very small chance (and the chance that I'll sooner or later hook up something that uses I/O ports, is pretty big).

Make it selectable would be a nice testing option, but frankly I don't think it's even worth dedicating an I/O pin on the CPLD to (or the extra gate to make it selectable). An emulator would be a better platform to hunt for such 'odd' software...

I'll use my emulator to do exactly that when I get an opportunity. I don't use Windows, but I'm working on the assumption that it wouldn't be such an easy task directly from the compiled forms of the popular emulator/debuggers?

Might i refer one to Grants excellent page namely...
http://home.micros.users.btopenworld.com/zx80/zx80.pdf

I'm feeling quite guilty for dragging the conversation off topic so please forgive my brevity but thanks for responding. I'll look at the documentation, assemble such evidence as I have properly and post something relevant in its own thread if justified. To the extent that it is relevant here, obviously you're much more of an authority than I am and the circuit diagram looks definitive.