Page 1 of 2
Robo-VIC: An Android Inspired GUI
Posted: Mon Aug 21, 2017 8:57 am
by plbyrd
I'm working on an Android inspired gui for the VIC20. So far I've gotten the basics of the display set up, but I need a mouse driver for cc65. I've started a joystick driver, but am not able to compile it as part of the standard cc65 build process. It simply does not see the new source file under libsrc/vic20/mouse
I will be creating PC tools to generate a standard UI markup language. The end goal is to be able to use a subset of XAML to define the pages of the GUI, and then run a parser to tokenize it into something that Robo-VIC will understand (and not use much memory).
I'll be releasing this as open source once someone actually expresses interest in helping. There's some overhead to manage an open source project, even on Github, and so I don't want to take cycles away from coding for that.
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 3:52 am
by pixel
Cool. Last year I started an UI for the Ultimem expansion in C. It has basic automatic layout features and can be found at
https://github.com/SvenMichaelKlose/g/t ... /flashmenu but needs cc65g, a fork of cc65 at
https://github.com/SvenMichaelKlose/cc65g to help with the attempt to write a Unix-like OS for the VIC.
You can safely ignore the kernel. Wanted to push the UI further first. I suggest you make your thing open-source ASAP to get some input.
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 5:23 am
by plbyrd
Yeah, I've decided to leave the kernel alone for compatibility to various devices that use the IEC port. I do highly recommend JiffyDOS to be used with it. I'm doing all my testing with JiffyDOS and 32K expansion. Eventually the core parts will be re-written in assembler.
The current wave of work is centering on the page definitions and navigation. I'm envisioning an array of structs. Each struct will define the element type, which a pointer to the element struct. So, that way each element can have different properties, but still be associated to the main array of elements. Each element will be responsible for handling the display of the element using the built in routines (drawText, drawButton, drawBox, etc). This way, I could have a scrolling list of complex elements just like in a template def in Android or Windows 10.
The UI Pages will be built in XAML on a PC and then tokenized into the array structure that can then just be loaded as a binary file in the GUI.
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 5:36 am
by beamrider
Disclaimer: Just my opinion, so please don't take this the wrong way, but...
I struggle to see the merit in creating something like this, unless it's just for personal enjoyment of course and you aren't expecting anyone to actually use it?
The number of Vic owners, with access to MB memory expansions (and perhaps a compatible mouse) that would wish to run a general purpose OS on a 22 column display, without any compelling applications available would probably amount to just the author..?
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 5:45 am
by pixel
@beamrider: You're absolutely right and I don't mind the PMs that suggest better fine-tuning of medication.
BUT I turned to implementing the GUI for the file menu alone, knowing that something might show up that'd allow for quick hacks.
With "kernel" I was referring to the bank switching core of "g".
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 5:55 am
by plbyrd
beamrider wrote:Disclaimer: Just my opinion, so please don't take this the wrong way, but...
I struggle to see the merit in creating something like this, unless it's just for personal enjoyment of course and you aren't expecting anyone to actually use it?
The number of Vic owners, with access to MB memory expansions (and perhaps a compatible mouse) that would wish to run a general purpose OS on a 22 column display, without any compelling applications available would probably amount to just the author..?
This is actually a three part effort. There will be ports to C64 and C128 (40-column only). You're right about apps. I intend to create the following apps that will ship out of the "box" so to speak:
1) CG Terminal
2) wget
3) D64/D71/D81 converter
4) App store
All apps will be packaged in a very specific way. I hope to be able to write a non-type-safe JSON reader that can allow for a manifest file that's a little more complex than an INI file. This will enable app developers to publish their own apps and target any/all of the systems depending on need of specific hardware.
For example, the 128 version will store apps in the second bank of memory with only the shared memory available, or just the kernel, or both the kernel and GUI functions. For all three targets, there will be a jump table into the GUI API that will reside at the lowest possible common RAM location.
Did I mention that some sort of internet connection will be required? Any modem emulator plugged into the userport will do whether it be serial to tcpser, ethernet or wifi. As long as it's hayes compatible it'll work. Hell, you could even use a modem to connect to a gateway somewhere.
All targets will support keyboard and joystick input. On the 64 and 128 a mouse is optional. I don't think a mouse is cost effective for the VIC 20.
Whether anyone will use any of this is debatable. I want to do it, so I am doing it.
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 6:05 am
by beamrider
plbyrd wrote:Whether anyone will use any of this is debatable. I want to do it, so I am doing it.
...in that case, good luck!
Re: Robo-VIC: An Android Inspired GUI
Posted: Tue Aug 22, 2017 12:16 pm
by plbyrd
Is there a way to split the VIC screen into two modes, like the VIC-II can? I would like to offer the ability to mix multicolor graphics with the standard text mode of the UI. It would be really cool to allow the app to determine where the split would happen (example, lines 0-16 are always text for the notification area, the app wants line17-128 as bitmap, and the app wants lines 129-176 for text. Additionally, When the user clicks the notification dropdown glyph, I want to allow the notification area to expand up to 10 lines, moving the split to the appropriate line, and then when they close the notifications, move the split back where it started.
Re: Robo-VIC: An Android Inspired GUI
Posted: Wed Aug 23, 2017 1:25 am
by Mike
The VIC-I chip has only one display mode: multi-colour text.
If you want to display (parts of) the screen as bitmap, that is done by using a given arrangement of characters in the screen RAM as address generator, you then manipulate the character definitions. See
here.
It is though possible to sync a timer to the electron beam and change the base addresses of text screen and character generator mid-screen as you find necessary for a display application. You'll find several applications here in Denial. Of course, interrupt driven, 'active' screen displays add extra complexity when disk drive I/O is involved.
MINIGRAFIK displays 160x192 pixels out-of-the-box, and doesn't require any interrupts to do so. The lower 1K of the internal RAM ($0000..$03FF with ZP, stack and OS workspace) is not used. With the routines of
MG BROWSE, you can show fairly readable 40 columns/line. The remainder of the screen can show multi-colour graphics in any arrangement you want.
Re: Robo-VIC: An Android Inspired GUI
Posted: Wed Aug 23, 2017 6:20 pm
by plbyrd
I have an idea after installing JiffyDOS in my VIC20. I wonder if it'd be useful to make a Robo-VIC Kit available that would have replacement ROMs for the chargen and basic. Instead of booting to basic, you'd boot to Robo-VIC. We could make the chip switchable like JiffyDOS so you can still use the stock VIC-20 ROM when you want to.
Re: Robo-VIC: An Android Inspired GUI
Posted: Wed Aug 23, 2017 7:35 pm
by plbyrd
I got my Ultimem today.
O. M. G.
I've wondered if an EasyFlash like thing would ever be created for the VIC20.....
I cannot believe it's not more widely known about. I bought it on a whim to get a memory expander. I didn't even know it had a writable flash system. Now, posting this in the Robo-VIC thread is obviously for a reason. I had contemplated many configuration things for Robo-VIC/64/128. On 64, it'd be super cool for it to be an Easy Flash based system. I already have experience doing this with EasyCLI. I ruled that out because of a lack of an EasyFlash solution for the VIC-20. I was ill-informed. Now that option is back on the table. And there's a video out there of an expansion for the 128 that will be EasyFlash compatible. 8D I'm not sure I want to lock people into third party hardware (except maybe JiffyDOS). I also think selling kits with certain hardware bits to complement the software is a great idea too.
I sure could use some feedback. Right now I need some long term goals besides "get it done". The end result shapes the path you take, so to speak.
Re: Robo-VIC: An Android Inspired GUI
Posted: Wed Aug 23, 2017 7:44 pm
by pixel
plbyrd wrote:I have an idea after installing JiffyDOS in my VIC20. I wonder if it'd be useful to make a Robo-VIC Kit available that would have replacement ROMs for the chargen and basic. Instead of booting to basic, you'd boot to Robo-VIC. We could make the chip switchable like JiffyDOS so you can still use the stock VIC-20 ROM when you want to.
That half file browser I mentioned boots from the Ultimem expansion which comes with 8MB flash and 1MB RAM. Not sure about the other expansions at the moment. VICE supports it. You could grab an Ultimem image here:
http://hugbox.org/pixel/external/denial/g.zip and run it with
Perhaps you'd find it inspiring.
EDIT: Ooops... already forgot what's been posted here before. m(
Re: Robo-VIC: An Android Inspired GUI
Posted: Thu Aug 24, 2017 8:52 am
by plbyrd
Is there a way to safely detect the presence of the Ultimem?
Re: Robo-VIC: An Android Inspired GUI
Posted: Thu Aug 24, 2017 9:48 am
by Mike
plbyrd wrote:Is there a way to safely detect the presence of the Ultimem?
No. Any inconsiderate accesses to I/O 2 or I/O 3 by 3rd party software, regardless whether these are writes or reads(!), can lead to unforeseeable effects depending on which cartridge is connected. IMO, the only legit user of the I/O area is the firmware of the cartridge in question.
If you nevertheless (need to) use the I/O area as "Ultimem user", then the program ought to state this clearly
before attempting any access.
I'm not joking. tokra 'shot' the NVRAM of his Mega-Cart by just checking for the presence of *RAM* in I/Ox by one of his tools (by meticulously: 1. reading a byte at a certain address, 2. writing another value ($55) into this address, 3. check for the value correctly being written to the address. 4. and 5. redoing this with $AA (inverted bit-pattern), 6. restoring the old value) - any of the six accesses can have completely different results, when not a RAM cell is accessed, but a (possibly read-sensitive!) register of some I/O. It could cause a reset, flash the EEPROM, format the SD card, whatever. In the mentioned case, tokra had to reset the Mega-Cart's NVRAM to factory default by a key combo during power on. Then his Mega-Cart worked again.
That's how it is.
P.S. ...the earlier debates in the PC world for example how to correctly identify a certain type of CPU should give an interesting read in that regard, see
here and
here (seems they put a 2-article(-per-day?) limit in charge ...)
Re: Robo-VIC: An Android Inspired GUI
Posted: Thu Aug 24, 2017 11:31 am
by plbyrd
I wrote a quick memory configurator for Ultimem last night and saw a consistent behavior. When I applied a value to the registers and the Ultimem was there, leaving the program resulted in a soft-boot with the correct configuration. When I didn't have Ultimem in place, the program just drops back to basic when it finishes. If this is a safe and repeatable process then I could that behavior to determine the presence of Ultimem. However, I was hoping for a less invasive way to do it.