New GUI for the Atari 8-bit

[ilmenit]

NO - I want the calculator. You get to do the terminal

Calculator? Why not https://en.wikipedia.org/wiki/Abacus ?

[Joey Z]

NO - I want the calculator. You get to do the terminal

no, I already got dibs!

[danwinslow]

 

I wrote an Othello for the GUI, just waiting for the API :-)

https://atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/page-26?do=findComment&comment=2253584

 

Gah! From hell's heart, I spit at thee! Fine, I'm calling Minesweeper then.

[+Stephen]

no, I already got dibs!

OK - maybe I'll try a simple "Paint" then.

[pseudografx]

Today I was thinking about a name for your OS and came up with the title "Antix" or "AntiX".

The initial part refers to the well-known graphics chip in the Atari while the -X reminds of various modern OSes ending with X.

Does anyone else have any other suggestions?

[flashjazzcat]

No shortage of potential developers, then.

 

Took a couple of days out to reorganize my work area (trying to set up dual monitors to improve workflow, but the second monitor looked so abysmal next to the LED backlit one that I shelved the idea), but have since moved the three currently resident system fonts out of main RAM and into an extended bank and started on a proper API for installing them. The UI now rapidly switches between the banks containing resources (i.e. strings for menus, etc) and the bank containing the actual font data when rendering. This wasn't so hard since PORTB is R/W, so the character renderer just pushes PORTB on the stack and pulls it again before exit. Made some improvements elsewhere to soak up the c. 20 extra cycles per rendered character. Note this means that 1MB machines will be able to install dozens of fonts, with each font (currently 32pt maximum) being up to 16KB in size. Of course in practice we'll allocate a smaller number of banks to fonts (only one bank on a 128KB machine, in fact), and fonts will probably be loaded when they are first referenced, and the loaded fonts which are used least frequently will be jettisoned when another font needs their memory space.

 

With this out of the way, I need to finish the window queue (with Z-ordering completely rewritten for multiple applications), code up a few more basic controls, and then see about throwing that process monitor up on the screen. Should keep me busy over the weekend.

Edited August 15, 2014 by flashjazzcat

[ilmenit]

 

Gah! From hell's heart, I spit at thee! Fine, I'm calling Minesweeper then.

 

Any other wishes Sire? :-)

 

To mark mines hold fire button longer on uncovered cell.

Minesweeper.zip

Edited August 15, 2014 by ilmenit

[twh/f2]

OK - maybe I'll try a simple "Paint" then.

 

Very well. then I take XEyes .. should be reasonable hard enough to me

[Shawn Jefferson]

I'll write the first virus, then someone else can tackle the Anti-virus.

 

[flashjazzcat]

We'll need an SIO driver and file system first. On the subject: I'm gonna write a simple file system driver for the cart (rather like SDX's CAR: device) so we can store files on ROM. I don't yet have any means of building a proper file system on the cart yet (FAT, for example), but something simple will do for the moment (such placing bank/address of the file in its directory entry). With that in place, the shell and resident fonts can be loaded from "disk" as they should be, and I can get rid of some of the crude set-up code which block copies stuff off the cart straight into RAM.

 

Spent three hours tracking down a bug in the rectangle list code which was completely preventing any windows from being opened. As usual, and after nasty single stepping of the rectangle splitting code, it turned out to be an off-by-one error which had crept in during the ROM conversion. Window list stuff is undergoing a complete re-write. A window's ID (passed back to the application to tell it which window stuff happened in) is now derived directly from its node position in the linked list, which makes sense given that this position will never change until the window is killed (changes in Z-order are all handled by list pointer adjustment). I promised someone I'd release a demo in 2-3 weeks regardless of what condition it's in. Hopefully it'll at least have the process monitor and some other windows to drag about.

[fibrewire]

We'll need an SIO driver and file system first.

 

I wouldn't have posted, but your PM is full. Remember there is a FAT driver in this particular multitasking OS you mentioned as well as a shell and basic interpreter!

 

http://www.6502.org/users/andre/osa/oa1.html

 

Okay, this time I PROMISE I'll keep my trap shut until something is released

Edited August 18, 2014 by fibrewire

[flashjazzcat]

Yep: I studied Geck/OS and Lunix (LNG) closely when writing the kernel. I've got a more-or-less ready-made read-only FAT16/32 driver left over from the Ultimate1MB/Incognito projects. Driver API, write capability, and a new SIO are what will take a little time. XXL and Hias have been helpful regarding approaches to SIO, which will of course have to emulate the Atari OS quite closely in order to function with external devices.

 

Good call on the shell, of course: that's a must have and I want to start fleshing out a console ASAP.

[Prodatron]

Yep: I studied Geck/OS and Lunix (LNG) closely when writing the kernel. I've got a more-or-less ready-made read-only FAT16/32 driver left over from the Ultimate1MB/Incognito projects. Driver API, write capability, and a new SIO are what will take a little time. XXL and Hias have been helpful regarding approaches to SIO, which will of course have to emulate the Atari OS quite closely in order to function with external devices.

 

Good call on the shell, of course: that's a must have and I want to start fleshing out a console ASAP.

 

A text shell is a real cool sub-task for such a project. It feels like a sub-OS inside the OS. And then you have interesting features like redirection and piping

[flashjazzcat]

A text shell is a real cool sub-task for such a project. It feels like a sub-OS inside the OS. And then you have interesting features like redirection and piping

It's also a total nerd-nirvana.

[flashjazzcat]

Just got CPU load profiling working, using the VCOUNT method previously described:

 

 

The Task Manager process (which I'll equip with a window tomorrow) issues a syscall (Kernel.SampleCPU), passing the address of a buffer. The kernel resets all the process counters and the scheduler then collates VCOUNT ticks during normal operation for the sample period (currently 25,600 VCOUNT ticks: around three seconds). Meanwhile, the Task Manager calls Kernel.MessageSleepReceive, and goes to sleep waiting for a message from the kernel. When the sample period has elapsed, the scheduler copies the sample data into the buffer specified earlier, and sends a message to the Task Manager, waking it up so it can process the data (i.e. throw it up onto the screen), and call the kernel again for the next sample.

 

The memory dump shows the sample results, sixteen bytes per entry:

0-7 Process Name
8   PID
9   Type (0 = RAM, 128 = ROM)
10  Priority (1 = highest, 7 = lowest)
11  State (0 = Asleep, 1 = Idle, 3 = Ready)
12  Approximate per cent CPU usage

So here we have the 'Desktop' process at 29 per cent, 'System' at two per cent, and 'Idle' at fifty. 'Desktop' and 'Idle' are ready, while everything else is currently asleep. We can derive total CPU usage by subtracting the Idle usage from 100. Assuming the sampling isn't way off, the missing 19 per cent can presumably be accounted for by time spent in the kernel, IRQ and NMI. In fact this sounds about right.

 

The Task Manager - such as it is - is shown below:

; ---------------------------------------------------------------------------------
; Profiler process
; This process repeatedly snapshots CPU usage, per process and overall
; ---------------------------------------------------------------------------------

	.local Profiler
	.byte 0 ; bank (populated by kernel)
	.byte 'Profiler' ; task name
Loop
	ldxy #SampleBuffer
	lda #0 ; bank
	SysCall Kernel.SampleCPU
	ldxy #MessageBuffer
	lda #ProcessID.Kernel ; sleep until we receive a message from the Kernel
	SysCall Kernel.MessageSleepReceive
	jmp Loop
	
MessageBuffer
	.ds MessageSize
SampleBuffer
	.ds 256
	.endl

Fairly happy with how this seems to work.

Edited August 25, 2014 by flashjazzcat

[Prodatron]

This communication between the task manager and the kernel is an interesting way to do it. I wonder what happens, if you start the task manager twice? If there is no task manager running, the kernel won't count the ticks?

Do you work with BCD numbers? First I thought it would be 41, 2 and 80 per cent (a total of 123).

[flashjazzcat]

My God... You're right: they're hex values. I shouldn't code so late. So there's some tweaks to make. A second sample request before the first won't work, so there'll have to be a mutual exclusion mechanism.

 

EDIT: the sample buffer was being overwritten by global variables (which needed moving), hence the spurious results. This looks a little saner:

 

 

Idle 66 per cent, System 2 per cent, and Desktop 5 per cent.

 

Yes: the IRQ should avoid counting ticks if there is no outstanding load sample request. I'd considered having the system process handle the application's request: at least this way, multiple requests would be queued up, avoiding contention. In any case: it's appealing to let the task manager go to sleep until there's a fresh set of data.

 

 

The second sample was taken while moving the mouse and pulling down menus. Desktop is now at 25 per cent, and Idle at 47 per cent. I suppose we could quote kernel/IRQ work at 27 per cent here.

Edited August 25, 2014 by flashjazzcat

[flashjazzcat]

Tested multitasking version on real hardware for the very first time:

 

 

Not much whizz-bang, but there are five running tasks and it works. Redraws are a little sub-optimal since some routines need grouping together in the same ROM bank in order to reduce banking overhead. This one's still using BRK kernel entry as well - mainly so I could see it working on a real 6502.

[w1k]

its possible show demo-ROM file for flash?

[flashjazzcat]

Yes: in two weeks' time.

[+MrFish]

This is running on a standard AtariMax 128K flashcart?

[+MrFish]

Nevermind; dumb question. The cart is sitting right there on the machine at the beginning.

[+Philsan]

Jon, will you make an .ATR loader for 1Mbit *and* 8Mbit AtariMax flash carts?

 

I have to buy a cart for your GUI and for Atari Blast!

(the cart I have is dedicated to Space Harrier).

[flashjazzcat]

Jon, will you make an .ATR loader for 1Mbit *and* 8Mbit AtariMax flash carts?

No problem Phil. It's easy to make ROMs - and thus flashers - for just about any cartridge out there. I have MaxFlash 1Mbit and 8Mbit, MyIDE, MyIDE II, SIDE2, and Sic! here for testing. Not forgetting the 64KB of Ultimate 1MB ROM space too. Version 2 of UFlash handles all the above, but it's not complete yet and I'm not sure when I'll get time to finish it, but of course ATR flashers will do just fine for point releases (although they're less convenient for rapid testing, hence the reason I wrote UFlash in the first place).

Edited August 26, 2014 by flashjazzcat

[flashjazzcat]

@Prodatron: does the "super-window ID" in a window record comprise the only hierarchical link in the application/window layer structure? I assume super-window 0 is the desktop. This seems a reasonable and capable way of maintaining parent/child relationships in a simple linked list of windows, although a binary tree has been suggested as an alternative. I wondered how you see it.