Jump to content
IGNORED

New GUI for the Atari 8-bit


flashjazzcat

Recommended Posts

>Having lacked energy all week, well - you just reminded me why this project is FUN.

That redraw speed is really cool. And as the dragging actually continues while is redrawing, it looks quite natural.

Link to comment
Share on other sites

I'd have to soft-load SuperTOS on my STE to get a true impression: I have no idea how accurately the blitter is implemented in Steem.

 

Burned the A8 ROM to a Maxflash cart this evening and tested it on real hardware for the first time since August (when I first ported the thing to ROM and was half way through writing the kernel). The odd thing is that it feels faster on real hardware.

 

Note: video strobes a bit.

 

 

Still a few cosmetic issues to fix (mainly owing to auto-refresh being disabled in the process list, resulting in some initial rogue CPU load values), and I really want to get live list scrolling done tomorrow, time permitting.

Edited by flashjazzcat
  • Like 10
Link to comment
Share on other sites

Awesome! Even has the column-based sorting on the list box working!

 

Will the opaque Window drags be optional? I always found them horribly distracting until things like Quartz Extreme in OSX came along. An impressive technical achievement though.

 

So are things like the filesystem drivers external modules or are they baked into the kernel?

Link to comment
Share on other sites

Will the opaque Window drags be optional?

Yes, absolutely.

 

So are things like the filesystem drivers external modules or are they baked into the kernel?

I could have taken a monolithic kernel approach and used syscalls for file operations, but I'll probably follow SymbOS and have filesystem drivers which belong to the system process. Applications just send messages to the system process in order to handle files. The filesystem drivers will be the major job for 2015.

Link to comment
Share on other sites

I want a demo for the GUI where a dog and a cat watch the mouse pointer move around... if the pointer gets too close to the Cat it takes a swipe at it... If the pointer gets to close to the Dog he takes a bite at it!

 

Glad to see you are concentrating on the 4 C's!

 

I still think about what an O.S. should be and always remember this funny video about winblows 8/8.1 it explains it all and is funny to watch...

 

https://www.youtube.com/watch?v=WTYet-qf1jo

 

http://www.youtube.com/watch?v=WTYet-qf1jo

Edited by _The Doctor__
  • Like 4
Link to comment
Share on other sites

Busy debugging the memory allocator now. It's based on the page allocator from LNG. I could see no point in writing the same thing from scratch, so I used the Lunix code and modified it to suit our banking strategy. I emailed the author to let him know this some months ago but I never received a reply, and since the LNG page hasn't been updated since 2004, I don't really expect one. But anyway: it's a nice compact allocator and maintains a bitmap of 64 x 256 byte pages. It does best-fit and fast single page allocation (the LNG kernel provides two separate calls for this, while I've combined them so the allocator uses the fastest option depending on the number of pages required). Errors which crept in during modification have been ironed out.

 

Unfortunately all this needs to be finished and working before I can get the RAM stats in the profiler to provide meaningful information. Similarly, the relocator also needs to work so that the loader can place the applications into properly sized chunks of RAM.

 

I've also done quite a bit of work on formatted output, and the list control now clips and centres and blocks right columns:

 

post-21964-0-38517100-1420488153_thumb.png

 

Similarly, the stats at the bottom of the monitor tab are now actual values rather than just dummy text:

 

post-21964-0-74813500-1420488217_thumb.png

 

There are several ways to display formatted numbers. The fastest (for subsequent redraws, if the numbers don't change so often) is to call the kernel's hex to ASCII conversion routine, which will handle 8, 16, 24 and 32 bit values and create a string at a specified buffer, with or without comma-separated thousands. This plain string control is then clipped and blocked right. There's also a formatted numeric string control which does the number conversion every time the dialog redraws, but obviates the need for explicit conversion inside the application.

 

Processes are now properly flagged as applications, shared services, or timers, so I can populate the "Applications" tab as well. I won't get too hung up on finishing too much stuff, since after this demo comes out, the release cycle is going to be a lot faster. What really held things up in the past was constantly running out of code space (hence I had to go away and rewrite the thing so it ran off a cart), but that's no longer an issue and things are progressing at a fair lick.

 

Edited by flashjazzcat
  • Like 9
Link to comment
Share on other sites

Hey Flash, will this project include a memory manager? Something that abstracts away bank switching and allows applications to scale (still only up to the full size of a single bank, I guess)? Along those same lines, do you intend for the resultant software to offer an environment that scales in feature set and performance up to some of the recent big memory sizes and super-fast storage? I know you have been committed to ensuring that the project can run on real, unmodified hardware and I think that is right on. Just wondering if the design leaves those doors open.

Edited by pixelmischief
Link to comment
Share on other sites

If you mean can applications allocate memory dynamically, then yes. And applications never write directly to the bank-switching register (indeed, they never write directly to any hardware).

 

There's no virtual memory, but performance will naturally ramp up the more resources it's possible to keep in RAM at one time. A good example: fonts. They can get quite big (up to 16KB when you get to the 32pt size), and less frequently accessed fonts will be purged from memory when it's required for applications. So if there's ever some application which uses a bunch of large fonts, having a lot of RAM will help. Likewise, if you run everything from a fast hard disk anyway, the pain of loading resources from disk will be lessened.

 

I'm working on the relocating loader as we speak (for MADS relocatable binaries). Getting this working will be a milestone.

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

Yes - as per the MADS description here:

 

http://mads.atari8.info/mads_eng.html#_relok

 

The loader's already written but needs testing, and this requires a rough and ready ROMdisk handler which I'm working on now. The loader isn't terribly complex, though.

 

Now, the MADS format is all very nice, but has a few limitations, so I'll probably support a second relocatable file format which loads binaries with relocation tables prepared by assembling at different offsets. A simple command line tool in C shouldn't take long to write. This will at least mean that use of MADS for application authoring isn't absolutely mandatory.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...