Newbie with DMD display & needs to speed up loops

Buzby

Senior Member
Would there be any advantage on making the source pic run on 16Mhz reso? or just leave it at 4Mhz as it's not hammering that much?
If you can put a 16MHz on the 'source' it will be better, as we will have more 'free time' between serial TX's in which to get the stuff from wherever we have it stored.
 

Buzby

Senior Member
The slowness is not in 'source' to 'driver', it's in the code inside source.

Next speedup is to up the baudrates to B115200.
( When you get a 16MHz reso in each we can run at a blistering baudrate, but not till then. )
 

OLDmarty

Senior Member
OK, source pic now has a 16Mhz reso fitted (and adjusted code for '64' settings).


This video is also with the baud rate set to 115200.....BIG improvement.

[video=youtube_share;Qb0Vty-ZBJU]http://youtu.be/Qb0Vty-ZBJU[/video]
 

Buzby

Senior Member
Getting better !.

Now we have 16MHz on both, let's try :

hsersetup 1,0 in the source,
hsersetup 1,1 in the driver.
( Just digits 1 and 0, no Bxxx_yy variables. )

This sets both to run the serial at 8 megabaud, but the 'driver' might not keep up, so if it gives problems just drop back to 115200

After this we'll get rid of the for/next and replace with 32 seperate lines, like in the 'driver'.

--

Because we've now got a working system it will make changes easier to debug.

Cheers,

Buzby
 

OLDmarty

Senior Member
Getting better !.

Now we have 16MHz on both, let's try :

hsersetup 1,0 in the source,
hsersetup 1,1 in the driver.
( Just digits 1 and 0, no Bxxx_yy variables. )

This sets both to run the serial at 8 megabaud, but the 'driver' might not keep up, so if it gives problems just drop back to 115200
OK, replaced Hsersetup as per above.....it still works! just a 'tad' faster animation


After this we'll get rid of the for/next and replace with 32 seperate lines, like in the 'driver'.
I had a go at replacing the 'source' for..next loop with 32 lines, but it's then about 380 bytes over-capacity and won't program ;-(


Overall, Definately on the improve anyway ;-)
 

Buzby

Senior Member
I had a go at replacing the 'source' for..next loop with 32 lines, but it's then about 380 bytes over-capacity and won't program ;-(

OK, the for/next just does 512 hserout's of @ptrinc.

The current for/next does 32 * 16
It could do 16 * 32,
or 8 * 64
or 4 * 128
or 2 * 256, which I think is the limit.

so two lines like

hserout 0, ( @ptrinc, @ptrinc ..... 256 times )

would be the same as 32 lines of 16.

It might fit, worth as try.

EDIT : Try attached. It fits in easy, 22 bytes free !.
 

Attachments

Last edited:

OLDmarty

Senior Member
Thanx Buzby,

I tried source v4, but the driver display is totally blank.

I also reverted back to 115200baud for the 2 chips, but still blank...doh! ;-)
 

OLDmarty

Senior Member
Thanx Buzby,
I tried source v4, but the driver display is totally blank.
I also reverted back to 115200baud for the 2 chips, but still blank...doh! ;-)
Ah Ha!
I found (in the 'source v4') you rem'ed out a debug line which also took out the "ptr = 0", so i restored "ptr = 0" and the display has come back ;-)
I also noted you have "ptr = 0" within the GetNextFrame subroutine, not sure if that's still required?

I also went back to the high (8Mbaud) settings instead of 115200 and the video below is the result....

This is "Driver" v5 and "Source" v4 in action...
[video=youtube_share;eCjrxXjIfIY]http://youtu.be/eCjrxXjIfIY[/video]
 

Buzby

Senior Member
Hi Marty,

Looks really good. A fantastic transworld cooperative effort !.
It would never have happened without the Forum to connect us.
Thanks Rev-Ed.

I don't know if there is much more we can do to up the animation rate.
Maybe hippy can ease another Hz or two out of the source.

The next step is more frame image storage, so we'll discuss our options shortly.

One thing, row 32 seems very bright. Try an extra rowclock after the last row code.

Did you get my PM ?

Cheers,

Buzby
 

OLDmarty

Senior Member
Agreed, proxy aint so bad ;-)

It would be nice to achieve speed that's perhaps too fast, requiring delays to be inserted, maybe that's for the high-end devices outside the picaxe range? even a 100MHz picaxe would solve it...

It would be nice to be able to have a decent range of speed to be able to use, from 'too slow' to 'too fast' so we wouldnt be limited by a brickwall when trying to design animations versus speed...
I'd rather put more delays IN the code to slow it down, rather than NOT be able to get it fast enough ;-)


Yep, i noticed row32 is bright, and that does open the other issue that 32 isn't actually bright, it's really row1to31 are DIM ;-(
I discovered this in recent pages, where i removed a bunch of the DISPenable codes, and the display was full brightness, but WITH ghosting...

There might still be some tweaking with the order of DISPenable, clocks, writes etc...


Now we're at a good working model, I raise an earlier question: will there be a speed advantage if we change the frame data from bytes to words?
I figure loading 256 words instead of 512 bytes must shave off some access time and potentially speed up animation rates?????



PM replied, i didn't see it, all this time ;-)

Marty.
 
Last edited:

Buzby

Senior Member
Now we're at a good working model, I raise an earlier question: will there be a speed advantage if we change the frame data from bytes to words?
I figure loading 256 words instead of 512 bytes must shave off some access time and potentially speed up animation rates?????
There is a strong possibility that using words instead of bytes in the LOOKUP tables may improve the timing.
A single LOOKUP can have 256 word entries, giving us a 512 byte frame in one line of code.

You could test this by making one, and time say 100 loops, using the same LOOKUP repeatedly.
If there is a significant improvement then I'll modify DMD Creator to handle it.

Another improvement, this time to the number of frames, is to start using the other slots.
We should be able to get about another 12 frames using these.

When we have a hardware frame memory we won't be using these lookup tables, but it will be interesting to see how far we can push the two-28X solution.

Cheers,

Buzby
 

OLDmarty

Senior Member
A single LOOKUP can have 256 word entries, giving us a 512 byte frame in one line of code.
So, could the 4 patterns in the 'source' now become 2 lookup tables of 256bytes, using a for..next "0 to 1" routine like the main TB1 routine uses?

I was also thinking about using data arrays instead of lookups, but that's probably also moving across into external storage methods anyway...

Marty
 

Buzby

Senior Member
Yes, two LOOKUPS of 256 bytes each will make one frame, so the 'For 0 to 1' is the way to go.
Joining the existing lines into big ones is easy.

Move the cursor to the end of the first LOOKUP line, backspace to delete just past the ')', insert a comma, then press delete repeatedly to bring the next line onto the end of the first.

This mod will get rid of 14 of the 16 loops, but moving to words will need a bit more effort !.

Cheers,

Buzby
 

AllyCat

Senior Member
A single LOOKUP can have 256 word entries, giving us a 512 byte frame in one line of code.
Hi,

I haven't been following your coding in detail, but beware that LOOKUPs execute much slower for longer search fields. It might be worth using more separate datafields with some form of pre-selection for the command. More detail than you probably want from around #13 in this thread.

Cheers, Alan.
 

OLDmarty

Senior Member
Hi,

I haven't been following your coding in detail, but beware that LOOKUPs execute much slower for longer search fields. It might be worth using more separate datafields with some form of pre-selection for the command. More detail than you probably want from around #13 in this thread.

Cheers, Alan.
Thanx Alan, and noted....
I guess at this stage, timing of the lookup tables isn't too critical as we're just experimenting with how much we can squeeze out of the 28X2.
The final project will have all the data stored on external eeprom/SDcard etc, and will be loaded & dealt with in a much smoother way.

Marty
 

Buzby

Senior Member
Another interesting option, a Colour DMD
(actually it's a notebook LCD with an interface fitted, to 'look' like a DMD to the pinball electronics).

http://www.colordmd.com/Home.html
That is very impressive ! ( See the videos on the store page. )

The claim is that the system interprets frames on-the-fly from the monochrome DMD controller, then artificially adds colour using a 'patented' algorithm.

It's easy to capture frames at full rate, ( not with a PICAXE ! ), but how does the algorithm work ?

I could see a way where each and every frame is replaced by a pre-defined coloured copy.
This could be done by calculating a signature for each frame on-the-fly, ( hardware could do this ), then using the signature to lookup a pre-defined replacement frame.

This method would tie-in with the fact that each game has it's own .rom file.

Very intriguing, I want to see the patent !.

EDIT : The inventor, Randy Perlow, "works as an ASIC designer and engineering manager for a major semiconductor manufacturer."
 
Last edited:

OLDmarty

Senior Member
Yep, from what i understand in the FAQ is it simply 'interprets' the incoming pattern (frame) and applies a coloured version in place of it.
It seems only 3 games are supported, i imagine it's VERY time consuming to snoop thru each frame and work out which colours they want to place where-ever.
I've emailed the site, and so far they've confirmed the 14pin DMD pin is 'standard', so there's no additional RGB signals at that end of things, it's all onboard in the interpreter (algorithm) board, which then drives the LCD.

I've asked for further info about driving a colour DMD myself (without a pinny), and i imagine i need to create my own rom file to interpret/colorize my incoming data.
If they allow it, i'd be happy to try it out, but i have a feeling they want to keep that info inhouse ;-(

Marty.
 

Buzby

Senior Member
An RGB LED DMD would be fairly easy to design, and much more in keeping with the feel of a traditional DMD.

How about that for our next project ? !!!


I've searched for the patent, but no luck.
Can someone else try, I may have not been using the right terms.
 

OLDmarty

Senior Member
Technically it's not a true DMD, but an LCD with adapter board, you could probably still make an RGB DMD board with no legalities ;-)

Nothing to stop a hobbyist version coming to life, Interesting either way.... ;-)

Marty.
 

Buzby

Senior Member
Hi Marty,

It's gone a bit quiet - have you got any new animations to show us ?.

I've been thinking, when we put external memory on we will have storage for hundreds of frames.

How do you envisage managing the display of these ?

Cheers,

Buzby
 

OLDmarty

Senior Member
Hi Buzby,

Been tied up with some work of late, but still tinkering in the background...

I'm still trying to master the brightness issue, but besides that, i think we can only move forward by taking the next step into external storage.
Since the source pic is FULL with 4 frames, i can't do much else (like an 8 frame anim etc).

Also with larger storage, it will then allow us to try some shading techniques too, this is probably something that needs to be integrated into DMDcreator as you step thru each frame?


While the external storage will no doubt store the frames in 512byte chunks(pages), i would have simply used a master pic/axe to call upon the address at each of the 512byte start address.
For example, calling upon the first 3 frames to be displayed would simply send 00h, 201h, 401h as their 'start' addresses.

Storage Map:

0000h-0200h = 1st frame (512 bytes)
0201h-0400h = 2nd frame (512 bytes)
0401h-0600h = 3rd frame (512 bytes)
.
.
.
.
.
.
.
0nnn - nnnn (last frame in rom, whether it's 100, 1000 or 10,000 frames stored, depends on storage used).


Regards,
Marty.
 

Buzby

Senior Member
Hi Marty,

... Since the source pic is FULL with 4 frames, i can't do much else (like an 8 frame anim etc)....
The 28X2 has 4 x 4k bytes of program storage accessed using #slot n, we have used only #slot 0.
Each #slot will hold 7 frames, giving us 25 frames in total.

I will put together a new GetNxtFrame that will access the extra slots.

... Also with larger storage, it will then allow us to try some shading techniques too, this is probably something that needs to be integrated into DMDcreator as you step thru each frame? ...
I don't think we'll have much chance with full screen shading, the update rate is too low.
However, there is a technique we can use to increase the *apparent* update rate considerably, just to test the effect.

Most of the 'source' delay is in the LOOKUP tables in GetNxtFrame. If we bailed out early, say after looking up only 16 or 8 rows, we would just update the top half or quarter of the DMD. This would give faster animation rates, but only a portion of the image would be moving, or shaded, the rest would be static.

This is easy to try.
Just make four images, each with blocks in the top few rows to show 25%, 50%, 75%, 100% brightness, then 'bail out early' from GetNxtFrame.

This 'selective update' I'm sure is used in real systems, and if PICAXE had a bigger addressable range when used as I2C Slave we could have done selective updates to any subset of the screen easily. There may be some mileage in trying to overcome this limitation, but it's a trade-off between fast subsets and slower full frames.

Regarding mass storage, we have some options.

I2C is easy and fast, and I've used it lots, but getting the frames into it from DMD Creator will need some thought. ( Not many laptops have I2C ports ! )
There may be USB-to-I2C dongles around, I've never looked. If so, this is a good possibility.

Another way is to use serial through the AXE027. Needs a lot more code, but no hardware.

Otherwise SD card or USB is probably the way to go, but I've used neither before.

If I was to choose I'd go for AXE027 for the transfer from PC to PICAXE, and an I2C eeprom on the PICAXE for the runtime.

Plenty to think on here !

Cheers,

Buzby
 

Buzby

Senior Member
Hi Marty,

After a few hours of banging my head trying to get this code working, I discovered my breadboard has developed some dodgy connections !.
( It is a good few years old, 15 maybe, so probably time for a new one !. )

The code is in 4 files, one for each Slot.
You need to download each one individually, the #Slot directives will tell the compiler where to put each file.

This code is just a framework. It's not got the latest speed-up mods, and you need to fill in the blanks, i.e put 24 frames in !.

It's fairly self explanatory, but if you want any clarification just ask.

--

This code is just temporary to get a few more frames on show, it will not run any faster than we have now.
The I2C stuff that I'm working on now will not need any of this Slot business, and will access 1000's of frames in super quick time.

It's going to take a week or two, there is a lot to do - modify DMD Creator to use the AXE027, write a protocol for downloading frames, re-write GetNxtFrame, etc. etc.

This is going to be one cool piece of kit !.

Cheers,

Buzby
 

Attachments

OLDmarty

Senior Member
Thanx Buzby, looks interesting.....

After some snooping around for SDcard info, it seems (impossibly) hard to master, and the SDcard docs/standards don't seem to agree with one another, which complicates matters further for the hobbyist.
So far, SDcard requires a FAT formatted system, that can read/write in FAT terms, which seems to be so heavy in code that it leaves no room in a pic to do anything else.....

So, in the name of "getting something working SOONER than LATER" i think i'm opting to use i2c serial eeproms.

I've found a 1Meg (24LC1025) which is really 128k x 8 which would happily hold 256 of our 512byte Frames.
A maximum of 4 of these devices can be wired on the same bus (4 addresses, using A0,A1 pins) to then offer 1024 Frames of storage.

The A2 pin is not an adress pin on this device (although A2 is used on smaller capacity eeproms),
A2 is really just another chip select, although we could wire 4 chip selects together and run 2 'lots' of 4 chips to double the capacity to 2048 frames.
(in fact several 'lots' of 4chips, could all be run back to something like a 1of8 decoder (or spare pin on pic) to expand the entire storage array to something quite large, yet PHYSICALLY small on the board, especially if SMD ;-)


Marty.
 

hippy

Technical Support
Staff member
So far, SDcard requires a FAT formatted system, that can read/write in FAT terms, which seems to be so heavy in code that it leaves no room in a pic to do anything else.....
SD Cards don't have to be FAT formatted but can be accessed on a raw block basis. Even with FAT code it isn't that bad for reading though it's perhaps easier to stick to MMC and less than 2GB SD Cards.

The advantages are fairly obvious; easy to use with a PC and fast to transfer data from PC to card. The PC software simply has to generate a data file, nothing more. Even a 32MB MMC/SD Card will be able to hold 65,000 frames and at today's second hand prices for just 10p or so.
 

Buzby

Senior Member
Hi Marty & hippy,

I've not used SD with PICAXE, but there are plenty of examples on this forum to look at, and it doesn't look too difficult.
Using SD to transfer is no doubt the fastest way, but I don't think that is the best route for other reasons.

I still see this project as POC, so I would rather concentrate on bettering the PICAXE, and stick with technologies I am familiar with.
If the project was more than POC then I would go for USB for transfer, because I think USB is more user friendly than SD, but still use I2C eeprom on the PICAXE.

--

This device is going to need some kind of control for selecting playlists of animations.
I suggest IR remote control. It's very little hardware, and a doddle to program.

--

I've got a 24LC256 wired up to my 'source', and I'm working on making a new GetNextFrame to access the pictures in it.
Simultaneously I need to write code in DMD Creator to send the pictures via AX027.

I could really do with a set of frames which display 0 to 63 to test these routines.
Marty, could I please ask you to make these, as you can test them easier than I can ?.
( I'm hoping to blag my way into a arcade game trade show soon, and see if I can get a sample DMD !. )

Have you had a chance to try the 24 frame slot-based code yet ?.
I don't need to see the results for the work I'm doing now, I'd just like to see a 24 frame animation driven by a PICAXE !.

Cheers,

Buzby
 

OLDmarty

Senior Member
No probs, i'll program the 'slot' programs and 1/m 1/2 way thru making up a 24frame code ready to test...

I also have some 24LC256's hanging around here, i will start wiring one (or at least an empty socket) to my source pic in readiness....
I'm using the C.3 & C.4 pins, being the hardware i2c pins, and i'm assumng you wired your eeprom Adress pins (A0,A1,A2) as address "0" ???

If that's all good, i'll proceed to keep wiring...

Marty.
 

Buzby

Senior Member
Hi Marty,

Yes, I2C on the dedicated pins. Don't forget the 4.7K pullups !.

Address 000 is correct.

I'm working on the DMD Creator interface to AXE027 at the moment.
What com port is yours on ? ( I could write code to allow selecting any com port, if I need to. )

Cheers,

Buzby
 

OLDmarty

Senior Member
Nup, i NEVER forget pullups after forgetting them MANY years ago ;-)

Ok, i'll keep tinkering along with it all....hopefyully have soemthing running in a few days, and a vid etc...

My AXE027 lives on com3 on my laptop, and/or com4 if i use the other usb port, although i think the port should be selectable or auto-detect, to accomodate whatever pc/lappy we use it on.

Marty.
 

Buzby

Senior Member
Hi Marty,

I'm working on the I2C and DMD Creator, but there's a lot to do, and I've got work as well, so it's going to be slow progress at this end.

Did you try the 4-slot code ?.

I would really like to see a 24 frame animation.

Cheers,

Buzby
 

OLDmarty

Senior Member
HI again,

Yep, work's been flatout recently for me too, but i'm tinkering along....although my main laptop with my DMD screens has been borrowed for work-use for a few days, so it's not home for me to dabble with for a few more days.

I've been tinkering with some other picaxe concepts (not DMD related) until my lappy is back home.
 

handyandy

New Member
Hello All

I have two of the Freetronics red led matrix screens. I am new to picaxe. I have tried A r d u i n o but it is to complex for me, Its ok you you just want to connected things down load a code and it works, but i would like to understand what the Picaxe is doing.

So is there any simple diragrams on who to connect these to the picaxe chips and i see the code has been posted, has there been any updates on it.

Thanks for your help inadvance
 

OLDmarty

Senior Member
I'm working on building a new setup. Instead of using 2 of: 28X2's, i'll use 2 of: 40X2's to offer more memory options.
 
Last edited:

AllyCat

Senior Member
Hi,

So what is your "requirements specification" now? I have no intention of reading through 156 previous posts to find out. :(

Cheers, Alan.
 

lbenson

Senior Member
I'm working on building a new setup. Instead of using 2 of: 28X2's, i'll use 2 of: 40X2's to offer more scratch pad memory etc.
No additional scratchpad memory in 40X2s relative to 28X2s. From manual 2:
Code:
PICAXE-28X1, 40X1, 20X2 parts have 128 scratchpad bytes (0-127)
PICAXE-28X2, 40X2 parts have 1024 scratchpad bytes (0-1023)
 

Buzby

Senior Member
Hi Marty,

2013 was a long time ago !

It's going to take me a few days to gather my thoughts together.

A quick look in my PICAXE folder shows 'DMD_Source' at v10, 'DMD_Driver' at v5, and 'DMD_Creator' at v7.

Do they match with your last versions we worked on ?.
 
Top