little assembler game challenge

Chris Micro · 2009-06-29 08:09

Hello together,

would it be possible to write a little game in assembler on the propeller which fits in only one cog?
There are these demo-challenges where the people try to fit a program in minimal space.

cheers,
chris

Nick Mueller · 2009-06-29 09:50

> would it be possible to write a little game in assembler on the propeller which fits in only one cog?

Whatever processor you have, you can design a game that fits into it.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

heater · 2009-06-29 10:24

Sure. How about a simple "duck shooting" game? Cycle one illuminated LED, the duck, around the 8 leds of a Prop Demo board. Have the player hit a button to "shoot" the duck when it arrives at a particular position. Keep a score of the number of hits and display in binary on the LEDs when so many ducks have past. Speed it up a bit for the next level. Have more than one duck lit up at a time. Randomize the times that ducks appear.

Now add sound effects for realism...

That's about the sophistication of games we used to make for old microprocessor development kits with tiny amounts of memory and I/O.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon · 2009-06-29 10:39

That's what I did with my Motorola 6800 D2 kit, over 30 years ago. It only had 128 bytes of user RAM, which I expanded to 256 bytes.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

heater · 2009-06-29 10:42

Games have not improved much since then. They just have 3d ducks now, in colour, with shading...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

potatohead · 2009-06-29 23:13

LOL!!

I love this comment, and it's often true.

Don't forget the value added, downloadable SUPER DUCK that's shown on the box, but only appears after you look in your wallet again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

CounterRotatingProps · 2009-06-29 23:33

The VASDWD generator !

Value Added Super-Duck Wallet Drainer

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chris Micro · 2009-06-30 12:33

Hi all,

thank you for your comments.
OK, it is clear: to connect some leds and switches to the Propeller would enable the chip to be a kind of game console.

I was thinking of connection VGA and a Keypoard or Mouse to the propeller. One could use the drivers in the object library.

The challenge would be to write game code in one COG ( the cogs used for VGA and Keyboard do not count ).

I think it is an excellent method of learning efficient assembler programming.

chris

Cluso99 · 2009-06-30 12:41

@Leon: The 6800D2. Had one of those and the D1. I am meeting a mate tomorrow to interface his D2 (bought on eBay) to a prop so it can be used as a terminal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Leon · 2009-06-30 12:59

It came as a kit and rather to my surprise it worked as soon as soon as I put it together. I think it cost me £209, equivalent to over £1,000 today, at a guess.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

heater · 2009-06-30 12:59

OK. Same duck shooting game[noparse]:)[/noparse] But with 2d ducks and maybe colour. Input from keyboard. Score on screen. Just POKE the ducks as chars/tiles into the video memory wherever it is in HUB!

Ducks can now move in 2d space as well.

It must be possible to get a Pong game in PASM in COG this way. Who knows where this challenge leads.

Embellish until COG is full. Then learn to do it in LMM and start using HUB for program space.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-06-30 13:55

Hi heater,

the reason why I wanted to have a one cog game is that I could run it on my COG-emulator. It runs on linux and writing hub-memory address 0 will output a char to the console. I made the console commands compatible to the vga_text.spin object, so you can set the color and cursor position. In my opinion this is a very good base for running a propeller asm based game on a pc.

For me this game would be a good test to see if I implemented the propeller instruction set correctly.

chris

heater · 2009-06-30 14:03

OK. Not a bad idea. When I get a moment I'll try and fire up cogEmu.

Does it support rd/wrlong/word/byte from HUB memory? If so I can see me wasting endless hours getting ZiCog to run under cogEmu under Linux!

Which might get me into a lot of trouble[noparse]:)[/noparse]

Edit: Sorry just read your post again. You can at least write to HUB 0000.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-06-30 14:24

Hi heater,

yes, the hub-memory commands are available. If it would be useful to print the output by accessing other memory locations than 0x0000 I could do that.

Sorry, if I let you to wasting endless hours running your ZiCog on the Emulator

( btw I would appreciate seeing the emulator running on the PC ) Is one COG sufficient?

chris

heater · 2009-07-01 17:52

Running this might take me a while to get around to.

One COG is sufficient for the actual CPU emulator PASM. Then another COG takes care simulating disk and console I/O which is Spin code. Then whatever COGS are required for console serial coms and SD card access etc.

I was thinking to just getting the basic CPU emulation working in the virtual COG for now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-07-01 18:40

>I was thinking to just getting the basic CPU emulation working in the virtual COG for now.

Hi heater,

I'm very curious how it works ...

If you need a second cog, you will find attached the "2 cog version". If you want to use a second cog, just take a look at the example file test.spin ( coginit is only working as in the example at the moment )

Have fun,
chris

heater · 2009-07-02 05:15

In ZiCog the PASM z80 emulation code handles IN and OUT op-codes by writing out the I/O port number and data bytes to HUB and then stops. At that point the Spin hardware emulation sees this and uses the info, performing console I/O or disk I/O as required. When done the Spin stops in a "repeat" loop and the PASM continues. A simple flag coordinates all this.

I'm thinking that initially its best to skip all the Spin stuff and just try and run the emulator PASM. That I/O stuff can be picked up by the COG emulation C code and console I/O simulated there. Perhaps even the disk hardware emulation could be done in C at some point.

The way I mostly run CP/M in ZiCog is to have the OS code loaded into HUB and the start the emulation. This way we can run CP/M up to it's command prompt without any disk I/O being required.

A couple of questions.

Have you taken care that self-modifying PASM code is simulated correctly? That is re: timing and the need for at least one instruction between a modified instruction and the instruction that does the modifying.

               movs  mod_inst, #3
               nop                                 'NOP required else 0 is added below not 3
mod_inst  add  something, #0-0

Have you tried to run the Props Spin interpreter? The code for it is posted here somewhere.

Still no time to play with this today though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-07-02 08:04

>The way I mostly run CP/M in ZiCog is to have the OS code loaded into HUB and the start the emulation. This way we can run CP/M up to it's command prompt without any disk I/O being required.
Later on we could think about reserving a special io location in the emulator for some disk access. The pc would have enough space

>A couple of questions.
>Have you taken care that self-modifying PASM code is simulated correctly? That is re: timing and the need for at least one instruction between a modified instruction and the instruction that does the modifying

Hmm, no, is it essential? The timing of the emulator is slightly different. It simply takes the instruction and executes it. So there is no need of the nop instruction.

>Have you tried to run the Props Spin interpreter? The code for it is posted here somewhere.

I was thinking about that. I saw the interpreter code. Probably someone wants to try it. With the sphinx-project there would be an open source spin interpreter for the pc.

In the attachment there is the 4 COG version. I'm not sure if I should make an 8 COG emulator. On my 1.6GHz Atom the 4 Cog emulation runs with about 3MIPS/COG.

heater · 2009-07-02 08:19

Sorry to say Chris but I think it may be essential. If I remove the NOP from the code snippet I posted above like so:

               movs  mod_inst, #3
mod_inst  add  something, #0-0

then 0 will be added to "something" when run on the Propeller but if your COG emulator does not include the pipeline delays then it will add the 3.

This may not matter in 99% of code as people tend to include the NOPs (or put some other useful instruction there) but it will trip up eventually somewhere.

I think the solution maybe as simple as reading the next instruction just before writing out the result of the current one. Unless I'm missing some other Prop subtleties.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-07-02 08:38

Yes, I know that it is essential on the Prop. But it seems no problem for me if someone uses the Prop Code on the Emulator: it works. It might be a problem if someone writes a program on the emulator and ports it to the Prop. In this case the people have to know it and to avoid this trap.
I could introduce a delay in the emulator, but it is time consuming in the emulation.

heater · 2009-07-02 09:04

I don't think you can get away with it in general. What if that last code sequence I posted is SUPPOSED to be like that (no NOP)? What if it is executed more than once? First time through 0 will get added, second time through 3 will get added. There WILL be code out there that does sneaky stuff like that (Prop coders are very devious[noparse]:)[/noparse]) and the emulation will fail.

We have to face the fact self modifying code like this is an essential concept in the Propeller and that if the emulator produces a different result than a real COG then the emulator is just wrong.

Anyway things are not so bad. Surely it cannot be so hard to include (not that I have looked at your code yet). There is no need to add a time consuming delay into the emulation. As I said I think it would suffice to just read the next instruction just prior to writing out the result of the current one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

little assembler game challenge

Comments