Shop OBEX P1 Docs P2 Docs Learn Events
Propeller GCC - TV Demo — Parallax Forums

Propeller GCC - TV Demo

BaggersBaggers Posts: 3,019
edited 2013-06-06 01:19 in Propeller 2
Hi All,

I've got my driver initially converted to run with the C stuff.

It's still working from TOP of memory for it's buffers for now.

But if you unzip this demo, and copy the Graphics folder to the SD card
then in a prompt of the MAC/PC that has Propeller-gcc setup, type
make run
Which will then make the demo, and run it.

It will then scan the Graphics folder and load every BMP file it comes across.

Make sure the BMPs are 32bit, and 768 pixels wide ( although it only shows 640 of the 768 pixels ), and 480+ deep.

http://www.jimbagley.co.uk/P2_BMP_Viewer.zip

This is the updated version, which is a BMP viewer, you unzip, copy the Drivers, Fonts, Graphics folder to your SD card, ( careful not overwriting any old graphics files for those on Macs )
Assuming you have the C setup installed, you can compile it with

make run

Or just run it manually with P2Load as the object is pre-built

p2load -b 115200 -r 1, TVGraphicsDemo.elf -t

Navigate with Key3 down and Key1 up, and Key2 select, then Key2 when you've finished looking at the pic, to go back to the file select
You can also load new fonts, if you have old 1bit ( two colour ) fonts, any size up to 256 chars ( 8x8 )

I've left the old version, as this has the Graphics folder still ;) saves me adding all the graphics each time.
http://www.jimbagley.co.uk/TVGraphicsDemo.zip
«1

Comments

  • potatoheadpotatohead Posts: 10,261
    edited 2013-05-25 17:39
    This works just great.

    And it validates the PropGCC build I did last week. Nice. I'm up on Snow Leopard.

    @all: If you don't get a successful read on the SD, format it and drop the Graphics folder on there. Should work then. FAT16, 2GB is what I used.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-26 00:31
    Thanks for the extra info potatohead ;)
  • ColeyColey Posts: 1,110
    edited 2013-05-27 04:45
    Cool.

    I had the same issue, didn't work first time.
    Formatted the SD card then it worked just great.
    FAT32 16GB (Sandisk Utra SDHC)

    Regards,

    Coley
  • BaggersBaggers Posts: 3,019
    edited 2013-05-27 10:19
    And again to you too Coley, cheers :)
  • potatoheadpotatohead Posts: 10,261
    edited 2013-05-27 12:56
    I just found the library will fail with other folders on the disk. After a bit of shuffling to cut down on the images displayed. (I put them in a not-graphics" folder.) File open no longer worked. Took a format to fix that one. Just FYI.

    @Baggers: I'm gonna break out the scope and I've made some test cards for the driver. The new one renders nicely on a digital NTSC HDTV, but isn't centered. Tears on an analog one with component option turned on. Composite looks good, and I got a coupla pictures. Crappy ones, but I'll send 'em along later tonight when I get another pass at this.

    I strongly suspect the pixels are coming too early in the scan line for NTSC, but can't confirm it yet. I'm gonna have a nice DVD player that does the full frame, output a few test images for me to look at on the scope to see what is what.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-27 15:02
    Ok cool, again thanks for the feedback potatohead :)
  • potatoheadpotatohead Posts: 10,261
    edited 2013-05-27 15:10
    Getting there. :) In the end, it's going to get sorted.

    I'll have another go late tonite. We are just out of sync time zone wise. I found the C fiddly, due to the fixed addressing. Sometimes I can modify code, sometimes I can't.

    For a quick test, I just ran the SPIN older driver and this one in C. The good news is ordinary composite seems to look equally good on my displays! :) The basics are deffo there. I'll catch up with you on SKYPE once I know something.

    @Coley, FAT 32? Sweet! That means an ordinary format operation on Windows and Mac OS will work great. Did you format the card to 32GB, or smaller?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-27 15:27
    potatohead wrote: »
    I just found the library will fail with other folders on the disk. After a bit of shuffling to cut down on the images displayed. (I put them in a not-graphics" folder.) File open no longer worked. Took a format to fix that one. Just FYI.
    Ugh. Sounds like there might be some problems with the PropGCC filesystem code.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-27 15:38
    The TV driver that I did, wasn't meant to be C compatible, and has fixed addresses at top of memory, ( this could be where the SD driver stores info? )
    I'm gonna work on making it all use a PAR to the COG to set the structure for the hub ram layout. this could fix the problem, before we go searching around the PropGCC filesystem code.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-05-27 16:01
    Seconded. I really just made the comment for others tinkering more than anything else.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-27 17:58
    Baggers wrote: »
    The TV driver that I did, wasn't meant to be C compatible, and has fixed addresses at top of memory, ( this could be where the SD driver stores info? )
    I'm gonna work on making it all use a PAR to the COG to set the structure for the hub ram layout. this could fix the problem, before we go searching around the PropGCC filesystem code.
    The stack is at the top of hub memory.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-28 02:37
    Yeah, I'll move that around later ;)
  • pedwardpedward Posts: 1,642
    edited 2013-05-29 14:07
    David, this thread gets me thinkin', what kind of memory allocator does PropGCC have?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-29 14:16
    pedward wrote: »
    David, this thread gets me thinkin', what kind of memory allocator does PropGCC have?
    malloc/free but we've also added a hubmalloc and hubfree for use in xmm-single and xmm-split modes. In lmm/cmm/xmmc modes hubmalloc and malloc do the same thing.
  • pedwardpedward Posts: 1,642
    edited 2013-05-29 15:32
    David Betz wrote: »
    malloc/free but we've also added a hubmalloc and hubfree for use in xmm-single and xmm-split modes. In lmm/cmm/xmmc modes hubmalloc and malloc do the same thing.

    I was speaking more about the allocator algorithm. How does it handle allocation and consolidation? Is it a standard buddy allocator?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-29 15:52
    pedward wrote: »
    I was speaking more about the allocator algorithm. How does it handle allocation and consolidation? Is it a standard buddy allocator?
    I'm not sure. I didn't implement the library. The source is in Google Code if you'd like to look at it. It's in propgcc/lib/stdlib.
  • pedwardpedward Posts: 1,642
    edited 2013-05-29 16:55
    FWIW, it uses a very simple approach. Malloc maintains it's own used/free heap and requests additional heap space via _sbrk. The caveat with this 2 layered approach is that memory, once freed, is not returned to the main heap. I was thinking that as C become more of a mainstream language for the Propeller 2, memory allocation and heap resources will become a pressure point.

    I was reading up on the buddy allocator system recently, and it make for an interesting and efficient system of memory allocation, but I was thinking of another approach that was brought on by this thread.

    The buddy allocator performs binary division of the heap to dice up blocks of memory that are the minimum required size. It keeps a free heap list for each memory block size available, if a block is unavailable, it breaks down one of the next larger blocks, working its way up the list if necessary. When freeing, it checks to see if the buddy block in the same larger allocation unit is free, then recombines them.

    In the context of the Propeller, you might have 2 different types of allocator needs, the "runtime" heap and the "system" heap. The idea would be that you could use the buddy system to first divide the HEAP into heap1 and heap2. heap1 would be for "frequent" allocations and heap2 would be for "static", or infrequent, allocations. Objects like frame buffers or network devices would allocate static buffers, but may be unloaded.

    The runtime would try and allocate only from heap1 unless it encounters memory pressure, then heap2 would handle the overflow. But the point is to try and allocate large contiguous chunks from heap2 and allow heap1 to become fragmented.

    Another option would be to choose heap2 vs heap1 based on the size of requested allocation. By default the large requests would be satisfied from heap2 and small from heap1, with the probability being that small allocations lead to more turnover and fragmentation, while large allocations are typically longer lived and benefit from contiguous blocks.

    Forget about realloc, that's a mess an a half if you are handling large blocks!
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-29 17:34
    pedward wrote: »
    FWIW, it uses a very simple approach. Malloc maintains it's own used/free heap and requests additional heap space via _sbrk. The caveat with this 2 layered approach is that memory, once freed, is not returned to the main heap. I was thinking that as C become more of a mainstream language for the Propeller 2, memory allocation and heap resources will become a pressure point.

    I was reading up on the buddy allocator system recently, and it make for an interesting and efficient system of memory allocation, but I was thinking of another approach that was brought on by this thread.

    The buddy allocator performs binary division of the heap to dice up blocks of memory that are the minimum required size. It keeps a free heap list for each memory block size available, if a block is unavailable, it breaks down one of the next larger blocks, working its way up the list if necessary. When freeing, it checks to see if the buddy block in the same larger allocation unit is free, then recombines them.

    In the context of the Propeller, you might have 2 different types of allocator needs, the "runtime" heap and the "system" heap. The idea would be that you could use the buddy system to first divide the HEAP into heap1 and heap2. heap1 would be for "frequent" allocations and heap2 would be for "static", or infrequent, allocations. Objects like frame buffers or network devices would allocate static buffers, but may be unloaded.

    The runtime would try and allocate only from heap1 unless it encounters memory pressure, then heap2 would handle the overflow. But the point is to try and allocate large contiguous chunks from heap2 and allow heap1 to become fragmented.

    Another option would be to choose heap2 vs heap1 based on the size of requested allocation. By default the large requests would be satisfied from heap2 and small from heap1, with the probability being that small allocations lead to more turnover and fragmentation, while large allocations are typically longer lived and benefit from contiguous blocks.

    Forget about realloc, that's a mess an a half if you are handling large blocks!
    You're welcome to experiment with different memory managers if you'd like. If you come up with one that works better than the simple one we currently support we can consider replacing ours with yours.
  • pedwardpedward Posts: 1,642
    edited 2013-05-29 17:53
    David Betz wrote: »
    You're welcome to experiment with different memory managers if you'd like. If you come up with one that works better than the simple one we currently support we can consider replacing ours with yours.

    I don't know that my ideas are any better, I just have a hunch.
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-05-30 07:46
    I looked at the code, and I see a couple of issues. The line buffer is hardcoded to the address 0x1c000. This is probably OK in your case, but it's better to declare the buffer as an array or to malloc it. The other problem I see is that you are using dp->d_name after you have done a closedir. closedir will free the buffer that was created by opendir and used by readdir, so dp->d_name may not be valid after that. This implementation of opendir, readdir and closedir may not be exactly standard's compliant. I'll have to check into that.

    You should probably call opendir from your main routine, and getfilename would just have to get the next file in the directory instead of having to scan through the directory each time it is called. Another solution would be to do strcpy(filename, dp->d_name) before calling closedir, where filename would be declared at the top of your program as "char filename[13]".
  • BaggersBaggers Posts: 3,019
    edited 2013-05-30 08:30
    Yes, Dave, the TV driver was written before I had PropGCC set up, so memory allocation was done old style, knowing where things were.
    As for the d_name after, was a mistake, as it was going through changes, and I wanted to get a first version out for others to see.
    As I have it being able to select a file, from the list, and navigate through directories.
    I just need to get some time to get the memory buffers for the display driver to be allocated, and all in a PAR that's passed to the driver.
    Hopefully this weekend.
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-05-30 09:26
    I searched around a bit to see if the use of dp is allowed after a closedir, but I couldn't find anything about it. In general, I think it's best not to use the contents pointed to by dp after calling closedir. It should definitely not be done with PropGCC.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-30 09:33
    Yeah, I'm not allocating any memory so the contents should still be there, once the routine returns, not that I will in the finished version though. :)
  • BaggersBaggers Posts: 3,019
    edited 2013-06-01 02:21
    I have the driver working now, in a section of HUB-RAM allocated in C. I'll update once I get it loading an image, at the mo, It seems to stop not sure if it's because the -t cog is getting zapped as it's loaded as cog0 for some reason.


    David, can the -t terminal be run in a specific cog? as it seems to start itself in COG0, and gets over written by the TV driver now, don't know what I did different to make it do that?

    Is there any chance, you can make it do -t4 to make it start in cog4?

    Cheers
    Jim.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-06-01 04:36
    Baggers wrote: »
    I have the driver working now, in a section of HUB-RAM allocated in C. I'll update once I get it loading an image, at the mo, It seems to stop not sure if it's because the -t cog is getting zapped as it's loaded as cog0 for some reason.


    David, can the -t terminal be run in a specific cog? as it seems to start itself in COG0, and gets over written by the TV driver now, don't know what I did different to make it do that?

    Is there any chance, you can make it do -t4 to make it start in cog4?

    Cheers
    Jim.
    You need to use "-r n," to run the main program in a different COG. Note the trailing comma. For example, to run the main program in COG 1 you would use this option:

    -r 1,
  • BaggersBaggers Posts: 3,019
    edited 2013-06-01 06:21
    My misunderstanding,is printf done in C, through it's own driver?

    Btw, what is running in Cog0? anything?

    I'm curios as to why the file IO is stopping on doing an opendir now.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-06-01 07:13
    Baggers wrote: »
    My misunderstanding,is printf done in C, through it's own driver?

    Btw, what is running in Cog0? anything?

    I'm curios as to why the file IO is stopping on doing an opendir now.
    By default printf uses the SimpleSerial driver which does not require an additional COG. The SD filesystem however *does* require a COG. It starts that COG using cognew so it gets the first COG that is free. So, if you use "-r 1," to get your main program running on COG 1 and then try opening a file before starting your video driver in COG 0, the SD driver will get loaded into COG 0. If later you start your video driver in COG 0 the SD filesystem will stop working. The solution is to start your video driver before opening a file. There is currently no way to force the C runtime library to use a particular COG for the SD driver.
  • BaggersBaggers Posts: 3,019
    edited 2013-06-01 07:32
    That'll be it then, as I was loading the TV driver from the SD :D
  • David BetzDavid Betz Posts: 14,516
    edited 2013-06-01 08:59
    Baggers wrote: »
    That'll be it then, as I was loading the TV driver from the SD :D
    You could try just loading some dummy code into COG 0 before accessing the SD card, then stopping it before loading the video driver.

    How about this? 
    ' Copyright (c) 2013, David Betz
' All rights reserved
' Contact author for licensing terms
' (I'm hoping to make a bundle on licensing this code)

DAT

    org 0
    jmp #$
  • BaggersBaggers Posts: 3,019
    edited 2013-06-01 13:36
    David, and all, thanks again for your help.

    I couldn't find the binary value in instructions.spin for JMP, there's JMPRET but no JMP as I was going to do it as a single int, included in the C. I ended up using a 2K pre-cleared buffer ( part of the screen ), so it'll be nops, until it gets to the sysvars I'll fix it in next update.

    HAHA nice one on licensing! :)

    Works a treat now anyway, even with the 0s for the coginit.

    Will fire up the PC later, and do a jmp #$

    Updated the first post :D enjoy!
Sign In or Register to comment.