Rom hex file help

[stefano]

You're absolutely right ! Apologies for having increased the entropy :/
I just discovered that EightyOne had and probably still has a small timing bug (1T difference probably raising from the Z80 emulation engine) which could have been a good reason to patch the original ROM. I'm curious now, prehaps the original ROM is available or perhaps it is not so difficult to manually revert the patch comparing it to the standard zx81 ROM..

[stefano]

I had a deeper look in the 4th roms.
First of all, they're very similar. The only differences are in the video loop and in the copyright message.

This permits us to understand that this video:
http://www.youtube.com/watch?v=J-f26z8Vqo4
is running in PAL mode.. if you look at it carefully you'll notice that the f4th rom is generating a different video frequency.

I havent fully decoded the video loop but it looks quite customized.. couldn't it just be not compatible with the zx80core ?
I.E. I see the video loop uses the system variable locations FC80h and FC82h.. is it normal ?

Code: Select all

00000038:	DEC C
00000039:	JP NZ,0047h
0000003C:	POP HL
0000003D:	DEC B
0000003E:	RET Z
0000003F:	SET 3,C
00000041:	LD R,A
00000043:	EI
00000044:	NOP
00000045:	NOP
00000046:	LD PC,HL

00000047:	POP DE
00000048:	RET Z
00000049:	JR -0Ah
0000004B:	DEC IY
0000004D:	LD (IY+00h),L
00000050:	RET
00000051:	LD H,(IY+00h)
00000054:	INC IY
00000056:	RET

00000057:	LD A,E4h	; <<<	FFh in the PAL version
00000059:	EX AF,AF'
0000005A:	LD HL,0098h
0000005D:	LD (FC80h),HL
00000060:	POP HL
00000061:	RET

00000066:	EX AF,AF'    ; < NMI
00000067:	DEC A
00000068:	JR Z,+02h
0000006A:	EX AF,AF'
0000006B:	RET

0000006C:	PUSH HL
0000006D:	LD HL,(FC80h)	; JUMP in the current video handling module, either $57, $71, or $98
00000070:	LD PC,HL

00000071:	LD A,23h	; <<<   x8 = 280 lines instead of 262 (NTSC standard), in the PAL version it is 4Ah, which makes it work in 592 lines
00000073:	EX AF,AF'
00000074:	PUSH AF
00000075:	PUSH BC
00000076:	PUSH DE
00000077:	LD BC,1809h
0000007A:	LD HL,0098h
0000007D:	LD (FC80h),HL
00000080:	LD HL,(FC6Eh)
00000083:	LD A,EAh
00000085:	HALT
00000086:	OUTA (FDh)
00000088:	CALL 0092h
0000008B:	OUTA (FEh)
0000008D:	POP DE
0000008E:	POP BC
0000008F:	POP AF
00000090:	POP HL
00000091:	RET

00000092:	LD R,A
00000094:	LD A,DDh
00000096:	EI
00000097:	HALT

00000098:	OUTA (FDh)
0000009A:	INA (FEh)
0000009C:	LD A,1Eh
0000009E:	EX AF,AF'
0000009F:	LD HL,(FC82h)
000000A2:	LD (FC80h),HL
000000A5:	PUSH BC
000000A6:	PUSH AF
000000A7:	LD HL,0000h
000000AA:	LD BC,FEFEh
000000AD:	IN A,(C)
(...)

[Moggy]

Great work stefano.

It would be good to find out what code needs changing in the ROM image from eighty one to make it display correctly on real zeddy.

Also the tape save/routines seem to work at a much higher baud rate than the basic ROM.

[stefano]

The strange thing is that this same ROM seems to have been used also by the Delhez`a emulator (xt2). Are we sure it is the ROM being faulty? A faster load/save routine could have been inserted by purpose.

[PokeMon]

No idea at the moment, when I have more time I will have a closer look on it.
As far as I know it is not just the video frequency - I think it will totally hang, something during startup code maybe.
RAM test ???

[stefano]

I see, I'll peep starting from the beginning, but I suppose a defect on the video loop would result on an almost immediate crash.
The video driver gets the current value from locations FC80h and FC82h and jumps in it.

Just to be sure let me ask again: is the data memory access managed in the same way for addresses > 49152 ?

[PokeMon]

I checked it and it is the original address decoding logic of the ZX80 (and ZX81).
/RAMCS is active with /MREQ and A14=1
/ROMCS is active with /MREQ and A14=0

/OE is active with either /RD or /RFSH
/WR is directly connected to /WR of CPU

I can't see a hardware issue when review the schematics.

RAM is available from $4000-$7FFF and mirrored to $C000-$FFFF.
ROM is available from $0000-$3FFF and mirrored to $8000-$BFFF.

It is unusual to write to the shadow RAM.
Does anybody know about hardware requirements ?
Could be maybe an additional (non-shadowed) RAM in this area and a fixed "DFILE" put into that extra RAM.
So writing $FC80 could maybe overwrite the stack or any other area.
Not sure about it, just an idea.

[stefano]

I did a simple experiment with EighyOne, the h4th roms stop working if you choose a memory size > than 16k and enable the m1not circuit.

I tried unsuccesfully to patch the ROM and move all the system variables under 32768, but I did not succeed fully nor the partial results changed the EO behavior. Since I'm still tracking the D-FILE position, there is still some hope on this approach.

[Moggy]

This may illustrate what I mean about the display anomaly I find on real zeddy.

On a real zeddy type the following as a direct command...

CO REV

Then create the following forth program...

: z 704 0 do ." p " loop ;

Enter as a direct command z and if the rom in your zeddy is anything like the three I burned for mine then the rightmost colum of the letter p will not be reversed, it is as if the "mask" is one chr to the left.

[stefano]

Interesting. On the screen being shifted on the top-right I noticed the same effect on EO, which should be fixable.
The NTSC version does not seem to suffer the same problem, did you try it ? I don't know if there are compatibilty problem mixings the zx81 version and the h4 ROM versions.

The strange thing of a missing inverse attribute on a column is odd.. on did you test the rom on an original zx81 ?