Page 1 of 1

Memofest 2014 - a bit of fun, with a serious side

Posted: 27 Jul 2014 00:27
by Dave
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 ... 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,, 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. :lol: )

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.

(Number 1 Judge)
(Address details for the aforementioned padded envelopes available on request)

Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 27 Jul 2014 17:38
by 1024MAK
No bias then :lol: :lol: :lol:


Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 05 Sep 2014 22:39
by Bill B
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 :oops: , an updated zip file with a (hopefully) working version of CODE.BAS.

Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 05 Sep 2014 22:51
by Dave
Hi Bill,

BASIC isn't excluded, so, you have the honour of being the first official entrant :-)


Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 06 Sep 2014 11:19
by Bill B
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.



Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 07 Sep 2014 20:10
by Dave
Sneak preview . . . . .
Capture.JPG (67.3 KiB) Viewed 3294 times

Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 04 Oct 2014 17:44
by Bill B
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.


Re: Memofest 2014 - a bit of fun, with a serious side

Posted: 05 Oct 2014 09:40
by Bill B
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 :oops: .

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.