OK Folks,
as a bit of fun, but really, to hopefully to stimulate a bout of frantic programming in advance of Memofest 2014, Martin and I have decided that we will donate a MAGROM board - see
http://primrosebank.net/computers/mtx/p ... magrom.htm
to the winner of a Memotech programming competition.
Whilst a fully featured MTX program or game would be nice, it is probably a bit of a stretch to expect one in the time available - even though we have some of the original Memotech games programmers around, including, Andy K, Jim, Keith, Rich, Andy S, et.al., along with converter extraordinaire, Claus.
So, even if we can't expect, for example, a Memotech version of Elite, the entries should be functional at a basic (rather than BASIC) level, i.e., they should allow the user to get an appreciation of what the program / game is intended to do. Bugs, crashes, etc., will not be cause for disqualification, but obviously, higher scores will be awarded for a more mature offering.
Any subject matter, e.g., games, utilities, etc., is acceptable - only limited by your imagination.
(Platform games will be rewarded with a score inversely proportional to the number of existing MTX platform games. )
Enhanced firmware for original Memotech hardware will also be considered.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Competition Rules
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
- Most good competitions, and all of the bad ones, have them, so here goes . . . .
1. The Judge(s) decision is final and no correspondence will be entered into.
2. There are no restrictions on the number of entries per person.
3. Extra points will be awarded for programs that can fill a Memotech Type 03 floppy disk, and even more, for programs or a suite of programs, that can fill an 8MB SD card
(Excessive use of padding of file(s) to increase the disk-space used will result in instant disqualification and a severe slagging off of the offender during Memofest 2014 and likely for a considerable time afterwards)
4. The software should have been first written in 2014
5. The software should have been created from scratch.
Complete rewrites of similar software/games from other platforms is acceptable.
"Porting" of software, either manually, or using translation tools is not (sorry Claus).
6. Enhanced firmware for original Memotech items (ROM code etc.) is acceptable
Updates to firmware for existing modern day enhancements, such as REMEMOrizer is not (sorry Andy).
7. The prize will be presented at Memofest 2014
Should the winner be unable to attend, they will still be eligible for award of the prize, but the
prize will only be sent to a valid UK address, unless the winner pays the cost of overseas shipping.
8. The competition will run from 27th July 2014 to the date of Memofest 2014, currently scheduled for 20th September 2014.
The closing date will change to the actual date of Memofest 2014 should the event be rescheduled.
9. Any attempt to bribe or otherwise unfairly influence the judge(s) will only be considered acceptable if the following conditions are met :
a) The offering / transaction remains confidential between the initiator and the judge(s)
b) The offering is considered by the judge(s) to be acceptable
c) The offering shall have been fully processed in advance of the competition's closing date
d) The judge(s) shall not be compelled to act on the influence offered / regardless of whether it has been accepted (see Rule 1)
e) If a "facilitation" payment is to take the form of "cash", the only acceptable forms of payment are :
i) Bearer bonds drawn on an entity in Western Europe or the USA
o - Bonds drawn on entities located in Nigeria and similar countries shall be excluded
o - Non compliant offerings shall be confiscated by the judge(s) with no right of appeal
(See Rule 1)
ii) Cash - large denomination, used notes in the following currencies :
o - US Dollars ($)
o - UK Pounds (£)
For the avoidance of doubt, Euros, Monopoly money, or currencies with similar credibility are not acceptable
Regardless of whether option i) or ii) is selected, the offering shall be submitted in a padded brown envelope
10. The Judge(s) decision is final and no correspondence will be entered in to.
11. See Rule 1
Force Majure
Should a working Kelly Materializer be demonstrated during the course of Memofest 2014, the competition rules shall be immediately rendered null & void. The prize will be awarded to the producer of the Kelly Materializer and the device’s output shall be immediately confiscated by the senior judge and taken away for further, in depth, analysis.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Competition entries should be sent to the undersigned by e-mail and should include the source and executable code that has been demonstrated to run to some level on real Memotech hardware and/or MEMU. In the case of real hardware, please describe the hardware configuration used and for MEMU, please state the required MEMU parameters to run the program.
regards
Dave
(Number 1 Judge)
(Address details for the aforementioned padded envelopes available on request)
Memofest 2014 - a bit of fun, with a serious side
Re: Memofest 2014 - a bit of fun, with a serious side
No bias then
Mark
Mark
Standby alert
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Autumn is here. Bye bye summer 2024...
Not as many MTXs as Dave!
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Autumn is here. Bye bye summer 2024...
Not as many MTXs as Dave!
Re: Memofest 2014 - a bit of fun, with a serious side
So does that mean that something written at the BASIC level is excluded?
My puzzle-game "Crack the Code" is written in MTX BASIC for the SDX. It can also be run in MEMU in hardware emulation mode (loading the SDX ROM and using an mfloppy file for a disk). Interestingly, it has problems in software emulation mode (-sdx switch). (Andy, there is an issue with random file access, I have not yet had time to track down the details).
I will concede that the code is a bit slow in places. I call that thinking time I am presently undecided whether assembler acceleration of a few key routines, or a complete re-write in assembler as a .run file would be more effective.
EDIT: Having finally managed to read the instructions for cpmcp correctly , an updated zip file with a (hopefully) working version of CODE.BAS.
My puzzle-game "Crack the Code" is written in MTX BASIC for the SDX. It can also be run in MEMU in hardware emulation mode (loading the SDX ROM and using an mfloppy file for a disk). Interestingly, it has problems in software emulation mode (-sdx switch). (Andy, there is an issue with random file access, I have not yet had time to track down the details).
I will concede that the code is a bit slow in places. I call that thinking time I am presently undecided whether assembler acceleration of a few key routines, or a complete re-write in assembler as a .run file would be more effective.
EDIT: Having finally managed to read the instructions for cpmcp correctly , an updated zip file with a (hopefully) working version of CODE.BAS.
- Attachments
-
- code.zip
- Corrected ZIP file. Unzip contents then use CPM toos to copy all three files onto an SDX floppy or MFLOPPY file.
- (12.29 KiB) Downloaded 1377 times
Last edited by Bill B on 06 Sep 2014 18:49, edited 2 times in total.
Re: Memofest 2014 - a bit of fun, with a serious side
Hi Bill,
BASIC isn't excluded, so, you have the honour of being the first official entrant
regards
Dave
BASIC isn't excluded, so, you have the honour of being the first official entrant
regards
Dave
Re: Memofest 2014 - a bit of fun, with a serious side
A little clarification, my "Crack the Code" game is written for a single disk SDX system, not specifically for a CP/M system.
It assumes that the game files are in the default A: drive. Display is on the video screen, not on the monitor screen.
If using MEMU, then use CP/M Tools to copy the game files onto a bootable MFLOPPY file. Load the SDX ROM as ROM5 (or ROM3), and the MFLOPPY file as the first disk file. Boot and do ROM 5 (or ROM 3 as appropriate). Then USER DIR "CODE.*" should show all three game files in upper case. In which case you should be good to go: USER LOAD "CODE.BAS" followed by RUN.
You can use a CP/M system, but you have to ensure that the game files are on drive A:. Then use MTX.COM followed by ROM 5.
Enjoy,
Bill.
It assumes that the game files are in the default A: drive. Display is on the video screen, not on the monitor screen.
If using MEMU, then use CP/M Tools to copy the game files onto a bootable MFLOPPY file. Load the SDX ROM as ROM5 (or ROM3), and the MFLOPPY file as the first disk file. Boot and do ROM 5 (or ROM 3 as appropriate). Then USER DIR "CODE.*" should show all three game files in upper case. In which case you should be good to go: USER LOAD "CODE.BAS" followed by RUN.
You can use a CP/M system, but you have to ensure that the game files are on drive A:. Then use MTX.COM followed by ROM 5.
Enjoy,
Bill.
Re: Memofest 2014 - a bit of fun, with a serious side
Having worked out where the MTX BASIC variables are hiding in memory, a little bit of machine code provides a reasonable speed-up of my game. It is still not fast, but the new version (attached) is not quite as slow.
Bill.
Bill.
- Attachments
-
- code2.zip
- The new version of the game is CODE2.BAS, the data files are the same as for the previous version.
- (13.6 KiB) Downloaded 1363 times
Re: Memofest 2014 - a bit of fun, with a serious side
One of the issues with using the MTX assembler is that the location of the code changes depending upon the size of the machine being used. This has two implications:
1. When using the USR() function to call the assembler, you have to use a system variable to determine the correct address. I managed to use the wrong one .
2. All the addresses within the machine code block have to be re-calculated. Unfortunately the MTX does not to this automatically when loading a program into a machine with a different memory size. To update the addresses it is necessary to ASSEM each code block, and then exit again without making any changes.
To work around this, I have now saved two versions of my program. The source of the two is identical (now using the correct system variable), but CODE232K.BAS has the assembler addresses calculated for a 32K machine, while CODE264K.BAS has the addresses calculated for a 64K (or above) machine.
1. When using the USR() function to call the assembler, you have to use a system variable to determine the correct address. I managed to use the wrong one .
2. All the addresses within the machine code block have to be re-calculated. Unfortunately the MTX does not to this automatically when loading a program into a machine with a different memory size. To update the addresses it is necessary to ASSEM each code block, and then exit again without making any changes.
To work around this, I have now saved two versions of my program. The source of the two is identical (now using the correct system variable), but CODE232K.BAS has the assembler addresses calculated for a 32K machine, while CODE264K.BAS has the addresses calculated for a 64K (or above) machine.
- Attachments
-
- code2.zip
- Corrected version of CODE2, with versions for different memory sizes.
- (16.19 KiB) Downloaded 1364 times