Vic GUI

[saehn]

VEOS? Looking cool. Why not 32k instead of 16k? Seems like 32k is going to be the new standard expectation (after stock, of course).

[nbla000]

VEOS? Looking cool.

GEOS means "Graphic Environment Operating System" so what does mean VEOS ?

I think GEOS for VIC-20 or VIC-OS is a better name

Why not 32k instead of 16k? Seems like 32k is going to be the new standard expectation (after stock, of course)

I agree, FE3, Mega-Cart, 32K expansion, there are a lot of potential users nowadays that may add 32K to the VIC and if you need a drive just refer to modern drives like a uIEC or SD2DRIVE.
Diddl developed SJLOAD routines for a very quick access to these drives (similar to memory transfer between Vic blocks) so the limit is the SD-Card size, 512MB, 1GB, 2GB or more

Please, think big

PS: And if you use FE3 or Mega-Cart you may have a Vic +32K +3K too, additional 3K RAM could be useful as swap space.

[RobertBe]

VEOS?

Heh, the VIC Environment Operatiing System. I approve of the work being done, and I'm eager to hear of the OS's progress.

Still in Portland, Oregon,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[Kananga]

Thanks for the intersting ideas and the encouragement.

Please, think big

Thinking big is not the problem, it is more what you can do in a few spare hours per week...
For now I'll concentrate on the GUI and on making the interface usable. For something I'd call an OS you'd also need memory management, I/O drivers, perhaps a relocating loader ... and I haven't even finished keyboard handling.

Apropos (programming) interface:
I use a sequence of calls to initialize windows, their properties, etc., but that leads to pages of initialisation code. Perhaps, it would be better to setup a structure with all necessary information and pass it to a single "create this!" call.
What do you think?[/b]

[robinsonmason]

I think you should stick to the foundation and once that is done, open it up to people who want to add things on top of that, start a blogger or wiki page here or some other collaborative site inviting people to contribute to the VEOS effort. Some of the ambitious ideas here are really more the kind of thing a group of programmers should tackle in a Linux/Open Source model of cooperation. The results could be huge!

I would choose only 16K expansion first --- correct me if I'm wrong but the only memory expansion carts that are out there in any great number for the VIC-20 are the Commodore branded ones that only went up to 16K. Requiring users spring for a 100 dollar Megacart (or a rare 3rd party expansion cart) really limits the audience that can enjoy this GUI idea as well, even if it might make sense when limited to Denial members.

[RobertBe]

Requiring users spring for a 100 dollar Megacart (or a rare 3rd party expansion cart) really limits the audience...

There is the far cheaper 32K Ultimate Expander. Read about it at

http://www.8bitcentral.com/supervic_cartridge.htm

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[nbla000]

OK then maybe main functions with 16K and full version with 32k btw as Robert said I don't think it is a cost matter, Mega-Cart costs 100 USD because it is not just a Memory Expansion of course but you may build yourself the FE3 or use the Eslapion's Ultimate Expander about 30 USD.

I have all of them and also an old 32K expansion but you need just one of them, if you need just a cheap 32k memory expansion then buy the Eslapion's Ultimate Expander.

My idea is that if we don't use 32k for a tool on 2010, when we will use full Vic potentiality ?

[saehn]

VEOS? Looking cool.

GEOS means "Graphic Environment Operating System" so what does mean VEOS ?

I think GEOS for VIC-20 or VIC-OS is a better name

VEOS = VIC-20 Environment Operating System.

Or GEOS-20. Or whatever. Just ideas.

[robinsonmason]

My idea is that if we don't use 32k for a tool on 2010, when we will use full Vic potentiality ?

This is a good point, but I thought it should be limited to the old expansion carts still available via E-bay or that VIC-20 enthusiasts still have rolling around in a box somewhere, not the latest homebrew or expensive solutions. That said...

There is the far cheaper 32K Ultimate Expander. Read about it at
http://www.8bitcentral.com/supervic_cartridge.htm

Is there a place I can buy this? Francois Leveille = eslapion?

Does the cart have a plastic shell?

[Mike]

Hi, Kananga!

Apropos (programming) interface:
I use a sequence of calls to initialize windows, their properties, etc., but that leads to pages of initialisation code. Perhaps, it would be better to setup a structure with all necessary information and pass it to a single "create this!" call.
What do you think?

IMO, this is a reasonable approach. Currently, that information is buried in the operand fields of the code snippet which does the API calls - with essentially redundant, constant(!) bytes of LDA #, LDX #, LDY #, and JSR instruction opcodes interspersed.

That single API call could have these parameters:

A: type of structure; X: low byte of pointer to structure; Y: high byte

Since MINIGRAFIK has been mentioned some posts above -

From your screenshots I've concluded you use a tile-based display with ~208x256 pixels. This is about the maximum size you can expect to be visible with CRT PAL monitors. Some might crop the corners. With NTSC, it is hard to go over 192x216 pixels (i.e. 24x27 in text). Of course, within VICE these restrictions don't apply in this sense.

I've chosen 160x192 as resolution for MINIGRAFIK, as it displays well within the overscan limits of both PAL, and NTSC (in fact I've never heard of complaints in this regard), and it nearly exactly fills the upper 4K of internal RAM: 240 bytes for the address generating text screen, 3840 bytes for the bitmap, leaving only 16 bytes free. The lower 1K are not used for the display, as MG was written with interoperability in mind to CBM BASIC, and KERNAL.

I'll keep an eye on your project.

Greetings,

Michael

[RobertBe]

Is there a place I can buy this? Francois Leveille = eslapion?

Yes, he is the man. Just send him a message.

Does the cart have a plastic shell?

No, it doesn't.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 24-25 CommVEx v6 2010 - http://www.commodore.ca/forum
and click on ComVEX

[Kananga]

Hi, Kananga!
Since MINIGRAFIK has been mentioned some posts above -

From your screenshots I've concluded you use a tile-based display with ~208x256 pixels. This is about the maximum size you can expect to be visible with CRT PAL monitors. Some might crop the corners. With NTSC, it is hard to go over 192x216 pixels (i.e. 24x27 in text). Of course, within VICE these restrictions don't apply in this sense.

I have thought about that, too. On NTSC systems the 208x256 mode is not usable at all. The reason, why I used the tile-based approach is that I wanted to try what you can do with it.
It is perhaps worthwile (and not much effort) to have two versions:
1. Tile based approach as above.
2. Based on (the excellent) MINIGRAFIK

The project is still in prototype stage, but I am working in my limited spare time to put something together to run & read (and continue discussing).

Thanks again for the interesting discussion!

[Mike]

1. Tile based approach as above.

For an example, in MINIPAINT the editor/zoomed view is not a MG bitmapped display. Rather the GUI elements are done with tiles.

The design happened to fit into the standard 22x23 screen layout. Exactly 128 characters are used to draw the frames, zoomed view, original size view, status display, and cursor. The second 128 characters provide for the 128x64 pixels text window for the dialog boxes.

There's a static assignment what the different tiles represent, but for many of them their content is dynamic, and calculated on the fly - with dedicated code.

2. Based on (the excellent) MINIGRAFIK

In that case, once the text map and VIC registers are initialised thus (taken from MG code for the @ON command):

Code: Select all

.On 
 CLC            ; set up char map 
 LDA #$10       ; first char is 'P', accessing $1100 
 TAY 
.On_00 
 STA $0FF0,Y 
 ADC #$0C 
 BCC On_01 
 SBC #$EF 
.On_01 
 INY 
 BNE On_00 
 LDY #$05       ; program VIC registers 
.On_02 
 CLC 
 LDA $EDE4,Y 
 ADC Offset,Y 
 STA $9000,Y 
 DEY 
 BPL On_02 
 RTS 

.Offset 
 EQUB $02 
 EQUB $FE 
 EQUB $FE 
 EQUB $EB 
 EQUB $00 
 EQUB $0C

... you only have to worry about the contents of the bitmap, and colour RAM. There's no overhead of maintaining a pool of free characters, and all pixels are freely definable. If there's no fixed layout on screen, this might be the preferable approach.

All in all, it depends on the application. As always.

[Kananga]

Did I say I hate writing documentation?

Anyway, I put together a small document and put it together with the GUI demo on google code:
http://code.google.com/p/vin20/downloads/list

No calculator yet and no keyboard input either, but see for yourself.

[BBQedIguana]

That is VERY cool!!! Thank you for your work on this GUI - it looks awesome so far!

Rick