- the memotech hrg board works well only on very old versions
- the microdrive cartridges can be easily destroyed on exit (file truncate at 0 bytes)
I am not familiar with the operation of the HRG board. Could you provide some more details on what doesn't work so well. If you could provide step-by-step instructions on what to do to replicate the problemsand explain how it should behave then that would be really helpful.
Does this always happen or just sometimes? Again, any step-by-step instructions on how to reliably replicate the problem would be helpful.
I hope I haven't mixed the files but it should be the same binary which worked on a real ZX81: https://www.z88dk.org/wiki/lib/exe/fetc ... mt_hrg.jpg
Other versions, especially when only the first 64 graphics lines are used and 32K RAM is chosen work also on recent EO versions.
There is probably also some bug on my code, possibly the emulator is doing everything correctly, but I noticed the difference and I wanted to point it out... as said it can be my fault, at the time I used the old EO as reference, then someone was testing my results on the real HW
- (8.61 KiB) Downloaded 115 times
I noticed there is a small glitch at startup on both versions where it looks like an extra line is inserted right across the maze from the left tunnel to the right tunnel. The glitch is only momentary and shifts the maze down then back up. It makes me wonder whether the program is writing to the wrong part of memory. The glitch occurs at the start of each life. Might this be randomly crashing the game?
Here is the corruption caught on the game running on 1.12:
Some times the corruption is a solid black line, other times a few dots. But always across the line.
What difference do you see when running the game on 0.42z and 1.12?
I don't know how compatible the EightyOne.ini file is between the two versions so it might be worth making sure you delete it and let a new one be created.
also the frequencies are probably odd, I thought that my theories were right after the successful tests and the confirmation of the test on a real hardware (on a flat screen, though).. then the later EO versions don't show the picture at all
Is there any problems when the program is run twice on a real Memotech card?
This program is an asm code, and a bug can corrupt the card memory...
On the Xur, a second RUN display a bad UDG.
I had to test a french demo using the &0-&400 memory room, how we can switch it using an IRQ...
There is a 1kb memory buffer in the HRG Memotech !
Located beatween &0 and &400.
It's use by the memotech rom to the display feature.
In EO, this inboard buffer is assigned by the HRG card, but, the user can't write it. (RO restrictions over the ROM)
If we POKE a value in this room, the buffer memory will be changed... [/WR set to 0 => set inboard buffer)
RAND USR 16514 : Copy the ROM in the BUFFER (read ROM-refresh buffer!)
POKEs update the buffered rom (/WR redirected to the card!)
RAND USR 9346 : Init the HRG and set the memory buffer in RD stat... &0-&400 will be read, not the ROM.
IRQ $5F set to 2, the /RD read the buffer, not the monitor ROM...
(this IRQ assume 0,2 and 3. : bits 0 & 1)
The ROM/buffer trigger is located in the HRG ROM :
Code: Select all
ORG $2482 ; [@9346/@h2482] Lb2482: LD A,$02 IN A,($5F) ; Memotech HRG mode. RET ; ==========================
Code: Select all
'// 5Fh - Memotech HRG card. If Port_ID = &H5F& And G_Card = eHiResMEMOTECH Then ' Debug.Print "Input Port MEMOTECH: "; Hex(port) If Mem_Display = 0 Then ' Clear display buffer. ClrMemory sLastScreen(0), 768 ' Clear display buffer. ClrMemory gcBufferBits(0), 6528 ' Clear Basic display. gpicDisplay.Cls End If Mem_Display = CByte(Int(port \ 256)) ' 0 for Basic Display, 2 for HRG buffer and 3 for Inverted display. If Mem_Display = 0 Then FrmMainWnd.DispHRGon Else FrmMainWnd.DispHRGoff ' Bit0= 0=> Normal Basic Mode / 1=> Inverted Display. ' Bit1= 0=> Rom (Set RomCs'=1) / 1=> Memotech buffer actived.(0h to 400h)