WIP: INGLE, the cozy desktop for the Ultimem

[pixel]

Don't get mad. Arukanoido can only continue with me not being homeless+hardware back in hands.

INGLE is the latest attempt to make a desktop where most programmers can participate. It's written mostly in C with help of cc65.
It's on Github here: https://github.com/svenmichaelklose/ingle Most ideas are in the README.

And it'll need your help to grow and give you the campfire feeling. The GUI can be used without Ultimem, so you can actually write some fun apps already. It's got some auto-layout functionality btw.

What I'll do is the UltiFS (without KERNAL hooks) and the file manager.

Or just become a little dreamy and post your ideas about how it would make you happy in a remote block house off the grid. I'm for my part would be super-happy about VFORTH with basic graphics support (not especially INGLE support). VFORTH should really be an essential part of it.

[srowe]

I'm for my part would be super-happy about VFORTH with basic graphics support (not especially INGLE support). VFORTH should really be an essential part of it.

Once I'm finishing messing about with vicVOICE I'd like to

1. build a 40 column version of VFORTH
2. add a graphics vocabulary to VFORTH

[pixel]

Great! Have seen an editor written in FORTH for the C64 and it was quite small. Cannot wait to see what's possible with VFORTH + gfx.

Got "restore-on-reset" to work… but cannot access my web server, so no demo this time.

p.s.: Got a job, so hacking retro stuff is way more fun.

[pixel]

Cannot let loose of this project at least and I wouldn't mind if symbols in cc65 object files could at least be renamed to generate wrappers for memory banking…

But what did my head in most was the question of how to get every coder here included. BASIC, VFORTH, C, assembly, Rascal, any programming language that is up and running and make this a pandemic. But HOW!?!?

Here's how: good-old Unix style file I/O. What the Ultimem really needs is the Ultimem file system connected to the KERNAL. That way one can already do rather crazy stuff with BASIC (fast overlaying, temporary files, etc.). And that's the right foundation to bring on a second virtual drive: the GUI which essentially provides a browser for hypertext files you write to it. That hypertext format is basically ASCII with new control codes. The user input and events are received by reading from the very same file. Or the browser launches an application via buttons.

Am not a BASIC coder (will go for VFORTH instead) but it'd probably look like this.

Code: Select all

10 OPEN 2, 30, 2, "OPTIONAL TITLE" : REM OPEN WINDOW
20 PRINT #2,"CLICK THE BUTTON TO LAUNCH THE APP!" + CHR(13) : REM DO TEXT
30 PRINT #2, CHR(1) + "CLICK ME!" + CHR(0) + "APPNAME" + CHR(0) : REM DO BUTTON
40 PRINT #2, CHR(0) : REM END OF DOCUMENT, RENDER.
50 INPUT #2, A$ : REM WAIT FOR INPUT
60 PRINT #2, CHR(0) : REM BYE-BYE WINDOW
70 CLOSE 2

Writing the browser is easy fun. It's got auto-layout and tables already. (No images. Can become an editor later.)

But figuring out the KERNAL wedge to simulate a 1541 drive? Duct tape me to a radiator on turn on Death Metal instead.

Please help out with existing source code or links to the right docs. What MUST the virtual device simulate?

And ideas and comments.

And stay healthy at home.

[srowe]

While there is a set of vectors for the KERNAL calls related to I/O creating a wedge for a new device is fiddly. You need to test for the device number at various points, the method varies a bit from call to call.

I can dig out my IEEE-488 re-write and you can use that as a guide.

[pixel]

While there is a set of vectors for the KERNAL calls related to I/O creating a wedge for a new device is fiddly. You need to test for the device number at various points, the method varies a bit from call to call.

I can dig out my IEEE-488 re-write and you can use that as a guide.

Not sure. Thanks! Am having problems getting along with file access in general. Guess I'll have switch to "real" 1541 emulation in VICE to get along.

[srowe]

I can create a wedge that gives you the hooks to catch all operations to a specific device if you like. You can then fill out the implementation for them.

[Mike]

Please help out with existing source code or links to the right docs. What MUST the virtual device simulate?

Kananga's FE3 RAM Disk might serve as useful start point.

This wedge supports KERNAL LOAD and SAVE, OPEN, CLOSE and single character I/O on files (via CHKIN, CHKOUT, CHRIN, CHROUT and CLRCHN). The directory can be retrieved in the same way as on CBM drives, by OPENing the "$" file. Save-and-replace by prefixing "@:" to a filename is also there.

There's a command channel, which provides a minimal subset of the CBM DOS commands, most prominently Scratch, Rename, UI (reset drive) and Position, the latter which not only works for REL files (yes, they are supported!) but also 'regular' PRG, SEQ and USR files where it does byte-wise positioning.

That should give a good idea for the frontend. The backend side will need to be adapted though to implement a Flash ROM File System for Ultimem.

[pixel]

I can create a wedge that gives you the hooks to catch all operations to a specific device if you like. You can then fill out the implementation for them.

Can barely resist but am wedging it in already. Thanks!!

[pixel]

Please help out with existing source code or links to the right docs. What MUST the virtual device simulate?

Kananga's FE3 RAM Disk might serve as useful start point.

This wedge supports KERNAL LOAD and SAVE, OPEN, CLOSE and single character I/O on files (via CHKIN, CHKOUT, CHRIN, CHROUT and CLRCH). The directory can be retrieved in the same way as on CBM drives, by OPENing the "$" file. Save-and-replace by prefixing "@:" to a filename is also there.

There's a command channel, which provides a minimal subset of the CBM DOS commands, most prominently Scratch, Rename, UI (reset drive) and Position, the latter which not only works for REL files (yes, they are supported!) but also 'regular' PRG, SEQ and USR files where it does byte-wise positioning.

I should be just mailing that guy. Excellent sum-up as usual, Mike.

That should give a good idea for the frontend. The backend side will need to be adapted though to implement a Flash ROM File System for Ultimem.

Dude.... it's already there. https://github.com/SvenMichaelKlose/ing ... aster/mkfs

[Mike]

Dude.... it's already there.

May I point you to this thread from two years ago?

Which memory expansions with more than +37K are you using?

... and to quote from my response there:

[...] you could use the FE3 RAM Disk to have an abstracted interface for data storage. It could be worthwhile to port this RAM Disk driver over to Ultimem. [...]

...

[pixel]

[...] you could use the FE3 RAM Disk to have an abstracted interface for data storage. It could be worthwhile to port this RAM Disk driver over to Ultimem. [...]

Yes, you're a genius. But where exactly is the source?

[Mike]

[...] where exactly is the source?

Here: https://sourceforge.net/p/vin20/code/HE ... trunk/fe3/

[pixel]

[...] where exactly is the source?

Here: https://sourceforge.net/p/vin20/code/HE ... trunk/fe3/

Thanks again! As usual with assembly this won't get reused but that's the blueprint I'd need to not spend *ages* on this.

[pixel]

The latest image: http://hugbox.org/pixel/software/vic-20/ingle.img.zip

You can really just launch some apps and get some taste of it. And it'll most likely crash after a couple of times. Am not too happy about it.

Press '?' for help. A reset (ALT+F12 on the Linux VICE) will get you back to the UI instantly.