Trying to modify the VGA_Text driver.
GilesGoat
Posts: 26
Hi,
yesterday I tried to modify the VGA_Text.spin driver to aim to obtain the VESA 720x400 mode.
If I understood correctly, in the example, the clock is generated 16x via PLL starting from 5Mhz so it's an 80 Mhz clock, however the VGARATE is 1/4
of that so 20Mhz so 50ns per tick.
( cause this line I see here )
vga_rate := clkfreq >> 2
With those assumptions and using a 16x16 matrix I was expecting to get some 45x25 chars thing so I modified the driver as that :
CON
cols = 45
rows = 25
further down I modified the parameters block as this :
vga_params long 0 'status
long 1 'enable
long 0 'pins
long %0001 'mode
long 0 'videobase
long 0 'colorbase
long cols 'hc
long rows 'vc
long 1 'hx
long 1 'vx
long 0 'ho
long 0 'vo
long 406 'hd horizontal display ticks (406)
long 20 'hf front porch
long 40 'hs hor synch
long 60 'hb hor back porch (61)
long 400 'vd
long 1 'vf
long 3 'vs
long 42 'vb
long 0 'rate
Those timings are re-calculated based on this table : http://tinyvga.com/vga-timing/720x400@85Hz
(i.e. for example take 'hd' that - in that table - is ( 1 / 35.5Mhz * 720 ) / 50 ns = 405.6 )
which also states ( tried to change in all combinations anyway ) that hsynch in this case is negative but vsynch is positive.
I was expecting to see "some stuff" on the video and then maybe go and adjust things but all I see is my monitor
just 'complaining' that there's no video signal, I saved that file as "Vga_Text_720.spin" and modified the VGA_Text_demo.spin such as to include
' text : "vga_text"
text : "vga_text_720"
However nothing seems to work .. any idea what am I missing here ?
Thanks in advance for any help.
yesterday I tried to modify the VGA_Text.spin driver to aim to obtain the VESA 720x400 mode.
If I understood correctly, in the example, the clock is generated 16x via PLL starting from 5Mhz so it's an 80 Mhz clock, however the VGARATE is 1/4
of that so 20Mhz so 50ns per tick.
( cause this line I see here )
vga_rate := clkfreq >> 2
With those assumptions and using a 16x16 matrix I was expecting to get some 45x25 chars thing so I modified the driver as that :
CON
cols = 45
rows = 25
further down I modified the parameters block as this :
vga_params long 0 'status
long 1 'enable
long 0 'pins
long %0001 'mode
long 0 'videobase
long 0 'colorbase
long cols 'hc
long rows 'vc
long 1 'hx
long 1 'vx
long 0 'ho
long 0 'vo
long 406 'hd horizontal display ticks (406)
long 20 'hf front porch
long 40 'hs hor synch
long 60 'hb hor back porch (61)
long 400 'vd
long 1 'vf
long 3 'vs
long 42 'vb
long 0 'rate
Those timings are re-calculated based on this table : http://tinyvga.com/vga-timing/720x400@85Hz
(i.e. for example take 'hd' that - in that table - is ( 1 / 35.5Mhz * 720 ) / 50 ns = 405.6 )
which also states ( tried to change in all combinations anyway ) that hsynch in this case is negative but vsynch is positive.
I was expecting to see "some stuff" on the video and then maybe go and adjust things but all I see is my monitor
just 'complaining' that there's no video signal, I saved that file as "Vga_Text_720.spin" and modified the VGA_Text_demo.spin such as to include
' text : "vga_text"
text : "vga_text_720"
However nothing seems to work .. any idea what am I missing here ?
Thanks in advance for any help.
Comments
I just tried to run it, it works.
As I said "I am totally new" so I am also trying to learn a bit, if I understand correctly by a quick look at your driver :
- your drivers runs on 2 cogs
- your system.launch() is someway used to be sure you launch the code on some "cog X" and then a second copy on "X+1", you need them to be two "consecutive" cogs ? ( i.e. if it would be '3' and '7' won't work cause timings ? )
- the 'mailbox' is some ram where you pass params and you wait on mailbox[3] for some synchronized start ?
Very interesting driver, I think I'll fiddle a bit with it trying to see where I can get.
The "redef" method if I am correct is to redefine a char.
I'll see if I can use all this as a "base start" to make a simple "VTxx" emulation
Wow, what a blast from the past. I bough some cosmic "light synthesizer" program for the ATARI ST 520 from Jeff's mum at the PCW show in 1983 or so. Sorry I forget what it was called.
Great times. Hope all is well with you guys.
Sorry for the diversion from technical debate here.
Edit: Must have been Colourspace in 1986. Man my memory is shot away.
Exactly, it's just basic example code to get things going. If you have more questions feel free to ask.
I plant to "merge" a few things together, the idea would be one cog running a serial driver, I've seen/studied the one in the LIB, pretty clever, should do, the only other way it could have been done 'better' maybe via interrupts but should perfectly do the job as it is.
The other thing is to use the PS/2 driver to read a kb, once that "merge all together with some logic to handle the screen".
Your video driver is "complicated", I understand it's a state machine switching between a number of phases ( to generate synch, video and the rest ) but "I need more time to study to digest it".
Maybe I could have this "master plan" where one cog runs the PS/2 "driver", one the Serial port, one the "interpret logic" and two the video, that's more or less the idea.
It's all very good .. really a nice interesting controller, I want to learn a bit more about it before I can say/make a better opinion about it
@Heater ( lightly off topic ) : if it's wasn't Colourspace, it could have been Trip A Tron maybe ? Anyway Llamasoft is more alive than ever, just Google you'll easily find our website, we are all into VR nowadays
Already implemented some basic stuff like :
at (40,12)
str ( string (" This is a test") )
setAttribute ( 1,0,0 )
at (0,13)
str ( string ("Writing in different colour @(0,13) ") )
All simple stuff but learning a bit about SPIN and things ..
By connecting this new serial port and launching the serial driver and putting things together I was able to connect a terminal emulator on this new RS232 port, send chars from a PC and have them printed on the screen. Now I am starting to work a bin on some basic ECMA-48 sequences. Next step will be also to connect a PS/2 KB on the parallax and see if that I manage to send the keyboard codes to the serial port as keys.
Also such a Prop based VT100 terminal would be great to hook up to the UART on the Raspberry Pi for use as the Linux console.
Have a look over here as well. Since then the vt100 object and the VGA driver (80x30) have been updated (check with Oldbitcollector over at http://propellerpowered.com/forum/index.php). I do have the latest source at home as well, so let me know when you can't find it otherwise.
You can have a look at the .ZIP attached which I made/the approach I am taking as I said it's a bit of a learning/fun process to me, I am totally new to this.
The idea is a pretty basic "state machine" which scans the codes and .. does things .. I am still hacking/learning/chopping/debugging stuff. For "simplicity" at the moment still using SPIN, you may have a look to see "the kind of road I took" so far
"Please excuse my naive SPIN code" or such
Ah of course "I claim no (C) and such or whatever" I literally trying to learn and have some fun so take all things just like "a few hours project" .. but I'd be happy if I can make it work OK to be used with my ( bigger project CP/M machine ).
( this one in case you missed it http://www.gilesgoat.com/Yak/FirstRunSBCZ80.jpg )
Anyway there is my .ZIP so far, works with the "demo board" where on P7/P6 I attached a MAX232 and there is the serial port, to test it I send it chars/stuff via another terminal emulator.
[edit] - ah the "Scroll N lines DOWN" does not work yet ( up does ).
Funny enough I never managed to install/configure Wordstar properly .. but I normally use VEDIT for editing programs.
My "biggest hack" so far was to create a special "char translation mode" ( in the CBIOS ) for .. using ZAPL on my system ( with a real VT220 ) where I even done it all by hand a complete APL char set, that was tricky because ZAPL actually seems to support all the "overstrike" modes I wonder if it was actually made to work with a real teletype rather than a video terminal and I kinda supported that as well ( i.e. you type 'C', backspace , 'O' that should give you the "lamp" sign for 'comment' ).
Yes MS Basic works quite well but I like that C compiler ( altough needs more resources ) .. I did try long ago to implement that Z80 Unix/Minix version but I got a bit stuck/frustrated at some point.
Yes, memory is a problem for a Z80 emulator on the Prop. And there in lies a long story...
In years gone by when I discovered the Prop I had the same idea as you. Hey, I have a bunch of 8080 and Z80 chips and I have some tubes of 32K static RAM, the Prop would could make all the required peripherals: Serial port, VT100 screen, disk storage (SD), keyboard....
But then I wanted to learn some Propeller assembler wrangling and started down the road of writing an 8080 emulator as an "exercise". Turns out an 8080 emulation, limited to 16 or 24K HUB RAM on the Prop runs as fast as the original 8080. So was born the old PropAltair project (search the forum).
Then forum members turned up with RAM expansions for the Prop. DrAcular with his DracBlade designs, Cluso99 with his TriBlade and RAM blade designs, Bill Henning with his VMCOG cache memory system...
Before long PropAltair grew into ZiCog, emulating most of the Z80 instruction set and running on the systems mentioned above. That led to running CP/M on the Prop.
The crowning achievement of this I think was "CP/M in a Matchbox" turning up on Hack-a-day: http://hackaday.com/2009/12/27/zilog-in-a-matchbox/
At that point my life got a bit busy and I had no time to carry it forward. Besides I was really wanting to put it on hold until the Propeller 2 turned up....still waiting...
Then forum member PullMoll turned up and in no time at all wrote his own Z80 emulator. Which ended up running CP/M a Spectrum emulator a NASCOM emulator and God knows what else. Search hear for PullMoll qz80.
In the middle of all this the guys building the N8VEM Z80 computer produced a Propeller based peripheral card for their system.
I still dream of going to back to that original plan: Z80, static RAMs, Propeller for VT100 terminal, perhaps another for odd peripherals.
I have had WordStar running on the Propeller. All be it over a serial link to Minicom running on my Liunux PC. Others have done it with Propeller based terminals.
MicroSoft 4K and 8K Basic ran fine on PropAltair with no external RAM.
The BDS C compiler works to.
It was kind of interesting in that when using external RAM for CP/M on the Prop raw execution speed is reduced. But as we are using SD cards instead of floppies all that disk I/O is much faster. All in all you end up with a system as fast as that Intertech SuperBrain machine I used back in 1981.
This is the reason why I seldom talk about what I do unless is "pretty innocent"
I could give you here a "project" that "all you need is to make a PCB, solder the components and have a Z80 system working" with "all you had in mind" in fact that thing in the pic is a "canonical" Z80 system except it has 512 Kb of static ram ( 64K used as ram and the rest as A: ram disk ) a 128K rom with CP/M 2.2 and a mini cp/m disk image containing asm/disasm/ms basic and such .. recently working on another card with a WIZ5100 module and an SD card on it.
Unfortunately I am also "super mega busy" ( with work ) and I tend up to do all this "in waves" .. sometime I can work some month ( of little spare time ) on it, sometime I have to leave it all sitting for many months ..
I am pretty sure someone, somewhere else has probably made "yet another Z80 system" right now
But I don't want to know about it, I just want to finish mine that I started and see where / how it goes
I just got the Propeller ( actually over a year ago I think ) I wanted to have a look at it to learn something about, I tought that making a small VT 100 like emulator could be really useful for my needs and a interesting way to learn things about this CPU.
If I have to say "fully" what I think about Propeller so far is that "it's very interesting for some things" but at the same point "is not what I need for other things" .. it would be "certainly another kind of beast" if it would have some FPU unit aboard .. but then I can also see "it would be all another sort of CPU" and would need also lot more pins and different things, I think it's a bit hard to say but maybe "It's good as it is for what it is, if you'd change it too much you are risking to go into a different world".
I think you have summed up my attitude toward this hobby of ours very well. Fun, curiosity, relaxation, a little learning and "I did it my way". It's all about doing it yourself. I'm sure others here would concur.
However I must say there is a huge added pleasure to be had from the "community" aspect of all this. It's great when, having flown some crazy half baked idea on the inter-tubes, that someone pipes up with a neat idea to make it a bit better or contributes that bit of code you needed but did not want to tackle.
It's great to find out that even just one person can take what you have done and make something fun for themselves out of it.
I also agree with your comments about the Propeller. I love it for it's unique and "holistic" design. The result of one man's vision.
Over the years there has been a lot of discussion about all the wonderful features a new Propeller should have. Many of those suggestions miss the point that if a Prop had or did what was suggested it would no longer be a Prop. There is no point in morphing a Propeller into yet another SoC like ARM or MIPs.
The Prop is a classic design. Like the 555. It has it's limitations but it is what it is and it is great at that.
PS: Is there any vt100 compatible server library written in SPIN+PASM? I want to use PuTTY to configure, control and interact with Propeller "supermegamachine".
So far .. "interrupted by a terrible cold"
That was an interessting VGA driver. I`ve just tested it and it looks great. Thanks.
Q: Do you know if anyone has made something similar high resolution version of the TV.Text.spin??
I would love to be able to put out more text pr page at the TV.screen at my "main station". I don`t even know if it`s possible.., do you?
while struggling to cope with a really really bad cold I've done a bit of more coding/stuff on this too.
I found a document from 1984 "Summary of ANSI standard for ASCII terminals" that in an appendix in the end lists the minimal MUST-SUPPORT things for a VT-100 terminal compatible
sorted in 5 different classes ( of increased complexity ) I am getting close to be "to class 5".
Tried to understand a bit the video driver .. "in principle I get it" .. but NOT in the details .. it's really quite a complex bit of code I am really not fully grasping it right now.
Implemented a sort of SW Cursors, it's not "super" but what it does it's basically sets 'the cursor pos' to a "reverse video + flash" .. problem is a white space ( $20 ) just shows a steady block, still, it's a cursor.
I am testing/comparing my implementation with TeraTerm Pro as in I sent it the same escape sequences and I check "mine does the same", it actually helped me to debug some stuff that happens when you set a different scrolling region ( i.e. ESC [ start ; end r ), there's behaviour that changes about newline, cursor movement and other things.
Searching around I found out about this interesting utility, that I will see if I'll manage to compile on Ubuntu ( or find a package that already has it ) : http://invisible-island.net/vttest/vttest.html
it's an utility designed to test VT emulators and tell you "how close you are to the real thing".
Some thing would be nice - for this purpose, NOT saying that "could be useful for a general display driver" ( in fact as it is I think it's pretty nice as it is ) - would be if the video driver :
- would have maybe another 80x25 "extended" attribute map ?
- would have a cursor that you can turn on/off and would 'flash' reversing paper/ink
- could do an 'underline' by setting $ff to the last line of the char if enabled
- could be able to do double width/height chars ( by duplicating pixels and skipping one char / line of chars )
I am just saying "would be nice if" I am NOT saying "should be done" or who should be doing it, maybe one day in the future when I'll understood things better it could be me trying to do that.
But for the moment back to ANSI, getting close to have all "1 .. 5" covered
[1L Insert blank line at current row (shift screen down)
[1M Delete the current line (shift screen up)
All the others are in and seems to work, including "insert mode" ( [4h [4l ).
There are still quite a few sequences I want to implement but so far I am quite happy
What you are doing is the way to learn and remember. Nothing like trying it yourself. When you need help, or even just a way to do something, or to get some opinion on the way you have done something, just ask.
Most of us here are doing it for the fun of it. Some of us have commercial projects too - some we can talk about and some we cannot.
There were all sorts of quirks (from different implementations of VT100), particularly when the characters run off the end of the line onto the next. Lots of software in those days avoided these traps.
As for cursor flashing or whatever, you may be interested to look at what I did in the 1-pin TV driver (IIRC its in the debug section of the obex). Basically I used a counter of screen frames to determine when to display the cursor position normally and when to display an alternative (could be inverse, could be underline, or anything else).
that video driver that Kuronkeo done ( for me now ) is quite a bit complex to understand, I understand it's a sort of state machine where in turns generates various bits/timings to generate vsynch/hsynch/or put pixels out, I also kinda understood that he uses a 8x16 font and puts 1 blank 9th pixel, it seems to me it uses a that jmpret to switch states/bits of code quite a few times, I am not 100% sure but I think that he has "a number of sub states/different routines" that get called to output different parts of the same char, got the impression that at some point he first prepares 'a list of pixels" to put out and then does it.
At some point I guess I'll try some "simple video experiment generations" my own maybe I'll understand a bit better how those video drivers work.
Well as I am saying I am "testing" my implementation so far comparing it with another VT100 "pro" emulator .. also .. "worse to worse" .. I don't have a VT100 BUT I DO HAVE a real VT220 here I could check as well
There is/was the story of autowrap / no autowrap but I very rarely seen the no-autowrap being used.
I do remember well - and that's something I did not see in any emulator so far - that VT100 had the "smooth scroll" mode and can't remember if it was the VT220 or the VT340 that had the story of "the scrolling window" where actually the "screen" was like two pages and it was possible to "roll" around them.
Anyway last terminal I ever used was a VT340, we had quite a number in our old "lab" .. eeeh those were the times of OS9 ( Microware OS9 ) and VME machines and of course the never-to-be-missed VAX/VMS ( Microvax ).
I'll go on a bit more with all this in the next days
Really ?
The source says this :
'' long[par][2]: [!Z]:addr = 16:16 -> zero (accepted) cursor location (?n) unused
I see there's that 'locn' but it does not seem to be used for anything.
I am using your 80x25 dual cog driver version '' 20140916 " checking all the driver I cannot really see anything that would support/do a cursor ???
[edit] - I don't understand .. have you changed that link ?
It seems what I downloaded was a "Archive 2014 9/16 Time 15.26" and in fact has NO support for cursor.
This one is "Archive 2014 9/20 Time 15.26" and is a bit different.
Don't know how I got that first one then .. anyway thanks, I'll try to replace it and see how it goes
"Let's try this cursor" .. block + flash ... OMG ! It's TOO FAST MY EYES MY EYES !
Took me a little but I had to change those two lines as this
' cmpsub fcnt, #36 wz ' N frames per phase (on/off)
cmpsub fcnt, #64 wz ' N frames per phase (on/off)
and this
' if_c cmp fcnt, #18 wc
if_c cmp fcnt, #32 wc
That flashing rate was making me go insane.
Now "the weird thing" is "these are words coming from the guy that tried to play some game on Oculus DK2 at 220 Frames Per Second or higher shouting 'Give me more ! Give me more! " .. " .. but when it comes to "read text on a terminal and flashing cursors" it's all another matter.
I'll spare you here "infinite discussions" we had somewhere on other forums about things like "best font for a console", "best palette", "best monitors" and "they don't make those BW CRTs any more or those VT340 amber screens or" ...
Cracking job man anyway ... .... "... but the cursor speed .. " ..
Now if I understood correctly, according to some docs, "this sets the region" .. ok .. FINE .. BUT what it's not "super clear" is the following.
Region should be "ON" by setting ESC [ ? 6 h and "OFF" via ESC [ ? 6 l .. calling ESC [ top; bottom r I *THINK* should change the region BUT NOT "automatically" set it to "ON" after that ?
Also some documents seems to say that as soon as you change/set the region ( assuming is "ON" ) the cursor should go into the NEW "home" position and when you put it "OFF" then again you are working in the "full screen" so the cursors should go to the HOME position 1,1
But I *THINK* as long as region is "OFF" changing the region should not alter anyting ( until you make an "ON" again ) ?
I found a quite strange behavior in Teraterm PRO with the region and I don't think it's correct, when you do an ESC [ top; bottom r it sets the region but it's like "partially on/off" .. you cannot move the cursor out if it it you go inside it but you can still move/position the cursor all around.
According to other documents I found I think "this should not happen", the moment the "region" is "ON" what should happen is :
- cursor cannot move out of the region
- all positioning like ESC [ col; row H/f is now relative to the region origin ( i.e 1,1 goes whatever line the region is )
- cursor positioning as well is relative to that
- scroll and such is confined to that
There's no such a thing as "half on" like Teraterm does, I think it's doing it wrong, all seems to go fine anyway when I set ON/OFF via ESC ? 6 h/l