ULA revistited.

[sirmorris]

That won't work with ZXpand. I've modified the statup code quite comprehensively

C

[PokeMon]

Because the first five bytes of the ROM are written to by the Basic as the result of an error in the maths.

I dont think so.
The CPU may try to write in my ROM but I think it will never do this successful.

And I think if anyone has moved a RAM to this location, he will be able to correct the BASIC math error.

[Paul]

You are absolutely right. It will Not succeed.
But that's not the problem. If poking there will set Andys configuration, the math error will also do randomly. I don't think this is what Andy wants. Anyway, I knew Sirmorris would have problems with the startup routine

[siggi]

Because the first five bytes of the ROM are written to by the Basic as the result of an error in the maths.

It's not a bug, it's a feature: instead of writing the 5 bytes of a floating number to the calculator stack, they are written to "/dev/null" (or address 0 in the Z80 memory map ), when they are not needed on the stack. So by loading the destination register with 0 (instead of the calculator stack address), the same subroutine may be used ...

And that is the reason, why the German ZX-Team uses the addresses 7, 8, and 9 for POKEing, to enable specific features of the ZX2000 or to do memory-bank-switching in the ZX96 ...

Siggi

[Andy Rea]

yeah, i'm not exactly replacing the rom byte with ram, but... since as the ULA has direct connection to the CPU data bus it can do what i am after...

when pokeing a memory location that lies in ROM the ROM is enabled because of the incomplete memory decoding, but this should not prove troublesome as the ula will see the cpu data, and not what the rom is outputing.

when peeking a memory location that lies in ROM the ROM is once again enabled, but unlike the CPU the ULA can only pull the data lines LOW, not drive them high, thats why i'm after a ROM location that contains $FF

I have taken M1 into account so should for some reason the memory read be an M1 cycle the cpu will see the ROM data.. $FF is RST $38 if i am not mistaken, i don't think it is used in the rom anyway... i might be wrong.

anyhow if this thing works like i am thinking, there's gonna be bog standard mode, and advanced, but advanced will require a little soldring to connect the missing address bus lines.

Regards Andy

P.s i remember reading somehwere about the calc attempting to write to rom, but can;t remeber where.

[PokeMon]

I think it's not a good idea to change rom code in general. Maybe it's better to extend standard rom code after it does initialization.
If Andy needs only 6 bit instead of 8 bits for control of the ULA he might use 0068h / 104 decimal.
There he find a $FA code (JP M,....)
But maybe someone changed the code of the NMI service routine as well.

Code: Select all

;; NMI
L0066:  EX      AF,AF'          ; (4) switch in the NMI's copy of the 
                                ;     accumulator.
        INC     A               ; (4) increment.
        JP      M,L006D         ; (10/10) jump, if minus, to NMI-RET as this is
                                ;     part of a test to see if the NMI 
                                ;     generation is working or an intermediate 
                                ;     value for the ascending negated blank 
                                ;     line counter.

        JR      Z,L006F         ; (12) forward to NMI-CONT
                                ;      when line count has incremented to zero.

[Andy Rea]

I could use any address >4 to write to the 8 bit latch, but i really wanted to be able to read that value back also...

I like ' 101 ' it's easily remebered


Andy

[Paul]

Hi Andy.
You said the ROM is enabled due to restricted decoding. As the ULA does so, would it be possible to activate ROMCS only when a opcode is fetched? Peeking the ROM isn't really required, except for pixeldata which is fetched like an opcode.
So what would happen if you wouldn't enable the ROM when not fetching opcodes?
Am I missing something?

[siggi]

So what would happen if you wouldn't enable the ROM when not fetching opcodes?

You would get a black screen during SLOW mode, because the character generator in ROM is read during refresh cycles, not during opcode fetch cycles.
So you can sell your monitor, because you won't need it anymore

Siggi

[Paul]

So what would happen if you wouldn't enable the ROM when not fetching opcodes?

You would get a black screen during SLOW mode, because the character generator in ROM is read during refresh cycles, not during opcode fetch cycles.
So you can sell your monitor, because you won't need it anymore

Siggi

Thanks for the hint I thought I was missing something
So: is it possible to enable the rom during opcode fetches AND refresh, but not during peeks.
We are talking about the ULA. That's the master of everything