I'll send you a list of the VT100 codes I use tonight - it is really only 'vi' that depends on them.
Ross.
In case you can run the VT100 emulation in its own cog, you could use mine - which works rather well with Wordstar under CP/M.
It is called with a list of parameters in longs, most of which are compatible with VGA_HiRes_Text. You can attach it to another video screen memory, though.
#0 pointer to a command long (where you write the character codes to send and wait until it's 0 again)
#1 pointer to your screen memory (columns x rows bytes)
#2 pointer to colour memory (rows words with per row colours)
#3 cursor pointer (may be 0 or points to a VGA_HiRes_Text compatible 6 byte array)
#4 vsync pointer (pointer to a long that is written to at vsync - not really used)
#5 width of the screen
#6 height of the screen
ESC c Reset Device
ESC [noparse][[/noparse] K Erase End Of Line
ESC [noparse][[/noparse] 2 J Erase Screen
ESC [noparse][[/noparse]?25l Invisible Cursor
ESC [noparse][[/noparse]?25h Visible Cursor
ESC [noparse][[/noparse]r ; c H Set Cursor to row r and column c
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Esc c (Reset Device): What does it do? (cursor home, non inverse, anything else special?) I can check the VT100 spec.
Cursor visible/invisible is easy (It doesn't mean hide characters does it? -not possible)
The others are easy. Erase Screen and Set Cursor are done with a single ASCII command, so easy to add.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Digital VT100 User Guide said...
Reset the VT100 to its initial state, i.e., the state it has after it is powered on. This also causes the execution of the power-up self-test and signal INIT H to be asserted briefly.
The initial state of a true VT100 is partially determined by the contents of it's non-volatile storage - but your interpretation woud usually be correct - i.e. screen blank, non-inverse, cursor at location 1,1 and the cursor is visible.
And yes, making the cursor visible/invisible only affects the cursor itself, not the character it is on.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Update to PropCMD (renamed BOOTPROP.BIN on the SD card to boot into this program)
PropCMD v0.061 adds...
"?" to display a list of available commands (FTP not working)
"RUN filename" is equivalent to "SPIN filename".
The binary is attached as well as the source.
BEWARE: Do not delete the old BOOTPROP.BIN, just rename it to something else. You must·NEVER·DELETE A FILE·as this may interfere with ZiCog that relies on the fact that files are contiguous. Then you may copy this file to the card as BOOTPROP.BIN or as it is and leave the old version as is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The zip file contains the sources for ZiCog v167 and has been compiled for 104MHz and uses 1pin TV and 1pin Kbd. I have also included the compiled binary as a separate file.
I have not tested this as yet as I will be away for a few days.
Included in the zip file are two new drivers for the RamBlade...
ZiCog_145.spin
RamBlade_203_005.spin
These drivers correct an SRAM timing problem where I was not holding the data and address after the end of CE & WE (I was disabling the data outputs and CE and WE in the same instruction). While the
hold time is specified as 0, the prop/track/sram timing did not always guarantee this would be met.
I have included the binary file...
ZICOG15A.BIN
This is a binary for ZiCog v150 compiled for the RamBlade with the new drivers using a UART/Terminal connected at 115200 baud. It has been tested.
I have included the binary file...
TEST_RB6.BIN
This is a binary for testing the RamBlade and does not report an error with the later filenames. It also tests some of the SRAM harder. It uses an attached UART/Terminal such as a pc connected at 115200. It has been tested.
The photo is the RamBlade in the new box (red translucent) that I will be using for the new Cluso's Modular Blades, including RamBlade II that I will announce shortly. The existing RamBlades will still be available. The screen is a 4.3" color LCD with 80x25 (ZiCog 1pin TV/Keyboard running) that I purchased on eBay for $25 inc postage (see recent thread). You can just see the edge of the PS2 keyboard on the right of the photo. Man that keyboard is huge!
Z168_1P.BIN
Here is the latest 1pin binary v168 compiled for 6.5MHz(104MHz), NTSC 80x25 mono, PS2 Keyboard...
Yes, RamBlade II will move the serial back to P31/P30. Because of this, it will be slightly slower to access the SRAM (an extra instruction read in the read loop). For that reason, RamBlade will also continue to be available.
I have been busy with other things so the pcbs have not been dispatched to production - there are a group of different pcbs to go.
Antoine: Have you downloaded the latest test programs and ZiCog for the RamBlade? The earlier versions were time sensitive. The latest is at the end of the end of the RamBlade thread (link in my signature). Let me know how you go please, perhaps on the RamBlade thread to save poluting this thread.
Cluso, yes I downloaded the latest test and ZiCog for the RamBlade, the first output in the text file I attached on the Catalina thread is in fact the output from the latest RamBlade test:
apart from that little difference in pullups readback (which is not on data bus anyway) the boards are still passing this test.
This is the output of Catalina ram test, which used to succeed too until not long ago:
Catalyst v3.3
> xmm_test
To begin, Press any key
TRIVIAL:
A 00000000 22222202 DEADBEEF
A 00000004 02222204 DEADBEEF
A 00000008 2222222A DEADBEEF
A 0000000C 2222220C DEADBEEF
A 00000010 22222212 DEADBEEF
A 00000014 22222214 DEADBEEF
A 00000018 2222221A DEADBEEF
A 0000001C 2222221C DEADBEEF
A 00000020 22220222 DEADBEEF
A 00000024 22222224 DEADBEEF
A 00000028 2222222A DEADBEEF
A 0000002C 2222022C DEADBEEF
A 00000030 22222232 DEADBEEF
A 00000034 22222234 DEADBEEF
A 00000038 2222223A DEADBEEF
A 0000003C 0222223C DEADBEEF
Again? y
TRIVIAL:
A 00000000 02222202 DEADBEEF
A 00000004 22222204 DEADBEEF
A 00000008 2222222A DEADBEEF
A 0000000C 2222220C DEADBEEF
A 00000010 22222212 DEADBEEF
A 00000014 22222214 DEADBEEF
A 00000018 2222221A DEADBEEF
A 0000001C 2222221C DEADBEEF
A 00000020 22222222 DEADBEEF
A 00000024 22222224 DEADBEEF
A 00000028 2222222A DEADBEEF
A 0000002C 2222022C DEADBEEF
A 00000030 22222232 DEADBEEF
A 00000034 22222234 DEADBEEF
A 00000038 2222223A DEADBEEF
A 0000003C 2222223C DEADBEEF
Again? y
TRIVIAL:
A 00000000 02020202 DEADBEEF
A 00000004 22222204 DEADBEEF
A 00000008 2222220A DEADBEEF
A 0000000C 2222220C DEADBEEF
A 00000010 22222212 DEADBEEF
A 00000014 22222214 DEADBEEF
A 00000018 2222221A DEADBEEF
A 0000001C 2202221C DEADBEEF
A 00000020 22222222 DEADBEEF
A 00000024 22222224 DEADBEEF
A 00000028 2202222A DEADBEEF
A 0000002C 2222022C DEADBEEF
A 00000030 22222232 DEADBEEF
A 00000034 22222234 DEADBEEF
A 00000038 2222223A DEADBEEF
A 0000003C 2222223C DEADBEEF
the test (repeated on the same locations) reads back a $22 value (bits 1 and 5 on databus I guess), superimposed to the value that was stored there. Some of the bits are flipping from time to next.
I have tried (at both 100MHz and 80MHz) to insert delays in Catalina access code, to allow more settling time, but it doesn't seem to make much difference.
Have you tried the latest Catalina on your RamBlades? Could you do run a ram test and see the result?
Antoine: I do not have Catalina running on the RamBlade. Ross is testing a new RamBlade driver for me hopefully over the weekend which will improve the performance but I didn't see anything wrong with his driver that should matter. When he has done this I have asked him to send me the tests so that I can try here. I want to try it on my RamBlade3 too.
As far as the Ram tests go, the pullup values read back will be different. The tests take care of this and that is why you get a passed message. The sram tests are not exhaustive because I do not check every data pattern per address. I increment the data and the address, so ultimately all values of data and all values of addresses are checked to ensure the hardware wiring is correct (i.e it should test for shorts or opens). However, it is not testing the sram itself for bit errors. Perhaps I will look at this over the w/e.
I note you say you have tried 100MHz and 80MHz. IIRC Ross checks at 100MHz. But remember, I ship the RamBlade with 104MHz (6.5MHz xtal) and a 13.5MHz xtal separately, so I presume you have a 6.25MHz xtal for 100MHz operation. Actually I guess so since you are getting a response from Catalina which does mean it is running somewhat. Does Catalina run without XMM?
Antoine: I do not have Catalina running on the RamBlade. Ross is testing a new RamBlade driver for me hopefully over the weekend which will improve the performance but I didn't see anything wrong with his driver that should matter. When he has done this I have asked him to send me the tests so that I can try here. I want to try it on my RamBlade3 too.
At this point it's worth waiting. Meanwhile I'll keep trying, but no worries. I'm sure it will get solved.
As far as the Ram tests go, the pullup values read back will be different. The tests take care of this and that is why you get a passed message. The sram tests are not exhaustive because I do not check every data pattern per address. I increment the data and the address, so ultimately all values of data and all values of addresses are checked to ensure the hardware wiring is correct (i.e it should test for shorts or opens). However, it is not testing the sram itself for bit errors. Perhaps I will look at this over the w/e.
Thanks for the info. Yeah I thought the same about the pullpus, as long as the result was "inclusive" it was fine.
I note you say you have tried 100MHz and 80MHz. IIRC Ross checks at 100MHz. But remember, I ship the RamBlade with 104MHz (6.5MHz xtal) and a 13.5MHz xtal separately, so I presume you have a 6.25MHz xtal for 100MHz operation. Actually I guess so since you are getting a response from Catalina which does mean it is running somewhat. Does Catalina run without XMM?
Yes it's running without XMM, Catalina compiled as tiny too (just tried fibo.c).
At the moment I have 5MHz on one board and 6.25M on the other.
Using 80MHz to rule out overclocking until it's solved, they both used to run fine at 100MHz.
I prefer 100MHz because I have 6.25 crystal on a couple of other boards, so this way I only have to deal with less variations.
A nice thing that I discovered about newer FTDI drivers is that they work at non standard speeds, so to connect with a program compiled for 6.25M after switching the crystal to 5.0M it is enough to specify 92160 as the serial speed, without recompiling.
For Mike Green:
Here is the source code and binary for the RamBlade EEPROM. You will need to short the WE link on the pcb and connect the propplug to the programming pins (the center 4 pins on the pcb edge labelled G, R, I, O) - I do this by just putting a 1x2 pin header with a shunt shorting it into the holes and manually keeping pressure on it. Otherwise you can solder pins into it and just put a shunt on it when you want to program it. PropBootSD_V1_10_RB1 - Archive [Date 2012.06.02 Time 09.52].zip PropBootSD_V1_10_RB1.binary
Mike, perhaps you missed shorting the WE pins. The eeprom is write protected by default.
However, it seems more likely that the programs on the SD card may be corrupted. Maybe you need to reformat and reload???
There is a test program for the RamBlade that tests all pins and the SRAM. Do you have it?
Alas, there's already a WE 1x2 header installed with a shorting block across it. Like I said, the Prop won't identify itself and you can't download anything to RAM or EEPROM ... I've got a 4-pin header in the right PCB holes that I used originally to download Zicog. I will probably do some continuity and short testing from the 4-pin header to the Prop pins, but your new RamBlade3R sounds like a nice replacement.
By default, what came on the SDcard that I ordered with my Ramblade way back when?
I'm thinking I want to do CPM over a serial terminal window and try out SuperCalc. Is that doable or do I need composite for that to work? If it will work over serial terminal, what terminal emulation do I need?
Comments
Here is the link http://forums.parallax.com/forums/default.aspx?f=25&m=431556&p=3
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'll send you a list of the VT100 codes I use tonight - it is really only 'vi' that depends on them.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
In case you can run the VT100 emulation in its own cog, you could use mine - which works rather well with Wordstar under CP/M.
It is called with a list of parameters in longs, most of which are compatible with VGA_HiRes_Text. You can attach it to another video screen memory, though.
#0 pointer to a command long (where you write the character codes to send and wait until it's 0 again)
#1 pointer to your screen memory (columns x rows bytes)
#2 pointer to colour memory (rows words with per row colours)
#3 cursor pointer (may be 0 or points to a VGA_HiRes_Text compatible 6 byte array)
#4 vsync pointer (pointer to a long that is written to at vsync - not really used)
#5 width of the screen
#6 height of the screen
The code is PASM LMM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Here is a list of VT100 codes I currently use:
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Esc c (Reset Device): What does it do? (cursor home, non inverse, anything else special?) I can check the VT100 spec.
Cursor visible/invisible is easy (It doesn't mean hide characters does it? -not possible)
The others are easy. Erase Screen and Set Cursor are done with a single ASCII command, so easy to add.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
ESC c is defined to do the following: The initial state of a true VT100 is partially determined by the contents of it's non-volatile storage - but your interpretation woud usually be correct - i.e. screen blank, non-inverse, cursor at location 1,1 and the cursor is visible.
And yes, making the cursor visible/invisible only affects the cursor itself, not the character it is on.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
PropCMD v0.061 adds...
"?" to display a list of available commands (FTP not working)
"RUN filename" is equivalent to "SPIN filename".
The binary is attached as well as the source.
BEWARE: Do not delete the old BOOTPROP.BIN, just rename it to something else. You must·NEVER·DELETE A FILE·as this may interfere with ZiCog that relies on the fact that files are contiguous. Then you may copy this file to the card as BOOTPROP.BIN or as it is and leave the old version as is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 zip file contains the sources for ZiCog v167 and has been compiled for 104MHz and uses 1pin TV and 1pin Kbd. I have also included the compiled binary as a separate file.
I have not tested this as yet as I will be away for a few days.
Included in the zip file are two new drivers for the RamBlade...
ZiCog_145.spin
RamBlade_203_005.spin
These drivers correct an SRAM timing problem where I was not holding the data and address after the end of CE & WE (I was disabling the data outputs and CE and WE in the same instruction). While the
hold time is specified as 0, the prop/track/sram timing did not always guarantee this would be met.
I have included the binary file...
ZICOG15A.BIN
This is a binary for ZiCog v150 compiled for the RamBlade with the new drivers using a UART/Terminal connected at 115200 baud. It has been tested.
I have included the binary file...
TEST_RB6.BIN
This is a binary for testing the RamBlade and does not report an error with the later filenames. It also tests some of the SRAM harder. It uses an attached UART/Terminal such as a pc connected at 115200. It has been tested.
Please report any errors here.
The photo is the RamBlade in the new box (red translucent) that I will be using for the new Cluso's Modular Blades, including RamBlade II that I will announce shortly. The existing RamBlades will still be available. The screen is a 4.3" color LCD with 80x25 (ZiCog 1pin TV/Keyboard running) that I purchased on eBay for $25 inc postage (see recent thread). You can just see the edge of the PS2 keyboard on the right of the photo. Man that keyboard is huge!
Z168_1P.BIN
Here is the latest 1pin binary v168 compiled for 6.5MHz(104MHz), NTSC 80x25 mono, PS2 Keyboard...
I've got one of those displays on the way.
What happened to RamBlade2? Did you ever decide if you were going to move the UART back to 31/30?
I have been busy with other things so the pcbs have not been dispatched to production - there are a group of different pcbs to go.
Cluso, yes I downloaded the latest test and ZiCog for the RamBlade, the first output in the text file I attached on the Catalina thread is in fact the output from the latest RamBlade test:
apart from that little difference in pullups readback (which is not on data bus anyway) the boards are still passing this test.
This is the output of Catalina ram test, which used to succeed too until not long ago:
the test (repeated on the same locations) reads back a $22 value (bits 1 and 5 on databus I guess), superimposed to the value that was stored there. Some of the bits are flipping from time to next.
I have tried (at both 100MHz and 80MHz) to insert delays in Catalina access code, to allow more settling time, but it doesn't seem to make much difference.
Have you tried the latest Catalina on your RamBlades? Could you do run a ram test and see the result?
As far as the Ram tests go, the pullup values read back will be different. The tests take care of this and that is why you get a passed message. The sram tests are not exhaustive because I do not check every data pattern per address. I increment the data and the address, so ultimately all values of data and all values of addresses are checked to ensure the hardware wiring is correct (i.e it should test for shorts or opens). However, it is not testing the sram itself for bit errors. Perhaps I will look at this over the w/e.
I note you say you have tried 100MHz and 80MHz. IIRC Ross checks at 100MHz. But remember, I ship the RamBlade with 104MHz (6.5MHz xtal) and a 13.5MHz xtal separately, so I presume you have a 6.25MHz xtal for 100MHz operation. Actually I guess so since you are getting a response from Catalina which does mean it is running somewhat. Does Catalina run without XMM?
At this point it's worth waiting. Meanwhile I'll keep trying, but no worries. I'm sure it will get solved.
Thanks for the info. Yeah I thought the same about the pullpus, as long as the result was "inclusive" it was fine.
Yes it's running without XMM, Catalina compiled as tiny too (just tried fibo.c).
At the moment I have 5MHz on one board and 6.25M on the other.
Using 80MHz to rule out overclocking until it's solved, they both used to run fine at 100MHz.
I prefer 100MHz because I have 6.25 crystal on a couple of other boards, so this way I only have to deal with less variations.
A nice thing that I discovered about newer FTDI drivers is that they work at non standard speeds, so to connect with a program compiled for 6.25M after switching the crystal to 5.0M it is enough to specify 92160 as the serial speed, without recompiling.
Here is the source code and binary for the RamBlade EEPROM. You will need to short the WE link on the pcb and connect the propplug to the programming pins (the center 4 pins on the pcb edge labelled G, R, I, O) - I do this by just putting a 1x2 pin header with a shunt shorting it into the holes and manually keeping pressure on it. Otherwise you can solder pins into it and just put a shunt on it when you want to program it.
PropBootSD_V1_10_RB1 - Archive [Date 2012.06.02 Time 09.52].zip
PropBootSD_V1_10_RB1.binary
However, it seems more likely that the programs on the SD card may be corrupted. Maybe you need to reformat and reload???
There is a test program for the RamBlade that tests all pins and the SRAM. Do you have it?
I'm thinking I want to do CPM over a serial terminal window and try out SuperCalc. Is that doable or do I need composite for that to work? If it will work over serial terminal, what terminal emulation do I need?