IMHO, VBLANK, HBLANK, SCANCNT, VISIBLE are the core outputs needed. Right now, I use a simple write only for TV cog, read write graphics cog in potatotext. It works nicely, but probably isn't needed, if a scan count were just maintained in the TV cog. Good call. Probably created more work for myself the first time around, doing it the way I did.
Re: Pins. I like what's been posted. For stuff like video, and probably other things like sound, would it be fair to say those core elements don't need to be aware of that standard, because they will be setup and started by something that is? I'm asking for reasons of focus. It seems to me, having a stand alone binary build possible is language neutral. I really want to see that happen this time, so users of C, prop basic, etc... can use the product of this next effort, and so things can be fetched from SD card, or EEPROM, or something else (bluetooth??) as needed. It's time for that, because bigger things can be built now.
For those binary blob type things, I'm thinking there should only be a pointer to a sequential block of longs, and a document that details what those longs do. The parent project, whatever it is, would read the global parameters, stuff the longs, and fire off the driver, ideally overwriting where it started in the HUB to do something else. Sample configs can be commented in and out, written as a method, or loaded as binary data as well. I'll be using [noparse][[/noparse]name].cog for the loadable, executable file.
The only real assumptions are then, the system clock stored at the default location, PAR being used to tell the driver where it's block of communication lives, and that everything is long aligned. Organizing everything else happens one layer up. (buffers and such)
@Baggers, Cluso, et al.. Yeah, thanks! I'll need it. Time to build out the PAL for potatotext, before building anything else out.
- for objects where the pin order is guaranteed to have to be the same, I only supply starting pin (TV, VGA)
- KB/Mouse pins can be in any order, I wanted to preserve the flexibility, still a problem for Hyrda which uses 4 pins each
- unfortunately, the order of SPI pin's have not been standardized by everyone; heck due to confusion, I use different orders on some of my own boards!
- many boards have multiple SPI ports, so it is not enough to have a generic SPI set of pins
- SPI standards use MOSI and MISO so there is no possible confusion as to which is the input and output on slave or master
- while laying out this version, I kept ProtoBoard, DemoBoard, and all my boards in mind, as well as Hydra (except for 4 pin kb/mouse - that is very unique)
I am still trying to figure out a nice way of handling multiplexed SPI ports (several /CS, but only one set of CLK, MOSI, MISO)
Basically, *_pins.spin will work great for describing the standard interfaces (vga,tv,kb,mouse,audio,sd,eth) but cannot work for XMM - for that, I've made VMCOG - it also can't work for non-standard graphics such as PropGFX and Morpheus.
I am pretty happy with it being able to handle >90% of boards though [noparse]:)[/noparse]
Oldbitcollector said...
A few comments. Some object only require the starting pin. Take the first pin only?
Also, I thought the following names were used a little more often with the SD. (DI & DO)
(Same with ethernet.)
I tried handling many configurations by providing:
pin#js = 1 if there is a Joystick interface
pin#js_first = starting prop pin
pin#js_last = ending prop pin
This accommodates using 5 prop pins for an Atari stick, 3 for serial-input-parallel-output shift registers, or 4 for an MCP23S17
There are too many possible joysticks and interfaces, I think we need a "JS.SPIN" standard joystick interface object, which can use the above three fields to interface specific hardware, and give things like direction and buttons.
I will be working on such an API, and trying to keep it flexible enough to cover Hydra, PropCade, etc - however we may also need an ajs.spin object for analog joysticks, unless we decide to emulate analog on digital joysticks, and digital with analog sticks, in the same API
FYI, the PropCade joystick interface is implemented with six button Sega controllers in mind, however I am perfectly willing to adopt the NES encodings - except I will add more buttons on higher bits [noparse]:)[/noparse]
Maybe something like
js.read(n) ' reads digital joystick N
and bit masks that are exported constants from the js object:
js.readx(n) ' read X coordinate from analog joystick
js.ready(n) ' read Y coordinate from analog joystick
js.readz(n) ' read Z coordinate / thubmwheel from analog joystick
trodoss said...
@Bill,
In a lot of Hydra/Game code, there are the NES bit encodings present. Something like the following:
' NES bit encodings for NES gamepad 0
NES0_RIGHT = %00000000_00000001
NES0_LEFT = %00000000_00000010
NES0_DOWN = %00000000_00000100
NES0_UP = %00000000_00001000
NES0_START = %00000000_00010000
NES0_SELECT = %00000000_00100000
NES0_B = %00000000_01000000
NES0_A = %00000000_10000000
Since joystick/gamepad code and pinouts would be different for each, maybe leaving them out of that would be a good idea. Thoughts?
Bill Henning said...
Here is my first pas at 'demoboard_pins.spin' ... comments please
From the Sphinx thread ....
Oldbitcollector said...
Oh no, not the pin map discussion again.. [noparse]:)[/noparse]
...
OBC
It was a good idea 2 years ago when first discussed, it's still a good idea, and I've used it several times. A small problem is how it gets included in a build for the user. With BST/BSTC it's easier because we get a library path, but one still needs to remove the file from a newly published package. With Propeller tool, the user's file has to be copied.
Bill you can copyright the names [noparse]:)[/noparse] You can't even trademark them in spin i.e. tx(tm) [noparse]:)[/noparse]
Some of the names are a little terse even for me.
ser - ? SerialPortEnable maybe?
rx,tx - is this for console only?
exp1 ?
Good thing constants don't consume memory [noparse]:)[/noparse] This coding convention has lots of growth potential.
LOL... sorry, old time developer here, automatically put copyright notice on everything I write... if people are offended, I will remove it on this one, but I explicitly stated MIT [noparse]:)[/noparse]
Well, since the physical interface is serial, I used 'ser' - but will change to serial [noparse]:)[/noparse]
rx & tx are standard names, even on PropPlug, demo board etc...
Nice work! I wish I'd noticed this a couple of years ago!
Some comments:
- suffix for VGA1,2 etc is almost never needed, maybe have no suffix for first interface, and add a digit if more than one exist? ie vga, vga2
- a little verbose for me, I like short names [noparse]:)[/noparse] as I grew up on Unix [noparse]:)[/noparse]
- I prefer SD to FSRW, sometimes I use Kye's great driver
- specific RTC belongs in an RTC object, many different ones in use (we do need a standard RTC object though, to abstract different RTC's)
- xbee, hydranet, ping gps etc only needed on boards that implement them
- instead of coding specifically to NES, we should have generic JS object - but we can keep bit encodings same if you like
The main differences between your wiki pins and mine can be summed up as:
- Bill likes short names, Jeff likes long names
- Bill prefers only implemented pins in a specific board's file, Jeff wants all possible boards all possible peripherals in one file
(I know, I showed unimplemented devices in my demoboard example, but that was for demonstration purposes (dolphins?))
Oldbitcollector said...
Yes, I was thinking that... [noparse]:)[/noparse]
It's still a good idea!
Here's the pin defs I uploaded to Wiki a couple years ago..
BTW, OBC's pindefs.spin includes the clock configuration ... this is very important to have. Some people use strange _xinfreq values [noparse]:)[/noparse]
I can remove exp(x)... reason was to specify if 8 pin group was unused - but it is not necessary.
I was thinking of leaving the clock definition to the OS... however if it is here, we could even have the FREQA constants for NTSC/PAL pre-computed in CONSTANT() expressions...
jazzed said...
Bill, I'm not sure exp1 adds any value.
BTW, OBC's pindefs.spin includes the clock configuration ... this is very important to have. Some people use strange _xinfreq values [noparse]:)[/noparse]
Bill Henning said...
I was thinking of leaving the clock definition to the OS... however if it is here, we could even have the FREQA constants for NTSC/PAL pre-computed in CONSTANT() expressions...
Not that it matters too much, but not everyone will use an OS [noparse]:)[/noparse] It does however bring up a good point:
If you want to have your own definition of _xinfreq for example, including the pindefs.spin with that syntax gives it to you. Alternatively pindefs.spin can use "xinfreq = 5_000_000" for example instead of "_xinfreq = 5_000_000" and that will allow you to include the definition in a separate file without overwriting whatever an OS already provides when an OS compliant binary boots. One could argue however that applications shouldn't be touching pins directly, but instead rely on the drivers provided by the OS [noparse]:)[/noparse]
re Pins... Good work guys but on way out so no time to look closely, but a few comments...
P31/30: I always use SI and SO because TX & RX mean different things at each end and I have seen SI & SO in objects.
SD: I prefer the DO & DI (Out & In) which seems common in objects. All need specifying. For multiple /CS do the whole 4 pins again like SPI2_DO, etc. Not sure how the software will handle re-used pins - I have the same issue here, guess it will be the software MUST handle these things.
Audio: Can we use AudioL & AudioR rather that LAudio & RAudio?
Kbd & Mouse: Sometimes the data and clock are reversed - is that just a Hydra thing? Of course I have a 1pin keyboard object.
VGA & TV: I did spec the extra pins - next time I am short of pins I am thinking to use a 74LVC2G86 to save a VGA pin (HS & VS can share a pin). I already have 1pin TV which can also be great for debugging.
I will let you guys continue with the clkfreq idea.
I did mention that I would like this in a SD file, but hey we can use the same for both!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@potatohead: Firstly, sorry we hijacked your thread for the pins discussion :-(
The NTSC IIRC can have 32 lines for PAL so 8x32=256 visible lines - see my 1pin TV object. There is also some extra timing info here that may be of help to you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Wow, this thread I started took on a life of its own. It originally started as a request for comments on a software project to enable a simple propeller circuit (i.e. demoboard) be a video interface for other micro controllers to entice other developers to use the Propeller. I guess I wasn't too clear on my objectives. It has turned into something very interesting though.
It shows that the Propeller definitely has a niche and there definitely the talent on this forum to make this happen. Keep the discussion going! [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
Yeah, I was going to say, I think I jacked it from blittled!! (sorry about that, man! We tend to do that here. Once a few of us catch the fever, it just starts...) Don't fear the mob. Keep jumping right in. That's what we generally do. This topic is on some minds, and it all seemed to gel. That's a good thing.
Started first pass PAL work today on potatotext. That TV cog is the closest to the discussion we've had, and a build of it that does game related color is well on it's way anyway. IMHO, having live computations based off the clock will be handy, as there are "sweet" frequencies and not so sweet ones. I toyed with that some today, working through the nice comments Eric left, along with some others on various forum threads on the topic.
@Cluso: Thanks! Will do. Right now, I'm just building a simple bitmap to get the hang of things and do some timing tests to see whether or not the core TV cog code will need to be changed.
I'm plugging away in PAL right now. I first thought I would just drop the code into Eric's PAL template, debug and go. Turns out the timing and scan line differences are enough to trigger a rebuild of the original potatotext TV cog from the PAL source template. How they are built is somewhat different, largely because the signal is somewhat different.
So, I've been chipping away at that, leaving the rest of the code alone.
When it's done, I'm hoping to put both hunks of code into the same .cog file for binary loading of a NTSC / PAL base TV cog, as discussed above. The only other TV cog that operates like this is the Parallax one, done by Chip.
If there is room, that TV cog should do the following things:
NTSC / PAL
Compute timings during VBLANK, for live mode changes, and deal with different clocks. It won't autodetect pins. That will be an option for the parent program, if desired.
Simple bitmap display.
All current NTSC signal options.
Some PAL signal options.
Both interlaced or not.
Provide scan line buffer, 4 color and full color.
(probably do color cells, if requested, leaving a graphics cog to do pixels only, if desired)
I really should use CALL in the original COG to remove duplicate code, and refactor for less overall memory usage. Probably, I will do that, once the PAL one is done. It's gonna get written that way, which will be the model for the older NTSC TV cog.
So that's the goal on it. I'm hoping once that's done, people can write graphics cogs they want, with a template similar to the video ones Eric dropped here for us.
Right now, a lot of that is done on NTSC. On PAL, I'm just building up stage by stage to learn the differences. This stuff just takes a while for me.
Comments
This is an excellent design standard. One catch. We need to agree on the names.
sd_cs, kb, raudio, laudio, etc.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
IMHO, VBLANK, HBLANK, SCANCNT, VISIBLE are the core outputs needed. Right now, I use a simple write only for TV cog, read write graphics cog in potatotext. It works nicely, but probably isn't needed, if a scan count were just maintained in the TV cog. Good call. Probably created more work for myself the first time around, doing it the way I did.
Re: Pins. I like what's been posted. For stuff like video, and probably other things like sound, would it be fair to say those core elements don't need to be aware of that standard, because they will be setup and started by something that is? I'm asking for reasons of focus. It seems to me, having a stand alone binary build possible is language neutral. I really want to see that happen this time, so users of C, prop basic, etc... can use the product of this next effort, and so things can be fetched from SD card, or EEPROM, or something else (bluetooth??) as needed. It's time for that, because bigger things can be built now.
For those binary blob type things, I'm thinking there should only be a pointer to a sequential block of longs, and a document that details what those longs do. The parent project, whatever it is, would read the global parameters, stuff the longs, and fire off the driver, ideally overwriting where it started in the HUB to do something else. Sample configs can be commented in and out, written as a method, or loaded as binary data as well. I'll be using [noparse][[/noparse]name].cog for the loadable, executable file.
The only real assumptions are then, the system clock stored at the default location, PAR being used to tell the driver where it's block of communication lives, and that everything is long aligned. Organizing everything else happens one layer up. (buffers and such)
@Baggers, Cluso, et al.. Yeah, thanks! I'll need it. Time to build out the PAL for potatotext, before building anything else out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 3:00:26 PM GMT
I'll draft up a quick spin object for the demo board, and post it. Later, I will do one for PropCade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
- file removed, see newer version lower on this page
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 7/26/2010 5:43:03 PM GMT
Also, I thought the following names were used a little more often with the SD. (DI & DO)
(Same with ethernet.)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
In a lot of Hydra/Game code, there are the NES bit encodings present.· Something like the following:
Since joystick/gamepad code and pinouts would be different for each, maybe leaving them out of that would be a good idea.· Thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
- for objects where the pin order is guaranteed to have to be the same, I only supply starting pin (TV, VGA)
- KB/Mouse pins can be in any order, I wanted to preserve the flexibility, still a problem for Hyrda which uses 4 pins each
- unfortunately, the order of SPI pin's have not been standardized by everyone; heck due to confusion, I use different orders on some of my own boards!
- many boards have multiple SPI ports, so it is not enough to have a generic SPI set of pins
- SPI standards use MOSI and MISO so there is no possible confusion as to which is the input and output on slave or master
- while laying out this version, I kept ProtoBoard, DemoBoard, and all my boards in mind, as well as Hydra (except for 4 pin kb/mouse - that is very unique)
I am still trying to figure out a nice way of handling multiplexed SPI ports (several /CS, but only one set of CLK, MOSI, MISO)
Basically, *_pins.spin will work great for describing the standard interfaces (vga,tv,kb,mouse,audio,sd,eth) but cannot work for XMM - for that, I've made VMCOG - it also can't work for non-standard graphics such as PropGFX and Morpheus.
I am pretty happy with it being able to handle >90% of boards though [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
pin#js = 1 if there is a Joystick interface
pin#js_first = starting prop pin
pin#js_last = ending prop pin
This accommodates using 5 prop pins for an Atari stick, 3 for serial-input-parallel-output shift registers, or 4 for an MCP23S17
There are too many possible joysticks and interfaces, I think we need a "JS.SPIN" standard joystick interface object, which can use the above three fields to interface specific hardware, and give things like direction and buttons.
I will be working on such an API, and trying to keep it flexible enough to cover Hydra, PropCade, etc - however we may also need an ajs.spin object for analog joysticks, unless we decide to emulate analog on digital joysticks, and digital with analog sticks, in the same API
FYI, the PropCade joystick interface is implemented with six button Sega controllers in mind, however I am perfectly willing to adopt the NES encodings - except I will add more buttons on higher bits [noparse]:)[/noparse]
Maybe something like
js.read(n) ' reads digital joystick N
and bit masks that are exported constants from the js object:
js#up
js#right
js#left
js#down
js#select
js#start
js#a
js#b
js#c
js#d
js#x
js#y
js.readx(n) ' read X coordinate from analog joystick
js.ready(n) ' read Y coordinate from analog joystick
js.readz(n) ' read Z coordinate / thubmwheel from analog joystick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 7/26/2010 5:36:25 PM GMT
From the Sphinx thread ....
It was a good idea 2 years ago when first discussed, it's still a good idea, and I've used it several times. A small problem is how it gets included in a build for the user. With BST/BSTC it's easier because we get a library path, but one still needs to remove the file from a newly published package. With Propeller tool, the user's file has to be copied.
Bill you can copyright the names [noparse]:)[/noparse] You can't even trademark them in spin i.e. tx(tm) [noparse]:)[/noparse]
Some of the names are a little terse even for me.
ser - ? SerialPortEnable maybe?
rx,tx - is this for console only?
exp1 ?
Good thing constants don't consume memory [noparse]:)[/noparse] This coding convention has lots of growth potential.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
LOL... sorry, old time developer here, automatically put copyright notice on everything I write... if people are offended, I will remove it on this one, but I explicitly stated MIT [noparse]:)[/noparse]
Well, since the physical interface is serial, I used 'ser' - but will change to serial [noparse]:)[/noparse]
rx & tx are standard names, even on PropPlug, demo board etc...
I am uploading a new version into this message...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
It's still a good idea!
Here's the pin defs I uploaded to Wiki a couple years ago..
PinDefs.spin
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Some comments:
- suffix for VGA1,2 etc is almost never needed, maybe have no suffix for first interface, and add a digit if more than one exist? ie vga, vga2
- a little verbose for me, I like short names [noparse]:)[/noparse] as I grew up on Unix [noparse]:)[/noparse]
- I prefer SD to FSRW, sometimes I use Kye's great driver
- specific RTC belongs in an RTC object, many different ones in use (we do need a standard RTC object though, to abstract different RTC's)
- xbee, hydranet, ping gps etc only needed on boards that implement them
- instead of coding specifically to NES, we should have generic JS object - but we can keep bit encodings same if you like
The main differences between your wiki pins and mine can be summed up as:
- Bill likes short names, Jeff likes long names
- Bill prefers only implemented pins in a specific board's file, Jeff wants all possible boards all possible peripherals in one file
(I know, I showed unimplemented devices in my demoboard example, but that was for demonstration purposes (dolphins?))
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
BTW, OBC's pindefs.spin includes the clock configuration ... this is very important to have. Some people use strange _xinfreq values [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I was thinking of leaving the clock definition to the OS... however if it is here, we could even have the FREQA constants for NTSC/PAL pre-computed in CONSTANT() expressions...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
If you want to have your own definition of _xinfreq for example, including the pindefs.spin with that syntax gives it to you. Alternatively pindefs.spin can use "xinfreq = 5_000_000" for example instead of "_xinfreq = 5_000_000" and that will allow you to include the definition in a separate file without overwriting whatever an OS already provides when an OS compliant binary boots. One could argue however that applications shouldn't be touching pins directly, but instead rely on the drivers provided by the OS [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
P31/30: I always use SI and SO because TX & RX mean different things at each end and I have seen SI & SO in objects.
SD: I prefer the DO & DI (Out & In) which seems common in objects. All need specifying. For multiple /CS do the whole 4 pins again like SPI2_DO, etc. Not sure how the software will handle re-used pins - I have the same issue here, guess it will be the software MUST handle these things.
Audio: Can we use AudioL & AudioR rather that LAudio & RAudio?
Kbd & Mouse: Sometimes the data and clock are reversed - is that just a Hydra thing? Of course I have a 1pin keyboard object.
VGA & TV: I did spec the extra pins - next time I am short of pins I am thinking to use a 74LVC2G86 to save a VGA pin (HS & VS can share a pin). I already have 1pin TV which can also be great for debugging.
I will let you guys continue with the clkfreq idea.
I did mention that I would like this in a SD file, but hey we can use the same for both!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The NTSC IIRC can have 32 lines for PAL so 8x32=256 visible lines - see my 1pin TV object. There is also some extra timing info here that may be of help to you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
It shows that the Propeller definitely has a niche and there definitely the talent on this forum to make this happen. Keep the discussion going! [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
Post Edited (blittled) : 7/27/2010 2:12:08 AM GMT
Started first pass PAL work today on potatotext. That TV cog is the closest to the discussion we've had, and a build of it that does game related color is well on it's way anyway. IMHO, having live computations based off the clock will be handy, as there are "sweet" frequencies and not so sweet ones. I toyed with that some today, working through the nice comments Eric left, along with some others on various forum threads on the topic.
@Cluso: Thanks! Will do. Right now, I'm just building a simple bitmap to get the hang of things and do some timing tests to see whether or not the core TV cog code will need to be changed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/27/2010 2:56:11 AM GMT
I'm plugging away in PAL right now. I first thought I would just drop the code into Eric's PAL template, debug and go. Turns out the timing and scan line differences are enough to trigger a rebuild of the original potatotext TV cog from the PAL source template. How they are built is somewhat different, largely because the signal is somewhat different.
So, I've been chipping away at that, leaving the rest of the code alone.
When it's done, I'm hoping to put both hunks of code into the same .cog file for binary loading of a NTSC / PAL base TV cog, as discussed above. The only other TV cog that operates like this is the Parallax one, done by Chip.
If there is room, that TV cog should do the following things:
NTSC / PAL
Compute timings during VBLANK, for live mode changes, and deal with different clocks. It won't autodetect pins. That will be an option for the parent program, if desired.
Simple bitmap display.
All current NTSC signal options.
Some PAL signal options.
Both interlaced or not.
Provide scan line buffer, 4 color and full color.
(probably do color cells, if requested, leaving a graphics cog to do pixels only, if desired)
I really should use CALL in the original COG to remove duplicate code, and refactor for less overall memory usage. Probably, I will do that, once the PAL one is done. It's gonna get written that way, which will be the model for the older NTSC TV cog.
So that's the goal on it. I'm hoping once that's done, people can write graphics cogs they want, with a template similar to the video ones Eric dropped here for us.
Right now, a lot of that is done on NTSC. On PAL, I'm just building up stage by stage to learn the differences. This stuff just takes a while for me.