28X2 PICAXE PlayStation

#1
Finally, I've actually produced a PICAXE project of real use. PLAY:D

It started off as a datalogger with graphical output.
After I'd done all the standard stuff you need for a datalogger, I still had room to add in data uploads and data downloads.
After that, I still had some spare menu space AND a spare slot!

What else could be added?
Oh yes, some games. (see next post if you are too impatient to read on).

The hardware is pretty basic.
Fancy box from Maplin.
Cutting the square holes was a pain but only took about 30 minutes sat in the garden with a medium sized hand file for the GLCD cutout and a jewller's file for the square illuminated push-buttons. (must use round ones next time!).

The three illuminated buttons are push fit with a drop of superglue to hold them in place.
The GLCD is held in place with double sided tape.
The on/off switch is a round fixing so that was very easy.
The other hole is the stero jack socket which doubles up for programming and data down/up loads to another 28X2 which does the actual logging.
There is also a piezo glued to the back of the metal panel.

At the back is a charging socket and PS2 connector which has 0v,5v I2C and couple of I/O pins on it. This can be used so that it can also function as a stand-alone unit for I2C devices, a DS18B20 temp sensor or 0v to 5v data logging.

Inside, not a lot.
A pack of 6XAA NiMh batteries.
A low drop 5v regulator plus caps.
A 28X2 with D1307 RTC and 24L256 EEPROM on the I2C bus.
Some pull-downs for the buttons and resistors for LEDs.
That about it. Runs for 43 hours with the LCD backlight on.
Never timed it without but should be a lot longer.

I could have only used 5*AA but I don't have any chargers for 5.
It was cheaper to add the extra cell than build a new charger.

Anyway, after selecting the main menu, you are presented with a "Games" option. See second attachement.

Oh, nearly forgot.
It uses the dedicated hardware interrupt inputs for the menu system.
It took me ages to work out why I was getting an interrupt on both the push AND the release. CONTACT BOUNCE.
I've never had issue with those buttons before but the 28X2 hardware interrupts are so blindingly fast it finds the smallest of bounce. Be warned.
I had to add 10k/22nF to suppress the bounces.

The games don't use interrupts so no need to worry if your buttons are bouncy.

ENJOY.
 

Attachments

Last edited:
#4
I've done the first two to get the ball rolling.
Waiting for someone else to come up with the others.:rolleyes:

Just wanted to tidy the code a little before posting.
I want to make it a stand-alone slot. At the moment it still relies on slot 0 for some of the initialisation and is threaded with interrupts so that data-logging can continue whilst you play!

Although....
I could just stick with the current trend in the finsished projects area.
Some wild claims with no circuit or code to back it up:mad:
 
#5
I have now attached the code in post #2.
It's not very readable because I've scrunched it down to reduce the number of pages.

It is fully standalone and can run in a single slot. Namely 0 if you so desire.
Don't worry about the hardware requirements, it is easily modified to use serout or sertxd to give the play data if you don't have a GLCD to use.
(you might want to follow with a hardware version of the game though).

The only other hardware required is a 28X2
3 X push-buttons wired to give 5v when pushed.
Optional 2 LEDs.

The buttons.
PinB.0 to make your move.
PinB.1 move the cursor left
PinB.2 to move it right

LED on C.5 On when it's your turn
LED on C.6 flashes at end of game.

The GLCD is on B.3
The GLCD status signal is on PinB.5
You do not need to use the status signal. Simply replace all the "wait for status" do:loop structures with a pause 50.

The AXE091 is an ideal platform for this project.

Special thanks to Hippy & Technical for their help with the Set/Unset bit routines.
 
Last edited:

QuIcK

Senior Member
#6
wowzers. thats impressive!
how long did it take you to get it to detect the end of the game? did you have 3 routines, 1 looking for horizontal, 1 for verticle, and 1 for diagonal (mayb 2 for diagonal)?
 
#7
Initially I opted for storing the 'game board' as a set of bytes for each plane, H,V & D. In the end I only used H & V (some of the old D symbol deffinitions remain, maybe even soem code!). The idea was to maximise speed over code space.
In practice it only takes a fraction of a second to test the 'board' for win,draw or lose.
However, it does take up to around 7 seconds to check all possible moves and outcomes for both players at a single level. Maybe implementing the diagonals as seperate data storage could improve on that.
I'd like to put in a second level check but I calculate that it would take several minutes to work it out.

With a bit more optimising and overclocking (it's the default m8 at the moment) I'm sure that could be brought down to just a few seconds but I don't have time at the moment to look into it.

Besides, it's a "solvable" game. You don't want it too smart or there is no point playing. You could NEVER win.

I'm hoping that somebody like yourself or Hippy will have a quick look and say "if you do this simple change, it will run 10 times faster".

As everyone here knows, my forte is hardware not software. I only really 'play' with code till it does what I want.

EDIT:
Just re-read your question.
Did you mean how long to write?
The test for win,draw or lose was easy. Maybe a few hours spread over 3 days.
The hard part was getting weight values that would play a reasonable game without needing to use look-ahead. (thank you Rev-Ed for the "NOB" command)

EDIT2:
Thanks for the inspiration.
Checking (using NOB) BEFORE the test would give a significant speed improvement.
(no need to check lines < four bits set)
I'll look at implementing that tonight.

EDIT3:
Tried the NOB idea. Very little change.
However, I did notice that it spends most of it's time testing the diagonals.
That's because I've gone about it completely wrong.
I 'walk' through the data looking for a row of four.
I should walk through the data and exit as soon as there is not a row of four.
It'll need a bit of a re-write!
 
Last edited:
#8
Has nobody tried this?
I was expecting at least a few comments on the game play.
Ideally, some suggestions on improving it, particularly speed wise.
 

hippy

Technical Support
Staff member
#9
I think the main limitation to trying it is that few have the same hardware configuration as you do. Although "easily modifiable" without a GLCD for Serial use that may not be the perception of somone who is unfamiliar with your code. I don't know if it will attract more interest or not, but providing a version which doesn't require modification and runs using Terminal may encourage people to give it a try.
 
#11
@Myc, Dippy has not posted in this thread (yet).

@Hippy, Good point about the hardware but as the LED042 is a Rev-Ed product I thought at least a few might have one.

Running in the simulator is not a viable option because even at the fastest setting, simulation is much slower than a real 28X2. A typical move takes around 6 minutes to calculate compared to 7 seconds on the 28X2.

If I have a quiet moment, I'll look at doing a terminal version.
Simply outputting the move played would be very easy but would require keeping note of the game play either by pen & paper or with a mechanical version of the actual game.
 
#13
I had a quick bash at doing a terminal version but was hampered by the fact that the terminal (f8) does not have a proportional font. This makes a "display" almost impossible.
The best I can offer (if anyone is interested) would be "I play postion X" type output using a simple Sertxd statement at each move.
 

nbw

Senior Member
#14
That's a fantastic project BB! Well done. I have a 128x64 GLCD myself (not the Rev-Ed serial one - I'm on a severe budget here) but haven't dared try to get the thing working yet.

How many bytes did your code come to?

I wonder if for the chess side of it, the multiple program bank space in the X2 would be good to maybe store cunning moves for the PAX to throw at the unsuspecting player?!?!
 
#15
Glad you like it.
Memory used = 1476 bytes out of 4096.

As you can see, that really isn't very much and it plays quite a mean game for such a simple play method. The problem with "Captain's Mistress" is that the game can be 'solved' which makes it impossible to beat. The method I used doesn't try to solve the problem. It looks for oportunities only.

Plenty of room left for you to add in the required code to drive your display.
Alternatively, Rev-Ed now sell the serial GLCD driver chip as a standalone.

I really don't think chess would be feasable. Not because of memory limitations but because of speed. I DO think Backgammon MIGHT be possible based on what I've seen done on very early systems such as the ZX81.
If you take out all the fancy graphics, the code is really quite compact and could well be implemented within a few slots on a 28X2.
 

nbw

Senior Member
#17
@BB - a serial GLCD IC would be really useful. Found it in the store - but like the 20x2 at present - no price attached to it? I guess it's a work in progress :)
 
#18
Beanie, I think this one rivals my 28X1 laptop for the powerful combination of most-awesome/most-useless =) I might have to get one of these newfangled 28X2 chips!
 
#19
Go for it. The power of the 28X2 leaves the lower breads standing!
The difference between the fire breathing 18X and the 28X2 is like the difference between the 08 and the 18X!

I should also point out that the project is actually a data logger with graphical analysis capabilities (whilst still logging).
The games were slipped in as an EXTRA.
 
#21
Those dinky little printers that you could NOT get the silver paper for:mad:
Aluminium foil on black paper that was vapourised by a high current going down a thin point. You could smell the ozone a mile off after a few feet of text, and where did all that vapourised alli go?
Probably explains some of my medical conditions today!
 

nbw

Senior Member
#22
That's right - and the paper was expensive. Didn't it come with 1K of RAM, and you could buy a WHOPPING 16K expansion pack? And that rubber keyboard... man, I'm old. (turning 40 in a month)
 
#23
Yep, and that massive 16k RAM pack came with a very precarious connector.
The slightest movement of the ZX81 and your program would dissapear, usually after an hour or so of typing in hex values:mad:
 

Buzby

Senior Member
#24
I remember the ZX81, I've still got a couple of boards and cases around somewhere.

But, in relation to this thread, there was a chess for the 1K machine. Given that the new PICaxes are bigger and faster than a ZX, I can see no reason why chess should not now run on a Rev-Ed device.

If anyone wants to reverse engineer the 1K chess, look here :

http://users.ox.ac.uk/~uzdm0006/scans/1kchess/

or just Google 'ZX81 chess'.
 
#25
Off you go then. We're all waiting;)

Seriously, it's probably possible to get a PICAXE to do the 'play'. It's the graphics/output which chews up code.

There would also be a speed issue. Z80 asm compared to interpreted BASIC!

Even 'Captain's Mistress' at two levels takes the 28X2 a few sesnonds.
Three level chess would take hours if not days!
 
Last edited:

Buzby

Senior Member
#26
If I remember correctly, the 1K chess just put out an 8x8 matrix of Normal and Inverse characters, and used those 64 bytes for working the logic as well !.

To display a more graphical interface, on say a GLCD, I don't think would chew up too much code. Using the 'Get Bitmap and Display' function to show real chess pieces might be classed as cheating, ( edit - I read the book wrong, Get and Display is no use at all ) but if just Normal and Inverse characters are acceptable then the Print At should suffice.

As regarding speed, the ZX80/81 ran at 4.43 Mhz ( I think it was that, it's the crystal that every PAL TV used for colour burst timing, so they were incredibley cheap to buy. ) Given that new PICaxes can run at 64MHz we are ahead already.

The efficiency of Interpreted BASIC versus Hand Crafted ASM is maybe a stumbling block, but I think a workable solution is more likely than not.

I don't know anything about how to code a game like chess from scratch, so I would have to reverse engineer the Z80 ASM. It's been many years since I did ASM on the Z80 ( but not as long ago as on the SC/MP in Clive's first computer, the MK14. Who remembers that ? ) but I'll have a go.

I'll keep you posted, but don't hold your breath.;)

Cheers,

Buzby
 
Last edited:
#27
I'd love you to prove me wrong, but even with a Z80 @ 1Mhz and a 28X2 @ 64Mhz, I think you'll still find the 28X2 several orders of magnitude down on speed.
As for output, the ZX80 mapped it's memory onto the display in hardware. No such luxury with PICAXE. You'll have to generate and output.
Even a move based text output would be quite resource consuming.

PLEASE have a go. Even if it is horribly slow, it would speak volumes as an accomplishment. Don't forget, you also have external slots available so program space (done cleverly) need not be an obsticle.
 

Buzby

Senior Member
#28
The ZX machines did not have hardware video RAM !.

The 1K models used the same RAM for both video and code, re-mapping the area not used for display as code storage, or vice-versa. The 16K expansion just allowed a fixed chunk to be dedicated to the display

And there is another point in the PICaxe favour.

The ZX81 only processed data during the TV sync times, so as to keep the screen on while still running code. This was different to the ZX80 which 'snowed' the screen while calculating, only displaying stuff when it stopped thinking.

If this is the case then the ZX81 was only effectivley running at a fraction of it's possible speed.

I'm not giving up yet :D
 
#29
The ZX machines did not have hardware video RAM !.
That was sort of my point. ALL the RAM was available not just for code but also, it could be accessed so the 'display' could be read and used as data storage. No need to track 'state of play' seperately.

Anyway, don't be put off. Give it a go.
Valid point about ZX BASIC only processing during the sync pulses but did that asm chess program do that?
 

Buzby

Senior Member
#30
I'll have to Google for a lot more detail about how the ZX's generated video. I know it cleverly used the PAUSE input on the Z80 to hold the current instruction while the video refresh counters took over the busses. ( I used the same technique to build an eprom programmer add-on for the ZX, using just a transistor and a 74123 )

It would not be feasible to do anything like that with a PICaxe, but it could be done with a raw PIC, but that's not the challenge.

I'll do some work on this when I've solved the Tx/Rx problem in my other thread.

I still am confident that we will see a chess machine built from Rev-Ed parts :)
 
#31
With my projects at a standstill while wife charges ahead with renovations (to the house) have taken an interest in this thread.

I have fond memories of the ZX81 and hacking it to improve things (wish the interweb had been around back then) I thought the following may help re ZX81 video output:

Video Tutorial

ZX81_video_technical_operation

The first link is good, as its base url.

Cheers
 
#33
and there I thought "at last, someone about to take on the challenge of PICAXE chess".

Never mind, the old ZX80/1 stuff does bring back happy memories:)
It has been a long time (centuries) since I did any Z80 assembler programming. Tempting, just no time to dedicate. Maybe when my redundancy is announced:mad:
 

nbw

Senior Member
#34
SUrely chess could be the killer app for the 20x2 we've been waiting for! How about 2 x 20x2 slugging it out... War Games, 1983, anyone?
 
#35
It'll be interesting to see how chess could be done on PICaxe, but surely keeping in everything in order to check for checkmates would chow the memory capbilities of a PICaxe to the quick. I wish I had more knowledge in the LCD's stage of PICaxes to think about it. I get the basics, but the size of the chess board.... must try and make, summer project probably.
 
Top