* Read or write a byte to the 64k ram. This is used by Z80 instructions, eg LD A,(nnnn) loads register A with the byte at nnnn (0000 to FFFF). This type of read/write is random access and buffering is unlikely to be helpful as the bytes will not be contiguous.
* Read or write bytes to disk. This is done in 128 byte blocks, with a high probability that blocks are contiguous, so buffering is likely to be helpful.
Cluso, when you say that the bytes go via the hub ram, is that referring to random memory read/writes or disk read/writes or both?
Addit: I'm deep inside this code trying to get a board working that does vga/keyboard and the zicog all on one board. I've got pins 0-7 as a data bus and the sd card on some different pins. I guess each application (hydra etc) might need custom drivers. It is helpful to know the memory access code comes up both in a specific driver (the triblade.spin driver) and also in the zicog code itself. I'm still pondering ways of maybe making the process of porting to different pinouts easier.
Drac: The Z80 instructions execute byte access to ram and this is within the cog so transfer is ram to/from cog and occurs once as a subroutine in ZiCog. The TriBlade block driver as used in the disk section of CPM goes via hub. This is because the SD driver lives in a different cog to the TriBlade driver. It may be possible to combine these and go direct, but remember, we also are deblocking the SD as it reads 512 bytes, so chances are often the SD read will already be in hub, so actually a transfer from hub to ram is required. It is also my intention to expand the TriBlade driver to implement the Z80 block moves as this would be much faster than the current method.
However, all these improvements can wait. Have to get RamBlade off to mfr, then fix the bug I have with getting fsrw24 running - had a thought - if you get time can you recompile with #define fsrw_new (something like that) and try? I recall, I have changed my xtal to 6MHz and I know lonesock said he is on the limits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hey fellas, is there a version of any of this that can run on an unmodified demo board and contains any software that could be used on a VT100 serial terminal?
Alternatively I've got a Proto-board with an SD socket strapped to it, but like the Demo board it has no external ram.
Firstly, I'm simply interested in watching it work. But secondly, I've gone a bit into adding VT100 emulation into bst. I'm testing it using vttest over a loopback serial connection, and I've got quite a bit of functionality happening. I'm starting to wonder just how much of the VT100 I need to emulate, as none of the terminal emulation code I've seen you using seems to implement scroll windows, movable margins, programmable tabstops, multiple charsets and some of the more complex fluff.
vttest is complete torture and does a very good job of showing up bugs in the implementation. I just wonder if I need to go as far as I'm going to have a usable serial terminal.
The biggest limitation I have is no character attributes (bold/strikethrough/underline) and no colour support, but I've got 80/132 Col mode, full cursor/scroll movement and all the basic commands working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Yes Brad, download the latest code (on the TriBlade forum at the end) IIRC its v _rr126.
Change the #define to PropDemo (I think thats what it is called) and set the SD pins correctly. It should compile - if anything is missing let me know. You only get 21KB of ram though. But hey, it works and that was a luxury many years ago
Just not sure if you need another SD file - IIRC I think I fixed that to use the curent SD files because I have run it without using the ram on TriBlade.
email me cluso at bluemagic dot biz if any problems
Wordstar seems to use only a small subset of the VT100. Ignore the attributes and colors for starters. Cursor positioning was the biggest use and insert/delete line (scrolling) as well. Bold and underline were the 2 I recall most used in atributes.
I have added the following comments to VT100 code Dracula posted·recently after looking at the code and also the VT100 specs.
'VT100 code as posted by Dr_Acula 20091016
'Believed to be from OBC's original code
'
' RR20091016 _rr001 simplify & add case statements
'------------------------------------------------------------------------------
' VT100 codes (ignore blanks)
' Esc D scroll down <--- linefeed
' Esc E <--- newline
' Esc L scroll down
' Esc M scroll up
' Esc c clear screen & reset terminal
' Esc r
' Esc [noparse][[/noparse] {val} @ insert spaces
' Esc [noparse][[/noparse] {val} A cursor up
' Esc [noparse][[/noparse] {val} B cursor down
' Esc [noparse][[/noparse] {val} C cursor right
' Esc [noparse][[/noparse] {val} D cursor left
' Esc [noparse][[/noparse] {{row} ; {col}} H cursor home/position
' Esc [noparse][[/noparse] {val} J clear screen 0/none=from cursor, 1=to cursor, 2=line
' Esc [noparse][[/noparse] {val} K clear line 0/none=from cursor, 1=to cursor, 2=line
' Esc [noparse][[/noparse] {val} P delete spaces
' Esc [noparse][[/noparse] ? 1 ; Ps c Ps=0 for VT-100 no options
' Esc [noparse][[/noparse] {row} ; {col} ; f cursor home/position
' Esc [noparse][[/noparse] {opt} h enable option \ 7=auto newline wrap, 20=cr+lf
' Esc [noparse][[/noparse] {opt} l disable option / 7=no line wrap , 20=cr
' Esc [noparse][[/noparse] {{att} ; {att} ..} m attributes.. 0=reset all, 30=black (foreground), 40=black (background)
' 1=bright , 31=red 41=red
' 2=dim , 32=green 42=green
' , 33=yellow 43=yellow
' 4=underline, 34=blue 44=blue
' 5=blink , 35=magenta 45=magenta
' , 36=cyan 46=cyan
' 7=reverse , 37=white 47=white
' 8=hidden ,
' Esc [noparse][[/noparse] r scroll enable
' Esc [noparse][[/noparse] {start} ; {end} r scroll
'------------------------------------------------------------------------------
' WYSE codes (ignore blanks)
' Esc ; cls (clear screen)
' Esc * cls (clear screen)
' Esc =
' Esc = row col move cursor
' Esc .
' Esc . 0 cursor on/off
' Esc . 1 cursor on/off
'------------------------------------------------------------------------------
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Yes Brad, download the latest code (on the TriBlade forum at the end) IIRC its v _rr126.
Change the #define to PropDemo (I think thats what it is called) and set the SD pins correctly. It should compile - if anything is missing let me know. You only get 21KB of ram though. But hey, it works and that was a luxury many years ago
Not to be too much of a pain in the bottom, but..
zicog_cpm_rc5.5b_rr126(330,14) Error : Unable to locate object
UART : "FullDuplexSerial_rr004" 'FDX v1.2 with mods
_____________^
Have you made changes significant enough to preclude me for just using the standard FDX?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad: Was the modified FDX·not in the zip file ? Postedit: Oops, not included :-(
Here it is and the changes are documented at the beginning - only minor·- cr+lf issue, variable buffer size (not required) and a few calls to be compatible with other drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Don't worry about it. The current code is very much tied to the triblade if you want to use a formatted SD card.
Interestingly it would not even mount the 128M MMC I tried to use first.
I don't need help testing the VT100 aspect. I'm using it as a linux terminal and beating it with VTTest. That provides a more than adequate test frame. I'll just make sure I've got the functionality all the current prop based terminal emulators have covered (excepting colour of course).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
No you can use a formatted SD card on ZiCog running on a DemoBoard as well. With the complication that one has to first find the starting blocks of all the files using a program Cluso made (can't remember it's name just now) and then edit zicog_cpm.spin to tell it those start block numbers. Still not going to help you much.
Are you saying that this terminal can be built and run as a stand alone Linux VT100 terminal emulator? If so I'd love it if would release it as such for use as a console with the SIMH AltairZ80 emulator with I/O from stdin/stdout.
I've been search around for VT100 emulators for Linux and there does not seem to be anything except minicom and some old X Windows thing. For SIMH they recommend telneting to the emulatoir to run WordStar.
What, no colour? I though it was to be green on green [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
No you can use a formatted SD card on ZiCog running on a DemoBoard as well. With the complication that one has to first find the starting blocks of all the files using a program Cluso made (can't remember it's name just now) and then edit zicog_cpm.spin to tell it those start block numbers. Still not going to help you much.
Are you saying that this terminal can be built and run as a stand alone Linux VT100 terminal emulator? If so I'd love it if would release it as such for use as a console with the SIMH AltairZ80 emulator with I/O from stdin/stdout.
Actually, I hadn't planned on it, no. But now you mention it that is how I'm testing. I've written a very simple shell around the terminal component and it's basically just a one trick pony.
So, yes I will happily release it as a separate, stand alone program if you'd find it useful. In fact, I can use that for the beta testing so I don't keep having to do pre-release builds of bst while people test the terminal emulator.
hrm.. stdio support too? I'll have to think about how I might do that cleanly, but anything is possible I guess.
If you send me a configured & working SIMH tarball I'll do some work on it.
That also nicely solves the problem of me not being able to run stuff on my Props..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Not sure how far you want to go with this.
On the one hand a stand alone VT100 terminal emulation talking through a regular serial port would be just great.
Not sure how one would get it to work as a shell to run SIMH AltairZ80 or other progs in. Maybe you could borrow some ideas from GTKTerm or such.
Either way a full screen mode with 80 columns of big green on green "dotty" text would be the bees knees.
It's best to get the SIMH Alatir Z80 tarball from the SIMH site www.schorn.ch/cpm/intro.php. Nothing to configure just download one of the "Quick Start for Running CP/M" tarballs.
On that page you will also find a WordStar tarbal and Vedit package that is configured for VT100. Again nothing much to configure the AlatirZ80 config files are included in each package.
Hmm...I just downloaded the WordStar package again and find that it seems to work quite well in a normal Linux console window (Konsole). Could have sworn I didn't have any luck with that a long time ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Spoke to soon. "Quite well" for WS on Konsole above is until you hit the cursor keys.
Are you sure WS responds to VT100 cursor keys? I can find no reference to Wordstar ever responding to VT100 cursor key sequences.
I seem to recall the cursor keys on my old CP/M Bondwell laptop were mapped to the Wordstar cursor control codes.
It would be easy enough to have an emulation switch to allow flicking the cursor keys back and forward. In fact the VT100 had a soft option for that the application could
set.
heater said...
You are right. It's just that I thought I remembered the Intertec SuperBrain I used a long time ago had cursor keys. I guess they were mapped to WS.
Thinking about how to connect your VT100 terminal to SIMH. Well SIMH has a configuration command that causes it to listen to a socket for serial I/O.
ATTACH SIO 23
Where 23 is the telnet port but it will take any port number there. This command can be put in the start up config file.
So your terminal need only connect to that port instead of a serial device.
Yeah, that's how I was testing WS for ANSI cursor sequences. It's something to play with in any case.
I honestly think xterm does quite a good VT102 emulation, so really if simh is misbehaving in there it's probably an application not coping with VT100 sequences (like WordStar). In any case, I now have a way of testing my terminal compliance against random CP/M applications. Thanks [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Yes, of course, the SIMH is great for testing codes. It looks like you already have this working, but if not, pls let me know as I have already written this sort of code. I've got a batch file called AltairTelnet which you just double click. It contains just one line
altairz80 telnet
And the file 'telnet' (no extension) is:
set console telnet=23
d tracks[noparse][[/noparse]0-7] 254
attach dsk cpm2.dsk
attach dsk1 basic.dsk
attach dsk2 games.dsk
attach dsk3 sbasic.dsk
attach dsk4 bdsc160.dsk
attach dsk5 tools.dsk
attach dsk6 wordstar.dsk
attach hdsk i.dsk
set cpu 64k
set cpu noitrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
set sio ansi
set sio nosleep
boot dsk
bye
(remove the unwanted disk images if not needed)
Doubleclick the batch file and it runs and sits there waiting for a telnet connection:
C:\N8VEM\AltairSIMH>altairz80 telnet
Altair 8800 (Z80) simulator V3.7-3 build 1016 (scp created Apr 20 2008 at 13:01:
09 with gcc 4.2.3)
Listening on port 23 (socket 1932)
Waiting for console Telnet connection
Waiting for console Telnet connection
Waiting for console Telnet connection
Running
The connection was made when I then ran Hyperterminal and connected with TCP/IP (leave the host address blank).
Hopefully you already have a telnet connection from within BST etc (I've done it from vb.net but that wouldn't be much use except to show that it can be done).
Have I misinterpreted some of the planned moves that the hardware has/will take? I had an add on sort of board that was a twin ram blade2, but it did strange things on the ram tests etc and as things seemed to buzz out ok, I just took the plunge and built up another one. This one is single 512Kb rammed but I am now wondering if the reduction in ram was just your ramblade card (which I suspect is wired differently). Is the ramdrive still going to continue and if so how big
I could piggy back the extra ram and route the /CE's as per your early mod, style and grace ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: I only wired 1x512KB when I built my replacement TriBlade. It is the TriBlade #2 circuit with the -OE modification and latch fitted. Since I am no longer using the 1MB (originally used for RamDisk before SD card was running). We will require 256KB IIRC for banking for CPM3 although there is a non-banked version that I had running.
RamBlade will only have 1x512KB capability and has a different hardware spec/connection.
I am still planning to get the RamDisk running utilising whatever ram memory is available and it will be write-through which means writes will also go to the SD card if the data changes, meaning the SD will always be up to the ram disk. However, this is low on the priority list.
I discovered there was an error in the memory testing program originally published. Look backwards in the TriBlade thread for the newer memory test. IIRC it only checks the lower 512KB ram. Make sure you have the correct -CE connected for the lower ram (pin 17 of the latch).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks for the instant reply. I am now still slightly confussed as to the /OE mod ( not, as I said, the /CE, which does go to latch(17)). I have it decked, but with pads waiting in case it has to be modded. It still has the full size SD and is 3.2" x 3.4" single sided, wire links, ironed on toner ....
A condenced down thread printout would be so wonderful, but .... what a job to do!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 10/24/2009 3:01:35 PM GMT
heater: Here is a version of ZiCog that saves an additional 8 longs and should be marginally faster as well. There were only 2 spare longs·in the TriBlade version.
I thought it would be more relevant to be posted here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Z80 bits into overlays is OK, not much impact on us CP/M running guys.
If 8080 bits have to go into overlays (DAA aside) we should start to think about a better way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: There are two types of memory fetching (reading). One is the instruction fetch using pc as the address, and the other is fetching data which may be anywhere. Just thinking, a special routine for instruction (and following arguments) would be simple and could increment the pc for free (during the nop) and save having to move from the pc location. Just a thought? Any comments? for after v1.0 of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Heater: Thanks for your insight. I think that the code space would come from the sections that move the pc to the temp address, and then after fetching, increment the pc. This would be accomplished within the subroutine so I think that the instructions saved will compensate for the extras used. Anyway, time will tell.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Using pins 0..7 helps too, ·but most have the SD card on 0..3
Thanks· Antoinie
I have only had the HX512K card for a few days, so I am still getting my head around the driver.
Post Edited (Ron Sutcliffe) : 10/20/2009 10:44:37 PM GMT
* Read or write a byte to the 64k ram. This is used by Z80 instructions, eg LD A,(nnnn) loads register A with the byte at nnnn (0000 to FFFF). This type of read/write is random access and buffering is unlikely to be helpful as the bytes will not be contiguous.
* Read or write bytes to disk. This is done in 128 byte blocks, with a high probability that blocks are contiguous, so buffering is likely to be helpful.
Cluso, when you say that the bytes go via the hub ram, is that referring to random memory read/writes or disk read/writes or both?
Addit: I'm deep inside this code trying to get a board working that does vga/keyboard and the zicog all on one board. I've got pins 0-7 as a data bus and the sd card on some different pins. I guess each application (hydra etc) might need custom drivers. It is helpful to know the memory access code comes up both in a specific driver (the triblade.spin driver) and also in the zicog code itself. I'm still pondering ways of maybe making the process of porting to different pinouts easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 10/20/2009 11:29:00 PM GMT
However, all these improvements can wait. Have to get RamBlade off to mfr, then fix the bug I have with getting fsrw24 running - had a thought - if you get time can you recompile with #define fsrw_new (something like that) and try? I recall, I have changed my xtal to 6MHz and I know lonesock said he is on the limits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Alternatively I've got a Proto-board with an SD socket strapped to it, but like the Demo board it has no external ram.
Firstly, I'm simply interested in watching it work. But secondly, I've gone a bit into adding VT100 emulation into bst. I'm testing it using vttest over a loopback serial connection, and I've got quite a bit of functionality happening. I'm starting to wonder just how much of the VT100 I need to emulate, as none of the terminal emulation code I've seen you using seems to implement scroll windows, movable margins, programmable tabstops, multiple charsets and some of the more complex fluff.
vttest is complete torture and does a very good job of showing up bugs in the implementation. I just wonder if I need to go as far as I'm going to have a usable serial terminal.
The biggest limitation I have is no character attributes (bold/strikethrough/underline) and no colour support, but I've got 80/132 Col mode, full cursor/scroll movement and all the basic commands working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Change the #define to PropDemo (I think thats what it is called) and set the SD pins correctly. It should compile - if anything is missing let me know. You only get 21KB of ram though. But hey, it works
Just not sure if you need another SD file - IIRC I think I fixed that to use the curent SD files because I have run it without using the ram on TriBlade.
email me cluso at bluemagic dot biz if any problems
Wordstar seems to use only a small subset of the VT100. Ignore the attributes and colors for starters. Cursor positioning was the biggest use and insert/delete line (scrolling) as well. Bold and underline were the 2 I recall most used in atributes.
I have added the following comments to VT100 code Dracula posted·recently after looking at the code and also the VT100 specs.
'VT100 code as posted by Dr_Acula 20091016 'Believed to be from OBC's original code ' ' RR20091016 _rr001 simplify & add case statements '------------------------------------------------------------------------------ ' VT100 codes (ignore blanks) ' Esc D scroll down <--- linefeed ' Esc E <--- newline ' Esc L scroll down ' Esc M scroll up ' Esc c clear screen & reset terminal ' Esc r ' Esc [noparse][[/noparse] {val} @ insert spaces ' Esc [noparse][[/noparse] {val} A cursor up ' Esc [noparse][[/noparse] {val} B cursor down ' Esc [noparse][[/noparse] {val} C cursor right ' Esc [noparse][[/noparse] {val} D cursor left ' Esc [noparse][[/noparse] {{row} ; {col}} H cursor home/position ' Esc [noparse][[/noparse] {val} J clear screen 0/none=from cursor, 1=to cursor, 2=line ' Esc [noparse][[/noparse] {val} K clear line 0/none=from cursor, 1=to cursor, 2=line ' Esc [noparse][[/noparse] {val} P delete spaces ' Esc [noparse][[/noparse] ? 1 ; Ps c Ps=0 for VT-100 no options ' Esc [noparse][[/noparse] {row} ; {col} ; f cursor home/position ' Esc [noparse][[/noparse] {opt} h enable option \ 7=auto newline wrap, 20=cr+lf ' Esc [noparse][[/noparse] {opt} l disable option / 7=no line wrap , 20=cr ' Esc [noparse][[/noparse] {{att} ; {att} ..} m attributes.. 0=reset all, 30=black (foreground), 40=black (background) ' 1=bright , 31=red 41=red ' 2=dim , 32=green 42=green ' , 33=yellow 43=yellow ' 4=underline, 34=blue 44=blue ' 5=blink , 35=magenta 45=magenta ' , 36=cyan 46=cyan ' 7=reverse , 37=white 47=white ' 8=hidden , ' Esc [noparse][[/noparse] r scroll enable ' Esc [noparse][[/noparse] {start} ; {end} r scroll '------------------------------------------------------------------------------ ' WYSE codes (ignore blanks) ' Esc ; cls (clear screen) ' Esc * cls (clear screen) ' Esc = ' Esc = row col move cursor ' Esc . ' Esc . 0 cursor on/off ' Esc . 1 cursor on/off '------------------------------------------------------------------------------▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 10/21/2009 7:43:01 AM GMT
Not to be too much of a pain in the bottom, but..
Have you made changes significant enough to preclude me for just using the standard FDX?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Here it is and the changes are documented at the beginning - only minor·- cr+lf issue, variable buffer size (not required) and a few calls to be compatible with other drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 10/21/2009 7:59:47 AM GMT
You could knock up a quick Spin prog to throw some of these files at the terminalartscene.textfiles.com/vt100/ or these www.textfiles.com/art/
Doesn't really answer the question about what subset of VT100 we actually need though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Interestingly it would not even mount the 128M MMC I tried to use first.
I don't need help testing the VT100 aspect. I'm using it as a linux terminal and beating it with VTTest. That provides a more than adequate test frame. I'll just make sure I've got the functionality all the current prop based terminal emulators have covered (excepting colour of course).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Are you saying that this terminal can be built and run as a stand alone Linux VT100 terminal emulator? If so I'd love it if would release it as such for use as a console with the SIMH AltairZ80 emulator with I/O from stdin/stdout.
I've been search around for VT100 emulators for Linux and there does not seem to be anything except minicom and some old X Windows thing. For SIMH they recommend telneting to the emulatoir to run WordStar.
What, no colour? I though it was to be green on green [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually, I hadn't planned on it, no. But now you mention it that is how I'm testing. I've written a very simple shell around the terminal component and it's basically just a one trick pony.
So, yes I will happily release it as a separate, stand alone program if you'd find it useful. In fact, I can use that for the beta testing so I don't keep having to do pre-release builds of bst while people test the terminal emulator.
hrm.. stdio support too? I'll have to think about how I might do that cleanly, but anything is possible I guess.
If you send me a configured & working SIMH tarball I'll do some work on it.
That also nicely solves the problem of me not being able to run stuff on my Props..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Looks like I need ZIBOOT.COM to compile _rr126 even for Demo board. Only boot #define option in the Zilog.spin is *Boot from SD*
Not sure where to find the file.
I just want to get Zicog up to play with my 64K driver code. maybe I should go back to V 0.05
I will use V0.05 to play with the HX512 driver
Ron
Post Edited (Ron Sutcliffe) : 10/21/2009 10:36:54 AM GMT
On the one hand a stand alone VT100 terminal emulation talking through a regular serial port would be just great.
Not sure how one would get it to work as a shell to run SIMH AltairZ80 or other progs in. Maybe you could borrow some ideas from GTKTerm or such.
Either way a full screen mode with 80 columns of big green on green "dotty" text would be the bees knees.
It's best to get the SIMH Alatir Z80 tarball from the SIMH site www.schorn.ch/cpm/intro.php. Nothing to configure just download one of the "Quick Start for Running CP/M" tarballs.
On that page you will also find a WordStar tarbal and Vedit package that is configured for VT100. Again nothing much to configure the AlatirZ80 config files are included in each package.
Hmm...I just downloaded the WordStar package again and find that it seems to work quite well in a normal Linux console window (Konsole). Could have sworn I didn't have any luck with that a long time ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Are you sure WS responds to VT100 cursor keys? I can find no reference to Wordstar ever responding to VT100 cursor key sequences.
I seem to recall the cursor keys on my old CP/M Bondwell laptop were mapped to the Wordstar cursor control codes.
It would be easy enough to have an emulation switch to allow flicking the cursor keys back and forward. In fact the VT100 had a soft option for that the application could
set.
www.groupsrv.com/computers/about105937.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thinking about how to connect your VT100 terminal to SIMH. Well SIMH has a configuration command that causes it to listen to a socket for serial I/O.
ATTACH SIO 23
Where 23 is the telnet port but it will take any port number there. This command can be put in the start up config file.
So your terminal need only connect to that port instead of a serial device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yeah, that's how I was testing WS for ANSI cursor sequences. It's something to play with in any case.
I honestly think xterm does quite a good VT102 emulation, so really if simh is misbehaving in there it's probably an application not coping with VT100 sequences (like WordStar). In any case, I now have a way of testing my terminal compliance against random CP/M applications. Thanks [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
And the file 'telnet' (no extension) is:
(remove the unwanted disk images if not needed)
Doubleclick the batch file and it runs and sits there waiting for a telnet connection:
The connection was made when I then ran Hyperterminal and connected with TCP/IP (leave the host address blank).
Hopefully you already have a telnet connection from within BST etc (I've done it from vb.net but that wouldn't be much use except to show that it can be done).
Run wordstar from your terminal program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I could piggy back the extra ram and route the /CE's as per your early mod, style and grace ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
RamBlade will only have 1x512KB capability and has a different hardware spec/connection.
I am still planning to get the RamDisk running utilising whatever ram memory is available and it will be write-through which means writes will also go to the SD card if the data changes, meaning the SD will always be up to the ram disk. However, this is low on the priority list.
I discovered there was an error in the memory testing program originally published. Look backwards in the TriBlade thread for the newer memory test. IIRC it only checks the lower 512KB ram. Make sure you have the correct -CE connected for the lower ram (pin 17 of the latch).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Thanks for the instant reply. I am now still slightly confussed as to the /OE mod ( not, as I said, the /CE, which does go to latch(17)). I have it decked, but with pads waiting in case it has to be modded. It still has the full size SD and is 3.2" x 3.4" single sided, wire links, ironed on toner ....
A condenced down thread printout would be so wonderful, but .... what a job to do!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 10/24/2009 3:01:35 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I thought it would be more relevant to be posted here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Beyond that I think it is putting some of the other resident Z80 bits into overlays too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
If 8080 bits have to go into overlays (DAA aside) we should start to think about a better way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wherever you stash your Z80 bit it will still run so much more elegently.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Random BYTE read.
Random BYTE write.
Random WORD read.
Random WORD write.
Instruction BYTE read (auto incrementing PC).
All of which would be nice optimizations. I have always put them out of my mind as we have precious little space to put them.
I would add to this list:
Instruction WORD read (with PC = PC + 2).
This is for use in jumps and calls which there tends to be a lot of.
Where are we to put all this code ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
- DemoBoard support has been stripped out
- microSD files attached - they must be contiguous!
heater: Perhaps you could·check this out on your TriBlade with·the EXZ80 tests?bst is required to compile
Drac:·Perhaps you could check this out on your TriBlade·with Wordstar? There is some N8VEM I/O left in there - presume this should remain?
I will produce a release candidate for V1.0 (DemoBoard version) hopefully tomorrow - done, see later post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 12/3/2009 9:59:38 AM GMT