Standard newbie questions
cmd
Posts: 5
Trying to get my head wrapped around the Propeller, so please bear with me here, and pardon the silly or obvious questions:
- How is Hub RAM accessed in assembly language? An instruction liked RDBYTE has a 9-bit source and 9-bit destination field, but the Hub RAM is in the lower 32K of a 64K space so at least 16 bits are needed. Where do the extra address bits come from? Could I get an example of writing byte #$AA to Hub RAM offset $7E03 to see what such an operation looks like?
- Is it feasible to do audio playback by having a cog read data from SPI flash memory into a buffer in Cog RAM, and then output it to a SPI DAC at a reasonable sample rate like 22050 Hz?
- If the Propeller is connected to a FTDI FT232R chip can you continuously download and run new programs over USB? Say without having to manually cycle the power and do a cold boot every time.
- Do command-line driven tools such as a assembler exist? The GUI stuff is great, of course, just looking for more traditional tools.
- And the big question: Can you implement a standard VGA-type text mode using a single cog? The specifications are:
80x25 text using 8x16 characters, 1 blank pixel between characters (e.g. 9x16)
That's a 720x400 pixel display, 60 Hz (here, 720/9=80 if it isn't totally clear)
Character bitmaps stored in Hub RAM, so 256 characters x 16 bytes/char = 4096 bytes needed (Note: not using the built-in ROM fonts here)
Character matrix also in Hub RAM, 80x25 16-bit words (LSB is character number, MSB is two nibbles specifying IRGB values of a foreground and background color) so 4000 more bytes. Total Hub RAM needed is now 8096 bytes.
Output is 4-bit digital IRGB + H&V-sync for an old-school digital IRGB monitor (expecting VGA compatible timings); definitely not doing composite video or interlacing here.
Well now that's a little wordy, but I think people with a PC/DOS background will understand. Can the Propeller do this with a single cog? (or do this at all?)
Thanks for any advice. I'm excited about the Propeller and all these ideas are coming up at once.
- How is Hub RAM accessed in assembly language? An instruction liked RDBYTE has a 9-bit source and 9-bit destination field, but the Hub RAM is in the lower 32K of a 64K space so at least 16 bits are needed. Where do the extra address bits come from? Could I get an example of writing byte #$AA to Hub RAM offset $7E03 to see what such an operation looks like?
- Is it feasible to do audio playback by having a cog read data from SPI flash memory into a buffer in Cog RAM, and then output it to a SPI DAC at a reasonable sample rate like 22050 Hz?
- If the Propeller is connected to a FTDI FT232R chip can you continuously download and run new programs over USB? Say without having to manually cycle the power and do a cold boot every time.
- Do command-line driven tools such as a assembler exist? The GUI stuff is great, of course, just looking for more traditional tools.
- And the big question: Can you implement a standard VGA-type text mode using a single cog? The specifications are:
80x25 text using 8x16 characters, 1 blank pixel between characters (e.g. 9x16)
That's a 720x400 pixel display, 60 Hz (here, 720/9=80 if it isn't totally clear)
Character bitmaps stored in Hub RAM, so 256 characters x 16 bytes/char = 4096 bytes needed (Note: not using the built-in ROM fonts here)
Character matrix also in Hub RAM, 80x25 16-bit words (LSB is character number, MSB is two nibbles specifying IRGB values of a foreground and background color) so 4000 more bytes. Total Hub RAM needed is now 8096 bytes.
Output is 4-bit digital IRGB + H&V-sync for an old-school digital IRGB monitor (expecting VGA compatible timings); definitely not doing composite video or interlacing here.
Well now that's a little wordy, but I think people with a PC/DOS background will understand. Can the Propeller do this with a single cog? (or do this at all?)
Thanks for any advice. I'm excited about the Propeller and all these ideas are coming up at once.
Comments
The memory bandwidth of HUB-RAM to COG-RAM is 80_000_000 / 16 * ( 1 | 2 | 4 ) depending on which instruction you use wrbyte, wrword or wrlong (same for rdxxx). This is a max. of 20MB/sec. Doing extra things of course costs some bandwidth, but for audio there is a lot of headroom.
Download ... well ... the standard is, that the PropellerTool causes a reset on propeller-side and then is providing the new program. So, it is not the propeller which requests a program for download. If you want it that way, you have to code something on propeller side and on PC side.
For the standard way there are standalone tools available to upload programs to the propeller - if I remember right it's possible to call these via command line, so you can run a batch to periodically do updates for example.
If you only talk about the development: No, there is no reason for cold-boot. Just hit F10 or Ctrl + F10 and the PropellerTool uploads freshly.
There are drivers out which support a HUB-RAM font. Don't know which resolution, but my guess is that what you want should not be a problem. Maybe some little changes here or there. Was this driver written by Ariba? Have to search for it.