POC VERSION TWO

[BigDumbDinosaur]

BigEd wrote:

Well, it's clearly built as a graphics display. A nice mail asking for an enhancement might be the thing.

But as for the cursor, isn't this what XOR cursors were invented for? You don't need to map the damage, you just re-apply.

You're correct in that regard. Using Commodore's VIC as an example, which lacked a hardware cursor, the kernel merely XORed the character under the cursor to produce the illusion of a cursor. Bit 7 of the screen code determined if the character was in foreground or reverse mode, so the IRQ handler could simply toggle bit 7 at whatever rate the cursor was supposed to flash. If a static cursor was to be displayed, bit 7 was set and remained so until the cursor was moved to a different location on the screen.

However, the Commodore kernel was directly manipulating display RAM, which can't be done with the Picaso µVGA-II SGC module. The Picaso has several functions for writing characters to the display but none for later reading back what was written at any given screen coordinate. Hence a display map in RAM would be required that would be a "shadow" of the screen contents. In fact, two such maps would be required, one for the character data and another for character attributes. Nearly 4K of RAM would have to be allocated for this purpose. Complicating matters, a way to write to the module during the IRQ without messing up foreground activity would be required.

It all comes down to just how much time and system resources am I willing to consume just to achieve one function. If I'm going to go through that much trouble just to have an interactive cursor I might as well use a video display controller with dedicated video RAM, where I'd have even more control. However, this is a lot to bring to bear just for a basic console that will always operate in character mode.

[BigEd]

Hmm, it does look as if there's no XOR mode: there's a command to draw a rectangle, but not to xor it into the frame buffer. That does point to holding a character array model on the host side (if aiming for a character display)
Cheers
Ed

[BigDumbDinosaur]

BigEd wrote:

Hmm, it does look as if there's no XOR mode: there's a command to draw a rectangle, but not to xor it into the frame buffer. That does point to holding a character array model on the host side (if aiming for a character display)

Correct. I'm not willing to commit the RAM that would be required to map the display character-by-character. It's fairly clear that the Picaso µVGA-II SGC module was not meant for interactive use, other than touch screens. It certainly wouldn't do very well in an application like a text editor, where the cursor would be moved all over the place. Plus there's no functions for scrolling the screen. Once you get into the realm of writing code to do all this you're way off-track. I might as well use some sort of video display controller if I'm going to go to such lengths to generate a text display.

[whartung]

BigDumbDinosaur wrote:

Plus there's no functions for scrolling the screen. Once you get into the realm of writing code to do all this you're way off-track.

Having written such code, it's not really a big deal. It's pretty simple code. Blinky cursor, scrolling, the whole thing.

Save for the most simple of applications on consoles (i.e. a serial console), you will likely need an addressable buffer representing the display anyway. For example, a text editor needs to know what its internal buffer looks like as well as what the screen is supposed to look like so that it can properly represent the text on the display. A line that's 100 characters has a different representation in memory and on the screen (on screen it could be wrapped, or clipped, or wrapped with a special character to show line wrap, etc.). The program needs to know how the screen looks so it knows how to update it.

When the video display is memory mapped, then that representation can be shared with the display (like on a C64 or whatever). If not, like on a machine with a serial terminal, it has to have its own internal buffer. The overall point being that, for many cases, that screen buffer is needed.

[BigDumbDinosaur]

whartung wrote:

BigDumbDinosaur wrote:

Plus there's no functions for scrolling the screen. Once you get into the realm of writing code to do all this you're way off-track.

Having written such code, it's not really a big deal. It's pretty simple code. Blinky cursor, scrolling, the whole thing.

Have you done that for the Picaso µVGA-II SGC module?

Quote:

Save for the most simple of applications on consoles (i.e. a serial console), you will likely need an addressable buffer representing the display anyway...

All this is is a console. I'm not trying to, nor interested in, replicating the screen kernel of a C-64. As you will soon see if you study the Picaso µVGA-II SGC's command set, a cursor is not a simple matter, nor is line-by-line scrolling (although the latter can be simulated with some built-in functions).

As I don't want POC V2 to languish while I try to resolve how to make a console display work, I'm going to set aside the console feature and continue to use a dumb terminal. POC V2's main purpose is to prove out the CPLD glue logic and to develop a rudimentary preemptive multitasking kernel. The console was an afterthought that will have to stay on the back burner for now.

[Dr Jefyll]

Quote:

I don't want POC V2 to languish while I try to resolve how to make a console display work... ... will have to stay on the back burner for now.

I think the necessary cursor software (even including the interrupt nuances) might initially appear complex but would turn out to be readily managable once you actually sit down and dig in. But I fully understand that a dumb terminal is adequate for the time being, and that human IO is not your immediate focus. So, back-burner it is. (Gosh, isn't it amazing how crowded that back burner is getting!!)

I admit to being quite taken with the Picaso, myself. Although a home-brew computer could instead incorporate some sort of video display controller, Picaso already has the RGB output circuitry and VGA connector. It also has an SD memory card adaptor (with low level or DOS compatible access)! And Picaso needn't be attached to the computer in question. As a stand-alone unit it could be used with different projects as required.

cheers
Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

Quote:

I don't want POC V2 to languish while I try to resolve how to make a console display work... ... will have to stay on the back burner for now.

I think the necessary cursor software (even including the interrupt nuances) might initially appear complex but would turn out to be readily managable once you actually sit down and dig in. But I fully understand that a dumb terminal is adequate for the time being, and that human IO is not your immediate focus.

Like everyone else here, I only get 24 hours in a day and I do sleep for a few of them (but not many). Aside from not wanting to have everything stall out over this one feature, I have to consider the effect on resource consumption if I were to commit resources to managing a display.

Quote:

So, back-burner it is. (Gosh, isn't it amazing how crowded that back burner is getting!!)

I've got a few pots simmering back there. This adds yet another.

Quote:

I admit to being quite taken with the Picaso, myself. Although a home-brew computer could instead incorporate some sort of video display controller, Picaso already has the RGB output circuitry and VGA connector. It also has an SD memory card adaptor (with low level or DOS compatible access)!

The SD memory card feature may be the key to solving the display issues. At the least, it could be used to map the display. Manipulation of it can be cumbersome, however, as it really behaves as a block-oriented device, whether the FAT16 features are or are not used.

[Dr Jefyll]

Quote:

The SD memory card [...] behaves as a block-oriented device.

I agree -- it's kinduva pain. But OTOH it's much the same as a hard disk.* In fact, maybe sometime later it could be an additional medium for your file system.

BTW, my back-burner remark was only a joke. It would be ridiculous for me to seriously tease anyone, given the backlog on my own back burner!

-- Jeff

*Edit: admittedly the SD card does require initialization. And, optionally, wear-levelling.

[whartung]

BigDumbDinosaur wrote:

Have you done that for the Picaso µVGA-II SGC module?

Nope, I don't have one.

BigDumbDinosaur wrote:

Quote:

Save for the most simple of applications on consoles (i.e. a serial console), you will likely need an addressable buffer representing the display anyway...

All this is is a console. I'm not trying to, nor interested in, replicating the screen kernel of a C-64. As you will soon see if you study the Picaso µVGA-II SGC's command set, a cursor is not a simple matter, nor is line-by-line scrolling (although the latter can be simulated with some built-in functions).

That's because the Picaso is NOT a Console. It's a VGA frame buffer with high level commands to talk to it. So, "of course" you'll have to roll a "console like" behavior out of it. Save, perhaps, for the hardware cursor, you'd be in the same boat with an old school CGA card: scrolling, wrapping, etc. etc.

If you had intended to have any kind of application that used the screen as more than a "glass tty", an internal buffer is effectively required, especially for anything like a text editor.

The command set looks straightforward. At its core, you effectively have GOTOXY and PUTCHAR. With these you can "do anything". With the added PUTSTRING, you can do some things more efficiently. With the Screen Cut/Paste, things (notably scrolling) get much faster. Your worst case is a screen repaint where every single character is a different color and font (and you would need to create your own fonts for BOLD and UNDERLINE if those at all interested you). In that nightmare scenario you need to send, for an 80x25 screen, 6 * 80 * 25 = ~12,000 bytes (more if you're playing with fonts). At 115KBaud, that's 1/10 of a second. Meaning you'd get, at best, 10 frames/sec of full frame text animation. Not great.

Naive Scrolling (including insert/delete line) can fall under that meme of "full screen animation", but with the screen cut and paste, you can do it with ~500 bytes. That's much faster.

The two issues with the blinky cursor are the necessity of a screen buffer so it can know what character it is over, and the coordination of the cursor state and access to the display. Simply, this display gives you the worst of both console worlds. It's a graphics device, meaning you have to manage the entire screen yourself, but at the same time it's a serial device, so you can't just "draw on VBLANK" from the screen buffer (because a screen repaint is simply too slow). So the blink cursor has to be managed and coordinated with the regular output stream to the device. Simplest way it probably simply having some internal lock, and use that to gate access to the display.

Your primitives can be "cursor aware" so they know that if the cursor happens to be lit at the moment, they can keep it on when they draw their data, meanwhile the interrupt driving the cursor checks the lock and if it's not available, it simply bails until next time, otherwise it rewrites the character underneath the current cursor position.

You're right, this code is a distraction, but frankly it's as much of a distraction as the PC keyboard decoding software you would need (and were apparently planning) to write as well. If you didn't mind having a static (non blinking) cursor, it's even simpler as that's really the only messy part of the system.

[BigDumbDinosaur]

whartung wrote:

If you had intended to have any kind of application that used the screen as more than a "glass tty", an internal buffer is effectively required, especially for anything like a text editor.

Of that I am aware. However, what I was going to do was write primitives that could do only the glass-tty functions required to produce a console display, thus avoiding display maps and the attendant RAM consumption.

Quote:

The command set looks straightforward. At its core, you effectively have GOTOXY and PUTCHAR. With these you can "do anything". With the added PUTSTRING, you can do some things more efficiently. With the Screen Cut/Paste, things (notably scrolling) get much faster. Your worst case is a screen repaint where every single character is a different color and font (and you would need to create your own fonts for BOLD and UNDERLINE if those at all interested you).

Full screen scolling is done by cutting and pasting pixels, not characters. In theory, if the cut and paste is correctly done, the character attributes would move with the characters themselves, so a literal screen repaint might be avoidable.

As for fonts, the Picaso does have provisions for font replacement. However, only the printable ASCII range maps to text characters, so some other means of underling, bold-facing, etc., would be necessary. In this regard, it's not at all like CGA/EGA, where each character has a set of attributes to define its appearance.

Quote:

The two issues with the blinky cursor are the necessity of a screen buffer so it can know what character it is over, and the coordination of the cursor state and access to the display.

The coordination issue can mostly be avoided by not using buffered I/O with the console. That way a single primitive can be called to write to the Picaso. There's a bit of a complication in that just about every command is implemented with multiple bytes, so a semaphore would be required to avoid having the interrupt interfere with a foreground write. The change in cursor state, if scheduled, could then be deferred to the next IRQ (100 Hz IRQ rate).

Quote:

You're right, this code is a distraction, but frankly it's as much of a distraction as the PC keyboard decoding software you would need (and were apparently planning) to write as well. If you didn't mind having a static (non blinking) cursor, it's even simpler as that's really the only messy part of the system.

Actually, the keyboard would have been quite simple, as the decoding grunt work is done by a AVR and all the MPU has to do is respond to an IRQ from the AVR when a byte is ready for pickup.

[whartung]

I think a generic serial console is the hot tip for this anyway.

I think developing the driver routines for the graphics things is best done interactively.

Load up a Forth and go to town, perfecting the scrolling, getting the rest to work. Something about visual work and being able to do it interactively that makes the turn around so much faster.

Type code, hit <ENTER>, look at the screen, rinse and repeat. Beats downloading new images.

You could do this on any machine I reckon, since the VGA module is serial. But that's how I'd do it.

Don't forget in your glass tty to handle the BACKSPACE/DELETE action properly. It's a minor thing but easily overlooked. I'd also add a clear screen capability. You could write it to always start at the bottom of the display and scroll up, but adding a clear screen and fill down then scroll capability is pretty minor work. Could always simply use FF char for that.

You might want to add TAB support, but that's likely optional.

Back in the day, some systems relied on local processing by the terminals. Notably things like back space and field advancement. When the screen was painted, the fields were defined and the user was locked to which fields they could interact with. The back end never saw keystrokes, they saw sets of fields sent all at once. There was a name for these terminals, but they escape me. I never had the opportunity to work on such a system, I found them archaic even when I started to a "modern" system that was truly interactive. But I can see their value especially on communications with high latency. Nothing worse than a sluggish typing session.

[BigDumbDinosaur]

whartung wrote:

I think developing the driver routines for the graphics things is best done interactively.

That would make it too easy.

Quote:

Back in the day, some systems relied on local processing by the terminals. Notably things like back space and field advancement. When the screen was painted, the fields were defined and the user was locked to which fields they could interact with. The back end never saw keystrokes, they saw sets of fields sent all at once. There was a name for these terminals, but they escape me. I never had the opportunity to work on such a system, I found them archaic even when I started to a "modern" system that was truly interactive. But I can see their value especially on communications with high latency. Nothing worse than a sluggish typing session.

What you are referring to is called "block mode." The terminal buffers the keystrokes until the user hits the "Send" key (or similar), at which time the fields are sent in sequence, each field separated by an ASCII <FS> character. In some cases, fields were grouped into records, with an ASCII <RS> character telling the remote server when one record ended and the next started.

Block mode was widely used back when slow phone line connections were the norm. Anything from 4800 bps and up can work interactively with proper programming if the terminal has enough intelligence. Oxymoron: a dumb terminal with intelligence.

[whartung]

BigDumbDinosaur wrote:

Block mode was widely used back when slow phone line connections were the norm. Anything from 4800 bps and up can work interactively with proper programming if the terminal has enough intelligence. Oxymoron: a dumb terminal with intelligence.

I never really had a problem working with interactive systems running 1200 Baud and above. We have, like, 4 terminals in school that would run 2400 (and they happened to be closest to the computer center). They were certainly prized when you could get on them.

300 isn't really usable, I've done work at 110. I used to print out my english papers edit with a line editor on the back of green bar paper formatted with a RUNOFF style word processor, and the printing terminal was 110 Baud. Whoo boy.

But we regularly used screen editors and such at 1200 Baud.

[BigDumbDinosaur]

Earlier I mentioned that I had reevaluated my design with an eye to eliminating the separately plugged-in SCSI host adapter. My idea of building in console hardware has been pushed to the back burner, so that aspect of the design is out. However, I will continue on the path of using a production sized board so the SCSI hardware is embedded. Doing so will eliminate one of the constraints on maximum clock speed, as well as make for an overall neater package.

An interesting thing about EPCB's production service is that in small quantities the board area is not a major factor in the cost. As I am looking at laying out the board to conform to the micro-ATX footprint (but narrower), I have more freedom with the amount of hardware that can be installed. That has led me to take a second look at the memory situation.

My original design uses two 512KB SRAMs soldered directly to the board. Since I have more room on the (enlarged) board, I am now thinking about adding more RAM. This might be a good time to look at adapting Garth's 4MB DIMM, which would use space more efficiently than that of soldering the chips to the PCB. While I have some trepidation about the use of pins on the DIMM, its general design is attractive because of its compactness, a feature that should aid in achieving high speed operation. A little more decoding would be needed from the CPLD, but so far, it appears that it has sufficient P-terms to do the job. In the next week or so I will evaluate the expanded memory map (now with RAM out to $3FFFFF) and determine if it will fit. The CPLD will have quite a bit of other stuff to do, which I can't eliminate to make room for added RAM decoding. We'll see...

[enso]

How is Picasso visually? I am curious because a few years ago, faced with the same issues, I bought another serial/VGA controller - the name escapes me but I think it was mentioned in one of the messages. I think the manufacturer is in Germany; the board had a keyboard port next to the VGA output (possibly a mouse port as well)... Maybe it was an earlier version of the Picasso...

The reason I ask is that the output of the board was so horribly UGLY that after 5 minutes I unplugged it and threw it into the scrap box where I am sure it still sits. I could not believe you could make an 80-column display that ugly if you tried. I think they took a 5x7 font and had it scaled up a few pixels with the most outragous result. I emailed the company and they never replied. Perhaps I was a little harsh (why did you pick an ugly unreadable font?), but the product was useless...

My hope at the time was to eliminate the PC entirely - I have yet to do this....