g – a multitasking OS for Ultimem/VICMIDI (WIP)

Basic and Machine Language

Moderator: Moderators

User avatar
Mike
Herr VC
Posts: 3016
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: g – another GUI under construction

Postby Mike » Tue Mar 15, 2016 6:20 pm

pixel wrote:Shower worked wonders – 160x192 it is! Thanks, Mike! :D

eslapion wrote:Wouldn't that pose problems on NTSC VIC-20s ?

m(

Francois.

Just start up any program that uses MINIGRAFIK.

There you have it.

160x192.

I've been doing this all the years.

On PAL.

And NTSC.

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Tue Mar 15, 2016 6:34 pm

vin20's huge display area must be producing more Xrays than colours on NTSC then. However, easy fix: shrink it back down. Once cooked some simple algorithms for automatic layout when nested tables bombed Netscape: https://github.com/SvenMichaelKlose/ptk
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Wed Mar 16, 2016 1:47 am

The RAM limit is now 2Mb. Was worried about task switches but as it turns out the high bytes of the Ultimem's bank registers don't need to be touched and since every process gets its own copy of the core things seem to become very fast. :)
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

eslapion
ultimate expander
Posts: 4330
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: g – another GUI under construction

Postby eslapion » Thu Mar 17, 2016 6:15 am

Mike wrote:
pixel wrote:Shower worked wonders – 160x192 it is! Thanks, Mike! :D

eslapion wrote:Wouldn't that pose problems on NTSC VIC-20s ?

m(

Francois.

Just start up any program that uses MINIGRAFIK.

There you have it.

160x192.

I've been doing this all the years.

On PAL.

And NTSC.

Here's my answer to this...

In pure graphic mode, in theory you're right because the 6561/0 can only access 4k of RAM at a time.

However, the VIC doesn't have a bitmap mode per se, what you're doing is filling the screen codes area with 8x16 pixel characters from 0 to 255 then altering the content of these customs characters to create "sort of" a bitmap.

However, if you create a custom character set and reuse some of them, you can effectively display up to 176 x 264 at the expense of not being able to display more than about 200 different repetitive "tiles" of 8x16 pixels.

That, of course is true only of the PAL VIC-20.

Concerning the NTSC VIC-20, I thought going up to 192 vertically would cause part of the display to be lost in the overscan area but apparently you're right. If, as above, you limit yourself to a certain number of tiles you can even increase your display resolution to 176x200. Not as much as the PAL VIC but quite large nonetheless.
No one can do everything. Everyone can do something.

User avatar
Mike
Herr VC
Posts: 3016
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: g – another GUI under construction

Postby Mike » Thu Mar 17, 2016 7:29 am

Let's set the facts straight:

eslapion wrote:In pure graphic mode, in theory you're right because the 6561/0 can only access 4k of RAM at a time.

First: the VIC has an address bus of 14 bits width. Thus, it can address 16K. In an unmodified VIC-20, the internal RAM and the character ROM can be accessed by VIC for text screen/character data and it can access the colour RAM for attribute data over an extra 4 bits wide data bus.

This is no theory, this also works in real. However, it is unrelated to your objections that a display with 192 lines height might not work on NTSC.

However, the VIC doesn't have a bitmap mode per se, what you're doing is filling the screen codes area with 8x16 pixel characters from 0 to 255 then altering the content of these customs characters to create "sort of" a bitmap.

Not only "sort of" a bitmap. Once the VIC register values and the text screen are set up, I can forget about them both, and handle the character definitions as bitmap. That there is some in-between stage, which serves as address generator is largely irrelevant. There is a 1:1 correspondence between screen pixels and bits in memory, and this is exactly what defines a display bitmap!

However, if you create a custom character set and reuse some of them, you can effectively display up to 176 x 264 at the expense of not being able to display more than about 200 different repetitive "tiles" of 8x16 pixels.

You are telling me no news here.

tokra and I however had advanced beyond those limitations a long time ago already. For both PAL and NTSC, we constructed fully bitmapped resolutions much larger than 160x192. They just come at the expense of available CPU time, as they use the main processor to shuffle data from the expansion RAM into the (VIC accessible) internal RAM, synchronous to the raster beam, so VIC can display a larger bitmap and/or finer colour attributes (not only raster bars! But 8x1 pixel foreground colour cells).

BTW, in my VFLI mode the "I" does not mean "interlace". FLI is a standard designation on C64 to Flexible Line Interpretation - colour attributes in the hires screen are there then not anymore 8x8 pixels, but 8x1 pixels. My hardware mod and the corresponding display routine realize a 208x256 FLI mode on the VIC-I, hence VFLI. Without the hardware mod, 104x256 pixels are still possible on PAL and 88x400 (interlaced) can be done on NTSC.

...

What puts me at odds against you is, that you are telling obviously wrong or at least inaccurate assertions regarding this topic, even though you have been posting long enough here in Denial and had more than enough opportunities to get it right. You really should know better.

The one who says it cannot be done should not interrupt the one doing it.

eslapion
ultimate expander
Posts: 4330
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: g – another GUI under construction

Postby eslapion » Thu Mar 17, 2016 2:37 pm

Mike wrote:... What puts me at odds against you is, that you are telling obviously wrong or at least inaccurate assertions regarding this topic, even though you have been posting long enough here in Denial and had more than enough opportunities to get it right. You really should know better.

The one who says it cannot be done should not interrupt the one doing it.

Mike, even if the 656x has 14 bits of addresses, it is attached to 1 block of 1k of RAM and another one of 4K. So talking about 16k of addressable, in this case is irrelevant.

My point was, the PAL version can display more pixels vertically and you essentially confirmed it.

The fact that you use this architecture in a manner where there is a correspondence of 1:1 between screen pixels and bits in memory changes NOTHING to the fact hidden under it is a system of tiles and that you can use this system to cheat on the maximum resolution... with zero CPU time.

It also changes nothing to the fact this system of tiles provides for a higher potential vertical resolution on PAL VIC-20 vs NTSC and nothing to the fact this sort of trick cannot be done on the C64 because the 6567/6569 have the same displayable number of rows/columns.

So the only place where I was wrong, is not saying this in a manner which your very rigid cognition can accept.

So what puts me at odds with you is everything is wrong according to you if its not described with your specific cognitive approach.

BTW, you did the same thing when I asked you to help me make a program to dump 256k of data. You demanded information that you clearly didn't need and didn't even use but blamed me for not providing. You resolved the problem anyways.

BTW, in my VFLI mode the "I" does not mean "interlace". FLI is a standard designation on C64 to Flexible Line Interpretation

Now from what planet did you take that I said the 'I' in VFLI means interlace ?

I said:
I think Mike and other programmers took advantage of that along with the interlace capability which is also specific to the VIC-20 for VFLI displays.

Ha... so saying VFLI uses interlace implies I said the 'I' means interlace...

Image
No one can do everything. Everyone can do something.

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Thu Mar 17, 2016 3:15 pm

Now I know why there's hair starting to grow on my back. Dudez, I retreated from GUI programming in favour of Kananga's and other people's work. Could we make this focus a little more on what you'd like to roll out in a VIC multitasking environment in this thread, please?
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
Mike
Herr VC
Posts: 3016
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: g – an Ultimem OS/GUI under construction

Postby Mike » Thu Mar 17, 2016 3:50 pm

Francois,

you have an odd habit to try to enforce and continue a discussion, when all relevant things already have been stated. But anyway:

even if the 656x has 14 bits of addresses, it is attached to 1 block of 1k of RAM and another one of 4K. So talking about 16k of addressable, in this case is irrelevant.

First of all, there's also the character ROM, so there are already 9K in an unmodded VIC-20, which the VIC chip can access. It is possible, with a hardware modification, to add another 3K at $0400..$0FFF and also 2K at $9800..$9FFF as VIC addressable memory, as internal expansion. The 3K has been done by various people (me included). The extra 2K VRAM in the I/O area have been proposed - anyone who does those should be wary it wouldn't be compatible with control registers of cartridges.

Even with an unmodified VIC-20, and excluding the character ROM, the VIC chip can already address 5K of RAM! Not 4K.

Still this is irrelevant to the displayable vertical resolution. 192 pixels height can be done on both PAL and NTSC anyway. Exactly this was, what you disputed in your earlier statement. Bringing this into conjunction with the addressable memory is just plain wrong!

My point was, the PAL version can display more pixels vertically and you essentially confirmed it.

I didn't bring any higher resolutions into this discussion until you brought them forth as examples what could be done with a tile-based "sparse" bitmap, when the techniques of emulated DMA, that tokra and I pioneered were not available. Once again, this isn't relevant to the 160x192 resolution, which can just be set up, and handled by the VIC chip. With 0% CPU overhead.

Why would you want me to confirm the higher vertical resolution of the PAL VIC anyhow? It's all in the data sheet. On what grounds would I able able to deny this? Why would I want to? Of course I'd be all wrong if I told people there's no difference between PAL and NTSC VIC chips. But I don't tell people this wrong fact. All I tried to convey to you is, that the 160x192 resolution can be displayed not only on PAL but also on NTSC.

The fact that you use this architecture in a manner where there is a correspondence of 1:1 between screen pixels and bits in memory changes NOTHING to the fact hidden under it is a system of tiles

It is there. I wouldn't deny this. But it is just (once again!) irrelevant, when it comes to "real world" use of the bitmap.

I (and everyone else who sets up this mode) can use the address range $1100..$1FFF as full fledged bitmap. Period. The VIC-I needs a properly initialised text screen, which serves as address generator into the bitmap. Other video chips use other methods to generate those addresses. Doesn't make it any more or less bitmap.

and that you can use this system to cheat on the maximum resolution.

Then you still have a graphic display, yes. But not anymore a bitmap.

And anyway, what's about this notion of "cheating"? There's the video chip, there's the RAM. All that matters, is that what I want to display is at the right place in RAM at the right time so VIC can fetch the data and display it.

This is what truly opened the way to the higher, fully bitmapped resolutions, that tokra and I constructed. Even if the bitmap is now distributed between static RAM contents and operand fields of LDA #imm instructions, I still can point you to a bit in RAM, point you to a pixel on screen, have that 1:1 correspondence, and thus there's a - bitmap! Unlike the "static" approach of the bitmap as done by MINIGRAFIK, this is a dynamic approach. But it's only the result that counts: 224x280 pixels in PAL, 192x416 (interlaced) in NTSC as maximum resolution with (mostly) unchanged colour resolution, slightly less with dynamic changes of the colour registers. Or you get FLI modes with much enhanced colour resolution, near the standard pixel resolution.

It also changes nothing to the fact this system of tiles provides for a higher potential vertical resolution on PAL VIC-20 vs NTSC and nothing to the fact this sort of trick cannot be done on the C64 because the 6567/6569 have the same displayable number of rows/columns.

I wasn't talking about the C64. One other thing you bring into the discussion, that isn't related to the fact that 192 pixels vertical resolution can be done on both PAL and NTSC.

So the only place where I was wrong, [...]

What you are now doing is called: "Extending the Battle Zone". You try to divert the discussion into topics which are irrelevant to your original, wrong assertion. When you are told in no uncertain terms, that what you said is clearly wrong, and unexplainably so - you bring forth other subjects which are at the best only mildly connected. You could just accept you have been oblivious to well known facts, and this would be o.k.

I am not going to discuss anything beyond this point regarding your picture about my mind setup.

@pixel: Sorry - but I felt the need to reply to this. No more extra de-railing of this thread by me. Promised.


P.S. Oh, and this one:

Ha... so saying VFLI uses interlace implies I said the 'I' means interlace...

VFLI doesn't use interlace.

eslapion
ultimate expander
Posts: 4330
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: g – an Ultimem OS/GUI under construction

Postby eslapion » Thu Mar 17, 2016 4:02 pm

Then you still have a graphic display, yes. But not anymore a bitmap.

I only said "resolution" - you said bitmap.

I think you didn't understand my starting point anyways.

...

The PAL

VIC-20

can display

a higher

vertical

resolution

than its

NTSC

counterpart

This discrepancy

does not

exist

on the

VIC-II

series of chips.

Ok?
No one can do everything. Everyone can do something.

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Thu Mar 17, 2016 4:14 pm

Phoarrh! Just continue discussing. I'll be back when my crap's finished. :P
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Sat Mar 19, 2016 3:09 am

The planned, smallest set of core functions so far, including some convenience functions that come for free, to get everything else done in libraries. With a ROM file system this could at least make g the ideal tool to manage the set of games stored on the Ultimem. :D

$0400 – Link process to core or a library.
"launch" – Launch program on file system.
"fork" – Create child process.
"control" – Stop or resume a process.
"quit" – Quit a process or unload a library.

"alloc" – Allocate memory bank.
"free" – Free memory bank.
"setblock" – Assign bank to block.
"freeblock" – Free block.

"create" – Create file.
"mount" – Mount process to directory.
"mknode" – Mount process to virtual file.
"remove" – Remove file or node.
"open" – Open file.
"setin" – Set input channel.
"setout" – Set output channel.
"chkin" – Check input channel data availability.
"read" – Read byte.
"readw" – Read word.
"readn" – Read multiple bytes.
"readm" – Read block of unknown size.
"load" – Like "readm" but also allocating memory banks.
"write" – Write byte.
"writew" – Write word.
"writen" – Write multiple bytes.
"writem" – Write block starting with size.
"close" – Close file.

"cd" – Change working directory.
"mkdir" – Make directory.
"rmdir" – Remove directory.

"settimer" – Set timer.
"cleartimer" – Clear timer.
"overtake" – Stop multitasking.
"release" – Continue multitasking.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Sun Mar 20, 2016 3:20 pm

It can launch programs now and multitask via the NMI – just wondering why one has to disable interrupts via $912e.

EDIT: No linking yet – so not of much use for people who'd like to try coding for it.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Sun Mar 20, 2016 7:55 pm

Applications can now request jump tables to get to the core (not called "kernel" to avoid confusion).

First posting has been updated with a link to a ZIP to get head started.
The Hello World is here: https://github.com/SvenMichaelKlose/g/tree/master/src/sh

Will get to more in the README after… zzzZZZzzz… zzzZZZzzz…
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Tue Mar 22, 2016 1:13 pm

It dynamically links the graphics lib and runs in multitasking mode together with the init process. Every process or library has its very own 34K RAM at the cost of costly bank switching. Now I assume that multitasking via IRQ is better than NMI. That's what I'm going for now. Processes and libs don't free allocated banks, yet.

It's getting very unixy.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose

User avatar
pixel
Vic 20 Nerd
Posts: 868
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/pixel/
Location: various
Occupation: Pan–galactic shaman

Re: g – an Ultimem OS/GUI under construction

Postby pixel » Tue Mar 22, 2016 2:40 pm

KERNAL works (kept task switcher in NMI tho).

If one does KERNAL calls, multitasking should be switched off temporarily:

Code: Select all

   jsr take_over
   jsr $ffxx
   jsr release


Want to provide a virtual file system with nodes that divert accesses to processes (drivers).
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose


Return to “Programming”

Who is online

Users browsing this forum: No registered users and 1 guest