The first one is the same as before - flashing cursor, green background and no text
I tried simplifying the one that works with the second option and just changed the hires vga to low res VGA and that works fine.
So I think the problem is with linking to the hi res vga driver (or the driver itself).
The program doesn't test the keyboard as such, but the keyboard lights are blinking on restart, so I think the keyboard is working ok too.
I've taken a working Dracblade and popped out the propeller chip and I can send you the board. (It boots to CP/M, you might like to try programming in BDS C?!) Can you please PM me your address?
But more to the point, once the display is working we can look at using the 512k of ram.
Down the bottom of this thread I've posted the ram driver code. It uses the same instructions as cluso's driver, but the PASM is completely different. But very easy to use:
OBJ
RamLatches : "Dracblade" ' to talk to the ram chip
then at the beginning
r := RamLatches.start 'start the dracblade driver
then set the high latch A16-A23 (512k uses A16 to A18, the other pins are spare)
HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23
RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' set high latch byte A16-A18, plus led plus the 4 spare outputs
then to write some bytes to a location in ram
r := RamLatches.DoCmd("W", @buff, $FF00, 256) 'write 256 bytes from buff[noparse][[/noparse]] to sram location $FF00
and to read some bytes from ram
r := RamLatches.DoCmd("R", @buff, $80, 128) ' read 128 bytes from location 80H in ram to the buff array
I hope there is a cunning way that could be useful for storing data in C
''Dracblade driver for talking to a ram chip via three latches
'' Modified code from Cluso's triblade
' DoCmd(command_, hub_address, ram_address, block_length)
' R - read bytes at address n up (n to n+block_length) where n =0 to 65535 (ie lower 64k of the sram chip)
' W - write bytes at address n up
' I - initialise
' N - Led on
' F - Led off
' H - set high latch to value in ramaddress A16 to A23 (will include the led)
VAR
' communication params(5) between cog driver code - only "command" and "errx" are modified by the driver
long command, hubaddrs, ramaddrs, blocklen, errx, cog ' rendezvous between spin and assembly (can be used cog to cog)
' command = R, W, N, F H =0 when operation completed by cog
' hubaddrs = hub address for data buffer
' ramaddrs = ram address for data ($0000 to $FFFF)
' blocklen = ram buffer length for data transfer
' errx = returns =0 (false=good), else <>0 (true & error code)
' cog = cog no of driver (set by spin start routine)
PUB start : err_
' Initialise the Drac Ram driver. No actual changes to ram as the read/write routines handle this
command := "I"
cog := 1 + cognew(@tbp2_start, @command)
if cog == 0
err_ := $FF ' error = no cog
else
repeat while command ' driver cog sets =0 when done
err_ := errx ' driver cog sets =0 if no error, else xx = error code
PUB stop
if cog
cogstop(cog~ - 1)
PUB DoCmd(command_, hub_address, ram_address, block_length) : err_
' Do the command: R, W, N, F, H
hubaddrs := hub_address ' hub address start
ramaddrs := ram_address ' ram address start
blocklen := block_length ' block length
command := command_ ' must be last !!
' Wait for command to complete and get status
repeat while command ' driver cog sets =0 when done
err_ := errx ' driver cog sets =0 if no error, else xx = error code
DAT
'' +--------------------------------------------------------------------------+
'' | Dracblade Ram Driver (with grateful acknowlegements to Cluso) |
'' +--------------------------------------------------------------------------+
org 0
tbp2_start ' setup the pointers to the hub command interface (saves execution time later
' +-- These instructions are overwritten as variables after start
comptr mov comptr, par ' -| hub pointer to command
hubptr mov hubptr, par ' | hub pointer to hub address
ramptr add hubptr, #4 ' | hub pointer to ram address
lenptr mov ramptr, par ' | hub pointer to length
errptr add ramptr, #8 ' | hub pointer to error status
cmd mov lenptr, par ' | command I/R/W/G/P/Q
hubaddr add lenptr, #12 ' | hub address
ramaddr mov errptr, par ' | ram address
len add errptr, #16 ' | length
err nop ' -+ error status returned (=0=false=good)
' Initialise hardware (unlike the triblade, just tristates everything and read/write set the pins)
init mov err, #0 ' reset err=false=good
mov dira,zero ' tristate the pins
done wrlong err, errptr ' status =0=false=good, else error x
wrlong zero, comptr ' command =0 (done)
' wait for a command (pause short time to reduce power)
pause mov ctr, delay wz ' if =0 no pause
if_nz add ctr, cnt
if_nz waitcnt ctr, #0 ' wait for a short time (reduces power)
rdlong cmd, comptr wz ' command ?
if_z jmp #pause ' not yet
' decode command
cmp cmd, #"R" wz ' R = read block
if_z jmp #rdblock
cmp cmd, #"W" wz ' W = write block
if_z jmp #wrblock
cmp cmd, #"N" wz ' N= led on
if_z jmp #led_turn_on
cmp cmd, #"F" wz ' F = led off
if_z jmp #led_turn_off
cmp cmd, #"H" wz ' H sets the high latch
if_z jmp #sethighlatch
mov err, cmd ' error = cmd (unknown command)
jmp #done
tristate mov dira,zero ' all inputs to zero
jmp #done
' turn led on
led_turn_on or HighLatch,ledpin ' set the led pin high
jmp #OutputHighLatch ' send this out
led_turn_off andn HighLatch,ledpin ' set the led pin low
jmp #OutputHighLatch ' send this out
' set high address bytes with command H, pass value in third variable of the DoCmd
' 4 bytes - masks off all but bits 16 to 23
sethighlatch call #ram_open ' gets address value in 'address'
shr address,#16 ' shift right by 16 places
and address,#$FF ' ensure rest of bits zero
mov HighLatch,address ' put value into HighLatch
jmp #OutputHighLatch ' and output it
'---------------------------------------------------------------------------------------------------------
'Memory Access Functions
rdblock call #ram_open ' get variables from hub variables
rdloop call #read_memory_byte ' read byte from address into data_8
wrbyte data_8,hubaddr ' write data_8 to hubaddr ie copy byte to hub
add hubaddr,#1 ' add 1 to hub address
add address,#1 ' add 1 to ram address
djnz len,#rdloop ' loop until done
jmp #init ' reinitialise
wrblock call #ram_open
wrloop rdbyte data_8, hubaddr ' copy byte from hub
call #write_memory_byte ' write byte from data_8 to address
add hubaddr,#1 ' add 1 to hub address
add address,#1 ' add 1 to ram address
djnz len,#wrloop ' loop until done
jmp #init ' reinitialise
ram_open rdlong hubaddr, hubptr ' get hub address
rdlong ramaddr, ramptr ' get ram address
rdlong len, lenptr ' get length
mov err, #5 ' err=5
mov address,ramaddr ' cluso's variable 'ramaddr' to dracblade variable 'address'
ram_open_ret ret
read_memory_byte call #RamAddress ' sets up the latches with the correct ram address
mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read
mov outa,GateHigh ' actually ReadEnable but they are the same
andn outa,GateHigh ' set gate low
nop ' short delay to stabilise
nop
mov data_8, ina ' read SRAM
and data_8, #$FF ' extract 8 bits
or outa,GateHigh ' set the gate high again
read_memory_byte_ret ret
write_memory_byte call #RamAddress ' sets up the latches with the correct ram address
mov outx,data_8 ' get the byte to output
and outx, #$FF ' ensure upper bytes=0
or outx,WriteEnable ' or with correct 138 address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
nop ' no nop doesn't work, one does, so put in two to be sure
nop ' another NOP
or outa,GateHigh ' set it high again
write_memory_byte_ret ret
RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram
mov dira,LatchDirection ' set up the pins for programming latch chips
mov outx,address ' get the address into a temp variable
and outx,#$FF ' mask the low byte
or outx,LowAddress ' or with 138 low address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
' ?? a NOP
or outa,GateHigh ' set it high again
' now repeat for the middle byte
mov outx,address ' get the address into a temp variable
shr outx,#8 ' shift right by 8 places
and outx,#$FF ' mask the low byte
or outx,MiddleAddress ' or with 138 middle address
mov outa,outx ' send it out
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
RamAddress_ret ret
OutputHighLatch ' sends out HighLatch to the 374 that does A16-19, led and the 4 spare outputs
mov dira,latchdirection ' setup active pins 138 and bus
mov outa,HighLatch ' send out HighLatch
or outa,HighAddress ' or with the high address
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set the gate high again
OutputHighLatch_ret jmp #tristate ' set pins tristate
delay long 80 ' waitcnt delay to reduce power (#80 = 1uS approx)
ctr long 0 ' used to pause execution (lower power use) & byte counter
GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low
Outx long 0 ' for temp use, same as n in the spin code
LatchDirection long %00000000_00000000_00001111_11111111 ' 138 active, gate active and 8 data lines active
LatchDirection2 long %00000000_00000000_00001111_00000000 ' for reads so data lines are tristate till the read
LowAddress long %00000000_00000000_00000101_00000000 ' low address latch = xxxx010x and gate high xxxxxxx1
MiddleAddress long %00000000_00000000_00000111_00000000 ' middle address latch = xxxx011x and gate high xxxxxxx1
HighAddress long %00000000_00000000_00001001_00000000 ' high address latch = xxxx100x and gate high xxxxxxx1
'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxxx000x and gate high xxxxxxx1
' commented out as the same as GateHigh
WriteEnable long %00000000_00000000_00000011_00000000 ' /WE = xxxx001x and gate high xxxxxxx1
Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins
data_8 long %00000000_00000000_00000000_00000000 ' so code compatability with zicog driver
address long %00000000_00000000_00000000_00000000 ' address for ram chip
ledpin long %00000000_00000000_00000000_00001000 ' to turn on led
HighLatch long %00000000_00000000_00000000_00000000 ' static value for the 374 latch that does the led, hA16-A19 and the other 4 outputs
I suggest you download and have a look at the DracBlade support package - it contains all the files that might need to be changed, and if you search for 'DRACBLADE' you will see every change I had to make for that board (including XMM changes, even though the XMM code itself hasn't been written yet). You can model your RamBlade changes on that. Mostly it's changing the pin configurations and the choice of drivers to use in various circumstances (e.g. on the RamBlade you will probably want to default to the PC drivers for display and keyboard).
I won't get time to do this myself till at least next week, but if you can wait that long I'll include both RamBlade and DracBlade support in a Catalina patch release (at least LMM support - for XMM support I'll either need a RamBlade board, or rely on Cluso or yourself to write the XMM code).
I have finally managed to fix the Catalina program loader and want to get that out this week - then I have a backlog of work to do to support Bob Anderson's new C source level debugger (woohoo!).
The next program you might want to try is probably 'test_suite.c' - this is a trivial program that test a few simple C features (and also uses the keyboard).
So now the edit/download/re-edit/download cycle is down to only 5 seconds. That makes development fun!
I wonder if you might be interested in adding in the LCD code? No hurry as I know other things are higher priority, but this is one of the nifty things about the dracblade - you don't need a VGA or TV if you don't want to. For small projects you can do a lot with a 20x4LCD (or even smaller ones), especially if you keep the questions and answers short
enter your name:
enter your age:
etc
With CP/M the output goes to vga, to LCD and to the serial port and hence a terminal program, so you can use all three if you want.
PUB PrintChar(c) ' sends c to the uart, LCD display and the vga display
UART.tx(0,c) ' send to the PC
LCD.out(c) ' send to LCD display
vgatext.txVT100(c) ' send to vt100 terminal
The LCD driver is pretty straightforward. But I'm not sure how catalina includes things like optional code. Is it with #ifdefs like the zicog does?
'' parallel 20x4 lcd driver for the DracBlade including a 'Terminal' that scrolls properly, backspace etc
CON
_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000
LatchDirection =%00000000_00000000_00001111_11111111 ' 138 active, gate active and 8 data lines active
MaskLowByte = %00000000_00000000_00000000_11111111 ' used in lots of routines to & mask off low byte
LCDLatch = %00000000_00000000_00001011_00000000 ' LCD latch is xxxx101x and gate high xxxxxxx1
EnableBit = %00000000_00000000_00000000_00000010 ' Enable pin 6 on LCD displays
OBJ
delay : "timing"
VAR
long Char ' Character To Send To LCD
long Inst ' Instuction To Send To LCD
long Column ' column counter for line 4 ' don't use byte, causes all sorts of overrun errors
long LineNumber ' line number 1,2,3,4
long LCDChar ' character to send to LCD 0-$FF
long LCDByte ' byte to latch out to LCD display
byte Display[noparse][[/noparse]79] ' buffer for display 20x4 ' put this last as bizarre overwriting going on
PUB Start | n
Init_Lcd
Column:=0 ' start at zero
repeat n from 0 to 79 ' fill the display memory with spaces
Display[noparse][[/noparse]n]:=" " 'fill with spaces
Redraw
{
repeat 25 ' test code for running standalone
out(65)
out(10)
out(66)
out(13)
}
PUB str(stringptr)
'' Print a zero-terminated string
repeat strsize(stringptr)
out(byte[noparse][[/noparse]stringptr++])
PUB dec(value) | i '' Print a decimal number
if value < 0
-value
out("-")
i := 1_000_000_000
repeat 10
if value => i
out(value / i + "0")
value //= i
result~~
elseif result or i == 1
out("0")
i /= 10
PUB hex(value, digits) '' Print a hexadecimal number
value <<= (8 - digits) << 2
repeat digits
out(lookupz((value <-= 4) & $F : "0".."9", "A".."F"))
PUB bin(value, digits)
'' Print a binary number
value <<= 32 - digits
repeat digits
out((value <-= 1) & 1 + "0")
PUB out(c) | i,j
' Output a character, ignores most <32 and all >126
' possibly add a 'turn on display' and 'turn off display' with selected ascii characters ?? esc seq
i:=c ' need a local working variable as an if statement seems to corrupt subsequent working variables!
j:=Column ' and need a local version of column otherwise corrupts this too
if c==10 ' Linefeed
Newline
Column:=0 ' reset column counter
j:=21 ' ensures code below doesn't run
if j<20 ' this LCD driver code is slow so better to not print anything after line 20 and wait for CRLF
' if j > 19 ' is it off the end of the display? (old display wrapped around)
' Column:=0 ' reset to beginning
' Newline
if c==08 ' Backspace
Backspace
' if c==13 ' do nothing as LF includes CR as part of the code
if i >= 31 ' and statements don't work in if lines?!
if i<=126 ' send the ascii character
char := c ' get the character
Send_Text ' send it out
Display[noparse][[/noparse]Column+60]:=c ' store the character in the last column
Column:=Column+1 ' add 1 to column
if j==19
CursorOff
PUB CursorOn
Inst:=13 ' turn on the cursor
Send_Inst
PUB CursorOff
Inst:=12 ' cursor off
Send_Inst ' send the instruction
PRI Init_Lcd
LCDLow ' set the 6 LCD lines low
delay.pause1ms(200) ' short delay for LCD bootup 200ms
LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx
PulsOut
LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx
PulsOut
LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx
PulsOut
LCDByte:=%00001000 ' send out 0010 already shifted to xxnnnnxx
PulsOut
LCDByte:=%00001000 ' send out 0010 already shifted to xxnnnnxx
PulsOut
LCDByte:=%00100000 ' send out 1000 already shifted to xxnnnnxx
PulsOut
Inst:=14 ' cursor on
Send_Inst
Inst:=1 ' cls
Send_Inst
Inst:=13 ' flashing cursor
Send_Inst
Inst:=128 ' to position 1
Send_Inst
pri Send_Inst ' send instruction in Inst
RSLow ' not actually needed see below but makes code more logical
LCDByte:=Inst ' get high nibble
LCDByte:=LCDByte>>2 ' shift right two bits so xxnnnn00
LCDByte:=LCDByte & %00111100 ' mask the nibble and sets RS low as well (bit0)
Pulsout ' send it out
LCDByte:=Inst ' get low nibble
LCDByte:=LCDByte<<2 ' shift left two bits so xxnnnn00
LCDByte:=LCDByte & %00111100 ' mask the nibble and sets RS low as well (bit0)
Pulsout ' send it out
RSHigh ' back to text mode
pri Send_Text ' pass Char = a byte
'RS always high = bit 0, bits are xxnnnnER where nnnn is the nibble, E=enable and R=RS
LCDByte:=Char
LCDByte:=LCDByte>>2 ' shift right two bits so xxnnnn00
LCDByte:=LCDByte & %00111100 ' mask off just the nibble
LCDByte:=LCDByte | %00000001 ' keep RS high
Pulsout ' send it out
LCDByte:=Char ' get low nibble
LCDByte:=LCDByte<<2 ' shift left two bits so xxnnnn00
LCDByte:=LCDByte | %00000001 ' keep RS high
Pulsout
pub Next_Line
Inst := %11000000 ' Move Cursor To Line 2
Send_Inst
PRI ToggleGate
OUTA[noparse][[/noparse]8]:=0 ' set gate pin low
OUTA[noparse][[/noparse]8]:=1 ' and high again - may need a delay in PASM
PRI EnableLatchPins
DIRA:=LatchDirection ' 138 active, gate active and 8 data lines active
PRI Tristate ' tristate all pins
DIRA:=%00000000_00000000_00000000_00000000
PUB LCDOutput | n ' sends byte LCDByte to latch
EnableLatchPins ' turn on the pins needed to talk to the latches
n:=LCDByte ' byte value to send out
n:=(n & MaskLowByte) ' 2 AND mask the low byte
n:=(n | LCDLatch ) ' 3 OR with the LCD address 138
OUTA:=n ' 4 send it out
ToggleGate ' 5 and latch it
tristate ' back to tristate on all pins
PUB LCDLow ' sets all LCD pins low for startup
LCDByte:=0
LCDOutput
PUB PulsOut ' pulse the enable pin 6 high then low - uses LCDByte and returns it unchanged
LCDByte:=(LCDByte | %00000010) ' logical OR to set just this bit high
LCDOutput ' send it out
' delay.pause1ms(1) ' short pause not needed as spin very fast
LCDByte:=(LCDByte & %11111101) ' logical AND set just this bit low
LCDOutput ' send it out
' delay.pause1ms(1) ' delay for LCD to process it
PUB RSHigh ' set RS pin 4 high - uses LCDByte and returns it unchanged
LCDByte:=(LCDByte | %00000001) ' logical OR to set just this bit high
LCDOutput
PUB RSLow ' set RS pin 4 low - uses LCDByte and returns it unchanged
LCDByte:=(LCDByte & %11111110) ' logical AND set just this bit low
LCDOutput
PUB Backspace | i,j
' backspace is a special case - need to subtract 1 off the column, make the last character a space
' and redraw the screen and print out column number of characters on last line
' only really works on line 4 but most of the time the display is on line 4 anyway
j:=Column ' the last character added 1 to column so start with one less
if j>1 ' not reliable at 1
Display[noparse][[/noparse]Column+60-1]:=32 ' was one past the character
Column:=Column-1 ' subtract 1
Redraw
repeat i from 0 to j-2
Char:=Display[noparse][[/noparse]60+i] ' print out the last row with one less character
Send_Text
PUB Redraw ' redraw the entire screen
Inst:=128 ' line 1
Send_Inst
LineNumber:=1 ' print line 1
Printline
Inst:=192 ' line 2
Send_Inst
LineNumber:=2 ' print line 2
Printline
Inst:=148 ' line 3
Send_Inst
LineNumber:=3 ' print line 3
Printline
Inst:=212 ' line 4
Send_Inst
LineNumber:=4 ' print line 4
Printline
Inst:=212 ' cursor to beginning of line 4
Send_Inst
CursorOn
PUB PrintLine | n ' Prints the line in LineNumber 1 to 4
n:=(LineNumber-1)*20 ' convert to pointer for the array 0-79
repeat 20 ' do this 20 times
Char:=Display[noparse][[/noparse]n] ' get the character from the array
Send_Text ' send it out
n:=n+1 ' increment counter
PUB Newline | i ' move the lines all up one, clear line 4, move cursor to position 1 of line 4
repeat i from 0 to 59 ' move up to next line
Display[i]:=Display[noparse][[/noparse]i+20]
repeat i from 60 to 79
Display[i]:=32 ' space
Column:=0 ' column counter to zero
Redraw ' redraw the screen
[/i][/i]
Glad you got it working. I'll figure out what's going wrong with the hires VGA driver when I get some time.
The LCD code would make a very useful debugging aide - no promises, but I'll see what I can do. The simplest way to add support for it in Catalina would be to just add it as another alternative HMI option (e.g. if you compile a program with '-D LCD' standard output (stdout) would become the LCD). The problem with this is that you couldn't use both VGA and LCD at the same time.
A more complex (but more useful) solution would be to make the VGA display the C standard output (stdout) but have the LCD display the C standard error output (stderr) - this would fit in very well with using it as a debugging aide. However, this would require a custom DracBlade VGA driver, as currently both stdout and stderr go to the VGA display (but using separately addressable cursors so you can put them at different places on the screen).
Just released a small patch to fix a bug in the Catalina Generic SD/SIO Program Loader. The patch is attached to the first post in this thread. Here are the details:
Patch Release 22 Jan 10
================
This release contains a small patch to fix a bug in the Catalina Generic SD and SIO Loaders which could lead to programs failing to initialize correctly - typical symptoms were that the screen was cleared, but the C program was never started (especially when using the HiRes TV driver). It appears that clearing unused hub RAM to zero is required whenever a new program is loaded, or the SPIN interpreter may not start correctly.
Just apply this patch over Release 2.3 and run 'rebuild_all' in the utilities directory to rebuild the loader binaries - no need to rebuild Catalina.
I just noticed a difference between your version of the HiRes VGA text driver (VGA_HiRes_Text.spin) and my version modified for Catalina (Catalina_VGA_HiRes_Text.spin).
I had assumed my version was based on Chip's original, but I found a difference I can't account for:
My version:
movi frqa,#(pr<<2 / 5) 'set pixel rate
Your version (and also the version in the OBEX):
movi frqa,#(pr / 5) << 2 'set pixel rate
When I use your version it no longer works on my Hydra. I don't remember making this change, so I think the Hydra must have come with a customized version and I didn't realize it.
I have enclosed a new version (modified for Catalina) based on the OBEX original. Can you try it out for me? Please copy the enclosed file to the Catalina target directory and recompile 'hello_world.c' using the following command:
catalina -D DRACBLADE hello_world.c -lc
Thanks,
Ross.
Edit: attachment removed. DracBlade support is now part of the main Catalina release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just released a small patch to Catalina - it is attached (as usual) to the first post in this thread. Here are the details:
Patch Release 28 Jan 10
================
This release is a small patch to fix a bug in the Catalina HiRes VGA Driver when used with the NO_MOUSE option, or on a platform without a mouse (such as the DracBlade). It also adds support for the DracBlade (there are no XMM drivers for the DracBlade yet, but LMM and EMM programs will now work correctly).
Just unzip the patch in the zipfile attached to this post over a Catalina Release 2.3 installation and rebuild any affected C programs - no need to rebuild Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just updated the Patch Release 28 Jan 10 - the original zip file had the wrong folder names, and unzipping it over your exisitng Catalina installation would have simply created a 'Catalina_Patch_28_Jan_10" folder - you can either download the zip file again, or manually copy everything out of that folder up one level (i.e. into the main Catalina directory).
Sorry about that!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Woot! Got Othello working on the Dracblade. And other little programs as well. (@Rossh, no damage done by the patches, all was fixed with a Windows reboot rather than my usual hibernate/unhibernate. Windows needs a real reboot now and then).
Minor problem - still bright green on dark green background.
Ok, can you explain how to write a C program for a CP/M old timer like me?
In CP/M the screen is whatever physical color it happens to be. Green on black, white on blue, etc. But you can change it if you want. Either with a call to some I/O ports, or with some VT100 codes. Those calls are usually the first thing in a program, right before the CLS clear screen and they are then followed by the text.
But a Catalina program seems to leap straight into printing out text:
/*
Beginning C, Third Edition
By Ivor Horton
ISBN: 1-59059-253-0
Published: Apr 2004
Publisher: apress
*/
#include <stdio.h>
#include <catalina_hmi.h>
#include <ctype.h>
#define SIZE 8 /* Board size - must be even */
/* Function prototypes */
void display(char board[noparse][[/noparse]][noparse][[/noparse]SIZE]);
int valid_moves(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player);
void make_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int row, int col, char player);
void computer_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player);
int best_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player);
int get_score(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], char player);
void main()
{
char board [noparse][[/noparse]SIZE][noparse][[/noparse]SIZE] = { 0 }; /* The board */
int moves[noparse][[/noparse]SIZE][noparse][[/noparse]SIZE] = { 0 }; /* Valid moves */
int row = 0; /* Board row index */
int col = 0; /* Board column index */
int no_of_games = 0; /* Number of games */
int no_of_moves = 0; /* Count of moves */
int invalid_moves = 0; /* Invalid move count */
int comp_score = 0; /* Computer score */
int user_score = 0; /* Player score */
char y = 0; /* Column letter */
int x = 0; /* Row number */
char again = 0; /* Replay choice input */
int player = 0; /* Player indicator */
t_string(1,"\nREVERSI\n\n");
t_string(1,"You can go first on the first game, then we will take turns.\n");
t_string(1," You will be white - (O)\n I will be black - (@).\n");
There probably is a way of defining screen colors within the program itself - for the dracblade it would be some OUT commands or VT100 escape commands.
But I think Catalina defines it somewhere else. Looking at the vga driver code, I think the variables are passed via this line
Great news! I thought for a horrible moment Catalina had destroyed your PC!
The bright green characters on a dark green background is my default color scheme for HiRes VGA. It is set up in the HMI plugin (in this case Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_Input.spin - on or about line 365).
You can also change colours from within the C program by using low level Catalina HMI functions. I have enclosed an example. Compile it with
catalina -D DRACBLADE -lc hello_colour.c
You could add the set_screen_color function in this program to other programs. such as the the othello.c program (and call it at the beginning of the main routine). Note that this function is specific to the HiResVGA driver - the LoResVGA uses different colors and you have to set the value of each character cell individually. One day I will write some simple "wrapper" functions that make this easier to do - so much to do, so little time!
And DRACBLADE is just a symbol used in various #define statements spread throughout the target directory files - it just causes the DracBlade specific sections of code to be included during the compilation process.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
#ifdef PROXY_SCREEN
#else
' set up colors
repeat i from 0 to rows - 1
' word[noparse][[/noparse]pscreen][noparse][[/noparse]colors + i] := %%0100_1310 ' pale green on dark green
word[noparse][[/noparse]pscreen][noparse][[/noparse]colors + i] := %00001000_11111100 ' white on blue
However, it hasn't changed anything.
1) is %% octal or something - and hence is my binary code correct?
2) Reading the ifdef, I think the above is only called if PROXY_SCREEN is false? What is proxy_screen, and if I'm not adding it to the command line, maybe it is false, and hence is the color definition coming from anywhere else in the code?
Alright, I'm going crazy here. I saved that change and then went to find the file I had edited. Because the names are all so similar for those drivers, I went and resorted the directory based on when the files were last modified. A huge number had been edited at the same time - which was the time I did the last .c program compile. I figured - this is odd, only writing a windows file changes the edit time, not a read and a compiler should just be reading. So I went back to check my changes and they had gone.
So to really test this out I edited out the lines above using the propeller tool and recompiled a .c program. The lines are back again!
Are the spin source files self modifying or something? How do you make changes to them, or are you not supposed to?
BUT ... maybe it doesn't matter, because hello_colour.c works fine, and so it would be much easier just to add these lines of code at the beginning of a program. See photo.
Your change looks fine - I just tried it here and it works. But you are not editing the correct file (yes, they are self-modifying!). You have to edit Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_Input.spin in the directory C:\Program Files\Catalina\target\input\. Make sure it has the _Input in the filename - you are probably editing the version in the target directory instead - and the compiler rebuilds this version on every compile from the input files. I realize this is a bit obscure - but it is documented in various places, including at the top of the file itself.
The %% in SPIN means 'Quaternary' - each digit is 0..3, representing 2 bits. See the Prop manual for more details.
PROXY_SCREEN is only relevant for multi-CPU Prop systems - it allows a program running on one CPU to use a display connected to another CPU. It's used on the TriBladeProp or Morpheus, but is not relevant for the DracBlade.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thanks for the clarification - now it makes a lot more sense.
The little colour.c program is about as simple as it gets - very easy to understand and use.
At the beginning of this thread is mention of code::blocks. Is this an IDE for catalina? I got a bit confused about the IDE option - is it possible to write and compile a C program from within one IDE type environment (similar to the prop tool)?
Yes, Code::Blocks is a really cool compiler-independent graphical development environment. It's a little like the Parallax Propeller tool, but actually more similar in look and feel to Visual Studio, or to the Embedded Workbench (which many AVR users will be familiar with).
It provides a front-end to the Catalina command line compiler - and for most programs you will never need to open a DOS window at all. Once you set up a Code::Blocks project with the appropriate configuration, it's one-click to recompile.
Currrently you can create, edit and compile C programs with Code::Blocks. Soon you will also be able to download and debug them. The built-in editor is C syntax-aware and context-sensitive. It also has a built in 'make' function for maintaining programs that consist of multiple C source files.
In the current release, setting up Code::Blocks is a little tricky - you have to donwload Codde::Blocks, install it, run it once, and then edit its configuration files it creates to make it 'Catalina-aware'. This is all documented in the README.codeblocks file in the codeblocks subdirectory. In future I'll try and streamline the install process.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ok, got codeblocks. Reading through the install notes and configuring it at the moment. It looks very interesting. Nice to be working in an environment with colour highlighting of keywords etc. This will make it easier to spot syntax errors etc.
I've just been reading through memory models en.wikipedia.org/wiki/C_memory_model
The paging system of the IBM with its overlapping offsets is going to be a bit different, but paging ought to fit nicely with a 512k model. I think this is a far pointer ie up to 1 megabyte.
Memory models are the one thing that C has that is simply not present in Basic (as far as I know). Versions of Basic were stuck with the memory of the machine they were designed for, but C seems to have worked out a model in the mid 1980s that meant it was much more machine independent.
The page you refer to is fairly specific to machines with 16 bit architectures (such as the x86). Catalina implements it's own memory models, tailored to the Prop's true 32 bit architecture (but peculiar memory arrangement).
All the Catalina memory models use "flat" 32 bit addresses (i.e. no segmentation). Even if the XMM hardware implements physical memory using multiple pages (for speed, or to save pins), this is hidden from the C program by the XMM access routines (such routines have not yet been written for the DracBlade, but the same will be true for those as well).
The Catalina memory models currently implemented are:
Tiny. In this mode, all addresses are Hub RAM addresses – this means that all code, data, stack and heap must fit into the 32k (Prop I) or 256k (Prop II) Hub RAM. This is the mode implemented by the LMM Kernel for all programs compiled using the –x0 or –x1 command line options. It can be used on any Propeller.
Small. In this mode, all data addresses are Hub RAM addresses, but all code addresses are XMM RAM addresses. Currently, I only use 24 bits as XMM address since I can't imagine anyone needing more than 16Mb on a single Prop (famous last words!). All data, stack and heap must fit into the 32k (Prop I) or 256k (Prop II) Hub RAM, but code size can be up to 16Mb. This mode is implemented by the XMM Kernel, for programs compiled using the –x2 command line option. Of course, this mode requires external XMM RAM.
Large. In this mode, global data and code addresses are XMM addresses, and so the total code and global data (including heap) size can be up to 16Mb. The 32k (Prop I) or 256k (Prop II) of Hub RAM is used for the stack and for local data. This mode is also implemented by the XMM Kernel, for programs compiled using the –x5 command line option. Of course, this mode also requires external XMM RAM.
More detail can be found in the Catalina Reference Manual (pp 66).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A couple of intriguing posts by RossH in two other threads. First - in the Dracblade thread regarding LMM working up to 512k with a promise of some code coming soon. And second,a post in a discussion about LMM by Bean with some code to do virtual Call. This I find interesting, because while I don't fully understand what a LMM actually is, what I do understand is the code to do a virtual call, because this (to me) suggests that this isn't just using the larger ram for storing data arrays, but rather it is using the larger ram to actually store program code.
So - a question for Ross - is it now possible to use Catalina to write BIG programs in C?
Currently Catalina supports as much as the XMM target can give... so you could use the 512KB on your board for code and data!
One of the Blade's on TriBlade can support 1MB
Morpheus supports 16MB, 2.5MB has been tested
Dr_Acula said...
A couple of intriguing posts by RossH in two other threads. First - in the Dracblade thread regarding LMM working up to 512k with a promise of some code coming soon. And second,a post in a discussion about LMM by Bean with some code to do virtual Call. This I find interesting, because while I don't fully understand what a LMM actually is, what I do understand is the code to do a virtual call, because this (to me) suggests that this isn't just using the larger ram for storing data arrays, but rather it is using the larger ram to actually store program code.
So - a question for Ross - is it now possible to use Catalina to write BIG programs in C?
Yes, as Bill mentions above, instead of a measly 496 instructions, LMM allows a PASM program to be up to 8198 instructions, or use up to 32Kb of data (up to the maximum 32Kb of Hub RAM), and XMM allows PASM programs to be up to 4,194,304 instructions, or use up to 16Mb of data (up to the maximum size of the physical XMM RAM installed).
There are a few restrictions on which PASM instructions you can use - but Catalina takes care of all that for you.
LMM will work on ANY Propeller - it's like having a Prop with a cog size of up to 8192 longs instead of 496 longs (but running a bit slower).
XMM will work on the Hydra, Hybrid, TriBladeProp, or Morpheus - and now on the DracBlade. It's like having a Prop with a cog size of 4 million longs (but running slower still).
I'll post the new DracBlade target support package tonight.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just released a small patch to add XMM support for the DracBlade. The DracBlade is now fully integrated into the standard Catalina target support package.
See the first post in this thread for more details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
And the practical upshot of that is you can take a C program that compiles to a 350k binary and run it on a Propeller. Of course, Ross has done a lot of work behind the scenes to make that happen, but it all works perfectly. See the Dracblade thread posts from today.
This really does open up some possibilities for coding huge programs.
hey people
ive gone over this posting 3 times and still cant find where to download the catalina compiler?
the 3 patches, no problem, but not the base program?
any ideas how my fading light keeps missing this?
thanks, norm
"hey people
ive gone over this posting 3 times and still cant find where to download the catalina compiler?
the 3 patches, no problem, but not the base program?
any ideas how my fading light keeps missing this?
thanks, norm"
Um...yeah. Every link to calalina sends me back to the top of this thread. I'm not an idiot, but I'm not Sherlock Holmes either.
They are in the second to sixth posts in the thread (depending on your platform - there are linux and windows versions, source and binary releases).
In all cases you should download the documents, utilities and demos zips, and then the binary release zips for your platform. The source release zips are optional. After installing the base releases (source and/or binary) then apply the patch releases.
Holler if you have problems.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I DID figure it out. It took all morning, but I did (two hours spent looking for codeblocks in my settings file - who knew it would be hidden?). I even compiled "hello.c". It takes up 23kb???!!! I think I have to read the manual.
Glad you got it sorted. Let me know of anything you had particular trouble with and I'll try and make it clearer in the documentation for the next release. I don't get the bit about Code::Blocks settings being hidden - can you explain?
The "Hello, world" program compiles to 23k only if you include floating point support in the stdio routines (i.e. compile with -lc). If you compile with the integer-only stdio routines (-lci) it compiles to 15k. If you use the Catalina alternate I/O routines (see hello_world_1.c) it compiles to 8k. If you then also omit the (unused) keyboard and mouse drivers (using -D NO_KEYBOARD -D NO_MOUSE) , it compiles to around 6k.
In all cases, the actual 'main' routine is 11 instructions long. The remainder consists of:
the kernel itself - this space is re-used as stack/heap/data space at run time.
the HMI (video, keyboard and mouse) drivers - this space is also re-used as stack/heap/data space at run time.
the library support code (stdio in particular is quite large).
For comparison, gcc compiles "hello_world" down to 16k on a windows PC - and Catalina has to include ALL O/S support, whereas the PC executble does not.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
I have got Code::Blocks·working.
Now to get Catalina up on Ramblade SBC. What targets files require modification ?
There is only SIO on 23..22 so maybe its only Catalina_xmm, are there others ?
Ron
Post Edited (Ron Sutcliffe) : 1/22/2010 12:08:18 AM GMT
The first one is the same as before - flashing cursor, green background and no text
I tried simplifying the one that works with the second option and just changed the hires vga to low res VGA and that works fine.
So I think the problem is with linking to the hi res vga driver (or the driver itself).
The program doesn't test the keyboard as such, but the keyboard lights are blinking on restart, so I think the keyboard is working ok too.
I've taken a working Dracblade and popped out the propeller chip and I can send you the board. (It boots to CP/M, you might like to try programming in BDS C?!) Can you please PM me your address?
But more to the point, once the display is working we can look at using the 512k of ram.
Down the bottom of this thread I've posted the ram driver code. It uses the same instructions as cluso's driver, but the PASM is completely different. But very easy to use:
then at the beginning
then set the high latch A16-A23 (512k uses A16 to A18, the other pins are spare)
HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23 RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' set high latch byte A16-A18, plus led plus the 4 spare outputsthen to write some bytes to a location in ram
r := RamLatches.DoCmd("W", @buff, $FF00, 256) 'write 256 bytes from buff[noparse][[/noparse]] to sram location $FF00and to read some bytes from ram
r := RamLatches.DoCmd("R", @buff, $80, 128) ' read 128 bytes from location 80H in ram to the buff arrayI hope there is a cunning way that could be useful for storing data in C
Dracblade ram driver
''Dracblade driver for talking to a ram chip via three latches '' Modified code from Cluso's triblade ' DoCmd(command_, hub_address, ram_address, block_length) ' R - read bytes at address n up (n to n+block_length) where n =0 to 65535 (ie lower 64k of the sram chip) ' W - write bytes at address n up ' I - initialise ' N - Led on ' F - Led off ' H - set high latch to value in ramaddress A16 to A23 (will include the led) VAR ' communication params(5) between cog driver code - only "command" and "errx" are modified by the driver long command, hubaddrs, ramaddrs, blocklen, errx, cog ' rendezvous between spin and assembly (can be used cog to cog) ' command = R, W, N, F H =0 when operation completed by cog ' hubaddrs = hub address for data buffer ' ramaddrs = ram address for data ($0000 to $FFFF) ' blocklen = ram buffer length for data transfer ' errx = returns =0 (false=good), else <>0 (true & error code) ' cog = cog no of driver (set by spin start routine) PUB start : err_ ' Initialise the Drac Ram driver. No actual changes to ram as the read/write routines handle this command := "I" cog := 1 + cognew(@tbp2_start, @command) if cog == 0 err_ := $FF ' error = no cog else repeat while command ' driver cog sets =0 when done err_ := errx ' driver cog sets =0 if no error, else xx = error code PUB stop if cog cogstop(cog~ - 1) PUB DoCmd(command_, hub_address, ram_address, block_length) : err_ ' Do the command: R, W, N, F, H hubaddrs := hub_address ' hub address start ramaddrs := ram_address ' ram address start blocklen := block_length ' block length command := command_ ' must be last !! ' Wait for command to complete and get status repeat while command ' driver cog sets =0 when done err_ := errx ' driver cog sets =0 if no error, else xx = error code DAT '' +--------------------------------------------------------------------------+ '' | Dracblade Ram Driver (with grateful acknowlegements to Cluso) | '' +--------------------------------------------------------------------------+ org 0 tbp2_start ' setup the pointers to the hub command interface (saves execution time later ' +-- These instructions are overwritten as variables after start comptr mov comptr, par ' -| hub pointer to command hubptr mov hubptr, par ' | hub pointer to hub address ramptr add hubptr, #4 ' | hub pointer to ram address lenptr mov ramptr, par ' | hub pointer to length errptr add ramptr, #8 ' | hub pointer to error status cmd mov lenptr, par ' | command I/R/W/G/P/Q hubaddr add lenptr, #12 ' | hub address ramaddr mov errptr, par ' | ram address len add errptr, #16 ' | length err nop ' -+ error status returned (=0=false=good) ' Initialise hardware (unlike the triblade, just tristates everything and read/write set the pins) init mov err, #0 ' reset err=false=good mov dira,zero ' tristate the pins done wrlong err, errptr ' status =0=false=good, else error x wrlong zero, comptr ' command =0 (done) ' wait for a command (pause short time to reduce power) pause mov ctr, delay wz ' if =0 no pause if_nz add ctr, cnt if_nz waitcnt ctr, #0 ' wait for a short time (reduces power) rdlong cmd, comptr wz ' command ? if_z jmp #pause ' not yet ' decode command cmp cmd, #"R" wz ' R = read block if_z jmp #rdblock cmp cmd, #"W" wz ' W = write block if_z jmp #wrblock cmp cmd, #"N" wz ' N= led on if_z jmp #led_turn_on cmp cmd, #"F" wz ' F = led off if_z jmp #led_turn_off cmp cmd, #"H" wz ' H sets the high latch if_z jmp #sethighlatch mov err, cmd ' error = cmd (unknown command) jmp #done tristate mov dira,zero ' all inputs to zero jmp #done ' turn led on led_turn_on or HighLatch,ledpin ' set the led pin high jmp #OutputHighLatch ' send this out led_turn_off andn HighLatch,ledpin ' set the led pin low jmp #OutputHighLatch ' send this out ' set high address bytes with command H, pass value in third variable of the DoCmd ' 4 bytes - masks off all but bits 16 to 23 sethighlatch call #ram_open ' gets address value in 'address' shr address,#16 ' shift right by 16 places and address,#$FF ' ensure rest of bits zero mov HighLatch,address ' put value into HighLatch jmp #OutputHighLatch ' and output it '--------------------------------------------------------------------------------------------------------- 'Memory Access Functions rdblock call #ram_open ' get variables from hub variables rdloop call #read_memory_byte ' read byte from address into data_8 wrbyte data_8,hubaddr ' write data_8 to hubaddr ie copy byte to hub add hubaddr,#1 ' add 1 to hub address add address,#1 ' add 1 to ram address djnz len,#rdloop ' loop until done jmp #init ' reinitialise wrblock call #ram_open wrloop rdbyte data_8, hubaddr ' copy byte from hub call #write_memory_byte ' write byte from data_8 to address add hubaddr,#1 ' add 1 to hub address add address,#1 ' add 1 to ram address djnz len,#wrloop ' loop until done jmp #init ' reinitialise ram_open rdlong hubaddr, hubptr ' get hub address rdlong ramaddr, ramptr ' get ram address rdlong len, lenptr ' get length mov err, #5 ' err=5 mov address,ramaddr ' cluso's variable 'ramaddr' to dracblade variable 'address' ram_open_ret ret read_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov dira,LatchDirection2 ' for reads so P0-P7 tristate till do read mov outa,GateHigh ' actually ReadEnable but they are the same andn outa,GateHigh ' set gate low nop ' short delay to stabilise nop mov data_8, ina ' read SRAM and data_8, #$FF ' extract 8 bits or outa,GateHigh ' set the gate high again read_memory_byte_ret ret write_memory_byte call #RamAddress ' sets up the latches with the correct ram address mov outx,data_8 ' get the byte to output and outx, #$FF ' ensure upper bytes=0 or outx,WriteEnable ' or with correct 138 address mov outa,outx ' send it out andn outa,GateHigh ' set gate low nop ' no nop doesn't work, one does, so put in two to be sure nop ' another NOP or outa,GateHigh ' set it high again write_memory_byte_ret ret RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram mov dira,LatchDirection ' set up the pins for programming latch chips mov outx,address ' get the address into a temp variable and outx,#$FF ' mask the low byte or outx,LowAddress ' or with 138 low address mov outa,outx ' send it out andn outa,GateHigh ' set gate low ' ?? a NOP or outa,GateHigh ' set it high again ' now repeat for the middle byte mov outx,address ' get the address into a temp variable shr outx,#8 ' shift right by 8 places and outx,#$FF ' mask the low byte or outx,MiddleAddress ' or with 138 middle address mov outa,outx ' send it out andn outa,GateHigh ' set gate low or outa,GateHigh ' set it high again RamAddress_ret ret OutputHighLatch ' sends out HighLatch to the 374 that does A16-19, led and the 4 spare outputs mov dira,latchdirection ' setup active pins 138 and bus mov outa,HighLatch ' send out HighLatch or outa,HighAddress ' or with the high address andn outa,GateHigh ' set gate low or outa,GateHigh ' set the gate high again OutputHighLatch_ret jmp #tristate ' set pins tristate delay long 80 ' waitcnt delay to reduce power (#80 = 1uS approx) ctr long 0 ' used to pause execution (lower power use) & byte counter GateHigh long %00000000_00000000_00000001_00000000 ' HC138 gate high, all others must be low Outx long 0 ' for temp use, same as n in the spin code LatchDirection long %00000000_00000000_00001111_11111111 ' 138 active, gate active and 8 data lines active LatchDirection2 long %00000000_00000000_00001111_00000000 ' for reads so data lines are tristate till the read LowAddress long %00000000_00000000_00000101_00000000 ' low address latch = xxxx010x and gate high xxxxxxx1 MiddleAddress long %00000000_00000000_00000111_00000000 ' middle address latch = xxxx011x and gate high xxxxxxx1 HighAddress long %00000000_00000000_00001001_00000000 ' high address latch = xxxx100x and gate high xxxxxxx1 'ReadEnable long %00000000_00000000_00000001_00000000 ' /RD = xxxx000x and gate high xxxxxxx1 ' commented out as the same as GateHigh WriteEnable long %00000000_00000000_00000011_00000000 ' /WE = xxxx001x and gate high xxxxxxx1 Zero long %00000000_00000000_00000000_00000000 ' for tristating all pins data_8 long %00000000_00000000_00000000_00000000 ' so code compatability with zicog driver address long %00000000_00000000_00000000_00000000 ' address for ram chip ledpin long %00000000_00000000_00000000_00001000 ' to turn on led HighLatch long %00000000_00000000_00000000_00000000 ' static value for the 374 latch that does the led, hA16-A19 and the other 4 outputs▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/21/2010 11:20:47 PM GMT
I suggest you download and have a look at the DracBlade support package - it contains all the files that might need to be changed, and if you search for 'DRACBLADE' you will see every change I had to make for that board (including XMM changes, even though the XMM code itself hasn't been written yet). You can model your RamBlade changes on that. Mostly it's changing the pin configurations and the choice of drivers to use in various circumstances (e.g. on the RamBlade you will probably want to default to the PC drivers for display and keyboard).
I won't get time to do this myself till at least next week, but if you can wait that long I'll include both RamBlade and DracBlade support in a Catalina patch release (at least LMM support - for XMM support I'll either need a RamBlade board, or rely on Cluso or yourself to write the XMM code).
I have finally managed to fix the Catalina program loader and want to get that out this week - then I have a backlog of work to do to support Bob Anderson's new C source level debugger (woohoo!).
Ross.
PM sent.
The next program you might want to try is probably 'test_suite.c' - this is a trivial program that test a few simple C features (and also uses the keyboard).
Ross.
And I must say that this little program is a really good introduction to C. It is very helpful to see real world simple examples of code.
I wrote a tiny batch file with a simple name so I can compile quickly. Called it TS.BAT and it contains
catalina -D DRACBLADE test_suite.c -lc -D LORES_VGA
So now the edit/download/re-edit/download cycle is down to only 5 seconds. That makes development fun!
I wonder if you might be interested in adding in the LCD code? No hurry as I know other things are higher priority, but this is one of the nifty things about the dracblade - you don't need a VGA or TV if you don't want to. For small projects you can do a lot with a 20x4LCD (or even smaller ones), especially if you keep the questions and answers short
enter your name:
enter your age:
etc
With CP/M the output goes to vga, to LCD and to the serial port and hence a terminal program, so you can use all three if you want.
PUB PrintChar(c) ' sends c to the uart, LCD display and the vga display UART.tx(0,c) ' send to the PC LCD.out(c) ' send to LCD display vgatext.txVT100(c) ' send to vt100 terminalThe LCD driver is pretty straightforward. But I'm not sure how catalina includes things like optional code. Is it with #ifdefs like the zicog does?
'' parallel 20x4 lcd driver for the DracBlade including a 'Terminal' that scrolls properly, backspace etc CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 LatchDirection =%00000000_00000000_00001111_11111111 ' 138 active, gate active and 8 data lines active MaskLowByte = %00000000_00000000_00000000_11111111 ' used in lots of routines to & mask off low byte LCDLatch = %00000000_00000000_00001011_00000000 ' LCD latch is xxxx101x and gate high xxxxxxx1 EnableBit = %00000000_00000000_00000000_00000010 ' Enable pin 6 on LCD displays OBJ delay : "timing" VAR long Char ' Character To Send To LCD long Inst ' Instuction To Send To LCD long Column ' column counter for line 4 ' don't use byte, causes all sorts of overrun errors long LineNumber ' line number 1,2,3,4 long LCDChar ' character to send to LCD 0-$FF long LCDByte ' byte to latch out to LCD display byte Display[noparse][[/noparse]79] ' buffer for display 20x4 ' put this last as bizarre overwriting going on PUB Start | n Init_Lcd Column:=0 ' start at zero repeat n from 0 to 79 ' fill the display memory with spaces Display[noparse][[/noparse]n]:=" " 'fill with spaces Redraw { repeat 25 ' test code for running standalone out(65) out(10) out(66) out(13) } PUB str(stringptr) '' Print a zero-terminated string repeat strsize(stringptr) out(byte[noparse][[/noparse]stringptr++]) PUB dec(value) | i '' Print a decimal number if value < 0 -value out("-") i := 1_000_000_000 repeat 10 if value => i out(value / i + "0") value //= i result~~ elseif result or i == 1 out("0") i /= 10 PUB hex(value, digits) '' Print a hexadecimal number value <<= (8 - digits) << 2 repeat digits out(lookupz((value <-= 4) & $F : "0".."9", "A".."F")) PUB bin(value, digits) '' Print a binary number value <<= 32 - digits repeat digits out((value <-= 1) & 1 + "0") PUB out(c) | i,j ' Output a character, ignores most <32 and all >126 ' possibly add a 'turn on display' and 'turn off display' with selected ascii characters ?? esc seq i:=c ' need a local working variable as an if statement seems to corrupt subsequent working variables! j:=Column ' and need a local version of column otherwise corrupts this too if c==10 ' Linefeed Newline Column:=0 ' reset column counter j:=21 ' ensures code below doesn't run if j<20 ' this LCD driver code is slow so better to not print anything after line 20 and wait for CRLF ' if j > 19 ' is it off the end of the display? (old display wrapped around) ' Column:=0 ' reset to beginning ' Newline if c==08 ' Backspace Backspace ' if c==13 ' do nothing as LF includes CR as part of the code if i >= 31 ' and statements don't work in if lines?! if i<=126 ' send the ascii character char := c ' get the character Send_Text ' send it out Display[noparse][[/noparse]Column+60]:=c ' store the character in the last column Column:=Column+1 ' add 1 to column if j==19 CursorOff PUB CursorOn Inst:=13 ' turn on the cursor Send_Inst PUB CursorOff Inst:=12 ' cursor off Send_Inst ' send the instruction PRI Init_Lcd LCDLow ' set the 6 LCD lines low delay.pause1ms(200) ' short delay for LCD bootup 200ms LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx PulsOut LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx PulsOut LCDByte:=%00001100 ' send out 0011 already shifted to xxnnnnxx PulsOut LCDByte:=%00001000 ' send out 0010 already shifted to xxnnnnxx PulsOut LCDByte:=%00001000 ' send out 0010 already shifted to xxnnnnxx PulsOut LCDByte:=%00100000 ' send out 1000 already shifted to xxnnnnxx PulsOut Inst:=14 ' cursor on Send_Inst Inst:=1 ' cls Send_Inst Inst:=13 ' flashing cursor Send_Inst Inst:=128 ' to position 1 Send_Inst pri Send_Inst ' send instruction in Inst RSLow ' not actually needed see below but makes code more logical LCDByte:=Inst ' get high nibble LCDByte:=LCDByte>>2 ' shift right two bits so xxnnnn00 LCDByte:=LCDByte & %00111100 ' mask the nibble and sets RS low as well (bit0) Pulsout ' send it out LCDByte:=Inst ' get low nibble LCDByte:=LCDByte<<2 ' shift left two bits so xxnnnn00 LCDByte:=LCDByte & %00111100 ' mask the nibble and sets RS low as well (bit0) Pulsout ' send it out RSHigh ' back to text mode pri Send_Text ' pass Char = a byte 'RS always high = bit 0, bits are xxnnnnER where nnnn is the nibble, E=enable and R=RS LCDByte:=Char LCDByte:=LCDByte>>2 ' shift right two bits so xxnnnn00 LCDByte:=LCDByte & %00111100 ' mask off just the nibble LCDByte:=LCDByte | %00000001 ' keep RS high Pulsout ' send it out LCDByte:=Char ' get low nibble LCDByte:=LCDByte<<2 ' shift left two bits so xxnnnn00 LCDByte:=LCDByte | %00000001 ' keep RS high Pulsout pub Next_Line Inst := %11000000 ' Move Cursor To Line 2 Send_Inst PRI ToggleGate OUTA[noparse][[/noparse]8]:=0 ' set gate pin low OUTA[noparse][[/noparse]8]:=1 ' and high again - may need a delay in PASM PRI EnableLatchPins DIRA:=LatchDirection ' 138 active, gate active and 8 data lines active PRI Tristate ' tristate all pins DIRA:=%00000000_00000000_00000000_00000000 PUB LCDOutput | n ' sends byte LCDByte to latch EnableLatchPins ' turn on the pins needed to talk to the latches n:=LCDByte ' byte value to send out n:=(n & MaskLowByte) ' 2 AND mask the low byte n:=(n | LCDLatch ) ' 3 OR with the LCD address 138 OUTA:=n ' 4 send it out ToggleGate ' 5 and latch it tristate ' back to tristate on all pins PUB LCDLow ' sets all LCD pins low for startup LCDByte:=0 LCDOutput PUB PulsOut ' pulse the enable pin 6 high then low - uses LCDByte and returns it unchanged LCDByte:=(LCDByte | %00000010) ' logical OR to set just this bit high LCDOutput ' send it out ' delay.pause1ms(1) ' short pause not needed as spin very fast LCDByte:=(LCDByte & %11111101) ' logical AND set just this bit low LCDOutput ' send it out ' delay.pause1ms(1) ' delay for LCD to process it PUB RSHigh ' set RS pin 4 high - uses LCDByte and returns it unchanged LCDByte:=(LCDByte | %00000001) ' logical OR to set just this bit high LCDOutput PUB RSLow ' set RS pin 4 low - uses LCDByte and returns it unchanged LCDByte:=(LCDByte & %11111110) ' logical AND set just this bit low LCDOutput PUB Backspace | i,j ' backspace is a special case - need to subtract 1 off the column, make the last character a space ' and redraw the screen and print out column number of characters on last line ' only really works on line 4 but most of the time the display is on line 4 anyway j:=Column ' the last character added 1 to column so start with one less if j>1 ' not reliable at 1 Display[noparse][[/noparse]Column+60-1]:=32 ' was one past the character Column:=Column-1 ' subtract 1 Redraw repeat i from 0 to j-2 Char:=Display[noparse][[/noparse]60+i] ' print out the last row with one less character Send_Text PUB Redraw ' redraw the entire screen Inst:=128 ' line 1 Send_Inst LineNumber:=1 ' print line 1 Printline Inst:=192 ' line 2 Send_Inst LineNumber:=2 ' print line 2 Printline Inst:=148 ' line 3 Send_Inst LineNumber:=3 ' print line 3 Printline Inst:=212 ' line 4 Send_Inst LineNumber:=4 ' print line 4 Printline Inst:=212 ' cursor to beginning of line 4 Send_Inst CursorOn PUB PrintLine | n ' Prints the line in LineNumber 1 to 4 n:=(LineNumber-1)*20 ' convert to pointer for the array 0-79 repeat 20 ' do this 20 times Char:=Display[noparse][[/noparse]n] ' get the character from the array Send_Text ' send it out n:=n+1 ' increment counter PUB Newline | i ' move the lines all up one, clear line 4, move cursor to position 1 of line 4 repeat i from 0 to 59 ' move up to next line Display[i]:=Display[noparse][[/noparse]i+20] repeat i from 60 to 79 Display[i]:=32 ' space Column:=0 ' column counter to zero Redraw ' redraw the screen [/i][/i]▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/22/2010 12:57:33 AM GMT
Glad you got it working. I'll figure out what's going wrong with the hires VGA driver when I get some time.
The LCD code would make a very useful debugging aide - no promises, but I'll see what I can do. The simplest way to add support for it in Catalina would be to just add it as another alternative HMI option (e.g. if you compile a program with '-D LCD' standard output (stdout) would become the LCD). The problem with this is that you couldn't use both VGA and LCD at the same time.
A more complex (but more useful) solution would be to make the VGA display the C standard output (stdout) but have the LCD display the C standard error output (stderr) - this would fit in very well with using it as a debugging aide. However, this would require a custom DracBlade VGA driver, as currently both stdout and stderr go to the VGA display (but using separately addressable cursors so you can put them at different places on the screen).
Ross.
Just released a small patch to fix a bug in the Catalina Generic SD/SIO Program Loader. The patch is attached to the first post in this thread. Here are the details:
Patch Release 22 Jan 10
================
This release contains a small patch to fix a bug in the Catalina Generic SD and SIO Loaders which could lead to programs failing to initialize correctly - typical symptoms were that the screen was cleared, but the C program was never started (especially when using the HiRes TV driver). It appears that clearing unused hub RAM to zero is required whenever a new program is loaded, or the SPIN interpreter may not start correctly.
Just apply this patch over Release 2.3 and run 'rebuild_all' in the utilities directory to rebuild the loader binaries - no need to rebuild Catalina.
Ross.
I just noticed a difference between your version of the HiRes VGA text driver (VGA_HiRes_Text.spin) and my version modified for Catalina (Catalina_VGA_HiRes_Text.spin).
I had assumed my version was based on Chip's original, but I found a difference I can't account for:
My version:
Your version (and also the version in the OBEX):
When I use your version it no longer works on my Hydra. I don't remember making this change, so I think the Hydra must have come with a customized version and I didn't realize it.
I have enclosed a new version (modified for Catalina) based on the OBEX original. Can you try it out for me? Please copy the enclosed file to the Catalina target directory and recompile 'hello_world.c' using the following command:
Thanks,
Ross.
Edit: attachment removed. DracBlade support is now part of the main Catalina release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 1/28/2010 10:40:01 AM GMT
Ok, new hires to c:\program files\catalina\target
catalina -D DRACBLADE hello_world.c -lc
and I still get pale green cursor on dark green screen.
There will be one tiny thing I'm not doing right...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It was a long shot, but worth a try - I'll figure out what the problem is when your board arrives.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just released a small patch to Catalina - it is attached (as usual) to the first post in this thread. Here are the details:
Patch Release 28 Jan 10
================
This release is a small patch to fix a bug in the Catalina HiRes VGA Driver when used with the NO_MOUSE option, or on a platform without a mouse (such as the DracBlade). It also adds support for the DracBlade (there are no XMM drivers for the DracBlade yet, but LMM and EMM programs will now work correctly).
Just unzip the patch in the zipfile attached to this post over a Catalina Release 2.3 installation and rebuild any affected C programs - no need to rebuild Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just updated the Patch Release 28 Jan 10 - the original zip file had the wrong folder names, and unzipping it over your exisitng Catalina installation would have simply created a 'Catalina_Patch_28_Jan_10" folder - you can either download the zip file again, or manually copy everything out of that folder up one level (i.e. into the main Catalina directory).
Sorry about that!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Minor problem - still bright green on dark green background.
Ok, can you explain how to write a C program for a CP/M old timer like me?
In CP/M the screen is whatever physical color it happens to be. Green on black, white on blue, etc. But you can change it if you want. Either with a call to some I/O ports, or with some VT100 codes. Those calls are usually the first thing in a program, right before the CLS clear screen and they are then followed by the text.
But a Catalina program seems to leap straight into printing out text:
/* Beginning C, Third Edition By Ivor Horton ISBN: 1-59059-253-0 Published: Apr 2004 Publisher: apress */ #include <stdio.h> #include <catalina_hmi.h> #include <ctype.h> #define SIZE 8 /* Board size - must be even */ /* Function prototypes */ void display(char board[noparse][[/noparse]][noparse][[/noparse]SIZE]); int valid_moves(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player); void make_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int row, int col, char player); void computer_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player); int best_move(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], int moves[noparse][[/noparse]][noparse][[/noparse]SIZE], char player); int get_score(char board[noparse][[/noparse]][noparse][[/noparse]SIZE], char player); void main() { char board [noparse][[/noparse]SIZE][noparse][[/noparse]SIZE] = { 0 }; /* The board */ int moves[noparse][[/noparse]SIZE][noparse][[/noparse]SIZE] = { 0 }; /* Valid moves */ int row = 0; /* Board row index */ int col = 0; /* Board column index */ int no_of_games = 0; /* Number of games */ int no_of_moves = 0; /* Count of moves */ int invalid_moves = 0; /* Invalid move count */ int comp_score = 0; /* Computer score */ int user_score = 0; /* Player score */ char y = 0; /* Column letter */ int x = 0; /* Row number */ char again = 0; /* Replay choice input */ int player = 0; /* Player indicator */ t_string(1,"\nREVERSI\n\n"); t_string(1,"You can go first on the first game, then we will take turns.\n"); t_string(1," You will be white - (O)\n I will be black - (@).\n");There probably is a way of defining screen colors within the program itself - for the dracblade it would be some OUT commands or VT100 escape commands.
But I think Catalina defines it somewhere else. Looking at the vga driver code, I think the variables are passed via this line
(the Dracblade CP/M emulation is using the same original VGA driver so I know my way around this one!)
But what is setting ColorPtr? Is it set somehow with the command -D DRACBLADE
And if so, is DRACBLADE a file somewhere or is it a series of switches in another source file?
Anyway, at least we can play some games with Catalina on the Dracblade. Please forgive me if I don't post for a while *grin*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Great news! I thought for a horrible moment Catalina had destroyed your PC!
The bright green characters on a dark green background is my default color scheme for HiRes VGA. It is set up in the HMI plugin (in this case Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_Input.spin - on or about line 365).
You can also change colours from within the C program by using low level Catalina HMI functions. I have enclosed an example. Compile it with
You could add the set_screen_color function in this program to other programs. such as the the othello.c program (and call it at the beginning of the main routine). Note that this function is specific to the HiResVGA driver - the LoResVGA uses different colors and you have to set the value of each character cell individually. One day I will write some simple "wrapper" functions that make this easier to do - so much to do, so little time!
And DRACBLADE is just a symbol used in various #define statements spread throughout the target directory files - it just causes the DracBlade specific sections of code to be included during the compilation process.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 1/29/2010 2:27:15 PM GMT
Ok, I edited that hmi driver
#ifdef PROXY_SCREEN #else ' set up colors repeat i from 0 to rows - 1 ' word[noparse][[/noparse]pscreen][noparse][[/noparse]colors + i] := %%0100_1310 ' pale green on dark green word[noparse][[/noparse]pscreen][noparse][[/noparse]colors + i] := %00001000_11111100 ' white on blueHowever, it hasn't changed anything.
1) is %% octal or something - and hence is my binary code correct?
2) Reading the ifdef, I think the above is only called if PROXY_SCREEN is false? What is proxy_screen, and if I'm not adding it to the command line, maybe it is false, and hence is the color definition coming from anywhere else in the code?
Alright, I'm going crazy here. I saved that change and then went to find the file I had edited. Because the names are all so similar for those drivers, I went and resorted the directory based on when the files were last modified. A huge number had been edited at the same time - which was the time I did the last .c program compile. I figured - this is odd, only writing a windows file changes the edit time, not a read and a compiler should just be reading. So I went back to check my changes and they had gone.
So to really test this out I edited out the lines above using the propeller tool and recompiled a .c program. The lines are back again!
Are the spin source files self modifying or something? How do you make changes to them, or are you not supposed to?
BUT ... maybe it doesn't matter, because hello_colour.c works fine, and so it would be much easier just to add these lines of code at the beginning of a program. See photo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/29/2010 11:45:37 PM GMT
Your change looks fine - I just tried it here and it works. But you are not editing the correct file (yes, they are self-modifying!). You have to edit Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_Input.spin in the directory C:\Program Files\Catalina\target\input\. Make sure it has the _Input in the filename - you are probably editing the version in the target directory instead - and the compiler rebuilds this version on every compile from the input files. I realize this is a bit obscure - but it is documented in various places, including at the top of the file itself.
The %% in SPIN means 'Quaternary' - each digit is 0..3, representing 2 bits. See the Prop manual for more details.
PROXY_SCREEN is only relevant for multi-CPU Prop systems - it allows a program running on one CPU to use a display connected to another CPU. It's used on the TriBladeProp or Morpheus, but is not relevant for the DracBlade.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The little colour.c program is about as simple as it gets - very easy to understand and use.
At the beginning of this thread is mention of code::blocks. Is this an IDE for catalina? I got a bit confused about the IDE option - is it possible to write and compile a C program from within one IDE type environment (similar to the prop tool)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes, Code::Blocks is a really cool compiler-independent graphical development environment. It's a little like the Parallax Propeller tool, but actually more similar in look and feel to Visual Studio, or to the Embedded Workbench (which many AVR users will be familiar with).
It provides a front-end to the Catalina command line compiler - and for most programs you will never need to open a DOS window at all. Once you set up a Code::Blocks project with the appropriate configuration, it's one-click to recompile.
Currrently you can create, edit and compile C programs with Code::Blocks. Soon you will also be able to download and debug them. The built-in editor is C syntax-aware and context-sensitive. It also has a built in 'make' function for maintaining programs that consist of multiple C source files.
In the current release, setting up Code::Blocks is a little tricky - you have to donwload Codde::Blocks, install it, run it once, and then edit its configuration files it creates to make it 'Catalina-aware'. This is all documented in the README.codeblocks file in the codeblocks subdirectory. In future I'll try and streamline the install process.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've just been reading through memory models en.wikipedia.org/wiki/C_memory_model
The paging system of the IBM with its overlapping offsets is going to be a bit different, but paging ought to fit nicely with a 512k model. I think this is a far pointer ie up to 1 megabyte.
Memory models are the one thing that C has that is simply not present in Basic (as far as I know). Versions of Basic were stuck with the memory of the machine they were designed for, but C seems to have worked out a model in the mid 1980s that meant it was much more machine independent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The page you refer to is fairly specific to machines with 16 bit architectures (such as the x86). Catalina implements it's own memory models, tailored to the Prop's true 32 bit architecture (but peculiar memory arrangement).
All the Catalina memory models use "flat" 32 bit addresses (i.e. no segmentation). Even if the XMM hardware implements physical memory using multiple pages (for speed, or to save pins), this is hidden from the C program by the XMM access routines (such routines have not yet been written for the DracBlade, but the same will be true for those as well).
The Catalina memory models currently implemented are:
- Tiny. In this mode, all addresses are Hub RAM addresses – this means that all code, data, stack and heap must fit into the 32k (Prop I) or 256k (Prop II) Hub RAM. This is the mode implemented by the LMM Kernel for all programs compiled using the –x0 or –x1 command line options. It can be used on any Propeller.
- Small. In this mode, all data addresses are Hub RAM addresses, but all code addresses are XMM RAM addresses. Currently, I only use 24 bits as XMM address since I can't imagine anyone needing more than 16Mb on a single Prop (famous last words!). All data, stack and heap must fit into the 32k (Prop I) or 256k (Prop II) Hub RAM, but code size can be up to 16Mb. This mode is implemented by the XMM Kernel, for programs compiled using the –x2 command line option. Of course, this mode requires external XMM RAM.
- Large. In this mode, global data and code addresses are XMM addresses, and so the total code and global data (including heap) size can be up to 16Mb. The 32k (Prop I) or 256k (Prop II) of Hub RAM is used for the stack and for local data. This mode is also implemented by the XMM Kernel, for programs compiled using the –x5 command line option. Of course, this mode also requires external XMM RAM.
More detail can be found in the Catalina Reference Manual (pp 66).Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So - a question for Ross - is it now possible to use Catalina to write BIG programs in C?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
YES!
Currently Catalina supports as much as the XMM target can give... so you could use the 512KB on your board for code and data!
One of the Blade's on TriBlade can support 1MB
Morpheus supports 16MB, 2.5MB has been tested
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Yes, as Bill mentions above, instead of a measly 496 instructions, LMM allows a PASM program to be up to 8198 instructions, or use up to 32Kb of data (up to the maximum 32Kb of Hub RAM), and XMM allows PASM programs to be up to 4,194,304 instructions, or use up to 16Mb of data (up to the maximum size of the physical XMM RAM installed).
There are a few restrictions on which PASM instructions you can use - but Catalina takes care of all that for you.
LMM will work on ANY Propeller - it's like having a Prop with a cog size of up to 8192 longs instead of 496 longs (but running a bit slower).
XMM will work on the Hydra, Hybrid, TriBladeProp, or Morpheus - and now on the DracBlade. It's like having a Prop with a cog size of 4 million longs (but running slower still).
I'll post the new DracBlade target support package tonight.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just released a small patch to add XMM support for the DracBlade. The DracBlade is now fully integrated into the standard Catalina target support package.
See the first post in this thread for more details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
This really does open up some possibilities for coding huge programs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
ive gone over this posting 3 times and still cant find where to download the catalina compiler?
the 3 patches, no problem, but not the base program?
any ideas how my fading light keeps missing this?
thanks, norm
ive gone over this posting 3 times and still cant find where to download the catalina compiler?
the 3 patches, no problem, but not the base program?
any ideas how my fading light keeps missing this?
thanks, norm"
Um...yeah. Every link to calalina sends me back to the top of this thread. I'm not an idiot, but I'm not Sherlock Holmes either.
They are in the second to sixth posts in the thread (depending on your platform - there are linux and windows versions, source and binary releases).
In all cases you should download the documents, utilities and demos zips, and then the binary release zips for your platform. The source release zips are optional. After installing the base releases (source and/or binary) then apply the patch releases.
Holler if you have problems.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I DID figure it out. It took all morning, but I did (two hours spent looking for codeblocks in my settings file - who knew it would be hidden?). I even compiled "hello.c". It takes up 23kb???!!! I think I have to read the manual.
Glad you got it sorted. Let me know of anything you had particular trouble with and I'll try and make it clearer in the documentation for the next release. I don't get the bit about Code::Blocks settings being hidden - can you explain?
The "Hello, world" program compiles to 23k only if you include floating point support in the stdio routines (i.e. compile with -lc). If you compile with the integer-only stdio routines (-lci) it compiles to 15k. If you use the Catalina alternate I/O routines (see hello_world_1.c) it compiles to 8k. If you then also omit the (unused) keyboard and mouse drivers (using -D NO_KEYBOARD -D NO_MOUSE) , it compiles to around 6k.
In all cases, the actual 'main' routine is 11 instructions long. The remainder consists of:
- the kernel itself - this space is re-used as stack/heap/data space at run time.
- the HMI (video, keyboard and mouse) drivers - this space is also re-used as stack/heap/data space at run time.
- the library support code (stdio in particular is quite large).
For comparison, gcc compiles "hello_world" down to 16k on a windows PC - and Catalina has to include ALL O/S support, whereas the PC executble does not.Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 2/7/2010 10:58:38 PM GMT