UDG designer

[Moggy]

I find the board to be rock solid and have no problems switching the jumper, why add more cost and complication, let people mod their own boards as needed.

[Andy Rea]

New verison of UDG Deigner updated in first post. UDGDES01.P

I have also included the dkchr.rom file in the zip so you don't have to go hunting for it

bug fix id you left the editor in 128 char mode with current char =>128 <=191 and then run the program again char zero was shown inverted in the editor until you changed to next or previous char.

Added new feature, R for Restore

key R on its own will restore the current character to its standard rom equivalent
Shift and R will restore the current block of 64 characters been edited

further suggestions and or ideas for improvement are most welcome.

Regards Andy

[Moggy]

Off we go again!!

I can't think of anything else this needs offhand, cracking bit of software.

[Andy Rea]

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.

regards Andy

[mrtinb]

It will be a few days before I have time to test this.

[PokeMon]

To be clear - it is not a problem to read/write to 8-16k area from a .p program. I think the designer is a standard p file which can be loaded normally to 16k area. ZXblast can not load data to 8-16k now but a program can do it and use this area. This will be fixed in the next release.

[Andy Rea]

To be clear - it is not a problem to read/write to 8-16k area from a .p program. I think the designer is a standard p file which can be loaded normally to 16k area. ZXblast can not load data to 8-16k now but a program can do it and use this area. This will be fixed in the next release.

Understood, but the user might need to load data before starting the editior, and certainly would like to save data after editing. As i don't have a ZXblast im going on what the manual says and bits i'm picking up from her and Martins results on various tests.

the work around for the display trick was to copy the 2 bytes after each CALL instruction to the corresponding addresses in the 48 -64 K

regards Andy

[PokeMon]

Yes - indeed if you want to execute code with more than one byte (not only one M1 cycle but with following read/write cycles M2, M3) or with D6 set to 0 - it will not be executed correctly. The standard ZX81 does due to mirroring but if you have any 48k or 56k variant this would also not work I think as long as you don't copy the code. This is typical M1NOT stuff.

[mrtinb]

If you depend on M1NOT, this might be the problem. ZxBlast doesn't support M1NOT in the current release.

[Andy Rea]

No it's not m1not, just expect full mirroring like on a 16k machine