Possibly hundreds (?) of new games for the MTX
Re: Possibly hundreds (?) of new games for the MTX
I can't get the Zip to download, it starts, but immediately stops with 0 bytes downloaded, and the message "this file could not be downloaded"
Re: Possibly hundreds (?) of new games for the MTX
Uploaded again. Try this copy.
- Attachments
-
- zvm_200112.zip
- ZVM source and executables
- (270.45 KiB) Downloaded 813 times
Re: Possibly hundreds (?) of new games for the MTX
Just tested. I can download either copy without any issues.
Re: Possibly hundreds (?) of new games for the MTX
The new one worked a treat. (6 partial downloads of the other version deleted!)
Re: Possibly hundreds (?) of new games for the MTX
Just to confirm, not only did the download work, the fixes do too.
While testing, I ran the MTXplus at various speeds, obviously faster is better, but subjectively, at 4mhz, M576ZVM seems a lot faster than CPMZVM, far more so that the 30% less cycles figure would suggest. It probably makes the difference between slow, and a little too slow.
But either is a great addition to the MTX game "market" which you've probably doubled in one go!
Now everyone needs one of Andy's memory cards !
While testing, I ran the MTXplus at various speeds, obviously faster is better, but subjectively, at 4mhz, M576ZVM seems a lot faster than CPMZVM, far more so that the 30% less cycles figure would suggest. It probably makes the difference between slow, and a little too slow.
But either is a great addition to the MTX game "market" which you've probably doubled in one go!
Now everyone needs one of Andy's memory cards !
Re: Possibly hundreds (?) of new games for the MTX
Martin,
I am not surprised that you found M576ZVM to be significantly faster (well less slow).
The cycle counts given in the earlier post are best case values obtained on MEMU and do not include cycles spent waiting for I/O.
Also, they are taken at the start of the program, when M576ZVM is loading the entire story file into RAM. Once it has done so, and you are playing the game, it never has to read the disk again, unlike CPMZVM which is having to swap bits of the story file in and out of memory. So the difference in cycle counts is almost certainly higher once into the game.
I am not surprised that you found M576ZVM to be significantly faster (well less slow).
The cycle counts given in the earlier post are best case values obtained on MEMU and do not include cycles spent waiting for I/O.
Also, they are taken at the start of the program, when M576ZVM is loading the entire story file into RAM. Once it has done so, and you are playing the game, it never has to read the disk again, unlike CPMZVM which is having to swap bits of the story file in and out of memory. So the difference in cycle counts is almost certainly higher once into the game.
Re: Possibly hundreds (?) of new games for the MTX
In terms of hardware support, it would be possible to produce a custom version for the CFX-II.
The speed would be in between that of M576ZVM and CPMVVM.
The CFX-II has a silicon disk rather than extra memory for a RAM disk. With the silicon disk it is not possible to directly access individual bytes of the RAM, you have to read or write a sector at a time. However, by copying the story file into consecutive sectors of the silicon disk, and bypassing all the file system logic, the swapping would be more efficient than for CPMZVM.
The speed would be in between that of M576ZVM and CPMVVM.
The CFX-II has a silicon disk rather than extra memory for a RAM disk. With the silicon disk it is not possible to directly access individual bytes of the RAM, you have to read or write a sector at a time. However, by copying the story file into consecutive sectors of the silicon disk, and bypassing all the file system logic, the swapping would be more efficient than for CPMZVM.
Re: Possibly hundreds (?) of new games for the MTX
I have produced a bit of a write-up of the porting process for Dave's site.
It is an example of how, sometimes, speed improvements can best be obtained by re-thinking the high-level design rather than low-level optimisations.
It is an example of how, sometimes, speed improvements can best be obtained by re-thinking the high-level design rather than low-level optimisations.