Sinclair ZX80 / ZX81 / Z88 Forums

It has to do with M1NOT as the ULA is typically active in this area. It is not just about mirroring, you need also special op codes that are not handled by the ULA (with bit 6 set). And if you want 56k RAM you definitely need an M1NOT interpretation which switches between tow RAM areas depending on video code execution.

No Karl it isn't m1not, my special d-file has CALL nnnn embedded.l with in it the address of the call is back to main memory < 32k area. The call opcode had bit 6 set so is interpreted just fine, the problem is then the Operand bytes ( normal read cycles, so absolutely nothing to do with m1 ) and need the correct memory mirroring, ( or in my fix the two operand bytes are copied to the appropriate location in the 48 to 64k region )

The program as is does not require m1not

Regards Andy

It is not M1NOT exactly but it is in the same drawer.

If you have a 56k RAM Zeddy, how will you distinct between video execution (need mirrored memory) and data access to >48k (avoid mirroring at all) ? If you do this trick it can only run on a Zeddy with only 40k RAM (while last 16k is always mirrored) or your data (jump address) will be read wrong because a memory read has no M1. So this can only work with always mirroring which can not be arranged with 56k RAM.

Don't believe what on EightyOne runs or not - there are some adaptions and side effects which do not show up on real hardware. I got this when experimenting with H4TH and EightyOne which does a very strange mirroring. A programming trick to get H4TH run. I think there are more tricks and considerations, wanted or accidently.

well yes there are many was to configure memory in a zeddy. i have tested the program on eightyone, ZXpand, ZXpand+ and my 64K zeddy both in mirror mode and non mirror mode ( it has page memory at 48 - 64K so it can be same memory as 16-32k or it can be other memory ) and it work sucessfully.... for a machine that has only memory upto the 56K i can make sure than my fake d-file is in the 16-24k region and then by copying the CALL addresses to the corespondng address in the 48k-56k region it will work without mirroring or m1not.

regards Andy

Andy Rea wrote: ↑Tue Aug 29, 2017 10:01 pm okies peeps, this one is mostly for Mrtinb, in an effort to make a one size fits all solution for eightyone, zxpand and zxblast here is a new release of UDGDES ( see first post for download )

because of the current difficulty to load data to the 8 - 16K region on ZXblast the first question you are now asked is to choose the address of a free 8K block of memory to use as a working area for the UDG's that you wish to edit. suggested start addresses are 8192, 32768 or 40960 in any case it should be on a 1K boundary. NOTE please do not use an address >48k for compatibility reasons some area's of the display file used during the active editor are copied to the memory region.

i guess for now, zxblast users are going to have to manually save and load memory area's but i think Pokemon is working on a patched ROM that will aloow load and save from within basic.

I can report: It now works fine with ZxBlast. Thank you.

Whhooey Thats great news Martin, as without hardware to test with i was doing a best guess

Hopefully Pokemon will have more ZXBlast in the future.

regards Andy

Does anyone have a CHR$128 font with small letters where there normally are large letters; and large letters where there normally are inverse letters?

This would be nice for the word processors that support small letters and display the large letters on screen with inverse letters.

(I use LText and Word Sinc 2, that works this way.)

This data can be arranged easily with copying/moving in a hex editor.
For having upper and lowercase you could use the ZX Spectrum charset or extract it from the ROM.
Or copy the source code section. Didn't use the designer yet but should be easy copy&paste stuff

@Andy.

Just been reading the instructions for the designer and the line which says something like "the ZX81 hardware will still invert the second set of characters"

In practise it doesn't do that at all from my experience.

For example some of the CHR$ from the inverted set I changed in the two conversions I did and I got exactly what I created with no automatic inversion whatsoever in other words a full 128 UDG set of what ever I wanted with no automatic inversion made by either the zeddy or the UDG board and definitely no inverse font except for where it's deliberately left as such.

EG design a black "X" on a white background and that's exactly what you get not a white "X" on a black background as the instructions suggest.

Check out the accompanying file M6.U8K The second CHR set I changed the inverse alphabet to to normal black on white and in use that's exactly what I get and not the inverse lettering as suggested.

Or am I missing something?

He he... in an attempt to make it easier for the end user the editor operates in a WYSIWYG mode.... for example start a new edit and choose 128 char mode now edit a normal character ( 0 to 63) to a specific pattern ( all white is a good example ) now look at the numbers immediately to.the right these are the actual bytes stored for that character ( if you picked all white they should all be 0 )... now do exactly the same pattern on a inverse character ( 128 to 191 ) now the numbers that are stored should be different so for our all white example they should now read 255. So stored in inverse because the zx81 hardware will re-invert thus giving you on screen what you saw in the editor...

It can also be noted that the characters displayed at the bottom of the screen are generated by the zx81 hardware so that is what you can expect to see when using the characters in your own program..

To be fair writing concise and clear instructions has never been a strong point for me... maybe someone with better writing skills would like to write some

Regards Andy