Denial

Mainly a quick hack of graphics primitives yet:


Unlike vin this GUI uses a bitmapped screen and is intended to waste Ultimem's RAM and ROM as if there's no tomorrow, so applications don't have to be relocatable.

This one also introduces a bytecode interpreter. Machine and bytecode can be mixed easily. Possibly an inspiration for those who want to hammer large applications from the PET or C64 into the VIC. If cc65 had support for this kind of thing to squeeze down repetitive code – phoarrh.

However, a source says more than a thousand words: https://github.com/SvenMichaelKlose/g
cc65 C compiler with "vic20g" target: https://github.com/SvenMichaelKlose/cc65g

Why g?

* Program loader on steroids, crack cocaine and Jolt at once.
* You'll be glad when the apocalypse is on. Or if your real PC blew up and you can at least edit text on SD card for profit.
* A new bunch of retro software that has been written in ANSI–C becomes available for easy porting.
* Tool for learning programming and doing homework for minors that is simple Mum will be impressed – and it doesn't come with all the porn. Wouldn't bet on the latter for too long, though.
* NSA–free desktop.

Any good reason g only sports a bitmap of 160x176 instead of 160x192?

Mike wrote:Any good reason g only sports a bitmap of 160x176 instead of 160x192?

Just because I couldn't get it to run with a higher resolution on the first attempt and preferred to focus on the stuff that would probably fry my brain trying, like clipping text.
But if you say that 160x192 should work… well… I'll just take a shower and do it.

pixel wrote:But if you say that 160x192 should work…

It's not as if MINIGRAFIK hadn't been around for quite some time now.

Mike wrote:

pixel wrote:But if you say that 160x192 should work…

It's not as if MINIGRAFIK hadn't been around for quite some time now.

I have another great excuse: when I wrote those routines there was only 56.6kbaud Internet around, which is a real pain up main street if you want to look up things. But I assume it's about moving charset and screen to $1000 and offset the character values. Back in a sec.

When the 160x192 mode was hinted at in "64'er Sonderheft 3", page 60, there even wasn't any Internet around accessible for the general public:

64'er SH 3/86 wrote:Immer wenn über die VC-20-Grafik geschrieben wurde, bekam man bisher vorgerechnet, daß die Auflösung nicht 28160 Punkte überschreiten kann. Um es gleich vorwegzunehmen: In der Tat ist die echte Maximalauflösung mit 160 * 192 = 30720, wie sie durch entsprechendes Umgestalten der Data-Becker-Grafik aus dem Buch »Tips & Tricks für den VC 20« gelang, [...]

So, no reason to settle for anything less than 160x192 nowadays.

Shower worked wonders – 160x192 it is! Thanks, Mike!

And that's where the trouble starts. Who'd want to contribute to a VIC GUI at all even if one could use tools of his choice?

@pixel: PM sent

Here's an idea to get around backwards compatibility issues and have everybody use the tools of his choice.

All applications start at $2000. The +3K area is reserved for g.

Jump tables must be requested by an application using a list of ASCIIZ strings that denote the calls wanted, so new functions can be added or removed without breaking everything. Like so: Libraries that provide syscalls start with a header: All versioning problems virtually solved. Your not happy with the window manager? Invented a new input device? Mike soldered an Amiga AGA chip into your VIC? Just put the right lib into place.

The path could also point to another running process, so we get inter–process communication.

Wasn't there another WIP years ago? What happened to Kananga's try? It already included a disk utility .
Current work folder here.

orion70 wrote:Wasn't there another WIP years ago? What happened to Kananga's try? It already included a disk utility .
Current work folder here.

Yes, it's very exciting work and the reason why I kept my hands off an own attempt earlier. Am hoping that Kananga would like to port it to some UltiOS. At the moment I'm thinking about the non–graphical part (memory, I/O and process management – all the mega–boring stuff) that would make it easy for him as well.

Imagine multitasking and hibernating the system to ROM...

Great project pixel!

With your talent it can be only a success!

Can't wait for the Ultimem

Well, bank allocation was the first and last no–brainer. Writing OSes is a brutal sport.

Am about to use the +3K area mostly for jump table destinations – generated functions which will set the right banks before hopping to the real deals.

Banking is causing confusion right away because you probably want to share banks instead of copying data. The most simple fix I can see for that is to switch only banks the callee allocated so all other banks are shared across calls without further intervention. Back to programs having to start with a load address. I assume that BLK5 will probably be not shared most of the time as it seems to be convenient to place libraries there.

Moreover I'm certain that you will want KERNAL–compatible I/O so you could port programs more swiftly. Oh, speaking of I/O: the regular KERNAL has to stay in unless somebody is crazy enough to write a replacement, I guess.

pixel wrote:the regular KERNAL has to stay in unless somebody is crazy enough to write a replacement, I guess.

At least g should be aware of JiffyDOS in place of a standard KERNAL.