mrtinb wrote: ↑Sun Aug 27, 2017 10:38 pm
Currently I can only get games to work, that contains the UDG and copies it to the right location. Software that needs seperat load of bin-file to 8192 currently fails with ZxBlast. I seem to remember these bugs will be fixed in next firmware.
I had only tried to load the ROM-file into RAM. This didn't work due to the current state of ZxBlast.
But when I flash the ROM-file into ROM at location $2000, then it works perfectly.
(Haven't figured how to run UDGDES yet.)
I described the reason in my posting above. Maybe try to read again and maybe understand difference between loading data into 8-16k ROM (no problem as the ZXblast instance 0 also have ROM in this region) rather than RAM. This is solved but not yet available.
Andy Rea wrote: ↑Mon Aug 28, 2017 11:19 pm
Ah i think i know why it crashes.... but i need to test my theory on my 64k machine... which i am nowhere near at the mpment....
The UDG Designer does a neat little trick in the lower half of the editor window, it displays a line of ROM character, then 1 blank scan line and then a row of UDGs chars, 1 blank scan line row of ROM chara so 8 rows and 8 blank scan lines during the blank scan line code is actually executed to alter the i register mid display.... so....
For it to work correctly the 16 to 32k memory must be mirrored to the 48 to 64k region always not just during the M1 fetch.
The code embedded on the blank lines is a CALL xxxx so your getting the CALL because that the M1 cycle but then your not getting the xxxx your getting something else from the other memory....
That's my theory anyway.... one of my other demos from a while back wouldn't work on some maxed out zeddy either for the same reason
Regards Andy
ZXblast operates different and does not mirror the display file. If video display is detected (A15&A14&!/M1), A15 on RAM side is forced to 0 during display while leaving the 48-64k memory untouched. If video display is not detected it will execute the wrong code (in 48-64k region). One workaround could be to copy the code manually in the 48k-64k area.
Another one would be to activate the compatibility mode in ZXblast config (not yet available in software but in hardware possible) while forcing A15 to 0 always. This way you have all mirrored but limited to 32k RAM.
Thanks Karl for a very speedy response, maybe i will just try to write a zxblast version. Alongside the zxpand version, wouldn't really need much changes and could maybe be done with conditional compiler if defs.... my fake d-file is static in memory so moving it to a higher ram area is no problem.
Regards Andy
what's that Smell.... smells like fresh flux and solder fumes...
Andy Rea wrote: ↑Mon Aug 28, 2017 11:33 pm
Thanks Karl for a very speedy response, maybe i will just try to write a zxblast version. Alongside the zxpand version, wouldn't really need much changes and could maybe be done with conditional compiler if defs.... my fake d-file is static in memory so moving it to a higher ram area is no problem.
Regards Andy
Or maybe just ask on screen if user has ZxPand or ZxBlast. Then one binary works for all.
PokeMon wrote: ↑Mon Aug 28, 2017 11:20 pm
I described the reason in my posting above. Maybe try to read again and maybe understand difference between loading data into 8-16k ROM (no problem as the ZXblast instance 0 also have ROM in this region) rather than RAM. This is solved but not yet available.
Thank you for explaining this to me.
I am a software man, and have learned about hardware thru these forums. I try to follow your thread about ZxBlast on the german forum, but most information there is way over my head.
mrtinb wrote: ↑Tue Aug 29, 2017 11:31 am
Thank you for explaining this to me.
I am a software man, and have learned about hardware thru these forums. I try to follow your thread about ZxBlast on the german forum, but most information there is way over my head.
Okay - sorry if it is very technically. Every computer has an address room which is divided into ROM and RAM. A typical ZX81 has 16k rom and 16k up to 48k ram. Only 8k is used for ZX81 rom and the second 8k is free so can be used as ram if the hardware supports this feature. The ZXmore does.
But when the file loader is active, the instance is temporarily switched to ZXblast control which you can see at the led colour as well (goes out). The ZXblast firmware does not fit into into 8k and so need 16k rom. To write in 8-16k ram the address decoder has to be programmed but this way you have only 8k ZXblast firmware or code sequences are not available.
In the past I did check that the 8-16k ram area can be used as RAM with simple PEEK/POKE and didn't expect here problems with the loader code. The code could be reconfigured theoretically to have the desired code in the first 8k. But I am not a friend of this kind of sophisticated software engineering and better solved this in a hardware change to allow the programming via the memory paging function. I switch on paging in the ZXblast instance and move the page to the 8-16k address area of the desired instance.
